5-50-500-5000

I mostly hear complaints about Change Management.  Too much paperwork, too many meetings and the process slows everything down.  All true, and if the Sarbanes-Oxley legislation didn't exist, I believe most IT departments would have abandoned the process years ago.  And that would have been an absolute shame.

A decent Change Management process is trying to tell you how risky the change you're making is in terms of the impact to the business if things go wrong.  It's also trying to match the level of testing, backout planning, etc. to mitigate that risk.  And the underlying cause in many instances is that we've designed our technology solutions as "big bang" implementations.  Have you noticed how big Internet and mobile device companies implement their changes?  They typically have a beta program which engages risk-tolerant people first.  When a few cycles of this passes and the known bugs are worked out, they begin a slow trickle of upgrades, ready to halt the process at a moments notice.  When all is good for a decent chunk of their users, they upgrade the remainder in short order.  They've avoided the "big bang" approach, shortened their cycle times and not upset their customer or their business.  

Sure, you say, they have advantages internal IT shops don't have, and in some cases that's true.  But in many other cases we do, and just haven't.  Which brings me to the title of this blog, 5-50-500-5000.

Years ago our email system, Lotus Notes, became an increasingly important service.  New software releases came out frequently and offered compelling new features and performance gains, and we wanted to deploy them as quickly as possible.  But with 5000 email users on a single system and everyday business counting on it, any major change was a very high risk.  A test system was of little help, since a few technical people could not adequately test everything, primarily because 5000 users do a lot of different things.  Our solution was to break up the email system into four partitions, while still making it appear as a single email system.  The first partition held about 5 users, just members of the core technical staff.  The second held about 50 users, a mixture of IT and risk-tolerant users.  The 500 system was a broad, representative set from across the entire organization.  The remainder fit into the 5000 set.  

The risk, to the business, of upgrading either the 5, 50 or 500 groups was very tolerable.  When it came time to upgrade the 5000 group, we had reasonable assurance that things would go smoothly, again, with respect to the entire business.  These Change Management meetings typically went smooth and short, which they should when the risk was largely mitigated by the facts at hand.  The real victory were users that experienced few problems and enjoyed new email features.

Listen, learn and adapt your IT services to what your processes are telling you.  Your customers, and yourself, will benefit from the results.