Home    ITIL  Index

How To Handle Change Better Than The Rest

By Brian Hendry If change is the only constant, why are some organizations so bad at it?
Mar 20, 2005
By

ITSM Watch Staff





By Brian Hendry

Everyone knows that change exists but some organizations are reluctant to accept it as a standard part of the IT environment. They refuse to accept the need to formalize the way they handle Change Management.

A change to the IT infrastructure can be anything from upgrading a server to installing new software or adding a new desktop PC or email account for someone who has just joined the company. It can cover the whole spectrum from something relatively trivial through to an alteration which could bring down the entire system.

Changes happen every day in every organization. Many IT Departments just go out and implement them without formal accountability. If it is just a question of adding a new email account, a formal approach may not be necessary but if a new email or Web server is being replaced this could turn out to be a huge issue if the project goes wrong.

Change is an important integral part of the IT Service Management toolkit which ultimately ensures good quality service for customers. Change Management is closely linked to the Incident, Problem, and Configuration and Release modules.

Success and change go hand in hand. Change Management provides a pro-active and integrated approach to change control that minimizes business risks and promotes strategic planning.

So, why do so many organizations not bother with formal Change Management? Why is everyone not doing it? Our experiences reveal a substantial minority of organizations who are not carrying it out in a formal, structured and consistent way.

Small changes that can cost big bucks
Some private and public sector organizations conduct Change Management informally: a verbal or emailed request comes in from a member of staff or is referred by the IT Help Desk, and time for the change is scheduled. "Right," the decision is announced. "We'll swap over the email server at 7 o'clock this evening." There is nothing wrong with this approach if it works but if staff come in at 9 o'clock the following morning and cannot access their emails, that is serious.

The problem may have been caused by human error and not lack of a formal Change Management system but without a proper structure and documentation the problem can come as a total surprise to everyone because they were not notified in advance. Internal communications are an important part of Change Management. If you are a big business, where people buy from you on-line this can be catastrophic with losses of substantial sums of money. There could be similar embarrassments if you are an airline whose check-in system goes down. Small changes can cost big bucks.

Change Management, however, is much more than effective internal communications.
Change Management should include an impact assessment. IT managers should ask themselves; "If we implement this change what kind of effect is it likely to have on the computing infrastructure and the overall business? Is this our main email or Web server? If so, maybe 7 pm isn't the best time to do it. Perhaps we should do it at a weekend? What kind of testing do we need to make sure the procedure goes smoothly? What back-up plans ought we to have in place?" It can be a much more complex process than just sticking more memory in a server.

Releases of new software with bugs can have catastrophic impact - so too can changes which might seem at first glance to be trivial.
IT Managers may say they lose sleep over introducing changes but this discipline is more than just about expressing concern. It is about impact assessments, having back up, testing and contingency plans in place, and making sure the right people are aware of what is being done - and the implications.

Formal Change Management begins with the logging of a Request for Change from someone who believes an improvement is called for. Ideally what happens afterwards is that the request goes to the Change Management team which, after considering if the change is really necessary, categorizes and prioritizes it.

Depending on the scale of the alteration they will move to the next stage to set up the change itself or refer it to a Change Advisory Board (CAB) made up of interested parties such as the operations manager and business managers. The CAB will go through all changes requested that week or month and decide which to accept or reject, or seek more information. Changes authorized by the CAB or Change Management team are then forwarded to the team which carries out the work, first drawing up testing and back-up plans.

Eliminating the errors
The most common mistake in adopting formal Change Management is to make procedures too bureaucratic. Some documentation is essential but some organizations make things so complex that people just stop doing it. There does not have to be a plethora of sign-offs and authorizations; there should be a balance between having the right controls in place and getting strangled in red tape.

Another mistake is not appreciating that resources are needed to handle it. Good organizations tend to have a Change Manager or Change Management team who retain ownership through the whole cycle although they can have other roles as well. Some organizations operate effectively without a dedicated Change Manager but need to be more careful because the system is more fragmented and there is no single person or team keeping their eye on the big picture.

Some of the older established teams, like mainframe or server support, tend to be better at Change because they have been doing it for a long time. Newer teams, like those dealing with software or Web applications, are often less structured since they are working in a particularly fast moving environment. But Change Management is equally important for everyone.

Some industry sectors, like pharmaceuticals, are forced to adopt Change Management. Manufacturers have legal reasons to adopt it.

The IT Infrastructure Library (ITIL, internationally accepted guidelines for Best Practice in IT Service Management) gives useful guidelines. A good ITSM software solution can help by supporting the process and automating many of the processes and data flows.

Fighting the fear of change
People are usually fearful of change and reluctant to adopt it, particularly if they are being asked to write more reports, so they need to be persuaded of the benefits. IT managers need buy-in, to get people on their side. "Hearts and minds" must be won.

Change Management can embrace a large number of different items but they do not all need to be tackled simultaneously. Take a phased approach; if the Desktop team are keen to do it, start with them, then move on to the more reluctant sections who hopefully by then will have seen the benefits.

Do not forget the metrics. You can extract a great deal of useful management information from Change Management reports - for instance, how long people are taking to carry out changes. One of the disadvantages of not having formal Change Management is that staff could have been working all day to implement changes but no one knew because it was not documented.

You can also document areas causing the greatest problems. Why are you always swapping out that type of server? Maybe it does not suit the environment or is old. So why not just replace it and save everyone a lot of trouble?

At the end of the day you want change to happen without the end-user or other customer being aware of what has happened but appreciating the benefits. That should be an aim which never changes.

Brian Hendry is a senior consultant with Axios Systems (www.axiossystems.com), the leading global IT Service Management software and consultancy services organisation. He has over 15 years ITSM experience, having performed over 60 consultancy assignments (including health checks) for Axios Systems.

His previous experience was also in the ITSM health check field where he regularly performed ITSM and Help Desk process reviews of large multinational companies. He is trained to ITIL Service Manager standard.




Comments  (click to add your comment)

Comments

    Name or nickname

    Email address

    Website

    Write comment
    You have characters left. (Maximum characters: 1200).

     


    IT Management Daily Newsletter




    Most Popular