Projektmanagement mit Tool-Unterstützung

Berlin, den 23.02.2004 Josef Schwab Projektmanagement mit Tool-Unterstützung Methodisches Projektmanagement mit MS Project Es gibt eine historisch gewachsene Aufteilung des Fachwissens zum Projekt- management, sowohl in der einschlägigen Literatur als auch in den Kompetenzbeschreibungen der Berater: einerseits gibt es eine fast unübersehbare Literatur zum Projektmanagement überhaupt, zu den Methoden des PM, ebenso entsprechende Autoren, und dies sind dann auch meist die renommierten Fachleute. Andererseits gibt es Bücher zur Anwendung von EDV-Programmen zum Projektmanagement und hier entsprechend kompetente Berater und Trainer. Dies setzt sich fort in dem Angebot zur Aus- und Weiterbildung: einerseits Methodenseminare (was immer die Anbieter zu den zu lehrenden Kernkompetenzen zählen, jedoch ohne Tool-Anwendung), anderseits gibt es Tool-Kurse, die als reine Programm-Anwenderschulungen betrachtet werden. Der Graben scheint fest gefügt: die Methoden-Päpste lassen sich natürlich nicht in die Niederungen der Tool-Anwendung ein, die Spezialisten für Tools lehnen die Beschäftigung oder gar Festlegung auf PM-Methoden ab. Für Letztere ist das Tool ein Werkzeug, mehr nicht. Diese Trennung ignoriert, dass gerade die Tool-Anwendung der methodischen Grundlage bedarf, wenn sie erfolgreich sein soll. Umgekehrt ist Projektmanagement nicht mehr ohne PC-Unterstützung zu realisieren, sowohl für die Planung und Steuerung der Projekte wie auch für die Kommunikation der Projektdaten. So bleibt der Projektleiter oder das Projektteam alleine, wenn es nach Wegen sucht, ein oder gar mehrere Projekte nach erprobten Methoden lege artis mit einem beherrschbaren Tool zu planen und zu steuern, und das auch noch mit einem vernünftigen Aufwands-/Ertragsverhältnis. In diesem kurzen Ausführungen will ich versuchen, das methodische Vorgehen im Projektmanagement bezogen auf die Arbeit mit einem PM- Tool darzustellen. Dies ist die benötigte Hilfe für die Praxis der Projektarbeit, wie z. B. ein mir unbekannter Leser meines Buches über Projektmanagement mit Microsoft Project feststellt: “Dieses Buch stellt das methodische Vorgehen im PM bezogen auf eine bestimmte Software dar. Es Seite 1 von 11 war für mich von sehr viel höherem Nutzen als Bücher, die nur PM oder nur eine Software vorstellen.“ 1 Des PMBOK Guide des PMI (USA)2 soll die methodische Grundlage darstellen. Statt der Aufteilung in Wissensgebiete stelle ich die Vorgehensweise im Projektablauf dar. Die Methode des PMBoK Guides ist eine strenge Strukturierung in (Projekt-) Prozesse. Ein Prozess wird definiert durch seine jeweiligen Eingangswerte („Inputs“: notwendige Vorraussetzungen oder Kenntnisse, die entweder vorliegen oder beschafft werden müssen), eine Beschreibung der anzuwendenden Werkzeuge und Verfahren in diesem Prozess („Tools & Techniques“) und das Ergebnis dieses Prozesses, die Ausgangswerte („Output“). Meist ist der Output eines Prozesses ein Liefergegenstand („Deliverible“), der als Input für den nächsten Schritt oder die nächste Phase der Projektarbeit eine Voraussetzung ist. Im Prinzip ist meine Darstellung eines systematischen PM-Vorgehens neutral gegenüber dem Einsatz einer bestimmten Software, da alle Programme zum PM auf der gleichen Grundlage („Netzplantechnik“) beruhen (unabhängig von der IT-Technik) und sich in Darstellungs- und Handhabungsvarianten unterscheiden. Als Tool will ich Microsoft Project verwenden, da es das am Meisten eingesetzte Programm ist. Dies sagt nichts primär über die Leistungsfähigkeit des Tools aus, sondern, dass es die größte Akzeptanz unter den Benutzern findet. Es ist in der Version Project 2003 mit Project Server verfügbar. Ich beginne mit der Planung und Überwachung des Einzelprojektes, schließe einige Überlegungen zur Multiprojekttechnik mit dem Project Server an und stelle zum Schluss noch kurz die Team- Projektkommunikation über den Web Access dar, der einen kontrollierten Browser-Zugriff auf die Projektdaten ermöglicht. 1 Ein unbekannter Leser bei „Amazon“ über mein Buch „MS Project 2000 Projektplanungen realisieren“, Hanser Verlag, München 2001 Demnächst erscheint das Update im gleichen Verlag: „Projektplanungen realisieren mit MS Project 2003 und Project Server“ 2 „A Guide to the Project Management of Knowledge (PMBOK Guide)”, Ausgabe 2000, Deutsche Übersetzung, Hrsg. Project Management Institut, Inc., Pennsylvania, USA Seite 2 von 11 1 Terminmanagement 1.1 Terminplanung Nachdem Ziel, Inhalt und Umfang der Projektes festgelegt sind, kann die Terminplanung des Projektes in Angriff genommen werden. Hierzu ist der Einsatz einer PM-Software die notwendige Technik, da eine Berechnung der Termine ohne Tool schlichtweg zuviel Zeit benötigte, im Normalfall die Beteiligten überfordern würde. Die Inputs der Terminplanung sind (als Bestandteil der genannten Inhalts- und Umfangsdefinition) die Projektstruktur, d.h. die Definition der Phasen. Hier die Sicht auf die Struktur, die als Ergebnis einer Phase immer eine Lieferung oder ein überprüfbares Ergebnis darstellen sollte: Abb. 1: Phasenplanung Natürlich können Projektphasen zeitlich parallel liegen, wenn der Output einer Phase nicht der Input der anderen Phase ist. Zur Vorgangsplanung werden die Projektphasen, gegebenenfalls wieder in Abschnitte gegliedert, letztlich auf einzelne Arbeitspakete heruntergebrochen („Definition der Vorgänge“). Für die Vorgänge muss der jeweilige Aufwand geschätzt werden und der Ablauf der Vorgänge, sei es technischer oder organisatorischer Natur, muss in Vorgangsfolgen erfasst werden. Ein wichtiges Strukturierungselement ist die Definition von Meilensteinen („Festlegung der Vorgangsfolgen“). Wenn man auch den Einsatz der Mitarbeiter oder anderer am Projekt beteiligten planen und überwachen will, müssen die Ressourcen („Einsatzmittelbedarf“) den Vorgängen zugeordnet werden. Wenn dabei schon die Verfügbarkeit und die Arbeitszeiten der Mitarbeiter gepflegt werden, ist das Ergebnis der fertige Teminplan. Die notwendige Informationsbeschaffung erfordert in der Praxis u. U. viel Aufwand. Hat man diese Informationen zur Verfügung, ist die Eingabe und der Aufbau im Tool, hier in MS Project, der leichtere Teil der Übung. Nach Seite 3 von 11 Eingabe des Projektanfangstermins werden nach der Methode des Kritischen Weges die Termine berechnet: Abb. 2: Berechnete Termine 1.2 Termineinschränkungen In der Terminplanung ermittelt die Projektleitung durch eine sorgfältige Strukturierung der Vorgänge den von ihr für notwendig erachteten Zeitbedarf für das Vorhaben. Nun wird es in der Realität oft nicht allein am Projektleiter liegen, das Zeitfenster des Projektes zu bestimmen. Externe Terminvorgaben sind an der Tagesordnung, oder die Projektleitung setzt sich selbst fixe Termine für bestimmte Meilensteine. Dies hat den Vorteil, dass schon in der Planung oder dann in der Projektdurchführung (gegenüber den „Ist-Werten“) sowohl Zeitreserven als auch Terminplankonflikte erkannt werden können. Für diesen Schritt sind die externen Terminvorgaben oder die selbst gewählten Fixtermine die Eingangswerte, das Verfahren ist die Festlegung der Termine im Tool, das Ergebnis sind die Informationen über Terminplankonflikte oder Pufferzeiten. Die Sicht auf Pufferzeiten (grüne Unterstriche hinter den Vorgängen) und Terminplankonflikte (negative Pufferzeiten als pinke Unterstriche vor den Balken): Seite 4 von 11 Abb. 3: Terminplankonflikt und Pufferzeiten Durch die Festlegung des Starts der Programmierung hier im Beispiel auf den Termin 1. 6. wird erkennbar, dass die davor ablaufenden Phasen diesen Termin nicht werden halten können. Eine Planänderung wäre notwendig, dadurch würde sich auch der Terminplan für die Ressourcen ändern. Die grünen Pufferzeiten signalisieren eine Zeitreserve. Das Terminmanagement ist so lange zu durchlaufen, bis eine von allen Projektbeteiligten und –interessenten („Stakeholder“) akzeptierte Terminplanung erreicht ist. 1.3 Projektausführung Nach der Planung kommt die Durchführung des Projektes, wobei dies im Regelfall natürlich in iterativen Schleifen durchlaufen wird: die Realisierung einer oder mehrer Phasen kann so gravierende Änderungen mit sich bringen, dass man die folgenden Phasen wieder neu planen muss. Der PMBOK Guide fasst dies als „Integrationsmanagement“ zusammen und nennt die iterative Überarbeitung der Pläne „Integrierte Änderungssteuerung“. Die Projektleitung muss in der Projektausführung die realisierten Fortschritte überwachen und Maßnahmen ergreifen, wenn Vorgänge nicht wie geplant durchgeführt werden (können). Wie der realisierte Fortschritt festgestellt wird, ist ein weites Feld und sehr unterschiedlich in den Projektarten. Seite 5 von 11 Ein sicherer Wert sind die realisierten Termine, also ob die Vorgänge zum geplanten Termin begonnen werden und dann zu den vorgesehenen Ter- minen ihre Ergebnisse erbringen. In MS Project, wie in anderen PM-Tools auch, muss ein Basisplan festgehalten werden, um dann die Abweichungen der Ist-Werte zu den Soll- Werten (das sind die des Basisplanes) errechnen und anzeigen zu können. Nachdem der Basisplan gespeichert ist, müssen die aktuellen Termine in die entsprechenden Felder eingetragen werden. Die Eingangswerte der Projektüberwachung sind die geplanten Werte (Basisplan) und die Ist-Werte (Aktuelle Werte). Das Ergebnis sind die Informationen über Abweichungen und evtl. notwendige Änderungen. Abb.