Die Schwierigkeit in diesen

Transkript

1 Möglichkeiten des Zusammenspiels zwischen traditionellem & agilem PM Immer öfter beobachten wir in Unternehmen jene Situation, dass agil geplante und gesteuerte Projekte bzw. Subprojekte (z.b. in der Methode Scrum) in traditionelle Projekte oder Programme (in der Methode IPMA oder PMI) eingebettet werden müssen. von Christian Sterrer & Manfred Brandstätter Die Schwierigkeit in diesen Vorhaben besteht in erster Linie darin, dass in der agilen Methode durch das iterative Vorgehen keine oder nur schwierig zu definierende Vorhersagen für den Leistungs-, Zeit- und Kostenrahmen zu treffen sind, während die traditionelle Methode von einer quasi-konkreten Vorgabe in Leistung, Terminen und Kosten ausgeht (Gloger, 2008, S. 60ff.; Pichler, 2008, S. 7ff.) Mit folgenden Fragen- bzw. Aufgabenstellungen sehen sich die Verantwortlichen derartiger Projekte konfrontiert: Geht das überhaupt? Widerspricht das nicht einerseits den agilen Grundsätzen bzw. andererseits den traditionellen Projektmanagementmethoden? Und wie sind agil geführte Projekte in einem unternehmensweiten Projektportfoliomanagement sinnvoll zu integrieren? Wir denken nicht, dass sich Tradition und Agilität wider- sprechen und werden hier versuchen dies zu argumentieren. Im nachfolgenden Beitrag werden wir anhand zweier Beispiele die Möglichkeit des Zusammenspiels von traditionellem und agilem Projektmanagement darstellen. Das Fallbeispiel A stellt die Integration eines agil geführten Projekts in einem traditionell gemanagten Programm zur Entwicklung einer webbasierenden Personalmanagement-Software dar. Das Fallbeispiel B stellt die Implementierung eines Projektportfoliomanagements 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 unterscheidet sich massiv vom traditionellen 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 nachkommen werden. 2. Projektorganisation Während das traditionelle PM grundsätzlich von den Projektrollen Projektauftraggeber, Projektleiter, Projektteammitglied und Projektmitarbeiter (optional weitere Rollen, wie z.b. Projektlenkungsausschuss, etc.) ausgeht, 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.).

2 3. PM-Methoden und Instrumente Ohne auf eine detaillierte Beschreibung der Instrumente und Methoden einzugehen, wird schon anhand der groben Gegenüberstellung (siehe dazu Abbildung 1) der beiden PM-Methoden ein großer Unterschied sichtbar. Während zum Beispiel im traditionellen Projektmanagement 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. Abb. 1: Grober Vergleich zw. den Projektphasen der traditionellen und agilen Methode 4. PM-Prozesse Das traditionelle PM definiert die Prozesse: Projektbeauftragung, Projektstart (Projektplanung), Projektkoordination, Projektcontrolling (Realisierungsphase) und Projektabschluss. Im agilen PM existieren zunächst simple dafür jedoch iterativ wiederkehrende Abläufe. Die Erstellung zum Beispiel des Product Backlogs (analog zur Produktspezifikation 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 Retrospective Meeting werden dabei als Bestandteile des Prozesses für die Leistungsfortschrittskontrolle, die Risikobetrachtung- und bewältigung, sowie die kontinuierliche Verbesserung innerhalb eines agilen Projektes definiert. Abbildung 1 bietet einen groben Überblick der beiden PM-Methoden und wagt dazu einen ungefähren Vergleich. In der Realität stehen derzeit viele Unternehmen vor der Herausforderung, traditionelles und agiles Projektmanagement zu kombinieren. Nachfolgend werden zwei Beispiele möglicher praxisbewährter Ansätze beschrieben. Fallbeispiel A: Agiles Release Management mittels Meilensteinsteuerung und Richtwertermittlung im Vorfeld Die Grundlage der nachfolgend beschriebenen Methode ist einerseits aus dem Bedürfnis heraus entwickelt worden, agile und traditionelle Planungsund Steuerungsmethoden in Projekten zu kombinieren und andererseits aus den Erkenntnissen der integrierten Kommunikation als Erfolgsfaktor in Projekten (vgl. Brandstätter/ Gölzner/Siems, 2008; Brandstätter/Stumpf, 2012). Bei dem nachfolgend beschriebenen Fallbeispiel handelt es sich um ein abgeschlossenes IT-Projekt. Dabei wird ein Projekt zur Entwicklung einer Software für ein Internet-basierendes Personalmanagement System eines Handelsunternehmens der Automobilbranche beschrieben. Dieses Projekt ist im Kontext eines Change Management Programms eingebunden. Das Gesamtprogramm wird in der Stabsstelle des Unter- nehmens mit den traditionellen Methoden des Projekt- bzw. Programm Managements nach IPMA (vgl. IPMA, 2009) geplant und zentral gesteuert. Das darin eingebettete Projekt der Softwareentwicklung führt die unternehmenseigene IT-Abteilung ebenfalls via traditioneller PM-Methode durch. Ein Teilprojekt daraus wird gemeinsam mit einem externen Unternehmen durchgeführt. Dieses externe Softwareunternehmen 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 darin, liegt in zwei Aspekten begründet, der Richtwertermittlung und dem Meilenstein-gesteuerten Release Managment (siehe Abb. 2). In der Ermittlung eines sogenannten Richtwertes werden die komplexen Anforderungen 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).

3 Das Softwareunternehmen erstellt im Vorfeld entweder als eigenes Teilprojekt oder als Meilenstein im Rahmen des Gesamtprojektes 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 diese Vorgehen in Form eines eigenen Teilprojektes durchgeführt. Abb. 2: Gesamtdarstellung der Methode des Agiles Release Management mittels Meilensteinsteuerung Die Planung und die Einbettung des Teilprojektes in das Gesamtprojektmanagement erfolgt im zweiten Schritt der Methode, nämlich in Form des Meilenstein-gesteuerten Release Managements. Dabei fließen die Ergebnisse der Vorplanung (Richtwert) in die Planung und Umsetzung des Release Managements ein. Es werden die Spezifikationen wir sprechen dabei nur mehr von Product Backlog Items kategorisiert, 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, Produktverantwortlichem (Product Owner) und Anwender (Kunden). Die Releases werden anschließend mit dem Software Unternehmen und dem zentralem Projektmanagement gemeinsam in einzelnen Meilensteinen geplant und gesteuert. Folgende detaillierte Vorgehensweise liegt dieser Methode nun zugrunde: 1. Ermittlung des Richtwertes Die Methode zur Ermittlung des Richtwertes beschreibt jene Vorgehensweise, um ausgehend von einer herkömmlichen Funktionsbeschreibungen (z.b. in Form von Lasten- oder auch Pflichtenheften), eine initiale Schätzung zu bekommen, die einerseits dem agilen Vorgehen gerecht wird und andererseits dem traditionellen Projektmanagement eine ungefähre Orientierungshilfe gibt (siehe Abb. 3 im Pkt. 1). Im Folgenden schätzt nun das Software-Team die relative Größe der Funktionen (User Stories) auf Basis von Story Points, so dass am Ende eine initiale Schätzung des gesamten Software Projekts vorliegt. Das Schätzen kann entweder mit Affinity Estimating erfolgen, weil es am schnellsten und effektivsten 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 Softwareunternehmen mit dem Kunden zu einer sogenannten Definition of Done (DoD) ab, die insbesondere auch Qualitätskriterien definiert und festlegt, ob die Anwendung beispielsweise mit automatisierten Fachtests 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öglich unterschiedlichen Schwierigkeitensgrade (Richtwert Stories) auf Tasks (Richtwert Tasks) herunter und entwickeln Design Ideen für die Umsetzung. Auf Basis der DoD erstellt das Team (hautpsächlich der Product Owner) eine Expertenschätzung 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ätzungen für die weiteren

4 sich in keiner Weise vom herkömmlichen Schätzverfahren. Eine weitere Variante ist die Methode Money 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 gelieferte Funktionalität ausreichend ist. Die Differenz des Aufwandes wird geteilt, d.h. der Dienstleister erhält die Hälfte des Geldes für den nicht geleisteten Aufwand und der Kunde spart die andere Hälfte ein (vgl. Sutherland, 2008). Abb. 3: Vorgehensmodell des Meilenstein-gesteuerten Agilen Release Managements und Richtwertermittlung im Vorfeld Stories ermittelt. Man erhält so einen Umrechnungsfaktor von Story Points auf Personentage und umgekehrt (1 Story Point = X Tage Aufwand; 1 Personentag = X Story Points). Auf Basis dieser initialen Schätzung des Backlogs in Storypoints und des Umrechnungsfaktors kann nun der Personalaufwand 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 Festpreises für agile Projektvorgehen verwendet werden). Wichtig dabei ist folgende Aussage: A) Diese 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 Philosophie 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 2. Planung und Kategorisierung der Release #1 (und nachfolgende) Der nachfolgende 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 gemeinsam mit dem Product Owner des Software Teams (in Abstimmung mit dem Kunden) nur kategorisierte Anforderungen (Backlog Items) in die nachfolgende Release-Planung aufgenommen (siehe 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 innerhalb des Softwareunternehmens (siehe Abb. 3 im Pkt. 3).

5 Reports via Burn-Down-Chart vom aktuellen Release durch den Product Owner des Scrum Projektes an das zentrale Projektmanagement. 5. Releasetest & -abnahme Der finale Test und die Abnahme des gesamten Release passiert gemeinsam mit dem Team, Product Owner und Kunden und schließt als letzten Meilenstein den aktuellen Release ab. Abb. 4: Beispiel einer traditionellen PM-Prozesslandkarte, beinhaltet sowohl Einzelals auch Projektportfoliomanagement-Prozesse 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, der jeweilige Aufwand, der auf der initialen Schätzung basiert. Diese inhaltliche Grobplanung des Release wird vom Softwareunternehmen entweder direkt an den Kunden (wird empfohlen) oder über das zentrale Projektmanagement in Form eines Teilangebotes (jeweils spätestens ein Monat vor Umsetzung eines Releases an den Kunden) gelegt. Sie muss für eine zeitgerechte Umsetzung eines Releases bis spätestens zum 15. des jeweiligen Monats vom Kunden bestätigt sein (siehe Abb. 3 im Pkt. 4). Änderungen werden in jedem Fall vom Product Owner des Softwareunternehmens dem zentralen Projektmanagement in Form eines Change Requests (einer Änderung im Leistungsumfang) gemeldet. Die Umsetzung und Abnahme der jeweiligen Sprints wird im jeweiligen Entwicklungszyklus nach der Methode Scrum durchgeführt. Das diesbezügliche Prozedere wird daher hier in diesem Artikel nicht explizit beschrieben. Die darin erforderlichen Sprint Reviews und Retrospectives werden sofort im Anschluß 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 Sprintergebnis (z.b. unvollständig umgesetzte User Stories) werden dem zentralen Projektmanagement nach dem Sprint Review gemeldet. Ebenso werden auftretende Probleme innerhalb der Sprints (z.b. Abbruch eines Sprints, Anhäufung ungelöster Probleme) durch den Product Owner an das zentrale Projektmanagement sofort berichtet. Bewährt hat sich die Risikoprävention in Form eines wöchentlichen Fallbeispiel B: Übergeordnetes Projektportfoliomanagement für traditionelle und agile Projekte 1. Ausgangssituation Ein mittelständisches Versicherungsunternehmen in Deutschland implementiert ein unternehmensweites Projektportfoliomanagement. Die Vielzahl der Einzelprojekte (EPM) werden nach traditionellem Projektmanagement abgewickelt, einige wenige Projekte im IT-Bereich werden agil durchgeführt. Die Aufgabenstellung war: Wie kann ein effizientes, einheitliches Projektportfoliomanagement etabliert werden und trotzdem sowohl der traditionelle als auch der agile Projektmanagement- Ansatz akzeptiert werden? 2. Vorgehensweise Zunächst wurde das Projektportfoliomanagement (PPM) definiert. Die Definition umfasste: Definition der PPM-Organisation Definition der PPM-Prozesse Definition der PPM-Daten In der PPM-Organisation wurden die relevanten Rollen

6 Abb. 5: Projektmanagement-Dreieck: zeigt die Zusammenhänge der Leistungen, Termine, Ressourcen und Kosten auf Abb. 6: Beispiel einer PM-Methodenliste inkl. Zusammenhang zu Scrumprojekte und Gremien (also Projektmanagementoffice, Projektesteuerungskreis (PSK), etc.) als auch die Kommunikationsstrukturen (Häufigkeit und Inhalte der PSK-Sitzungen) und Spielregeln definiert (vgl. IPMA, 2009). Die PPM-Prozesse beinhalteten insbesondere die Folgejahresplanung (strategische Planung des PPF für das folgende Geschäftsjahr), die Projektbeauftragung, das PPF-Controlling (Steuerung der laufenden Projekte) und die Projektabnahme sowie Projektevaluierung. Weiters wurden die Schnittstellen zu den EPM-Prozessen definiert. Schlussendlich wurden alle relevanten 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üglich Anforderungen an die Projekte (sowohl traditionelle als auch agile Projekte). Darauf aufbauend wurde das Einzelprojektmanagement definiert. Dazu wurde eine PM- Methodenliste vereinbart, in der auch nochmals zwischen Projekte und Kleinprojekte differenziert wurde (siehe Abb. 6). Aufgrund der Prozessvorgabe im PPM (monatliche PSK-Sitzungen) wurde automatisch das Projektcontrolling-Intervall der Einzelprojekte festgelegt. Die PM-Methodenliste 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 Aufgabenstellung 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 PL agiler Projekte erstellen einen Projektauftrag und stimmen diesen mit einem Projektauftraggeber ab (der Projektauftrag ist für traditionelle und agile Projekte ident). Es muss monatlich ein Projektstatusbericht erstellt werden (auch ident zum traditionellen PM). Es muss ein Mindestmaß an Projektdaten zum Projektmanagementdreieck (Leistungen, Termine, Ressourcen und Kosten) geliefert werden. Leistungen Die Sprints werden als Arbeitspakete dargestellt und darauf aufbauend auch der Leistungsfortschritt ermittelt (z.b. sind 12 Sprints à 1 Monat geplant und bereits 6 Sprints abgearbeitet, dann ist der Leistungsfortschritt 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 bedeutet 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 prozentuellen Zuteilung zum Projekt berechnet werden, die Ist-Stunden werden auf Projektebene erfasst, die Hochrechnung der Gesamtstunden (Ist + Rest) bleibt unverändert, solange sich die Anzahl der Sprints und die prozentuale 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.

7 Checkbox: Agiles & traditionelles PM Zur Entscheidung, ob Sie zukünftig agiles und traditionelles PM einsetzen, sollte abhängig von der Anzahl der prognostizierten Projekte sein. Wenn Sie im Jahr nur ein agiles Projekt durchführen, zahlt sich der Aufwand nicht aus! Zur Entscheidung, ob in einem Projekt agil oder traditionell vorgegangen werden soll, kann eine Prognose der Änderungsrate helfen: Scrumprojekte sind ab einer Änderungsrate von größer 30% sinnvoll! Agile Projekte machen nur dann Sinn, wenn die beteiligten Projektmitarbeiter mindestens 50% ihrer Kapazität für das Projekt zur Verfügung stellen, darunter ist ein traditionell geführtes Projekt sinnvoller! Das Projektportfoliomanagement definiert die notwendigen Daten: diese sind von den Einzelprojekten zu liefern, ganz gleich ob diese mit traditionellem PM oder agil geführt werden! Voraussetzung für ein funktionierendes Scrumprojekt ist, bereits Vorerfahrung gesammelt zu haben: dies ist die Voraussetzung für ein effizientes, agiles PM, insbesondere was das Zusammenspiel im Team und bezüglich der Abschätzung (z.b. Velocity) betrifft! 3. Lessons Learned Das PPM setzt auf traditionelle Projektinformationen 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, unternehmensweiten PPM. Zusammenfassung Es ist im Unternehmen gut zu überlegen (und auch strategisch zu entscheiden), ob der traditionelle und agile Projektmanagementansatz eingesetzt werden soll. Diese Entscheidung erhöht die Komplexität des Projektmanagements im Unternehmen 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. 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 zusammen zu führen. Wesentlich ist aber ein übergeordnetes Konzept zuvor zu entwickeln (und zu schulen), das das Zusammenwirken der beiden Ansätze im Unternehmen definiert und das dann auch verbindlich von allen Projektleitern und Projektbeteiligten eingehalten wird. Die Autoren Christian Sterrer (Mag., geboren 1968) ist Gründer und geschäftsführender Gesellschafter der pmcc consulting GmbH, Referent an mehreren Hochschulen (Steinbeis Hochschule Berlin, UNI St. Gallen, etc.) und Erfolgsautor zum Projektmanagement. Seine 20jährige, internationale Erfahrung als Trainer, Coach und Berater projektorientierter Organisationen macht ihn zu einem der führenden Experten zum Projektmanagement im deutschsprachigen Raum. Manfred Brandstätter (MBA, geboren 1959) ist Autor verschiedener Publikationen zum Thema temporäre Unternehmensorganisation mit Schwerpunkt agile Projektorganisation, Projektleiter, Wirtschaftstrainer und Hochschuldozent. Manfred Brandstätter hat sich in den letzten Jahren seiner über zwanzigjährigen Tätigkeit als internationaler Projektleiter auf Krisenmanagement und Turnaround Management von Technologieprojekten spezialisiert. Literaturverzeichnis Brandstätter, M., Gölzner, H., Siems, F. (2008): Anspruchsgruppen-orientierte Kommunikation, Neue Ansätze zu Kunden-, Mitarbeiterund Unternehmenskommunikation, Hrsg.,: Siems, F., Brandstätter, M., Gölzner, H., Siems, F. Gabler, Wiesbaden. Brandstätter, M., Stumpf, M. (2012): Nachhaltigkeit im Projektmanagement Bedeutung der Integrierten Kommunikation in der Innenund Außendarstellung von Projekten. In: Umwelt-, Wirtschaftsforum, Heft 3-4/2012, S 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 html. (Abfrage: ). Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, DPunkt, Heidelberg. Schwaber, K./Beedle, M. (2001): Agile Software Development with Scrum, Prentice Hall, New York. Sutherland, J. (2008): (Abfrage: ). Sterrer, C; Winkler, G. (2009): Setting Milestones, Projektmanagement, Methoden-Prozesse-Hilfsmittel, Goldegg-Verlag, Wien.