Why Traditional “Fixed Bid” Software Projects Usually Fail

Paul Dittmann, Tuesday, December 15, 2009 @ 7:15 am

By now almost everyone has figured out that traditional fixed bid doesn’t work for software development projects, especially where effective, intuitive user interaction is a significant component of success.  Over time there has been a lot of effort devoted to finding the underlying reasons for project failure.  The Standish Group Chaos Report for 2002 found that 45% of features developed were never used, their 2008 Chaos Report found that typical software projects come in at 189% of original estimates (there is an obvious correlation there), and many studies over the years have concluded that an uncomfortably small percentage of development projects are viewed as meeting or exceeding expectations or providing competitive advantage.

Hidden implications of “fixed bid”

Although you need to provide a target budget to get projects approved, “fixed bid” for application development starts of with a faulty basic assumption – that user, functional and system requirements are fully known and documented in a way that enables efficient development. True fixed bid also implies “waterfall” development and two assumptions: 1.) you have completed a thorough, efficient design phase, and 2.) requirements won’t change during the development process. Neither of these assumptions are realistic.

Fixed bid usually creates a mind set that change orders will increase costs. Although you could look for other areas to reduce scope to compensate for the cost of any new requirements or increased complexity uncovered during the development and testing periods, this seldom happens. It also means that a less than thorough job will be done in identifying unneeded features or features that could be developed at a more basic level. These will tend to be built as defined in the initial requirements whether they provide value or not. The above goes a long way towards explaining why “fixed bid” projects are almost always over budget and late.

But that’s not the greatest risk. What if you can’t get the additional budget needed to address the new and enhanced requirements uncovered and you have to deliver the project as originally specified, on-time and on budget. You now probably end up with a product that provides limited or no value and has difficulty gaining user acceptance. Even if it is launched rather than abandoned, the cost of forcing acceptance probably exceeds the additional cost of building a better application (of course those costs come out of someone else’s budget – so you can probably pretend it was a successful project).

Agile "fixed bid", managing to a cap - change does not = increased costs

With Agile, the cap can provide the ROI comparison number needed to get project approval. It is as “fixed” as a “fixed bid”. The difference is the focus and how change is managed. Rather than focusing on how much money is being spent (on time, on budget), it focuses on how much value is being created (what are the features that provide the highest ROI for a given amount of dollars). Instead of changes in requirements and increased complexity being treated as surprises that need change orders, change is expected and its impact is being continually be evaluated to help ensure the most important features, those leading to greatest ROI, are always being worked on first and that features determined to be of little or no value are treated accordingly (just reducing the percent of features developed but not used from 49% to 25% is a huge win). With Agile, the entire team – developers, business stakeholders and users – is clearly focused on making sure you end up with the best product that can be produced for any targeted budget number.

Related posts:

1. Requirements Set in Stone and Software Made of Concrete
2. Kanban for Bench Projects
3. The Origins of Software Engineering Economics — You are Ron Turcotte
4. Agile Development Improves ROI – But RFP Processes are Stuck in Waterfall.
5. Agile, The Control Paradox, and the Boring Software Manifesto

Comments (2)

Software Development

Comments: 2 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. [...] Just found a great article on why fixed price projects fail. Paul Dittmann has writing a great article on it which you can find here [...]

   Pingback by Why Traditional “Fixed Bid” Software Projects Usually Fail | Sentia | Sydney IT Consultancy, Software Development, Ruby on Rails, Web Application Development, Rails Development, Test Driven Development, Microsoft.Net, Asp.Net , Agile, Continuous Integ, Wednesday, December 16, 2009 @ 8:42 pm

2. 

   Paul, great article and a topic that I believe is timely. The Standish Group’s findings on project failures have not changed much since 1994. Like you, I think that applying Agile development techniques is one way to improve your project success rates.

   I recommend that you spend some time in a future article describing agile development a little more including how the team works together to prioritize the features to be developed and how iterations or sprints are established. I’d be happy to contribute to that or co-author an article with you.

   Happy holidays!
   Anthony Mersino

   Comment by Anthony Mersino, Tuesday, December 22, 2009 @ 6:03 am

Leave a comment