Software should be built around the process, not the other way round.

Internal software projects rarely fail because the code was bad. They fail because the software encoded a process that existed on a slide, while the people doing the work followed a different one in spreadsheets, e-mails and phone calls. The result is a system that is technically finished and practically ignored.

The process on the slide versus the process in the room

Every organisation has two versions of a process. The documented one is linear, has clear roles and ends in a decision. The real one has exceptions, back-channels, a person who “just knows”, and a step that only exists because of an incident three years ago. Software built on the first version breaks on the second within a week.

The job before any design work is to find the second version. It is not in the documentation. It is in the room where the work happens.

How we find it

Follow one case end to end. Not a description of a case: an actual order, request or claim, from the moment it arrives to the moment it is closed. Sit with each person who touches it. Write down what they open, what they copy, who they ask and what they wait for.

Collect the workarounds. Every spreadsheet on a shared drive is a requirement nobody wrote down. Every “I keep a list” is a missing feature. Every “I ask Petra” is an undocumented rule that lives in one head.

Count the exceptions. If the “normal” path covers 60 % of cases, the other 40 % are the process. Design for them explicitly: which exceptions get a defined path, which get a human decision with the right information in front of them, and which get rejected at the door.

Name the decisions. Most processes are a chain of decisions with data movement in between. Each decision needs an owner, the information required to take it, and a place where it is recorded. That list is the backbone of the application.

What this changes in the software

• The data model follows the case, not the org chart. The central object is the thing being processed, with its states, decisions and history. Departments are roles on that object.
• States are explicit. “In progress” is not a state. “Waiting for supplier confirmation, due Friday, owner: purchasing” is.
• Exceptions have UI. The screen for the unusual case is designed as carefully as the screen for the normal one, because that is where the time goes.
• Integrations replace copy-and-paste. Every place where someone re-types data from one system to another is an integration on the backlog, prioritised by how often it happens.
• The first release is narrow and real. One case type, end to end, in production, with the people who followed the case. Then the next.

The measure of success

Not the number of features. The number of spreadsheets that were deleted, the number of e-mails that stopped, and whether the person who “just knows” can take a holiday.