Roles and Activities >
Change Control Manager >
Review Change Request
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.
Frequency:
Once a configuration item has been baselined and entered into the
configuration management system, all requests to bring changes to it should go
through the official change request management process.
Role:
Change Control Manager
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, may play this
role. In the Unified Process for EDUcation, 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. The 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.
Typical states that a Change Request may pass through are shown in Concepts:
Change Request Management)