Every business needs to make changes but problems arise when there is no one in place to manage those changes...... our writer John A G Smith helps explain how important Change Management is:

Harry studied the paperwork for a few minutes and then looked up.

“You’re absolutely right,” he said, “the change is essential and urgent. I’ll give you access to the Live Library. You and your team go ahead and build the change. When you you’ve tested it I’ll give you the password and you can put it into live.”

I was stunned. He was right about the urgency but this was way out of line. Here I was, just a subcontractor, being given the keys to the kingdom.

“What about Change Management?” I asked. “And doesn’t it have to go through the Change Advisory Board? Doesn’t anyone have to sign it off?”

“Nah.” He leaned back in his chair, legs straight and thrust his hands deep in his pockets. “The problem here is that our systems are too dynamic. We’ve got so many urgent changes going on that any sort of Change Management system will just get in the way. It would slow the whole thing up and be too much of a drag on everything.”

“What about security? You realise that with this system I could divert payments to anywhere?”

“I’ll split it with you,” he laughed.

“But …” I started to protest but he was not to be swayed. So we worked late and in the early hours of the next morning the fixes were implemented and the next day a happy user was once more generating profit for the company.

The Fix - Mark II

It was two or three days later that Harry stormed into the undersized cupboard they called my office.

“I thought you had fixed the Payment Allocation System …” he snarled at me.

“I did. Ask the user. He was pleased with it.”

“Well he’s not pleased now. He reckons that it’s gone wrong again and doing exactly what it was doing before.”

Over the course of the next few minutes I downloaded the live code and quickly scanned it and found, to my surprise, no evidence of the new and changed lines of code we’d installed a few days earlier. I called Harry.

“Somehow or another the change we made the other day to the Payment Allocation System has been backed out. Any ideas?” He hadn’t.

The only thing we could think of was that ‘the Systems’ Guys’ had done some sort of restore and rolled back to an earlier version. I checked the library used for storing version of live code and that, too, contained a version that did not have our altered code. So, with all options exhausted, I got Harry to approve a new change, reinstalled the version we had created earlier and uploaded it to the library.

Happy user. Happy Harry. But I was decidedly uncomfortable … and I was right to be.

.... Mark III

The phone call started with a barrage of bad language and went downhill from there. The Director of Finance wanted to know on what authority I, a lowly contractor, had backed out his essential change. His change had been ‘essential’, ‘endangered the security of the organisation’s finance’ and more. Thank goodness I had Harry’s signature to authorise the change. It transpired that his team had discovered a massive security hole and used the ‘accepted practice’ of just making the change, testing until they were happy and then implementing. The problem was they had kept a copy of an earlier version and, assuming this was still the current version, made their change to that. As soon as they uploaded it – and sent a copy to the Live Library – they had backed out our change.

When we reverted to our version we then backed out their version. No wonder they were unhappy. They believed it was their system and they had every right to make the change. But Harry assured me it was his system and that they had no such rights.

The answer, Change Management

The affair had multiple spinoffs with high level meetings and numerous workshops. They all led to the conclusion that a Change Management System was essential and urgently required. My role, supporting a minor financial subsystem, was suddenly broadened to include setting up and implementing a Configuration Management Database (CMDB) and then build a whole Change Management function from it.

Fortunately I had ITIL to fall back on and the ITIL books became a permanent part of my deskscape.

The implementation of ITIL was not straightforward. Many resisted, using the old arguments about restricting the change process and getting in the way of a dynamic business but as people were taken through the process, many attending ITIL Foundation or Awareness courses, they came on board.; A huge hurdle to overcome was that different areas of the business demanded their own Change Manager, arguing that ‘nobody else will be able to understand our unique requirements.’ But they were eventually persuaded when they discovered that systems that bridged business areas were either covered by both Change Managers or, worse, covered by neither.

Far from inhibiting and restricting urgent changes we discovered the new system made all changes slicker, more controlled and properly impact assessed. The average cost of making a ‘standard’ change was reduced by 20% and the cost of urgent changes fell by nearly 40%. There were far fewer failed or backed out changes.

But there was one more knock on. Once Change Management, support by a comprehensive DMDB, was fully functioning, the business then discovered that the other support processes: Service Desk, Incident Management and Problem Management, fell out naturally as a result … with vast savings on other areas of the business.

Win … win … win.

Win at change by learning the management principles and how to put them into practice with our accredited Change Management Practitioner course.

The APMG-International Change Management and Swirl Device logo is a trade mark of The APM Group Limited.