18 months. Every time.
Ask ten companies how long their last BPM project took. You will hear: “Nearly two years.” “We stopped after 14 months.” “Technically finished — but whether it really runs, I couldn't tell you.”
That is no accident. No failure. And no sign of poor tools or incompetent consultants.
It is the structural result of a paradigm built on long timelines.
Step 1: the scope that inflates everything
Every BPM project begins with: “what should be documented?” Nobody knows exactly. So everyone gets invited. The scope grows. Before the first line is modeled, the project is already too big for three months.
That is called scope creep — and it isn't an exception but a predictable consequence: documenting processes for people means involving every stakeholder. So it takes time.
Step 2: the modeling phase that never ends
In practice: interviews get postponed because key people have no time. Models get reworked because “that isn't really how it is”. Teams don't agree — because every team does the process differently.
Every process produces discussions. Discussions produce change requests. Change requests produce new iterations.
Multiply that by 80 processes. You get 18 months.
Step 3: the change management nobody budgets for
Nobody changes their behaviour because a diagram says they should. So training arrives. Communication campaigns. Pilot rollouts. Feedback loops.
And here is the ironic part: after the change management, the process often still doesn't run the way it was modeled. Which means the documentation is out of date again after twelve months.
Step 4: the consulting model
This has to be named openly.
A consultant billing by the day has no financial interest in a project being finished in six weeks. That isn't a criticism of the industry — it is a systemic reality.
Project duration is directly proportional to revenue. Complexity justifies more resources. The incentive structures aren't built for speed.
Step 5: the integration that gets underestimated
In most projects, integration is planned as “phase 2”. Phase 2 begins when phase 1 is finished. Phase 1 is never really finished. So phase 2 never really begins.
The result: the BPM tool exists alongside the operational systems instead of with them. People have to switch between tools. The system is experienced as extra work, not as relief.
Why this isn't an inescapable fate
All of these factors share one cause: the paradigm.
If the goal is to document processes for people — then 18 months are logical and unavoidable.
If the goal is a different one — processes as a machine-readable data foundation for AI systems and automation — the arithmetic changes fundamentally:
- no need for human agreement on every model
- no change management for the whole organization
- no manual modeling — automated capture in days, not months
- no consulting model — SaaS instead of project work
The result: not 18 months to first results. Four weeks.
Not as a shortcut. As the consistent consequence of a different approach.