Organizations want to innovate faster. New technologies, data, and digitalization offer plenty of opportunities. At the same time, we see that the step from idea to working solution is often difficult. In practice, I notice that this is particularly the case in environments with a lot of governance and where solutions must be fixed in advance.
The cause rarely lies in technology. The problem lies in how we organize the path from need to realization.
In theory, that path seems logical and structured. In practice, it is iterative, uncertain, and highly dependent on the context in which a solution must land.
The logical route on paper
In many situations, everything starts with a concrete need:
- a bottleneck in an operational process
- a desire to work more efficiently
- an ambition to make better use of data
From a design and chain perspective, the next step is logical:
- organize design sessions
- develop a service blueprint
- translate into epics and backlog items
- start with realization
This approach ensures structure and coherence. But what seems logical on paper often does not align with how organizations actually work.
The reality: steering based on certainty rather than insight
Many organizations are structured around:
- pre-approved solutions
- clear scope and budget
- minimal uncertainty at the start
As a result, the focus quickly shifts to: “What are we going to build?”
While the most important question remains unanswered: “What works in practice?”
This leads to a recognizable pattern:
- solutions are designed based on assumptions
- validation only takes place during realization
- insights arrive too late to make effective adjustments
The consequence is rework, delays, and solutions that do not sufficiently align with operations.
The core error: linear thinking in an iterative reality.
Innovation does not proceed linearly. It is a process of exploring, formulating assumptions, testing in practice, and learning. Yet, we often try to organize this process as a straight line. That is where the tension arises.
What works: combining design and validation
A more effective approach explicitly acknowledges uncertainty and builds validation in before realization. In my current assignment, I see that this validation step is often skipped, even though that is precisely where the greatest gains lie in terms of quality, consensus and effectiveness.
The Role of the Business Analyst
The Business Analyst plays a key role in this, not as a translator of requirements, but as a director of the process from need to realization.
In practice, this means that the Business Analyst:
- asks the right question before solutions are devised
- makes assumptions explicit and validates them
- ensures that initiatives are part of a coherent chain
In doing so, the role positions itself clearly before the realization phase, where the most value is determined.
Conclusie
The path from need to realization is rarely linear. Organizations that work iteratively and validate early realize value faster.
Pascal Speek
Business Analist