Project Failure - causes, risks and liabilitiesDate: Dec 07, 2009
Computer Weekly and specialist technology insurer Hiscox, conducted a peer-to-peer roundtable event on the 24th November, to discuss why project failures happen, what to do if the worst occurs and how to prepare for it and what to look out for to avoid future disputes.
After the event we talked to Hiscox’s Alan Thomas, Head of UK Technology Underwriting, and attendees, about the most common causes of project failure.
Read the full transcript from this video below:
Project Failure - causes, risks and liabilities
James Garner: Hello. I am James Garner and we are at
Weekly Hiscox roundtable discussion on project failure.
Firstly, I am going to be talking to Alan Thomas,
who is head of UK Technology Underwriting for Hiscox.
Alan, what are the most common causes of project failure?
Alan Thomas: What we have seen at Hiscox and across our
expanse of claims, so where a project failure has
come to the point of no return almost, so litigation
or client dissatisfaction, we have broken it down
and we see five very common causes. Firstly, starting
to get into the work too quickly. That means before
you have set out contractually who is going to be doing what,
and not having invested enough time in the initial scoping
of the project. The second key factor is: Have you invested
the time and effort up front to make sure you are clear with
each other, customer and supplier, about what you are going
to deliver and what is needed? That actually does bring out
quite a big point on how you use a contract, so actually mapping
down a clear specification who is responsible for delivering
what, and what it will look like, and then actually including
in that contract what to do if things go wrong. We do not
always see that at the point of claim, but when we do is see it;
it is very useful for both the supplier and the customer to know,
at the beginning, who is supposed to be doing what. Finally,
two points which are very common and quite obvious, really,
poor project management: Having a good quality project
manager who understands the client's requirements and
can deliver to them is really important. Then actually not
involving the right people at the right time, so that can
either be users at the scoping stage. Ignoring those people
who will ultimately use the system is a big, common mistake.
Also, engaging the right senior management to see
the project through.
James Garner: When you embark on a project, should you
for project failure or is that not just a very negative outlook?
Alan Thomas: I would say absolutely, you should prepare
project failure. Failure of some description or change
happens in virtually all of the projects we see, and yes,
I think it is just good risk management, and it is about
being clear with each other about what to do if a project
does start to go wrong. That, in my experience, is vital to
a good client relationship and the successful project.
James Garner: How can you avoid disputes over the project
failure in the case when things do unravel at the end?
Alan Thomas: Again, it does come back to being clear with
other up front. Making sure you have discussed what
could go wrong and agreed how you will deal with it,
if it does. Simple things like, for a larger project and
larger organizations, an escalation procedure; who will
be brought in to solve problems when they happen?
More simply, just agreeing if X happens and it is a risk,
then how will we deal with that now? It allows for better
planning and scoping at the beginning of a project to
have those potentially quite difficult conversations,
but it is just about managing expectations, making
sure that you are clear with each other from the start.
James Garner: It seems there is a lot of initial preparation
be done that will help a project succeed in the first place.
Alan Thomas: Absolutely. That is certainly our experience
we see things go wrong. We always have advised the
client to invest more time up front, planning for what could
happen and what could go wrong, then how to deal with it if it does.
James Garner: We asked delegates: Ware the most common
causes of project failure? How can IT firms best
prepare for the challenges that arise from this?
Simon Aaron: I think both sides, the client and the
need to put skin in the game. They need to invest in time,
either in consultants on their side, or project managers
on their side, as well as our side. Both people have to
invest, there needs to be an open dialogue, and there
also needs to be a very clear risk register, or risk plan,
for both sides to work through.
Peter Sweetbaum: The best way is by working with clients to
that strategically, all the objectives of the organization
are translated into the scoping of the project and the
requirements. That contains all the objectives so they
can be delivered throughout the project exercise.
Giles Sirett: I see the single most common reason for
failure is a lack of involvement at strategic-level
within organizations, a lack of involvement at board-level.
In terms of avoiding project failure, it is about good early
engagement between the supplier and the customer.
Doug Cubin: Personally, from my experience, I believe
organizations are not involving the actual end
users early on enough in the process of kicking
off a project. Right from the very beginning, indeed,
even during the sales pitches and the actual formulation
of the contract itself, you need to engage the end users,
themselves, also, to continue that engagement throughout
the whole project lifecycle. By making sure they are in on the
project at the very beginning so their requirements are fully
understood, and they fully understand what is going to be
delivered, and they could use something like the agile methodology.
Chris Tiernan: I think one of the key things is I am not sure
projects actually fail.
I am not sure that they overrun budget, overrun timescales, or
deliver short. I think what fails is really the setting of expectations
in the first place. The way projects are estimated and planned,
then the execution of them and the management. The difference
between those two things is the project is often just an amorphous
entity, whereas the others, when you look at them, they actually
go back to particular individuals who ought to take on particular roles.
I think we are hiding underneath this umbrella of projects,
when it is really to do with the expertise of individuals.