What is the first thing you should think of doing when an IT project goes wrong, and what logical steps lead to a solution?
The resulting risks, of course, are numerous and should come to mind first, as they must guide your strategy for solving the problems. Ultimately, and of primary importance, there is a need to determine why the problems arose and to fix them, often by restructuring the project to ensure that they will not recur.
Having a system fail once it is up and running can have a serious impact. If the system cannot be resurrected quickly, there is a good chance of a loss of profits and other damage to your business. The longer the system is down, or its functionality substantially impaired, the greater the exposure.
Where the project is a work in progress, and bear in mind that various estimates put the failure rate of major IT projects at over 80 per cent, the risks may not be as immediate but the medium term impact of failing to deal with them strategically and effectively will be at least as significant.
If you are the person responsible for keeping the system running, or the project on track, your own career prospects may suffer unless the problems are fixed quickly and do not recur.
A failing IT (including outsourcing) project will usually be over budget, under spec or late. All three raise their own particular challenges and, just to make things more complicated, there is usually a trade off among them when a deal is renegotiated.
If your initial approach is to persevere with meetings and letters aimed at achieving compliance, you are moving in the right direction, but only in the very short term. If you do not move quickly to limit the exposure from more pernicious risks, you are likely to be increasing the costs to your company and placing a successful outcome in greater doubt.
In this article we will look at how to analyse and address the challenges which accompany a project failure.
While most of the following points deal specifically with the restructuring of a failing project which is a work in progress, they are relatively easily adapted to the situation where there has been a major failure in an already implemented and operational system.
In the same way, while the perspective adopted is that of the user, the points are generally applicable to the position in which a supplier would find itself as well.
Three main objectives come immediately to mind. The first is to solve the technical, commercial and legal problems and set out the solution in a clear and enforceable fashion.
The second objective, of equal importance, is to establish a record which ensures that you cannot be blamed for problems which are not your fault. A cynic would add a corollary in the form of a further goal; to make it appear that the other party is in fact to blame, regardless of where the fault lies.
This record is usually best prepared with the advice of a lawyer experienced in drafting from a project director's perspective, without disclosing to the other party that legal advice is being taken.
Creating a paper trail of legitimate, easily understandable points over the course of a failing project, often in routine, apparently innocent correspondence, becomes valuable when the parties renegotiate or if they ultimately litigate.
And the third objective is to use any weakness in the other party's position to renegotiate those provisions of the original contract which you found difficult to accept but could not get changed.
These objectives appear straightforward and, in principle, they should be just that. In practice, however, they can be particularly challenging to implement. Either side can have a hidden agenda.
Suppliers sometimes intentionally commit to delivering a product or service sooner than their development plans allow, for example.
In the same vein, users have been known to sign contracts in the knowledge that they have not finally made up their minds as to what they want (they may have the budget this year and need to spend it or lose it, for example) and expect the supplier to absorb the additional costs subsequent changes in expectations generate.
Lastly, major IT projects are rarely simple, especially given the interdependence of the user’s and supplier's obligations and the opportunity that this affords the parties to muddy the waters to their strategic advantage.
With that in mind, a frequent defensive strategy is for a party to ensure that the documentary record reflects that, for example, it could not complete its obligations on time because the other party had failed to live up to its part of the bargain.
Countering this kind of strategy is vital, and requires a careful analysis of both the contract and the parties' performance to date, and documentation of the logical and legally effective counter.
The team required to solve the problems of failing IT projects has three essential elements: technical, commercial and legal.
For obvious reasons, someone with a strong grasp of the technical aspects of the projects needs to be available to determine which changes to specifications and delivery dates will not dramatically alter the degree to which the project's own objectives are met. Where a change being considered could have a significant effect on achieving these objectives, careful analysis will also be required.
Someone with commercial skills is also required to deal with pricing and damages assessments. It may be uneconomic, for example, to push for full compliance with the original specification if the additional cost of doing so will be significant or the delay more than the user can accommodate.
And while it may be tempting for a party to insist on full compliance, this is generally only feasible where that party is demonstrably not in default. Furthermore, you may find that better liquidated damages and other remedies in the event of a further default, provisions which you are free to stipulate and may well win in a renegotiation, are worth giving up some functionality or enduring a delay.
Once a project is in trouble, legal advice from someone with expertise in restructuring IT projects and establishing a suitably documented position should be brought to bear sooner rather than later in order to develop and negotiate the solution.
After all, the legal implications of the groundwork you lay once a problem arises can make the difference between achieving a favourable solution and losing to a more experienced player.
Bear in mind, for example, that the party which insisted that its standard form be used for the contract, and which then typically resisted significant changes to it, did so because that contract was designed, among other things, to give it the best advantage in the face of its own default.
Now is your chance to develop a position which gives you the best chance of getting the changes you need to de-risk the project from your perspective.
As unappealing as a failing project is, good analysis, advice and strategy, and the proper implementation of a coherent restructuring plan, will generally leave you in a fully satisfactory technical, commercial and legal position going forward. And in many instances, that is a better result than starting again with a different supplier or user and litigating against the first.
