P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 54 Auf Basis der Risikobewertung wird im nächsten Schritt eine Risikoklassifikation vorgenommen. Aufgabe der Klassifizierung ist es, die Risiken nach ihrer „Behandlungsbedürftigkeit“ zu sortieren. Es sprechen zwei Gründe dafür, nicht alle Risiken, sondern nur ausgewählte zu behandeln: ● zum einen knappe Ressourcen (Zeit, Personal und Geld), ● zum anderen die Wahrung der Verhältnismäßigkeit zwischen Schadenshöhe und Beseitigungsbzw. Minderungseinsatz. Durch die Sortierung wird die Auswahl der Risiken, die in die Risikobehandlung eingehen müssen, wesentlich erleichtert. Als unterstützende Methoden können z. B. die ABC- Analyse und die Portfolio-Technik zur Anwendung kommen. 2.1.3 Risikobehandlung In der Phase der Risikobehandlung wird untersucht und festgelegt, wie mit den zuvor identifizierten und bewerteten Risiken umgegangen, also auf sie reagiert werden soll. Risikobehandlung kann (nach [8, S. 256]) vorgenommen werden: ● ursachenbezogen/ präventiv (Risikoplanung) durch Risikovermeidung oder -verringerung, ● auswirkungsbezogen/ korrektiv (Risikovorsorge) durch volle oder teilweise Risikoüberwälzung, verbunden mit einer optimal gestalteten Selbstvorsorge. Maßnahmen zur Risikobehandlung können zum Beispiel die Eliminierung, Akzeptanz, Übertragung oder Verminderung von Risiken sein. 2.1.4 Risikocontrolling In der letzten Phase des Risk-Management-Prozesses werden die risikopolitischen Maßnahmen umgesetzt. Hierzu wird ein detaillierter Maßnahmenkatalog ausgearbeitet, in dem die einzelnen Maßnahmen und Vorgehensschritte geplant und nach zeitlicher Priorität geordnet werden. Da jedes Projekt ein dynamischer Prozess ist - neue Risiken entstehen, grundlegende Projektziele ändern sich etc. -, müssen die Wirksamkeit und der Nutzen der risikopolitischen Maßnahmen ständig überprüft werden. Die Kontrolle der Maßnahmen führt zu einer neuen Risikoanalyse. Der Regelkreis des operativen Risk Managements wird neu durchlaufen. 2.2 Risk Management im Projektverlauf Die Notwendigkeit, mit der Risikoanalyse möglichst frühzeitig zu beginnen, ergibt sich aus der Tatsache, dass Risikopotenziale in ihren Wurzeln bereits vor oder bei Projektbeginn existieren und erkennbar sind, ihre Auswirkungen und Schäden aber erst im späteren Projektverlauf zutage treten [9, S. 1083]. Aus diesem Grund ist der Risk- Management-Prozess vor Projektstart zu etablieren und in den gesamten Projektprozess als permanente (Teil-)Aufgabe des Projektmanagements einzubinden. Die Identifikation, Analyse und Bewertung von Risiken muss jeweils mit Blick auf das gesamte Projekt (Solution Delivery) und auf spezielle Aspekte der einzelnen Projektphasen Startup, Manage und Close stattfinden. Dabei treten in den entsprechenden Phasen für diese Phasen typische Risiken auf. Sie müssen identifiziert werden, damit sie den Risk-Management-Prozess durchlaufen können und somit verhindert werden kann, dass das Projekt in seinem Verlauf gestört wird. Solution Design Methoden/ Tools Checklisten Close (Projekt abschlie§en) Manage (Projekt managen) Startup (Projekt aufsetzen) S o l u t i o n D e l i v e r y P r o j e k t m a n a g e m e n t D i s c i p l i n e s Quality Management Risk Management Change Management ... Projektumfeld Schwache Signale G e r Ÿ c h te k Ÿ c h e E r h š h t e Vertrag K r a n k h e i t s q u o t e Risk Management Abb. 3: Risk Management als Projektmanagement- Disziplin im Projektverlauf (Solution Delivery) 55 Im Folgenden wird ein kurzer Überblick von Risiken gegeben, die charakteristisch in den einzelnen Phasen auftreten. 2.2.1 Startup (Projekt aufsetzen) Der Fokus des Risk Managements in der Startup-Phase liegt vor allem in der vertragsmäßigen Prüfung und den allgemeinen Gegebenheiten des Projektumfelds. Ziel ist es, mögliche Risiken zu erkennen, die den eigentlichen Projektablauf stören können. Typische Fragen zur Identifikation von potenziellen Risiken sind z. B.: ● Haben sich Annahmen und Voraussetzungen seit Vertragsunterzeichnung ge ändert? ● Gibt es einen ernannten Projektleiter für das Projekt? ● Sind Unterlieferanten am Projekt beteiligt? ● usw. 2.2.2 Manage (Projekt durchführen) Das Risk Management in den einzelnen Abwicklungsphasen des Projektes ist durch den sachlichen/ inhaltlichen Projektfortschritt gekennzeichnet. Grunds ätzlich geht es während der Projektdurchführung darum, ● bekannte Risiken aus der Vertragserstellungs- und Startup-Phase und deren Veränderung zu beobachten, ● die Wirkung der ergriffenen Maßnahmen zu bewerten und ● zus ätzliche und neue Risiken regelmäßig und ergebnisbezogen zu analysieren. Charakteristische Risikofragen in der Manage-Phase sind z. B: ● Sind alle Ressourcen wie geplant verfügbar? ● Kommt der Kunde seinen Mitwirkungspflichten nach? ● Wird der Kunde das Gesamtprojekt ohne Einschränkungen abnehmen? ● usw. 2.2.3 Close (Projekt abschließen) Das Projektende ist erreicht mit der Leistungserfüllung und der Abnahme durch den Kunden. Besonders kritisch wird es, wenn der Kunde die Abnahme aufgrund des Projektergebnisses verweigert, da er ursprünglich ein anderes Ergebnis oder Produkt gewünscht hat. Durch die Risikobetrachtung sollen solche „Fehlleistungen“ vermieden werden, was z. B. durch folgende typische Fragestellungen zur Identifikation von Risiken unterstützt werden kann: ● Wurden die vertraglichen Inhalte und Zusagen erfüllt? ● Liegt eine Projektdokumentation vor? ● Liegt eine vom Kunden unterschriebene Abnahmeerklärung vor? ● usw. 2.3 Schwache Signale als Frühwarnsystem für Projektkrisen Die bisherige Betrachtung von Risk Management ging davon aus, dass Risiken einer systematischen Behandlung auf der Grundlage des Risk-Management-Prozesses unterzogen werden müssen, um das Entstehen von Projektkrisen zu vermeiden. Ein derzeit stark vernachlä ssigter Bereich während des Projektablaufs ist jedoch das Reagieren auf „schwache Signale“. Aus diesem Grund soll dieses Thema hier, im Ansatz neu, mit betrachtet werden. Viele Projektkrisen entwickeln sich gewöhnlich aus kleinen Ursachen heraus, können aber oft zu gravierenden Konsequenzen führen. Nicht selten ist ein Scheitern bzw. Abbruch der Projekte die Folge. Diese sich anbahnenden Krisen deuten sich häufig in Form „schwacher Signale“ an, die zunächst kaum bemerkbar sind und nur durch geringfügige Diskontinuitäten der bisherigen Abläufe festgestellt werden können. Um solche „schwachen Signale“ handelt es sich bei Botschaften aus dem Projekt bzw. dem Projektumfeld, die zwar zunächst kaum wahrnehmbar sind, aber doch - falls sie sich verdichten - auf größere Diskontinuitäten schließen lassen [4, S. 12]. „Schwache Signale“ lassen sich vor allem im Umfeld von Projekten erkennen, wie z. B. durch Verfolgung von Projektmeetings und der dort aufgefangenen Botschaften. Sie können mit einer Fiebermessung verglichen werden und erfordern eine dementsprechende Auswertung. Schwache Signale sind zum Beispiel: ● erhöhte Krankheitsquote bei den Teammitgliedern ● Fernbleiben der Mitarbeiter bei Besprechungen ● erhöhte Kündigungsquote der Manage ... Risk- Management- Prozess R i s i k e n M a § n a h m e n V o r s o r g e 4. 3. 2. 1. Startup ... Close ... Abb. 4: Risk-Management-Prozess in den Projektphasen P M - F A L L B E I S P I E L / F A L L S T U D I E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 56 Mitarbeiter des Projektteams und der Firma ● zunehmende Bürokratie ● gegenseitiges Misstrauen im Team ● ausgesprochene Warnungen/ Drohungen ● Gerüchteküche ● usw. Um möglichst früh Abweichungen vom geplanten Kurs des Projektes zu erkennen, empfiehlt es sich, bereits in frühen Phasen in das systematische Risk Management ein Konzept der „schwachen Signale“ zu integrieren [4, S. 13]. So genannte Frühwarnsysteme sollen entstehende Krisen erkennen und die Notwendigkeit korrektiver Maßnahmen aufzeigen. 3 NEUER ANSATZ Untersuchungen (Interviews mit Projektleitern) haben gezeigt, dass in der Handhabung der Methoden große Unterschiede bezüglich der Aktualisierbarkeit des Detaillierungsgrades und des zu investierenden Zeitaufwandes bestehen. Nachteile liegen häufig darin, dass keine Standard-Risiko-Checklisten existieren, mit denen der Projektleiter die auftretenden Standard-Risiken nur „abzuklopfen“ braucht. Sie orientieren sich teilweise am Projektmanagement-Prozess, nicht jedoch am Risk- Management-Prozess. Mit einem neuen Ansatz wird das Ziel verfolgt, den Risk-Management- Prozess zu operationalisieren, d. h., dessen relevante Schritte darzulegen und durch eine Checkliste eine einfach zu praktizierende und schnelle Handlungsanleitung für Projektleiter und Projektteams für den einfachen Umgang mit den Projektrisiken zu geben. Dadurch soll die Bereitschaft der Projektmitarbeiter, Risk Management zu praktizieren, erhöht werden. Die erarbeitete Checkliste orientiert sich am Projektverlauf, d. h., es findet eine Dreiteilung in die Projektphasen Startup, Manage und Close statt, was dem dynamischen Charakter des Projektes entspricht (Abb. 5). Zus ätzlich zu den Risiken in den Projektphasen wird eine weitere Risikokategorie eingeführt, welche überprüft, ob im Projekt die Prozessschritte nach Solution Delivery angewendet werden. Darüber hinaus werden aber auch die „schwachen Signale“, welche im Kapitel 2.3 beschrieben wurden, mit eingebunden. Eine vierte Checklistenkategorie enthält freie Felder, in welchen individuelle Projektrisiken beschrieben werden können. Letzteres ergibt sich daraus, dass jedes Projekt dem Projektcharakter entsprechende, spezifische Risikopotenziale besitzt. Die existierenden Checklisten verallgemeinern - sie können jedoch die Risikosituation im einzelnen Projekt unter Umständen nicht vollständig beschreiben. Deshalb ist es empfehlenswert, in jedem Projekt, zus ätzlich zur Standardcheckliste eine projektindividuelle Risikoidentifikation und -analyse mit Suchfeldern durchzuführen. Zusammengefasst sind in der erarbeiteten Checkliste folgende neuen inhaltlichen Ans ätze enthalten: ● Betrachtung der Risiken im Projektverlauf (Startup, Manage, Close) Startup .... .... .... Manage Close Startup .... .... .... Manage Close Solution-Delivery- Prozesse ... -Schwache SignaleÒ ... Individuelle Projektrisiken ... Risiko-Kontroll- Dokument (Hoch/ Mittel ) Hohe/ Mittlere Risiken Abb. 5: Aufbau der Checkliste zur Durchführung des Risk- Management- Prozesses Abb. 6: Ausschnitt aus Risikocheckliste <Projektname> Risk Management Revision Number: <> <Projektleiter> Risiko-Checkliste Volume: <>, Section: <> <Projektkunde> Manage-Phase Druckdatum: <> Risiken: Trifft zu Bewertung Status/ Vermerk Manage (Projekt managen) Leistungsumfang: J N H/ M/ L Stimmt die Erwartungshaltung des Kunden mit dem definierten Leistungsumfang noch überein? Sind wichtige Aufgaben noch nicht begonnen? Projektabhängigkeiten: Gibt es negative Einflüsse aus Abhängigkeiten außerhalb des Projektes? Haben diese Auswirkungen auf das Projekt? Projektteam/ Ressourcen: Existieren soziale Konflikte? Verändert sich das Projektteam? Sind alle Mitarbeiter wie geplant verfügbar? Steht ein Projektleiterwechsel bevor? Gibt es Mitarbeiterwechsel bei „kritischen Skills“? Kommt der Kunde seinen Mitwirkungspflichten bezüglich Umfang/ Termin nach? Leistet der Unterlieferant qualitativ und terminlich wie geplant? Projektmanagement: Wird das Management des Kunden regelmäßig über 57 ● Berücksichtigung der Vorgehensschritte des Solution-Delivery- Prozesses ● Einbeziehung der „schwachen Signale“ aus dem Projektumfeld ● Berücksichtigung individueller Projektrisiken Für Risiken mit hoher Priorität (High/ Medium) wird ein Risiko- Kontroll-Dokument entwickelt. Darin sollen die in der Risiko-Checkliste identifizierten hohen und mittleren Risiken erfasst werden, damit diese dem gesamten Risk-Management-Prozess unterzogen werden können (Abb. 7). Das Besondere und Neue im anwendungstechnischen Ansatz ist, dass der Einsatz der erarbeiteten Checkliste mit dem Risiko-Kontroll- Dokument die Anwendung des gesamten Risk-Management-Prozesses auf die Risiken (hohe/ mittlere) ermöglicht. 4 ERFAHRUNGEN BEIM PRAXISEIN- SATZ UND EMPFEHLUNGEN Die Einführung von Risikomanagement in ein Projekt ist mittels des hier beschriebenen Ansatzes mit Risiko-Checkliste und Risiko- Kontroll-Dokument gelungen. Die Checkliste erwies sich als geeignetes Mittel, um Risiken zu identifizieren. Ein Schwachpunkt ist die Priorisierung der Risiken, die allein auf der Einschätzung der Projektleitung beruht. Das Bearbeiten der Risiko- Kontroll-Dokumente legt den Fokus auf die Behandlung der mittleren und hohen Risiken. Als schwierig erwies sich allerdings die Identifikation geeigneter Maßnahmen zur Risikoeindämmung. Hierbei ist großes Erfahrungswissen notwendig. Aus diesen Erfahrungen können die folgenden Empfehlungen abgeleitet werden: ● Es sollte einen Katalog erfolgswirksamer Maßnahmen zu den wichtigsten Projektrisiken geben. Neben der Nutzung des Risk Management an sich liegt hier das größte Potenzial zur Vermeidung wirtschaftlichen Schadens. ● Damit ein wirkungsvolles Risikocontrolling etabliert werden kann, empfehlen sich die Einplanung und Verfolgung der eindämmenden Maßnahmen in einem Projektplan. Um eine konsistente Sicht auf das Projekt sicherzustellen, empfiehlt es sich - entgegen anderen Ans ätzen - nicht, einen gesonderten Risikomanagementplan aufzusetzen. Stattdessen wird die Einplanung der eindämmenden Maßnahmen in den regulären Projektmanagementplan empfohlen. Der Vorteil liegt vor allem in der Praktikabilität (z. B. gemeinsame Ressourcen für Projektwie Risikomaßnahmen) und unterstützt damit den Einsatz von Risk Management. ● Aus dem Handlungsgrundsatz „separation of duties“, d. h. dem Vier-Augen-Prinzip, leitet sich die Forderung nach einem gesonderten „Risikobeauftragten“ ab. Ähnlich wie dem Qualitätsbeauftragten obliegt es dem Risikobeauftragten in Zusammenarbeit mit dem Projektleiter, Risiken zu identifizieren und zu behandeln. Damit wird einer möglichen „Betriebsblindheit“ der Projektleitung hinsichtlich der Risiken ihres Projektes vorgebeugt. 5 KRITISCHE BETRACHTUNG UND PERSPEKTIVEN DES RISK MANAGEMENTS Diese Arbeit hat eine pragmatische Vorgehensweise entwickelt, die durch einige einfache Formulare unterstützt wird. Der hier vorgestellte Ansatz deckt sowohl den Projektmanagementals auch den Risk-Manage- <Projektname> Risk Management Revision Number: <> <Projektleiter> Risiko-Kontroll-Dokument Volume: <>, Section: <> <Projektkunde> Druckdatum: <> Risiko-Kontroll-Dokument (RKD) Erstellt von: RKD-Nummer: Erstellt am: Status (aktiv/ nicht aktiv): Risiko Owner: Priorität (High/ Medium): Kurzbeschreibung: Risiko-Beschreibung Abb. 7: Ausschnitt aus Risiko- Kontroll- Dokument P M - F A L L B E I S P I E L / F A L L S T U D I E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 58 ment-Prozess ab, indem er parallel zum Projektmanagement-Prozess die phasenrelevanten Risiken behandelt, die dann dem Risk-Management-Prozess unterzogen werden. Ebenfalls neu bei dieser Vorgehensweise ist die Berücksichtigung von individuellen Projektrisiken und der „schwachen Signale“, die vor allem im Projektumfeld auftauchen und künftige Projektkrisen anzeigen. Durch den Einbezug aller dieser Punkte soll erreicht werden, Projekte schon in der jeweiligen Vorphase mit Risk Management zu behandeln, um sie vor einem Scheitern weitestgehend zu bewahren. Trotzdem bleiben offene Punkte. So ist z. B. ein Maßnahmenkatalog zur Eindämmung der gängigsten Projektrisiken wünschenswert. Des Weiteren bleibt die Frage nach dem „Risikobeauftragten“ offen. Natürlich kann es einen „Risikobeauftragten“ aus Kostengründen nicht geben. Aber die Funktion „Risikobeauftragter“ kann z. B. als neue Aufgabe und Herausforderung von den Qualitätssicherungsbeauftragten übernommen werden. Neben diesen methodischen Verbesserungen bleibt anzumerken, dass zwar das Bewusstsein für die Relevanz von Risk Management existiert, in der Praxis aber, vermutlich aus Zeit- und Kostengründen, nicht ausreichend gelebt wird. Als Ausblick bleibt festzuhalten, dass die Bedeutung von professionellem Risk Management in Zukunft stark zunehmen wird, da die Innovationszyklen immer kürzer werden und Projekte somit mit einem sich ständig ändernden Umfeld konfrontiert werden. ■ Literatur [1] Beyeler, Andreas: Risikomanagement komplexer Projekte. In: Management-Zeitschrift IO, Heft 4, Jg. 1994, S. 27-30 [2] GPM Deutsche Gesellschaft für Projektmanagement e.V. Region Stuttgart/ Karlsruhe. Regional Nachrichten Nr. 15, Jg. 1998 [3] Deutsches Institut für Normung: DIN 69 901. Projektmanagement-Begriffe. Berlin 1987 [4] Dreger, Wolfgang: Schwache Signale als Krisen-Frühwarnungen. In: PROJEK TM ANAGE - MENT, Heft 3, Jg. 1998, S. 12-16 [5] Franke, Armin: Risiko- Controlling bei Projekten des Industrieanlagenbaus. In: Controlling, Heft 3, Jg. 1997, S. 170-179 [6] Kellner, Hedwig: Die Kunst DV-Projekte zum Erfolg zu führen. Budgets, Termine, Qualität. München 1994 [7] Kleinaltenkamp, Michael/ Plinke, Wulff: Auftrags- und Projektmanagement. Projektbearbeitung für den Technischen Vertrieb. Berlin-Heidelberg-New York 1998 [8] Patzak, Gerold/ Rattay, Günter: Projekt Management. Leitfaden zum Management von Projekten, Projektport folios und projektorientierten Unternehmen. Wien 1996 [9] Rohrschneider, Uwe: Risikomanagement. In: Rationalisierungs-Kuratorium der deutschen Wirtschaft e.V. (Hrsg): Projektmanagement Fachmann. 4. Auflage, Hemsbach 1998, S. 1081-1113 [10] Schnarrenberg, Uwe/ Göbels, Gabriele: Risikomanagement in Projekten. Methoden und ihre praktische Anwendung. Braunschweig-Wiesbaden 1997 [11] Wischnewski, Erik: Frühwarnsysteme im Projektmanagement: Wie Sie Risiken erkennen und Probleme vermeiden. In: Gabler’s Magazin, Heft 4, Jg. 1997, S. 42-44 [12] Wischnewski, Erik: Modernes Projektmanagement: PC-gestützte Planung, Durchführung und Steuerung von Projekten. 5. Auflage, Braunschweig-Wiesbaden 1996 Autorin Dipl.-Betriebsw. Daniela Freund, Jahrgang 1978, studierte an der Verwaltungs- und Wirtschaftsakademie Stuttgart. Bei der Firma IBM Deutschland GmbH besch ä ftigte sie sich wä hrend ihres Studiums u. a. mit den Themen Projektmanagement, Risk Management und Vertrieb von Services. Seit 1999 ist sie bei debis Systemhaus GmbH im Bereich Service Management tätig. Anschrift debis Systemhaus GmbH Fasanenweg 15 D -70771 Leinfelden-Echterdingen Tel.: 07 11/ 9 72-53 84 Fax: 07 11/ 9 72-51 91 E -Mail: dfreund@debis.com Betreuer Dipl.-Inform. Dieter Hirsch, Jahrgang 1943, studierte Informatik an der TU Karlsruhe. Anschließend arbeitete er bei der Robert Bosch GmbH, Karlsruhe u. a. in den Bereichen Anwendungsentwicklung, Marketing und Projektmanagement. Seit 1984 arbeitet er bei der IBM Deutschland GmbH in Stuttgart in unterschiedlichen Bereichen wie z. B. Großkundenbetreuung für Lean Manufacturing, Qualitätssicherung, PM. Sein besonderes Engagement gilt der „Kompetenz in Projektmanagement“ und der damit verbundenen Projektleiter- Qualifikation. Er ist Initiator und Betreuer einer Vielzahl von Diplomarbeiten aus dem Themenbereich des praktischen Projektmanagements. Seit 1994 ist er Mitglied der GPM und pflegt den aktiven PM-Erfahrungsaustausch. Anschrift IBM Deutschland GmbH Hanns-Klemm-Straße 45 D -71034 Böblingen Tel.: 0 70 31/ 6 42-68 21 Fax: 0 70 31/ 6 42-62 04 E -Mail: dhirsch@de.ibm.com 59 E in Unternehmen entwickelt neue Produkte, führt eine neue SAP-Software ein, baut ein neues Fertigungswerk im Ausland auf. Alles wird nach bestem Wissen und den Methoden des Projektmanagements geplant, gesteuert und abgeschlossen. Dennoch gibt es während des Projekts lange Diskussionen, was besser hätte laufen können: Hat der Projektleiter seine Befugnisse genutzt? Wer ist für die anschließenden Änderungen verantwortlich? usw. Der Projektleiter greift daher zu PM DELTA, um seine Projektarbeit zu optimieren. Der Handzettel informiert ihn über PM-Standards und über die Notwendigkeit einer einheitlichen Sprachregelung. Er erfährt etwas über die Gliederung, die hier in Anlehnung an die DIN 69 904 in 19 „Elemente“ vorgenommen wurde, die alle relevanten Aspekte eines Projekts von der „Zieldefinition“ bis zur „Dokumentation“ beleuchten. Das Ergebnis der Selbstdiagnose wird dann in einem Spinnennetzdiagramm dargestellt und soll die Stärken und Schwächen der Projektarbeit offen legen. Etwas irritiert liest unser Projektleiter den „Ausblick“ im Handzettel. Die CD soll einen Anschub liefern, Assessoren der GPM zu engagieren, einen Lehrgang zum PM-Fachmann zu besuchen, Komponenten des PM- Systems mit PM-Beratern weiterzuentwickeln und sich an dem Deutschen PM Award zu beteiligen. Handelt es sich hier um verstecktes Akquisitionsmaterial der GPM? Daran denkt unser Projektleiter zunächst nicht - er will wissen, wie sein Projekt optimiert ablaufen müsste, und legt die Scheibe auf. Er findet eine übersichtliche und einfach zu bedienende Oberfläche vor. Er sieht die 19 Elemente, die er vom Handzettel bereits kennt, und klickt eines an. Er findet Fragen vor, die er nur mit „Ja“ oder mit „Nein“ beantworten kann. Will er Hilfe zu einer Frage, erhält er sie über die PM-Standard-Taste. Die Fragen werden hier verdeutlicht, und er findet auch einen Literaturverweis auf ISO, ICB, DIN und PMF-Wissensspeicher. Diese Literatur hat er natürlich nicht neben sich liegen. Nach mehreren Fragen ist ein Element abgeschlossen. Unser Projektleiter wählt als erstes Element die „Zieldefinition“. Vielleicht gab es bei dem Projekt damit Probleme. Erste Frage: „Werden zu Beginn eines Projekts Ziele systematisch erfasst? “ Eine Gewissensfrage - natürlich hat der Projektleiter alle vorher gefragt. Aber war das ausreichend? „Ja“ oder „Nein“? Er möchte gerne 80 % angeben, wird aber zur Vereinfachung gezwungen. Hier zeigt sich eine Schwäche der Scheibe. Bekanntlich unterscheiden wir zwischen offenen und geschlossenen Fragen. Die ersteren ermöglichen ordinale oder kardinale Abstufungen, die letzteren sind nur mit „Ja“ oder „Nein“ zu beantworten. Die Fragen lassen sich bei Unternehmen, die Projektmanagement fortgeschritten betreiben, nach meiner Erfahrung nur quantifiziert beantworten. Möglicherweise etwas gemildert wird das Problem, indem die Fragen offensichtlich in einer nicht genannten Art hierarchisch gegliedert sind, so dass abhängig von der gegebenen Antwort oft weitere Fragen nicht berücksichtigt werden. Bei der Auswertung geht die Klarheit in der Bedienerführung etwas verloren. Vom Hauptmenü kommt man über einen Link zur „Auswertung“ und kann dann entscheiden, ob diese exportiert oder angezeigt PM DELTA Die Selbstdiagnose für optimales Projektmanagement PM DELTA. Die Selbstdiagnose für optimales Projektmanagement. GPM Deutsche Gesellschaft für Projektmanagement e. V., Nürnberg 2000. PM-Fragen-/ -Antwortkatalog auf CD-ROM DM 598,00, PM-Benchmarking-Auswertung auf Diskette/ E-Mail DM 68,00, zuzügl. Porto und Verpackung. GPM-Mitglieder erhalten 10 % Rabatt. P M - B U C H B E S P R E C H U N G P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 60 werden soll. Dann erscheint ein Link zur „Anzeige Stärken und Schwächen“. Wer den Link „Drucken“ betätigt, druckt noch lange nichts aus, sondern kommt zu einem Menü, aus dem heraus gedruckt werden kann. Also Vorschlag: das erste Menü „Anzeigen und Drucken“ nennen, das folgende Menü mit „Auswertung eines Elements“ kennzeichnen und statt drucken „Druckmenü“ schreiben. Und wenn dort auch noch stünde, dass die Elemente, die man gedruckt haben will, im Kä stchen anzukreuzen seien, dann wäre die Bedienerführung perfekt. Der etwas erfahrene PC-Benutzer lernt es auch durch Probieren, aber das muss nicht sein. Die Auswertung selbst wird nicht einsichtig beschrieben. Der Anwender erhält zunächst eine Prosabeurteilung. Hat unser Projektleiter die beispielhaft herangezogene Frage mit „Nein“ beantwortet, erfährt er aus der Auswertung, dass ein „Projekt stets mit der Festlegung seiner Ziele beginnen sollte und diese zwischen Projektteam und Auftraggeber zu vereinbaren sind“. Wählt er „Ja“, wird ihm mitgeteilt, dass mit der systematischen Erfassung der Projektziele die erste unverzichtbare Voraussetzung für den Projekterfolg geschaffen wird. Viel bringt das dem gestandenen Projektleiter nicht. Der nächste Schritt, die Erstellung des Spinnendiagramms, ist nirgendwo erläutert. Wie ergibt sich aus dem Fragenmaterial eine quantifizierte Größe? Es müsste eigentlich so sein: Bei jeder Frage wird ermittelt, wie wichtig sie für den Projekterfolg ist, dann wird das Vorhandensein dieses Merkmals im Projekt quantitativ hinterfragt und daraus ergäbe sich ein schlüssiges Maß über das Verbesserungspotenzial. So wäre ein Bezug zum Unternehmen gegeben. Es ist oft eine Schwäche bei der Lehre von Projektmanagement, den Unternehmenskontext aus dem Auge zu verlieren. Dabei genügt es, eine einfache Kontrollfrage zu stellen: Was bringt Projektmanagement mit seinen Methoden substanziell dem Unternehmen? Damit zusammen hängt auch die Frage: Ist Projektmanagement ein universelles Tool, oder muss es auf Branchen und Projekttypen zugeschnitten werden? Unternehmen leben in verschiedensten Branchen, Projekte müssen es vermutlich auch. Was bei FuE-Projekten die Schwierigkeit bei der Überführung einer Entwicklung in die Fertigung ist, stellt sich bei Bauprojekten als das Vertragsmanagement und bei Organisationsprojekten als der menschliche Faktor heraus. Nicht alle Projektmanagement-Methoden sind für alle Projekte gleich erfolgsträchtig. Der Rezensent hat die Erfahrung gemacht, dass Projektmanagement wie das Leben ist: bunt, vielfältig überraschend und schwer in eine verkürzende Systematik zu pressen. Hilfreich wären auch Hinweise zur Dramaturgie und zu Personen, die sich der Scheibe bedienen können, wie der Projektleiter, das Projektteam, der Auftraggeber - oder alle zusammen? Wird die Untersuchung zu Beginn, in der Mitte oder am Ende des Projekts durchgeführt? Bei der Anwendung werden die Autoren feststellen, wie wichtig diese Festlegung ist. Was hat unser fiktiver Projektleiter nun gelernt? Was macht er mit dem Gelernten? Ich möchte vermuten, dass für große umfassende Projekte viele Anregungen entnommen werden können, nicht so sehr bei kleineren und einfacheren Projekten. Den Autoren ist der Mut, ein solches Diagnosesystem erstellen zu wollen, nicht abzusprechen. Möge es ihnen gelingen, ihre Scheibe weiterzuentwickeln und auf die erfolgsrelevanten Faktoren der zahlreichen Projekttypen in den diversen Branchen der Industrie und der Institutionen auszudehnen, um so dem Anwender eine konkrete Hilfestellung für sein konkretes Projekt zu geben. Je allgemeiner nämlich die Fragen gestellt sind, desto unverbindlicher sind die Antworten und die Ratschläge. ■ Autor Prof. Dr.-Ing. Walter Kä stel, Jg. 1947, Studium der Physik, Aufbaustudium Betriebswirtschaftslehre. Industriepraxis in der Entwicklung messtechnischer Geräte. Veröffentlichungen auf dem Gebiet der Mess- und Regelungstechnik und des Projektmanagements. An der Fachhochschule Heilbronn, Außenstelle Künzelsau, Schwerpunkt Mess- und Regelungstechnik sowie Projektmanagement.