Zusammenspiel Zwischen traditionellem & agilem pm · agilem Projektmanagement darstellen. Das Fallbeispiel A stellt die Integration eines agil geführten Projektes in einem traditionell

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“


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


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


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


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


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.


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


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


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


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!


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

E [email protected]

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

Documents

Zusammenspiel Zwischen traditionellem & agilem pm · agilem Projektmanagement darstellen. Das Fallbeispiel A stellt die Integration eines agil geführten Projektes in einem traditionell