Prior to the Change Initiation Review, there are important planning aspects to be considered that contribute to an effective and efficient change initiation and approval process. Different role clusters within the Microsoft Operations Framework (MOF) can submit requests for change (RFCs) for approval in the Change Initiation Review for a variety of reasons, as shown in the following table.
Table: Typical Change Requests According to the MOF Role Cluster
Role cluster | Type of change request |
---|---|
Infrastructure |
New systems and improvements to existing systems and infrastructure. |
Operations |
Changes that affect or improve day-to-day operations of the technology. |
Partner |
Third-party and supplier-related changes-for example, changes to an outsourced partner system affecting in-house systems. |
Release |
Changes to the change, configuration, and release management systems and processes. |
Security |
Changes to security processes-for instance, authentication or network security improvements. |
Service |
Changes driven by new service level requirements, service improvement projects, or business strategy. |
Support |
Changes enabling incident and problem resolution and changes to the help desk system. |
In addition to the role clusters, other groups outside operations may submit an RFC (for example, a graphics production group), although they may also work in conjunction with a specific MOF role to initiate a change request. The review can be held in different formats depending on the type of change that has been submitted for approval. The type of review selected may also be affected by the size of the group that is convened and the members' geographic locations.
Selecting the Review Team Lead
The team lead for this operations management review (OMR) is typically the change manager or a designated representative from change management who is selected by the change manager or the change advisory board (CAB). Another option is to select the lead from the key functional area or team role cluster for the proposed solution. For example, a representative from security would be a suitable team lead for a security-centered RFC since this person would have in-depth knowledge of the change and the requirements, policies, and standards in use.
The team lead guides the Change Initiation Review process to a go/no-go decision. In the case of standard and minor changes, if the change manager is the lead reviewer, he or she may simply authorize the change under the criteria defined in the change management process. The selected team lead is responsible for overseeing the planning activities leading up to the Change Initiation Review, including setting the parameters for the review, developing the agenda, and communicating meeting details. The review lead also invites the review participants, including the change initiator, the change owner, and members of the CAB.
If the review is to take the form of a CAB, a CAB emergency committee, or a meeting of the IT board, then the preparatory activities must include the requirements outlined in the change management process for these methods of approval. The CAB should contain at least one member from each role cluster as defined in the MOF Team Model. The CAB has several members who always participate (or who have replacements who participate in their absence) and review all RFCs submitted to them. In addition to these regular members, the CAB should include personnel and experts who are from departments affected by the change or who can add value to the discussion of the change. These additional members are chosen on a case-by-case basis.
The process of selecting review team members can be simplified by drawing up a CAB membership list for each type of change-for example, network infrastructure change, facilities change, new application, new data, operating system fix/upgrade, desktop fix, and so on. For each change being reviewed, CAB members can be selected from the standing list and the optional lists. Individuals can be added or removed as necessary. The total number of CAB members should still be limited in order to make the CAB meetings more efficient and manageable.
As a general guide, the review activities are as follows.
Team Lead Sets Review Parameters
The basic review parameters include team members, RFC number, change details, review date, time, location, technology, and review scope. (A Change Initiation Review Definition template is provided online at Operations Templates.)
The team lead selects the review team members. These can be representatives from selected role clusters in the MOF Team Model, as well as representatives from the development and test teams, the customer, and end users of any proposed change or solution. For the Change Initiation Review to be effective, it is imperative that the review team members possess the knowledge and authority to make decisions about the suitability of the RFC and are able to commit to further any action items for their functional role cluster 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; in this case, the team lead is responsible for ensuring that a customer advocate is included to represent that point of view.
Also during this step, the Change Initiation Review team lead:
- Sets the date, time, nature, and length of the Change
Initiation Review meeting.
The CAB normally meets on a regular basis-for example, monthly. The standing members always attend or send replacements who are authorized to make decisions in their place. When authorization for initiation needs to be expedited, the change manager or the CAB/EC can authorize such changes. Further information is contained in the Change Management service managment function (SMF), available at the Microsoft Operations Framework (MOF).
The meeting's duration is dependent on the nature and complexity of the changes to be discussed. For example, the Change Initiation Review for a minor or standard change may not require a meeting at all. The change manager and change initiator can confirm this type of change, provided the change initiator has gathered and collated the correct information on the RFC form.
Larger, complex, and high-impact changes may require lengthier discussions of additional submitted material. Keep in mind when scheduling the Change Initiation Review that significant or major changes often require attendance and approval by high-level decision makers or budget holders, whose schedules are usually the most challenging to accommodate. The change manager should be able to escalate any issues in ensuring attendance of the right people. - 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. The team lead also obtains meeting supplies
and equipment, such as a PC projection system and
flipcharts.
- Communicates the approval logic for reaching a decision to
approve the change. This might require unanimous approval by every
attendee, a majority vote by a predefined percentage, or a simple
majority; this logic should be defined before the meeting. Further
information about voting logic is contained in the Conduct Review
section later in this document, and in the Change Management SMF at
the Microsoft Operations Framework (MOF) Web
site.
- Defines the review scope, which helps the team focus on the
deliverables. The scope of the review depends on the scope of the
change, which includes:
- Functionality - The functionality provided by the
change.
- Geography - The physical locations affected by the
change.
- Organization - The parts of the organization affected by
the change.
- Infrastructure - The infrastructure affected by the
change.
- Functionality - The functionality provided by the
change.
The team lead should review the change log for similar changes that may have been approved before. Throughout the change life cycle, from initiation through development and culminating in deployment, everyone involved in the change (whether or not they are part of the team) should review the change log to ensure that they:
- Identify and manage risks encountered for similar
changes.
- Repeat best practices discovered in association with previous
changes; these best practices are usually added to the standards
and policies managed by infrastructure engineering.
- Avoid repeating any mistakes made in association with previous
changes.
Team Lead Sets Review Agenda
A written agenda often improves the effectiveness of a meeting; this is certainly true of the Change Initiation Review meeting, especially if there is more than one RFC to be discussed and authorized. Communicating the agenda well in advance helps attendees prepare for the meeting, allowing for optimized discussions during the review.
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-usually the change manager-is made much easier if others-for instance, the change administrator-act as timekeeper and minutes-taker.
Team Lead Announces Meeting Details
The review meeting announcement contains details that typically include:
- A review definition sheet that outlines basic review parameters
that the team lead has set previously, such as meeting
participants, review date, time, location, and review
scope.
- Previously selected meeting format. As an alternative to
holding face-to-face meetings, CAB meetings may be held by using
NetMeeting technology or telephone conference calls.
- Links to the change log for all RFCs that are going to be
reviewed.
- The order in which RFCs will be reviewed (agenda). CAB members
may be interested in only a small number of the proposed changes
and might join the meeting only when necessary.
- Ground rules and guidelines for the meeting.
- Pre-work templates for each role in the review.
- A copy of the forward schedule of change for planning and
discussion.
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. Suggestions for using OMR meetings to accomplish more than just their OMR objective are contained in The Effect of Business Context.
Note: |
---|
The meeting notification must be sent to the attendees far enough in advance to allow them to review the RFCs before the meeting. |
Samples and Templates
Template versions of these sample templates are available online at Operations Templates.