| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-TuCzhSCW4ZtU_Z5h-cGwFQ" |
| name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-TuCzhSCW4ZtU_Z5h-cGwFQ" changeDate="2008-06-30T07:01:04.328-0700" |
| version="7.2.0"> |
| <mainDescription><h3>
 |
| Getting started 
 |
| </h3>
 |
| <p>
 |
| Implementing an effective change management process requires agreement on the appropriate level of change
 |
| control. Not all projects require the same level of control.
 |
| </p>
 |
| <p>
 |
| For small, co-located teams, a relatively light-weight process such as the one described here is sufficient.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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 <a class="elementLink" href="./../../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project Work]</a>. During project planning, the team reviews the backlog,
 |
| prioritizes work, and decides which changes will be implemented next.
 |
| </p>
 |
| <p>
 |
| Begin by reviewing the <a class="elementLink" href="./../../../practice.mgmt.team_change_mgmt.base/tasks/request_change_A048C387.html" guid="_0mwzEclgEdmt3adZL5Dmdw">Request Change</a> task and associated guidance. Next, review the <a class="elementLink" href="./../../../practice.mgmt.iterative_dev.base/guidances/practices/iterative_development_CD1297B8.html" guid="_LR_g4J9WEdy3Nc4rvuj7bA">Iterative Development</a> practice to understand how requests for change are captured
 |
| and managed on the <a class="elementLink" href="./../../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Work Items List</a>.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h3>
 |
| Common pitfalls
 |
| </h3>
 |
| <p>
 |
| <b>Too much process.</b> Too much overhead in reviewing, approving, and verifying a change request may slow down the team. 
 |
| Simple changes should be possible with minimum overhead.
 |
| </p>
 |
| <p>
 |
| <b>Too little process.</b> If not properly managed, changes can lead to scope creep, cost growth, schedule
 |
| slippage, dashed expectations, and project cancelation.
 |
| </p>
 |
| <p>
 |
| <b>Poorly integrated configuration management.</b> 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.
 |
| </p>
 |
| <p>
 |
| 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: </p>
 |
| <ul>
 |
| <li>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). </li>
 |
| <li>Change requests that are relatively low risk, or those that do not impact stakeholder
 |
| requirements, can undergo a more light-weight change process. </li>
 |
| </ul>
 |
| <p>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).
 |
| </p>
 |
| <p>
 |
| Finally, the appropriate choice of tools will greatly reduce the overhead associated with change management and
 |
| traceability.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
