28฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 29฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 1฀ Definition฀und฀Ziele฀von฀Projektbenchmarking Unter Benchmarking versteht man nach dem American Productivity & Quality Center [1] „den Prozess fortlaufenden Vergleichens und Messens der eigenen Organisation mit weltweit führenden anderen Organisationen. Ziel ist es dabei, der eigenen Organisation bei der Verbesserung der Leistungsfähigkeit zu helfen.” Häufig wird freilich in der Praxis nicht mit konkreten Unternehmen verglichen, sondern mit so genannten „besten Praktiken“. Dabei ist nur selten zu ersehen, wie und von wem diese identifiziert wurden. Benchmarking bezog sich, wie sich auch aus der obigen Definition ergibt, zunächst auf Institutionen als Ganzes. Im Gegensatz dazu wird bei der Anwendung von Projektbenchmarking zumindest in einer Ausprägungsform nur ein einzelnes Projekt betrachtet. Dabei wird bewusst in Kauf genommen, dass keine Aussage darüber getroffen werden kann, wie die durchführende Organisation ihre Projekte insgesamt abwickelt. In einer zweiten Ausprägungsform wird geprüft, welches System, verstanden als Summe von Werkzeugen, Regelungen und Prozeduren, eine Organisation implementiert hat, um Leistungserstellung mit Projektcharakter zu planen und zu realisieren. Repetitive Formen der Leistungserstellung, wie Groß- und Kleinserienfertigung, bleiben unberücksichtigt. Ziel des Projektbenchmarking im Speziellen ist es nach Ottmann [2, S. 4 f.], die Projektdurchführung durch  „die systematische Identifikation und Analyse von Schlüsselprozessen im Projekt,  den Vergleich mit den besten Vorgehensweisen, sog. Best Practices,  den Ideentransfer von Best Practices in die eigenen Projektprozesse und  die direkte Einbindung von Mitarbeitern in die Konzeption und Umsetzung der Maßnahmen zu optimieren.“ Unter Prozessen versteht man dabei „eine Folge von Schritten, die zur Erreichung eines gegebenen Zwecks ausgeführt wird.“ [3] 2฀ Arten฀von฀Benchmarking-Modellen 2.1฀ Branchenneutrale฀Modelle Ein sehr frühes, bemerkenswertes Modell, das u. a. für die Bewertung einzelner Projekte verwendet werden kann, stammt von v. Wasielewski [4, 5]. Der Ansatz, der unter dem Titel „Projektvergleichstechnik” vorgestellt wurde und der aus einem Kennzahlensystem besteht, konnte sich bisher allerdings nicht auf breiter Front durchsetzen, vermutlich wegen der sehr hohen Ansprüche, die an die verfügbaren Daten gestellt wurden. Ein branchenneutraler Rahmen für ein Kennzahlensystem wurde in neuerer Zeit von George [6] vorgestellt. Zu der bislang noch relativ geringen Zahl von Modellen für das Benchmarking einzelner Projekte gehört auch das Modell „Project Excellence” der GPM Deutsche Gesellschaft für Projektmanagement e. V. [7, 2, 8, 9, 10]. Wie bei anderen neuen Modellen auch, wird dabei freilich weit über die Ermittlung und den Vergleich von Kennzahlen hinausgegangen. Zu den Modellen, mit denen das gesamte Projektmanagementsystem einer Organisation einer Analyse unterzogen wird, zählt z. B. das Assessmentverfahren PM Delta der GPM [11], das als Grundlage die DIN 69904 mit ihren Orientierungsfragen benutzt. Wie die Urheber dieses Benchmarking-Ansatzes betonen, kann es allerdings auch dazu verwendet werden, einzelne Projekte zu bewerten. In jedem Fall muss untersucht werden, ob die getroffenen Regelungen tatsächlich in die Praxis umgesetzt werden. Erfahrungen haben gezeigt, dass nahezu immer zwischen den Sollvorstellungen, wie sie in Handbüchern festgehalten sind, und der täglichen Praxis des Projektmanagements erhebliche Diskrepanzen bestehen, die „Papierform“ allein also nur wenig aussagt. Obwohl sich mit PM-Delta, wie schon erwähnt, auch einzelne Projekte bewerten lassen, besteht doch ein ganz erheblicher Unterschied zu Project Excellence. PM-Delta fragt nicht nach dem Projekterfolg. Weitere branchenneutrale Modelle dieser Kategorie sind das noch in Entwicklung befindliche OPM3 des Project Management Institute of America (PMI), der größten Projektmanagement-Vereinigung der Welt [12], das Das฀aktuelle฀Stichwort: ฀ Projektbenchmarking Heinz฀Schelle Mit฀diesem฀ersten฀„aktuellen฀Stichwort“฀soll฀eine฀Serie฀von฀Artikeln฀eröffnet฀werden,฀die฀in฀ kurzer฀Form฀auf฀neuere฀Entwicklungen฀im฀Projektmanagement฀hinweisen.฀Ziel฀ist฀es฀nicht,฀ das฀Thema฀vollständig฀abzuhandeln,฀sondern฀in฀knapper฀Form฀zu฀informieren฀und฀dem฀ Leser฀die฀Möglichkeit฀zur฀Vertiefung฀in฀der฀Literatur฀zu฀geben. 30฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 31฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Reifegradmodell von Kerzner [13] und das Programme Management Maturity Model (PMMM) [14] der britischen Association for Project Management (APM) und der British Computer Society. 2.2฀ Branchenspezifische฀Benchmarking-Modelle Kennzahlensysteme und entsprechende Datensammlungen, wie sie in Kapitel 2.1 aufgeführt wurden, gibt es auch für spezielle Branchen. So sind firmenübergreifende Projektdatenbanken für IT-Projekte eingerichtet worden (im Detail dazu [15, S. 123 ff.]). Ein relativ einfaches Kennzahlensystem für Software-Projekte findet sich bei Möller und Paulish [16]. Auch für die Bauwirtschaft existieren Datenbanken mit Kennwerten aus abgeschlossenen Vorhaben. Weit darüber hinaus gehen andere branchenspezifische Benchmarkingmodelle. Dazu gehört als wohl Erstes das Capability Maturity Model (CMM) des Software Engineering Institute der Carnegie Mellon University [17, 18], das speziell für die Softwarebranche entwickelt wurde. CMM wurde - grob gesprochen - für die Evaluierung des Software-Entwicklungsprozesses von Organisationen konzipiert. Inzwischen gibt es aus dem Software-Engineering-Institute eine ganze Modellfamilie, auf die hier schon aus Platzgründen nicht eingegangen werden soll. CMM unterscheidet die folgenden fünf Reifestufen:  initialer Prozess (auch chaotischer oder Ad-hoc- Prozess). Auf dieser Stufe ist der Projekterfolg im Wesentlichen von heroischen Anstrengungen der Mitarbeiter abhängig,  wiederholbarer Prozess,  definierter Prozess,  gesteuerter Prozess,  optimierender Prozess. Es werden die wichtigsten Teilprozesse identifiziert, die für die systematische Entwicklung von Software erforderlich sind, und in so genannte Schlüsselpraktiken zusammengefasst (Key Practice Areas), die einer der fünf Reifegradstufen zugewiesen werden. Nur die wenigsten Organisationen kamen bisher über die Stufe des „wiederholbaren Prozesses“ hinaus. Die Stufe des „definierten Prozesses“ ist in den USA Voraussetzung für den Erhalt eines Auftrags vom Department of Defense. Sozusagen Nachfolgemodelle von CMM sind BOOTSTRAP und SPICE (vgl. dazu im Detail [19]). Sowohl PM-Delta als auch die drei erwähnten Reifegradmodelle aus dem IT-Bereich sind sehr stark prozessorientiert. Dies gilt auch für ISO 9000 ff. In der 2. Normrevision 9000: 2000 ist die Prozessorientierung noch sehr viel stärker ausgeprägt als in den vorangegangen Versionen. Betrachtet wird auch hier nicht das Projektergebnis, also das Produkt, sondern die Prozesse, die zu seiner Entstehung führen. Unterschieden wird in der Regel zwischen Ad-hoc-Prozessen, die „spontan, individuell und ungeregelt“ (Glinz, [20]) sind, und systematischen Prozessen, die eindeutig definiert sind und nach denen auch gearbeitet wird. Durch Systematisierung der Abläufe soll ein einheitliches Vorgehen im Projekt erreicht werden. Der Projekterfolg soll personenunabhängiger und berechenbar werden. Von der Dokumentation der Prozesse werden auch Ansatzpunkte zur Verbesserung erwartet. Aus der fast ausschließlichen Betrachtung von Prozessen resultieren freilich auch Gefahren, auf die Glinz [20] aufmerksam macht:  Letztendlich interessiert den Kunden die Qualität des Produkts und nicht die des Prozesses.  Aufgaben, für die keine Prozesse definiert sind, werden möglicherweise vernachlässigt.  Buchstabengetreue Befolgung der vorgeschriebenen Prozessschritte führt zur Projektbürokratie.  Mit viel Aufwand definierte Prozesse erstarren möglicherweise, weil niemand mehr wagt, sie zu ändern. Ein weiterer Kritikpunkt ist, dass durch die Prozessorientierung die so genannten „weichen Faktoren“, wie z. B. das Engagement der Unternehmensführung für das Projekt und die Motivation und Qualifikation der Mitarbeiter, vernachlässigt werden. So kritisiert Hall [21, S. 52] an CMM: „It does not adress human resources, for example, which are known sources of software risk.“ Durch die Entwicklung des People-Capability- Maturity-Modells (P-CMM) [22] ist allerdings gerade für die älteste Modellfamilie dieser Vorwurf inzwischen ausgeräumt. 2.3฀ Klassifikation฀von฀Benchmarking-Modellen In den letzten Jahren sind nach Angaben von Cooke- Davies [23] rund 30 Projektbenchmarking-Modelle entstanden. Eine Übersicht und Synopse steht bislang aus. Abb. 1 zeigt die verschiedenen Arten von Benchmarking-Modellen in einem Raster. Branchenspezifische Modelle zur Bewertung von Einzelprojekten sind dem Verfasser bislang nicht bekannt, sieht man einmal von den relativ einfachen Kennzahlensystemen ab. ������������ ��������� �������� ���������� ����������� ����������� ������������ ��������������� ������������������ Project Excellence PM-Delta der GPM Deutsche Gesellschaft für Projektmanagement OPM3 PMMM Project Management Maturity Model (Kerzner) � CMM SPICE BOOTSTRAP Abb.฀1: ฀Kategorien฀von฀Benchmarking-Modellen 30฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 31฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 3฀ Kritik฀und฀Ausblick Folgende Bemerkungen und Forderungen ergeben sich aus einer kritischen Betrachtung:  Die dominierende Prozessorientierung einer Reihe von Modellen und die Vernachlässigung der so genannten „weichen Faktoren“ entsprechen nicht mehr dem derzeitigen Stand der Erfolgsfaktorenforschung im Projektmanagement. Dieser Einwand gilt allerdings für Project Excellence nur in eingeschränktem Maße.  Einige untersuchte Benchmarking-Modelle (etwa der Ansatz von Kerzner) machen einen wenig systematischen Eindruck. Warum gerade die im Bewertungskatalog zu findenden Fragen gestellt wurden und keine anderen und warum alle Fragen gleich gewichtet werden, wird beispielsweise nicht begründet. Mit anderen Worten: Es fehlt bislang eine solide wissenschaftliche Fundierung. Die schon erwähnte Erfolgsfaktorenforschung könnte hier eine Grundlage liefern.  Modelle, die sich zu stark auf den derzeitigen „Stateof-the-art“ bei den Methoden und Werkzeugen stützen, können schnell unflexibel werden und veralten. Deshalb ist größere Flexibilität anzustreben. Das Modell „Project Excellence“, das für den Nachweis bei den einzelnen Kriterien viele Möglichkeiten bietet, könnte hier beispielhaft sein.  Verschiedene Ansätze wie z. B. CMM sind geeignet, den potenziellen Anwender abzuschrecken. Wer sich jemals die entsprechenden voluminösen Handbücher aus dem Netz heruntergeladen hat, wird das sicher bestätigen. Die Gefahr des Benchmarking-Bürokratismus liegt sehr nahe. Flexibilität und einfache Handhabbarkeit sind also auch deshalb erforderlich, um auch kleineren Firmen die Chance der Benutzung zu geben.  Das schnelle Wachstum des Bestands an Modellen macht es auch nahezu unmöglich, einen Überblick zu gewinnen. Deshalb ist es dringend notwendig, die einzelnen Ansätze gegenüberzustellen und Gemeinsamkeiten und Unterschiede herauszuarbeiten. Vorbildhaft könnte hier etwa der von Paulk [24] angestellte Vergleich zwischen ISO 9001 und CMM sein.  Aus einer solchen Synopse müssten Schwachstellen einzelner Modelle (z. B. bei der Analyse des Risikomanagements) identifiziert und fundierte Empfehlungen abgeleitet werden, in welchen Fällen welche Modelle für ein Benchmarking geeignet sind. Nach dieser kurzen Darstellung lässt sich abschließend sagen: Die Entwicklung von Benchmarking-Modellen steht erst ganz am Anfang und steht noch auf unsicherem theoretischem Fundament. Um zu wirklich befriedigenden Ansätzen zu kommen, sind noch viele Anstrengungen erforderlich. Sie bedürfen der Koordination durch eine internationale Instanz, etwa die IPMA.  Literatur [1]฀American฀Productivity฀&฀Quality฀Center฀(Ed.): ฀The฀ Benchmarking฀Management฀Guide.฀Portland฀1993 [2]฀Ottmann,฀R.: ฀4.10.2฀Projektbenchmarking฀(PBM)฀-฀Analyse฀der฀besten฀Praktiken.฀In: ฀Schelle,฀H.; ฀Reschke,฀H.; ฀ Schnopp,฀R.; ฀Schub,฀A.฀(Hrsg.): ฀Loseblattsammlung฀„Projekte฀erfolgreich฀managen“.฀Köln฀1994฀ff.,฀10.฀Aktualisierung [3]฀IEEE฀90: ฀IEEE฀Standard฀Glossary฀of฀Software฀Engineering฀Technology.฀IEEE฀St.฀610.12-1990 [4]฀Wasielewski,฀E.฀v.: ฀Grundzüge฀einer฀Projektvergleichstechnik.฀In: ฀Saynisch,฀M.; ฀Schelle,฀H.; ฀Schub,฀A.: ฀(Hrsg.): ฀ Projektmanagement.฀Konzepte,฀Verfahren,฀Anwendungen.฀ München-Wien฀1979,฀S.฀371-397 [5]฀Wasielewski,฀E.฀v.; ฀Oertzen,฀H.-J.฀v.: ฀Projects฀Comparing฀ Technique฀-฀Fundamentals฀under฀Excel.฀In: ฀Ottmann,฀R.; ฀ Grau,฀N.; ฀Schelle,฀H.฀(Eds.): ฀16 th ฀IPMA฀World฀Congress฀on฀ Project฀Management.฀Making฀Visions฀Work.฀Berlin฀2002,฀ S.฀407-412 [6]฀George,฀G.: ฀4.10.4฀Kennzahlen฀und฀Kennzahlensysteme฀ für฀das฀Projektmanagement.฀In: ฀Schelle,฀H.; ฀Reschke,฀H.; ฀ Schnopp,฀R.; ฀Schub,฀A.฀(Hrsg.): ฀Loseblattsammlung฀„Projekte฀erfolgreich฀managen“.฀Köln฀1994฀ff.,฀16.฀und฀17.฀Aktualisierung [7]฀GPM฀Deutsche฀Gesellschaft฀für฀Projektmanagement฀ e.฀V.฀(Hrsg.): ฀The฀International฀German฀Project฀Management฀ Award.฀Der฀Internationale฀Deutsche฀Projektmanagement฀ Award฀2001.฀Application฀Brochure.฀Nürnberg฀2002 [8]฀Techt,฀U.: ฀Selbstbewertung฀nach฀Project฀Excellence.฀ Anzeige 32฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 33฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Wie฀Sie฀in฀Ihren฀Projekten฀den฀Stand฀auf฀dem฀Weg฀zu฀ Spitzenleistungen฀erkennen฀und฀daraus฀Verbesserungen฀ ableiten.฀In: ฀Projektmanagement,฀7.฀Jg.,฀H.฀4,฀S.฀47-52 [9]฀http: / / www.gpm-ipma.de/ 10-1.htm฀(20.฀1.฀2003) [10]฀Schelle,฀H.: ฀Projektbenchmarking.฀In: ฀Specht,฀D.; ฀Möhrle,฀G.฀(Hrsg.): ฀Gabler฀Lexikon฀Technologiemanagement.฀ Management฀von฀Innovationen฀und฀neuen฀Technologien฀im฀ Unternehmen.฀Wiesbaden฀2002,฀S.฀259-262 [11]฀Eschwei,฀W.: ฀4.10.3฀PM-Assessment฀in฀Projekten฀und฀ von฀Systemen.฀Die฀Diagnose฀für฀Ihr฀Projektmanagement.฀ In: ฀Schelle,฀H.; ฀Reschke,฀H.; ฀Schnopp,฀R.; ฀Schub,฀A.฀(Hrsg.): ฀ Loseblattsammlung฀„Projekte฀erfolgreich฀managen“.฀Köln฀ 1994฀ff.,฀12.฀Aktualisierung฀und฀http: / / www.gpm-ipma.de/ 11-1.htm฀(20.฀ 1.฀2003) [12]฀Friedrich,฀R.: ฀PMI’s฀Organizational฀Project฀Management.฀Maturity฀Model.฀In: ฀Ottmann,฀R.; ฀Grau,฀N.; ฀Schelle,฀H.฀ (Eds.): ฀16 th ฀IPMA฀World฀Congress฀on฀Project฀Management.฀ Making฀the฀Vision฀Work.฀Berlin฀2002,฀S.฀497-500 [13]฀Kerzner,฀H.: ฀Strategic฀Planning฀for฀Project฀Management฀ using฀a฀Project฀Management฀Maturity฀Model.฀New฀York฀ 2001 [14]฀http: / / www.e-programme.com/ pmmm.htm฀(20.฀1.฀2003) [15]฀Bundschuh,฀M.; ฀Fabry,฀A.: ฀Aufwandschätzung฀von฀IT- Projekten.฀Landsberg/ Lech฀2000 [16]฀Möller,฀K.฀H.; ฀Paulish,฀D.฀J.: ฀Software฀Metrics.฀A฀ Practitioner’s฀Guide฀to฀Improved฀Product฀Development.฀ London฀1993 [17]฀http: / / www.sei.cmu.edu/ cmm/ cmm.html฀(20.฀1.฀2003) [18]฀Dymond,฀K.฀M.: ฀CMM฀Handbuch.฀Das฀Capability฀Maturity฀Model฀für฀Software.฀Berlin-Heidelberg฀2002 [19]฀Stienen,฀H.: ฀Nach฀CMM฀und฀BOOTSTRAP: ฀SPICE.฀Die฀ neue฀Norm฀für฀Prozessbewertungen.฀In: ฀Informatik.฀Informatique,฀Heft฀6,฀1999,฀S.฀16-21 [20]฀Glinz,฀M.: ฀Eine฀geführte฀Tour฀durch฀die฀Landschaft฀der฀ Software-Prozesse฀und฀-Prozessverbesserung.฀In: ฀Informatik.฀Informatique,฀Heft฀6,฀1999,฀S.฀7-11 [21]฀Hall,฀E.฀M.: ฀Management฀Risks: ฀Methods฀for฀Software฀ Systems฀Development.฀Boston฀1998 [22]฀http: / / www.sei.cmu.edu/ cmm/ cmm-p฀(20.฀1.฀2003) [23]฀Cooke-Davis,฀T.: ฀Do฀you฀need฀a฀project฀management฀ maturity฀model? ฀In: ฀Project฀Management฀Today,฀May฀2002,฀ S.฀16-20 [24]฀Paulk,฀M.฀C.: ฀How฀ISO฀9001฀compares฀with฀the฀CMM.฀ In: ฀IEEE฀Transactions฀on฀Software,฀Vol.฀12,฀No.฀1,฀January฀ 1995,฀S.฀74-83 Schlagwörter Projektanalyse,฀Projektbenchmarking,฀Projektbewertung,฀ Projektvergleich,฀Reifegradmodell Autor Prof.฀Dr.฀Heinz฀Schelle,฀geb.฀1938,฀ist฀ Inhaber฀einer฀Professur฀für฀Betriebswirtschaftslehre฀mit฀besonderer฀ Berücksichtigung฀des฀Projektmanagements฀an฀der฀Fakultät฀für฀Informatik฀ der฀Universität฀der฀Bundeswehr฀ München.฀Er฀ist฀einer฀der฀Gründer฀der฀ GPM,฀war฀von฀1979฀bis฀1998฀Mitglied฀ des฀Vorstands฀und฀ist฀heute฀Ehrenvorsitzender฀der฀Gesellschaft฀und฀Mitglied฀des฀Kuratoriums. Anschrift Universität฀der฀Bundeswehr฀München Fachbereich฀Informatik Werner-Heisenberg-Weg฀39 D-85577฀Neubiberg E-Mail: ฀h.schelle@gaponline.de