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
- Rollout 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.
Overall Go/No-Go Decision
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|
Every attendee must vote yes for approval.
A simple majority or a predefined percentage of attendees must vote yes for approval.
An attendee may abstain due to lack of impact of the release in his or her area of responsibility.
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.
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
- The development team taking lessons learned from the review
back to developers to apply to the development of future
If action items require changes to the release or the IT environment, it is essential to use the organization's formal change management process.