Activity: Review Change Request

Purpose The purpose of this activity is to determine if the Change Request (CR) should be accepted or flagged for rejection. For accepted CRs, this activity assesses priority, effort, schedule, and so on to determine if the change is in scope for the current release.
Steps Schedule CCB Review Meeting Retrieve Change Requests for Review Review Submitted Change Requests
Input Artifacts: Change Request	Resulting Artifacts: Change Request
Frequency: Once a configuration item has been baselined and entered into the configuration management system, all requests to changes to it should go through the official change request management process.
Role: Change Control Manager
Tool Mentors: Reporting Review and Work Status Using Rational ClearQuest
More Information: Change Request Management

Workflow Details:

Configuration & Change Management

Manage Change Requests

Schedule CCB Review Meeting

The Change (or Configuration) Control Board (CCB) is 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 person, 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.

The function of this meeting is to review Submitted Change Requests. An initial review of the contents of the CR 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 CR 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.

Retrieve Change Requests for Review

The Change Request Form is a formally submitted artifact that is used to track all 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 CR, 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. An example Change Request Form is provided in Artifact: Change Requests.

Review Submitted Change Requests

The function of this activity is to review Submitted Change Requests. This state occurs as the result of 1) a new CR submission, 2) update of an existing CR or 3) consideration of a Postponed CR for a new release cycle. CR is placed in the CCB Review queue. No owner assignment takes place as a result of this action.

An initial review of the contents of the CR 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.

If the CR is determined to be valid, but "out of scope" for the current release(s) it will be put in the Postponed state and will be held and reconsidered for future releases. A target release may be assigned to indicate the timeframe in which the CR may be Submitted to re-enter the CCB Review queue.

If a CR is believed to be a duplicate of another CR that has already been submitted, its should be assigned to the CCB Review Admin or the team member assigned to resolve it. When the CR is placed into the Duplicate state, the CR number it duplicates will be recorded (on the Attachments tab in ClearQuest). A submitter should initially query the CR database for duplicates of a CR before it is submitted. This will prevent several steps of the review process and therefore save a lot of time. Submitters of duplicate CRs should be added to the notification list of the original CR for future notifications regarding resolution.

Sometimes a CR is determined 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 (Opened), the CR 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 CR state will be changed to More Info. The CR will be reviewed again in the CCB Review Meeting considering any new information. If confirmed invalid, the CR will be Closed by the CCB and the submitter notified.

When a CR has been determined to be "in scope" for the current release it is assigned to an Opened state 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 CR into the resolution queue. If a CR of priority two or higher is found, it should be brought to the immediate attention of the QE or Project Manager. At that point they may decide to convene an emergency CCB Review Meeting or simply open the CR into the resolution queue instantly.

An Opened CR is then the responsibility of the Project Manager to Assign Work based on the type of CR and update the schedule, if appropriate.