Eine der wichtigsten und bekanntesten Ursachen für Schwierigkeiten in IT-Projekten ist, dass Auftraggeber und Auftragnehmer vor dem Projektstart nicht ausreichend Klarheit über die zu erstellenden Ergebnisse geschaffen haben. Es ist relativ einfach, ein Budget (z.B. 0,5 Mio €) oder einen Fertigstellungszeitpunkt (z.B. 2015-01-31) genau anzugeben. Wesentlich schwieriger gestaltet es sich, alle Komponenten des Produkts genau zu benennen.

Wenn z.B. der Abteilungsleiter eines Fachbereichs eine Software kennenlernt, von der er sich eine deutliche Effizienzsteigerung verspricht, stellt er schnell entschlossen einen Projektantrag an die hauseigene IT-Abteilung. Im diesem Antrag beschreibt er, wie er diese Software zur Unterstützung eines Geschäftsprozesses einsetzen möchte, er definiert ein Budget und einen Zeitrahmen. Eventuell ergänzt er noch einen Business Case, in dem er die Nutzeffekte überaus optimistisch darstellt. Weitere Fachexperten oder Vertreter der betreuenden IT-Abteilung zieht er nur selten hinzu. Die Folge davon ist, dass z.B. die Migration von Datenaltbeständen, der Aufbau und die Anpassung von Schnittstellen zu anderen Systemen oder Einführungs- und Trainingsaufwände völlig außer acht gelassen werden.

Im Laufe des Projekts werden diese Themen unweigerlich hochkommen und zu Diskussionen zwischen Antragsteller und dem Projektleiter über benötigtes zusätzliches Budget und eine Ausdehnung des geplanten Zeitrahmens führen: Das Projekt gerät in Schieflage oder droht sogar zu scheitern. Der "schwarze Peter" liegt dann meist beim Projektleiter, der sich rechtfertigen muss, warum er nicht zeit- oder kostengerecht alle nun gewünschten Produkte und Eigenschaften liefern kann (Enderle da Silva, 2013).

Als verantwortlicher Manager für Prozesse und Tools im PMO der Abteilung Information Management der Airbus Defence and Space (vorher: Cassidian als Tochter der EADS) suche ich beständig nach Verbesserungsmöglichkeiten für das Projektmanagement des Bereichs Information Management (IM). Deshalb analysierte ich einzelne in Turbulenzen geratene Projekte und stellte dabei fest, dass genau die oben beschriebene Problematik in der Vergangenheit zu den Schwierigkeiten führte. Hierzu zwei weitere Beispiele:

• Es wird vergessen oder nur halbherzig berücksichtigt, dass bei einem internationalen Roll-Out in den einzelnen Ländern genügend Zeit und Ressourcen für die Vorbereitung und Durchführung der Anwendertrainings in der jeweiligen Landessprache zur Verfügung stehen, was entscheidend zur Akzeptanz beiträgt.
• Die Kosten und der Aufwand zum Aufbau der späteren operativen Services (Kalkulation der Service-Kosten, Aufnahme in den Servicekatalog, Berücksichtigung der Kosten in das Fachbereichsbudget, Einweisung des Help Desks, Bereitstellung der benötigten Experten im Fehlerfall, usw.) werden nicht oder nur unzureichend berücksichtigt.

Lösungsansatz: Produktorientierte Planung

Um alle Projektmanagementaktivitäten der Abteilung Information Management (IM) bei Airbus Defence & Space umfassender zu koordinieren und im Sinne eines kontinuierlichen Verbesserungsprozesse zu optimieren ist ein eigenes PMO (IM PMO) installiert worden, das hinsichtlich Kosten, Termine und Ergebnisse für alle Projekte des Bereiches IM (Information Management) verantwortlich ist und auch die Projektmanager disziplinarisch führt. Das IM PMO verfügt über ca. 35 Projektleiter. Die Projekte werden über einen definierten Projektportfolioprozess (s.u.) beantragt und gestartet.

Bei der Analyse erkannte ich, dass genau durch diesen Prozess die Projektleiter einem hohen Erwartungsdruck durch die Auftraggeber ausgesetzt sind, vor allem dann, wenn sie unvorbereitet ein sofort umzusetzendes Projekt übernehmen sollen. Die Position der Auftraggeber lässt sich pointiert so formulieren: "Was diskutiert ihr noch lange herum, die Software ist doch bereits gekauft! Macht doch endlich vorwärts, damit wir mit unserer Anwendung arbeiten können!“

In der Folge konzentrierten sich die Projektleiter in bestimmten Fällen darauf, wie sie die unmittelbaren technischen Aspekte umsetzen konnten. Bei der Planung stand die Work Breakdown Structure (WBS) mit ihren Arbeitspaketen, also die Umsetzungsbausteine, im Mittelpunkt. Dabei vergaßen sie teilweise, die Gesamtheit aller Lieferbausteine vorher zusammen zu tragen und mit dem Kunden klar und einvernehmlich abzustimmen.

Den Lösungsansatz für dieses Dilemma fand ich in der produktbasierten Planungsmethode des britischen Projektmanagementsystems PRINCE2® (OGC, 2009). Angeregt durch den Artikel "Produktbasierte Planung nach PRINCE2" im Projekt Magazin (Angermeier, Projekt Magazin 4/2012 und 5/2012) entwickelte ich eine standardisierte Struktur für die Liefergegenstände eines IT-Projektes und führte sie beim IM PMO ein.

Produktstruktur eines IT-Projekts

Im Folgenden beschreibe ich eine systematische und strukturierte Vorgehensweise beim Projektinhaltsmanagement (im Folgenden "Scope-Management"), die ich bei IT-Projekten erfolgreich eingesetzt habe, um die oben beschriebenen Störungen im Projekt zu verhindern oder zumindest weitestgehend zu vermindern.

Ein IT-Projekt hat typischerweise die folgenden Ergebnis-Komponenten: