Changing Requirements, but Fixed Price.

In their article series titled “Familiar Metric Management”, software measurement gurus Lawrence J. Putnam and Ware Myers write about big software work, and “What characterizes these big jobs, besides being big?

 #1. Big projects start with a big vision, but few nuts and bolts that you can put a cost on. The “nuts and bolts” i.e., “requirements” are not very well defined to begin with. The “requirements” are incomplete and even wrong in many respects. This requirements problem is not something that can be corrected by clean living and right thinking. It is inherent in complex projects. The customers/users/stakeholders don’t know what ought to be done beyond the knowledge that Spring will come”.

 #2. Big projects entail “risks,” usually lots of them. Depending on what you count as a risk, there may be dozens of them, or even hundreds of them. “We have found that risks (or at least the acknowledgment of them) diminishes the closer you get to the US Congress,” observed Marvin J. Carr of the Software Engineering Institute [“Risk Management May Not Be for Everyone,” IEEE Software, May-June, 1997]. “In general, placeholders in a bureaucracy are uncomfortable with risk. Solution: the vision proponents from the lower reaches pretend there are no risks or, if a few turn up, “our splendid team will vanquish them on schedule.”

 #3. In the intermediate reaches of the executive structure are “bottom-line” people who want a bid down to the nearest penny and the exact day of delivery. “We don’t know in full what we are going to do, but we do know enough to see risks in it. Nevertheless, we promise to deliver it on July 31 two years from now for $29, 642,788.”

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For those experienced in outsourced software services and fixed price development projects, the Putnam-Myers note is likely to be a familiar thing.

Looking at the “nuts and bolts” i.e., “requirements”, somehow measuring acceptable input quality has been elusive. What constitutes acceptable quality of “customer requirements”? Professionals in software development projects expect customer requirements and specifications to be timely, adequate, consistent, concise, unambiguous, feasible, testable and traceable.

Adoption of ‘Agile’ doesn't mean that problems arising from requirements churn, requirements scrapping, requirements creep, requirements volatility etc. will disappear. Requirements engineering, in Agile based delivery too, is human intensive. Hence, requirements often tend to be incomplete, in conflict, incorrect and changing. One needs to be on high alert so that these are not silently brushed under ‘rework’ attributable to the development team.

In outsourced Agile based fixed price development projects, amongst other things, it is essential for a customer and a service provider to design and adopt budgeting and estimation models that clearly define and suitably factor changes to requirements; be it due to churn, scrapping, creep, volatility etc. 

An outsourced, Agile based fixed price project with quality of delivered software as the only enforceable basis for acceptance, will tilt only in favor of the customer. To be balanced and fair to both parties, it is time that quality of delivered software along with quality of customer requirements get enforced.

The principle, “Welcome changing requirements” does not mean at zero extra effort or free of cost.