Strategisches Projektmanagement || Zentralisierung

5Zentralisierung

Frederik Ahlemann, Fedi El Arbi, Kunal Mohan und Michael Kaiser

Inhaltsverzeichnis

5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.2 Elemente der Zentralisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.2.1 Etablierung eines Project Management Office (PMO) . . . . . . . . . . . . . . . . 885.2.2 Projektorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.2.3 Zentrales PM-Informationssystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1015.2.4 Zentralisierte Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1065.2.5 Zentrales Risikomanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1085.2.6 Zentrales Ressourcenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105.2.7 Zentrales Projektportfoliomanagement . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.3 Zusammenfassung & Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

5.1 Einleitung

Der Zentralisierung geht die im vorherigen Kapitel beschriebene Standardisierungsphasevoraus, in der auf einer Einzelprojektebene viele Projektmanagementpraktiken vereinheit-licht und harmonisiert wurden. Mit der Standardisierung werden bereits viele Problemegelöst, aber noch immer ergibt sich für Projektorganisationen eine Reihe von Herausfor-derungen. Zu diesen gehören:

Prof. Dr. F. Ahlemann (B) ⋅ F. El Arbi ⋅ Dr. K. Mohan ⋅ Dr. M. KaiserEBSUniversität fürWirtschaft und Recht, EBS Business School, Institute of Research on InformationSystems, Konrad-Adenauer-Ring 15, 65187 Wiesbadene-mail: [email protected]

87F. Ahlemann, C. Eckl (Hrsg.), Strategisches Projektmanagement,DOI 10.1007/978-3-642-34761-0_5, © Springer-Verlag Berlin Heidelberg 2013

mailto:[email protected]

88 F. Ahlemann, F. El Arbi, K. Mohan, M. Kaiser

Kein Überblick über die Projektlandschaft: Dem Management steht noch immer keingesamtheitlicher und umfassender Überblick über die Projektlandschaft zur Verfü-gung.

Ressourcenengpässe und -überlastungen: In Projekten kommt es häufig zu Kapazitäts-engpässen. Insbesondere knappe Ressourcen sind deutlich überlastet.

Geringe strategische Ausrichtung der Projekte: Die Projekte entsprechen vielfach nichtoder in nur geringem Maße den strategischen Zielen der Unternehmung. Hierzu zähltauch, dass insbesondere kleine Projekte ohneGenehmigung durchgeführt werden („U-Boot-Projekte“).

Die Zentralisierung adressiert diese Probleme mit zwei grundlegenden Ansätzen:

1. Es werden zentrale Organisationseinheiten und Gremien etabliert, die die Abwicklungaller Projekte überwachen und koordinieren.

2. Es werden einheitliche Prozesse für die Projektinitiierung und -auswahl definiert. Hier-bei handelt es sich um Prozesse, die dem Projektbeginn vorgelagert sind.

Mit diesen zwei Ansätzen entfaltet die Zentralisierungsphase ihre Wirkung. Zunächsteinmal sorgt sie für vollständige Transparenz über alle Projekte und ihren jeweiligen Pro-jektstatus. Dies ist nur deshalb möglich, weil in der Standardisierungsphase die Projektab-wicklung weitgehend vereinheitlicht wurde. Damit ist es auch möglich, einheitliche Infor-mationen über Projekte zu sammeln und auszuwerten. Die erhöhte Transparenz über dasProjektgeschehen ermöglicht fortgeschrittene Planungs- und Steuerungsaktivitäten auf derMultiprojekt- und Portfolioebene. Hierzu gehört beispielsweise eine zentralisierte Projekt-freigabe oder auch ein zentralisiertes Ressourcenmanagement. Diese Aktivitäten führenzu einem optimierten Ressourceneinsatz und damit zu einer erfolgreicheren Projektab-wicklung. Weitere positive Effekte der Zentralisierung sind eine höhere Flexibilität derGesamtorganisation und eine gesteigerte Planungssicherheit für alle Projektbeteiligten, danicht nur klar ist, welche Projekte zu einem Zeitpunkt in der Ausführung sind, sondernauch, welche Projekte in der Zukunft wann gestartet werden. Korrekturen der Multipro-jektplanung sind – sofern notwendig – vergleichsweise schnell zu realisieren, da derenKonsequenzen transparent gemacht werden können.

5.2 Elemente der Zentralisierung

5.2.1 Etablierung eines Project Management Office (PMO)

Die Projektzentralisierungsphase implementiert eine Reihe von regelmäßig stattfindendenPlanungs- und Koordinationsaktivitäten, die normalerweise von einer auf Dauer ange-legten Organisationseinheit wahrgenommen werden, so dass die notwenige Kontinuität

5 Zentralisierung 89

Basis für die Projektmanagement-Methoden schaffen

• Team für die Methoden-entwicklung bilden

• Strategie für die Metho-denentwicklungdefinieren

• Vorhandene Praktiken erfassen

Methodenentwurf

• Komponenten der Methode identifizieren

• Lebenszyklusprozess entwickeln

• Projektmanagement-Praktiken entwickeln

• (IT-)Plattform für die Benutzung der Methoden einführen

Implementierung der Methoden

• Implementierung der Methoden planen

• Übergangsphase planen

• Methoden umsetzen• Training veranstalten

Methodenverwaltung

• Implementierung der Methoden bewerten

• Performanz der Methoden analysieren

• Methoden pflegen und nachbessern

Abb. 5.1 Methodenmanagement [1]

im Multiprojektmanagement gegeben ist. Diese zentrale Organisationseinheit wird übli-cherweise als Project Management Office (PMO) bezeichnet.1 Das PMO übernimmt dieVerwaltung des Projektportfolios und steuert die zugehörigen Prozesse. Wesentliche pro-jektbezogene Entscheidungen werden jedoch meist weiterhin durch entsprechende Gre-mien getroffen. Weiterhin kann das PMO eine Reihe zusätzlicher Aufgaben übernehmen,z. B. (siehe auch die detaillierte Darstellung in Tab. 5.1):

Informationsmanagement: Zu den grundlegenden Aufgaben des PMO gehört das Sam-meln, Erfassen und Aufbereiten projektrelevanter Informationen. Dies erfolgt in derRegel mit Hilfe einer Projektmanagement-Software, die vom PMO auch fachlich be-treut wird.

Berichtswesen: Die Etablierung und der Betrieb eines projektbezogenen Berichtswesenszählen ebenso zu den Aufgaben eines PMO.

Ressourcenmanagement: Dieses umfasst die Verwaltung von Ressourcenpools sowie dieZuweisung von Ressourcen zu Projekten. Während in der Standardisierungsphase vorallemdas Ressourcenmanagement innerhalb eines Projektes vereinheitlichtwurde, gehtes nun um projektübergreifendes Ressourcenmanagement.

Risikomanagement: Das PMO kann die Risiken einzelner Projekte bewerten und das Ge-samtrisiko des Projektportfolios analysieren.

Projektinitiierung: Im Rahmen der Projektinitiierung werden Projektideen gesammelt,geprüft und bewertet, bevor final über sie entschieden wird.

Portfoliomanagement: Das PMO koordiniert häufig die Prozesse der Projektpriorisie-rung und -budgetierung. Darüber hinaus wird das Portfolio fortlaufend überwacht.

Zusätzlich fallen Tätigkeiten an, die der Entwicklung und Verbreitung des Projektma-nagements in der Organisation dienen. Dazu gehören:

1 Wir verwenden hier den englischen Begriff, weil er sich im deutschen Sprachraum durchgesetzthat.


Tab. 5.1 Tätigkeiten des PMO

Aufgabe Beschreibung Anwendung BeispielProzess-management

Prozessmanagementbeschäftigt sich mitder Identifikation,dem Entwurf, derImplementierung, Do-kumentation, Steuerungund Verbesserung vonGeschäftsprozessen(unter anderem vonProjektmanagement-Prozessen).

• Identifikation derbestehenden Pro-jektmanagement-Prozesse

• Implementierungneuer Projektmanage-ment-Prozesse

• Optimierung derbestehenden Prozesse

Definition eines Vorge-hensmodells für Projekte(siehe Kap. 4)

Methoden-management

ZumMethodenmana-gement gehören dieErfassung bestehender,Implementierung neuerund fortlaufende Op-timierung bestehenderMethoden. Prozess-management kann alsTeildisziplin des Me-thodenmanagementsgesehen werden.

• Verfassung eines Pro-jektmanagement-Handbuches

• Definition neuer Pro-jektmanagement-Methoden

• Nachbesserungexistierender Pro-jektmanagement-Methoden

Einführung neuerKostenmanagement-Methoden

Training Training umfasst al-le Maßnahmen für dieKompetenzentwicklungder Mitarbeiter.

• Schulungen für dieProjektstakeholderund Vermittlungneuer Projektma-nagement-Methoden

• Entwicklung vonKompetenzentwick-lungsplänen

Schulung der Pro-jektmanager imKostenmanagement (sie-he Kap. 6)

Reifegrad-messung

Bei der Reifegradmes-sung werden vorhandenePraktiken sowie derenNutzung erfasst und sodie Reife der Organisati-on bewertet.

• Erfassung der Pro-jektmanagement-Methoden, Abläufeund Praktiken

• Ermittlung des Rei-fegrades anhand vonbestimmten Kriterien

Messung des Reifegradesdes Projektmanage-ments nach CMMI (sieheKap. 6)

Projektma-nagement-Software(PMS)a

PMS-Systeme sindIT-Systeme, die dieAnwender beim Pro-jektmanagementunterstützen.

• Auswahl der PMS• Einführung der PMS• Fachliche Weiterent-

wicklung der PMS• Unterstützung der

Benutzer

Auswahl einer geeignetenPMS für das Portfolioma-nagement

a Zur Einführung einer Projektmanagement-Software siehe Fallbeispiel im Abschn. 5.2.3


Tab. 5.1 Fortsetzung

Aufgabe Beschreibung Anwendung BeispielProjektaudits Im Rahmen von Pro-

jektaudits werdendie Projekte auf ihreKonformität mit denProjektmanagement-Richtlinien und auf dieValidität der Statusbe-richte hin geprüft.

• Projektauditorenausbilden

• Auditprozess definie-ren

• Auditergebnisse do-kumentieren undkommunizieren

–

Projekt-management-Beratung

Projektmanagement-Beratungsleistungen (z.B.Unterstützung bei derProjektplanung) werdenangeboten.

• Definition eines Kom-petenzkataloges derPMO-Mitarbeiter

• Definition und Do-kumentation derBeratungsleistung

• Abwicklung der Bera-tungsdienstleistung

Unterstützung bei derPlanung eines Großpro-jektes

Modera-tion vonWorkshops/Besprechun-gen

Bei Projektmanagement-Workshops, den Treffender Lenkungsausschüs-se oder bei politischschwierigen Projekt-besprechungen kanndie Moderatorrolle vonPMO-Mitarbeitern über-nommen werden.

• Teilnahme an Mode-rationsschulungen

• Eskalation vonKommunikations-problemen

• Durchführung vonWorkshops und Be-sprechungen

–

Nutzen-management

Beim Nutzenmanage-ment geht es um diePlanung, Quantifizierungund Steuerung der Rea-lisierung des erwartetenNutzens eines Projektes.

• Nutzenidentifizierung• Nutzenoperationali-

sierung• Nutzenplanung• Nutzensteuerung

(siehe Kap. 6)

Planung des Nutzens derEinführung eines neuenIT-Systems

Projekt-controlling/Reporting

Hier geht es um dieSteuerung der Projekteund die Erstellung vonaggregierten Statusbe-richten.

• Statusberichte anfor-dern

• Statusberichte analy-sieren

• Aggregierte Berichteerstellen

• Bei Bedarf Problemeeskalieren

Erstellung eines Be-richts über die laufendenProjekte für das Topma-nagement



Aufgabe Beschreibung Anwendung BeispielPortfolioma-nagement

Projektportfolioma-nagement ist eineMultiprojektmanage-ment-Methode, die dieAuswahl und Steuerungmehrerer Projekte um-fasst.

• Projektauswahl-kriterien definieren

• Projekte priorisieren• Projektportfolio

planen• Projektportfolio

steuern• Portfolioberichte

erstellen• Projektportfolio

optimieren

–

Coaching/Mentoring

Bei Coaching/Mentoringgeht es um die Begleitungder Mitarbeiter mit demZiel der Verbesserung dereigenen Kompetenzen.

• Coaching-Program-me definieren

• Mentoren/Coachesbenennen

• Mentoren/Coachesausbilden

• Periodische Coa-ching-Termineanbieten

Erfahrene Projektmana-ger als Mentoren für neueProjektmanager.

Lieferanten-management

Lieferantenmanagementist die systematische Pla-nung und Steuerung derGeschäftsbeziehung zuden Lieferanten.

• Projektlieferanten-portfolio definieren

• Persönliche Kontaktemit den strategischenLieferanten pflegen

• Leistungen der Liefe-ranten bewerten

Bewertung der Qualitätder gelieferten Rohstoffefür ein Bauprojekt

Vertrags- undNachforde-rungsmanage-ment

Bei diesen Praktiken wirdermittelt, ob die Pro-jektergebnisse mit denvertraglich festgelegtenVereinbarungen überein-stimmen.

• Mapping zwischenVerträgen und Pro-jektplänen

• Erstellung einesClaim-Plans

• Claim-Steuerung

Definition von Termi-nen und Fristen für dieLieferung der Projek-tergebnisse und vonVertragsstrafen beiAbweichung von Ver-tragsvereinbarungen

Risikomana-gement

Risikomanagement be-schäftigt sich mit derErmittlung und Steue-rung der Projektrisiken.

• Projektrisikoermitteln

• Projektrisikoevaluieren

• Projektrisikoanalysieren

• Portfoliorisikoermitteln

• Steuerung der Reakti-on auf Risiken

Analyse der Risiken dereigenen Entwicklung ei-ner Projektmanagement-Software



Aufgabe Beschreibung Anwendung BeispielRessourcen-management

Ressourcenmanagementumfasst die Prozessefür die Organisation,Steuerung und Führungder Projektressourcen.

• Verwaltung von Res-sourcenpools

• Zuweisung von Res-sourcen zu Projekten

Vergabe von knappenRessourcen gemäß derProjektpriorisierung

Methodenmanagement: Hierzu zählen die Konzeption der Projektmanagement-Metho-dik, die Implementierung der Methodik, die Überwachung ihrer Anwendung sowieihre kontinuierliche Verbesserung (siehe Abb. 5.1).

Projektmanagement-Beratung: Das PMO kann bei Bedarf Organisationseinheiten odereinzelne Personen bzgl. der Anwendung des Projektmanagements beraten. Die Bera-tung kann insbesondere dann erforderlich sein, wenn ein Projekt großen Risiken aus-gesetzt ist oder aber in eine Schieflage gerät.

Projektmanagement-Ausbildung: Eine weitere sehr wichtige Aufgabe stellt das Trainingder Projektmanagement-Anwender dar. Hier geht es darum, allgemeine Kompetenz,aber auch Kenntnisse bzgl. der spezifischen Projektmanagement-Standards der Orga-nisation zu vermitteln.

Bei der Ausgestaltung der Aufgaben eines PMO gibt es in der Praxis erhebliche Unter-schiede, die sich aus den diversen Erfordernissen verschiedener Projekttypen, Branchen,Reifegrade und methodischer Schwerpunkte ergeben. Tabelle 5.1 zeigt detailliert die viel-fältigen Aufgaben eines PMO und erläutert, wann diese wahrgenommen werden.

Fallbeispiel: PMO bei einemUS-amerikanischen FinanzdienstleisterIn diesem Fallbeispiel wird die Einführung eines PMO bei der American Eagle FederalCredit Union (AEFCU), einem US-amerikanischen Finanzdienstleister, behandelt [2].Die AEFCU hatte 2004 einen Umsatz von $ 800Millionen und beschäftigte ca. 220Mit-arbeiter. Zu ihren strategischen Zielen gehörte es, einen Umsatz von einer MilliardeDollar innerhalb von 5 Jahren zu erreichen. Um dieses Ziel zu erreichen, wurde eineReihe vonWachstumsprojekten gestartet. Nach dem ersten Statusreview dieser Projek-te wurde der AEFCU klar, dass ihre strategischen Ziele aufgrund von Abweichungenvon den Projektplänen gefährdet waren. Der Review hat aufgedeckt, dass die Projektezwei oder drei Mal länger dauern würden und 50 bis 300% mehr Budget als geplanterforderlich sein würde. Die Ressourcenallokation war ineffizient. Außerdem war dieQualität der Projektergebnisse mangelhaft. Als Antwort auf diese Probleme entschiedsich die AEFCU dazu, ein PMO zu etablieren. Für die Implementierung des PMO wur-de ein Business-Case erstellt. Dadurch wurde bewiesen, dass die Betriebskosten desPMO niedriger sein würden als die Kosten für ineffizientes Projektmanagement (z. B.


Terminverzüge, ineffiziente Ressourcenvergabe, falsche Projektpriorisierung, operativeEinbindung des Topmanagements).

In der Einführungsphase wurde das PMO mit einem Direktor und einem Assisten-ten besetzt. Da die Projektmanagement-Fähigkeiten der internen Mitarbeiter sich alsmangelhaft erwiesen, wurden zertifizierte Projektmanager eingestellt. Weiterhin war esAufgabe des PMO, neue Methoden zu entwickeln und diese organisationsweit zu im-plementieren. Diese Methoden werden bis heute im Rahmen eines jährlichen Prozessesunter der Leitung des PMO weiterentwickelt. Es wurden weiterhin Metriken für dieMessung der strategischen Relevanz der Projekte und des Projekterfolges etabliert. DasPMO war ebenfalls in die Portfolioplanung einbezogen und hatte die Aufgabe, Projek-tideen zu sammeln und zu bewerten. Das war sinnvoll, da das PMO keinen Nutzen ausder Projektauswahl ziehen konnte und Projektideen deshalb weitestgehend neutral be-wertete.Diese Bewertung diente dann als Entscheidungsgrundlage zur Projektportfolio-freigabe durch dieGeschäftsführung.Zu denAufgaben des PMOgehörten desWeiterendie projektübergreifende Planung von Ressourcen und die Auflösung von Ressourcen-konflikten in Koordination mit den Linieneinheiten. Das PMO berichtete wöchentlichüben den Status der laufenden Projekte an den CEO.

Die Implementierung des PMO hat zu einer signifikanten Verbesserung der Projek-tergebnisse geführt. 2009 waren 95% der Projekte erfolgreich und die Ressourcenpla-nung wurde in der Organisation als effizient empfunden.

Fallbeispiel: PMO bei einem BaudienstleisterDas in diesem Beispiel behandelte Unternehmen ist ein Baudienstleistungsunterneh-men mit ca. 70 000 Mitarbeitern. Das PMO hat in diesem Unternehmen neben denklassischen Projektportfoliomanagement-Aufgaben (z. B. Risikoanalyse und Projekt-steuerung) eine beratende Rolle für die Projektteams inne, so dass die technischen,methodischen und vor allem die Kommunikationskompetenzen der PMO-Mitarbeitereine besonders wichtige Rolle spielen. Im Rahmen von Trainingsprogrammen wer-den den PMO-Mitarbeitern entsprechende Fähigkeiten vermittelt und diese beständigausgebaut.

Das PMO bietet Beratungsleistungen für die Projektanalyse, Projektangebotserstel-lung, Projektplanung und Projektdurchführung. Der Beratungsansatz des PMO wirdan die Besonderheiten des Projektteams angepasst. Je nach Erfahrung und Affinität desProjektteams für Beratungsleistungen entscheiden sich die PMO-Berater für das ge-eignete Vorgehen. PMO-Berater betreuen in der Regel mehrere Projekte und werdenvon den Projektteams gut akzeptiert. Eine besondere Herausforderung besteht aller-dings darin, dass das PMO neben seiner Beraterrolle auch als Steuerungsorgan wirktund Aufgaben wie das Projektportfoliomanagement durchführen muss. Das kann zuInteressenskonflikten führen, da Steuerungs- und Beratungsaufgaben unterschiedlicheZielsetzungen verfolgen.


Aufgrundder hohenKompetenz der PMO-Mitarbeiterwerden die PMO-Beratungs-dienstleitungen auch von externen Organisationen in Anspruch genommen. In demFall werden die PMO-Mitarbeiter als externe Berater eingesetzt. Das sichert dem Un-ternehmen zusätzliche Erlöse und sorgt für die Diversifizierung des Firmenportfolios.Das PMO wird aufgrund seiner Projekterfahrung auch in die Akquise von Kundenpro-jekten eingebunden. Außerdem beaufsichtigt das PMO das Projektwissensmanagementund übernimmt die Rolle eines Kompetenzzentrums für Projektmanagement-Software.

Im Rahmen unserer Studie haben wir eine Reihe von Faktoren identifiziert, die PMOsschlagkräftig und erfolgreich machen. Eine Grundvoraussetzung hierfür ist, dass das PMOnicht allein als administrativer Verwalter eines Projektportfolios begriffen wird, sondernEigentümer des gesamten Projektprozesses von der Idee bis zur Nutzenrealisierung ist. Dasimpliziert, dass das PMO stark in den strategischen Planungs- und Steuerungsprozess ein-gebunden ist. Eine solche Einbindung ist jedoch nur dann erfolgreich, wenn das PMO alsStabsstelle zur Unternehmens- oder Bereichsleitung installiert ist. Gute PMOs erforderndarüber hinaus Mitarbeiter, die über ausgiebige Erfahrungen in der Projektabwicklungverfügen und sich damit vor ihren Projektleiterkollegen legitimieren können. Bei der Ein-führung eines PMOs ist weiterhin darauf zu achten, dass nicht alle Aufgaben gleichzeitigübertragen werden. Es ist empfehlenswert, sich zunächst auf „Quick-Wins“ zu konzen-trieren, d. h. auf diejenigen Aufgaben, die schnell einen signifikanten Nutzen erzielen. Dassorgt für Rückenwind und zerstreut Bedenken bezüglich dieser neuen Organisationsein-heit.

5.2.2 Projektorganisation

Bereits im Rahmen der Standardisierungsphase wurde die Projektabwicklung vereinheit-licht. Unweigerlich gehört hierzu auch die Definition von Rollen, die festlegen, wer wel-che Projektaufgaben wahrnehmen sollte. In der Zentralisierungsphase wird dieses auf dieEinzelprojektabwicklung beschränkte Rollenmodell zu einem umfassenden Projektorgani-sationsmodell erweitert, das auch Gremien festlegt, die für das Multiprojektmanagementerforderlich sind. Eine solche klar definierte Projektorganisation hat verschiedene Vorteile:Aufgaben sind klar verteilt, Verantwortlichkeiten geregelt, Entscheidungen werden nach-vollziehbar getroffen und es kommt zu einer höheren Verlässlichkeit im Projektgeschehen.Damit bildet eine klar definierte Projektorganisation auch die Grundlage für die prozes-suale Gestaltung des Projektmanagements. In der Tab. 5.2 sind typische Rollen, Gremienund Einheiten einer Multiprojekt- oder Projektportfolioorganisation dargestellt. Welchesdieser organisatorischen Elemente benötigt wird, hängt – wie so oft – von verschiedenenKontextfaktoren wie dem Projekttyp oder der Branche ab (Tab. 5.3).

Ein zentrales Element der Multiprojektorganisation ist die Einplanung von Eskalati-onswegen, die dazu dienen, im Falle von Konflikten oder umfassenden Projektänderun-


Tab.

5.2

Exem

plarischeRo

llenun

dGremienin

einerM

ultip

rojektum

gebu

ng

Bezeichn

ung

Rolle/

Gre-

mium

(R/G

)

Beschreibu

ngBe

richtsweg

notwendige

Qualifi

katio

n

Projekt-

spon

sor/

Kun

de

RDer

Projektspo

nsor

(oderd

erKun

debeiexternenProjekten)

istderP

rojekt-

auftraggeber.Er

liefertdiefin

anziellen

Einsatzm

ittelfürd

asProjekt.

Der

Projektspo

nsor

beiinternenPro-

jekten

istin

derR

egelMitg

lieddes

Projektlenk

ungsausschussesu

nderhält

dieStatusberichtevom

Projektleiter.

Ermussg

gf.überd

enNutzenreali-

sierung

sgraddesP

rojektes

anseine

Führun

gskräft

eberichten(siehe

Kap.6).Der

externeProjektkun

deerhältStatusberichtevonderP

erson,

diefürd

ieKun

denb

eziehu

ngzustän-

digist

(z.B.Projektleiter,Key

Accou

ntManager)

Der

Projektspo

nsor

undderK

unde

müssenüb

ergrun

dlegende

Kenntnis-

seim

Projektm

anagem

entverfügen,

umihre

Rolle

profession

ellausüb

enzu

könn

en(siehe

Kap.6).Das

koop

e-rativ

eVe

rhaltendesP

rojektspon

sors

oder

Kun

denist

entscheidend

fürd

enProjekterfolg[3].

Projekt-

controller

RDieAufgabe

desP

rojektcontrollersist

dieProjektsteuerung

.Erm

ussregelmä-

ßigprüfen,obdieProjektkosten,

die

Projektdauer

unddieProjektqualität

dem

Projektplanun

ddenProjektanfor-

derungen

entsprechen.

Der

Projektcon

trollerk

annfüre

inod

ermehrereProjektezuständigsein.Steu-

ertd

erCon

trollern

ureinProjekt,kann

eralsT

eild

esProjektte

amsinstalliert

werden.

Der

Projektcon

trollerb

ekom

mt

regelm

äßigStatusberichtevom

Projekt-

manager.D

iese

Berichtesind

häufi

ger

unddetaillierter

alsd

ieBe

richtefür

denLenk

ungsausschuss.Be

iAbw

ei-

chun

genvondenProjektplänenod

erbeiP

roblem

en,diedenProjekterfolg

gefährden,

nutzen

dieProjektcon

troller

dieEskalatio

nswege.

Neben

denüb

lichenCon

trollin

g-Fähig-

keitenmussd

erProjektcon

trollerü

ber

guteKenntnisseinderP

rojektplanun

gverfügen,um

Projektpläne

zuverstehen

undggf.Problemezu

entdecken.


Tab.

5.2

Fortsetzun

g

Bezeichn

ung

Rolle/

Gre-

mium

(R/G

)

Beschreibu

ngBe

richtsweg

notwendige

Qualifi

katio

n

Claim

-Manager

RBe

imAuft

raggeber

sorgen

dieClaim

-Manager

dafür,dassdieVe

rtragsver-

einb

arun

generfüllt

werden.Hingegen

sind

dieClaim

-Manager

beim

Auft

rag-

nehm

erdafürv

erantwortlich,dassd

ieProjektpläne

denVe

rtragsmod

alitäten

entsprechen.

Claim

-Manager

berichtenan

den

Projektspo

nsor,den

Kun

denod

erdenLenk

ungsausschuss.Sign

ifikante

Abw

eichun

genvonvertraglichenVe

r-einb

arun

genwerdeneskaliert.

Claim

-Manager

müssennebenjuris-

tischen

Kenntnissen

über

fund

ierte

KenntnisseinderP

rojektplanun

gver-

fügen.

Qualitäts-

manager

RDer

Qualitätsm

anager

übernimmtd

ieQualitätsm

anagem

ent-Aufgabendes

Projektm

anagers.Er

überprüft

,obdie

Projektergebnissedere

rwartetenQuali-

tätentsprechen.

Der

Qualitätsm

anager

berichtetanden

Projektm

anager.

Der

Qualittätsmanager

mussü

berp

ro-

jektspezifische

Qualitätsm

anagem

ent-

Kenntnissev

erfügen(siehe

Kap.4).

Testmanager

RTestmanager

beschäftigensic

hmitder

Planun

gun

dSteuerun

gderT

estpro-

zesseinn

erhalbdesP

rojektes.D

iese

Rolle

istb

eson

dersfürS

oftware-

und

Prod

uktentwicklun

gsprojekterelevant.

Der

Testmanager

berichtetandenPro-

jekt-o

derQ

ualitätsm

anager.

FürT

estm

anager

gibes

verschiedene

Zertifizierun

gsprogrammewiez.B.

die

ISTQ

B-Ze

rtifizierun

g[4]für

Softw

are-

tester.


Tab.

5.2

Fortsetzun

g

Bezeichn

ung

Rolle/

Gre-

mium

(R/G

)

Beschreibu

ngBe

richtsweg

notwendige

Qualifi

katio

n

Projekt-

lenk

ungs-

ausschuss

GDer

Lenk

ungsausschussistdieob

ers-

teProjektin

stanz.Er

repräsentie

rtalle

wesentlichen

Stakeholdergrupp

eneines

Projektes,dientalsEskalatio

nsinstanz

undüb

erwacht

dieArbeitd

esProjekt-

managers.

ImNormalfallwerdenLenk

ungsaus-

schü

ssen

urfüre

inProjekteingerichtet.

Siekönn

enaber

auch

mehrere

Projekte

oder

sogare

invollständ

iges

Programm

bzw.

Projektportfo

lioüb

erwachen.

Der

Lenk

ungsausschusserhältSta-

tusberichtev

omProjektleiter.Be

igravierend

enProjektproblem

enwer-

dendieEskalatio

nswegegenu

tzt.

EinLenk

ungsausschussistobligato-

rischfürP

rojekteab

mittlererG

röße.E

rstelltsic

her,dassdiewichtigsten

Pro-

jektstakeholderü

berd

enProjektstatus

inform

iertsind

unddasP

rojekt

ange-

messenun

terstützen

[3].Mitg

lieder

desL

enku

ngsausschu

ssessollten

über

grun

dlegende

Projektm

anagem

ent-

Kenntnissev

erfügen(siehe

Kap.6)

Portfolio

-lenk

ungs-

ausschuss

GDer

Portfolio

lenk

ungsausschusse

nt-

scheidetüb

erdieProjektpriorisierun

gun

dsteuertd

asProjektportfo

lio.E

rist

besetztm

itFü

hrun

gskräft

en,die

entsprechend

eBud

getentscheidun

gen

treffen

könn

en.

Der

Portfolio

-Lenku

ngsausschu

ssem

pfängt

Statusberichtevom

Pro-

jektcontrollero

derd

emProject

Managem

entO

ffice.

Mitg

liederd

esPo

rtfolio

lenk

ungs-

ausschussesm

üssenüb

erfund

ierte

Kenntnisseim

Projektcon

trollin

gun

dstrategischenManagem

entverfügen.


Tab.

5.2

Fortsetzun

g

Bezeichn

ung

Rolle/

Gre-

mium

(R/G

)

Beschreibu

ngBe

richtsweg

notwendige

Qualifi

katio

n

Fachausschuss

GFachausschüssesin

dEx

pertengrem

ien,

dieüb

erTh

emen

beraten,dievonFü

h-rungskräfte

nnichtallein

entschieden

werdenkönn

en.Z

umBe

ispielbe-

urteilenFachausschüssetechnische

Projektergebnisseun

dform

ulieren

Entscheidu

ngsempfehlungen

fürF

üh-

rungskräfte

.Siekönn

endarüberh

inaus

eine

beratend

eRollefürd

asProjekt-

team

spielen.

Der

Fachausschussb

erichtetin

derR

e-gelanFü

hrun

gskräft

ein

derL

inieun

dSteuerun

gsgrem

ienwieLenk

ungsaus-

schü

sse.

Mitg

liederd

esFachausschussesm

üssen

fund

ierteFachkenn

tnisse

haben.

Risiko-

ausschuss

GDer

Risik

oausschu

ssist

fürd

asRi-

sikomanagem

entd

erOrganisa

tion

zuständig.Der

Risikoausschussb

ewer-

tetR

isikoanalysen

und-pläne

ausd

enProjekten.

Der

Risikoausschussb

erichtetan

Steue-

rungsgremienwieLenk

ungs-o

der

Portfolio

ausschüsse.

Der

Risikoausschussspielteinebe-

sond

ereRo

llebeid

erFinanz-u

ndBa

ubranche,indenendasR

isikoma-

nagementsehra

usgeprägtist.


Tab. 5.3 Branchenunterschiede bei den Projektgremien

Gremium IT- undOrganisations-projekte

Bau- undAnlagenbau-Projekte

Produkt-entwicklungs-projekte

Finanz-branche

Projekt-Lenkungsausschuss × × × ×

Portfolio-Lenkungsausschuss × × × ×

Fachausschuss ×

Risikoausschuss ×

Architekturausschuss ×

gen Entscheidungen an höhere Führungsebenen zu delegieren. Klare Eskalationswege sindwichtig, weil so Probleme schnell gelöst werden können und damit Projektverzögerun-gen vermieden werden. In großen Organisationen können Gremien hierzu auf mehrerenHierarchieebenen angesiedelt werden. So ist es beispielsweise denkbar, dass es einen Risi-koausschuss auf Abteilungs-, Bereichs- und Unternehmensebene gibt.

Fallbeispiel: Projektmanagement-Rollen und -Gremien bei einem Finanz-dienstleister

Berichtet an

Vorstand

Portfoliolenkungs-ausschuss Risikoausschuss

Ber

icht

et a

n

Projektlenkungs-ausschuss

Portfolio-Controlling

ProjektsponsorProjektmanager

Projektmanager-pool

PMOIst Teil von

Berichtet anProjektcontroller

Fachmanager IT-Security-Office

Sitz

t im

Ber

icht

et a

n

Sitz

t im

Unt

erst

ützt

In der Projektorganisation eines großen Finanzdienstleisters sind alle ProjektmanagerMitglieder eines Projektmanagerpools, der imPMO angesiedelt ist. Die Projektmanagerwerden in ihren Tätigkeiten von dem IT-Security-Office (bei Fragen zur IT-Sicherheit)und von einem Fachmanager (bei fachlichen Fragen) unterstützt und müssen an einenProjektcontroller berichten.


Sowohl der Projektcontroller als auch der Projektsponsor sind Mitglieder des Pro-jektlenkungsausschusses. Dieses Gremium tagt regelmäßig, bespricht die Projektsta-tusberichte, trifft Projektentscheidungen und berichtet an den Portfoliocontroller. DerPortfoliocontroller sitzt wiederum im Projektportfoliolenkungsausschuss, dessen Rolledie Steuerung des Projektportfolios ist. Dieser Ausschuss berichtet an den Vorstand undan den Risikoausschuss.

In der Praxis hat es sich bewährt, die Projektorganisation schrittweise und bedachtaufzubauen. Dreh- und Angelpunkt ist dabei das zuvor diskutierte PMO, das für die Ent-wicklung des Rollen- und Gremienkonzeptes zuständig ist. Das PMO versorgt auch vieleRollen und Gremien mit Informationen. Zu den ersten Gremien gehören zentrale Steuer-kreise wie beispielsweise der Lenkungsausschuss für Projekte oder der Portfolioausschuss.Danach werden Schritt für Schritt koordinierende Gremien z. B. für das Risikomanage-ment oder das Architekturmanagement (bei Organisations- und IT-Projekten) eingeführt.Letztlich bilden sichmeist ebensoGremien für Beratung undWissensaustausch (siehe auchKap. 6).

Einige Organisationen nutzen die in der Projektorganisation angelegten Eskalations-wege, um die Aufmerksamkeit für Projekte und Projektmanagement zu steigern. Hierzuwird ein bestimmter Anteil (z. B. 5%) aller Probleme zur nächsthöheren Entscheidungsin-stanz eskaliert. Dies ist ein einfacher Mechanismus, um auf höheren Managementebenendas Verständnis für Projekterfordernisse zu stärken. Ähnliches gilt für das projektbezogeneBerichtswesen, das für diesen Zweck schlank, einfach verständlich und homogen aufge-baut sein sollte. Im Wesentlichen sollte es sich auf Probleme und Entscheidungsbedarfekonzentrieren. Damit insbesondere diejenigen Rollen und Gremien, die nur wenig Zeitmit der Begleitung von Projekten und des Projektmanagements verbringen, ihre Aufgabeadäquat erfüllen können, sind die Personalentwicklungsmaßnahmen entsprechend anzu-passen bzw. zu erweitern. Sie sollten explizit auf die verschiedenen Rollen und Gremieneingehen unddenMitarbeitern vermitteln, welcheAufgaben undVerantwortlichkeitenmitihnen einhergehen.

5.2.3 Zentrales PM-Informationssystem

Bei der Etablierung eines Projektportfoliomanagements in einer Organisation wird manzunächst auf die bekannten Office-Standardapplikationen setzen, um das Projektportfo-lio zu steuern. Produkte wie Microsoft Excel machen es leicht, Listen mit Projekten undProjektanträgen zu pflegen, diese zu priorisieren undBudgets zu verteilen. Ein fortgeschrit-tenes Multiprojektmanagement ist jedoch kaum mit derartigen Lösungen zu realisieren.Die praktisch nicht vorhandene Mehrbenutzerfähigkeit sowie die mangelhafte Unterstüt-zung für komplexere Datenstrukturen, wie sie beispielsweise bei der Terminplanung oderbeim Ressourcenmanagement anfallen, sind nur zwei Gründe, warum es nach einer An-


fangsphase eines ausgereiftenMultiprojektmanagementsystems bedarf. Bei der Einführungeines solchen Systems besteht die Möglichkeit, entweder komplett die lokalen Einzelpro-jektmanagementsysteme abzuschaffen und ein zentrales System einzurichten oder, einemintegrativen Absatz folgend, die Daten aus den einzelnen Systemen zu aggregieren. Derzweite Ansatz gilt als weniger riskant, da die Projektmitarbeiter wie gewohnt mit den be-stehenden Systemen arbeiten können.

Zentrale Projektmanagement-Informationssysteme bieten eine Reihe von Vorteilen:

Zentrale Datenhaltung: Informationen zu allen Projektenwerden einheitlich in einer zen-tralen Datenbank gespeichert. Daraus ergibt sich der Vorteil, dass projektübergreifendeDatenauswertungen leicht möglich sind.

Mehrbenutzerfähigkeit: Praktisch beliebig viele Benutzer können zeitgleich und mit ge-nau definierten Zugriffsrechten mit einem solchen System arbeiten.

Umfassende Funktionalität: Marktführende Produkte bieten Funktionen für nahezu alleGebiete des Projektmanagements, z. B. das Ressourcenmanagement, das Portfolioma-nagement, das Terminmanagement, das Risikomanagement usw.

Internetfähigkeit: Zunehmend könnenProjektmanagement-Softwarelösungen auch überdas Internet in einem normalenWebbrowser genutzt werden. Damit erschließt sich derZugang über eine Vielzahl von Endgeräten.

Im Rahmen der Zentralisierung werden viele übergeordnete Prozesse des Projektma-nagements wie bspw. die Projektinitiierung vereinheitlicht und erfordern in diesem Zugkonsolidierte, aktuelle und möglichst genaue Informationen über laufende und geplan-te Projekte. Aus diesem Grund ist die Zentralisierung der Projektinformationen in dieserPhase essentiell. Im Rahmen dieser Zentralisierung sind die folgenden Einzelaufgaben zurealisieren:

1. Anforderungsdefinition:Hier ist zunächst zu definieren, welche Projektmanagement-Techniken und -Prozesse durch die Software unterstützt werden sollen. Daraus lassensich die entsprechenden Anforderungen an die Software ableiten und dokumentieren.

2. Softwareauswahl: Um ein geeignetes Produkt zu finden, ist der Markt für Projektma-nagement-Software zu sichten und im Rahmen eines Auswahlprozesses ein geeignetesProdukt zu bestimmen.

3. Konfiguration und Integration:Die allermeisten Projektmanagement-Softwaresyste-me erfordern eine umfassende Konfiguration. Zum Beispiel müssen Zugriffsrechte de-finiert und Bildschirmmasken angepasst werden. Hinzu kommen Integrationstätigkei-ten, wenn die Lösung mit anderen Softwaresystemen für Zwecke des Datenaustauschsverbunden werden soll.

4. Pilotierung: Insbesondere bei größeren Installationen kann es sinnvoll sein, den Ein-satz der neuen Software zunächst in einem abgegrenzten Bereich zu testen. Die Er-fahrungen mit diesem Piloteinsatz können dazu genutzt werden, das Produkt oder diedurch das Produkt unterstützten Prozesse weiter anzupassen.


5. Training: Jedem Einsatz einer neuen Software sollten Schulungsmaßnahmen voraus-gehen, um die Anwender vorzubereiten.

6. Roll-Out: Schließlich kann die Software in den Produktivbetrieb überführt werden.Von nun an wird sie praktisch zur Unterstützung des Projektmanagements eingesetzt.

7. Support:Während der Nutzung sind die Anwender durch einen Helpdesk und weiter-gehende Maßnahmen (z. B. Key-User-Konzept) bei Problemen und Fragen zu unter-stützen.

8. Fortlaufende Anpassung: Da sich die Projektmanagement-Prozesse und die Projekt-management-Organisation weiterentwickeln, unterliegt auch die Software einer konti-nuierlichen Weiterentwicklung.

Fallbeispiel: Rollout von saprima® bei einem Kunden/saprima® Inte-grationsszenario

In diesem Fallbeispiel wird die Einführung der Multiprojektmanagement-Softwaresaprima® der Firma INTECO bei einem der weltweit führenden Chemiekonzerne be-handelt. Der Bedarf an zentralisiertem Ressourcenmanagement für die Engineering-Einheit dieses Konzerns (ca. 1000 Mitarbeiter) war ausschlaggebend für die Entschei-dung, ein zentrales Projektmanagement-Informationssystem einzuführen. Das Ziel derEinführung der Projektmanagement-Software bestand darin, Ressourcenengpässe früherkennbar zu machen, Personalressourcen besser zu steuern sowie eine Informations-grundlage für Projektabstimmungsprozesse und Auslastungsprognosen zu schaffen.Kapazität, Bedarf und Auslastung der einzelnen Mitarbeiter sollten mittels dieser Soft-ware transparent gemacht werden. Die Projektmanagement-Software sollte ebenfalls andas ERP-System der Organisation angebunden werden, um Informationskonsistenz zugewährleisten.

30 Softwareanbieter wurden identifiziert, die diese Anforderungen erfüllen konnten.Nach einer ersten Analyse kamen 10 Anbieter in die engere Auswahl und nach einerVorstudie hat sich die Organisation für saprima® entschieden. Gründe waren die Flexi-bilität und die Anpassbarkeit dieser Software sowie die Schnittstelle zum ERP-System.

Bereits in den frühen Einführungsphasenwurden alle relevanten Projektstakeholder(z. B. Projektleiter, Teilprojektleiter, Projektcontroller) eingebunden, um Konsens überdie Funktionalitäten der Software und deren Integration in die Unternehmensabläufezu schaffen. Außerdem konnten so leicht die Zuständigkeiten für die einzelnen Moduledes Einführungsprojekts definiert werden.

Fallbeispiel: Weiterentwicklung des Projektmanagements bei einemder größten Technologieanbieter im Gesundheitswesen

In diesem Fallbeispiel wird der Aufbau des Projektmanagements bei einem der Markt-führer im Bereich der Medizintechnik besprochen. Das Produktportfolio dieser Firma


umfasst unter anderem Computertomographiegeräte, MagnetresonanztomographenundUltraschalluntersuchungssyteme. Forschungs- und Entwicklungsprojekte sind hierMotor der Wertschöpfung und Garant für eine technologisch führende Marktposition.Zwei Drittel aller Produkte dieser Organisation sind jünger als drei Jahre. Mehr als 9%des Umsatzes werden in Forschung und Entwicklung investiert.

Im vorliegenden Fall bestanden die folgenden Herausforderungen bezüglich desProjektmanagements:

• Verringerung der Risiken hinsichtlich Terminen und Kosten• Verbesserung der Planungsqualität, Überwachung und Steuerung der Projekte• Standortübergreifende, durchgängige Informationsflüsseund Prozesse aller beteilig-

ten Organisationseinheiten

Als Reaktion auf diese Probleme entschied die Organisation im Jahre 2001, externeBerater damit zu beauftragen, die Projektmanagement-Praktiken auf die dritte CMMI-Stufe zu bringen. Ein Projektvorgehensmodell wurde eingeführt.

Das Informationsflussproblem wurde damit aber nicht gelöst. Einige Monate späterstartete die Organisation daher ein neues Projekt mit dem Ziel, Termine, Kosten undFunktionsumfang der laufenden Projekte quer zu allen Organisationsstrukturen für alleBeteiligten auf einen Blick erfassbar und auf einfache Weise nachvollziehbar zu gestal-ten. Um alle Zielsetzungen zu verwirklichen, war ein ganzheitlicher Ansatz erforderlich,der sämtliche Projektebenen von der Ablaufplanung bis hin zur strategischen Roadmapder Produktlinie in den Verbesserungsprozess mit einbezog. Zu diesem Zweck wur-de die Methode Integrated Enterprise Project Management (iEPM) der BeratungsfirmaINTECO® für das Berichtwesen implementiert und ein zentrales Projektmanagement-Informationssystem eingerichtet. Die Zentralisierung der Projektdaten hat für mehrTransparenz der Projekte undmehr Effizienz in der Projektabwicklung gesorgt. Auf Ba-sis der Daten des zentralen Informationssystems werden mit iEPM die Projektmanage-mentinformationen in den Statusberichten beispielsweise in Form von Ampelberichtenvisualisiert und aktuelle Leistungsmetriken wie Fehlerbehebungsstatistiken berechnet.Die hierfür erforderliche Verbindung von Produktstrategie und Projektportfoliomana-gement stellt iEPM durch einen Meilensteinplan her, der die Roadmap des Entwick-lungsprojektes abbildet. An jedem Meilensteintermin beschließt der Leitungskreis ineiner Phasenentscheidungssitzung über Veränderungen, Vorgaben undMittelfreigabenfür die nächste Projektphase.

Die Nutzungsart, -breite und -tiefe eines Projektmanagement-Informationssystems di-vergieren stark von Projekttyp zu Projekttyp und vonOrganisation zuOrganisation. Tabel-le 5.4 zeigt die verschiedenen Typen vonProjektmanagement-Software und deren jeweiligeVor- und Nachteile.


Tab. 5.4 Projektmanagement-Software

Projektmanage-ment-Software(PMS)

Beschreibung Vorteile Nachteile

Single-PMS Der Zweck eines Single-PMSist die Unterstützung desProjektmanagers bei derPlanung und Steuerung eineseinzelnen Projektes.

• Wenig Aufwandfür Installation,Konfigurationund Training

• BeschränkteFunktionalitä-ten

Multi-PMS Eine Multi-PMS verfügt übereine zentrale Datenbank, wasdie Möglichkeit bietet, die-selbe Projektmanagement-Methodik bei verschiedenenProjekten anzuwenden unddie Ressourcen projektüber-greifend zu koordinieren.

• Unterstützungvon Multipro-jektmanagement-Tätigkeiten

• Keine Mög-lichkeit dieProjektarbeitzwischen ver-schiedenenStakeholdernzu koordinieren

Enterprise PMS Enterprise PMS verfügenüber Workflow-Manage-ment-Funktionalitäten undsind einfach anzupassen. Siebieten Funktionen für ver-schiedene Rollen / Projekt-Stakeholder, decken das Port-foliomanagement ab undsind oft Internet-fähig.

• Hohe Flexibilitätund Anpassbar-keit

• Hohe In-stallations-,Konfigurations-und Trainings-kosten

Performanz-orientierte PMS

Zusätzlich zu den Funktiona-litäten eines Enterprise PMSverfügen performanzorien-tierte PMS über Berichts-und Business-Intelligence-Werkzeuge.

• Leistungs-orientierung

• Setzt eine hoheProjektmanage-ment-Reife derOrganisationvoraus

WissensorientiertePMS

Diese PMS-Kategorie bietetzusätzlichWissensmanage-ment-Funktionalitäten.

• Entwicklung vonBest Practicesund Lessons-Learned

• Setzt eine sehrhohe Reife derOrganisationvoraus

Integratives PMS PMS dieser Kategorieaggregieren die Projekt-informationen aus denbestehenden Single-PMS.

• Verbindet dieVorteile vomPMS, Multi-PMSund EnterprisePMS mit Fle-xibilität bei derAuswahl der PMSauf Einzelprojekt-ebene

• Neuartiger An-satz


Bei der Einführung von Projektmanagement-Software ist stets darauf zu achten, dassnicht allein Projektmanager zu denNutzern einer solchen Software gehören, sondernprak-tisch alle Projektbeteiligten zu Anwendern werden können. Es bietet sich daher an, dieAuswahl einer geeigneten Lösung partizipativ unter Einbindung aller Stakeholdergruppendurchzuführen. Das hat weiterhin den Vorteil, dass die Akzeptanz der Lösung größer ist,als wenn ein PMO oder ein kleines Projektteam die Entscheidung autonom fällt. Darüberhinaus sollte die Bewertung von Lösungen anhand der Informationsbedarfe der Anwend-ergruppen erfolgen und nicht auf der Basis einerWunschliste mit Funktionen. Hier geht esauch darum zu entscheiden, ob ein zentrales Standard-Projektmanagement-Informations-system oder ein integratives System für die Organisation besser geeignet ist. Die zentraleFrage lautet: Welche Informationen benötigt welcher Anwender in welcher Qualität zuwelchem Zeitpunkt? Lediglich beim Termin-, Ressourcen- und Risikomanagement ist be-sonders intensiv auch auf Funktionen zu achten, weil hier die Ergonomie und Flexibilitätder Lösung einen großen Einfluss auf ihren Nutzen und damit auch auf ihre Akzeptanzhat. Weitergehende Informationen zum Thema Akzeptanz von Methoden und Werkzeu-gen finden Sie in Kap. 3.

5.2.4 Zentralisierte Prozesse

Mit der Einführung eines Project Management Office, einer klaren Projektorganisationss-truktur und der Unterstützung eines zentralen PM-Informationssystems wird es möglich,viele Prozesse des Multiprojektmanagements zu zentralisieren. Damit wird die Voraus-setzung für ein einheitliches und transparentes Risiko-, Ressourcen- und Portfoliomana-gement geschaffen und letztlich sichergestellt, dass ein auf Basis von Risiko- und Chan-cenüberlegungen (weitgehend) optimales Projektportfolio gewählt und abgewickelt wird.Strategische Ziele lassen sich so mit beherrschbaren Risiken umsetzen. Von der Zentrali-sierung sind üblicherweise folgende Teilprozesse betroffen:

Projektinitiierung [5]: Dieser Teilprozess umfasst die Sammlung von Projektideen bzw.Projektanträgen sowie ihre Kategorisierung, Ausarbeitung und Bewertung als Vorbe-reitung der Entscheidung bezüglich ihrer Durchführung.

Projektauswahl/Budgetierung [5]: Nach der Projektinitiierung werden die Projektanträ-ge priorisiert. Unter Berücksichtigung der zur Verfügung stehenden Ressourcen wirdüber ihre Durchführung entschieden. Weitergehende Informationen zu diesem Teil-prozess finden Sie in Abschn. 5.2.7 und in Kap. 4.

Projektdurchführung [6]: Dieser Prozess umfasst das Management eines einzelnen Pro-jektes im engeren Sinne. Es geht um alle Schritte, die nach der Beauftragung des Pro-jektteams und der Bereitstellung der Ressourcen anfallen. Dieser Prozess wurde bereitsin der Standardisierungsphase vereinheitlicht und muss nun ggf. um wichtige Aspektefür das Multiprojektmanagement erweitert werden.


Projektreviews und -audits [5]: Hier geht es um die Steuerung und Überwachung vonProjekten auf der Portfolioebene.

Projektabschluss [5]: Der Projektabschluss ist von besonderer Bedeutung, weil er sich gutdafür eignet, aus der Projektabwicklung zu lernen und das Projektmanagement der Or-ganisation zu verbessern.

Projektnachbetrachtung [7]: Insbesondere in den Fällen, in denen das Projektergebniszielgerichtet in der Organisation weiterverwendet wird, kann es sinnvoll sein, über dasProjektende hinaus die Wirkung des Projektes zu verfolgen und zu analysieren. Damitlässt sich beurteilen, ob das Portfoliomanagement mit der Freigabe des Projektes dierichtige Entscheidung getroffen hat.

Für jeden dieser Teilprozesse sind die folgenden Schritte erforderlich:

1. Prozess definieren: Zunächst einmal ist festzulegen, aus welchen Einzelaufgaben derProzess besteht, wie die zeitlich-sachlogische Abfolge dieser Einzelaufgaben ist undwerdiese Aufgaben wahrnimmt. Darüber hinaus sind ggf. Methoden undWerkzeuge fest-zulegen, die zur Lösung der Aufgaben erforderlich sind.

2. Prozess etablieren: Nach der Definition eines Prozesses ist dieser in der Organisati-on einzuführen. Mitarbeiter sind entsprechend zu instruieren und auszubilden, unter-stützende Softwaresysteme bereitzustellen, Vorlagen, Methoden und Werkzeuge sindvorzuhalten.

3. Prozess überwachen und steuern: Die Prozessabwicklung sollte fortlaufend über-wacht werden. Wenn nötig, ist steuernd einzugreifen. Das kann zum Beispiel dannnotwendig sein, wenn sich Mitarbeiter nicht an die Vorgaben halten oder es Unsicher-heiten bzgl. des Verfahrens gibt.

4. Prozess verbessern: Aus der Prozessüberwachung und -steuerung kann sich die Not-wendigkeit ergeben, den Prozess zu verbessern.Derartige Verbesserungen sind zu kon-zipieren, zu testen und anschließend einzuführen.

Die Art undAnzahl der zentralisierten Projektprozesse variiert vonBranche zu Branchebzw. von Projekttyp zu Projekttyp.

Fallbeispiel: Bau undAnlagenbauSiehe Kap. 6, Fallbeispiel: Claim-Management bei einem großen Bau- und Dienstleis-tungskonzern.

In vielen Organisationen sind die abzuwickelnden Projekte sehr heterogen. Sie unter-scheiden sich im Hinblick auf ihr Budget, ihre Komplexität, ihre Risiken und auch ihreRessourcenbedarfe. Oft ist es wenig effizient für einfache Projekte, alle Prozesse vollständig


zu durchlaufen. Stattdessen sollten für derartige Projekte schlankere Prozesse zur Anwen-dung kommen. Daher ist es sinnvoll, Projekte zu klassifizieren und entsprechende Pro-zessvarianten zu entwickeln. In vielen Organisationen gibt es zum Beispiel eine A/B/C-Klassifikation, wobei A-Projekte besonders groß und komplex und C-Projekte besondersklein und einfach sind. Für letztere kommen dann auch entsprechend einfache Prozessezur Anwendung.

In der Praxis des Multiprojektmanagements haben sich darüber hinaus die folgendenLeitlinien als hilfreich erwiesen:

Fokus auf Verantwortlichkeiten: Wichtiger als die exakte Definition, wie ein Prozess-schritt zu vollziehen ist, ist es festzulegen, wer die Verantwortung für Entscheidungenträgt. Wir empfehlen klar festzulegen, welche Entscheidungsträger im Prozess zu wel-chem Zeitpunkt auf Basis welcher Informationen welche Entscheidungen zu treffenhaben.

Keine Ausnahmen: Definierte Prozesse sollten in der Organisation absolut verbindlichsein. In den seltenen Fällen, in denen vomdefinierten Prozess abgewichenwerdenmuss,ist dies entsprechend zu begründen und zu dokumentieren.

Schritt für Schritt: Es bietet sich an, Prozesse Schritt für Schritt einzuführen und die Or-ganisation langsam an die neuen Abläufe zu gewöhnen.

5.2.5 Zentrales Risikomanagement

Risikenwerden imProjektmanagement oft nur unzureichend antizipiert. Es ist nicht selten,dass die Beteiligten Risiken eingehen, da sie von den Konsequenzen ihres Handelns be-freit sind und die Schäden nicht tragen müssen [8]. Verstärkt wird dieses Verhalten durchmangelnde Risikotransparenz und falsche Anreize, die z. B. darin bestehen können, dassbei Projekterfolg Boni gezahlt werden, umgekehrt aber Schäden aus Risiken keine Auswir-kung haben. Dies kann zum Beispiel dann der Fall sein, wenn ein Software-Projektteaminnovative Technologien verwendet, die zwar den Projekterfolg steigern können, aber ei-gentlich nicht beherrscht werden. Projektbezogene Risiken können existenzbedrohend fürein Unternehmen sein [9]. Es ist daher wichtig, eine zentrale Instanz zu definieren, die sichfür das Risikomanagement verantwortlich zeigt.

Beim Aufbau des Risikomanagements müssen die nachstehenden Aufgaben abgedecktwerden [5]:

Risikoidentifikation: In dieser Phase werden die möglichen Projektrisiken identifiziert.Die Risiken können anhand von vordefinierten Risikochecklisten, die aus alten Pro-jekterfahrungen resultieren, oder kreativen Methoden (z. B. Workshops) identifiziertwerden.

Risikobewertung: In dieser Phase werden die Auswirkungen der Risiken auf die Projek-te (am besten quantitativ) geschätzt. Bei komplexen Projekten ist es durchaus sinnvoll,


die kombinierte Auswirkung mehrerer Risiken abzuschätzen. In der Regel werden dieRisiken nach ihrer Abschätzung in drei Kategorien gegliedert: Nicht signifikante Ri-siken, signifikante Risiken und „Show Stopper“ (Risiken, die den Gesamtprojekterfolggefährden oder sogar die Organisation bedrohen). Im Anschluss werden die Risikenpriorisiert. Kategorisierung und Priorisierung der Risiken erfolgen auf der Basis einereigenen Heuristik, die jede Organisation für sich definiert.

Risikoanalyse: In diesemSchritt werden dieAuswirkungen der Risiken genauer analysiert.Hier können Simulationen (z. B. Monte-Carlo-Analyse) oder qualitative Methoden ge-nutzt werden. Anhand dieser Analyse wird ein Maßnahmen- und Reaktionsplan fürdie Risiken vorbereitet. Dieser legt fest, wie die Risikoeintrittswahrscheinlichkeit ge-mindert werden kann bzw. wie im Fall des Risikoeintritts zu verfahren ist.

Risikosteuerung: Hier werden die Projekte im Hinblick auf Risiken gesteuert und beimEintreten eines Risikos die entsprechenden Reaktionspläne aktiviert und abgearbeitet.Tritt ein Risiko auf, ist ggf. die Anpassung der Projektpläne notwendig (z. B. Anpassungdes Zeitplans mit realistischen Dauern für die Aufgabenpakete). Ein regelmäßiges Be-richtswesen spielt beim Risikomanagement eine zentrale Rolle: Es bildet die Informati-onsgrundlage für die Risikobeurteilung durch Steuerungsgremien und Führungskräfte.

Art und Auswirkungen von Risiken sind von Projekttyp zu Projettyp sehr verschieden.Bauprojekte z. B. sind in Hinblick auf ihre Risiken tendenziell komplex. Neben den inter-nen Risiken (beispielsweise Qualifikation der Mitarbeiter, Liquiditätsengpässe) bestehenexterne Risiken aufgrund der Beziehungenmit den Lieferanten undden Subunternehmernsowie der Schwankung der Rohstoffpreise. Selbst der Baugrund kann mit einer Reihe vonRisiken verbunden sein. Im Vergleich sind die Risiken bei IT-Projekten recht überschau-bar (z. B. Qualifikation der Mitarbeiter, Technologierisiken, Kostenüberschreitung), aberfür die Realisierung der Projektzielsetzungen nicht weniger relevant.

Fallbeispiel: Risikomanagement bei einem mittelständischen Eisen-bahnsicherungstechnik-Unternehmen

Das hier untersuchte Unternehmen beschäftigt knapp 300 Mitarbeiter und ist im Be-reich der Eisenbahnsicherungstechnik tätig. In dieser Organisation werden Produkt-entwicklungs- und Bauprojekte durchgeführt. Im Rahmen der Bestrebungen, den drit-ten CMMI-Level zu erreichen, wurden neue zentralisierte Projektmanagement-Prozes-se eingeführt.

Bis dahin wurden Projekte wie folgt geplant: Der Projektmanager erhielt Vorgabenbezüglich der Projektdauer und des Projektaufwandes und plante das Projekt dement-sprechend. In einem zweiten Schritt ermittelte man die Risiken, schätzte diese ab undermittelte ein Worst-Case-Szenario. Im dritten Schritt wurde versucht, einen realisti-schen Projektplan als Kompromiss zwischen Managementvorgaben und Worst-Case-Szenario zu erstellen. Dieser Plan war „mathematisch richtig“, aber oft unrealistisch.


Nach der Neudefinition der Risikomanagementprozesse werden die Risiken in derProjektplanung und -steuerung weitergehend berücksichtigt: Zuerst plant der Projekt-manager sein Projekt wie gewohnt ohne Berücksichtigung der Risiken, dannwerden dieRisiken identifiziert und es wird eine Monte-Carlo-Simulation [10] durchgeführt. DieErgebnisse der Monte-Carlo-Simulation werden dazu verwendet, für jedes Arbeitspa-ket zwei Aufwandswerte anzuzeigen: den ursprünglichen Planwert und den Wert, dermit 85% Wahrscheinlichkeit erreicht wird. Diese neu definierten Prozesse haben einerealistischere Termin- und Aufwandsschätzung zur Folge.

Risikomanagement-Methoden sollten nicht blind verwendet werden. Hinter vielenMe-thoden der Risikoanalyse (z. B. Monte-Carlo-Simulationen) stecken komplizierte stochas-tische Modelle. Die Risikoanalysten und -manager müssen die Funktionsweise dieser Me-thoden verstehen, umdie notwendigenDaten bereitstellen unddie Ergebnisse richtig inter-pretieren zu können. Sonst sind die Ergebnisse wenig aussagekräftig („Garbage in, garbageout“).

Es ist zu beachten, dass die Ergebnisse der Risikoanalysen verständlich sein müssen.Die unmittelbare Ausgabe entsprechender Analysewerkzeuge ist vielfach nur für Expertennachvollziehbar und bedarf einer managementgerechten Aufbereitung.

Die Güte des Risikomanagements wächst mit der Güte der Schätzwerte zu Risikoein-trittswahrscheinlichkeiten und Schadenshöhen. Daher ist es wichtig, Vergangenheitswertesystematisch zu sammeln, zu analysieren und für die Risikobewertung und -analyse ver-fügbar zu machen (siehe Kap. 6).

5.2.6 Zentrales Ressourcenmanagement

In der Standardisierungsphase werden Ressourcenmanagement-Praktiken auf Einzelpro-jektebene eingeführt. Als Ergebnis herrscht ein hohes Maß an Transparenz über die Res-sourcenverwendung in den Projekten. Allerdings kann damit nur ein Teil der Problemedes Ressourcenmanagements tatsächlich gelöst werden, weil viele Probleme aus interde-pendenten Projekten resultieren, die Ressourcen gemeinsam, oft auch parallel, verwenden.So sind viele Engpass- und Überlastungsprobleme nur dann zu beheben, wenn das Res-sourcenmanagement zentralisiert wird und die Ressourcenzuweisung und der Ressour-cenabgleich nicht nur für ein Projekt, sondern für alle Projekte eines Portfolios simultanerfolgen. Hierzu sind folgende Aufgaben zu nennen:

Ressourcenstrukturen und -pools: Wie bereits im Zusammenhang mit der Standardisie-rungsphase diskutiert, sind die Ressourcen zunächst einheitlich zu beschreiben und zuklassifizieren. Dafür können Ressourcenstrukturen (siehe Kap. 4) undRessourcenpoolsverwendet werden. Ein Ressourcenpool ist eine Zusammenfassung gleichartiger Res-sourcen bzw. organisatorisch zusammengehöriger Ressourcen, die von einer zentralen


Instanz (d. h. einem Ressourcenmanager) verwaltet werden (dazu gehören Projektma-nager, Softwareentwickler, aber auch Maschinen). Um über aktuelle Informationen fürdie Ressourcenanalyse und -planung zu verfügen, wird empfohlen, die Projektressour-cenpools an die HR-Systeme der Organisation anzubinden.

Ressourcenplanungsprozesse: Es sind strukturierte Prozesse der Ressourcenplanung undZuweisung zu definieren und einzuführen. In vielen Organisationen gibt es derartigeProzesse auf verschiedenen Planungsebenen. Zum Beispiel werden auf der Ebene desProjektportfolios Ressourcen langfristig und sehr grob geplant – oft nur auf der Ebenevon Abteilungen, des Ressourcenpools oder einer anderen Gruppierung von Ressour-cen (z. B. Fähigkeiten). Eine solche Planung findet einmal jährlich statt. Unterjährigerfolgt auf einer zweiten Ebene die Zuweisung von verfügbaren Ressourcen zu Projek-ten. Schließlich kann der Projektmanager auf der dritten Ebene die ihm zur Verfügungstehenden Ressourcen den Arbeitspaketen zuweisen. In vielen Organisationen erfolgtdieRessourcenzuweisung allerdings nicht nur top-down, sondern auch bottom-up, d. h.Projektmanager fragen von ihnen benötigte Ressourcen nach und stellen eine entspre-chende Anfrage. Auch diese Anfrage-/Freigabeprozesse sind zu definieren.

Ressourcenplanungstechniken [5, 6]: Die Planung der Ressourcennutzung kann schnellsehr komplex werden und bedarf in der Regel spezialisierter Software. Verfügbarkeits-kalender fürMitarbeiter, Organisationseinheiten und Projekte, das zeitliche und struk-turelle Detaillierungsniveau der Planung (siehe auch Kap. 4), Einlastungsprofile sowievoneinander abhängige Ressourcen und Analyseverfahren sind nur einige Aspekte, dieim Kontext der Ressourcenplanungstechniken zu diskutieren und zu definieren sind.

Rückmeldungen und Berichtswesen: Nach Abschluss der Planung undwährend der Pro-jektlaufzeit ist die tatsächliche Ressourcennutzung zu erfassen, zu analysieren und überdas Berichtswesen zu kommunizieren. Die Informationen über geleistete Aufwändeund erledigte Aufgaben müssen an den Projektmanager und den zentralen Ressour-cenmanager zurückgemeldet werden. Anhand dieser Informationen werden ggf. dieEinzelprojektpläne und die Ressourcenverfügbarkeit auf zentraler Ressourcenmanage-mentebene aktualisiert. Gleichzeitig fließen diese Daten in das Projektcontrolling ein.Sie bilden zum Beispiel die Basis für die Earned-Value-Analyse [6].

Die Unterschiede im Ressourcenmanagement je nach Projektart und Branche wurdenin Kap. 4 besprochen. Es bestehen zusätzlich Unterschiede im Ressourcenmanagement-Prozess, die durch die Organisationsform bedingt sind: In der Matrixorganisation (z. B.ein internes IT-Projekt) müssen die Ressourcen von der Linienorganisation „ausgeliehen“werden. Das erfolgt mit Hilfe des oben skizzierten Ressourcenanfrage- und -freigabepro-zesses. Viele Dienstleistungs- oder Baufirmen hingegen sind z. B. reine Projektorganisatio-nen; es sind keine Anfragen und Freigaben der Ressourcen erforderlich. Zusätzlich bietetes sich an, in der Matrixorganisation schriftliche Vereinbarungen über die Ressourcenbe-reitstellungen zu treffen. Das hat aus organisatorischer und ethischer Sicht verschiedeneVorteile:


• Es werden Konflikte zwischen der Projektorganisation und der Linienorganisation ver-mieden.

• Unbelastete Ressourcen können nicht von der Linienorganisation ohne Begründungvorbehalten werden. Besteht kein Bedarf, werden die Ressourcen für Projekte freigege-ben.

• Durch die Regulierungen wird vermieden, dass die Mitarbeiter der Linienorganisationin den Projekten überlastet werden.

Bei der Zentralisierung des Ressourcenmanagements spielt ein zentrales Projektmanage-ment-Informationssystem eine wichtige Rolle, da es die Informationsgrundlage für diesePraktiken bietet. Eine Abstimmung der Daten zwischen diesem System und den ande-ren Informationssystemen der Organisation (z. B. ERP-System, HR-System) ist daher eineVoraussetzung für den Erfolg des zentralen Ressourcenmanagements. Beispiele für die Im-plementierung zentralisierter Ressourcenmanagement-Praktiken sind in den Fallstudien-kapiteln zu finden. Empfehlungen für das Topmanagement bezüglich der Einführung vonRessourcenmanagement werden in Kap. 4 aufgezeigt.

5.2.7 Zentrales Projektportfoliomanagement

Neben dem Risikomanagement und dem Ressourcenmanagement ist das Portfoliomana-gement die dritte Projektmanagement-Funktion, die hier besonders herausgestellt werdensoll. Bei ihr geht es um die zielgerichtete Auswahl und Steuerung aller Projekte, die in ei-nerOrganisationseinheit oder auch demgesamtenUnternehmen durchgeführt werden. DaProjekte in der Regel durchgeführt werden, um strategische Ziele zu realisieren, kommtdem Portfoliomanagement eine wichtige Rolle zu: Es entscheidet darüber, wie die Unter-nehmensstrategie umgesetzt wird, und es stellt sicher, dass diese Umsetzung erfolgreichist.

Voraussetzung für effizientes Projektportfoliomanagement sind klar definierte strate-gische Ziele, da diese in der Regel in Auswahlkriterien für potenzielle und auch laufendeProjekte überführt werden. Neben der Übereinstimmung mit der Unternehmensstrategieist ein ausgeglichener Business-Case ein weiteres Kriterium für die Aufnahme eines Pro-jektes in das Projektportfolio.

Die Steuerung und Moderation des Projektauswahlprozesses wird in vielen Organisa-tionen vomPMOoder einemProjektportfoliomanager übernommen.Davon unbeeinflusstist jedoch die Entscheidungskompetenz der Führungskräfte, die die endgültigen Beschlüs-se über Projektfreigaben treffen. Zusätzlich zur Planung sollte das Ist-Portfolio regelmäßigeiner strategischen Analyse unterzogen werden, um es ggf. zu optimieren oder die Prioritätder Projekte neu zu definieren.

Die Strategiedefinition und Implementierung unterscheidet sich stark von Branche zuBranche bzw. von Projekttyp zu Projekttyp. Darum sind die Kriterien für die Zusammen-stellung des Projektportfolios und die Informationsbedarfe für das Portfoliomanagement


unterschiedlich. In der Bau- undAnlagebaubranche z. B. ist die Gesamtunternehmensstra-tegie für die Definition und Steuerung des Projektportfolios wichtig [9]. Unternehmendieser Branche wollen gezielt Risiken vermeiden, definieren Zielmärkte und versuchensich auf ein Marktsegment zu spezialisieren. Bei IT-Projekten spielt die IT-Strategie (diejedoch von der Unternehmensstrategie abgeleitet sein sollte) eine übergeordnete Rolle.Themen wie die Ziel-IT-Unternehmensarchitektur, Kostenreduzierung und Qualitätsstei-gerung sind die Kriterien für die Projektentscheidungen.

Fallbeispiel: Zentrales Projektportfoliomanagement bei einem Energie-unternehmenEin Energieunternehmen hat sich dafür entschieden, seine Projektportfoliomanage-ment-Praktiken zu zentralisieren. Das Projektportfolio umfasst ohne Berücksichtigungvon Vertriebsprojekten im Schnitt 14 Kraftwerksbauprojekte mit einem Budget vonknapp 10 Milliarden Euro.

Aufgrund der strategischen Wichtigkeit der Kraftwerksbauprojekte und der finan-ziellen Bedeutung solch eines Projektes wird das Portfolio zentral mit Beteiligung desTopmanagements geplant. In dieser Organisation existiert ein dedizierter Geschäftsbe-reich für Multiprojektmanagement, der für die Projektportfoliosteuerung zuständig ist:Projektinformationen werden gesammelt und aggregiert sowie Projekthandlungsemp-fehlungen verfasst. Anschließend werden diese an das Topmanagement berichtet.

18 Mitarbeiter sind in diesem Bereich tätig. Diese Abteilung ist ebenfalls für dieEvaluation der Projektideen unddie Projektinitiierung zuständig. Für die einzelnen Pro-jekte bildenMitarbeiter dieser Abteilung einen Projektlenkungsausschuss. Die Rolle desProjektlenkungsausschusses ist eher konsultativ. Dieses Gremium stellt Standards fürdas Projektmanagement zur Verfügung und unterstützt bei der Projektplanung und Ri-sikoanalyse. Projektentscheidungen werden direkt von der Geschäftsführung getroffen.

Fallbeispiel: Projektportfoliomanagement bei einem FinanzdienstleisterIn diesem Fallbeispiel werden die IT-Projektportfoliomanagement-Praktiken einesgroßen Finanzdienstleisters erläutert.

Die Abteilungen sind in Cluster unterteilt. Für die Projekte jedes Clusters ist ein Pro-jektportfoliomanager zuständig. Die Projektportfoliomanager handeln im Auftrag desTopmanagements, das im Vorfeld das Gesamtprojektbudget festlegt. Das Projektport-foliomanagement wurde an die Projektportfoliomanager delegiert, da das Topmanage-ment nicht in der Lage war, die große Anzahl der Projektanträge zu bearbeiten. DieRolle der Portfoliomanager besteht in der Analyse der Projektanträge und der Aggrega-tion der Projektinformationen aus den Projektstatusberichten in einen Portfolioberichtfür das Topmanagement. Für die Analyse der strategischen Wichtigkeit eines Projekteswird eine Balanced-Scorecard eingesetzt.


Die Projektportfoliomanagement-Praktiken haben dazu beigetragen, Transparenzbezüglich der Projektpriorisierung zu schaffen.Diese werden aber von denmeistenMit-arbeitern als langsam und nicht innovationsfreundlich empfunden.

Das Portfoliomanagement sollte als Interessenausgleichsprozess begriffen werden, beidem alle relevanten Stakeholder gemeinsam über das zukünftige Projektportfolio „verhan-deln“ (siehe dazu auch Kap. 3). Mathematische Modelle, die für die Portfoliooptimierungbereit stehen, kommen in der Praxis selten zur Anwendung.Weitergehende InformationenzumThema Portfoliomanagement können dem Kap. 7 entnommen werden.

5.3 Zusammenfassung & Empfehlungen

Mit dem erfolgreichen Abschluss der Zentralisierungsphase hat eine Organisation einengroßen Schritt getan: Von nun an sind Projekte klar an übergeordneten strategischen Zie-len ausgerichtet und mit den notwendigen Ressourcen ausgestattet. Darüber hinaus istes der Organisation möglich, den Verlauf der Projekte nicht nur zu verfolgen, sondernauch aktiv zu steuern. Die Zentralisierung wird bei einigen Beteiligten das Gefühl we-cken, dass es zu einer Bürokratisierung des Projektmanagements kommt. In der Tat kanndies eine negative Folge der Zentralisierung sein, wenn sie nicht mit dem nötigen Fin-gerspitzengefühl durchgeführt wird. Darum sollte der Organisation schon früh vermitteltwerden, wie die Zentralisierung – sofern sie gut umgesetzt ist – die Effizienz beträcht-lich steigern kann. Die Einrichtung eines PMO für alle Projekte, ein schlankes Reporting,die Nutzung eines Projektmanagement-Informationssystems, ein durchdachter Ressour-cenmanagement-Ansatz sowie pragmatische Gremienarbeit können der Tendenz zur Bü-rokratisierung entgegenwirken. Im Idealfall ergeben sich durch die Zentralisierung sogarSkaleneffekte, weil spezialisierte Fachkräfte Projektmanagement-Aufgaben übernehmen,die zuvor verteilt durchgeführt wurden.

Abschließend sei noch einmal darauf hingewiesen, dass dem PMO als Katalysator desProjektmanagements eine zentrale Rolle zukommt. Führungskräfte sollten weiterhin dar-auf achten, dass die in dieser Phase definierten und eingeführten Prozesse rigoros einge-halten werden. Es mag zwar immer wieder Ausnahmen von Regeln und Prozessverläufengeben, diese bedürfen aber stets der fachgerechten Prüfung undmüssen transparent doku-mentiert werden.

Literatur

1. Hill, G. M. (2007).The complete project management office handbook. Boca Raton, FL, USA: Au-erbach Pub.

2. Brennan, M. V., & Heerkens, G., R. (2009). How we went from zero project management to PMOimplementation – A real life story. In PMI Global Congress 2009 – North America. Proceedings.

Literatur 115

3. El Arbi, F., Ahlemann, F., & Kaiser, M. (2011). The effects of agency problems in the project or-ganization on IS project alignment. SSRN eLibrary.

4. Graham, D., Van Veenendaal, E., Evans, I., & Black, R. (2008). Foundations of software testing:ISTQB certification. London, UK:Thomson Learning Emea.

5. Turner, J. R. (2009).The handbook of project-based management. New York, NY, USA: McGraw-Hill Professional.

6. Project Management Institute (2004). A guide to the project management body of knowledge(3. Aufl.). Philadelphia, PA, USA: Project Management Institute.

7. Lin, C., & Pervan, G. (2003). The practice of IS/IT benefits management in large Australian or-ganizations. Information & Management 41(1), 13–24.

8. Eisenhardt, K. M. (1989). AgencyTheory: An Assessment and Review.Academy of ManagementReview 14(1), 57–74.

9. Kaiser, M., El Arbi, F., & Ahlemann, F. (2011). Strategic Project Portfolio Management: Under-standing the link between information and structure. SSRN eLibrary.

10. Mooney, C. Z. (1997).Monte Carlo simulation. New York, NY, USA: Sage Publications.

Strategisches Projektmanagement || Zentralisierung

Documents

Transcript of Strategisches Projektmanagement || Zentralisierung