4 Terminplansteuerung bei mehreren Projekten (S. 133)

Wir haben im vorherigen Kapitel den systematischen Aufbau eines Projektplanes dargestellt. Das singuläre Projekt ist die „Keimzelle" jedes Projektmanagements, darauf baut alles auf. Im einzelnen Projekt entsteht die Qualität der Daten, auch und gerade, wenn viele Projekte eine Rolle spielen und die Daten aller Projekte des Unternehmens insgesamt betrachtet und ausgewertet werden sollen. Es nützt die tollste Server-Technologie nichts, wenn die Daten aus den einzelnen Projekten Schrott sind.

Der methodisch kluge Aufbau eines Projektes besteht in der richtigen „Mischung" von Vorgängen, die vom Programm berechnet werden können, und Fixterminen. Bei Änderungen soll das Programm die Termine und die anderen Daten (z. B. Ressourcenauslastung) bei „normalen" Vorgängen neu berechnen und damit die geänderte Datenlage anzeigen und Fixtermine, die den Projektplan stabilisieren und deren Änderung nur durch einen Eingriff der Projektleitung (und nicht durch das Programm) möglich ist. Alle wichtigen Übergänge im Projekt – zwischen den Projektphasen, von einem Unternehmen zum nächsten oder auch von einer Abteilung zu anderen – müssen als Meilensteile fest vereinbart, d. h., in Project fixiert werden. Im Gegensatz dazu müssen alle inhaltlichen Aktivitäten, die sich in der eigenen Planungshoheit befinden, variabel sein hinsichtlich Termin- und Ressourcenänderungen.

Dieses methodische Prinzip findet seine analoge Fortsetzung, wenn man mit mehreren Projekten arbeitet. All das, was wir bisher für die Projektphasen und ihre Übergänge entwickelt haben, gilt sinngemäß bei mehreren Projekten für ihre Struktur und ihre Abhängigkeiten untereinander.

Projektorientiertes Arbeiten in Unternehmen führt schnell von einigen Projekten zu vielen. Es gibt mannigfache Gründe, mit mehreren Projekten zu arbeiten. Einmal weil es ganz einfach viele Entwicklungen, z. B. neuer Produkte oder neuer Technologien, gibt, die als Projekte vorangebracht werden. Zum anderen kann man auch ein großes Projekt in mehrere Teilprojekte aufteilen, wobei jeder Projektleiter seinen Teil als Projektplan verantwortlich pflegt. Wie man den Inhalt und Umfang eines Projektes definiert, ist ja frei, und da mögen einzelne Projektphasen schon als eigenständige Projekte gelten oder Teile eines Gesamtprojektes (man denke an Entwicklungen im Maschinen- und Anlagebau) schon so umfangreich sein, dass man sie als eigenständige Projekte ansehen will oder aus organisatorischen Gründen ansehen muss. Gerade wenn man große Projekte in Teilprojekte aufgliedert, bleiben die Abhängigkeiten von Vorgängen in einem Projekt von Ergebnissen in einem anderen Projekt bestehen.

Umgekehrt – sozusagen von oben betrachtet – besteht das gesamte Projektportfolio eines Unternehmens oder einer Organisation aus mehr oder weniger großen Projekten, die wieder in Teil- oder Unterprojekte aufgeteilt sein mögen. (Die Einteilung in Programme, z. B. Organisations-, Produkt- oder interne Technologieentwicklungsprojekte, ordnet die Projekte inhaltlich, nicht strukturell.)

Manche Unternehmen siedeln ihr Projektmanagement auf unterschiedlichen organisatorischen Ebenen an: Die oberste Ebene ist verantwortlich für den Kundenkontakt und vereinbart feste Meilensteine mit den Stakeholdern. Die Termine müssen mit der operativen Ebene, die intern das Projekt realisiert, kommuniziert werden und vice versa. Auch dies führt technisch zu mehreren oder vielen Project-Dateien, die spezifische Verknüpfungen haben. Bei der Gesamtprojektplanung mit dem Project Server 2007 können Lieferumfänge (Deliverables) definiert werden. Diese stellen wichtige Auslieferungen des Projektes zu einem bestimmten Zeitpunkt dar.