Establishing a project's requirements is almost never a one-time event (though projects would be simpler if it were). At some point, even well planned projects will have to respond to changing business needs, technology, solution options, and more. Requirements changes made without thorough consideration can wreck havoc by causing unanticipated changes in other requirements and in the solution design.
To avoid the chaos that can result from unexpected changes, it's important to establish, before change happens, how potential changes will be assessed, prioritized, and implemented.
Establishing a solid change control process
as part of your requirements management plan
is a good first step. In your change control process, make it crystal clear who will be responsible for each portion of the change review. Then, when the team receives a change for review, follow that process and consider the factors below before making a decision.
Identify the source of the change.
Complete a thorough impact analysis
- Is it driven by an external force, e.g., a compliance requirement or a regulatory issue? Is it driven by some other external force over which the project leaders have no control, or an external factor on which the whole project is dependent? With externally influenced changes, there may not be a choice of whether to implement the change, but only of when or how to do so.
- Has additional information been uncovered? Is there now a deeper understanding of a process or internal factor? If so, perhaps you've identified some missed requirements, which now need to be incorporated as changes.
- Has something within the business changed? Has it affected a process or function that the solution addresses? If so, you'll want to quickly identify the change and how it affects the rest of the project.
while evaluating proposed changes. Pay particular attention to project risks caused by incorporating the change (delays, rework, etc.), as well as the risks of not
incorporating the change (risk to the organization of noncompliance, risk of missing a business objective, etc.).
- How will incorporating the change affect the rest of the project? A traceability matrix will help you fully understand the impacts. Make sure you understand the priorities and categories of each requirement that will be impacted by the change.
- How will the change impact the project's acceptance criteria? The project team has likely laid out a minimum set of criteria for successful project completion. Look closely at these criteria, to see how the change will affect them, and whether revising them would be risky or wise.
- How will the change impact the business value of the project? Once you've gathered all possible information about the change, apply your decision analysis tools to weigh its impact on the project's business value. Remember to incorporate input from each project discipline and business area that will be affected by the change.
Considering all of these aspects does not mean you have to institute a lengthy, bureaucratic process for every possible requirements change (though complex changes or changes to a core requirement may merit more than a 10-minute phone chat). Incorporating smaller changes may take no more than a few minutes of careful consideration and a few emails, as long as you are following the established change control process and not working outside the law, as it were. But by taking the extra time to consider these factors—whether it takes a quick review or a detailed investigation—you vastly increase the odds that you fully understand the impact of a change, and vastly decrease the chances of finding out later that a seemingly small or harmless change inadvertently added expensive rework or violated the customer's expectations.