Why Traditional “Fixed Bid” Software Projects Usually Fail

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

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 off 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.