The 'fixed price' myth

‘Fixed price’ contracts aim to limit costs and to transfer the risk to the supplier. This works very well for projects in which the deliverables are defined clear and unambiguous – leaving no room for interpretational differences. But for many projects the deliverables are far from clear. The supplier provides a quote using numerous assumptions and selecting a most cost-effective solution. During the course of the project, countless decisions need to be made. For the intended user community there is no incentive to go for the least costly option: the project costs are fixed, so filling in details is considered to be ‘part of the deal’. The supplier however, will consider the more elaborate options as additional scope – and will raise change requests to cover the extra effort. Whether the client agrees and extends the budget or the supplier pushes for the least-but-still-fitting-the-requirement option – the client will feel that the fixed price is not adhered to and that he is not getting value for money. In other words: the fixed price is perceived to be not so fixed after all.

'Fixed price' for a 'fixed size'

The good news is that there is a good alternative for ‘fixed price’ – one that still provides cost control and is geared towards realizing the functionality that is really needed (and so actively contributes to risk reduction). This alternative is a ‘fixed price’ for a ‘fixed size’. This principle has proven itself in combination with agile projects – in which the functionality is developed incrementally in short iterations with frequent user interaction. At the start of the project all functionality is described on a high level (e.g. through Smart Use Cases) and prioritized (MoSCoW). Using a function point analysis (Like NESMA2) not only provides insight in the size of the application, but does this in an objective and comparable manner. This has a number of advantages. First, client and supplier can agree on the number of hours (and associated cost) that will be spent per function point. With the function point analysis, the client can compare the supplier’s productivity to industry benchmarks. Second, the project size can be agreed on before the project is started.

Independent bench-marking

Now a ‘fixed price’ can be agreed on the number of function points that the project will deliver. In other words: a ‘fixed price’ for a ‘fixed size’. At the end of the project a final function point count can be made. The advantage of certified function point analysis methods like NESMA2 is that they enable the client to have an external party verify the outcome. The client pays for the actual number of realized function points. As an alternative the complexity of the application to be realized can be measured with Smart Use Case Points. Although a benchmark for Smart Use Case Points is less objective (as it is dependent on the current team), it can be determined by running a pilot first and serve as a basis for the ‘real’ project.

"You know what you need when you get what you asked for"

With the issue of ‘are we getting value for our money?’ out of the way, the key-users can concentrate on what their needs are. I firmly believe in the saying that ‘users know what they need when they get what they asked for’. The agile approach takes this into account, actively involving the key-users in the iterative development process. Experience from many projects shows that about 75% of the functionality is more or less realized as envisioned, but up to 25% of the functionality is modified or replaced due to progressing insights. For that reason not more than 80% of the functionality should be prioritized as ‘must have’. This means at least 20% is available for progressing insights – effectively replacing lower prioritized functionality. As all changes in functionality are communicated in function points, stakeholders can actively manage the project within the budget constraints.

A satisfied client is all that counts

The following analogy sums it all up: picture a client walking into a grocery store with 10 Euros and a shopping list containing potatoes, sprouts and tomatoes. Seeing the actual fresh produce, the client changes his mind and buys potatoes, broccoli and strawberries, and will probably enjoy a nicer meal because of it. At the end of the day a satisfied client that feels he got value for money is all that counts.

Join the discussion

I would love to hear from you! Join the discussion on LinkedIn Pulse, where this article has also been posted: https://www.linkedin.com/pulse/fixed-price-agile-jacques-dunselman.