Agile and Fixed Price?

First, let’s pin down what “fixed price” actually means. It’s not just that the customer demands to know as precisely as possible how much they will have to pay for the project (which, on the surface, is not an unreasonable request).

Usually, the customer will also want to fix what it is that they are going to get – the scope. Often, the customer is interested in getting the deliverable by a certain date, thereby fixing the time as well. In reality, therefore, it often makes sense to speak of “fixed iron triangle” projects.

On the surface there is nothing unreasonable about wanting things done this way. We all act like this when we want our kitchen remodeled, for example. So, why isn’t this approach working very well on software projects? As a recent study conducted by McKinsey and the BT Centre for Major Programme Management at the University of Oxford of more than 5,400 IT projects demonstrates, software projects (especially large ones) on average run 66 percent over budget and 33 percent over schedule. In reality, fixed-price contracts hardly “fix” project costs or schedules.

Scott Ambler analyzes in detail both why customers demand fixed price and why fixed-price contracts tend to set projects up for failure. One reason is that the software profession as a whole is not exceptionally good with estimations, making the predictability of a fixed price project an unattainable illusion. Also, as Martin Fowler points out, the fixed scope is really not so fixed in most cases, as requirements tend to change over time, plus there is always a discrepancy between how the requirements are understood by the business and by the developers. Moreover, being held to a fixed estimate motivates IT providers to adopt strict change management policies, reducing customer motivation to change their defined requirements, even if their requirements have in fact changed. Thus, as Scott Ambler argues, the ethics of fixed-price projects are questionable because they essentially motivate customers to pay for functionality they really don’t want.

Another problem is that when a project is slipping and pressure is put on developers to still deliver on time and on budget, they begin to cut corners, and quality is the first victim. As Ken Schwaber continually observes in many of his books, articles, and talks, customers often don’t want to hear the harsh truth (e.g. that the deadline is not going to be met), and developers are afraid to tell them: “The [customers] want to believe in magic, and the developers support the belief by lying. ‘Can you do this project by this date?’ ‘Sure, no problem.’”

The consequences of disrespecting the iron triangle are always dire. One way agile may help bring the desired transparency in terms of project costs is by replacing “fixed price” with “fixed budget”. Your financial outlays are capped, and the deadline may be fixed, but you get to vary the scope and make changes to the requirements based on the reality of how the project is actually going. Some agile companies offer customers the opportunity to introduce new requirements on the fly but at the cost of giving up blocks of outstanding lower value functionality.

What is your experience with the fixed price, fixed budget, and agile?

This post originally appeared on TechWell.