Getting started
Implementing an effective change management process requires agreement on the appropriate level of change
control. Not all projects require the same level of control.
For small, co-located teams, a relatively light-weight process such as the one described here is sufficient.
For larger teams, or teams working on safety- or business-critical applications where the cost of failure is very high,
there is a need for more formal change control.
This practice describes the simplest possible change management approach, one in which change management is an integral
part of project management. In this approach, any one may request a change to the system (or supporting
artifacts) at any time, either to correct an identified defect or to add an enhancement. The request for change is
captured on the backlog of outstanding [Project Work]. During project planning, the team reviews the backlog,
prioritizes work, and decides which changes will be implemented next.
Begin by reviewing the Request Change task and associated guidance. Next, review the Iterative Development practice to understand how requests for change are captured
and managed on the Work Items List.
If more formal change control is required, you may define a new practice, or re-use existing commercially available
practices. To define your own practice, begin by defining which roles will review, assign, implement, verify, and
close change requests. An explicit change request artifact, which includes a definition of the various lifecycle
states of a change request, may be of value for status reporting. Finally, define the tasks and associated roles
that transition the change request between the lifecycle states defined previously.
Common pitfalls
Too much process. Too much overhead in reviewing, approving, and verifying a change request may slow down the team.
Simple changes should be possible with minimum overhead.
Too little process. If not properly managed, changes can lead to scope creep, cost growth, schedule
slippage, dashed expectations, and project cancelation.
Poorly integrated configuration management. In order to understand the impact of changes and to plan for
verification, change requests must identify which versions of which artifacts were affected by the change. A
common problem with stand-alone change management practices and tools is a lack of traceability to the affected configuration
items.
Unfortunately, as mentioned previously, there is no "one-size-fits-all" solution for change management. One possible
compromise is to classify change requests in two categories:
- Change requests that have high risk or cost
associated with them, or those that impact stakeholder expectations, undergo a more formal change process (including
stakeholder review and approval).
- Change requests that are relatively low risk, or those that do not impact stakeholder
requirements, can undergo a more light-weight change process.
This approach is common on large projects, and the
two categories are commonly referred to as Class 1 change requests (which require a more formal change process
involving stakeholders) and Class 2 change requests (which are under the control of the development team).
Finally, the appropriate choice of tools will greatly reduce the overhead associated with change management and
traceability.
|