Soren Lauesen's Own Website

Soren masters IT-requirements, UX, software acquisition, and business. He is helpful, constructive and innovative. He has experience from more than 100 projects and learns new application areas fast.

Updated 2023-01-31: New:  
The mini-course in user interface design had wrong links to the slide show. Now corrected: Mini-course.
Soren has changed mail address to: slauesen@os.dk
Several pdf-files had strange meta-data, making some pdf-viewers show strange document names. Now corrected.
The section on the User story experiment has been improved.
The report on project failures and cures is available here: Download latest report (pdf)   Download latest overview of failure data  (xlsx)   And in Danish: Seneste oversigt (på dansk)  (xlsx)


Soren Lauesen portrait Home
Søren Lauesen, professor emeritus
Nordtoftevej 15
DK-2860 Søborg
Phone +45 3956 1748
Mobile +45 2963 6248
Email: slauesen@os.dk
Web: www.itu.dk/people/slauesen/
Affiliation
IT University of Copenhagen
Rued Langgaards Vej 7
DK-2300 Copenhagen S
Phone, main: +45 7218 5000

About Soren

Project CV (pdf)   CV and interests   Publication list

Project failures and cures

Large IT projects may be damaged in many ways, for instance large cost or schedule overruns, unsatisfied users, or disappointing business results. I have investigated several large projects and identified 37 damage causes and 22 cures. The full report (pdf). The short version 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 (på dansk)  (xlsx)
Related sections on this site: Why the electronic land registry failed, Acquisition of the EPIC health record system

Want help to write problem-oriented requirements? Simply send a message to: slauesen@os.dk

Problem-oriented requirements - SL-07     Danish version

Traditional requirements describe what the system shall do. Problem-oriented requirements (SL-07 requirements) describe what the system is to be used for. They cover all kinds of requirememts, are five times shorter, five times faster to write, and five times faster to reply to. Y-Foundation requirements   CMS requirements   Use cases vs. SL-07 tasks   Textbook and papers

User story experiment

My colleagues in industry and universities praise user stories and epics, as the way to write requirements. But there is no agreement on how to use them and how they cover requirements. The inventors of "user stories" were academics, who had tried them on toy systems with students.

In cooperation with Mohammad Kuhail, I compared 8 requirements specifications written by 8 professional analysts for the same real-life project: A support system for a hotline. The analysts had got an analysis report mentioning 30 functional issues the customer wanted the system to deal with. They could use user stories and whatever else they found needed. They could ask us questions, as they could do in a real project, but nobody did.

In their replies, they used user stories and epics only. We asked the analysts whether they covered all requirements and to our surprise, they all said "yes". However, on average, their specifications covered only 10 of the 30 functional issues the customer had stated (ranging between 5 and 13 issues). Further, user stories hardly mentioned any of the non-functional requirements needed too, such as usability, data migration and phasing out. Many user stories were wrong: they specified something the customer definitely didn't want. See more

IT Contracts for IT people (in Danish)

Requirements are often appendices to long contracts. IT-people don't read the contract and lawyers don't read the requirements. It need not be so. SL-07 requirements have an 8 page contract with 4 appendices. Together they cover what traditional 50 page contracts with 16 appendices do.

UX versus User Interface Design

There is a big gap between UX specialists and software developers. UX specialists are good at identifying user needs and testing whether usability of the user interface is adequate. However, they are rarely able to design intuitive and efficient user interfaces. Nor are programmers. There are no systematic design methods. At best it is trial-and-error. Around 2005, Lauesen invented a design method (Virtual Windows) that gives a minimum of user screens, good data overview, efficiency for professional users, and fast development. The health record screen at the right was developed with this method. Mini-course in the method   Some great user interfaces   Microsoft Access tutorial   Other UX papers

Data visualization, End-user development and EHR

Professionals need overview of complex data, so good data visualization is crucial. Uvis is a tool that allows IT-interested users to develop interactive, complex data visualizations. The health record screen at the right was made this way. Visualization papers

EHR - Electronic health records

Lauesen has been involved in many aspects of EHR. Here are some links: The early national EHR strategy   Graphical and customizable EHR   Anonymizing an EHR   Troubles with the EPIC acquisition   Time study of EPIC in the clinic  

IT architecture and software engineering (in Danish)

Lauesen has worked in software engineering since 1962. He wrote his first tutorial in 1969, developed operating systems, studied why SW research wasn't used in industry, how perfectionism killed usefulness, and fought hype about OO, SOA and IT-architecture.

One of my interests
I am at the left

Guide to SL-07
Cover of Requirements SL-07

Uvis health record
Uvis health record

User interface design
Cover of User Interface Design