I was in a meeting the other day and someone mentioned that each attendee had a different idea of what constituted a Standard Change. Josh had his idea of a Standard Change, Doug had his idea of a Standard Change, Corey had his idea of a Standard Change, and of course I (Mr. ITILtopia) had my idea of a Standard Change.

Let me tell you right now, my idea is the only correct one.

I say that partially tongue-in-cheek because ITIL is adapt and adopt. There is no one true ITIL.

That being said, this is my blog, and I’m going to tell you the right way to think of a Standard Change.

A Standard Change is a form with a drop down box, a time/date box, a pick list field, and three radio buttons.

The submission of a Standard Change should be as simple as filling out the first three fields and hitting submit. Resolving the Change consists of picking one of the radio button options and saving the form. There shouldn’t be lengthy, multi-part electronic forms to fill out. There should be no approval process. All of the scheduling/approval/notifications for Standard Changes should be templated and automated.

Submitting the Change

The first field on the Standard Change form is the drop down box. This drop down box will contain a list of all the available Standard Changes. Period. If it isn’t on the list, then it isn’t a Standard Change. You then enter the date/time of when the Change will take place, and pick the person who will be performing the Change from the pick list.

When you fill out those three fields on a Standard Change form and submit it, the system should fill out virtually every other aspect of the Change on your behalf, including:

• Affected Services/Systems
• Risk
• Impact
• Urgency
• Priority
• Roll-back procedure
• Test plans
• Implementation procedures
• Change duration/end date
• Notification distribution lists
• Notification content

In a perfect world, the act of submitting the Standard Change form would initiate all required communications, fill in the Forward Schedule of Change, update the CMDB with the affected CIs, determine outages for downstream Services, etc., etc.

Closing the Change

After the Change is complete, open the form and select from one of three radio buttons:

• Successful
• Successful with Issues
• Unsuccessful

Of course, you might want to add some notes to the Change form if it was Successful with Issues or Unsuccessful.

But that is how easy a Standard Change should be to submit and complete.

The hard part is setting up the template and automations for a Standard Change. You have to ensure that the submission executes all of the unique automations and notifications for every Standard Change listed in the drop down box. This aspect requires the most thought, so don’t be surprised if you miss something the first time you execute a Standard Change (oops, forgot to notify the Service Desk). Just make sure that you iteratively improve the Change every time you execute it.

The fact that you can template a Change to such a high degree of accuracy and precision is what defines it as a Standard Change.

If you find that you can’t easily determine the Risk, or you can’t know ahead of time how long the Change will take to implement, then it probably isn’t a good candidate for a Standard Change.

As your organization’s Change Management process matures, you should start to measure the ratio of Standard to non-Standard Changes with the hope of achieving that magical 80/20 rule, with 80% of all your changes being Standard Changes. Once it does mature, the Change Management process will go from being a burdensome overhead to a few keystrokes with advantages that will be obvious to everyone.