von M.Jerger und M.Mörike
Planung ist eine grundlegende und wiederkehrende Aufgabe im Projektalltag. Manchmal ist es schwierig, einen guten Plan zu erstellen und manchmal ist es einfach. Woran liegt das? An der Tagesform oder an dem was geplant werden muß? In diesem Beitrag werden die Faktoren untersucht, die für eine Planung die unverzichtbare Voraussetzung bilden und die Faktoren, die eine erfolgreiche Planung effektiv verhindern können. Wer sich diese Faktoren bewusst macht, kann viel schneller erkennen, welche Voraussetzungen zu seiner Planung fehlen.
Motivation
Ein Plan dient einem unveränderlichen Gesamtziel. Das Gesamtziel darf sich im Laufe der Projektdurchführung zwar konkretisieren aber nicht ändern. Ein Plan wird erstellt, um den folgenden drei Aspekten zu genügen:
Willenserklärung
Ein Plan manifestiert die Entscheidung, wieviel Funktionalität mit welchen Ressourcen realisiert werden. Diese Willenserklärung bildet den Vertrag zwischen Projektkunde und Projektmitarbeiter und darf sich ebenso wie das Gesamtziel nicht ändern sondern nur konkretisieren. Zu einem guten Plan gehört bei der Willenserklärung auch das richtige Maß an Mut.
Vorhersagemodell
Ein Plan liefert ein Vorhersagemodell für das Erfüllen einer Aufgabe. Durch das stufenweise Unterteilen des Gesamtziels in Teilziele wird das Vorhersagemodell plausibel gemacht. Die Idee ist, dieses Vorhersagemodell beständig zu verbessern und so nach und nach eine immer genauere Planung zu erhalten. Controlling dient dabei als eine der wichtigsten Feedbackquellen. Der Weg, zu dem diese Teilziele zusammengefügt werden, darf sich ändern.
Kommunikation
Ein Plan muß das Gesamtziel, die Willenserklärung und das damit verbundene Vorhersagemodell deutlich kommunizieren. Dabei sind unterschiedliche Kommunikationspartner beteiligt, die sich für unterschiedliche Planungsergebnisse interessieren:
- Die Projektkunden: Interessieren sich für die Willenserklärung. Sie müssen mit dem Handel der in der Willenserklärung steckt einverstanden sein.
- Die Mitarbeiter und Zulieferer: Interessieren sich für das Vorhersagemodell. Die Mitarbeiter müssen den Plan für durchführbar halten und die damit verbundene Willenserklärung mittragen.
In der Realität ändert sich hin und wieder das Gesamtziel oder auch die Willenserklärung. Das bedeutet, alle Vereinbarungen (Budget, Personal, Funktionalität und Termin) müssen neu ausgehandelt werden. Eine komplette Neuplanung ist in einer solchen Situation unumgänglich, eventuell ist es sogar gerechtfertigt, das gesamte Projekt neu aufzusetzen.
Planungsgrößen
In einem IT-Projekt müssen die folgenden fünf Größen geplant werden. Die Verhandelbarkeit der entsprechenden Größen nimmt dabei zu, die Wichtigkeit entsprechend ab.
Termin
Bei vielen Projekten ist der Termin eine harte Größe, da eine Terminverschiebung immer negativen Einfluß auf die übergeordnete Planung hat. Selbst wenn ein Termin nicht als unumstößlich bezeichnet wird, löst eine Terminverschiebung immer Ängste auf der Seite der Projektkunden aus.
Qualität
Qualität wird meist nicht explizit gefordert und geplant. Implizit wird von den Projektkunden aber immer eine gute Qualität erwartet. Auch die Projektmitarbeiter wollen eine gute Qualität liefern, da Qualität meist ein wesentlicher Faktor für das Selbstwertgefühl der Projektmitarbeiter ist.
Funktionalität
Der Funktionsumfang wird mehr oder weniger detailliert in Pflichten- und Lastenheften festgelegt. Die entscheidende Frage für die Funktionalität ist: Was benötigen die Projektkunden für das Erreichen des Projektgesamtziels? Weitergehende Funktionen sind meist verhandelbar und sind Teil der Willenserklärung.
Personal & Ressourcen
Personal ist eine Planungsgröße, die sich nur mit viel Vorlauf steuern lässt. Zusätzlich ist die Personalplanung mit vielen harten äußeren Zwängen behaftet (Einbinden von Keyplayern, Personalverfügbarkeit und "Richtlinien über den Einsatz von externen Kräften"). Mit anderen Worten heißt das, die Zwänge aus der Personalplanung bestimmen, wieweit im voraus ein entsprechend detailierter Plan vorhanden sein muß. Ähnliches gilt für Ressourcen, wie Server- und Client-Hardware. Meist hat die Hardware aber einen kürzeren Vorlauf oder ist schon vorhanden.
Budget
Budget ist meist der variabelste Anteil in einer Planung. Interessante Fragen bei der Budgetplanung sind:
- Wieviel Nutzen bringt das Projekt dem Projektkunden?
- Nach welcher Größe (Minimale Investitionshöhe, schnellste Amortisation oder maximaler Projektnutzen nach n-Jahren) möchte der Projektkunde optimieren?
- Werden Puffer in der Planung eingebaut oder werden sie vom Projektkunden transparent verwaltet?
Planungsvorgang
Der eigentliche Vorgang der Planung kann sich in folgende Arbeitsschritte aufteilen:
Aufteilung des Gesamtziels
Die Aufteilung des Gesamtziels in Teilziele, Funktionsblöcke und Arbeitspakete ist eine Architekturaufgabe. Diese Aufteilung kann entlang verschiedener Kriterien stattfinden. Gebräuchliche Kriterien sind z.B. nach Kundennutzen, nach technischen Abhängigkeiten, nach Risiko oder nach anderen externen Planvorgaben.
Übersicht
Nach der Aufteilung ist es notwendig, eine Übersicht über alle möglichen Teilziele, Funktionsblöcke oder Arbeitsschritte auf der jeweils entsprechenden Planungsstufe zu erstellen. Zusätzlich muß die so erstellte Übersicht auf Vollständigkeit überprüft werden.
Schätzung
Nach einer ersten vorläufigen Priorisierung ist es dann möglich, die einzelne Punkte aus dieser Übersicht bezüglich Aufwand, Personal und anderer benötigter Resourcen zu schätzen. Um die Schätzung systematisch zu verbessern, bietet sich ein entsprechendes Controlling als Feedback für die Schätzenden an.
Priorisierung
Die Übersichtliste muß abschließend nochmals priorisiert werden. Die Priorisierung richtet sich dabei nach dem Kriterium, nach dem die Unterteilung vorgenommen wurde. Bei der Priorisierung können die Projektkunden mit eingebunden werden.
Planung erstellen
Um der Planung Freiheitsgrade zu nehmen, und damit die Komplexität zu reduzieren, wird der Termin und die Qualität jeweils als fixe Eingangsgrößen betrachtet. Der Termin wird meist schon durch die Projektkunden vorgegeben. Für die Qualität kann ein pauschaler Aufschlag zu allen geplanten Aufwänden festgelegt werden. Stehen Termin und Qualität fest, können streng nach Priorität geordnet die einzelnen Funktionsblöcke in die Planung mit aufgenommen werden. Für jeden hinzugenommenen Funktionsblock wird dann
- der Personalbedarf
- der Ressourcenbedarf und
- das Budget kalkuliert
Abschließend muß noch die Einhaltbarkeit des Termins überprüft werden. Die vorab schon erkennbaren Risiken werden beschrieben und der kritische Pfad wird bestimmt.
Je nach Optimierungsziel (Minimale Investitionshöhe, schnellste Amortisation oder maximaler Projektnutzen nach n-Jahren) wird das Projekt zwischen Geschwindigkeit und Kostenoptimierung eingestellt.
Die an dieser Stelle typischerweise aufgeführten technischen Abhängigkeiten werden oft überbewertet. Es lohnt sich, eine bewusste Entscheidung zu treffen, zwischen:
- Flexibilität: Technische Abhängigkeiten werden möglichst wenig berücksichtigt, mit dem Ziel den Plan möglichst flexibel zu halten. Dieser Ansatz verursacht eventuell Mehraufwände.
- und Kostenoptimierung: Technische Abhängigkeiten werden vollständig mit geplant, mit dem Ziel möglichst viel Budget zu sparen. Der Plan hat dadurch mehr Abhängigkeiten und wird riskanter.
Optimierung und Tips
In der Praxis gibt es bei jeder Planung eine Reihe von wiederkehrenden Optimierungsaufgaben und anderen Dingen, an die man denken sollte:
- Ein Plan muß präsentierbar und einprägsam sein.
- Ein Projektleiter sollte die wesentlichen Eckpunkte seines Plans auswendig kennen.
- Um Mitarbeiter zu motivieren, bietet es sich an, die Mitarbeiter mit in die Planung einzubinden (siehe auch "Participative Leadership" [Lik67])
- Wieviel Planung ist notwendig? Bei zu wenig Planung bleibt die Unsicherheit zu groß wohingegen zuviel Planung zu teuer ist, zu lang braucht und nachher einengt.
- Wieviel Funktionalität wird versprochen? Viel Funktionalität zu versprechen erhöht das Risiko, das Versprechen nicht einhalten zu können, wohingegen wenig versprochene Funktionalität die Projektmitarbeiter zu wenig fordert und motiviert.
- Wie soll das Personal geplant werden? Die Personalplanung sollte möglichst ausgewogen und ohne Spitzen auskommen. Unausgewogenheit und Spitzen bedeuten Fluktuation. Bei Fluktuation geht immer Wissen, Motivation und damit Geld verloren.
- Wieviel Parallelisierung ist notwendig? Um möglichst viel Funktionalität in möglichst kurzer Kalenderzeit umzusetzen, ist Parallelisierung unumgänglich. Mehr Parallelisierung ist teurer, risikoreicher und macht einen Plan verwundbar. Der Termin wird dabei jeweils durch den kritischen Pfad bestimmt. Das bedeutet, Parallelisierung verkürzt die Kalenderzeit nur, wenn der kritische Pfad entlastet werden kann.
- Wann muß ein Plan fertig sein? Im Sinne des ausgeglichenen Personaleinsatzes ist immer ein gewisser Planungsvorsprung nötig um die Planungsarbeit, die nur von wenigen ausgeführt wird, parallel zu den restlichen Arbeiten ausführen zu können, so daß für die Mehrheit kein Leerlauf entsteht.
Fazit
In dieser Perspektive wurde der Vorgang des Planens systematisch untersucht und die einzelnen Einflussgrößen beleuchtet. Mit diesem Wissen fällt es leichter, die Ursachen für Planungsschwierigkeiten zu finden und zu beheben.
Literatur
[Lik67] - Likert, R. (1967). The human organization: Its management and value, New York: McGraw-Hill
Comments:
|
Moin, ich stehe diesem Beitrag kritisch gegenüber, da er teils vom Wording und teils Fachlich Unrichtigkeiten enthält. Als Beispiel nehme ich nur die Ausführung über Qualität, bei dem der Begriff nicht im Sinne und der Definition innerhalb des Projekt Management verwendet wird. Als weiteres Beispiel diesen Satz:" wird der Termin und die Qualität jeweils als fixe Eingangsgrößen betrachtet" Was soll das sein? Termin ergibt sich aus Scope, Aufwand und Ressourcen sowie ggf. Zulieferzeiten. Wenn dieser als gesetzt bezeichnet wird, würde man eine "reverse" Planung machen. Diese wäre dann nicht realistisch und würde im Projektverlauf zusammenbrechen. Ein der Hauptursachen von fehlgeschlagenen Plänen. Und was meint Qualität in diesem Zusammenhang? Time, Scope und Budget? Oder Fehlerfreiheit? Und ebenfalls: Schon mal was von fit to time oder fit to budget gehört. Damit wäre der Scope wieder nicht gesetzt! Ich will nicht groß weiter machen, aber Leser die unerfahren sind im Bereich Projektplanung eher warnen diesen Artikel mit Ernst zu betrachten sondern eher als Gedankenanregung. CU Jens 
Posted by jgersdorff at 25. Apr 2012 12:42
|
|
Hallo Jens, sehe deine Punkte. Vielleicht hast du Lust eine alternative Sichtweise als eigenen Beitrag zu posten. Dann könne wir auch mehrere Beiträge zu einer Diskussion zusammenfassen. @Michael&Michael: Lasst uns den Artikel auf jeden Fall noch verbessern. Jens ist einer unserer anspruchsvollsten Krititker. Gruß Bernhard
Posted by bschloss at 25. Apr 2012 20:35
|
|
Hallo Jens, interessanter Kommentar von Dir. Den Teilsatz "Der Termin wird meist schon durch die Projektkunden vorgegeben" empfinde ich subjektiv als realitätsnah. In meinen Projekten ist es sehr oft so, dass z.B. durch gesetzliche Rahmenbedingungen oder interne Prozesse beim Kunden ein Abgabe-/Fertigstellungstermin von Anfang an feststeht/definiert ist. Die Aufgabe ist dann zu prüfen, ob genügend Ressourcen (Mitarbeiter, geeignete Tools, KnowHow etc) bereitgestellt werden können, um die Anforderungen termingerecht zu erfüllen. Ich würde Dir aber auch Recht geben, dass solche Pläne tendenziell öfter den geplanten Endtermin überschreiten. Aus meiner Sicht, weil zum einen IT (Software)Projekte immer schwierig umzusetzen sind und zum anderen weil die Anforderungen im Projektverlauf geändert werden. Letzteres würde natürlich für Scrum sprechen (iterative Vorgehensweise). Vielleicht fühlt sich Rainer Eschen berufen etwas beizutragen. Wenn ich richtig liege, arbeitet er auch in vielen IT Softwareentwicklungsprojekten.
Posted by fogbird at 25. Apr 2012 20:37
|
|
Hallo Bernhard, keine Sorge - über eine konstruktive Diskussion freue ich mich immer - und oft ist's der vehemente Widerspruch, der einen Schritt nach vorne bringt. @Jens: Magst du die fachlichen Ungereimtheiten mal pointiert zusammenfassen - damit ich eine Chance habe, darauf einzugehen? Viele Grüße,
Posted by mjerger at 26. Apr 2012 16:59
|
|
Ich steige mal noch nicht konkret ein, auch wenn ich hier und da schon "die Augen verdreht" habe
Posted by rainwebs at 26. Apr 2012 19:11
|
|
Moin Christian, ich sage ja nicht, dass es Endtermine gibt, die der Kunde vorgibt. Aber deswegen ist es wichtig Prioritäten zu haben und fit2time oder fit2budget durch zu führen. Und ob das für scrum spricht, weiß ich nicht. Denn scrum würde den Termin halten, aber vorher sich nicht auf einen Scope oder Budget commiten. Aber in dem Artikel wird alles davon als gesetzt betrachtet. Ich wollte sowieso was zum Thema Planung schreiben. Allerdings aus der Praxis. Also eher ein How to als eine akademische Betrachtung der Planung Vielleicht schaffe ich es im Laufe der ersten Mai-Woche. Denn Morgen bin ich unterwegs in den Süden und am Wochenende fröne ich dem Surfen Das Thema Planung korrespondiert ja mit dem was ich angefangen habe im Controlling. Ohne Planung kein Controlling. Und Planung ist immer noch ein Teil des "plan act do check" Kreislaufs. CU
Posted by jgersdorff at 26. Apr 2012 19:15
|
|
Moin Rainer ... wo hast Du denn die Augen verdreht??
Posted by jgersdorff at 26. Apr 2012 19:28
|
|
Es ist ja gerade der Sinn agilen Projketmanagements (Scrum ist EIN Framework davon), dass die Anforderungen sich im Verlauf des Projekts verändern können also kein fester Scope vorliegt. Es ist allerdings nicht richtig zu behaupten, es gäbe kein Commitment auf einen Scope und ein Budget. Bei externer Entwicklung ist das anders gar nicht möglich, da die meisten Kunden Festpreisangebote mit fixem Termin wünschen. Allerdings kann abhängig von der Vertragsart dann eine Anwenderstory / ein Use Case gegen einen anderen (in etwa) gleich großen ausgetauscht werden ohne das der Festpreis davon berührt würde. Bei weiter gehenden Änderungen (zusätzlichen Features) würde dann das gleiche Change Request Verfahren greiefen wie bei "klassischen" Projekte. Die Vorteile agiler Entwicklung liegen eben im zeitnahmen Projektcontrolling am Ende jeder Iteration (haben wir das Richtige auch richtig hinbekommen) und an der Möglichkeit der Anpassung der Anforderungen an neue Erkenntnisse.
Posted by jbruns at 30. Aug 2012 14:11
|
|
Da ist einiges zu hinterfragen, ich nehme nur mal das Kapitel Budget raus:
Wenn ich ein Einzelprojekt mache ist der Nutzen des Projekts für den Projektkunden oft etwas was sich mir entzieht - ich habe eine Auftragsarbeit zu erledigen. Er hat nur soviel zum Budget zu tun, das der Kunde vermutlich wenn er mehr Nutzen hat, auch bereit ist, mehr Budget zu Verfügung zu stellen. ABER hat der Kunde kein Geld, kann sein "ganzer" Nutzen nicht realisiert werden, aber oft sehr wohl Teile des Projekts durchgeführt werden Auch der 2.Satz ist mir für ein Auftragsprojekt nicht so wichtig, weil das das Problem des auftraggebenden Unternehmens ist - als PM habe ich mit einem Budget auszukommen - oder eben zu kommunizieren, das mit diesem Budget eine Realisierung nicht möglich ist Ad Puffer - ich nehme an hier geht's um Budgetpuffer - auch die sind eher im Bereich des Kunden anzusiedeln. Einer meiner Chefs meinte mal bei Projekte wird eines immer zu mindestens 100% erfüllt - die Kosten.
Posted by hu at 16. Jan 2013 12:30
|
Lasst euch von ihm nicht unterkriegen, sondern versteht es als sportliche Herausforderung. Was mir insbesondere noch fehlt, ist der IT Bezug, den ihr im Titel extra gewählt habt.
.