1

Prepare for Review Meeting

• Before meeting, all participants must be prepared to discuss the change requests.
• Examine all change requests assigned to the business analyst, and determine which change requests can be reviewed in the allotted time. Use the Priority field to ensure higher priority change requests get reviewed. These change requests become the agenda for the review meeting.
• Send the change request list for review to all meeting participants well before the actual review meeting. Give everyone enough time to review the change requests. Include links to the change request work items to make it easy to find information about the change requests.
• Each participant should think through the proposed resolution for each change request to ensure that such a resolution will not negatively impact customer value and satisfaction, create a gap in a key user scenario, or prevent your team from achieving its vision for the customer.
• The release manager should anticipate questions and concerns from other participants and gather information beforehand to be ready. The release manager should also think through alternate solutions and be able to communicate why his or her solution is the most appropriate for the customer.

2

Hold Review Meeting

• Meet and discuss change requests in the order determined by the agenda. Use the attached proposed solution for each change request to guide discussion. If a Microsoft PowerPoint slide deck was created, the business analyst should guide the presentation.
• The focus of any discussion concerning change requests should be on the user and business impact, not on the individuals involved with the feature. This perspective takes personal issues out of the discussion and puts the focus on user and business impact.
• Each participant should represent their discipline and identify any inaccuracies or misunderstandings in the change request. For example, if a component in the change request has another dependent component that is not identified, the development manager should point this out.
• Each participant should indicate if they agree or disagree with the proposed change, and why. Participants should indicate if their team has enough resources and time to accept the change. Participants should suggest alternatives if they see blocking issues for their area.
• The change request is approved or rejected. Approval is not determined by consensus where everyone agrees, because that level of consensus is too difficult to meet for the challenge and complexity of reviewing change requests. Instead consensus is reached when no one objects; the team must work toward solutions that everyone can live with. This presents a far more achievable and often more optimal outcome.

3

Approve Change Request

• Optional
• If the change request is approved, it moves to the Active state with the reason set to Accepted.
• Update the change request work item with any new information decided during the change request review. Record the reasons for accepting, or modifying the change request so that anyone interested in investigating the status of a feature can read about it in the work item.
• Document in which iteration the change request will be implemented.
• Assign the change request to the appropriate project manager to begin implementing the change.

4

Reject Change Request

• Optional
• If the change request is rejected, it moves to the Closed state with the reason set to Rejected.
• Record the reasons for rejecting the change request so that anyone interested in investigating the status of a feature can read about it in the work item. Rejecting a change request now, however, doesn’t necessarily mean that you shouldn’t consider the change request for the next version of the product or feature. Record discussions about what is important or desirable to include in the next version of the product.

5

Defer Change Request

• If the change request is deferred because more information or investigation is required, leave the change request in the Proposed state.
• Record the reasons for deferring the change request. Identify what information is required, or who should be consulted. The change request must then return to the Analyze Change Request activity for further analysis.

6

Communicate Changes

• Communicate through e-mail with everyone who will be impacted after the change control board has approved the change. Because most changes impact people on other teams, communicate changes to people beyond the immediate feature team. For example, other teams may be dependent on a component that will change. Also people working on related areas of the product or people from other areas, such as upper management and marketing may need to be aware of the change.

Accepted or rejected change request.