In my previous post I looked at “How do we ensure a BPM project succeeds”, but it got me thinking, why do many IT projects fail? I racked my brains through the very few projects I have been involved with directly that have, not failed as such, but not gone well shall we say. I also started to think back to many projects I was brought in on to help succeed, and tried to remember just why they were failing in the first place.
There are numerous reasons why projects fail, why requirements were missed, why over complex procedures are put in place when not needed etc etc. But what are the real big reasons, what do we have to really understand and monitor closely as to keep an eye on proceedings and limit the chances of failure…
Politics
Ahh internal politics. This is possible the biggest singular reason why projects fail, usually as a direct cause. So what do I mean here…Well, at the early stages of a project, you need to ensure you get the right people with the right knowledge involved, especially if you are identifying requirements. But this is where it all starts. Straight away politics takes over, and putting together a “high level” team, along with “senior users” etc all means politics kicks off. For example how often are you working in a team and realise (as a consultant) that some of the people in that team from the company just shouldn’t be there. Why are they there? In addition, you walk the floor and find key users with a lot of knowledge not involved in decision making? Their absence has meant functions are overlooked, processes missed and for what reason? Often it is internal politics that decides who is in what team…
This isn’t the end though. No, internal politics can also mean you see key personnel dropping out of projects being moved elsewhere in the company. You also find people trying to make a name for themselves using your project as a vehicle, and because of this they slow everything down, re-visit old ground and basically make everything a pain in the neck (being polite).
My favourite experience though is internal IT departments refusing to get involved because they were not consulted with at the beginning of a project. Classic….There are so many many more examples, but let’s just say, if a project is going to fail; internal Politics will have something to do with it…
Before moving on, internal politics can also lead to the wrong system, solution or vendor / consultancy being used. More often than not, internal politics determines just who the business can work with on a project, not even taking into consideration expertise, skills, price and many other common factors.
Nepotism
This follows on from politics to be honest, or could even be seen as a part of internal politics. Unfortunately nepotism can often raise its head on an IT project. In many cases (well all in my experience) this causes friction and can have a real negative impact on a project, contributing to failure ultimately (if it goes that far).
It sounds obvious, but if someone just can’t pull their weight, or doesn’t have the necessary knowledge to be involved in the project (no matter what stage) then that person, no matter who they are, shouldn’t be involved….
Building on this though, it can also lead to particular vendors, or particular firms being used when simply they shouldn’t…
Incompetence
This one is a worry, as how do you identify someone is incompetent before it is too late? Unfortunately I have worked on projects with people who just don’t have a clue. To say they are incompetent maybe an understatement. I, as a co-worker can spot this, but more often than not, manager’s spot incompetence too late. It is therefore important that managers get a feel for their team, get feedback and try to judge if anyone is being “carried” or just plainly is incompetent
Change Management, or resistance to change
This one is deadly; it seems to creep up on IT projects. The 3 reasons before can all be “nipped in the bud” with good management. In addition they show up early in an IT projects lifecycle. However, poor change management or resistance to change from staff can mean that you may have the best solution in the world, but it will ultimately fail because no one wants to change the way they work.
To minimise this, IT project managers need to get not just key staff involved early on, but as many staff members as possible. I am not suggesting they all get to put their 2cents in, but allow them to feel a part of the project, get them involved in reviews, prototypes, demonstrations, the odd focus group etc. This way ensures that when the system comes along, many users have already come to terms with this fact and the solution itself. It minimises the risk of change resistance…
Conclusion
Ultimately managers make or break a project. The reasons shown above can all be avoided with good business management, good people management and a little dash of political prowess.
Recent Comments