A Solution to Fixed-Bid vs. Hourly Contracts (Part 1)

Right now, I’m waiting for Audi to give my car an oil change and fix a problem with the power steering. While the technician told me that it shouldn’t take more than two hours, we’re nearly at three (and counting.)

Of course, the moment I wrote that, the technician came over to explain the delay. Turns out they found a couple of unexpected (but legitimate) issues which they needed to fix. Things weren’t quite as simple as he originally assumed.

Pretty typical.

Which brings me to this. If an auto-mechanic can’t accurately estimate a quick and simple car fix, what hope do software developers have when building something new and complex, over the course of many months (or years,) that’s never been exactly done before?

Technology projects are notorious for cost overruns.

The Hubble Space Telescope, which has allowed us to look back in time nearly all the way to the big bang, was originally supposed to cost $400 million to build. Final construction costs actually came in at $2.5 billion.

Boston’s “Big Dig” and Denver’s International Airport were each supposed to cost $2.8 billion. They cost $14.6 billion and $4.8 billion respectively.

A study performed a few years back by the Standish Group discovered that 71% of IT projects were over budget with a total average overage of 43%.

Why does this happen? And what does a space telescope or a major construction project have to do with your website or intranet?

The answer is they are all creative exercises. They are unique. There isn’t another tunnel exactly like Boston’s in the entire world, and there isn’t another website exactly like yours. You can’t build your website on an assembly line, and if you could, you really wouldn’t want to.

Sure, it would be great if we could send a bunch of commodity-priced raw materials into an airport construction factory, click the “on” button, wait a predictable amount of time, and out comes your airport, ready for takeoffs, landings, and weather delays.

Predictable inputs. Predictable outputs. Ah….

But websites and intranets are more like art, music, and literature. I want to commission you to compose a 45-minute orchestral masterpiece for our symphony. How much time will that take you? Um…

"Websites and intranets are more like art, music, and literature..."

OK, not all web projects are complex. Some are simple and straightforward and can be easily developed by your nephew who learned some HTML as part of a school project. Those just aren’t the kinds of projects we work on.

Six Feet Up builds sophisticated websites, intranets, and extranets.

For example, we develop a lot of websites on Plone, an open source, Python-based content management system. Plone is perfectly suited for complex content management, customized content types, intricate workflows and permission structures, and integration with other discrete technology platforms (i.e. CRM systems like Salesforce, authentication systems like LDAP, etc.) With Plone, you can create and manage numerous sub-sites that inherit content and templates from a parent site. You can build a global website, managing content in dozens of different languages.

Plone is unbelievably powerful and flexible. It’s also quite user-friendly for content managers.

But, Plone development is not simple. For those with generic, simpler needs, a solution like WordPress may be more appropriate (and easier to estimate.)

So when it comes to budget estimates, where does this leave us? When every project has unique requirements, how can a precise estimate be developed? (It can’t.) And how can any project move forward without a reliable budget estimate? (Again, it can’t.)

What kind of payment structure can be created that’s fair for all parties?

"What kind of payment structure can be created that’s fair for all parties?"

We have an answer that’s worked extremely well for our clients. Our solution and process aligns interests and minimizes risk. It provides transparency and allows flexibility. It’s relationship-building and hands-on.

What is it?

Stay tuned for part 2 where I go over why "Time and Materials" contracts are the only sensible structure for sophisticated software development...

Want to be notified when similar blog posts get published? Sign up here….