Tag Archives: Fixedpricecontracts

Not the Fixed Price Contract

Posted on by

The fixed price contract has been discussed here at the Crisp blog by others. It is broken by design as it creates more problem than it fixes.

On the way from JAOO I talked to Udi Dahan and that made it fall into place in a different fashion. Not that this is what he said, this is what he sparked.

The fixed price contract is not necessarily fixed price, a contract or evil.

First of all, it is an excuse to get a budget. Let’s face it, your client on the other side of the desk, the man with the tie, has a boss. He wants to look good in front of his boss. So he needs a sum of money written down next to a promise of something. The sum must be big enough to justify him talking to the boss. The promise must sound like it has value and of course it does, you wrote a proposal full of great ideas.

Once the contract is approved, the fixed price changes as there are always change requests and they cost money. So the price is not really fixed.

But you know that is going to happen, so the proposal is gold plated with features that are not really necessary. When the client comes with a change, you suggest they trade it for something of that gold plated stuff. Of course they do. So you seem very agile as you take on a change request for practically nothing.

Best of all, if you trade something with higher risk for something with lower risk, you are better off than before.

In the end you deliver the product on time, different from what was in the contract and perhaps for a slightly higher price (not all changes can be traded for something else).

The project is a success and nobody cares about what was in the original contract.

You will get a request for a second version and this time you know the customer even better so the gold plating can be even more cunning *cough* clever.

Evil? Depends on how you see it. As long as the customer is happy and gets a return on their investment, all is well. After all, the value of something is what someone is willing to pay for it.

So the price changes and the scope changes. Why call it a fixed price contract?

Now, Udi may think I am madly misinterpreting him. So, I guess he is only responsible for the subject and not the content.

Fixed priced contracts – flawed by design

Posted on by

Why do we have fixed price contracts?
“We need to know what we get” – would be the most obvious answer.

“We want to pick the manufacturer with the best price. They won’t quote us without a fixed set of requirements”  – also a likely answer.

Do you always take the same amount of steps on a jogging round?
Do you always pick the shoes with lowest price?
Not likely.

Even so we persistently request and call out for fixed priced contracts.

“But we have to have some estimate of where it is going to end”. Well. Now we are getting somewhere.

Planning is everything, plan is nothing
When outlining a fixed priced contract, we look into our needs in detail. We look at what is important and think about non functional demands, such as reliability, load, security and maintainability. At the same time we also set out a target goal for the business case, so we make sure we make money on it. This is all good.

Trap #1: Does a need discovered written down ever get removed?
Trap #2: Do we prioritize our demands against each other?
Trap #3: Is that prioritization made on business grounds?

There can be all sorts of explanations why a requirement exits. IT department might want to play with a new technology. A security manager is sure that security comes first. Et cetera.

Point is: the requirement review is a constant action if we want to reflect reality. Not a one time deal during a six month period.

Litmus test: Have you ever removed a requirement once written down?

Myth: Fixed priced contracts gives the lowest cost

  1. A skilled supplier typically would include a risk premium (cost of risk) in a fixed contract. Think of it in the same way as the risk premium you get in fixed rate interest
  2. If suppliers overbid, you suddenly risk needing to save them from financial trouble. And this half way through your project with no way out
  3. A supplier only focusing on cost is least likely to have the skilled staff you would like leverage from. More likely they are junior and learning at your expense

Overall, a fixed priced contract will not give you the lowest cost because the biggest part of risk is put on the supplier.

So what is it we want to achieve, really?

  1. We want to maximize our business options at any given time
  2. We want to keep a low risk level (work in progress) at any given time. Why? Because invested unfinished work we risk loose in favor of adopting to outside changes.

How do we deal with it?
Here is the key: you need to put together a cross functional team that can take ideas to runnable software at the end of every sprint.

  1. Without this we short circuit the customer feedback loop preventing him to learn what he really needs
  2. If we cannot deliver runnable software, we cannot build trust needed to outweight  the importance of the contract

If your customer at any point of time prefers thew existing software in favor for the written contract, you know you are on the right track.