Planung für (IT-) Projekte

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:

  1. Ein Plan muß präsentierbar und einprägsam sein.
  2. Ein Projektleiter sollte die wesentlichen Eckpunkte seines Plans auswendig kennen.
  3. Um Mitarbeiter zu motivieren, bietet es sich an, die Mitarbeiter mit in die Planung einzubinden (siehe auch "Participative Leadership" [Lik67])
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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

Michael JergerMichael Mörike

Twittern

9 Kommentare

  1. 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

    1. 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. (Zwinkern) 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.

      Gruß

      Bernhard

      1. 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?
        Die Diskussion über Begrifflichkeiten würde ich als Nebenkriegsschauplatz allerdings gerne hinten an stellen.

        Viele Grüße,
        Michael

    2. 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.

      1. Ich steige mal noch nicht konkret ein, auch wenn ich hier und da schon "die Augen verdreht" habe (Zwinkern). Jens, wo bleibt Deine Liste?

        1. Moin Rainer ...

          wo hast Du denn die Augen verdreht?? (Zwinkern)

      2. 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. (Zwinkern)

        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 (Lächeln).

        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 (breites Grinsen)

        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

  2. 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.

  3. Da ist einiges zu hinterfragen, ich nehme nur mal das Kapitel Budget raus:

    • 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?

    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.

     

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen