<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-TuCzhSCW4ZtU_Z5h-cGwFQ" name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-TuCzhSCW4ZtU_Z5h-cGwFQ" changeDate="2010-09-15T12:40:22.858-0700" version="7.2.0">
  <mainDescription>&lt;h3>&#xD;
    Getting started&amp;nbsp;&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Implementing an effective change management process requires agreement on the appropriate level of change control. Not&#xD;
    all projects require the same level of control.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For small, co-located teams, a relatively light-weight process such as the one described here is sufficient.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For larger teams, or teams working on safety- or business-critical applications where the cost of failure is very high,&#xD;
    there is a need for more formal change control.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This practice describes the simplest possible change management approach, one in which change management is an integral&#xD;
    part of project management. In this approach, any one may request a change to the system (or supporting artifacts) at&#xD;
    any time, either to correct an identified defect or to add an enhancement. Change requests can result from any and all&#xD;
    project activities, including managing requirements, development, testing, customer service, customer review, and&#xD;
    discussions in the team, and can apply to the tools and process used by the team as well as work products produced by&#xD;
    the team. The request for change is captured on the backlog of outstanding [Project Work]. During project planning, the&#xD;
    team reviews the backlog, prioritizes work, and decides which changes will be implemented next.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Begin by reviewing the &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../practice.mgmt.team_change_mgmt.base/tasks/request_change_A048C387.html&quot;&#xD;
    guid=&quot;_0mwzEclgEdmt3adZL5Dmdw&quot;>Request Change&lt;/a> task and associated guidance. Next, review the Iterative Development&#xD;
    practice to understand how requests for change are captured and managed on the &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.mgmt.common.extend_supp/workproducts/work_items_list_39D03CC8.html&quot;&#xD;
    guid=&quot;_rGNWsCbSEdqh1LYUOGRh2A&quot;>Work Items List&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If more formal change control is required, you may define a new practice, or re-use existing commercially available&#xD;
    practices. To define your own practice, begin by defining which roles will review, assign, implement, verify, and close&#xD;
    change requests. An explicit change request artifact, which includes a definition of the various lifecycle states of a&#xD;
    change request, may be of value for status reporting. Finally, define the tasks and associated roles that transition&#xD;
    the change request between the lifecycle states defined previously.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Common pitfalls&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    &lt;b>Too much process.&lt;/b> Too much overhead in reviewing, approving, and verifying a change request may slow down the&#xD;
    team. Simple changes should be possible with minimum overhead.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;b>Too little process.&lt;/b> If not properly managed, changes can lead to scope creep, cost growth, schedule slippage,&#xD;
    dashed expectations, and project cancellation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;b>Poorly integrated configuration management.&lt;/b> In order to understand the impact of changes and to plan for&#xD;
    verification, change requests must identify which versions of which artifacts were affected by the change. A common&#xD;
    problem with stand-alone change management practices and tools is a lack of traceability to the affected configuration&#xD;
    items.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Unfortunately, as mentioned previously, there is no &quot;one-size-fits-all&quot; solution for change management. One possible&#xD;
    compromise is to classify change requests in two categories:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Change requests that have high risk or cost associated with them, or those that impact stakeholder expectations,&#xD;
        undergo a more formal change process (including stakeholder review and approval).&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change requests that are relatively low risk, or those that do not impact stakeholder requirements, can undergo a&#xD;
        more light-weight change process.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    This approach is common on large projects, and the two categories are commonly referred to as Class 1 change requests&#xD;
    (which require a more formal change process involving stakeholders) and Class 2 change requests (which are under the&#xD;
    control of the development team).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Finally, the appropriate choice of tools will greatly reduce the overhead associated with change management and&#xD;
    traceability.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
