Upload
vuongdieu
View
213
Download
0
Embed Size (px)
Citation preview
Zusammenspiel Zwischen traditionellem & agilem pm
Die Schwierigkeit in diesen Vorhaben be-
steht in erster Linie darin, dass in der agilen
Methode durch das iterative Vorgehen keine
oder nur schwer zu definierende Vorhersa-
gen für den Leistungs-, Zeit- und Kosten-
rahmen zu treffen sind, während die traditi-
onelle Methode von einer quasi-konkreten
Vorgabe in Leistung, Terminen und Kosten
ausgeht (Gloger, 2008, S. 60ff.; Pichler,
2008, S. 7ff.)
Immer öfter beobachten wir in Unternehmen jene Situation, dass agil geplante und gesteuerte Projekte bzw. Subpro-jekte (z.B. in der Methode Scrum) in traditionelle Projekte oder Programme eingebettet werden müssen.
Christian Sterrer & Manfred Brandstätter
Mit folgenden Fragen bzw. Aufgabenstel-
lungen sehen sich die Verantwortlichen der-
artiger Projekte konfrontiert: Geht das über-
haupt? Widerspricht das nicht einerseits
den agilen Grundsätzen bzw. andererseits
den traditionellen Projektmanagementme-
thoden? Und wie sind agil geführte Projekte
in einem unternehmensweiten Projektport-
foliomanagement sinnvoll zu integrieren?
Wir denken nicht, dass sich „Tradition“
2
und „Agilität“ widersprechen und werden
hier versuchen dies zu argumentieren. Im
nachfolgenden Beitrag werden wir an-
hand zweier Beispiele die Möglichkeit des
Zusammenspiels von traditionellem und
agilem Projektmanagement darstellen. Das
Fallbeispiel A stellt die Integration eines agil
geführten Projektes in einem traditionell ge-
managten Programm zur Entwicklung einer
webbasierenden Personalmanagement-
Software dar. Das Fallbeispiel B stellt die
Implementierung eines Projektportfolioma-
nagements vor, das sowohl traditionelle als
auch agile Projekte beinhaltet.
1. Grundsätzlich
Unserer Erfahrung nach herrscht in vielen
Unternehmen immer noch die Meinung
vor, agiles Projektmanagement ist nur „eine
etwas ungenauere Projektplanung“. Der
agile Projektmanagement-Ansatz unter-
scheidet sich massiv vom traditionellen
Abb. 1: Grober Vergleich zw. den Projektphasen der traditionellen und agilen Methode
Projektmanagement (PM), sowohl in der
Betrachtung der Projektorganisation, in der
Art und Verwendung der PM-Methoden und
Instrumente, wie auch in der Abwicklung
der PM-Prozesse. Daher bedarf dies vorab
einer differenzierten Betrachtung, der wir in
den nachfolgenden Punkten 2 bis 4 nach-
kommen werden.
2. Projektorganisation
Während das traditionelle PM grundsätzlich
von den Projektrollen Projektauftraggeber,
Projektleiter, Projektteammitglied und Pro-
jektmitarbeiter (optional weitere Rollen, wie
z.B. Projektlenkungsausschuss, etc.) aus-
geht, finden sich im agilen PM-Ansatz die
Rollen: Product Owner, Scrum Master und
Scrum Team. Eine direkte 1:1 Zuordnung
der einzelnen Rollen zwischen den beiden
Ansätzen ist nicht ohne weiteres möglich
(vgl. Sterrer/Winkler, 2009, S. 116ff.; Gloger,
2008, S. 71ff.).
In vielen Unterneh-men herrscht immer noch die Meinung vor, agiles PM ist nur „eine etwas ungenauere Projekt- planung“
Zusammenspiel Zwischen traditionellem & agilem pm
3
3. PM-Methoden und Instrumente
Ohne auf eine detaillierte Beschreibung der
Instrumente und Methoden einzugehen, wird
schon anhand der groben Gegenüberstel-
lung (vgl. Abb. 1) der beiden PM-Methoden
ein großer Unterschied sichtbar. Während
zum Beispiel im traditionellen Projektma-
nagement eine Fülle von PM-Instrumenten
existiert, werden im agilen Ansatz wenige,
dafür jedoch simple Instrumente, wie z.B.
Product Backlog, Burndown Chart und
Impediment Chart verwendet.
4. PM-Prozesse
Das traditionelle PM definiert die Prozesse
Projektbeauftragung, Projektstart (Projekt-
planung), Projektkoordination, Projektcont-
rolling (Realisierungsphase) und Projektab-
schluss. Im agilen PM existieren zunächst
simple, dafür jedoch iterativ wiederkehrende
Abläufe. Die Erstellung beispielsweise des
Product Backlogs (analog zur Produktspe-
zifikation in der traditionellen PM-Methode),
sowie Sprintplanung werden als ein Prozess
der Projektinitialisierung und Projektplanung
verstanden. Die Daily Scrum Meetings, das
Sprint Review bzw. das Sprint Retrospec-
tive Meeting werden dabei als Bestandteile
des Prozesses für die Leistungsfortschritts-
kontrolle, die Risikobetrachtung und
-bewältigung, sowie die kontinuierliche Ver-
besserung innerhalb eines agilen Projektes
definiert. Abb. 1 bietet einen groben Über-
blick der beiden PM-Methoden und wagt
dazu einen ungefähren Vergleich.
In der Realität stehen derzeit viele Unter-
nehmen vor der Herausforderung, traditi-
onelles und agiles Projektmanagement zu
kombinieren. Nachfolgend werden zwei
Beispiele möglicher praxisbewährter Ansät-
ze beschrieben.
Abb. 2: Gesamtdarstellung der Methode des Agiles Release Management mittels Meilensteinsteuerung
Zusammenspiel Zwischen traditionellem & agilem pm
4
FallbeIsPIel a:agiles Release Management mittels Meilensteinsteuerung und Richtwertermittlung im Vorfeld
Die Grundlage der nachfolgend beschrie-
benen Methode ist einerseits aus dem
Bedürfnis heraus entwickelt worden, agile
und traditionelle Planungs- und Steue-
rungsmethoden in Projekten zu kombinieren
und andererseits aus den Erkenntnissen der
integrierten Kommunikation als Erfolgsfak-
tor in Projekten (vgl. Brandstätter/Gölzner/
Siems, 2008; Brandstätter/Stumpf, 2012).
Bei dem nachfolgend beschriebenen Fall-
beispiel handelt es sich um ein abgeschlos-
senes IT-Projekt. Dabei wird ein Projekt zur
Entwicklung einer Software für ein internet-
basierendes Personalmanagement System
eines Handelsunternehmens der Automo-
bilbranche beschrieben. Dieses Projekt ist
im Kontext eines Change Management
Programmes eingebunden.
Das Gesamtprogramm wird in der Stabs-
stelle des Unternehmens mit den tradi-
tionellen Methoden des Projekt- bzw.
Programmmanagements nach IPMA (vgl.
IPMA, 2009) geplant und zentral gesteuert.
Das darin eingebettete Projekt der Soft-
wareentwicklung führt die unternehmensei-
gene IT-Abteilung ebenfalls via traditioneller
PM-Methode durch. Ein Teilprojekt daraus
wird gemeinsam mit einem externen Unter-
nehmen durchgeführt. Dieses externe Soft-
wareunternehmen verwendet für Planung
und Umsetzung ein agiles Rahmenwerk
nach Scrum (vgl. Schwaber/Beedle, 2001).
Die Möglichkeit einer Kombination aus
traditionellem Gesamtprojektmanagement
und der agilen Vorgehensweise in einem
Teilprojekt liegt in zwei Aspekten begründet,
der Richtwertermittlung und dem Meilen-
stein-gesteuerten Release Management
(vgl. Abb. 2).
In der Ermittlung eines so genannten Richt-
wertes werden die komplexen Anforderun-
gen der Portalsoftware im Vorfeld mittels
agiler Schätzmethoden qualitativ und
anschließend quantitativ bewertet (Cohn,
2005, S. 25ff.; Gloger, 2008, S. 165ff.;
Pichler, 2008, S. 93).
Die Planung und die Einbettung des Teilpro-
jektes in das Gesamtprojektmanagement
erfolgt im zweiten Schritt der Methode,
nämlich in Form des Meilenstein-gesteuer-
ten Release Managements. Dabei fließen
die Ergebnisse der Vorplanung (Richtwert)
in die Planung und Umsetzung des Re-
lease Managements ein. Es werden die
Spezifikationen – wir sprechen dabei nur
mehr von Product Backlog Items – kate-
gorisiert, mit dem Kunden priorisiert und
gemeinsam mit dem Projektmanagement
des Gesamtprojektes in einzelnen Releases
geplant. Die Releaseplanung findet daher
in Relation zur nachfolgenden Release
Umsetzung jeweils zeitversetzt statt. Das
Gelingen dieses Vorgehensmodells bedingt
ein hoch diszipliniertes Zusammenspiel
zwischen Software-Entwicklungsteam, Pro-
duktverantwortlichem (Product Owner) und
Anwender (Kunden). Die Releases werden
anschließend mit dem Softwareunterneh-
men und dem zentralen Projektmanage-
ment gemeinsam in einzelnen Meilensteinen
geplant und gesteuert.
Folgende detaillierte Vorgehensweise liegt
dieser Methode nun zugrunde:
1. ermittlung des Richtwertes
Die Methode zur Ermittlung des Richt-
wertes beschreibt jene Vorgehensweise,
um ausgehend von einer herkömmlichen
Funktionsbeschreibung (z.B. in Form von
Lasten- oder auch Pflichtenheften) eine
initiale Schätzung zu bekommen, die einer-
seits dem agilen Vorgehen gerecht wird und
Zusammenspiel Zwischen traditionellem & agilem pm
5
andererseits dem traditionellen Projektma-
nagement eine ungefähre Orientierungshilfe
gibt (vgl. Abb. 3 im Pkt. 1).
Das Softwareunternehmen erstellt im Vor-
feld – entweder als eigenes Teilprojekt oder
als Meilenstein im Rahmen des Gesamt-
projektes organisiert – gemeinsam mit dem
Projektmanagement und den Anwendern
des Handelsunternehmens (nachfolgend
als Kunde beschrieben) ein initiales Product
Backlog. Dieses initiale Product Backlog ist
eine Sammlung von User Stories und wird
auf Basis eines klassischen Pflichtenheftes
erstellt. Im angeführten Beispiel wird dieses
Vorgehen in Form eines eigenen Teilprojek-
tes durchgeführt.
Im Folgenden schätzt nun das Software-
Team die relative Größe der Funktionen
(User Stories) auf Basis von Story Points,
sodass am Ende eine initiale Schätzung des
gesamten Software Projektes vorliegt. Das
Schätzen kann entweder mit Affinity Estima-
ting erfolgen, weil es am schnellsten und ef-
fektivsten ist – ggf. kann aber auch Planning
Poker verwendet werden. Das Einbinden
des Kunden bei dieser initialen Schätzung
bewährt sich, weil dies auf beiden Seiten
für ein besseres Verständnis der Funktionen
sorgt und viele Missverständnisse schon
früh ausgeräumt werden können (vgl. Cohn,
2005; Gloger, 2008; Pichler, 2008).
Anschließend stimmt sich das Softwareun-
ternehmen mit dem Kunden zu einer so
genannten Definition of Done (DoD) ab,
die insbesondere auch Qualitätskriterien
definiert und festlegt, ob die Anwendung
beispielsweise mit automatisierten Fach-
tests und/oder manuell durch ein Testteam
geprüft werden soll (vgl. Cohn, 2004).
Im darauf folgenden Schritt brechen sie
exemplarische Stories in der Bandbreite
der möglichen unterschiedlichen Schwie-
Abb. 3: Vorgehensmodell des Meilenstein-gesteuerten Agilen Release Managements und Richtwertermittlung im Vorfeld
Zusammenspiel Zwischen traditionellem & agilem pm
6
rigkeitsgrade (Richtwert Stories) auf Tasks
(Richtwert Tasks) herunter und entwickeln
Design Ideen für die Umsetzung. Auf Basis
der DoD erstellt das Team (hauptsächlich
der Product Owner) eine Expertenschät-
zung für diese Richtwert Tasks und erhält
so in Summe den Personalaufwand für die
Richtwert Stories in Personentagen. Dann
wird der Aufwand auf Basis der Schätzun-
gen für die weiteren Stories ermittelt. Man
erhält so einen Umrechnungsfaktor von
Story Points auf Personentage und umge-
kehrt (1 Story Point = X Tage Aufwand; 1
Personentag = X Story Points).
Auf Basis dieser initialen Schätzung des
Backlogs in Storypoints und des Um-
rechnungsfaktors kann nun der Personal-
aufwand für ein initiales Backlog ermittelt
werden. Der Aufwand multipliziert mit
dem durchschnittlichen Tagessatz des
Umsetzungsteams ergibt die geschätzten
Entwicklungskosten (diese Methode kann
durchaus auch zur Ermittlung eines Fest-
preises für agile Projektvorgehen verwendet
werden).
Wichtig dabei ist folgende Aussage: A) Die-
se geschätzten Entwicklungskosten gelten
jetzt aber nicht für den Umfang des initialen
Backlogs, sondern: B) für die Anzahl der
initial berechneten Story Points. D.h. der
Kunde kann den mengenmäßigen Umfang
(in Story Points) des initialen Backlog damit
umsetzen, muss es aber nicht. Er kann
auch jederzeit Stories austauschen, neue
hinzufügen und andere streichen – solange
er den Gesamtumfang der Storypoints nicht
überschreitet. Aussage A und B lesen sich
zwar im ersten Moment als sinngleich, sind
aber im Detail unterschiedlich. Diese Art
von Definitionen unterstreicht die Philoso-
phie der agilen Bewertungsmethode, indem
z.B. grobgranulare Spezifikationen nicht als
Basis von feingranularen Kosten verwendet
werden sollen.
Es gibt natürlich noch andere Varianten
zur Ermittlung des agilen Richtwertes.
Beispielsweise kann man den Aufwand
für Storypoints nur durch das Umsetzen
einiger weniger Testsprints (2 bis 4) auf
Basis von Zeit und Material ermitteln. So
kann man den Umrechnungsfaktor sehr
präzise empirisch bestimmen und hat auf
beiden Seiten höhere Planungssicherheit.
I.d.R. arbeiten Dienstleister ohne diese
Sicherheit mit einem “Risikoaufschlag”
bei der initialen Schätzung, um das Risiko
von Mehraufwänden z.B. im Festpreis
zu berücksichtigen. 30% Aufschlag sind
dafür ein realistischer Erfahrungswert.
Dieses Verfahren unterscheidet sich in
keiner Weise vom herkömmlichen Schätz-
verfahren.
Eine weitere Variante ist die Methode Mo-
ney for nothing – change for free, die Jeff
Sutherland vorgeschlagen hat. Bei dieser
Variante kann der Kunde jederzeit sagen,
dass er das Projekt beendet, weil die ge-
lieferte Funktionalität ausreichend ist. Die
Differenz des Aufwandes wird geteilt, d.h.
der Dienstleister erhält die Hälfte des Gel-
des für den nicht geleisteten Aufwand und
der Kunde spart die andere Hälfte ein (vgl.
Sutherland, 2008).
2. Planung und Kategorisierung der Release #1 (und nachfolgende)
Der nachfolgend aufgestellte Iterationsplan
muss immer mindestens drei Monate im
Voraus, jedoch mindestens zwei Monate
vor dem Release Start mit dem Sprint #1
geplant sein. Die Angabe in Monaten geht
immer von einer definierten Sprintlänge
von 4 Wochen aus. Bei einer allfälligen
Änderungen der Sprintlänge müssten dann
auch die Planungszeiträume adaptiert
werden. In dieser Phase der Release-
Planung und Kategorisierung werden nun
Zusammenspiel Zwischen traditionellem & agilem pm
7
gemeinsam mit dem Product Owner des
Software-Teams (in Abstimmung mit dem
Kunden) nur kategorisierte Anforderun-
gen (Backlog Items) in die nachfolgende
Release-Planung aufgenommen (vgl. Abb.
3 im Pkt. 2).
3. Grobplanung des sprints
Die Anforderungen (Backlog Items) müssen
mindestens ein Monat vor der jeweiligen
Umsetzung (in Form von Sprints) geschätzt
werden. Die Grobplanung passiert durch
den Product Owner, die Schätzung jedoch
immer in Abstimmung mit dem Team inner-
halb des Softwareunternehmens (vgl. Abb.
3 im Pkt. 3).
4. Teilangebot, bestätigung und start für Release #1 (und nachfolgende)
Die inhaltliche Grobplanung für das Release
umfasst:
die Auswahl der Backlog Items des
aktuell geplanten Releases,
mit ergänzenden Funktionen, die bei
eventuell nachfolgenden Releases durch
Kunden oder Softwareunternehmen
identifiziert wurden,
den jeweiligen Aufwand, der auf der
initialen Schätzung basiert.
Diese inhaltliche Grobplanung des Re-
leases wird vom Softwareunternehmen
entweder direkt an den Kunden (wird
empfohlen) oder über das zentrale Projekt-
management in Form eines Teilangebotes
(jeweils spätestens ein Monat vor Um-
setzung eines Releases an den Kunden)
gelegt. Sie muss für eine zeitgerechte
Umsetzung eines Releases bis spätestens
zum 15. des jeweiligen Monats vom Kun-
den bestätigt sein (vgl. Abb. 3 im Pkt. 4).
Änderungen werden in jedem Fall vom
Product Owner des Softwareunterneh-
mens dem zentralen Projektmanagement
in Form eines Change Requests (einer
Änderung im Leistungsumfang) gemeldet.
Die Umsetzung und Abnahme der jewei-
ligen Sprints wird im jeweiligen Entwick-
lungszyklus nach der Methode Scrum
durchgeführt. Das diesbezügliche Pro-
zedere wird daher hier in diesem Artikel
nicht explizit beschrieben. Die darin
erforderlichen Sprint Reviews und Ret-
rospectives werden sofort im Anschluss
an das Sprintende, jeweils gemeinsam
mit dem Team, Product Owner und dem
Kunden durchgeführt. Ist es dem Kunden
terminlich nicht möglich, die Funktionen
im Sprint Review zeitnah abzunehmen,
dann muss dies, ohne einen Verzug zu
erreichen, bis spätestens ein Monat nach
Abschluss des Sprints durchgeführt
werden.
Wichtig: Mögliche Änderungen im Sprint-
ergebnis (z.B. unvollständig umgesetzte
User Stories) werden dem zentralen Pro-
jektmanagement nach dem Sprint Review
gemeldet. Ebenso werden auftretende
Probleme innerhalb der Sprints (z.B. Ab-
bruch eines Sprints, Anhäufung ungelöster
Probleme) durch den Product Owner an
das zentrale Projektmanagement sofort
berichtet. Bewährt hat sich die Risiko-
prävention in Form eines wöchentlichen
Reports via Burn-Down-Chart vom aktuel-
len Release durch den Product Owner des
Scrum Projektes an das zentrale Projekt-
management.
5. Releasetest und Releaseabnahme
Der finale Test und die Abnahme des ge-
samten Releases passiert gemeinsam mit
dem Team, Product Owner und Kunden
und schließt als letzten Meilenstein den
aktuellen Release ab.
Zusammenspiel Zwischen traditionellem & agilem pm
8
FallbeIsPIel b: Übergeordnetes Projekt- portfoliomanagement für traditi-onelle und agile Projekte
1. ausgangssituation
Ein mittelständisches Versicherungsunter-
nehmen in Deutschland implementiert ein
unternehmensweites Projektportfolioma-
nagement. Die Vielzahl der Einzelprojekte
(Einzelprojektmanagement, EPM) werden
nach traditionellem Projektmanagement
abgewickelt, einige wenige Projekte im IT-
Bereich werden agil durchgeführt.
Die Aufgabenstellung war: Wie kann ein effi-
zientes, einheitliches Projektportfoliomanage-
ment etabliert werden und trotzdem sowohl
der traditionelle, als auch der agile Projekt-
management-Ansatz akzeptiert werden?
2. Vorgehensweise
Zunächst wurde das Projektportfolioma-
nagement (PPM) definiert. Die Definition
umfasste:
Definition der PPM-Organisation
Definition der PPM-Prozesse
Definition der PPM-Daten
In der PPM-Organisation wurden die rele-
vanten Rollen und Gremien (also Projekt-
management-Office, Projektsteuerkreis
(PSK), etc.) wie auch die Kommunikations-
strukturen (Häufigkeit und Inhalte der PSK-
Sitzungen) und Spielregeln definiert (vgl.
IPMA, 2009).
Die PPM-Prozesse beinhalteten insbeson-
dere die Folgejahresplanung (strategische
Planung des PPF für das folgende Ge-
schäftsjahr), die Projektbeauftragung, das
PPF-Controlling (Steuerung der laufenden
Projekte) und die Projektabnahme sowie
Projektevaluierung. Weiters wurden die
Schnittstellen zu den EPM-Prozessen de-
finiert. Schlussendlich wurden alle relevan-
ten Daten definiert, die im PPF notwendig
waren und somit auch regelmäßig von allen
Projektleitern im Rahmen des Controlling
aktualisiert werden mussten. Diese Daten
bildeten den gemeinsamen Nenner bezüg-
lich Anforderungen an die Projekte (sowohl
traditionelle als auch agile Projekte).
Abb. 4: Beispiel einer traditionellen PM-Prozesslandkarte, beinhaltet sowohl Einzel- als auch Projektportfoliomanagement-Prozesse
Zusammenspiel Zwischen traditionellem & agilem pm
9
Darauf aufbauend wurde das Einzelprojekt-
management definiert. Dazu wurde eine
PM-Methodenliste vereinbart, in der auch
nochmals zwischen Projekten und Kleinpro-
jekten differenziert wurde (vgl. Abb. 6).
Aufgrund der Prozessvorgabe im PPM
(monatliche PSK-Sitzungen) wurde auto-
matisch das Projektcontrolling-Intervall der
Einzelprojekte festgelegt. Die PM-Metho-
denliste bildete die Basis für das zukünftige
EPM und wurde 1:1 von der verwendeten
PM-Software unterstützt und über PM-
Schulungen den Projektbeteiligten vermittelt
(vgl. Sterrer/Winkler, 2009, S. 206ff.).
Etwas schwieriger wurde die Aufgaben-
stellung bei den agilen Projekten. Da die
PM-Methoden ganz anders sind, einigte
man sich darauf, die notwendigen Daten für
das PPM zu liefern, was konkret Folgendes
bedeutete:
Auch Projektleiter (PL) agiler Projekte er-
stellen einen Projektauftrag und stimmen
diesen mit einem Projektauftraggeber ab
(der Projektauftrag ist für traditionelle und
agile Projekte ident).
Es muss monatlich ein Projektstatus-
bericht erstellt werden (auch ident zum
traditionellen PM).
Es muss ein Mindestmaß an Projektda-
ten zum Projektmanagement-Dreieck
(Leistungen, Termine, Ressourcen und
Kosten) geliefert werden.
Leistungen
Die Sprints werden als Arbeitspakete dar-
gestellt und darauf aufbauend auch der
Leistungsfortschritt ermittelt (z.B. sind 12
Sprints à 1 Monat geplant und bereits 6
Sprints abgearbeitet, dann ist der Leis-
tungsfortschritt für das Projekt bei 50%)
Termine
Bei gleich langen und in der Anzahl
definierten Sprints kann ein geplanter
Endtermin festgelegt werden (z.B.
12 Sprints à 1 Monat bedeuten eine
Durchlaufzeit von 12 Monaten). Solange
keine zusätzlichen Sprints geplant sind,
hält der Endtermin.
Ressourcen
Die Planstunden können aufgrund der
Zusammensetzung des Teams und deren
prozentueller Zuteilung zum Projekt berech-
net werden, die Ist-Stunden werden auf
Projektebene erfasst, die Hochrechnung
der Gesamtstunden (Ist + Rest) bleibt
Abb. 5: Projektmanagement-Dreieck: zeigt die Zusammenhänge der Leistungen, Termine, Ressourcen und Kosten auf
Zusammenspiel Zwischen traditionellem & agilem pm
Kosten
RessourcenTermine
Leistungen
10
unverändert, solange sich die Anzahl der
Sprints und die prozentuelle Zuteilung des
Projektteams nicht verändert.
Kosten
Erfolgt gleich wie bei den traditionellen
Projekten nach den definierten Kostenarten,
die Personalkosten errechnen sich aus den
geplanten Stunden.
3. lessons learned
Das PPM setzt auf traditionelle Projektin-
formationen und -daten auf. So gesehen
gab es für die Projektleiter der traditionell
geführten Projekte keine Zusatzaufwände
bzw. Änderungsbedarf. Die Projektleiter
der agilen Projekte stehen grundsätzlich
jeglichem administrativen Mehraufwand
reserviert gegenüber, akzeptierten den
notwendigen Mehraufwand jedoch im Sinne
und zugunsten eines ganzheitlichen, unter-
nehmensweiten PPM.
ZusaMMenFassunG
Es ist im Unternehmen gut zu überlegen
(und auch strategisch zu entscheiden), ob
der traditionelle und der agile Projektma-
nagement-Ansatz eingesetzt werden sollen.
Diese Entscheidung erhöht die Komplexität
des Projektmanagements im Unterneh-
men deutlich, auch weil Projektbeteiligte in
unterschiedlichen Projekten zwischen den
beiden Ansätzen umdenken müssen. Diese
Entscheidung wird wohl nicht zuletzt auch
von der Anzahl der traditionellen und agil
geführten Projekte abhängen.
Abb. 6: Beispiel einer PM-Methodenliste inkl. Zusammenhang zu Scrumprojekten
PM-Methoden/Instrumente Kleinprojekte Projekt Scrum Projekte
Projektauftrag M M r
Projektstakeholderanalyse K M
Projektstrukturplan (PSP) M MProduct Backlog,
Sprint als AP
AP-Spezifikationen K K Sprint Backlog
Meilensteinplan M M
Balkenplan (Gantt) K MSprint werden als Balken geplant
Ressourcenplan M M r
Kostenplan M M r
Organigramm K M
Kommunikationsstrukturen K M
Arbeitspaketverantwortliche M M
Funktionendiagramm K K
Spielregeln K M r
Risikoanalyse K M
Statusbericht M M r
To Do- und Entscheidungsliste M M
Projektabschlussbericht M M r
Zusammenspiel Zwischen traditionellem & agilem pm
11
Anhand der beiden Fallbeispiele zeigt sich
aber auch, dass es Möglichkeiten gibt,
die Ansätze (z.B. in einem Programm) zu
kombinieren bzw. im Rahmen eines PPM
zusammenzuführen.
Wesentlich ist aber, zuvor ein übergeord-
netes Konzept zu entwickeln (und zu schu-
len), das das Zusammenwirken der beiden
Ansätze im Unternehmen definiert und das
dann auch verbindlich von allen Projektlei-
tern und Projektbeteiligten eingehalten wird.
Checkliste
� Die Entscheidung, ob Sie zukünftig
agiles und traditionelles PM einsetzen,
sollte abhängig von der Anzahl der pro-
gnostizierten Projekte sein. Wenn Sie
im Jahr nur ein agiles Projekt durchfüh-
ren, zahlt sich der Aufwand nicht aus!
� Zur Entscheidung, ob in einem
Projekt agil oder traditionell vorgegan-
gen werden soll, kann eine Prognose
der Änderungsrate helfen: Scrumpro-
jekte sind ab einer Änderungsrate von
größer als 30% sinnvoll!
� Agile Projekte machen nur dann Sinn,
wenn die beteiligten Projektmitarbei-
ter mindestens 50% ihrer Kapazität
für das Projekt zur Verfügung stellen,
darunter ist ein traditionell geführtes
Projekt sinnvoller!
� Das Projektportfoliomanagement defi-
niert die notwendigen Daten:
diese sind von den Einzelprojekten zu
liefern, ganz gleich ob diese mit traditi-
onellem PM oder agil geführt werden!
� Voraussetzung für ein funktionierendes
Scrumprojekt ist, bereits Vorerfahrung
gesammelt zu haben: Dies ist die Vo-
raussetzung für ein effizientes, agiles
PM, insbesondere was das Zusam-
menspiel im Team und bezüglich die
Abschätzung (z.B. Velocity) betrifft!
Zusammenspiel Zwischen traditionellem & agilem pm
Ein über-geordnetes Konzept zum Zusam-menspiel der beiden Ansätze ist wesentlich.
Manfred brandstätter, Mba Senior Consultant
M 0049/151/20533932
E manfred.brandstaetter@
pmcc-consulting.com
Mag. Christian sterrer Managing Partner
M 0043/676/845611100
Literaturverzeichnis
Brandstätter, M., Gölzner, H., Siems, F . (2008): Anspruchsgruppen-orientierte Kommunikation, Neue Ansätze zu Kunden-, Mitarbeiter- und Unternehmenskommunikation, Hrsg.,: Siems, F., Brandstätter, M., Gölz-ner, H., Siems, F. Gabler, Wiesbaden.
Brandstätter, M., Stumpf, M. (2012): Nachhaltigkeit im Projektmanage-ment – Bedeutung der Integrierten Kommunikation in der Innen- und Außendarstellung von Projekten. In: Umwelt-, Wirtschaftsforum, Heft 3-4/2012, S. 217-221. Springer, Heidelberg.
Cohn, M. (2004): User Stories Applied. For Agile Software Development, Addison-Wesley, Boston.
Cohn, M. (2005): Agile Estimating an Planning, Prentice Hall, New York.
Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, Hanser, München.
IPMA (2009): IPMA Competence Baseline Version 3.0. http://www.p-m-a.at/ICB-pm-baseline-und-pm-basic-syllabus/View-category.html. (Abfrage: 10.08.2012).
Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einset-zen, DPunkt, Heidelberg.
Schwaber, K./Beedle, M. (2001): Agile Software Development with Sc-rum, Prentice Hall, New York.
Sutherland, J. (2008): http://scrum.jeffsutherland.com/2008/08/agile-2008-money-for-nothing.html (Abfrage: 10.08.2012).
Sterrer, C; Winkler, G. (2009): Setting Milestones, Projektmanagement, Methoden-Prozesse-Hilfsmittel, Goldegg-Verlag, Wien.
www.pmcc-consulting.com