Projektplanung sowie Projektsteuerung bzw. –kontrolle gehören zu den zentralen Methoden des IT-Projektmanagements. Auf der Basis des Projektziels bzw. der Projektanforderungen wird das Gesamtprojekt in Phasen und Arbeitspakete zerlegt. Für diese werden Zeiten und Kosten geplant bzw. Ressourcen zugeteilt.
Projektplanung und –steuerung als Teil des Projektmanagements
Die Entwicklung großer IT-Systeme erfolgt in der Regel in Projekten. Projektmanagement beschäftigt sich mit organisatorischen, funktionalen und methodischen Aspekten des Projekts. Die Planung und Steuerung von Projekten wird dem methodischen Bereich zugeordnet.
Der Project Management Body of Knowledge (PMBOK) unterteilt die Methoden oder Prozesse des Projektmanagements in fünf Hauptgruppen, die zeitlich wie in der folgenden Abbildung dargestellt angeordnet sind.
Abb.1 Einordnung der Projektplanung und –steuerung in Anlehnung an PMBOK
Nach dem Initiierungsprozess wird das Projekt formal aufgesetzt. Anschließend geht das Projekt in einen Zyklus von Planung, Ausführung und Steuerung ehe am Ende das Projekt abgeschlossen wird. Der Zyklus betont die Tatsache, dass Projektplanung keine einmalige Aktivität am Anfang des Projekts ist, sondern dass Planung und Steuerung kontinuierliche Prozesse während des gesamten Projektes sind. Werden bei der Steuerung Änderungen zwischen Realität und Plan festgestellt, so muss der Plan der geänderten Situation angepasst werden.
Projektplanung
Ziel der Projektplanung ist die Festlegung des Projektumfangs sowie die Erstellung der Zeit-, Kosten- und Ressourcenpläne. In großen Projekten werden zusätzlich noch Kommunikations-, Qualitäts- und Risikomanagementpläne angefertigt.
In der Praxis sind die Ziele eines Projektes nach der Initiierungsphase nur grob umrissen. In der Projektplanung werden diese Ziele weiter untergliedert und präzisiert. Die Ziele werden in Kostenziele, Terminziele und Leistungsziele unterteilt. In SW-Entwicklungsprojekten werden diese Ziele im Pflichtenheft dokumentiert.
Identifikation von Arbeitspaketen
In einem zweiten Schritt wird das Projekt in Arbeitspakete zerlegt, die in einer Hierarchie, dem Projektstrukturplan (PSP, engl. Work Breakdown Structure, WBS) angeordnet werden. Ziel des PSP ist es, sämtliche Aktivitäten, die Teil des Projektes sind, zu identifizieren und hierarchisch zu gliedern. Hierzu gehören neben den eigentlichen Entwicklungstätigkeiten auch unterstützende Aktivitäten wie z.B. Konfigurationsmanagement oder Projektmanagement. Der PSP ist die Grundlage für sämtliche weiteren Planungsaktivitäten. Dementsprechend muss dieser Plan sorgfältig erstellt und stets aktuell gehalten werden.
Ressourcenplanung
Für die einzelnen Aktivitäten werden im nächsten Schritt Ressourcen bzw. Kompetenzen zugewiesen. In einem SW-Entwicklungsprojekt sind dies einerseits menschliche Ressourcen. Beispielsweise kann einer Codierungsaufgabe ein GUI-Programmierer oder ein DB-Entwickler zugeordnet werden. Zusätzlich werden in der Praxis kritische Ressourcen (z.B. teure Testsysteme) den Aktivitäten zugeordnet.
Zeitplanung
Auf der Basis des PSPs wird ein Zeitplan entwickelt. Dazu werden in einem ersten Schritt die benötigten Zeiten für jedes einzelne Arbeitspaket abgeschätzt. Dies geschieht entweder unmittelbar, d.h. einem Arbeitspaket wird eine geplante Dauer (z.B. eine Arbeitswoche) zugewiesen, oder indirekt. In diesem Fall wird zuerst die Größe des zu erstellenden Artefakts geschätzt (z.B. Anzahl Seiten eines Dokuments, Anzahl Lines of Code (LOC) für ein Programm). In einem zweiten Schritt wird dann auf dieser Basis ebenfalls die benötigte Zeit für das Arbeitspaket geschätzt (siehe auch Aufwandschätzverfahren).
Im nächsten Schritt wird die Reihenfolge der Aktivitäten definiert. Dazu wird für jedes Arbeitspaket festgelegt, ob es von der Fertigstellung anderer Arbeitspakete abhängt. Mit Hilfe dieser Abhängigkeiten lässt sich ein Ablaufplan erstellen. Häufig werden die Ablaufpläne in Form eines Netzplans dargestellt (siehe Netzplantechnik). Netzpläne haben den Vorteil, dass der komplexe Sachverhalt übersichtlich visualisiert wird. Es lassen sich parallele Aktivitäten, der kritische Pfad (siehe Netzplantechnik) etc. identifizieren.
Um von den einzelnen Arbeitspaketen zu abstrahieren, wird ein Projekt zusätzlich in aufeinanderfolgende Phasen unterteilt. Dabei wird jedes Arbeitspaket genau einer Phase zugeordnet. Die Phase wird mit einem sogenannten Meilenstein abgeschlossen. An diesem Meilenstein müssen alle Arbeitspakete, die zu der entsprechenden Phase gehören, abgeschlossen und die Arbeitsprodukte (engl. Workproduct) der entsprechenden Arbeitspakete fertiggestellt sein. Ein Meilenstein ist immer durch ein geplantes Zieldatum und durch eine Ergebnisliste definiert. Meilensteine dienen dadurch als Kontrollpunkte innerhalb eines Projektes. Während Meilensteine zurückblicken – wurden in der abgeschlossenen Phase alle definierten Ziele erreicht? – schauen Projektentscheidungspunkte zu Beginn einer Phase nach vorne: Sind die notwendigen Voraussetzungen gegeben, um die nächste Phase zu starten (Benötigte Ressourcen vorhanden? Anforderungen geklärt? Vorarbeiten geleistet?).
Bei der Zeitplanung wird zwischen einer Top-Down- und einer Bottom-Up-Strategie unterschieden. Erstere beginnt mit der Definition der Phasen und zerlegt diese nach und nach in Arbeitspakete, bis diese die gewünschte Granularität haben. Bei der Bottom-Up-Strategie werden dagegen zuerst die elementaren Arbeitspakete identifiziert und anschließend zusammengefasst. Daneben wird zwischen der Vorwärts- und der Rückwärtsplanung unterschieden. Bei der Vorwärtsplanung legt man auf der Basis des Startpunkts des Projektes und der durch den Netzplan gegebenen Dauer den Endpunkt des Projektes fest. Bei der Rückwärtsplanung geht man von einem festen Abgabetermin aus und plant die Aktivitäten rückwärts. In der Praxis werden typischerweise Mischformen von Top-Down und Bottom-Up bzw. von Vorwärts- und Rückwärtsplanung verwendet.
Kostenplanung
Auf der Basis des Projektstrukturplans und der geschätzten Zeiten pro Arbeitspaket lässt sich die Kostenplanung durchführen. Sind die Kosten pro Stunde und Ressource bekannt, lässt sich ein Großteil der Kosten direkt kalkulieren. Weitere Kosten wie beispielsweise Reisekosten, Anschaffungskosten für Hard- oder Software, etc. müssen, falls sie dem Projekt zugeordnet werden, ebenfalls in die Kostenplanung aufgenommen werden.
Planung des Risikomanagements
Zur Planung des Projektes gehört die Identifikation möglicher Projektrisiken sowie die Festlegung, wie mit diesen Risiken umgegangen wird (siehe Projektrisikomanagement). Für eine konsistente Projektplanung ist es wichtig, dass die geplanten Aktivitäten im Zusammenhang mit dem Risikomanagement im Projektstrukturplan dokumentiert werden.
Kommunikationsplanung
In einem Kommunikationsplan wird neben der Frage wer mit wem kommuniziert (Projektorganisation), das Berichtswesen definiert. Teil der Planung ist damit, wer, wann, an wen einen Projektstatusbericht verschickt. Insbesondere werden in einem Kommunikationsplan auch Meilenstein-Sitzungen etc. geplant.
Projektplanung abschließen
Obwohl die einzelnen Schritte der Projektplanung sequentiell beschrieben werden, ist die Planung eines Projektes eher mit einem Puzzle zu vergleichen. In der Praxis „stimmt der Plan noch nicht“, wenn die Planungsaktivitäten durchgeführt wurden. Das Projekt ist zu teuer, nicht rechtzeitig fertig, benötigte Ressourcen stehen zum gewünschten Zeitpunkt nicht zur Verfügung, etc. Daher werden die einzelnen Planungsschritte in mehreren Iterationen durchlaufen, die Pläne mehrfach überarbeitet, bis ein konsistenter Gesamtplan vorliegt. Dieser stellt einen geeigneten Kompromiss bzgl. der unterschiedlichen Ziele, Erwartungen und Randbedingungen dar.
Wichtig ist in diesem Zusammenhang, dass die Pläne nicht vom Projektleiter allein erstellt werden. Projektpläne benötigen die Zustimmung aller am Projekt Beteiligten, z.B. der Projektsponsoren und der Mitarbeiter im Projekt. Im Capability Maturity Model Integration (CMMI), in dem Projektplanung eine zentrale Rolle einnimmt, wird daher explizit die Identifikation und Zustimmung der beteiligten Personen gefordert. Projektplanung ist in diesem Sinne kein rein mathematischer Algorithmus zur Ermittlung eines optimalen Plans sondern ein Weg, um einen Kompromiss zwischen allen Beteiligten (Stakeholder) bzgl. des Projekts zu erzielen.
Projektsteuerung und –kontrolle
Ziel der Projektsteuerung und -kontrolle ist es, einen Überblick über den Projektfortschritt zu geben, um gegebenenfalls geeignete Korrekturmaßnahmen einleiten zu können. In der Praxis wird anhand der Pläne überprüft, ob die zu einem bestimmten Zeitpunkt geplanten Aktivitäten erledigt sind, ob die Qualität den (geplanten) Erwartungen entspricht, ob Kosten eingehalten und die Ressourcen wie geplant eingesetzt werden. Sind die Abweichungen gering, werden üblicherweise mit Hilfe einer Offenen-Punkte-Liste zusätzliche Aktivitäten spezifiziert und mit Hilfe der Liste überwacht. Sind die Abweichungen größer, ist möglicherweise eine Überarbeitung der Pläne (engl. replanning) des Projektes notwendig. In der Praxis bedeutet dies beispielsweise, dass dem Projekt zusätzliche Ressourcen zur Verfügung gestellt, dass die Leistungsziele (die Systemanforderungen) reduziert werden oder dass der Abgabetermin verschoben wird.
Als Steuerungsinstrumente stehen vor allem Projektberichte, Projektreviews und Kennzahlen zur Verfügung. Projektspezifische Kennzahlen sind beispielsweise die bis zu einem bestimmten Zeitpunkt verbrauchten Kosten und gearbeiteten Stunden oder die Anzahl der fertiggestellten Teilprodukte. In SW-Entwicklungsprojekten sind typische Kennzahlen für den Projektfortschritt die Anzahl fertiger Module, die Anzahl geschriebener Quelltextzeilen (engl. Lines of Code, LOC), Anzahl durchgeführter und offener Testfälle sowie die Anzahl offener und korrigierter Fehler.
In einem Projektreview kommen Projektleitung und Leitungsausschuss (siehe Projektorganisation) zusammen. Die Projektleitung präsentiert den aktuellen Status des Projekts in Bezug zum geplanten Status. Projektreviews finden in der Praxis entweder regelmäßig (z.B. wöchentlich, monatlich) oder zu bestimmten Ereignissen (z.B. Meilenstein erreicht) statt.
Es ist offensichtlich, dass die Projektsteuerung von der Qualität der Projektpläne abhängt. Sind die Kriterien für die Fertigstellung eines Arbeitsprodukts bzw. Arbeitspakets nicht sauber definiert, dann kann auch keine saubere Kontrolle erfolgen.
Projektplanung und –steuerung in agilen Projekte
In den letzten Jahren ist agile Softwareentwicklung populär geworden. Der Wandel von traditionellen, wasserfall-basierten zu agilen Ansätzen hat Konsequenzen für Projektplanung und –steuerung. Während bei ersteren das gesamte Projekt geplant wird, lehnen agile Projekte diese Vorgehensweise als unrealistisch ab. In agilen Projekten wird das Projekt am Anfang in kleinere Iterationen fester Dauer unterteilt (z.B. 28 Tage). Es wird nur die jeweils nächste Iteration geplant und gesteuert. Da es zu Beginn eines Projekts unklar ist, wie viele Iterationen benötigt werden, ist es nicht möglich, Zeit- und Kostenziele für das Gesamtprojekt zu spezifizieren. Da die Iterationen kleiner sind als typische SW-Entwicklungsprojekte, sinkt der sonst notwendige Formalismus zur Planung und Steuerung. Planung und Steuerung werden dadurch nicht weniger wichtig aber leichter (lightweight processes). Die Projekte können mit einfacheren Instrumenten planen (handschriftliche Skizzen, …). Inwieweit große Projekte mit Hilfe agiler Methoden durchgeführt werden können, ist eine offene Frage.
Literatur
Frederick P. Brooks: Vom Mythos des Mann-Monats : Essays über Software-Engineering. 1.Deutsche Auflage. mitp : Bonn 2003
Harold Kerzner: Projekt Management : Ein systemorientierter Ansatz zur Planung und Steuerung. 2.Auflage. mitp : Heidelberg 2008
Steve McConnell: Rapid Development : Taming Wild Software Schedules. Microsoft Press : Redmond, Washington 1996
o.V.: A Guide to the Project Management Body of Knowledge (PMBOK Guide). 3.Auflage. Project Management Institute : 2004
Heinz Schelle; Roland Ottmann; Astrid Pfeiffer: ProjektManager. 3.Auflage. GPM Deutsche Gesellschaft für Projektmanagement : Nürnberg 2008
International Project Management Association (IPMA): www.ipma.ch (Abruf: 23.8.2013)
Project Management Institute (PMI): www.pmi.org (Abruf: 23.8.2013)
Software Engineering Institute, Capability Maturity Model Integration (CMMI): www.sei.cmu.edu/cmmi/ (Abruf: 23.8.2013)
