How to kill a major IT project without killing your career

Meet Christine, the CIO at a midsize manufacturing company. Christine is a year into an 18-month, $2 million SAP expansion, and, to put it mildly, things aren’t going as planned. In fact, the real problem is that this project is never going to go as planned. We’ll join Christine’s thoughts as she makes her way to the quarterly steering committee meeting to deliver the bad news.

“I can’t believe I let those guys at SAP talk me into adding a bunch of new modules onto this system. I should have known the software wasn’t ready. They just acquired it as part of the purchase of a couple of companies, and it’s clear they are still trying to integrate the new code into the core SAP modules. I could kick myself. I really, really should have known better. Things never go smoothly after an acquisition.

This was supposed to be a quick win and a simple integration to meet my customer’s needs. Yeah, right. This project is going to take an additional six months, and, worse, it’s going to cost us another $2 million.

How am I going to tell the execs we’re in trouble, and we need to consider canceling this project?”

Sound familiar?

What senior IT leader hasn’t had to face this challenge? If you were lucky enough to avoid the ax, it probably cost you a raise or a bonus. But worst of all, it hurt your credibility with senior management.

So how do you handle a situation like this? How do you kill a major project without killing your career?

Before we solve Christine’s problem, let’s take a closer look at Christine and her situation.

Sure her project is in trouble, but is success as an IT leader contingent upon never having a troubled project? Is it really possible to expect the IT leaders of large organizations to never have to deliver bad news? Come on.

Information technology projects are always pushing the envelope in an effort to support the business. There are going to be failures, period. What sales or marketing group can claim 100% success on all programs? So if you plan on being an influential IT leader, you’d better be able to not only survive problem projects but also know how to use them to demonstrate leadership and to build political capital with your executive peers.

Christine is in hot water for a few reasons, none of which has to do with the specifics of the project.

• Christine cares about her work and her reputation. She doesn’t shy away from personal responsibility and she is keen to bring that same personal responsibility to all the company’s IT projects. And that’s the problem. She mistakenly thinks (and acts) as if she is personally responsible for all IT projects. [Note — I said personally not professionally. There is a very big difference.]
• Christine is a first-rate IT project manager. Her projects never fail. She knows how to prepare for project success, but doesn’t have a clue about preparing for failure. Not her failure, mind you, but the project’s failure.
• Christine is a visionary and can see the great benefits the project will bring the company, and she’s excited about the possibilities. Unfortunately, this excitement translates into Christine becoming a major advocate and supporter of the project, which makes it hard for her to shut down the project without looking stupid.

Sure the SAP project is in trouble, but the real problem is that Christine has become the project. To effectively deal with problem projects — and every good IT leader is going to have them — you have to stand separate and apart from the IT projects you are charged to oversee.

You have to change your understanding of your role vis-à-vis the IT project portfolio. You have to recognize that as the CIO, your job is not to be the project manager of every IT project. And stop acting like the project’s biggest cheerleader. Don’t get so personally invested in the project. Remember the real focus of your job as the CIO is to get the right projects done in the right way, for the right price.

From the very start, yours should be the voice of concerned risk management. Be the skeptic. Ask the tough questions like: Will this work? Can you really do that? What if things go wrong?

Let the users, the more junior people on your team, and the vendor prove to you that everything is really OK. Your job is to highlight the risks until the project is up and running smoothly. Challenge the project team to meet their stated objectives.

And most importantly, don’t position yourself as the person presenting the project to your peers. That just sets you up to be the object of their criticism. Instead, get on their side of the table. Be part of the team reviewing the problem project, not the person delivering the bad news.

Unfortunately, Christine didn’t do that, and she’s really in a jam. She still has no idea what to say to the steering committee, and that sinking feeling in the pit of her stomach just gets worse, the closer she gets to the conference room. Christine could sure use some help.

As she rounds the corner to the executive suite, she bumps into Martin, her trusted consultant, who’s just finished running a successful, large-scale data warehousing project for her.

“Martin, I’m so glad I ran into you. I really need your advice. I need to kill this project. It’s gone horribly wrong,” she said, filling him in on the problem. “What should I do?”

Next time, we’ll listen in as Martin gives Christine some advice.