A common design of a fixed-price, fixed scope agreement is:

1. Attempt to define the solution up-front, based on expert knowledge and instinct
2. Establish a competitive procurement process, based on the defined requirements
3. Select the partner who promises the best combination of cost effectiveness and compelling proposal

The above approach effectively guarantees failure. Unfortunately, it is a popular approach among large enterprises. I can understand why. It seems to promise achieving the required outcome while shifting all risk to the vendor. In addition it looks like it should achieve cost effectiveness due to the competitive procurement process. This procurement approach is an understandable attempt to apply practices that work in other domains, such as purchasing heavy equipment or the construction of roads, to the domain of software development. The approach fails because software development is not the same as building a road, specifically it has much greater uncertainty and much lower cost of change.

The unfortunate irony is that the well-intentioned attempt to protect the purchasing organisation almost guarantees an unsuccessful outcome. This happens because the procurement logic described above rests on a number of incorrect assumptions.

Myth 1: The customer knows, and can define, the solution to their problem

Observe Jonathan Rasmusen’s facts of software development:

1. You can’t gather all the requirements up front.
2. The requirements you do gather will change.
3. There is always more to do than time and money will allow.

In the beginning, I don’t know the solution to my customer’s problem, and nor do they. The competitive procurement process presupposes that it is possible to define what is needed so that vendors can propose approaches and compete on price, with a shared definition of what will be delivered. It is not possible to precisely define a solution and if it was you’d be defining the wrong solution anyway. Inexperienced customers think they can define what they need. Predatory vendors know better and exploit the knowledge asymmetry, making their money on change requests. Fixed-price, fixed-scope doesn’t fix the price at all.

I once triggered an angry reaction in a project sponsor when I asked why the organisation wanted to fund the project we were discussing. He was ready to spend hundreds of thousands of dollars without the faintest idea of why. How can you know the optimal solution if you don’t even know why you are doing the work? The customer had carefully implemented their competitive procurement process, dutifully documented their requirements and engaged vendors, all without giving a thought to what outcome they were trying to achieve.

Our business is divided into a number of capabilities, one of which is design. The first responsibility of the design capability is to help customers understand their problem and discover the best solution. These are highly skilled specialists, focused on solution discovery via careful application of the scientific method. They exist because instinct is not enough. You have an instinctive understanding of your customers and your coworkers and you know which solution will work. So do I, and we are both wrong. Leading technology companies understand this. Google doesn’t assume they can guess what solution they need. Microsoft doesn’t do it. Amazon certainly doesn’t do it. They have acquired humility through hard lessons. Instead of guessing they do the work to discover, test, prototype, research and validate their ideas. It is the less advanced organisations that believe they can take a blank page and guess the solution that is going to work.

As a purchaser of technology services, don’t pay someone to implement a solution, pay them to help you to achieve an outcome. The best way to achieve that outcome is something you will discover together as the project progresses.

Myth 2: A project that is on-time and on-budget is a successful project

Fixed-price, fixed-scope doesn’t say anything about outcomes. The focus is 100% on costs and 0% on value. The process is designed to reduce the risk of being over budget and over time, and ignores the greater risk of failing to solve the problem. Also, not very effective at being on time and on budget. Focusing on cost, schedule and scope establishes a competitive environment that makes it hard to deliver a valuable outcome. The customer is incentivized to get as much as they can for as little as possible. The vendor is incentived to charge as much as possible for as little as possible. This creates an environment of conflict and an emphasis on following the plan over delivering something that is actually valuable.

So, how do we all succeed together?

Fixed-price, Fixed-effort

I propose a different fixed-price approach called fixed-price, fixed-effort.