What's the right level of change control for requirements?
I've been part of projects where the controls were so tight we could hardly breathe, and on a few where we flew by the seat of our pants. What's the right level of change control for requirements?
Requirements are like chameleons—they change colors to match their environment. Taking time to establish version control on the requirements documents will take you a long way toward effective change management.
Striking a balance between insufficiently tracking changes and tracking them to death is tougher than it looks. What kinds of changes should you manage? What level of rigor should you aim for? Unfortunately there are no easy answers, but there are some useful criteria that will help you decide the right level of change control for each project:
What kind of change is it? Very minor changes (document typos, formatting glitches, word changes, etc.) that don't impact the meaning of the requirement should be managed within the requirements discipline and assigned minor version numbers. But major changes that add, remove, or fundamentally alter any of the documented requirements should be managed within the project team and noted with major version numbers. For example, you might want to assign requirements versions to a numbering scheme X.Y, where X indicates a major change and Y indicates minor changes. Thus, version 2.2 has only minor typographical or formatting differences from version 2.1, but 2.2 includes major changes to the meaning or scope of the requirements compared to version 1.2.
Who needs to know? If the requirements haven't been approved and handed off to the development team, the only people who'll need to be aware of any changes are those who've reviewed the requirements. This usually happens in the early stages of the project. But if the change impacts people outside the requirements team, it should be escalated to the project team for review. This usually happens after the requirements have been handed off to the development team.
How big is the impact? Part of your change control process should be identifying the impact of the change and discussing it before it's approved. Will the change help the project team meet the defined objectives? Will it impact the duration or cost of the project? Will it leave any vision-level requirements unmet? The change control process must be rigorous enough to include research into the impact of changes before those changes are incorporated for review and approval.
How much time do we have? It's easier to incorporate big requirements changes early in the project than after a solution has already been developed. As the project progresses, there might be a point (e.g., after testing and just before implementation, to cite an extreme example) where the project leadership decides it will make more sense to add the change to a different project or to an enhancement list than to try to cram it in at the tail end of the current project. Similarly, if a flood of changes comes too close together, the project leadership may feel it's time to stop and find out why before moving on.
For more insights into change management processes and how to establish the right level of control, see our Requirements Change Management Guideline, provided by a software executive with decades of experience and a passion for getting this right.