In preparation for my speech at the “What to do When IT Goes Wrong” conference next week, I have been casting my mind back to memorable IT projects I have worked on in the past.
One thing is for sure – with over 75% of UK businesses having gone through legal disputes over IT contracts in the last four years, teething problems are practically expected.
And once a relationship has gone sour, the overwhelming priority is almost always felt to be termination. However, in my opinion, termination is rarely the best solution – it certainly shouldn’t be the first solution.
In this article, I want to discuss a project of note that I was engaged in recently, and what it can teach us about project termination (and recovery).
When an IT Project Goes Wrong
More often than not, Best Practice Group are employed at a stage of crisis.
Most organisations are reticent to engage in professional advice at the inception stage, but are left with little choice when the contracted service is falling apart around them.
Broken Promises
That is the very point at which we entered the particular scenario I want to discuss today. We had been employed by an events management company to negotiate the termination of an IT contract with an overseas company.
The contract was to deliver a much-improved front-end booking system – delivering like-for-like functionality of the old, plus an array of improvements. Unfortunately, the provider had been unable to deliver on its promises. All it had delivered was a system more cumbersome than the old one, with transactional speeds for completing the same business process increasing spectacularly from four to more than forty-four minutes.
Somehow, the provider had convinced the client to accept the software, on the basis that snagging issues would be resolved in the post-contract stage. Although the provider was very keen to resolve the issues, it was apparent that it was an issue of capability rather than capacity. In the software’s current coding framework, the promised outcomes could simply not be met.
Enter Best Practice Group
Fast forward a year or so, and we were tasked with terminating the contract and securing the best possible outcome for the client.
In such situations, our first task is to immerse ourselves fully in the history of the relationship, the terms of the contract, the functionality [and architecture] of the software itself, and so on. We carry out a full evaluation of delivery and performance, and compare our findings against what was promised.
Once that process is complete, our next step is to produce an ultimatum to the provider — an opportunity for them to turn the project around within a reasonable timeframe. This may come across as counterintuitive — after all, how does giving the provider one last go get you any closer towards project termination? However, this step is absolutely vital in establishing that all reasonable efforts were explored before pursuing the project termination route.
Even in the most disastrous of projects, we will always explore project recovery options. If nothing else, it strengthens your position (if legal proceedings become inevitable).
Resolution
Unfortunately (and unusually), the provider was unable to deliver on its promises subsequent to our ultimatum, and the process was escalated. We engaged with solicitor, Queen’s Counsel, and an expert aural witness in preparation for legal proceedings.
However, legal proceedings were ultimately not necessary — which is typically in the best interests of both parties. Once we had a compelling case for the provider’s complete failure to meet the terms of the contract, a mediation was organised, and a mutually agreeable outcome was agreed.
The settlement resulted in the client receiving three times the cost of the contract in compensation, and this result was achieved without the huge financial (and time) investment that a court case would have required.
The Benefits of Project Recovery Under All Circumstances
In our experience, a final (and cogent) attempt at project recovery is always advisable, if not mandatory, for two reasons:
- It may result in project recovery, or
- It provides a clearer path to positive legal resolution.
Having said that, we find that in the vast majority of cases, project recovery is the final solution. The above case study focused on a comprehensive failing by the provider. They had got themselves in a position where delivering on their original promises was essentially impossible.
But that is not typically the case. More typical IT issues relating to data migration, software configuration, behavioural shortcomings, functionality and so on, are all recoverable.
If however you do find yourself approaching litigation, your approach can make all the difference. When we were employed to resolve the situation described above, the threat of legal proceedings had already been rumbling on for a number of months. A focused approach to the issue with an eye to providing an acceptable solution to both parties resulted in a positive outcome within a short timeframe.
The Ideal Solution
I’d like to leave you with just one piece of advice — under all circumstances, you should look to avoid project recovery and termination. If you get off on the right foot with your provider, either outcome should be unnecessary.
If you would like to know more about creating mutually beneficial outsourcing relationships, you may be interested by the presentation I will be giving at the “What to do When IT Goes Wrong” conference mentioned at the beginning of this post. I will be covering the outsourcing of complex IT projects and programmes to expert providers for maximum benefit. Click here to find out more.
Creative Commons image courtesy of TheNixer
