PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
91
2003
143
Gesellschaft für ProjektmanagementWas ist eigentlich Projekterfolg?
91
2003
Helmut Strohmeier
In dieser, in der letzten Nummer begonnenen Reihe befasst sich dieses Mal Helmut Strohmeier mit einem Thema, das vor allem im angelsächsischen Sprachraum gegenwärtig zumeist unter dem Stichwort „Benefit-Management“ diskutiert wird. Im Grunde geht es - etwas vereinfacht - um die Frage, was eigentlich Projekterfolg bedeutet, ein Problem, das in der Projektmanagementliteratur viele Jahre nicht als solches erkannt wurde. In unserer im vergangenen Jahr durchgeführten internationalen Expertenbefragung haben wir dazu eine ganze Reihe von Thesen sammeln können. Eine davon sei hier einleitend zitiert: „Traditional approaches to measuring project success based on time, cost and quality will evolve into a more customer based approach where the customer’s developing expectations will be the measure of success.“
Der Autor hat für seine sehr originelle Auseinandersetzung mit diesem Thema die prägnanten Begriffe „Abwicklungserfolg“ und „Anwendungserfolg“ geprägt, wobei der Abwicklungserfolg der oben angesprochenen traditionellen Auffassung vom Projekterfolg entspricht.
pm1430029
30 P R O J E K TMANA G E M E N T 3 / 2 0 0 3 WISSEN 31 P R O J E K TMANA G E M E N T 3 / 2 0 0 3 sprünglich getroffene Annahmen nicht haltbar sind, mag man zwar als Irrtum werten können, ein Fehler ist das aber sicher nicht. Ein Fehler wäre es vielmehr, wider besseren Wissens an nicht mehr gültigen Annahmen festzuhalten. Kann man also von einem Misserfolg sprechen, wenn wir nachweislich hinzugelernt haben? Gibt uns nicht die Natur unendlich viele Beispiele, wie sie aus Irrtümern lernt und sich gerade deshalb fortentwickelt? Dürfen wir also den Statistiken noch trauen, wenn in ihnen - obiger Erfolgsdefinition folgend - das „lernende Projekt“ als Misserfolg, unser Projekt-Informationssystem hingegen als Erfolg verbucht ist? Wasfolgt,wenneinProjektprodukteingerichtetist? Wir werden nicht umhinkommen, die lang gehegte Erfolgsdefinition einer kritischen Beurteilung und einer etwas differenzierteren Betrachtung unterziehen zu müssen. Obig genannte traditionelle Maßeinheit (ich bezeichne sie als Abwicklungserfolg) hat natürlich nach wie vor ihre Berechtigung, denn Projekte dürfen keinen Freibrief zum schamlosen Überziehen von Terminen und Budgets bekommen. Müssten wir aber nicht ergänzend dazu den Projekterfolg am lang anhaltenden Nutzen und am Ausbleiben schädlicher Wirkungen messen? Eine zweite Messlatte sollte sich also hinzugesellen (ich bezeichne sie als Anwendungserfolg), die uns verdeutlicht, ob und in welchem Umfang das Projektergebnis Vorteile für ein gesamtes Unternehmen erzeugt. Dazu bedarf es gründlich durchdachter und gemeinsam verabschiedeter Annahmen, die anschließend einer wiederkehrenden Überprüfung zu unterziehen sind. Annahmen können sich auf erreichbare materielle Vorteile, auf anhaltende Nutzerzufriedenheit, aber auch auf Vor- und Nachteile im Vergleich zu irgendetwas anderem beziehen; sie können die angestrebte Aufwand-Nutzen-Relation und den vermutlichen Ballast (z. B. Betreuungsaufwand) zum Inhalt haben, den sich ein Unternehmen mit einem neuen Projektprodukt auferlegt. Ob diese Annahmen richtig sind oder nicht, wird sich endgültig erst zeigen, wenn unser Projektprodukt im praktischen Einsatz wirkt - also mit einigem Zeitverzug. Doch gerade weil der Zeitraum ziemlich lang sein kann, sollten wir unser „automatisches Schlauerwerden“ während des Projektverlaufs sinnvoll nutzen und unseren jeweils neuesten Erkenntnisstand an ursprünglich getroffenen Annahmen reflektieren. Sind sie noch haltbar? Können wir sie als untermauert bestätigen oder müssen wir sie revidieren? Zeigen unsere Prüfungen, dass Annahmen nach wie vor gültig sind, dann ist das natürlich erfreulich. Doch auch das Entdecken von Diskrepanzen ist ein Gewinn, weil wir dann aus Irrtümern lernen und vermutlich noch korrigierend eingreifen können. Mitunter werden wir auch feststellen, dass sich beide Erfolgsmaßstäbe widersprechen. Mal wird das „Schlauerwerden“ raten, einen Termin zu verschieben, mal wird erzielbarer Nutzen die Einführung zum frühestmöglichen Zeitpunkt unmissverständlich fordern, auch wenn Verbesserungen noch denkbar sind. Weil es einerseits unsinnig ist, ein Produkt anzustreben, das den Wünschen einer Organisation nicht (mehr) genügt, diese es andererseits aber auch nicht mag, wenn das Projektergebnis ewig nicht fertig wird, ist eine Organisation stets auf weise Entscheidungen intelligenter Menschen angewiesen, Menschen, denen das Wohl des gesamten Unternehmens nicht abhanden gekommen sein darf. Und nur der konkrete Einzelfall darf entscheidend sein, welchem der beiden Maßstäbe höhere Priorität eingeräumt wird. SystemverständnisundvernetztesDenken Unseren Projekten den zweiten, einen an Wirkungen orientierten Erfolgsmaßstab beiseite zu stellen, macht sie natürlich nicht einfacher - im Gegenteil. Wir bekommen es mit zusätzlicher Komplexität und neuer Verantwortung zu tun. Nun müssen wir nämlich nicht nur unser Projektprodukt beherrschen, sondern vor allem den Teilausschnitt einer Organisation, in dem das Produkt später wirken wird. Der wahre Bedarf will erkannt und das Gesamtsystem einer Organisation beherrscht sein - aus Sicht des Fortschritts ein äußerst lohnendes Unterfangen, auch wenn es anstrengend ist. Wir dürfen eben nicht übersehen, dass Projektergebnisse ein real existierendes System, den Organismus einer Organisation, mehr oder weniger stark beeinflussen. Und sobald wir die Regeln eines Gesamtsystems, sein Verhalten und seine Eigenheiten nicht kennen, hemmen wir höchstwahrscheinlich, wenn auch ungewollt, den ������� ������ ����������� ������� ������ ����������� ������� ������� ����������� ������� ������� ����������� ������������ ������������ ����������� ������������ ������������ ����������� ������������ ������������ ������������� ������������ ������������������ ������� �������� ������������������������ ������������������������ � � � � � � � � ����������������������� ������������������������������ � ����������������������������������������������������������������������������������������������������� � ������������������������������������������������������������������������������ � ������������������������������������������������������������������������������������ � ����������������������������������������������������������������������������������������� Abb.1: AmErfolgorientiertes,iterativesLernenaufvierEbenen 30 P R O J E K TMANA G E M E N T 3 / 2 0 0 3 WISSEN 31 P R O J E K TMANA G E M E N T 3 / 2 0 0 3 Fortschritt. Es kommt zu überraschenden und eigenmächtigen Reaktionen mit unangenehmen Nebenwirkungen, weshalb sich prophezeiter Nutzen häufig nicht so ergeben will wie erhofft. Ein Projekterfolg ist heute weit weniger von einer wohl durchdachten Konstruktion eines Produkts, sondern weit mehr von seinem Wirken in einer bestehenden Umgebung abhängig. Ich befürchte deshalb, dass wir uns als Manager von Organisationsprojekten auf Gebiete begeben müssen, die wir bisher weitgehend links liegen gelassen haben. Ich denke an Disziplinen wie vernetztes Denken und systemische Betrachtung. Systemdenker wie Peter M. Senge, Frederic Vester und Dietrich Dörner haben abseits unserer Projekte verdeutlicht, was passieren kann, wenn wir Systeme nicht beherrschen und sie genau deshalb falsch zu beeinflussen versuchen. Wir übersehen Gefahren und produzieren schädliche Wirkungen, wie unser Projekt-Informationssystem beweist. Zudem sind wir uns selten bewusst, dass Systeme träge sind und erst mit Zeitverzug reagieren. Wir werden deshalb rasch ungeduldig und tendieren zur Übersteuerung: „Falls sich die Organisation gegen die Neuerung sträubt, dann muss das System eben noch ausgefeilter und umfassender sein.“ Oder aber wir wollen dem Gesamtsystem kraft Autorität zu seinem Glück verhelfen: „Das neue System wird eingeführt, basta! “ Wir vergessen allerdings, dass der Organismus einer Organisation viel mächtiger ist als jedes Projekt. Er wird unser Projektprodukt entweder freudestrahlend aufnehmen oder aber sich dagegen wehren, schlimmstenfalls sogar mit seinem Tod antworten. „Konkursreifes Unternehmen verklagt Standardsoftwarehersteller“, lautete einmal eine Schlagzeile in der Computerwoche. UnsereFehlerbeimBeeinflussenvonkomplexen Systemen Wir machen im Verlauf eines Projekts vieles falsch, und doch sind unsere Fehler meist nur eine Folge einer mittlerweile leider tief verwurzelten, aber äußerst schädlichen Praxis: des Reparaturdienstverhaltens. Wir kurieren häufig nur am Symptom, wie obig genannte Autoren übereinstimmend festgestellt haben. Seit Menschengedenken sind wir gewohnt, in linearen Ursache- Wirkungs-Ketten, nicht aber in vernetzten Strukturen zu denken. Wir versuchen Missstände zu beseitigen, weil es irgendwo bereits fürchterlich brennt, ohne darüber nachzudenken, wo tiefer liegende Ursachen angesiedelt sind. Und über mögliche Kobra-Effekte unseres Tuns denken wir schon gar nicht nach, sie überraschen uns lediglich. Der Kobra-Effekt hat seinen Namen aus der Zeit der englischen Kolonialverwaltung in Indien. Weil das Land unter einer Kobra-Plage zu leiden hatte, setzte die Regierung eine Prämie für jede gefangene Kobra aus. Die Bevölkerung aber sah darin eine zusätzliche Einnahmequelle und so züchtete sie Kobras. Dass nicht nur wir Projektverantwortlichen stark im engen linearen Denken verhaftet sind, sondern wir Gleiches fast täglich an unseren Politikern beobachten dürfen, sollte nicht wirklich trösten. Betrachten wir vor diesem Hintergrund nun die Empfehlung, Projekte möglichst klein zu halten. Provozieren wir damit nicht förmlich das Kurieren am Symptom? Ist es nicht verständlich, dass wir Zusammenhänge übersehen, wenn wir uns stets nur kleine Teilausschnitte vornehmen? Wissen wir nicht seit langem, dass das Optimieren vieler kleiner Teilbereiche nie zu einem Gesamtoptimum führen kann? Wer hat sich nicht schon über wenig durchdachte Systeme seiner Vorgänger geärgert? Ich behaupte also, dass ein bedingungsloses Zerschlagen von Projektinhalten vielleicht noch aus Sicht des Abwicklungserfolgs berechtigt sein mag, aus Sicht des Anwendungserfolgs aber höchst selten. Wir werden kein Verständnis für umfassende Zusammenhänge aufbringen, wenn wir uns stets nur auf kleinste Teilbereiche stürzen. Wir werden die Wirkungen außerhalb unserer engen Projektgrenzen nicht beurteilen können, wenn wir das Gesamtsystem nicht kennen. Und wir werden eben auch nicht ausreichend genug hinzulernen. So schädigen wir den Organismus einer Organisation, erkennen es nur leider nicht, weil das Gesamtsystem eben erst mit erheblicher Zeitverzögerung reagiert. WarummüssenProjekteeigentlichkleinsein? Was hat wohl zur Empfehlung geführt, Projekte klein zu halten? Einerseits dürfte das Bestreben, auf diese Weise schnell zu nutzbringenden Lösungen zu kommen, Pate gestanden haben, und andererseits vermute ich, dass es die Angst vor Komplexität ist. In kleinen Projekten scheinen wir sie noch zu beherrschen (Ausnahme: schädliche Wirkungen), in großen offenbar nur selten. Doch schon wieder drängt sich die Frage auf, ob wir nicht auch hier das Symptom anstelle der Ursachen bekämpfen. Wäre es nicht besser darüber nachzudenken, wie die Komplexität großer Vorhaben in den Griff zu bekommen ist, anstatt sie künstlich zu zerhacken? Und was das erste Argument, die frühere Einführung, betrifft, so ist auch dieses kaum haltbar. Wir finden sehr schnell einzeln realisierbare Teilbereiche, wenn wir zuerst in Zusammenhängen denken - vielleicht sogar dann erst recht. Allerdings müssen wir dazu die Komplexität beherrschen, was erst einmal ziemlich anstrengend ist. Es mag nun der Eindruck entstanden sein, dass ich ein entschiedener Verfechter von Großprojekten bin. Stimmt gar nicht. Ich bin ein Verfechter des „Right- Sizing“, weil genau darin manches Erfolgs- oder Misserfolgsgeheimnis liegt. Ein Projekt ist richtig dimensioniert, wenn es umfassend Nutzen erzeugen kann und wenig bis keine schädlichen Wirkungen hinterlässt. Es ist richtig dimensioniert, wenn das zu entwickelnde Teilsystem sich nahtlos in den Organismus eines Unternehmens integrieren lässt und von diesem anstandslos aufgenommen wird. Haben wir den Projektumfang auf diese Weise definiert, dann hat anschließend ein Optimierungsprozess stattzufinden, der nun sicherzustellen hat, dass besonders nutzbringende Teile rasch eingeführt werden und der Projektaufwand die Organisation nicht überfordert. Es sind Risiken zu beurteilen und geeignete Maßnahmen zur Risikominimierung einzuleiten, um auf diese Weise die Misserfolgswahrscheinlichkeit weiter zu reduzieren. Damit werden wir dem Projekt echte Stärke aneignen, die allein schon den Misserfolg eher unwahrscheinlich macht. Die Wahrscheinlichkeit des Erfolgs schaukelt sich auf - auch ein Phänomen, das wir beobachten können, sobald wir uns 32 P R O J E K TMANA G E M E N T 3 / 2 0 0 3 WISSEN 33 P R O J E K TMANA G E M E N T 3 / 2 0 0 3 die Fähigkeit angeeignet haben, das Verhalten von Systemen zu durchschauen. AufdemWegederBesserung Wenn wir beiden Erfolgsmaßstäben zu ihrem Recht verhelfen und damit die Erfolgswahrscheinlichkeit all unserer Projekte drastisch erhöhen wollen, müssen wir einiges tun. Die folgende Zusammenfassung soll es zeigen: Wir sollten uns angewöhnen, den Projektumfang aus Chancen und viel weniger aus Symptomen zu bilden. Es ist die Frage zu stellen, an welchen Stellen einer Organisation die Hebel anzusetzen sind, um größtmöglichen und anhaltend wirkenden Fortschritt erzielen zu können. Wir müssen das Projekt so dimensionieren, dass Gesamtzusammenhänge einer Organisation komplett beachtet und vollständig innerhalb eines Projekts einer neuen Lösung zugeführt werden. Wir müssen die Außenbeziehungen unseres Projektprodukts genau ermitteln und an allen Schnittstellen zum Gesamtsystem einer Organisation die Aufnahmebereitschaft herstellen. Wir müssen dafür sorgen, dass sich eine Organisation (Zuständigkeiten, Prozesse usw.) transparent zeigt, dass sie ihr Regelwerk, nach dem sie funktioniert, offen legt. Wir brauchen Methoden und Werkzeuge, mit denen auch höchste Komplexität beherrschbar wird und überschaubar darzustellen ist. Wir müssen Annahmen offen legen und Erfolge ebenso wie Irrtümer messen, um daraus Rückschlüsse ziehen zu können. Aus diesen Rückschlüssen werden wir zu verbesserten Annahmen kommen, die nicht nur für das gegenwärtige Projekt, sondern ebenso für alle Folgeprojekte bedeutend sind. Wir müssen dafür sorgen, dass Manager und Mitarbeiter nicht nur ihr eigenes, sondern stets auch das Wohl des gesamten Unternehmens im Auge haben und behalten. Wir alle müssen uns verantwortlich fühlen, dass Nutzen tatsächlich eintreten wird und schädliche Wirkungen ausbleiben (nicht irgendeiner ist dafür verantwortlich, sondern das gesamte Projektteam). Wir müssen das systemische Denken, das Denken in Gesamtzusammenhängen und das Erkennen kybernetischer Regeln innerhalb dieser Systeme fördern. Wir müssen sicherstellen, dass sowohl im Vorfeld eines Projekts als auch während seines Verlaufs ein gemeinsames Lernen stattfindet. Wir müssen dem Projekt genau zu der Stärke verhelfen, die es verdient (was auch heißt, dass wir unbedeutende oder wenig bedeutende Projekte dem bedeutenden unterzuordnen haben). Fazit: Ein gleichberechtigtes Nebeneinander von Maßstäben, nach denen wir sowohl den Abwicklungsals auch den Anwendungserfolg messen, ist eine unabdingbare Voraussetzung für echten Projekterfolg. Wir bekommen diese Voraussetzungen jedoch nicht geschenkt, sondern müssen die ein oder andere Denk- und Verhaltensweise, die sich heimlich, still und leise eingeschlichen hat, aus unseren Unternehmen verbannen. Die Summe der Projekterfolge lässt sich in vielen Unternehmen gewaltig steigern, nur nicht von heute auf morgen. Wie erwähnt, bestehende Systeme sind träge, und organisatorische, auf Verhalten von Menschen basierende leider besonders. Literatur [1]Dörner,Dietrich: DieLogikdesMißlingens.Hamburg 2001 [2]Senge,PeterM.: DiefünfteDisziplin.Stuttgart2001 [3]Strohmeier,Helmut: RechtzeitigdierichtigenProjekte finden.Köln2000 [4]Strohmeier,Helmut: DieArchitekturerfolgreicherProjekte.München2003 [5]Vester,Frederic: DieKunstvernetztzudenken.Stuttgart2000 Schlagwörter Abwicklungserfolg,Anwendungserfolg,BenefitManagement,Projekterfolg Autor HelmutStrohmeier,Jahrgang1949; StudiumderBetriebswirtschaft mitSchwerpunktOrganisation undDatenverarbeitungander FachhochschuleMünchen.Nach seinerZeitalsSystementwickler, OrganisatorundIS-Leiteristerin dieBeratunggewechseltundhat indieserFunktionvieleOrganisationsprojektegeleitet undbegleitet.HeuteisterGeschäftsführereinesBeratungsunternehmensfürmethodischeSystementwicklung undProjektmanagement.AlsAutormehrererBücherund FachartikelbetätigtersichderzeitvorwiegendalsCoach vonGroßprojektenundalsTrainer. Anschrift Strohmeier&PartnerGmbH AmFischergries20a D-85570MarktSchwaben Tel.: 08121/ 437000 E-Mail: Strohmeierpartner@t-online.de 32 P R O J E K TMANA G E M E N T 3 / 2 0 0 3 WISSEN 33 P R O J E K TMANA G E M E N T 3 / 2 0 0 3 Leserbriefe IneigenerSache Exoccidentelux? Projektmanagementaktuell,Heft1/ 2003,S.39 M it meiner Rezension des Project Management Body of Knowledge (PMBOK) des Project Management Institute of America (PMI) in der Nr. 1/ 2003 dieser Zeitschrift habe ich Reaktionen ausgelöst, die ich in dieser Stärke nicht erwartet hatte. Neben einigen zustimmenden Briefen habe ich auch Kritik geerntet. Sie kam aus den Reihen der deutschen PMI- Mitglieder. Etwas vereinfacht könnte man sie auf den Nenner bringen: So etwas tut man nicht unter Kollegen. Allerdings ist auch die Meinung geäußert worden, dass man vielleicht aus der Buchschelte auch Nutzen ziehen könnte. Auch aus GPM-Kreisen habe ich keineswegs nur Lob erhalten. Die Ursache dafür liegt, soweit ich das sehe, wohl eher im Bereich der Diplomatie. Etwas enttäuscht hat mich, dass die Kritiker sich bisher zur Sache selbst nicht geäußert und versucht haben, meine Argumente zu widerlegen. Die deutschen Vertreter des PMI haben zwar speziell für meinen Beitrag ein Diskussionsforum im Internet eröffnet, die Ergebnisse sind mir aber bislang nicht zugänglich gemacht worden. Auf mein im Januar dieses Jahres spontan gemachtes Angebot, mich einer Diskussionsrunde zu stellen, habe ich nach anfänglicher Zustimmung nichts mehr gehört. Ich gebe gerne zu, dass ich zum Teil sehr deftige Formulierungen - z. B. den Hinweis auf den Speichelfluss der Pawlow’schen Hunde - gewählt habe. Das hat vielleicht damit zu tun, dass der Stamm der Altbaiern, dem ich angehöre, noch niemals große und geschmeidige Diplomaten hervorgebracht hat. In der Sache habe ich freilich keinerlei Abstriche zu machen. Sollte sich allerdings jemand durch allzu grobe Formulierungen verletzt fühlen, entschuldige ich mich in aller Form. Hocherfreulich ist, dass jetzt zwei in der Projektmanagementszene sehr bekannte und sachkundige Kollegen, Manfred Saynisch und Dr. Erhard Motzel, umfangreiche Leserbriefe geschrieben haben, in denen sie sich mit meiner Rezension auseinander setzen. Manfred Saynisch hat darüber hinaus in einem zweiten Beitrag, den wir später veröffentlichen werden, auch Vorschläge zur Weiterentwicklung unserer Disziplin gemacht. Es war von vornherein meine Absicht, eine lebendige Diskussion anzuregen, die für unser aller Anliegen, die Förderung systematischen Projektmanagements, von Vorteil ist. Jetzt haben wir sie. HeinzSchelle,Oberau
