Damages in large IT projects Home


Soren Lauesen: Damages and damage causes in large IT government projects

Accident

Accident
Damage: House smashed, 1 person killed.
Cause 1: Crane overloaded.
Cause 2: Faulty tilt sensor.
Cure: Always test sensor before work.

Accident

New health record system
Damage: Fewer patients per hour, 8000 frustrated clinicians . . .
Cause 1: Didn't plan the new work processes
Cause 2: Wanted everything at once . . .
Cures: Problem-oriented requirements,
Deploy part-by-part . . .

Large IT projects may be damaged in many ways, for instance large cost or schedule overruns, unsatisfied users, or disappointing business results. Sometimes the damages are so severe that the project is closed (complete failure). This report contains accident investigations of 5 large government IT-projects in Denmark. The most catastrophic project caused the government to delay 10,000 million$ of debt for years. We identified 37 causes of damage, e.g. that project owners trusted tech hype or couldn't see how far the supplier was. We offer 22 cures that might have prevented the damages.

The full report (pdf). A short version is published in IEEE Access, 2020: Soren Lauesen: IT Project Failures, Causes and Cures (pdf).

Related data: Overview of failure data  (xlsx), and in Danish: Oversigt  (xlsx)
Related sections on this site: Why the electronic land registry failed (below) and: Acquisition of the EPIC health record system

Service-oriented architecture (SOA) is often a cause of damage. Actually, it is the only technical damage cause we observed. The paper by Pagaard below, is a detailed investigation of two ways to integrate systems: The ideal SOA and the shared database.

Christoffer Pagaard, 2017: Service-oriented architecture versus shared database

This paper compares the IT architecture in two large Danish government departments: TAX and STAR (department of labor market, including management of unemployment benefit). Tax uses the ideal SOA architecture where an arbitrary collection of IT systems communicate with services. Data is not replicated, but each system retrieves what it needs from other systems. It may also need to update data in other systems. In contrast, STAR has a shared database managed by the department, but operated and maintained by changing IT suppliers. Around 50 IT systems in government and industry draw on the database with services. They may replicate data, but the reference data are the shared database.

The conclusion is that the shared database has many advantages, e.g. response time, availability and ease of maintenance. It could be improved by using Odata with SQL-like requests, rather than traditional specialized xml-services. Experience from other systems show that maintenance is vastly simplified with Odata. Instead of two parties having to negotiate a service, Odata allows the client party to define the services himself. Security and performance seem to be risks, but in practice it is not worse than the traditional approach.

One factor Christoffer ignores, is the need for testing the integration. When testing a client system, special test data in the server may be needed. However, this data must not disturb the server's normal operation. The testing problem exists in both architectures. When reading the report, the reader should appreciate that Christoffer is almost blind. Download report (pdf, in Danish)

Soren Lauesen: Why the electronic land registry failed

This paper gives details of one of the damaged projects, the electronic land registry. In 2009 Denmark got a compulsory IT system for Land Registration of ownership. It soon created a national disaster because selling houses and getting mortgages might take months. The press claimed it was yet another IT failure, but actually the IT system worked as intended. What was the real cause? The visible problem was overloaded staff in the Registry Office, but behind this were optimistic estimates of human performance, lack of usability, insufficient user interface requirements, unrealistic SOA requirements, immature risk analysis, and other factors. After 7 months, the registry had got rid of the backlog. The system has gradually been improved and today (2016) it is a success to society, although still hard to use for ordinary citizens. Download report (pdf)