I Love the Subject of Change Control

I love it not because it is wrapped in complexity, but for quite the opposite reason; it is (and should be) a perfect case of simplicity.

Let me explain why with a quick story of bad change control.

I watched an organization react to the pretty significant failure of a change by instituting a new step in their change control process.  “The CIO or VP of Operations must now approve all changes.”  You couldn’t make me laugh (and cry) at the naivety of such a move.  What value can a CIO or VP of Operations add to a change that would make it any less likely to fail? The answer is none, unless they are the one who designed or is implementing the change, or is somehow an intimate expert in the change, which for a large organization would be a gross misuse of their time.  The only thing that insertion of such a step would achieve is to demonstrate that you have no confidence in the people who work for you.  While that lack of confidence may be true, the action achieves absolutely nothing to improve the probability that changes will be better in the future.  Instead it breeds a culture of fear, a belief in inferiority in the staff which then slows velocity for new changes and services to a crawl, with no one in IT willing to take chances let alone do things that should be necessary.  The IT department grinds to a standstill, its customers become dissatisfied, and innovation and new products die on the vine.

Instead, what if every change failure was subject to a proper root-cause analysis (5 Whys).  What if that root cause analysis led to investment to correct the root cause (training, corrected documentation, better testing, patience to do things right, breaking a cycle of rushing, executing necessary maintenance, coordinating schedules changes, communicating changes to customers…)

Now you’ll have IT that corrects its mistakes by fixing the real cause, with support from management to do so.  Replacing a culture of distrust to one that employs Maslow’s higher order needs – growth and contribution, that can be painful when errors are made, but are personally (and collectively) rewarding when learned and executed on correctly.  

Psychology studies have shown that both punishment and encouragement can both create changes in behavior, but that one creates fear of taking chances, while the other tends to promote development.  Each has their place.  They should each be used appropriately to create the environment necessary.  But starting with punishment and distrust is not a good precedence.  Start with trust, and punish when that trust is repeatedly broken.

About Daniel Blander

Information Security consultant who has spent twenty plus years listening, discussing, designing, and creating solutions that fit the requirements presented. President, Techtonica, Inc.
This entry was posted in Uncategorized. Bookmark the permalink.