PMO Teil 3 - (7)

Merkert Consulting 

Program Management Office 

Das moderne PMO 

Seite 1

Inhalt 

1. Ausgangslage 

2. Das moderne PMO 

3. Aufgaben eines PMO 

4. Positionierung des PMO im Unternehmen 

5. Planung 

6. Konzeption 

7. Implementierung zentraler Prozesse 

8. Test des PMO und Nachjustierung 

9. Pilotierung - Einführung - Betrieb 

10. Praktische Anwendung eines digitalen PMO (Mehrprojektumgebung) 

Seminar: PMO - Program Management Office © Uwe Merkert 

Seite 2


Kapitel 07 

Hier werden die typischen Prozesse beschrieben, die ein PMO unterstützt: 

• beginnend von der Projektidee, über alle typischen Projektphasen bis zur 

Abnahme von Ergebnissen 


Seite 3



Dieses Kapitel stellt wichtige Prozesse vor, die vom PMO grundsätzlich beherrscht 

und bei Bedarf unterstützt werden müssen. In vielen Unternehmen 

unterschiedlicher Größe sind verschiedene Prozesse eingeführt, die in etwa den 

nachfolgenden ähneln. In zahlreichen Unternehmen ist die Entwicklung von 

praxisorientierten Prozessen allerdings noch ganz am Anfang. 

Nachfolgend werden typische Prozesse vorgestellt, die sich bereits bewährt haben, 

und grundsätzlich in jeder Organisation, die Projekte erfolgreich umsetzen muss, 

eingeführt werden sollten. 


Seite 4



Ein weiteres Ziel dieses Kapitels ist, schlanke und zielführende Prozesse 

darzustellen, die einfach und schnell für aktuelle Projekte anzuwenden sind, damit 

Projektleitungen und PMOs sofort einsetzbare Werkzeuge zur Verfügung haben. 


Seite 5


Und: Die Einführung und Einhaltung der nachfolgend beschriebenen Prozesse im 

Unternehmen sind geeignet, den Reifegrad der Organisation im Sinne einer 

IT Governance deutlich zu erhöhen. 

Gestaltung eines Prozesses: 

• Ziel des Prozesses 

• Prozess-Owner 

• Zielgruppe des Prozesses 


Seite 6


Projektidee (Initiative): 

Neue Projektideen, auch Initiativen genannt, werden von der designierten 

Projektleitung bearbeitet und so bearbeitet, dass eine fertige Projektidee einem 

Gremium vorgestellt werden kann, mit der Bitte um Genehmigung zur Umsetzung. 

Wichtig ist hier, den Business Case und somit die wirtschaftliche Sinnhaftigkeit 

der Projektidee für das Unternehmen überzeugend darzustellen. 

Nur so hat die Projektidee eine Chance auf die Bewilligung eines Budgets. 


Seite 7


Geplante Projekte: 

Hier werden vormals Projektideen, die zur Umsetzung genehmigt wurden, im 

Detail ausgeplant. 

Die Ausplanung eines geplanten Projekts wird in der Regel vom designierten 

Projektleiter vorgenommen. Hier wird bereits eine (geplante) Projektstruktur 

und ein erster Grobplan durchgeführt. Insbesondere wichtige Untersuchungen 

(z. B. IT-Architektur, Sicherheit, Datenschutz, usw.) werden durchgeführt und zur 

Freigabe (Freigabeprozess) beantragt. 

Die Aufwände, die bei geplanten Projekten anfallen, werden bereits einer 

entsprechenden Projektkostenstelle zugeordnet. 


Seite 8


Aktive Projekte: 

Unter den aktiven Projekte zählen all diejenigen, die erfolgreich geplant wurden 

und alle erforderlichen Freigaben, die zur Aktivierung erforderlich sind, erhalten 

haben. 

Die Projektphasen: 

Innerhalb der aktiven Projekte werden die Projekte nochmals in Projektphasen 

aufgeteilt. Dies kann je nach Unternehmen und Branche auf unterschiedliche 

Weise erfolgen. 

Die Unterteilung aktiver Projekte in unterschiedliche Projektphasen berücksichtigt, 

dass Projekte erfahrungsgemäß am Anfang eines Projekts andere Aufgaben und 

Anforderungen erfüllen müssen, als zu späteren Zeitpunkten. 


Seite 9


Nachfolgend ein mögliches Beispiel für gängige Projektphasen: 

Projektphasen 

• Tailoring 

• Phasenergebnisse 

(Beispiel…) 


Seite 10


7.2 Prozess - Freigabeprozess 

Immer mehr Unternehmen haben bestimmte Freigaben vorgesehen, die ein 

Projekt durchlaufen muss, um zunächst einmal genehmigt und später weiter 

fortgeführt zu werden. 

Typische Freigaben sind: 

• Budget-Freigabe 

• IT/Architektur-Freigabe 

• Datenschutz-Freigabe 

• IT-Sicherheit 


Seite 11


7.3 Prozess - Reporting 

Das Berichtswesen (Reporting) in Projekten ist sehr vielfältig: 

Protokolle, Anträge, verschiedene Übersichten, u. a. zu offenen Punkten, Risiken 

und Change Requests, und natürlich der Statusbericht. 

In Projekten wird festgelegt, welcher Bericht für welche Zielgruppe erstellt wird, 

und zu welchen Zeitpunkten dies geschieht, z. B. wöchentlich, monatlich oder 

alle zwei Wochen. 


Seite 12


7.3.1 Status Feedback 

Das Feedback aus den Projekten meint insbesondere den Projektstatusbericht. 

Dabei sorgt das PMO unter anderem dafür, dass der Statusbericht zu festen 

vereinbarten Terminen bereitgestellt wird, und stellt die Aussage sicher: 

Welche Informationen müssen dargestellt sein, nach welchen Kriterien wird die 

Ampel im Projekt-Statusbericht ermittelt. 


Seite 13


Status Feedback 

Beispiel eines Statusbericht mit typischen 

Inhalten für ein Projekt. 

Wichtig: Sofern in der Organisation bereits eine 

Vorlage besteht, ist diese unbedingt zu 

berücksichtigen. 


Seite 14


7.3.2 Management Reporting 

Das Management Reporting unterstützt ausgewählte Berichte zu speziellen Sichten 

auf die Projektlandschaft, z. B. auf ein Projektprogramm. 

Typische Sichten sind z. B.: 

• Übersicht des Ampelstatus 

• Kosten 

• Risiken 

• Projektfortschritt in Prozent (FGR %) 

• Business Case 

• Strategiebeitrag der Projekte 


Seite 15


Management Reporting 

Beispiel eines Management Report (Summary) 

mit Inhalten über ein Projektprogramm. 

Typische Bestandteile: 

• Kopfdaten: 

Namen und Termine, 

Verantwortlichkeit, Ansprechpartner 

• Ampelstatus 

• Kosten 

• Meilensteine / Ergebnisse 

• Risiken 

• Maßnahmen 

• Planänderungen 

• nächste Ergebnisse 


Seite 16



Ein Summary (Zusammenfassung, Überblick) stellt in knapper Form wichtige 

Informationen über den Status eines Projektprogramms (oder eines einzelnen 

Projekts) dar. 

Zielgruppe für diesen Bericht ist immer auch das Management. 


Seite 17



Übersicht des Ampelstatus aller Projekte 

des Programms. 

Verteilung der Kosten auf die Projekte 

eines Programms. 


Seite 18



Wie weit sind die einzelnen Projekte 

fortgeschritten in Prozent? 

(Fertigstellungsgrad, Projektfortschritt %) 

7.3.3 Erweitertes Berichtswesen 

Das erweiterte Berichtswesen umfasst Auswertungen, die sich speziell auf das jeweilige 

Umfeld der Projekte beziehen und sind entsprechend von den Anforderungen des 

Unternehmens geprägt. 

Hierzu zählen u. a. Sichten über verschiedene Standorte, Marken oder Sparten. 


Seite 19


7.4 Prozess - Qualitäts-Management 

Bei der Projektplanung müssen die messbaren Ziele des Projekts festgelegt 

werden. Dabei werden alle relevanten messbaren Ziele in Gruppen unterteilt, z. B. 

für Performance, Sicherheit oder Bedienungsfreundlichkeit. 

Qualitätssicherung: 

Die Qualitätssicherung beschreibt den QS-Konfigurations-Management-Plan und 

die messbaren Ziele. 

Im QS-Konfigurations-Management-Plan sind u. a. die Speicherorte und -Formate 

des QM-Prozesses, des Testverfahrens und der Testergebnisse festgelegt. 

Auch die Rollen zur Qualitätssicherung und der Testdurchführung. 


Seite 20


Beispiel: Auszug aus der Liste der messbaren Ergebnisse 


Seite 21


Testverfahren: 

Das Testverfahren, der Testplan und die Testfälle orientieren sich am Projektplan 

und umfassen die geplanten Testtermine, die zu testenden Gegenstände, die 

Testfälle und den Status. 

Teil-Abnahmen: 

Im Projekt sind evtl. Teil-Abnahmen vorgesehen, z. B. für einzelne Schnittstellen 

oder Bauabschnitte. 

Zusätzlich können Teil-Abnahmen für ausgewählte Ergebnisse und zu jedem 

Meilenstein vereinbart, durchgeführt und dokumentiert werden. 


Seite 22


Abnahme: 

Die Projekt-Abnahme erfolgt in Form einer Teil- und Gesamtabnahme. 

Der Ablauf einer Abnahme ist im Projektordner hinterlegt. 

Der Inhalt des Abnahmeberichts umfasst: 

• Angaben zum Auftrag 

• Angaben zum Test / zur Prüfung 

• Ergebnisse 

• Bemerkungen und Hinweise zu Dokumenten 

• Unterschriften Auftraggeber und Auftragnehmer 


Seite 23


7.5 Prozess - Projektergebnisse und Abnahmen 

Jedes Projekt muss bestimmte Ergebnisse erreichen, um den geplanten Aufwand 

und das geplante Budget zu rechtfertigen. Daher ist für ein neues Projekt klar 

festzulegen, was das Ziel des Projekts ist und welche eindeutigen Ergebnisse am 

Ende des Projekts erwartet werden. 

Oft wird mit einer Liste der Ergebnisse begonnen, die später um verschiedene 

Informationen ergänzt wird: u. a. um einen Bereitstellungstermin (Ende-Datum), 

Fortschrittsgrad oder Kennzeichen über eine Abnahme. 

Es ist möglich, die geplanten Ergebnisse zu Meilensteinen zuzuordnen. 


Seite 24


Projektergebnisse und Abnahmen 

Liste der Meilensteine: 


Seite 25


Meilensteine (sowie ihre geplanten Ergebnisse) können den zu durchlaufenden 

Projektphasen zugeordnet werden. 

Es geht darum, den Entwicklungsfortschritt von Projektergebnissen 

nachzuverfolgen und den geplanten Fertigstellungstermin (Bereitstellung) im Auge 

zu behalten. 

Beispiel: Projektphasen und erwartete Projekt-Ergebnisse: 

• Auftragsklärung: Anforderungs-Dokument (Lastenheft) 

• Fachkonzeption: Pflichtenheft 

• Systemrealisierung: Funktionsfähiger Pilot 

• Systemeinführung: Abgenommenes und produktiv eingesetztes System 


Seite 26


7.6 Prozess - Arbeitsaufwand 

Die Nachverfolgung der bisher geleisteten Arbeit im Projekt ist häufig eine der ganz 

großen Herausforderungen im Projektalltag: 

• Oft wird der Aufwand hierfür zu hoch eingeschätzt. 

• In der Regel muss der Arbeitsaufwand bereits mit hauseigenen Tools erfasst 

werden, daher wird häufig redundante Datenerfassung als Ablehnungsgrund 

angeführt. 

Aber wie kommt die Projektleitung an entsprechende Daten, um den geplanten 

Arbeitsaufwand nicht aus den Augen zu verlieren? 


Seite 27


In der Praxis haben sich Tabellen bewährt, die über einen bestimmten Zeitraum die 

Monatswerte des Arbeitsaufwands (bzw. des Stundenverbrauchs) aufnehmen. 

Beispiel: Projektaufwand vereinfacht als Monatswerte erfassen 


Seite 28


Der Sinn ist, für die Projektleitung schnell und ohne großen Widerstand den 

ungefähren Stundenverbrauch zu ermitteln. 

Wichtig: 

Anhand des Stundenverbrauchs ist auch ein Budgetverbrauch (Kosten) abzulesen, 

und zwar die variablen Kosten aus der Projektarbeit. 

Herausforderung: 

Häufig müssen einzelne Projektmitarbeiter in mehreren (verschiedenen) Projekten 

gleichzeitig unterstützen. 

Und dies nicht selten zu unterschiedlichen Stundensätzen bzw. Kostensätzen. Auch 

dies gilt es zu erfassen und zu berichten. 


Seite 29


7.7 Prozess - Kostenplanung 

Bereits am Anfang eines Projekts, in der Regel bereits während der Planungsphase 

für ein Projekt, müssen die erwarteten Kosten geplant und festgehalten werden. 

Dazu zählen die bekannten Kosten, z. B. bekannte Kosten für Ausstattung 

(Hardware und Software), für Lizenzen und ggf. für Support, durch das hausinterne 

Rechenzentrum und andere Instanzen. 

Auch geschätzte Kosten, z. B. mögliche Releases oder Schulungen, müssen 

vorausschauend geplant werden. 

Wichtig: 

Die Kostenplanung ist ein Bestandteil des Business Case und wird in vielen 

Unternehmen regelmäßig überprüft. 


Seite 30


Nachfolgend eine weit verbreitete und leicht handhabbare Kostenplanung in 

Tabellenform: 


Seite 31


7.8 Prozess - Change Management 

Im Laufe eines Projekts können veränderte Anforderungen entstehen, z.B. 

hervorgerufen durch neue Erkenntnisse oder durch geränderte 

Rahmenbedingungen, sodass eine Änderung in der Vorgehensweise oder in der 

Projektentwicklung entsteht: sogenannte Requests for Changes. 

Im Projektverlauf wird hierfür oft ein Change Control Board eingesetzt. 

Beispiel für einen Change Status: 

Tipp: Aus dem Change Status 

lässt sich in der Praxis ein 

kleiner Workflow ableiten. 


Seite 32


Schematischer Ablauf bei einem Änderungsantrag – Request for Change (RfC): 

(Beispiel…) 


Seite 33


7.9 Prozess - Risiko-Management 

Ein aussagefähiges Risikomanagement ist der Bestandteil in Projekten, um 

ausgewählten Stakeholdern (z. B. Steuerkreis, Sponsoren, Management) frühzeitig 

mögliche Gefahren für ein Projekt mitzuteilen und um rechtzeitig geeignete 

Abwehrmaßnahmen zu entwickeln oder einzuleiten. 

Oftmals ist das Risikomanagement in Projekten sehr schwerfällig (umständlich 

oder aufwändig) ausgelegt oder noch gar nicht in der Organisation angekommen. 

Nachfolgend ein Überblick zum Risikomanagement in Projekten. 


Seite 34


Risiko-Klassifizierung: 

A-Risiko = hohes Risiko 

- Eskalation mit Lösungsvorschlag an den Projektsteuerkreis 

B-Risiko = mittleres Risiko 

- Maßnahmendefinition im Projekt sowie im Management-Review 

C-Risiko = geringes Risiko 

- Nachverfolgung im Projektteam durch 

den jeweils Verantwortlichen 

oder durch die Projektleitung 

(Beispiel…) 


Seite 35


7.10 Prozess - Zusammenarbeit in Projekten - Collaboration 

Die Zusammenarbeit in Projekten erfordert abgestimmte und eindeutige Prozesse 

hinsichtlich des Berichtswesens und der Kommunikation. Hierzu zählen u. a. die 

Erstellung von regelmäßigen Statusberichten und die Erfassung der angefallenen 

Projektarbeitszeiten. 

Um dies zu erreichen, eignen sich besonders unternehmensweite 

Softwarelösungen, z. B. Client/Server-Anwendungen oder Cloud-basierte 

Lösungen. 

Die Praxis zeigt jedoch, dass dieses Ziel oft mit kleineren Mitteln erreicht werden 

muss. 


Seite 36


7.10.1 Verteiltes Statusfeedback 

Projektteams arbeiten oft unter verschiedenen Rahmenbedingungen, z. B. 

interne/externe Teilnehmer und von verschiedenen Standorten aus, für ein und 

dasselbe Projekt. 


Seite 37


Folgende kleinere Lösungen mit leicht verfügbaren Medien bieten sich für ein 

verteiltes Statusfeedback an: 

• Statusbericht mittels Tabellenkalkulation (Excel) 

• Statusbericht mit Einbeziehung der Cloud (SharePoint) 

• Statusbericht mittels E-Mail (Outlook) 

• Statusbericht mit einem Client im Rahmen einer C/S-Lösung 


Seite 38


Folgende Statusinformationen sind typischerweise erforderlich: 

Allgemeine Daten: 

• Projektname 

• Projektleitung 

• Berichtszeitraum 

Termine und Kosten: 

• Plan Kosten / Aktuelle Kosten / Prognostizierte Kosten 

• Plan Ende / Aktuelles Ende / Prognostiziertes Ende 


Seite 39


Ampelstatus: 

Ampel Gesamt ➔ Ampel Kosten 

➔ Ampel Termin 

➔ Ampel Umfang 

Qualität 

Tripple Constraint*: 

Kosten 

Umfang 

Qualität 

Termin 

*s. PMBOK des PMI 


Seite 40


Ergebnisse, Risiken und Maßnahmen: 

• Ergebnisse 

• Offene Punkte 

• Risiken 

• Maßnahmen 

• Planänderungen 

• Nächste Ergebnisse 


Seite 41


7.10.2 Organisationsdiagramm, Stakeholderanalyse, Rollen und Aufgaben: 

Organisationsdiagramm: 

Für eine geordnete Zusammenarbeit in einem Projekt ist es wichtig, die 

grundsätzliche Organisation für die Dauer des Projekts festzulegen. 

Daraus ergeben sich die zukünftigen Berichtswege und die ersten 

Verantwortlichkeiten im Projekt. 


Seite 42


Typische Beispiele für ein 

Organisationsdiagramm 

(Org. Chart) in Projekten. 

Alle wesentlichen Rollen 

werden aufgenommen. 

Auch Querschnittsfunktionen 

wie IT-Architektur, 

IT-Sicherheit (oder Datenschutz) 

und andere. 

Aufgabe: Ein Organisationsdiagramm gemeinsam 

erarbeiten 


Seite 43


Stakeholderanalyse: 

Im Projektmanagement gelten sowohl alle direkt Beteiligte als auch andere, 

in irgendeiner Weise vom aktuellen Projekt Betroffene, als Stakeholder. 

Wichtig: 

Die Stakeholderanalyse hat zum Ziel, alle Stakeholder mit hohem Konfliktpotenzial, 

insbesondere Influencer (mit ggf. großem Einfluss) und Blockierer, die ein Projekt 

zum Scheitern bringen können, frühzeitig zu erkennen und in die 

Kommunikationsplanung und Risikoplanung einzubeziehen. 

Die Ergebnisse der Stakeholderanalyse werden in einer Stakeholderliste 

festgehalten. 

(Beispiel…) 


Seite 44


Rollen und Aufgaben: 

Mit einem Konzept für Rollen und Aufgaben wird für die Dauer eines Projekts 

verbindlich festgelegt, durch welche Personen welche Rolle wahrgenommen wird 

und welche Aufgaben damit verbunden sind. 


Seite 45


7.11 Prozess - Tailoring von Projekten 

Unter Tailoring (Maßschneidern) von Projekten versteht man die Anpassung eines 

Vorgehensmodells an den tatsächlichen Projekt-Bedarf. Das ist besonders wichtig, 

da sich viele Projekte einer Organisation hinsichtlich ihrer Komplexität, ihres Inhalts 

und ihrer Ziele stark unterscheiden. 

Ein kurzes Projekt mit hartem Endtermin wird - um Erfolg zu haben - andere 

Maßstäbe an das Qualitätsmanagement anlegen, als ein Mehrjahresprojekt, 

dessen Produkt später die Sicherheit von Menschen garantieren soll. 

Ein im Unternehmen festgelegtes und gut implementiertes Tailoring von Projekten 

stellt einen wesentlichen Beitrag zur Standardisierung der Projektumsetzung und 

der Bewertung des Status im Management von Mehrprojektumgebungen dar. 

(Beispiel…) 


Seite 46


7.12 Prozess - Betriebsübergabe und Support 

Immer häufiger unterstützt ein PMO bereits in einer frühen Phase des Projekts die 

Planung und Überwachung der Anforderungen für eine spätere Übergabe des 

Projekts in ein lauffähiges System an den geregelten Betrieb (IT, Rechenzentrum, 

Support) eines Unternehmens. 

Auch die Betriebsübergabe ist im Rahmen eines Tailoring hinsichtlich der zu 

erfüllenden Anforderungen detailliert beschrieben. Hierzu kommen in der Praxis 

oftmals „Übergabe-Checklisten“ zum Einsatz. 

Wichtig: 

Erst durch die erfolgreiche Betriebsübergabe wird die Projektleitung endgültig 

entlastet. 


Seite 47


Zusammenfassung Kapitel 07 

Nachfolgend die Aspekte, die in diesem Kapitel behandelt wurden: 

• Gestaltung eines Prozesses (Ziel – Owner – Zielgruppe) 

• Projektphasen – Definition und Phasen-Inhalte 

• Identifizierung aller zentralen Prozesse 

• Messbare Projektergebnisse definieren 

• Tripple Constraint 

• Organigramm (Project Chart) 


Seite 48


Zusammenfassung Kapitel 07 

Fortsetzung: 

• Rollen und Aufgaben 

• Tailoring 


Seite 49


Ende Kapitel 07 


Seite 50

PMO Teil 3 - (7)

Verwandeln Sie Ihre PDFs in ePaper und steigern Sie Ihre Umsätze!

Template löschen?

Als Template speichern ?