The team members should be prepared with specific information from each of their respective functional areas pertaining to release readiness. This information should include risk assessments, testing results, and operations and support readiness. Each member should come prepared with a go/no-go decision recommendation. Each team member may complete the pre-designed template for his or her functional area. Templates are available online at Operations Templates.

The templates provide a structure for determining whether:

• The release is operable and supportable.
  
• The production environment (organization and infrastructure) is ready to support and operate the release.
  
• The release strategy plans are comprehensive and complete.
  

Team members fill in the template with talking points that include a preliminary go/no-go decision and collect evidence to support their conclusions about the readiness of each element. The following table lists some possible examples:

Table: Go/No-Go Indicators

Element	"Go" indicators	"No-Go" indicators
Release	All prerequisites have been met. All documentation is in order. Adequate rollback plan exists.	Release is not built to standards. Documentation is missing. Primary and secondary support personnel have not been assigned.
Production environment	Support staff is already trained. All administrative procedures for the release are clear and aligned with site standards. Operating level agreements (OLAs) and underpinning contracts (UCs) are in place and appear to support required service levels.	Software levels used to build the solution are unsupported (too new, too old) in the current environment. No support staff training plan. No backup plan.
Release strategy plans	Escalation process and contact list have been communicated. All key stakeholders have been notified. All resources required for implementation have been confirmed.	Single point of failure or fatal flaw exists in plan-for example, dependence on one technician or an unproven technology. Plan prerequisites have not been met, such as confirmation that users will be on hand to do acceptance testing. Change management documentation is not in order.

The team lead frequently strives for consensus about readiness criteria since different members may have different opinions. For example, one team member might accept a small set of tests as an indication of readiness, whereas another team member might demand a larger set. Obviously, it helps to define and communicate the criteria before attendees start gathering evidence.

The lead is also responsible for representing business-specific criteria, including the value proposition and economic justification for the release, as well as any overriding business imperatives. For example, team members might need to accept a lower level of readiness for a release that is required to address a business-threatening security breach.

Although new information or additional action items might affect a team member's final decision, this preparation is essential for an effective review meeting.

In order to take any customer commitments into account during the review, it is critical that all team members receive such information before the review. A customer commitment is not a valid reason to proceed with a release which is not ready, but that commitment might affect the tactics of readiness action plans.

In summary, the team member votes "go" if the release itself, the production environment, and the release strategy plans (if executed) will result in the release being deployed into the environment and meeting agreed service levels with respect to the team member's functional area. Accordingly, a "no-go"vote should be submitted if any of the above criteria are not met.