Careful planning can help to make sure your project succeeds, but
if it is clearly not going to work, be ready to pull the plug. Karl
Cushing examines Computer Weekly's research into why projects go
wrong and how to prevent failure
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.comHow 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