Treating football like long jump
- Claas
- 23 hours ago
- 6 min read
Updated: 9 hours ago
Not everything is a process
Processes are usually the starting point in IT projects. Before anything is built, work gets described as a flow, often end-to-end, with the assumption that structure comes from defining the right sequence. Workshops focus on mapping steps, dependencies, and handovers. Diagrams are produced. The expectation is that once the process is clear, system design and responsibilities follow.
In practice, these processes rarely drive execution once the project moves forward.
They exist, they are documented, sometimes in detail, but they are not what determines how work actually gets done. Day-to-day work follows a different logic, shaped more by situations, decisions, and constraints than by a predefined sequence. The gap is usually visible quite quickly, but it is rarely addressed directly, because the process itself is still treated as the reference point.
Where processes work well
Processes work well when the work itself is stable. Configuring systems requires structure, because workflows need defined steps, transitions, and conditions. Without that, automation breaks down and responsibilities become unclear. Where activities repeat and variation is limited, this structure maps to reality and does not feel artificial.
Typical examples are finance operations or structured service processes, where tasks follow a consistent pattern, inputs and outputs are predictable, and exceptions are the minority rather than the norm. In these environments, a clear sequence reduces ambiguity, supports handovers, and makes both system behavior and human interaction easier to manage.
The benefit is not just technical. A well-defined process creates alignment across teams, because everyone shares the same understanding of how work should move from one step to the next. Decisions become simpler, escalation paths are clearer, and performance can be measured against a defined flow instead of individual interpretation.
In that setup, the process is not just documentation. It effectively becomes the operating model.
Where the model breaks down
The same logic breaks down when the work does not behave that way. Projects still invest heavily in defining a clean process upfront, trying to make it coherent and complete, but once execution begins, the model starts to drift. The sequence looks right on paper, yet it cannot absorb what actually happens once different situations, dependencies, and constraints come into play.
The reason is structural, not behavioral. The work itself does not follow a stable pattern, so a fixed sequence becomes something teams have to work around instead of work with. Steps get reordered or combined, loops appear, decisions move outside the defined flow, not because people ignore the process but because the situation requires it.
Adding more detail does not help. The more granular the process becomes, the harder it gets to use. Edge cases multiply, exceptions grow, and the model ends up trying to capture everything while guiding very little. What remains is a gap between model and execution that tends to widen over time rather than close.
Long jump and football
Long jump looks like a process. There is a defined structure (run-up, take-off, flight, landing), often with a fixed number of steps in the run-up. The sequence is clear and can be described without much ambiguity, which makes it look very similar to how processes are modeled in systems.
But performance does not come from executing that sequence mechanically. It depends on constant adjustment within the structure: correcting stride length during the run-up, timing the take-off precisely at the board, reacting to small deviations, controlling the body in flight and landing. The structure provides orientation, but execution is driven by continuous decisions.
Football works differently.
There are rules, roles, and a few structured situations like kick-off or corners, but the game itself does not follow a predefined sequence. It is shaped by decisions, interactions, positioning, and tactics, where every action depends on what just happened. The flow emerges from the situation rather than from a defined path.
Both have structure, but of a different kind. Long jump has a clear sequence with adaptive execution. Football has structure without sequence.
In IT projects, a lot of work behaves more like football than like long jump, even though it gets modeled as long jump.
What happens instead
The gap between model and execution is usually visible, but it tends to get interpreted as a discipline issue, as if better adherence to the process would close it. In practice, stricter enforcement rarely improves the situation. It increases friction, slows teams down, and pushes even more work into informal paths.
What teams actually do is adjust. They follow the process where it fits and step outside it where it does not, often within the same case. Steps are combined, skipped, or revisited. Decisions are taken earlier or later than planned. Certain situations get handled outside the system because the defined flow does not cover them in a usable way.
This is not a one-off exception. It becomes the normal way of working. The process stays in place, but execution is driven by context, dependencies, and judgment. What stabilizes the work is not tighter control of the sequence, but the ability to adapt it. Teams build their own ways of handling variation, sometimes explicitly, often implicitly. That is what keeps things moving, even when the formal model suggests something different.
What process mining shows
Process mining sometimes makes the gap visible. Instead of a single, clean flow, you see how cases actually move through the system, and that usually means a range of different paths rather than one dominant sequence. Variants appear, loops show up, steps are skipped or repeated. The idea of one consistent process becomes hard to defend.
This often gets framed as a transparency problem, as if more data would resolve it. But the data already tells the story:
The variation is not noise around a stable core, it is the normal behavior of the system.
The typical reaction is to simplify, standardize, or enforce the process more strictly. That only works if the variation is truly unnecessary. In many cases, it is not. It reflects different situations, dependencies, and decisions that cannot be reduced to a single path without losing what makes the work effective.
Process mining answers the question of what is happening. It does not answer how to structure it. Seeing variation does not tell you whether to reduce it, accept it, or design for it.
A different structure
A process is one way to structure work, but it assumes the path is known in advance and that most cases follow it with limited variation. Where that assumption does not hold, a different structure works better.
Instead of describing a fixed sequence, it is more useful to describe states, rules, and decisions. States define where you are in the overall context, independent of how you got there. Rules define what is allowed, what is required, and what constraints apply. Decision points make explicit where choices need to be made and what information those choices depend on.
A claims case in insurance is a useful illustration. There is no single sequence that fits all cases. A claim can be in states like reported, under review, awaiting documentation, in expert assessment, in negotiation, or closed. Rules govern what can happen in each state: what evidence is required, which approvals apply, when escalation is triggered. Decision points are explicit: cover yes or no, settlement amount, whether to involve an external assessor. Different cases take different routes through the same model without breaking it.
This shifts the focus from controlling the path to enabling movement within a defined space. Systems can still support this, but in a different way. Instead of enforcing a linear workflow, they guide decisions, provide context, and make sure rules are applied consistently. The structure remains, but it adapts to variation instead of trying to eliminate it.
Where this leaves things
To be clear, this is not an argument against processes. That would be absurd. They are often the right solution. They provide clarity, enable systems and create alignment. Where the work follows a stable sequence, a well-defined process works and should be used.
But the starting point should be the nature of the work, not the process. This sounds obvious, but it is rarely done in practice. The process gets defined first, and only later does it become clear whether it fits. By then, the model is already in place and difficult to change, so teams start working around it.
The actual decision is straightforward in principle. Does the work follow a stable sequence or not. If it does, define the process and use it as the backbone. If it does not, do not try to force it into one. Design for states, rules, and decisions instead. Not everything needs a process.
In many situations, a lighter structure is enough. Clear rules, defined conditions, and guidance for specific situations can provide orientation without forcing everything into a fixed sequence. That leaves room for variation where it is needed, while keeping consistency where it matters.
The question is not whether to use a process. It is whether the work behaves like one.
Comments