Change for change's sake blights the IT sector more than most. The business mantra "change or perish", however glib, has gained great currency of late. The logic is that if you're not constantly shifting the goalposts for your workforce this will somehow make you uncompetitive.
In practice, changes to working life are counter-productive, in the short term at least. And many organisations fail to handle the change well enough to make it profitable in the long term either, even those with formal change programmes. A recent survey by consultancy AT Kearney of 294 European firms with change programmes revealed that only 20% were successful.
Two main problems need to be addressed. First, the psychological effect of change on the workforce, imposed through mergers, acquisitions or downsizing. It is also a major issue when firms relocate or simply re-engineer the way they operate. In the most extreme cases the effect on staff can be compared to bereavement, the recovery from which follows a similar pattern.
The second major cause of lost productivity -- and one with enormous relevance to many companies going through a major upgrade -- is the organisational challenge involved whenever staff are asked to work in different ways. Asking them to use new tools, be they applications or operating systems, or to follow new procedures involves a lot of hand-holding.
In imposing change, no department has the potential to invoke as much hostility as IT. A common complaint from IT managers is that they are constantly fire-fighting, but what many end-users don't understand is why they constantly seem to be changing the IT systems. Small wonder that many dig in and refuse to co-operate. "Some people will be convinced that there is no need for change, while others may fear it," says Professor John Kotter, a management expert at Harvard University. "Resistance can come at all levels. Even those who initially support it may change their minds if there is no sign of success."
A roll-out of new technology, then, is less an upgrade than a highly sensitive operation in office politics. If such a project were undertaken in real politics, it would be accompanied by a publicity machine praising the benefits of the new scheme. It is understandable if company IT departments don't employ public relations techniques but they could do much to win over the workforce by communicating better.
"If you don't communicate the changes that's a great way of generating hundreds of calls to the helpdesk and making an enemy of the IT department," says Nick London, manager of Getronics' managed services division. "In fact, you should be over-communicating if anything." However, communication won't compensate for a poorly managed upgrade.
Many firms are embarking on the migration to Windows 2000, the first service pack just released by Microsoft. This is the catalyst that has made many of the customers of systems integrator Deverill make the change. Tony Ford, UK general manager at Deverill, says you should have spent at least as much time preparing for the change as it will take to implement it. "So many change management handovers go wrong because the migration team didn't allow enough time to plan the process," says Ford. In some cases, he advises, you shouldn't be surprised if you spend two or three times as long auditing and planning and getting the details right.
Since it is the helpdesk that inevitably bears the brunt of all the reaction to a systems change, it is understandable that the majority of change management systems have grown out of helpdesk systems.
One of the most popular systems was originally designed to help keep track of the inventory of software and hardware across the company, so that when end-users called, the helpdesk operator already knew their history. This kind of database about the company's human and technical assets can become a powerful management tool on which successful technology roll-outs could hinge.
There are more reactive systems, using inventory tools to collate information about changes, to take requests for changes and assign a task to the hardware support team. Publishing FAQs on an intranet may reduce the number of calls to the helpdesk and increase the knowledge base.
On Technology, for example, seems to be suited to managing the transition of multiple desktops. As end-users are migrated to Windows 2000, there are three main ways of updating each PC. Few people are still employing the method of sending a support engineer to each desk, shooing the user off the system, then unloading and reloading software. The standard way of doing things now is by the Snapshot method, which gives everyone in the whole company the same applications and configuration. This is managed from a single point, a management console from which configurations are sent out to all the relevant points on the network.
A much more productive method, says Rob Drew, country manager for On Technology, is to do a native installation for each user. It's ludicrous that everyone gets the same IT when clearly their needs are different, however easier that is for the IT department. "You can do native installations and tailor them from your management console, without having to visit each desk or run the upgrade overnight," says Drew. "We can even rebuild an entire machine remotely."
Even the rebooting of machines can be carried out remotely. Boot agents such as PXE from Intel, NBA form 3Com and WOL (Wakeup on Lan) are all supported by On Command, On Technology's management package. In practice this means that Deutsche Bank's PCs at its London, New York and Hong Kong offices are managed form a single console in Colchester.
Before the implementation of IT systems changes, a software change management system provides an up-to-date status report of all change projects. IT operations personnel can look into the system to see what changes are imminent and plan accordingly. The system will tell them what changes are pending, who is assigned to the project and whether packages are in development, test or pending production implementation.
Software change management solutions also control the change implementation process. They can be set to prevent changes during critical periods, such as the end or beginning of fiscal periods. They can also limit changes to hours during which support would be available, say from 8am to 3pm on business days.
The real application of change management tools will come when application service provision is more widely adopted. With the purchase of applications being turned into a commodity, it is likely that the IT set-up of users is likely to change constantly -- especially since competition will drive down prices and rental agreements will be constantly reviewed by users. Service providers will need to be able to uninstall and install systems remotely with great regularity.
Change management is ultimately a human issue that overshadows the technical considerations. Firms are taking more notice of this problem as the pace of change accelerates. One IT company, Logical, has even appointed a director of change management.
The psychology of change
When two companies merge and the systems of one are imposed on the other it's not unreasonable if the users revolt, especially when you consider the psychology involved.
The transition employees go through when finding themselves in an environment that has been imposed on them is similar to the process of bereavement, says Dr Robina Chatham, lecturer at the Cranfield School of Management. Shock is followed by denial, when people refuse to let go of their old conditions. After that they slip into depression. In any of these low emotional states they will be unable, and unwilling, to take on board new ideas.
"Explaining new systems to them would be pointless," says Chatham. "It's all very well telling people to change, but they have to be in the right emotional state to be able to act effectively. It's no good putting someone on a training course when they're in denial because they'll be closed to new ideas."
The point is that training is a vital part of implementing IT upgrades and changes. The time and money you spend on training will be ineffective if your users are not in the right frame of mind to accept it. Different character types respond differently to change. There are two main types, characterised as 'sensors' and 'intuitives'. Sensors like stability and security, they think sequentially, have great attention to detail and need a strong sense of where they are. Accountants, for example, fall into this category, so before sending them on a training course you may want to try another department whose staff may adapt quicker, such as the intuitives who make up the marketing department.
"The psychology of change isn't given enough thought in many companies but these days, when change is heaped upon change, we can be driving our employees into clinical depression," says Chatham.
How to avoid getting millions of helpdesk calls
- Don't do a big bang -- implement changes department by department
- Make sure you train your help desk staff first
- Communicate. Tell people what you're going to do, tell them when you're doing it, and tell them how great it is that you've done it
- Hold daily meetings with the migration team and project managers to make sure everything is on schedule.
- Analyse areas of difficulty and fix them
- Ensure all kit is able to make the transition. (Does application X need a 500MHz chip, and how many PCs have got that?)
- Decide who is the key person for overall changes and make sure all staff are aware that he/she is the point of contact.