# The costliest assumption: We already know what we need

> Why good transformation does not begin with choosing a solution.

**Source:** https://pilot.isp.validatus.com/en/docs/die-teuerste-annahme
**Language:** en
**Published:** 2026-10-12
**Updated:** 2026-10-12
**Category:** Architecture
**Tags:** Requirements Engineering, Decision-Making

A company wants to use AI to speed up order processing.

The requirements have been defined. Vendors are being compared and budgets prepared. Everything suggests that the next task is to choose the right technology.

But imagine that a closer look at the workflows reveals something else.

Orders lose most of their time before or after data entry. They wait for approvals, pass through unclear responsibilities, or get stuck between the ERP, document management and individual departments.

AI could speed up individual steps.

**But would it solve the actual problem?**

Perhaps the project's most important decision was made before the problem was sufficiently understood.

## The request is clear. The problem may not be.

Companies make decisions with incomplete knowledge. This is not a new insight.

The economist Herbert Simon described this as *bounded rationality*: decisions are made with limited information, attention and time.

For transformation projects, this has an important consequence.

When a department says, "We need a new ERP", it is initially describing its view of a necessary change. A new ERP may indeed be the right solution.

But the problem may also lie in contradictory data, missing responsibilities, or processes that have never been examined together.

**A stated requirement is therefore not yet a tested diagnosis.**

## The question determines which solutions we see.

Amos Tversky and Daniel Kahneman showed how the way a decision is presented influences which options people prefer.

Applied to our example:

If we ask "Which AI do we need?", we examine models, vendors and features.

If we ask "Why does our order processing take so long?", we examine waiting times, system boundaries, decisions and information flows.

Both questions can be useful. But they lead to different investigations.

And potentially to very different investments.

**Sometimes the biggest improvement comes from asking a better question, rather than finding a better answer.**

## Requirements also emerge through understanding.

Research into requirements engineering suggests that requirements do not simply exist in full, waiting to be collected.

An empirical study by Ferrari, Spoletini and Debnath examined how requirements emerge and change during interviews and further analysis. Their findings suggest that requirements development is also a shared process of discovery.

This does not mean that every company misjudges its needs.

It means that a good transformation project needs room to test assumptions and incorporate new insights into decisions.

## What does this mean for architecture?

For us, this is where Infrastructure, Systems and Processes — **I|S|P** — come together.

Infrastructure establishes secure and resilient technical foundations.

Systems architecture makes applications, data, interfaces and responsibilities understandable.

Process automation starts where workflows and desired outcomes are sufficiently clear.

This does not have to become a preliminary project lasting several months. A focused look at a critical business process or a small prototype is often enough to test important assumptions.

Before a major investment, three questions should be answerable:

1. **What specific problem do we want to solve?**
2. **Where does it actually arise — and who is responsible for it?**
3. **How will we know that our change has succeeded?**

Only then can we determine whether a new platform, an integration, automation, AI, or an organizational change makes sense.

## Understand first. Then change.

Transformation does not require a company to know all the answers from the outset.

But it should know which assumptions underpin its next major decision.

Good architecture provides orientation. It makes connections visible, narrows uncertainty and helps shape change with purpose.

**The most important task is therefore not always to find a solution faster. It is first to make sure we are solving the right problem.**

---

### Scientific foundations

- [Herbert Simon — Rational Decision-Making in Business Organizations, 1978](https://www.nobelprize.org/prizes/economic-sciences/1978/simon/lecture/)
- [Amos Tversky & Daniel Kahneman — The Framing of Decisions and the Psychology of Choice, 1981](https://doi.org/10.1126/science.7455683)
- [Paul Slovic — The Construction of Preference, 1995](https://scholarsbank.uoregon.edu/items/8bfbe1ef-a008-470a-a730-625bfc00c192)
- [Ferrari, Spoletini & Debnath — How do requirements evolve during elicitation?, 2022](https://link.springer.com/article/10.1007/s00766-022-00383-7)

*The opening company example is hypothetical. The research establishes mechanisms of decision-making and requirements development, rather than a universal cause of transformation-project failure.*