Projects go belly-up for all sorts of reasons. The project team, the leadership, the suppliers and the stakeholders can all provide sources of failure. However, the most common reasons for project failure are rooted in the project management process itself. In the IT Project Leadership Report, based on research carried out by process consultancy The Coverdale Organisation for Computer Weekly, issues relating to the project management process accounted for three of the top four most common causes of project failure.
In most cases, respondents identified unrealistic time and/or resources estimates (75%); unclear or immeasurable project objectives (71%); and project objectives changing during the project (61%) as key factors in failures. All this suggests one thing: a lack of planning.
All too often it seems that project teams charge into a new project without knowing exactly why they are doing it or what they want to achieve, while harbouring unrealistic expectations. Planning is all: get this wrong and your house is built on sand. It is not a case of "if" the project will fail but "when". Other time bombs at the planning stage were identified as lack of a timetable and lack of a contingency plan; poor communication; and no change control procedures, so that when things go awry it is even harder to claw your way back on track or salvage something from the project. The scope for failure and failing to meet expectations is huge.
So why are project managers continuing to make the same mistakes? Steve Goodman is a consultant at The Coverdale Organisation, which has been running Computer Weekly-backed workshops on how to lead IT projects, based on the research. A key factor in project failures is that too many people try to follow a methodology blindly, he says. This fails to account for local conditions and the size of the project. "It needs to be tuneable," says Goodman. "For example, you can't follow the same process for large and small projects."
Another common cause of failure is that project managers are often simply given a methodology, such as Prince 2, and tools such as MS Project or Primavera, and told to get on with it. They fail to study the basic principles of project management and stages such as critical path analysis. "In the US they have a phrase for it," says Goodman. "A fool with a tool is still a fool." Project leaders should be "aiming, planning, doing and reviewing". Failure to follow these four basic steps is a major reason for project failure, he says, and results in a tendency to "shoot at something and then call whatever is hit the target". Stakeholders should have a clear, common and unambiguous vision of what is to be achieved.
Goodman stresses the importance of phasing projects, establishing at the end of each phase clear markers at which it should be established whether the project should continue. For this process to work, the project leader has to be more proactive and must not be afraid to confront senior staff and stakeholders with the truth if a project has gone off the rails.
Another common problem is lack of commitment. Too many project managers are forced to manage projects in addition to their regular tasks. This spells disaster for a project, says Goodman. This point is also raised by Graham Cassell, content team manager at bookmaker Ladbrokes.
Cassell, who attended one of the three-day Computer Weekly/Coverdale workshops, says one of his key problems is he often has to juggle different jobs.
Another common problem is the level of control put into the hands of the IT staff. "We're often expected to make major decisions that should come from the sponsors of the project," he says. However, Cassell stresses that Ladbrokes uses a thorough project planning methodology based on a project control document.
For another participant on the course, Steve Walker, project development manager at software firm Ciberion, the biggest problem is that projects are often started for the wrong reasons, such as a desire "to keep up with the Joneses". Another key problem is conflict management and for this Walker says his knowledge of psychology is often more useful than his professional IT qualifications.
Walker's main piece of advice for all project managers is to not be afraid of pausing to take stock of the situation. A failure to re-evaluate and conduct regular interim reviews to make sure you don't end up with the project management equivalent of the parlour game Chinese Whispers is "ludicrous", he says.
Like Goodman and Cassell, Walker stresses that good communication is central to the success of any project, although for Walker the key is effective communication - sometimes it is possible to over-communicate, he says. This is interesting, as one of the main reasons given by respondents for IT projects failing was that the project leader had poor communication skills. Two-thirds (64%) of respondents cited this as a major factor in project failure, putting it third in the list of most common problems, with a similar number (61%) saying that project managers with poor leadership skills was a major contributor to project failure.
Strong leadership and effective communication among all of the parties involved in a project, along with thorough planning to ensure that everyone knows their role, is crucial. Unfortunately these qualities are often lacking. More than half of the respondents cited a failure to clearly define the responsibilities of the project team and the fact they did not work as a team as major reasons for project failure.
As for stakeholders, the key issues reflect concern over a perceived lack of involvement or even interest on their part. The three main gripes were that senior management did not show strong support (59%), take ownership of the project (56%) or were not involved in setting project objectives (48%).
While poor relations with suppliers and other third parties did not make it onto the list of most common problems, the fact that the most common gripe was that there was no tight management of suppliers by the project manager of the team (44%) reinforces the need for strong leadership. Again, lack of communication of project aims was a common problem, highlighted by more than a third of respondents (36%), but perhaps most disturbing was the fact that a similar number (39%) cited lack of technical competence of the supplier or third-party staff as a major factor.
The bottom line is there is no surefire way to ensure that a project will be successful. However, there are things you can do to minimise the risk of everything going pear-shaped. Plan thoroughly; keep those communication channels open; be flexible; and do not adhere too strictly to a set methodology. Hopefully then you will end up cracking open the bubbly instead of taking part in a lengthy post-mortem or, worse still, witch hunt.
Advice for project managers
Coverdale recommends that new project managers:
- Identify risks but do not take them
- Take a systematic approach: aim, plan, do and review
- Do not be too concerned about spending too much time planning - charging off in the wrong direction is worse than "paralysis through analysis"
- Do not allow yourself to be bullied by anyone
- Do not be afraid to approach more experienced practitioners: network
- Do not be afraid to say "I don't know"
- Remember that communication is vital to any project and for experienced hands
- Do not assume that those you are working with know what they are doing just because you do (or think you do).
The next three-day Leading IT Projects workshop takes place in High Wycombe on 15 January 2003. www.coverdale.com
How the research was done
The Computer Weekly/Coverdale research is based on interviews with 867 senior IT professionals, who were asked to consider 60 factors that could affect the success of an IT project spanning five categories:
- The project process
- The project leader
- The project team
- The stakeholders
- The suppliers or other third parties.
Respondents were asked whether each of the factors was a major contributor, a minor contributor or not a contributor at all to the failure of IT projects in their own real-life experience.
<< Directors' notes
<< Brief encounters