You should expect that requirements will change from the time you start your project implementation to the time you deploy and through the life of the product or service. Accept that there are things that you simply will not know until you get into the details of implementation. And business requirements are in a constant state of flux to stay current with their needs. In fact, the larger a project and the longer the duration, the greater the number of changes you should expect.
Rule 101 of requirements management is that change is not bad. Uncontrolled change is bad. Uncontrolled change means that new requirements are allowed to come into the project with no formal process for analyzing the requirement and accepting or rejecting it.
Develop a change management process that:
- Defines a process for reviewing and approving change requests.
- Ensures that the new requirement aligns with the goals and objectives of the project
- Evaluates how it impacts project cost, schedule and resources
Once a change is approved, consider the following:
- Is the testing team aware of the change? Some changes will require special testing preparation.
- Ensure that resources are available if additional resources are required
- Determine when the change will be implemented. If you are iteratively developing, you will want to determine what release to apply the change to.
For larger projects or programs, you might need to consider chartering a change control board to review and address changes.
Do you have additional thoughts or recommendations on managing change? Want to know more about a specific change management activity? Let us know. We’d love to hear from you.
