CIO Lessons 1: How to manage change

See also: CIO Lessons 2, how to manage people

CIO Lessons 3, how to manage suppliers

With thanks to:

Pip Peel, VP, program management consulting at Cognizant Sharm Manwani, associate professor, Henley Business School, former IT director of Grand Metropolitan and Electrolux. Stuart MacKenzie, managing director of leadership consultancy, Maynard Leigh

Change management tends to conjure up a nightmare vision of unruly, monolithic projects that are the nemesis of the CIO.

In fact, the term could legitimately be invoked every time an IT project is initiated where business benefits are desired: research from the Institute of Directors shows that 80% of budget needs to be invested in achieving business change, processes and culture, with just the remaining 20% spent on the tech aspects of a project.

Most CIOs get the fact that there’s more to a technology upgrade than putting some kit on lots of desktops. But the problem with change management is that it is discussed in flashy terms and has been elevated to management speak.

Happily, our practitioner panel says it is very much the realm of the CIO and can be boiled down to three things: commonsense, keeping a firm grip on multiple strands, and a fearlessness when it comes to communications.

So with the days long gone when the CIO focussed on the technology and other people filled in the gaps, change management needs to be fully embraced.

Do it with eyes and ears open, and there’s every chance of retaining control and maybe winning plaudits. But ignore any aspect of this discipline and it has the habit of boomeranging back in an unpleasant way. Our panellists (listed above) offer their tips:

Avoid the sandbox syndrome Boards have a tendency to put technology in a sandbox but the reality is that most boardroom decisions around technology also involve change.

A common pitfall for a CIO is to be saddled not only with responsibility for the tech implementation but also any accompanying business change, without that element being properly discussed. Business change should be the responsibility of the whole.

Make peers accountable Get assurances from your CxO peers that they are their functional heads are going to do their part. Try and get these responsibilities aired at the board level and mapped into the change plan. If you have a good and functioning board, the other directors would welcome this. If it’s bad and your fellow directors are defensive, you’ll have a nightmare on your hands.

Eradicate ambiguity A surprisingly high number of projects begin life without clear objectives. One common oversight is clarity about the regions where software will be deployed, which could potentially impact thousands of users.

A plan that looks logical to the top brass, will be a source of some consternation to the staff in Madrid, say, who don’t know whether they’ll be using a Spanish or English version of software.

If there are any vague areas in a project, don’t be afraid to ask the simple questions.

Build a stakeholder map Once you have a programme in place, identify and log all business heads whose people or processes are affected. Take a traffic light approach to monitoring stakeholders; the antagonistic are flagged up as red, the ambivalent brigade is amber and the enthusiastic, green.

Make someone on your team responsible for managing these critical relationships and update the map regularly.

Even if you can’t change people’s minds, this approach enables damage limitation while the ‘greens’ can be put to work on the project’s behalf.

Create a comms plan But it’s well worth formalising this realisation with a communications plan that marks the tech milestones and accompanying communications activities.

These should be plotted on a gant chart and relate to the before, during and after of a cutover weekend, roll-out or whatever IT activity is being implemented.

Having a comms plan that tracks these activities is as important as the tech plan that manages the bits and bytes components.

Ignore your business customers and a tech rollout that is flawless will fail because you lose mindshare in the perception battle.

Expect emotional upheaval Humans are creatures of routines and the whiff of change can make many react with anxiety, hyperactivity or resistance. These are emotions that CIOs with their logical bias may be less comfortable with, but it’s good to engage early on with the users who will be affected by a technology roll-out.

The trick during any communication is to focus on the business problem, rather than selling them the tech solution. (see below)

Have a dream

Martin Luther King didn’t stand up and say ‘I have a technology project’. When the CIO has to explain the reasons for a change project to business colleagues, William Bridges, change management guru, offers these tips.

– Link the change to the drivers that make it necessary – Sell the problem before you try to sell the solution – Don’t use jargon – Keep it short

Grow grassroots groups The abundance of online collaborative tools certainly aid co-ordination of a change programme. Wikis, email, and daily bulletins on the intranet are indispensable methods of ongoing and mass communication.

But underestimate the value of face-to-face meetings at your peril. As well as the high-level steering committee group, put in place a sub group that is populated with users from all areas of the business.

Your grass root team members will provide valuable feedback on programme elements going well, and those going not so well.

Hire a spin doctor Seasoned CIOs often hire an external comms consultant to manage messages for them around change management programmes.

These spin doctors should be able to come up with some creative ways of engaging with the business and creating a buzz around a project.

A regular newsletter and frequent bulletins on the intranet are obvious places to start. A more innovative idea was to run a series of lunches, where all staff were invited to a working lunch see some presentations and prototypes and hear.

Measure benefits Set up mechanisms to measure the benefits that the change management programme is expected to bring. The follow-through calls for dogged persistence, long after the adrenalin and excitement of the technology deployment has passed, but is necessary.

Good results can be fed back to the board; indifferent measurements can be mitigated through extra training; ignore the measurement of benefit realisation, though, and the CIO will become the victim of a project’s perceived failure.

Pic: Slideshow Brucecc2.0