In the last article, I gave three reasons for IT project failure. These are not the only ways to fail! In this article I describe failure modes I’ve seen that are much less conventional – and harder to overcome without serious dedication at the top.
Here are the three reasons from last time:
- They’re not defined well
- The people doing the work are not a team
- They don’t have enough resources or the right resources
And here are the new ones:
4. Management is fighting over who controls the project
There’s nothing nastier in corporate politics than a turf battle. All the best-intentioned platitudes about teamwork and customer-centricity are forgotten when there is a fight for power. If these are happening in an organization near you, then you’re probably hunkered down, waiting for the chips to fall. The project work is also probably way behind schedule and no one is willing to take any risks while the battles are fought.
These projects usually falter when the funding becomes uncertain because of the battles. That of course leads to failure reason #3 above.
5. The project has been chartered in order to show off a capability, rather than to accomplish a real, customer-oriented goal
A U.S.-based company I was working in asked me to manage a development project that was being done on the other side of the Atlantic. Why? I found out later it was simply because the former VP of Software was now in Europe and he wanted to show off the capability of the European software development team. Although we managed to deliver the product and the team performed well, the product was not well received. It was really unnecessary.
6. Middle management is truly incompetent
A client company started development on a system that was way outside the company’s traditional area of expertise. When the managers realized they needed an essential software component and asked for it, the development team showed them the component that they had already developed, because it made no sense to proceed without it.
This company’s first and second level managers were in over their heads with regard to the technology. What made it worse is that the two levels of managers protected each other from showing their weakness to anyone above the second level. Both the system and the company folded within a few years.
7. The CEO and the executive staff don’t support the project because they don’t understand its significance.
A company I worked for was the first disruptor of markets for the big players in computer systems. It offered systems that were an order of magnitude less costly than the competitors, and this not only opened up markets and applications that were new, it began to eat into the margins and the market share of the big players.
Twenty years later, other new companies began offering systems that were an order of magnitude less costly than this company’s systems. The company couldn’t respond adequately because the top management did not understand how these “cheap” systems could do what the more costly ones did. They also failed to grasp the significance of software as a business, separate from the “iron” of computer hardware. The company ended by being acquired by one of the upstart disruptors.
If you can find your way to a safe place to proceed with your project, keep on trying to establish good practices and excellent communication. And if you’re depending on successful completion of the project? Then get clear about what’s going wrong, and get help.
About John Levy