In a strong article by George Spafford on Datamation, entitled "The True Value of Change Management", many good thoughts around change mgmt are listed. 

 

Some of the points mentioned are:

 

When looking at the change mgmt process specific to your organization, it is true that you have to define a process that takes into account various categories of changes.  This classification should be based on priority and impact to the organization.  The following can help guide the decision for the proper change category:

 

 

There are many other factors that can be considered, of course, and ideally these should be placed in a matrix based on each category to help quickly determine what category an RFC (request for change) should be classified with.

 

Once the RFC is classified, it should flow through various levels of authorization, testing, release readiness review, implementation, and post implementation review.  I made the following graphic in an attempt to explain the nature of this process.

 

 

The idea behind this graphic is that once the change is categorized in the classification phase, it flows down the appropriate column for a major, significant, minor, or standard change. 

 

As you can see, standard changes flow through the process very quickly to production with minimal "pieces of the pie" required for a post implementation review.  They do not require any authorization or release readiness.  These are changes that are very low impact, often repeatable, and usually pre-approved.  However, they still need to be tracked as a "change" to a particular item in your environment. 

 

As you move to the left into the minor, significant, and major changes, more "pieces of the pie" are needed in order to authorize the RFC, give the GO / NO GO decision for release readiness, and review in the change in the post implementation review.  These "pie pieces" would be made up of various levels of IT Executive Committee, CAB members, Change Managers, Change Owners, etc.  More pieces are needed as the change category rises in impact.

 

In building your change process this way, it is flexible to account for various impact levels for changes, yet still follows a consistent pattern and approach.  Importantly, this same approach can be made for emergency changes.  You could take this same process flow and reduce the amount of personnel involved at each stage.  The CAB/EC (CAB Emergency Committee) would replace the CAB in most cases.  The Change Manager could have a greater authority to put changes through the system.  However, regardless of whether the change is emergency in nature or not, the same level of post implementation review should be made, as at that point, the emergency should be over.