FPCs work like this: based upon a given set of requirements we can estimate that a project will cost X, and take Y time. The requirements define the scope and quality of an acceptable system, we specify the cost and time necessary to produce it.
During development, for many reasons, the customer changes their requirements. So we move into the change control procedure, of costing the change and submitting it to the customer for approval, changing the scope, cost and time of the system, and sometimes its quality.
The customer see the project like this: we will get a return on investment of approximately Y%, and we are willing to risk X to get it. Or sometimes like this: we can save Y per year, if we invest X, given that X is not greater than 85% of Y then we should proceed.
That is, the customer is willing to invest X for a minimum return. The problem is that at the beginning of a FPC they agree to invest Z, which is less than X, but end up paying 2Z, which is often considerably greater than X.
The customer distrusts us because they know we’re lying when we agree to fix a price, but they don’t have any other way to control the costs. At least this way they can have someone else to point to when it all goes wrong.
Did that make sense? I think it will be "old news" to most of you. You’ve all been doing this for years, and know exactly how it works. Therein lies the problem -- you do know exactly how it works, you have done it before and you have seen it happen a dozen times before.
With that much experience, don’t you think that you could have come up with a solution that would better meet the needs of the customer? We’re meant to be the smart ones, aren’t we?
We know that the customer is going to change their minds, that their business is going to change, and that the political environment is going to change. What do we do about it? We charge the customers for it, make obscene profits and watch them hate us, because they have no choice but to pay till it hurts.
It’s time for a better solution.
In XP we provide a project estimate, in cost and time, for the whole project. We plan release dates, and the stories (points of functionality) that are to be included in each release. However, this is just a quote, to allow the customer to see if the project is more or less affordable.
From there on in we prefer to work on a professional services bases. We provide services, for which the customer chooses to pay, and the result of this relationship is software.
In this model the customer chooses to invest in a couple of iterations' worth of work. Their responsibility is to provide people to the project team with the ability and knowledge to make decisions about the functionality, decisions about what the investment is spent on. We call these people "The Customer", and they are an intimate part of the team.
The customer is responsible for producing the stories, scheduling them and specifying the tests that we must pass to prove that we’ve produced what they asked for. We call these the "Customer Tests", or Acceptance Tests (ATs).
The customer is allowed to introduce new stories whenever they need to. These are estimated, and added to the pool. Knowing the cost means that the customer can make an informed decision about the scheduling of that story. They may decide that it’s too expensive and so won’t schedule it at all, or they may decide that it’s of very high value to them, and so it will be scheduled for the next iteration.
In this way we deal with change. We say that we welcome change, because for us it’s just another story. We support this, through the rest of our practices, without which it would never work. We produce code that is very easy to change, and is of very high quality, and we produce it very rapidly.
At the end of every iteration we run the customer tests, and if they pass the customer can pay us. Passing the tests means that we have produced what they asked for, when they asked for it. The customer can then decide if they wish to continue investing in the project. They may decide to invest further, that more functionality will provide a benefit greater than the money they will invest, or they may not. Either way, we are successful.
At the end of every iteration we will have produced a fully working, integrated system that passes all of its internal tests, and all of its customer tests, which may, at the customer’s whim, be deployed to users.
Now the shocker: our iterations are usually only one week long.
How about that for control? The customer can change the direction of the project on a weekly basis. How about that for risk management? The customer’s exposure is limited to the cost of the development team for a single iteration.
So, go ask your customer what their current exposure is on your project. If it’s bigger than the cost of your team for one week, then you are putting your customer at a significant, and totally unnecessary, risk.
What will your customer be thinking after they read this?