IT Audit (8) IT Operations (29) IT Security (11)

Standard Changes

Essentially, Change Management is a risk management exercise.  In Visible Ops we stress the importance of the Change Management process in “Stabilize the Patient” and reinforce that repeatedly through the book.  Unfortunately, many groups fight with misconceptions about what Change Management involves and create an overly bureaucratic process that eventually collapses.  Change Management needs to take the impacts of changes to the business into account and then use reasonable measures to reduce the risks associated with changes.

 

Using Vilfredo Pareto’s observations of inequality, we can expect a relatively small percent of changes to cause the largest amount of problems.  As a result, those few, the 20% or so, are the ones that should be scrutinized by the CAB and have more rigor involved.  We do not want to burden the CAB with all changes needlessly.

 

Some changes happen over and over with a known outcome and relatively little risk to the business.  These are known as “Standard Changes”.  They get reviewed by the CAB once and once deemed safe and appropriate, become classified as Standard Changes and are essentially pre-approved for building and implementation moving forward.  This does not mean that they disappear from view!  They must still be recorded so people can always determine what Changed when viewing a CI during Incident or problem management.  Examples include installing a PC and changing a password.

 

Because Standard Changes flow through in a pre-approved manner, they do not burden the CAB and reduce burdens on the process.  If a Standard Change does begin to cause Incidents or there are concerns for whatever reason, then the Change Manager can elect to revoke the Standard Change designation and require additional scrutiny.

 

Again, Standard Changes do not disappear from view.  We must always know what has changed to a given CI.  Standard Changes present us an opportunity to improve the efficiency of Change Management while still being able to track and account for all changes.

Published Sunday, April 30, 2006 3:46 PM by George Spafford
Filed Under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: Standard Changes

We have recently implemented a Pre-Approved Change process and use a couple of controls to prevent the change management organization from loosing sight of them. First, Pre-Approved Change must be "re-approved annually, to keep focus on the activity. Many factors can change in the environment during a year (people, process, tool) so annual evaluation makes sense. Second, the Pre-Approved Change is revoked if an incident is logged during execution of the Pre-Approved Change; if fact for the Pre-Approved Change to be approved initially, there must be no problem associated with execution in the past year.

These simple controls, along with others, allow us a much better understanding of risk in the environment relative to Pre-Approved Change
Wednesday, May 03, 2006 6:50 AM by RCC in CM

# re: Standard Changes

That's a great approach RCC.  I like the idea of annual reaccreditation - that makes a lot of sense.

--George
Wednesday, May 03, 2006 7:59 AM by George Spafford

# re: Standard Changes

This is a valuable nugget as we try to maintain the critical balance between getting work done and having enough control to do good work.
Friday, May 05, 2006 11:41 AM by Jay Richmond

# re: Standard Changes

George, I manage change management for Symantec and we have broken up Standard Changes into "Additional Authorization" and "Blanket Authorization".  The Additional Authorization requires that the person requesting the change has their manager sign off.  Are you aware of others that break down their standard changes this way and do you see any issues with doing it this way?
Friday, August 11, 2006 10:08 AM by Craig H Gray

# re: Standard Changes

Hello Craig,

Standard changes are really just another change model wherein you've found from past experience that the risks are low and review is not needed.  If you've seemingly split it into two paths - one that needs authorization and one that does not, then you've simply created a new change model for relatively low risk changes.  Change management is all about reducing risks to an acceptable level.

You can have n number of change models but want to limit them to a number that is meaningful and manageable.  Too few and you are very rigid and lose agility.  Conversely, if you have too many then you risk confusion over which model to use when and that ambiguity creates risks.

I don't see anything wrong with what you've done - it really is just a matter of naming.  For changes that go through without the additional signature, I'd call those "standard changes" and come up with a name of the model that requires the authorization of the manager.

Does that help?
Friday, August 11, 2006 1:36 PM by George Spafford

What do you think?

(required) 
required 
(required)