Getting on top of change management

One of the first articles I ever had to write as an analyst was about change management.

In it, I suggested that major IT programmes tend to follow a similar path as the stages of grief – denial, anger, bargaining, depression and acceptance.

Of course, this was no great insight: many managers will be familiar with the team-building stages of forming, storming, norming and performing, and meanwhile Stephen Covey’s seven habits include a familiar four stages between unconscious incompetence, through to conscious, then unconscious competence. Change, it would appear, is a multi-phased thing.

Change management is, perhaps, the one thing that has kept constant through the years, decades, indeed centuries of change itself. Perhaps the earliest change managers were village elders, called upon for sage advice to counter the impetuousness of youth and the political dynamics of the power-hungry. From these simple beginnings, the only strange thing about change management is, perhaps, fact that we still feel pressed to talk about it. If it is so fundamental, surely we should have it taped by now?

Part of this can be explained by acknowledging that each generation seems to need to learn certain things for itself. We see this over and again in IT, as once-exciting technologies become shelfware. The reasons for deployment failures are frequently down to a lack of consideration for the impact they may have: from poorly specified requirements and unsuitable selection of solutions, to political inertia, lack of executive buy-in and ‘not-invented-here’.

Anyone who has worked in IT for a while knows that nothing is ever built to last, and even successful projects can very quickly need to be superseded. Back in the Eighties, we saw mainframes replaced by minicomputers, which were in turn booted into touch by client server models. IT was just about getting its act together when the Internet came along and changed everything, followed closely by mobile phones.

Today, the evolution of hosted computing is having its time in the spotlight, and social networking is forcing a rethink of collaboration models. Against this background, the pace of change is a double-edged sword. It may be seen as a good thing that deployments can take place in a matter of months, where it used to take years; however, of course, this means that it could only take months before a new system becomes legacy.

The implication for businesses large and small, is that IT is itself a programme of change. All the elements that you would expect, from getting stakeholder buy-in, through awareness training for general users, to managing the transition and looking for quick wins, all play their part for individual projects. At a programme level as well, some level of continuity becomes an inevitable consequence.

This is not the place to say all organisations ‘should’ do this or that, not just because it would be patronising, but also because it is very difficult to be prescriptive.

We can, however, offer some guidance based on the lessons we have learned from senior decision makers in IT roles, notably around the importance of portfolio management. A number of people we interviewed for The Technology Garden, a book on IT best practice, told us how important it was to manage IT as a portfolio of services. Several interviewees made the comparison with a portfolio of financial assets, some of which may be higher risk with the potential for higher reward, whereas others will be more stable for longer-term value.

It’s not hard to see the connection between the portfolio management attitude and the need to consider IT from the perspective of constant change. It also gives an idea of the kinds of roles that might be required: not just technologists, but also managers who get, and who are measured on, how well the portfolio of services is delivered over time, as opposed to one-off projects.

In IT, nobody has a monopoly on the future. Perhaps one day change management itself will be automated such that it just happens, without any need for manual activities like stakeholder management or user acceptance testing – though from here, this seems as likely as quantum computing or holographic memory.

In the meantime however, we’re going to have to make do with our own innate skills as human beings. In the village that is IT, it doesn’t look like we should be getting rid of our elders any time soon.

Content Contributors: Jon Collins