part0011

Change Management:

The organisation, planning, scheduling and implementation of IT changes that make alterations to existing technology systems or introduce new systems and components into operation.

This chapter will help you by:

• grouping change activities into an easy-to-remember 5 step model

• providing a list of best practice hints and tips for planning and implementing IT change

Perhaps that should be: The more things change, the more they are likely to break.

Through bitter experience we all know things tend to work smoothly when we leave them alone and they’re more likely to break when we start changing something.

In the world of IT, it’s not uncommon to hear of service availability or quality issues arising on the back of change implementation. Why do seasoned IT people still manage to cause problems when implementing changes?

Probably because we learn lessons as individuals but don’t always think to share them with others. Indeed, there are those who are reluctant to share because they believe knowledge is power. This is where an experienced IT Manager or Change Manager can make a difference by collecting all those lessons and making them available to every member of the IT department.

This chapter sets out some best practice hints and tips using the easy to remember ALTER model shown in the table below. This model will help you improve how you implement changes to your technology systems – be they major upgrades or regular business-as-usual updates, infrastructure changes or application changes.

Throughout our lives we learn by attempting things and discovering what works and what doesn’t. Two major points underpin this approach:

For IT professionals, that means testing in non-production systems and making sure we don’t repeat previous mistakes when implementing in the live environment. When you go live with a release or a new piece of infrastructure you want to be sure that it will work without causing any service degradation for your user community. But how much testing should you do? Some live incidents arise out of the most obscure circumstances. Situations that one might never have considered when drawing up the test plan.

It may not be possible to test everything. It may be that some tests fail and you can’t get the ﬁx ready before the project live date. The important thing is to give an honest appraisal of the situation when brieﬁng management. Sugar coating the position by glossing over any unresolved issues will always come back to catch you out, so it’s best not to do it.

The IT management team must work with stakeholders in business areas to make risk-based decisions on what can and cannot be promoted into production. That means presenting a clear assessment of the level of risk the change carries. For example - there should be no high impact test issues left unresolved, though it might be reasonable to accept the risk of going forward with some medium or lower impact items outstanding.

As well as being sure about the hardware or software you are implementing, you should also make sure the implementation task plan is sound. That might not be as easy to test, particularly for larger scale changes, and you may have to rely more heavily on past experience.

It is acceptable to make some assumptions along the way as long as you document what they are. The more assumptions you can remove prior to implementation time, the more conﬁdence you will give the people around you.

As you approach the implementation date, a fully documented plan with clear roles and responsibilities will remove any misunderstandings between participants and ﬂush out any false assumptions about task interdependencies.

Obvious and simple, you will say. But how much detail do you include in your plans? How well are the steps documented? In the event of an unexpected illness, could someone step in at the last minute and execute the change? Or is its success dependent on a speciﬁc individual?

Documentation isn’t always the most enjoyable thing for IT technicians to spend time on, so it often drops down the task list at the expense of more interesting, hands-on, technical activities. Documenting the change is most likely to be overlooked when it is going to be undertaken by one individual – ‘I know what I’ve got to do, why do I have to waste time writing it down?’

Reversion of the change also tends to get scant coverage, especially in smaller, routine and lower risk changes. How many times do you see the words ‘back out the change’ in the reversion section of Change Records? Unfortunately, far too often. Yet the reversion could be more complicated than the actual installation itself, particularly where databases are being upgraded.

In larger changes there may be a team of people carrying out the installation work. This requires a lot more thought about how the activities will be managed – who will take a lead role in making sure everyone follows the plan. How will communication work if people are in separate locations? Consider how will you keep senior management and business stakeholders informed of progress and how decisions will be taken when something goes wrong.

And how will you know that the change has been successful? Agreeing a set of test conditions up front means that you can schedule involvement from non-IT personnel to validate everything is working before opening the system up for general use again.

Timings in your plan are essential. You have a live service that must be brought up intact before the end of your agreed change window.

If you have carried out similar changes in the past you will have a good idea of how long it is going to take. But what if something goes wrong? How much contingency time should you allow for troubleshooting during the change window? And have you left sufﬁcient time to back out your change if the worst comes to the worst?

That prompts the question whether you actually know with certainty how long the back out will take. If you have simply written ‘back out the change’ as your reversion plan then it is unlikely you will have a good estimate for how long will be needed.

For longer duration changes, identify speciﬁc milestone points that are evenly spread throughout the plan and can be used to help you track progress.

Execution is all about sticking to your plan. If something goes wrong, your decision making should follow the responsibilities previously agreed in the implementation plan. Unilateral actions should not be tolerated. If you have done a good job of deﬁning clear roles, responsibilities, and communication protocols then it is reasonable to expect all personnel to respect that.

When things are going to plan, managing a change can be very straight forward. Like most things in life, good management and coordination is needed when things go wrong. In problem situations, decisions should be taken by involving the appropriate level of management. Where necessary, this should include a management escalation call.

As with major incidents, keeping a log of events during longer running and more complex changes can serve many purposes. It is particularly helpful to record timings as this will lead to more accurate time estimation in future changes.

I recommend you get into the habit of reviewing all changes. The successful and alarm-free implementations often yield as many learning points as the disaster-ridden changes. After all, it is a lot more rewarding to reﬂect on things that have worked well.

Even the small, routine changes deserve some reﬂection. The more that minor issues can be ironed out, the more conﬁdent everyone will be when it comes to signing approval for those business as usual changes.

In chapter 3 we talk about reviewing change in more detail, with particular focus on those that failed or were problematic.

As mentioned earlier, documentation often gets set to one side because technicians think it is burdening them with more admin. You might get away with a minimalist approach but that will vary depending on what industry you’re operating in. Heavily regulated sectors (ﬁnance being a prime example) will demand strong evidence of planning, testing, and documentation in change records.

The level of documentation should be commensurate with the scale, complexity, and risk of the change being undertaken. That said, it is strongly recommended that smaller changes be subjected to similar rigour. Low risk changes will cause damage to service availability if carried out with undue care and attention.