Best Practices – oder: Der unstillbare Wunsch nach Schema F

Die neue Konferenzsaison beginnt – und tagtäglich flattern Call for Papers ins Postfach. Stets gewünscht: Best Practices. Die ganze Projektmanagement-Branche träumt von einem Erfolgsrezept, das man jedem Projekt über-stülpen kann und mit dem dann nichts mehr schief geht. Die Idee klingt ja auch verlockend: Die beste realisierte Lösung wird einfach nachgestellt und der Erfolg damit quasi frei Haus geliefert. Doch bei Jedem, der die Definition eines Projekts im Hinterkopf hat, müsste diese Idee sogleich ein Stirnrunzeln hervorrufen.

Best Practices – oder: Der unstillbare Wunsch nach Schema F

Die neue Konferenzsaison beginnt – und tagtäglich flattern Call for Papers ins Postfach. Stets gewünscht: Best Practices. Die ganze Projektmanagement-Branche träumt von einem Erfolgsrezept, das man jedem Projekt über-stülpen kann und mit dem dann nichts mehr schief geht. Die Idee klingt ja auch verlockend: Die beste realisierte Lösung wird einfach nachgestellt und der Erfolg damit quasi frei Haus geliefert. Doch bei Jedem, der die Definition eines Projekts im Hinterkopf hat, müsste diese Idee sogleich ein Stirnrunzeln hervorrufen.

In der Softwareentwicklung trägt ein Minimum Viable Product beispielsweise dazu bei, dass die Zahl an Featurewünschen auf ein machbares Maß minimiert werden kann. Es geht dabei nicht darum, Prototypen oder Entwürfe zu erstellen, sondern um ein minimal ausgestattetes, aber dennoch voll funktionsfähiges Produkt, mit dem man Rückmeldungen von Seiten der Anwender einholen kann.

MVP dient als Priorisierungsstrategie, indem Funktionen, die die Zielgruppe für das Produkt begeistern, von solchen unterschieden werden, die zwar ganz nett sind, potenzielle Kunden aber nicht zum Produktkauf animieren. Nach dem Lean-Startup-Prinzip "Build – Measure – Learn" (Bauen – Messen – Lernen) wird das Produkt iterativ weiterentwickelt. Natürlich eignen sich hierfür agile Projektmanagement-Methoden sehr gut, aber man kann das Prinzip auch in einer klassischen Zeitplanung umsetzen.

Minimum Viable Product

Bild: Minimum Viable Product – minimal, aber brauchbar.
© InLoox GmbH
Bild vergrößern

Was Großunternehmen von Lean-Startups lernen können

Kann dieser Lean-Startup-Gedanke auch Großunternehmen dabei helfen, wichtige Projekte schneller und effizienter umzusetzen? Lange Projektlaufzeiten sowie eine umfangreiche Projektorganisation mit verschiedenen Gremien, organisatorischen Regelungen und hierarchischen Entscheidungsstrukturen machen solche Unternehmen häufig so wendig wie ein Tanklastschiff.

Daher lassen sich die meisten großen Firmen auch nicht in ein schlankes Startup transformieren. Doch es werden sich sicher Nischen finden, in denen sich ein Minimum Viable Project umsetzen lässt. Und wenn man Glück hat, entwickelt ein erfolgreiches Projekt eine solche Strahlkraft, dass es zur Blaupause für erfolgreiches Projektmanagement im gesamten Unternehmen wird.

Dabei stellen sich zunächst zwei Fragen: Wie viel Projektorganisation ist nötig, damit ein Projekt gelingen kann? Wie wenig Projektorganisation ist möglich? Bevor man in die Build-Phase eines Minimum Viable Projects geht, sollte man daher zunächst seine Recherche-Hausaufgaben machen. Eine anonyme Online-Befragung unter erfahrenen Projektteammitgliedern kann z.B. dazu beitragen, im Unternehmen bekannte Hemmnisse für einen zügigen Projektverlauf aufzuzeigen.

Alle erfahrenen Projektleiter werden wissen, welche Antwort am häufigsten kommen wird: Genau – die Ressourcen reichen nicht aus. Doch das Ziel eines Minimum Viable Projects ist es nicht, auf magische Weise die vorhandenen Ressourcen zu vervielfältigen, sondern das Beste aus den vorhandenen Möglichkeiten zu machen.

Fünf Empfehlungen für Minimum Viable Projects

  1. Besinnen Sie sich auf den Kern des Vorhabens: Welches Ergebnis muss das Projekt zwingend erbringen, so dass es von Wert für das Unternehmen ist? Identifizieren Sie diesen Wert und kommunizieren Sie ihn ganz klar an das Projektteam. Alle Maßnahmen im Projekt werden diesem Ziel untergeordnet.
  2. Halten Sie den Projektauftrag überschaubar. Ziel eines Minimum Viable Projects ist es, so schnell wie möglich Ergebnisse zu liefern. Dies ist von vorne herein zum Scheitern verurteilt, wenn das Team mit Änderungsanforderungen und Ergänzungen zum Projektauftrag überflutet wird. Die Floskel "Wenn wir schon dabei sind, könnten wir doch auch noch…" wird aus dem Vokabular gestrichen.
  3. Definieren Sie einfache Indikatoren, die Ihnen sagen, ob Ihr Projekt in der Spur läuft. Bleiben Sie auch dabei minimalistisch und lernen Sie. Starten Sie mit so wenigen Kennzahlen wie möglich und vermeiden Sie, Mitarbeiter ausschließlich für das Projekt-Controlling abzustellen.
  4. Geben Sie Ihren Teammitgliedern Entscheidungskompetenz. Das erfordert Mut und ein positives Menschenbild. Wenn Sie implizit annehmen, dass Ihre Mitarbeiter Freiheiten sofort zu Ungunsten des Unternehmens ausnutzen, sobald man ihnen die Gelegenheit dazu gibt, werden schnelle Entscheidungen nicht möglich sein. Dann müssen sich alle wieder bei ihrem Vorgesetzten und beim Vorgesetzten des Vorgesetzten absichern – die Schwerfälligkeit des Projekts ist damit vorprogrammiert.
  5. Messen und lernen Sie! Dazu muss von vorneherein klar sein, wann Sie das Projekt als Erfolg werten – die Erfolgsmessung hängt also von einer glasklaren Zieldefinition ab. Bei iterativen Projekten lassen sich Stellschrauben sehr viel leichter identifizieren und nachjustieren, als dies bei "Rundumschlagprojekten" der Fall ist.

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 0
Kommentare 2

Alle Kommentare

Guest
Glückwunsch zu diesem Beitrag - ich hoffe, viele Lesende lassen sich dadurch inspirieren und sind ermutigt, in Zukunft z.B. das Set-up ihres neuen Projekts selbst in die Hand zu nehmen und die beste Lösung tatsächlich selbst zu erdenken. Denn komplexe Probleme kennen keine Best Practices (zum Weiterlesen für Interessierte: Snowden/Boone, A Leader’s Framework for Decision Making, Harvard Business Review, 2007).
Heinz-Detlef
Scheer
Vielen Dank auch von mir für diesen Beitrag! Auch ich möchte das Buch von Lars Vollmer zu diesem Thema empfehlen. Es ist herrlich pragmatisch und deshalb wirkt seine wunderbare Polemik erfrischend und anregend und nicht verletzend. Auch ich habe als Coach Kunden, die gerne Rezepte haben möchten, um ihre Probleme in den Griff zu bekommen. Ich habe für mich das Problem folgendermaßen gelöst: Kunden, die darauf bestehen ein Rezept zu bekommen, bekommen auch eins! Ich habe mir vor einiger Zeit sogar einen Rezeptblock drucken lassen. Da schreibe ich dann ein individuelles Rezept drauf, das sich allerdings als Anleitung dazu herausstellt, selbst ein Vorgehen zu entwickeln. Dazu ist es immer nötig, dass er Kunde eine „Inventur“ seiner Kompetenzen macht oder etwas dazulernt (in den seltensten Fällen nötig!) und dann seine selbst entwickelte individuelle Strategie anwendet. Diese wirkt meist eher nachhaltig und tragfähig als irgendwelche Ratschläge, weil der Kunde der beste Experte für seine Bedingungen ist. Diese Rezepte bewirken in der Regel, dass sich das Thema in Humor und eine Lösungsidee auflöst, oder es kommt nach einer kurzen Ent-Täuschung zu einem längeren Prozess der Entwicklung einer komplexen, aber selbst erfundenen Lösung, die dann auch länger tragfähig ist. Meistens ist sie dann aber auch wieder flexibel. Die Einsicht, dass es keine Rezepte oder „Schema Fs“ geben kann inklusive. Ein individuelles Vorgehen kann nur entstehen, wenn die Bedingungen dafür stimmig sind. Dazu gehört eine exzellente Expertise der Beteiligten – in diesem Falle der Projektleiter oder Projektingenieure, die dann auch in der Lage sind im Getümmel der unterschiedlichen bis gegensätzlichen Interessen der Stakeholder zu bestehen. Dies kann man aber nicht mit zusammengeschrumpften, verbilligten, aber zertifizierten Weiterbildungen erreichen, sondern nur durch eine fundierte Ausbildung. Dieses Problem lässt sich übrigens ungebremst auf die Coaching – Szene übertragen. Das einzige „Schema F“ kann nur eins sein, dass die Entwicklung von prinzipiell unendlich vielen „Schemata X“ ermöglicht. Das erfordert Mut und Vertrauen. Das wiederum scheitert aber oft genug an einem Management bzw. an Entscheidern, die teilweise aus Angst die Bedingungen nicht schaffen können, unter denen sie keine Angst mehr haben müssten, weil sie von exzellenten Fachleuten umgeben sind, die in der Lagen sind Probleme selbstständig und in Eigenregie aufgrund vorhandener Kompetenzen zu lösen.
Alle anzeigen