The team lead facilitates the review meeting with assistance from the timekeeper and minutes-taker. During each part of the review, each team member is polled to present a preliminary decision (and the evidence for it) and makes known any issues that need to be resolved.

The review includes these four parts:

• Release readiness - Release readiness is covered first because there is no point in proceeding with the discussion if the team decides that the release itself is not ready for deployment. A key component of determining release readiness is reviewing test results and deciding whether the results are acceptable for deployment into production. The test results review includes acceptance and pilot testing and performance and stress testing, if appropriate. Other testing results may be reviewed as well, including regression testing, integration testing, system testing, and QA testing.
  
• Production environment (organization and infrastructure) readiness - This is a discussion of whether the environment is ready to accept the deployed release.
  
• Release strategy readiness - The team decides the completeness, accuracy, and reasonableness of the release strategy plans. The plans that need to be included are:
  
  • Rollout plan
    
  • Rollback plan
    
  • Training plan
    
  • Support plan
    
  • Communications plan
    
  • Risk management plan
    
• Risk management - A risk is the possibility of suffering a loss, and risk management is essentially the process of identifying risks and deciding on an approach for mitigating each. Risk management is important to the Release Readiness Review process because this is a key point where decisions are made that can potentially introduce risks into the IT environment.
  

The Release Readiness Review process should be based on the same pre-defined approval logic used by the change advisory board (CAB) to approve changes.

Default logic should be in place. An example would be: "A 75 percent majority vote is required with all core board members present."

The change manager pre-determines whether the default logic is adequate and whether additional or different logic must be applied. The person in this role informs the members of the logic prior to the meeting. The following table offers an overview of voting approaches.

Table: Types of Approval Logic

Type of approval logic	Description
Unanimous	Every attendee must vote yes for approval.
Majority	A simple majority or a predefined percentage of attendees must vote yes for approval.
Abstentions	An attendee may abstain due to lack of impact of the release in his or her area of responsibility.
Vetoes	One attendee may have the ability to say no, which results in rejection of the release readiness approval. For example, the security member may have veto on any release with a potential impact on Domain Name System (DNS) or a firewall.
Quorum/Required voters	Defines minimum number of people to form a quorum or the minimum majority percentage requirement.

If the release is deemed ready to proceed, but at least one team member has voted no-go, adjustments in the form of more work or re-work may be needed to satisfy the requirements of the concerned attendee or group. Adjustments are committed action items.

If action items are required, each should have the following:

• A description of the action.
  
• The owner of the action.
  
• The deadline for completion.
  
• The criteria for completion.
  

Possible action items include:

• Further testing is required.
  
• Additional documentation is required.
  
• Improvements to risk mitigation plans, training plans, or support plans.
  
• The development team taking lessons learned from the review back to developers to apply to the development of future releases.
  

If action items require changes to the release or the IT environment, it is essential to use the organization's formal change management process.