Disaster but no recovery?

You are the CIO of a company whose board, a year ago, agreed with your recommendation to upgrade existing computer systems by buying an "ERP-like package", "lightly-customised", from a "solution provider".

Castell_Stephen150You are the CIO of a company whose board, a year ago, agreed with your recommendation to upgrade existing computer systems by buying an "ERP-like package", "lightly-customised", from a "solution provider".
Using a hurried selection process, you had identified and chosen the package and the provider. You meant to visit reference sites, but were too busy; and intended to involve your company's end-user staff in selection. But didn't. Your operations managers never completed that full written requirements specification. Your lawyers only had time for a "quick look" at the contract.

In the event, the package installation is severely delayed - the "light customisation" work needed is badly underestimated by the supplier's project manager. When finally delivered, the incomplete system is implemented on a "pilot" basis only. Problems with data migration from one of your company's key legacy systems bedevil system testing during pilot running.

Each party accuses the other of failing to take responsibility for cleaning the legacy data. Your working relationship with the supplier's project manager has badly deteriorated. End-users refuse to love the new system, claiming it is more difficult, slow and cumbersome to use.

Performance 'non-functional'

Now you have checked the contract and find it is silent on data migration, data quality, and who is responsible for achieving it. Same story, as regards "non-functional requirements", such as performance and end-user response times. Ditto user training...

Your board is "losing patience", as you euphemistically put it to the litigation lawyers you've just consulted. They advise writing a letter on your behalf giving the supplier 30 days' notice to deliver a "functionally-complete, operationally-reliable and contractually-compliant system". If the supplier then fails to do so, you could terminate the contract.

You may then be able to sue the supplier for breach of contract, claiming the system is "worthless and useless". Your board insists it would want well over £5m in compensation.

The supplier tells you it will vigorously defend any such claim, and will counter-claim for £750,000 of unpaid invoices. It contends it is your own failure to analyse and define your business processes and system requirements, to provide clean legacy data and to collaborate in achieving a successful project that are to blame. And there is nothing wrong with the software package. "How can there be, when it is installed, 'tried and tested', at 20 other sites?" it asks.

Heed the eight warning flares!

It adds that there were so many changes in requirements insisted upon by your company that its programmers had to "write and test masses of new code". Furthermore, it alleges your end-users refused to learn the new software. Its lawyers have told it the courts have ruled there is an obligation on a customer to co-operate with a supplier in achieving the success of an IT project - which your company has woefully failed to do.

Either way, your company still does not have the nice new system its board wanted. You have taken to reading the job ads...

Call yourself an IT professional? If only you had paid early heed to the forensically-established "eight red warning flares of the IT disaster project", and checked if any of these things were absent:

  • Statement of requirements
  • Prioritisation of most important requirements (those that will have the most serious business consequences if not delivered)
  • Data transfer/migration specification (what? who? new software needed? how to test integrity, completeness and accuracy of data?)
  • Capacity and performance requirements (end-user response times, throughput)
  • System cycle (what are the business's true critical needs and operational deadlines?)
  • End-user training (plans, timetable, materials, data)
  • Acceptance criteria (clear plans, processes, materials)
  • Project-management roles, responsibilities and processes

Each of these key things should be in writing: clear, comprehensive, detailed, unambiguous - and in the contract from the start. Otherwise, make ready for that IT disaster - and the litigation that could all so readily follow it...

Stephen Castell is chairman of Castell Consulting


Read more on IT project management