An introduction to the MOF Change and Configuration SMF

The guidance in Microsoft Operations Framework (MOF) encompasses all the activities and processes involved in managing an IT service. It’s conception, development, operation, maintenance, and ultimately its retirement. MOF organises these activities and processes into Service Management Functions (SMFs), which are grouped together in phases that mirror the IT service lifecycle. Each SMF is anchored within a lifecycle phase and contains a unique set of goals and outcomes supporting the objectives of that phase. An IT service’s readiness to move from one phase to the next is confirmed by management reviews, which ensure that goals are being achieved in an appropriate fashion and that IT’s goals are aligned with the goals of the organisation.

MOF begins with the Plan phase and our previous blog articles in this series explain the role of the Microsoft Operations Framework (MOF), service management functions (SMF’s) and introduce the Planning SMF which is the first step in implementing MOF within your business. If the topics introduced below don’t make sense or perhaps you feel they’re missing context then please refer to the following articles for background context and explanation.

Blog Article 1: What’s your ITIL IQ®? Meet MOF

Blog Article 2: The MOF Plan Phase

Blog Article 7: The MOF Deliver Phase

Blog Article 13: The MOF Operate Phase

Blog Article 18: The MOF Manage Layer

Position of the Change and Configuration SMF within the MOF  IT Service Lifecycle

The Change and Configuration SMF belongs to the Manage Layer, the foundation of the MOF IT service lifecycle. The following figure shows the place of the Change and Configuration SMF within the Manage Layer, as well as the location of the Manage Layer within the IT service lifecycle.

MOF-Change-and-Configuration-SMF

Figure 1. Position of the MOF Change and Configuration SMF within the IT service lifecycle

Why Use the Change and Configuration SMF?

This SMF should be useful for anyone who wants to understand and gain control over the changes made in IT.

It addresses how to do the following:

  • Manage changes.
  • Know the current state of configuration at all times.
  • Reduce risk of negative impact from changes to the organisation.
MOF Change and Configuration SMF Overview

Change management is very important. To deliver reliable and effective IT service, organisations need to ensure that change is planned and purposeful. The business relies on IT to embrace change management processes that take into consideration the needs for prompt action, reliable services, and compliance with policies and regulations.

Change in any form carries risk, such as risk of failure, cultural resistance, disruption of operations, technical challenges, resource constraints, and unanticipated consequences. But many IT organisations fail at change management, either because they find it so big and onerous that they don’t try it at all, or because they make it so complicated that no one will use it.

It doesn’t have to be that way.

The MOF Change and Configuration Management SMF offers best practice guidance to help IT manage change through repeatable, predictable, and measured processes while addressing risk. An organisation’s tolerance for risk determines the appropriate level of detail and formality to apply to change processes for each type, size, and timing of change.

When an IT organisation determines how restrictive and how formal change management should be at any point in the IT service lifecycle, it must balance the cost of controlling the change against the benefit of the control. This balance depends on the impact of making or not making the change, the organisation’s risk tolerance, and the speed with which the decisions must be made. Costs of change management controls may include time, money, and speed. Another cost may be limiting exploration of alternatives too soon. Benefits of restricting changes include more efficient work, more stable environment, and minimised impact to related services, all of which have financial and timing implications.

Change management applied at the appropriate level throughout the IT service lifecycle establishes boundaries within which flexibility exists. These boundaries narrow from the Plan through the Deliver and Operate phases, as impacts and risks to the production environment and IT services become more immediate.

The risk of a change is determined by the classification and place in the IT service lifecycle of the change. The level of identified risk determines the rigor required in change control.

Risk is driven, in part, by the place in the IT service lifecycle where the change is requested. Change controls should be looser for change requests in Plan and the beginning of Deliver, and tighten toward the end of Deliver and in Operate. In the Plan Phase and early in the Deliver Phase, there are risks that come from not allowing exploration and evaluation across a range of alternatives. As an IT service moves through Deliver, risk increasingly evolves into a disruption of the work that is being done or into an expansion of scope so that the decisions made in the Plan Phase are overturned. In the Operate Phase, the biggest risk is destabilising well functioning IT services.

Changes can be organised in the following categories:

  • A change where the impact on the group could be massive—for example, a departmental or company wide change, or a network wide or service wide change.
  • A change where the effect is widespread, but not massive—for example, a change affecting a group within a department or a specific group of configuration items (CIs).
  • A change affecting small numbers of individuals or CIs—for example, a change to a printer used by a department consisting of just a few members.
  • A change that has been performed before and is part of the operational practice of the business—for example, an update to a user profile.

Standard changes provide agility within the boundaries of change management in the Operate Phase. Every organisation should develop a collection of standard changes, ensuring predictability and the efficient use of resources by using a “tried, tested, and true” standard process for common change requests. This is accomplished by identifying common recurring changes and optimising their execution. Ideally, 80 percent or more of all Operate Phase changes should be standard, this signals a mature change management process.

A standard change begins as a minor, significant, or major change. After the change has been thoroughly tested, deployed, and validated and the execution steps have been documented, a change may become standard. Examples of standard changes include desktop refresh, standard software deployment, password reset, and patch management.

As changes are approved and implemented, it is critical to record an accurate picture of the production environment configuration before and after each change is made. With configuration information readily available, IT is better equipped to:

  • Evaluate proposed changes.
  • Understand the current state of the production environment.
  • Troubleshoot problems by analysing recent changes made to the production environment.
  • Return the configuration to a previously known state to address chronic problems or to meet regulatory requirements.
  • Test changes outside of the production environment with the confidence that the production environment will be similar to the test environment.
Change and Configuration SMF Role Types

The primary Team SMF accountability that applies to the Change and Configuration SMF is the Management Accountability.

The following table lists the role types associated with the Management Accountability, as well as the responsibilities and roles for each role type.

Table 1. Management Accountability and Its Attendant Role Types

Role Type Responsibilities Role in This SMF
Change Manager ·        Manages the activities of the change management process for the IT organisation ·        Ensure changes are made with the least amount of risk and impact to the organisation
Configuration Administrator ·        Tracks what is changing and its impact

·        Tracks configuration items (CIs), updates configuration management system (CMS)

·        Ensure a known state at all times
Goals of Change and Configuration

The primary goal of change and configuration management is to create an environment where changes can be made with the least amount of risk and impact to the organisation.

Table 2 shows the desired outcomes of the Change and Configuration SMF goals and lists measures that you can use to gauge how successfully you have achieved these goals.

Table 2. Outcomes and Measures of the Change and Configuration SMF Goals

Outcomes Measures
Have a predictable process for managing changes to the production environment to improve reliability and customer satisfaction. ·        Improved reliability scores (see the Reliability SMF, and the Operations Health Review in the Operate Phase Overview)

·        Improved customer satisfaction scores (see the Service Review in the Plan Phase Overview)

Eliminate unnecessary change. ·        Reduction in cancelled projects

·        Reduction in reversed changes

Reduce unintended side effects. ·        Reduction in production failures
Enable IT to revert to a previous environment state in response to service disruptions by keeping accurate knowledge of the configuration and changes made. ·        Number of managed service maps compared to the number of services offered

·        Number of items in the Configuration Management System (CMS) with historical state records

·        Date range of historical data maintained within the CMS (for example, previous states for the past 6 months)

Enable troubleshooting problems through an analysis of recent changes. ·        Changes to production are known

·        Decrease time to resolve problems

Key Terms

The following table contains definitions of key terms found in this guide.

Table 3. Key Terms

Term Definition
Change The addition, modification, or removal of approved, supported, or baselined hardware, networks, software, applications, environments, systems, desktop builds, or associated documentation.
Change advisory board (CAB) A cross-functional group set up to evaluate change requests for business need, priority, cost/benefit, and potential impacts to other systems or processes.
Change category Measurement of a change’s release impact on IT and the business. The change complexity and resources required, including people, money, and time, are measured to determine the category.
Change log A log of Requests for Change (RFCs) submitted for all changes in a service that tracks the progress of each change from submission, through review, approval, implementation, and closure. A change log can be managed manually with a document or spreadsheet, or it can be managed automatically with a tool.
Change Manager The role that has the overall management responsibility for the change management process in the IT organisation.
Configuration item (CI) An IT component that is under configuration management control. Each CI can be composed of other CIs. CIs may vary widely in complexity, sise, and type; their scope can range from an entire system (including all hardware, software, and documentation) to a single software module or a minor hardware component.
Configuration management system (CMS) A set of tools that is used to manage IT service management data such as changes, releases, known errors, and incidents.
Definitive software library (DSL) A secure software library where all versions of software CIs that the CAB has approved for deployment are held in their definitive, quality controlled form.
Forward Schedule of Change (FSC) A record of upcoming approved changes, also known as a change/release calendar, which may help you understand the impact that already approved changes might have on any new proposed changes. This can also be accomplished using the service portfolio described in the Business/IT Alignment SMF.
Post-implementation review (PIR) A review that occurs after release of a new or updated service. This review evaluates and measures the success of the release in the production environment.
Release A collection of one or more changes that includes new and/or changed configuration items that are tested and then introduced into the production environment.
Release Manager The role that is responsible for managing and coordinating the activities of the release management process for the IT organisation.
Request for Change (RFC) The formal change request, including a description of the change, components affected, business need, cost estimates, risk assessment, resource requirements, and approval status.
Risk value A part of the RFC that captures the assessments of risk for a change.
Service map A representation of a service from the perspective of the business and user that shows critical dependencies, settings, and areas of responsibility (for more information about service maps, see the Business/IT Alignment SMF).
Standard change A change category that describes changes that are pre-approved and that can bypass the authorisation process to proceed directly to release.
Change and Configuration Process Flow

The change and configuration management process flow provides the overall structure for this SMF with a consistent set of processes for initiating and completing changes.

Change and configuration management consists of the following tasks:

  • Baseline the configuration.
  • Initiate the change.
  • Classify the change.
  • Approve the change.
  • Develop and test the change.
  • Release the change.
  • Validate and review the change.

Figure 2 illustrates the process flow for change and configuration management.

Change-and-configuration-management-process-flow

Figure 2. Change and configuration management process flow

Process 1: Baseline the Configuration

As you begin the process of initiating and implementing a change, your first process should be to baseline the configuration so that the starting configuration is known. This baseline may be needed for rollback, disaster recovery, and understanding the impact of the proposed change.

Baseline-the-configuration

Figure 3. Baseline the configuration

Activities: Baseline the Configuration

In order to successfully manage change, an organisation must also manage the configuration of the production environment. The most effective way to do this is to baseline the configuration before and after each change.

A configuration baseline is a snapshot of the IT environment that identifies its structure and underlying dependencies. The data from this snapshot should be captured and recorded in a configuration management system (CMS). A CMS can be as simple as a spreadsheet or as complex as an integrated set of tools that includes a database.

A CMS provides:

  • A way to understand, control, and predict the consequences of change.
  • An accurate and comprehensive representation of the state of the production environment.
  • A history of previous states to support efforts to analyse and remedy problems.

IT professionals can use the CMS throughout the change process by:

  • Reviewing it as part of evaluating a new request for change (RFC) in order to understand the impact of the proposed change.
  • Updating it with approved RFCs so that this knowledge can be used in evaluating other RFCs.
  • Updating it with released changes so that this knowledge can be used in troubleshooting any problems that arise after the change.
  • Using it to confirm a known good state for rolling back any changes that have unexpected negative impacts.

A CMS contains information about configuration items (CIs), which are IT components that are important in understanding the state of the production environment. Each CI may be composed of other CIs and can vary widely in complexity, size, and type – from an entire system (including all hardware, software, and documentation) to a single software module or a minor hardware component. All versions of software CIs that the change advisory board (CAB) has approved for deployment should be contained in their definitive, quality-controlled form in a definitive software library (DSL). This is a secure software library that provides a known good source of the software used in production.

Baselining configuration can be a major undertaking. One option is to baseline as you make changes so that eventually the entire production configuration is known.

The following table lists the activities involved in baselining the configuration. These include:

  • Defining and collecting the configuration data to track in the CMS each time a new type of CI is added to the configuration.
  • Auditing the CMS content.

Table 4. Activities and Considerations for Baselining the Configuration

Activities Considerations
Define and collect the configuration data to track in the CMS

 

Key questions:

·        What information should be captured?

·        Which users need access to service and/or system component information?

·        In what format would the information be most useful to each user?

·        Does any information in the CMS need to have restricted access?

·        How often does data need to be updated?

·        How will this data be used?

Inputs:

·        Service level agreements (SLAs) (see Business/IT Alignment SMF)

·        Operational level agreements (OLAs). (see Business/IT Alignment SMF)

·        Underpinning contracts (UCs) (see Business/IT Alignment SMF)

·        Applicable regulations and laws (see Policy SMF)

·        Internal policies (see Policy SMF)

·        Risk and impact analysis (see Governance, Risk, and Compliance SMF)

·        List of needed and desired CMS reporting requirements

Outputs:

·        RFC and CMS requirements

Best practices:

·        Define both business (services interdependencies) and technical (system components) use of data.

·        To obtain the most complete idea of needs, involve all relevant people in assessment and planning. This group might include individuals from Solution Development, Enterprise Architecture, Operations, Service Desk, and the business.

·        Start by tracking as little data as possible, and add more as needed. Keeping configuration records up-to-date takes resources. Be sure the return on the additional data collected is worthwhile. Know why you are tracking the data you are tracking.

·        When you add a new type of CI, re-evaluate the configuration data to be tracked.

Audit the CMS content Key questions:

·        Are audits mandated by regulatory compliance requirements or policy? How often should audits be done?

·        How will CMS information be confirmed? Who will confirm it?

·        Will access restrictions need to be enforced?

Inputs:

·        CMS

·        Access restriction requirements

·        Policy and regulatory requirements

·        Production environment

Outputs:

·        Current state accuracy report

·        Remediation plans for inaccuracies

Best practices:

·        Don’t let your CMS go too long between audits. Smaller corrections are much easier to do than larger remediations.

·        If the CMS frequently gets out of date, consider your processes and adjust them to improve accuracy.

Process 2: Initiate the Change

After baselining the configuration, you can initiate the change.

Initiate-the-change

Figure 4. Initiate the change

Activities: Initiate the Change

Change requests can come from many sources, including:

All change requests need to be evaluated for impact and benefit to the organisation.

The following table lists the activities involved in initiating the change. These include:

  • Initiating an RFC.
  • Checking the technical configuration.
  • Checking the business process configuration.
  • Identifying the business impact.
  • Updating the RFC.

Table 5. Activities and Considerations for Initiating the Change

Activities Considerations
Initiate a request for change (RFC) Key questions:

·        What kind of information is to be included in the change description? For example, the service that will be affected, the business benefit, and the exact description of the configuration items to be changed.

·        Who can initiate a change? Can anyone in the organisation initiate a change?

·        How will the RFC be categorised and tracked?

·        Does each service maintain its own set of RFCs?

·        How are RFCs interlinked and cross-referenced?

·        Is there a specific RFC for common or standard changes?

Inputs:

·        Request for a change

·        Description of the change

Output:

·        New RFC

Best practices:

·        Keep RFC forms as simple as possible while capturing sufficient information to manage risk.

·        The RFC should be continually updated throughout the process; it can be initiated without a thorough analysis or detailed information about the change and then updated later. It is important to have easy access to the RFC so that additions to it can be made. Additionally, organisations can use role authentication to ensure that read and write access is applied at the right time during the process. Determine who should have permission to read or change the RFC in each process.

·        The organisation can streamline the RFC process by using pre-populated fields and drop-down lists for information such as the type of change, the service affected by the change, and the applicable technology.

·        There should be a point of contact for each change request. This can be the Change Manager or the change initiator. The point of contact should have access to the most recent history, understand the technical and resource implications, and appreciate how this change will affect other planned changes and the day-to-day work of the business.

·        Do not confuse the RFC process with a Service Desk request. The latter is a request for such things as existing services or questions about existing services, and is handled through the Customer Service SMF. An RFC is completed by the IT group to ensure that changes to the production environment are well thought out and planned.

·        Ensure that the RFC form is self-explanatory and that it is clear how to seek assistance, if needed, for completing the form.

Check the technical configuration Key questions:

·        Has the RFC identified all CIs that will be affected or that will require a change?

·        How many actual CIs will be affected? If this is a global change such as a software update, is there an accurate account of all services or production devices that will be affected?

·        When looking at the configuration database information, are there additional CIs that may be affected?

Inputs:

·        CIs

·        Service map

·        Impacted services gathered from the RFC

Output:

·        CIs impacted by the RFC

Check the business process and application configuration Key questions:

·        What business processes are potentially affected by this proposed change?

·        What will need to change to accommodate this RFC?

·        What applications will be affected by this RFC?

·        Which users and business groups need to know about this change?

·        Best practices:

·        Dependencies on business processes and functionality must be identified. If you change the workflow or how the application is used, the business must be involved to identify impacts.

·        Consider services, process, and impacted applications when considering what communications are required.

Identify the business impact and assess the risk Key questions:

·        How will the organisation benefit from the change? If the change is not done, is there a potential risk to the organisation?

 

·        How will the business justification or impact be explained and quantified? For example, if a change is requested to increase the demand of a particular service, the demand can be expressed in terms of capacity data or an upcoming business event.

·        What are the risks associated with this change?

Inputs:

·        Request for a change

·        Identification of the IT service and business group impacted by the change

Output:

·        Documentation of a clearly stated business reason and the impact and risk of the change request

Best practice:

·        For more information about assessing risk, see the Governance, Risk, and Compliance SMF.

Process 3: Classify the Change

The next process is to classify the requested change.

Classify-the-change

Figure 5. Classify the change

Activities: Classify the Change

After the RFC is initiated, the next process is to classify the request.

The following table lists the activities involved in classifying the change. These include:

  • Identifying the priority of the change.
  • Identifying the category of the change.
  • Checking and validating the configuration, assessing the risk, and updating the RFC.

Table 6. Activities and Considerations for Classifying the Change

Activities Considerations
Identify the priority of the change Key questions:

·        Is this a low, medium, high, or emergency priority change?

Priority levels should be designed with specific time frames and should support the business requirements. A typical priority ranking includes:

·        Low. The change can wait until the next scheduled release.

·        Medium. Because of its impact level, the change cannot wait until the next scheduled release.

·        High. The change needs to be released as soon as it is complete and has been tested.

·        Emergency. The change needs to be released as soon as possible; many of the approval and the development steps are abbreviated.

Best practices:

·        The Change Manager and RFC initiator might need to negotiate the priority if they are not in agreement about it. Define an escalation process.

·        If there are too many emergency and high-priority changes, review the reasons for the volume. This may indicate that staff members are avoiding the process or that the process is not effective.

Identify the category of the change Key questions:

·        What category does the change belong to?

Categories take into account the resource requirements for the change, the impact to the business of doing or not doing the change, organisational experience with the change, and new technology or processes. Typical categories include:

·        Standard change. This category is low risk because it has a set release path that has been proven to be successful, it has minimal business impact, and it has a known set of release procedures.

·        Minor change. This category affects a small percentage of users and resources. Also, the risk of an outage is less because of the organisation’s experience in implementing this type of change.

·        Significant change. This category has a moderate effect on users, resources, and the business. It might involve downtime of services and may also involve a situation in which the organisation has less experience with the product, infrastructure, or the client involved in the change.

·        Major change. With a high risk and high cost, this category involves the greatest potential impact on users and resources. It might also affect a business-critical system and could involve downtime of the service.

·        Emergency change. This category is high risk because of the urgency of release and the minimal time in which to test it. It is relatively uncertain if the change will succeed, and there is a big impact on the business if it fails. This type of change is often a result of an urgent incident. These changes are escalated to the Change Advisory Board/Emergency Committee (CAB/EC) for fast-track approval. (For more information about the CAB, see Process 4: “Approve the Change.”)

·        Unauthorised change. This level involves changes that occur outside of the agreed-to change management policies or that are specifically forbidden.

 

 Best practices:

·        Effective use of standard changes is important for keeping the process manageable and usable. Evaluate minor changes that go through the CAB process for recategorisation as future standard changes.

·        Be as specific as possible in defining what is and is not a particular type of change.

Update RFC Input:

·        Check and validate the configuration

·        Assess risk

·        Updates about the change

Output:

·        Updated RFC

Process 4: Approve and Schedule the Change

The next process is to have the change approved.

Approve-the-change

Figure 6. Approve the change

Activities: Approve and Schedule the Change

Approval of a change is driven by its category. Approval for a significant or major change usually begins by presenting the change to the appropriate approving body, a team of reviewers typically known as the change advisory board (CAB). These are key people who represent many perspectives and who will be held accountable for the results of the change. The considerations involved in establishing the CAB are discussed in the Governance, Risk, and Compliance SMF. Emergency changes are normally reviewed by an emergency committee of the CAB for fast-track approval.

It is up to the CAB to determine if the change should:

  • Be approved and scheduled.
  • Be refused and ended.
  • Be returned to earlier processes of this SMF for further clarification and consideration.

Understanding the potential impact of change is fundamental when making approval decisions. The inputs for the approval process include:

  • Previously determined risk tolerance. (This is explained in the Governance, Risk, and Compliance SMF and the Policy SMF.)
  • The category of the change, Standard, Minor, Significant, Major, or Emergency, which summarises the complexity and resources required, including people, money, and time.
  • The potential impact of the change on the organisation’s configuration and users, including service downtime.

This information helps in the identification and selection of appropriate reviewers with sufficient knowledge and authority to make a decision.

Standard changes require little effort to implement, carry a low level of risk, and have pre-defined approval. If a change has been classified as a standard change, it promptly moves through the minimally required approval and documentation process to release. Minor changes can be approved by the Change Manager. All other change categories require approval of the CAB.

The methods for reaching a decision to approve or reject a change should be determined before the CAB reviews the change. Depending on the governance models chosen by an organisation, voting is often employed to reach a decision and move the change into another activity or to stop it altogether.

Once the CAB reaches a decision, it is important that the conclusion be documented in the RFC so that the knowledge gained during the processing of the change is captured. This allows for more efficient auditing of the change management process as well as providing information that can be used in additional iterations through the change process.

The following table lists the activities involved in approving the change. These include:

  • Routing the change to the correct approving body.
  • Processing standard changes to release.
  • Analysing the impact of the change and identifying reviewers.
  • Approving or rejecting the change, or seeking additional information.
  • Updating the RFC.

Table 7. Activities and Considerations for Approving the Change

Activities Considerations
Route the change to the correct approving body Key question:

·        According to the IT governance processes, what governing body has the approval authority for this change based on its classification?

Input:

·        Governance structure (steering committees, forums) (see the Governance, Risk, and Compliance SMF for more information)

Outputs:

·        RFC added to the CAB’s agenda or given to the Change Manager

·        Standard or minor changes given to the Change Manager

Best practices:

·        Approving bodies should have some members that participate in change approvals on an ongoing basis. These standing members should be well versed in weighing the broader implications of making changes.

·        In addition to standing members, include personnel and experts from parts of the organisation 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.

·        Beware of the “this is obvious, just do it” decision. Solicit sufficiently broad input by involving a variety of parties in the approval body so that there is rigor in identifying trade offs.

Process standard changes to release Key questions:

·        Has this change been classified as a standard change?

·        Are the change tasks well known and proven?

·        When this standard change has been performed, has it always resulted in expected outcomes?

·        Does this change fit in the next available change window?

Inputs:

·        The RFC under consideration

·        List of approved standard changes

Outputs:

·        Identified standard changes proceed directly to development (if needed) or to release

·        Documentation of a standard change having passed through approval (see Process 6: “Release the Change” for more information)

Best practices:

·        ”Tried, Tested, and True”. These are characteristics of standard changes. Early examples of these changes were not standard, but as more examples of these changes were done, knowledge about them was captured. There is a high level of predictability and confidence that a standard change will yield expected results, without exception.

·        Because the types of changes that have been pre-approved as standard changes are known to have a low impact on the environment and are a low risk to it, they do not need to be reviewed again by the CAB or even the Change Manager. This, however, means that care must be taken during the initial screening to ensure that a change request that has been categorised as standard is, indeed, one of the pre-approved change types and fits in the change window.

·        Document the approval of a standard change including when it was approved and the intended results of the change.

Analyse the impact of the change and identify reviewers Key questions:

·        Who can best perform and evaluate an impact analysis for the change?

·        Does the impact analysis support the classification of the change?

·        Will policies, procedures, or any aspect of regulatory compliance be affected by this change?

·        Has the business case changed since the change was initiated?

·        Who in the business is most likely to be affected by this change in terms of either its success or failure?

·        Who has the most relevant IT technical knowledge?

·        Who would best understand the implications to the business of not making this change?

·        Who will best understand the security and privacy implications?

·        Who can represent the policy and compliance issues that might result?

Inputs:

·        The RFC and any related RFCs under consideration

·        Additional information about impacted areas needed in the review process

Outputs:

·        Standing members of change review bodies

·        Invited experts and affected user representatives

Best practices:

·        Completeness in impact analysis includes looking across all requests for changes affecting a service so that impacts are evaluated comprehensively. The evaluation procedures include processes to evaluate the costs of the changes and a means to verify that the expected business benefit exceeds cost (or that the change is mandatory).

·        Revisit the business case and impact analysis of the change to help ensure that the change and the business case still make sense. Use the impact analysis to determine the areas of the organisation that should participate in change review and to identify the potential experts or user representatives who should participate in the review.

·        Record how reviewers were identified and the fact that they agreed to participate in the review. Demonstrate that the impact of the change was considered from a broad perspective when identifying reviewers so that best efforts could be given to the approval decision.

Approve or reject the change, or seek additional information Key questions:

·        Are all members of the change review body prepared to make the decision?

·        Is there a predetermined approach to resolving impasses in approving decisions or determining tie-breakers in voting?

·        Does the change really need to be made?

·        Is the timing right to make the change or is there a better change window?

Input:

·        The RFC with change log and any other accompanying information from the analysis process

Outputs:

·        The RFC is approved and scheduled or rejected or returned

·        Any required contingencies for implementation

·        Documentation of the approval process

Best practices:

·        Implement all approved requests on a timely basis. Keep the business case and impact analysis close in time to the approval of a change to help ensure that the change is still relevant and the right thing to do.

·        Retain minutes of the change approval meetings as part of the documentation of the process and participants.

·        Identified contingencies should be kept as simple and direct as possible to minimise additional judgments or interpretations of the RFC.

Update the RFC Key questions:

·        Is all information available to complete the documentation requirements for the RFC?

·        Who will update the RFC?

·        Who needs to know the results of the CAB review?

Input:

·        The RFC and change log

Output:

·        Updated RFC and change log

·        Communication to affected groups

Best practices:

·        Timely completion of documentation and status of the RFC will reduce confusion or ambiguity around the status of the change.

·        Timely documentation also aids management’s assessment of change, risk mitigations that depend on changes moving into production, and accurate metrics indicating the maturity of the change process (for example, the number of changes authorised per week, the number of changes denied approval, and the number of standard changes automatically approved each week).

·        When a change is approved and scheduled, update the CMS with the future state and date of the configuration change. This will be used in evaluating other proposed changes.

Process 5: Develop and Test the Change

Once a change has been approved, development and then testing of the proposed change can start. These are activities that coincide with the Deliver Phase of the IT service lifecycle. They focus on ensuring that IT services are envisioned, planned, built, stabilised, and released in line with business requirements and the customer’s specifications.

Develop-and-test-the-change

Figure 7. Develop and test the change

Activities: Develop and Test the Change

Developing and testing a change are activities that tie directly to the Deliver Phase of the IT service lifecycle. More information about developing and testing a change can be found in the Deliver Phase Overview. Even more detailed information can be found in the following Deliver Phase SMFs:

Low risk and minimal effort changes can go through this process and the next process very quickly. More complex changes should follow the processes outlined in the Deliver SMFs. Both sets of processes follow a similar path. Follow these guidelines for each change request category:

  • Standard Change: Follow the established procedures for the standard change.
  • Minor Change: Follow the processes for minor changes outlined in this document. See the Deliver SMFs for more detail if needed.
  • Significant or Major Change: See the Deliver SMFs.
  • Emergency Change: Use where necessary to quickly get an essential service back up and running, Testing may be delayed until after the release of the change. Be sure to complete the testing to confirm that there are no unknown issues caused by the change. Use caution when dealing with emergency changes, as risk levels are generally higher.

The following table lists the activities involved in this procedure. These include:

  • Designing the change.
  • Identifying configuration dependencies.
  • Building and testing the change.
  • Reviewing the readiness of the change for release.
  • Updating the RFC.

Table 8. Activities and Considerations for Developing and Testing Change

Activities Considerations
Design the change Key questions:

·        Does the design demonstrate an understanding of the business requirements and define the features that users need to do their jobs?

·        Have adequate usage scenarios been developed?

·        Does the design address operational requirements?

·        Does the design address system requirements?

Inputs:

·        Business and user requirements for the solution

·        Usage scenarios

·        Operational and system requirements

Output:

·        Design document

Best practice:

·        Maintain traceability between requirements and solution features. This serves as one way to check the correctness of design and to ensure that the design meets the goals and requirements of the solution.

Identify configuration dependencies Key questions:

·        Are there other CIs that have dependencies on or that could be affected by the proposed change?

·        Does the proposed change have dependencies on other changes? In other words, does completing the proposed change require other changes to be made first?

·        Are all changes (both the prerequisites and the ultimate change) recorded in the CMS?

Input:

·        Information about other proposed changes in the CMS

Output:

·        A CMS entry showing CI dependencies that might be affected by or have an effect on the proposed change

Best practice:

·        The CMS should be updated whenever an RFC is approved. This will help track that a change is planned for a CI or group of CIs. The CMS must also be updated once the change is complete and successful.

Build and test the change Key questions:

·        Does the built-out change meet the customer’s specifications?

·        Has the development team prepared a development lab?

·        Has the development team prepared an issue-tracking process?  How will these issues be handed over to the Operations team for use in a knowledge database?

·        Have the development and test teams worked together to prepare a test specification?

·        Has the team created multiple release candidates and tested each to see whether it is fit to release to a pilot group?

·        Has the team completed user acceptance testing?

·        Has the team piloted the solution and collected feedback?

Inputs:

·        Vision/scope document

·        Functional specification

·        Customer requirements

·        Code

·        Test specification document

·        Test plan

·        Lab environment

·        Issue-tracking database and issue-tracking policies and procedures

Outputs:

·        Release candidates

·        Pilot-ready release candidate

Best practices:

·        Resolve all known issues, whether the resolutions are fixes or deferrals.

·        Define and communicate standards for issue priority and severity to all team members, including Development, Test, and User Experience.

·        Deliver the issue database to training and support staff so that they can have a deeper insight into the history of the solution and the problems found in development.

·        Schedule regular meetings with those responsible for development and testing to review issues and plan strategies for resolving them.

Review the readiness of the change for release Key questions:

·        Is there business alignment, and are priorities understood?

·        Is there clear ownership of all activities and actions?

·        Has the appropriate management signed off on all plans?

·        Have required communications with all affected groups occurred?

·        Do the users and owners of dependent services know this change is scheduled and what the impact will be to them?

·        Are the functional users ready and committed to the new processes?

·        Is the testing complete?

·        Are Operations and Support ready for the release?

Input:

·        Status reports for the Release Manager

Output:

·        A go/no go decision about whether to release

Best practices:

·        Ensure that the Release Manager is provided with the appropriate status reports.

·        Provide feedback and acknowledgement to those who have supported the release, and remind the organisation of the expected benefits.

Update the RFC Key questions:

·        Have updates been made to reflect such things as the planned release date, backout plans and any reasons for a backout (if one was required), support requirements, rollout plan, test results, observed problems, and date of the post-implementation review (PIR)? (For more information about the PIR, see Process 7: “Validate and Review the Change.”)

·        Have status updates and monitoring been done throughout the process?

·        Has the change initiator been able to view the RFC throughout the process to get status?

·        Has there been formal communication at the point of release with the change initiator?

Input:

·        Updates about the change

Output:

·        Updated RFC

Best practice:

·        The Change Manager should be monitoring open changes that are pending release in order to ensure information gets updated. An operations level agreement (OLA) can assist with setting expectations to do this.

Process 6: Release the Change

Once the changed has been built, tested, and reviewed for release readiness, it is time to release the change.

Release-the-change

Figure 8. Release the change

Activities: Release the Change

The Release Readiness Management Review marks the end of the testing of a change. At this point, the process of releasing the change begins. Releasing the change coincides with the Deploy SMF in the Deliver Phase of the IT service lifecycle.

The following table lists the activities involved in this process. These include:

  • Releasing the change and any accompanying site components into the production environment.
  • Stabilising the release.
  • Getting final customer approval of the change.
  • Documenting the released change and communicating the impact to users.
  • Transferring responsibility from the project team that built the change to Operations and Support.
  • Updating the RFC and the configuration database.

Table 9. Activities and Considerations for Releasing the Change

Activities Considerations
Release the change Key questions:

·        Is the change stable enough to release?

·        Is the team ready to release the change to production?

Inputs:

·        Released change, including:

·        Solution deliverables.

·        Solution documentation.

·        Release plan

Output:

·        Released change

Best practice:

·        Make decisions about the release strategy early in the project, possibly in the envisioning or project planning phases, to minimise risk.

Stabilise the release Key questions:

·        Does the team have a plan to monitor the solution during the quiet period? This is the period when the project team is no longer active but does respond to issues as Operations and Support escalate them to the team. Typical quiet periods last from 15 to 30 days.

·        Is the release change stable?

·        Have all issues found by testing and through pilot feedback been resolved?

·        Has user acceptance testing been done?

Inputs:

·        Test specification document

·        Master plan, including the test plan

·        Test scenarios and test cases

·        Lab environment

·        Interim builds, including:

·        Solution deliverables.

·        Documentation.

·        Issue-tracking database.

·        Issue-tracking policies and procedures

Outputs:

·        Release candidate

·        Pilot-ready release candidate

Best practices:

·        Use a formal issue-tracking system to track and report the status of bugs.

·        Document issue-tracking and reporting procedures during planning.

·        Define and agree on success criteria for testing the release candidate.

·        Do not release the candidate until the entire team signs off on its suitability.

·        Do not begin a pilot test until the project team, customers, and users all agree on the criteria for a successful result.

Get final customer approval of the change Key questions:

·        Is the customer satisfied with the change?

·        Does the customer accept the released change?

Input:

·        Released change

Output:

·        Release sign off

Document the released change and communicate the impact to users Key questions:

·        Have changes made to IT components during release been communicated and documented in the change log?

·        Has the team recorded in the change log any workarounds or requests for change submitted regarding the release?

Inputs:

·        Information about the change

·        Service map

Outputs:

·        Updated change log

·        A stable solution released into the production environment

·        A customer who is satisfied with and accepts the released solution

·        A solution that is successfully transferred from the project team to the Operations and Support teams

Best practice:

·        Clearly communicate the change to all interested parties.

Transfer responsibility to Operations and Support Key questions:

·        Has the change solution been transferred successfully from the project team to the Operations and Support teams?

·        Has training been done to ensure that Operations and Support personnel are prepared to manage and support the new service solution?

Input:

·        Released change

Output:

·        A managed and supported service solution

Update the RFC and the configuration database Key questions:

·        Has the RFC been updated to reflect any changes made from the original request?

·        Have changes made to IT components been recorded in the CMS?

·        Have any workarounds or requests for a change submitted in support of the release been recorded in the CMS?

Inputs:

·        Changes made in original request

·        Information about changed CIs

Outputs:

·        Updated RFC

·        Updated CMS

Best practice:

·        When a change is moved to production, update the CMS current state so that an accurate picture is available for problem analysis and other RFCs.

Process 7: Validate and Review the Change

The final process is to validate that the change has been released correctly and to review the effectiveness of the change.

Validate-and-review-the-change

Figure 9. Validate and review the change

Activities: Validate and Review the Change

After the team has successfully released the change into the production environment, the next important process is to validate the release and then review it. The goal of validation is to verify that the change has actually been released as expected. The goal of reviewing the change, typically called a post-implementation review (PIR), is to determine whether the change has had the desired effect and has met the requirements from the original RFC.

Determining whether the released change has been effective and has achieved the desired results requires monitoring the change in the production environment. For a small change, this might be a matter of checking on the desired functionality. Larger changes might require monitoring of network and server information, performance data, event logs, and response times.

After the release of the change has been validated, the PIR can be performed. The results of the PIR should include:

  • A success/failure decision on the change implementation.
  • A review of how the change was released and whether it was implemented on time and on budget.
  • Documentation of the lessons learned from the change process.

The following table lists the activities involved in validating and reviewing the change. These include:

  • Validating the technical success or failure of the change.
  • Validating the business success or failure of the change.
  • Auditing the configuration database.
  • Communicating and recording the change.
  • Updating and closing the RFC.

Table 10. Activities and Considerations for Validating and Reviewing the Change

Activities Considerations
Validate the technical success or failure of the change Key questions:

·        Did the change meet the technical requirements? This may be verified in different ways based on the type of change. For example:

·        User testing

·        IT testing

·        Monitoring tools

·        Are all site deployments complete and stabilised?

·        Have all the project team members transferred out of the project?

·        Was the quiet period uneventful or were numerous incidents documented?

Input:

·        Data about the technical success of the change

Output:

·        Management review report

Best practices:

·        Incidents related to the change are a reactive indicator of the success of the change.

·        For workstation changes, a phone call or a walk around check-in after a change is made are proactive verifications.

Validate the business success or failure of the change Key questions:

·        Did the change meet the business requirements and objectives?

·        Are customers and users satisfied with the solution and its release?

·        Are customers and users happy with the results?

·        Have there been any unexpected side effects?

Inputs:

·        Feedback regarding technical aspects of the change

·        Feedback regarding business requirements aspects of the change

Output:

·        Validation of the change

Audit the configuration database Key questions:

·        How accurate is the data about the change that has been stored in the CMS?

·        Who updates the CMS, and what happens if the data is incorrect?

Input:

·        Information about the changed CIs

Output:

·        Accurate and updated information in the CMS

Communicate and record the change Key questions:

·        Has the team documented the results of the change, including the service type, completion date, and technology type in a data store that has query capability?

·        Has the team provided feedback (including issues and a summary of the PIR) about the change to the appropriate parties? For example:

·        CAB members

·        Customers and users who are affected

·        The change management and release management teams

·        IT management

·        IT staff

Input:

·        Information about the change

Output:

·        Communications about and a record of the change. This information feeds into the Operations Health Review

Update and close the RFC Key questions:

·        Has the RFC been updated to include feedback from the PIR?

·        Does the RFC accurately reflect the change just completed?

·        Have the results of the PIR been documented?

Input:

·        Updated information about the change

Output:

·        Closed RFC

Conclusion

The MOF Change and Configuration SMF describes the process for understanding and gaining control over the changes made in IT. CI and RFC data is collected and used in this process. Change requested are reviewed, approved, and implemented.

The major processes described by the SMF are:

  • Configure baseline.
  • Initiate changes.
  • Classify changes.
  • Approve and schedule changes.
  • Develop, test, release, validate, and review changes.
How can I implement ITIL IQ®?

Hopefully by now you’ll begin to understand the value that the Microsoft Operations Framework can bring to your business. The goals, outcomes and measures outlined above require many activities and considerations which form part of our day to day activities at First Solution. In fact, we’re experts in MOF and have even developed a unique ITIL IQ® process that benchmarks a business’s current state, identifies their desired state and provides an action plan (called a Service Delivery Plan) that helps organisations of all sises achieve their desired business outcomes. Most importantly, our unique ITIL IQ® process begins with a Proactive Services Maturity Review (PSMR) which identifies a score (out of 100) that clearly communicates the current state of your businesses IT operational maturity. Armed with your ITIL IQ® score, a non-IT professional such as a finance or procurement professional can concisely present to the IT Executive Officer the businesses current state, desired state, and ITIL IQ® score with an action plan to improve the ITIL IQ® score and thereby ensure that IT’s goals are aligned with the goals of the business and that both are progressing together. Once the IT Executive Officer has bought into the MOF concept we can help to develop an IT service strategy, IT service map, IT service portfolio and Service level agreements.

How can I manage governance, risk and compliance?

Simply get in touch to arrange a free ITIL IQ® survey and one of our MOF experts will conduct an interview with the IT Manager or IT Executive Officer within your business and provide an ITIL IQ® score with which you can measure the performance of your IT function. Once you know your ITIL IQ® score we can provide a Service Delivery Plan to help you improve it each month and measure and report progress back to you during a Monthly Service Review. And there we have it, an ITIL based solution to simply identify and measure the performance of your IT function. So, are you ready to manage governance, risk and compliance?

 

The Microsoft Operations Framework 4.0 is provided with permission from Microsoft Corporation. 

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.