Avoid twenty-first century shocks
3 November 1997
10 June 2013
24 April 2013
19 June 2013
14 October 2013
1 February 2013
While the year 2000 issue is easy to understand, the solution is messy - many companies will have thousands of programs to check - and the problem has an immoveable deadline. It may well take between 30 and 60 per cent of IT project budgets to resolve the problem. This will either result in a massive overspend on IT or in resources being diverted from new system development; both options will require strong management.
However, observers have been dismayed at the level of complacency displayed by many organisations, especially given the fact that many companies may now have only one chance to solve this problem and will not be able to rely on the experiences of others to show them the way.
If suppliers are not forthcoming with appropriate solutions, businesses will need to consider self-help solutions and, possibly, recourse to law. However, it is important to realise that the law will not provide a technical solution to the problem.
If a year 2000 problem is discovered, suppliers and users should check the original contracts, specifications and invitation-to-tender documentation for the software to see if any express reference is made to dates into the next century. However, even without an express reference, year 2000 compliance may be implied in contracts for software designed to calculate dates into the next century, such as those dealing with long term-financial policies, because any supplier exercising reasonable skill and care should have designed the software to be year 2000 compliant.
As well as contractual claims, it may be possible to bring claims under the tort of negligence if the supplier fails in its "duty of care" to the user, provided that the damages which result are foreseeable. Clearly any exclusions of liability in contracts between the supplier and user regarding negligence and implied terms will be valid only if the exclusions are reasonable. Suppliers may also benefit from get-out clauses which will enable them to withdraw support, either on notice or on the basis that the user has not complied with the terms and conditions of the support contracts.
It is also important to consider the time of the claim. In contract, the limitation period will run from the time of the breach, that is, six years from the date of the contract.
Therefore, it may be difficult to bring any claims for pre-1991 contracts and, in practice, for many pre-1993 contracts which predate the first public airing of this issue.
On the other hand, in tort, negligence claims may be brought within six years from when the damage occurs or, if the damage is latent, within six years of the damage occurring or within three years from when the damage was reasonably discoverable. Thus, some claims may well be statute-barred by 2000.
Therefore, regardless of the outcome of any legal arguments on limitation periods, prudent businesses should analyse their contracts sooner rather than later if they do not wish to rule out the possibility, or cost effectiveness, of making any legal claim.
Essentially, any business which attempts to bury its head in the sand will be prejudiced.
Finally, a supplier's liability will also be reduced to reflect the user's duty to mitigate its loss. For example, if the user has ignored advice supplied to it regarding 'workarounds' and so on, it may not be able to claim for its resulting loss.
While the cost or resolving the issue is initially likely to be shared by suppliers and users, the cost of the year 2000 problem will surely eventually be passed on to users through higher licence and service charges in the future.