Fixed-Price Projects and Scrum

Comments Off on Fixed-Price Projects and ScrumWritten on November 28th, 2010 by
Categories: Business, slider
Time and time again people discuss whether or how Scrum fits into projects with fixed-price contracts. Within those discussions, fixed- price models are considered to be very difficult. However, in many areas fixed-price projects are standard and this will likely not change in the near future, despite the many disadvantages of this type of contract. Getier unterwegs Since my field is also dominated by fixed-price projects, here are some thoughts on the subject.

Fixed-Price Projects – Price is not the only thing that is fixed

In a fixed-price project, all essential parameters are set:

  • The offer specifies the price, there are no variables
  • The specification defines features and scope
  • Delivery dates are fixed in most cases and penalties for missed deadlines are intended to encourage on-time delivery
  • Concerning quality, the phrase “ according to current technical standards” is often referenced; a phrase that provides enough ammunition for lawyers

At first glance, a fixed-price contract gives the impression of providing a secure basis for a project. Problems, however, lie in the details.

Typical Challenges with Fixed-Price Projects

Examples of typical challenges with fixed-price projects are as follows:

  • Price is often driven by competition. Estimates of development departments are being revised downwards, risk is not appropriately factored in. Sales are often measured by turnover of transactions rather than if promised results can be delivered.
  • Requirements and specifications are generally neither sufficiently accurate nor error free. Even if it were so, specifications written before the first real phase of the project would never truly meet the needs of the customer. And these change constantly.
  • Generally one only has limited options to work closely with (potential) clients when bidding on fixed-price projects. There is also a considerable investment (of time) that only pays off if an offer is attractive enough to be awarded the contract for a project. “Attractive” here is often defined by cost.
  • Deadlines are often set by wishful thinking. Possible risks are being ignored here also.
  • Quality standards are not agreed upon and all parties involved have different perceptions on how quality is defined.

In his article, Roy Morien writes a crucial sentence (quote) that is probably said by fixed-price project clients at some point or another:

Oh, but surely you understood that {some feature or process} is part of what we asked for.

In many cases the client was not aware at the time of awarding the contract that function and process are part of the scope. Otherwise he would have had to have stated this after receiving specification. Generally the customer cannot be exempt from involvement.

Procedures for Proposals and Execution

Generally, there are two ways to deal with challenges regarding fixed-price projects:

  • For lesser challenges, “buffers” are used to avoid unnecessary friction through negotiation of change requests. A method that is not truly recommendable, since the buffer can generally be used in other positions and as a result, trust can be broken.
  • Commonly, change requests must already be discussed shortly after start of a project. Change requests tend to have an impact on project budget and deadlines. Sometimes functions can be successfully exchanged, this means to adjust the scope of the project.

Success Factors

Deciding factors for fixed-price projects are often things like

  • Openness and Trust: Are contractor and client communicating openly and is there a basic trust between both parties?
  • General Agreement and Purchasing: Is the general agreement fair or is one party at a disadvantage? When or how should the purchasing department/project management be involved? What policies and procedures exist?
  • Comprehension: Are change requests understood by both parties? Are costs understood?
  • Change Management: Were provisions for dealing with change request outlined during contract negotiations?
  • Flexibility: Is the client holding back part of the budget for the project in order to be able to promptly pay for change requests? Is he flexible enough to change requirements?
  • Capacity: Does the contractor have the capacity and ability to implement desired changes in a timely fashion?

There are a variety of opinions from the agile community

The topic of fixed-price projects has always triggered different reactions. Discussions are even more intense in the agile community. Scott Ambler, for example, considers fixed-price projects fundamentally unethical:

Fixed price work is unethical. As wannabe professionals we need to stand up to the bureaucratic treadmill.

Peter Stevens gave a key note speech on the subject of fixed-price projects and scrum at the Italian Agile Day. You can read a brief summary about different types of contracts –incl. fixed price- here. Simon Baker already wrote about fixed-price projects a long time ago:

To say how much something will cost, you need to know in great detail exactly what needs to be built so that your estimates for the work can be accurate. But you can't define everything you want, in detail and up front, and get it exactly right so there will be no changes in the future. And no estimate is ever accurate (it wouldn't be an estimate if it was). […] Don't base the contract with your vendor on conformance to a detailed requirements specification. If you do, you're saying all your good ideas happen at the start of a project and you're effectively betting all your money on a hole-in-one

In response, one of his readers discusses his experience with a fixed-price project:

[…] fixed price contract where the client and contractor fought endlessly over what was included in the price I endorse everything said above. Unless you are exceptionally lucky your fixed price contract will be toxic to the client supplier relationship.

Paul Klipp explains in his article why fixed-price projects are also bad for the client: Why Fixed Bids Are Bad for Clients (Scrum Alliance). An older article (German) on gives an overview various forms of contracts in agile organizations.


My conclusion on fixed-price projects is that it is still a very popular type of contract in the industry and it is associated with many challenges. The reason for this is that it is looks like a safe deal for client at the first glimpse. You can react well and flexibly to changes, even with fixed-price projects – if client and contractor approach this subject openly and are interested in a win-win-situation. However, if there is no basic trust, it can quickly turn into a lose-lose-situation: At best, the client will get what he has specified – not what he really needs. A provider that, at first, seemed to be inexpensive can turn out to be comparatively expensive when it comes to change requests. For providers fixed-price projects are always a major challenge, especially if a large profit margin or a large safety buffer cannot be factored in. Normally a fixed-price projects must be always sold more expensively than projects with a times and material contract as for such contracts risk provisions, bargaining chips, buffers and additional transaction and analytical costs don’t play a role.


Tags: , , ,