MOF Action Plan - Standard Changes
Author: Microsoft Corporation

MOF ACTION PLAN: Standard Changes

Situation
We need a way to increase agility without increasing risks.
Action Plan
Use standard changes where possible to fast track common changes with standard procedures and streamlined approvals. Standard changes help your organization reduce the amount of overhead required to process and authorize well-known, well-tested changes. Reducing overhead increases agility (the ability to respond quickly to a changing environment). Examples of standard changes include desktop refresh and standard software deployment .
To deliver reliable and effective services, organizations need to ensure that change is planned and purposeful, and that they follow change management processes that balance the need for prompt action with the need for reliable services that are in compliance with policies and regulations. Standard changes reduce risk because they have a set process for implementation that has been proven to be successful, and they have minimal business risk from implementation.

Defining Standard Changes

Putting Standard Changes into Practice

Identify standard changes.
Define criteria, approvals, and process, and then thoroughly test.
Test the request against the criteria and get approval.
Follow the process carefully.
Record the change.
Periodically evaluate.

Identify Standard Changes

A standard change is less risky because it has gone through the same process a number of times. Only a change that has been thoroughly tested, deployed, and validated, with execution steps that have been well documented, can become standard.
When looking for standard change candidates, review changes that are frequently requested, have a well-understood process, and are relatively low risk if done incorrectly (errors can be easily caught and reversed). These standard change candidates should also be worth the overhead of making into standard changes—they happen frequently enough to be worth the overhead, and the process does not include a lot of decision and collaboration points that would be more easily handled with a normal change management process.

Define and Test

For each standard change, clearly define:
How you know this is a standard change. Also identify what seems similar but should NOT be treated as a standard change (and how to tell the difference).
When this standard change can and cannot be used.
Authorization process for the standard change. Can it be authorized by the customer service representative who receives the request? Or does it need an approval from someone more senior? Remember, if the approval process is too complex, using your normal change management process may be a better choice.
Once approved, what is the process to be followed to implement the standard change? Make the effort to ensure this is as clear as possible. This standard process will be what reduces the risk in implementing standard changes and, if it is not easy to follow, your risk will be increased. Automate wherever possible to reduce risk. The more automation (and fewer manual steps) that can be built into a standard change, the better it is at reducing risk. Automated processes also save time, effort, and money.

1 www.microsoft.com/MOF

Define and Test (Continued)

Thoroughly test the criteria for determining if a request is a standard change and the process for making the change itself. Test in real-life after testing in the lab. Work out all of the bugs before launching this standard change.
Keep in mind that even a standard change needs to follow your change management processes in terms of testing, implementing into production, and recording changes.

Putting Standard Changes into Practice

The criteria for determining if a request is a standard change will be used by customer service representatives for new service requests to decide if the request meets the criteria and to obtain appropriate approval.
Follow the Process
Once you’ve received an approved standard change request, follow the process as written. Remember that any deviations from that process have NOT been tested. On occasion you may find that this request is not a standard change after all. That’s not a problem; just treat it as a normal change request in that case.
Record the Change
Any change to production must be recorded. Standard changes are no exception. The process for recording the change appropriately should be part of the process. Logging all changes is key for compliance.
Evaluate the Standard Changes
Periodic evaluation of your standard changes is key to managing risk. Consider the following in your evaluation:

Was this set of changes truly low risk?
Were there any unanticipated impacts from the changes?
Were there any incidents that may have been the result of a standard change?
Was the process followed without modifications? Does the process need adjustment or clarification?
Did classifying these changes as standard changes save time or resources?

Are there other common change requests that should become standard changes for your organization?

Learn More

This real-life IT solution was brought to you by Microsoft Operations Framework (MOF) 4.0.
To learn more about the free, practical guidance provided by MOF 4.0, visit www.microsoft.com/MOF.
Download related content:
MOF 4.0: http://technet.microsoft.com/en-us/library/cc506049.aspx
Change and Configuration SMF: http://technet.microsoft.com/en-us/library/cc543211.aspx
Using Standard Changes to Improve Provisioning: A MOF Companion Guide: http://go.microsoft.com/fwlink/?LinkId=193084

Microsoft Solution Accelerators

Microsoft Operations Framework and the related content listed above are all offerings from Solution Accelerators.
Solution Accelerators are authoritative resources that help IT pros plan, deliver, operate, and manage IT systems that address real-world scenarios. Solution Accelerators provide free, prescriptive guidance and automation to accelerate cross-product integration, core infrastructure development, and other enhancements.
www.microsoft.com/solutionaccelerators

www.microsoft.com/MOF 2