When a digital initiative fails, the code is almost never the reason.
This shows up with remarkable consistency in retrospectives. The software largely works. The requirements were not absurd. The team was not incompetent. And yet less happened than expected, it took longer, and the impact the initiative was started for is hard to demonstrate.
The reason sits in an inconspicuous place: the transitions. Wherever responsibility moves from one group to the next, a gap appears. And gaps have no owner.
That observation is the foundation of our work. We build software — and we take care of the transitions where software otherwise stays ineffective.
Transition 1: from decision to domain
Management decides that a process will be digitised. What should follow is precise descriptive work: what actually happens in this process, with which exceptions, and which of it is essential?
What often happens instead: the decision is translated into a requirements document that describes the existing way of working rather than the domain reality — including every workaround that grew out of the weakness of the old system. You end up automating the past.
What helps here is joint modelling with the people who own the process, in a representation both sides can read. Event modeling is our preferred tool for that, because it orders events in time instead of abstracting data structures.
Transition 2: from domain to delivery
This is where technical quality is decided — but less through the choice of technology than people assume. What matters is whether questions keep being asked during delivery.
Every team hits cases while building that did not appear in the analysis. The only question is what happens then: does somebody ask, or is a plausible assumption made so work can continue? Assumptions are cheap in the moment they are made and expensive once they have settled into data structures.
That is why we consider ownership the most important factor in this phase: a named person who decides technically, documents the reasoning and voices uncomfortable findings early.
Transition 3: from delivery to use
This is the most thoroughly underestimated transition. A system goes live, there is training, maybe a guide — and then the real competition starts: the new system against the familiar way of working.
People do not switch because something is theoretically better. They switch when their own work becomes noticeably easier, early enough to justify the effort of changing.
In practice that means:
- Every user group needs an early, concrete gain.
- The people who get asked internally must be convinced — not just management.
- There must be named responsibility after go-live, or the system is orphaned.
- Resistance is information, not interference. It often points at a real design flaw.
Where this transition fails, you get the classic finding: the system runs, but next to it sits a spreadsheet where the actual work happens.
Transition 4: from use to impact
A used system is not yet an effective system. Impact means something has measurably changed — cycle times, error rates, conversion, effort per case.
This transition usually fails on a simple omission: nobody defined beforehand how success would be recognised. Without a baseline, improvement can neither be shown nor doubted — which also removes the basis for continuing or stopping an initiative.
This is not about elaborate metric frameworks. Two or three honest numbers, captured before the start, are almost always enough.
Why four capabilities belong together
These transitions are the reason we do not treat software engineering, marketing, sales and people as four offerings side by side, but as one connected task.
Engineering delivers the system. Marketing and positioning make its value explainable — outwards and inwards. Sales creates agreement, internally with stakeholders and externally in the market. People and culture decide whether the organisation can carry the change at all.
Remove one of these sides and you get the familiar state: good software without impact — or large promises of impact without technology that holds.
What follows from this
Assess an initiative not only by its progress, but by its transitions. Four questions are enough for a first honest read:
- Is the domain described in a way the business could confirm?
- Is there a named person responsible for the technical course?
- Does every user group know what concretely gets better for them?
- Was it defined beforehand how impact would be recognised?
Wherever one of these questions stays unanswered, that is most likely where the risk sits — regardless of how good the code is.
← Back to insights