Roadmap: How to Adopt the Team Change Management Practice |  |
This roadmap describes how to adopt the Team Change Management practice.
Main Description
### 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.
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. EPF Copyright.