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. Change requests can result from any and all
project activities, including managing requirements, development, testing, customer service, customer review, and
discussions in the team, and can apply to the tools and process used by the team as well as work products produced by
the team. 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 cancellation.
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.
|