Prior to conducting the actual Release Readiness Review, there are important planning aspects to be considered that contribute to an effective and efficient Release Readiness Review process.

The team lead is usually the release manager or a designated representative from release management who is selected by the release manager or the change advisory board (CAB). Another option is to select the lead from the key functional area of the solution. For example, a representative from security would be a suitable team lead for a security-centered release.

The review team lead guides the review process to a go/no-go decision. The selected team lead is responsible for overseeing the planning activities, including setting the scope for the review, developing the agenda, and communicating meeting details. This person also invites the review participants, who include the change initiator, the change owner, and members of the CAB.

The basic review parameters include team members, review date, time, location, technology, and review scope. (A template is provided online at Operations Templates.)

The team lead selects as team members representatives from each role cluster in the Microsoft Operations Framework (MOF) Team Model, as well as representatives from the development and test teams, the customer, and users. For the review to be effective, it is imperative that team members possess the knowledge and authority to make decisions about the readiness of the release and are able to commit to action items for their functional areas. In the case of emerging IT service providers, such as application service providers (ASPs) and business-to-business suppliers (B2Bs), a real customer might not be accessible; if so, the team lead is responsible for ensuring that a customer advocate is included to represent that point of view.

Also during this step, the readiness review team lead:

• Sets the date, time, length and location of the review meeting. Like any meeting, it must be scheduled far enough in advance for attendees to include it in their schedules. Because it is a final signoff, it must take place after the readiness preparations have been completed. The meeting's length is dependent on the nature and complexity of the release. For example, the Release Readiness Review meeting for a simple or straightforward release may last just an hour, while complex, high-impact releases may require several hours. Keep in mind when scheduling that critical releases often require attendance by high-level decision makers, whose schedules are usually the most challenging to pin down.
  
• Selects and reserves the meeting technology and location, such as the physical meeting locations, video conferencing, Microsoft NetMeeting conferencing software, teleconferencing, or some combination thereof, and obtains meeting supplies and equipment, such as a PC projection system, flipcharts, and so on. Ideally, the technology and location selected would allow the release to be observed in the test environment in order to answer questions, resolve disputes, and otherwise verify readiness.
  
• Communicates the approval logic for reaching a go decision. This might require unanimous approval by every invited attendee or a majority vote by a pre-defined percentage or simple majority, but it should be defined before the meeting.
  

In setting the review parameters, the lead needs to define the scope of the review. This helps the team focus on the deliverables. The scope of the review depends on the scope of the release, which includes:

• Functionality - The functionality provided by the release.
  
• Geography - The physical locations affected by the release.
  
• Organization - The parts of the organization affected by the release.
  
• Technology - The hardware and software affected by the release.
  

The team lead should read previous team leads' comments about how best to run the review itself. Throughout the release's development, everyone involved in the release (whether or not they are part of the team) should review records of previous releases to ensure that they:

• Identify and manage risks encountered during other releases.
  
• Repeat best practices discovered in previous releases.
  
• Avoid mistakes made in previous releases.
  

A written agenda often improves the effectiveness of a meeting and this is certainly true of the review meeting. Communicating the agenda well in advance helps attendees perform their pre-meeting work.

Although it may seem obvious, it is very important that all attendees clearly understand their own roles as well as everyone else's. Also, the facilitator's job is made much easier if others act as timekeeper and meeting minutes-taker.

This meeting announcement contains details that often include:

• A review definition sheet that outlines basic review parameters.
  
• The meeting agenda and logistics, such as date, time, location, what to bring, and directions to the meeting location, if appropriate.
  
• Instructions for using the meeting technology, if required.
  
• Meeting ground rules and guidelines.
  
• Pre-work templates for each role in the review.
  

As mentioned previously, templates for all of these items are available online at Operations Templates.

When scheduling the meeting, the review team lead should consider the broader context of the meeting. For example, this may be an excellent opportunity to establish new relationships, repair broken ones, or recognize achievement. The Effect of Business Context contains suggestions for using the meeting to accomplish more than just its MOF objective.