Projektmanagement

Wenn der Projektfortschritt hinter Plan ist…

Veröffentlicht am

Lassen Sie uns mit einem kleinen Quiz starten: Was machen Sie, wenn Sie eine derartige Grafik sehen:

  • Sie verschieben den Endtermin nach hinten
  • Sie reduzieren das Ziel (die Anzahl)
  • Sie ergreifen Maßnahmen, um die Produktivität zu steigern
  • Sie machen nichts – ab der nächsten Woche wird die Produktivität ganz sicher steigen

Interessanterweise erlebe ich es immer wieder (und erschreckend oft), dass die Option 4 verfolgt wird. Dabei ist es unerheblich, ob es sich um den Projektfortschritt, Testfortschritt oder Produktionsfortschritt handelt. Die Menschen, die derartige Entscheidungen treffen, sind in der Regel intelligent, gut ausgebildet und mit reichlich Berufserfahrung ausgestattet.

Wieso laufen diese Menschen sehenden Auges ins Verderben? Wieso wählen sie einen objektiv unmöglichen Weg? Diese Frage beschäftigt mich seit vielen Jahren.

Ich habe hierzu die folgende Hypothese entwickelt:

  • Das Projekt / der Test / die Produktion existiert nicht allein, sondern ist in ein Umfeld eingebettet
  • Das Umfeld ist üblicherweise ständigen Veränderungen unterworfen
  • Früher oder später kann eine dieser externen Veränderungen als Erklärung dienen, warum der eigene Plan nicht erreicht werden kann

Ich höre beispielsweise Erklärungen wie…

  • „Projekt X ist in Verzug und benötigt zusätzliche Ressourcen. Selbstverständlich helfen wir, das hat aber leider Auswirkungen auf unseren eigenen Projektplan…“
  •  „Das Testsystem unseres Partners Y steht diese Woche nicht zur Verfügung. Ausgerechnet jetzt hatten wir unseren Spezialisten für die Tests eingeplant, es ist völlig offen, wann er wieder zur Verfügung steht…“
  • „Wir hatten mit Unterstützung aus Abteilung Z geplant. Die Kollegen wurden überraschend für ein anderes Thema abgezogen, jetzt können wir unseren Plan nicht erreichen…“

Die Gründe für die Planabweichung liegen außerhalb des eigenen Einflussbereichs, daher konnte man selber auch nichts dagegen tun.

Jetzt könnte man sagen „Ist doch egal, aus welchem Anlass der Plan aktualisiert wird und Maßnahmen ergriffen werden. Wichtig ist, dass etwas passiert“. Dieser Aussage stimme ich nicht zu. Ja, die Kosten auf Grund einer längeren Projektlaufzeit fallen eh an. Ja, die Kosten für zusätzliche Tester fallen eh an. Der größte Schaden entsteht allerdings üblicherweise nicht durch erhöhte Projektkosten, sondern durch entgangene Chancen wegen einer späteren produktiven Nutzung.

  • Das neue Cabrio steht nicht im Frühling bei den Händlern? Dann kaufen die Kunden ein anderes…
  • Die neue Spielekonsole ist nicht für das Weihnachtsgeschäft verfügbar? Dann kaufen die Kunden bei der Konkurrenz…
  • Die Flugzeuge sind noch nicht mit den neuen Business Class Sitzen ausgestattet? Dann fliegen die Kunden mit der Konkurrenz…

Neben dem direkten Schaden durch entgangene Chancen entsteht ggf. auch ein indirekter Schaden – die Kunden bleiben bei der Konkurrenz. Projektleiter, die auf erkannte Probleme nicht unverzüglichen reagieren, schaden einem Unternehmen mehr, als es auf den Blick scheint. Daher ist das Aussitzen von Problemen bis „5 vor 12“ in meinen Augen die schlechteste Option.

Allgemein

Anwendertest und Scrum – wie passt das zusammen?

Veröffentlicht am

Ich saß vor einigen Tagen mit Kollegen zum Thema „Test“ zusammen, insbesondere aus einer Anwender- / Nutzerperspektive. In klassischen Projektvorgehensweisen wie beispielsweise V-Modell ist diesem Test üblicherweise eine eigene Projektphase „Abnahmetest“ oder auch „User Acceptance Test“ gewidmet. Insofern stellt sich weniger die Frage, ob ein Anwendertest durchgeführt wird, sondern wie gut und wie ausführlich.

Und in Scrum? Die Definition of Done wird gemeinsam entwickelt, das Entwicklungsteam ist für die Qualität der Software verantwortlich, der Product Owner definiert Akzeptanzkriterien in den User Stories. Ergo gibt es keine Notwendigkeit für Anwendertest?!

Falsch – und gleichzeitig richtig. Ein Ziel von Scrum ist das kontinuierliche und frühzeitige Feedback von Nutzern (test and adapt). Insofern bietet Scrum eine großartige Chance, durch Anwendertests die Software kontinuierlich besser zu machen. Es benötigt nicht mehr einer langen Testphase an deren Ende nur das Schlimmste verhindert werden kann, sondern die Anwender können kontinuierlich testen und ihr Feedback äußern.

Damit die Anwendertests nicht in Freestyle-Tests ausarten ist auch hier ein wenig Struktur hilfreich, die sich an den Zielen der Anwendertests orientieren kann:

  • Verbesserung der Software:
    • Aus meiner Sicht bieten sich hier Tests entlang der Geschäftsprozesse an. Auf diese Weise kann leicht festgestellt werden, wie gut (schnell, qualitativ hochwertig, …) die Software die Prozesse unterstützt. Außerdem lassen sich Lücken identifizieren, z.B. welche Sonderfälle nicht unterstützt werden.
    • Sofern eine Prozessdokumentation vorliegt, ist dies eine wunderbare Ausgangsbasis für diese Art von Tests.
    • Verbesserungsvorschläge können als neue Anforderungen an den Product Owner gehen, der sie regulär bewertet, priorisiert und ggf. umsetzt
  • Identifikation von Fehlern:
    • Es muss der Anspruch des agilen Entwicklungsteams sein, funktionierende Software auszuliefern. Aus Anwendersicht sollte es daher nicht notwendig sein, explizit nach Fehlern zu suchen.
    • Sofern Fehler dennoch gefunden werden, sollten sie sofort vom Entwicklungsteam behoben werden (Null-Toleranz-Strategie)
  • Formale Abnahme:
    • Eine formale Abnahme wird vom Product Owner durchgeführt. Basis hierfür ist die gemeinsam verabschiedete Definition of Done sowie die Akzeptanzkriterien in den User Stories.
    • Vor diesem Hintergrund kann es aus Anwendersicht sinnvoll sein, gemeinsam mit dem Product Owner die User Stories zu erstellen. So werden unnötige Diskussionen nach Abnahme vermieden.

Aus meiner Sicht wird hieraus deutlich, dass der Anwendertest im agilen Umfeld nicht überflüssig wird, er sich allerdings verändert. Weg von „das Schlimmste verhindern“ hin zu wertstiftenden Verbesserungen der Software und zu glücklichen Anwendern!

Allgemein

Ein Projektplan, an den nicht einmal der Ersteller glaubt

Veröffentlicht am

Das Leben ist voller Überraschungen. Ein Kollege stellte mir neulich den Plan für sein Projekt vor. Ich schaute etwas irritiert, da der Plan aus meiner Sicht nicht realistisch war. Der Kollege nickte nur und sagte: „Stimmt. Die Annahmen zu den Aufgaben, zusätzlichen Mitarbeitern und der Produktivität sind so vage, da kann ich eigentlich gar nicht planen.“ Ich war sprachlos. In diesem Fall war der Endtermin nämlich unverrückbar…

Nehmen wir als Analogie den Weihnachtsmann. Santa Claus möchte am 24.12. die Geschenke für 100.000 Kinder verteilen. Jedoch…

  • …weiß er nicht, ob alle Geschenke im September angeliefert werden oder auch noch später
  • …weiß er nicht, ob ihn mehr Wichtel als vorheriges Jahr beim Einpacken unterstützen
  • …weiß er nicht, ob die Wichtel signifikant schneller packen als vorheriges Jahr

Die Planung geht jedoch von genau diesen Punkten aus.

Schlimm? Das kommt drauf an, wie man die möglichen Konsequenzen einschätzt.

  • Möglicherweise bekommen nur (zufällig ausgewählte) 80.000 Kinder ihre Geschenke. Aus Sicht von Santa Claus ist das wahrscheinlich nicht akzeptabel.
  • Möglicherweise bekommen die Kinder ihre Geschenke erst am 17. Januar. Aus Sicht von Santa Claus ist das wahrscheinlich nicht akzeptabel.
  • Möglicherweise werden die Wichtel wegen einer Überlastung krank. Aus Sicht von Santa Claus ist das wahrscheinlich nicht akzeptabel.

Was sollte der Weihnachtsmann tun? In Abhängigkeit von den Auswirkungen eines Scheiterns sollte der Projektleiter einen pessimistischen, realistischen oder optimistischen Plan entwerfen. Wenn ein Scheitern nicht akzeptabel ist, dann sollte der Projektleiter bei der Durchführung immer „auf der sicheren Seite“ sein. Dies kann beispielsweise bedeuten

  • Dass er bewusst weniger Kinder beschenkt als ursprünglich geplant (z.B. nur Kinder ab 4 Jahren)
  • Dass er die Schleife des Geschenks weglässt
  • Dass er Unterstützung vom Nikolaus und den heiligen drei Königen anfordert

Derartige Maßnahmen sollte der Projektleiter sofort ergreifen. Es besteht keine Notwendigkeit, bis zum 23. Dezember zu warten, um festzustellen, dass der Plan nicht funktioniert hat…

Allgemein

Lügen haben kurze Beine

Veröffentlicht am

Ich habe neulich meiner sechsjährigen Tochter erklärt, dass sich Lügen und Schwindeleien nicht lohnen. Früher oder später kommt die Wahrheit heraus. Bei Kindern sind es eher Kleinigkeiten wie „hast du dir die Hände gewaschen“, die in der Regel keine ernsthaften Konsequenzen haben. Hier geht es in erster Linie um das Prinzip und die Einstellung.

Im Projektgeschäft sind Lügen, Unwahrheiten und Halbwahrheiten leider weit verbreitet, in der Regel in Verbindung mit Projektstatus, Fertigstellungstermin, Budgeteinhaltung oder sogar mit dem initialen Plan. Beispiele gefällig?

  • Der berühmte Melonenstatus (außen grün, innen rot): Die Projektmitarbeiter erklären, dass sie ein ernsthaften Problem haben bzw. nicht rechtzeitig fertig werden (rot). Der Teilprojektleiter signalisiert ein Risiko (gelb). Der Projektleiter erklärt dem Lenkungsausschuss, alles liefe nach Plan (grün).
  • An einem Fertigstellungstermin wird bis zur letzten Sekunde festgehalten. „Plötzlich“ wird festgestellt, dass man nicht rechtzeitig fertig wird.
  • Ein Projektplan wird vorgestellt und verabschiedet, der objektiv unmöglich umzusetzen ist (Geplanter Aufwand, geplante Ressourcen und geplante Zeit passen nicht zusammen).

Schlimm? Ja. Mit derartigen Unwahrheiten und Halbwahrheiten beschneidet man seine Handlungsmöglichkeiten als Projektleiter:

  • Ein korrekter Status ermöglicht es dem Projektleiter, ein angemessenes Erwartungsmanagement des Lenkungsausschusses und des Auftraggebers durchzuführen. Überraschungen werden vermieden.
  • Ein korrekter Status ermöglicht es dem Projektleiter, ggf. Unterstützung von außerhalb des Projektes zu erhalten bzw. die Prioritäten innerhalb des Projektes
  • Ein korrekter Status ermöglicht es, rechtzeitig Gegenmaßnahmen zu ergreifen, um einen Termin noch zu ermöglichen (und nicht erst in einen Panikmodus zu verfallen, wenn das Kind bereits in den Brunnen gefallen ist)
  • Als Projektleiter begibt man sich in einen Teufelskreislauf, in dem auf eine Lüge eine weitere folgt, und noch eine weitere, … da man nicht sein Gesicht verlieren möchte.

Lügen haben kurze Beine. Es ist nicht die Frage, ob eine Unwahrheit entdeckt wird, sondern wann.

Warum existiert das Phänomen der Unwahrheiten so häufig im Projektmanagement? Aus meiner Sicht gibt es hierfür zwei zentrale Erklärungen:

  • Unkenntnis. Häufig werden in der Projektdurchführung keine quantitativen Fortschrittsmessungen genutzt. Damit kommt es zum „Fast-Fertig-Syndrom“ und man folgt der trügerischen Hoffnung, dass das Problem in der nächsten Berichtsperiode von alleine verschwindet. Dies passiert in der Regel nicht…
  • Ego. Als Projektleiter bin ich Macher, Leiter, Manager und habe meinen Laden im Griff. Jede Abweichung vom Plan werte ich als persönliches Versagen und lasse sie nicht zu. Bis es zu spät ist…

Es ist Zeit, sich den unbequemen Wahrheiten des Projektgeschäfts zustellen. Ich kann an dieser Stelle nur für totale Transparenz und den Einsatz quantitativer Projektmanagementmethoden plädieren. Aus meiner Sicht ist dies ein entscheidender Vorteil agiler Vorgehensweisen wie z.B. Scrum: schnelles Feedback, Transparenz und quantitative Methoden gibt es fast automatisch.