20th October 2014
It's the age-old project manager's nightmare; dodgy spec and a fixed-price project. Why doesn't everyone accept that people will do their best and go for the flexibility and realism of Time & Materials (T&M)? These days there seems to be a strong leaning towards fixing the price of software development projects; after all, the budget is fixed so it doesn't make sense not to fix the price as well. The trouble is, as many experienced PMs know, things are rarely that simple.
The issue is one of risk and who takes it. With a fixed price project the risk is deemed to be the supplier's, with T&M it is the customer who takes the risk. This risk is presumed to be the risk of overrun. In other words, if the project is not completed on time the cost of resources to continue working on it will be borne by one party or the other.
In the fixed price scenario, the supplier is in theory happy to accept the risk because it is the supplier who names the price and sets the timeline. If the project comes in early then the supplier makes a super profit because the engagement was profitable even if it was only on time, and the supplier is usually allowed to add a mark-up to the project for accepting the risk in the first place. Everybody is happy unless the project comes in so late that it eats into the supplier's contingency and extra margin, but if that should happen it is the supplier's fault anyway for getting it so wrong in the first place. Or is it?
In reality the supplier rarely sets the price or the timeline. Customers don't just sit back and accept the estimates they are given; they negotiate and they usually negotiate the fixed price risk factor away. Suppliers need the business and recognize that if they don't do it their competitors will, so they take the risk of a fixed price project, scoped out to meet exact deadlines. However, if they fail to meet those deadlines, they do not passively accept the cost of the overrun either! Even if it is entirely their fault, suppliers will do their utmost to stay in business, and running unprofitable projects is not a good way to remain solvent. They will under-deliver on what was promised, scale back on resources allocated to the project, either by using less or cheaper labor, and they will hit back with that dreaded weapon, the Change Request. When the arguments start over the Change Requests then nobody wins.
If we look at what was intended rather than the means of getting and paying for it we might be able to see a way out of the problem. Customers want good, reliable software that addresses a need that they have. However, suppliers cannot give customers what they want; they can only give them what they ask for. Customers, not being experts in the software development business frequently don't know how to ask for what they want. Sometimes they do not even know if it is possible to get it. If you know that there is a gap between what the customer asks for and what they want, and you have enough experience to know that they rarely like what they are given first time, then the solution is to show them what they are going to get, early.
Project managers should try to minimize the size of the gap by making sure that, as far as possible, the customer sees what they are going to get as soon as possible, in small chunks. The sooner the "what you want" vs "what you get" battle is fought, the sooner the "risk" vs "pricing" issue gets resolved and the more likely the project is to succeed.
We call this "Minding the Gap" and we learnt to do this because the reality in large projects is that there is rarely only one gap. The need to "Manage the Gap" is just as great as the need to recognize it in the first place.