Principle 1 – Successful projects begin with responsibility, not just assigned roles
Many projects do not fail because of a lack of expertise, but because responsibility is unclear. This is where the first principle of successful projects begins: it is not enough to know who performs which task – what matters is who keeps the overall outcome in view.
There is a moment almost every project manager knows: the project has officially started. The project plan has been approved. The first workshops have taken place. The mood is positive.
At last, things are moving.
A few weeks later, the first important decision is due. And suddenly the project stalls. Not because the decision is particularly difficult, but because no one can say with certainty who is actually supposed to make it.
The business unit points to IT. IT points to architecture. Architecture points to programme management. Programme management points to the sponsor. Everyone involved is acting responsibly. And yet the project comes to a standstill.
From the outside, it often looks like a lack of willingness to make decisions. In reality, the problem is usually quite different:
Responsibility was distributed, but it was never truly brought together.
Many projects invest a great deal of time at the outset in role descriptions, organisational charts and RACI matrices. That is useful and necessary. Yet these tools often answer only one question: Who performs which task? The more important question surprisingly often remains unanswered: Who is accountable for the outcome?
There is a fundamental difference between these two questions. A task can be delegated; responsibility for project success can only be delegated to a very limited extent. This idea runs like a thread through Frank Gehry’s way of working.
Harvard Business Manager describes how, over many years, Gehry placed great emphasis on taking responsibility not only for the design of a building, but also on actively shaping the entire course of the project2.
At first glance, this could be interpreted as a desire for control.
I believe, however, that this interpretation falls short. Gehry was not trying to make every decision himself. He was ensuring that responsibility and outcomes were not lost at organisational handovers. Because that is precisely where much of the friction in complex projects arises.
Every additional interface increases the likelihood that information will be interpreted differently. Every handover carries the risk of delayed decisions or unclear responsibilities. This pattern can be observed time and again, especially in large transformation programmes.
The more organisational units are involved, the more important it becomes to have one person or a small leadership team keeping the overall outcome in view. Not as a central decision-making authority, but as the connecting element between the individual areas of responsibility.
Aus der Praxis
When introducing a cloud-based collaboration tool, I experienced exactly this situation. Management had approved the initiative in principle. For the project team, that meant: “We can start.”
Architecture interpreted the same statement differently: “The initiative is supported in principle. Technical approval is still pending.”
Information security, in turn, regarded the start of the project as the starting point for its own assessment.
Three areas, the same decision and three different interpretations.
Looking back, the problem was neither poor communication nor a lack of motivation. Everyone involved was acting responsibly.
What was missing was a shared understanding of which decision had actually been made – and which one was still pending.
That is precisely why a successful project does not necessarily begin with a project plan. It begins with a simple question:
Which decisions will need to be made over the course of this project – and who will take responsibility for them?
The more I thought about it, however, the clearer it became that even this question is not enough. Because even when responsibility is clearly defined, a second, often underestimated risk remains. Everyone knows who decides. But does everyone really understand the same goal?
That is where the second principle of successful projects begins.
