| <?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><h3>
 |
| Getting started&nbsp;
 |
| </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. 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.
 |
| </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 Iterative Development
 |
| 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 cancellation.
 |
| </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> |
