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