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, Vt., 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 coloured. Instead, you should look at “Is it done or not done?” where done has a clear definition. If you want to use colours, have a clear definition of what those colours 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 re-deploy 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.
