I’ve found it very difficult to convince clients on the benefits of variable scope projects. One approach that I have found useful is to use a risk-based approach to determining the project management variables scope (product), schedule, and cost (see the project management triangle). Here the client ranks the three variables by how confident they are about their estimate for that variable (or your estimate for scope).
First you sit down with a client and ask them what the easiest variable to put an estimate on is. In today’s business climate, this is usually the schedule. “Oh, we have a trade show on March 1.” What is the client’s confidence in this estimate? For all intents and purposes it is 100 percent. Whatever software they are demonstrating needs to be done by then. The trade show may be rescheduled, but it is not likely unless there is an earthquake or other disaster, in which case the show would be cancelled anyway.
That leaves scope and cost. Now ask the businessperson what they are more confident in estimating. “We have a budget approved for only $250,000.” And the confidence of that is again close to 100 percent. So, the variable with the least amount of confidence, scope, is allowed to “float” based on concrete decisions on the other two variables. Thus we fix what we are most confident in, and allow the lesser known variable to be appropriately more flexible.
“But we need a certain amount of functionality delivered!” they will exclaim.
Perfect! If the client can prioritize the functionality, tell them you will deliver as many of the most important features as possible considering the schedule and cost. Also remind the client that they cannot fix all three sides of a triangle, only two within reason. What do I mean by within reason? Well, even if I have a several million US dollars, I won’t be able to rewrite the entire space shuttle program by the close of business tomorrow.
Finally, offer to work in short iterations, and at the end of each demonstrate a working system. Not a complete system, but a fully-working part of one. And tell the client that they will be able to make changes at the end of each iteration (every 2-4 weeks) until the delivery date regardless of changes in business conditions. If work is not getting done as fast as the client would like, then they have the option of increasing the project’s budget to allow for more developers, to purchase components, or whatever else to speed up development.