When Projects Fail and GO legal!

When Projects Fail and GO legal!

Sadly, seven out of ten projects fail. Some lead to customers taking their IT Partner (System Integrator, Consultancy Firm et al) to court to claim damages. The outcomes of such cases are rarely reported and many lead to compromise agreements. Obviously, both parties will not wish to ‘hand their dirty washing out in public’.

For the Project Manager community we never get to learn the lessons from such legal cases. So based upon my experience over the past ten years, I calculate that three projects out of every fifteen ended up in court.

So what went so badly wrong to land the respective parties in a court of law defending their respective positions?

1.       The respective parties expectations of each other failed to align and were only fully exposed at the end of the implementation. Sadly, often too late to address the underlying issues. I have witnessed organisations failing to take ownership and seemingly leaving it to the implementation partner to shoulder all the responsibilities for getting the project live. Hard to believe in 2014 when you would have assumed organisations are project savvy.

·         There is a case going through the courts now where an organisation requested significant customisations to an ERP solution and then blamed the implementation partner for poor quality code after the solution went live! So what went wrong (if anything) in the testing stages and perhaps more importantly why did the organisation fail to adopt the solution?

·   They failed to adequately invest in internal business project resources to support the key stages of testing and transition into live running

·   They failed to acknowledge the likely business impacts and then invest in business change resources to help the employees adopt the new ways of working enabled by the solution

 

2.       The solution fails in testing, possibly UAT and heavens forbid fails in live running. The solution fails for one or many reasons and doesn’t do what it says on the tin!

·         There is a case where a large organisation pulled the plug on a service management solution at the UAT stage having invested over £20m when they discussed that the ERP vendor had previously advised their System integrator that the proposed solution would not work a year earlier!

·   Avoid the bleeding edge projects!

·   Work closely with the application provider and their design/development  team

3.       The client bought a standard application solution but had to demand customisations that extended the scope of the project and led to major project overruns on time and cost

·         A recent case in the local government sector saw a consultancy firm challenged in the law courts for failing to manage the delivery of the solution with all the required customisations within the agreed budget (revised many times). Ironically, the consultancy firm had produced the original business case detailing a cost of implementation which the Council approved but then three years later and two behind schedule the cost had tripled. Why did they get it so wrong? They took a standard approach to delivering an ERP solution without realising the client had significant requirements that had not been fully identified, specified and validated  

o   Do the basics right!

o   Define your business requirements, document and valid them with your key managers and SME’s, who own them during the implementation lifecycle and beyond

o   Avoid the temptation to go with a template solution or process flow accelerators without stamping your organisation mark all over them!