My last article ("Fixed Price IT Project – The avaricious pays twice? – Part I: Preparation) talked about challenges of a business pain transformation into the proposal to build an IT system. This time I’ll describe the second, more dramatic stage of the ultimate transformation – project implementation. A lucky vendor is awarded a contract and a project team is ready to start.
4. Execution phase.
The Project team has a formal leader – a Project Manager. He or she, was orchestrating a RFP response preparation and was a major player in the sales efforts to win the deal before. But now PM is The Person in charge. What is a key metric for the Project Manager’s performance? Customer satisfaction, quality of deliverables, meeting deadline and milestones…it’s all true, but. Good project managers have enough paperwork to cover their backs when the problem arises with any of the above mentioned metrics and are rarely punished for that. What is really intolerable is running out of budget on a fixed price contract. Not many PMs have survived this and it leads to an idea that the cost and only the cost is the primary metric that drives project manager’s decisions. How does this affect the project?
Project managers are well familiar with the iron triangle – scope-schedule-cost. It limits PM’s flexibility to maneuver. There is a wide spread perception that a fixed price project does have all 3 parameters fixed. Not true – any attempt to fix them all will only have a negative impact on the project quality. When the cost is locked, then scope and schedule are the two weapons PM can use to stay within planned project performance parameters. The Delivery date is pretty much set in the proposal and scope is the last remaining option. You may say that scope is set as well in a contract. True, but remember, there are project assumptions, out-of-scope and acceptance criteria. All these elements will come into play now.
The Project team gains better understanding of real customer expectations almost daily and have to address a mismatch between project proposal and real or changing needs to avoid project termination. The Project Manager is forced to start Change Requests game on day one. Now we have a Project Manager pushing scope changes, the project team is constantly reevaluating and re-estimating work to be done, PM’s counterpart on the customer side is soliciting extra funds from the budgeting committee etc. And who is working on the project and when? …
Common assumption is that project re-scoping magically happens afterhours and does not affect the current production cycle. And that this is free for the customer. Both statements are true only partially. Initial project work estimates were based on an 8 hour work day, but execution relies on a professional day contribution from the team members. Professional day is something longer than 8 hours but shorter than 24. Reasonable managers limit it to 9-10 hours, but there are project situations when 12-16 hours may be necessary. Free estimates mean someone is paying for that and that someone is a project team member. Senior team members have to invest substantial amount of extra hours to support Change Requests preparation.
Is this a part of the burden of being a Senior team member? Yes, but Senior members bring unique expertise how to do stuff right and are capable of finding a solution that works best for the customer (business process, architecture changes etc.). We need them to do this type of work and be committed to customer satisfaction. Change Request preparation turns them into multitasking that is not very productive and even “forces” them to work against the customer! Team has to apply “progressive thinking” to use proposed loopholes (assumptions, out-of-scope statements) to justify extra funding. This helps sales folks, improves project financial metrics, but doesn’t do any good for the customer.
Overutilization has one more negative impact with delayed consequences. Long hours ruin work/life balance for involved team members and works as a time bomb. Workaholics have miserable personal life, if any at all. Personal issues are popping up, people frequently get sick and the work is rescheduled to remaining team members. This only worsens morale and leads to conflicts and factions. High turnover rate is almost inevitable in such conditions and it triggers a demand for tacit knowledge transfer which is always incomplete.
This affects the fourth (hidden) metric of magic triangle – Quality. Acceptable project quality is a tricky measure and is hard to test. Undetected bugs exist in every system and system design is never perfect. But people do a much better job when they are happy and team morale is high. Cost pressure forces people to make quick, spontaneous decisions that are far from being optimal. This leads to system performance issues and much higher cost of each new Change Request.
Project troubles will trigger unpleasant, but frequent finger pointing blames from both sides that now have to be addressed by a steering committee. This will initiate even more unproductive timewasting debates while project quality continues to degrade.
Do you still think using the Fixed Price model was a good idea for IT industry?
Fixed Price model is widely used outside IT projects and had proved its effectiveness dealing with preassembled building blocks and well defined integration procedures like in construction. IT systems have been and still remain an art work rather than an output of an assembly line. Such development projects should be nurtured to keep an inspiration and creativity going, but not be cornered by cost-scope-schedule locks.
All of the above leads us to a very unpleasant conclusion that fixed price projects designed to be more expensive than planned, project teams on both sides get exhausted and demoralized, and final deliverables have questionable quality. Who will suffer the most from these consequences? Believe it or not, but it will be system end users – business customers, who ordered the system.
I have no rational explanation why someone wants to spend more money to hurt himself following an illusion of a predictable and “low” IT project cost. (originally posted on CIO.com)