Disaster, what disaster?

You are an established, reputable, medium-sized company. A year ago your board decided to upgrade your existing disparate computer systems by buying a 'unified package', 'lightly-customised', from a 'solution provider'. The new modified system was to be complete, installed and working, 3 months after the Contract Date.



You identified and chose the package, and the 'solution provider', on the basis of a somewhat hurried selection process – you did always mean to go and visit some other reference sites, and actually see the software live in action, and talk to some other (hopefully satisfied) customer. But you were always much too busy. Just like you always intended to get your company's end user staff members involved in the selection process. But didn't. Ditto preparing a full written Requirements Specification document.



The initial package installation was delayed by 4 months – it turned out that the 'light customisation' work needed was badly under-estimated by the solution provider's Project Manager. The system when finally delivered, late, and incomplete, was therefore implemented on a 'pilot' basis only. Problems with data migration from one of your company's key legacy systems then bedevilled running/testing during the pilot phase. Each party accused the other of failing to take responsibility for clean (or cleaning the) legacy data.



The working relationship between your own IT Manager and the supplier's Project Manager has deteriorated rapidly. And your end users are stubbornly refusing to love the new system, claiming it is more difficult, slow and cumbersome to use: "it frequently crashes and you can't trust the data anymore". You are beginning to lose some of your best staff to your competitors.



Now you've checked the Contract and find it is completely silent on data migration, data quality etc and who should/not be responsible for achieving it; also, as regards specifying 'non-functional requirements', such as system uptime and service levels, disaster recovery standards, performance and throughput targets, and user response times. Ditto user training.



You've been trying to run the pilot system for two months, and your board is "beginning to lose patience", as you euphemistically put it to the solicitors you've just consulted. The lawyers have advised that they should write a letter on your behalf giving the supplier 30 days' notice to "deliver a functionally complete, operationally reliable and contractually compliant" system. They further advise that, if the supplier then fails to do so, you would be entitled to reject the software and terminate the Contract.



They further say that you may then be able to sue the supplier for breach of contract, on the grounds that the system is "worthless and useless; and contains many fundamental design and other flaws, deficiencies, and further unresolved problems". Your board has insisted it would expect to claim for over £5m in compensation for losses and damages. The supplier has said he would vigorously defend any such claim, and will counter-claim for £750,000 of unpaid invoices and licence fees.



Either way, your company still does not have the nice new system its board wanted. You have taken to reading the job ads first in the morning newspaper, before the news or the sports pages…



Where did it all go wrong? Could you have planned to avoid such an IT Disaster?



NOW YOU CAN FIND OUT, by attending a new Course, 'Avoiding IT Disasters – the Expert Way'. On this two-day intensive seminar, workshop and clinic, being held at LE GRIMALDI Hotel, Nice, Côte d'Azur, France 17th –19th March 2005, you will be taught The Forensic Approach to assessing and dealing effectively with IT Project Risks: