IT Projects that work: strike to kill

In the last year, I’ve been asked for my advice on the implementation of a number of major IT systems. No matter who’s asking, no matter the type or size of the project, it always seems to come down to a single question: “If we want this project to be a success, what is the one thing that we really need to do?”

One thing. If only it was that easy.

If I had to come up with just one thing, it would probably be a piece of advice from medieval times: “If you raise your hand to strike the King, make sure you plan to kill him.”

Of course, people rarely understand what I’m on about the first time through, so I’d probably have to explain the lack of follow through that is almost epidemic in organizations that sponsor IT projects.

By way of an explanation, I’d start by asking about the project history of the organization sponsoring any new systems initiative. I’d ask if the organization had a flavour-of-the-month approach to systems projects, or a focus-and-finish reputation like General Electric.

“Like GE?” they might ask. As I’ve said before in this column, one of the many things that GE chairman “Neutron Jack” Welch is known for is focus. As big as GE is, Welch points to just five major initiatives in the organization in his nearly 20 years at the helm. Twenty years, five major initiatives – GE ain’t no flavour of the month company.

“Is yours?” I’d ask.

I’d ask how many of the organization’s IT projects had been cancelled before they were completed. Of those that were completed, I’d ask, how many were widely regarded as a success? I’d ask how long these systems stayed in production, how long they were actively used and supported before they were retired?

What I’d probably find, as weird as it sounds, is a whole lot of raised hands, and not a dead King in recent memory.

Fact is, there are far fewer bad IT projects out there than we might think – no one ever deliberately starts out with a bad idea for a project.

Fact is, there are a great number of organizations who don’t have the patience or intestinal fortitude to make good project ideas work.

And it’s getting worse – call it Internet impatience. We’ve come to believe that if the business world is changing fast, if technology is changing faster, we’d better see results from our project investments even faster than that.

What we get is project schizophrenia – too many projects, too many cancellations too early, too little patience.

Worse yet, project impatience drives the kind of organizational behaviours that you don’t want to see. If an organization has a history of project non-support, of letting projects fail, of pulling the pin on initiatives before the benefit streams start rolling in, it teaches the people in the organization that the expected thing to do, the easiest thing to do, is to simply let projects fail.

Some organizations are so extreme in this behaviour that the easiest thing to do is simply not to participate at all.

Ask yourself: is your organization one in which it hurts more to push ahead with a project than it does to stay on the sidelines? If yours is one of the latter, it would be better off to crawl into a corner and die quietly and leave big IT projects to the professionals.

Successful project organizations strike to kill, knowing that if they don’t, the King has a nasty habit of striking back.

Hanley is an IS professional living in Calgary. He can be reached at