The team lead (again, usually the change manager) facilitates the Change Initiation Review meeting with assistance from the timekeeper and minutes-taker, most likely the change administrator. For each request for change (RFC) reviewed in the Change Initiation Review, the change manager must ensure that the required quorum of voters is present at the meeting. That is, all the required voters (or substitutes) and the minimum number of voters must be present, as defined by the voting logic for the type of RFC in question. If insufficient stakeholders are available to validate the vote, the change manager must reschedule the review, and the RFC is placed in a pending state until then. The review can be deferred to the next scheduled meeting if time constraints allow. If not (for example, because the change must be made before the next scheduled meeting), the change manager must arrange an extra meeting to review the RFC and possibly increase its priority.

Change initiators are normally present at the Change Initiation Review session that considers authorizing their proposed change. They may be requested to obtain more information and then present the RFC again. Or additional supporting information might be required from some other member of the Change Initiation Review team. For example, more detailed information about the security implications of the change might be needed from the security manager, or details about the wider impact on service levels might be needed from the service manager. The change advisory board (CAB) then schedules a new meeting to review the new evidence and places the RFC in a pending state while the information is being obtained. The change manager updates the change log with the request for more information and the date and time of the next review.

The CAB may also want to make changes to the RFC. Because change initiators must agree to any alterations, their presence at the meeting will speed up the decision on the RFC in light of these alterations.

During the review, each team member is polled to present his or her decision, the reasons behind it, and any issues that need to be resolved in the following areas:

• The impact that the change will have upon the business operation.
  
• The effect upon the infrastructure and customer service, as defined in the service level agreement (SLA), and upon capacity and performance, reliability and resilience, resources, contingency plans, and security.
  
• The standards and policies in place for the affected infrastructure.
  
• The business need and cost justification of the change.
  
• Any budgetary signoff requirements.
  
• The impact on other services that run on the same infrastructure (or on software development projects).
  
• The impact on non-IT infrastructures within the organization-for example, security, office services, transport, and help desks that serve business customers.
  
• The consequences of not implementing the change.
  
• The IT business resources and other resources required to implement the change, including the likely costs, the number and availability of people required, the elapsed time, and any new infrastructure components required.
  
• Additional ongoing resources required if the change is implemented.
  

Based upon these assessments and the potential benefits of the change, each of the Change Initiation Review members should be able to decide whether to approve the initiated change for development and eventual deployment.

The Change Initiation Review process should be based on the same predefined approval logic used by the CAB to approve changes.

The change manager predetermines 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 change in his or her area of responsibility.
Vetoes	One attendee may have the ability to say no, which results in rejection of the change. For example, the security member may veto any change with a potential impact on the Domain Name System (DNS) or a firewall.
Quorum/Required voters	Defines minimum number of people to form a quorum or the minimum percentage of votes required to constitute majority status.

Further information about CAB voting logic is contained in the Microsoft Operations Framework (MOF) Change Management Service Management Function guide, available at the Microsoft Operations Framework (MOF).

Once voting has been completed for the RFC under review and the change is deemed ready to proceed, it can enter the change development phase. If team members have voted not to approve the change, more work or re-work will likely be needed to satisfy the requirements of the concerned attendee or group in order for the change to be resubmitted. Adjustments are committed action items.

If action items are required, each should include:

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

Possible action items include:

• Further planning is required.
  
• Additional documentation is required.
  
• The timing must be addressed.
  
• The infrastructure policies must be followed, and the plan must be changed.
  

If action items require further changes to the RFC or the IT environment, it is essential to use the organization's formal change management process and update the change log accordingly.