Damages in IT projects, Soren Lauesen Home
Lauesen, Soren: Working paper: Damages and damage causes in large IT government projects
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). In this paper I report on findings in 5 large government projects in Denmark. The most catastrophic project caused the government to delay 10,000 million$ of debt for years. I identified 36 causes of damage, e.g. that project owners trusted tech hype or accepted a solution description without understanding it. I offer 20 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. And it is the only technical damage cause observed. The paper by Pagaard below, is a detailed investigation of two ways to integrate systems: The ideal SOA and the shared database. There are also detailed reports on some of the projects.
Pagaard, Christoffer: Master's thesis, 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. 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 it 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 seems a risk, but in practice it is not worse than the traditional approach. When reading the report, the reader should appreciate that Christoffer is almost blind.
Download report (pdf, in Danish)
Metcalf-Rinaldo, Oliver and Mosko Jensen, Stephan: Master's thesis, 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)
Lauesen, Soren: Why the electronic land registry failed
This paper gives details of one of the troubled 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)
Lauesen, Soren: Valg af EPIC, 2018 (in Danish)
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 these areas.
Download report (pdf)