The Trouble with Transformations

Thinking big when you should just be thinking

By Julian Browne on December 11, 2007. Filed Under business, delivery

Transformation time.

"Dr Chilton does enjoy his petty torments"

"What did you mean by 'transformation', Doctor?"

"I've been in this room for eight years now, Clarice.

I know they will never ever let me out while I'm alive.

What I want is a view. I want a window where I can see a tree, or even water.

I want to be in a federal institution far away from Dr Chilton"

I can't hear the word "transformation" without thinking about that scene from Silence of the Lambs. Buffalo Bill, the psycho skin-coat seamstress who lives in a house full of moths (oh the symbolism), transforms himself from Looney Tunes dog lover into an unconvincing woman, while agent Clarice Starling transforms herself from rookie cop into a far more convincing federal agent. The point being, I suppose, that transformations can go either way.

These days it seems like everybody's at it. I checked three international job sites this morning and uncovered well over a hundred (I gave up counting) roles required to either manage, or contribute in a significant way to, a transformation. I myself have, over the last six years: been transformed, been seconded into two transformation teams to transform others, and led one such initiative entirely.

I'm not going to fall into the trap of kidding myself that I harboured fundamental doubts on any of those projects. Far from it. I think I genuinely believed that better futures could be constructed by taking a step back, to redesign and update things like process, organisational structures, skills, attitudes, and so on. In fact I still believe that it's possible, but I also have to admit that, on balance, a transformation exercise is more likely to simply waste valuable time than it is to revamp a tired and under-performing IT organisation.

• It's a Management Problem

  An old boss of mine, when faced with one of those "we aren't going to hit the date because.." conversations from his team, would often reply "it's a management problem" and send us away to sort it out.

  At the time, we thought this a somewhat unhelpful response, and would lament another lost opportunity for a hard hitting transformational good-riddance to the under-performers who were to blame. But, older and wiser, I now see that he had a point. Late projects are, more often than not, due to basic things like over-optimistic dates, poorly understood requirements, disorganised project delivery processes, poor communication, or a lack of clarity within the business itself. All fixable by better management. Certainly not by the kind of uncertainty you get during a transformation.

• It's not an IT Problem

  And while we're talking about a possible lack of clarity within the business, that's a good place to start looking for fixes. The most perfect IT processes and people in the world can never satisfy a business that doesn't really know what it wants.

  Not that anyone should realistically expect a business not to change its mind. I've said before that blindly and submissively meeting requirements is a waste of time - the fact of the matter is that the sands of competition in business change all the time. IT's job is to roll with that, but in return the business must at least have a clear idea of what it's priorities are at any one moment and why certain projects are more valuable to the bottom line than others.

  IT has an obligation to discharge its duties with the utmost professionalism, and to minimise nasty surprises in doing so, but ultimately the business is accountable for extracting the maximum business value from IT, not IT itself.

  See Gartner's Robert Mack's Four Business Myths About IT: Value, Alignment, Risk and Agility for more on this.

• It's a Consultancy Problem

  And while we're talking about consultancies: in my view, one of the biggest causes of transformation mishap is that they are a honey pot for consultants. Now heaven knows I have no beef with consultancy organisations beyond the fact that they almost exclusively hire from each other, and hardly ever people who have actually delivered software. And when I need a bunch of overdressed twenty-somethings, with the audacity to present to me as if I might be just a tad slow on the uptake, I will be sure and give them a call.

  The thing is nobody knows your problems like you do. The answer for you is most certainly not the same as the answer for someone else. And consultants aren't you. They come armed with their version of "best practice" which is the magnolia mix of solutions gathered from other institutions that also aren't you.

  Maybe you think that your levels of business-as-usual are so high you simply do not have the bandwidth to address transformational-sized issues. Well, here's a plan: hire one or two contractors, get them to survey your teams to determine what the biggest issues are (you'll already know them, but it's as well to have some sense of measurable consensus), then choose just one or two from that list and make those changes. Then wait a bit. It might not sound like much, but it's a direct listen-plan-response approach, and it shows everyone that you're not happy with the status quo. Then repeat the whole thing again a couple of months later.

  Your list will be long, and each time you look at what's wrong new things will appear, but you will be fixing them properly, one at a time. You won't be paying millions for what may, or may not, have worked elsewhere and nobody will become nervous about their job security. If there are personnel issues then deal with those via management - that's what HR processes are for. If the organisational structure needs tweaking then address that separately.

• It's a Culture Problem

  It may be that there's a culture issue. I've talked before about the emotional crisis IT seems to be experiencing - the business demands too many unclear things too quickly and IT flounders while delivering late and with poor quality. IT gets the blame and over time it loses self-respect and pride. A pyramid structure then develops with a few masochists who thrive on the importance the chaos provides them with (they are the only ones who "know how things work") at the top, and the rest of the team resigned to their lot at the bottom.

  Making even small changes in this kind of atmosphere is difficult. The heroes don't want to lose their status, and the rest are difficult to convince that anything new is necessarily better. You certainly can't change a culture overnight, and neither would I suggest that small tweaks will change it either. The only thing that will fix deeply embedded cultural issues is .. management. Those that face-off to the business have to make that partnership successful despite any issues.

  The old maxim that nothing breeds success like success is a true one. Pick one project, get help if you need, but not too much, and make it a flagship. Then do it again with a different group of people. Accept that corners will need to be cut using the concept of design debt that removes blame entirely, but allows the business to understand the implications of its actions.

• It's a Communication Problem

  And finally whatever you do, you will never communicate enough. Have a "change" intranet site, make it someone's role to update it every day, send an email newsletter out at least once a week, even when there's nothing to say, present progress at least twice a month. It sounds crazy but it all helps.

  Making change is a sensitive issue even on a small scale. People are understandably twitchy when the word change is mentioned, mention transformation and you'll have half the workforce updating their CV/résumés and hitting the job sites before lunch. The good ones will get lured to competitors making your original problem worse.

And keep referring back to why you're doing it. Don't get led into change for its own sake. Remember what happened with Hannibal Lecter. All he wanted was a view, a window where he could see a tree, or even water. Then the consultant showed up.