What's the best way to deal with changes to requirements as a project progresses?
In some companies, if I asked 10 people in different parts of an organization how they handled change, I'd probably hear at least 11 different answers. But, in areas which are good at managing change, there are some practices which they have in common, even if they manifest themselves in different ways.
Good change management implies the ability to:
- Define the proposed change clearly and unambiguously.
- Determine the costs and benefits of the change.
- Assess the business and technical impact of the change.
- Decide whether or not the change should be made.
- Decide when the change can be made.
- Track the change with respect to some kind of baseline of the requirements.
How you execute on these abilities depends on what development approach you are using and whether or not you have regulatory constraints which require formal change management. For example, if you are in an organization which uses an agile approach, the product owner will use the cost/benefit and change impact analysis to determine what changes should be made. The product owner also will manage change by ensuring that proposed changes are applied to future iterations (or sprints if Scrum is used) rather than to the current iteration or sprint. If your agile approach is small-scale and informal, it may be up to the product owner to decide how to track the changes. If you are scaling agile practices for larger or more complex efforts, you may choose to use automated tools to route proposed changes to decision-makers, record the decisions made about the changes, and to track when they are implemented. If you work in a highly regulated environment, you may have a formal change management process where everything about the change is thoroughly documented.
One key to a "best way" is to pick the lightest change management and tracking process that still meets your needs. The other key to a "best way" is to expect change and deal with it. With very few exceptions, practices which freeze requirements for months at a time are too rigid for today's volatile business climate. Not being able to quickly implement a change– perhaps in response to what a competitor is doing – may have severely negative business consequences.
Dig Deeper on Software Requirements Gathering Techniques
Related Q&A from Sue Burk
Does sequence matter when you are not using use cases or process modeling techniques? Expert Sue Burk explains the importance of sequence by using a ...
Do new technologies affect the requirements gathering process? In this response, expert Sue Burk delves into this question, explaining the tenets of ...
Expert Sue Burk explains the importance of gaining proper approval for requirements changes and offers suggestions for the most efficient ways to ...
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.