Managing change overview
Change is inevitable, and you can expect that your requirements will change throughout the course of your project. Requirement change is due to a variety of external and internal factors.
External factors are those over which the project team has no control. They include the following:
- a change to the problem that you are trying to address, related to changes in governmental regulations, the economy, technology, and consumer preferences;
- a change of perception among clients regarding what the new system should do,
- a change in the external environment, which creates new constraints or opportunities (e.g., changes in technology); and
- new requirements generated by the installation of the new system.
Internal factors are those over which the team has control. They include the following:
- failing to ask the right people the right questions at the right time during the initial requirement-gathering phase of the project (which may happen if the team has not completely identified all stakeholders), and
- failing to create a process to help manage requirement changes on an incremental basis (e.g., by prematurely freezing requirements).
Because change is inevitable, the project team must have a process for managing change. By having a process in place, the team regains control of the project and is in a better position to discover change, assess the impact, and incorporate changes that are considered necessary into the system. An effective change management process should include the following steps:
- Recognize that change is inevitable and plan for it. Changes requested by stakeholders are legitimate and should be taken seriously because the stakeholder has both a real need and the potential to add real value to the system. Similarly, requests from development team members should be factored into the process, because they know more about the system than anyone else.
- Create a baseline of the requirements. You can create a baseline of your requirements when you think you have identified all of them. That constitutes the frame of reference against which new requirements can be compared. When new requirements are requested, you can compare them to the existing baseline to see where they fit in and whether they conflict with existing requirements.
- Establish a single channel to control change. A proposed feature may have a profound impact on existing features, features anticipated for future releases, schedules, and budget. Therefore, every change should go through a single channel (in small projects, a project manager; in large projects, a Change Control Board consisting of a few people), which will determine the impact of the change on the system and whether the proposed change should be approved.
- Manage change hierarchically. Changes to requirements should be carried out in a top-down hierarchical fashion. Any requirement you want to introduce can be added to the Vision document, and a new baseline can be generated. By establishing traceability relationships among the requirements, you can where a change in a requirement introduces a suspect link that must be checked, and you can see the ripple effect of this change throughout the project.
(Adapted from Managing Software Requirements: A Unified Approach, by Dean Leffingwell and Don Widrig. Boston: Addison-Wesley, 2000, pp. 367-379.)
Return to main tutorial