Workflow Detail: Manage
Change Requests
|
The purpose of this workflow detail is to ensure that due consideration is given to the impact of change on the project, and that approved changes are made within a project in a consistent manner. |
|
|
|
Description
Having a standard, documented change control process ensures that changes are made within a project in a consistent manner and the appropriate stakeholders are informed of the state of the product, changes to it and the cost and schedule impact of these changes.
Related Information
This section provides links to additional information related to this workflow detail.
Timing
While this work starts in Inception and continues throughout the lifecycle, it tends to gain importance as the lifecycle progresses. It is often much more formally managed in Transition than it starts out being managed in Inception.
Optionality
This work is not considered optional, although project culture will mean this work will vary from being a small informal consideration to a larger more formal endeavor. Note that some CM environments may enable the CCB function to supported through process automation where rules can be established within a tool. This is particularly valuable where the CCB function must be managed across distributed teams.
How to Staff
The Change (or Configuration) Control Board (CCB) oversees the change process, and consists of representatives playing various roles in RUP. Typically this includes managers, stakeholders (customers, end-users), developers, and testers. In a small project, a single person, such as the project manager or software architect, may be the only representative on the CCB. In the Rational Unified Process, this primary CCB role is the Change Control Manager.
Work Guidelines
See the Related Information section for additional guidance that will help you in performing this work.
Further explanation of these concepts, suggested activities, and states of Change Requests are found in Concepts: Change Request Management.
