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 Computer 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 prepare for project failure or is that not just a very negative outlook?

Alan Thomas: I would say absolutely, you should prepare for 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 each 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 that can be done that will help a project succeed in the first place.

Alan Thomas: Absolutely. That is certainly our experience where 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 provider, 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 ensure 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 project 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 that 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.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy