Projektplanungen realisieren mit MS Project 2003 und Project Server 2003

Projektplanungen realisieren mit MS Project 2003 und Project Server 2003 Josef Schwab ISBN 3-446-22204-9 Inhaltsverzeichnis Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-22204-9 sowie im Buchhandel Inhalt ________________________________________________________________________ V Inhalt Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII 1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Was ist ein Projekt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Projektplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.1 Ihr Plan entsteht im Kopf... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.2 ... vom Kopf in das Programm... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.3 ... und dann in die Realität! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.4 Wie werden die Termine berechnet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2.4.1 Der Kritische Weg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2.5 Praktische Bedeutung der Terminberechnung? . . . . . . . . . . . . . . . . . . . . 13 1.2.6 So wird das Programm richtig eingesetzt . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.7 Der Projektablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.3 Mehrere Projekte und viele Beteiligte? . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3.1 Multiprojekttechnik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3.2 Dateibasiertes Arbeiten versus Project Server-Lösung . . . . . . . . . . . . . . 19 1.3.3 Gründe für den Servereinsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.3.3.1 Team-Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.3.3.2 Unternehmensweiter Ressourceneinsatz . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.3.3.3 Projektübergreifende Auswertungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 1.4 Die Kommunikationsstruktur der Project Server-Lösung . . . . . . . . . . . . 23 2 Arbeiten mit Microsoft Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1 Eine kurze Bedienungsanleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.1.1 Oberfläche anpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.1.1.1 Automatische Internet-Hilfe ausschalten . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.1.1.2 Symbole ein-/ausblenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.1.2 Projektberater benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.1.3 Befehle ausführen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.1.3.1 Symbolleisten anpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.1.3.2 Auswahl über das Menü . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.1.3.3 Auswahl über das Kontextmenü . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.1.3.4 Befehlsausführung über Symbole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 VI _______________________________________________________________________ Inhalt 2.1.3.5 Weitere nützliche Symbole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.1.4 Ansichten, Tabellen und Masken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.1.4.1 Ansichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.1.4.2 Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.1.4.3 Masken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.1.4.4 Kombinierte Ansichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.1.4.5 In den Ansichten verlaufen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.2 Die Grundeinstellungen in Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.2.1 Bevor Sie beginnen... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.2.2 Anfangstermin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.2.3 Projektkalender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 2.2.3.1 Projektkalender bestimmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.2.3.2 Speichern und Geltung der Kalender . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.2.4 Kalender-Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.2.5 Datei-Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.3 Arbeiten mit dem Project Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.3.1 Anmeldung am Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.3.2 Speichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 2.3.3 Veröffentlichen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 2.3.4 Projekt öffnen/auschecken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 2.3.5 Projekt importieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 2.3.6 Projekt exportieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 2.3.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3 Terminmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.1 Terminplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.1.1 Definition der Vorgänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.1.1.1 Vorgangsliste bearbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3.1.2 Die Dauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3.1.3 Strukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.1.3.1 Sammelvorgänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.1.3.2 Gliederung nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.1.4 Anordnungsbeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.1.4.1 Ende-Anfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 3.1.4.2 Anfang-Anfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 3.1.4.3 Ende-Ende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.1.4.4 Anfang-Ende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.1.4.5 Vorgangsfolgen mit Zeitabständen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 3.1.4.6 Anordnungsbeziehungen vornehmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.1.5 Meilensteine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 3.1.6 Projektprozesse – einige Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.1.7 Ergebnis der Planung: berechnete Termine . . . . . . . . . . . . . . . . . . . . . . . 103 Inhalt ______________________________________________________________________ VII 3.1.8 Spezielle Terminberechnungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 3.1.8.1 Späteste Lage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 3.1.8.

Projektplanungen realisieren mit MS Project 2003 und Project Server 2003 Josef Schwab ISBN 3-446-22204-9 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-22204-9 sowie im Buchhandel 1 Grundlagen _______________________________________________________________ 19 3. sachliche und/oder terminliche Abhängigkeiten zwischen den Projekten. Projektüber- greifende Vorgangsverknüpfungen bilden diese ab. Auch Projekte insgesamt können voneinander abhängig sein. Schema 1.3 Projektübergreifende Vorgangsverknüpfung 1.3.2 Dateibasiertes Arbeiten versus Project Server-Lösung Auch wenn Sie mehrere Projekte gleichzeitig planen und steuern möchten: Bevor Sie auf eine Multiprojektumgebung mit dem Project Server losgehen, empfehle ich Ihnen, eine Kosten-Nutzen-Analyse zu machen. Viele – besonders kleinere – Unternehmen benöti- gen nicht unbedingt einen Project Server (und unterschätzen den Aufwand), um eine ganz akzeptable Datenbasis für ihre Projekte mit MS Project zu generieren. Für viele Anwendungen reicht m. E. eine klug angelegte Projektplanung auf Dateibasis durchaus. Umgekehrt bringt ein für die wirklichen Inhalte und Probleme des Projektma- nagements blinder Einsatz eines Project Servers zwar viele Daten, aber keine wirkliche Hilfe für die Projektleiter. Daten alleine helfen nicht, im Gegenteil: Datenflut führt zur Verwirrung. Die Perspektive des Tooleinsatzes muss immer die optimale Hilfe für die Menschen sein, die in und mit den Projekten arbeiten. Der entscheidende Unterschied zur herkömmlichen dateibasierten Arbeit ist die daten- bankbasierte Speicherung der Projektdaten auf dem Server. Die dateibasierte Arbeit spart eine Menge Aufwand und Probleme (und deren Beseitigung), hat aber – besonders natür- lich in der Multiprojekttechnik – deutliche Grenzen. Der Einsatz des Project Servers bedeutet finanziellen und personellen Aufwand und bietet dafür wesentliche Informa- tionsgewinne und ein besseres Handling besonders für – manche werden sagen, es ermöglicht erst – unternehmensweites Projektmanagement. Sie werden an den jeweiligen 20 ______________________________________ 1.3 Mehrere Projekte und viele Beteiligte? Stellen hier im Buch – z.B. bei der Ressourceneinsatzplanung – den Unterschied demons- triert bekommen und können dann entscheiden, ob Sie die „große“ Lösung mit dem Ser- ver angehen wollen. Hier einige generelle Überlegungen vorab. 1.3.3 Gründe für den Servereinsatz Bedenken Sie bei der Kosten-Nutzen-Überlegung, dass es nicht mit dem Erwerb des Ser- vers getan ist, was die Beschaffung der Hardware, der Software und der Lizenzen betrifft. Der Server muss installiert werden (kein ganz einfaches Unterfangen, wenn alles – auch z.B. die gemeinsame Dokumentenverwaltung (Windows SharePoint Services) – richtig funktionieren soll. Die Enterprise-Funktionen müssen an die unternehmensspezifischen Gegebenheiten angepasst werden, angefangen von den gemeinsamen Arbeitszeitkalen- dern bis hin zu den Einstellungen über den Rückmeldemodus und andere Teamwork- Funktionen im Web Access. Die Daten auf dem Server müssen zentral gepflegt werden, so z.B. der unternehmensweite Ressourcenpool etc. (siehe 7. Kapitel, „Project Server ein- richten und verwalten). Kurz, eine Umgebung für unternehmensweites Projektmanagement gibt es nicht umsonst, sondern erfordert neben finanziellem Aufwand für Hard- und Software (den man aufgrund der Nutzeranzahl kalkulieren kann) auch einen personellen Aufwand in der eigenen Orga- nisation (der wahrscheinlich schwerer zu kalkulieren und längerfristig höher als der Erst- genannte ist). Ab einer gewissen Größenordnung wird es nicht ohne die Etablierung eines Projektbüros gehen, auf jeden Fall muss es einen (der nette „Kümmerer“) oder mehrere Verantwortliche für die Einrichtung und Pflege der Enterprise Features geben. Man wagt sich ja an echtes Multiprojektmanagement heran, und dies sollte – auch was die organisa- torischen Veränderungen für die Organisation angeht – nicht unterschätzt werden. Der Einsatz eines Project Servers ist dann notwendig bzw. sinnvoll, wenn folgende Sach- verhalte in Ihrem Unternehmen oder Ihrer Organisation eine Rolle spielen: 1.3.3.1 Team-Kommunikation Der in meiner Beratungspraxis an erster Stelle stehende Grund, den Project Server einzu- setzen, ist der Wunsch, eine entwickelte elektronische Team-Kommunikation einzuset- zen. Dies stellt sich als Notwendigkeit dar z.B. bei verteilten Standorten oder bei vielen Mitarbeitern in Projekten, die in die Kommunikation über den Projektfortgang einbezo- gen werden müssen. Die auf dem Server veröffentlichten Projektdaten stehen über den Web Access nach Zugriffsrechten differenziert für Mitarbeiter, Geschäftsführung, Kunden oder andere Inte- ressenten („Stakeholders“) zur Verfügung, ohne dass diese MS Project benötigen. Über den Project Web Access mittels des Internet Explorers können Sachverhalte kommuni- ziert werden wie z.B. die in Vorgängen geleistete Arbeit, oder es können neue Aufgaben vorgeschlagen oder Aufgaben weiterdelegiert werden, die Termine in den Projekten kön- 1 Grundlagen _______________________________________________________________ 21 nen (endlich, und vielleicht auch nicht so wie gewünscht) mit der persönlichen Termin- planung in MS Outlook koordiniert werden etc. (siehe 8. Kapitel, „Teamarbeit mit dem Web Access“). Bei der Einführung bzw. Benutzung einer computergestützten Kommunikation in der Teamarbeit wie dem Web Access kommt es nicht nur darauf an, dass die Benutzer eine solche Kommunikationsform gewohnt sind, sondern dass sie den Hintergrund der kom- munizierten Daten kennen und ihren Nutzen verstehen. Denn sie, die Mitarbeiter, die rückmelden, müssen einen gewissen von ihnen zu erbringenden Aufwand akzeptieren – meist wird dies als zusätzlicher Arbeitsaufwand oder gar als Kontrolle angesehen, obwohl man sich natürlich fragen kann, wie denn bisher die Projektdaten kommuniziert wurden bzw. was die Alternative wäre. Dies wird in einer projektorientierten Organisation leichter gehen als in einer sehr tradi- tionellen Linienorganisation, aber es wird m.E. in jedem Fall notwendig sein, auch die Benutzer des Web Access einzuweisen, weniger in der Bedienung der Oberfläche an sich, sondern in Sinn und Nutzen des Projektmanagements. Erst wenn sie den Gesamtzusam- menhang ihrer Daten in der Projektarbeit des Unternehmens oder der Organisation und ihren möglichen Nutzen erkennen können und Vertrauen in diese Zusammenarbeit haben, werden sie motiviert sein, den notwendigen Aufwand zu leisten. 1.3.3.2 Unternehmensweiter Ressourceneinsatz Die vordringliche Aufgabe des Multiprojektmanagements ist es, den Einsatz der Mitar- beiter über viele parallel laufende Projekte zu steuern. Hier gibt es zwar auch eine dateibasierte Lösung, der gemeinsame Ressourcenpool für mehrere Projekte – ein gemeinsamer Ressourcenpool als Datei ist auch mit Project 2002 und Project 2003 möglich (siehe 4. Kapitel, Abschnitt 4.8, „Ressourcenpool als Datei“) –, aber diese Lösung hat doch enge Grenzen. Dies liegt einmal an der Unmög- lichkeit, differenzierte Zugriffsrechte auf die Ressourcendaten einzurichten, zum ande- ren gibt es ab einer bestimmten Anzahl von Ressourcen und Projekten nicht nur Perfor- mance- und Stabilitätsprobleme, sondern für die Projektleiter wird es sehr komplex, die Übersicht zu behalten. Hier hilft der Servereinsatz mit seiner Funktion des Team-Buil- ders: Damit kann für jedes Projekt das Team zusammengestellt werden, und der Pro- jektleiter muss nur noch sein Team planen und überwachen – eine wesentliche Erleich- terung gegenüber dem dateibasierten Ressourcenpool. Als entscheidendes K.o.-Kriterium wird immer genannt, dass die auf den dateibasierten Ressourcenpool zugreifenden Projektleiter einen unbegrenzten Schreibzugriff auf diese Datei benötigten. Sie können Ressourcenkalender ändern, Ressourcen löschen oder neue hinzufügen – kurz, der unkontrollierten Bearbeitung der Daten kann man informa- tionstechnisch keinen Riegel vorschieben. (Meine Erfahrung ist allerdings, dass man in einem überschaubaren Rahmen durch organisatorische Maßnahmen mit diesem Manko sehr wohl leben kann – organisatorischer Wille und Disziplin, die sich auch durch ent- 22 ______________________________________ 1.3 Mehrere Projekte und viele Beteiligte? sprechende Einweisungen der Mitarbeiter ergibt, vorausgesetzt.) Hier bietet die Haltung der unternehmensweiten Ressourcendaten auf dem Server ganz andere Möglichkeiten: differenzierte Zugriffsmöglichkeiten nach Rollen: neben den Teammitgliedern sind in der Benutzerverwaltung des Project Servers die Gruppen Projektmanager, Teamleiter, Ressourcenmanager, Portfoliomanager und Führungskräfte angelegt. Durch Anpassung der Rechte der Gruppen oder der Neudefinition von Rollen und der Kategorien, die Hand- lungsrechte auf Objekte zusammenfassen, kann doch ein Stück weit die Projektorganisa- tion des Unternehmens oder der Institution abgebildet werden. Durch den Ressourcen- strukturcode (RSP-Code) kann auch zusätzlich die Organisationsstruktur in die Vergabe der Zugriffsrechte einbezogen werden (s. Kapitel 7, Abschnitte 7.4 und 7.5). 1.3.3.3 Projektübergreifende Auswertungen Projektorientierte Unternehmen oder Abteilungen zeichnen sich dadurch aus, dass ein größerer Teil ihrer Wertschöpfung in Projekten stattfindet. Hier stellt sich die Frage, wie Projekte vergleichbar sind hinsichtlich ihrer Effizienz, letztlich ihrer Profitabilität. Viel- leicht kann man daraus Schlüsse ziehen über die Auswahl zukünftiger Projekte. Denn nicht nur bei einem großen Angebot von Vorschlägen, was man machen könnte und was evtl. wünschenswert wäre, ist die Steuerung der Projektlandschaft eines Unternehmens eine nicht ganz leichte Managementaufgabe.

Projektplanungen realisieren mit MS Project 2003 und Project Server 2003 Josef Schwab ISBN 3-446-22204-9 Vorwort Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-22204-9 sowie im Buchhandel Vorwort ____________________________________________________________________ XIII Vorwort Dieses Buch will zeigen, wie Projektleiter das Programm Microsoft Project in der Praxis der Projektplanung und der Projektdurchführung sinnvoll einsetzen können. Die Vollstän- digkeit der Beschreibung der Software ist nicht das Ziel dieser Ausführungen. Ziel ist da- gegen, die Methoden zu zeigen, wie vor dem Hintergrund der Praxis des Projektmanage- ments das Programm so anzuwenden ist, dass es mit einem vertretbaren Aufwand optimale Informationsgewinne generiert und möglichen Handlungsbedarf in der Projekt- arbeit aufzeigt.1 Dies bleibt uneingeschränkt das Ziel auch für dieses Buch, indem die Projektarbeit mit der Version Microsoft Office Project 2003 und dem Project Server dargestellt wird. Auch und gerade bei dem Einsatz multiprojektfähiger Software kommt es darauf an, den An- wender zu befähigen, mit der zunehmenden Komplexität der Software umzugehen. Ent- gegen mancher Versprechung, kann die Software nicht die qualifizierte Anwendung und das dazu notwendige Wissen auf Seiten des Anwenders verringern oder gar ersetzen, sondern erfordert im Gegenteil mehr denn je Wissen sowohl über die Methode des Pro- jektmanagements als auch über den entsprechenden methodischen Einsatz des Pro- gramms. Nach wie vor ist nicht das Ziel, die Software vollständig zu beschreiben, sondern aus der Praxis des Projektmanagements einen Weg zu zeigen, wie die Software sinnvoll und pra- xisgerecht einzusetzen ist. Versionen Nun ist mein Vorhaben durch die neuen Versionen des Programms (zunächst Version 2002, jetzt die aktuelle Version 2003) nicht einfacher geworden, da es jeweils die Mög- lichkeit gibt, Project als Desktop-Version, also ohne Server, einzusetzen, oder in einer de- zidierten Mehrprojektumgebung, also mit Server. Ein Einsatz ohne Server erfordert nur die jeweiligen Standardversionen (Project 2002 Standard oder Project 2003 Standard). Damit arbeitet man dateibasiert, d.h. die einzelnen Projekte werden als Project-Dateien geführt. 1 Dies ist der einleitende Abschnitt meines Buches zur Vorgängerversion: „MS Project 2000 Projektplanungen realisieren. Ein praktischer Leitfaden“. Hanser Verlag, München 2001 XIV ____________________________________________________________________ Vorwort Bei Einsatz des Project Servers hat man die zusätzliche Möglichkeit, die Projekte auf dem Server in eine Datenbank zu speichern (ohne die Möglichkeit, dateibasiert zu arbei- ten, zu verlieren). Nur dann benötigt man die Version Professional 2002 oder Professio- nal 2003. Einzelprojekte und Server Dieses Buch will den Mitarbeitern helfen, die ihre Projekte mit den Desktop-Versionen, also ohne Server, auf Dateibasis (das können Einzel-, aber auch viele Projekte sein), pla- nen und überwachen, und soll auch den Projektleitern in Unternehmen von Nutzen sein, die ihre Projekte in einer dezidierten Multiprojektumgebung führen, also ihre Projekte auf dem Project Server anlegen und pflegen. Letzteres wird von Microsoft als EPM = Enter- prise Project Management bezeichnet, und ich werde es hier als unternehmensweites Pro- jektmanagement oder Multiprojektmanagement bezeichnen. Die Basis jeder Projektarbeit bleibt die Anlage des individuellen Projektes, das sind die Vorgänge und ihr geschätzter Aufwand, die Struktur der Projektphasen, die Erfassung des Ablaufes und die zugeordneten Ressourcen in diesem Projekt. Das Einzelprojekt liefert die Daten. Wenn diese auf dem Server gespeichert werden, besteht die Möglichkeit, die vielen Projekte in ihrer Gesamtheit zu betrachten. Der Einsatz eines Servers bringt einen Informationsgewinn auch für das Einzelprojekt, z.B. die bessere Sicht auf den projekt- übergreifenden Ressourceneinsatz, aber er macht die sorgfältige Planung des Einzelpro- jektes nicht unnötig, sondern im Gegenteil: Wenn die Anlage der Einzelprojekte falsche oder schlechte Daten liefert, kann man sich den Aufwand für den Server eigentlich spa- ren. Der Einsatz des Servers baut auf der Qualität der Einzelprojekte auf. Die Grundlagen der Projektarbeit sind identisch, versionsunabhängig und unabhängig von der technischen Umgebung. Deshalb richtet sich der größte Teil der Ausführungen im Buch an Projektmenschen aller Couleur und ist unabhängig von datei- oder serverbasier- ten Lösungen. Nun gibt es Teile oder Abschnitte des Buches, die sich speziell nur an die Anwender einer Art richten. Dies ist deutlich zu erkennen aus der Überschrift des Kapitels, z.B. des 7. Ka- pitels „Project Server einrichten und verwalten“ und des 8. Kapitels „Teamarbeit mit dem Web Access“. Letzteres richtet sich speziell an Mitarbeiter, die zwar in Projekte und damit in die Kommunikation der Projektdaten eingebunden sind, aber nicht selbst mit Microsoft Project arbeiten und über den Internet Explorer mit dem Project Server mittels des Web Access kommunizieren (siehe 1. Kapitel, Abschnitt 1.4: „Die Kommunikationsstruktur der Project Server-Lösung“). In einigen Abschnitten gibt es eine Aufteilung nach der Art der Anwendung. Soweit das dargestellte Feature nur die dateibasierte Arbeit betrifft, wird dies mit diesem Symbol ge- kennzeichnet: Vorwort ____________________________________________________________________ XV Dateibasiert Wenn diese Anwendung nur speziell in der Server-Umgebung möglich ist: Serverbasiert Der Aufbau folgt auch in dieser Reihenfolge, zunächst immer die Darstellung für das Einzelprojekt, dann die Darstellung für die Project Server-Anwender. Dies mag zu kleinen Unbequemlichkeiten führen, die aber unvermeidlich sind: so wird im Kapitel 2 erst eine kurze Bedienungsanleitung für die Standard-Oberfläche von Microsoft Project gegeben, danach die Anmeldung am Project Server dargestellt. Prozessorientierung Mein Buch zum Projektmanagement mit Project 2000 in diesem Verlag ist ja sehr freundlich aufgenommen worden, trotz der darin methodisch angelegten (provozieren- den) These „Keine Termine ohne vorherige Planung“. So eigenartig es klingt, aber dass die entscheidende Aufgabe der Projektplanung darin besteht, die Aktivitäten mit ihrem Zeitbedarf und ihrem Ablauf zu ermitteln und daraus die möglichen Termine zu errech- nen, d.h. dass die Termine das Ergebnis (!) der Planung sind, ist noch nicht zu allen Men- schen durchgedrungen, die glauben, Projektmanagement zu betreiben. Die Vorgabe irgendwelcher Termine wird für Projektplanung gehalten.2 Meine provozierende Frage ist natürlich die, wo Termine herkommen, die nicht aus einer Planung resultieren? Entsprechend katastrophal sind ja auch die Resultate prominenter Projekte und die in Untersuchungen ermittelten Erfolgsraten von Projekten (im Durchschnitt z.B. bei Soft- ware-Projekten 50–70% Zeit- und Kostenüberschreitungen, hohe Abbruchraten). Dies ganz im Gegensatz zur Eigenwerbung der Berater, denen jedes Projekt gelingt. Um nicht nur über die Ergebnisse zu jammern, sondern die Entstehung der Probleme zu sondieren, hat sich die Forschung jetzt immerhin auch der „Qualität der Planung“ angenommen, und eine hohe Korrelation von schlechter oder Nicht-Planung und Projektmisserfolg festgestellt.3 2 „Im Schätzen sind wir nie sehr gut gewesen, weil unsere Chefs es nie wirklich beachtet haben. Wir hatten Projekte, die ,abgeschlossen sein mussten am Soundsovielten, ganz egal was passiert‘. In solchen Situationen war der Termin ein Ziel, keine Schätzung.“ Tim Lister und Tom DeMarco im Interview, Dorset House 2002, deutsche Übersetzung 2004 Carl Hanser Verlag, München Wien 3 „Von der Erfolgsfaktorenforschung zu Frühwarnsystemen im Projektmanagement“, Vortrag von Prof. Dr. Gemünden, TU Berlin, vor der GPM-Regionalgruppe Berlin am 25.02.2004 XVI ____________________________________________________________________ Vorwort Nun glaube ich, noch eine Unterstützung von anderer Seite bekommen zu haben. Die Methodik des PMI (Project Management Institut, Pennsylvania, USA) dringt erfolgreich nach Deutschland vor und der PMBOK Guide4 wird als Standard deklariert. Schon ein Blick in das Inhaltsverzeichnis des PMBOK Guide zeigt, dass hier die (neun) Wissensgebiete des Projektmanagements behandelt werden. Dies ist aber kein Vorge- hensmodell, sondern eine m. E. gut strukturierte Darstellung der Wissensgebiete des Pro- jektmanagements, die ein Projektleiter beherrschen sollte. Aus den Wissensgebieten lässt sich kein Vorgehensmodell ableiten, und soweit z.B. Phasenmodelle dargestellt werden, werden diese ausdrücklich als beispielhafte Darstellungen bezeichnet. Es ist hier nicht der Ort, den Inhalt des PMBOK Guides ausführlich zu erörtern. Wichtig ist mir die Darstellung der Methode, und dies ist die gnadenlose Strukturierung in Pro- zesse. „Projekte setzen sich aus Prozessen zusammen. Ein Prozess ist eine Abfolge von Handlungen, die ein Ergebnis hervorbringen.“ (Abschnitt 3.1, S. 29) Prozesse sind eine Abfolge von Handlungen, die so beschrieben werden können: Eingangswerte (Input): Um den Prozess beginnen zu können, müssen diese Eingangswerte vorhanden sein oder beschafft werden. Diese Werte können Dokumente, Daten, Informationen oder Material sein – alles, was notwendig ist, um den Prozess durchführen zu können. Werkzeuge und Verfahren (Tools and Techniques): Dies ist die Beschreibung des Vorgehens in diesem Prozess: Mit welchen Werkzeugen wird welches Verfahren angewendet, um das gewünschte Ergebnis zu erzielen. Ausgangswerte (Output): Die Ergebnisse dieses Prozesses.