The Dire Consequences of Fixed Price Projects

Posted by Ben Hughes on May 03, 2007

Sections

Process & Practices,

Architecture & Design

Topics

Customers & Requirements ,

Methodologies ,

Agile

Tags

Waterfall ,

Planning ,

Contracts & Negotiation

Scott Ambler in The Dire Consequences of Fixed Price IT Projects lays out in print the common problems with fixed price projects and the bad habits it forces on the project team.

• Big requirements up front (BRUF) approach where you create a detailed requirements specification early in the life cycle.
• A change management process which strives to avoid "scope creep" throughout the project.
• A big design up front (BDUF) approach where you attempt to specify your architecture in detail before coding begins.
• A software development life cycle that is mostly serial in nature.

He then goes on to discuss each of these points in detail, illustrating how a fixed price project forces the project down a non agile route, right from the start.

Scott walks through the project life cycle, tying up the all too common events of strained projects with the fixed price characteristics, paying particular attention to how rigid change control and  up front estimation encourages the customer further along the fixed price project route. He also notes that "Fixed-price IT projects aren't good for the developers working on the project because it motivates questionable behaviors which put your job at risk in the long term."

In summary, Scott calls for a revisit in how we fund our IT projects, as clearly fixed price puts unacceptable, controlling constraints on both the business stakeholders and delivery team alike.

The alternative to fixed-price projects is of course variable-priced projects. In practice it is much easier to reduce financial risk on variable-priced projects with gated investment based on interim deliverables (ideally working software).

Further Reading:

Optional Scope Contracts, Kent Beck and Dave Cleal

1. Back to top

   Only partially true

   by Al Tenhundfeld

   With all due respect to Mr. Ambler, I disagree with his assessment. Yes, those issues he lists -- BDUF, BRUF, mistaking change management for change prevention -- are all really big problems in the industry that most seasoned professionals know to avoid.
   
   However, I don't believe that fixed-price engagements have much effect on how likely you are to make those mistakes. If you take an agile approach to fixed-price engagements, you focus on delivering the most business value as quickly as possible. Instead of framing the contract as we will deliver these exact features in this timeline for this price, effectively fixing all three sides of the triangle, you frame the contract to say that you will deliver the best possible value, accomplishing at least a critical subset of ROI-maximized features with regular customer interaction and provide the ability to reprioritize features before any given iteration.
   
   I think it's easy to argue that fixed-price projects encourage developers to focus on delivering valued products instead of focusing on their billable hours.
   
   In my opinion, T&M projects are no more likely to succeed than fixed-price. Unless you're a salesman or in charge of invoicing, I don't think T&M vs fixed-price really has much effect on the lives of developers or the quality of the product.

   Reply

2. Back to top

   Re: Only partially true

   by Ådne Brunborg

   Fixed Price is only a problem if the project managers allow it to directly influence the way the project is managed. Any B*UF will force the project in the dreaded Waterfall direction, and it is the PMs job to stop it from doing so. An Agile PM who goes for B*UF is not Agile at all.
   
   The problem for the salesman, however, is how to decide upon the fixed price without any B*UF? While an estimate based on an educated guess ("gut feeling") often is just as correct as one based on B*UF, it isn't always so easy to convince salesman of this. This is one reason why Fixed Price should be avoided - not because it will influence the development team negatively (it shouldn't affect it at all), but because it is harder to get acceptance for a fixed price not based on B*UF.

   Reply

3. Back to top

   T & M Contracts are abused

   by Dean Schulze

   There are lots of good points in Ambler's article. Both Ambler and Kent Beck (in the link above) point out that fixed price projects put the two parties interests in contention with each other ("I gain at your expense") instead of aligning their interests ("We both gain").
   
   The alternative to fixed price contracts is usually a time and materials contract. T&M contracts are what major consultancies use to fleece their clients, especially governments.
   
   It would be very interesting to see what percentage of T&M contracts are successful (on time and within budget) as judged by those who pay for the software.
   
   The flip-side of T&M contracts is that they allow the client to change the requirements any time they want. Irresponsible requirements changes can also doom T&M projects.
   
   T&M contracts seem doubly bad. They only way they can work is with conscientious management by the client and ethical performance by the vendor.

   Reply

4. Back to top

   Fixed price user stories

   by Pranab Ghosh

   Fixed price conract seems to work better at a more granular level i.e. user stories. An entrepreneur friend of mine is using this model to pay his consutants for developement work. It seems to be working out nicely for him.

   Reply

5. Back to top

   Fixed Price Projects Possible Using Agile But...

   by Dwight Ferguson

   Having recently had to speak to the matter of fixed price projects using Agile while speaking at a PM workshop it is certainly possible to use Agile on a fixed price project, however there are some caveats...
   
   Fixed Price Projects Typically Possess Other Fallacies from an Agile Perspective:
   For consultants and/or contracting firms bidding on projects based off a client/vendor provided RFP with all the requirements already stated "up-front", this is in itself an issue for true Agile projects as one of the core principles advocated within Agile itself is that the business customer does not truly know all the requirements for their system/product up-front. These "up-front" requirements will almost assuredly change over the course of the project and therefore there needs to be a means to allow new or changed requirements to be added to the project while at the same time preventing the cost & duration of the project from spiralling well above the agreed upon "fixed" budget.
   
   If RFP's are an absolute must in the bidding process, certainly breaking a "colossal" RFP into as many smaller deliverables as makes sense could also be advantageous as again Agile promotes breaking things down so as to ensure more accurate estimations - the Agile philosophy being the smaller the measure of work, the easier it is to plan & accurately estimate. The theory behind this is that contractors bidding on a series of smaller customer RFPs will have a better shot at being accurate and therefore being closer to on-time and closer to budget for the series of fixed price project deliverables as opposed to bidding & estimating on the larger entity.
   
   Newly Identified "Higher Priority" User Stories Must take the place of Previous Stories of Equal Size and Value (Limit Scope):
   For every and any new user stories/business requirements identified during the course of the fixed price project an existing user story of equal size and value must be removed from the scope of the project or be pushed to a future product release. This is one of the most effective ways to prevent any adverse impacts to the date of the initial scheduled release. Remember that fixed price also means that the Release Plan for the project cannot simply be extended an additional iteration because fixed price will also translate into a "set project date deadline". Having said this, there is an implication that future releases can be planned and estimated and therefore receive their own budget. Anyone who has familiarity with the ScrumMaster certification materials will come across such an example with how to deal with Fixed Price engagements & managing changes to existing requirements or new requirements identified throughout the project.
   
   Also, I would like to dissuade anyone from resorting to the knee-jerk horrific practices of simply adding more bodies to the project or requiring existing project resources to work longer hours as they typically prove ineffective & harmful to the quality of the end product. Both of these practices, generally-speaking, lead to poorer quality products(more bugs) and to hasty engineering decisions, too many cooks in the kitchen (if adding bodies adopted), lowering project morale, etc...
   
   Issues with Fixed Price Projects Not Specific to Agile-Based Projects:
   I would also like to note that the issue of fixed price projects and the matter of project scope creep or scope change is not an issue specific to Agile projects as waterfall style projects have the exact same issue when it comes to project scope changes, that's why the formal change control request form was created. Again, something has to give when dealing with fixed price projects, either previously identified user stories are eliminated or pushed to a future release in lieu of newly identified "higher priority" stories or the overall date of the project's completion & hence the project's cost will be negatively impacted if new scope changes are added, but nothing is removed or pushed to a future release that will possess its own budget.

   Reply

6. Back to top

   Re: Only partially true

   by Tiberiu Fustos

   Having worked for a consultancy specialised in fixed-time/fixed-price projects, I have to say that I have experienced both good and bad. Since the scope was part of the contract (BRUF), missing the deadline meant automatically losing money - basically the work after the deadline was on the cost of the service provider.
   
   The interesting part however, was that the service provider has full freedom about staffing decisions and internal project organisation. In theory, it was possible to perform the design/develop/test phase using any agile methodology, including scope changes - since each new feature has to be traded for something else (another feature, time or money).
   
   Usually it goes wrong exactly because of this up-front estimation - now I like the idea of "variable funding", but I still find it difficult in corporate enviroments where there are many other constraints (release dependencies, budgeting cycles, approval processes etc.).
   
   However, that the agile community started to look for solutions for the funding aspects shows a certain sign of maturity. At the end of the day, I have to agree with Jeff de Luca: "agile methods are more suited to types of people and organisational cultures than types or projects".
   
   The promise of "bringing business on board" unfortunatelly comes from so many sources nowadays, that it's hard to find the right method (btw. 5 years ago, FT/FP was the coolest way to keep business "aligned" with IT...).

   Reply

• Older >