Damages in large IT projects Home


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

Accident

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

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 paper 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. Download latest version (pdf)   Download latest overview of data  (xlsx)

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 servers'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)    See more 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)

Oliver Metcalf-Rinaldo and Stephan Mosko Jensen, 2017: Learnings from the implementation of Epic

This paper gives details of one of the damaged projects, the health-record system EPIC. Download report (pdf),   Download appendix (pdf)

Soren Lauesen: Why EPIC was chosen, 2018

This paper investigates how the customer selected the health-record system EPIC, and why they didn't realize that work with the new system would be much slower in many of the medical areas. The report also includes a detailed time study in one of the medical areas. Download report - in Danish (pdf)