Why transformation projects fail when needs are treated as fixed, known, and fully articulable from the start
Most transformation projects begin with a familiar assumption: the business already knows what it needs. Requirements are gathered, tools are shortlisted, and a project is launched around a stated set of goals. But in practice, that assumption is often wrong.
Companies rarely begin with fully formed, stable, and well-understood needs. Instead, needs are discovered under uncertainty. They are shaped by incomplete information, legacy processes, internal politics, coordination problems, and the way the problem itself is framed.
Without operational architecture, organizations do not scale transformation. They scale ambiguity.
1. Bounded Rationality: organizations do not decide from complete knowledge
Herbert Simon’s work on decision-making inside economic organizations remains one of the clearest starting points for understanding this problem. Simon argued against the idea that decision-makers operate with perfect rationality, complete knowledge, and unlimited computational ability. Instead, they operate under bounded rationality: they have limited information, limited attention, and limited ability to model consequences.
His research on decision-making within organizations was recognized with the Nobel Prize in Economic Sciences in 1978.
In practical terms, this means a company does not simply “know” what it needs before a transformation begins. What it has are partial descriptions, local incentives, inherited assumptions, and fragments of operational reality.
2. Framing effects: how a company defines the problem changes what it wants
Behavioral decision research adds a second important layer. Daniel Kahneman’s Nobel-recognized work, together with Amos Tversky, demonstrated that decisions under uncertainty systematically diverge from classical rational models. One of the most important insights is that framing matters: the way options and risks are presented changes how people evaluate them.
If a company frames its challenge as “we need AI,” it will see one set of solutions. If the same underlying problem is framed as “our operating model is fragmented,” it will see another.
3. Constructed preferences: needs are often formed during diagnosis
Paul Slovic’s work on the construction of preference is especially useful here. Slovic argues that preferences are often not simply stored inside people or organizations waiting to be revealed; rather, they are frequently constructed in the process of elicitation.
For companies, this means the same is often true of “needs.” A business may believe it needs automation, ERP, AI, dashboards, or workflow software. But those stated needs often evolve once the organization sees its own process boundaries more clearly.
4. Requirements uncertainty: the operational reality of systems projects
This problem is not only philosophical; it is also widely recognized in systems and software research. Research on requirements uncertainty and requirements volatility shows that incomplete, changing, or unclear requirements materially affect project performance and outcomes.
This is why transformation projects that begin too quickly with implementation often struggle. The issue is not simply bad project management. It is that the operating reality has not yet been made legible.
5. What this means for operational architecture
This is the reason operational architecture matters before automation.
The first task is not to automate everything quickly. The first task is to make the operating model visible and structured.
That is the logic behind the I|S|P Principle:
• Infrastructure Security creates the technical and operational boundary conditions. • Systems Architecture structures roles, workflows, data models, and system relationships. • Process Automation automates only what has been made legible and governable.
Conclusion
Companies often do not know what they need — yet. That is not a failure. It is a normal condition of decision-making under uncertainty. The mistake is to treat early stated requirements as if they were complete, fixed, and fully rational.
From there, transformation becomes less about buying tools and more about building the operational architecture that makes good decisions possible.
