There is a point in Section 2 of the 25 Point Plan to Reform IT that reads, " Preventing scope creep by defining high-level requirements upfront, locking down the current release, and pushing additional non-critical functionality to future release".
This idea or concept will be found in every book about Project Management and systems development published from about 1996 on. Everyone believes it and feels that it is true and a worthwhile endeavor. I wrote about this some time ago in my A Time for Change piece, but I'm going to try to be even more practical here. The first thing to know is that change is inevitable. If you think you have a project that is immune to scope creep then stop now and find another job.
It is a chicken and egg problem. Which comes first? But in this case, the stakeholders can't respond to a set of functionality until they have an opportunity to play with that functionality. See it is only through the process of testing that people are able to ferment their ideas about what does and does not work. They will give it a try in the requirements and design process but those exercises are purely theoretical and not practical. This is why the previous bullet in the 25 Point Plan is so meaningful, "Regularly capturing and incorporating user feedback through an iterative process that assesses user satisfaction with each release, continuously refining design to ensure alignment with business need".
The important thing that I do in my development projects, projects in which we are going from zero to finish in a year, is that we must be testing Iteration 1 no later than 90 days after the kickoff. This seems crazy to many people because most times we are less than 20 percent complete with requirements by then. My response to these people is that they are correct, they are less than 20% of the way to getting the customer to sign in blood that they correctly understand the requirements. But remember, these exercises are all on the theoretical side of the project, not the practical side. So people will tell you what think the best way to proceed is, but they will only have about 10% certainty with what they are telling you because the entire system is so fuzzy.
This is what McConnell calls the Cone of Uncertainty. As you begin a project, how long it will take, how much it will cost, what it will actually do is very unsettled. As you progress through the project each of these estimates begins to crystallize and become more accurate. Finally in the last phase of the project there is certainty about how long it will take, how much it will cost and what it will do. My point here is that we must accept that the cone of uncertainty exists and work to chunk and time-box the project to mitigate the risk to these constraints.
So by saying that we will be playing with functionality within 90 days of the kickoff I am saying that we will be moving from the theoretical side to the practical side in less than 90 days (Schedule). I am saying that the ideas about what this thing will do will move from theoretical to practical (testing) in 90 days (Scope). Finally, by establishing the contract or task order to be Firm Fixed Price (see my discussion on the variety of contract types) we have mitigated the cost risk.
The trick here is how we make this work on a real project. This has been very successful for me. It is a balancing act. You have to implement change so that, in the end, the stakeholders receive the product they need. But if you swing the pendulum too far in that direction then the vendor will complain that they are expending too much energy implementing the changes and that is affecting their cost. They will make the case that they are performing re-work because the government doesn't know what we want. We will say that we can't know what we want until we are testing the functionality. This is the classic chicken and egg scenario.
The way out of this dilemma is to work with the vendor to identify the pool of free development hours. I have actually heard of some metrics about how we decide the right amount of free development. Some people use 10 or 20 percent of the overall development effort. Thus if we are buying what is estimated to be 10,000 hours of development on a project, we would have 1,000 (10%) or 2,000 (20%) hours that would be available for Free Development. You take those free development hours and put them in a pool. Then you start capturing the changes that people want to make against the requirements baseline.
It is important to highlight the distinction between a change (scope) and a defect (quality). Changes are not bugs. The vendor is required to perform to the standards that will be indicated in the Quality Management Plan. The time to implement changes that are required to address a defect or bug do not count against the pool of free development. Changes in which the functionality is working correctly but the government doesn't want it to work like that are indeed changes to the requirements baseline. The cost of implementing those changes counts against the pool of free development.
This simple technique does a few really important things. First, it characterizes the maximum amount of effort the vendor will be required to bring to the project and that should yield lower prices in the proposals. Without this idea of free development vendors have to price in their worst case scenarios and that will inflate the cost. Second, it forces the stakeholders to make value-based decisions about which changes are most important. When you are sitting at 1,000 or 2,000 hours, those first changes are relatively easy and painless to approve. When you get to 100 hours remaining, trust me, that is where the rubber hits the road and the business will have that real conversation about what is most important. So it forces the stakeholders to be more deliberate about the changes they approve. Finally, it establishes a commodity formula for changes. I have seen this several times. We spend that last 100 hours on really important changes, but you know, we have a few more that we think are also really important, we want to buy another 100 hours of change. That is fair to both the business and the vendor. The vendor is justly compensated for the extra effort that is required for the project and the business recognizes the cost of implementing the changes. Once the project is done, any changes not yet implemented or pushed to later releases automatically populate the change list when the project pivots from development to operations and maintenance releases.
This process has work over and over for me. It is fair to both the business and the vendor.
