Vilfredo Federico Damaso Pareto (July 15, 1848 – August 19, 1923)

In October of 2008, I was invited to speak at the Data Center Decisions conference in Chicago. My topic for the session was “ITIL v3 – What’s New, What’s Changed”. Pretty exciting stuff, huh?

I drew a crowd of about 30 attendees to my session and spoke for an hour on what interesting things were abreast with the recently released ITIL version 3 books. To put this in context, the attendees of Data Center Decisions are all big corporate IT Operations managers that, for most part, manage data centers with mainframes. No one in the audience was new to ITIL, and in fact many of them had been performing the ITIL processes since ITIL started gaining popularity back in the 90’s.

After my presentation was over, I took a few questions, many of them focusing on the efficiency (or lack thereof) of the Change Management process, and what improvements ITIL v3 introduced to that process. Sadly, I had to inform them that the differences between ITIL v2’s Change Management process and ITIL v3’s Change Management process were minimal to non-existent.

To try and see where the underlying questions about Change Management were coming from, I decided to ask the audience a few questions. I first asked the audience members to raise their hand if their organization had a formal Change Management process in place. Every hand in the room went up (this wasn’t surprising considering that the audience was made up of mainframers). I then asked if any of them enjoyed the process of submitting and getting approvals for Changes. Every hand in the room dropped. Well, to be honest, “enjoy” was probably a loaded term, so I rephrased the question to ask who thought their Change Management process was efficient in approving changes. Two or three hands went up.

Well that explained everything!

The goal of Change Management is to ensure that standardized methods and procedures are used for the efficient and prompt handling of all changes, to minimize the impact of Change-related Incidents, and improve day-to-day operations.

I must admit that I find most of ITIL’s process goal statements a bit lame, but Change Management’s goal statement is pure gold!

• Standardized methods and procedures
• Efficient and prompt handling of all changes
• Minimize impact
• Improve operations

The fact that so few people in the room thought that their Change Management process was able to efficiently handle Changes indicated that their processes were completely failing the goal of Change Management.

I then asked how many people in the room had a solid list of Standard Changes. The same 2 or 3 hands went up.

The room we were in didn’t have anyone scheduled for the next session, so I took 30 minutes to discuss Change Categorization.

Change Categorization

There are three categorizes of Change: Standard, Normal, and Major (we’ll talk about Emergency Changes some other time). The Normal Change can be further broken down into two subcategories: Minor and Significant.

For purposes of clarity, I will not use the term Normal Change, since Normal Changes can be better identified as either a Minor Change or a Significant Change. This gives us four categories of Change:

• Standard
• Minor
• Significant
• Major

Each category of Change has associated with it a different level of risk, and each category has an increased level of complexity for approval.

Standard Changes

Let’s start with Standard Changes. Standard Changes are pre-approved. The steps to execute a Standard Change are well understood and probably have been executed a hundred times previously. You are filling out the paperwork to submit a Standard Change for two reasons. 1) If things go badly the next day, someone will need to look up a record of what changes were made. 2) Upon successful implementation of the Change, the Configuration Management Database Librarian (you do have a CMDB Librarian in your organization, don’t you?) will use the completed Change record to update the CMDB.

Minor and Significant Changes

Both Minor and Significant Changes require approval. The difference is that the Change Manager, in reviewing all the submitted Changes, may opt to approve/reject some of them in advance of the Change Advisory Board (CAB) meeting. The Changes that the Change Manager approves or rejects are, by definition, Minor Changes. The Changes that the Change Manager defers for review by the CAB are Significant Changes. So to review:

• Minor Changes are Changes submitted for review and then either approved or rejected by a single person: the Change Manager.
• Significant Changes are Changes submitted for review that are forwarded to the CAB for evaluation and approval/rejection.

Major Changes

Major Changes are Changes that could affect the viability of the organization’s continuity. In plain speech, a Major Change that goes wrong could be the end of the company (or at the very least, require the company to invoke its Disaster Recovery Plan).

Example: You are planning on upgrading your mainframe from OS/390 to z/OS. Also, it turns out that all your point-of-sale terminals are just dumb terminals hanging off your mainframe. If that Change goes badly, don’t even bother opening the doors the next day. Game over.

Major Changes are Changes that the CAB defers up to the business’ governance board. Typically, Board/CxO level leaders must sign-off on Major Changes.

The Pareto Principle

So now that we understand the Change Categories, let’s talk about Pareto. I am always surprised at how many people use the Pareto Principle without realizing where it came from. Vilfredo Federico Damaso Pareto was an early 20^th-century economist who discovered an inequality in wealth distribution amongst Italian land owners. He  found out that 80% of all the land was owned by 20% of the population.

The Pareto Principle has since transformed into the 80/20 rule. The 80/20 rule roughly states that 80% of your results can be achieved by focusing on a 20% subset of work.

The Pareto Principle as it applies to Change Management is that 80% of your Changes should be Standard Changes. Of the remaining 20% of Changes, 80% of them should be Minor Changes. The ones left over should be Significant Changes, with a Major Change thrown in once in a blue moon just to keep things interesting.

Let’s do the math. We will take 100 submitted Changes and see how the numbers break down:

• 100 Changes Submitted
• 80% (80) of those Changes are Standard Changes (pre-approved, no authorization required)
• Of the Remaining 20 Changes, 80% of them (16) are Minor Changes (the Change Manager approves without further review required)
• The remaining 4 Changes will need to be reviewed by the full CAB in their weekly meeting

Out of 100 Changes, 4 of them hit the CAB. This is what I call an efficient method for handling Changes.

More information about the Pareto Principle.