22 l projekt MA N A G E M E N T aktuell 1/ 2014 38 WISSEN 1 Einleitung Typische Projektkonstellationen anspruchsvoller, komplexer Projekte beinhalten in der Regel immanent das Konstrukt einer Auftraggeber-Auftragnehmer-Konstellation. Denn es ist ja gerade das Wesen von Projekten, in einer recht einzigartigen Aufgabenstellung für einen begrenzten Zeitraum interdisziplinäre Kapazitäten in einer temporären Organisation zusammenzuführen. Dazu bedarf es im Allgemeinen eines Vertragswerks. Doch welcher Auftraggeber bestellt schon gerne etwas, dessen Umfang und Eigenschaften er zum Zeitpunkt des Vertragsschlusses nicht genau greifen kann. Ganz zu schweigen von dem Wunsch nach Festpreisen und Gewerken, welche eine genaue A-priori-Spezifikation des Leistungsgegenstands verlangen. Die klassische Auftraggeber-Auftragnehmer-Beziehung nach DIN bzw. V-Modellen ist entsprechend gekennzeichnet durch die in Abbildung 1 dargestellte grundsätzliche, formelle Sequenz. Damit wird formelle Integrität, aber nicht maximale Nutzeneffizienz erreicht. Der vorliegende Beitrag postuliert anhand des Typs eines ERP-Systemeinführungsprojekts 1 einen „hybriden Projektansatz“, der das sogenannte Wasserfallvorgehen mit einem agilen Vorgehen nutzenmaximierend kombiniert. 2 Kritik am Wasserfallmodell Traditionelle Methoden der Softwareentwicklung (z. B. V-Modell ® XT) oder Standard-Softwareimplementierung (z. B. AcceleratedSAP ® ) folgen im Allgemeinen einem wohldefinierten Phasenbzw. Wasserfallmodell. Dabei werden die definierten Phasen sequenziell abgearbeitet und erreichen vielfach eine Dauer von bis zu einem Jahr, zum Beispiel in einem komplexen SAP-Implementierungsprojekt. Sichtbare Ergebnisse werden in der Regel in der zweiten Projekthälfte produziert, was gegebenenfalls 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. Das strenge Phasen- oder Wasserfallmodell traditioneller Methoden führt zu ❑ Wissensaufbau auf Halde: In jeder Phase wird eine große Menge detailliertes Wissen erworben und dokumentiert. Der Einsatz des Wissens erfolgt zu einem großen Teil zeitlich entkoppelt in nachgelagerten Phasen. ❑ Intransparenz bezüglich des Projektfortschritts: Da erworbenes Wissen häufig erst sehr viel später umgesetzt wird, kann keine unmittelbare Verifikation der Korrektheit durch Anwendung („Proof of concept“) erfolgen. Agilität im Auftraggeber- Auftragnehmer-Spannungsfeld Mit hybridem Projektansatz zur Win-win-Situation Das Schlagwort „Agilität“ ist heute aus dem Aufgabengebiet des Projektmanagements bzw. dessen Vorgehensmodellen nicht mehr wegzudenken. Doch die Situation der Unternehmenspraxis - gerade auch jenseits von Inhouse-Softwareentwicklungen beispielsweise in Software-Einführungs- und -Beratungsprojekten - lässt nach eigenen Erkenntnissen nicht den Schluss zu, dass agile Ansätze schon flächendeckend Fuß gefasst hätten. So sind beispielsweise Organisationsprojekte, die nach agilem Denkmuster verliefen, eher gar nicht bekannt [3]. Ist Agilität letztlich nur ein (weiteres) Schlagwort, das durchs Projektdorf getrieben wird? Oder vielleicht nur praktikabel anwendbar auf die bereits oben genannte Aufgabenstellung der Inhouse-Softwareentwicklung? Claus Hüsselmann Ist Agilität letztlich nur ein (weiteres) Schlagwort, das durchs Projektdorf getrieben wird? Oder vielleicht nur praktikabel anwendbar auf die Aufgabenstellung der Inhouse-Softwareentwicklung? Typische Projektkonstellationen anspruchsvoller, komplexer Projekte beinhalten in der Regel immanent das Konstrukt einer Auftraggeber-Auftragnehmer-Konstellation. Wie verhält es sich diesbezüglich mit dem Wunsch nach Festpreisen und Gewerken, welche eine genaue A-priori-Spezifikation des Leistungsgegenstands verlangen? Der Beitrag zeigt auf, wie ein hybrider Projektansatz in Synthese von klassischem, Wasserfall-dominiertem Projektumfeld und agilen Vorgehen dazu beitragen kann, den Nutzen für alle Projektparteien zu erhöhen. Dazu wird eine Taxonomie für den adäquaten Methodeneinsatz entworfen und ein Anwendungsszenario vorgestellt. +++ Für eilige Leser +++ Für eilige Leser +++ Für eilige Leser +++ 1 Ein Enterprise Resource Planning-System ist eine komplexe, integrative Anwendungssoftware zur Unterstützung der Ressourcenplanung eines gesamten Unternehmens [2]. Proze Proje PM_1-2014_1-72: Inhalt 30.01.2014 13: 21 Uhr Seite 38 ❑ Vernachlässigung des sich ändernden Projektumfelds: Auf Veränderungen der externen und internen Projektparameter (z. B. Gesetzgebung, neue Anforderungen …) sowie Erkenntnisse bezüglich getroffener Annahmen kann nicht oder nur erschwert reagiert werden. Untersuchungen ergeben regelmäßig, dass zum Beispiel bei mehr als der Hälfte aller ERP-Implementierungen geplante Zeitund/ oder Kostenziele nicht erreicht werden [10], konkret 68 Prozent aller IT-Projekte den Zieltermin signifikant überschreiten und 16 Prozent der IT-Projekte mehr als doppelt so viel kosteten wie anfangs geplant [11]. Kunden von Beratungshäusern reagieren darauf mit verstärkter Forderung von vermeintlichen „Sicherheiten“, wie zum Beispiel 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 zum Teil in die richtige Richtung geht, die wesentlichen Kritikpunkte jedoch nicht umfassend adressiert: Prototyping, Baseline-Ansätze, Best Practices, … 3 Chance der Agilität Ziel der agilen Softwareentwicklung ist es, den Prozess der Softwareentwicklung im Vergleich zu klassischen Vorgehensmodellen wie dem V-Modell ® XT flexibler und schlanker zu machen, da diese oft als schwergewichtig und bürokratisch angesehen werden. Im Fokus sollen die zu erreichenden Ziele und die technischen und sozialen Probleme stehen. Scrum geht als eine agile Methode davon aus, dass Entwicklungsprozesse zu komplex sind, um in große abgeschlossene Phasen und einzelne Arbeitsschritte eingeteilt zu werden. Effizienter ist es, wenn sich ein Team in einem festen äußeren Rahmen selbst organisiert. Traditionelle Werkzeuge der Projektsteuerung durch das Management werden dabei abgelehnt. Stattdessen treten verhältnismäßig kurze Projektzyklen in den Vordergrund, in denen nicht zuletzt der Scope des Projekts und die Priorisierungen regelmäßig kritisch hinterfragt und neu ausgerichtet werden. Scrum steht bezüglich seines operativen Einsatzes noch am Anfang, gewinnt aber an Bedeutung. In einer Umfrage auf CIO.de erklärten von 190 Teilnehmern 25 Prozent Scrum bereits einzusetzen, 7 Prozent binnen Jahresfrist nachziehen zu wollen, 24 Prozent nicht mit Scrum zu arbeiten und 44 Prozent den Begriff nicht zu kennen [4]. Scrum wird also bereits von einem Drittel des Marktes eingesetzt bei steigender Tendenz. Die Vertragsgestaltung in einem klassischen Projektauftrag, welcher ein Gewerk zu einem Festpreis erstellt, führt zu einer Pareto-ineffizienten Situation: Die vollumfängliche Realisierung des ursprünglich vereinbarten Scopes kostet (im Idealfall) 100 Prozent des Budgets, wobei der Geschäftsnutzen des Projektergebnisses auf einer Einschätzung zum Zeitpunkt der Beauftragung fußt und zudem alle Elemente innerhalb des Scopes prinzipiell gleich behandelt. Zum anderen müht sich der Leistungsbeschreibung/ Lastenheft Angebot/ Pflichtenheft Scope/ Festpreis/ Vertrag Gewerk/ Abnahme Abb. 1: Formelle Sequenz in der Auftraggeber-Auftragnehmer-Konstellation Prozessorientiertes Projektmanagement - Anzeige PM_1-2014_1-72: Inhalt 30.01.2014 13: 21 Uhr Seite 39 Auftragnehmer ab, die letzten 10 bis 20 Prozent der Details ebenfalls zu erzielen, um die notwendige Abnahme zu erreichen. Dieses Prinzip ist nach eigener Erfahrung (z. B. [5]) im Bereich des öffentlichen Sektors mit seinen formellen Ausschreibungsverfahren besonders ausgeprägt. Bei mehr Flexibilität (also Agilität) zur Projektlaufzeit könnten beide Parteien eine bessere Lösung erzielen: mehr Nutzen beim Auftraggeber mit weniger Aufwand beim Auftragnehmer. Allerdings ist hierfür ein Umdenken bei der Vertragsgestaltung notwendig. 4 Das Beste aus beiden Welten vereinen! „One of the industry statistics is that 65 percent of all functionality that is delivered and then has to be maintained and sustained is rarely or never used.“ Dieses Zitat von Ken Schwaber [6], dem Mitbegründer der Scrum-Methode, können sicherlich viele aus eigener Erfahrung auch mehr oder weniger für den oben genannten Zusatzentwicklungsbereich im Rahmen von ERP- Systemeinführungen bestätigen. In einem hybriden Projektansatz werden die Prinzipien des klassischen Wasserfallmodells mit der Scrum-Methode kombiniert, um so einen größtmöglichen Nutzen und Sicherheit für die Projektbeteiligten zu erreichen. Dazu gilt es, die Erfolgsfaktoren beider Ansätze gezielt einzusetzen. So hat der Wasserfallansatz sicherlich seine Stärken, wenn die Anforderungen klar sind, die Technik bekannt, zum Beispiel eine ERP-Software, die Teammitglieder klare Richtlinien benötigen, vertragliche Sicherheit wichtig ist, zum Beispiel wenn noch kein Vertrauen zwischen Auftraggeber und Auftragnehmer besteht, Dokumentation und Nachvollziehbarkeit unverzichtbar sind, z. B. im GxP-Umfeld etc. 2 Die agile Scrum-Methode macht demgegenüber Sinn, wenn die Anforderungen unklar sind, die einzusetzende Technologie neu und unbekannt ist, Druck auf Timeto-Market-Lieferung besteht, Fortschrittstransparenz gefordert ist und ein vertrauensvolles Auftraggeber-/ Auftragsnehmerverhältnis besteht. Abbildung 2 zeigt in einem systematisierten Aufbau eine eigene Taxonomie zur Methodenentscheidung hinsichtlich klassischen, Wasserfall-bezogenen versus agilen Vorgehens. Die „Schieber“ dienen dabei der Einstufung im konkreten Fall und damit letztlich zur Wahl der Mittel. Die Idee eines hybriden Projektansatzes nutzt die oben genannten Charakteristiken im Falle von ERP-Systemeinführungsprojekten und kombiniert beide Modelle: das Wasserfallmodell als „Baseline“-Ansatz insbesondere für den Standardanteil der ERP-Systemeinführung, der via Customizing realisiert wird, sowie das Scrum-Vorgehen für über den ERP-Standard hinausgehende Zusatzentwicklungsanteile, etwa im Bereich des Reportings. Abbildung 3 zeigt das hybride Vorgehensmodell in einer schematischen Übersicht. Da für ein Scrum-Vorgehen „nur“ ein Product Backlog - das heißt die Menge der relevanten Produktanfor- 22 l projekt MA N A G E M E N T aktuell 1/ 2014 40 WISSEN Abb. 2: Taxonomie zur Methodenentscheidung 2 „GxP“ bezeichnet zusammenfassend alle Richtlinien für „gute Arbeitspraxis“, welche insbesondere in der Medizin, der Pharmazie und der pharmazeutischen Chemie Bedeutung haben [2]. PM_1-2014_1-72: Inhalt 30.01.2014 13: 21 Uhr Seite 40 derungen - die Startvoraussetzung ist und ein Sprint den Ablauf „Plan - Design - Build“ immanent enthält, kann grundsätzlich mit diesem Teil des Projekts auch früher begonnen werden, gegebenenfalls bereits direkt nach Projektstart. Allerdings ist zu berücksichtigen, dass der oben genannte Anwendungsfall einer ERP-Systemeinführung diese Parallelität wohl kaum zulassen dürfte, da im Rahmen des sogenannten Business Blueprints zunächst integrative Aspekte geklärt werden, das Delta zwischen Standard und Zusatzentwicklung identifiziert und auch strukturelle Voraussetzungen durch das Grund-Customizing des Systems gewährleistet sein müssen. Eine differenzierte Betrachtung ist da erforderlich (Migrations-, Schnittstellen-, Zusatzfunktionalitäten-, Berichtentwicklung etc.). In Detaillierung der vereinfachten Darstellung in Abbildung 3 werden im Allgemeinen die Ergebnisse des Scrum-Anteils bereits in die „Prepare“-Phase, insbesondere den Integrationstest, einfließen. Scrum kann in dem oben genannten Anwendungsfall einen Design to Budget-Ansatz mit maximalem Kundennutzen realisieren: Durch die wiederholte Neuausrichtung des Backlogs werden unnütze Elemente vermieden und so ein Pareto-Optimum für Auftraggeber und Auftragnehmer erreicht. Die Vertragsgestaltung muss dieses berücksichtigen, indem ❑ zugelassen wird, dass der Backlog gegebenenfalls erst zu einem späteren Zeitpunkt (Business Blueprint) definiert und auch dynamisch angepasst wird und der agile Anteil des Scopes nicht als Gewerk a priori vereinbart werden kann, ❑ für die potenziell agilen Anteile ein Budget sowie benötigte Fähigkeiten und Kapazitäten identifiziert werden, dies formell in einem Dienstleistungsvertrag vereinbart und damit das Prinzip „Design to Budget“ umgesetzt wird, ❑ das Change Request-Verfahren der dynamischen, zyklischen Sprint Backlog-Priorisierung weicht. 5 Die Rollen im Wandel des Projektansatzes Scrum- und Wasserfallmodelle kennen voneinander abweichende Rollen im Bereich des Projektmanagements. Im hybriden Projektansatz ist daher ein Zusammenwirken bzw. ein Übergang zu definieren. Das Wasserfallmodell kennt unter anderem den (Gesamt-)Projektleiter und Teilprojektleiter. Letztere fungieren im Falle der Zusatzentwicklung einer ERP-Systemeinführung als Entwicklungskoordinator. Sie berichten an den Projektleiter. Die Scrum-Methode kennt insbesondere den Product Owner sowie den Scrum Master - beide ohne Projektleitungsaufgabe im engeren Sinne. Abbildung 3 zeigt, dass sich das Projekt nach der Designphase gleichsam aufsplittet, an dieser Stelle ist also der Rollenwechsel notwendig. In der nachfolgenden Abbildung 4 werden mögliche Rollenübergänge im hybriden Ansatz aufgezeigt. Dabei orientieren sich die Möglichkeiten an der Verteilung der Projektmanagementaufgaben im Scrum-Modell [1] bzw. klassischen Modell PMI ® , IPMA ® oder V-Modell XT ® . Die in Tabelle 1 aufgeführten Rollenwechsel erscheinen sinnvoll (Scrum-Rolle - klassische Rolle - Begründung). Abbildung 4 fasst die möglichen Rollenübergänge grafisch zusammen. Die weitere Ausgestaltung muss unter den konkreten Randbedingungen und Voraussetzungen des Projekts bzw. der Projektmitarbeiter ermittelt werden. projekt MA N A G E M E N T aktuell 1/ 2014 l 41 Abb. 3: Hybrides Projektvorgehensmodell Product Owner ➜ (Gesamt-)Projektleiter ❑ Verantwortung für das Erreichen der Projektziele ❑ definiert und priorisiert Product Backlog ❑ betreibt Stakeholdermanagement ➜ Integrationsmanager/ Lösungsarchitekt ❑ fungiert als Chief Engineer ❑ hat fundiertes technisches Verständnis ❑ trifft übergreifende Architekturentscheidungen ➜ Process Owner/ Produktmanager/ Bedarfsträger ❑ entscheidet über Leistungsmerkmale des Produktes ❑ verantwortet Produkt ggf. über Release-Zyklen ❑ repräsentiert/ versteht Endkundenbedürfnisse Scrum Master ➜ Teilprojektleiter/ Entwicklungskoordinator ❑ agiert als Coach ❑ stellt Ablauf sicher ❑ räumt Hindernisse aus dem Weg ❑ schützt das Team gegenüber Einwirkung von außen ❑ unterstützt bei der Verbesserung der Praktiken ➜ Qualitätsmanager ❑ agiert als Methodencoach ❑ stellt sicher, dass das Vorgehen eingehalten wird ❑ hat keine Weisungsbefugnis oder direkte Ergebnisverantwortung ❑ kann moderierend einwirken ➜ Project Officer (PMO) ❑ wie PMO Tab. 1: Adaption des Rollenverständnisses PM_1-2014_1-72: Inhalt 30.01.2014 13: 21 Uhr Seite 41 6 Fazit Der hybride Projektansatz kann im klassischen, Wasserfall-dominierten Projektumfeld dazu beitragen, den Nutzen für alle Projektparteien zu erhöhen. Allerdings sind die Anwendungsbereiche des agilen Anteils zielgerichtet auszuwählen und weitere Voraussetzungen zu schaffen. Dazu gehören beispielsweise eine fokussierte Mitarbeiterdisposition, eine adäquate Vertragsgestaltung zwischen den Projektparteien (Scrum kennt keine Change Requests! ) inklusive einer entsprechenden Unternehmenskultur. Zu untersuchen bleibt dabei, wie Projekte, die nach agilem Ansatz durchgeführt werden, bei dem immanent zum Zeitpunkt der Beauftragung des Projekts das Ergebnis nicht umfassend spezifiziert werden kann, sich im Rahmen eines systematischen (IT-)Projektportfoliomanagements des Unternehmens greifbar machen und integrieren lassen. Durch die agilen Elemente im hybriden Projektansatz wird eine Pareto-optimale Situation in der Auftragnehmer-Auftraggeber-Konstellation („Win-win“) erreicht, da beide Parteien durch das laufende Re-Adjustieren des Scopes, insbesondere in aufwendigen und teilweise im Nutzen umstrittenen Bereichen (ERP-Standard vs. Zusatzentwicklung), ihren Ressourceneinsatz (Geld bzw. Kapazitäten) optimieren. Dabei wird das Verhältnis des Gesamtaufwands zum Gesamtnutzen verbessert, ohne dass es auf Kosten einer der beteiligten Parteien ginge. In die Praxis etwa von Beratungs-, SAP-Einführungsprojekten etc. hat dies nach eigenen Erkenntnissen leider noch keinen Einzug gefunden. Hier bietet sich ein mit dem hybriden Projektansatz gleichsam postulierter Paradigmenwechsel aus der geschilderten Motivation heraus daher an. ■ Literatur [1] Pichler, R.: Scrum - Agiles Projektmanagement erfolgreich umsetzen. 1. Auflage, dpunkt.verlag, Heidelberg 2008 [2] http: / / de.Wikipedia.org. Stand: 27.12.2011 [3] Hildebrandt, D.: Die agile Projektmanagementmethodik im Spannungsfeld des PMI-Standards am Beispiel von SCRUM. Vortrag PMI Chapter Cologne vom 25.11.2011 [4] www.cio.de. Stand: 27.12.2011 [5] Bürmann, R./ Hüsselmann, C.: Ressortweiter Wirkbetrieb von ERP-Software in der Bundesverwaltung. Behörden Spiegel Nr. XI, 23. Jahrgang, 11/ 2007 [6] Schwaber, Ken, live in: Google Tech Talks. 5. September 2006, Stand: 28.12.2011 [7] V-Modell ® XT. Version 1.3, 2008 [8] ICB - IPMA Competence Baseline. Version 3.0, GPM, 2008 [9] PMBOK ® Guide: A guide to the project management body of knowledge. 4. Edition, PMI, 2008 [10] 2010 ERP Report. Panorama Consulting Group, 2010, Stand: 28.12.2011 [11] Saïd Business School working papers. University of Oxford, August 2011, Stand: 24.5.2012 Stichwörter Agilität, hybrides Vorgehen, Scrum, Vorgehensmodell, Wasserfallmodell, Win-win-Vertragsgestaltung Kompetenzelemente der NCB 3.0 4.1.3 Projektanforderungen und Ziele, 4.1.10 Leistungsumfang und Lieferobjekte (Deliverables), 4.1.11 Projektphasen, Ablauf und Termine, 4.1.14 Beschaffung und Verträge Autor Dipl.-Math. techn. Dr. rer. oec. Claus Hüsselmann ist als Partner bei der 2010 gegründeten Scheer Management GmbH (Saarbrücken/ München) zuständig für das Beratungsfeld Projekt-, Programm- und Portfoliomanagement. Nach dem Studium der Technomathematik wirkte er zunächst als leitender Entwickler in einem SAP-Systemhaus für kommunale Anwendungen. Nach seinem Wechsel zur IDS Scheer AG - jetzt Software AG - verantwortete er mehrere Beratungseinheiten, (Groß-)Projekte sowie zuletzt den Project Operations & Risk Control-Bereich für das gesamte Consulting-Geschäft. Seine Promotion absolvierte er berufsbegleitend am Institut für Wirtschaftsinformatik der Universität des Saarlandes zum Thema Geschäftsprozessmanagement und Fuzzy-Logic. Claus Hüsselmann ist zertifizierter Project Management Professional und Scrum Master. 2010 konnte er den Award „Deutsche Meisterschaft im Projektmanagement“ gewinnen (Computerwoche). Seit 2012 ist er Mitglied im Vorstand der GPM. Anschrift Scheer Management GmbH Associate Partner Project Performance Management Consulting Uni-Campus Nord D-66123 Saarbrücken Tel.: 01 72/ 4 58 02 36 Fax: 06 81/ 93 51 11 00 E-Mail: Claus.Huesselmann@scheer-management.com www.scheer-management.com 22 l projekt MA N A G E M E N T aktuell 1/ 2014 42 WISSEN Abb. 4: Rollenübergang im hybriden Projektansatz Andreas PM_1-2014_1-72: Inhalt 30.01.2014 13: 21 Uhr Seite 42