Concepts: Change Request Management

Change Request (CR) – A formally submitted artifact that is used to track all stakeholder requests (including new features, enhancement requests, defects, changed requirements, etc.) along with related status information throughout the project lifecycle. All change history will be maintained with the Change Request, including all state changes along with dates and reasons for the change. This information will be available for any repeat reviews and for final closing.

Change (or Configuration) Control Board (CCB) – The board that oversees the change process consisting of representatives from all interested parties, including customers, developers, and users. In a small project, a single team member, such as the project manager or software architect, may play this role. In the Rational Unified Process, this is shown by the Change Control Manager role.

CCB Review Meeting – The function of this meeting is to review Submitted Change Requests. An initial review of the contents of the Change Request is done in the meeting to determine if it is a valid request. If so, then a determination is made if the change is in or out of scope for the current release(s), based on priority, schedule, resources, level-of-effort, risk, severity and any other relevant criteria as determined by the group. This meeting is typically held once per week. If the Change Request volume increases substantially, or as the end of a release cycle approaches, the meeting may be held as frequently as daily. Typical members of the CCB Review Meeting are the Test Manager, Development Manager and a member of the Marketing Department. Additional attendees may be deemed necessary by the members on an "as needed" basis.

Change Request Submit Form – This form is displayed when a Change Request is being Submitted for the first time. Only the fields necessary for the submitter to complete are displayed on the form.

Change Request Combined Form – This form is displayed when you are reviewing a Change Request that has already been submitted. It contains all the fields necessary to describe the Change Request.

The general process associated with Change Requests is described in Activity: Establish Change Control Process. However, the following outline of the Change Request process describes the states and statuses of Change Requests through their overall process, and who needs to be notified during the lifecycle of the Change Request.

Sample Activities for Managing Change Requests

The following example shows sample activities that a project might adopt for managing a Change Request (CR) throughout its lifecycle (click on items in the diagram to view descriptions):

Activity	Description	Responsibility
Submit CR	Any stakeholder on the project can submit a Change Request (CR). The Change Request is logged into the Change Request Tracking System (e.g., Rational ClearQuest) and is placed into the CCB Review Queue, by setting the Change Request State to Submitted.	Submitter
Review CR	The function of this activity is to review *Submitted* Change Requests. An initial review of the contents of the Change Request is done in the CCB Review meeting to determine if it is a valid request. If so, then a determination is made if the change is in or out of scope for the current release(s), based on priority, schedule, resources, level-of-effort, risk, severity and any other relevant criteria as determined by the group.	CCB
Confirm Duplicate or Reject	If a Change Request is suspected of being a *Duplicate* or *Rejected* as an invalid request (e.g., operator error, not reproducible, the way it works, etc.), a delegate of the CCB is assigned to confirm the duplicate or rejected Change Request and to gather more information from the submitter, if necessary.	CCB Delegate
Update CR	If more information is needed (More Info) to evaluate a Change Request, or if a Change Request is rejected at any point in the process (e.g., confirmed as a *Duplicate, Reject*ed, etc.), the submitter is notified and may update the Change Request with new information. The updated Change Request is then re-submitted to the CCB Review Queue for consideration of the new data.	Submitter
Assign & Schedule Work	Once a Change Request is *Opened*, the Project Manager will then assign the work to the appropriate team member – depending on the type of request (e.g., enhancement request, defect, documentation change, test defect, etc.) – and make any needed updates to the project schedule.	Project Manager
Make Changes	The assigned team member performs the set of activities defined within the appropriate section of the process (e.g., requirements, analysis & design, implementation, produce user-support materials, design test, etc.) to make the changes requested. These activities will include all normal review and unit test activities as described within the normal development process. The Change Request will then be marked as Resolved.	Assigned Team Member
Verify Changes in Test Build	After the changes are *Resolved* by the assigned team member (analyst, developer, tester, tech writer, etc.), the changes are placed into a test queue to be assigned to a tester and *Verified* in a test build of the product.	Tester
Verify Changes in Release Build	Once the resolved changes have been *Verified* in a test build of the product, the Change Request is placed into a release queue to be verified against a release build of the product, produce release notes, etc. and *Close* the Change Request.	CCB Delegate (System Integrator)

Sample States and Transitions for a Change Request

The following example diagram shows sample states and who should be notified throughout the lifecycle of a Change Request (CR) [Click on items in the diagram to view descriptions]:

State	Definition	Access Control
Submitted	This state occurs as the result of 1) a new Change Request submission, 2) update of an existing Change Request or 3) consideration of a *Postponed* Change Request for a new release cycle. Change Request is placed in the CCB Review queue. No owner assignment takes place as a result of this action.	All Users
Postponed	Change Request is determined to be valid, but "out of scope" for the current release(s). Change Requests in the *Postponed* state will be held and reconsidered for future releases. A target release may be assigned to indicate the timeframe in which the Change Request may be *Submitted* to re-enter the CCB Review queue.	Admin Project Manager
Duplicate	A Change Request in this state is believed to be a duplicate of another Change Request that has already been submitted. Change Requests can be put into this state by the CCB Review Admin or by the team member assigned to resolve it. When the Change Request is placed into the *Duplicate* state, the Change Request number it duplicates will be recorded (on the Attachments tab in ClearQuest). A submitter should initially query the Change Request database for duplicates of a Change Request before it is submitted. This will prevent several steps of the review process and therefore save a lot of time. Submitters of duplicate Change Requests should be added to the notification list of the original Change Request for future notifications regarding resolution.	Admin Project Manager QE Manager Development
Rejected	A Change Request in this state is determined by in the CCB Review Meeting or by the assigned team member to be an invalid request or more information is needed from the submitter. If already assigned (*Open), the Change Request is removed from the resolution queue and will be reviewed again. A designated authority of the CCB is assigned to confirm. No action is required from the submitter unless deemed necessary, in which case the Change Request state will be changed to More Info. The Change Request will be reviewed again in the CCB Review Meeting considering any new information. If confirmed invalid, the Change Request will be Closed* by the CCB and the submitter notified.	Admin Project Manager Development Manager Test Manager
More Info	Insufficient data exists to confirm the validity of a *Reject* or *Duplicate* Change Request. The owner automatically gets changed to the submitter who is notified to provide more data.	Admin
Opened	A Change Request in this state has been determined to be "in scope" for the current release and is awaiting resolution. It has been slated for resolution before an upcoming target milestone. It is defined as being in the "assignment queue". The meeting members are the sole authority for opening a Change Request into the resolution queue. If a Change Request of priority two or higher is found, it should be brought to the immediate attention of the QE or Development Manager. At that point they may decide to convene an emergency CCB Review Meeting or simply open the Change Request into the resolution queue instantly.	Admin Project Manager Development Manager QE Department
Assigned	An *Opened* Change Request is then the responsibility of the Project Manager to Assign Work based on the type of Change Request and update the schedule, if appropriate.	Project Manager
Resolved	Signifies that the resolution of this Change Request is complete and is now ready for verification. If the submitter was a member of the QE Department, the owner automatically gets changed to the submitting QE member; otherwise, it changes to the QE Manager for manual re-assignment.	Admin Project Manager Development Manager QE Manager Development Department
Test Failed	A Change Request that fails testing in either a test build or a release build will be placed in this state. The owner automatically gets changed to the team member who resolved the Change Request.	Admin QE Department
Verified	A Change Request in this state has been *Verified* in a test build and is ready to be included in a release.	Admin QE Department
Closed	Change Request no longer requires attention. This is the final state a Change Request can be assigned. Only the CCB Review Admin has the authority to close a Change Request. When a Change Request is Closed, the submitter will receive an email notification with the final disposition of the Change Request. A Change Request may be *Closed: 1) after its Verified* resolution is validated in a release build, 2) when its Reject state is confirmed, or 3) when it is confirmed as a Duplicate of an existing Change Request. In the latter case, the submitter will be informed of the duplicate Change Request and will be added to that Change Request for future notifications (see the definitions of states "Reject" and "Duplicate" for more details). If the submitter wishes to contest a closing, the Change Request must be updated and re-*Submitted* for CCB review.	Admin

The state ‘tags’ provide the basis for reporting Change Request (aging, distribution or trend) statistics.