Strategisches Projektmanagement || Standardisierung - Vom Chaos zur einheitlichen Projektabwicklung

4Standardisierung – Vom Chaos zur einheitlichenProjektabwicklung

Fedi El Arbi, Frederik Ahlemann und Michael Kaiser

Inhaltsverzeichnis

4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2 Elemente der Standardisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2.1 Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.2.2 Umfangsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.2.3 Zeitmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.2.4 Ressourcenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.2.5 Kostenmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2.6 Qualitätsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.3 Zusammenfassung & Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.1 Einleitung

In Organisationen mit geringem Projektmanagement-Reifegrad gibt es keine verbindli-chen Managementvorgaben für die Durchführung von Projekten. Die Entscheidung, obund wie Projektmanagement zur Anwendung kommt, obliegt in diesen Organisationendem (oft wenig erfahrenen) Projektmanager und so verwundert es nicht, wenn bewährteVerfahren und Techniken des Projektmanagements gar nicht oder nur rudimentär genutztwerden. Problematisch ist dies, weil die Projektabwicklung in solchen Fällen häufig erfolg-los bleibt. Typische Probleme sind:

F. El Arbi (B) ⋅ Prof. Dr. F. Ahlemann ⋅ 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]

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

mailto:[email protected]

60 F. El Arbi, F. Ahlemann, M. Kaiser

Geringe Kundenzufriedenheit: Werden die Anforderungen der Auftraggeber eines Pro-jektes nicht oder nur unzureichend erfüllt, liegt dies oft in abweichendenTerminologiendes Auftragnehmers und Auftraggebers oder fehlenden Abstimmungsmöglichkeiten(z. B. Workshops und Meetings) begründet. In der Folge kommt es zu divergieren-den, nicht explizierten Vorstellungen vomProjektergebnis [1]. Die Unzufriedenheit desKunden kann auch durch mangelhafte Planung des Projektumfangs und der Projektin-halte verursacht werden, was zu einer schlechten Qualität des Projektergebnisses führt.

Termin- und Budgetüberschreitungen: Abweichungen von geplanten Terminen undKosten sind in der Regel die Folge von schlechter Planung oder großer Volatilitätdes Projektumfelds (z. B. sich wandelnde Anforderungen). In der Folge kommt es zuhektischen Umplanungen und den berüchtigten „Feuerwehreinsätzen“: Es werden Res-sourcen und Budgets immer nur genau da verfügbar gemacht, wo es gerade „brennt“.

Mangelhafte Realisierung strategischer Ziele: DieUmsetzung der strategischenZiele desUnternehmens ist mangelhaft, weil Projekte ohne vorherige tiefer gehende Analysendurchgeführt werden (Business Case). Beispielsweise kommt es zu übereilten Reaktio-nen auf aktuelle Änderungen des Markt- oder Technologieumfeldes. Es werden Projek-te initiiert, die zwar eine Lösung für kurzfristige Probleme darstellen, mit der langfris-tigen Organisationsstrategie aber nicht übereinstimmen oder gar hohe Risiken für dieOrganisation darstellen. Die Abstimmung der Projekte mit der Organisationsstrategiewird in der Literatur als Strategic Fit [2] bezeichnet und hat je nach Branche und Pro-jekttyp verschiedene Ausprägungen: Bei IT-Projekten z. B. ist die Rede von Business-IT-Alignment [3]. Bei Produktentwicklungsprojekten muss das resultierende Produkt-portfolio die Marktpositionierung der Organisation widerspiegeln. Bei Vertriebs- undKundenprojekten wird die strategische Relevanz an der Profitabilität gemessen.

Um solche Probleme als Resultat schlechten Projektmanagements zumindern, standar-disieren Organisationen ihr Projektmanagement. Standardisierung bedeutet die Etablie-rung einheitlicher und verbindlicher Regeln, wie Projekte zu planen und zu steuern sind.Die Standardisierung des Projektmanagements hat drei übergeordnete Nutzeffekte:

Replikation erfolgreicherManagementansätze: Die Standardisierung erlaubt die Repli-kation erfolgreicher Managementansätze. Erweist sich z. B. eine Methode zum Um-fangsmanagement oder zur Aufwandsplanung als erfolgreich und nützlich, kann sieorganisationsweit genutzt und zum verbindlichen Standard in der Organisation erho-ben werden.

Transparenz und Vergleichbarkeit: Eine einheitliche Projektabwicklung macht Fort-schritte, Probleme und Erfolge von Projekten transparent und erlaubt so eine objektiveund vergleichende Beurteilung. Standardisierung ist damit auch eine notwendige Vor-aussetzung für die Zentralisierung des Projektmanagements. Diese wird in Kap. 5thematisiert.

Kompetenzentwicklung: Die Einführung von verbindlichen Richtlinien für das Mana-gement von Projekten zwingt Projektmanager und andere Projektbeteiligte dazu, sich

4 Standardisierung – Vom Chaos zur einheitlichen Projektabwicklung 61

Projektmanagement-Methoden anzueignen und einzuüben. Auf diese Weise bewirktsie eine schrittweise Kompetenzentwicklung bei den Beteiligten.

Fallbeispiel: Standardisierungsinitiativebei einemAnbieter vonEisenbahnsicherungstechnik

Die in diesem Fallbeispiel behandelte Organisation ist einer der Markführer im Bereichder Eisenbahnsicherungstechnik. Das Unternehmen beschäftigt knapp 300 Mitarbeiterund hat im Durchschnitt 30 IT-Projekte im Projektportfolio, die 6 Monate bis 2 Jahredauern.

Von 2004 bis 2009 wurde eine Initiative zur Standardisierung der Projektmanage-ment-Methodik und der Projektmanagement-Tools unter der Leitung eines Business-Improvement-Managers durchgeführt, der das Unternehmen zur dritten CMMI-Reifestufe geführt hat. Ausschlaggebend für diese Initiative waren:

• Schwierigkeiten aufgrund der verschiedenen Compliance-Vorgaben, unterschiedli-che Projekttypen zu steuern.

• Der Wunsch, Projektinformationen unternehmensweit zu analysieren.• Bestrebungen, das Ressourcenmanagement zu optimieren.

Der erste Schritt des Standardisierungsvorhabens war die Definition einer einheit-lichen Projektmanagement-Methodik. Dabei wurden die Branchenbesonderheiten undder Kontext der Anwendung derMethodik berücksichtigt: Die Standardisierung basier-te auf den Vorgaben des PMBoK [4], die an die Bedürfnisse der Organisation angepasstwurden. Darüber hinaus wurden für Produktentwicklungsprojekte, Anlagenbauprojek-te im Inland und Anlagenbauprojekte im Ausland jeweils unterschiedliche Variantender Methodik entwickelt. Ein Projektrollenmodell und einheitliche Budgetierungsvor-gaben wurden definiert. Weiterhin wurde ein Projektprozessmodell implementiert. DiePhasen den Ideengenerierung und der Projektauswahl wurden standardisiert und ein-heitliche Berichtsvorgaben etabliert.

Zur Unterstützung der neu etablierten Prozesse wurde eine geeignete Projektmana-gementsoftware beschafft und nach den Prozessvorgaben konfiguriert. So wurden bei-spielsweise gemäß den Methodikvarianten spezifische Projektvorlagen entwickelt undin der Software hinterlegt. Gleichzeitig wurde eine stochastische Netzplantechnik ein-geführt, wozu die Terminplanungsfunktionalität der Software angepasst wurde, und einProjektkennzahlensystem aufgebaut. Diese neue Funktionalität hat dazu beigetragen,die notwendige Projektplanungsdauer von knapp zwei Wochen auf ein paar Stundenzu reduzieren. Unternehmensweit werden die Projekte mit Hilfe einer Balanced Sco-recard gesteuert, für die die nötigen Projektdaten aus der Projektmanagementsoftwareentnommen werden.

Nach dem Abschluss der Softwareeinführung wurde ein Projekt zur Erhöhung desCMMI-Reifegrads der IT-Organisation gestartet. Im Rahmen dieses Projekts wurden


System- und Software-Engineering-Prozesse neu definiert und Risikomanagementme-thoden eingeführt.

Im folgenden Abschnitt werden typische Projektmanagement-Aufgaben vorgestellt, dieim Rahmen einer Standardisierung vereinheitlicht werden. Der Schwerpunkt dieses Ka-pitels liegt dabei nicht auf der ausführlichen Erklärung dieser Aufgaben. Detaillierte In-formationen hierzu können der einschlägigen Projektmanagement-Literatur entnommenwerden (z. B. [4–6]). Es geht vielmehr darum, darzustellen, worauf in der Phase der Stan-dardisierung zu achten ist. Insbesonderewird dieRolle von Führungskräften diskutiert undBranchenunterschiedewerden erläutert. Im letztenAbschnitt werden dieKernaussagen desKapitels und die Empfehlungen für die Führungsebene zusammengefasst.

4.2 Elemente der Standardisierung

4.2.1 Vorgehensmodell

Das vermutlich wichtigste Element der Standardisierung ist die Vereinheitlichung der Pro-jektabwicklung in Form von definierten Phasen,Meilensteinen oder Vorgängen. Dazuwirdein Projektvorgehensmodell spezifiziert, das oft zusätzlich Methoden und Techniken fest-legt, die während des Ablaufs eines Projektes zur Anwendung kommen sollen. Es gibt eineVielzahl vonVorgehensmodellen für die unterschiedlichsten Projekttypen undRahmenbe-dingungen. Beispiele können Tab. 4.1 entnommenwerden. Einheitliche Vorgehensmodellesind von besonderer Bedeutung, weil sie die Vergleichbarkeit von Projekten ermöglichenund zugleich die Steuerung der Projekte für den Projektsponsor und die Kontrollgremieneinfacher machen. Zu einem Vorgehensmodell gehören üblicherweise die folgenden Ele-mente:

Begriffssystem: Dieser Punkt umfasst die Projektmanagement-Terminologie, die für dieBeschreibung des Vorgehensmodells und für die Kommunikation zwischen den ver-schiedenen Projektbeteiligten eingesetzt wird.

Phasen: Mit Hilfe eines Vorgehensmodells werden die Projekte in Phasen gegliedert. Pro-jektphasen werden meist mit dem Erreichen eines Meilensteins beendet.

Meilensteine: ImProjektmanagement sindMeilensteineZwischenziele eines Projektes, diefür die Erreichung des Projektergebnisses von besonderer Bedeutung sind und für dieMessung des Projektfortschritts genutzt werden.

Checklisten: Mittels Checklisten wird geprüft, ob nach Abschluss einer Phase bzw. beiErreichen eines Meilensteins die notwendigen Zwischen- und Endergebnisse in der er-forderlichen Qualität vorliegen.

Rollenmodell: Ein Rollenmodell legt die Verantwortlichkeiten für die verschiedenen Auf-gaben während der Projektabwicklung fest.


Die in der Literatur vorgeschlagenen Vorgehensmodelle werden in den meisten Fällen vonOrganisationen nicht unmittelbar verwendet, sondern erst an organisationsspezifischeGe-gebenheiten angepasst. Zu den typischen Faktoren, die bei einer Anpassung zu berücksich-tigen sind, gehören:

Vorkenntnisse: In der Regel verfügen die Projektstakeholder über (rudimentäre) Projekt-management-Vorkenntnisse.Wird einVorgehensmodell gewählt, das diesenVorkennt-nissen nahe kommt oder wird es entsprechend angepasst, ist mit höherer Akzeptanz zurechnen.

Kultur: Eine spezifische Führungskultur kann Einfluss darauf haben, wie ein Vorgehens-modell ausgestaltet wird. Ist in einer Organisation ein eher hierarchischer Führungsstiletabliert und legen Führungskräfte dementsprechend viel Gewicht auf Planung undKontrolle, wird ein Vorgehensmodell anders gestaltet als in einer von unternehmeri-schem und eigenverantwortlichem Denken und Handeln geprägten Organisation.

Organisatorische Rahmenbedingungen: Bestehende Abläufe und Organisationsstruk-turen sind bei der Ausgestaltung eines Vorgehensmodells zu berücksichtigen. Sokann es sinnvoll sein, bestehende Rollen in das Vorgehensmodell zu integrieren oderSchnittstellen zu bestehenden Planungs- und Steuerungsprozessen zu schaffen (z. B. zuControlling- oder Beschaffungsprozessen).

Bei der Implementierung eines Vorgehensmodells haben sich die folgenden Leitlinienbewährt:

• Als Grundmuster empfiehlt es sich, Phasen bzw. Meilensteine stets mit der Bereitstel-lung prüfbarer Ergebnisse zu verbinden. Diese sollten durch Steuerungsgremien formalabgenommen werden, bevor die Weiterarbeit mit der nächsten Phase möglich ist. DieAbnahme wird durch Vorlagen und Checklisten unterstützt bzw. strukturiert.

• In vielen Fällen bietet es sich an, für verschiedene Projekttypen unterschiedliche Vor-gehensmodelle zu definieren. Dadurch kann man vermeiden, dass die Abwicklung ei-nes Projektes anhand eines Vorgehensmodells zu einem übermäßig bürokratischen Aktwird. Beispielsweise haben vieleUnternehmen spezielle schlankeVorgehensmodelle fürkleine Projekte.

• Das Vorgehensmodell sollte in der Regel nicht mehr als zehn Phasen bzw. Meilensteinebeinhalten. Bei einer großen Anzahl an Phasen und Meilensteinen steigt der Aufwandbei der Projektsteuerung.

• Die Phasen sollten nicht zu lang oder zu kurz sein, um eine angemessene Steuerung zuermöglichen.

• Das Vorgehensmodell sollte schlank gestaltet werden. Bei einem komplizierten Modellverlieren die Projektstakeholder die Übersicht und es steigt der Lernaufwand, was dieAkzeptanz für das Modell senken kann (siehe Kap. 3).


Tab.

4.1

Beisp

ielhaft

eVorgehensmod

elle

Projektty

pMod

ell

VereinfachteDarstellung

Prod

uktent-

wicklun

gWearnes

Lebenszy-

klus-M

odel

Dem

and

Res

earc

hE

valu

atio

n

Des

ign

Dev

elop

men

tM

aint

enan

ce

Con

tract

sU

se

Con

stru

ctio

nC

omm

issi

onin

g

Rec

ords

Stu

dy

[6]

DiesesM

odellw

urde

vonStephenWearneentwickeltun

dorientiertsic

han

dem

Prod

uktlebenszyklus.


Tab.

4.1

Fortsetzun

g

Projektty

pMod

ell


Prod

uktent-

wicklun

gKotlersMod

ell

Idea

gen

erat

ion

Scre

enin

gD

evel

opm

ent

& te

stin

gM

arke

ting

stra

tegi

e

Busi

ness

anal

ysis

Prod

uct

deve

lopm

ent

Mar

ket t

estin

gCo

mm

erci

aliz

atio

n[6]

DiesesM

odellw

urde

vonPh

ilipKotlere

ntwickelt.Be

idiesem

Mod

ellkön

nenMitarbeiterjederzeitProjekti-

deen

einb

ringen

unddamitdenProjektprozessanstoß

en.

Prod

uktent-

wicklun

gStage-Gate-Mod

ell

M0

Idea

App

rove

d

M0

Idea

App

rove

d

M1

Pro

ject

Aut

horiz

ed

M1

Pro

ject

Aut

horiz

ed

M2

Pro

ject

Agr

eed

M2

Pro

ject

Agr

eed

M3

Pro

duct

Pro

cess

Des

ign

Rel

ease

d

M4

Pro

duct

ion

Par

t App

rove

d

M5

Dev

elop

men

t P

roje

ct C

lose

d

M6

M7

Phas

e 0

Idea

Sel

ectio

n

Phas

e 5

Pro

duct

ion

Ram

p-up

Phas

e 4

Intro

duct

ion

To P

rodu

ctio

nD

esig

nV

alid

atio

nPh

ase

3P

roto

typi

ngPh

ase

2C

once

pt

Dev

elop

men

t

Phas

e 1

Acq

uisi

tion

& Q

uota

tion

Phas

e 6

Ser

ies

Pro

duct

ion

&M

aint

enan

ce

Phas

e 7

Orig

inal

E

quip

men

tS

ervi

ces

Idea

Eva

luat

ion

Des

ign

Pro

duct

ion

[Abb

ildun

gangelehn

tandenGating-Prozesse

ines

deutschenAutom

obilzulieferers]

Das

Stage-Gate-Mod

ellw

urde

vonRo

bertG.C

oopere

ntwickelt.Be

idiesem

Vorgehensm

odellsteht

die

Kon

trollederQ

ualitätderP

rojektergebn

isseim

Vordergrun

d.


Tab.

4.1

Fortsetzun

g

Projektty

pMod

ell


ITWasserfallm

odell

Ana

lyse

Ent

wur

f

Rea

lisie

rung

Initi

alis

ieru

ng

Nut

zung

Ein

führ

ung

[6]

Das

Wasserfallm

odellw

urde

vonWinston

W.R

oyce

entwickelt.Dieursprüng

liche

VariantediesesMod

ell

enthieltkeineRü

ckkopp

lung

zwischen

denProjektphasen.

Um

Fehler

aufd

ernächsthö

herenStufebeheben

zukönn

en,w

urdendem

Mod

elln

achträglichIte

ratio

nsschleifenhinzugefüg

t.


Tab.

4.1

Fortsetzun

g

Projektty

pMod

ell


ITV-M

odell

Sys

tem

-A

nfor

deru

ngsa

naly

se

Sys

tem

arch

itekt

ur

Sys

tem

entw

urf

Sof

twar

earc

hite

ktur S

oftw

aree

ntw

urf

Uni

t-Tes

ts

Inte

rgra

tions

test

s

Sys

tem

inte

grat

ion

Abn

ahm

e un

d N

utzu

ng

[7]

Das

V-M

odellw

urde

vonBa

rryBo

ehm

entwickelt.DieBe

sond

erheitdiesesMod

ellsist

dieEins-zu-Eins-

Gegenüb

erstellung

vonEn

twurfs-u

ndTeststufen.


Tab.

4.1

Fortsetzun

g

Projektty

pMod

ell


ITSpiralmod

ell

Laun

ch

Ris

k

Con

cept

Req

uire

men

tslif

e-cy

cle

plan

sR

equi

re-

men

tsV

alid

atio

nD

evel

opm

ent

plan

Ris

kA

sses

smen

t

Ris

k

Pro

duct

desi

gn

Val

idat

ion

Inte

grat

ion

& T

est

plan

Ris

kA

sses

smen

t

Ris

kA

sses

smen

t

Mai

nten

ance

plan

Det

ail

desi

gn

Cod

e

Uni

t tes

t

Acc

epta

nce

test

Sys

tem

bu

ildS

yste

m te

st

Ope

ratio

nal

Pro

toty

ping

Ope

ratio

nal

Pro

toty

ping

Sim

ulat

ions

, mod

els,

ben

chm

arks

Eval

uate

al

tern

ativ

es

Dev

elop

/ver

ify

next

leve

lPl

an n

ext s

tage

Det

erm

ine

obje

ctiv

es

[7]

DiesesM

odellw

urde

ebenfalls

vonBa

rryBo

ehm

entwickelt.Jede

SchleifederS

piralegeht

durchvier

Teil-

schritte:Definitio

nderZ

iele,EvaluationderA

lternativen,E

ntwicklun

gun

dTesten

dern

euen

Prod

uktstufe

sowiePlanun

gdern

ächstenPh

ase.


Tab.

4.1

Fortsetzun

g

Projektty

pMod

ell


ITSC

RUM

Spr

int (

Dev

elop

men

t)

Sp

rin

t B

ackl

og

Use

r Sto

ry m

Use

r Sto

ry 1

Use

r Sto

ry 2

. . .

Req

uire

men

ts u

pdat

e

Pro

du

cd B

ackl

og

[11]

SCRU

Mist

eine

agile

Softw

areentwicklun

gsmetho

de,dievonKen

Schw

aber

undMikeBe

edleform

alisiert

wurde.B

eiSC

RUM

wird

dieProjektdauer

insogenann

teSprin

tsaufgeteilt.Der

SatzvonFu

nktio

nen,

diein

einem

Sprin

timplem

entie

rtwerdensollen,

wird

dem

sogenann

tenProductB

acklog

entnom

men.


AufgabenbeschreibungProjekt:

Ziele

Datum:

AufgabenVoraussetzungen

Name of Task: Start Date: End Date:

Schnittstellen

Ressourcen

Kosten

Bemerkungen

QualitätsanforderungenErwartete Ergebnisse

Verantwortlich:__________________ QM Manager: __________________

VerantwortlicherKernaktivität: __________________

Fertig am:_____________

Q geprüft am:______________

Aufgabenbeschreibung

Projekt:

Ziele

WBS-ID:

AufgabenVoraussetzungenAuftrag: Startdatum: Enddatum:

Schnittstellen

Ressourcen

Kosten

Bemerkungen

QualitätsanforderungenErwartete Ergebnisse

Verantwortlich: ______________ Qualitätsmanager: _____________

VerantwortlicherKernaktivität: __________________

Fertig am:_____________

Q geprüft am: ______________

Aufgaben-ID:

Abb. 4.1 Arbeitspaketbeschreibung

4.2.2 Umfangsmanagement

Laut PMBoK [4] umfasst das Projektumfangsmanagement alle Prozesse, die garantieren,dass während des Projektes die notwendigen Arbeitspakete bearbeitet werden. ImWesent-lichen beschäftigt sich das Projektumfangsmanagement mit der Definition und Steuerungder Inhalte, die Bestandteil des Projekts sind. Zum Umfangsmanagement gehört die De-finition einer Projektstruktur (engl. Work Breakdown Structure) und eines Einsatzmittel-strukturplans (engl. Resource Breakdown Structure).

Zur Standardisierung von Projektmanagement gehören Regeln, wie der Projektumfangerfasstwird undwie die Strukturpläne zu erstellen sind.DieArbeit der Projektleiter kann indiesemZusammenhang deutlich vereinfacht werden, indemStandardpläne für die Projekt-struktur entwickelt und bereitgestellt werden. Hierbei kann zwischen Pflicht- undWahlar-beitspaketen unterschiedenwerden.Umein gemeinsamesVerständnis für dieArbeitpaketesowie eine Basis für ein einheitliches Projektcontrolling zu schaffen, sollten die Arbeitspa-kete einheitlich beschrieben werden. Ein Beispiel für eine Beschreibung von Arbeitspa-keten ist in Abb. 4.1 zu finden.

Bei der Klärung, wie der Projektumfang zu definieren ist, kann ein Rollenmodell fürTransparenz sorgen. Mit einem einheitlichen Rollenmodell werden die Verantwortlichkei-


ProjektmanagerProjektauftraggeber / Kunde

Anforderungsmanager

Vertragsmanager

Experte

Kommunikation der Anforderungen

Anforderungskatalogliefern

Projektstrukturplanliefern

Projektstrukturplan-Vertrag-Abgleich

Unterstützung bei der Definition des Projektstrukturplans

Abb. 4.2 Beispielhaftes Rollenmodell

ten für die verschiedenen Umfangsmanagement-Aktivitäten im Vorfeld klar definiert. Einbeispielhaftes Rollenmodell wird in Abb. 4.2 dargestellt.

Im Rahmen des Umfangsmanagement-Prozesses entstehen verschiedene Dokumente(z. B. Anforderungskatalog, Projektplanentwurf). Um den Aufwand für die Anfertigungdieser Dokumente zu reduzieren sowie die Steuerung der Projekte einheitlicher und einfa-cher zu gestalten, sollten Vorlagen für diese verschiedenen Dokumente entwickelt werden.In Tab. 4.2 werden verschiedene Dokumentvorlagen beispielhaft aufgeführt.

Je nach Branche können sich die Umfangsmanagement-Praktiken unterscheiden. Beiagilen Methoden, die zunehmend in IT-Projekten zum Einsatz kommen, wird der Projek-tumfang nicht definiert, da die Projektanforderungen sich während der Projektdurchfüh-rung ändern können. Das Umfangsmanagement beschränkt sich einzig und allein darauf,die Anforderungsliste aktuell zu halten und den Erfüllungsgrad der Anforderungen imAu-ge zu behalten. Bei anderen Projekttypen (oder auch bei nicht agilen IT-Projekten)wird derProjektumfang klar definiert.

Bei der Implementierung vonUmfangsmanagement haben sich die folgenden Leitlinienbewährt:

• Erfahrene Projektleiter sollten einbezogen werden, da sie sich mit bestehenden Abläu-fen, Praktiken, Best Practices und potentiellen Problemen gut auskennen. Sie könnendamit wertvolle Hinweise für die Entwicklung sinnvoller Vorlagen geben. Darüber hin-aus können sie während des Veränderungsprozesses als Fachpromotoren fungieren.

• Vorlagen sollten pragmatisch gestaltet werden. Ihre Detaillierung sollte soweit erfol-gen, dass sie eine echteHilfestellung für Projektmitarbeiter darstellen und eine sinnvolle


Tab. 4.2 Beispielhafte Dokumentenvorlagen

Name BeschreibungAnforderungskatalog [4] Sammlung aller Anforderungen an das Projekt. Es wird erklärt, wie

die Anforderungen mit den Projektzielen zusammenhängen.Spezifikations-dokument [4]

Detaillierte Beschreibung der lieferbaren Ergebnisse und des Auf-wands für deren Erstellung, um ein gemeinsames Verständnis derProjektziele zwischen den Projektstakeholdern zu schaffen.

Projektstrukturplan [4] Hierarchische Unterteilung des Projektes in Arbeitspakete. Mit dieserVorlage wird eine äquivalente Beschreibung der Aufgabenpakete aufeinheitlichem Detaillierungsniveau gewährleistet.

Entwurfsdokument (beiSoftwareprojekten)

Skizze der Struktur der Projektergebnisse basierend auf den Anforde-rungen. Bei einem Softwareprojekt z. B. besteht dieses Dokument auseiner Beschreibung der Softwarestruktur und deren Komponenten.

Testprotokoll Dokumentation des Tests der Projektergebnisse. Testfälle sowie dieErgebnisse und die Anmerkungen des Testers werden aufgeführt.

Projektvertrag Gegenseitige Selbstverpflichtung zur Koordination und Regelung desVerhaltens der Projektpartner.

Risikocheckliste Eine Auflistung aller Projektrisiken, der Wahrscheinlichkeit ihresEintritts und der dadurch entstehenden Kosten.

Projektsteuerung ermöglichen. Eine darüber hinausgehende Bürokratisierung der Pro-jektabwicklung sollte vermieden werden.

• Als Faustregel gilt, dass für jede Phase aus dem Vorgehensmodell mindestens eine Vor-lage für die Ergebnisdokumentation entwickelt werden sollte.

Fallbeispiel: Umfangsmanagement bei einemDienstleistungsunternehmenIn der IT-Abteilung eines Dienstleistungsunternehmens wurde ein Projektphasenmo-dell entwickelt. Dieses Modell definiert die Phasen, die ein Projekt durchlaufen muss,sowie die Arbeitspakete, die in jeder Phase erledigt werden sollen. Es legt auch dieDokumente fest, die in jeder Projektphase zu erstellen sind. Im Folgenden werden aus-zugsweise die Ergebnisdokumente der ersten drei Projektphasen vorgestellt:

Phase Dokument BeschreibungAnfangsphase Gesprächs-

leitfadenProjekteva-luierung

Dieses Dokument enthält eine Beschreibung der Projektaus-gangssituation, -idee, -ziele und -voraussetzungen sowie eineEinschätzung des Projektbudgets, -nutzens und der Prozesskos-ten.

Mission-State-ment

In diesem Dokument werden die wichtigsten Projektziele und-anforderungen festgelegt.


Phase Dokument BeschreibungVorbereitungs-phase

Projektcharter In einer ersten Näherung werden die Projektprobleme, dasProjektziel sowie der Projektumfang beschrieben und der Pro-jektaufwand geschätzt.

Projektkalku-lation

In diesem Dokument werden die Projektaufwände, -kosten undder Projektnutzen erfasst.

Projektbe-schreibung

Dieses Dokument fungiert als Vertrag zwischen dem Auftrag-geber und dem Auftragnehmer. Es umfasst folgende Punkte:Ausgangssituation, Aufgabenstellung, Projektmeilensteine,Ergebnisse, Projektabhängigkeiten, Projektorganisation, Kom-munikation, Verantwortlichkeiten und Risiken.

Stakeholder-analyse

In diesem Dokument werden alle wesentlichen Projektstakehol-der und deren Einstellung zum Projekt erfasst. Es werden auchMaßnahmen zur Einbindung dieser Stakeholder abgeleitet.

Risikoanalyse Zweck dieses Dokumentes ist die Identifikation der Risiken,deren Eintrittswahrscheinlichkeiten und Auswirkungen sowiedie Entwicklung von Gegenmaßnahmen.

Projektplan In diesem Dokument werden die Dauer, Kosten und notwendi-gen Ressourcen für jedes Arbeitspaket ermittelt.

Analysephase Fachliche An-forderungen

Dieses Dokument dient der Analyse der Anforderungen desAuftraggebers.

System Re-quirementSpecification

In diesem Dokument werden die nichtfunktionalen Anfor-derungen an das Projekt spezifiziert (z. B. Verfügbarkeit,Performance).

FunctionalRequirementSpecification

Das Dokument wird für die Spezifizierung der funktionalenAnforderungen an das Projekt genutzt (z. B. technische Aspek-te, gesetzliche Anforderungen).

Grobkonzept In diesem Dokument wird ein möglicher Lösungsansatz skiz-ziert zwecks Abstimmung mit dem Auftraggeber.

Testanforde-rungen

In diesem Dokument werden die Anforderungen an die Testsformuliert und eine Teststrategie entwickelt.

4.2.3 Zeitmanagement

Zeitmanagement beschäftigt sich mit der Planung und Überwachung der Zeit, die für dieDurchführung eines Projektes erforderlich ist [4]. Es umfasst die Identifikation der Ab-hängigkeiten zwischen den Arbeitspaketen bzw. Vorgängen, der notwendigen Ressourcenund der Dauer von Arbeitspakten bzw. Vorgängen sowie die Erstellung und Steuerung desZeitplans.

Im Rahmen der Standardisierung sind auch Regeln für das Zeitmanagement zu definie-ren. Diese Regeln können entweder für alle Projekte gelten oder werden für verschiedeneProjekttypen festgelegt. Von zentraler Bedeutung ist die Festlegung des Terminplanungs-verfahrens (z. B. Critical Path Method (CPM) [4] oder Program Evaluation and Review


Technique (PERT) [4]). Grundsätzlich existieren sowohl Verfahren, die eine vollständi-ge Planung erfordern, als auch solche, die auf eine exakte Terminplanung verzichten. Zuletzteren gehören bspw. die agilen Methoden. Diese folgen einer flexiblen Planungsphilo-sophie, bei der die Arbeitspakete nicht im Vorfeld vollständig definiert werden und dieReaktion auf Veränderungen wichtiger ist als die Verfolgung eines Plans. Organisationenkönnen sich auch für hybride Strategien, d. h.Mischformen entscheiden. BeispielhafteZeit-management-Techniken sind aus Tab. 4.3 ersichtlich.

Für die Steuerung des Terminplans sind in der Regel drei Planungsstände notwendig:

• Der Basisplanwurde ursprünglich in der Projektplanungsphase genehmigt.• Der Soll-Plan ergibt sich aus dem genehmigten Plan und allen genehmigten Planände-

rungen.• Der Ist-Plan spiegelt den tatsächlichen Projektstand wider.

Bei der Standardisierung des Zeitmanagements ist neben der Auswahl der Planungs-technik noch eine Reihe weiterer Aspekte zu diskutieren und festzulegen:

Detaillierungsgrad: Projekte können stunden-, tages-, wochen- oder monatsgenau ge-plant werden. Wir empfehlen, den Detaillierungsgrad in Abhängigkeit von den Erfor-dernissen des Projektes festzulegen: Bei Projekten, die routiniert von einerOrganisationabgewickelt werden können, ist der Nutzen einer detaillierten Planung begrenzt, da dieOrganisation über genügend Erfahrung verfügt. Bei riskanten Projekten oder bei Res-sourcenknappheit (z. B. Spezialmaschinen bei Bauprojekten) ist es sinnvoll, die Projektefeingranular zu planen, um Ressourcenkonflikte und -engpässe zu vermeiden. Grund-sätzlich ist zu beachten, dass die Volatilität eines Projektplans mit der Detaillierungsteigt, was einen Mehraufwand für die Überarbeitung der Pläne nach sich zieht. EinWartungsprojekt imAnlagenbau z. B. wird aufgrund des Termindrucks und der Sicher-heitsanforderungen sehr detailliert ggf. bis auf die Ebene von Stunden geplant. Ein IT-Projekt ist hingegen in der Regel sehr viel schlechter planbar und wird oft nur grobgeplant.

Aktualisierungsintervall: Selten werden Projekte exakt so abgewickelt wie sie geplantwurden. Aus diesem Grund ist festzulegen, in welchen Intervallen Aktualisierungender Planung vorgenommen werden sollen.Wie zuvor sind die Aktualisierungsinterval-le in der Praxis sehr unterschiedlich. Meist orientieren sich diese an Steuerungs- undBerichtserfordernissen, d. h. Pläne werden aktualisiert, wenn die neuen Plandaten fürdas Berichtswesen bzw. Steuerungssitzungen benötigt werden.

Steuerungstechniken: Der zeitliche Ablauf von Projekten muss überwacht und gesteu-ert werden. Hierzu bedarf es Plan/Soll/Ist-Vergleichen, um Abweichungen frühzeitigzu erkennen und geeignete Maßnahmen anstoßen zu können. Für diese VergleicheundAbweichungsanalysen stehen verschiedene Techniken zur Verfügung, die teilweise


Tab. 4.3 Beispielhafte Zeitmanagement-Techniken

Name Beschreibung Vor-/Nachteile (+/−)Meilensteine undMeilenstein-Tren-danalyse (MTA)(siehe Abb. 4.3)

Bei der MTA werden zu Beginneines Projektes Meilensteine de-finiert und regelmäßig durch einBerichtswesen überwacht. Re-gelmäßige Neuschätzungen derMeilensteintermine sowie der Ver-gleich aktueller und ursprünglicherTermine erlauben eine Beurteilungdes Projektfortschrittes.

+ Erhöhte Kontrolle des Projektes+ Pläne sind einfach+ Planungssicherheit− Fehlende Flexibilität

CPM/PERT undProgrammmanage-ment [4]

Mit diesenMethoden wird für jedeProjektaktivität das Start- und End-datum ermittelt. Pufferzeiten werdenfür jede einzelne Aktivität berechnet.

+ Die terminbestimmende logischeKette kann ermittelt und die Pro-jektdauer durch den Eingriff indiesen kritischen Pfad minimiertwerden

+ Hohe Genauigkeit der erzeugtenTerminpläne

− Ressourcenbeschränkungen wer-den nicht berücksichtigt

− Projektplaner tendieren dazu, dieProjektaktivitäten aufzublähenund die Pufferzeiten zu verbrau-chen

Critical Chain [8] Bei CC wird der Projektplan zuerstähnlich wie bei CPM berechnet unddann erfolgt im zweiten Schritt eineRessourcennivellierung. Es wirdein Gesamtprojektzeitpuffer für alleProjektaktivitäten berechnet.

+ Effizienteres Puffermanagement+ Schnellere Projektabwicklung+ Berücksichtigung der Ressour-

cenbeschränkungen− Hohe Komplexität− Besondere Anforderungen an die

Kultur und an den Führungsstil

Agile Methoden [9] Bei den agilen Methoden sind keinefeingranularen Planungsmaßnahmenvorgesehen. Es wird nicht viel Wertauf Kontrolle und stringente Projekt-planung gelegt. Die agilen Methodenhingegen basieren auf Vertrauen undsetzen eine hohe Kompetenz derEntwickler voraus.

+ Motivation des Entwicklungs-teams durch Selbstorganisation

+ Qualitätssteigerung+ Produktivitätssteigerung− Unbestimmte Projektpläne− Probleme bei der Projektfort-

schrittmessung

auch die Kosten bzw. Aufwände des Projektes einbeziehen, um zeitliche Abweichungeninterpretierbar zu machen. Derartige Analysen werden beispielsweise von der EarnedValue Analyse (EVA) [4] unterstützt.


Abb. 4.3 BeispielhafteMei-lensteintrendanalyse [http://upload.wikimedia.org/wikipedia/de/2/2d/MTA2.png]

Für das Zeitmanagement empfehlen wir folgende Leitlinien:

• Halten Sie die Vorgaben für die Projektmanager schlank. Definieren Sie das Zeitmana-gement nur insoweit, als es für die übergeordnete Steuerung von Projekten erforderlichist (d. h. die Beurteilung des Projektes und die Vergleichbarkeit von Projekten müssendurch diese Praktiken möglich werden). Darüber hinaus sollten Sie den Projektleiterndie Möglichkeit geben, die Planung nach eigenen Vorstellungen auszuarbeiten. EineAusnahme stellen Projekte dar, in denen sehr viele Ressourcenabhängigkeiten bestehen.In solchen Fällen könnten straffe Vorgaben entscheidend sein, um einen reibungslosenProjektverlauf zu gewährleisten.

• Analysieren Sie, ob es sinnvoll ist, einheitliche Vorgaben für alle Projekte zu definie-ren oder ob ggf. komplexere Zeitmanagement-Ansätze nur für größere Projekte vorge-schrieben werden.

• Anfänger tendieren dazu, sich in sehr detaillierten Zeitplänen zu verlieren. Seien Siesich der Problematik detaillierter Zeitpläne bewusst (Volatilität, Änderungsaufwand)und fördern Sie ein pragmatisches Zeitmanagement.

http://upload.wikimedia.org/wikipedia/de/2/2d/MTA2.png





Abb. 4.4 Ressourcenstruktur und Ressourcenzuweisung

4.2.4 Ressourcenmanagement

Ressourcenmanagement umfasst die Prozesse zur Organisation, Steuerung und Führungder Projektressourcen (z. B. Mitarbeiter, Maschinen, Materialien, Betriebsstoffe, Werkzeu-ge oder Flächen) [4]. Hierzu gehören die Zuweisung von Rollen und Zuständigkeiten fürdie Projektdurchführung an die Mitglieder des Projektteams, die Zuordnung der notwen-digen Ressourcen zu den Arbeitspaketen und die Behebung von Ressourcenkonflikten, dieauftreten können, wenn dieselben Ressourcen von mehreren Projekten in Anspruch ge-nommen werden sollen.

Bei der Einführung des standardisiertenRessourcenmanagements sind die nachstehen-den Punkte zu adressieren:

Ressourcenstrukturen: Bevor mit der Definition von Planungs- und Steuerungstechni-ken begonnen wird, bietet es sich an, die Ressourcenstruktur zu vereinheitlichen. Untereiner Ressourcenstruktur wird ein meist hierarchisches Verzeichnis aller zur Verfü-gung stehenden Ressourcen verstanden. Eine einheitliche Ressourcenstruktur ist dieVoraussetzung dafür, dass Ressourcenpläne nachvollziehbar und vergleichbar werden,was die Projektsteuerung erleichtert. Eine beispielhafte Form der Ressourcenstrukturist in Abb. 4.4 dargestellt. Für eine effiziente Planung ist es darüber hinaus unerlässlich,Ressourcen eindeutig zu identifizieren. Dies kannmit Ressourcen-Identifikationsnum-mern (IDs) erreicht werden.

Struktureller Detaillierungsgrad: Grundsätzlich kann die Planung und Steuerung vonRessourcen auf verschiedenen Ebenen der Detaillierung erfolgen, z. B. auf der Ebene


der Organisationseinheiten, Ressourcengruppen oder Einzelressourcen.Wenngleich esletztlich demProjektmanager überlassen sein sollte, welchesDetaillierungsniveau er fürseine Planung anstrebt, sollten im Rahmen der Standardisierungsphase Empfehlungenerarbeitet werden. In Abhängigkeit vom angestrebten Detaillierungsgrad fällt auch dieRessourcenstruktur komplex oder weniger komplex aus. Wie beim Zeitmanagementauch stehen den Vorteilen einer hohen Detaillierung (und damit einem hohem Maßan Transparenz) große Planvolatilität sowie enormer Planungsaufwand gegenüber. Ei-ne detaillierte Ressourcenplanung kommt nur in Frage, wenn die Projekte entwedersehr komplex sind oder aber unter sehr stabilen Rahmenbedingungen abgewickelt wer-den. Es ist zu beachten, dass für personenbezogene Ressourcenplanung grundsätzlichdie Zustimmung des Betriebsrats notwendig ist, da eine solche Planung prinzipiell eineLeistungskontrolle ermöglichenwürde. Dieses Einverständnis istmöglichst früh einzu-holen, damit verdeutlicht werden kann, dass die Leistungskontrolle keinesfalls das Zieldieses Vorhabens ist, sondern die Verhütung geplanter Überlastung.

Ressourcenklassifikation: Zur Vereinfachung der Suche nach geeigneten Ressourcen fürein Projekt ist es sinnvoll, diese zu klassifizieren. Bei Personalressourcen wird die Klas-sifikation in der Regel anhand von Kompetenzen und Fähigkeiten oder auch gemäß desStandorts erfolgen. Bei technischen Ressourcen sind es meist Leistungsmerkmale. Einentsprechendes Klassifikationssystem sollte parallel zur Ressourcenstruktur aufgebautwerden. Einzelne Klassifikationsmerkmale können dann den Ressourcen zugewiesenwerden.

Zeitlicher Detaillierungsgrad: Auch beim Ressourcenmanagement ist der zeitliche De-taillierungsgrad der Planung festzulegen. Ressourcen können monatsgenau, wochen-genau, tagesgenau oder sogar stundengenau geplant werden. Auch bei der Ressourcen-planung gilt, dass ein Mittelweg zwischen Genauigkeit der Planung auf der einen Seiteund Volatilität und Aufwand auf der anderen Seite gefunden werden muss (siehe Ab-schn. 4.2.3.

Je nach Projekttyp unterscheiden sich die Arten der Ressourcen: es können Maschi-nen, Rohstoffe, Zukaufkomponenten, Personal, Prüfstände oder auch Flächen sein. DieseRessourcenarten haben Auswirkungen auf die Beschaffungs-, Planungs- und Steuerungs-prozesse eines Projektes: Bei einem Bau-/Anlagenbauprojekt z. B. steht das Beschaffungs-und Lieferantenmanagement im Vordergrund, da Komponenten bestellt, Maschinen ge-bucht, Gewerke beauftragt und Materialien beschafft werden müssen. Bei einem Softwa-reentwicklungsprojekt geht es fast ausschließlich um Personalressourcen und das Beschaf-fungsmanagement ist deshalb oft nicht derart ausgeprägt.

Fallbeispiel: Grobe Planung bei SoftwareprojektenEin Softwareprojekt wird üblicherweise wie folgt geplant: AmAnfang des Projektes legtman das Budget und die Dauer festgelegt und sammelt die Anforderungen an das Pro-jekt.


Werden agile Methoden für das Projekt eingesetzt (wie z. B. SCRUM), wird keindetaillierter Projektplan definiert, da bei diesen Methoden die Reaktion auf die Ände-rungen der Projektrahmenbedingungen wichtiger als das Verfolgen von Projektplänenist.

Bei klassischen Projektmanagement-Methoden hingegen wird das Projekt in Pha-sen,Aktivitäten undArbeitspakete (jedoch auf einem relativ hohenAbstraktionsniveau)gegliedert. Der zeitliche Ablauf des Projektes sowie die Projektmeilensteine werden de-finiert. Es werden im Anschluss die Verantwortlichkeiten für die Bearbeitung der Ar-beitspakete festgelegt. ImLaufe des Projektes wird der Projektfortschritt beobachtet unddementsprechend die Pläne angepasst.

Fallbeispiel: Sehr feine Planung bei Revisionsprojekten für kerntech-nische Anlagen

Bei Kernkraftwerk-Revisionsprojekten spielt die Sicherheit der Anlage und der Mitar-beiter eine übergeordnete Rolle. Aufgrund der wirtschaftlichen Bedeutung eines Kern-kraftwerkes (finanziell und in Bezug auf die Versorgungssicherheit) müssen Revisions-projekte schnell abgewickelt werden. Die typische Dauer eines Revisionsprojektes liegtbei 20 Tagen.Während dieser Zeit werden 3000 bis 4000 Vorgänge auf die Stunde genauabgearbeitet. Bis zu 100 Vorgänge können parallel ablaufen. Bis zu 1500 Fachkräfte vonca. 100 Dienstleistern sind an solchen Projekten beteiligt.

Um den Zeitdruck bei derartigen Projekten bewältigen zu können und den Sicher-heitsanforderungen gerecht zu werden, werden alle Vorgänge und ihre zeitlichen Ab-hängigkeiten bis ins letzte Detail exakt geplant und optimiert. Die Planung eines Revisi-onsprojektes dauert in der Regel ein Jahr. Der terminkritische Pfad bei diesen Projektenwird ohne jeglichen Puffer geplant. Ein Kernteam von 20 bis 30 Ingenieuren und Tech-nikern steuert das Revisionsprojekt.

Unter diesen Rahmenbedingungen werden die Ressourcen feingranular ausgeplant.Jeder Dienstleister ist in einem genauen Zeitraster mit seinen Arbeiten beschäftigt. Je-dem Vorgang werden Ressourcen zugewiesen. Die Verfügbarkeit der Ressourcen wirdauf die Stunde genau ermittelt.

Bei der Einführung von Ressourcenmanagement-Praktiken wird eine pragmatischeHerangehensweise empfohlen:

• Organisationen tendieren oft dazu, Ressourcen zu detailliert zu planen, was einengroßen Planaktualisierungsaufwand nach sich zieht. Definieren Sie pragmatische Richt-linien für die Ressourcenplanung, die den Erfordernissen ihrer Organisation gerechtwerden. Mit einem hohen Planungsaufwand wird oft nur Scheingenauigkeit erreicht:Ein feingranularer Plan vermittelt den Eindruck, dass der Projektleiter das Projekt im


Griff hat. Solche Pläne müssen aber oft überarbeitet werden und entsprechen demtatsächlichen Projektgeschehen häufig nur in geringem Maße.

• Identifizieren Sie Engpassressourcen und analysieren Sie, ob für diese Ressourcen einedetailliertere Planung erforderlich ist. Ggf. können Sie einen Planungsansatz verwen-den, der Engpassressourcen explizit berücksichtigt (z. B. Critical Chain Project Mana-gement [8]).

• Berücksichtigen Sie die Aufwände für die Ressourcenplanung und planen Sie diese ein(z. B. in der Form einer besonderen Aktivität im Projektplan).

4.2.5 Kostenmanagement

Beim Kostenmanagement geht es um die Kostenschätzung, die Budgetierung, die Er-stellung einer Kosten-Baseline und die Steuerung der Projektkosten [4] (siehe Abb. 4.5).Grundsätzlich ist beim Kostenmanagement zwischen der erstmaligen Kostenplanung undder danach stattfindenden fortlaufenden Kostenkontrolle zu unterscheiden. Erstere wirdtypischerweise vom Projektleiter oder einem eigens beauftragten Team durchgeführt.Letztere sollte für die meisten Projekte im Rahmen des normalen Rechnungswesens ei-nes Unternehmens erfolgen. Hierzu ist das Projekt und ggf. auch die Projektstruktur imRechnungswesen abzubilden (d. h. in Form eines Kostenträgers), sodass im Rahmen dernormalen Kostenrechnung anfallende Kosten auf das Projekt gebucht werden können. Ineinem solchen Fall sinkt derKostenmanagement-Aufwand auf Seiten des Projektmanagers.Dieser erhält in festgelegten Intervallen Kostenträgerberichte, die die notwendigen Kos-tenanalysen ermöglichen. Bei Großprojekten wird das Kostenmanagement oft vollständigdurch einen eigenständigen Projektcontroller abgewickelt. Eine wichtige Vorbedingungfür das Kostenmanagement ist ein funktionierendes Ressourcenmanagement, weil diemeisten Kosten ressourcengebunden sind. Daher ist nur im Rahmen einer Ermittlung dernotwendigen internen und externen Ressourcen und der Verfügbarkeit dieser Ressourceneine Kostenabschätzung und -steuerung möglich.

Auf Basis der detaillierten Plan- und Ist-Kosten sowie von Informationen zu Projekt-status und -fortschritt kannmit Hilfe vonMethoden der Kostenanalyse eine Abweichungs-analyse vollzogen werden, z. B. eine Earned-Value-Analyse (EVA) [4]. Beim Kostenmana-gement müssen sprunghafte Investitionskosten (z. B. Beschaffung vonGroßkomponenten)bzw. die Linearisierung von Kostenverläufen besonders berücksichtigt werden.

Das Kostenmanagement kann je nach Projekttyp variieren. Bei IT-Projekten wird manvielfach ein eher gering ausgeprägtes Kostenmanagement vorfinden, da die Projektkostenfast ausschließlich aus der Nutzung von Personalressourcen resultieren, die auch über dasTermin- und das Ressourcenmanagement gesteuert werden können. Bei Bau- und Anla-genbauprojekten hingegen ist eine kostenorientierte Steuerung der Projekte entscheidend,da ein großer Kostenblock durch Zukauf von Komponenten, Materialien und Fremdleis-tungen verursacht wird. Die Schwankungen in den Beschaffungspreisen oder auch zwi-schen Währungen können daher in Bau- und Anlagenbauprojekten problematisch sein,


Projekt-Mitarbeiter

Projekt-ManagerExperte

Zeitaufschreibung

Ressourcenkosten

Projekt-Sachkosten

Rohstoffe

Kau

fpre

is

Bagger

Zeitaufschreibung

Projekt-Controller

Kostenverrechnung Projekt-Budget

Zukaufteile

Abb. 4.5 Projektleistungsbeziehungen

da sie eine Projektkostenschätzung im Vorfeld erschweren und ggf. zu einer raschen Erhö-hung der Projektkosten führen. Deshalb sind derartige Einflüsse im Rahmen des Vertrags-managements, des Liquiditätsmanagements und des Risikomanagements zu berücksichti-gen.

Die Wahl der Kostenmanagement-Praktiken ist auch von der Projektgröße und demGeschäftsmodell abhängig. In Großprojekten und bei Projektgesellschaften wird oft nebeneinem klassischen Kostenmanagement ein ausgereiftes Liquiditätsmanagement [10] benö-tigt. Ziele des Liquiditätsmanagements sind die Sicherung der finanziellen Liquidität desProjektträgers und die Optimierung des Zahlungsverkehrs. Zu den Aufgaben des Liquidi-tätsmanagements gehören:

Liquiditätsplanung: Planung der Zahlungseingänge und -ausgängeDisposition liquiderMittel: Abdeckung der Liquiditätsüberschüsse und Anlage von

ÜberschüssenSteuerung der Zahlungsströme: Minimierung der Kosten für den ZahlungstransferWährungsrisikomanagement: Management der Risiken, die durch schwankende Wech-

selkurse entstehen


ImHinblick auf die Standardisierung des Kostenmanagements empfehlen wir wie beimRessourcenmanagement eine pragmatische Herangehensweise:

• Sorgen Sie für eine angemessene Balance von Aufwand und Nutzen des Kostenma-nagements. Bei kleinen und mittleren Projekten ohne eigene Projektgesellschaft ist eslohnenswert, über eine Abwicklung im Kontext der normalen Kostenrechnung nach-zudenken.

• Projekte, die zum überwiegenden Teil Personalkosten erzeugen, können ggf. ohne be-sonderes Kostenmanagement abgewickelt werden. Stattdessen genügt ein ausgereiftesRessourcenmanagement.

4.2.6 Qualitätsmanagement

Ein gutes Qualitätsmanagements sichert ab, dass die Projektergebnisse die Bedürfnisseund Anforderungen erfüllen, die der Entscheidung zur Projektdurchführung zugrundelagen [4]. Zum Qualitätsmanagement gehören die Definition von Qualitätsmanagement-Richtlinien, -Zielen und -Verantwortlichkeiten. Wie beim Projektmanagement im Allge-meinen stehen auch im Qualitätsmanagement Kundenzufriedenheit, die Prävention vonQualitätsdefiziten, eine fortlaufende Optimierung der Qualität und die Einbindung vonFührungskräften im Vordergrund.

Als Teildisziplin des Projektmanagements ist das Qualitätsmanagement von verschie-denen Standardisierungsaspekten betroffen: Die verschiedenen Teil- und Endergebnissedes Projektes sind so zu entwickeln, dass sie den Qualitätsanforderungen des Kunden undder Gesamtorganisation gerecht werden. Hierzu muss klar sein, welche Qualität erwartetwird und wie diese zu erreichen ist. Im Rahmen des Umfangsmanagements sind hierzumöglichst exakt die Inhalte der Arbeitspakete festzulegen und es sind für diese InhalteQualitätsstandards zu definieren. Die Qualität der Projektergebnisse kann z. B. währendder Meilenstein- oder Phasenabnahmen geprüft und durch die Einführung von Vorlagengefördert werden.

Je nach Projekttyp bestehen teilweise sehr deutliche Unterschiede in der Ausgestaltungdes Qualitätsmanagements. Bei Softwareprojekten wird die Qualität in der Regel anhandder Fehlerzahl, Verfügbarkeit, Zuverlässigkeit und Sicherheit gemessen. Die Abnahme er-folgt durch den Anwender. Bei Organisationsprojekten hingegen wird die Qualität anhandder Zufriedenheit der Stakeholder oder anhand vonEffizienz- undEffektivitätsmaßen (z. B.Prozesseffizienz) beurteilt. In Bauprojekten ergibt sich Qualität unter anderem aus einergeringen Anzahl an Nachforderungen. Während bei einigen Projekttypen Qualität nurqualitativ durch den Kunden festgestellt wird, kommen bei anderen quantitative, statisti-scheMethoden (z. B. Prozentzahl der produzierten defekten Stücke) zum Einsatz. In vielenFällen gibt es branchenspezifische Qualitätsmanagement-Normen, die zum Aufbau vonProjektmanagementsystemen herangezogen werden können (ISO 9001, ISO 10006, DIN69901).


Die Einführung von Qualitätsmanagement in der Standardisierungsphase ist essentiell,denn ohne Qualitätsmanagement entfalten die anderen standardisierten Praktiken nichtihren vollständigenNutzen. Es wird sich imWesentlichen in einer fortlaufenden,möglichstobjektiven Prüfung von Projektzwischen- und -endergebnissen manifestieren, die fest indas Vorgehensmodell eingebettet sein sollten.

4.3 Zusammenfassung& Empfehlungen

Die Standardisierung von Projektmanagement-Praktiken stellt den ersten Schritt auf demWeg zu einem erfolgreichen, organisationsweiten Projektmanagement dar. Dabei ist dieStandardisierung in Abhängigkeit vom Projekttyp unterschiedlich zu gestalten (siehe auchTab. 4.4).

Die definierten Standards sollten vollständig dokumentiert werden, damit sie der Or-ganisation bei Mitarbeiterfluktuationen erhalten bleiben, im Zweifelsfall eine Referenz zurVerfügung steht und eine Grundlage für die Ausbildung vonMitarbeitern besteht. Die Ver-fahrensstandardskönnen entweder in Form eines Projektmanagementhandbuches oder alsTrainingsmaterial dokumentiert werden. In jedem Fall sollten die Richtlinien knapp, präzi-se und anwendungsnah dokumentiert undmit anschaulichen Beispielen illustriert werden.

Generell wird eine Einbindung von Führungskräften bei der Einführung von Projekt-management-Standards empfohlen, daWiderstände gegenüber den notwendigenVerände-rungen in manchen Fällen nur durch Intervention von Führungskräften zu begegnen ist.Dies kann beispielsweise in Form der Herausgabe einer Projektmanagement-Grundsatz-erklärung durch die Führungskräfte erfolgen (siehe Abb. 4.6). Die Beteiligung von Füh-rungskräften beim Entwurf neuer Standards signalisiert außerdem deren Wichtigkeit undsteigert ihre Akzeptanz. Weitere Details zu diesemThema sind im Kap. 3 zu finden.

Eine partizipative Entwicklung der Projektmanagement-Standards ist ebenfalls emp-fehlenswert. Durch die Einbindung erfahrener Projektmanager und anderer Projektstake-holder in den Standardisierungsprozess können Erfahrungswissen und Best-Practices indie Richtlinien einfließen. Gleichzeitig können Teilnehmer als Fachpromotor dienen undfür die Akzeptanz der Standards werben.

Fallbeispiel: Partizipative Methodenentwicklung bei einem Dienst-leistungsunternehmen

Forscher der EBS Business School haben in Kooperationmit Mitarbeitern eines Dienst-leistungsunternehmens eine Projektmanagement-Methodik für diese Organisation ent-wickelt. Im ersten Schritt der Methodenentwicklung wurde ein Kernprojektteam beste-hend aus zwei Forschern und ausgewählten Projektstakeholdern definiert. Basierend aufden Erfahrungen der Mitglieder dieses Kernteams und dem theoretischen Wissen derForscher wurde eine erste Basisversion dieser Methode definiert.


Tab. 4.4 Zusammenfassung zur Relevanz der Standardisierungsbereiche für unterschiedliche Pro-jekttypen

IT Bau Produkt-entwicklung

Organisation

Vorgehensmodell HochHoher Bedarf anStrukturierungder Projektpha-sen

GeringViele derProjektanalyse-und Planungs-tätigkeiten sindTeil des täglichenBetriebs

HochHoher Bedarf anStrukturierungder Projektpha-sen

MittelDie Projektpha-sen müssen zwardefiniert werden,aber das Testendes Endergebnis-ses ist wenigerintensiv

Umfangs-management

MittelDie Anforde-rungen (mitAusnahme vonagilen Methoden)und Ziele desProjektes müs-sen klar definiertwerden

HochDer Projektplanmuss mit demProjektvertragabgeglichen wer-den

HochEs besteht wenigSpielraum, dasProduktergeb-nis im Laufe desProjektes nachzu-justieren

HochDie Anforderun-gen und Zieledes Projektessind schwer zuermitteln und zuoperationalisie-ren

Zeitmanagement MittelDie Aufwändefür die einzelnenArbeitspaketekönnen mit Hilfevon Erfahrungs-werten ermitteltwerden

HochProjektverzugbedeutet hoheVertragsstrafen

HochEs ist oft ent-scheidend,Produkte soschnell wiemöglich zu ent-wickeln, um denVorsprung ge-genüber derKonkurrenz zusichern

HochÄnderungenin einer Orga-nisation sindschnell umzu-setzen, da dieProduktivitätaufgrund derUmstellungs-phase beein-trächtigt wird

Ressourcen-management

MittelDie Ressourcenin einem IT-Projekt sind imWesentlichenPersonal-ressourcen

HochEine Vielfaltvon Ressour-cen kommt beiBauprojektenzum Einsatz, dieoptimal bereit-gestellt werdenmüssen

MittelDie Ressourcen,die bei einemProduktentwick-lungsprojekt zumEinsatz kommen,sind oft über-schaubar

MittelDie Ressour-cen in einemOrganisations-projekt sind imWesentlichenPersonal-ressourcen

Nach demAbschluss dieser Phasewurde das Kernprojektteamumvier Projektmana-ger erweitert. Die Basisversion derMethode diente als Diskussionsgrundlage undwurdeinWorkshopsmit dem erweiterten Team schrittweise verfeinert. Nachdem ein Konsensim erweiterten Projektteam erreicht war, wurden weitere Projektmanager hinzugezo-


Tab. 4.4 Fortsetzung

IT Bau Produkt-entwicklung

Organisation

Kosten-management

GeringDie Kosten fürein IT-Pro-jekt sind imWesentlichenPersonalkostenoder Anschaffun-gen mit stabilenPreisen

HochAufgrund derKomplexität vonBauprojektenund der Schwan-kungen in denRohstoffprei-sen und/oderWährungenist das Kosten-managementanspruchsvoll

MittelAufgrund derniedrigen Kom-plexität derRessourcen-planung istdas Kosten-managementeinfach imVergleich mitBauprojekten

MittelDie Kos-ten für einOrganisations-projekt sind imWesentlichenPersonalkostenoder Anschaffun-gen mit stabilenPreisen

Qualitäts-management

HochEgal, um welchen Projekttyp es sich handelt, die Sicherung derQualität des Endergebnisses spielt eine entscheidende Rolle.

gen. Die EBS-Forscher haben die Methode gemäß deren Feedback weiterentwickelt.So wurden für Software-, Infrastruktur- und Organisationsprojekte verschiedene Va-rianten der Methodik definiert. Pflicht- und Wahlteile garantierten die Flexibilität undAnpassungsfähigkeit der Methodik an variierende Projektrahmenbedingungen.

Als ein Konsens über die Methode zwischen dem Kernteam und den Projektma-nagern erreicht war, wurde sie Linienmanagern vorgestellt und auf Basis der entspre-chenden Rückmeldungen abermals überarbeitet. Die Methodenentwicklung wurde ab-geschlossen, als alle Beteiligten zu einem Konsens gelangt waren.

Die neuen Standards müssen natürlich gesetzeskonform gestaltet werden und solltenalle relevanten Compliance-Vorgaben berücksichtigen. Dazu gehören z. B. Basel-II und dasEuroSOX für die Finanzbranche sowie das Baugesetzbuch (BauGB) für Bauprojekte.

Die Entwicklung der Standards muss nicht bei Null beginnen. Es besteht bereits einegroße Vielfalt von öffentlich zugänglichen Projektmanagement-Standards und -Normendie als Basis dienen können. Bestehende Standards sollten jedoch immer an die spezifi-schen Bedürfnisse der Organisation angepasst und nicht eins zu eins verwendet werden.Eine Tabelle mit den wichtigsten Projektmanagement-Standards ist in Kap. 1 zu finden.


Projektmanagement-Grundsatzerklärung

Projektmanagement ist als ein Schlüsselfaktor anerkannt, um unsere Firma zum Geschäftserfolg zu führen.

Es ist unser Grundsatz, dass alle Organisationen, die an Projekten beteiligt sind, professionelle Projektmanagement-Methoden und -Prozeduren verwenden, wie sie von den dafür verantwortchen Organisationen definiert und festgelegt sind.

Von jeder/m Mitarbeiter(in), die/der in das Projektmanagement eingebunden ist, wird adäquate Projektmanagement- Kompetenz gefordert.

Abb. 4.6 Beispielhafte Grundsatzerklärung

Literatur

1. Lyytinen, K. (1988). Expectation failure concept and systems analysts’ viewof information systemfailures: Results of an exploratory study. Information & Management 14(1), 45–56.

2. Waterman, R. H. (1982). The seven elements of strategic fit. Journal of Business Strategy 2(3),69–73.

3. Chan, Y. E., & Reich, B. H. (2007). IT alignment: What have we learned? Journal of InformationTechnology 22(4), 297–315.

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

5. Kerzner, H. (2004). Advanced project management: Best practices on implementation. Hoboken,NJ, USA: Wiley.

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

7. Bröhl, A. P. (1995). Das V-Modell: Der Standard für die Softwareentwicklung mit Praxisleitfaden.München, Deutschland: Oldenbourg.

8. Goldratt, E. M. (1997). Critical chain. Great Barrington, MA, USA: North River Press.

9. Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum. Upper Saddle River,NJ, USA: Prentice Hall.

10. Hormuth, M. W. (1998). Recht und Praxis des konzernweiten Cash-Managements: Ein Beitragzur Konzernfinanzierung, Publications of Darmstadt Technical University, Institute for BusinessStudies (BWL).

11. Takeuchi, H., & Nonaka, I. (1986). The new new product development game, Harvard BusinessReview 64(1), 137–146.

Strategisches Projektmanagement || Standardisierung - Vom Chaos zur einheitlichen Projektabwicklung

Documents

Transcript of Strategisches Projektmanagement || Standardisierung - Vom Chaos zur einheitlichen Projektabwicklung