Problemstellung Bei einer Auswertung am Anfang des Jahres 2007 wurde festgestellt, dass die Anzahl der gestellten Demands, das heißt der neuen Anforderungen an die IT-Systeme, über die Zeit kontinuierlich angestiegen war. Die Anzahl der im Januar 2007 bereits erfassten Demands ließ (fortgeschrieben auf das ganze Jahr 2007) auf eine weitere, extreme Erhöhung schließen. Gleichzeitig war das zur Verfügung gestellte Budget für 2007 gekürzt worden, das heißt, es war abzusehen, dass ohne eine Änderung der Vorgehensweise nur ein sehr kleiner Anteil der Anforderungen tatsächlich würde umgesetzt werden können. Um die knapper gewordenen Ressourcen und die gestiegenen Anforderungen in Einklang zu bringen und dabei ein möglichst effizientes Ergebnis zu erzielen, musste ein Verfahren gefunden werden, mit dem sich der Umfang von einzelnen Demands reduzieren ließ. Gleichzeitig sollte dieses Verfahren leicht anwendbar sein und die Projektteams nicht unnötig belasten. Im Rahmen eines Pilotprojekts wurde bei einer Landesgesellschaft die Anwendung der Pareto-Regel auf den Inhalt und Umfang von IT-Projekten erprobt. Die Ergebnisse waren so vielversprechend, dass von der IT- Abteilung und den Fachabteilungen gemeinsam eine Ausweitung des Ansatzes auch auf die eigenen Projekte beschlossen wurde. Die Pareto-Regel Die Pareto-Regel (auch bekannt als 80/ 20-Regel) ist nach dem italienischen Ökonomen und Soziologen Vilfredo Pareto (1848-1923) benannt, der in einer seiner Untersuchungen herausfand, dass 80 Prozent des italienischen Volksvermögens bei 20 Prozent der Familien konzentriert sind. Der Ingenieur Joseph M. Juran (1904-2008) wandte dieses Prinzip auf Fragen des Qualitätsmanagements an und prägte den Ausdruck „vital few, useful many“. Gemeint sind Sachverhalte wie z. B. ❑ 20 Prozent der Kunden bringen 80 Prozent des Umsatzes eines Unternehmens, ❑ 80 Prozent der Fehler einer Software sind auf dieselben 20 Prozent der Ursachen zurückzuführen, ❑ in 20 Prozent meiner Arbeitszeit erreiche ich 80 Prozent meiner Ergebnisse usw. Dabei sind die Zahlen 80 und 20 keineswegs als starre Werte aufzufassen, vielmehr ist gemeint, dass häufig ein kleiner Anteil an den Ursachen bereits den größten Teil der Wirkungen hervorbringt. Es ist bei Ressourcenknappheit daher sinnvoll, diesen kleinen Anteil zu identifizieren und sich darauf zu konzentrieren, um möglichst effizient zu arbeiten. Diese Regel galt es zu formalisieren und in das firmeneigene Vorgehensmodell zu integrieren. projekt MA N A G E M E N T aktuell 1/ 2009 l 27 Tim Krüger Scope Management mithilfe der Pareto-Regel Knappe Ressourcen und praktisch unbegrenzte Anforderungswünsche - für jeden Projektmanager ein bekanntes Phänomen. Nicht immer gelingt es, gemeinsam mit dem Auftraggeber beides in Übereinstimmung zu bringen. Ein international tätiger Mobilfunkanbieter hat für seine internen IT-Projekte unter dem Schlagwort „Rightsizing“ ein Verfahren auf Basis der sogenannten Pareto-Regel entwickelt, mit dem Projektmanager und Auftraggeber den Projektinhalt und -umfang an die Ressourcensituation anpassen können. Ein großer Mobilfunkanbieter stand 2007 vor dem Problem, dass die Fachabteilungen immer mehr Anforderungen an die Neu- und Weiterentwicklung der internen IT-Systeme stellten. Arbeitskapazität und Budget der IT-Abteilung reichten aber nicht aus, um diese umzusetzen. Es wurde deshalb ein Verfahren entwickelt, mit dem sich Projektinhalt und -umfang reduzieren und an die Ressourcensituation anpassen lassen. Dabei werden die besonders nützlichen Funktionsanforderungen herausgefiltert und umgesetzt, Anforderungen mit einem niedrigeren Nutzen fallen weg. Das Verfahren basiert auf dem Pareto- Prinzip und wird im Unternehmen deshalb als Pareto-Analyse bezeichnet. Tim Krüger stellt Ablauf und Nutzen der Pareto-Analyse vor. +++ Für eilige Leser +++ Für eilige Leser +++ Für eilige Leser +++ 2005 2006 2007 (Prognose) Demands gestellt realisie rt Abb. 1: Geschätzte Entwicklung von gestellten und tatsächlich realisierten Demands PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 27 Das Vorgehensmodell Softwareentwicklungsprojekte laufen nach einem eigenen Vorgehensmodell ab. Ausgangspunkt ist immer eine Anforderung (Demand), beispielsweise aus einer Fachabteilung wie dem Marketing oder der Kundenbetreuung. Eine solche Anforderung entsteht, wenn neue Geschäftsprozesse eingeführt bzw. bestehende, durch IT- Systeme bereits unterstützte Geschäftsprozesse erweitert, verändert und/ oder optimiert werden sollen. Eine Anforderung kann auch technikgetrieben sein, zum Beispiel um die IT-Architektur zu vereinheitlichen oder eine bessere Unterstützung der Geschäftsprozesse zu erreichen. Alle Anforderungen werden in einer eigenentwickelten Software erfasst und vom Gremium, das für die Release- Planung zuständig ist, priorisiert. Da im betrachteten Unternehmen eine sehr große Anzahl an IT-Systemen im Einsatz ist, erstreckt sich eine technische Lösung für eine Anforderung in der Regel über mehrere Systeme, sodass ein hoher Koordinations- und Steuerungsbedarf für das Entwicklungsprojekt entsteht. In diesem Fall wird ein eigener Projektmanager zugewiesen, während Lösungen innerhalb eines einzigen Systems unter der Leitung des Systemverantwortlichen erarbeitet werden. Gibt es mehrere, konkurrierende Ansätze für eine Lösung oder ist unklar, ob eine Anforderung überhaupt lösbar ist, wird zunächst eine Vorstudie (Feasibility Study) angefertigt. Sie hat zum Ziel, mögliche Lösungen zu identifizieren, zu bewerten und eine Entscheidungsgrundlage für die weitere Verfolgung des Projekts zu geben. Fällt die Entscheidung zur Realisierung der in der Feasibility Study empfohlenen Lösung positiv aus, wird sie in der nächsten Phase geplant. Hierzu wird zunächst ein Fachkonzept (Detailed Solution Design) erstellt. Es stellt die fachlichen Anforderungen vollständig und konsistent dar, benennt alle betroffenen Systeme und zählt Abhängigkeiten zu anderen Projekten auf. Wird das Detailed Solution Design vom Auftraggeber sowie von den Betreuern der betroffenen Systeme genehmigt, wird für jedes beteiligte System eine genaue technische Spezifikation der Lösung angefertigt (System Design). Auch diese Dokumente müssen vom Auftraggeber freigegeben werden. Ist das Lösungsdesign abgeschlossen, liegt auch eine genaue Aufwandsschätzung für die Lösung vor, auf deren Grundlage das für die Release-Planung zuständige Gremium über die Umsetzung entscheidet. Die weiteren Phasen des Vorgehensmodells bestehen aus der Realisierung (Realisation), den System- und Verbundtests (Test & Acceptance) und schließlich der Inbetriebnahme (Deployment). An welcher Stelle des Vorgehensmodells kommt nun die Pareto-Regel zum Einsatz? Wird eine Feasibility Study erstellt, so sieht das Vorgehensmodell eine Pareto- Analyse am Ende ihrer Erstellung vor, denn zu diesem Zeitpunkt steht bereits fest, welcher der möglichen Lösungsansätze empfohlen werden kann. Wird dagegen keine Feasibility Study, sondern gleich ein Detailed Solution Design entworfen, so ist eine Pareto-Analyse des Anforderungsumfangs gleich zu Anfang des Designs obligatorisch. Um kleinere Projekte nicht unnötig mit Verwaltungsaufwand zu belasten, wurde aber beschlossen, dass die Pareto-Analyse nur bei Projekten mit einem Gesamtaufwand von über 100 Personentagen verpflichtend durchgeführt werden muss. Die Analyse selbst wurde ebenfalls als formaler Prozess definiert. Der Bewertungsprozess Im ersten Schritt der Pareto-Analyse wird der Gesamtumfang des Projekts in einzelne Teilanforderungen (Sub- Demands) aufgeteilt. Als Richtlinie für die Unterteilung gilt, dass die Teilanforderungen getrennt bewertbar, getrennt implementierbar und getrennt einführbar sein müssen - anderenfalls wäre ein späterer Ausschluss von Teilanforderungen kaum durchführbar. Die Aufteilung nimmt der Projektmanager in Abstimmung mit dem Auftraggeber vor. Diese Unterteilung ist mit einem Projektstrukturplan vergleichbar: Sie sollte an den Liefergegenständen des Projekts ausgerichtet sein und den Projektumfang zu 100 Prozent abdecken. Allerdings findet an dieser Stelle keine Hierarchisierung statt. Im zweiten Schritt erfolgt die eigentliche Bewertung. Hierbei bewertet der Projektmanager die Kosten, der Auftraggeber dagegen den Nutzen jedes einzelnen Sub- Demands. Unter Nutzen wird dabei ein betriebswirtschaftlicher Nutzen wie z. B. Kosteneinsparung, Risikoverringerung usw. verstanden und nicht etwa die persönliche Präferenz des Auftraggebers. Die Bewertung erfolgt in einer Prozentskala, wobei die Summe aller Kostenbzw. Nutzenbewertungen stets 100 Prozent ergeben muss. Ein Beispiel ist in Abb. 2 zu sehen. Entscheidend ist, dass Projektmanager und Auftraggeber getrennt und unabhängig voneinander ihre Bewertungen vornehmen, damit eine größtmögliche Objektivität des Verfahrens gewährleistet ist. Im dritten Schritt werden die Sub-Demands anhand des ermittelten Kosten-Nutzen-Verhältnisses verglichen. 22 l projekt MA N A G E M E N T aktuell 1/ 2009 28 WISSEN # Requirement / Component Costs Benefit 1E … 4 % Mandatory 1I … 2 % 8 % 1J … 7 % 4 % 2A 2B … 25 % Mandatory 2C … 0 % 1 % 3A … 4 % 15 % 3B … 35 % 1 % 4A … 1 % 20 % 5A … 9 % 8 % 5B … 4 % 1 % 6A 6B … 4 % 10 % 6C 6D … 1 % 12 % 6E … 2 % 10 % 6F 6G … 2 % 10 % Abb. 2: Beispiel für eine Pareto-Bewertung PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 28 Hier kommt das Pareto-Prinzip zum Tragen: Es gilt, diejenigen Sub-Demands zu identifizieren, die nur wenig Nutzen, aber den Großteil der Kosten ausmachen, und diese aus dem Projektumfang zu entfernen. Dabei sind (wie schon erwähnt) die Werte „20 Prozent“ und „80 Prozent“ als ungefähre Richtwerte zu verstehen. Projektmanager und Auftraggeber legen gemeinsam den Inhalt und Umfang des Projekts fest, indem sie die Sub-Demands als „In scope“ oder „Out of scope“ klassifizieren. Das Ergebnis wird als formlose Liste festgehalten. In der Pareto-Analyse aus Abb. 2 beispielsweise wurden die Sub-Demands 3B und 5B aussortiert, das heißt, hier wurde eine „39/ 2-Regel“ verwendet. Der Projektmanager versteht sich an dieser Stelle als strategischer Berater des Auftraggebers. Wurde die Pareto-Analyse am Ende einer Feasibility Study durchgeführt, so gilt für das nachfolgende Detailed Solution Design der festgelegte Projektumfang als verbindlich. Wurde das Projekt gleich mit einem Detailed Solution Design gestartet, so wird nach durchgeführter Pareto-Analyse nur noch der entsprechend reduzierte Projektumfang geplant. In beiden Fällen wird die gesamte Pareto-Analyse als separates Dokument abgelegt und im Ausgangsdokument (Feasibility Study oder Detailed Solution Design) ein entsprechender Verweis eingefügt. Ergebnisse und Lessons Learned Durch Einführung der Pareto-Analyse wurde der Umfang von Projekten nachweisbar um durchschnittlich 30 Prozent reduziert. Sub-Demands, die im Zuge der Analyse aus dem Projektumfang entfernt worden waren, wurden allerdings teilweise von den Auftraggebern als Anforderungen für spätere Releases erneut eingestellt. Diese Praxis wurde unterbunden, ein abgelehnter Sub-Demand wird nur noch dann erneut zugelassen, wenn ein eigener Business Case für seine Realisierung dargelegt werden kann. Es zeigte sich, dass eine besondere Herausforderung in der Unterteilung in Sub-Demands liegt. Ist die Unterteilung zu grob, können viele kleine kostentreibende und dabei entbehrliche Features nicht identifiziert und eliminiert werden. Ist sie zu fein, wird es zunehmend schwierig, eine Einigung zwischen Projektmanager und Auftraggeber zu erzielen. Außerdem steigt in diesem Fall der Aufwand für die Einteilung in Sub-Demands stark an. Um die „Diskussionsbereitschaft“ der Auftraggeber bei der Pareto-Analyse zu erhöhen, wurde eine zusätzliche Maximalschwelle festgelegt: Projekte, deren Umfang die verfügbaren Entwicklerkapazitäten eines betroffenen Systems übermäßig belegen würde, haben eine deutlich geringere Chance auf Realisierung. Um einen Ausschluss der Anforderungen zu verhindern und wenigstens einen Teil davon realisieren zu können, waren die Auftraggeber eher bereit, einer Reduktion des Umfangs durch eine Pareto-Analyse zuzustimmen. Um den Mitarbeitern die Aufmerksamkeit des Managements zu verdeutlichen, wurde ein regelmäßiger Präsentationstermin eingerichtet, bei dem Projektmanager ihre Projekte mitsamt der durchgeführten Pareto-Analyse auf Bereichsleiterebene vorstellen. Um den Aufwand eines Projekts noch besser abbilden zu können, soll Schritt für Schritt auf eine Bewertung der Total Cost of Ownership (TCO) umgestellt werden. Dies macht die Bewertung für den Projektmanager allerdings schwieriger und aufwendiger, da zum Beispiel für die Ermittlung von Hardware- oder Betriebskosten weitere Spezialisten befragt werden müssen. Das Gesamturteil zur Pareto-Analyse fällt positiv aus: Mit einigen Veränderungen im Detail leistet sie einen wertvollen Beitrag zur effizienten Projektarbeit und hat sich im Arbeitsalltag bewährt. ■ Schlagwörter Kosten-Nutzen-Analyse, Pareto-Prinzip, Projektanforderungen, Projektumfang, Requirements, Scope Management Kompetenzelemente der NCB 3.0 4.1.2 Interessierte Parteien, 4.1.3 Projektanforderungen und Projektziele Autor Dipl.-Kfm. Tim Krüger ist Senior Consultant bei der 7P Consulting GmbH und Spezialist für IT-Projektmanagement. Nach mehreren Jahren als Softwareentwickler und Projektleiter im E-Business-Bereich ist er aktuell als IT-Berater und Projektmanager bei Großunternehmen in der Mobilfunkbranche im Einsatz. Tim Krüger ist zertifizierter Project Management Professional (PMP®). Anschrift 7P Consulting GmbH, Landsberger Straße 302, D-80687 München, E-Mail: tim.krueger@7p-group.com projekt MA N A G E M E N T aktuell 1/ 2009 l 29 in-Step ® Risikomanagement Qualitätsmanagement Projektmanagement Die Infrastruktur für alle Projekte - in LAN & Internet Die Lösung für Scrum V-Modell ® XT PRINCE2 ™ Automotive SPICE ™ konformes Vorgehen Eigene Prozesse making IT better Konfigurationsmanagement www.in-Step.de microTOOL GmbH Voltastraße 5 13355 Berlin Germany Tel.: +49 30 / 467 08 6-0 Fax: +49 30 / 464 47 14 E-Mail: info@microTOOL.de für prozessbasiertes Projektmanagement für mehr Qualität: Entwicklungsprojekte einheitlich planen und sicher durchführen Multiprojektmanagement & Anforderungsmanagement Änderungsmanagement & m i c r o T O O L auf der OOP in München 27. - 29.01.2009 Anzeige PM_1-09_1-64: Inhalt 19.12.2008 13: 36 Uhr Seite 29