​ Projekte in der Krise I ​

Warum Projektplanung wichtig ist.

Das Projektgeschäft ist bekanntermaßen ziemlich tückisch. Oft gibt es Probleme, die man erst im Nachhinein erkennt und selten nimmt sich jemand die Zeit die Probleme aus der Vergangenheit wirklich zu reflektieren und auszuwerten. Das führt dazu, dass einige Projektleiter mit großer Erfahrung ein Projekt zum Erfolg führen können. Hauptsächlich dann, wenn genügend Probleme der aus vorhergehenden Projekten bereits bekannt sind und man weiß wie man damit umgeht. Kommen zu viele unbekannte Probleme oder ist der Projektleiter nicht erfahren in dieser Materie, wird irgendwann der kritische Punkt überschritten, bei dem das Projektteam die Fehler nicht mehr ausgleichen oder korrigieren kann. In diesem Fall wird das Projekt dann ein Desaster.

Viele Firmen, die ich kennen gelernt habe sind der Meinung, dass sie mit Projekten umgehen können. Eben weil sie ausreichend Projekte absolviert haben, bei denen das Ergebnis letzten Ends den Erwartungen des Kunden entsprochen hat – oder zumindest die Mindestanforderungen erfüllt hat. Am Ende zählt nur noch das Ergebnis und der Weg dorthin verschwindet oft im Gedächtnis des Einzelnen. Selten wird das Projekt noch einmal reflektiert oder gar Erkenntnisse schriftlich festgehalten.

Aus diesem Grund möchte ich in dieser Beitragsserie mal über meine persönlichen Erfahrungen der größten Projektfehler berichten und mögliche Gegenmaßnahmen zeigen. Leider sind das alles keine magischen Werkzeuge, die alles einfach machen, sondern nur Strukturen und Prozesse, die Initial erst einmal wieder Mehraufwände verursachen, bevor sie ihre Magie wirken können. Ein gewisses Maß an Vertrauen und auch Durchsetzungsvermögen gegenüber den Projektbeteiligten ist also durchaus notwendig.

Keine ausreichende Planung zu Beginn eines Projektes

Tatsächlich ist die mangelnde Planung am Anfang oft schon der Grundstein für das Fiasko. Dabei waren die Absichten gut. Der Kunde hat Zeitdruck, es geht nur um einen sehr überschaubaren Projektrahmen oder der Entwickler hat ohnehin schon signalisiert, dass er genau weiß was zu tun ist oder man möchte man Zeit aufholen. Es gibt diverse Gründe dafür den Projektstart ad hoc durchzuführen und einfach mal loszulegen. Oft ist die Ursache auch nicht bei einem einzelnen Grund zu suchen, sondern ergibt sich aus einer Summe verschiedener Teile.

Und dann passiert es. Zum Beispiel hat sich der entscheidende Entwickler krank gemeldet. Der Zeitplan ist aufgrund von Fehlern im Projekt nun unhaltbar geworden und es ist viel zu spät aufgefallen um noch Gegenmaßnahmen zu ergreifen. Der überschaubare Projektrahmen wurde durch diverse kleinere Änderungen aufgebläht, ohne das es aufgefallen ist. Die Architektur hat sich durch diese kleineren Änderungen nun doch entscheidend geändert.

Das Ergebnis ist oftmals verheerend. Der mangelnde Pflegeaufwand am Anfang zieht sich dann meistens wie ein roter Faden durch das Projekt. Änderungswünsche werden nicht dokumentiert, Probleme nicht an den Kunden kommuniziert und der Druck auf die Projektmitarbeiter wird immer größer. Da nicht klar ist, welche Anforderung wann und wie rein kam, wird einfach gemacht was der Kunde sagt. Man weiß nicht mehr, wie genau er seine Anfrage gestellt hat und irgendwann ist das Geld alle und das Produkt noch nicht fertig. Beide Parteien streiten sich um das Produkt und am Ende wird das Projekt entweder eingestampft oder unter enormen Kosten zu Ende geführt. Niemand ist glücklich und voraussichtlich war es das letzte Projekt in dieser Konstellation.

So könnte zumindest der Extremfall aussehen. Normalerweise ist es so, dass die Mitarbeiter des Zulieferers mit Überstunden, Vermutungen und einer gewissen Bugtoleranz doch noch das Ziel erreichen. Der Kunde ist zwar nicht glücklich, doch die Fehler werden mit dem nächsten und übernächsten Release gefixt und das Projekt unter „Erfahrung“ verbucht. Leider wieder ohne Retrospektive.

Dieses Beispiel zeigt wie leicht aus gutem Willen am Anfang und der Idee die eigene Agilität zu demonstrieren ein Desaster werden kann. Doch was hilf dagegen? Natürlich, Struktur. Sonst hätte ich den Beitrag ja nicht so eingeleitet. Aus meiner Sicht gibt es einige Grundsätzliche Dinge, die beim Projektstart auf jeden Fall erledigt werden müssen. In welcher Ausbaustufe das ganze Stattfindet, hängt dabei vom jeweiligen Projektumfang ab und einige Sachen können auch zunächst grob Skizziert und später ausdefiniert werden. Aber zumindest die Grundstrukturen sollten da sein.

Ein Projektplan auf Basis der Schätzung

Für das Projekt wurde initial irgendetwas geschätzt. Sonst hätte man den Auftrag ja nicht bekommen. Das sind die Zahlen, die für einen ersten Projektplan als Grundgerüst dienen. Welche Pakete wurden vereinbart, welche Zahlen stehen in PT für welche Rolle daran. Gibt es Abgabetermine und wer kann die Rollen besetzen. Je detaillierter dieser Projektplan definiert werden kann, umso besser sind die Ergebnisse später messbar. Doch es reicht am Anfang auch ein grobes Gerüst als Richtschnur. So sehen wir zumindest, wenn etwas völlig aus dem Ruder läuft und wir gegensteuern oder den Kunden informieren müssen.

Personalplanung auf Basis des Projektplans

Damit die richtigen Leute für mein Projekt zur Verfügung stehen muss ich diese auch einplanen. Je früher und weitreichender ich diese Planung durchführen kann, desto höher ist die Chance, dass meine Leute auch verfügbar sind. Damit ich nicht rate, wann ich welche Leute benötige, sollte der Projekt- und Meilensteinplan vorher zumindest in einem ersten Stand sein. Somit weiß ich, dass ich nach Meilenstein M1 die Person XY benötige, da sie eine Kernkompetenz für die Erbringung von M2 hat. Natürlich kann ich noch nicht auf den Tag genau sagen welche Personen ich von Anfang bis Ende benötige. Aber über den Projektplan bekomme ich eine Vorstellung und kann die Leute in dem betreffenden Zeitraum zumindest schon einmal vorplanen. Mit jedem Statusmeeting und jedem erfolgreichen Modul, dass abgeschlossen wurde, kann ich den Projektplan nachschärfen und auch die Personalplanung optimieren. Somit wird nicht nur für mich, sondern auch meine Leute der eigentliche Termin immer greifbarer und andere Projekte können sich nach dieser Planung immer besser richten.

Klärung der Abnahmekriterien der ersten Meilensteine / Sprints etc.

Bis zum nächsten Meilenstein, besonders am Anfang, gibt es oft sehr viel zu tun. Auch Dinge, die eigentlich nichts mit meiner Zielerreichung zu tun haben, sondern bereits vorgeplant werden für spätere Schritte. Damit man das eigentliche Ziel des aktuellen Meilensteins nicht aus den Augen verliert und sich in Details verstrickt, sollte für jeden Meilenstein klare Abnahmekriterien definiert sein. Was muss erreicht werden, damit der Kunde glücklich ist? In Scrum würden diese Aspekte einen möglichst hohen Wert in Story Points bekommen und somit zeitnah erledigt werden. Während die Arbeiten für später oder die weniger relevanten Nebentätigkeiten entsprechend herunter priorisiert werden. Dies hilft jedem einen klaren Blick auf das Ziel zu behalten und dem Projektleiter die Erreichbarkeit des Ziels und den aktuellen Status leichter zu messen.

Definition und Beschaffung der benötigten Arbeitsmaterialien

Es hört sich total trivial an, doch oftmals ist genau hier der Knackpunkt von vielen Projekten. Spätestens beim Projekt-Kick-Off muss klar sein, welche Arbeitsmaterialien benötigt werden, wer diese beschafft und wann die Arbeitsfähigkeit hergestellt ist. Erst dann – und wirklich erst dann – lohnt es sich mit einem Team in das Projekt einzusteigen. Bis zu diesem Zeitpunkt sollten lediglich die Experten für die Arbeitsmaterialien arbeiten und alle anderen Personen in anderen Aufgaben aktiv sein. Zu diesen Arbeitsmaterialien gehören in unserer Welt VSTS (TFS)-Projekt, Entwicklungsmaschinen, Zugriffe auf Kundensysteme, vollständige Anforderungen (zumindest für die ersten 2 Sprints), Ansprechpartner, Architekturkonzepte, Testkonzepte und ähnliches. So lange diese Bausteine nicht verfügbar sind und problemlos ihre Aufgabe erfüllen ist jede Art von operativer Hektik kontraproduktiv und wird letzten Ends die Qualität des Projektes untergraben und einem später wieder auf die Füße fallen.

Klärung der Aufgabenbereiche und Rollen

Auch das klingt einfach. Ein Entwickler soll natürlich den Code schreiben! Dafür haben ihr ihn ja dazu genommen! Ja, schon. Aber was denn noch? Ist er für das Aufsetzen der Entwicklungsmaschine zuständig? Ist der Architekt für Kundenkommunikation zuständig? Ist der Qualitätsmanager für die Erstellung der Testfälle zuständig? Für jeden Mitarbeiter sollte es ein gezieltes Onboarding in das Projekt geben. Wenn dies nicht möglich ist, sollte das Onboarding zumindest zentral in einem Projekt-Kick-Off stattfinden. Am Ende muss sich der Mitarbeiter genau auf diese Rollenbeschreibungen verlassen können und sich auch direkt darauf committen. Denn nur so ist sichergestellt, dass er eine implizite Andeutung nicht überhört hat. Gerade bei den oben genannten Beispielen ist dies nicht zwangsläufig so und der Kollege fühlt sich vielleicht gar nicht zuständig, obwohl der Projektleiter es eigentlich genau so gemeint hat. Deshalb lieber einmal zu viel sagen, was der Kollege machen soll und ihn das auch noch einmal in eigenen Worten wiederholen lassen, damit alle auf den selben Stand sind. Besonders bei langen Projekten bietet sich außerdem an, diese Aufgaben noch einmal schriftlich zu fixieren, damit sie nicht in Vergessenheit geraten. In Scrum könnte man diese dann zum Teil der Retrospektive machen. Waren wirklich alle Teammitglieder in Ihrer Rolle aktiv? Sind sie gut damit klar gekommen, oder bestehen irgendwo Lücken, die es zu schließen gilt?

ALM Tech Blog

Application Lifecycle, Qualitäts- und Projekt-Management