Der neueste James Bond is Spectre ist schon wieder alt. Da wir allerdings nicht Kino-Saison abhängig sind, gilt unsere Mission das ganze Jahr:

Risiken eliminieren und Chancen in Erfolge Wandeln.

Was für James Bond die „Licence to kill“, ist für uns Projektmanager das Streben nach Verbesserungen. Uns Projektmanager, Projektmitarbeitern und insbesondere agile Teams treibt das Thema der kontinuierlichen Optimierung geradezu an.

Im Folgenden sind vier Themenbereiche beschrieben, welche in Projektmanagement Lessons Learned Sessions immer wieder benannt werden. Neben einer generellen Beschreibung und Feststellung zu den jeweiligen Defiziten, sind zu jedem Thema ein paar konkrete Anregungen aufgelistet.

Fokus

Verliere das Ziel nicht aus den Augen. Das aktuelle Projekt oder die Tätigkeit an welcher Du arbeitest, hat ein ursprüngliches Ziel.  Hier zwei Beispiele:

#1 Konstruktion eines Lautsprechers, welcher wireless bedient werden kann. Hier wäre zusätzliche auch eine Uhr hilfreich und eine Ladefunktion für das Smartphone. Die Frage ob der Konsument/die vermeintliche Zielgruppe dies überhaupt benötigt, vermeide ich an dieser Stelle. Wir Projektmanager versuchen uns immer an der Kunst der Einhaltung des magischen Dreiecks (Qualität/Scope, Budget und Zeit). Hierbei verfolge ich persönlich den Ansatz, erst ein fertiges Produkt zu haben, bevor es weiterentwickelt bzw. mit Zusatzanforderungen überladen wird.

#2 Ein Stift mit dem man im Weltall schreiben kann. Hierbei kann man natürlich Jahre an einem Space Pen entwickeln und horrende Summen verausgaben, damit alle vermeintlichen Anforderungen Berücksichtigung finden. Oder man fokussiert sich auf das wesentliche und nimmt einen Bleistift.

Fokussiere Dich von Beginn an auf die relevanten Bereiche und Anforderungen. Hinterfrage ob die Zusatzanforderungen/Änderungen dem Projektziel dienen, oder nicht eher „nice to have“ sind.

„Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt, sondern wenn man nichts mehr weglassen kann.“ Antoine de Saint-Exupéry

Anregungen zur Fokussierung

• Liegt zum Projektstart eine Kurzbeschreibung (Project Charter) des Projektes bzw. des Produktes vor, welcher alle relevanten Stakeholder zugestimmt haben?
• Wurde zu einem frühen Zeitpunkt ein MVP (Minimum Viable Product) des Projektes/Produktes definiert, welches u. a. das „Core-Feature“ beschreibt?
• Ziel sollte es sein, Produkte für die Zielgruppe zu entwickeln, nicht für einzelnen Anforderer oder Führungskräfte. Eine Frage hierzu könnte sein, ist die vermeintliche Anforderung aus Kundensicht relevant und wird sie direkt oder indirekt vom Konsument angefragt? Stichwort: Design Thinking.
• Zielkonflikte im Management auflösen. Sind alle Zielkonflikte erkannt (siehe auch Risikomanagement) und konkrete Maßnahmen zur Auflösung vereinbart worden (z.B. Ablieferungstermin erfordert Reduktion der Erwartungen an Produktscope)?

Eigenverantwortung

Dieses ist mir persönlich eines der wichtigsten Lessons Learned der vergangenen Projekte. Die Attitude der fehlenden Eigenverantwortung ist in unterschiedlichen Ausprägungen fast täglich im privaten und beruflichen Umfeld wahrnehmbar. Viele sehen nur Probleme, warum irgendetwas nicht klappt. Der Trick ist, die Sicht umzudrehen. Die Frage an sich selbst sollte sein, was kann ich machen, dass ich mein Ziel erreiche oder meinen Job erfüllen kann.

Robin Sharma umschreibt es aus meiner Sicht in diversen Büchern total inspirierend mit „The Leader Who Had No Title„*. Hierüber werde ich noch einen eigenen Artikel schreiben, da ich diese Sicht sehr interessant und inspirierend finde.

Hier ein paar konkrete Anregungen um Dein Projekt hinsichtlich Eigenverantwortung zu prüfen.

• Ist ein zentraler Verantwortlicher für das geplante Produkt/Produkt definiert? Vgl. Product Owner (PO) in SCRUM). Bei größeren Projekten, mit mehreren kleineren Teams, kann zusätzlich ein Chief Product Owner (CPO) implementiert werden.
• „Wer nicht im Projekt ist, ist nicht im Projekt“. D.h. alle Stakeholder dürfen Wünsche äußern, bleiben aber „Chicken“. Vgl. den Scrum Comic Klassiker mit „Chicken“ und „Pig“. Sind alle relevanten Verantwortlichen in der Projektorga erfasst und deren Rollen definiert?
• Projektleitung mit Ende zu Ende-Verantwortung ausstatten. Ist der Projektleiter mit den notwendigen Befugnissen zur Projektzielerreichung ausgestattet? Gibt es ein Zustimmung aller relevanten Bereiche zur Bereitstellung der notwendigen Ressourcen?
• Linienverantwortlicher/Vorgesetzter verpflichtet sich zum Sign-Off vom Projekt (inkl. Projektplänen) und den Projektmitarbeitern. Ist der Projekt-Charter vom Linienvorgesetzten unterschrieben und wird er über den aktuellen Status kontinuierlich informiert (Stichwort Reporting)?
• Erstrebenswert ist die Etablierung eines partnerschaftlichen Verhältnisses zwischen Projektmitgliedern und den Führungskräften. Um hierfür das notwendige Vertrauen zu schaffen, empfiehlt es sich, das Management über Relevantes zu informieren. Z. B. über Stand der Umsetzung und Projektrisiken. Ist der Vorgesetzte im Reporting kontinuierlich eingebunden?
• Es wäre wünschenswert, wenn die jew. Führungskraft (ggf. Projektsponsor) den Projektverantwortlichen unterstützt und coacht. Steht der Vorgesetzter als Projekt-Coach oder Berater zur Verfügung? Falls nein, gibt es einen Experten im Umfeld, an den ich mich bzgl. eines Coachings wenden kann?
• Habe den Mut zu Projektanfragen und Scopeänderungen auch nein zu sagen. Am Ende wirst Du am Erfolg des Projektes gemessen und nicht all diejenigen, die gerne noch diese und jene Anforderung umgesetzt haben möchten. Sind die Gründe für Deine Ablehnung ausreichend beschrieben, für Dritte verständlich und nachvollziehbar?
• Es ist eine starke Empfehlung, dass zeitnah stabile Teams für die Produktentwicklung zur Verfügung stehen. Hast Du Dein Wunsch-Team zusammen und ist das Team für die Dauer des Projektes hierfür freigestellt?

Aktives Risikomanagement

Kommen wir nun zu dem oft zu wenig beachteten Bereich eines Projektmanagers, dem Risikomanagement. Oder nennen wir es Chancenmanagement. Das klingt doch gleich viel positiver. Selbst wenn Du die folgende Liste der Tipps nicht beachtest oder vergisst, versuche in Deinem Projekt die Risiken nicht negativ zu sehen. Verstehe jedes Risiko als Chance einen Fehler oder ein Problem zu vermeiden und diese Chance in einen Erfolg zu wandeln. Z.B. erkennst Du das Risiko in der Feasibility Phase, dass ein potentieller Anbieter einer Zulieferung so klein ist, dass er insolvent gehen könnte. Bei der Recherche nach einem alternativen Anbieter findest du einen Vendor der die selbe Zulieferung 15% günstiger anbietet.

• Zur Etablierung eines offenen Chancenmanagements empfiehlt es sich, Risiken und Chancen offen ansprechen zu können (Im Sinne: Fail fast, fail cheap). Sind alle Projektbeteiligten angehalten eine offenes Risikomanagement zu leben?
• Risiken sollten von Projektbeginn bis zum Projektabschluss aufgenommen werden. Werden die Risiken von Beginn an von einem Verantwortlichen strukturiert erfasst, kontinuierlich überwacht und im Projekt-JF besprochen?
• Eine Anregung zur Steigerung der Motivation ist ein offener Austausch und die Chance, Veränderungen und Verbesserungen am Zusammenarbeitsprozess vornehmen zu können. Werden regelmäßig Lessons Learned im Projektteam zur Projektlaufzeit durchführt und verbessernde Maßnahmen umgesetzt?
• In einem Projekt gibt es immer Punkte auf die man einen starken oder weniger starken Einfluss hat. Wurden externe Abhängigkeiten im Projektplan explizit sichtbar gemacht?

„Real Case“ Planung

„Ja, das ist eine schöne Ideologie. Unser Management hat aber klar gesagt zum Stichtag muss das Projekt vollumfänglich fertig sein. Von uns Projektmitarbeitern weiß eigentlich jeder, dass es nicht klappen wird.“

Kommt Dir diese Aussage bekannt vor? Wenn ja, bist Du hier genau richtig. Klar haben wir definierte Timelines, ein begrenztes Budget und sollen am liebsten die Eierlegende-Wollmilch-Sau am Ende abliefern. Aber doch bitte mit Sinn und Verstand.

Eine wesentliche Erkenntnis im Rahmen der Projektplanung ist die oftmals fehlende Akzeptanz zu Planungspuffer bzw. Schätzungsungenauigkeiten. Durch die Definition eines Projekts, ist klar, dass es sich um ein einmaliges Vorhaben/Produkt handelt. D.h. es handelt sich nicht um eine Regeltätigkeit, die bereits x-fach ausgeübt wurde. Somit sollte es mehr als nachvollziehbar sein, dass das Projekt Schätzungsungenauigkeiten in der Planung enthalten sind.

• Welche Werte als Basis zur Schätzung liegen Dir vor? Je nach Projekterfahrung, hast Du evtl. bereits ähnliche Projekte durchgeführt oder Zugang zu Experten, die Dir Schätzungen liefern können. Je nach dem, kannst Du für Deine Schätzung eine Grobschätzung, z.B. einen Top-Down Ansatz wählen, oder eine three-point estimation.
• Hat das Projekt einen konkreten Startzeitpunkt? Diverse Events für einen Startzeitpunkt sind möglich.
• Puffer einplanen und diesen sichtbar machen. Ein Projekt ohne Puffer („ambitionierter Plan“) bedeutet hohes Risiko, dass Ziele nicht erreicht werden. Faustregel: 2/3 der Zeit ist Entwicklung, 1/3 ist Puffer. Nach 50% Projektfortschritt 3:1, nach 75% 4:1 möglich. Wurde im Projektplan explizit Puffer eingeplant?
• Ein belastbarer Meilensteinplan kann zu Beginn des Projektes noch nicht vorliegen. Wurde im Projekt-JF und im Reporting verdeutlicht, dass zu einer frühen Phasen nur Grobschätzungen (ROM Estimation) möglich sind?
• Eine Anregung für die Projektplanung ist, die Ausrichtung nach den Terminen CeBIT und IFA zu entzerren. Optimales Ziel wäre, das Produkt (z.B. den MVP Umfang) zu einem früheren Termin verfügbar und ggf. technisch gelauncht zu haben. Wurden im Projektplan die Termine für die techn. Produktfertigstellungen (können mehrere sein, vgl. SCRUM) und die Markteinführung inkl. Puffer eingeplant und kommuniziert?
• In einigen Projekten tendiert man dazu, nur einen Launchtermin mit dem vollständigen Anforderungsumfang zu planen und einzuhalten. Die fehlenden „Zwischenauskopplungen“ führen ggf. zu minderer Qualität und unerfüllten Erwartungen. Wurden mehrere Releases eingeplant und kommuniziert, die die Schritte zwischen Nullserie (z.B. MVP) und Serienreife beschreiben?
• Tests sollten entwicklungsbegleitend durchgeführt werden (Testzeiträume sind keine Pufferzonen). Sind in Entwicklungszeiten im Projektplan bereits Testzyklen mit eingeplant?

Fazit

Übrigens, der Input für diesen Artikel entstand in konspirativem Teamwork zusammen mit Thomas Jung, Johan Heidemann und Florian Scheiber.

Unser Job als Projektmanager ist es, das Projekt objektiv zu managen, das Projektziel zu erreichen und Risiken zu eliminieren. Der Trick ist, lösungsorientiert vorzugehen und sich nicht von allen Probleme die Sicht auf das Wesentliche zu verbauen. Um auch Deinem Management Deine Kompetenz widerzuspiegeln, empfehle ich zum nächsten Steering-Board für Dein Problem mind. einen Lösungsvorschlag im Gepäck zu haben und eine Empfehlung auszusprechen. Schaffe Transparenz über den Planungszustand und die Risiken. Solltest Du mal keine Maßnahme für ein Problem ableiten können, ist es kein Imageverlust, seine Vorgesetzten nach Unterstützung zu fragen.

Was sind Deine Erkenntnisse aus den vergangenen Projekten? Und welche essentiellen Lessons Learned hast Du aus der Vergangenheit gelernt? Danke für Dein Feedback!

* Affiliate Link – Ggf. wird es ja nicht etwas mit dem Passiveinkommen 😉