Principle 3 – Why models move successful projects forward
Complex ideas remain abstract as long as they are only described. Models, sketches and prototypes make differing interpretations visible and create a basis for shared decisions.
There is a moment that almost every project manager has probably experienced. After a workshop, everyone leaves the meeting room feeling that there is finally clarity.
The requirements have been discussed. The next steps have been agreed. The presentation is sent out. Everyone nods in agreement.
A week later, the same discussion starts all over again.
Not because anyone failed to listen or because information is missing, but because language is surprisingly imprecise. Terms such as modernise, migrate, operationally ready or go-live sound unambiguous. In reality, each person associates them with a slightly different picture.
Goethe already wrote: “Everyone hears only what they understand.” In today’s project organisations, that might look like this: the business thinks of new processes. IT thinks of new systems. Operations thinks of stable infrastructure. Management thinks of the business case.
Everyone uses the same words. And yet they are talking about different realities. This is one of the greatest challenges in complex projects. We overestimate the ability of documents to create shared understanding.
Documents convey information. Shared understanding only emerges when people develop the same mental picture. Frank Gehry seems to have understood this principle early on.
Harvard Business Manager vividly describes how intensively Gehry’s teams work with models, alternatives and simulations. Looking at these models, it would be easy to assume that their primary purpose is architectural precision. I have come to believe something else:
They are there to make thought processes visible.
A model does not initially answer the question “Is this the right solution?” It answers a much more fundamental question: “Do we all mean the same thing?”
That is where its real strength lies. A model exposes differences that often remain hidden in conversation. Suddenly it becomes apparent that the client and planners have interpreted the same requirement differently, that engineers are working from different constraints, or that an apparently clear decision has been understood in completely different ways.
These insights cost little during the concept phase. During execution, however, they can cost millions. Perhaps the greatest value of a model is therefore not that it provides answers. Its greatest value may be that it provokes the right questions.
Aus der Praxis
In innovation projects, I have repeatedly seen how dramatically discussions change as soon as an idea becomes visible. As long as teams only talk about a solution, the discussion often remains abstract.
Everyone fills in the missing details. Requirements are interpreted differently. Gradually, a different picture forms in each person’s mind.
But as soon as an initial sketch, a clickable prototype or a simplified process model is on the table, the conversation changes. Not because the model is already good, but because suddenly everyone is talking about the same reality.
Interestingly, our first models were rarely particularly mature. Their real value was that they exposed flaws in our thinking early. More than once, this led us to question assumptions that had previously been taken for granted. Looking back, those insights were often more valuable than the finished prototype itself.
This experience fundamentally changed my view of documentation. I used to think that documentation primarily served to preserve knowledge. Today I see its purpose in a more nuanced way.
Documentation records decisions. Models create shared understanding.
This is not a linguistic distinction. It reflects a fundamentally different understanding of collaboration. A specification answers the question: “What did we decide?” A model answers the much more important question: “Did we actually understand the same thing?” With AI, models can now also be created within a practical scope for projects of almost any size.
Projects should therefore visualise earlier and document later. Not because documentation is unimportant, but because shared understanding must always come before complete documentation.
Models do not reduce technical uncertainty. They reduce room for interpretation.
I believe this is one of the most successful principles in Frank Gehry’s approach. It is not the models themselves that make his projects exceptional, but the conversations those models create.
Innovation therefore begins not only with a good idea, but also with a shared picture.
And that shared picture often determines whether projects later move forward quickly – or repeatedly revisit the same misunderstandings. The next section shows how closely this is connected to the relationship between thorough preparation and speed of execution.
Because exceptionally successful projects do not work more slowly. They simply invest their time at a different point.
