Project Management Offices (PMO) liegen derzeit voll im Trend. Denn für Organisationen, die eine Vielzahl an Projekten zu bewältigen haben, gibt es einige gute Gründe, ein PMO aufzubauen. Welche Gründe das sein können und wie der Aufbau bzw. die Einführung eines PMO aussehen kann, zeigt dieser Erfahrungsbericht. Der Beitrag behandelt die Einführung eines PMO in der zentralen IT der Divisionen "Rail Systems" sowie "Mobility & Logistics" (IC RL/MOL IT) der Siemens AG.

Vornehmlich richtet sich der Beitrag an Manager bzw. Verantwortliche von Organisationen mit einem hohen Volumen an Projekten und kann als Hilfestellung für den Aufbau eines PMO dienen. Zudem soll der Artikel Anregungen und Empfehlungen geben, wie sich ein solcher Aufbau gestalten lässt.

Die Organisation der IC RL/MOL IT

Für ein Grundverständnis der IT-Organisationsstruktur und zur Einordnung der Bedarfe an das Projektmanagement, sollen hier zu Beginn einige Eckdaten genannt werden. Bei der IC RL/MOL IT handelt es sich um eine Stabsstelle mit rund 250 Mitarbeitern an sieben Standorten in Deutschland. Die Abteilung übernimmt Aufgaben des Demand-, Applikations- und Infrastrukturmanagements, der kaufmännischen Betreuung sowie diverse Querschnittsfunktionen. Zu diesen Querschnittsfunktionen zählen Leistungen wie die Strukturierung und Verwaltung von Unterschriftsberechtigungen, Arbeitssicherheitsschulungen und Audits für die Divisionen, aber auch die IT-Kommunikation sowie das IT-Projektmanagement.

Der Auftrag der IC RL/MOL IT ist es, den Betrieb aufrecht zu erhalten und weltweit den beiden Divisionen "Rail Systems" und "Mobility & Logistics" die notwendige Systemlandschaft zur Verfügung zu stellen, um Kundenaufträge abzuwickeln. Darüber hinaus führt die Abteilung notwendige Veränderungen bzw. Innovationen durch. So ergeben sich neue Anforderungen (Demands) aufgrund geänderter rechtlicher Vorgaben, Releasewechsel und Systemneueinführungen bzw. -ablösungen sowie neuer Business-Anforderungen. Diese Demands teilen sich auf in kleine Themen, die im laufenden Tagesgeschäft und in größere Vorhaben, die – je nach Aufwand – als Change Requests bzw. Projekte umgesetzt werden. Daraus ergeben sich ca. 40 bis 60 Projekte pro Jahr mit einem Volumen von ca. zehn Millionen Euro, das sich hauptsächlich aus Personalleistungen zusammensetzt.

Ausgangslage und Bedarf

Innerhalb der Siemens AG gibt es (seit nunmehr zehn Jahren) Vorgaben zur Projektabwicklung – jedoch haben diese ihren Schwerpunkt auf den Kundenprojekten. Vorgaben für die interne Projektabwicklung und die Ausbildung interner Projektleiter waren bisher kaum gegeben, sodass eigene Strukturen bis zu einer einheitlichen Regelung geschaffen werden mussten.

Bereits im Jahr 2004 existierte für die damalige IT-Abteilung eine Richtlinie zur Abwicklung von IT-Projekten. Schwerpunkte darin waren die Festlegung von Projektrollen, Elemente zur Planung und Steuerung sowie die Darstellung des Meilensteinprozesses sowie der Projektkategorien. Die Einhaltung wurde aber nicht ausreichend forciert und den betroffenen Mitarbeitern die Methodik nicht aktiv "nähergebracht"; d.h., eine strukturierte, einheitliche und qualitative Vorgehensweise war nur sehr begrenzt vorhanden.

Bis 2007 war die Projektabwicklung innerhalb der IT-Abteilung geprägt durch Ad-hoc-Benennungen interner Mitarbeiter zum Projektleiter. So wurden Fachexperten der IT zum Projektleiter ernannt, selbst wenn die Fähigkeiten dazu gar nicht oder nur kaum vorhanden waren. Eine Unterstützung durch Coaches oder Schulungsmaßnahmen erfolgte nicht. Darüber hinaus wurden, um die Fachabteilungen zu entlasten, auch vermehrt externe Berater als Projektleiter eingesetzt, die zwar die grundsätzliche PM-Methodik beherrschten, jedoch nicht die Organisation oder das Vorgehensmodell zur IT-Projektabwicklung kannten.

Kein wachsendes PM-Know-how

Ergebnis daraus war, dass jeder Fachexperte sich aufs Neue in die Projektarbeit einarbeiten musste und bei Einsatz von Externen das in den Projekten gewonnene PM-Know-how nicht in der Abteilung gehalten werden konnte. Die Lernkurve zum Thema Projektmanagement wurde folglich immer wieder individuell durchlaufen, ohne eine für die gesamte Organisation substantielle Weiterentwicklung zu erreichen. So wurden Projektdokumentationen immer wieder neu erstellt, die Projektablage war willkürlich aufgebaut, ebenso die Projektberichterstattung. Das Management erhielt für jedes Projekt individuelle und nicht vergleichbare Unterlagen.

Außerdem existierten keine einheitlichen Projektprozesse, wie z.B. eindeutige Entscheidungswege und ein systematisches Projektreporting. Die individuelle Handhabung führte zu großen Abstimmungsaufwänden und es gab keinen geordneten Überblick über die Gesamtheit der aktuell anstehenden bzw. laufenden Projekte. Bei Anfragen aus dem übergeordneten Sektor, dem die beiden Divisionen angehören, oder der zentralen IT-Abteilung von Siemens mussten die Daten in den einzelnen Projektablagen gesucht oder alle Projektleiter abgefragt werden, was einen immensen…