Managing Requirement Changes

Author: Geri Schneider Winters

Almost every project will have to deal with requirements that change. I can imagine some maintenance type projects that are so well defined (fix this list of bugs) that there are no requirements changes for the lifetime of the project. Or perhaps the project is so short (a couple of hours) that there are no requirements changes. But all other projects will have some amount of requirements change.

You could argue that XP projects do not have to deal with this. In XP, a developer works directly with a customer to implement a small amount of functionality. So that small amount of functionality will probably be completed without change. But as soon as the customer sees the results of that functionality, they will want something more or something different.

This is one approach to dealing with changing requirements. Define a small amount of functionality, write the code for that, and demonstrate it to your customer. Get their feedback. Now define another small amount of functionality. This could be any combination of new features and changes to existing features. Write the code for that small amount of functionality and demonstrate it to your customer.

Sound familiar? It should. This is a brief description of a basic iterative development process. XP is an iterative development process, as are RUP and EUP. All iterative or spiral processes were defined for the purpose of dealing with the problem of requirements that change throughout the project.

The key to this is to *not* define all the requirements at once, but to only define enough of the requirements to be able to write some code so you can demonstrate it to the customer.

“But”, you say, “even though my company does iterative development, I am required to write all of the requirements at the beginning of the project and to get them signed off by the stakeholders before any development work is complete.”

Basically, you are describing a process that is waterfall at the beginning, followed by a series of development releases. This is really a modified waterfall. I think what drives so many companies to this process is that upper management wants an estimate of project cost up front, and to estimate the cost of the entire project basically requires you to describe all of the requirements of the project at the beginning.

(Side note: Another way to estimate project cost is to compare what you know about this project to similar projects in the company’s past, and use the final amount of the cost of the previous project as the estimate for the current project. Of course, this requires that the company keep information about previous projects in such a way that it can be found later.)

In this situation, your project must either adjust to each change as it comes along, or define a process to allow you to bundle a set of changes and deal with those changes at well-defined points in time in your project.

This latter way of doing things is preferred, since it minimizes the impact of change on your project team. An easy way to do this is to wait until the development team reaches the end of one of their cycles of development, and introduce the changes when the next set of functionality is being designed. This is less of a disruption on the development team than giving them changes whenever they are discovered.

Another issue arises when considering the impact of change on the project timeline and budget. If you are required to accept every requested change, your project will go over time and over budget. If you cannot exceed your resources, then you will have to add to the change process a mechanism for deciding how much the change will cost, and what the project will give up in exchange. You have to pay for changes somewhere in the project. Either you get more time and money to develop the product, or you pay for changes by not developing something that was originally planned.

This is just basic budgeting as we all practice it at home. If I have $5.00, I can buy a Venti Chai Soy Latte at Starbucks, or a Big Mac meal at McDonalds. But I do not get to buy both. I have to pick one or the other to spend my money on. The same is true on a project. If you have $10,000 to spend, then to add feature A which costs $10,000 you have to remove another feature from the project which costs $10,000. This is very easy to understand, but so many people want to believe that adding new features to the software is somehow free.

I have had fairly good success at positioning requirements changes in terms of cost (time and/or money). So instead of saying, “If you want A you have to give up B” or “We can’t do that within our time and budget”, I tell the customer “You have so much money to spend on the project and it is all allocated to development costs already. This feature you want will cost $10,000 to develop. Where do you want that money to come from? Can we add $10,000 to the budget, do you want to give up something else worth $10,000, or is this new feature not important enough to spend $10,000 on?”

Estimating the cost of the changes and presenting that estimate is part of my process for changing requirements. I do not tell the customer “No”, I tell the customer the cost and the consequences and let the customer decide what to do.

What is the approach to handling requirements changes at your company? There always is an approach, even if that approach is to try to ignore the change requests and hope they go away.