Why IT projects fail

Ever wondered why IT project status reports are so upbeat, managers continue to fund losing efforts, and some projects are doomed from the start?

Ever wondered why IT project status reports are so upbeat, managers continue to fund losing efforts, and some projects are doomed from the start? Sue Young, CEO of ANDA Consulting in Colchester, Vermont, thinks about that all the time. She talked with Computerworld's Mitch Betts about preventing failure in IT projects and why risk management isn't enough.

Why are IT status reports often so rosy, even for projects in trouble?

Because status isn't reported in objective, observable terms. It's often put in subjective terms like "percent done," or "red," "yellow" or "green". As long as you allow reporting to be done in subjective terms, you're going to get results that could be colored. Instead, you should look at "Is it done or not done?" where done has a clear definition. If you want to use colors, have a clear definition of what those colors mean.

Another reason is that if your reward system values compliance — not rocking the boat, looking like you're on schedule — and it doesn't value the early detection of problems, it leads to rosy status reports.

The third reason is fear, whether it's fear of looking bad or losing your job. You're not likely to remove fear in the workplace, but if you change the other two factors — status reports that are objective and observable, plus a rewards system that values the early detection of problems — then you'll have status reports that are reliable.

Are some IT projects just plain doomed from the start?

Yes, I still see that. Either the data required for the project doesn't exist anywhere in the company, or the project is out of alignment with the business strategy, or the objective is simply unattainable.

Why do managers continue to fund losing efforts?

One, they don't have any empirical evidence that the project can't be salvaged. Two, they want to salvage what's already been invested. The third reason is fear — fear of looking bad, fear of losing their job, fear of making a mistake.

At what point do you decide to kill the project despite the sunk costs?

When you know that it can't possibly succeed. That requires knowing your definition of success. If you know that even if you pour more money into it, it's not going to be worth the benefits that you get out of it, then it's already failed, whether you keep going at it or not.

What's the best way to kill a project?

I don't know that there's a best way. One way that seemed to work very well was that one company had a meeting first thing in the morning, fired the consultants and contractors, told the managers to figure out how to redeploy the resources, and everyone else was told they had the day off and to come back tomorrow to find out what they'd be doing. It was clean and efficient.

Are most project failures caused by technical problems, people problems or business problems?

People problems. Business and technical problems boil down to people problems. Calling something a technical problem is a convenient label to say "It's not something I can handle". If the server goes down, "it's a technical problem". Well, you either fix it or get someone to handle it. It's a people problem. People solve problems. People create problems. "It was a technical problem because the software was buggy." Well, it was people who created buggy software or made the decision to buy the software. It's the extent to which we take responsibility for solving problems that gets them solved.

The myth of IT is that it's about computers and technology. It's not — IT is about people.

So why do IT projects fail?

No one prevented them from failing. We define success as a lack of failure and failure as a lack of success. If you eliminate the possibility for failure, the only possibility you have left is success.

You can try to do all the things to make something succeed and still be blindsided by something you didn't notice, didn't consider. So trying to do all the right things won't necessarily ensure success.

In risk management, we look at what might be a problem. In failure prevention, we look at what will definitely cause this to fail and let's make sure it doesn't happen.

Compared to the causes of failure, risks are friendly. You can watch them, mitigate them, see if they happen. Risks have a probability. But there are definite causes of failure that, if you have them in your project, your project will fail, like objectives not aligned with business strategy or missing data. And if you have something that will definitely cause your project to fail, there's only one thing left to do, and that's to get rid of it.

Reality Check

Many IT project crises are caused by an unrealistic schedule. How do you come up with a realistic one? Consultant Sue Young says there are seven often-overlooked things that must be done before you can come up with a realistic schedule:

1. Nail down the scope and requirements.

2. Prototype the biggest technical risks.

3. Create a model of the user interface.

4. Pay attention to industry-standard estimates for similar projects.

5. Let each person create an estimated task schedule for his own work.

6. Accept only observable, measurable status reports (such as "done" or "not done," with a clear definition of done).

7. Subdivide all the tasks until each task takes one to two weeks to complete.

It sounds like a lot of work before even starting the actual project. "That's right. But if you want a realistic schedule, that's the way to do it," Young says. "To create a schedule before the scope and requirements are known is absurd, and yet we see it all the time."

In fact, doing steps such as prototyping the most difficult technical portion of the project may show that the project isn't feasible, Young says. "It's better to find that out upfront.

Sue Young

Position: CEO of ANDA Consulting in Colchester, Vermont, which performs "failure prevention assessments" that show companies how to prevent cost overruns, rework, cancellations, postinstallation rejection and the failure of software development projects.

Background: Young has 20 years of experience with database projects, started her first company at age 18 and started ANDA Consulting in 1989. She has a second-degree black belt in tae kwon do and is a member of American Mensa.

Web site: www.andaconsulting.com

Join the newsletter!

Error: Please check your email address.

More about Betts GroupReality Check

Show Comments