Die Hiding Hand verführt uns zu Projekten. Lean- und Agile-Ansätze sind die Fortsetzung.

Wir haben schon über die “Hiding Hand” in unseren Projekten geschrieben /1/. Die Idee kommt von Albert O. Hirschman. Hirschman beobachtete 1967 auf Basis seiner Erfahrungen in Entwicklungsländern, wie fehlgeplante Projekte durch Anpassungen trotzdem zu einem positiven Nutzen gebracht werden. Die “Hiding Hand” bringt uns dazu, Projekte zu unternehmen, die wir nie angegangen hätten, wenn wir die vollen Kosten und Risiken zu Projektbeginn gekannt hätten. Die Fehlplanung wird (angeblich) zu einem Segen, der unsere Entwicklung vorantreibt /2, 4/. Aber brauchen wir wirklich eine Hiding Hand, die uns in Projekte lockt? Ich denke nicht.

Hirschman sah die Hiding Hand als Teil eines Lernprozesses. Die Hiding Hand verschwindet mit der Zeit, da wir lernen, besser zu planen und größere Risiken einzugehen. Aber, Herr Hirschman, hat Deutschland in diesem Sinne das Stadium eines Entwicklungslands wirklich verlassen?

Wenn wir die aktuelle Projektlandschaft anschauen, von Berliner Flughafen bis zu kleineren Projekten in Firmen, stellt es sich die Frage, ob die Hiding Hand in Länder wie Deutschland wirklich keine Rolle mehr spielt. Ich erlebe ihre Wirkung in fast jedem Projekt. Haben wir aus unseren Projekterfahrungen nichts gelernt, wie Bent Flyvbjerg meint? /3/

Oder haben wir uns doch durch die Hiding Hand schon weiter entwickelt? Aus meiner Sicht zeigen Techniken aus den Bereichen Lean und Agile genau die von Hirschman versprochene Reifegradentwicklung. Durch sie wagen wir mehr Projekte, allerdings ohne den Stress der Rettung eines gekenterten Projekts.

Welche Techniken aus der agilen Welt könnten helfen? Mir fallen folgende Punkte ein:

Aufgaben bzw. Projekte in kleine Teile zerlegen
Menge der gleichzeitigen Aufgaben reduzieren (Limiting work in progress)
Fast Feedback

Also, wir testen die Hypothese der Reihe nach….

Lieber kleine Projekte

Bei Projekten explodieren Schätz- und Planungsfehler exponentiell mit der Größe. Ansätze wie Scrum, Kanban oder Lean Startup empfehlen, die “Batch Size” (Arbeitpakete, User Stories, Größe oder Menge an Features, Sprint-Länge etc.) klein zu halten. Das ist vorteilhaft:

Die Sache bleibt überschaubar. Damit kann ich genauer schätzen und planen.
Ich bin eher bereit die Risiken einzugehen, weil sie klein sind.
Fast Feedback ist möglich. Wir bekommen früher Ergebnisse und können besser Ziele und Aufgaben anpassen.

Wir sollten durch die Hiding Hand lernen, größeren Risiken einzugehen. Sind kleine Projekte hier ein Widerspruch? Keineswegs. Gerade die Erfahrungen aus kleineren Projekten gibt uns den Mut, größere Projekten anzugehen.

Anzahl der Aufgaben begrenzen (limiting work in progress)

Das Eingrenzen und Priorisieren der aktuellen Projekte/Aufgaben verbessert unsere Produktivität. Zwar erhöht das WIP-Limit unseren Durchsatz enorm. Aber gerade die Priorisierung, also die Frage, welches Projekt als nächstes begonnen wird, verbessert unsere Einschätzung des Risikos.

Begrenzung und Prioriserung verringert Kapazitätsengpässe. Teams, die ein Kanban-Board aufgestellt haben, berichten wie zauberhaft die Eingrenzung der WIP wirkt, als ob eine Hiding Hand sie unterstützt.

Und die Ausnahme bestätigt der Regel. Ich kenne ein kleines Startup, das mit dem vollen Einsatz von Scrum stolziert. Leider wurde wenig auf die Begrenzung des WIP geachtet. Dadurch haben sie einen See von Aufgaben aufgefüllt, worin sie zu ertrinken drohen. Nun führt die Firma Kanban-Boards und starke Prioritisierungsregeln ein. Die Wirkung: die Produktivität, die Qualität und die Motivation der Mannschaft steigen. Die Reifegradentwicklung dieses jungen Unternehmens ist innerhalb nur Monate spürbar.

Fast Feedback

Fast Feedback hilft uns dabei, zu lernen. Fast Feedback schließt Messverfahren und Erstellung von Prototypen ein, sowohl in internen Prozessen als auch beim Kunden. Mit Fast Feedback reduziert sich das Risiko, unter falsche Voraussetzungen hinsichtlich Anforderungen, Qualität, Nutzen, Umfang usw. zu arbeiten. Wir können schnell korrigieren. Wir gewöhnen uns an Changes, und die Anpassungen an sich werden kleiner. Wenn wir die Gewissheit haben, dass eine Korrektur möglich ist, entscheiden wir uns eher dafür, etwas neues zu entwickeln.

Ich denke, dass wir doch was gelernt haben. Wie ist Ihre Erfahrung in Projekten?

Anmerkungen

/1/ James Lee: Wie die Hiding Hand unseren Projekten zu Hilfe kommt, Teamworkblog, erschienen am 31. März 2014, abrufbar unter http://www.teamworkblog.de/2014/03/wie-die-hiding-hand-unseren-projekten.html
/2/ Albert O. Hirschman: The principle of the hiding hand, erschienen in National Affairs, Issue Number 6 - Winter 1967, abrufbar unter http://www.nationalaffairs.com/public_interest/detail/the-principle-of-the-hiding-hand
/3/ Flyvbjerg, Bent: Megaprojects and Risk : An Anatomy of Ambition. First Edition, Sixth Impression. Cambridge: Cambridge University Press, 2003, Auszug abrufbar unter http://flyvbjerg.plan.aau.dk/excerpt.php
/4/ In einem aktuellen Beitrag im Project Management Journal (/5/) widerspricht Flyvbjerg vehement dem Segen der Hiding Hand.
/5/ Flyvbjerg, B. (2014), What You Should Know About Megaprojects and Why: An Overview. Proj Mgmt Jrnl, 45: 6–19. doi: 10.1002/pmj.2140, siehe http://onlinelibrary.wiley.com/doi/10.1002/pmj.2014.45.issue-2/issuetoc

Wie lassen sich Ergebnisse definieren? - Drei Beispiele (WBS, CBP und BDN)

Ich habe schon darüber geschrieben, warum das Definieren von Ergebnissen so wichtig ist. Es lenkt die Aufmerksamkeit des Projektteams auf die eigentlichen Ziele. Aber was sind eigentlich Projektergebnisse? In diesem Beitrag stelle ich drei Methoden vor, um leichter an Ergebnisse zu kommen.

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Erfahrung mit Vibe-Coding - und warum das keine Teamprobleme löst

Die KI-Werkzeuge zum Erstellen von Werkzeugen für die tägliche Arbeit werden immer besser. Die selbstgestrickten Tools erleichtern die eigene Arbeit. Aber für den Einsatz im Team fehlt noch etwas.

Microsoft Copilot - Notebook, Pages, Agents und mehr

Es tut sich sehr viel an der Copilot Front. Gefühlt entwickelt Microsoft mit aller Kraft die KI-Anwendung weiter. Mit dem letzten Update hat sich die Microsoft-Startseite stark verändert. Hier zeige ich, was sich hinter all den Begrifflichkeiten verbirgt und was davon alltagstauglich ist.

Wenn Leisten Leistung kostet

Immer. Immer "on". Immer mehr. Immer schneller. Und natürlich: Immer besser. Das ist die Welt, in der wir heute leben. Eine Welt der Dauerleistung. Und die hat ihren Preis: Wir werden schwächer. Sofern wir nicht die Grundlagen guten (Selbst-)Managements beherzigen und Pausen machen. Also zur richten Zeit das wirklich Wichtige tun.

Schätzungen sind schätzungsweise überschätzte Schätze

"Wer viel misst, misst viel Mist." Zumindest ist diese Gefahr gegeben. Entweder misst man z. B. Mist, weil man zu früh zu KPIs zur Messung von Ergebnissen greift, oder aber man greift zu den falschen KPIs, die gar nicht das messen, was man wissen möchte. Einst war agiles Arbeiten der alternative Ansatz, aber inzwischen gibt es auch für einige Details dessen, was in Konzernen als "agil" praktiziert wird, einleuchtende alternative Ideen, die bis heute noch nicht so richtig auf die große Bühne vorgedrungen zu sein scheinen.

A shared file storage is not a library

In over 90% of cases where we advise organizations on filing systems, we find that they are organized by topic. This system quickly leads to chaos because outdated documents are not disposed of quickly enough. So why does everyone think to structure their filing system by topic? I believe we have the wrong idea.

From False Starts to Precision Landing: The Evolution of Requirements Management

Requirements management originated in U.S. rocket programs between 1945 and 1970. A small management trick contributed to the success of the Apollo program.

Wie läuft ein Projekt zum Entwickeln von Szenarien ab?

Seit 2016 beschäftigen Edgar und ich uns intensiv mit der Szenariotechnik. Szenarien sind ein wirkungsvolles Werkzeug, um Projekte oder ganze Geschäftsmodelle auf ihre Zukunftstauglichkeit zu testen.

Wenn es mal gerade etwas schwierig bei Kund:innen wird… Zwei Fragen, die uns helfen, unsere Strategie mit unseren Kund:innen abzusprechen.

Seit 2024 organisieren Bob Galen und ich eine Masterclass für agile Coaches. Wir möchten die Ausbildung von agilen Coaches verbessern und ihnen Techniken mitgeben, mit denen sie bei ihren Kund:innen etwas einfacher haben. Bisher haben wir in vier Durchgängen mit jeweils 14 Modulen ungefähr 70 Extraordinarily Badass Agile Coaches ausgebildet (/1/). In diesem Blogpost möchte ich ein paar Erfahrungen und simple Techniken aus der Masterclass teilen, wie wir unsere Strategie besser abstimmen können. Sie beschränken sich nicht auf agiles Coaching – das ist nur das Setting.

Das Teamwork-Blog

Dieses Blog durchsuchen