eJournals

4฀฀ EDITORIAL P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 5฀฀ REPORT ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Risikomanagement฀-฀das฀ „Stiefkind“฀in฀der฀Projektarbeit Instrumente฀für฀Analyse฀und฀Bewertung฀der฀Projektrisiken฀bleiben฀häufig฀ungenutzt Oliver฀Steeger Experten฀schlagen฀Alarm: ฀Zu฀wenige฀Projektteams฀analysieren฀die฀Risiken฀ihres฀Vorhabens.฀Risikomanagement฀gehört฀bislang฀zu฀den฀„Stiefkindern“฀der฀Projektmanager฀ -฀mit฀fatalen฀Folgen.฀Die฀Liste฀der฀(vorhersehbaren)฀Gefahren,฀an฀denen฀Projekte฀in฀der฀ Praxis฀scheitern,฀ist฀lang.฀Indes,฀es฀liegen฀gute฀Strategien฀und฀Instrumente฀bereit,฀Projektrisiken฀zu฀identifizieren฀und฀zu฀bewerten.฀Zudem฀haben฀Unternehmen฀im฀Anlagenbau,฀ in฀der฀IT-Branche,฀in฀der฀Pharma-฀und฀der฀Automobilbranche฀Pionierarbeit฀geleistet.฀Sie฀ zeigen,฀wie฀sich฀Projekte฀gegen฀Risiken฀absichern฀lassen.฀Denn: ฀Am฀systematischen฀ Risikomanagement฀führt฀in฀den฀nächsten฀Jahren฀kein฀Weg฀vorbei฀-฀allein฀schon฀nicht฀ wegen฀den฀gesetzlichen฀Vorgaben,฀beispielsweise฀Basel฀II฀und฀KonTraGes.฀Diesen฀Trend฀ spiegeln฀die฀Expertenbefragungen฀der฀GPM฀und฀die฀praxisnahe฀Literatur฀zum฀Thema฀ Risikomanagement฀wider.฀ „ D ass die Probleme so eskalieren könnten“ - Projektleiter Thomas Gams (Name von der Redaktion geändert) ahnte, dass in seinem IT-Projekt von Anfang an „ein paar Punkte nicht so optimal waren“. Die Spezifikation, die der Wahl der Business- Software zugrunde lag, schien ihm beim ersten Blick an einigen Stellen unklar (an den entscheidenden Stellen, wie sich später zeigte). Dann zweifelte Gams an den vollmundigen Versprechungen eines Dienstleisters, der die neue Datenbanktechnologie als völlig problemlos bezeichnete. Zuletzt passierte etwas, was ihn hätte warnen müssen: Die Kollegen in der Buchhaltung, die mit der neuen Software arbeiten sollten, hielten von dem ganzen Projekt nichts. Nur halbherzig unterstützten sie die ersten Tests. Sie schienen geradezu erleichtert, als der Vorstand dem richtungslosen Vorhaben ein Ende setzte. Thomas Gams hat die Risiken seines Projektes geahnt, gelegentlich auch Vorsorge getroffen. Doch nicht genug, wie sich herausstellte: „Hätte ich die Risiken systematisch aufgespürt und mich abgesichert“, meint er heute, „ich hätte vieles anders steuern können.“ Die Erfahrung zeigt: Nicht wenige Projektleiter laufen blind ins Unglück. Sie versäumen es, methodisch die Gefahren ihres Vorhabens aufzuspüren, zu beschreiben, zu bewerten und sich zu wappnen. So durchkreuzen plötzlich, aber vorhersehbar technische Probleme die Planungen: Das Projektumfeld leistet „unerwartet“ Widerstand. Projektpartner arbeiten nicht pünktlich, das Top-Management versagt seine Unterstützung, es treten Engpässe bei Ressourcen ein. Solche Gefahren hätten sich bei gründlicher, früher Analyse in scharfer Kontur abgebildet. „Ich kenne genug Projektleiter, die ihre Projektrisiken nur als grobe Schemen sehen und auf gut Glück arbeiten“, klagt Professor Heinz Schelle von der Uni- Sorgfältig฀Risiken฀identifizieren฀und฀analysieren฀-฀das฀ist฀ beim฀Risikomanagement฀nur฀„die฀halbe฀Miete“.฀Während฀ des฀Projekts฀muss฀das฀Projektteam฀die฀Gefahrenlage฀ständig฀beobachten. Foto: ฀Siemens 6฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 7฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 versität der Bundeswehr München. Mehr noch: Sie tun die Risiko-Betrachtungen als Schwarzmalerei ab. Das Grübeln in Worst-Case-Szenarien untergrabe die Motivation des Teams, irritiere Projektgeber und koste knappe Zeit. Indes, sie werden von der Realität schnell eingeholt. Allein in der Softwareindustrie endet, wie der CHAOS-Report der Standish Group zeigt, eins von drei Projekten vorzeitig; ein weiteres Drittel der IT-Projekte kommt nur mit Mühen, erheblichen Verlusten und Verspätungen ins Ziel. Auch in anderen Branchen werden sieche Projekte klammheimlich zu Grabe getragen, die an heimtückischen, meist aber voraussehbaren Problemen scheiterten. Siebzig฀Prozent฀der฀Unternehmen฀ohne฀Risikomanagement In wenigen anderen Projektmanagement-Bereichen klaffen Theorie und Praxis so weit auseinander wie beim Risikomanagement. Risikomanagement ist bekannt, seit Jahren schon. In anerkannten Projektmanagement-Standards gehört Risikomanagement wie selbstverständlich dazu. Einschlägige Prozessmodelle beispielsweise für die Automobilentwicklung umfassen die aktive Auseinandersetzung mit Projektrisiken. Praktiker haben in der Fachwelt geschätzte Ratgeber verfasst, darunter Elaine M. Hall (Managing Risk. Methods for Software Systems Development, Boston 1997) und Markus Gaulke (Risikomanagement in IT-Projekten, München-Wien 2002). Auch stellen bereits zwanzig Jahre alte Veröffentlichungen aus dem Anlagenbau ein praktikables Instrumentarium bereit, das es nur zu nutzen gilt. Der฀Anlagenbau฀gilt฀beim฀Risikomanagement฀als฀vorbildlich.฀Schon฀früh฀haben฀einzelne฀Unternehmen฀Checklisten฀ erarbeitet,฀die฀heute฀als฀Muster฀auch฀für฀andere฀Branche฀gelten. Foto: ฀Siemens Foto: ฀MAN In฀der฀Automobilbranche฀ist฀Risikomanagement฀weit฀ verbreitet.฀Hier฀hat฀das฀Qualitätsmanagement฀wichtige฀ Impulse฀geliefert. 6฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 7฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 So weit die Theorie, genauer: die Empfehlungen, die aus leidvollen Erfahrungen gewonnen wurden. In der Praxis kommt das Risikomanagement selten über rudimentäre Ansätze hinaus. In 70 Prozent der Unternehmen, berichtet ein Münchner Unternehmensberater im vertraulichen Gespräch, fehlt das Risikomanagement bei Projekten gänzlich. Bestenfalls anhand von Erfahrungswerten, in der Regel nur aus dem Bauch heraus, erwägen Projektleiter das, was schief gehen kann. Schlimmstenfalls ignorieren sie das drohende Unwetter. An dieser Diagnose gemessen klingen innovative Konzepte zur Risikomanagement-Praxis wie ein Griff nach den Sternen. Beispielsweise wird für das Risikomanagement eine „Vier-Augen-Strategie“ angeregt. Zum einen bearbeitet der Projektleiter die Risiken, zum anderen wacht eine zweite, neutrale Instanz - etwa das Project Office - über die Gefahrenlage. Ebenso „visionär“ klingt der (bereits in der Pharma-Industrie umgesetzte) Vorschlag, die Risikoanalyse beim Multiprojektmanagement als Faktor einzubeziehen. Idee ist hier, die Risiken aller Projekte eines Unternehmens und ihre Abhängigkeiten nach einheitlichem Standard zu ermitteln. Die Ergebnisse werden beispielsweise bei der Projektpriorisierung berücksichtigt. Anlagenbau,฀Pharma-฀und฀Automobilbranche฀ Pioniere Die Scheu vor dem Risikomanagement ist groß. Warum eigentlich? Risiken gehören zum Projekt wie der Regenschauer zum Frühlingswetter. Definitionsgemäß ist ein Projekt ein Aufbruch ins Ungewisse. Altgediente Projektleiter meinen, dass erst durch (erkannte) Risiken und (bewältigte) Probleme Projekte „erwachsen“ werden. Der Umgang mit der „Projektmasse Risiko“ müsste so selbstverständlich sein wie eine Budgetkalkulation und ein Netzplan. Die฀Finanzwirtschaft฀bereitet฀sich฀auf฀das฀Risikomanagement฀vor.฀Gesetzliche฀Vorgaben฀fordern฀Risikovorsorge. Foto: ฀Deutsche฀Bank Die฀Risiken฀an฀den฀„richtigen฀Stellen“฀suchen: ฀Die฀Entwicklung฀neuer฀Transporttechnologien฀wird฀auch฀durch฀politische฀ Eingriffe฀und฀öffentliche฀Dikussionen฀beeinflusst. Foto: ฀Siemens 8฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 9฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Branchen, deren Vorhaben seit jeher mit Unwägbarkeiten verbunden sind, sind denn auch beim Projekt-Risikomanagement am weitesten fortgeschritten. Anlagenbauer beispielsweise, die umweltrechtliche und technische Gesetze beachten müssen, haben ausgefeilte Checklisten für das Risikomanagement entwickelt. Die Lurgi AG, eine weltweit tätige Unternehmensgruppe für Verfahrenstechnik und Anlagenbau, steht im Ruf, Pionier auf diesem Gebiet zu sein. Ähnliches gilt für die Pharma-Branche mit ihren hohen Arznei-Zulassungshürden. Auch Automobilzulieferer, in deren Metier das Qualitätsmanagement eine große Rolle spielt, haben ein Risikomanagement-System für die Produktentwicklung erarbeitet. Gesetzgebung฀fordert฀Risikomanagement Neuerdings beginnen die Finanzdienstleister mit Trainings und organisatorischen Maßnahmen dem Risikomanagement Rechnung zu tragen. Bewegt sich also doch etwas im Risikomanagement? Hoffentlich! Neue gesetzliche Regelungen erfordern Risikomanagement. So nimmt der Gesetzgeber seit 1998 die Spitze von Aktiengesellschaften in die Pflicht (KonTraGes - „Gesetz zur Kontrolle und Transparenz“ im Unternehmensbereich). Er fordert unternehmensweite Risikovorsorge. Das Top-Management habe über Risiken zu wachen, die den Fortbestand des Unternehmens gefährden könnten. Ins Visier des geforderten Überwachungssystems könnten groß angelegte Projekte kommen, IT-Projekte beispielsweise, die regelmäßig mit fünfbis sechsstelligen Investitionen zu Buche schlagen. Hier kann ein Totalausfall schnell das finanzielle Unternehmensfundament untergraben. In der Schadensbilanz summieren sich zu den verpulverten Investitionen dann auch die Einbußen in der Wettbewerbsfähigkeit, die eben dieses Projekt sichern sollte. Diese gesetzliche Pflicht zur unternehmensweiten Risikovorsorge betrifft zunächst nur Aktiengesellschaften. Doch könnte sie Kreise ziehen. International tätige Banken unterliegen mittlerweile einem ähnlichen Reglement zur Gefahrenabwehr (Basel II). Dies strahlt auf die übrige Wirtschaft ab, früher oder später. So prognostizieren die Fachleute, die die GPM in zwei Studien befragt hat, dem Risikomanagement eine große Zukunft. Alles, was Projektmanager an Instrumenten und Prozeduren brauchen, sei bereitgestellt. Es müsse jetzt nur genutzt werden. Eine gründliche Risikoanalyse, die sich des vorhandenen Instrumentariums bedient, kann Projektgeber, Kunden und Projektteams unsanft auf den Boden der Tatsachen holen. Nicht ausgeschlossen ist die Einsicht, dass ein Projekt aufgrund der Analyse erst gar nicht gestartet wird. Wieder andere Projekte könnten einen anderen Zuschnitt erhalten, müssten neue Wege gehen und ein aufwändiges Frühwarnsystem für Gefahren aufbauen. Vor allem: Auftraggeber - plötzlich mit gründlichen Gefahrenanalysen konfrontiert - müssten sich mit dem Thema Risiko auseinander setzen. Was kann das Unternehmen schultern? Wo lässt es besser die Finger von riskanten Vorhaben? Wo ist die Schmerzgrenze? Ein Balanceakt. Wer jedes Risiko ausschließen will, muss sich vom Projektgeschäft zurückziehen. Von derlei grundsätzlichen Erwägungen sind viele Unternehmen noch weit entfernt. Die wirtschaftliche Lage zwingt sie, in gefährliche Vorhaben einzuwilligen - selbst dann, wenn Risikomanager eher abwinken würden. Dann ergibt sich die paradoxe Situation, dass Projektmanager womöglich auf Risiken hinweisen, doch im Top-Management kein Gehör finden. Instrumentarien฀für฀Risikomanagement฀„en฀detail“ Das vorliegende Instrumentarium umfasst die systematische Identifizierung von Risiken, die Bewertung, In฀der฀Risiko-Prioritätenmatrix฀werden฀die฀Projektrisiken฀hinsichtlich฀ihrer฀Eintrittswahrscheinlichkeit฀sowie฀hinsichtlich฀ ihrer฀Folgen฀für฀Ergebnisse,฀Termine฀und฀Kosten฀eingeordnet. ��������������� ������������������ ������� ������ ����������� ������ ������������������ ������������������ ������������������� ������������������ �������� ������ ������������������ ����������������� ������������������� ����������� �������������� ������������������ ������������� ���������������� ������������������� ����������������� ���������������� �������������������� Grafik: ฀Prof.฀Dr.฀Siegfried฀Seibert 8฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 9฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 das Erstellen eines Maßnahmenplans und das Berichtswesen. Allerdings gibt es nur wenig Systeme von Frühwarnindikatoren, die rechtzeitig darauf hinweisen, dass ein identifiziertes Risiko tatsächlich zur realistischen Gefahr geworden ist. „Hier gibt es in der Tat noch keine Möglichkeit, diese Frühindikatoren zu messen“, meint Unternehmensberater Stephan Kasperczyk (TIBA Managementberatung, München). Beispiel: Bei einem Reorganisationsprojekt wird die mögliche Gefahr erkannt, dass das Top-Management seine Zustimmung für das Projekt zurücknimmt. An welchen Kriterien lässt sich bereits zu einem frühen Zeitpunkt erkennen und „messen“, dass dieses Projekt wirklich gefährdet ist? Ist es bereits ein Warnsignal, wenn das Top-Management auf wichtigen Sitzungen fehlt? Oder braucht’s noch deutlichere Hinweise? „Hier sind Projektmanager letztlich wieder auf ihre Erfahrungswerte angewiesen“, sagt Stephan Kasperczyk. Trotz dieser Einschränkung bietet sich Projektmanagern ein effizienter Prozess für das Risikomanagement an. Im Kern folgt es vier Phasen: 1. Phase eins: Risiken erkennen, also systematisch alle Bereiche eines Projekts auf mögliche Probleme untersuchen und die Risiken auflisten. Projektteams sollten in den Startsitzungen der Risikoidentifizierung viel Zeit widmen, dabei nicht nur an Planung und technische Risiken denken, sondern auch beispielsweise an das Projektumfeld, an Marktrisiken, an Ressourcenengpässe, Know-how-Probleme, „konkurrierende“ Pro- Risikomanagement฀bedeutet฀auch,฀nach฀dem฀„Feuerwehrprinzip“฀die฀richtigen฀ Notfallpläne฀bereitzuhalten. Foto: ฀Nokia 10฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 11฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 jekte oder ans Projektmarketing. Unternehmen, deren Projekte vorwiegend einem Standard folgen, empfiehlt Kasperczyk Checklisten für die Bestandsaufnahme aller Risiken. Das „Risiko-Inventar“ könne dann in einer Datenbank abgelegt werden. Zahlreiche Beispiele, wie etwa in dem Fachbuch von Markus Gaulke (siehe dazu auch die Buchbesprechung in diesem Heft) können hier unterstützen. Doch der Einsatz von Checklisten, die Projektteams wie eine Karte durch die Risikolandschaft führen, findet in der Praxis Grenzen. Betreten Teams mit innovativen Projekten Neuland, bleibt ihnen nur der kreative Weg: Sie sondieren die Felder, auf denen Gefahren lauern können. Stephan Kasperczyk schlägt dafür das „ETHOS-System“ vor und benennt die Felder mit economical, technical, human, organization und social. „Das ‚human‘-Feld umfasst Risiken, die sich seitens der Stakeholder oder des Teams ergeben“, erläutert Kasperczyk, „mit ‚social‘ ist das weitere Projektumfeld, beispielsweise gesellschaftliche Gruppierungen, gemeint.“ Mit diesem ETHOS-System haben die Teams zumindest grobe Cluster an der Hand, um die Risiken zu erschließen. 2. Phase zwei: Risiken analysieren und das Gefahrenpotential bewerten. Hier hat sich eine Matrix bewährt, in der die Risiken zum einen nach der Wahrscheinlichkeit ihres Eintritts, zum anderen nach ihrer Auswirkung auf das Projekt bewertet werden. Die Gefahren lassen sich damit zuverlässig gewichten und priorisieren. Berater Kasperczyk hat gute Erfahrungen damit gemacht die Projektrisiken in Euro-Beträgen zu beziffern, um ihre Auswirkungen plastisch zu machen. „Sind mögliche Beträge im Gespräch, setzen sich die Beteiligten automatisch intensiver mit dem Thema auseinander.“ Noch aussagekräftiger werden die Analysen, wenn als dritter Faktor der zu erwartende Gewinn eingerechnet wird: Was kann ich verlieren, wenn aus dem befürchteten Risiko eine reale Gefahr wird? Was kann ich gewinnen, wenn ich verantwortungsbewusst dieses Risiko eingehe? 3. Phase drei: Vorsorgemaßnahmen treffen. Spätestens jetzt stehen viele Projektmanager vor der Quadratur des Kreises. Wer Risiken ganz vermeidet, verschenkt womöglich Chancen. „In vielen Fällen lassen sich Risiken beherrschen, indem Projektplanungen geändert werden“, weiß Stephan Kasperczyk. Solche Vorsorgemaßnahmen vermindern die Eintrittswahrscheinlichkeit und die Auswirkung auf das Projekt. Für andere Risiken bieten sich Notfallpläne an. Sie liegen bereit, wenn aus einem Risiko eine tatsächliche Gefahr erwachsen ist. Die verlockende Strategie, Risiken beispielsweise auf Zulieferer zu verlagern, schützt derzeit nur wenig. „In wirtschaftlich schwierigen Zeiten ist es womöglich sinnvoller, das Risiko selbst zu tragen, als es auf einen unsicheren Partner zu übertragen“, meint er. Durch die Pleitenwelle werden Zulieferer, die bislang Risiken getragen haben, selbst zur Gefahrenquelle. „Bei der Vorsorge läuft letztlich vieles auf eine Mischung zwischen Schutzimpfung und Notfallpläne hinaus“, fasst Kasperczyk zusammen. 4. Phase vier: Risiken ständig überwachen, Risikomanagement pflegen. Die besten Pläne nutzen wenig, wenn das Team die Risikolandschaft nicht ständig im Blick hält. Zumindest bei jedem Statusmeeting sollte das Thema auf der Tagesordnung stehen und auch die Statusberichte sollten regelmäßig Risikomeldungen beinhalten. „Hilfreich ist es, Mitarbeiter persönlich für die Risikoüberwachung verantwortlich zu machen und es zu honorieren, wenn sie Gefahren rechtzeitig aufdecken“, meint Kasperczyk. Entscheidend für das Risikomanagement: Es muss früh beginnen, nicht erst dann, wenn das Projekt gestartet wird. Bereits bei der ersten Projektidee sollten die Risiken zumindest grob aufgespürt werden. „Dafür braucht man natürlich Zeit und Budget“, räumt Kasperczyk ein. Ohnehin sei die Vorsorge nicht zum Nulltarif zu bekommen. Für wichtig hält er es, dass die Instrumente des Risikomanagements alltagstauglich sind. Aufwändigen Methoden, denen komplizierte Rechenmodelle zugrunde liegen, erteilt er in der Regel eine Absage. Bürokratie hemmt eher die Vorsorge und fördert kaum Risikobewusstsein. Risikomanagement muss machbar sein, betont er. 10฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 11฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Pharma-Branche: ฀Wertanalyse฀ optimiert฀Risikomanagement Oliver฀Steeger Risiko฀vorprogrammiert: ฀Von฀10.000฀potentiellen฀Wirksubstanzen฀kann฀die฀Pharma-Forschung฀am฀Ende฀nur฀eine฀Handvoll฀auf฀den฀Markt฀bringen.฀Der฀Rest฀scheitert฀in฀den฀ umfangreichen฀Labortests,฀Tierversuchen,฀klinischen฀Studien฀und฀Genehmigungsverfahren.฀ Ein฀zwar฀„natürliches“,฀nichts฀desto฀trotz฀jedoch฀gewaltiges฀Risiko,฀mit฀dem฀die฀Entwicklung฀neuer฀Medikamente฀behaftet฀ist.฀Für฀die฀Pharma-Branche฀gilt฀als฀wahrscheinlich,฀ dass฀solch฀ein฀Projekt฀während฀seiner฀zehn-฀bis฀zwölfjährigen฀Laufzeit฀eher฀auf฀der฀Strecke฀ bleibt,฀als฀dass฀es฀gelingt฀und฀das฀Medikament฀in฀die฀Apotheken฀kommt. D ie Entwicklungswelt der Pharma-Industrie gleicht einem Labyrinth - viele Sackgassen und nur wenige Wege zum Ziel. Selbst dann, wenn nach drei bis vier Jahren Forschungszeit neue Wirksubstanzen beim Menschen angewendet werden können, haben sie nur eine Chance von zehn bis zwanzig Prozent, den Markt zu erreichen und die Entwicklungskosten wieder einzuspielen. „Wenn Sie bedenken, dass die Entwicklung eines Medikaments 500 bis 800 Millionen Euro kosten kann, wägen Sie genau ab, in welchem Stadium Sie ein Projekt abbrechen oder welches Restrisiko Sie bei der Weiterführung akzeptieren können“, erklärt Dr. Sabine Bernotat-Danielowski, Leiterin der globalen Portfolioplanung bei Merck KGaA Pharma. Mit diesen Risiken umzugehen, das hat die Pharma- Industrie gelernt. Der Branche ist es nicht möglich, die technischen Risiken ihrer Projekte vollständig auszuschließen. Sie wägt ab, welche Risiken sie für welchen möglichen Gewinn in Kauf nimmt. Was lohnt es sich wirklich zu riskieren - diese Frage stellt sich im Pharma-Projektalltag fast täglich. Hier beschäftigen sich interne und externe Fachleute damit, technische Risiken und den künftigen Markterfolg abzuschätzen. Beides wägen die Unternehmen gegeneinander ab. Erst dann entscheiden sie, ob es mit einem Projekt weitergeht oder ob es mangels Erfolgsaussicht eingestellt wird. Risiko-Wertanalyse nennt sich diese Strategie, mit den Risiken umzugehen, eine Vorgehensweise, die sich auch für andere Branchen empfiehlt. Risiko-Wertanalyse: Hier verhalten sich die Pharma-Entwicklungsabteilungen ähnlich wie Versicherungsgesellschaften. Sie versuchen Risiken so präzise wie möglich zu beziffern und in Wahrscheinlichkeiten zu rechnen. Komplizierte Rechenmodelle liegen dem zugrunde. Die Entwickler bauen Szenarien auf, spielen von Meilenstein zu Meilenstein Was-wäre-wenn-Modelle durch und kommen zu bemerkenswert sicheren Ergebnissen. „In der Tat sind wir so weit, dass wir nicht nur die Erfolgswahrscheinlichkeit der Zwischenschritte unserer Projekte, sondern auch die Wahrscheinlichkeit des endgültigen Produkterfolges relativ gut abschätzen kön- „Technisches฀Risiko“: ฀Von฀10.000฀potentiellen฀Wirksubstanzen฀kann฀die฀Pharma- Forschung฀am฀Ende฀nur฀eine฀Handvoll฀auf฀den฀Markt฀bringen.฀Risikoanalysen฀ helfen,฀die฀Erfolgswahrscheinlichkeit฀einzelner฀Projekte฀abzuschätzen. Foto: ฀Aventis 12฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 13฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Die฀Pharma-Industrie฀hat฀ihr฀Risikomanagement฀weit฀entwickelt. Foto: ฀Aventis nen“, meint Bernotat-Danielowski. Eine Erfolgswahrscheinlichkeit beispielsweise von 72 Prozent garantiere natürlich nicht den Erfolg. Die Information helfe aber, mit Risiken aktiv umzugehen. „Und darauf kommt es uns an“, meint die Portfolioplanerin. Sie will wissen, welche Gefahren ihren Projekten drohen, um die richtigen Entscheidungen zu treffen und die richtigen Maßnahmen einzuleiten. „Im Prinzip setzt diese Analyse an jedem Meilenstein und zu Beginn jeder Entwicklungsphase neu ein“, erläutert Bernotat-Danielowski. Wie groß ist beispielsweise das Risiko, dass das neue Medikament die erste Anwendung am Menschen nicht besteht? Rechtfertigt der anzunehmende Gewinn das Risiko der Investition - oder sollte das Projekt an diesem Punkt abgebrochen werden? Oder welche Schritte können helfen, den Entwicklungen einen günstigeren Verlauf zu geben? Vorteile aus der Risiko-Wertanalyse zieht nicht nur die Unternehmensleitung, sondern auch der Projektmanager. Er ist auf der sicheren Seite, wie Dr. Sabine Dr.฀Sabine฀Bernotat-Danielowski,฀Globale฀Leiterin฀der฀ Portfolioplanung฀bei฀Merck฀KGaA฀Pharma: ฀„Wenn฀Sie฀bedenken,฀dass฀die฀Entwicklung฀eines฀Medikaments฀500฀bis฀ 800฀Millionen฀Euro฀kosten฀kann,฀wägen฀Sie฀genau฀ab,฀in฀ welchem฀Stadium฀Sie฀ein฀Projekt฀abbrechen฀oder฀welches฀ Restrisiko฀Sie฀bei฀der฀Weiterführung฀akzeptieren฀können.“ Foto: ฀privat 12฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 13฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Bernotat-Danielowski betont. Forciert das Unternehmen ein Projekt trotz bekannter Risiken, kann sich der Projektleiter bei Problemen oder Fehlschlägen auf die (bekannten) Daten berufen. „Risiko-Wertanalyse bringt enorme Transparenz ins Projekt und ins Projekt-Portfolio eines Unternehmens“, hat Dr. Sabine Bernotat- Danielowski festgestellt. Zugleich betont sie, dass eben diese Transparenz nicht automatisch „jedem gefällt“ - und auch den Projektmanagern zusätzliche Aufgaben aufbürdet. So ist das Risikomanagement in der Pharma-Industrie mehr als nur ein Projektmanagement-Baustein. Mitunter scheint es die Dominante im Projektmanagement-Prozess zu sein; zumindest drückt es ihm einen deutlichen Stempel auf. „Wir fragen uns nicht nur, wie wir vorgehen können, um ein neues Medikament zu entwickeln“, erklärt die Expertin, „uns stellt sich immer wieder die Frage, was wir dabei gewinnen - und verlieren können.“ Solche Analysen helfen auch beim Portfoliomanagement, dann beispielsweise, wenn es Projekte zu priorisieren gilt. Die฀Risikoanalyse฀setzt฀im฀Prinzip฀an฀jedem฀Meilenstein฀ und฀zu฀Beginn฀jeder฀Entwicklungsphase฀neu฀ein.฀Wie฀groß฀ ist฀beispielsweise฀das฀Risiko,฀dass฀das฀neue฀Medikament฀ die฀erste฀Anwendung฀am฀Menschen฀nicht฀besteht? ฀Oder฀ nicht฀in฀Produktion฀gehen฀kann? Foto: ฀Aventis 14฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 15฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 E s gab Zeiten, da federten satte Margen aus dem Hardware-Geschäft die Schlappen der IT-Projekte ab. Doch die Zeiten sind vorbei. Misslingen heute IT-Projekte, schlägt dies ungeschmälert auf die Geschäftsbilanzen durch. Die Fehlschläge kosten Dienstleister und Kunden nicht nur Investitionen, sonder eben auch jene Wettbewerbsvorteile, die mit dem Projekt erzielt werden sollten. Ein wichtiger Grund für die Misserfolge liegt im mangelhaften Risikomanagement. Viele Projekte wären günstiger verlaufen oder erst gar nicht gestartet worden, hätten sich die Unternehmen über die Gefahren ihres Vorhabens informiert. Während sich viele Großunternehmen auf das Risikomanagement vorbereitet haben, arbeiten kleine Dienstleister und Mittelständler nach wie vor auf gut Glück. Wie lange das so noch gut geht, das können selbst Branchenkenner nicht abschätzen. Der Druck nehme zu - und auch die Angst. „Das Risikomanagement wird sich in den nächsten fünf Jahren zu einem immer wichtigeren Thema für IT- Projekte entwickeln“, prognostiziert Markus Gaulke, Risikomanagement-Experte im Bereich Information- Risk-Management bei KPMG. Ein neues Thema sei es allerdings nicht. „Viele in der IT-Branche üblichen Industriestandards wie das Reifegradmodell oder die ISO-Normen beinhalten Risikomanagement-Aspekte“, hat er festgestellt. Markus Gaulke hat sechs Gefahrenfelder für IT-Projekte aufgelistet: 1. Der „Business-Fokus“: Gefahr droht, wenn das IT- Projekt nicht auf die geschäftliche Gesamtstrategie des Unternehmens ausgerichtet ist und das Top- Management das Projekt zu wenig unterstützt. 2. Projektmanagement: Drohen Risiken beispielsweise bei Terminplanung oder Ressourcen? 3. Geschäftsprozesse: Ins Schleudern kommen Projekte, wenn die Anforderungen an die Projektlösung unzureichend spezifiziert sind. Bildet die Lösung detailliert genug die zukünftigen Geschäftsprozesse ab? Risikomanagement: Sechs฀„Gefahrenfelder“฀ in฀IT-Projekten Oliver฀Steeger Eine฀enorme฀Belastung฀für฀Geschäftsbilanzen฀und฀Image฀in฀der฀IT-Branche: ฀Fast฀jedes฀ dritte฀IT-Projekt,฀so฀berichtet฀der฀CHAOS-Report฀der฀Standish-Group,฀scheitert.฀Bei฀mehr฀ als฀der฀Hälfte฀der฀Vorhaben฀werden฀die฀ursprünglichen฀Kostenschätzungen฀um฀nahezu฀200฀ Prozent฀überschritten.฀16฀Prozent฀der฀untersuchten฀Projekte฀hielten฀Termin฀und฀Kosten฀ein฀ und฀realisierten฀auch฀die฀ursprünglich฀geplanten฀Funktionen.฀ „Die฀Zahlen฀spiegeln฀erschreckend฀die฀Praxis฀in฀der฀IT-Branche฀wider“,฀verrät฀ein฀leitender฀ Projektmanager฀eines฀bundesdeutschen฀IT-Spezialisten฀im฀vertraulichen฀Gespräch,฀„das฀ sind฀nicht฀nur฀nackte฀Fakten.฀Dahinter฀steht฀Leidensdruck.“฀Risikomanagement,฀hält฀Experte฀Markus฀Gaulke฀entgegen,฀könnte฀die฀Not฀im฀IT-Projektmanagement฀deutlich฀lindern. Markus฀Gaulke,฀Risikomanagement-Experte฀im฀Bereich฀Information-Risk-Management฀bei฀KPMG: ฀„Viele฀in฀der฀IT-Branche üblichen฀Industriestandards฀wie฀das฀Reifegradmodell฀oder฀ ISO-Normen฀beinhalten฀Risikomanagementaspekte.“ Foto: ฀privat 14฀฀ REPORT P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 15฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 4. Anwender: Wie lässt sich das Risiko verringern, dass die künftigen Anwender die Software nicht akzeptieren oder nicht mit ihr arbeiten können? 5. Technologie: Jede neue Technologie - Hardware, Software oder Entwicklungswerkzeuge - stellt unvermeidlich Risiken dar. Projekte scheitern oftmals an neuen IT-Systemen, die sich nur mit Problemen in die bestehende IT-Landschaft fügen. 6. Datenmigration: Die Übernahme bestehender Daten in das neue System gilt in der IT-Branche als Achillesferse. Rund die Hälfte aller Datawarehouse-Projekte, schätzt Gaulke, scheitert an der Datenqualität. Markus Gaulke empfiehlt, beim Risikomanagement strukturiert vorzugehen und systematisch die „wunden Punkte“ eines Projekts zu überprüfen. Die Risikobetrachtung sollte regelmäßig erfolgen, möglichst von Meilenstein zu Meilenstein. Hier können Checklisten helfen, die Risiken vollständig aufzuspüren. „Diese Checklisten müssen aber auf das Unternehmen zugeschnitten sein“, betont Markus Gaulke. Beispiel Risiko „Projektkomplexität“: Was Projektleiter kleiner Unternehmen als gefährlich komplex einstufen müssen, kann bei Kollegen aus größeren Unternehmen nur ein geringes Risiko darstellen. „Bei der Analyse und Bewertung der Risiken leisten Erfahrungen aus vergangenen Projekten große Hilfe“, fügt Markus Gaulke an. So müssen diese Erfahrungen immer wieder in die Checklisten einfließen. „Im günstigsten Fall wertet ein Project Office oder eine Stabsstelle die Erfahrungen aus und legt das Fundament für eine einheitliche Vorgehensweise beim Risikomanagement“, meint er. Literatur [1]฀Gaulke,฀Markus: ฀Risikomanagement฀in฀IT-Projekten.฀ Oldenbourg฀Wissenschaftsverlag,฀München฀2002 16฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 17฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Neuorientierung฀oder฀ Glasperlenspiel? Kritik฀der฀systemtheoretischen฀Ansätze฀im฀Projektmanagement Günter฀Drews Diese฀Abhandlung฀setzt฀sich฀kritisch฀mit฀dem฀im฀Arbeitskreis฀„Neuorientierung฀im฀Projektmanagement”฀der฀GPM฀eingeschlagenen฀Weg฀auseinander,฀eine฀Projektmanagementtheorie฀und฀-praxis฀auf฀systemtheoretischer฀Grundlage฀zu฀entwerfen.฀Sie฀kritisiert฀eine฀systemische฀Verengung฀des฀theoretischen฀Bezugsrahmens,฀der฀andere฀fruchtbare,฀in฀der฀Praxis฀ bewährte฀Ansätze฀wie฀interpretative฀und฀handlungsorientierte฀Theorien฀aus฀dem฀Blick฀ verliert.฀Begrenzter฀neuer฀Erkenntnisgewinn฀und฀Fehlentwicklungen฀der฀„Neuen฀Wege฀im฀ Projektmanagement”฀werden฀an฀den฀Beispielen฀Zielbildungsprozess฀und฀Projektabschluss฀ analysiert. Der฀zweite฀Teil฀(in฀Heft฀3/ 2003)฀beschreibt฀die฀Grundzüge฀eines฀handlungsorientierten฀Projektmanagements฀auf฀Basis฀der฀Theorie฀der฀Strukturierung฀von฀Giddens.฀Mit฀der฀„Theory฀of฀ Constraints“฀von฀Goldratt฀und฀dem฀„Accelerated฀Solution฀Environment™฀„von฀Cap฀Gemini฀ Ernst฀&฀Young฀werden฀beispielhaft฀in฀der฀Praxis฀bewährte฀Vorgehensweisen฀dargestellt,฀die฀ belegen,฀wie฀fruchtbar฀interpretative฀Ansätze฀für฀eine฀Projektmanagementpraxis฀nutzbar฀ gemacht฀werden฀können. 1฀ Einführung Etwa ab dem Jahre 1986 beschäftigte sich der Arbeitskreis „Neuorientierung im Projektmanagement“ der GPM eingehend mit einer Standortbestimmung der aktuellen Projektmanagementtheorie und -praxis (Ausgangspunkt war eine vermutete „Krise des Projektmanagements“, die jedoch nur vage expliziert wurde - „unterschiedlichen Facetten des ,Unbehagens‘“ [1, S. 1]). Das Gefühl der Unzulänglichkeit der damalig aktuellen Projektmanagementpraxis speiste sich einerseits aus den westlichen betriebswirtschaftlichen Produktivitäts- und Qualitätsinitiativen, angefangen  mit dem Total-Quality-Management-Ansatz von Deming W. Edwards (1982),  den von Saynisch [3, S. 30] zitierten Autoren Piore und Sabel mit der Veröffentlichung „The Second Industrial Divide“ (1984),  der „Theory of Constraints“ von Eliyahu M. Goldratt (1984) und weitergeführt mit  dem Lean-Management-Ansatz von James P. Womack (1990) „The Machine That Changed The World“ sowie  dem „Business Process Reengineering“ von Michael Hammer (1993). Andererseits zeigte ein Blick auf die sozialwissenschaftliche Theoriebildung, dass zunehmend systemtheoretische Denkmodelle aus der Biologie der lebenden Organismen in die Sozialwissenschaften übertragen wurden und dort in verschiedenen Facetten zum sozialwissenschaftlichen Mainstream avancierten. Das Unbehagen manifestierte sich darin, dass sich aus den betriebswirtschaftlichen Ansätzen eine gesteigerte Bedeutung des Projektmanagements ableiten ließ, die Theorie und Praxis des Projektmanagements aber weder die Produktivitäts- und Qualitätsinitiativen reflektierten noch über eine adäquate Theorie für diese neuen Herausforderungen verfügten. Die Neuorientierung war noch als pluralistischer Ansatz vorgesehen: „Eine wie auch immer erneuerte Methodenlandschaft des Projektmanagements wird nicht als monolithische Lehre gedacht. Angestrebt wird vielmehr ein offenes Netzwerk von Konzepten und Regeln, in dem sich auch Gegensätzliches vereinigen lässt und in dem die Freiheit für fruchtbare Begegnungen offen gehalten wird.“ [1, S. 2] Allerdings zeigte sich mindestens in den darauf folgenden Veröffentlichungen, dass der Arbeitskreis weitgehend systemtheoretischen Ansätzen folgt und Pluralismus nur noch innerhalb der Facetten der Systemtheorie gepflegt wird. Im Dokumentationsband des Deutschen Projektmanagementforums 1997 werden ausschließlich Spielarten der Systemtheorie als theoretische Basis für Projektmanagement diskutiert [4, S. 3-6-3.3-3], so  die Theorie sozialer Systeme nach Luhmann und Wilke,  die konstruktivistische Sozialtheorie, hier nur nach der sozialkybernetischen Variante von Hejl,  die Theorie der lebenden Organisation von Maturana und  Sozialkybernetik (Kybernetik IV). 16฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 17฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Eine ähnliche Ausrichtung findet sich auch im Sammelband „Networking und Projektorientierung“ [2], der im Wesentlichen Beiträge derselben Autoren des Dokumentationsbandes enthält. Die Adoption der „System Dynamics“ als derzeit neueste Variante der „Neuorientierung im Projektmanagement“ liegt auf derselben Linie [5]. Darüber hinaus wirkt dieser Ansatz anscheinend „schulbildend“, da sich zunehmend Autoren, die sich mit Aspekten des Projektmanagements beschäftigen, auf ein systemtheoretisches Fundament beziehen [6, 7, 8]. Ich halte die Fokussierung auf systemtheoretische Ansätze für eine bedenkliche Verengung. Die Bedenken stützen sich zum einen darauf, dass ein großes Spektrum der soziologischen und betriebswirtschaftlichen Modelle mit ihren fruchtbaren Erkenntnissen nicht für das Projektmanagement nutzbar gemacht wird, und zum anderen darauf, dass die Übertragung der Modellbildung lebender Systeme auf soziale Tatbestände in der Literatur nicht kritiklos akzeptiert wird und für die Praxis erhebliche Schwächen birgt.  Betrachtet man die aktuellen Paradigmen sozialwissenschaftlicher Theoriebildung [9, S. 15 ff.], so wird deutlich, auf welchem eingeschränkten Erkenntnisausschnitt man sich bewegt. Das breite Spektrum der akteur-orientierten Ansätze, die verstehenden Vorgehensweisen und die kritischen Ansätze bleiben unberücksichtigt.  Schon 1971 wies Jürgen Habermas in seiner berühmten Auseinandersetzung mit Niklas Luhmann auf die Probleme hin, die sich bei der Übertragung des Systemparadigmas auf gesellschaftliche Problemstellungen ergeben, insbesondere bei der Definition von Systemgrenzen, Sollzuständen und bestandsrelevanten Strukturen [10].  Noch bedenkenswerter: Selbst Humberto R. Maturana, der den Begriff der Autopoiesis [11, S. 29] als Kennzeichen lebender Systeme geprägt hat, hält die Übertragung dieses Begriffs auf soziale Systeme nicht für legitim [12]. Neben dieser Tatsache, dass von einem wissenschaftlichen Konsens darüber, ob es gerechtfertigt sei, das Modell lebender Systeme auf soziale Systeme zu übertragen, nicht die Rede sein kann, interessieren mich hier die praktischen Auswirkungen dieser Vorgehensweise. Diese sind im Wesentlichen:  Begrenzter, neuer Erkenntnisgewinn: Meist wird Altbekanntes in einem neuen Jargon wiederholt.  Konservative Grundhaltung: Die Theorie der Selbstorganisation führt in der Praxis meist dazu, dass die Beteiligten auf altbekannte Lösungsmuster zurückgreifen. Verstärkt wird dies noch durch das Credo, das System mit „Respekt“ zu behandeln. Diese konservative Grundhaltung muss dann versagen, wenn es nicht genügt, mit einem Projekt graduelle Verbesserungen zu erzielen, sondern Break-through-Lösungen gefordert sind.  Vernachlässigung der Einflussmöglichkeiten der Handelnden im Projekt: Die Systeme werden für den Einzelnen als zu komplex für sein Verständnis betrachtet. Der Einzelne ist Gesetzmäßigkeiten des Systems unterworfen, die sich hinter seinem Rücken durchsetzen.  Außensicht vor handelnder Teilnahme: Insbesondere in der Variante der System Dynamics nehmen die Verantwortlichen die Rolle des „objektiven“ Betrachters des Systems ein, der durch Modellierung von außen hinter die Gesetzmäßigkeiten des Systems kommt. Das Verständnis für ein Projekt, für Produkte, von Abläufen und der Motive der Handelnden erschließt sich jedoch erst durch aktive Teilhabe von innen.  Prozess vor Inhalt: Der Schwerpunkt verlagert sich auf den Prozess. Projektmanagement wird zum Prozessmanagement. Unabhängig vom Projektinhalt kann jeder alles managen, wenn er nur den Prozess beherrscht.  Weg vor Ziel: Die weitgehende Offenheit der Definition der Ziele führt zur Beliebigkeit in der Projektdefinition mit all den Folgeproblemen, wie z. B. zu bestimmen, wann ein Leistungsumfang erbracht und damit ein Projekt beendet ist.  Selbsterhaltung gegen termingerechtes Ende: Bestandserhaltung des Systems ist ein zentrales Anliegen der Systemtheorie. Projekte müssen aber auf Zeit angelegt sein und kontrolliert beendet werden. Im Folgenden möchte ich  beispielhaft diese Auswirkungen anhand einer Auseinandersetzung mit Veröffentlichungen aus dem Umfeld des Arbeitskreises „Neue Wege im Projektmanagement“ aufzeigen und  die Begrenztheit der Übertragung des Ansatzes lebender Systeme für das Projektmanagement zur Diskussion stellen. 2฀ Systemische฀Verkürzung 2.1฀ Begrenzter฀neuer฀Erkenntnisgewinn Betrachtet man die theoretische Hochrüstung der verschiedenen Varianten der Systemtheorie, so fällt auf, dass die praktischen Erkenntnisse daraus eher mager sind und mit weniger Aufwand an „Glasperlen“ 1 auch mit praktischem, gesundem Projektmanagerverstand hätten erreicht werden können. Auf diesen Umstand verweist auch Kieser [13, S. 199 ff.], der in seiner Auseinandersetzung mit dem St. Gallener Ansatz des evolutionären Managements zeigt, dass diese Konzepte und Methoden zu keiner prinzipiell anderen Vorgehensweise führen als konventionelle Ansätze. Der systemische Ansatz der St. Gallener Schule geht vom „Grundmodell des frei lebenden Organismus“ [14, S. 117] aus, überträgt dieses Paradigma auf soziale Systeme und leitet daraus Verhaltensmaßnahmen, Regeln für das Management und im speziellen Falle für das Projektmanagement ab. 1 „Glasperlen“ verweist auf den Roman von Hermann Hesse: Das Glasperlenspiel. Dieses Spiel ist eine hochartifizielle Kunst, gesellschaftlich hoch geachtet und auf keinerlei praktische Verwertbarkeit ausgerichtet. „Diese Regeln, die Zeichensprache, die Grammatik des Spieles, stellen eine Art von hochentwickelter Gemeinsprache dar, an welchen mehrere Wissenschaften und Künste, namentlich aber die Mathematik und die Musik (beziehungsweise die Musikwissenschaft) teilhaben und welche die Inhalte und Ergebnisse nahezu aller Wissenschaften auszudrücken und zueinander in Beziehung zu setzen imstande ist.“ 18฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 19฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Komplexe Systeme in diesem Sinne haben folgende Eigenschaften:  Man weiß über ein solches System nicht alles, was man wissen müsste, um es planmäßig zu steuern.  Sie stehen nur bedingt unter der Kontrolle von Führungsinstanzen, und es ist unwahrscheinlich, dass sich die Absicht eines Einzelnen durchsetzt.  Sie sind selbst organisierend und selbst regulierend.  Anpassungsvorgänge müssen ständig korrigiert werden.  Die jeweilig erreichten Zustände sind immer nur vorübergehender Natur. Daraus folgt für das Management, dass nicht das Detail vorgegeben wird, sondern der Schwerpunkt auf der Schaffung der richtigen Rahmenbedingungen liegt, damit sich die Eigendynamik des Systems entfalten kann [15, S. 145]. Im Detail bedeutet das die Vermeidung von detaillierten Regeln und Prozeduren, die Schaffung autonomer Subsysteme, das Zulassen von Konflikten und Fluktuationen, Raum bieten für Selbstorganisation, Schaffung von Freiräumen, sich mit neuen Fragen auseinander zu setzen [13, S. 201]. Anhand eines hypothetisch angenommenen Organisationsbeispiels vergleicht Kieser die Lösung der konventionellen Organisationsgestalter mit den Lösungsansätzen der St. Gallener Schule und kommt zu dem Schluss, dass die Anwendung der Konzepte und Methoden des evolutionären Managements nicht zu grundsätzlich anderem Vorgehen und zu anderen Lösungen führt als die Anwendung konventioneller Methoden. Den Hauptgrund sieht er (neben der grundsätzlichen Kritik an der Theorie der Selbstorganisation und der Übertragung auf Bedingungen der formalen Organisation) darin, dass das evolutionäre Management keine inhaltlichen Vorgaben macht, sondern lediglich Regeln zu den Prozessen gibt. So besteht die Gefahr, dass das übernommen wird, was immer schon gemacht wurde, und bestehende Lösungsmuster nicht wirksam überwunden werden. Was Kieser für den Bereich der Organisation diskutiert und kritisiert, kann für den Bereich des Projektmanagements demonstriert werden am Beispiel Petersen/ Witschi [16, S. 25 ff.]. Die Abstinenz von inhaltlichen Aspekten verkürzt Projektmanagement auf die Verwaltung von Prozessen und Regeln (ein Aspekt der systemischen Problemverkürzung):  Organisatorische Maßnahmen unterscheiden sich nur marginal von konventionellen Methoden.  Diese konventionellen Methoden bekommen mit systemischem Vokabular ein modernes Styling. Ihren Aufsatz „Komplexes Projektmanagement“ verstehen Petersen und Witschi explizit als praktischen Beitrag zur systemischen Theorie des Projektmanagements. Auffallend ist, dass man erst am Schluss des Artikels (in Tabelle 5) erfährt, um welche Aufgabenstellung es sich bei den beschriebenen Projekten handelt: im ersten Fall um die Transformation einer funktionalen Organisation in eine prozessorientierte Organisation und im zweiten Fall um die Umwandlung einer bestehenden Organisation (welcher? ) in eine prozessorientierte Matrixorganisation. Abgesehen davon, dass dies nun seit dem Beginn der Bewegung des Business Process Reengineering keine neue und inhaltlich offene Fragestellung mehr ist, erfährt man lediglich, dass es beim zweiten Projekt um „kürzere Durchlaufzeiten, mehr Flexibilität, bessere Kundenorientierung“ geht, und lapidar wird bemerkt, dass die Projekte nach 1,5 Jahren erfolgreich beendet wurden. Was Erfolg für wen ist und was eine Prozessorientierung dazu beitragen kann, die Ziele zu erreichen, wird nicht diskutiert. Versuchen die Autoren im einleitenden Kapitel noch eine Synthese zu bilden zwischen Inhalten und Prozess, harten Zielen und weichen Zielen, klassischem ergebnisorientiertem Projektmanagement und einem prozessualen Organisationsentwicklungsansatz, so beschäftigen sie sich im Laufe des Artikels ausschließlich mit dem Prozess und legen in der abschließenden Zusammenfassung eindeutig den Schwerpunkt auf den Prozess. „Das große Gewicht liegt hier auf der Aufgleisung und Organisation, auf der Orientierung und Vereinbarung, auf der Öffentlichkeitsarbeit und breiter Mobilisierung, also auf der Prozessgestaltung …“ [16, S. 30]. Diese Abstraktion von Inhalten und Zielen und die Operation mit den Begriffen Selbstorganisation, Evolution und Vernetzung sind selbst für Malik ein Grund, Kritik anzusetzen: „Ich kann mich aber des Eindrucks nicht erwehren, dass viele über die ständige Verwendung dieser Wörter hinaus nichts Wesentliches an Substanz beitragen. Es bringt naturgemäß nicht sehr viel, Selbstorganisation und Evolution ständig zu fordern, dann aber die Antwort auf die Frage schuldig zu bleiben, was sich eigentlich wie selbst organisiert, was dann wirklich evolviert und in welche Richtung dies geschieht“[15, S. 148]. Projektmanagement in diesem Sinne erscheint als Papiertiger. Alles Wichtige ist bereits vorgegeben, die Teilnehmer dürfen selbst organisieren, was das Management entschieden hat. Und was bringt diese Selbstorganisation Neues? In den Rollen, Aufgaben und Kompetenzen der Organe der Projekte absolut nichts, was nicht auch in einer traditionellen Projektorganisation so aufgeschrieben worden wäre [16, S. 27, Tabelle 2]. Interessant ist der Ansatz, die Nominierung der Teammitglieder und die Rollenverteilung im Team durch einen quasi demokratischen Abstimmungsprozess zu implementieren. Aber auch dies ist, unabhängig von der Projektmethodik, sogar in straff hierarchisch orientierten Organisationsstrukturen möglich. Bereits in den frühen sechziger Jahren wurde in einer Reihe von Untersuchungen die Überlegenheit des Urteils der Teammitglieder bezüglich der Eignung für bestimmte Rollen (z. B. Führungseigenschaften) gegenüber sonstigen Auswahlverfahren (wie psychologischen Tests) nachgewiesen [17, S. 151 ff.]. Gruppendynamisch ist dies also eine alte Erkenntnis, die im betrieblichen Alltag leider nicht weit genug verbreitet ist. Insofern ist es zu begrüßen, dass die Autoren diesen Ansatz wieder ins Gespräch bringen. Er kann jedoch unabhängig von der gewählten Projektphilosophie und -vorgehensweise eingesetzt werden. 2.2฀ Aufweichung฀der฀Verantwortlichkeiten฀durch฀ Flexibilität฀der฀Zielbildung Mogeln sich Petersen/ Witschi noch um das Problem der Zielbildung herum, ist diese Problematik das Haupt- 18฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 19฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 thema der Abhandlung von Hauschildt/ Pulczynski [18, 195 ff.] bei der Beschreibung des Scheiterns (? ) im Projekt GROWIAN (Große Windenergie-Anlage). Ziel der Abhandlung ist es nachzuweisen, dass bei Innovationsprojekten eine zu rigide Zielbildung dysfunktional ist, im Gegensatz zur Bedeutung der Zielbildung bei traditionellen Projektmanagementansätzen, bei denen eine vollständige, detaillierte Zielfindung mit quantifizierbaren und messbaren Größen erfolgsentscheidend ist [19]. GROWIAN war ein Forschungsprojekt, das den Nachweis der Möglichkeit einer großtechnischen Gewinnung von Energie aus Windkraft erbringen sollte. Das Zielsystem enthielt Leistungs-, Zeit-, und Kostenziele. Die Anlage wurde 1987 in Betrieb genommen und ein Jahr später wieder abgerissen. Die Leistungsspezifikation wurde erfüllt, die Betriebsdauer betrug anstatt der geplanten drei Jahre nur 17,5 Tage, die geplante Projektlaufzeit von 32 Monaten wurde um 20 Monate überschritten, die budgetierten Kosten um 33 %. Ursache dieser beachtlichen Abweichungen von der Planung waren technische Probleme mit den Materialien der Rotorblätter, die anstatt mit den geplanten, von den beteiligten Wissenschaftlern empfohlenen und als weitgehend technisch machbar beurteilten Composite- Materialien mit einer wesentlich schwereren Stahlkonstruktion ausgeführt werden mussten, was eine ganze Reihe kosten- und zeitintensiver Folgeprobleme nach sich zog, da die Geld gebenden politischen Regierungsstellen auf der Einhaltung einer öffentlichkeitswirksam festgelegten Höhe (höher als der Kölner Dom, höchste Windkraftanlage der Welt) kompromisslos bestanden. Die Autoren versuchen nun den Nachweis zu führen, dass das Scheitern nur oberflächlich ein technisches Problem war, sondern dass es vielmehr auf eine zu rigide Zieldefinition der Höhe durch die Politik zurückzuführen ist. Ich halte diese Darstellung für nicht geeignet, quantifizierbare Zieldefinitionen in Frage zu stellen (auch für Innovationsprojekte). Hier verschwindet die Verantwortung von konkreten Projektbeteiligten für ein Scheitern hinter abstrakten Zieldefinitionen. Nicht der Wissenschaftler mit seinem faktisch unberechtigten Enthusiasmus für eine innovative Bauweise ist verantwortlich, sondern das System, das halt keine genauen Zieldefinitionen verträgt, sondern dynamisch seine Ziele anpassen muss. Die beteiligten Politiker und privaten Unternehmen haben sich „rational“ gemäß ihrem Bereich verhalten (Machterhaltung durch Öffentlichkeitswirksamkeit in der Politik und Gewinnorientierung der beteiligten Privatunternehmen). Dem Wissenschaftsbereich sind die Kriterien der Wahrheit, Richtigkeit und Wahrhaftigkeit [20] zuzuordnen. Offensichtlich haben sich die Wissenschaftler hier mehr als Verkäufer denn als Wissenschaftler betätigt, ohne in diesem Bereichstausch bzw. Rollentausch von den anderen Gruppen wahrgenommen zu werden. 2.3฀ Projektabschluss Die „neuen Wege“ im Projektmanagement orientieren sich weitgehend an einem Systembegriff, der in enger Nähe zu den biologischen Systemen, den Körpern biologischer Organismen, anzusiedeln ist. Die Weiterentwicklung und Übertragung dieses Ansatzes auf soziale Systeme wurden, wie bereits erwähnt, in unterschiedlichen Bereichen von namhaften Autoren kritisiert: von Jürgen Habermas aus ideologiekritischer/ philosophischer Sicht, von Anthony Giddens hinsichtlich der Anwendbarkeit auf eine Gesellschaftstheorie [21], von Alfred Kieser in Bezug auf die Organisationstheorie. Ich halte die Übertragung auf Theorie und Praxis des Projektmanagements für ebenso problematisch. Projekte sind nicht etwas in der Wirklichkeit Vorgefundenes, sondern werden definiert in Übereinkunft mit den Projektbeteiligten. Was als Projekt bezeichnet und 20฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 21฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 behandelt wird, welche Aufgabenstellung es zu erfüllen hat, was dazugehört und was nicht, wann es als beendet erklärt wird oder nicht, ist Ergebnis rationaler Entscheidungen. Der Sinn einer spezifischen Projektdefinition erschließt sich erst, wenn man sich ein weit reichendes Verständnis des Umfeldes erarbeitet hat. Deshalb ist es für viele Unternehmen nicht trivial festzulegen, welche Aufgabenstellungen und Handlungen als Projekt definiert werden und welche nicht. Das hängt manchmal von solch profanen Tatsachen wie der Provisionierung von Vertriebsbeauftragten ab. Auch ist die Frage nach der Identität eines Projektes nicht unbedingt trivial zu beantworten. Ist das Projekt noch dasselbe Projekt, wenn zwar dieselbe Aufgabenstellung verfolgt wird, aber die Teammitglieder ausgetauscht wurden oder wenn man dieselben Teammitglieder hat, aber die Aufgabenstellung hat sich geändert oder andere zentrale Projektelemente wie Vorgehensweise etc. Besonders problematisch ist das Beenden eines Projektes. Ein zentrales Thema der Systemtheorie sind die Bedingungen der Bestandserhaltung eines Systems, sei es in der klassischen Version, die das „Letztproblem als Problem des Bestandes oder der Stabilität des Systems“ definiert, oder in der von Luhmann differenzierteren Form: „Erhaltung ist hier Erhaltung der Geschlossenheit und der Unaufhörlichkeit der Reproduktion von Elementen, die im Entstehen schon wieder verschwinden“ [22, S. 80]. „Bestandserhaltung“ oder „Unaufhörlichkeit der Reproduktion“ ist genau das nicht, was das Projektmanagement als Ziel erreichen muss, sondern ein kontrolliertes Beenden. Ist es schon nicht so einfach, ein Projekt professionell zu starten [6, S. 23 ff.], so ist es noch viel schwieriger, ein Projekt kontrolliert zu Ende zu bringen. Man betrachte nur die Schwierigkeiten, die Manager haben, zu definieren, wann ein Projekt beendet ist. Die Umfrage unter 164 Managern aus 62 Firmen bezüglich der Einführung und Optimierung von ERP-Systemen, deren Ergebnisse in Abb. 1 dargestellt sind, wurde von Deloitte Consulting auf der SAP- PHIRE ’99 in Nizza präsentiert. Eine Frage richtete sich danach, wann ein ERP-Projekt beendet sei. 49 % erklärten, dass ein ERP-Projekt nie beendet sei. (1 % der Befragten erklärte, ein Projekt sei zu Ende, wenn kein Geld mehr da ist.) In Softwareentwicklungsprojekten wird sehr viel Zeit und Energie darauf verwendet, Abnahmetest- Spezifikationen und Abnahmetests zu definieren, um das Projekt kontrolliert zu Ende zu bringen; im Sondermaschinenbau und Anlagenbau wird mit Mängellisten gearbeitet, um wenigstens formal eine Abnahme zu bekommen. Scope Management, Contract Management, Claims Management, Configuration Management sind alles Methoden, die helfen sollen, den vertragsgemäßen Liefer- und Leistungsumfang zu definieren, ein Projekt kontrolliert zu beenden oder im Crash-Fall wenigstens den finanziellen Schaden gering zu halten und sich eine gute juristische Ausgangsposition zu sichern. Niemand hat Interesse daran, dass sich Projekte über den geplanten Zeitraum hinaus selbst am Leben erhalten. Literatur [1]฀Balck,฀H.฀(Hrsg.): ฀Neuorientierung฀im฀Projektmanagement.฀Arbeitstexte฀der฀GPM.฀Köln฀1990 [2]฀Balck,฀H.฀(Hrsg.): ฀Networking฀und฀Projektorientierung.฀ Heidelberg฀1996 [3]฀Saynisch,฀M.: ฀Projektmanagement฀(PM)฀im฀Spannungsfeld฀eines฀sich฀wandelnden฀Führungs-฀und฀Managementverständnisses.฀In฀[1,฀S.฀29-39] [4]฀Lange,฀D.฀(Hrsg.): ฀Deutsches฀Projektmanagement-Forum฀ 1997.฀Tagungs-Dokumentation.฀Nürnberg฀1997,฀S.฀3-6-0-1฀ bis฀3-6-7-11 [5]฀Mekelburg,฀H.; ฀Frieß,฀P.฀M.; ฀Hadjis,฀A.; ฀Saynisch,฀M.: ฀System฀Dynamics฀als฀Innovation฀im฀Projektmanagement.฀Wie฀ Sie฀die฀Dynamik฀im฀Projekt฀und฀im฀Projektumfeld฀besser฀ bewältigen.฀http: / / gpm-ipma.de/ main/ download/ 04-1_wege/ fly_projekt4.pdf [6]฀Gareis,฀R.: ฀Der฀professionelle฀Projektstart.฀In: ฀Projektmanagement฀3/ 2000,฀S.฀23-29: ฀„Die฀Wahrnehmung฀von฀ Projekten฀als฀temporäre฀Organisation฀resultiert฀in฀einem฀ organisationsorientierten฀Projektmanagement-Ansatz,฀der฀ �� �� ��� ��� ��� ��� ��� �� ��� ��� ��� ��� ��� ��� ������� ���� ������ ������ ��� �������� �������� ������������ �������� ������������� �������� �� ���� ����� �������� ���������� �� �������� � ����������� ���������������������������������������������� ������������������������������������������������������� �������������������������������������������������������������������������� ��������������������������������������������������� ������������������������������ Abb.฀1: ฀Wann฀ist฀die฀Einführung฀eines฀ERP-Systems฀beendet? 20฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 21฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 charakterisiert฀ist฀durch฀die฀Anwendung฀von฀Methoden฀ und฀Modellen฀der฀Organisationstheorie฀und฀der฀sozialen฀ Systemtheorie.฀Der฀sozialen฀Systemtheorie฀von฀Niklas฀ Luhmann฀folgend฀können฀Organisationen,฀und฀daher฀auch฀ Projekte,฀als฀soziale฀Systeme฀wahrgenommen฀werden.“ [7]฀Bartsch-Bäuerlein,฀S.฀; ฀Klee,฀O.: ฀Projektmanagement฀mit฀ dem฀Internet.฀München-Wien฀2001 [8]฀Petersen,฀D.; ฀Witschi,฀U.: ฀Komplexes฀Projektmanagement,฀eine฀Synthese฀aus฀klassischem฀Projektmanagement฀ und฀Organisationsentwicklung.฀In: ฀Projektmanagement฀ aktuell,฀1/ 2002,฀S.฀25-31 [9]฀Scherer,฀A.฀G.: ฀Kritik฀der฀Organisation฀oder฀Organisation฀ der฀Kritik? ฀Wissenschaftstheoretische฀Bemerkungen฀zum฀ kritischen฀Umgang฀mit฀Organisationstheorien.฀In: ฀Kieser,฀A.฀ (Hrsg.): ฀Organisationstheorien.฀4.฀Auflage,฀Stuttgart-Berlin- Köln฀2001,฀S.฀1-37 [10]฀Habermas,฀J.; ฀Luhmann,฀N.: ฀Theorie฀der฀Gesellschaft฀ oder฀Sozialtechnologie.฀Frankfurt/ M.฀1971 [11]฀„Der฀Begriff฀der฀Autopoiesis฀wurde฀von฀dem฀chilenischen฀Biologen฀Humberto฀Maturana฀im฀Rahmen฀des฀ Versuches฀formuliert,฀eine฀Definition฀der฀Organisation฀von฀ Lebewesen฀zu฀entwickeln.฀Danach฀ist฀ein฀lebendes฀System฀durch฀die฀Fähigkeit฀charakterisiert,฀die฀Elemente,฀aus฀ denen฀es฀besteht,฀selbst฀zu฀produzieren฀und฀zu฀reproduzieren฀und฀dadurch฀seine฀Einheit฀zu฀definieren: ฀…“ Baraldi,฀C.; ฀Corsi,฀G.; ฀Esposito,฀E.: ฀GLU,฀Glossar฀zu฀Niklas฀ Luhmanns฀Theorie฀sozialer฀Systeme.฀Frankfurt/ M.฀1999 [12]฀Auf฀der฀Internetseite฀http: / / www.inteco.cl/ biology/ ask9707-1.htm฀gab฀es฀die฀Möglichkeit,฀Fragen฀an฀Herrn฀ Maturana฀zu฀stellen.฀Die฀Monatsfrage฀eines฀Herrn฀Paul฀ Samson฀im฀Juli฀1997฀lautete: “Dear฀Mr.฀Maturana, 1.฀At฀the฀moment฀there฀is฀a฀tendency฀in฀some฀sociological฀circles฀to฀put฀big฀questions฀about฀the฀approach฀ for฀Constructionist฀Social฀Theory฀from฀Niklas฀Luhmann฀ (German฀Professor,฀Bielefeld฀University)฀in฀Sociology฀and฀ before฀in฀Law.฀What฀is฀your฀opinion฀in฀the฀use฀of฀the฀autopoiesis฀„tool“฀in฀explaining฀„the฀total฀social฀live“฀as฀based฀ on฀the฀„medium“฀communication฀which฀is฀two-sided,฀ something฀between฀mind฀and฀the฀rest฀of฀the฀world฀…“ Die฀Antwort: “…฀1.฀I฀consider,฀that฀social฀systems฀are฀not฀autopoietic฀ systems.฀Moreover,฀I฀think฀that฀even฀if฀it฀were฀adequate฀to฀ talk฀about฀them฀as฀third฀order฀autopoietic฀systems,฀talking฀ that฀way฀would฀obscure฀what฀is฀proper฀to฀them฀which฀is฀ the฀dynamics฀of฀relations฀in฀coexistence฀of฀living฀systems.฀ In฀my฀understanding฀in฀human฀social฀systems฀the฀realization฀of฀human฀beings฀as฀languaging฀beings฀is฀central.฀We฀ human฀beings฀may฀exist฀in฀social฀systems฀that฀arise฀as฀a฀ result฀of฀interactions,฀and฀we฀become฀human฀beings฀by฀ growing฀in฀a฀human฀social฀domain฀…“ [13]฀Kieser,฀A.: ฀Fremdorganisation,฀Selbstorganisation฀und฀ evolutionäres฀Management.฀In: ฀Zeitschrift฀für฀betriebswirtschaftliche฀Forschung,฀46,฀1994,฀S.฀199-228 [14]฀Malik,฀F.: ฀Selbstorganisation,฀Evolution฀und฀Unternehmensführung.฀In฀: ฀[1,฀S.฀114-124] [15]฀Malik,฀F.: ฀Systemisches฀Management฀und฀systemisches฀Projektmanagement.฀In: ฀[2,฀S.฀145-164] [16]฀Petersen,฀D.; ฀Witschi,฀U.: ฀Komplexes฀Projektmanagement,฀eine฀Synthese฀aus฀klassischem฀Projektmanagement฀ und฀Organisationsentwicklung.฀In: ฀Projektmanagement฀ aktuell,฀1/ 2002,฀S.฀25-31 [17]฀Hofstätter,฀P.฀R.: ฀Gruppendynamik.฀Kritik฀der฀Massenpsychologie.฀Hamburg฀1957.฀Zitiert฀wird฀von฀Hofstätter฀eine฀ Reihe฀von฀Untersuchungen,฀die฀unter฀Offiziersanwärtern฀ der฀amerikanischen฀Streitkräfte฀gemacht฀wurden. [18]฀Hauschildt,฀J.; ฀Pulczyski,฀J.: ฀Rigidität฀oder฀Flexibilität฀ der฀Zielbildung฀in฀Innovationsprojekten.฀In: ฀[2,฀S.฀199-210] [19]฀Andersen,฀S.฀A.; ฀Grude,฀K.฀V.; ฀Haug,฀T.: ฀Goal฀Directed฀ Project฀Management.฀London-New฀Hampshire-New฀Delhi฀1984.฀Der฀Goal฀Directed฀Project-Management-Ansatz฀ (GDPM),฀der฀von฀verschiedenen฀Consulting-Firmen฀übernommen฀wurde฀(Coopers&Lybrand,฀die฀Projektmethodik฀ Target฀von฀Baan),฀basiert฀auf฀einem฀detaillierten฀Zielbildungsprozess฀in฀den฀Dimensionen฀„People“,฀„System“,฀ „Organisation“฀(PSO). [20]฀Habermas,฀J.: ฀Theorie฀des฀kommunikativen฀Handelns.฀ Frankfurt/ M.฀1981 Propositionale฀Wahrheit,฀normative฀Richtigkeit฀und฀subjektive฀Wahrhaftigkeit฀sind฀die฀Geltungsansprüche,฀die฀Jürgen฀ Habermas฀dem฀Bereich฀der฀Lebenswelt฀und฀dem฀hier฀gültigen฀kommunikativen฀Handel฀zuordnet,฀im฀Gegensatz฀zu฀den฀ mediengesteuerten฀Systemen฀wie฀Wirtschaft฀und฀Politik. [21]฀Giddens,฀A.: ฀Die฀Konstitution฀der฀Gesellschaft.฀3.฀Auflage,฀Frankfurt,฀New฀York฀1997 [22]฀Luhmann,฀N.: ฀Soziale฀Systeme.฀Frankfurt/ M.฀1984 Schlagwörter Critical฀Chain,฀handlungsorientiertes฀Projektmanagement,฀ Neuorientierung฀im฀Projektmanagement,฀Projektabschluss,฀ Systemtheorie,฀Zielbildungsprozess฀im฀Projekt Autor Günter฀Drews,฀Dipl.-Wirtschaftsingenieur฀(FH),฀ist฀seit฀1997฀bei฀der฀ Unternehmensberatung฀Cap฀Gemini฀ Ernst฀&฀Young฀als฀Senior฀Manager฀ für฀die฀Einführung฀und฀Optimierung฀ von฀ERP-Systemen฀auf฀Basis฀SAP฀und฀ Baan฀tätig. Zuvor฀war฀er฀zwölf฀Jahre฀bei฀Digital฀ Equipment฀in฀verschiedenen฀Positionen฀in฀der฀Softwareentwicklung฀und฀im฀Projektmanagement฀beschäftigt฀und฀ u.฀a.฀als฀Leiter฀des฀Systems฀Integration฀Business฀verantwortlich฀für฀die฀Implementierung฀der฀Infrastruktur,฀Policies฀ and฀Procedures฀und฀Qualitätskontrolle฀für฀Großprojekte฀im฀ Lösungsgeschäft. Anschrift Amselweg฀29 D-72663฀Großbettlingen 22฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 23฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Projektintegrierte฀ Know-how-Sicherung Praktisches฀Wissensmanagement฀in฀der฀Produktentstehung Jörg฀Longmuß,฀Manfred฀Mühlfelder Projektintegriertes฀Wissensmanagement฀ist฀erforderlich฀zur฀Unterstützung฀des฀Wissensflusses฀und฀der฀Kommunikation฀in฀Projektteams฀und฀der฀Ergebnissicherung฀für฀zukünftige฀ Projekte.฀Nachdem฀der฀Versuch,฀unternehmensweite,฀einheitliche฀Wissensmanagementsysteme฀für฀die฀Projektarbeit฀aufzubauen,฀oft฀die฀Erwartungen฀der฀Auftraggeber฀nicht฀erfüllt฀ hat,฀konzentriert฀sich฀der฀hier฀vorgestellte฀Ansatz฀auf฀dezentrale,฀praktische฀Vorgehensweisen,฀welche฀ohne฀zusätzliche฀Investitionen฀in฀Informations-฀und฀Kommunikationstechnik฀ umsetzbar฀sind,฀schon฀bei฀der฀Bewältigung฀der฀Alltagsarbeit฀unmittelbar฀nützlich฀sind฀und฀ die฀auf฀einen฀praktischen฀Mehrwert฀von฀Wissensmanagementaktivitäten฀für฀jeden฀einzelnen฀Projektmitarbeiter฀setzen.฀Er฀zielt฀darauf฀ab,฀die฀Motivation฀der฀Beteiligten฀zu฀einem฀ selbst฀gesteuerten฀Wissensmanagement฀zu฀erhöhen. Deshalb฀wird฀gezielt฀auf฀die฀Know-how-Sicherung฀in฀Projekten฀mit฀Schwerpunkt฀auf฀der฀ Produktentstehung฀fokussiert.฀Anhand฀eines฀praktischen฀Beispiels฀aus฀der฀Konsumgüterindustrie฀wird฀dargestellt,฀wie฀dies฀mittels฀einer฀„Baseline“฀realisiert฀werden฀kann. 1฀ Probleme฀des฀konventionellen฀Wissensmanagements฀für฀Projektarbeit 1.1฀ Was฀ist฀„konventionelles“฀Wissensmanagement? Das Problem ist allseits bekannt: Je stärker in Projekten gearbeitet wird, desto weniger eindeutig ist der Ort im Unternehmen, an dem entstandenes Wissen nach Abschluss der Arbeiten wieder auffindbar ist (zur generellen Frage des Wissensmanagements in Projekten siehe z. B. [1, 2]). Umso wichtiger ist es, zu Beginn, während des Verlaufs und am Ende eines Projektes den Wissensstand und die Projekterfahrungen zu sammeln und auszuwerten. Diese Auswertungen sind eine entscheidende Wissensquelle, die für zukünftige und parallel laufende Projekte zur Verfügung steht, sowohl auf der Ebene der Fachprozesse (technisches Fachwissen) als auch auf der Ebene des Projektmanagements (Steuerungswissen). Die Diskussion um Wissensmanagement im Projektmanagement allgemein und speziell in der Produktentstehung ist bislang überwiegend auf zentralisierte Systeme und Methoden konzentriert. Abb. 1 zeigt eine solche konventionelle Wissensmanagement-Strategie, die auf die zentrale Redaktion des fachlichen Inputs der einzelnen Fachabteilungen (z. B. Marketing, Entwicklung, Produktionsplanung, Einkauf etc.) durch eine Stabsfunktion (z. B. in der Funktion eines „Chief Knowledge Officer“) setzt. Die operativen Mitarbeiter können dann in der unternehmensweiten Wissensplattform nach Daten, Berichten und Personen mit Spezialkenntnissen suchen und die Ergebnisse für ihre eigene Arbeit nutzen. Diese Herangehensweise an das Thema „Wissensmanagement“ war in den letzten Jahren am meisten verbreitet, vor allem in solchen Unternehmen, die nach Inhalten für ihr neu und teuer geschaffenes Intranet suchten. Beispiele für konventionelles Wissensmanagement sind:  Sammlung und Standardisierung von Methoden, Arbeits- und Geschäftsprozessen mit dem Ziel des unternehmensweiten Transfers und der Adaptation von „best practices“,  zentrale Wissensdatenbanken, z. B. zur Archivierung von Versuchsberichten, Qualifikationsprofilen von Experten etc.,  anwendungsorientierte Wissensverarbeitung: data mining, collaborative filtering, profiling, agent based information retrieval etc. Die Erfahrung zeigt, dass eine solche konventionelle Wissensmanagementstrategie die Bereitschaft der Mitarbeiter zur Aufbereitung ihres Wissens nicht fördert (vergleiche z. B. [3, 4]). Dies hat mehrere Gründe:  Zum Ersten werden in den Projektbudgets meist keine oder nur geringe Ressourcen für Wissensmanagementaktivitäten eingeplant. Die Mitarbeiter haben oft keine Zeit, ihr Wissen zu dokumentieren und anderen zur Verfügung zu stellen.  Zum Zweiten besteht für die Projektmitarbeiter kein Anreiz, ihr Wissen so aufzubereiten, dass es in anderen Projekten wieder verwendbar ist. Aufgrund des Einmaligkeitscharakters von Problemen in der Projektabwicklung wird am Nutzen von Wissensmanagement als Mehrwert sowohl für die eigene Arbeit als auch für das Unternehmen gezweifelt. 22฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 23฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3  Zum Dritten besteht bei einigen dieser Ansätze die Gefahr, dass zum vorgesehenen Zeitpunkt der Dokumentation wichtige Mitarbeiter nicht mehr greifbar oder gemachte Erfahrungen nicht mehr präsent sind. Der Zusatzaufwand der Mitarbeiter zur Bereitstellung von Wissensinhalten muss daher oft durch Bonus- und Anreizsysteme und/ oder einen umfangreichen Ressourceneinsatz erkauft werden (z. B. Beschäftigung von externen Wissensredakteuren, Ausfallzeiten für Wissensaufbereitung und -dokumentation etc.). Vor allem aber zeigt die Praxis, dass zentral abgelegtes Unternehmenswissen meist nur wenig nachgefragt wird und daher aus betrieblicher Sicht ebenso unwirtschaftlich ist wie z. B. ein schlecht gepflegtes Materiallager. Dies liegt unter anderem daran, dass sich jedes Unternehmen nach Beginn einer Wissensmanagementinitiative ein Mengenproblem einhandelt. Anfangs wird jeder Eintrag in die Wissensdatenbank als weiterer Baustein des Unternehmenswissens gefeiert. Je umfangreicher die Wissenssammlung jedoch dann wird, desto aufwändiger wird die Suche nach dem „richtigen“ Wissen und umso geringer ist die Wahrscheinlichkeit, in begrenzter Zeit das benötigte Wissen zu finden. 1.2฀ Das฀Problem฀der฀Kontextbindung: ฀Explizites฀und฀ implizites฀Wissen Das hauptsächliche Problem konventionellen Wissensmanagements aber liegt nicht nur und nicht vor allem in einer möglicherweise unzureichenden Umsetzung der Lehrbuchinhalte in die Praxis; es hat auch zumindest einen strukturellen Grund: die Vernachlässigung der Kontextbindung von Wissen. Ohne eine Kenntnis des Umfeldes, in dem Wissen entstanden ist und seine Bedeutung erhalten hat, und der dazugehörigen Lerngeschichte ist seine Relevanz für ein neues Problem kaum abschätzbar [5]. In diesem Zusammenhang ist die Unterscheidung zwischen explizitem und implizitem Wissen wichtig. Explizites Wissen ist nicht personengebunden und liegt z. B. in Form von Dokumenten und Zeichnungen vor. Implizites Wissen hingegen liegt in den Köpfen jedes Mitarbeiters und wird z. B. als „persönliche Erfahrung“ oder als „Gespür für Sachverhalte“ bezeichnet. Daher ist implizites Wissen auch nur schwer an neue oder jüngere Kollegen ohne die entsprechende eigene Erfahrung vermittelbar. Jedes neu entstandene Wissen liegt zunächst implizit vor. Erst durch zusätzliche Aktivitäten wird es von seinem Kontext befreit und aus dem konkreten Anwendungszusammenhang herausgelöst. Es wird damit zu explizitem Wissen. Abb. 2 zeigt diesen Prozess der Umwandlung von implizitem in explizites Wissen und seine Rückwandlung durch Re-Kontextualisierung und Internalisierung. Ein Beispiel für diesen Transformationsprozess ist die Anfertigung eines Versuchsberichts unter Angabe des Verfahrens und der Ergebnisse. Wird der Kontext des Versuchs, z. B. die aufwändige Programmierung der Messprozedur oder das mühsame Ausmerzen von Fehlerquellen in der Durchführung, nicht mit dokumentiert, bleibt das explizit dokumentierte Wissen unvollständig und wird unter Umständen nutzlos, weil die Umstände, unter denen ein Versuchsergebnis erzielt worden ist, gedanklich nicht mehr nachvollzogen werden können. Je weiter Wissen aus dem ursprünglichen Kontext entfernt wird, desto abstrakter und umfangreicher wird seine Darstellung. Entsprechend ist es sehr aufwändig, dieses Wissen zu verstehen und es in einer anderen als der Entstehungssituation zu nutzen. In der Projektarbeit kann dies zum Problem werden, da die Rahmenbedingungen ständigen Veränderungen unterworfen sind und daher der Kontext jeweils einmaligen ������������������������� ����������������������������������������������������� ����������� ����������� ��������������������������������� ��������������������������� ����������� ��� ������������������������� ����������������������������������������������������� ����������� ����������� ��������������������������������� ��������������������������� ����������� ��� ������������������������� ��������������������������������������������������� � ����������� ����������� ��������������������������������� ��������������������������� ����������� ��� Abb.฀1: ฀Zentralisiertes฀Wissensmanagement ����������������� � � � ������ � � � ������ � � � ������� � ����������� � � � �������� � � � �������� � � � ��������� � ���������� � ��������� ����������� ��������� � �� � � � ������������������ � ���������� � ������� ����������� ��������� ����������� ���������� ���������������� � ������� ��������� � �� � � � ������������������ � Abb.฀2: ฀Wissensdiffusion฀nach฀Brödner฀[5] 24฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 25฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Charakter hat. Ein neues Produkt wird nur einmal in einer ganz bestimmten Marktkonstellation und unter bestimmten technologischen Voraussetzungen von einem einzigartigen Projektteam entwickelt. Soll ein ähnliches Produkt unter anderen Ausgangsbedingungen entwickelt werden und kann das neue Projektteam dabei auf explizites Wissen der Vorgänger zurückgreifen (z. B. Zeichnungen, Pflichtenhefte etc.), so lassen sich möglicherweise Problemlösungen kopieren und wieder verwenden. Die Übertragung dieses Wissens auf die eigene Problemstellung ist jedoch daran gebunden, dass die Nachfolger auch den ursprünglichen Kontext mitgeliefert bekommen, um bestimmte Entscheidungen und technische Lösungen überhaupt verstehen zu können. Als Fazit dieser kurzen Betrachtungen bleibt demnach festzuhalten, dass ein „konventionelles“, zentralistisches Wissensmanagement insgesamt wenig zum Unternehmenserfolg beiträgt, da das aufwändig gesammelte Wissen nur relativ begrenzt verwertbar ist und von den Mitarbeitern nur unzureichend für die eigene Projektarbeit genutzt werden kann, weil sein Entstehungskontext nicht mehr zugänglich ist. Es bedarf daher neuer Methoden, die das Wissensmanagement in die Projektarbeit integrieren und die Übertragbarkeit von Lösungen auf neue Probleme in ähnlichen Projekten unter Vermittlung des jeweiligen Kontextes ermöglichen. 2฀ Lösungsstrategie: ฀Projektintegriertes฀Wissensmanagement 2.1฀ Ausrichtung฀an฀der฀Projektebene Aus diesen Erfahrungen ergibt sich ein Bedarf an Konzepten und Lösungen für die Verlagerung des Wissensmanagements aus zentralen Stabsfunktionen in die operative Prozess- und Projektebene. Die Mitarbeiter dort sollten dazu berechtigt und qualifiziert werden, ihr Wissen selbst zu managen, da vor allem in der fachlichen und inhaltlichen Auseinandersetzung mit anderen Wissensträgern neue Ideen für innovative Projekte und effiziente Arbeitsprozesse entstehen. Die Verlagerung auf die operativen Einheiten zielt darauf ab, dass die Schritte zur Aufarbeitung, Speicherung und Weitergabe von Wissen gleichzeitig möglichst unmittelbar dem eigenen Arbeitsfortschritt im Projekt dienen. Dass dieses Wissen dann nicht mehr unbedingt in unternehmenseinheitlicher Form vorliegt, wird im Interesse der problemnahen Einsetzbarkeit in der Praxis in Kauf genommen. 2.2฀ Know-how-Sicherung฀in฀der฀Projektarbeit Im Gegensatz zu den eingangs beschriebenen konventionellen Konzepten ist es nach unseren Erfahrungen hilfreich,  Projektprozesse so zu strukturieren, dass möglichst viel Wissen „automatisch“ explizit wird, und  sich im Interesse von Verfahrensökonomie und Wiederverwendbarkeit auf solches Wissen zu beschränken, das ohnehin, z. B. in Form von Projektdokumenten, technischen Zeichnungen, Kontrollberichten, Berechnungen etc., explizit gemacht werden muss. Es geht also im Kern um eine unmittelbare Know-how- Sicherung für die Projektarbeit. Soll sie erfolgreich sein, darf dies nicht vor allem neue IT-Systeme, zusätzliche Routinen und neue Dokumente bedeuten. Vielmehr sollten die Systeme, Routinen und Dokumente, die ohnehin zur Gestaltung der Prozesse eingesetzt, durchgeführt bzw. angefertigt werden müssen, so gestaltet sein, dass das damit erworbene bzw. darin enthaltene Wissen leicht archiviert, verteilt und anderen zugänglich gemacht werden kann. Bereits übliche und erprobte Methoden der Prozessbeschreibung und Prozesssicherung sind zu ergänzen/ überarbeiten, ohne ein grundsätzlich neues Feld zu bestellen. Der zusätzliche Aufwand ist dann relativ gering. Im Gegenzug unterstützt ein solches projektintegriertes Wissensmanagement das Projektteam dabei, die Arbeitsprozesse zu strukturieren. Unter diesem Blickwinkel fordert Wissensmanagement keinen Zusatzaufwand, sondern die Beachtung von Standards eines guten Projektmanagements. Der entscheidende Vorteil ist, dass der Kontext insgesamt, aber auch die konkreten Formate (z. B. Lastenhefte, Vorlagen für Reporte, Zielkosten-Aufstellungen, Meilenstein-Checklisten) nicht nur innerhalb eines Projekts, sondern auch projektübergreifend allen Beteiligten vertraut sind. Gleichzeitig wird damit, auch wenn es nur ein Nebeneffekt ist, eine zusätzliche Motivation zur Einhaltung verabredeter Prozesse geschaffen. Dabei ist informationstechnische Unterstützung, etwa Auswahl und Einsatz von Software für das Dokumentenmanagement, zwar hilfreich (siehe z. B. [6]), aber nicht das Allheilmittel. Sie ist gut geeignet zum Sammeln und Aufbereiten von Informationen, weniger gut zur Kommunikation expliziten Wissens, aber kaum nutzbar, um das implizite Wissen, das in der Alltagsarbeit entsteht, für nachfolgende oder parallele Projekte nutzbar zu machen. 2.3฀ Die฀Bedeutung฀einfacher฀Instrumente฀im฀ Projektalltag Wissen sollte also bereits bei seiner Entstehung im Projektverlauf kenntlich gemacht und so aufbereitet werden, dass es später von Personen, die nicht an seiner Entstehung unmittelbar beteiligt waren, möglichst problemlos gefunden, verstanden und eingesetzt werden kann. Dabei ist einfachen Lösungen der Vorzug gegenüber komplexen, d. h. unternehmensweiten zu geben, die ohne großen Aufwand in den Arbeitsablauf integriert werden können und bei denen die „Absender“ den „Adressaten“ klar vor Augen haben. Da die Mitarbeiter in ihrem Arbeitsalltag beide Rollen innehaben, können sie so das Wissen in seinem Kontext verstehen und es für die eigene Tätigkeit nutzbar machen. Eine „80 %“-Variante, welche die wesentlichen Anforderungen erfüllt, aber einfach eingerichtet, geändert und ggf. ohne Verlust wieder abgeschafft werden kann, ist dafür oft effektiver als eine auf Vollständigkeit bedachte „100 %“-Lösung, die jedoch bei geringfügiger Änderung der Rahmenbedingungen unbrauchbar wird. Als positive Beispiele mögen dienen:  Bei einem Hersteller von Kleinserien-Blechteilen, bei dem es immer wieder Kommunikationsschwierigkeiten in der Fertigungskette gab (Konstruktion, Etap- 24฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 25฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 pen der Werkzeugerstellung, Umformen, Finishing), wurde eine „Werkzeug-Akte“ eingeführt, die jedes Teil bzw. jede Kleinserie über den gesamten Prozess begleitet. In dieser Akte werden alle relevanten Informationen (z. B. Verständnis-, Fertigungs- und Einsatzprobleme) objektbezogen zusammengefasst und ausgewertet. Dieses Wissen steht dann der Konstruktionsabteilung für das nächste Vorhaben zur Verfügung [7].  Um auf Probleme in der Produktion schneller und effektiver reagieren zu können, wurden in einem Unternehmen alle Fertigungs- und Montagebereiche mit Digitalkameras ausgerüstet. In Verbindung mit dem firmeneigenen Intranet können so alle Schwierigkeiten mit minimalem Aufwand für die Dokumentation und minimaler Zeitverzögerung an die Konstruktion zurückgemeldet werden [7].  In der Entwicklungsabteilung für lichttechnische Geräte eines Automobilherstellers tauchten immer wieder Nachfragen auf, welche Leuchte mit welcher Lampe (nach Hersteller und Produktnummer getrennt) ausgestattet wird. Eine einfache Tabelle, in der die Zuordnung fortgeschrieben wurde, erleichterte vor allem Neueinsteigern in der Abteilung, die mit der Betreuung von Serienteilen beauftragt wurden, die Auswahl des richtigen Leuchtmittels für die verschiedenen Varianten. Diese Strategie der einfachen Instrumente soll im Folgenden exemplarisch für die Know-how-Sicherung in Produktentstehungsprojekten dargestellt werden. Das bedeutet in diesem Kontext nicht nur die Weitergabe des Wissens von einem abgeschlossenen zu einem Nachfolgeprojekt, sondern auch Quermitteilungen von einem laufenden zu anderen Projekten, die sich in frühen Phasen befinden und von den neuesten Erfahrungen lernen wollen. Für diesen Zweck wird im Folgenden ein Instrument vorgestellt, das sich in Produktentstehungsprozessen bereits bewährt hat: die „Baseline“. 3฀ Die฀„Baseline“: ฀Eine฀strukturierte฀Dokumentation฀ des฀Projektstarts฀als฀Grundlage฀für฀den฀Produktentstehungsprozess Produkte werden üblicherweise entwickelt anhand eines - meist schrittweise konkretisierten - Lastenheftes mit allen technischen Spezifikationen, häufig noch ergänzt um eine Finanzkalkulation. Bei komplexen Produkten ist es sinnvoll, dies mit einer strukturierten Dokumentation aller darüber hinausgehenden Zielgrößen, Vereinbarungen und Annahmen bereits zum Projektstart zu verknüpfen. Dieses als „Baseline“ bezeichnete Dokument findet unter verschiedenen Bezeichnungen im Management von Produktentstehungsprozessen zunehmend Anwendung. In ihr wird der Ausgangspunkt eines Projektes mitsamt den darin enthaltenen Annahmen dokumentiert, und zwar: nach außen: die formellen Verträge mit dem Kunden (bei externen Auftraggebern) bzw. der Projektauftrag (bei internem Auftraggeber) einschließlich des gesamten (ggf. nicht expliziten) Vereinbarungsstandes über Lastenheft und Angebot hinaus; nach innen: die Zusammenfassung der eigenen Annahmen, Zielgrößen, Unsicherheiten (! ), Pläne und des eigenen Kenntnisstandes. Die Daten der „Baseline“ stellen das „Fleisch auf den Knochen“ des Projektmanagement-Handbuchs dar: Sie beinhalten Zusatzinformationen zu den technischen und betriebswirtschaftlichen Zahlen in den Lastenheften und den Controlling-Sheets. Dabei entsprechen sich ökonomische und technische Betrachtungen und sind ineinander überführbar: Die angestrebten Produktmerkmale führen zu einer bestimmten Kostenkalkulation und einem entsprechenden Budget; umgekehrt lassen sich technische Eigenschaften des Produkts aus den ökonomischen Randbedingungen heraus bestimmen. Mit Hilfe der „Baseline“ werden alle grundlegenden Annahmen zusammengeführt, die das Projekt kennzeichnen. Die „Baseline“ ist jedoch nicht mit dem Lasten- oder Pflichtenheft identisch. Sie erhebt nicht deren Anspruch auf Detailtiefe und Vollständigkeit, sondern konzentriert sich eher auf die Erfassung des Projekt- und Produktumfeldes. Außerdem ist sie ein „lebendes“ Dokument“, d. h., sie liegt nicht zu einem bestimmten Zeitpunkt in abschließender Form vor, sondern wird während des Produktentstehungsprozesses kontinuierlich fortgeschrieben, erweitert und ergänzt. Die „Baseline“ dient dem Abgleich unterschiedlicher Informationsstände und -quellen, Denkmodelle und Herangehensweisen der beteiligten Abteilungen und Hierarchiestufen. Damit hilft sie, auch implizites Wissen aus den Köpfen der Mitarbeiter herauszuholen und die persönlichen, durchaus unterschiedlichen (Vor-)Erfahrungen schriftlich festzuhalten. Am folgenden Praxisbeispiel sollen die grundlegende Struktur und einige konkrete Punkte einer „Baseline“ erläutert und in ihrer Funktion verdeutlicht werden. 3.1฀ Beispiel: ฀„Baseline“฀für฀eine฀Produktreihe฀im฀ Haushaltsbereich Die hier vorgestellte „Baseline“ wurde für Projekte der Produktentwicklung (im Unterschied zur Vorentwicklung) im Bereich der „weißen Ware“, d. h. aufwändigerer Konsumgüter im Haushaltsbereich, entwickelt. Sie ist in Frageform aufgebaut und enthält insgesamt über 150 Fragen, von denen in Abb. 3 einige für verschiedene Bereiche exemplarisch dargestellt sind. Der Produktentstehungsprozess, der ihr zugrunde liegt, besteht aus den drei Hauptphasen  Konzeptentwurf,  Konzeptabsicherung und  Serienentwicklung. Die erste Formulierung der „Baseline“ findet hauptsächlich während der Konzeptabsicherung über die einzelnen Meilensteine hinweg statt und wird während der Serienentwicklung fortgeführt und überarbeitet. Dazu wird sie in Tabellenform so angelegt, dass Revisionen schnell und übersichtlich durchgeführt werden können und leicht erkennbar und nachvollziehbar sind (siehe Abb. 4). Diese hier vorgestellte „Baseline“ ist als Format mit wenigen Änderungen für verschiedene Haushaltsgeräte einsetzbar. Allerdings ist die Weiterverwendung der dokumentierten Informationen und Erfahrungen, also des gewonnenen Wissens, in vieler Hinsicht nur innerhalb konkreter Produktreihen möglich, da sich z. B. Wäschetrockner und Geschirrspülmaschinen in den meisten Features zu stark unterscheiden. 26฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 27฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 3.2฀ Einsatz฀der฀„Baseline“฀im฀Projektalltag Die „Baseline“ ist ein zentrales Projektdokument, dessen aktueller Stand als mitgeltende Unterlage in verschiedenen Genehmigungsphasen eines Projekts durch die Entscheider verwendet werden kann. Sie kann neben den internen Adressaten (z. B. Projektsteuerkreis) auch externe Entwicklungspartner (z. B. Zulieferunternehmen, Kunden) ansprechen. Wenn z. B. aus Geheimhaltungsgründen einzelne Teile besonders vertraulich behandelt werden müssen, können verschiedene Varianten der „Baseline“ existieren. Sie gewährleistet einen Projektstart auf Grundlage des im Moment verfügbaren Wissens, und zwar unter ausdrücklicher Kennzeichnung der Unsicherheit, also des noch nicht vorhandenen Wissens. Sie ist gleichzeitig Ausgangspunkt für „Change Management“ bez. Konstruktionsänderungen, da sie die Bezugsgröße für alle ������������� ������������������������� �������������������� ����������������������������� ����������������������������������� ������������������������������������������������������������������������ ����� ���������������������� ��������������������� ����������������������������������������������������������������� ����������������������������������������������������������������� ������������������������������������������������������������������� ����� �������������������������� ���������������������������������������������������������������������� ������������������������������������������������������ ����� ���������������������������������������������� ���� ��������������������������� ��������������� ������������������������������������������������������� ����� ���������������������������� ��������������������������������������������������������� ������������������������������������������������������� ����� ����������������������������� ������������� ����� �������������� ������������������������������������ ������������������������������������������������������������� ���������������������������������������������� ����� ����� ���������� ������������������������������������������������������������������������ ������������ ������������������������������������������������������������������������������������ ������������� ����������������������������������������������������������������������������� ����������������� ������������������������������������������������������������������������ ������������������������������������������� ���������������������������������������������������������������������������� Abb.฀3: ฀Auszug฀aus฀einer฀„Baseline“ 26฀฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 WISSEN 27฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Formen von Weiterentwicklung und Änderungen darstellt. Außerdem ermöglicht sie, die Weiterentwicklung und Veränderung von Kundenwünschen zu erkennen und ein konsequentes „Claim Management“ bezüglich der Leistungserbringung und -vergütung zu realisieren. Im laufenden Projekt kann der augenblickliche Entwicklungsstand ständig mit der „Baseline“ abgeglichen werden. Dabei sind verschiedene Arten von Inhalten zu unterscheiden:  Annahmen, die das Projektumfeld beschreiben (z. B. Kundenpräferenzen im Konsumgüterbereich, Vorstellungen und vermutete Änderungswünsche des Auftraggebers im Anlagen- und Zulieferbereich, Wechselkurse etc.);  Aufwandsabschätzungen, die Einfluss auf die Projektplanung haben (z. B. Zeit- und Ressourcenpläne);  Ziele, bei denen eine Änderung des augenblicklichen Entwicklungsstandes angestrebt wird. Die Erwartung, dass diese Änderungen im angestrebten Umfang auch eintreten, ist häufig sogar entscheidend für den Entschluss, das Projekt überhaupt durchzuführen. Beispiele dafür sind Zielkosten, die im Projektverlauf erreicht werden sollen („target costing“), Zielgewichte, Volumengrenzen etc.;  offene Fragen und unsichere Annahmen, die bewusst in die „Baseline“ aufgenommen werden. Dazu gehört z. B. die vorläufige Bestimmung von Lieferanten, die bei Projektbeginn noch nicht feststehen. Die Konkretisierung dieser unsicheren Annahmen kann entscheidende Informationen für die Projektleitung liefern. Es gilt dabei zu beobachten, inwieweit sich bestimmte Annahmen als realistisch erwiesen haben, welche Ziele wie weitgehend erreicht werden konnten, welche Fragen evtl. noch konkretisiert bzw. korrigiert werden müssen etc. Je nach Art der verwendeten Software können Planungsdaten sogar überhaupt nicht geändert werden, ohne den Grund der Änderung festzuhalten. Damit wird aber gleichzeitig und praktisch ohne gesonderten Aufwand das im Laufe des Projekts gewonnene Wissen explizit und projektspezifisch festgehalten. Zweckmäßigerweise wird eine solche „Baseline“ nicht nur für ein einzelnes Projekt angelegt, sondern in einer Standardstruktur auf Grundlage eines Referenz- Produktentstehungsprozesses (siehe z. B. [8]) bereitgestellt, die für alle vergleichbaren Projekte im Unternehmen (z. B. die verschiedenen Entwicklungsreihen von Waschmaschinen oder Berechnungsprogrammen, Nahverkehrszügen oder Autositzen) verwendbar ist. Damit spart sie im Multi-Projektmanagement Arbeit und schafft Transparenz: Fragen müssen nur einmal ausgearbeitet werden, einheitliche Berichtsformate erleichtern den Überblick über die Gesamtheit der Projekte, und die Einarbeitungszeit von Mitarbeitern bei einem Wechsel von einem Projekt in ein anderes wird kürzer. 3.3฀ Die฀„Baseline“฀als฀Wissensquelle฀für฀das฀ laufende฀Projekt฀und฀für฀folgende฀Projekte Das Anlegen und kontinuierliche Verfolgen einer solchen „Baseline“ sind also, in Übereinstimmung mit den Thesen aus dem Abschnitt 2, kein Aufwand, der eine zusätzliche „Wissensmanagement-Aktivität“ darstellt. Sie ist vielmehr vor allem ein Instrument für eine transparente Definition und Verfolgung eines Projekts. Gleichzeitig ist sie aber ein zentrales Dokument für die Know-how-Sicherung: Sind die „Baseline“-Strukturen der einzelnen Projekte identisch, können sowohl die ursprünglichen Annahmen im weitesten Sinne als auch deren Änderungen zwischen den Projekten in ihrem ursprünglichen Kontext verglichen bzw. beim Start neuer Projekte direkt genutzt werden. Ferner lassen sich die Änderungen (und die Gründe für die Änderungen, die ohnehin in den Projektbesprechungen klarzustellen sind) in einem einheitlichen Format darstellen. Der entscheidende Vorteil einer „Baseline“ besteht darin, dass das Format, in dem die Änderungsdokumentationen eines laufenden Projekts abgelegt werden, mit dem Format übereinstimmt, in dem die Ausgangssituation für ein neues Projekt beschrieben wird. Es können also Start-, Zwischen- und Endpunkte vorangegangener Projekte direkt verglichen werden und es können korrigierte Annahmen über  den Startpunkt,  den Endpunkt bzw.  eine Extrapolation der Differenz zwischen ursprünglichen Annahmen und den zu Projektende vorhandenen Größen in das neue Projekt eingestellt werden. Datum Angabe/ Wert Grund/ Anmerkung … … 3.2.2 Wo sehen wir Änderungsrisiken/ -chancen im Lastenheft? … … … Überarbeitung I … … … Überarbeitung II … … … 3.2.3 … Abb.฀4: ฀Aufbau฀der฀„Baseline“฀in฀Tabellenform฀ 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 Da diese „lessons learned“ nicht unbedingt alle an einem Projekt beteiligten Fachbereiche und Abteilungen betreffen, können sie auch abteilungsspezifisch zugeschnitten werden (also z. B. in Form von Informationen über erzielte Lieferantenrabatte oder neue Layouts der Fertigungsanlagen). Damit ist auch eine Möglichkeit geschaffen, das gewonnene Wissen adressatenspezifisch auszuwählen und zu kommunizieren. 3.4฀ Gezieltes฀Einspeisen฀in฀die฀Organisation฀nötig Um das gewonnene Wissen in der Organisation wirksam werden zu lassen, sind entsprechende Vorgänge im Ablauf jedes neuen Produktentstehungsprojektes ausdrücklich vorzusehen:  Die Fachfunktionen sollen für ihren Input in der Projektdefinition (d. h. in die „Baseline“ des neuen Projekts) eine Analyse des Wissenszuwachses in vorhergehenden bzw. weiter fortgeschrittenen, parallel stattfindenden Projekten vornehmen.  In der Projektdefinition fließen die „lessons learned“ der Vorgängerprojekte in die „Baseline“ ein. Deren Grundstruktur dient als Schema zur Einordnung der vorhandenen Annahmen und Erfahrungen. Diese können dann beim „Kick off“ aufgearbeitet werden und in die konkrete Gestaltung und Ausstattung des neuen Projekts einfließen.  Im laufenden Projekt kann auf die Erfahrungen anderer Projekte durch die Verfolgung deren Entwicklungslinien, ausgehend von deren „Baseline“, zurückgegriffen werden. So wird mit Hilfe der „Baseline“ eine projektspezifische Sicherung von Erfahrungswissen erreicht. Projektmitarbeiter können ihr Wissen, das sie während der Projektbearbeitung erwerben, miteinander in Beziehung setzen und den jeweiligen Wissenszuwachs bewerten. Manche unsichere Annahmen zu Projektbeginn erweisen sich als tragfähig, andere als falsch, andere nur unter bestimmten Rahmenbedingungen als gültig. Durch den direkten Vergleich zweier Projekte anhand ihrer „Baselines“ können Rückschlüsse darüber gezogen werden, welche Maßnahmen zu welchen Resultaten geführt haben. Doppelarbeit kann vermieden und Prozessschritte abgekürzt werden. Die „Baseline“ dient dabei gleichzeitig als Referenz für den Wissenszuwachs und als definierte Schnittstelle zwischen verschiedenen Projekten im Sinne eines strategischen Wissensmanagements.  Literatur [1]฀Heisig,฀P.: ฀Erfahrung฀sichern฀und฀Wissen฀transferieren: ฀ Wissensmanagement฀im฀Projektmanagement.฀In: ฀Projektmanagement,฀4/ 1998,฀S.฀3-10 [2]฀Diesterer,฀G.: ฀Wissensmanagement฀in฀Projekten.฀In: ฀Projektmanagement฀4/ 2000,฀S.฀30 [3]฀Schindler,฀M.; ฀Eppler,฀M.: ฀Vom฀Debriefing฀zum฀kontinuierlichen฀Erfahrungslernen.฀In: ฀Organisationsentwicklung฀1,฀ 2002,฀S.฀58-71 [4]฀Longmuß,฀J.; ฀Mühlfelder,฀M.: ฀Wissensmanagement฀in฀ der฀Produktentstehung฀-฀Von฀der฀zentralen฀Wissensverwaltung฀zu฀zirkulierenden฀Wissensströmen.฀In: ฀Unternehmen฀der฀Zukunft฀3/ 2001,฀IAW฀+฀FIR,฀Aachen฀2001 [5]฀Brödner,฀P.; ฀Helmstädter,฀E.; ฀Widmaier,฀B.฀(Hrsg.): ฀Wissensteilung฀-฀Zur฀Dynamik฀von฀Innovation฀und฀kollektivem฀ Lernen฀(Zur฀Einführung).฀München฀und฀Mering฀1999 [6]฀Frank,฀U.; ฀Schönert,฀S.฀: ฀Wissensmanagement฀in฀Projekten.฀In: ฀Projektmanagement฀aktuell฀4/ 2001,฀S.฀25-33 [7]฀Thoben,฀K.-D.; ฀Weber,฀F.; ฀Wunram,฀M.: ฀Towards฀Pragmatic฀Approaches฀for฀Knowledge฀Management.฀In: ฀Engineering฀-฀Theory฀and฀Industrial฀Applications.฀In: ฀International฀Conference฀on฀Engineering฀Design.฀ICED,฀Glasgow฀ 2001 [8]฀Longmuß,฀J.: ฀Integrating฀Design฀Processes฀in฀an฀SE- Environment.฀In: ฀International฀Design฀Conference฀-฀Design฀ 2002.฀Dubrovnik฀2002 Schlagwörter Know-how-Sicherung,฀Erfahrungssicherung฀in฀Projekten,฀ Produktentstehungsprozess,฀Produktentwicklung,฀Wissensmanagement Autor Dr.-Ing.฀Jörg฀Longmuß฀ist฀Konstruktionstechniker฀und฀Senior-Berater฀bei฀ der฀Berliner฀Unternehmensberatung฀ GITTA฀mbH.฀Zu฀seinen฀Arbeitsgebieten฀gehört฀das฀Projektmanagement฀in฀ Industrie฀und฀Forschung฀mit฀Schwerpunkt฀Organisations-฀und฀Teamentwicklung.฀Er฀hat฀in฀verschiedenen฀ Unternehmen฀die฀Einführung฀bzw.฀Erneuerung฀von฀PM- Standards฀und฀das฀Erarbeiten฀von฀Produktentstehungsplänen฀begleitet. Anschrift GITTA฀mbH Kreuzbergstr.฀37/ 38 D-10965฀Berlin Tel.: ฀0฀30/ 7฀85฀20฀82 E-Mail: ฀longmuss@gittambh.de Autor Dipl.฀Psych.฀Manfred฀Mühlfelder฀ist฀ wissenschaftlicher฀Mitarbeiter฀am฀ Institut฀für฀Arbeitswissenschaft฀(IAW)฀ der฀RWTH฀Aachen.฀Schwerpunkte฀ seiner฀Tätigkeiten฀sind฀die฀humanorientierte฀Analyse,฀Bewertung฀und฀ Gestaltung฀von฀Produktentstehungsprozessen.฀Im฀Rahmen฀des฀vom฀Bundesministerium฀für฀Bildung฀und฀Forschung฀(bmb+f)฀geförderten฀Leitvorhabens฀INVITE฀(http: / / www.invite.de)฀hat฀er฀ sich฀vertieft฀mit฀dem฀Aspekt฀„Wissensmanagement฀in฀der฀ Produktentstehung“฀am฀Beispiel฀der฀Automobilindustrie฀ auseinander฀gesetzt. Anschrift IAW฀der฀RWTH฀Aachen Bergdrisch฀27 D-52062฀Aachen Tel.: ฀02฀41/ 8฀09฀94฀73 E-Mail: ฀m.muehlfelder@iaw.rwth-aachen.de 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 40฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 41฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 China: ฀„Schwieriges฀Terrain“฀für฀westliche฀ Projektmanager?  Gern sei er in Asien, bekundete Heinrich von Pierer nach der Rückkehr aus dem Reich der Mitte. „Die Wachstumsraten sind dort beeindruckend“, diktierte der oberste Siemens-Chef Journalisten der „Frankfurter Allgemeinen Sonntagszeitung“ in den Notizblock. Ihm mache die Aufbruchsstimmung Freude, die Begeisterung für Technik, überhaupt die Begeisterungsfähigkeit. Und er sehe gute Chancen für weitere Transrapid-Aufträge in China, jenes Vorzeigeprojekt, das endlich wieder bundesdeutsches Know-how in die Schlagzeilen brachte. So wie von Heinrich von Pierer erhalten immer mehr deutsche Projektmanager den Segen der Unternehmensspitze, sich in Asien zu engagieren, vor allem in China. Doch dort angekommen, gesellt sich schnell Ernüchterung zur Aufbruchsstimmung. An dem rasanten Aufbruch in China teilzunehmen, das koste nach Einschätzung chinakundiger Projektmanager Nerven. „Man muss Abschied nehmen von aus unserer Sicht vielen Selbstverständlichkeiten im Geschäftsleben und Projektgeschäft“, gibt Maik Ullrich, Geschäftsführer der „Hamburg Projektmanagement GmbH“, seinen Kollegen mit auf den Weg. Nach seinen Aufenthalten in China ist er überzeugt: „Mit Projekten in China Geld zu verdienen ist ein unglaublich mühsames Geschäft.“ Nicht nur für die Unternehmen. Vor allem für die Projektmanager. Dabei ist China in Sachen Projektmanagement vergleichsweise gut vorbereitet. Die chinesischen Projektleiter sind solide ausgebildet. An vielen Hochschulen gehört Projektmanagement zum Curriculum. Gewaltige Projekte wie der Drei-Schluchten-Staudamm machen Furore. Mangelhaftes Projektmanagement, das beklagen West-Projektleiter in China selten. Was ihnen das Leben mehr oder weniger erschwert, das sind die kulturellen Differenzen zwischen Ost und West, historische Vorbehalte, komplizierte Strukturen und unterschiedliche Mentalitäten. Die jahrtausendealte chinesische Kultur sowie die jüngere Geschichte des Landes wirken sich deutlich auf das Geschäftsleben aus. So steht beispielsweise in China das zwischenmenschliche „Networking“ im Vordergrund. Persönliche Vorteilsnahmen gelten in China nicht als anrüchig. Verträge gelten, so pointiert Maik Ullrich, bis die Tinte trocken ist - danach garantieren nur persönliche Beziehungen die Einhaltung. „Abmachungen, sogar unterzeichnete Verträge scheinen zu schwimmen“, meint er. „Sich allein auf schriftlich getroffene Abmachungen zu verlassen - dieses für uns selbstverständliche Vorgehen kann in China hoffnungslos scheitern.“ Und: „Vielleicht liegt dies daran, dass sich in China erst seit den letzten Jahren ein transparentes Rechtssystem mit einem freien Vertragswesen entwickelt.“ Seine Beobachtungen werden von der China-Expertin Petra Müller gestützt: „In der Tat ist es so, dass Chinesen Verträge flexibler auslegen und häufig nachverhandeln.“ Das jedoch hindert Unternehmen selten, ihre Projektmanager ins Reich der Mitte zu entsenden. Der Schwindel erregende Aufschwung in den chinesischen Boom-Regionen zieht die westliche Industrie magisch an. China gibt starre Reglements auf und hat mit dem Beitritt zur Welthandelsorganisation WTO ausländische Investitionen erleichtert. Investitionen stehen an. Beispiel Logistik: Allein durch den WTO-Beitritt rechnen Volks- Gern฀reist฀Siemens-Chef฀Heinrich฀von฀ Pierer฀nach฀Asien: ฀„Die฀Wachstumsraten฀sind฀dort฀beeindruckend.“฀Eine฀ Begeisterung,฀die฀Projektmanager฀nur฀ zur฀Hälfte฀teilen.฀Das฀Projektgeschäft฀ mit฀China฀ist฀nicht฀leicht. Foto: ฀Siemens Maik฀Ullrich,฀Geschäftsführer฀der฀„Hamburg฀Projektmanagement฀GmbH“: ฀„Mit฀ Projekten฀in฀China฀Geld฀zu฀verdienen฀ist฀ein฀unglaublich฀mühsames฀Geschäft.“ Foto: ฀privat฀฀ 42฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 43฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 wirte damit, dass der Seefrachtverkehr von 400 Millionen Tonnen (1999) auf 650 bis 700 Millionen Tonnen in 2005 anschwillt. Für den Logistik-Binnenmarkt gehen Beobachter für die nächsten zehn Jahre von einem Marktwachstum bis zu 25 % aus. Kurzum: Wer jetzt nicht den Fuß in die Tür zu diesem gewaltigen Markt steckt, dem wird eben diese Tür bald vor der Nase zugeschlagen. Und da müssen die Projektmanager westlicher Unternehmen einige Kröten schlucken, bevor sie die Ärmel aufkrempeln dürfen. Beispielsweise droht die zähe Besprechungskunst vieler Chinesen westliche Geschäftsleute zu überfordern. Bei Besprechungen werden sich die Parteien buchstäblich in letzter Minute einig, häufig beim Abschied, manchmal erst auf dem Heimweg. China-Expertin Petra Müller versucht Verständnis für die unberechenbare und manchmal aggressive Verhandlungstaktik im Reich der Mitte zu wecken. „Das Land hat in den letzten Jahren einen enormen Wandel hinter sich gebracht“, erläutert sie, „viele Chinesen sind mit den Gepflogenheiten der Privatwirtschaft immer noch wenig vertraut.“ Verunsicherung, mangelnde Erfahrung, teils auch Selbstüberschätzung seien vielfach der eigentliche Grund für den taktierenden Verhandlungsstil und den aus westlicher Perspektive laxen Umgang mit Verträgen und Abmachungen. „Früher waren Verträge staatlich vorgegeben“, ergänzt sie, „die Vertragsfreiheit ist eine vergleichsweise junge Errungenschaft.“ Ähnlich erklärt Petra Müller auch die vermeintliche Arroganz, die viele westliche Projektmanager an ihren Partnern in China registrieren. „In der jüngeren Vergangenheit spielte das Land weltpolitisch eine geringe Rolle. Nicht vergessen ist die Zeit, als China von anderen Nationen ausgebeutet und unterdrückt wurde“, erläutert sie, „heute ist man stolz darauf, in die Liga der Welthandelsnationen aufzusteigen - und zugleich misstrauisch, dass man von außen übervorteilt wird.“ Zu den Binsenwahrheiten zählt, dass die Hierarchien in China eine weitaus entscheidendere Rolle spielen als im Westen. Eine Verhandlungsdelegation betritt den Sitzungssaal: Wer zuerst eintritt, wer zuerst grüßt und begrüßt wird, wer wo am Tisch sitzt und wer wann das Wort ergreifen darf - all dies wird von den ungeschriebenen Gesetzen der Hierarchie geregelt. Umgekehrt erwarten Chinesen Ähnliches von ihren ausländischen Partnern. Ein westlicher Delegationsleiter, dem ein „untergebener“ Mitarbeiter ungefragt ins Wort fällt, riskiert schnell den Gesichtsverlust. In diesem hierarchisch geprägten Denken haben Projektleiter einen schweren Stand, wenn sie wenige Befugnisse mit ins Land bringen. Chefs sprechen nur mit Chefs; Chinesen erwarten, dass der persönliche Status dokumentiert und erkennbar ist. Kolportiert wird der Fauxpas eines Projektleiters, der auf dem Fahrrad zur Baustelle fuhr. Dies hatte ihm ein für allemal die Autorität untergraben. „Ein Chef muss Chef-Eigenschaften haben und zeigen“, pointiert Petra Müller. Derlei feine, aber entscheidende Unterschiede machen beiden Seiten das Leben schwer. Da ist die nervenzehrende Geduld, die Projektmanager mit nach China bringen müssen - beispielsweise dann, wenn die Partner bei Besprechungen schweigen oder immer wieder das Gleiche fragen oder sagen. Da ist die Verwunderung, dass chinesische Kollegen auf Besprechungen vieles mitschreiben und dokumentieren (und bei Streitfällen Jahre später noch hervorholen können). Und da ist die Verwunderung, dass den Chinesen scheinbar die Teamarbeit im westlichen Sinne schwer fällt. Indes, sollten sich Projektmanager aus dem Westen so weit als möglich der Kultur Chinas anpassen? „Ich habe Kollegen dort kennen gelernt, die sich keinen Deut um die Befindlichkeiten geschert haben“, berichtet Maik Ullrich. Petra Müller meint, dass westliche Projektleiter gut daran tun, sich bei der Projektplanung viel Zeit zu lassen und die richtigen Partner zu finden. Was Projektmanager in China beherzigen sollten: Die Regel des „Guanxi“: Chinesen legen - bei aller scharfen Verhandlungstaktik - Wert auf gute zwischenmenschliche Verhältnisse. Bereits ein kleiner, vermeidbarer Streit kann die Beziehungen verderben, mit deren Rückenwind das Projekt günstig segelt. Direkte Konfrontation ist verpönt, dafür schätzen die meisten Chinesen strategisches und taktisches Verhalten. Dazu gehören auch eine gewisse Art der Gewitztheit und Schlagfertigkeit. So klagte ein Chinese in einer kritischen Verhandlungsphase über das mangelnde Verhandlungsgeschick seines westlichen Partners. Der gab zurück, es sei doch für seinen chinesischen Geschäftsfreund ungleich schwieriger gewesen, wenn sein Partner klüger agiert hätte. Gut pariert - die gespannte Atmosphäre Unterschiede฀zwischen฀der฀Arbeitskultur฀und฀der฀Mentalität฀erschweren฀die฀ Zusammenarbeit฀zwischen฀China฀und฀dem฀Westen. Foto: ฀BASF 42฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 43฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 löste sich in allgemeine Heiterkeit auf. Mit Hinweis auf dieses „Guanxi“, auf die guten Beziehungen, raten China-Experten übrigens zu einer besonders sorgfältigen Projektumfeldanalyse. „Alles hat seine Zeit“: In China mahlen die Mühlen langsamer - und mit unberechenbarem Tempo. „Ich habe mich in China daran gewöhnen müssen, viel Arbeit für den Papierkorb zu produzieren“, berichtet Maik Ullrich. Wobei er den Akzent eher auf ein ungleichmäßiges statt langsames Tempo setzt: Mitunter werden Probleme über Wochen ausgesessen und dann in einer Hauruck-Aktion in Nachtschichten und an Wochenenden gelöst. Und während Projekte oft monatelang nicht von der Stelle kommen, wird ein Autobahnbau quer durch ein Siedlungsgebiet in Rekordzeit von weniger als drei Jahren „gestemmt“. So erstaunt es chinaerfahrene Projektleiter immer wieder, wie Behäbigkeit in Projekten um sich greift, wie beherzt auch riskante Projekte gestartet, wie klaglos dann Misserfolge verschmerzt werden. „Die Uhren in China ticken nicht langsamer, sondern anders“, meint Maik Ullrich. Das „shuangyong“-Prinzip: Die im Westen zwischen Projektpartnern wohl bekannte Win-win-Strategie erstreckt sich in China auch auf persönliche Beziehung. So kann es sein, dass Chinesen einen „persönlichen Gefallen“ von ihren Partnern erwarten, frei nach dem Prinzip: Ich verschaffe dir in China einen Auftrag, du vermittelst mir in Deutschland einen Studienplatz für meine Tochter. Selten nur geht es um Geldbeträge, mehr darum, das Kontaktnetz des Partners zu nutzen. Ohnehin spielen in China derlei Kontaktnetze und Seilschaften, die nach dem Gesetz „eine Hand wäscht die andere“ und ständiger Beziehungspflege funktionieren, eine große Rolle. Derlei kräftezehrende Beziehungspflege, die sich auch in Einladungen ausdrückt, drückt vielen Projektmanagern aufs Gemüt. Sie, so macht ein Experte seinem Unmut Luft, „nervt auf Dauer“. „Gesichtsverlust“, die unterschätzte Gefahr: Chinesen, so berichten Landeskenner, stehen unter starkem Erwartungsdruck. Kritik an ihrer Arbeit trifft sie hart, zumal ihnen der Gesichtsverlust droht. Deshalb müssen Projektmanager in China schnell lernen, Kritik vorsichtig zu äußern, nicht direkt, immer auf Umwegen. „Das Beste ist, man lässt Chinesen selbst Fehler und Verbesserungsmöglichkeiten erkennen“, meint Maik Ullrich, „man lässt in Besprechungen Hinweise fallen, steuert das Gespräch pfiffig und gibt ihnen das Gefühl, die Lösung selbst erarbeitet zu haben.“ Ohnehin nehmen besonders ältere Chinesen ungern Rat und Anweisungen von „Rangniedrigeren“ entgegen. Petra Müller indes empfiehlt, in diesem Punkt nicht übervorsichtig zu sein: „Ein Vorgesetzter, der Fürsorglichkeit für seine Mitarbeiter ausstrahlt, hat es ungleich leichter, auch diese unangenehmen Punkte behutsam anzusprechen. Das Wichtigste ist, Vertrauen zu schaffen.“ Oliver฀Steeger Mit฀dem฀Transrapid฀exportierte฀Deutschlands฀Industrie฀schlagzeilenträchtig฀Technik฀nach฀China.฀Ihre฀ Projektmanager฀tun฀sich฀im฀Reich฀der฀Mitte฀allerdings฀schwer. Foto: ฀Siemens Anzeige Wir setzen auf Projektmanagement! 44฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 45฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3  Zweiundachtzig Fuß lang sollte die „Alster-Sonne“ werden. Da mussten die schwäbischen Ingenieure - mit nautischen Maßen wenig vertraut - nachrechnen: 82 Fuß, das sind 26,53 Meter. Doch beim Rest des Auftrags aus Hamburg war das Projektteam schnell bei der Sache. Das weltgrößte Solarboot sollten sie binnen 100 Tagen in die Hansestadt liefern. Bis zu 16 Stunden würde das Fahrgastschiff auf den Hamburger Gewässern, allein durch Sonnenkraft getrieben, über das Wasser gleiten. 96 Photovoltaik-Module auf dem futuristisch wirkenden Schiffsdach sollten Sonnenlicht in maximal 8,4 Kilowatt Strom verwandeln. Die Solartechniker der schwäbischen Vorzeige-Innovatoren Kopf AG waren über das Öko-Projekt schier begeistert. Verhalten dagegen die Schifffahrtsbehörde der Hansestadt: Wie können Ingenieure im Schwarzwald, die bestenfalls einen Fischteich vor der Tür haben, dieses Boot bauen? Nicht zuletzt ließ das durchdachte Projektmanagement sie Vertrauen fassen. Der Mittelständler wusste, was er zu tun hatte. Ein Projekt, wie es im Buche steht: technisch und methodisch Neuland Schwäbisches฀Projektmanagement฀überzeugte฀an฀der฀„Waterkant“ betreten - und das unter Termindruck. „Wir hatten am Anfang nicht mehr als eine Designstudie und die Festlegung technischer Leistungsdaten“, berichtet Projektleiter Thilo Kläger. Karl-Wilhelm von Rotenhan (Wolfram Ott & Partner), der als Coach und Berater ins Team kam, ließ sich von der Vision schnell anstecken: „Das Innovative, die Herausforderung haben mich Feuer fangen lassen. Ich habe mich sofort gefragt, wie wir das stapellauffähige Boot an einem Stück vom Schwarzwald nach Hamburg transportieren können.“ Verführerisch: Das Team spielte anfangs mit dem Gedanken, das Boot per Cargo-Lifter an die „Waterkant“ transportieren zu lassen - eine (leider unerfüllte) Hoffnung, die die Herzen der Ingenieure höher schlagen ließ. Zugleich wusste von Rotenhan, dass dieses Vorhaben Projektmanagement-Bestleistungen erfordern würde. Perfekte Planung für Termine und Aufgaben und Controlling waren erforderlich. Das junge Team erkannte schnell, dass „Projektmanagement heißt, Risiken früh zu erkennen und erst gar nicht zu einem Problem werden zu lassen.“ Dank฀Sonnenenergie฀auf฀Hamburger฀Gewässern฀unterwegs: ฀Auch฀fachmännisches฀Projektmanagement฀half,฀ das฀Solarboot฀„Ra“฀zu฀bauen฀und฀„Klarschiff“฀zu฀machen. Foto: ฀Kopf฀AG Sie schworen sich auf die Devise ein, Probleme zu erspüren und zu verhindern, bevor das Team Zeit verlor bei der Suche nach Ersatzlösungen. Von Rotenhan ergänzt: „Ohne professionelle Stakeholder- Analyse, Zieldefinition, saubere Strukturen, angemessenes Projektcontrolling und klare Rollenverteilung war dieses Prestige-Projekt nicht zu meistern.“ Denn der schwäbische Spezialist ist in Anlagenbau und Solartechnik zu Hause, nicht im Schiffsbau. So schwor Friedrich Kopf, Geschäftsführer der Kopf AG, seine 250 Mitarbeiter auf das Projekt ein: „Kein Mensch hat jemals zuvor etwas Vergleichbares gebaut.“ Sein Sohn Joachim Kopf, Geschäftsführer des Firmenablegers „Solardesign“, präzisierte: „Mit Ausnahme technischer Einzellösungen und einer Designstudie war die gesamte Vorgehensweise und das Ziel auch für uns völliges Neuland.“ Ein „echtes“ Projekt eben. Gemeinsam bauten Thilo Kläger und Karl-Wilhelm von Rotenhan ein eigenes Workflow-Management mit einfachen Mitteln auf. In einer Access-Datenbank führten sie die 16 Baugruppen des Bootes auf, dar- 44฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 45฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 Anzeige unter den Katamaran-Rumpf, die Energieanlage, das Dach und die Ruderanlage. Den Baugruppen ordnete das Team die beteiligten Mitarbeiter zu. „Über diese Datenbank konnten die Mitarbeiter kommunizieren“, erklärt von Rotenhan, also für alle einsehbare Notizen über Fortschritt und Probleme der Arbeit einstellen. „Wir haben bewusst auf E-Mail im Projektteam verzichtet, um einer transparenten, für alle zugänglichen Kommunikation den Vorzug zu geben“, erklärt von Rotenhan. Wichtiger noch: Dieses Workflow-Management strukturierte das Projekt für das Team übersichtlich in einzelne Objekte. „Viele Techniker denken in Projekten tendenziell mehr in Objekten als in Projektphasen“, weiß der Berater, „hier ist es sinnvoll, mit objektorientierter Strukturierung den Ingenieuren die Kommunikation zu erleichtern.“ Der Projektmanager allerdings müsse die anderen Blickrichtungen auf sein Projekt halten, also in Projektphasen denken oder das Projekt aus der Perspektive einzelner Abteilungen und Funktionen seines Unternehmens betrachten. Zudem adaptierte das Team die in der Automobilindustrie verbreitete „Fehlermöglichkeits- und Einflussanalyse“ (FMEA). Punkt für Punkt untersuchte das Team, welche Fehler möglicherweise am Design, an den Bauteilen des Bootes, bei den Prozessen oder in der Produktion entstehen könnten. Es prüfte Wahrscheinlichkeit und Auswirkungen der möglichen Fehler - angefangen bei technischen Problemen mit der Ruderanlage, Untersuchungen von Brand, Kurzschluss, Kollision bis hin zu Terminstörungen. „Diese Vorgehensweise beeindruckte den Kunden mit ihrer Transparenz und Systematik“, berichtet Berater von Rotenhan. Projektmanagement-Berater Wolfram Ott bestätigt: „Sie wurzelt im Qualitätsmanagement. Für prozessorientierte Projektarbeit ist dieser ganzheitliche Ansatz hervorragend geeignet.“ Auch Kunden, die nicht so sehr mit Projektmanagement vertraut sind, könnten die Kerngedanken nachvollziehen. Eben diese Transparenz beim Projektmanagement erwarten Kunden und Auftraggeber, auch dann, wenn sie mit den Instrumenten und Strategien des Projektmanagements wenig vertraut sind. „Wir haben zudem festgestellt, dass gerade risikobewusstes Projektmanagement auch bei Genehmigungsbehörden und anderen Projektpartnern gut ankommt“, meint Karl-Wilhelm von Rotenhan. „Stapellauf“฀per฀Kran: ฀Das฀Solarboot฀kommt฀pünktlich฀an.฀Das฀Projektmanagement฀überzeugte฀auch฀die฀Genehmigungsbehörden. Foto: ฀Kopf฀AG 50฀฀ NACHRICHTEN P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 51฀฀ GPM฀INTERN ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 GPM-Mitglieder: ฀ 3.029 Davon฀Firmenmitglieder: ฀ 170 Teilnehmer฀am฀Lehrgang฀„Projektmanagement-Fachmann“: ฀ 4.350 Durch฀PM-Zert฀vergebene฀Projektmanagement-Zertifikate฀insgesamt: ฀ 1.875 ฀+ +++ +++ +++ +++ +++ + ฀+ +++ +++ +++ +++ +++ + her angehende Projektmanager in mehr als 75 Kursen. Zudem bietet er seit fast zwanzig Jahren gemeinsam mit Roswitha Müller-Ettrich und Professor Heinz Schelle das Dreitages-Seminar „Projekte planen und kontrollieren“ an. 80 Mal bislang beteiligte er sich an dem „Weiterbildungs-Klassiker“ der GPM, der einen ersten fundierten Zugang zum Projektmanagement eröffnet. „Viele Teilnehmer sind heute gestandene GPM-Mitglieder“, berichtet er, „sie treffe ich auf unseren Foren oder Versammlungen wieder.“ 1996 wählten ihn die Mitglieder in den Vorstand, seit 1998 obliegen ihm die Finanzen der GPM. Der Umzug der GPM-Geschäftsstelle und der PM-ZERT-Geschäftsstelle nach Nürnberg fiel in seine Amts-  Lächelnd quittiert GPM-Vorstand Günter Rackelmann die Vergleiche mit dem Berliner Finanzminister. Ja, zwischen Hans Eichel und ihm gebe es gewisse Parallelen. „Wir müssen halt beide das Mögliche mit dem Machbaren abgleichen“, meint der Nürnberger GPM-Aktive, der in der Spitze des Fachverbands für Finanzen und Administration verantwortlich zeichnet. Also die finanzielle Großwetterlage im Auge behalten, Kompromisse suchen, wenn es ums Geld geht, unbequeme Entscheidungen verfechten und flexibel für neue Ideen sein. Günter Rackelmanns „Reich“: Ein jährliches Budget von 1,4 Millionen Euro, das er für die rund 3.000 GPM-Mitglieder verwaltet - eine zwar verantwortungsvolle, doch zumeist stille Tätigkeit. Nur einmal jährlich steht der Nürnberger richtig im Scheinwerferlicht. Dann gibt er auf der Mitgliederversammlung Rechenschaft ab für das Vorjahr, und er stellt die Budgetplanung für das nächste Jahr vor. „Da muss ich natürlich mit Fragen und Vorschlägen der Mitglieder rechnen“, sagt er. Und auch mit Kritik. Ja, so betrachtet: Da sind wirklich ein paar Ähnlichkeiten zwischen ihm und dem Berliner „Schatzmeister“. Als Finanzvorstand muss Günter Rackelmann die GPM gründlich kennen - nicht nur durch die Brille des diplomierten Betriebswirts. Seit 1982 gehört Günter Rackelmann dem Fachverband an, von 1992 bis 1997 leitete er die GPM-Regionalgruppe Nürnberg. Als einer der ersten Trainer war er beim Aufbau des Lehrgangs „Projektmanagement- Fachmann“ dabei und schulte seitzeit. Seither half er die GPM zu einer mitgliederorientierten Serviceorganisation auszubauen, stellte neue Mitarbeiter ein und sorgte für eine komplette Neuorganisation der Büroinfrastruktur. „Ich bringe hier gerne meine Erfahrung aus meinem eigenen Unternehmen ein“, meint Günter Rackelmann, der 1979 mit zwei Partnern in Nürnberg die „GCA Gesellschaft für Computeranwendungen“ gründete. Für ihn schließt sich damit gewissermaßen der Kreis. Sein Unternehmen, das heute 40 Mitarbeiter beschäftigt und (bezeichnenderweise) den Zusatz „GCA projektmanagement + consulting“ trägt, brachte ihn seinerzeit in Kontakt mit Projektmanagement. Er profitierte anfangs von dem Know-how der GPM, wie die GPM heute von seinem kaufmännischen Know-how profitiert. „Ich hatte 1979 mein Unternehmen noch gar nicht richtig auf den Weg gebracht, da wurde ich quasi über Nacht in ein Projekt gerufen“, berichtet er. Er sollte die Termin- und Kostenplanung für die Bahn- Neubaustrecke zwischen Fulda und Würzburg übernehmen. Von Projektmanagement war damals für die erste bundesdeutsche ICE-Trasse keine Rede. Ablaufplanung nannte sich das Instrumentarium, mit dem die Realisierung des 3,2 Milliarden Mark teuren Projekts mit seinen Tunneln, Gleisanlagen und seiner technischen Infrastruktur gesteuert werden sollte. In Rackelmanns Zuständigkeit fiel der 83 Kilometer lange Abschnitt zwischen Fulda und Würzburg, der heute vielbefahrene Südabschnitt. „Eigentlich hatte mich der Zufall an dieses Prestige-Projekt gebracht“, sagt Günter Rackelmann, „wir hatten das Glück, als Subunternehmer eines großen Konzerns diesen Auftrag zu erhalten.“ Was für die Bahn ein Pionier-Projekt war, hatte auch für Günter Rackelmann Pionier-Charakter. „Ich musste mich „Learning by doing“ in die Netzplantechnik und die verwendete Großrechnertechnik einarbeiten“, erzählt er. Das Projekt schloss termingerecht 1988 ab. Günter Rackelmanns Begeisterung für das Projektmanagement blieb. So konzipierte er für mehrere Großunternehmen Projektsteuerungssysteme, beispielsweise für Neubaustrecken für die staatseigene „Hochleistungsstrecken-Aktien- Günter฀Rackelmann฀-฀Projektmanager฀als฀ GPM-„Finanzminister“ Verantwortet฀1,4฀Millionen฀Euro฀für฀ die฀GPM-Mitglieder: ฀GPM-Vorstand฀ und฀„Finanzminister“฀Günter฀Rackelmann฀(Nürnberg). Foto: ฀privat฀ 52฀฀ GPM฀INTERN P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 53฀฀ ฀ P R O J E K TMANA G E M E N T ฀ 2 / 2 0 0 3 gesellschaft“ in Österreich, führte sie ein und steuerte mit seinen Mitarbeitern das Projekt. Ähnliche Projektsteuerungsaufträge folgten, beispielsweise für die Automatisierung von Europas größtem Hochregallager und den Versand der „Quelle“ in Leipzig, für die Automatisierung der Post-Frachtzentren oder für die Entwicklung der Briefsortieranlagen der Deutschen Post sowie für die Autobahn Nürnberg- Berlin. Das Ablauf- und Terminmanagement hatte ihn erstmals zum Projektmanagement geführt, und so lag es für ihn nahe, sein Know-how als Fachautor beispielsweise für das Kompendium „Projektmanagement-Fachmann“ beizusteuern. „Mich reizt am Projektmanagement das, was viele Kollegen auch reizt“, meint Günter Rackelmann, „jedes Projekt ist naturgemäß anders als das vorhergehende.“ Da kommt beispielsweise der Auftrag auf den Tisch, punktgenau binnen drei Jahren eine technische Anlage für 50 Millionen Euro aufzubauen. Nach dem ersten „Oh, Gott! “ setze der Projektmanager sein Instrumentarium ein, knote das Projekt auf, strukturiere es und führe es konsequent ans Ziel. Die Logik der definierten Schritte helfe, das komplexe Projekt zu beherrschen. „Das“, sagt der Nürnberger Familienvater, „hinterlässt die Befriedigung, es geschafft zu haben.“ Wobei es ihm im Projektmanagement längst nicht nur auf das Instrumentarium, auf die „operationale Ebene“ ankommt. „Soziale Aspekte wie Teamgeist spielen im Projektmanagement eine immer größere Rolle“, hat er im Laufe der letzten Jahre festgestellt. Häufig sei der Mensch das wichtigste und zugleich schwächste Glied in der Projektmanagement-Kette. „Ein Projektleiter muss sein Projekt, sein Team, seinen Kunden und sein Umfeld im Auge behalten“, meint er. Drei dieser vier Projektseiten seien „menschelnde“ Aspekte. „Projektmanagement ist halt ein lebendiges und entwicklungsfähiges Fach.“ Jungen Projektmanagern empfiehlt Günter Rackelmann eine gründliche Ausbildung. Und danach? „Mir ist häufig zu Ohren gekommen, dass viele Absolventen unseres Lehrganges ein oder zwei Projekte bearbeiten“, bedauert er, „dann arbeiten sie wieder in der Linie.“ Nur wenige Großunternehmen haben fortschrittliche Karrierewege für Projektmanager eingerichtet. „Das Problem ist halt, dass Projektmanager noch kein eigenes Berufsbild ist - wir in der GPM arbeiten daran.“ So rät er Projektmanagern, sich mit Seminaren, Fachtagungen und GPM-Foren weiterzubilden sowie durch Mitarbeit in GPM-Fachgruppen ihren Erfahrenshorizont zu vertiefen und durch die Zertifizierung ihre Kompetenz zu dokumentieren. „Projektmanagement hat auf jeden Fall Zukunftspotential“, so Günter Rackelmann. Als Finanzvorstand hat er festgestellt, dass Angebote in der Projektmanagement-Qualifizierung - trotz aller Konjunkturprobleme - hoch im Kurs der Weiterbildung stehen. „Trotz allgemein gegenläufigem Trend verzeichnen wir in der Projektmanagement-Ausbildung einen Boom“, sagt er, „das deutet darauf hin, dass die qualifizierten Projektmanager weiterhin gesucht werden.“ GPM-Vorstand฀Günter฀Rackelmann: ฀ „Projektmanagement฀hat฀auf฀jeden฀ Fall฀Zukunftspotential.“฀Die฀Qualifizierungs-Angebote฀der฀GPM฀boomen฀ -฀trotz฀Konjunkturschwäche฀und฀ gegenläufiger฀Trends฀in฀der฀Weiterbildung. Foto: ฀privat฀ tentagung an“, erläutert er. Auch diesmal präsentiere die Fachtagung Vorgehensmodelle für die Einführung und Nutzung von MS Project und ermögliche Teilnehmern, Entscheidungen über das Tool vorzubereiten. Auch können die Experten ihre eigene Strategie den Erfahrungen anderer Unternehmen gegenüberstellen und prüfen. „Damit wird qualitatives Benchmarking ermöglicht“, ergänzt Prof. Hasso Reschke, der derzeit das Programm vorbereitet. Neben Plenarreferaten werden sich die Teilnehmer des zweitägigen  Chancen und vor allem Grenzen des weltweit am meisten verbreiteten Projektmanagement-Tools „Microsoft Project“ wird eine GPM-Expertentagung am 25. und 26. Juni 2003 in Heidelberg ausloten. Rund einhundert Fachleute werden aktuelle Erfahrungen aus Unternehmen diskutieren, die die Software eingeführt haben und anwenden. Dabei werden sie, so Tagungsleiter Prof. Hasso Reschke, Strategien aus Industrie und Dienstleistung studieren. „Diese Konferenz knüpft an die im Herbst 2000 veranstaltete GPM-Exper- GPM-Expertentagung฀zu฀„MS฀Project“ Fachmeetings zu parallelen „Praxisplanels“ mit eigenen Themenschwerpunkten zurückziehen und beispielsweise über Einführungsstrategien, Einsatzgebiete in IT-Bereichen, Prozessunterstützung, Multiprojektmanagement und Ressourcenmanagement diskutieren. Richten wird sich die Expertentagung an Leiter von Projektmanagement- Abteilungen, Project Management Offices/ Programmmanagement, an Verantwortliche für Projekt-Controlling, an Systemverantwortliche MS Project, Projektleiter, Leiter IT, Leiter Organisation sowie an Leiter