Arbeitspakete sind die atomaren Bausteine des Projektplans. Die Definition der Arbeitspakete hat großen Einfluss auf die Verständlichkeit des Plans aber auch auf seine Handhabbarkeit bei der Verfolgung und Aktualisierung. Es ist sehr schwierig, allgemein gültige Regeln aufzustellen, wie Arbeitspakete beschaffen sein müssen; jedes Projekt, jeder Projektleiter und jedes Projektumfeld hat spezifische Vorlieben und stellt andere Anforderungen. Dennoch kann und sollte man darüber nachdenken, welche Einflussgrößen es gibt und wie sie sich auf den Umgang mit dem Projektplan auswirken.
Je größer die Arbeitspakete gewählt werden, desto ungenauer kann der Fortschritt des Projekts ermittelt werden. In manchen Projekten und Projektumfeldern kann man mit dieser Unschärfe gut leben, während es in anderen einen gefährlichen Blindflug bedeutet. Wählt man Arbeitspakete hingegen zu klein, lässt sich der Fortschritt wiederum sehr gut ermitteln, sofern man sich und seinen Mitarbeitern die Bürde der Aktualisierung aufhalsen will. und kann. Ein todsicheres Mittel für Unmut im Team sind eine Vielzahl sehr kleiner Arbeitspakete mit jeweils eigenen Positionen im Zeiterfassungssystem, so dass die Arbeitszeit auf mindestens 10, besser noch 20, verschiedene Positionen verbucht werden muss und jede Fehlbuchung gerügt wird.
Zu große Arbeitspakete sind also schwer zu planen und zu verfolgen; zu kleine erschweren die Aktualisierung des Planes und führen zu Unmut angesichts des administrativen Aufwands für den einzelnen Mitarbeiter. Abgesehen davon beschädigt das Bedürfnis nach Micromanagement, dessen Symptom zu kleine Arbeitspakete sind, die intrinsiche Motivation der Mitarbeiter. Als ein wesentlicher Baustein der intrinsichen Motivation von Menschen gilt nämlich die Autonomie und Eigenverantwortung, wie es in diesem ausgezeichneten Video zum Buch „Drive“ von Daniel Pink erklärt wird.
Je größer Arbeitspakete gewählt werden, desto schwierig wird es diese logisch richtig in der Ablaufplanung miteinander zu verknüpfen. Es hängt dann alles irgendwie mit allem zusammen und der Plan besteht irgendwann nur noch aus wenigen lang und mehr oder weniger parallel laufenden Arbeitspaketen ohne explizite Abhängigkeiten. Neben dem bereits erwähnten Problem der Unschärfe der Fortschrittsmessung, macht es ein solch degenerierter Plan tendenziell auch schwieriger Auswirkungen von Ereignissen zu bewerten. Wenn beispielsweise Konzeption und Programmierung in ein einziges Arbeitspaket gepackt wurden, lässt sich die Abhängigkeit der Erstellung von Testfällen und Testdaten zur Konzeption gar nicht mehr ausdrücken und Auswirkungen einer Verzögerung der Konzeption lassen sich nur noch mit implizitem Nebenwissen erkennen.
Arbeitspakete richtig zu schneiden ist nicht einfach. Es gilt abzuwägen zwischen dem Bedürfnis nach Kontrolle und Verfolgung des Plans einerseits und dem Aufwand für die Aktualisierung andererseits. Vor dem Hintergrund der negativen Auswirkungen von zu kleinen Arbeitspaketen auf die Motivation, sollten Arbeitspakete lieber etwas größer sein und dem Bedürfnis nach eigenverantwortlichem Handeln der Menschen Rechnung tragen. Dem damit einhergehenden Problem der Unschärfe hinsichtlich der Abarbeitung kann beispielsweise durch definierte Statusschritte je Arbeitspaket begegnet werden.
Arbeitspakete sind die atomaren Bausteine eines Projektplans und die richtige Wahl hinsichtlich Größe und Inhalt hat große Auswirkung auf die Handhabbarkeit des Planes. Arbeitspakete alleine definieren allerdings nur die Struktur des Projekts, den Leistungsumfang, sie machen aber noch keine Aussage über den Ablauf des Projekts. Erst durch die logisch richtigen Verknüpfungen der Arbeitspakete, ihre Beziehungen zueinander, entsteht ein Ablaufplan, der in seiner Verkörperung als Gantt-Diagramm der Inbegriff eines Projektplans ist.
Methodische Fehler
»Das Ergebnis seh’ ich wohl, allein mir fehlt Methode!«, möchte man frei nach Goethes Faust beim Anblick so manches Projektplans ausrufen. Oft hat der Planende eine mehr oder weniger konkrete Vorstellung des Ablaufs und weiß beispielsweise, dass ein Arbeitspaket B erst nach dem Arbeitspaket A beginnen kann. In Ermanglung der richtigen Methode wird dann aber einfach Arbeitspaket B so weit auf der Zeitachse verschoben, bis es passt.
Das unterstützen die gängigen Projektplanungswerkzeuge auch alle, allerdings ist die damit ausgedrückte Bedeutung eine vollkommen andere: Arbeitspaket B hat dadurch einen festen frühesten Startzeitpunkt bekommen! Aus der Information »Arbeitspaket B kann erst nach Arbeitspaket A starten« wurde so »Arbeitspaket B startet frühestens am 8.3.2013«. Mit dieser Vorgehensweise lassen sich wunderschöne Pläne ohne die ganzen störenden Pfeile basteln, zu mehr als einem schönen Bildschirmfoto für eine Präsentation zu Projektstart taugen derart misshandelte Pläne allerdings nicht.
Abhängigkeiten explizit machen
Die methodisch saubere Vorgehensweise, um von einer gegliederten Liste von Arbeitspaketen zu dem ersehnten Gantt-Diagramm zu gelangen, erfordert das Verknüpfen von Arbeitspaketen. Mit einer solchen Verknüpfung werden logischeAbhängigkeiten definiert und explizit dokumentiert. Es ergeben sich prinzipiell die folgenden vier Möglichkeiten zwei Arbeitspakete miteinander zu verknüpfen.
Normalfolge oder Ende-Anfang-Beziehung (EA)
Logische Bedeutung: Wenn A endet, startet B.
Der Klassiker schlechthin. Ein Großteil der Beziehungen in einem Projektplan fallen in diese Kategorie.
Endefolge oder Ende-Ende-Beziehung (EE)
Logische Bedeutung: Wenn A endet, dann endet auch B.
Obwohl es auf den ersten Blick so aussehen mag, ist die Aussage nicht gleichbedeutend mit »A und B enden gleichzeitig.« Diese Beziehung ist nicht symmetrisch. Wenn sich A verzögert, dann wird sich auch das Ende von B verzögern, aber wenn sich B verzögert, kann A trotzdem schon beendet werden. Als Beispiel nehmen wir für einen Moment an, dass A und B beide 5 Tage Dauer haben. Verlängert man nun A um einen Tag ergibt sich das folgende Bild.
Das Ende von B verschiebt sich also automatisch mit. Wohingegen bei einer Verlängerung von B um einen Tag nicht auf das Ende von A auswirkt.
Anfangsfolge oder Anfang-Anfang-Beziehung (AA)
Logische Bedeutung: Wenn A beginnt, dann beginnt auch B.
Wie bei der Endfolge ist auch das nicht gleichbedeutend mit »A und B beginnen gleichzeitig.« B beginnt hier immer mit A zusammen, aber A kann vor B starten, falls sich B verzögert. Startet A in obigem Beispiel einen Tag später verschiebt dies auch B.
Umgekehrt verschiebt aber ein Tag späterer Start von B nicht den Start von A.
Sprungfolge oder Anfang-Ende-Beziehung (AE)
Logische Bedeutung: Wenn A beginnt, endet B.
Klingt komisch, findet aber tatsächlich in seltenen Fällen Anwendung. Wenn beispielsweise ein neues Backup-System eingeführt wird, dann endet der Betrieb des alten (B), wenn der des neuen gestartet wurde (A).
Vollständigkeit
Dennoch werden diese Abhängigkeiten oder Beziehungen oft nur unvollständig erfasst. Nämlich nur solange bis der Plan in etwa so aussieht, wie man es sich vorgestellt hatte. Das ist zwar schon ein deutlicher Fortschritt gegenüber dem eingangs beschriebenen brutalen Verschieben von Arbeitspaketen, birgt aber trotzdem noch Gefahren. Im folgenden Beispiel scheint es auf den ersten Blick unnötig, neben der EA-Beziehung zwischen A und C auch noch die EA-Beziehung zwischen B und C zu ziehen (natürlich nur wenn diese sich auch inhaltlich rechtfertigen lässt). Schließlich ändert diese ja nichts an dem Ablauf. Noch nicht, denn sobald sich B verschiebt oder verlängert, würde sich an dem Ablauf etwas ändern, was man aber ohne diese Beziehung übersehen wird. Darüber hinaus leistet die explizit beschriebene Beziehung einen wichtigen Beitrag zum Verständnis der Zusammenhänge im Projekt.
Fazit
Erst die logisch richtigen Beziehungen zwischen den Arbeitspaketen ergeben den Ablaufplan. Jedenfalls in einem ersten Entwurf, den es dann zu optimieren gilt. Die Mächtigkeit von gängiger Planungssoftware und der Druck schnell Mal einen Plan zu machen, verleiten allerdings oft zu Abkürzungen, die sich im weiteren Projektverlauf rächen. Wer zeitliche Einschränkungen missbraucht, um Arbeitspakte nach Belieben zu verschieben oder wer Abhängigkeiten unlogisch oder unvollständig nutzt, wird mit erhöhtem Aufwand bei der Aktualisierung des Planes bestraft.
Ressourcen zuweisen
Die Arbeitspakete im Ablaufplan erledigen sich nicht von selbst. Es braucht in der Regel Menschen zur Ausführung der geplanten Arbeiten. Diese so einfach scheinende Zuweisung von Mitarbeitern an die Arbeitspakete im Ablaufplan sorgt regelmäßig für Verzweiflung und Frust beim ungeübten Projektplaner. Da verkürzt sich plötzlich die Dauer von Arbeitpaketen oder es verschieben sich diese wie von Geisterhand. So war das nicht gemeint, denkt man, und sucht erschrocken nach dem richtigen Häkchen.
Menschen sind keine Ressourcen
Eines vorweg: In grässlich tayloristischer Manier werden Menschen in der Terminologie des Projektmanagements immer noch in einen Topf mit (anderen) Maschinen geworfen und übergreifend einfach Ressourcen genannt. Wenngleich ich mich weit von derartiger Herabwürdigung distanziere, verwende ich diesen mir verhassten Begriff hier einzig und allein aus didaktischen Überlegungen um den Bezug zu gängiger Projektplanungs-Software nicht zu verlieren.
Dauer und Arbeit
Zwei Eigenschaften von Arbeitspakten gilt es zu beachten: die Dauer und die Arbeit. Unter der Dauer versteht man erwartungsgemäß die Zeit, die zwischen Beginn und Ende der Bearbeitung des Arbeitspaktes liegt. Wie viel Arbeit während dieser Zeit geleistet wird oder werden muss, ist eine ganz andere Frage und die korrekte Antwort darauf lautet: Kommt darauf an. Nämlich auf die an das Arbeitspaket zugewiesenen Ressourcen. Mehr Ressourcen bei gleicher Dauer heißt mehr Arbeit. Man kann den Zusammenhang aber auch anders herum betrachten und die Arbeit fest vorgeben. Dann gilt: Mehr Ressourcen bei gleicher Arbeit heißt weniger Dauer. Jedenfalls bei manchen Arbeitspaketen und in gewissen Grenzen.
A project manager is a person who thinks nine women can deliver a baby in one month.
Auslastung und Kapazität
Die Zuweisung einer Ressource zu einem Arbeitspaket bedeutet verallgemeinert nichts anderes, als dass sich die verfügbare Kapazität um die Auslastung der neuen Ressource erhöht. Wenn Meier und Müller schon zu 100% an dem Paket arbeiten und Schmidt noch zusätzlich 50% dafür eingesetzt wird, ergibt sich dann eine Kapazität von 250%. Es gilt Dauer * Kapazität = Arbeit. Damit ist klar, dass eine Veränderung an einem dieser Parameter, sich auf die anderen beiden auswirken muss.
Empfehlungen
Aber wie soll eine Projektplanungs-Software beispielsweise auf eine Erhöhung der Arbeit reagieren? Soll die Dauer entsprechend erhöht werden oder die Kapazität oder beides irgendwie? Diese nicht-deterministische Situation lösen gängige Programme dadurch, dass je Arbeitspaket nur einer der drei Parameter variabel bleibt und von der Software automatisch angepasst wird, wenn sich die anderen beiden ändern.
In aller Regel wird man mit variabler Dauer arbeiten. Das heißt es wird ein fester Wert für die geplante Arbeit vorgegeben. Die Zuweisung von Ressourcen zu einem solchen Arbeitspaket fixiert die geplante Kapazität und führt dann zu einer Verkürzung der Dauer. Außer beim Arbeitspaket »Schwangerschaft« ist dieses Verhalten durchaus gewünscht und sinnvoll, etwa beim Arbeitspaket »Baugrube ausheben«, das mit zwei Baggern vermutlich wirklich nur halb so lange dauern wird.
Für einzelne Arbeitspakete kann es durchaus vorkommen, dass die Arbeit variabel sein soll und die Dauer fixiert ist. Man denke etwa an einen dreitägigen Workshop zur Anforderungsanalyse, der auch mit doppelt so vielen Menschen immer noch drei Tage dauert, aber dann eben doppelt so viel Arbeit verursacht.
Beim dritten Fall werden Arbeit und Dauer fest vorgegeben und die notwendige Kapazität dafür berechnet. Das kann sinnvoll sein, um etwa eine Grundlast von lang-laufenden Vorgängen abzubilden. Ein Beispiel dafür wäre die Besetzung einer Hotline während der Einführungsphase einer neuen Software. Die Dauer dieser Phase ist vereinbart und es wird mit einer Arbeit von durchschnittlich 4 Stunden pro Tag gerechnet. Diese Arbeit lastet dann einen Mitarbeiter zu 50% aus und ein zusätzlicher Mitarbeiter auf diesem Paket führt zu einer Reduktion der Auslastung auf 25%.
A Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.
Fazit
In der Praxis hat es sich bewährt, bei den meisten Arbeitspakten mit einem festen Wert für den jeweilige Arbeit zu planen und die Software die Dauer abhängig von den zugewiesenen Ressourcen berechnen zu lassen. Nur bei Arbeitspaketen, deren Dauer wirklich unveränderlich ist (z.B. Schwangerschaft) sollte man die Dauer fest vorgeben. In jedem Fall lohnt es sich diese verschiedenen Varianten mit der eigenen Planungssoftware ausgiebig durchzuspielen und sich dabei die Zusammenhänge zwischen Arbeit, Dauer und Kapazität klar zu machen.
Meilensteine
Arbeitspakete definieren, zueinander in Beziehung setzen und Ressourcen zuweisen – fertig ist der Projektplan. Prinzipiell ja, jedenfalls genauso wie eine Suppe vor dem Abschmecken: essbar, aber noch kein Genuss. Meilensteine sind sozusagen das Salz in der Projektplansuppe. Sie markieren wichtige Ereignisse im Projektverlauf, externe genauso wie interne. Maßvoll eingesetzt geben sie Orientierung, sorgen für Überblick und verleihen zusätzliche Struktur.
Externe Einflüsse modellieren
Jedes Projekt ist eingebettet in ein Umfeld. Dieses Umfeld stellt Anforderungen an das Projekt und schränkt die Planung ein. Beispielsweise kann der Test der Software erst beginnen, wenn die Testdaten aus einer Produktionsumgebung in die Testumgebung geladen wurden. Wenn das nur zweimal im Jahr gemacht wird, dann wären das zwei Meilensteine, von denen das zu planende Projekt abhängen wird und die deshalb auch explizit modelliert werden sollten.
Wenn umgekehrt gefordert ist, dass eine Schnittstelle zu einem anderen System zu einem bestimmten Datum fertig ist, beispielsweise weil dort aufgrund gesetzlicher Bestimmungen neue Daten benötigt werden, dann sollte auch dies als Meilenstein modelliert werden.
Durch das Hinzufügen von externen Meilensteinen lassen sich also Abhängigkeiten der Arbeitspakete zum Projektumfeld modellieren. Man beachte, dass diese Meilensteine alle ein festes Datum haben. Eine gute Planungssoftware weist dann nämlich auf Konflikte hin, etwa wenn aufgrund der Ablaufplanung der zu erreichende Meilenstein nicht gehalten werden kann.
Ergebnisse markieren
Neben der Modellierung externer Abhängigkeiten, dienen Meilensteine der Markierung von wichtigen Ereignissen und vor allem Ergebnissen des Projekts. Mit Meilensteinen wird explizit gemacht, was oft implizit angenommen wird. Ziel ist es,wesentliche Eckpunkte deutlich sichtbar im Projektplan herauszustellen. Wenn es beispielsweise ein Arbeitspaket »IT-Konzept erstellen« und ein zweites »IT-Konzept begutachten« gibt, sollte es den Meilenstein »IT-Konzept abgenommen« geben, der deutlich das Ende der Arbeiten am IT-Konzept darstellt.
Es bietet sich an solche markanten Meilensteine auf hoher oder sogar auf oberster Ebene der Projektstruktur zu modellieren. Dann bleiben die Meilensteine nämlich sichtbar, wenn die restlichen Gruppen zusammengeklappt sind, wodurch man schnell einen schönen Übersichtsplan des Projekts erstellen kann.
Berichterstattung erleichtern
Meilensteine eignen sich sehr gut für die Berichterstattung, fassen sie doch bei kluger Wahl den aktuellen Zustand des Projekts in wenigen Zeilen zusammen. Als Mittel der Wahl hat sich hierzu, neben dem reinen Soll-Ist-Vergleich von Meilensteinterminen, dieMeilensteintrendanalyse, kurz MTA, bewährt. Dabei werden zu jedem Berichtszeitpunkt die Meilensteintermine in einem Koordinatensystem grafisch notiert. Über die Berichtszeitpunkte hinweg hinterlassen die Meilensteine nun eine Spuren im Koordinatensystem. Man sieht mit etwas Übung auf einen Blick, welche Meilensteine verspätet sind und insbesondere wie sich diese Verspätung entwickelt hat.
Der Vorteil gegenüber dem reinen Soll-Ist-Vergleich liegt in der Visualisierung des Verlaufs. Aus einem Soll-Ist-Vergleich ist nicht ersichtlich, ob sich die Verzögerung gerade erst ergeben hat (und ein Eingreifen notwendig ist) oder ihre Ursache schon einige Zeit zurückliegt (und ein Eingreifen nicht mehr notwendig ist). In der MTA weist die Kurve im ersten Fall zum jetzigen Zeitpunkt steil nach rechts oben, wohingegen im zweiten Fall die Kurve jetzt wieder waagerecht ist und die Steigung schon einige Zeit zurück liegt, wie dies bei der roten Kurve im Bild oben der Fall war.
Eine detaillierte Beschreibung inklusive Links auf verschiedene Vorlagen findet sich hier.
Fazit
Meilensteine sind nötig und sinnvoll zur Modellierung externer Einflüsse auf den Projektplan aber auch um wichtige Ereignisse und Ergebnisse hervorzuheben. Aber auch hier gilt nach Paracelsus: »Sola dosis facit venenum.« (lateinisch für: »Nur die Dosis macht das Gift.«) Zu viele Meilensteine versalzen die Suppe!
I love deadlines. I like the whooshing sound they make as they fly by.
DOUGLAS ADAMS
Fortschritt messen
»Planung ersetzt Zufall durch Irrtum.« soll Albert Einstein gesagt haben und Feldmarschall Helmuth von Moltke meinte dazu nüchtern-realistisch: »Kein Plan überlebt die erste Feindberührung.« Ein Plan ist nur eine Richtschnur, die Messlatte mit der Abweichungen festgestellt werden. Der Plan muss deshalb regelmäßig an der Realität gemessen und korrigiert werden. Nichts schlimmer als ein veralteter Plan, heuchelt er doch trügerische Sicherheit, wo schon Blindflug herrscht.
Handhabbarkeit von Beginn an
Die Qualität eines Plans und die Erfahrung des Planenden zeigt sich besonders daran, wie leicht die Aktualisierung fällt. In den vorangegangenen Teilen dieser Serie wurde auf die Handhabbarkeit des Planes bereits eingegangen. Arbeitspakete sollten beispielsweise nicht zu klein gewählt werden, weil ihre Aktualisierung sonst sehr mühsam werden kann. Selbst wenn es zunächst keinen Unterschied im Ablauf macht, sollten logische Abhängigkeiten explizit im Plan eingetragen werden, weil es bei einer späteren Verschiebung einen Unterschied machen könnte. Ein gut aktualisierbarer mittelmäßiger Plan ist besser als ein schlecht aktualisierbarer perfekter Plan.
Wer viel misst, misst viel Mist
Es steht außer Frage, dass wir in der Lage sein müssen, Auskunft über den Zustand und den Fortschritt des Projekts zu geben. Aber welche Informationen sollte man dazu regelmäßig einsammeln? Gängige Planungssoftware verleitet uns dazu, je Arbeitspaket den Fortschritt in Prozent einzutragen. Das ist aber nicht ganz ungefährlich.
Betrachten wir die einfach scheinende Frage, was ein Fortschritt von 20% bedeutet. Die Software und der Projektleiter verstehen darunter meistens, dass 20% der Arbeit geleistet wurden und noch 80% zu leisten sind. Der Bearbeitende versteht darunter aber oft, dass die Ergebnisse zu 20% fertig gestellt sind. Leider ist das nicht immer identisch. Ersteres macht eine Aussage über den Aufwand, letzteres über den durch den Aufwand erzielten Gegenwert. Oft gilt nämlich das bekannte Pareto-Prinzip: es besagt, dass 80% der Ergebnisse mit 20% des Aufwands erreicht werden, während die restlichen 20% der Ergebnisse 80% des Aufwands verursachen. (vgl. Wikipedia)
Einfach nach dem Grad des Fortschritts zu fragen birgt also die Gefahr eines Missverständnisses, wenn man nicht explizit betont, dass das Verhältnis von bereits geleisteter zu insgesamt zu leistender Arbeit gemeint ist.
Restaufwände
Stattdessen empfiehlt es sich also, nach dem Restaufwand für das Arbeitspaket zu fragen. Die bereits geleistete Arbeit (Ist-Aufwand) hat man in der Regel ohnehin in irgendeiner Art von Zeiterfassung verfügbar und so ergibt sich der Fortschritt dann automatisch als Verhältnis von Ist-Aufwand zu der Summe von Ist- und Restaufwand. Gleichzeitig hat man damit auch den Gesamtaufwand für dieses Arbeitspaket aktualisiert, denn es wird oft so sein, dass der geschätzte Restaufwand zusammen mit dem Ist-Aufwand nicht dem ursprünglich geschätzten Gesamtaufwand passt.
Nehmen wir an, wir stecken mitten in der Bearbeitung eines Arbeitspakets »IT-Konzept erstellen«. Der Aufwand war mit vier Wochen geschätzt und der Kollege Meier arbeitet nun seit zwei Wochen an diesem Paket. In einer idealen Welt müsste das Paket zu 50% fertig gestellt sein. Meldet der Kollege Meier nun aber einen Restaufwand von drei Wochen, ist klar, dass einerseits die ursprüngliche Schätzung falsch und dass andererseits das Paket nun fünf Wochen dauern wird, weil der Kollege Meier alleine daran arbeitet. Wir haben nun zwei Erkenntnisse gewonnen: erstens hat das Paket »IT-Konzept erstellen« einen Fortschrittsgrad von 40% und zweitens wird es eine Woche später fertig. Mit entsprechenden Auswirkungen auf den Terminplan oder das Überstundenkonto von Kollegen Meier.
Der umgekehrte Fall, also dass eine Woche weniger als ursprünglich geschätzt benötigt wird, kommt leider in der Praxis nie vor. Hier gilt das erste Parkinsonsche Gesetz, wonach die Arbeit sich immer auf die zur Verfügung stehende Zeit ausdehnt.
Work expands so as to fill the time available for its completion.
C. NORTHCOTE PARKINSON
90%-Syndrom
Gerade weil man anfangs gefühlt gut vorankommt (Pareto-Prinzip), wird der Restaufwand zur Fertigstellung gerne unterschätzt und damit ein zu hoher Fortschritt ermittelt. Dieses Phänomen wird gerne als 90%-Syndrom bezeichnet, weil recht schnell 90% erreicht werden um dann recht lange auf diesem Niveau zu verharren.
Miteinander reden
Auch wenn die Ermittlung des Fortschritts prinzipiell unscharf bleibt, ist die Zeit zurgemeinsamen Aktualisierung doch gut investiert. Es wird nämlich über den Plan, die laufenden Aktivitäten, Fortschritt und Restaufwände, Probleme und Abhängigkeiten geredet. Diese Kommunikation anhand des Plans, macht den Plan zu einem gemeinsamen, gibt Orientierung und Ziel. Daraus folgt, dass die Aktualisierung des Plans im Dialog erfolgen sollte, auch wenn das mehr Zeit erfordert. Von einem simplen Einholen der benötigten Informationen über E-Mail oder Projektmanagement-Software ist eher abzuraten.
Fazit
Den Fortschritt im Projekt zu erfassen ist nicht einfach. Durch ungeeignete Wahl von Arbeitspaketen und unkluges Vorgehen bei der Erfassung wird es sogar noch schwieriger. Umgekehrt ist das regelmäßige gemeinsame Durchgehen des Plans ein ausgezeichnetes Mittel den Plan im Team zu verankern.
Plan optimieren
Sind die Arbeitspakete erst zum Ablaufplan verknüpft und ihre Dauer bestimmt, sei es fest vorgegeben oder durch Zuweisen von Ressourcen, kommt das böse Erwachen. Die errechneten Termine liegen meist mehr oder weniger weit jenseits der eigenen Vorstellung und noch viel weiter neben der Vorstellung des Auftraggebers. Der Plan muss optimiert werden. Nun schlägt leider zu oft die Stunde von blindem Pragmatismus und unverantwortlichem Zweckoptimismus. Über Möglichkeiten und Grenzen der Optimierung des Ablaufplans.
Kritischer Pfad
Nicht alle Arbeitspakete haben in gleichem Maße Einfluss auf den berechneten Endtermin. Vielmehr gibt es in jedem Ablaufplan eine Folge von Arbeitspaketen, die den Endtermin eindeutig bestimmen, den sogenannten kritischen Pfad. Um Einfluss auf den Endtermin auszuüben, setzt man also sinnvollerweise bei den Paketen auf dem kritischen Pfad an. Umgekehrt sind es diese Pakete die im Falle von Verzögerungen direkt auf den Endtermin wirken. Im folgenden kleinen Beispiel ist der kritische Pfad rot hervorgehoben. Man sieht, dass das Arbeitspaket »Testfälle erstellen« nicht auf dem kritischen Pfad liegt, die anderen beiden aber schon.
Überlappung
Eine beliebte Vorgehensweise, um ein paar Tage aus dem Plan herauszuquetschen, ist die teilweise Überlappung von Arbeitspaketen. Dazu gibt es die Möglichkeit aufVerknüpfungen von Arbeitspaketen einen Versatz anzugeben, der auch negativ sein kann. Konkret könnte das bedeuten, dass mit dem Paket »Implementierung« schon eine Woche vor Fertigstellung des Pakets »IT-Konzept« begonnen wird. (In der Realität ist man ja schon zufrieden wenn das IT-Konzept nicht erst nach der Implementierung entsteht, aber das ist ein anderes Thema.) Dazu ändert man die Verknüpfung der beiden Pakete von »EA« (Abkürzung für »Ende-Anfang-Beziehung«) einfach auf »EA – 2 Tage«. Nebenbei bemerkt führt diese Überlappung nun dazu, dass anschließend auch das Paket »Testfälle erstellen« Teil des kritischen Pfads wird (der im Übrigen gar kein Pfad im graphentheoretischen Sinne ist, sondern ein gerichteter azyklischer Graph, wie an diesem Beispiel deutlich sichtbar).
Oft ist es tatsächlich möglich mit ersten Ergebnissen des vorangegangenen Arbeitspakets das nächste zu starten. Natürlich nur sofern es sich wenigstens teilweise um verschiedene Ressourcen handelt.
Noch mehr?
Ist die Lücke zwischen Wunsch und Realität allerdings größer und nicht durch solche Überlappungen im Kleinen zu korrigieren, sind schwerere Eingriffe notwendig. Im Prinzip gibt es dazu zwei Möglichkeiten die Dauer der Pakete auf dem kritischen Pfad zu verändern: erstens, Kapazität erhöhen und zweitens, Leistungsumfang reduzieren. Ob mehr Kapazität wirklich hilfreich ist, hängt stark vom jeweiligen Arbeitspaket ab und sollte kritisch betrachtet werden, gerade dann, wenn man ohnehin schon in Verzug geraten ist.
Adding manpower to a late software project makes it later.
BROOK’S LAW
Leistungsumfang reduzieren hingegen stößt immer auf wenig Gegenliebe beim Auftraggeber oder bei anderen Stakeholdern. Diesen Konflikt muss man als Projektleiter aushalten und sogar frühzeitig suchen. Wenn es ein Problem mit dem Wunschtermin gibt (und das gibt es immer), dann wird dieser Konflikt früher oder später zu Tage treten. Die Frage ist nur wann und mit welchen Konsequenzen. In der Planungsphase aber haben Projektleiter und Auftraggeber noch viel mehr Handlungsoptionen, weshalb Lücken zwischen Wunsch und realistischem Plan genau in dieser Phase thematisiert werden müssen. Je weiter das Projekt fortschreitet, desto weniger Optionen bleiben. Der anfangs durch Zweckoptimismus beschwichtigte Auftraggeber wird sich am Ende über Verzögerungen und schlechte Qualität ärgern und den Projektleiter, zu Recht, unzuverlässig nennen. Lieber anfangs konfrontativ mit verlässlichen Terminen als anfangs zu lieb und am Ende unzuverlässig.
Fazit
Während die bisherigen Teile der Serie eher technischer Natur waren und den richtigen Umgang mit der Ablaufplanung zum Ziel hatten, fordert die Optimierung des Plans nun die Führungsfähigkeit und Kreativität des Projektleiters. Insbesondere deswegen, weil es nun die Lücke zwischen vernünftigem Plan und utopischem Wunsch deutlich sichtbar wird. Wer nun die Konfrontation scheut und übermäßig optimistisch plant handelt unverantwortlich und wenig erwachsen.