{"id":4945,"date":"2026-08-07T23:55:18","date_gmt":"2026-08-07T21:55:18","guid":{"rendered":"https:\/\/michael-hoepfl.com\/unkategorisiert\/four-principles-for-successful-projects\/08-2026\/"},"modified":"2026-08-11T14:47:41","modified_gmt":"2026-08-11T12:47:41","slug":"four-principles-for-successful-projects","status":"publish","type":"post","link":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/","title":{"rendered":"Four Principles for Successful Projects"},"content":{"rendered":"\n<blockquote class=\"wp-block-quote is-style-plain is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><em><strong>Most projects do not fail during execution. They fail in the way they begin.<\/strong><\/em><\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity is-style-default\"\/>\n\n\n\n<p class=\"wp-block-paragraph\">Why do some successful projects seem to run almost effortlessly, while others repeatedly stall despite experienced project managers, detailed project plans and sufficient budgets? It is a question I keep coming back to in my work as a project manager.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">And this is not just about IT projects. Over the past few years, I have seen similar patterns in transformation programmes, organisational development, infrastructure projects and even when looking at architecture or major public projects. The circumstances differ considerably \u2013 the underlying challenges surprisingly little. That is precisely why it is worth looking beyond our own discipline.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\"><strong>What can an architect teach a project manager about successful projects?<\/strong><\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">Probably more than one might initially expect. The starting point for this article is a piece in <em>Harvard Business Manager<\/em> about the architect Frank Gehry<sup data-fn=\"fa6ff816-5cd3-4552-96fc-02e3e4932bfe\" class=\"fn\"><a href=\"#fa6ff816-5cd3-4552-96fc-02e3e4932bfe\" id=\"fa6ff816-5cd3-4552-96fc-02e3e4932bfe-link\">1<\/a><\/sup>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The more I explored Gehry\u2019s way of working, the more often I found myself thinking about my own projects. Not because IT projects and architecture face the same challenges, but because they share something fundamental: people have to create something together that did not exist before.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">That is precisely why it is worth looking beyond our own discipline.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">In this article, I bring together insights from project research, management literature and my own project experience. The aim is explicitly not to summarise individual sources, but to develop an independent perspective on successful projects.<\/p>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<blockquote class=\"wp-block-quote is-style-plain is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>A project does not begin with its official start. It begins the moment people start thinking about the same task. And that is often where the first risks already emerge.<\/strong><\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">Ask project managers when a project begins and you will usually hear similar answers.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>&#8220;<em>With the project mandate.<\/em>&#8220;<\/li>\n\n\n\n<li>&#8220;<em>With the kick-off.<\/em>&#8220;<\/li>\n\n\n\n<li>&#8220;<em>With budget approval.<\/em>&#8220;<\/li>\n\n\n\n<li>&#8220;<em>With the first entry in the project plan.<\/em>&#8220;<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The longer I have worked with projects, however, the more I have felt that these answers are understandable \u2013 but miss the crucial point.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\"><strong>What Frank Gehry teaches us about successful projects<\/strong><\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">When I read the <a href=\"https:\/\/www.manager-magazin.de\/hbm\/strategie\/von-frank-gehry-lernen-vier-regeln-fuer-erfolgreiches-projektmanagement-a-4473d0df-2d6e-4163-8b4f-474c5a8ef20a\" data-type=\"link\" data-id=\"https:\/\/www.manager-magazin.de\/hbm\/strategie\/von-frank-gehry-lernen-vier-regeln-fuer-erfolgreiches-projektmanagement-a-4473d0df-2d6e-4163-8b4f-474c5a8ef20a\">article <em>\u201cNo One Planned Better Than Frank Gehry\u201d<\/em> in <em>Harvard Business Manager<\/em><\/a>, I initially expected a piece about an exceptional architect and his work.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">I was surprised. The real subject of the article was project management.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Bent Flyvbjerg and Dan Gardner describe Frank Gehry\u2019s way of working against the backdrop of decades of research into major projects. Their central observation can be summarised as follows:<\/p>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<blockquote class=\"wp-block-quote is-style-plain is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Exceptionally successful projects are not different because they are less complex. They are different because of how they deal with complexity.<\/strong><\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">They bring together people with different perspectives to develop something that did not exist before. That is their real common denominator. It is therefore not about the technology or the industry, but about dealing with uncertainty. And that is precisely why project managers should look beyond their own discipline.<\/p>\n\n\n\n<!--nextpage-->\n\n\n\n<h1 class=\"wp-block-heading\">Principle 1 \u2013 <strong>Successful projects begin with responsibility, not just assigned roles<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\"><strong><strong>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 \u2013 what matters is who keeps the overall outcome in view.<\/strong><\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">At last, things are moving.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">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 <em>who is actually supposed to make it<\/em>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">From the outside, it often looks like a lack of willingness to make decisions. In reality, the problem is usually quite different:<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">Responsibility was distributed, but it was never truly brought together.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">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: <em>Who performs which task?<\/em> The more important question surprisingly often remains unanswered: <em>Who is accountable for the outcome?<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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\u2019s way of working.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Harvard Business Manager<\/em> 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 project<sup data-fn=\"3d682157-50c0-4bff-89c2-d56a4dca4a1c\" class=\"fn\"><a href=\"#3d682157-50c0-4bff-89c2-d56a4dca4a1c\" id=\"3d682157-50c0-4bff-89c2-d56a4dca4a1c-link\">2<\/a><\/sup>.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">At first glance, this could be interpreted as a desire for control.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\t\t<!-- begin AlertsDLX output -->\n\t\t<style>\n\t\t\t#alerts-dlx-daba7218 {\n\t\t\t\tmax-width: 650vw;\n\t\t\t\t--alerts-dlx-base-font-size: 14px;\n\t\t\t\t--alerts-dlx-bootstrap-base-size: 14px;\n\t\t\t}\n\t\t\t#alerts-dlx-daba7218 .alerts-dlx-icon-preview svg {\n\t\t\t\tmax-width: 1.8em;\n\t\t\t\tmax-height: 1.8em;\n\t\t\t}\n\t\t<\/style>\n\t\t<div\n\t\t\tclass=\"alerts-dlx template-bootstrap is-style-warning is-appearance-default icon-vertical-align-top aligncenter\"\n\t\t\tdata-expiration=\"0\"\n\t\t>\n\t\t\t<figure\n\t\t\t\trole=\"alert\"\n\t\t\t\tclass=\"alerts-dlx-alert alerts-dlx-bootstrap alerts-dlx-has-icon alerts-dlx-has-description\"\n\t\t\t\tid=\"alerts-dlx-daba7218\"\n\t\t\t>\n\t\t\t\t\t\t\t\t\t<div class=\"alerts-dlx-icon alerts-dlx-icon-frontend\" aria-hidden=\"true\">\n\t\t\t\t\t\t<div class=\"alerts-dlx-icon-preview\">\n\t\t\t\t\t\t\t<svg xmlns=\"http:\/\/www.w3.org\/2000\/svg\" fill=\"currentColor\" class=\"bi bi-lightbulb-fill\" viewbox=\"0 0 16 16\"><path d=\"M2 6a6 6 0 1 1 10.174 4.31c-.203.196-.359.4-.453.619l-.762 1.769A.5.5 0 0 1 10.5 13h-5a.5.5 0 0 1-.46-.302l-.761-1.77a1.964 1.964 0 0 0-.453-.618A5.984 5.984 0 0 1 2 6zm3 8.5a.5.5 0 0 1 .5-.5h5a.5.5 0 0 1 0 1l-.224.447a1 1 0 0 1-.894.553H6.618a1 1 0 0 1-.894-.553L5.5 15a.5.5 0 0 1-.5-.5z\"><\/path><\/svg>\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<section>\n\t\t\t\t\t<h2 class=\"alerts-dlx-title\">Aus der Praxis<\/h2>\t\t\t\t\t<div class=\"alerts-dlx-content-wrapper\">\n\t\t\t\t\t\t\t\t\t\t\t\t\t<div class=\"alerts-dlx-content\">\n\t\t\t\t\t\t\t\t<p class=\"wp-block-paragraph\">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: <em>\u201cWe can start.\u201d<\/em><\/p>\n<p class=\"wp-block-paragraph\">Architecture interpreted the same statement differently: <em>\u201cThe initiative is supported in principle. Technical approval is still pending.\u201d<\/em><\/p>\n<p class=\"wp-block-paragraph\">Information security, in turn, regarded the start of the project as the starting point for its own assessment.<\/p>\n<p class=\"wp-block-paragraph\">Three areas, the same decision and three different interpretations.<br \/>Looking back, the problem was neither poor communication nor a lack of motivation. Everyone involved was acting responsibly.<\/p>\n<p class=\"wp-block-paragraph\">What was missing was a shared understanding of <em>which decision had actually been made \u2013 and which one was still pending<\/em>.<\/p>\n\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/section>\n\t\t\t<\/figure>\n\t\t<\/div>\n\t\t<!-- end AlertsDLX output -->\n\t\t\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p class=\"wp-block-paragraph\">That is precisely why a successful project does not necessarily begin with a project plan. It begins with a simple question:<\/p>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<blockquote class=\"wp-block-quote is-style-plain is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong><strong>Which decisions will need to be made over the course of this project \u2013 and who will take responsibility for them?<\/strong><\/strong><\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">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 <em>who<\/em> decides. But does everyone really understand the same goal?<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That is where the second principle of successful projects begins.<\/p>\n\n\n\n<!--nextpage-->\n\n\n\n<h1 class=\"wp-block-heading\">Principle 2 \u2013 <strong>Successful projects first create a shared understanding<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Misunderstandings rarely arise because people are pursuing different goals. Far more often, everyone believes they are talking about the same thing \u2013 while each person understands something different. Successful projects therefore invest early in a shared vision of the target state.<\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p class=\"wp-block-paragraph\">There is a sentence I hear again and again in projects: <em>\u201cWe all know what this is about.\u201d<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Almost every time, this sentence is spoken shortly before it becomes clear that this is exactly what is not true. The fascinating thing is that no one is misleading anyone.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Everyone is convinced they understand the goal. And yet, weeks or months later, discussions arise about what was actually supposed to be delivered.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Did \u201cmigration\u201d mean the technical transition, or the organisational rollout as well? Does \u201cgo-live\u201d mean that a system is available in production \u2013 or that the business can actually work with it? Is a project complete when the last piece of software has been installed, or when the customer has achieved the expected benefit?<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">Questions like these may sound trivial.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">In practice, however, they often determine whether a project runs smoothly or repeatedly has to realign itself. The more complex an initiative becomes, the more dangerous seemingly unambiguous terms become. Words often create the illusion of shared understanding. But shared understanding does not arise from words alone.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Frank Gehry addresses this problem in a remarkable way. Before construction begins, his team invests an extraordinary amount of time in models, alternatives and joint discussions. At first glance, one might assume that these models are intended to perfect the architecture. I believe their real purpose is different:<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">They create a shared reality.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">They ensure that clients, engineers, specialist planners and construction companies are no longer talking about their own individual ideas, but about the same model. At first, the quality of the model is secondary. Its real value lies in making differences in understanding visible \u2013 not during construction, but long before it begins.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The more I explored this way of working, the more often I was reminded of situations from my own project experience.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\t\t<!-- begin AlertsDLX output -->\n\t\t<style>\n\t\t\t#alerts-dlx-499b403e {\n\t\t\t\tmax-width: 650vw;\n\t\t\t\t--alerts-dlx-base-font-size: 14px;\n\t\t\t\t--alerts-dlx-bootstrap-base-size: 14px;\n\t\t\t}\n\t\t\t#alerts-dlx-499b403e .alerts-dlx-icon-preview svg {\n\t\t\t\tmax-width: 1.8em;\n\t\t\t\tmax-height: 1.8em;\n\t\t\t}\n\t\t<\/style>\n\t\t<div\n\t\t\tclass=\"alerts-dlx template-bootstrap is-style-warning is-appearance-default icon-vertical-align-top aligncenter\"\n\t\t\tdata-expiration=\"0\"\n\t\t>\n\t\t\t<figure\n\t\t\t\trole=\"alert\"\n\t\t\t\tclass=\"alerts-dlx-alert alerts-dlx-bootstrap alerts-dlx-has-icon alerts-dlx-has-description\"\n\t\t\t\tid=\"alerts-dlx-499b403e\"\n\t\t\t>\n\t\t\t\t\t\t\t\t\t<div class=\"alerts-dlx-icon alerts-dlx-icon-frontend\" aria-hidden=\"true\">\n\t\t\t\t\t\t<div class=\"alerts-dlx-icon-preview\">\n\t\t\t\t\t\t\t<svg xmlns=\"http:\/\/www.w3.org\/2000\/svg\" fill=\"currentColor\" class=\"bi bi-lightbulb-fill\" viewbox=\"0 0 16 16\"><path d=\"M2 6a6 6 0 1 1 10.174 4.31c-.203.196-.359.4-.453.619l-.762 1.769A.5.5 0 0 1 10.5 13h-5a.5.5 0 0 1-.46-.302l-.761-1.77a1.964 1.964 0 0 0-.453-.618A5.984 5.984 0 0 1 2 6zm3 8.5a.5.5 0 0 1 .5-.5h5a.5.5 0 0 1 0 1l-.224.447a1 1 0 0 1-.894.553H6.618a1 1 0 0 1-.894-.553L5.5 15a.5.5 0 0 1-.5-.5z\"><\/path><\/svg>\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<section>\n\t\t\t\t\t<h2 class=\"alerts-dlx-title\">Aus der Praxis<\/h2>\t\t\t\t\t<div class=\"alerts-dlx-content-wrapper\">\n\t\t\t\t\t\t\t\t\t\t\t\t\t<div class=\"alerts-dlx-content\">\n\t\t\t\t\t\t\t\t<p class=\"wp-block-paragraph\">In my role as an Estimation Vali<strong>dator<\/strong>, I regularly review numerous project estimates. The discussions are often impressively precise.<\/p>\n<p class=\"wp-block-paragraph\">We talk about person-days, work packages, dependencies and critical paths.<\/p>\n<p class=\"wp-block-paragraph\">Sometimes two effort estimates differ by only a few hours. And yet I repeatedly have the impression that something crucial is missing. Not in the numbers, but before them.<\/p>\n<p class=\"wp-block-paragraph\">Only as the discussions progress does it sometimes become clear that different teams are assuming different scopes of work.<\/p>\n<p class=\"wp-block-paragraph\">Everyone is estimating diligently \u2013 just not the same reality.<\/p>\n\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/section>\n\t\t\t<\/figure>\n\t\t<\/div>\n\t\t<!-- end AlertsDLX output -->\n\t\t\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p class=\"wp-block-paragraph\">We often associate planning with precision. The more precise the numbers, the safer the project appears. But precision and certainty are not the same thing. A project plan can be mathematically excellent. If the underlying assumptions are understood differently, that precision does not create certainty. It merely creates a very precise description of uncertainty.<\/p>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<blockquote class=\"wp-block-quote is-style-plain is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>A precise estimate of an unclear scope does not make a project safer.<\/strong> <strong>It merely gives uncertainty a number.<\/strong><\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">This sentence now accompanies me through almost every major project. Not because effort estimates are unimportant, but because they often start in the wrong place. A project plan answers the question: <em>When will we do something?<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A shared vision of the target state answers the much more important question:<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">Why are we doing it at all \u2013 and how will we later know that we have succeeded?<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">Perhaps good planning is therefore not about defining as many activities as possible as early as possible. Perhaps it is about first ensuring that everyone involved genuinely has the same future in mind. At this point, it becomes clear that responsibility alone is not enough.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Even when it is clear who decides and what goal is being pursued, one crucial challenge remains: how can this shared understanding be maintained over weeks, months or even years? Frank Gehry\u2019s answer is: not through more documents, but through models that make thinking visible.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">And that is where the next principle of successful projects begins.<\/p>\n\n\n\n<!--nextpage-->\n\n\n\n<h1 class=\"wp-block-heading\">Principle 3 \u2013 <strong>Why models move successful projects forward<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>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.<\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The requirements have been discussed. The next steps have been agreed. The presentation is sent out. Everyone nods in agreement.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">A week later, the same discussion starts all over again.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">Not because anyone failed to listen or because information is missing, but because language is surprisingly imprecise. Terms such as <em>modernise<\/em>, <em>migrate<\/em>, <em>operationally ready<\/em> or <em>go-live<\/em> sound unambiguous. In reality, each person associates them with a slightly different picture.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Goethe already wrote: \u201cEveryone hears only what they understand.\u201d In today\u2019s 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Documents convey information. Shared understanding only emerges when people develop the same mental picture. Frank Gehry seems to have understood this principle early on.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Harvard Business Manager<\/em> vividly describes how intensively Gehry\u2019s 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:<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">They are there to make thought processes visible.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">A model does not initially answer the question <em>\u201cIs this the right solution?\u201d<\/em><strong> <\/strong>It answers a much more fundamental question: <em>\u201cDo we all mean the same thing?\u201d<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\t\t<!-- begin AlertsDLX output -->\n\t\t<style>\n\t\t\t#alerts-dlx-284ea85c {\n\t\t\t\tmax-width: 650vw;\n\t\t\t\t--alerts-dlx-base-font-size: 14px;\n\t\t\t\t--alerts-dlx-bootstrap-base-size: 14px;\n\t\t\t}\n\t\t\t#alerts-dlx-284ea85c .alerts-dlx-icon-preview svg {\n\t\t\t\tmax-width: 1.8em;\n\t\t\t\tmax-height: 1.8em;\n\t\t\t}\n\t\t<\/style>\n\t\t<div\n\t\t\tclass=\"alerts-dlx template-bootstrap is-style-warning is-appearance-default icon-vertical-align-top aligncenter\"\n\t\t\tdata-expiration=\"0\"\n\t\t>\n\t\t\t<figure\n\t\t\t\trole=\"alert\"\n\t\t\t\tclass=\"alerts-dlx-alert alerts-dlx-bootstrap alerts-dlx-has-icon alerts-dlx-has-description\"\n\t\t\t\tid=\"alerts-dlx-284ea85c\"\n\t\t\t>\n\t\t\t\t\t\t\t\t\t<div class=\"alerts-dlx-icon alerts-dlx-icon-frontend\" aria-hidden=\"true\">\n\t\t\t\t\t\t<div class=\"alerts-dlx-icon-preview\">\n\t\t\t\t\t\t\t<svg xmlns=\"http:\/\/www.w3.org\/2000\/svg\" fill=\"currentColor\" class=\"bi bi-lightbulb-fill\" viewbox=\"0 0 16 16\"><path d=\"M2 6a6 6 0 1 1 10.174 4.31c-.203.196-.359.4-.453.619l-.762 1.769A.5.5 0 0 1 10.5 13h-5a.5.5 0 0 1-.46-.302l-.761-1.77a1.964 1.964 0 0 0-.453-.618A5.984 5.984 0 0 1 2 6zm3 8.5a.5.5 0 0 1 .5-.5h5a.5.5 0 0 1 0 1l-.224.447a1 1 0 0 1-.894.553H6.618a1 1 0 0 1-.894-.553L5.5 15a.5.5 0 0 1-.5-.5z\"><\/path><\/svg>\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<section>\n\t\t\t\t\t<h2 class=\"alerts-dlx-title\">Aus der Praxis<\/h2>\t\t\t\t\t<div class=\"alerts-dlx-content-wrapper\">\n\t\t\t\t\t\t\t\t\t\t\t\t\t<div class=\"alerts-dlx-content\">\n\t\t\t\t\t\t\t\t<p class=\"wp-block-paragraph\">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.<\/p>\n<p class=\"wp-block-paragraph\">Everyone fills in the missing details. Requirements are interpreted differently. Gradually, a different picture forms in each person\u2019s mind.<\/p>\n<p class=\"wp-block-paragraph\">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.<\/p>\n<p class=\"wp-block-paragraph\">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.<\/p>\n\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/section>\n\t\t\t<\/figure>\n\t\t<\/div>\n\t\t<!-- end AlertsDLX output -->\n\t\t\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p class=\"wp-block-paragraph\">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.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">Documentation records decisions. Models create shared understanding.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">This is not a linguistic distinction. It reflects a fundamentally different understanding of collaboration. A specification answers the question: <em>\u201cWhat did we decide?\u201d<\/em> A model answers the much more important question: <em>\u201cDid we actually understand the same thing?\u201d<\/em><strong> <\/strong>With AI, models can now also be created within a practical scope for projects of almost any size.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Projects should therefore visualise earlier and document later. Not because documentation is unimportant, but because shared understanding must always come before complete documentation.<\/p>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<blockquote class=\"wp-block-quote is-style-plain is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Models do not reduce technical uncertainty. They reduce room for interpretation.<\/strong><\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">I believe this is one of the most successful principles in Frank Gehry\u2019s approach. It is not the models themselves that make his projects exceptional, but the conversations those models create.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Innovation therefore begins not only with a good idea, but also with a shared picture.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">And that shared picture often determines whether projects later move forward quickly \u2013 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.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Because exceptionally successful projects do not work more slowly. They simply invest their time at a different point.<\/p>\n\n\n\n<!--nextpage-->\n\n\n\n<h1 class=\"wp-block-heading\">Principle 4 \u2013 Think slowly. Deliver fast.<\/h1>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>The desire for speed leads many projects to cut preparation short. Successful projects deliberately invest more time in early decisions \u2013 and recover that time many times over during execution.<\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p class=\"wp-block-paragraph\">Few statements run more counter to today\u2019s working environment than this one: <em>\u201cTake more time to prepare.\u201d<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Understandably so. Nobody wants to lose time. Yet in many cases, this is precisely where one of the biggest misconceptions in modern project work lies.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">We often confuse <em>acting early<\/em> with <em>making fast progress<\/em>.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">In his book <em>How Big Things Get Done<\/em>, Bent Flyvbjerg describes a principle that seems paradoxical at first: <strong>Think slow. Act fast.<\/strong>[^2] Flyvbjerg is by no means calling for slow projects. He is calling for projects that invest their time in the right place.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Exceptionally successful projects do not push complexity into execution. They resolve it beforehand. That is precisely why they often appear remarkably calm during execution. Not because fewer problems occur, but because many difficult decisions have already been made.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Frank Gehry\u2019s projects follow exactly this pattern:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Before a building takes shape, alternatives are developed.<\/li>\n\n\n\n<li>Models are built.<\/li>\n\n\n\n<li>Assumptions are challenged.<\/li>\n\n\n\n<li>Uncertainties are made visible.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">From the outside, this phase looks slow. In reality, it accelerates everything that follows. Every open question answered before the first shovel hits the ground is one that does not have to be resolved later under time pressure.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\t\t<!-- begin AlertsDLX output -->\n\t\t<style>\n\t\t\t#alerts-dlx-981cc4fe {\n\t\t\t\tmax-width: 650vw;\n\t\t\t\t--alerts-dlx-base-font-size: 14px;\n\t\t\t\t--alerts-dlx-bootstrap-base-size: 14px;\n\t\t\t}\n\t\t\t#alerts-dlx-981cc4fe .alerts-dlx-icon-preview svg {\n\t\t\t\tmax-width: 1.8em;\n\t\t\t\tmax-height: 1.8em;\n\t\t\t}\n\t\t<\/style>\n\t\t<div\n\t\t\tclass=\"alerts-dlx template-bootstrap is-style-warning is-appearance-default icon-vertical-align-top aligncenter\"\n\t\t\tdata-expiration=\"0\"\n\t\t>\n\t\t\t<figure\n\t\t\t\trole=\"alert\"\n\t\t\t\tclass=\"alerts-dlx-alert alerts-dlx-bootstrap alerts-dlx-has-icon alerts-dlx-has-description\"\n\t\t\t\tid=\"alerts-dlx-981cc4fe\"\n\t\t\t>\n\t\t\t\t\t\t\t\t\t<div class=\"alerts-dlx-icon alerts-dlx-icon-frontend\" aria-hidden=\"true\">\n\t\t\t\t\t\t<div class=\"alerts-dlx-icon-preview\">\n\t\t\t\t\t\t\t<svg xmlns=\"http:\/\/www.w3.org\/2000\/svg\" fill=\"currentColor\" class=\"bi bi-lightbulb-fill\" viewbox=\"0 0 16 16\"><path d=\"M2 6a6 6 0 1 1 10.174 4.31c-.203.196-.359.4-.453.619l-.762 1.769A.5.5 0 0 1 10.5 13h-5a.5.5 0 0 1-.46-.302l-.761-1.77a1.964 1.964 0 0 0-.453-.618A5.984 5.984 0 0 1 2 6zm3 8.5a.5.5 0 0 1 .5-.5h5a.5.5 0 0 1 0 1l-.224.447a1 1 0 0 1-.894.553H6.618a1 1 0 0 1-.894-.553L5.5 15a.5.5 0 0 1-.5-.5z\"><\/path><\/svg>\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<section>\n\t\t\t\t\t<h2 class=\"alerts-dlx-title\">Aus der Praxis<\/h2>\t\t\t\t\t<div class=\"alerts-dlx-content-wrapper\">\n\t\t\t\t\t\t\t\t\t\t\t\t\t<div class=\"alerts-dlx-content\">\n\t\t\t\t\t\t\t\t<p class=\"wp-block-paragraph\">In my role as an Estimation Validator, I have often seen project teams respond to uncertainty with increasingly detailed project plans.<\/p>\n<p class=\"wp-block-paragraph\">The more questions remained open, the more precisely deadlines were planned. And the less clear the requirements were, the more Excel spreadsheets appeared.<\/p>\n<p class=\"wp-block-paragraph\">It looked professional at the time, yet a few weeks later the plans changed again \u2013 precisely because fundamental assumptions had not yet been clarified.<\/p>\n<p class=\"wp-block-paragraph\">Interestingly, project plans became stable whenever they had been preceded by intensive discussions about goals, responsibilities and dependencies. This did not necessarily improve the planning itself, but it aligned the shared understanding.<\/p>\n\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/section>\n\t\t\t<\/figure>\n\t\t<\/div>\n\t\t<!-- end AlertsDLX output -->\n\t\t\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p class=\"wp-block-paragraph\">Perhaps good planning is therefore not about defining as many tasks as possible as early as possible. It is about eliminating as much uncertainty as possible early on. That also changes how we think about speed.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">A project does not become faster simply because execution starts earlier.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">It becomes faster because fewer surprises occur during execution. Anyone who has experienced a major change request in the middle of a running project knows this effect: the real delay rarely comes from implementing the change itself. It comes from suddenly having to reopen fundamental decisions.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">With every unresolved issue a project carries into the execution phase, the risk of such loops increases. That is why one simple question is worth asking before the project even starts:<\/p>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<blockquote class=\"wp-block-quote is-style-plain is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Which open questions would cost us the most time during execution if we left them unanswered today?<\/strong><\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">This perspective alone changes many project conversations. Suddenly, the goal is no longer to start as quickly as possible, but to start as well prepared as possible. Over the past few years, I have seen many projects begin at impressive speed. Some of them lost exactly that speed again only a few months later.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Not because of technical difficulties or a lack of resources, but because decisions had to be made later that could have been made before the project started.<\/p>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<blockquote class=\"wp-block-quote is-style-plain is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>A good project plan does not save time. It saves later changes.<\/strong><\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">Perhaps this sentence captures the real difference between activity and progress. Activity means starting execution as early as possible. Progress means having to revisit as few decisions as possible later. The longer I work with projects, the more strongly I believe:<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">The most successful project managers are not the ones who start running fastest.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">They are the ones who recognise when a project is truly ready to start moving. And this is where Frank Gehry\u2019s way of working connects with Bent Flyvbjerg\u2019s findings. Both show, in different ways, that exceptional projects are not created through perfect planning. They emerge because the right questions are asked early enough. Good preparation does not slow a project down. It prevents the project from having to brake again and again later.<\/p>\n\n\n\n<!--nextpage-->\n\n\n\n<h1 class=\"wp-block-heading\"><strong>What successful projects have in common<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>At first glance, the four principles appear independent of one another. In reality, they interlock and together form a pattern that can be observed time and again in successful projects across very different industries.<\/strong><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p class=\"wp-block-paragraph\">When I first read the article about Frank Gehry, I was convinced that I was about to discover four independent principles.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Responsibility.<\/li>\n\n\n\n<li>A shared goal.<\/li>\n\n\n\n<li>Models.<\/li>\n\n\n\n<li>Thorough planning.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">The longer I reflected on these ideas \u2013 and the more often I compared them with my own project experience \u2013 the clearer it became that they cannot really be separated. They do not describe four methods. They describe four perspectives on the same fundamental idea.<\/p>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<blockquote class=\"wp-block-quote is-style-plain is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Exceptionally successful projects do not try to avoid uncertainty. They make uncertainty visible early.<\/strong><\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">Perhaps this is the real common denominator of successful projects. They accept that complex initiatives can never be planned completely. But they invest an extraordinary amount of energy in identifying as early as possible <em>where<\/em> uncertainty arises, <em>why<\/em> it arises and <em>what consequences<\/em> it could have later.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\">The earlier this happens, the lower the cost of correction.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">This idea runs like a thread through all four principles.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Responsibility ensures that decisions are not lost between organisational units.<\/li>\n\n\n\n<li>A shared goal prevents teams from working towards different visions.<\/li>\n\n\n\n<li>Models make visible what has previously only been discussed.<\/li>\n\n\n\n<li>And thorough preparation reduces the likelihood that fundamental questions will have to be answered only during execution.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Taken individually, these principles seem almost self-evident. Their real strength, however, only emerges in combination, because they build on one another.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A shared goal without clear responsibility often has little effect.<\/li>\n\n\n\n<li>Responsibility without shared understanding leads to well-intentioned decisions that move in different directions.<\/li>\n\n\n\n<li>Models without a clear goal remain attractive visualisations.<\/li>\n\n\n\n<li>And a detailed project plan quickly loses value if the underlying assumptions have never been reviewed together.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Perhaps this sequence explains why some projects run remarkably calmly despite high complexity: many difficult conversations have already taken place before the actual execution begins.<\/p>\n\n\n\n<h6 class=\"wp-block-heading\"><strong>Why successful projects do not depend on methods<\/strong><\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">When people talk about successful project management today, methods are often at the centre of the discussion.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Agile or traditional.<\/li>\n\n\n\n<li>Scrum or PRINCE2.<\/li>\n\n\n\n<li>PMI or SAFe.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">These discussions are important. In my view, however, they answer the wrong question. Methods describe <em>how<\/em> projects are organised.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The more important question is: <em>Which principles remain effective regardless of the method?<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That, in my view, is where the most interesting insight in this article begins.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Whether a building is being constructed.<\/li>\n\n\n\n<li>An international SAP transformation is being carried out.<\/li>\n\n\n\n<li>A cloud platform is being introduced.<\/li>\n\n\n\n<li>Or an organisation is undergoing profound change.<\/li>\n<\/ul>\n\n\n\n<h6 class=\"wp-block-heading\">The tools differ. The principles surprisingly little.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">People need direction. They need clarity about responsibility. They need a shared understanding. And they need the courage to make uncertainty visible before it turns into risk.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Perhaps that is the real task of modern project leadership: not to have an immediate answer to every question, but to ask the right questions early enough.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The longer I work with projects, the less I believe in perfect project plans. I believe in good conversations, shared pictures, decisions with clear ownership and teams willing to challenge their own assumptions again and again.<\/p>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<blockquote class=\"wp-block-quote is-style-plain is-layout-flow wp-block-quote-is-layout-flow\">\n<p class=\"wp-block-paragraph\"><strong>Most projects do not fail during execution.<\/strong> <strong>They fail in the way they begin.<\/strong><\/p>\n<\/blockquote>\n\n\n\n<div style=\"height:10px\" aria-hidden=\"true\" class=\"wp-block-spacer\"><\/div>\n\n\n\n<h6 class=\"wp-block-heading\">That is the most important lesson I have taken from Frank Gehry\u2019s way of working.<\/h6>\n\n\n\n<p class=\"wp-block-paragraph\">His attitude of asking difficult questions as early as possible \u2013 because they become significantly more expensive later. That attitude applies far beyond construction projects. In my view, it describes one of the universal principles of successful projects.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">And that is precisely why it is worth looking beyond our own discipline. Sometimes the best answers are found exactly where we never thought to look for them.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\t\t<!-- begin AlertsDLX output -->\n\t\t<style>\n\t\t\t#alerts-dlx-babc2213 {\n\t\t\t\tmax-width: 650vw;\n\t\t\t\t--alerts-dlx-base-font-size: 14px;\n\t\t\t\t--alerts-dlx-bootstrap-base-size: 14px;\n\t\t\t}\n\t\t\t#alerts-dlx-babc2213 .alerts-dlx-icon-preview svg {\n\t\t\t\tmax-width: 1.8em;\n\t\t\t\tmax-height: 1.8em;\n\t\t\t}\n\t\t<\/style>\n\t\t<div\n\t\t\tclass=\"alerts-dlx template-bootstrap is-style-warning is-appearance-default icon-vertical-align-top aligncenter\"\n\t\t\tdata-expiration=\"0\"\n\t\t>\n\t\t\t<figure\n\t\t\t\trole=\"alert\"\n\t\t\t\tclass=\"alerts-dlx-alert alerts-dlx-bootstrap alerts-dlx-has-icon alerts-dlx-has-description\"\n\t\t\t\tid=\"alerts-dlx-babc2213\"\n\t\t\t>\n\t\t\t\t\t\t\t\t\t<div class=\"alerts-dlx-icon alerts-dlx-icon-frontend\" aria-hidden=\"true\">\n\t\t\t\t\t\t<div class=\"alerts-dlx-icon-preview\">\n\t\t\t\t\t\t\t<svg xmlns=\"http:\/\/www.w3.org\/2000\/svg\" fill=\"currentColor\" class=\"bi bi-info-square-fill\" viewbox=\"0 0 16 16\"><path d=\"M0 2a2 2 0 0 1 2-2h12a2 2 0 0 1 2 2v12a2 2 0 0 1-2 2H2a2 2 0 0 1-2-2V2zm8.93 4.588-2.29.287-.082.38.45.083c.294.07.352.176.288.469l-.738 3.468c-.194.897.105 1.319.808 1.319.545 0 1.178-.252 1.465-.598l.088-.416c-.2.176-.492.246-.686.246-.275 0-.375-.193-.304-.533L8.93 6.588zM8 5.5a1 1 0 1 0 0-2 1 1 0 0 0 0 2z\"><\/path><\/svg>\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<section>\n\t\t\t\t\t<h2 class=\"alerts-dlx-title\">Drei Fragen, die erfolgreiche Projekte fr\u00fcher stellen<\/h2>\t\t\t\t\t<div class=\"alerts-dlx-content-wrapper\">\n\t\t\t\t\t\t\t\t\t\t\t\t\t<div class=\"alerts-dlx-content\">\n\t\t\t\t\t\t\t\t<p class=\"wp-block-paragraph\">You may not need to answer these questions immediately. Sometimes it is enough to take them into your next kick-off. Good questions can achieve more than another project plan.<\/p>\n<p class=\"wp-block-paragraph\"><strong>1. Would everyone involved describe the same project?<br \/><\/strong>If you asked five key people independently how project success will be measured, how similar would their answers really be?<\/p>\n<p><strong>2. Which assumptions are already taken for granted in your project?<br \/><\/strong>Every project is built on assumptions. The most dangerous assumptions are rarely the wrong ones; they are the ones nobody questions anymore. Which assumption would change your project the most if it turned out to be wrong tomorrow?<\/p>\n<p><strong>3. Which difficult question are you postponing right now?<br \/><\/strong>Almost every project has issues that are supposed to be discussed \u201clater\u201d. Experience shows that these questions rarely disappear. Usually, they simply become more expensive. Perhaps it is worth taking that one question into your next project meeting.<\/p>\n\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/section>\n\t\t\t<\/figure>\n\t\t<\/div>\n\t\t<!-- end AlertsDLX output -->\n\t\t\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Outlook<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This article marks the beginning of a series on successful project management.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In the coming articles, we will explore the principles introduced here step by step. The focus will not be on new methods or frameworks, but on fundamental questions that arise in almost every demanding project.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Among other things, we will look at<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>why good planning begins long before the actual project plan,<\/li>\n\n\n\n<li>why precise estimates can still be wrong,<\/li>\n\n\n\n<li>what role models and prototypes play in creating shared understanding,<\/li>\n\n\n\n<li>how responsibility and communication influence project success,<\/li>\n\n\n\n<li>and what we can learn from exceptionally successful major projects for everyday leadership.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The series will conclude by asking which of these principles will endure in the age of AI \u2013 and which are only now beginning to unfold in new ways.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you do not want to miss an article in this series, you can sign up here for updates with no obligation. You will automatically receive a notification as soon as a new article is published.<\/p>\n\n\n<div class=\"wp-block-jetpack-subscriptions__supports-newline is-style-split wp-block-jetpack-subscriptions\">\n\t\t<div>\n\t\t\t<div>\n\t\t\t\t<div>\n\t\t\t\t\t<p >\n\t\t\t\t\t\t<a href=\"https:\/\/michael-hoepfl.com\/en\/?post_type=post&#038;p=4945\" style=\"font-size: 16px;padding: 15px 23px 15px 23px;margin: 0; margin-left: 10px;border-radius: 0px;border-width: 1px; background-color: #113AF5; color: #FFFFFF; text-decoration: none; white-space: nowrap; margin-left: 0\"><strong>Serie folgen<\/strong><\/a>\n\t\t\t\t\t<\/p>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t<\/div>","protected":false},"excerpt":{"rendered":"<p>Most projects do not fail during execution. They fail in the way they begin. Why do some successful projects seem to run almost effortlessly, while others repeatedly stall despite experienced [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":4944,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_import_markdown_pro_load_document_selector":0,"_import_markdown_pro_submit_text_textarea":"","_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"[{\"id\":\"fa6ff816-5cd3-4552-96fc-02e3e4932bfe\",\"content\":\"\"},{\"id\":\"3d682157-50c0-4bff-89c2-d56a4dca4a1c\",\"content\":\"\"}]","jetpack_post_was_ever_published":false},"categories":[274,273],"tags":[267,217,266,263,268,261,259,258,260,262,265,264],"class_list":["post-4945","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-communication","category-consulting","tag-bent-flyvbjerg","tag-consulting","tag-frank-gehry","tag-fuehrung","tag-kommunikation","tag-projekterfolg","tag-projektleitung","tag-projektmanagement","tag-projektplanung","tag-transformation","tag-verantwortung","tag-zusammenarbeit","bwp-blog-post","bwp-masonry-item","bwp-col-1","bwp-post-has-title"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.2 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Four Principles for Successful Projects - michael-hoepfl.com<\/title>\n<meta name=\"description\" content=\"Why do some projects succeed while others do not? Four principles drawn from project research and my own project experience.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/\" \/>\n<link rel=\"next\" href=\"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/2\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Four Principles for Successful Projects - michael-hoepfl.com\" \/>\n<meta property=\"og:description\" content=\"Why do some projects succeed while others do not? Four principles drawn from project research and my own project experience.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/\" \/>\n<meta property=\"og:site_name\" content=\"michael-hoepfl.com\" \/>\n<meta property=\"article:published_time\" content=\"2026-08-07T21:55:18+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-08-11T12:47:41+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/pexels-photo-4623523.jpeg\" \/>\n\t<meta property=\"og:image:width\" content=\"1880\" \/>\n\t<meta property=\"og:image:height\" content=\"1251\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Michael H\u00f6pfl\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Michael H\u00f6pfl\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"23 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/\"},\"author\":{\"name\":\"Michael H\u00f6pfl\",\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/#\\\/schema\\\/person\\\/8d843bca28bfc5f703bcf977868eb8d7\"},\"headline\":\"Four Principles for Successful Projects\",\"datePublished\":\"2026-08-07T21:55:18+00:00\",\"dateModified\":\"2026-08-11T12:47:41+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/\"},\"wordCount\":4214,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/#\\\/schema\\\/person\\\/8d843bca28bfc5f703bcf977868eb8d7\"},\"image\":{\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/michael-hoepfl.com\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/pexels-photo-4623523.jpeg\",\"keywords\":[\"Bent Flyvbjerg\",\"Consulting\",\"Frank Gehry\",\"F\u00fchrung\",\"Kommunikation\",\"Projekterfolg\",\"Projektleitung\",\"Projektmanagement\",\"Projektplanung\",\"Transformation\",\"Verantwortung\",\"Zusammenarbeit\"],\"articleSection\":[\"Communication\",\"Consulting\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/\",\"url\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/\",\"name\":\"Four Principles for Successful Projects - michael-hoepfl.com\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/michael-hoepfl.com\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/pexels-photo-4623523.jpeg\",\"datePublished\":\"2026-08-07T21:55:18+00:00\",\"dateModified\":\"2026-08-11T12:47:41+00:00\",\"description\":\"Why do some projects succeed while others do not? Four principles drawn from project research and my own project experience.\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/consulting\\\/four-principles-for-successful-projects\\\/08-2026\\\/#primaryimage\",\"url\":\"https:\\\/\\\/michael-hoepfl.com\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/pexels-photo-4623523.jpeg\",\"contentUrl\":\"https:\\\/\\\/michael-hoepfl.com\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/pexels-photo-4623523.jpeg\",\"width\":1880,\"height\":1251,\"caption\":\"Teamwork as the foundation of successful projects\"},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/#website\",\"url\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/\",\"name\":\"michael-hoepfl.com\",\"description\":\"my business. my brain stuff. my blog.\",\"publisher\":{\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/#\\\/schema\\\/person\\\/8d843bca28bfc5f703bcf977868eb8d7\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":[\"Person\",\"Organization\"],\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/#\\\/schema\\\/person\\\/8d843bca28bfc5f703bcf977868eb8d7\",\"name\":\"Michael H\u00f6pfl\",\"pronouns\":\"er\\\/ihr\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/LinkedIn-Profile-Image-2026-1024x1024.png\",\"url\":\"https:\\\/\\\/michael-hoepfl.com\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/LinkedIn-Profile-Image-2026-1024x1024.png\",\"contentUrl\":\"https:\\\/\\\/michael-hoepfl.com\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/LinkedIn-Profile-Image-2026-1024x1024.png\",\"width\":1024,\"height\":1024,\"caption\":\"Michael H\u00f6pfl\"},\"logo\":{\"@id\":\"https:\\\/\\\/michael-hoepfl.com\\\/wp-content\\\/uploads\\\/2026\\\/08\\\/LinkedIn-Profile-Image-2026-1024x1024.png\"},\"description\":\"Ich schreibe und poste hier zu Themen, die mich seit jeher privat als auch beruflich interessieren und begleiten. [Mehr \u00fcber mich]\",\"sameAs\":[\"https:\\\/\\\/michael-hoepfl.com\",\"https:\\\/\\\/www.linkedin.com\\\/in\\\/michael-hoepfl\"],\"url\":\"https:\\\/\\\/michael-hoepfl.com\\\/en\\\/author\\\/mhoepfl\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Four Principles for Successful Projects - michael-hoepfl.com","description":"Why do some projects succeed while others do not? Four principles drawn from project research and my own project experience.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/","next":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/2\/","og_locale":"en_US","og_type":"article","og_title":"Four Principles for Successful Projects - michael-hoepfl.com","og_description":"Why do some projects succeed while others do not? Four principles drawn from project research and my own project experience.","og_url":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/","og_site_name":"michael-hoepfl.com","article_published_time":"2026-08-07T21:55:18+00:00","article_modified_time":"2026-08-11T12:47:41+00:00","og_image":[{"width":1880,"height":1251,"url":"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/pexels-photo-4623523.jpeg","type":"image\/jpeg"}],"author":"Michael H\u00f6pfl","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Michael H\u00f6pfl","Est. reading time":"23 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/#article","isPartOf":{"@id":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/"},"author":{"name":"Michael H\u00f6pfl","@id":"https:\/\/michael-hoepfl.com\/en\/#\/schema\/person\/8d843bca28bfc5f703bcf977868eb8d7"},"headline":"Four Principles for Successful Projects","datePublished":"2026-08-07T21:55:18+00:00","dateModified":"2026-08-11T12:47:41+00:00","mainEntityOfPage":{"@id":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/"},"wordCount":4214,"commentCount":0,"publisher":{"@id":"https:\/\/michael-hoepfl.com\/en\/#\/schema\/person\/8d843bca28bfc5f703bcf977868eb8d7"},"image":{"@id":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/#primaryimage"},"thumbnailUrl":"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/pexels-photo-4623523.jpeg","keywords":["Bent Flyvbjerg","Consulting","Frank Gehry","F\u00fchrung","Kommunikation","Projekterfolg","Projektleitung","Projektmanagement","Projektplanung","Transformation","Verantwortung","Zusammenarbeit"],"articleSection":["Communication","Consulting"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/","url":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/","name":"Four Principles for Successful Projects - michael-hoepfl.com","isPartOf":{"@id":"https:\/\/michael-hoepfl.com\/en\/#website"},"primaryImageOfPage":{"@id":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/#primaryimage"},"image":{"@id":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/#primaryimage"},"thumbnailUrl":"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/pexels-photo-4623523.jpeg","datePublished":"2026-08-07T21:55:18+00:00","dateModified":"2026-08-11T12:47:41+00:00","description":"Why do some projects succeed while others do not? Four principles drawn from project research and my own project experience.","inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/michael-hoepfl.com\/en\/consulting\/four-principles-for-successful-projects\/08-2026\/#primaryimage","url":"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/pexels-photo-4623523.jpeg","contentUrl":"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/pexels-photo-4623523.jpeg","width":1880,"height":1251,"caption":"Teamwork as the foundation of successful projects"},{"@type":"WebSite","@id":"https:\/\/michael-hoepfl.com\/en\/#website","url":"https:\/\/michael-hoepfl.com\/en\/","name":"michael-hoepfl.com","description":"my business. my brain stuff. my blog.","publisher":{"@id":"https:\/\/michael-hoepfl.com\/en\/#\/schema\/person\/8d843bca28bfc5f703bcf977868eb8d7"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/michael-hoepfl.com\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":["Person","Organization"],"@id":"https:\/\/michael-hoepfl.com\/en\/#\/schema\/person\/8d843bca28bfc5f703bcf977868eb8d7","name":"Michael H\u00f6pfl","pronouns":"er\/ihr","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/LinkedIn-Profile-Image-2026-1024x1024.png","url":"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/LinkedIn-Profile-Image-2026-1024x1024.png","contentUrl":"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/LinkedIn-Profile-Image-2026-1024x1024.png","width":1024,"height":1024,"caption":"Michael H\u00f6pfl"},"logo":{"@id":"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/LinkedIn-Profile-Image-2026-1024x1024.png"},"description":"Ich schreibe und poste hier zu Themen, die mich seit jeher privat als auch beruflich interessieren und begleiten. [Mehr \u00fcber mich]","sameAs":["https:\/\/michael-hoepfl.com","https:\/\/www.linkedin.com\/in\/michael-hoepfl"],"url":"https:\/\/michael-hoepfl.com\/en\/author\/mhoepfl\/"}]}},"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/michael-hoepfl.com\/wp-content\/uploads\/2026\/08\/pexels-photo-4623523.jpeg","_links":{"self":[{"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/posts\/4945","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/comments?post=4945"}],"version-history":[{"count":7,"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/posts\/4945\/revisions"}],"predecessor-version":[{"id":5070,"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/posts\/4945\/revisions\/5070"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/media\/4944"}],"wp:attachment":[{"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/media?parent=4945"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/categories?post=4945"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/michael-hoepfl.com\/en\/wp-json\/wp\/v2\/tags?post=4945"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}