Agilität im Auftraggeber- Auftragnehmer-Spannungsfeld

Transkript

1 Agilität im Auftraggeber- Auftragnehmer-Spannungsfeld Mit hybridem Projekt-Ansatz zur Win-Win-Situation Dr. Claus Hüsselmann, Hamburg,

2 Agilität im Auftraggeber Auftragnehmer-Spannungsfeld Inhalt Motivation Kritik am Wasserfallmodell Chance der Agilität Das Beste aus beiden Welten vereinen Anwendungsbeispiele PM-Elemente im Wandel Fazit Seite 2

3 Auftraggeber Spannungsfeld Auftraggeber-Auftragnehmer-Projekt Kunde- und Dienstleister-Ziele sind oftmals gegenläufig Kostenreduktion Umsatz-/Ergebnismaximierung Flexibilität und Anpassungsfähigkeit an Geschäftsanforderungen Erfahrene Ressourcen Vorhersagbarkeit der Kosten Wiederholbare Prozesse der Standardisierung und Vorhersagbarkeit Ressourcen mit den niedrigsten Kosten, um die Aufgaben zu bearbeiten Aufwands-bezogene Fakturierung; wenig Risiko Auftragnehmer Befassung mit nur einem Ansprechpartner Verschiedene und oftmals im Wettbewerb stehende Bereiche im Kundenengagement Seite 3

4 gedeckelter Spannungsfeld Auftraggeber-Auftragnehmer-Projekt Werkvertrag mit Festpreis als konventionelle Lösung Wasserfall der Auftragnehmer- Auftraggeber-Beziehung: Klassifizierung der Vertragsarten: Leistungsbeschreibung/ Lastenheft Dienstleistung Legal- Perspektive Gewerk Leistung Angebot/ Pflichtenheft kaufm. Perspektive Festpreis Aufwand Time & Material Scope/Festpreis/ Vertrag führt i.a. zu einer Pareto-ineffizienten Situation! Gewerk/ Abnahme Fakturierung Werkvertrag bedeutet nicht zwangsläufig Festpreis, Dienstleistungsverträge sind nicht zwangsläufig Aufwandsprojekte! Seite 4

5 Typische Wasserfallmodelle Beispiel Standardsoftware-Einführung Traditionelle Vorgehensmodelle folgen vielfach einem wohldefinierten Phasenbzw. Wasserfallmodell. Dabei werden die definierten Phase sequentiell abgearbeitet: Strategy Project Preparation Business Blueprint Realization Go-Live Preparation Go-Live & Support Controlling Die einzelnen Phasen erreichen dabei eine Dauer von bis zu einem Jahr. Sichtbare Ergebnisse werden i.d.r. in der zweiten Projekthälfte produziert, was ggf. ein Jahr oder mehr nach Projektstart sein kann. Es wird davon ausgegangen, dass jede Phase mit Erreichen eines Meilensteines abgeschlossen ist spätere Rücksprünge sind nicht vorgesehen. Damit entfällt die Möglichkeit, Zwischenergebnisse auf der Basis von Feedback-Prozessen anzupassen. Seite 5

6 Kritik am Wasserfallmodell Das strenge Phasen- oder Wasserfallmodell traditioneller Methoden führt zu Wissensaufbau auf Halde Intransparenz bzgl. des Projektfortschritts Vernachlässigung des sich ändernden Projektumfelds Untersuchungen ergeben regelmäßig, dass z.b. bei mehr als der Hälfte aller ERP-Implementierungen geplante Zeit- und/ oder Kostenziele nicht erreicht werden: Quelle: Panorama Consulting Group, 2010 Seite 6

7 Kritik am Wasserfallmodell Konventionelle Reaktionen Kunden von Beratungshäusern reagieren darauf mit verstärkter Forderung von vermeintlichen Sicherheiten wie z.b. Vertragsstrafen oder Festpreisen, was wiederum zur Kalkulation von Zuschlägen und/oder Sicherheitspuffern führt. Beratungshäuser reagieren darauf mit Anpassungen des Vorgehens im Projekt, was z.t. in die richtige Richtung geht, die wesentlichen Kritikpunkte jedoch nicht umfassend adressiert Prototyping Baseline-Ansätze Best Practices Seite 7

8 Die Lösung Sind Sie schon agil? Klassisches PM ist doch Schnee von gestern, wir machen nur noch agile Projekte Klassische Methoden gelten als unflexibel dogmatische Vorgaben zu dokumentationslastig Beschäftigungstherapie für PL/PMO Agile Methoden gelten als unvollständig unausgereift nur in der IT anwendbar Trail & Error -Methode Seite 8

9 Aktuelle Nutzung von agilen Methoden (I) Agile Methoden werden inzwischen in den unterschiedlichsten Bereichen eingesetzt Quelle: Studie Status Quo Agile 2014 Seite 9

10 Aktuelle Nutzung von agilen Methoden (II) Vier Fünftel der Anwender sehen Verbesserungen durch agile Methoden Quelle: Studie Status Quo Agile 2014 Seite 10

11 Chancen der Agilität Agiles Manifest Im Februar 2001 wurde das Agile Manifest formuliert. Dabei wurden vier wesentliche Werte als Basis definiert: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. Die stetige Abstimmung mit dem Kunden ist wichtiger als die ursprüngliche Leistungsbeschreibung in Verträgen. Funktionierende Programme sind wichtiger als ausführliche Dokumentation. Der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans. Agile Prinzipien sind Leitsätze für die agile Arbeit, auch wenn sie häufig (bewusst falsch) als Methode bezeichnet werden. Agile Methoden sind an den Prinzipien der Agilität ausgerichtete Methoden zur Softwareentwicklung. Seite 11

12 Scrum die prominenteste agile Methode (?) Wesentliche Elemente (1/2) Scrum ist ein Vorgehensmodell, bei dem die Lieferung der Ergebnisse sukzessive erfolgt. Scrum basiert auf folgenden wesentlichen Elementen: Rollen ( Roles ) Scrum kennt drei klar getrennte Rollen. Artefakte ( Artifacts ) Das zu lieferende Produkt wird sukzessive erstellt. Dies erfolgt im Rahmen sog. Sprints. Meetings ( Ceremonies ) Scrum kennt regelmäßige Meetings mit definierten Zielsetzungen und Vorgehensweisen. Seite 12

13 Scrum die prominenteste agile Methode (?) Wesentliche Elemente (2/2) Der Erstellung eines Produkts erfolgt gemäß Scrum in einem Zyklusmodell. Zentrales Element ist dabei der Sprint: Ein Sprint bezeichnet die Umsetzung einer Iteration, wobei ca. 30 Tage als Iterationslänge vorgeschlagen werden. Am Ende eines Sprints steht immer eine lauffähige, getestete, inkrementell verbesserte Software. Quelle: Wikipedia, ScrumAlliance.org Seite 13

14 Scrum die prominenteste agile Methode (?) Typische Elemente Wohldefinierte, zeitlich begrenzte Arbeitsphasen (Timeboxing) Dynamische Anpassung des Umfangs ( Scopes ) möglich/immanent Häufige Rückkopplung zwischen Projektteam und Nutzer Systematischer Kontinuierlicher Verbesserungsprozess (KVP) der Projektarbeit Kleine Teams Interdisziplinäre Teams ( Omnipotenz ) Optimierung Kosten-Nutzen-Verhältnis ( Design to Budget ) Seite 14

15 Agilität vs. Wasserfall Typische Einsatzspektren Quelle: Google Tech Talks Ken Schwaber Wasserfall: Klar definierte Anforderungen Bekannte Technologien Unerfahrenes Team Hohe vertragliche Sicherheit Unsicheres AG-AN- Vertrauensverhältnis Hohe Anforderungen an Dokumentation & Nachvollziehbarkeit Scrum: Unklare Anforderungen Neue Technologien Eingespieltes Team Druck auf Time-to-Market Zeitnahe Fortschrittstransparenz Vertrauensvolles AN-AG-Verhältnis Seite 15

16 Agiles Vorgehen erfordert Interaktion Schnelle Rückkopplung durch Anwender: Anforderungen/Lastenheft Product Backlog = Realisierungskonzept/ Business Blueprint Sprint Backlog Sprint Backlog sequenzielle Bearbeitung Sprint Backlog Fachabteilungen Systementwicklung Sprint 1 Sprint 2 weitere Sprints Sprint n Inkrement weitere Ergebnisse Inkrement Akzeptanz Einführungskoordination (Planung, Cut Over, Change Mgmt., Trainings, etc.) Nutzung Seite 16

17 Hybrides Modell Wasserfall-Grundmodell Agile Zusatzelemente Auftrag Produktivstart Initiate Plan Design Build Prepare Run Realisierungskonzept/ Business Blueprint für Customizing-Anteil Für Zusatzentwicklungen: Design to Budget Dynamischer Scope Schnelle Rückkopplungszyklen Timeboxing Gemischte Teams Product Backlog/ Sprint Backlogs Daily Scrums für Zusatzentwicklungsanteil Sprints Seite 17

18 gedeckelter Hybrides Modell Ausgestaltung Agiles Vorgehen für Projektanteile wie z.b. Reporting Grundsätzlich früher Start möglich (jedoch Abhängigkeit vom Business Blueprint zu beachten) Synchronisation spätestens zur Integrationstestphase nötig Wiederholte Ausrichtung des Backlogs (Scope) erzeugt Pareto- Optimum (für alle Parteien) Vertragsgestaltung muss dieses zulassen, z.b. Änderungen nach Business Blueprint- Fertigstellung ( Version 1.0 ) Festlegung eines Budgets Definition von Fähigkeiten & Kapazitäten Angepasstes Change Request-Verfahren Dienstleistung Legal- Perspektive kaufm. Perspektive Gewerk Festpreis Leistung Fakturierung Aufwand Time & Material Seite 18

19 Charakterisierung der Vorgehensmodelle Im Kontext einer Vertragsgestaltung Agile bzw. rein Phasen- ( Wasserfall -) orientierte Projektvorgehensweisen lassen sich insbesondere bei Projekten mit Festpreisbeauftragung für externe Dienstleister wie folgt charakterisieren: Steuerung bei Wasserfall -Vorgehen Steuerung bei agilem Vorgehen Umfang Kosten Zeit fest Mehrwertorientiert Planorientiert variabel Kosten Zeit Umfang angelehnt an: Opelt, Gloger, Pfarl, Mittermayer: Der Agile Festpreis Seite 19

20 Rollen und Risikosphären bei Scrum-Projekten Die Verteilung der Rollen und damit der Schnitt der Risikosphären ist für die Vertragsgestaltung wesentlich Scrum Master AN Werkvertrag Scrum Master AG Dienstleistungsvertrag Scrum Master Management Product Owner Product Owner AG Werkvertrag noch möglich (kritisch) angelehnt an: Borkert, Agile Verträge für agile Projekte?! PM Forum 2014 Entwicklungs- Team Entwicklungsteam gemischt Dienstleistungsvertrag Seite 20

21 Methodenauswahl Taxonomie klassisch agil Innovation Neuartigkeit des Projektgegenstands gering hoch Quick Wins gering hoch AG/AN-Vertrauen gering hoch Team-Kultur (flache Hierarchie) gering hoch Einzelziele im Zielsystem Flexibilität & Geschw. der Unternehmensprozesse Anforderungen an System-Dokumentation hoch gering hoch gering hoch gering Seite 21

22 Anwendungsbeispiel Testmanagement Nach 1 Jahr Projektlaufzeit erfolgreicher Produktivstart Ein Projekt von Seite 22

23 Anwendungsbeispiel Testmanagement Übertragung agiler Grundprinzipien auf die Testdurchführung: (Test-)Datenübernahme Test 1 Fehlerbehebung 1 Rücktest 2 Fehlerbehebung 2 (Test-)Datenübernahme Begleitete Tests und direkte Fehlerbehebung Puffer Übliches Vorgehen Agiles Testmanagement Seite 23

24 Anwendungsbeispiel Testmanagement Testdurchführung in Test-Sprints sichert Produktivstart: Testcluster 1 (User Acceptance) Woche/Sprint 1 Woche/Sprint 2 testen beheben puffer testen beheben puffer Neuausrichtung nach Woche 2 Testcluster 2 (Operationel Acc.) testen beheben puffer Seite 24

25 Agiles Testmanagement Die Anwendung agiler Methoden: Sprint Backlog: Auswahl der wichtigsten Testfälle für die kommende Woche Daily Scrum-Meeting: Tägliche Teammeetings zur Feststellung der Lage und Klärung offener Fragen Team Room: Räumliche Konzentration von Testern & Technikern an einem Ort Burndown Chart: Tägliche Feststellung des Testfortschritts Scrum Master: Testmanager Product Owner: Autorisierter Nutzervertreter Seite 25

26 Anwendungsbeispiel Rollout-Projekt In der BVBS werden Mitarbeiter in 69 Behörden an 200 Standorten durch über Anwender mit PVS effizient eingesetzt. Ein Projekt von Seite 26

27 Anzahl Projektorganisationen Anwendungsbeispiel Rollout-Projekt Phasenmodell: Rollout 2 Lern- und Effizienzkurve Rollout 1 50 Legal Units Pilotierung 15 Legal Units Seite 27 3 Legal Units Projektphasen/Dauer

28 Anwendungsbeispiel Rollout-Projekt Timeboxing & zeitnahe Lessons Learned: Ablaufstruktur Woche Aktivität Know How-Transfer (zentral) Prozess-Transfer (vor Ort) Prozess-Transfer (vor Ort) Informationsbeschaffung (dezentral) Informationskonsolidierung (zentral) Roll-In Customizing (zentral) Seite 28

29 Hybrider Ansatz auf Unternehmensebene Flexible Kombination von Agilität und Phasenorientierung Unternehmens- oder Programmmanagement Lenken Lenken des Projekts übergeordneter PM-Rahmen Managen Vorbereitung des Projekts Initiierung des Projekts Managen eines Phasenübergangs Abschließen des Projekts Steuerung einer Phase Liefern Einzelausführung DL Managen der Produktlieferung

30 Das Rollenmodell im Wandel Schema (Gesamt-) Projektleiter Teilprojektleiter/ Entwicklungskoord. Product Owner Qualitätsmanager Scrum Master Integrationsmanager/Architekt Process Owner/ Bedarfsträger Project Officer (PMO) Seite 30

31 Das Rollenmodell im Wandel Beschreibung Product Owner (Gesamt-) Projektleiter Verantwortung für das Erreichen der Projektziele, definiert und priorisiert Product Backlog, betreibt Stakeholder Management Scrum Master Integrationsmanager/ Lösungsarchitekt Process Owner/ Produktmanager/ Bedarfsträger Teilprojektleiter/ Entwicklungskoordinator fungiert als Chief Engineer, hat fundiertes technisches Verständnis, trifft übergreifende Architekturentscheidungen entscheidet über Leistungsmerkmale des Produktes, verantwortet Produkt ggf. über Release-Zyklen, repräsentiert/versteht Endkundenbedürfnisse agiert als Coach, stellt Ablauf sicher, räumt Hindernisse aus dem Weg, schützt das Team ggü. Einwirkung von außen, unterstützt bei der Verbesserung der Praktiken Qualitätsmanager agiert als Methoden-Coach, stellt sicher, dass das Vorgehen eingehalten wird, hat keine Weisungsbefugnis oder direkte Ergebnisverantwortung, kann moderierend einwirken Project Officer (PMO) wie oben Seite 31

32 Gegenüberstellung der PM-Elemente Adaption mit agilen Komponenten Ausgewählte Elemente der Methoden lassen sich (bspw.) wie folgt überführen: Klassik Scrum Artefakte: Produktstrukturplan Product Backlog Arbeitspaket Register off. Punkte Sprint Backlog Ausnahmebericht Impediment Backlog Seite 32

33 Aktuelle Nutzung von agilen Methoden (III) Ca. 2/3 der Anwender praktizieren eine hybride oder fallweise Anwendung Quelle: Studie Status Quo Agile 2014 Seite 33

34 Fazit Agile Vorgehensweisen bzw. Merkmale in klassischen Projektansätzen können zielführend und gewinnbringend eingesetzt werden. Agilität bedeutet dabei nicht nur Laufende Anpassung des Scopes oder gar Planlosigkeit. Die Adaption zentraler agiler Elemente (z.b. Timeboxing, Lessons Learned) in traditionelle Ansätze ermöglich Best-of-Breed. Eine entsprechende Unternehmenskultur sowie ggf. ein Vertrauensverhältnis zwischen Auftraggeber und Auftragnehmer ist wichtiger Erfolgsfaktor. Die Vertragsgestaltung in einer Auftraggeber-Auftragnehmer- Relation muss hierbei angepasst werden, was aber im Rahmen üblicher Vertragskonstrukte erfolgen und zu einer Win-Win-Situation führen kann. Seite 34

35 Vielen Dank für Ihre Aufmerksamkeit! Am Tullnaupark 15 D Nürnberg Seite 35