Turnaround strategies for the CIO

Some people in life are natural born problem-solvers. If they’re good at it, then in commercial terms they become expensive hired guns – risk takers who see themselves as agents of change. While not every CIO is a turnaround specialist, almost every CIO will find themselves in such a scenario at some point in their career. Throughout my own career, I’ve worked closely with the super-cool, superhero turnaround guys, as well as the more cautious, middle-of-the-road crowd who just want to cope well when things go off the rails and get things back on track. The superheroes don’t necessarily need advice from consultants like me, although they often bring us in to litmus-test their strategy and help ensure it is well executed. This article is aimed at the rest of you – the mere mortals trying to do the right thing in difficult circumstances. No-one gets this far without a few black eyes and bloody noses along the way. When a project is cancelled, we like to think that it’s purely down to external circumstances – the recession, budget cuts or changes in business requirements – but certainly not anything that we’ve done, not done, or mismanaged. That’s just human nature. I’m sure you’ve all had major projects that have been cancelled for one reason or the other in the past. But if you’re really honest with yourself, the niggling feeling you had in your gut at the time means you know it wasn’t just down to external forces; part of it was down to you. Chances are that some of your projects weren’t cancelled just because of a sudden shift in priorities. Some of them were cancelled because there were problems or because they were judged unlikely to ever be completed. Or perhaps they were way over time or budget, or managers had lost sight of the original objectives so they no longer had any clear business value. As the great philosopher Soren Kierkegaard said, “Life should be lived forwards but understood backwards.” We all know the most common pitfalls, so I’m not here to lecture you on those. Besides, not all mistakes are necessarily a big deal unless you keep making them habitually. What I would like to do, however, is take a closer look at some of the minutiae that will give you an early warning system next time things are not as they should be, or when they are heading in the wrong direction, and what you can do about it.

Five early warning signs 1. Hard questions last. On any project, ask yourself if the critical, high-risk functionality is being delivered early on in the project. If it’s only the easy, low-level functionality that is being delivered early, then alarm bells should be ringing. The critical high-risk business functionality should be addressed up front. If you’re not comfortable early on, chances are the business is not going to get early sight and visibility which means no one is going to feel comfortable later on.

2. Lies we tell ourselves. It’s extremely common for people within your team to miss a deadline then reassure you that they can catch up and still deliver on time. You want to believe them. They’re part of your team. They’re hard working. You know they’re extremely capable. But don’t fool yourself. If you miss a deadline, you’re running late. When most people claim they can ‘catch up’ it means sacrificing a step somewhere along the way. The testing phase is almost always condensed in a Herculean effort to meet a deadline and then treated as an afterthought, for instance. Either change the delivery time frame and expectations accordingly, or de-scope the project. Rushing the testing or skipping steps is throwing egg on your own face.

3. Gold-plated delays. Understand the minimal scope early in the project. Don’t let it evolve. There’s a tendency for the business to want to gold-plate requirements early on because they’re not entirely sure what they need or have seen a software package and think that’s what they need. You must push back early on in this instance. The frilly bits can be added over time after the base functionality. You need to insist on the minimum spec up front and early on to ensure you deliver what’s essential for the end game.

4. Politics and people. Take a look at who is attending the meetings. Look at the project lifecycle – if key stakeholders don’t turn up for the meetings, it doesn’t bode well for your project. Stakeholders should not only turn up if things are going wrong. A steering committee still meets even when things are going well because it’s a steering committee, not a crisis -committee.

Most IT departments are intrinsically trying to do too much and make too many promises, and don’t have enough resources. I’ve seen some CIOs try and play all positions of a football team on the pitch themselves. Insist on other parts of the business playing their part on projects and programs – don’t fill the void.

5. Whining and whipping. Vendors can make good whipping boys for companies, especially when a project isn’t going well. In fact, if you look back at most projects, whining and blaming is one of the early alarm bells that things are off track. Likewise, chances are you’ll also encounter lots of independent project managers trying to justify their existence. Be aware that their main objective is to keep themselves employed – not necessarily deliver the project. If you start to experience frequently growing finger pointing, this is your cue to nip it in the bud, bring the team together and remind all those involved in the delivery process – the IT -department, multiple parts of the business, and multiple suppliers – that you share a common goal. If you let the blame game just play out in front of you, your project will almost certainly fail.

And five things to do about it Inevitably, at some point in your career, things will go catastrophically wrong – whether it’s your own doing or whether you inherit someone else’s mess. Any early warning alarm bells will be silenced by the scream of sirens going off around you. Here are a few tips to help you keep a cool head and do the right thing when things are falling down around you.

1. Demand management. Focus on managing demand by trying to route demand requests from the business through a single channel. Chances are that ICT is trying to do too much. This enables you get a handle on the true demand and stifle it as appropriate – which allows headroom to re-direct resource to longer term problem-solving rather than fire fighting.

2. Sponsorship. Be clear about which proects are sponsored in the ICT department and which are sponsored by the business. Insist on robust governance and correct role allocation. Change roles and governance arrangements if necessary.

3. Independent thinking. Commission an independent review of the project portfolio to demonstrate to your team that you are serious about bringing about change. This also provides advice for you outside of the immediate team you have inherited.

4. Programme conscience. Don’t try and do it all yourself – you can’t keep an eye on everything. For major programmes of work in the portfolio appoint an independent programme conscience to watch over and worry about the programme. Most importantly, surround yourself with trusted stars. Bring in trusted lieutenants if appropriate.

5. Focus on value. Identify which of the ICT services are high added-value to the business customers and which are lower added-value and commodity. Focus on improving the high added-value service and look to externally source the others. Above all, make sure your colleagues in the business don’t see business change as part of an IT project. This is fundamentally the wrong way round: an IT project is often part of a business change project. While it is true that the IT project may be the largest, most complex, time-consuming and expensive part of the programme – it needs to have its roots firmly embedded in business value – or else there is a very real risk that the tail will wag the dog.

About the author: David Kilpatrick is managing vice president at Hitachi Consulting UK