Change Management: What If it All Goes Wrong?

By on

The U.K.’s Swanwick Air Traffic Control center is an unfortunate example of the problems that can occur with the continuity of a business while undergoing a period of change.

The National Air Traffic service (NATS) switched the control center to the new base at Swanwick in January last year, but in April and twice in May the system went down, causing massive delays and cancelled flights across Europe and reducing public confidence in the service.

The problems were not all to do with the change in location and systems, but one that occurred on the May 17, 2002 was caused by a software upgrade. A spokesperson at the time said that the overnight upgrade went according to plan, but half of the workstations refused to work the following morning.

Although air traffic control is an extreme example of a business where information must be available and accessible on a second-by-second basis, it does demonstrate why business continuity (BC) planning should be right at the top of the agenda when undergoing any business change - be it a simple upgrade or perhaps a merger or acquisition.

All change, please

Business continuity is not a finite thing. Neither is it relegated to technology either, but instead needs to embrace the needs of the business at large. This process of keeping your people and information (whether intellectual property or IT related) connected is called information availability (IA), and forms a logical progression of the BC process, integrating as it does both parts of the business for success during both normal and crisis operations.

Keeping things connected is especially important every time changes occur within your organization. From staff and location changes to alterations to your IT network and configurations, IA means that your BC plan may also have to change to ensure it reflects the needs of the business further to such change. In addition, there has to be a heightened awareness of the possibility for problems to arise, which may result in a partial or complete invocation of your BC plans.

An example of this was an upgrade which occurred at a U.K. National Health Service Trust back in 2000. The particular NHS Trust in question ran the acute hospitals in its area, including a specialist children's hospital and an eye hospital. To provide an idea of the size of this large trust, it has over 2,100 beds and serves more than 190,000 inpatients and day cases and 600,000 outpatients per year. The IT team and their third-party support had planned an upgrade to a HP7000 server supporting a system which handles the processing of patient laboratory samples 24 hours a day 365 days per year. This includes critical data such as cervical smear tests. At any one time the system can have as many as 200 clinical staff accessing results. This was planned to occur with a limited amount of downtime, and precautions had been taken to ensure that this was possible.

However, during the process of the upgrade various problems occurred. As it became apparent that the problems could not be overcome during the planned shutdown period, the system was restored to its original version and the service returned to the users minus the required upgrade.

The IT security manager at the NHS Trust takes up the story: "The Trust was faced with a serious situation. We had a critical system, which could not stand further downtime but which urgently needed a lengthy upgrade to fix problems it already had. There was also no clear indication of how long the upgrade would take. Through our problem escalation procedure, we decided that although there was no actual loss of service the circumstances were such that SunGard Availability Services may be able to help under the terms of our disaster recovery (DR) contract."

The Trust had previously prepared for major problems through its disaster recovery plan (in this case with SunGard). The Trust invoked the service and SunGard provided a relief machine: a replacement HP7000 server was delivered. All users were transferred to the backup machine. A week later the IT team had successfully completed the upgrades on the client's machine and users were transferred back. The backup system was stood down.

Mergers and acquisitions

Equally, in the case of a merger or acquisition, IA and business continuity planning often end up on the back burner, despite the fact that business risk is often heightened at this time and the need to connect two entities as effectively as possible for operational and business benefit is paramount. Best practice would be to appoint a business continuity manager as soon as possible to ensure that threats to the business are reduced, and that a coherent BC plan is formulated for the combined organization. Many of the problems facing the BC manager will stem from cultural differences between the two companies; especially if both already have very different BC plans in place.

It can be difficult to gain management buy-in for BC planning at the best of times, but during hectic merger and acquisition activity, it is likely to be last on the list of priorities. Although the two companies pull together publicly to ensure a united front for customers, the 'back office' can find itself in disarray. It is therefore essential that the BC manager be brought in at the project planning stage, in order to reiterate the importance of BC and to ensure that resilience is built in to the merged business as it takes shape. A good business case can often be made for this approach, as the costs are likely to be lower than if BC planning is bolted on after completion of the merger.

A point worth considering at this stage is the involvement of a third-party consultant, who can bring a sense of objectivity to the party. After all, your approach and that of your counterpart employed by the other organization may differ. Providing the best plan for the combined organization should be the priority, not simply fighting your own corner. A consultant can review the existing plan or plans, and suggest the best approach without any previous baggage or allegiances to either side.

Often departmental heads are more aware of BC issues than managers higher up the food chain, and it is worth the BC manager taking time to recruit volunteers to fight the BC cause. They are often keen to help out in an environment where jobs are at risk, and those that go the extra mile are recognized for it. This approach also helps to break down barriers between the two companies, and demonstrates that the BC plan is for the common good.

Evolution not revolution

In conclusion, companies should consider fundamental changes, mergers or acquisitions as simply another phase in the evolution of an organization. A BC plan should evolve in the same way in order to reflect the changing needs of the business. If keeping people and information connected is important to your organization - whatever phase of evolution it is within - then these changes must become part of a dynamic IA strategy.

Ron Miller is senior consultant for SunGard Availability Services (www.sungard.com/availability).

Copyright © SC Magazine, US edition
Tags:

Most Read Articles

Log In

Username:
Password:
|  Forgot your password?