eJournals

PROJEKTMANAGEMENT AKTUELL
pm
2941-0878
2941-0886
UVK Verlag Tübingen
121
2000
114 Gesellschaft für Projektmanagement
P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 4 Zusammenfassung Projektport folio-Management - das Gestalten und Lenken der gesamten Projektlandschaft - findet als Disziplin in den Unternehmen zunehmend Beachtung. Zurückzuführen ist diese Entwicklung auf die wachsende Zahl der Projekte und auf die stets knappen personellen und finanziellen Ressourcen. Projektport folio-Management setzt sich aus verschiedenen Teilprozessen zusammen. Multiprojekt-Ressourcenmanagement nimmt dabei eine herausragende Stellung ein. Neben den ablauforganisatorischen sind auch die aufbauorganisatorischen Voraussetzungen zu schaffen: Als übergeordnete Instanz ist ein Projektportfolio-Entscheidungsgremium einzurichten, das die Verantwortung für die Zusammensetzung und Lenkung des Projektport folios trä gt. Im Bereich Projektmanagement sind heute verschiedene Informatiklösungen verfügbar. Das Angebot an geeigneten Projektportfolio-Management-Tools hingegen ist klein - insbesondere im Bereich Multiprojekt-Ressourcenmanagement. Abstract Project Port folio Management - managing and driving all your projects - is finding acceptance as an individual discipline in many companies today. The reason for this is the increase in the number of projects that most companies have as part of their strategic planning, coupled with the scarcit y of resources and their time, thus the need for a comprehensive resource management. Project Portfolio Management is a roll-up of several individual processes. Workload, or Resource Management, is the most important of these processes. Apart from the workflow process, the structures of a company also need to be defined. All these combined should be steered by a Project Port folio Steering Committee, who have the responsibilit y for prioritising projects and defining the work matrix of ongoing operations and individual projects or programmes. There are several tools available today to help manage these processes. However, the offering of effective project portfolio management tools is small, especially in the area of managing resources over multiple projects at one time. Schlagwörter Controlling des Projektport folios, Ideenmanagement, Projektevaluation, Projektportfolio-Management, Projekt vorbereitung, Ressourcenmanagement, Ressourcenplanung W ettbewerbsvorteile und Anpassung an Veränderungen sind nur über gezielte Projektarbeit zu erreichen. Viele erfolgreiche Einzelprojekte machen jedoch noch kein erfolgreiches Projektmanagement aus. Dies aus zwei Gründen: Erstens müssen die Ziele der einzelnen Vorhaben nicht nur in sich schlüssig sein, sie müssen in ihrer Gesamtheit - dem Projektportfolio - optimiert werden. Und zweitens muss dieses Projektportfolio zur Unternehmensstrategie passen. Beide Ansprüche werden erst durch ein funktionierendes Projektportfolio-Management erfüllt. Projektportfolio-Management - einige Autoren verwenden auch den Begriff Multi-Projektmanagement - beinhaltet verschiedene, voneinander abhängige Prozesse. Die Prozesse werden im ersten Teil dieses Beitrags beschrieben. Im zweiten Teil folgen eine Beschreibung der in diesem Zusammenhang relevanten Rollen und Gremien und eine Darstellung der Projektportfolio-Management-Prozesse mit der Regelung der Zuständigkeiten. Den Abschluss bilden einige Gedanken zum Einsatz von EDV-Tools und zur Einführung des Projektportfolio- Managements im Unternehmen. Projektportfolio-Management T H O M A S S C H O L I A N 5 1 PROZESSE DES PROJEKTPORTFOLIO- MANAGEMENTS 1.1 Strategisches Management des Projektportfolios Das Projektportfolio eines Unternehmens oder einer Organisation ist so zu gestalten, dass die Unternehmensziele bestmöglich erreicht werden beziehungsweise die in der Unternehmensstrategie formulierten Maßnahmen umgesetzt werden. Das strategische Management des Projektportfolios ist das Instrument zur Gestaltung des unternehmensweiten Projektportfolios (siehe Abb. 1). Das strategische Management des Projektportfolios dient der Initiierung und Freigabe neuer Projekte, fallweise aber auch dem Abbruch laufender Projekte. Der Fokus liegt dabei in erster Linie auf Projekten mit mittlerer und hoher strategischer Bedeutung bzw. auf Projekten, die hohe Kosten verursachen. Solche strategischen Projekte sind meist bereichs- oder abteilungsübergreifend und erfordern die Aufmerksamkeit des oberen Managements. Das Projektportfolio soll auf die Unternehmensstrategie ausgerichtet sein. Ideen für neue Projekte sind daher auf ihre Verträglichkeit mit der Strategie zu prüfen. Wichtiger ist aber, dass neue Projekte bewusst und gezielt aus der Strategie heraus entwickelt und umgesetzt werden. Die jährliche Strategieübung reicht hierzu nicht aus, diese Aufgabe benötigt permanente „Management Attention“. Sind im Jahresbudget des Unternehmens oder der Bereiche kleinere und mittlere Projekte als Pauschalen budgetiert, müssen für teure, strategische Projekte rechtzeitig entsprechende Budgets vorgesehen werden. Eine flexible, d. h. das Jahresbudget durchbrechende Budgetierung ist daher unerlä sslich, um neue, Erfolg versprechende Projekte nicht ins nächste Geschäftsjahr verschieben zu müssen. Eine vierteljährliche Überprüfung und Anpassung des Jahresbudgets sind durchaus angebracht. 1.2 Ideenmanagement Projekte werden vielfach durch Verbesserungsvorschläge und Ideen der eigenen Mitarbeiter angestoßen. Ein eigentliches Ideenmanagement drängt sich daher auf. Das Ideenmanagement hat nun aber nicht zum Ziel, möglichst viele Ideen, sondern möglichst gute Ideen zu gewinnen. Ideenmanagement heißt aber auch, Ideen zu bewerten und der weiteren Verwendung zuzuführen. Dazu muss das Ideenmanagement unternehmensweit organisiert werden [6]. 1.2.1 Ideen erzeugen Ideenmanagement tangiert alle Hierarchiestufen. Die Zeiten, in denen allein das Management für Innovationen zuständig war, sind längst vorbei. Es gilt, den Ideenreichtum und das Kreativitätspotenzial „aller“ Mitarbeiter auszuschöpfen. Eine konstruktiv-kritische Haltung und Eigeninitiative auf allen Stufen sind dafür die beste Voraussetzung. Eine solche Haltung ist allerdings nicht von einem Tag auf den anderen zu erreichen. Mit geeigneten Methoden lassen sich Ideen systematisch erzeugen. Bekannt sind verschiedene Kreativitätstechniken wie Brainstorming, Methode 635, Wettbewerbe usw. Aber auch andere Maßnahmen führen zu neuen Ideen. Beispielsweise lassen sich aus dem Resultat einer Risikoanalyse Ideen für die Weiterentwicklung eines Produktes ableiten. Auch der Markt - die Kunden, die Mitbewerber, die Lieferanten - liefern Ideen. Diese schier unerschöpfliche Quelle soll jedoch nicht nur gefiltert via Außendienstmitarbeiter, sondern auch über andere Kanäle erschlossen werden. Informationen über das Unternehmen und Ideen für neue Projekte sollen möglichst breit zugänglich sein: Nur informierte Mitarbeiter können konstruktiv mitdenken! Konkret Unternehmens- Strategie Strategisches Management des Projektportfolios Ideenmanagement Projektevaluation und -priorisierung Multiprojekt- Ressourcenmanagement Controlling des Projektportfolios Projekt- Vorbereitung Unternehmens- Controlling Auftraggeber/ Lenkungs ausschuss Projektleiter/ Projektteam Management/ Alle Projektportfolio - Entscheidungs gremium Unternehmens- Leitung Einzelprojekt - Management Projektbearbeitung Abb. 1: Die Projektportfolio- Management- Prozesse und -Gremien in der Übersicht P M - G R U N D S A T Z B E I T R A G P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 6 kann dies beispielsweise eine übergreifende Ideenliste im Intranet sein, in der alle Mitarbeiter ihre Anregungen und Vorschläge eintragen können. 1.2.2 Ideen bewerten Damit jeder Verbesserungsvorschlag und jede Projektidee auf ihre Verwendbarkeit geprüft werden kann, sind die Erfassung und eine stufengerechte Bewertung der Ideen zu organisieren und zu institutionalisieren. Es gilt, die Prozesse, die Zuständigkeiten, die Kriterien und die Periodizität festzulegen. Im Rahmen der Ideenbewertung werden die Prioritäten festgelegt: Priorität 1 bedeutet beispielsweise, eine Idee unverzüglich weiter zu verfolgen und sie der Projektvorbereitung (siehe unten) zuzuführen, Priorität 2 kann bedeuten, die Idee weiter zu verfolgen, sobald Ressourcen verfügbar sind. Priorität 3 heißt, Ideen werden vorläufig nicht bearbeitet, aber in die Ideen-Datenbank aufgenommen. Eine weitere Unterscheidung ist das Potenzial einer Idee: Ideen mit Potenzial A könnten zu einem Projekt mit hoher strategischer Bedeutung führen. B-Ideen deuten auf ein mittleres, abteilungs- oder bereichsinternes Projekt und Potenzial C auf kleinere, lokal abzuwickelnde Vorhaben hin. 1.2.3 Das Ideenmanagement organisieren Ein durchgängiges Ideenmanagement ist nur zu erreichen, wenn dem Ideenmanagement der notwendige Stellenwert eingeräumt wird, die erforderlichen Mittel und Ressourcen bereitgestellt werden und Ideenmanagement als Führungsaufgabe verstanden wird. Hauptakteur ist das Linienmanagement. Darüber hinaus ist aber auch jeder Projektleiter zuständig für das Ideenmanagement innerhalb seines Projektes. Für den Aufbau und die Betreuung des Ideenmanagements sollte ein haupt- oder nebenamtlicher Ideenmanager (evtl. pro Organisationseinheit) bezeichnet werden. Voraussetzung für diese Tätigkeit sind sowohl eine kreative als auch eine systematische Ader und genügend Kapazität. Der Ideenmanager wird auch die Dokumentation und den Zugang zu den Ideen sicherstellen und eine Ideendatenbank aufbauen, wobei hier mit einfachen Mitteln bereits viel erreicht werden kann. 1.3 Projektvorbereitung Die Projektvorbereitung dient haupts ächlich der Konkretisierung der in diesem Stadium noch meist vagen Ideen und Vorschläge und schafft bestmögliche Voraussetzungen für das künftige Projekt. Kern der Projektvorbereitung sind das Erkennen und Formulieren derjenigen Projektziele, die dem Unternehmen den größten Nutzen bringen. Ob das Projekt freigegeben wird, entscheidet sich im Anschluss an die Projektvorbereitung im Rahmen der Projektevaluation (siehe unten). Die Projektvorbereitung ist eine eigene Phase, in der mit geringem Aufwand erste wichtige Erkenntnisse zum Projekt gewonnen werden und die Stoßrichtung für das Projekt festgelegt wird. Die Projektvorbereitung soll nicht als Ersatz für die Vorstudie gesehen werden. 1.3.1 Auftragsklärung und Abstimmung mit Auftraggeber Zur Klärung einer Projektidee oder eines Auftrags empfiehlt sich ein Start-Brainstorming. Ein temporär zusammengestelltes Team behandelt dabei Fragen wie: Welche Informationen fehlen? Gibt es alternative Projektdefinitionen? Was sind mögliche Bedürfnisse und Ziele des Ideenlieferanten/ Auftraggebers? Mit welchen Risiken ist zu rechnen? Welche Chancen bieten sich? Was 148 156 … Strategiekompatibilität 4 4 16 5 20 Gewinnpotenzial 16 62 70 - Volumenpotenzial total 4 3 12 4 16 - Positionierung 4 4 16 5 20 - Vermarktungsaufwand 2 3 6 3 6 - Verbreitungsmöglichkeit 2 5 10 5 10 - aufwandfreier Umsatz 2 5 10 5 10 - Folgeaufträge 2 4 8 4 8 Volumensicherheit 2 4 8 4 8 Realisierungsfrist 5 4 20 4 20 Umsetzungsrisiko technisch 3 4 12 4 12 Projektaufwand 2 4 8 3 6 Konkurrenz 2 4 8 3 6 Abhängigkeit von Partnern 2 5 10 5 10 Synergien mit anderen Produkten 2 2 4 2 4 Total 38 Kriterien Gewicht Projekt 1 Projekt 2 … Abb. 2: Auszug aus einem bewerteten Projektportfolio 7 sind mögliche Kontaktpersonen und Ideenlieferanten? Welche Lösungsans ätze sind denkbar? Eine besondere Bedeutung gewinnt die Klärung der Projektdefinition: Hier geht es nicht in erster Linie um die Frage, was der Ideenlieferant bzw. Auftraggeber tun oder nicht tun will, sondern haupts ächlich um die Frage, ob nicht eine alternative Formulierung der zur Diskussion stehenden Projektidee zu einem Projekt mit noch höherem Nutzwert führen kann. Da diese Diskussion häufig nicht geführt wird, wird in den ersten Tagen vieler Projekte die Hälfte des Erfolgspotenzials verschenkt! Was hat nun die Auftragsklärung mit Projektportfolio-Management zu tun? Wenn aus einer scheinbar unbedeutenden Idee zur Verbesserung eines Produkts letztlich ein Projekt zur Entwicklung einer neuen Produktlinie wird, dann eben sehr viel! Die Projektleiter müssen ermutigt werden, in diesem Sinne einen Auftrag konstruktiv zu durchleuchten und den Auftraggeber zu führen! 1.3.2 Erstplanung des Projektes Ist die Projektdefinition zwischen dem Projektleiter und dem (potenziellen) Auftraggeber bereinigt, erfolgen erste grobe Schätzungen der Termine, Kosten und Aufwände sowie erste Überlegungen zu Nutzen und Wirtschaftlichkeit des Vorhabens. Diese Daten bilden wichtige Entscheidungsgrundlagen für die Projektfreigabe. 1.4 Projektevaluation und -priorisierung Die Evaluation und Priorisierung eines Projektes erfolgen im Anschluss an die Projektvorbereitung. Wichtiger Bestandteil der Evaluation ist, P M - G R U N D S A T Z B E I T R A G P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 8 Projekte ihrem „Gewicht“ entsprechend in Klassen einzuteilen. 1.4.1 Kriterien zur Bewertung eines Projektes Hier trifft man von der unsystematischen, intuitiven Bauchentscheidung bis hin zur komplexen, EDVgestützten Projektevaluation alles an, was man sich vorstellen kann. Praxistaugliche Systeme liegen irgendwo in der Mitte. Es empfiehlt sich sehr, die Bewertungskriterien überschaubar zu halten. Gut gemeinte, aber oft übertriebene Systematik kann hinderlich, ja gefährlich sein. Zur Bewertung eines Projektes sind in erster Linie zwei Fragen zu beantworten: Was ist der Beitrag zur Unternehmensstrategie (qualitativer Aspekt), und was ist der erwartete wirtschaftliche Nutzen (quantitativer Aspekt)? Zus ätzlich zu berücksichtigen sind Risiken und weitere Rahmenbedingungen: Beitrag zur Unternehmensstrategie: Das Projekt ist zu überprüfen bezüglich: Verträglichkeit mit der Firmenstrategie; Grad der Verstärkung der Kundenorientierung; Ausmaß der Verbesserung der Produktqualität; Potenzial zur Beschleunigung von Prozessen, Durchlaufzeiten und Lieferfristen; Nutzen für die längerfristigen Auswirkungen auf das Image des Unternehmens; Auswirkungen auf andere bestehende Produkte, Leistungen und Projekte usw. Wirtschaftlichkeit: Hier interessieren die prognostizierten Projektkosten inkl. Investitionen, der erwartete Ertrag bzw. die Einsparungen und die Betriebskosten des zu erstellenden Produkts. Risiken hinsichtlich der Zielerreichung: Zu hohe Risiken technischer, terminlicher oder wirtschaftlicher Art können dazu führen, dass das Projekt nicht freigegeben wird. Rahmenbedingungen: Voraussetzung für den Projekterfolg ist die Verfügbarkeit des benötigten Knowhows, der personellen Ressourcen und der finanziellen Mittel. Abb. 2 zeigt beispielhaft einen Auszug aus einem bewerteten Projektportfolio. 1.4.2 Projektklassen Durch das Einteilen von Projekten in Klassen lassen sich die für die Abwicklung anzuwendenden Methoden und Regelungen einheitlich festlegen sowie die zuständigen Entscheidungsgremien bezeichnen: Die Geschäftsleitung soll sich ja nicht um die Ausarbeitung einer neuen Parkplatzordnung kümmern müssen (Projekt der Klasse B), aber zur Verfügung stehen, wenn neue Märkte erschlossen werden sollen (Projekt der Klasse A)! Abb. 3 zeigt ein mögliches Raster, nach dem die Projekte in Klassen eingeteilt werden können. Welche Auswirkungen die Einteilung der Projekte in Klassen haben kann, zeigt beispielhaft Abb. 4. 1.5 Multiprojekt-Ressourcenmanagement Jeder CEO nennt heute die Mitarbeiter als das wichtigste Kapital des Unternehmens. Mutet es demzufolge nicht grotesk an, wie fahrlä ssig Unternehmen mit diesem Kapital teilweise umgehen? Während das finanzielle Controlling auf den Beitrag hoch A A A an die mittel B B A Strategie gering C B A gering mittel groß Mittelbedarf Abb. 3: Einteilung der Projekte in Klassen Abb. 4: Maßnahmen und Regelungen in Abhängigkeit von der Projektklasse Übergeordnete Entscheidungen Lenkungsausschuss Bereichsleiter Auftraggeber Auftragsanalyse, Start-Brainstorming und Auftragsklärung ja ja dringend empfohlen Projektorganigramm (Grafik) ja empfohlen nein Anwendung Road Map zwingend zwingend empfohlen Planung mit Planungstool ja fallweise fallweise Erfassung in Projektportfolio-Tool ja ja falls Aufwand > 10 Tage Analyse der Projektrisiken ja ja empfohlen Mitlaufende Projektkostenverfolgung ja ja nein Formaler Management-Report ja nein nein Projekt-Reviews ja empfohlen nein Projekt-Coaching Regel auf Anfrage nein Maßnahme/ Regelung A B C Projektklasse P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 10 Cent heruntergebrochen wird, werden Entscheide beim Einsatz der personellen Ressourcen weitgehend willkürlich getroffen. Ein zuverlä ssiges quantitatives Controlling des Personaleinsatzes fehlt in den meisten Organisationen. Maßgeblich beteiligt an dieser Situation ist ein falsches Rollenverständnis. Die Verantwortung für das Ressourcenmanagement wurde und wird in den Lehrbüchern dem Projektleiter zugeordnet. Ressourcenplanung kann aber so nicht funktionieren: Das Management der personellen Ressourcen ist - in Abstimmung mit den Anforderungen des Projektleiters - eine Hauptaufgabe des Linienmanagers [7]. Für die Evaluation und Priorisierung von Projekten sind in der Ressourcenplanung oft Projekte zu erfassen, die noch nicht detailliert geplant wurden und für die noch kein Projektleiter ernannt worden ist. Schon daran ist zu erkennen, dass Ressourcenplanung nicht primär die Aufgabe des Projektleiters sein kann. Ressourcenplanung erfolgt auf grober Projektstufe.Kürzere Projekte (Wochen bis Monate) brauchen nicht weiter gegliedert zu werden, länger dauernde Projekte wird man in Phasen zerlegen. Schon die steigende Datenmenge und damit der Aufwand für die Datenpflege hindern daran, zum Zweck der Ressourcenplanung die Projekte weiter zu gliedern, ganz abgesehen davon, dass die Planungsgenauigkeit mit zunehmendem Detaillierungsgrad keineswegs zunimmt. Völlig falsch ist daher der Ansatz, die projektübergreifende Ressourcenplanung auf die einzelnen Tätigkeiten, wie sie der Projektleiter für seine Ablauf- und Terminplanung benötigt, abzustellen. In einer Sackgasse endet auch der Versuch, das projektübergreifende Ressourcenmanagement mit herkömmlicher Projektmanagement-Software zu bewältigen.Hier helfen nur spezifische Tools weiter, die auf die Bedürfnisse der Linienmanager und Ressourcenverantwortlichen ausgerichtet sind. Noch wichtiger als die Wahl des richtigen Tools ist jedoch, die für das Ressourcenmanagement erforderlichen Prozesse und Rollen zu definieren und dafür zu sorgen, dass sie gelebt werden [8]. Größere Organisationen unterscheiden zwischen strategischer und operativer Ressourcenplanung. Die strategische Ressourcenplanung dient der längerfristigen Personalplanung auf der Stufe Gruppe oder Abteilung, die operative Ressourcenplanung entspricht der kurz- und mittelfristigen Einsatzplanung einzelner Personen und Gruppen. 1.6 Controlling des Projektportfolios (operative Ebene) Das Controlling des Projektportfolios hat nicht das einzelne Projekt im Fokus, sondern die Gesamtheit der Projekte. Controlling beschränkt sich dabei nicht auf die finanziellen Aspekte, sondern umfasst ebenso die terminlichen und inhaltlichen Komponenten. Zum Unternehmens- Controlling bestehen Schnittstellen, nicht zuletzt natürlich im Bereich Kosten/ Investitionen. Das Controlling des Projektportfolios ist ein kontinuierlicher Prozess. 1.6.1 Benötigte Daten Eine vollständige Projektliste ist der erste Schritt in Richtung Controlling des Projektportfolios. Für ein umfassendes Controlling müssen Abb. 5: Multi-Projektcontrolling im Projektportfolio-Tool ResSolution 11 aber - neben der Darstellung der aktuellen Belastungssituation - für alle Projekte mindestens folgende Daten verfügbar sein: ● eindeutige Projektidentifikation (Projekttyp/ -klasse, Termine, Status, Auftraggeber, Projektleiter), ● Kurzbeschreibung des Projektes, ● Kurzbeurteilung (z. B.: OK, gefährdet, kritisch/ Maßnahmen dringend erforderlich) und ● Termine, Aufwände und Kosten (Istwerte, voraussichtliche Restwerte, ursprüngliche Planwerte). 1.6.2 Mögliche Maßnahmen im Anschluss an die Analyse des Projektportfolios Entsteht aufgrund der Analyse des Projektportfolios Handlungsbedarf, sind folgende Maßnahmen denkbar: ● Projektziele werden angepasst, ● einzelne Projekte werden verzögert oder beschleunigt, ● zus ätzliche Mittel und Ressourcen werden zur Verfügung gestellt oder ● Projekte werden zu Gunsten anderer Projekte abgebrochen. Abb. 5 zeigt beispielhaft eine mit ResSolution erstellte Controlling-Ansicht. ResSolution ist ein bei Scheuring Projektmanagement entwickeltes Projektportfolio-Management-Tool. 2 ROLLEN UND GREMIEN IM PROJEKT- PORTFOLIO-MANAGEMENT Abb. 6 stellt schematisch die aus Sicht des Projektportfolio-Managements relevanten Gremien dar. 2.1 Auftraggeber und Lenkungsausschuss In der Regel ist der Auftraggeber der Nutznießer des Projektes und wird alles daransetzen, „sein(e)“ Projekt(e) in möglichst guter Qualität abzuschließen. Er bietet dem Projektteam seine Unterstützung an und trägt die Verantwortung für das Controlling seines Projektes. Die Rolle des Auftraggebers ist mit dem Projektabschluss beendet und damit zeitlich befristet. Es ist ein Muss, für jedes Projekt einen definierten, bekannten, die Interessen des Projektes vertretenden Auftraggeber zu bezeichnen. Die Repräsentationsrolle reicht hier nicht. Der Projektleiter muss ungehinderten Zugang haben zum Auftraggeber und dieser muss sich auch Zeit für die Führung des Projektleiters nehmen. Falls ein Lenkungsausschuss installiert wird, übernimmt der Auftrag- P M - G R U N D S A T Z B E I T R A G P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 12 geber die Rolle des Leiters des Lenkungsausschusses. Für die „mittleren Entscheidungen“ im Alltag steht dem Projektleiter ein Sponsor, ein Vertreter des Lenkungsausschusses, als Ansprechpartner zur Verfügung. Die Aufgaben des Auftraggebers bzw. des Lenkungsausschusses sind ● Formulierung des Projektauftrags (zusammen mit dem Projektleiter), ● Freigabe des Projektes in Abstimmung mit dem Projektportfolio- Entscheidungsgremium (siehe unten), ● Freigabe der einzelnen Projektphasen sowie der Entscheid über den Projektabschluss, ● Unterstützung des Projektleiters bei Interessenkonflikten und ● Sicherstellung der Projekterfolgskontrolle in Absprache mit dem Projektleiter. Mit der Rolle des Auftraggebers allein ist dem Projektportfolio-Management jedoch noch in keiner Weise Genüge getan. Erst das Projektportfolio-Entscheidungsgremium schafft die Voraussetzungen für eine umfassende Führung des Projektportfolios. 2.2 Projektportfolio-Entscheidungsgremium Die den Auftraggebern und Lenkungsausschüssen übergeordnete Instanz ist das Projektportfolio-Entscheidungsgremium. Meist entspricht in der Praxis dieses Gremium der (erweiterten) Geschäftsleitung. Das Projektportfolio- Entscheidungsgremium ist projektübergreifend tätig und ist damit zeitlich nicht befristet. Es tagt beispielsweise vierteljährlich. Für große, strategische Projekte kann die Geschäftsleitung zus ätzlich die Rolle des Auftraggebers einnehmen. Das Projektportfolio-Entscheidungsgremium trägt die Verantwortung für ● die periodische Evaluation und Priorisierung des gesamten Projektportfolios, ● die strategische Planung der personellen Ressourcen aller Projekte und Aufgaben, ● die Prüfung und Freigabe der Projekte, insbesondere der Klasse A, ● das Setzen von Projektprioritäten sowie das Fällen von Entscheiden bei Kapazitätsengpä ssen und ● das Fällen von mehrere Projekte betreffenden Entscheiden. 2.3 Projektportfolio-Controllingstelle Die Aufgaben der Projektportfolio- Controllingstelle werden in der Regel von der Projektmanagement-Stelle (Projektmanagement-Office, Projektmanagement-Servicestelle) wahrgenommen. Diese Stelle ist auch für den Aufbau und die Pflege des Projektmanagements sowie für die Unterstützung und das Coaching in den Einzelprojekten zuständig [9]. Die Projektmanagement-Stelle soll organisatorisch so eingebunden sein, dass ein direkter Zugang zur Leitung der entsprechenden Organisationseinheit besteht. Weiter soll sie über ausreichend Kapazität verfügen. Die Aufgaben und Verantwortung der Projektportfolio-Controllingstelle sind ● Führen der übergeordneten Ideenliste und Vorprüfung der Ideen, ● Entscheidungsvorbereitung bezüglich Projektevaluation und -priorisierung, ● Führen des Projektportfolios, ● Unterstützung und Coaching bei der quantitativen Ressourcenplanung und ● Planung und Leitung der periodischen Sitzungen des Projektportfolio-Entscheidungsgremiums. 2.4 Linienmanager Projekte „stören“ den Betrieb, den die Linienmanager sicherstellen sollen. Es gilt, diesen Interessenkonflikt zwischen Projektmanagern und Linienmanagern zu einer konstrukti- Projektportfolio- Entscheidungsgremium Projekt-Lenkungsausschuss Auftraggeber (Leiter Projekt- Lenkungsausschuss) Projektportfolio- Controllingstelle Linienmanager Projektteam Projektleiter Abb. 6: Gremien im Projektportfolio- Management 13 ven Partnerschaft zu entwickeln. Die Beziehungen zwischen Projektleitern und Vorgesetzten der Projektmitarbeiter sind daher besonders intensiv zu pflegen - von beiden Partnern! Linienmanager werden durch zunehmend projektorientierte Organisationen nicht in Frage gestellt, sondern erhalten Freiraum für die eigentlichen Linienaufgaben. Sie können sich endlich der Ressourceneinsatzplanung sowie der langfristig wirksamen Optimierung der Prozesse, der Strukturen, der Instrumente, vor allem aber der Fähigkeiten zuwenden. Künftig werden sich Linienmanager noch stärker als Coach, als Ressourcenmanager verstehen, aber auch als Wissensmanager, als Organisatoren und nicht zuletzt als Personalentwickler. Starkes Projektmanagement lä sst starke Linienmanager nicht nur zu, es ist auf diese angewiesen! 3 PROJEKTPORTFOLIO- MANAGEMENT-ROAD-MAP Die Road Map beschreibt - analog einem Funktionendiagramm - sowohl die Prozesse als auch die Zuständigkeiten der verschiedenen Stellen und Funktionen. Die Projektportfolio-Management-Road-Map darf ohne Übertreibung als der Schlüssel zum erfolgreichen Projektportfolio-Management bezeichnet werden. Eine vollständige, allgemein akzeptierte Road Map bedeutet ja, dass man sich über die Prozesse und die Zuständigkeiten einig ist. Gelingt es, diese Einigkeit zu erreichen, ist man dem Ziel, einem funktionierenden Projektportfolio-Management, ein gutes Stück näher gerückt. Abb. 7 zeigt einen Ausschnitt aus einer Projektportfolio-Management-Road-Map für einen Bereich. 4 COMPUTERGESTÜTZTES PROJEKTPORTFOLIO-MANAGEMENT 4.1 Paradigma-Wechsel bei den Tools Lange Zeit setzten Tools im Bereich Projektportfolio-Management und Ressourcenplanung auf die Detailplanung der Projektleiter. Auslastungsinformationen sollten aus der Konsolidierung aller Projektpläne generiert werden. Die dabei gemachten schlechten Erfahrungen reichen inzwischen aus, diesen Ansatz definitiv zu verwerfen. Die toolmäßige Integration von Detail-Projektplanung und Projektportfolio-Management erweist sich nämlich als außerordentlich problematisch. Ein Beispiel einer solchen Problematik soll hier genügen: Wer soll die „Hoheit“ über die Projekttermine haben? Der Projektleiter, der durch Verändern seiner Termine die gesamte Ressourcenplanung übersteuern kann, oder der Ressourcenmanager, der den Terminplan des Projektleiters manipuliert? Absprachen sind hier unbedingt nötig, auch wenn der Gedanke an eine Integration der Tools die Erwartung weckt, dass sich solche Absprachen durch die Integration erübrigen. Das „Zwei-Welten-Konzept“ - die Führung der beiden Welten „Einzelprojekte“ und „Projektportfolio“ in getrennten Tools - drängt sich auf. P M - G R U N D S A T Z B E I T R A G P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 14 Nicht nur die Erfahrungen des Autors, auch jene anderer Berater und Systemanbieter sprechen klar für die Trennung der beiden Ebenen. Anders zu beurteilen ist die „horizontale Integration“ auf der Ebene des Projektportfolio-Managements. Darunter versteht man die Integration der Funktionen Terminmanagement, Ressourcenmanagement und Kostenmanagement. Hier ist die Integration anzustreben, und Schnittstellen zum Finanz- und Rechnungswesen sind sehr sinnvoll (Abb. 8). Langsam beginnen sich Systeme durchzusetzen, die exklusiv auf das Projektportfolio-Management spezialisiert sind. Diese Tools, die im Rahmen des Projektportfolio-Managements vor allem die Ressourcenplanung professionell unterstützen, unterscheiden sich von den bisherigen integrierten Systemen in ihrem Konzept und im Handling grunds ätzlich. 5 PROJEKTPORTFOLIO-MANAGEMENT EINFÜHREN Die bisherigen Ausführungen beschreiben den anzustrebenden Endzustand. Den Abschluss dieses Beitrags bilden einige Gedanken zum Projekt „Einführung Projektportfolio-Management“. Projektmanagement einzuführen setzt die Unterstützung des Managements voraus. Die Einführung von Projektportfolio-Management hingegen erfordert aktive Konzeptarbeit durch das Management. Projektportfolio-Management tangiert so viele Geschäftsprozesse, dass Konzepte, die nicht im eigenen Hause entwickelt worden sind, keine Akzeptanz finden. Umgekehrt können neue Konzepte zur Anpassung bestehender Prozesse führen. Die Road Map zwingt zu einer durchaus erwünschten Verbindlichkeit. Neue Prozesse werden definiert und Zuständigkeiten werden teilweise neu geregelt. Dies setzt auf verschiedenen Ebenen ein Umdenken voraus, und nicht zuletzt hat dies auch Auswirkungen auf die Unternehmenskultur. Zur erfolgreichen Einführung von Projektportfolio-Management sind demzufolge auch die Veränderungen im kulturellen Bereich aktiv zu unterstützen. Projektmanagement und Projektportfolio-Management lassen sich unabhängig voneinander optimieren. Um Synergien nutzen zu können und um die Konzepte später nicht nachbearbeiten zu müssen, ist die parallele Bearbeitung aber entschieden vorzuziehen. Die Projektleitung für das Projekt Projektportfolio-Management kann nicht Sache des externen Beraters sein. Ein solches, tief in das Unternehmen eingreifendes Projekt braucht eine bestmögliche Verankerung. Ein externer Berater kann dies nicht leisten. Umgekehrt fehlt in den Unternehmen meist das Know-how, um Projektportfolio-Management einzuführen. Das Berater-Wissen ist da durchaus gefragt. Das Projektmanagement-Office Prozess/ Aufgabe Periodizität Projektportfolio- Entscheidungsgremium Auftraggeber Projektleiter Projektmitarbeiter Gruppenleiter Abteilungsleiter Bereichsleiter Projektportfolio- Controllingstelle … Ideenmanagement Ideen entwickeln laufend A A A A A A A A Ideen klassifizieren und dokumentieren laufend M V A-Ideen bewerten periodisch V M M A B-Ideen bewerten periodisch M V Projektvorbereitung Entscheid Projektvorbereitung situativ A- Ideen B- Ideen M Start-Brainstorming, Auftragsklärung, Erstplanung situativ M V Projektklassifikation situativ A-Projekte B-Projekte Projektfreigabe situativ A-Projekte B-Projekte Genehmigung der Projektorganisation situativ V … Projektführung … Period. Aktualisierung der Ressourcenplanung monatlich M V M M Übergeordnete Entscheidungen/ Phasenfreigaben Meilensteinbezogen V M … A = Ausführung; M = Mitarbeit; V = Verantwortung; A/ B-Projekte = Verantwortlich für A/ B-Projekte Abb. 7: Ausschnitt aus einer Projektportfolio- Management- Road-Map für einen Bereich P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 16 sollte rasch eingerichtet werden. Im Idealfall kann der Stelleninhaber den Aufbau des Projektportfolio-Managements - z. B. das Erfassen der Projektliste und die Einführung des Ressourcenmanagements - aktiv unterstützen. Es versteht sich von selbst, dass die Einführung von Projektmanagement und Projektportfolio-Management ein äußerst anspruchsvolles Organisationsprojekt mit einer starken IT-Komponente darstellt. Eine starke Führung durch die Projektleitung und ein professionelles Coaching durch den externen Berater sind Voraussetzung für das Gelingen dieses Vorhabens. Genauso wichtig ist nach Projektabschluss aber die Pflege des Systems. 6 FAZIT Das Management des Projektportfolios ist zentrales Mittel bei der Umsetzung der Unternehmensstrategie. Neue Konzepte, Denkmuster und Instrumente müssen diese Aufgabe professionell unterstützen. Dem Ressourcenmanagement kommt dabei eine hervorragende Bedeutung zu. ■ Literatur [1] Patzak, Gerold/ Rattay, Günter: Projekt Management. Leitfaden zum Management von Projekten, Projektport folios und projektorientierten Unternehmen. 3. Auflage, Linde Verlag, Wien 1998, S. 401-450 [2] Patzak, Gerold/ Rattay, Günter: Projekt- Portfoliomanagement. In: PROJEK TM ANAGE - MENT 3/ 96, S. 3-9 [3] Lange, Dietmar: Mehrprojektmanagement. Projektmanagement-Fachmann. 5. Auflage RK W, Eschborn 1999, S. 773-799 [4] Nelson, Beebe/ Gill, Bob/ Spring, Steve: Building on the Stage/ Gate. In: PROJEC T M ANAGEMENT INSTITUTE 28th Annual Seminars & Symposium. Chicago, Illinois: Papers Presented September 29 to October 1, 1997 [5] Hirzel, Matthias: Mit Multiprojektmanagement das Innovationspotential ausschöpfen: Zweck, Wertigkeit und Reihenfolge ausschöpfen. In: Gabler’s Magazin 5/ 98, S. 10-13 [6] Haller, Christine: Wie Ideen gedeihen. In: io management 5/ 97, S. 20-26 [7] Scheuring, Heinz: Ressourcenplanung: Sache des Linienmanagers! Bereinigung einer Altlast bei den Tools. In: PROJEK TM ANAGE - MENT 3/ 96, S. 22-26 [8] Scheuring, Heinz: Knappe Ressourcen effizient managen. In: Hirzel, Leder & Partner (Hrsg.): Fokussiertes Business Design. Gabler, Wiesbaden 1997, S. 209-222 [9] Büscher, Klaus/ Simon, Markus: Professionalisiertes Projektmanagement bei der General Accident Versicherungs-AG durch Einführung „Project Office“. In: zfo Zeitschrift Führung und Organisation 3/ 99, S. 167-171 Autor Thomas Scholian, Dipl.- Physiker ETH, arbeitet seit 1992 als Consultant und Trainer bei Scheuring Projektmanagement in Kaiseraugst (Schweiz). Er ist zustä ndig für den Produktbereich Projektport folio-Management. Nach dem Studium war er wä hrend über zehn Jahren in der Industrie tätig und leitete umfassende Projekte zur Entwicklung komplexer optischer Messsysteme. Er ist einer der ersten in der Schweiz zertifizierten Projektmanager und seit bald vier Jahren für den Verein zur Zertifizierung von Projektmanagern als A ssessor tätig. Anschrift Scheuring Projektmanagement Junkholzweg 1 CH-4303 Kaiseraugst Tel.: ++41/ 61/ 8 16 96 36 Fax: ++41/ 61/ 8 16 96 26 E -Mail: thomas.scholian@scheuring.ch Termin- Management Ressourcen - Management Kosten- Management F & RW Projekt/ Phase Arbeitspaket Aktivität Integriertes Multiprojekt-Controlling Einzelprojekt- Terminplanung Funktion Ebene Abb. 8: Die zwei Welten bei den Projektmanagement-Tools 17 Zusammenfassung Risiko treffen wir in allen Projekt vorhaben an; dies trifft besonders für FuE -Vorhaben und somit auch für die bekannten Raumfahrt vorhaben zu. In diesem Artikel werden die Methoden des Risikomanagements, wie sie in der Raumfahrt angewendet werden, vorgestellt. Es wird aber gleichzeitig darauf verwiesen, dass diese Methoden selbst verstä ndlich auch in anderen Industriezweigen angewendet werden können. Die Vorgehensweise ist absichtlich breit angelegt, um den vollen Umfang des Problems aller Industriezweige zu erfassen. Wenn die Methode erst einmal eingeführt ist, kann das Verfahren periodisch verbessert und erweitert werden, ohne den Gesamtprozess neu zu beginnen. Es wird mit Nachdruck empfohlen, dass die eingeführte Methode des Risikomanagements stä ndig aktualisiert wird, um mit den verä nderten Projektzielen und Umgebungsbedingungen Schritt halten zu können. Abstract This paper identifies a risk management approach that may be applied to a broad range of business activities within any industry. The approach was developed for the aerospace industry from risk management principles that are believed to represent “universal truths” about risk. It is purposely a broad and comprehensive approach in order to capture the full scope of problems that may be encountered in any business or project. Once implemented, the approach can be updated periodically without having to recreate the entire process. It is strongly recommended that any risk management approach be kept updated so the results are always aligned with changing business objectives and environments. Schlagwörter Maßnahmen zur Risikovermeidung, Risikobewertung, Risikoidentifikation, Risikomanagement, Risikovermeidung, Risikowahrscheinlichkeit 1 INTRODUCTION Risk is an inherent ingredient in nearly all enterprises. Risk is simply - “What can go wrong? ” In the space industry, there are many highly visible examples of what can go wrong - launch vehicle failures, satellite deployment problems, launch delays, etc. These failures are not caused only by hardware problems - software errors, and even management deficiencies have been found to cause some spectacular failures. The industry fights these problems with vigorous programs for Product Assurance and Quality Assurance, not to mention ISO 9000, 6-Sigma Quality, Zero Defects, and many other well-intentioned (and successful) programs. Certainly all of the industry participants fully support and execute these programs, with countless reviews and endless documentation to assure the project success. But still the failures occur. The truth is that space systems are comprised of rather complex pieces of equipment, often operating in P M - V E R F A H R E N / K O N Z E P T E Risk Management Lessons from Space for all Managers J A M E S B . D U F F Y P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 18 extreme conditions. Once deployed, these systems have limited tolerances for failure and no opportunity for maintenance or repair. Even small problems can thus have serious consequences. Any review of space system failures over the years will reveal that anything and everything can go wrong. Fortunately, not everything will go wrong for any one company. A company can not really prevent failures from occurring, but it can minimise the frequency and impacts of failures. A good Risk Management Program will accomplish this by actually managing the failures before they happen. The key is thus to recognise risk management as a basic management function - as basic as managing costs and schedules. Once it has been recognised that risk management is a management function, it will become quickly apparent that risk is not random. The frequency of risk events (failures) may be estimated by statistical means, but the events themselves are not created by randomly generated forces. There are underlying reasons why failures occur, reasons that may even be caused by competitive forces. Risk management should therefore focus on strategies for managing risk, not just rely on statistical processes that forecast a probability of loss. 2 A RISK MANAGEMENT APPROACH 2.1 Objectives Even for the most successful businesses, future enterprises may not be as successful as past experiences. Rather than gamble on success, a conscious and organised approach to success should be followed. A risk management program is a management tool that can be used to examine projects (or businesses in general) at any stage of their planning or execution. An examination of risk should identify where the project might experience problems, how severe the problems might become, and what can be done to prevent the problems. At the very least, the risk management program should identify how to minimise the impacts of the problem, but this may include problem prevention, intervention (containment), or recovery. A risk management program must also not only identify risks, but must also quantify the risks. The ultimate and true measure of risk is cost. A risk management program must provide a means of measuring the risk in terms of the amount of additional costs (cost exposure or value at risk) the company is exposed to. All companies are exposed to a certain amount of risk in their core operations, regardless of what strategies are employed or projects undertaken. Every strategy and project will provide its own incremental (but different) risk to the overall company success. The risk management program should thus measure the overall cost risk that a company must manage, and the incremental cost risks introduced by any contemplated or current projects. 2.2 A Recommended Approach to Risk Management A basic approach that is recommended for any risk management program is shown in Fig. 1. It is a complete and thorough sequence of activities, which is intended to encompass the entire business enterprise. Some of the activities may not need to be performed every time a risk assessment or risk analysis is performed. Data from previous risk analyses should be checked, however, to ensure that they are still consistent with current company priorities and objectives. Risk Environment: This phase is to clearly establish the environment in which the business is operating and to identify sources of risk to the company that may not exist now, but could develop under certain future scenarios. This phase requires a risk analyst to examine the business environment to determine recent trends in products, technologies, and in the product marketplace. This phase will help to establish what levels of risk are acceptable - or required. Internal Risks External Risks Market Environment Company Environment Business Environment Risk Event Criticality Risk Prevention Tactics Risk Exposure Risk Management Plan Risk Envelope The Risk Environment Risk Identification and Characterisation Risk Management Risk Measurement Fig. 1: Four Phases of a Risk Management Approach 19 Risk Identification and Characterisation: This phase is where a list of problems is generated - What could go wrong? Such a list could obviously become quite extensive, so a method is proposed which will narrow the list of potential problems to only those which are most relevant to the company objectives. Such a method will prove to be very useful when company objectives or strategies change in the future. Risk Management: This phase is where specific tactics to deal with the risks are identified. Tactics are actions that can be taken to prevent risks from occurring or to minimise the impacts when the risk does occur (for example, launch insurance). Risk tactics have their own costs however, which must also be accounted for by the company. Tactics are often implemented only under certain (negative) conditions. The implementation of risk tactics must be planned so the decision to implement them results in the remedy being in place when it is needed. Risk Measurement: This phase summarises the costs of the most likely risk events (including any risk prevention measures). The costs should be expressed in terms relevant to the company business plan. 2.3 Phase 1: Risk Environment The major sources of risk will be found both within the business and in the business’ external environment. It is important that all sources of risk be considered; otherwise the Achilles Heel may not be discovered. There is always some level of risk that is acceptable to a business, but this level varies as the business environment and company experiences change. It is important that this level of risk be understood by the risk analyst at the beginning of any risk assessment. Internal sources of risk are well known to every manager and are generally within the control of management. These risks are usually detected quickly and thus cause only low to moderate impacts. These risks include cost and schedule problems, engineering problems, test failures, and manufacturing or quality problems. External sources of risk are generally not within the control of management, and are usually the greatest risks to a business or project. These most dangerous sources of risk include new technologies, new or stronger competitors or products, and political or environmental changes. It is also important to note that these external sources of risk are constantly changing! It is important to try to anticipate these changes and avoid exposure to risk by actively searching for trends in the market. Note also that internal company organisations and operations are often a reflection of the business external environment. Everywhere the business interfaces with the external environment is also where the environment can introduce risks. Understanding these interfaces and their sensitivity to change is helpful in evaluating the potential for additional internal risks. 2.4 Phase 2: Risk Identification Once all sources of risk are understood, the actual risks (or risk events) must be identified - this could be a very large task. To develop a list of everything that could go wrong is a nearly perpetual task, and certainly would take too much time and effort to be useful. A process to generate a meaningful subset of problems is necessary. One process that has been found very effective for this purpose is Quality Function Deployment (QFD). The QFD process is normally used to transmit the “Voice of the Customer” down into a product design. In the risk identification application, QFD is used to transmit the P M - V E R F A H R E N / K O N Z E P T E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 20 most important needs of the business down into the large pool of potential risks. Using QFD in this manner, a rather short list of problems (risks) can be identified which represents only the most important risks that must be actively managed. The problem list is also directly linked to specific company requirements or objectives. When requirements or objectives change, the information can be readily updated and a new list of most relevant risks identified. Having created a list of potential significant problems (risk events) for the business, they must be prioritised so effort is not spent managing risks which are not of great significance or have very low probability of occurrence. To quickly prioritise a potentially large list of risks, a rather easy and fast criticality assessment can be performed. A numerical formula is available from standard risk assessment practices to calculate the criticality of a risk event based upon the probability and the consequence of occurrence. Risk Criticality = [Probability + Consequence] - [Probability × Consequence] The definition of the scales to be used for Probability and for Consequence can be rather arbitrary. A numerical scale from zero to one must be used, but any definition of the scale values that fit the needs or conditions of the business (or project) is acceptable. The objective is not to calculate an exact value, but only to rank the risks in order of importance (Criticality). For risks that are of very high criticality and consequence to the business, further risk analysis should be performed to fully understand the risk. A good process for this deeper risk analysis is the Failure Modes Effects and Criticality Analysis (FMECA). The FMECA is a standard process applied to aerospace hardware and software systems. For risk assessment, the process is applied more to the business elements and the effects being investigated are to the business - not to a hardware element. As is normally done in hardware FMECAs, multiple failure (risk) events need to be considered and analysed. 2.5 Phase 3: Risk Management There are no special procedures for identifying risk prevention or risk reduction methods. This phase is a time and place where creativity is valuable. The only criterion is that all critical risk events should be covered. Every industry seems to have a basic set of self-protection methods that range from tolerance to risk reduction, risk prevention, and ultimately intervention. These levels of risk protection are related to the acceptability of the loss event (not always expressed in terms of cost). Concepts such as insurance imply a willingness to tolerate the event, whereas nuclear power plants provide entire systems to intervene in (and recover from) risk events. Past practices used in an industry are usually time-proven and can be expected to continue to work, but new environments often require new solutions. Examination of risk prevention tactics from other industries often generates some interesting concepts. A sample of industries that employ strong “risk management” practices, and some characteristics of their practices, is provided in table 1. The risk protection methods selected to reduce or prevent risks (costs) will also cost money to implement. The resources to implement any risk protection method must be Industry Risk Acceptability Risk Management Characteristics Insurance Tolerance Probabilistic forecasting of risk, minimal or no actions to reduce or prevent risks Investment banking Reduction Probabilistic forecasting of risk, plus strategic planning to reduce risk exposure Aerospace (development) Reduction Subjective forecasting of risk, risk reduction actions implemented usually only after the risk event (recovery) Amusement parks Prevention High reliability and redundancy, plus barriers installed to prevent risk event occurrence Nuclear power Strong Intervention Multi-redundant systems to prevent risk, systems to monitor and detect risk sources, plus systems installed to recover from risk events Table 1: Industries that employ strong “risk management” practices and some characteristics of their practices 21 estimated and included in the business operating costs. It is useful to estimate the amount by which a tactic will actually reduce the project risk. A cost/ benefit ratio will aid in the selection of which risk protection methods to actually implement. There is no certainty that any of the identified risks will actually occur, but it is also certain that not all of the identified risks will occur. The actual amount of risk to plan for lies somewhere between these extremes. It is important that a “best estimate” (risk envelope) be developed of the actual risk losses the project will encounter in order that appropriate budgets will be established to deal with the risks (including to fund the risk protection tactics). One or more future scenarios of risk events that might occur should be developed. Past experience will give a good indication of what can be expected, but can also give a false sense of security. Several combinations of risk event scenarios should be developed to examine the full range of possibilities. The range should include not just the expected (nominal) combinations, but more importantly the worst case (feared) combinations of risk events. In such situations, a decision analysis technique called the Analytical Hierarchy Process (AHP) has been found most useful. To execute the selected risk protection tactics, many actions will be required. These actions must be time phased (planned) such that the protection is in place when the risk is likely to occur. Decisions to implement (or to not implement) any of the actions must also be appropriately timed, including the failure and decision criteria for risk events. All such information should become part of an overall Risk Management Plan that is actively reviewed and updated. 2.6 Phase 4: Risk Measurement With a “most likely” risk envelope (or scenario) and a selected set of risk protection tactics, the total risk exposure of the business or project can be estimated. The anticipated costs of both the risk events and the planned risk protection tactics should be estimated and time-phased. These costs may then incorporated into the business financial planning. This will reveal the true costs of risk exposure that the business must manage. For those risk events that are external to the business and that may occur randomly, risk identifiers should be identified. Risk identifiers are not too difficult to find if the risk event can be identified and understood. The key is to find identifiers that provide early detection of the event and thus more time to react to it. It is important to note that external risks are rarely truly random - somewhere, somebody causes these events to occur! 3 CONCLUSIONS The recommended approach for risk management should be expected to accomplish several objectives for any company or project. ● Identification of the most significant risk events to be managed ● Identification of the best approaches to deal with the risks ● Identification of the full cost exposure due to risk (risks and risk management actions) Further details of the execution of this approach have been developed for specific companies. It is found that individual company (or project) characteristics will begin to dominate the details of the approach at lower levels. Indeed, any risk management program should be carefully tailored to the needs and resources of the company. A risk management program that is based on the above approach, however, will be found to provide a comprehensive view of the risk exposure that nevertheless still produces a reasonable set of problems to manage. ■ References [1] King, Bob: Better Designs in Half the Time. GOAL/ QPC, M A. 1989 [2] Lasker, Edward: Chess Strategy. Dover Publications, N.Y. 1959 [3] Saat y, Thomas L.: Multicriteria Decision Making. The Analytical Hierarchy Process. 2nd ed. Pittsburgh, PA, RWS Publications, 1996 [4] Qualit y Function Deployment. Application Guide. Training seminar by Technicomp, 1986 Author James B. Duffy has been a project manager and system engineer for Rockwell International (now the Boeing Company) for twent y years. He held technical management positions on projects such as the Space Shuttle, the National AeroSpace Plane (NASP, X-30), and the X-33 Reusable Launch Vehicle. He founded TeraSim A ssociates two years ago to provide management and system engineering consulting services to the aerospace industry in Europe. Address TeraSim A ssociates Südliche Auffahrtstraße 47 D -80639 München Tel.: 0 89/ 17 99 83 07 E -Mail: jim.duffy@t-online.de P M - V E R F A H R E N / K O N Z E P T E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 22 Zusammenfassung Es wird versucht, die quantitative Wirkung von Risikovorsorge und -bewältigungsmaßnahmen zu ermitteln. Dazu werden die bedrohlichen Risiken identifiziert und die Maßnahmen im Ablauf eines Projektmodells beschrieben. Am Beispiel einer Neuentwicklung eines Serienproduktes wird die dramatische Zeit- und Budgetunterschreitung deutlich, wenn Risikomanagement als konsequente konstruktive Vorgehensweise betrachtet wird. Abstract In the paper there is made an attempt to calculate the quantitative value of risk reduction. Therefore the most dangerous risks are identified and the actions are described in context with a project model. The development of a new serial product is used to show the outstanding time and budget reduction which results from a consequent and constructive practice in risk management. Schlagwörter Aktionszyklen, Projektmodell, Risikomanagement, Risikoport folio, Risikoursachen, Team Expert Choice 1 RISIKOANALYSE UND BEWERTUNG 1.1 Was sind Risiken? Im üblichen Sprachgebrauch bezeichnet man mit Risiken Wagnisse und Gefahren. In der Wirtschaft versteht man darunter die Verlustgefahr, die mit jeder Unternehmung verbunden ist. Diese kann verursacht werden z. B. durch betriebliche Störungen, Fehlinvestitionen, Zahlungsunfähigkeit der Kunden, Absatzschwierigkeiten. Das eigentliche Geschäftsrisiko eines Unternehmens ist nicht erfassbar; in der Marktwirtschaft trägt es der Unternehmer. Was hat das mit Projekten zu tun? Nun, Projekte sind Unternehmen auf Zeit. Jedes Projekt ist also während seiner Initiierung und Durchführung von Risiken bedroht. Diese zu erkennen, zu bewerten (Analyse) und ihnen vorzubeugen oder zu bewältigen ist Aufgabe des Risikomanagements [1]. Die Risikoerkennung wird erfahrungsgemäß dadurch erschwert, dass Risiken kaum sichtbar sind. Es spielt dabei keine Rolle, ob sie „unsichtbar“ sind oder wegen menschlicher Schwächen so behandelt werden [2]. 1.2 Grundfunktionen des Risikomanagements Ein wesentlicher Erfolgsfaktor des Risikomanagements ist die Risikoanalyse und -bewertung. Zu Beginn einer Risikoanalyse müssen allerdings Auftrag und Vorgehensweise eindeutig definiert und abgegrenzt werden. Denn erst wenn das Ziel des Auftrages klar ist und auch der Weg dahin einigermaßen vorstellbar, können die Projektrisiken identifiziert werden. Die Risikoanalyse besteht aus den Aktivitäten ● Risikoidentifikation und ● Risikodokumentation. Die Ungewissheiten dabei sind zum Teil erfassbar durch sorgfältige Planung (Projektstrukturplan etc.), Marktforschung (Wer ist der Kunde? , Was will er im Kern? ) etc. Ziel der Risikobewertung ist es, die analysierten Risiken nach ihrer Eintrittswahrscheinlichkeit einzustufen und nach ihrer Tragweite zu quantifizieren (in der Regel in Geldeinheiten). Hierzu eignet sich eine Expertenbefragung. Bei größeren Pro- Management immer wiederkehrender Projektrisiken D I E T E R C O Y 23 jekten sollten die Experten aus der Gruppe der Beteiligten und Betroffenen (Interessen von Anspruchsgruppen) kommen und ein Risikodialog geführt werden [3]. Das Ergebnis dieser Befragung oder dieses Dialoges wird dokumentiert und die Bewerbung graphisch in einem Risikoportfolio dargestellt. 1.3 Risikoportfolio Ein Beispiel für ein Risikoportfolio aus der Praxis ist in Tabelle 1 und Abb. 1 wiedergegeben. Es handelt sich um die Einschätzung einer Neuentwicklung im Rahmen einer Machbarkeitsstudie. Mit der Diagonalen in Abb. 1 wird eine erste Selektion von bedrohlichen (rechts oben) und weniger bedrohlichen Risiken durchgeführt. Diese bedrohlichen Risiken, gegen die sofort Maßnahmen ergriffen werden müssen, können weiter klassifiziert werden in ● für das Projekt existentielle Risiken (ganz rechts oben); ● Risiken vom „Katastrophentyp“ (links oben). Bei diesen Risiken ist die Eintrittswahrscheinlichkeit extrem gering, der Schaden aber extrem hoch; ● Risiken vom Typ „Sand im Getriebe“ (rechts unten). Bei diesen Risiken ist der Schaden zwar sehr gering, dafür tritt er aber fast täglich ein. Die üblichen Betriebsrisiken gelten als beherrschbar und Kontrahentenrisiken (Lieferanten, Kunden, Banken, Behörden, allg. Vertragsbeziehungen) als gestaltbar. Marktrisiken (Wettbewerbs- und Absatzmarkt, rechtliches, soziales und politisches Umfeld, Beschaffungs-, Arbeits- und Kapitalmarkt) allerdings gelten als nicht beeinflussbar. Für Projektrisiken muss diese Einteilung sorgfältig überprüft werden: Die Risikolage in einem Projekt ist wesentlich höher als das „normale“ Unternehmerrisiko, denn ein Projekt kennt keinen so hohen Grad an Wiederholcharakter. Auch genügt es nicht mehr, sich nur auf die Risiken vom Katastrophentyp zu konzentrieren. Die Risiken vom Typ „Sand im Getriebe“ verursachen oft Termin- und Budgetüberschreitungen. 1.4 Risikosteuerung Die beste Risikosteuerung sind vorbeugende Maßnahmen. Die erste besteht darin, den erfassten Risikostatus regelmäßig zu überprüfen. Auf Unternehmensebene ist dieses Pflicht seit Veröffentlichung des KonTraG- Gesetzes. Für alle börsennotierten Gesellschaften und für alle übrigen Kapitalgesellschaften gilt es als Empfehlung im Sinne von „best practice“. Für Projekte gilt dies entsprechend verschärft: Je einmaliger/ neuartiger ein Projekt ist, desto mehr ist planerisch zu tun; je komplexer ein Projekt ist, umso mehr Steuerungsaufwand ist vorzusehen. Maßnahmen im Einzelnen können sein [1]: ● Zielorientierung überprüfen (zyklisch), ● Wirtschaftlichkeits- und Investitionsrechnungen/ Revision durchführen, ● Organisationsregeln zu Projektbeginn festlegen, Systematik des Reportings prüfen, P M - M E T H O D E N / I N S T R U M E N T E Eintrittswahrsch. Schadenhöhe 1 Eichpunkt 1,00 1,00 2 Personalressourcen zu knapp 1,00 0,90 3 Investsumme zu hoch 0,66 0,61 4 großer Produkthaftungsfall 0,43 0,83 5 unzureichende Prozessqualität 0,35 0,83 6 Anlagenbetriebskosten zu hoch 0,57 0,61 7 Zeitrahmen gesprengt 1,00 0,17 8 unzureichende Qualifikation 0,89 0,27 des Betriebspersonals 9 größter Wettbewerber wehrt sich 1,00 0,12 mit einer Preissenkung ... 25 kein Zweitlieferant 0,14 0,09 Tabelle 1: Bewertung der Risikoereignisse mit Team Expert Choice [6] Abb. 1: Portfolio der Risiken P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 24 ● Meilensteinplan, Projektstrukturplan, Ressourcenplan, Budgetierung überprüfen, Limit- und Toleranzenkontrolle, Meldezyklen definieren und einhalten, ● Informations-, Frühwarn- und Kommunikationssysteme nutzen/ pflegen. Schwierig einzuschätzen ist aber die Verhältnismäßigkeit der Mittel oder das Nutzen-Kosten-Verhältnis der jeweiligen Maßnahmen. Auch ist nicht immer klar, zu welchem Zeitpunkt im Projekt das Chancen-Risiko-Verhältnis im Projekt am besten neu optimiert werden soll. Hier hilft Erfahrung. Nur der Erfahrene erkennt und „riecht“ Quellen und Ursachen von Gefahren. Andererseits scheitern viele Projekte nicht an den Risiken mit großer Tragweite, sondern an den Risiken des täglichen Sandes im Getriebe. Es wird gern übersehen, dass man in Projekten an vielen Aufgaben nur deswegen scheitert, weil sich viele kleine Fehler in der Addition zu sehr häufen [2]. Dies Phänomen tritt umso stärker auf, je komplexer das Problem oder Risiko im Projekt ist. Hauptcharakteristikum komplexer Probleme ist Dynamik. So kann z. B. mit einer pfiffigen Maßnahme ein großes Risiko ausgeschaltet werden, die Neben- oder Fernwirkungen dieser Maßnahme bleiben aber unbeachtet, bis sie nicht mehr übersehen werden können. Es ist damit ein neues Risiko aufgetaucht, das u. U. noch schwerer beherrscht werden kann [3]. 2 EIN PROJEKTMODELL 2.1 Die Motivation für ein Projektmodell Wichtig ist in diesem Zusammenhang, vernetzt zu denken, damit eine Maßnahme so formuliert werden kann, dass deren Nebenwirkungen nicht dazu führen, dass ein Problem oder Risiko nur durch ein anderes ersetzt wird. Wir sind aber alle im kausalen Denken viel besser ausgebildet und trainiert als im vernetzten Denken. Projektteams können allerdings bei interdisziplinärer Zusammensetzung und guter Zusammenarbeit als Gruppe vernetzt denken. Für das Risikomanagement kommt es auf das Verstehen der Zusammenhänge und Spannungsfelder der Projektsituation an. Hier gilt es den zentralen Kreislauf der Vernetzung zu identifizieren und das Handeln nach Prozessen statt nach Funktionen zu organisieren. Dies ist vom Autor gemacht worden [4] mit dem Ergebnis eines Projektmodells. Dieses Modell wird nun kurz vorgestellt (Abb. 2). 2.2 Modellierung Das Projekt wird als verallgemeinerter menschlicher Aktionszyklus verstanden [4] und als „stilisierte Rennbahn“ wiedergegeben. Zugrunde gelegt ist beispielhaft die Entwicklung eines Serienproduktes. Die 9 Phasen stellen ihrerseits wieder Aktionszyklen dar, die genauer beschrieben werden: 2.2.1 Modellierung Die in den Aktionszyklen angesprochenen Themen (Tabelle 2) können auch früher begonnen werden. Spätestens in ihrem Aktionszyklus aber müssen sie konsequent bearbeitet und beendet werden. 2.2.2 Struktureigenschaften Die Folge dieser Meilensteine am Abb. 2: Aktionszyklen als Meilensteine im Entwicklungszyklus 25 Ende der Aktionszyklen hat gewisse Struktureigenschaften, die auch für die Aspekte des Risikomanagements von Bedeutung sind. Klassische Modelle ● Die Folge der Meilensteine 1-4 entspricht der klassischen Topdown-Strategie. ● Für die Folge der Meilensteine 5-8 gilt entsprechend die Bottomup-Strategie. ● Alle Meilensteine als Abschluss von Aktionszyklen zu verstehen entspricht dem bekannten Wasserfall-Modell. Simultaneous Engineering Das Modell besteht in der Darstellung aus einer äußeren Bahn, die den Entwicklungszyklus repräsentiert, und einer inneren Bahn, die phasenversetzt den Produktionszyklus reprä sentiert. Ursache / Wirkungen Eine gedachte vertikale Linie teilt das Modell in eine rechte Hälfte: im Wesentlichen Gedanken- und Papierarbeit, also die Ursachen, und in eine linke Hälfte: im Wesentlichen Werkarbeit, also die Wirkungen. Innovationen Die Meilensteine 3, 6 und 9 charakterisieren die Stellen im Ablauf, an denen neue Qualitäten oder Innovationen entstehen: ● ein neues Produkt, ● ein neues Produktionsverfahren, ● ein neuer Nutzen für den Markt. 2.2.3 Empirisch ermittelte Beziehungen zwischen den Meilensteinen Sichtweisen und psychosoziale Verhaltensweisen, die jeder Projekterfahrene schon erlebt hat, sind in den Verbindungslinien verdichtet dargestellt. Von 1 → 7 (leicht): In der Freude über den Auftrag entsteht ein erstes grobes Verständnis des Ziels. Von 1 → 4 (schwer): mulmiges Gefühl beim Blick auf die möglichen Schwierigkeiten nach Klärung der Details (Problemunterschätzung). Von 2 → 4 (leicht): klarer Blick auf die zu erwartenden Widerstände. Von 2 → 8 (schwer): klares Erkennen des Ziels nur im Augenwinkel; man muss den Kopf schon wenden (Zielorientierung). Von 4 → 1 (leicht): zurück zur Zielsetzung z. B. wegen mangelhafter Präzision oder Irrtümern. Falls dieser Weg durch den Auftraggeber verursacht wurde, ist Claim Management angesagt. Wenn dem Kunden die Ergebnisse der FMEA-Analyse vorgelegt werden, heißt es nicht selten: „So habe ich mir das nicht vorgestellt“, und der Zyklus beginnt wieder bei 1. In aller Regel ist dies auf mangelnde Kommunikation zurückzuführen und Claim Management daher schwierig (Budgetrisiko). Von 4 → 2 (schwer): Die Fülle der zu lösenden Details verstellt den Blick auf das Ziel (Risiko! ), daher macht es auch Mühe, noch einmal zurückzugehen und im Pflichtenheft P M - M E T H O D E N / I N S T R U M E N T E Aktionszyklus 1 Mit neuem Konzept akquirieren, Experten formulieren grobes LH, prüfen Herstellbarkeit und Wirtschaftlichkeit und erstellen eine Grobplanung, Angebot und Auftrag, Auftrag entgegennehmen und prüfen, Auftrag bestätigen und Kick-Off-Veranstaltung kommunizieren Aktionszyklus 2 PL und Team benennen, Objekt analysieren (QFD), Projekt planen (Pflichtenheft, Meilensteinplan, Kalkulation, Feinplanung für die überschaubare Zukunft), Planung kommunizieren (Freigabe des Projektes) Aktionszyklus 3 Sollzustand des Produktes beschreiben (Wertanalyse), Lösungsideen entwickeln (alle Kreativitätstechniken), ausgewählte Idee kommunizieren und festschreiben (Konfigurationsmanagement) Aktionszyklus 4 Entwurf erstellen, (mit FMEA) überprüfen und kommunizieren (mit dem Kunden) Aktionszyklus 5 Ein Prototyp (Form, Fit und Funktion) wird erstellt, überprüft (DoE) und prä sentiert Aktionszyklus 6 Sollzustand für die Produktion beschreiben (WA) und Lösungsideen entwickeln (Kreativitätstechniken), ausgewählten Prozess kommunizieren und festschreiben (Änderungswesen) Aktionszyklus 7 Tests gegen das Pflichtenheft im Detail planen, durchführen und die Ergebnisse kommunizieren Aktionszyklus 8 Module fertig stellen, integrieren und das Gesamtsystem abnehmen lassen (gegen die Anforderungsspezifikation) Aktionszyklus 9 Projektreview durchführen, Dokumentation abschließen und Ergebnisse schulen Tabelle 2: 9 Aktionszyklen P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 26 nachzuschlagen: „Was war eigentlich die Forderung? “ Von 5 → 8 (leicht): Nach dem Bau des Prototypen ist etwas „Anfassbares“ entstanden, d. h., die Aufgabe kann endgültig „begriffen“ werden. Das Ziel ist wieder klar im Blick und damit auch aller organisatorischer Aufwand, der alle Beteiligten auf das Ziel hin ausrichtet. Von 5 → 7 (schwer): Nachdem das „Design of Experiments“ (DoE) endgültig festgelegt worden ist, muss nun die Energie auf dessen Umsetzung gerichtet und die Tests gegen das Pflichtenheft konsequent durchgeführt werden. Von 7 → 5 (leicht): Die Ergebnisse der Tests führen zu einer Präzisierung des Prototypen und der Wiederholung von einer Reihe von Tests. Von 7 → 1 (schwer): Der Erkenntnisfortschritt „Hätten wir das doch nur schon zu Beginn gewusst“ führt in leichten Fällen zu Notizen, wie die Spezifikation in einem neuen ähnlichen Projekt aussehen sollte, in schweren Fällen zu einem Hinüberwechseln zu 1 und einem neuen Durchlaufen aller Meilensteine bis 7 (Risiko Zielverfehlung ist intern eingetreten). Von 8 → 2 (leicht): Der Erkenntnisgewinn kann klar benannt werden, der Auftraggeber nimmt die Aufgabe ggf. mit einigen Nachbesserungen ab. Wenn die Abnahme wegen „schwerer Mängel“ verweigert wird (Elchtest), muss der ganze Zyklus bei 2 beginnend neu durchlaufen werden (Risiko Zielverfehlung ist extern eingetreten). Starke Fliehkräfte (Ursachen für Risiken) Die Darstellung ist so gewählt, dass die üblichen Projekterfahrungen wiedergegeben werden können. Die Strecke (1-3) und die Strecke (6-8) kann mit relativ geringen „Fliehkräften“ durchlaufen werden. Dagegen treten bei den Strecken 3 bis 6 sowie 8 bis 9 und 9 bis 1 erhöhte „Fliehkräfte“ auf. Damit soll angedeutet werden, dass bei diesen Strecken ein Team besonders leicht aus der Bahn geworfen wird: Zu 4: Der ab 2 entstehende Druck, endlich etwas „Vorzeigbares“ auf den Tisch zu legen, lä sst keine Muße für bessere Ideen und eine sorgfältige FMEA. Das heißt, dass das Produkt- Risiko nicht beherrscht wird. Zu 5: Der Erkenntnisfortschritt für alle, auch entfernte Beteiligte wird nicht richtig „begriffen“, d. h., es gibt einen unterschiedlichen, also unausgeglichenen Informationsstand. Zu 6: Der Konsens im Simultaneous Engineering Team ist nicht hinreichend für eine effektive Prozessgestaltung und das Produkt in der Produktion damit teurer als nötig. Zu 9: Nach der Abnahme wird das Team vorzeitig auseinander gerissen und in neue Projekte gesteckt. Die Dokumentation leidet. Das Gelernte wird nicht richtig genutzt für den Aufstieg in die nächsthöhere „Spielklasse“. Der Verkauf und der Service werden nur unzureichend in den Eigenschaften des Produktes geschult. Zu 1: In der Sorge um neue Aufträge (Umsatz) unterlaufen Nachlä ssigkeiten in der Akquisition. Es werden unabgesicherte Zusagen gemacht. Der potentielle Projektleiter wird in die Angebotsbearbeitung nicht eingebunden. 2.3 Risikomanagement im Modell Zunächst einmal liegt der Vorteil dieses Modells in der relativ einfachen graphischen Darstellung. Jedem Meilenstein sind ein bestimmter Schwerpunkt der Aktivitäten sowie Sicht- und Verhaltensweisen zugeordnet. Das heißt, nicht nur der Beginn und die Beendigung eines Projektes sind klar strukturiert, sondern auch der mittlere Bereich, die Realisierungsphase. Die gesamte Projektabwicklung wird in deterministische Phasen, nämlich in Aktionszyklen und in „Wechselwirkungszyklen“, zerlegt. Der Vorteil dieses Modells unter dem Gesichtspunkt des Risikomanagements besteht darin, zu bestimmten Meilensteinen gezielte Risikoabschätzungen konsequent durchzuführen. Man scheitert beim Lösen vieler Aufgaben ja nur deswegen, weil sich viele kleine Fehler in der Addition zu sehr häufen. Hier wurde vergessen, ein Ziel genügend zu konkretisieren, dort wurde auf die Ablaufcharakteristiken eines Prozesses nicht geachtet, da wurde übergeneralisiert, dort wurde der Schutz des eigenen Selbstwertgefühls über die Kenntnisnahme des Misserfolges gestellt, hier wurde zu viel geplant, dort zu wenig etc. [2]. An der Strukturierung dieses Modells kann man nun versuchen bewusst zu machen, in welcher Situation typischerweise welche Fehler auftreten. Die Risiken bestehen dann darin, dass die vorhandenen Wechselwirkungszyklen ein- oder mehrfach durchlaufen werden müssen. Auf 1 wirken die Wechselwirkungszyklen (jeweils einmal gez ählt) 27 4 → 1 → 2 → 3 → 4 (Vertragsschleife Auftragsspezifikation, QFD- Prozess) 4 → 2 → 3 → 4 (innere Schleife, FMEA-Prozess) 7 → 5 → 6 → 7 (innere Schleife, Design of Experiments und Verifizierungsprozess) 7 → 1 → 2 → 3 → 4 → 5 → 6 → 7 (Vertragsschleife Realisierungsspezifikation) Auf 2 wirken zus ätzlich die Wechselwirkungszyklen (jeweils einmal gez ählt) 8 → 2 → 3 → 4 → 5 → 6 → 7 → 8 (Vertragsschleife Abnahmespezifikation) 8 → 5 → 6 → 7 → 8 (innere Schleife, Fertigungsüberleitung, interner Abnahmeprozess) Diesen Durchl äufen kann ein maximaler Aufwand zugeordnet werden, nämlich der Aufwand, der dafür geplant wurde oder in ungünstigen Fällen bereits geleistet wurde. Die „Versicherungsprä mie“, die gezahlt werden müsste, um diesen Fall finanziell abzudecken, ist ein Maß für den Aufwand der Risikovorsorgemaßnahmen im Rahmen eines Risikomanagements. Alle Meilensteine tauchen somit in 6 verschiedenen Wechselwirkungszyklen auf. Alle damit verbundenen Aufwände können besser geschätzt werden. Damit kann auch der Aufwand festgelegt werden, der notwendig ist, um das Risiko zu reduzieren, d. h. um folgende Fragen sorgfältig zu beantworten [5]: Spätestens bei 1: Wer ist der Kunde? Was will er im Kern? Spätestens bei 2: Was sind die Qualitätsmerkmale? Spätestens bei 3: Wie sieht ein wertgestaltetes Design aus? Spätestens bei 4: Wie sehen die Produkt- und Prozessmerkmale unter FMEA-Gesichtspunkten aus? Wenn dies erfolgt ist, ist das Projektrisiko ab 4 zwar nicht null, aber beherrschbar. 3 ERGEBNISSE 3.1 Erläuterung der Vorgehensweise Bei der Beschreibung des Modells wird deutlich, dass das Durchlaufen eines Wechselwirkungszyklus dem Eintritt eines Risikos entspricht. Die Kosten, die dabei entstehen, sind die Risikobewältigungskosten. In Abb. 3 ist das Durchlaufen des Projektmodells dargestellt: Die etwa unter 45° verlaufenden Stücke stellen den Arbeitsfortschritt des jeweiligen Aktionszyklus in Richtung Ziel bzw. P M - M E T H O D E N / I N S T R U M E N T E Abb. 3: Effekte einer Verkürzung der Zeitkonstante (Vergleichsprojekt) P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 28 den Kostenhochlauf dar, die waagrecht verlaufenden Stücke modellieren das Überprüfen der Meilensteinergebnisse, das eventuelle Nacharbeiten und auch das Warten auf die Freigabe für den nächsten Aktionszyklus. Wenn Risiken eintreten, also Wechselwirkungszyklen durchlaufen werden, ergibt sich kein Arbeitsfortschritt, nur Zeitverbrauch (Lernkurve Projekt 1) und zus ätzlich Mittelverbrauch (Kostenkurve Projekt 1). In dieser Darstellung wird ohne Beschränkung der Allgemeinheit angenommen, dass der Zeitverbrauch für das Durchlaufen der Wechselwirkungszyklen, also der Risikobewältigung, 50 % der Zeit beträ gt, die für das ordentliche Durchlaufen des Aktionszyklus erforderlich ist. Es kommt durchaus vor, dass Wechselwirkungszyklen 3bis 5-mal in der Nacharbeit iterativ durchlaufen werden. Ferner wird angenommen, dass die Teamgröße, die Fehlerrate des Teams und der zeitliche Abstand der Meilensteine über die ganze Zeit konstant sind. Die Praxis zeigt, dass diese Annahmen realistisch sind, wenn ein Projekt nach dem Beginn auch wirklich durchgeführt wird. 3.2 Die Wirkung In Abb. 4 ist nun in gleicher Weise der Durchlauf des Projektmodells für Projekt 2 dargestellt. Alle Annahmen sind dieselben bis auf eine: Der Zeitverbrauch für das Durchlaufen der Wechselwirkungszyklen beträgt wegen Vorsorgemaßnahmen statt 50 % (Projekt 1) nur 25 % der Zeit, die für das ordentliche Durchlaufen der Aktionszyklen erforderlich ist. Die Risiken treten also etwa nur halb so oft ein. Der Vergleich der beiden Projekte ergibt Folgendes: Eine „Halbierung“ der Risiken führt zu einer gesamten Zeitersparnis von 34 % und zu einer gesamten Kostenersparnis von 28 %. Sind das realistische Zahlen? Nun, es gibt ein Ereignis, an dem das Modell geeicht werden kann. Die im Zusammenhang mit dem Elchtest bekannt gewordene Auslieferungsverzögerung der A-Klasse um 6 Monate kann hier mit den Wechselwirkungszyklen am Meilenstein 8 von Lernkurve-Projekt-2 modelliert werden, indem sie auf die Länge von Lernkurve-Projekt-1 am Meilenstein 8 ausgedehnt wird. Wenn die graphische Verlängerung der Lernkurve- Projekt-2 sechs Monaten entspricht, errechnet sich die ursprüngliche Dauer der Lernkurve-Projekt-2 dann zu 3 Jahren, ein Wert, der für die Hauptentwicklung eines Automobils bekannt ist. Der entscheidende Unterschied zwischen beiden Lernkurven ist die Verkürzung der das System bestimmenden Zeitkonstante bei Projekt 2. 3.3 Wie geht man damit um? Aus dem Modell ist ersichtlich, dass die wesentlichen Risiken in den Wechselwirkungszyklen stecken, welche die Meilensteine 1 und 2 beinhalten. D. h., die Fehler, die bei 1 und 2 gemacht werden, oder die Risiken, die dort nicht erkannt werden, schlagen am stärksten zu Buche. Aus dem Qualitätsmanagement ist diese Gesetzmäßigkeit bereits bekannt. Den Vorsorgemaßnahmen, die den ersten Meilensteinen zugeordnet sind, muss also besondere Aufmerksamkeit gewidmet werden. Diese Maßnahmen sind: ● Die Ziele müssen ganz klar sein: Eine Anforderungsspezifikation, eine Abnahmespezifikation, eine Bedienungsanleitung des Produktes liegen vor. ● Die gesamte Planung liegt vor: Projektstrukturplan, Meilensteinplan, Budget und Qualitätsplan, d. h., die Kundenforderungen, sind mittels QFD in quantitative Abb. 4: Effekte einer Verkürzung der Zeitkonstante (mittels Risikomanagement) 29 Qualitätskriterien übersetzt worden. ● Lösungsalternativen aus lateralem Denken liegen vor [6]. ● Die Qualitätskriterien sind mittels QFD für diese Alternativen in Designkriterien übersetzt worden. ● Die beiden besten Alternativen werden entworfen/ konstruiert und mittels FMEA überprüft. ● Die Designanforderungen sind mittels QFD in Fertigungsanforderungen übersetzt worden. ● Die zuletzt verbliebene Alternative wird als Prototyp gebaut. Jeder Beteiligte und Betroffene fasst ihn an und gibt Kommentare. ● Eine Prüfplanung und Prüfmittelplanung liegen vor. Diese Liste macht deutlich, dass in frühen Projektphasen die geistige Durchdringung der Zielsetzung und der möglichen Realisierungsalternativen sehr viel intensiver stattfinden muss, um Risiken zu beherrschen und wirtschaftlich erfolgreich zu sein. ■ Literatur [1] Projektmanagement-Fachmann. RK W, Eschborn 1996 [2] Dörner, Dietrich: Die Logik des Misslingens. Rowohlt Verlag, Reinbek bei Hamburg 1991 [3] Gomez, Peter/ Probst, Gilbert: Die Praxis des ganzheitlichen Problemlösens. Paul Haupt Verlag, Stuttgart 1995 [4] Coy, Dieter: Die Gliederung von technischen Projekten in Aktionszyklen. In: Lange, Dietmar (Hrsg.): Deutsches Projektmanagement Forum 1999, Dokumentationsband. GPM Deutsche Gesellschaft für Projektmanagement, Nürnberg 1999 [5] Klein, Bernd: QFD Quality Function Deployment. expert verlag, Renningen-Malmsheim 1999 [6] Coy, Dieter: Team Expert Choice - Praxiserfahrungen. Unveröffentlichtes Manuskript Autor Dr.-Ing. Dieter Coy, Jahrgang 1947, studierte Nachrichtentechnik an der TH Darmstadt. Nach einer erfolgreichen Industrietätigkeit in Entwicklung und Vertrieb gründete er 1998 die Gesellschaft für Innovation und Beratung. Kernkompetenzen sind Projektmanagement, Innovationsmanagement und Entscheidungsfindungen. Er berät mittelstä ndische und große Unternehmen insbesondere im Sinne „schnelle und bessere Entscheidungen von Anfang an“ u. a. mit Hilfe der Software „Team Expert Choice“. Die Firmen erhöhen damit ihre Fä higkeit, in komplexen Situationen die richtigen Lösungsalternativen zu finden. Anschrift Gesellschaft für Innovation und Beratung Belchenweg 22 D -71088 Holzgerlingen Tel.: 0 70 31/ 74 55 63 Fax: 0 70 31/ 74 55 59 E -Mail: DieterCoy@t-online.de P M - M E T H O D E N / I N S T R U M E N T E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 30 Zusammenfassung Die Bewahrung und Nutzung von Wissen werden für Unternehmen zunehmend wettbewerbskritisch. Insbesondere wenn Erfahrungen und Wissen in Projekten gewonnen werden, ist Vorsorge dafür zu tragen, dass Folgeprojekte davon profitieren können. Vorhaben werden in Unternehmen ja gerade zur Lösung von innovativen und interdisziplin ä ren Fragestellungen eingesetzt; die dabei im Projektteam aufgebaute Kompetenz muss nach Projektende erhalten und anderen Projektteams zur Verfügung gestellt werden. Dafür müssen wä hrend des Projektabschlusses gezielte Schritte und Maßnahmen eingeleitet werden, von denen hier einige vorgestellt werden. Abstract For more and more companies the systematic acquisition, synthesis, and sharing of knowledge and experiences is an important enabler for ongoing business success. Especially knowledge and experiences gained in projects are valuable, because project organisations are chosen because of the underlying innovative and diverse nature of the given problems. During the close-down of such projects, systematic steps of experience retention are necessary to keep some of the knowledge and experiences within project profiles, lessons-learned etc. Schlagwörter Erfahrungstransfer, Lessons-Learned, Organisation, Projektabschluss, Projektmanagement, Projektsteckbrief, Wissensmanagement D er Begriff Wissensmanagement fasst alle Tätigkeiten zum organisierten, systematischen und kontrollierten Umgang mit dem Wissen eines Unternehmens zusammen. Dabei werden nur wenige Fachvertreter behaupten, dass diese Tätigkeiten alle grunds ätzlich neu sind. Eher setzt sich die Einschätzung durch, dass die heutige große Bedeutung der Ressource Wissen die Unternehmen zwingt, den Umgang mit unternehmensinternem Wissen zu bündeln, zu intensivieren und zu systematisieren. Damit sollen Planung und Steuerung der Bereitstellung und der Nutzung von Wissen und Erfahrungen im Unternehmen verbessert werden. Dabei birgt die Projektorganisation einige besondere Probleme. In einer „normalen“ Organisation gibt es stabile Institutionen wie Abteilungen, Bereiche, Werke u. Ä., in denen Wissen und Erfahrungen gesammelt und abgefragt werden können. Dabei können die Sammlungen durchaus unterschiedlich aussehen, z. B. Dokumentationen, Archive, kompetente Mitarbeiter oder in Arbeitsabläufen verborgen. Dies bietet in vielen einfachen Situationen, in denen Wissen nachgefragt wird, schnelle und von Einzelpersonen unabhängige Hilfe: Frage: „Wer weiß bei uns etwas über abc? “ Antwort: „Geh mal zu den Logistikern“, „… in die Anlaufplanung“, oder „… in den Einkauf “, oder „… zu denen im Werk Schleswig“. Diese Möglichkeiten gibt es in der Regel nicht zu Wissen und Erfahrungen, die in Projekten gesammelt werden. Projekte sind definitionsgemäß temporäre, zeitlich begrenzte Organisationen, die für besondere Tätigkeiten eingesetzt werden. Nach dem Projektende ist keine Institution oder kein Korpus mehr da, der als Sammelpunkt von Wissen und Erfahrungen angesehen werden kann. Anlaufstellen (wie Abteilungen, Bereiche, Werke), wo Unterlagen eingesehen oder Wissende getroffen werden können, existieren nach Projektende nicht mehr. Das Projekt wird nach Projektende aufgelöst und existiert nicht mehr (siehe Abb. 1). Nicht ohne Aufwand ist herauszufinden, welche Mitarbeiter bei einem vergangenen Projekt mitgearbeitet haben, wer von ihnen für was zu- Wissensmanagement in Projekten G E O R G D I S T E R E R 31 ständig war und ob/ wo diese Mitarbeiter noch im Unternehmen arbeiten. Dabei wird hier der Klarheit der Darstellung halber von der vereinfachten Situation ausgegangen, dass in einem Unternehmen nur ein Projekt zurzeit läuft. Selbstverständlich werden die genannten Probleme nur größer, wenn ständig mehrere Projekte nebeneinander abgewickelt werden - der Bedarf nach systematischer Handhabung von gesammeltem Wissen und Erfahrungen wird nur größer. Damit besteht die Gefahr, dass mit dem Projektende das neu gesammelte Wissen und die Erfahrungen dem Unternehmen verloren gehen. Bestenfalls nehmen die beteiligten Projektmitarbeiter die Erfahrungen mit und besitzen damit individuelle Erfahrungen, die sie zukünftig (vielleicht) nutzen können. Im Folgenden wird daher die besondere Bedeutung des Wissensmanagements für Projekte beschrieben, einige zu beachtende Besonderheiten erläutert und Maßnahmen detailliert, die im Projektmanagement ergriffen werden können, um die Nutzung von Wissen und Erfahrungen aus Projekten zu verbessern. 1 WISSENS- UND ERFAHRUNGS- TRANSFER ZUR EFFIZIENZSTEIGERUNG Seit Jahren werden in Unternehmen in stark zunehmendem Maß Aufgaben in Form von Projekten durchgeführt. Ein Ende dieses Trends ist nicht abzusehen, eher wird in Zukunft noch häufiger die spezielle Organisationsform „Projekt“ genutzt werden, da Schlüsseleigenschaften von Projekten hohe Bedeutung haben: flexibel, interdisziplinär, innovationsfördernd, übergreifend. Dabei steigt der Druck, Projekte effizient durchzuführen. Die Projektdauer wird oft zur erfolgskritischen Größe. Bei Entwicklungsprojekten zwingt „time-to-market“ zur Eile, bei internen Verbesserungsprojekten soll der Nutzen, den ein Projekt verspricht, möglichst schnell realisiert werden. Zugleich steigt die Bedeutung der Projektkosten durch den hohen wirtschaftlichen Druck und die starke Wettbewerbssituation, in der sich viele Unternehmen sehen. Projektarbeit ist häufig Entwicklungsarbeit; den Entwicklungskosten jedoch kommt gegenüber den Fertigungskosten in vielen Bereichen eine immer höhere Bedeutung zu [2, S. 435]. Möglichkeiten zu Effizienzsteigerungen in der Projektarbeit werden an vielen Stellen gesucht. Dem Wissensmanagement wird der Ansatz zugeordnet, in einem Unternehmen vorhandenes Wissen und von den Mitarbeitern gesammelte Erfahrungen systematisch aufzunehmen und weiterzuleiten. Das „Wiedererfinden des Rads“ stellt das abschreckende Beispiel dafür dar, vorhandenes Wissen nicht zu nutzen, sondern noch einmal neu aufzubauen. Die zunehmende Komplexität von Projekten aufgrund der steigenden Anzahl zu beachtender technischer und sozialer Zusammenhänge und Schnittstellen lä sst den Wert des vorhandenen Wissens zur Bewältigung von Komplexität und zur Effizienzverbesserung weiter steigen. 2 WISSENS- UND ERFAHRUNGS- TRANSFER ZWISCHEN PROJEKTEN Zur unmittelbaren Effizienzsteigerung müssen Projekte Wissen und Erfahrungen aus der Routinetätigkeit eines Unternehmens und aus vorhergehenden Projekten im Unternehmen aufnehmen (siehe Abb. 2). Für Wissen und Erfahrungen aus der Routinetätigkeit können die Projektmitarbeiter wesentliche Träger sein, die diesen Input mitbringen: So werden beispielsweise in Projekten zur Softwareentwicklung zukünftige Benutzer dieser Software aus der Fachabteilung in die Projektarbeit einbezogen („Benutzerbeteiligung“), oder in einem technischen Entwicklungsprojekt arbeiten Mitarbeiter aus der Arbeitsvorbereitung und der Produktion mit. Ebenso beinhalten interne Dokumentationen und Arbeitsunter- P M - M E T H O D E N / I N S T R U M E N T E Abb. 1: Projekte als temporäre Organisationen P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 32 lagen Wissen, das in Projekten wieder verwandt wird, und durch Befragungen von erfahrenen Mitarbeitern und Analyse der Routinetätigkeiten kann Wissen während der Projekte erhoben werden. Der Transfer von Wissen und Erfahrungen aus der Projektarbeit in die (anschließende) Routinetätigkeit ist im Projektmanagement ausdrücklich vorgesehen und etabliert: Die Produktdokumentation übernimmt diese Rolle, sei es beispielsweise in Form von technischen Zeichnungen, die als Teil des Projektergebnisses an die Produktion übergeben werden, oder sei es in Form eines Benutzer- und Bedienerhandbuchs bei einer neuen Software, in dem Handhabungswissen für zukünftige Benutzer und Systemadministratoren niedergelegt ist. Ebenso wichtig und wünschenswert ist der Transfer von Wissen und Erfahrungen aus vorhergehenden Projekten. Zwei Beispiele mögen die folgende Argumentation illustrieren. Ein Unternehmen entwickelt in einem Projekt ein neues Material oder eine neue Materialzusammensetzung. Während der Projektarbeit kommt der Kontakt zu einem Forschungsinstitut im Ausland zu Stande, das auf diesem Gebiet arbeitet, und es entsteht eine sehr fruchtbare Kooperation. Die Zusammenarbeit ist für das Projekt im Unternehmen sehr wertvoll, weil die Arbeitsgebiete des Forschungsinstituts einen hohen Deckungsgrad zum Projektauftrag aufweisen, gemeinsame Sprachkenntnisse die Kommunikation erleichtern, das Institut auf Anfragen offen und zügig reagiert und kleinere Forschungsaufträge an das Institut kompetent, schnell und termingerecht ausgeführt werden. Zudem wird ein Modus zur Kompensation der Aufwendungen gefunden, der beide Seiten zufrieden stellt. Doch was geschieht am Ende des Projektes innerhalb des Unternehmens mit dem Wissen über diesen Kontakt und die Ansprechpartner sowie den Erfahrungen der Zusammenarbeit? Wie erfahren nachfolgende Projekte mit ähnlicher Aufgabenstellung davon? In der Regel bleiben bezüglich der externen Kooperationspartner das Wissen über Personen, Spezialkenntnisse, technische Einrichtungen, Kommunikationswege usw. sowie die Erfahrungen zu Arbeitsweisen, Antwortzeiten, Sensibilitäten usw. in den Köpfen der Projektmitarbeiter verborgen und werden nicht systematisch ausgewertet und weitergeleitet. Zweites Beispiel: In einem Projekt wird das neue Release einer Software zum Projektmanagement eingesetzt. Die Änderungen des Releases gegenüber der im Unternehmen bekannten Version sind erheblich und lösen umfangreichen Einarbeitungsaufwand und Änderungen an Standardvorgaben aus. Einige Funktionen der neuen Software stellen sich nach einiger Zeit als unbrauchbar heraus, andere sind erst durch spezielle Tricks bei der Benutzung sinnvoll zu nutzen. Während der Projektarbeit werden also Wissen und Erfahrungen in erheblichem Umfang zu diesem neuen Software-Release aufgebaut. Wie erfahren Mitarbeiter nachfolgender Projekte davon und können so davon profitieren? In der Regel bleiben dies Handhabungskenntnisse einzelner Projektmitarbeiter. Traditionelle Transfermethoden zwischen Projekten greifen oftmals zu kurz: Projekthandbücher sind selten aktuell und spielen meist die Rolle von „Schrankware“, Checklisten sind generisch und decken kaum Details ab, nur zufällig ist einer der in dieser speziellen Sache erfahrenen Mitarbeiter aus vorhergehenden Projekten wiederum Projektmitglied usw. Die beiden geschilderten Beispiele verdeutlichen, dass diese Methoden in vielen Situationen untauglich sind. Nur für wenige Teilbereiche wie die Weitergabe von Erfahrungswerten zur Aufwandsschätzung sowie die Nutzung von Standard-Templates bei der Netzplantechnik haben sich Transfermethoden etabliert [2, S. 436 ff.]. Abb. 2: Wissen und Erfahrungen als Input und Output von Projekten 33 3 DOKUMENTATION ENTHÄLT SELTEN „LESSONS-LEARNED“ Die Dokumentation von Projekten hält nur selten Wissenswertes für nachfolgende Projekte bereit. Die Produktdokumentation (Zeichnungen, Arbeitsanweisungen, Benutzerhandbuch, Systemhandbuch …) hat als Zielgruppe die zukünftigen Anwender, Benutzer oder Betreiber des Ergebnisses von Projekten. Die Projektdokumentation (Projektauftrag, Projektpläne, Terminpläne, Kostenübersichten, Fortschrittsberichte, Sitzungsprotokolle …) dient vor allem der Kommunikation während der Projekte und hat als Zielgruppe die Mitarbeiter und das Management der Projekte und die Mitglieder von Kontroll- und Aufsichtsgremien. Selten ist eine Dokumentation vorgesehen, die sich an Mitarbeiter zukünftiger Projekte wendet. Diese Dokumentation stellt Methoden und Vorgehensweisen dar, schildert konkrete Probleme, beschreibt erfolgreiche und erfolglose Lösungsans ätze, nennt Ansprechpartner und externe Experten, enthält Schilderungen erfolgreicher Kooperationen und deren Erfolgsfaktoren, überliefert Handhabungstricks etc. In diesem Sinne wären Beschreibungen der „Lessons- Learned“ für nachfolgende Projekte wertvoll. Jedoch geht derartiges Erfahrungswissen mangels geeigneter Identifikation und Aufbereitung oftmals verloren [6, S. 8]. Ebenso wäre oft hilfreich, Mitarbeiter vorheriger Projekte gezielt finden und befragen zu können. Dies mag in kleineren und mittleren Unternehmen noch ohne Regelungsaufwand funktionieren. In größeren Unternehmen muss jedoch davon ausgegangen werden, dass zum Beispiel die Mitarbeiter eines Projektes ein Jahr nach Projektende nur mit erheblichem Aufwand identifiziert und ihre jetzigen Arbeitsplätze innerhalb eines Unternehmens herausgefunden werden können. 4 BARRIEREN ERSCHWEREN WIS- SENS- UND ERFAHRUNGSAUSTAUSCH Projektarbeit steht fast immer unter Zeitdruck, termingerechte Projektabschlüsse haben z. B. bei der Softwareerstellung Seltenheitswert. Daher muss oftmals die Fertigstellung des Produkts als Ende des Projekts angesehen werden, sich anschließende, notwendige Nacharbeiten zur Identifikation und Aufbereitung von Wissen und Erfahrungen müssen wegen aufgebrauchter Zeitressourcen entfallen. Projektmitarbeiter werden zudem nachdrücklich für Folgeprojekte angefordert; oftmals lösen sich so Projektgruppen sukzessive auf, ohne dass alle Projektbeteiligten systematische Nacharbeit und Dokumentation von Wissen und Erfahrungen betreiben können. Zudem bestehen erhebliche individuelle und soziale Barrieren, Wissen und Erfahrungen aus Projekten zu artikulieren und zu dokumentieren [3]. So wären zum Beispiel Analysen von Fehlschlägen, Irrtümern und Irrwegen besonders wertvoll, oftmals fehlt jedoch eine offene und konstruktive Atmosphäre, um diese zu artikulieren und zu analysieren. Mitarbeiter scheuen das Eingeständnis und Ansprechen von Fehlern, da sie negative Auswirkungen für sich fürchten. Oder: Offensichtlich haben andere Mitarbeiter des Unternehmens zu einem späteren Zeitpunkt den Nutzen einer derartigen Erfahrungssicherung und -dokumentation. Weitreichende Synergien entstehen erst, wenn sich alle Mitarbeiter an diesem Austausch beteiligen. Dieses Nutzenversprechen ist jedoch für den einzelnen Mitarbeiter oft zu vage und abstrakt („Was habe ich davon? “) und löst keine ausreichende Motivation zur Dokumentation von „Lessons-Learned“ aus. Auch wird dieser Dokumentation nicht genug Anerkennung in den Unternehmen zugemessen. Erfahrungssicherungspläne, wie etwa von Burghardt in seinem Standardwerk vorgeschlagen [2], werden nur selten aufgestellt. Warum sollen Mitarbeiter die Erfahrungssicherung für wichtig halten, wenn dafür noch nicht einmal in der Projektplanung explizit und ausreichend zeitliche Ressourcen vorgesehen werden? Für das Management der Unternehmen ergeben sich damit wichtige Aufgaben: Etablieren von Projektphasen der Identifikation und Sicherung von Wissen und Erfahrungen, vorbildhaftes Wirken bei der Sicherung von Wissen und Erfahrungen, Schaffen einer offenen und konstruktiven Atmosphäre zum Wissensaustausch, Motivation der Mitarbeiter zum Engagement beim Wissensaustausch [9]. Im Folgenden werden einige Maßnahmen vorgestellt, die den Wissensaustausch zwischen Projekten forcieren können. 5 MASSNAHMEN 5.1 Erfahrungssicherungsplan und Reflexion Schon während der Planung eines Projektes sind am Ende Arbeitsschritte und Zeitkontingente vorzu- P M - M E T H O D E N / I N S T R U M E N T E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 34 sehen, die dezidiert Aufgaben der Wissens- und Erfahrungssicherung zugeordnet werden. Dabei ist z. B. festzulegen, wer dafür zuständig ist, auf welchen Gebieten neues Wissen erwartet wird, wie Erfahrungen zu dokumentieren, zu speichern und zu archivieren sind [2, S. 435-436]. Damit rückt die Phase des Projektabschlusses in den Mittelpunkt der Anstrengungen um eine systematische Aufbereitung des in Projekten neu aufgebauten Wissens [8, S. 13]. Bezeichnungen wie „Experience Retention“ und „Debriefing“ [1, S. 11] weisen darauf hin, dass diese Phase eine wichtige Gelegenheit darstellt, um Wissen und Erfahrungen der Projektmitarbeiter aufzunehmen und zu sichern; beispielsweise soll BP entsprechende systematische Projektschritte erfolgreich im Zuge eines Wissensmanagements eingeführt haben [5, S. 19]. Fragen, die diesen Prozess initiieren, können etwa lauten: ● Wie ist das Projekt in den verschiedenen Phasen gelaufen: Planung, Analyse, Konzept, Umsetzung, Implementierung? ● Welche Faktoren waren für die Akquisition eines (Kunden-)Projektes erfolgskritisch? ● Wo waren wir gut, was würden wir aus heutiger Sicht anders machen? ● Wo waren besondere „Klippen“ im Projektverlauf, wie haben wir sie umschifft? ● Wie war die Kommunikation zwischen den Projektmitgliedern? Was hat den Projektverlauf gefördert, was gehemmt? ● Wie können wir bei künftigen Projekten Planung/ Steuerung/ Kontrolle verbessern? ● Welche Erfahrungen können wir wie aus diesem Projekt an andere weitergeben? Somit wird eine Reflexion des Projektverlaufs eingeleitet, deren offener und konstruktiver Verlauf durchaus nicht selbstverständlich ist. Manche Erfahrungen aus einem Projekt werden kritisch zu betrachten sein, so dass die Beteiligten die notwendige Distanz zu einer Reflexion aufbringen müssen und zum Beispiel Schuldzuweisungen zu vermeiden sind. Um die besonders wichtigen Lerneffekte aus kritischen und problematischen Projektsituationen auslösen und umsetzen zu können, ist von den Führungskräften eine entsprechende vertrauensvolle und offene Arbeitsatmosphäre zu erzeugen und zu sichern. 5.2 Sammlung von Lessons- Learned Eine wichtige Möglichkeit, die Ergebnisse derartiger Reflexionsphasen festzuhalten, bieten so genannte „Lessons-Learned“. Diese Darstellungen enthalten die ausführliche und detaillierte Dokumentation der Identifikation und Lösung konkreter und abgegrenzter Problemstellungen, die als modellhaft für Folgeprojekte angesehen werden. So werden etwa technische Fragestellungen, organisatorische Konstellationen oder soziale Situationen, die in Projekten auftreten und deren Handhabung im Nachhinein - während der Reflexion - als erfolgskritisch angesehen werden, detailliert beschrieben. Neben dem erfolgreich realisierten Lösungsweg zur Bewältigung werden ebenso gegebenenfalls missglückte Lösungsans ätze oder Lösungsans ätze, die nicht für eine Realisierung ausgewählt wurden, beschrieben. Dabei wird bei der Dokumentation von Lessons-Learned darauf Wert gelegt, dass für erfolgreiche wie erfolglose Lösungen genauestens die Problemsituation geschildert und der Kenntnisstand über Gründe und Folgen des Handelns wiedergegeben wird. Dies soll Mitarbeitern von Folgeprojekten die Möglichkeiten geben, dieses Wissen aufzunehmen und unmittelbar oder - durch Übertragung auf ähnliche Situationen - mittelbar nutzbringend einzusetzen. Zudem können diese Dokumentationen als Fallstudien zu Schulungszwecken eingesetzt werden. Durch die detaillierte Beschreibung der Problemsituation und die ausführliche Darlegungen erfolgreicher wie erfolgloser Lösungsans ätze gelten Lessons-Learned als eine Möglichkeit, implizites Wissen zu erschließen und niederzulegen. Derartiges implizites Wissen wird überwiegend durch Erfahrungen erlangt und ist eingebettet in individuelle Denkmuster und Verhaltensweisen. Dieses Wissen ist damit stark von den Individuen abhängig, die es aufgebaut haben und besitzen. Es ist schwer zu kodifizieren und zu dokumentieren sowie an andere Mitarbeiter zu übertragen. Im Gegensatz dazu ist explizites Wissen leicht zu kodifizieren und daher z. B. in Arbeitsanleitungen oder Lehrbüchern zu finden. Lessons-Learned stellen einen Weg dar, implizites Wissen zu externalisieren und damit zumindest teilweise zu explizitem Wissen umzusetzen, das sich beispielsweise in Form von Dokumentationen erhalten und weitergeben lä sst [7]. 35 5.3 Sammlung von Projektprofilen Standardisierte Projektprofile („Projektsteckbriefe“), die zum Projektabschluss zur Ergänzung der traditionellen Dokumentation erstellt werden müssen, können Wissen und Erfahrungen zumindest schlagwortartig und zusammenfassend aufnehmen. Diese Profile können dann mithilfe einer Datenbank und Suchmaschinen Mitarbeitern zukünftiger Projekte zur Verfügung gestellt werden, die über Deskriptoren oder im Volltext suchen können. Beispielsweise können bei Software-Entwicklungsprojekten in Projektprofilen Merkmale abgelegt werden wie: Entwicklungsumgebung und Einsatzumgebung der Software (Hardware, Systemsoftware), eingesetzte Entwicklungstools, beteiligte Stellen und Unternehmensbereiche, Funktionsbereiche, Anwendungsgebiete, Umfang Datenbasis, beteiligte Mitarbeiter usw. Insgesamt entsteht damit eine systematische Sammlung von Projektprofilen, die nachfolgenden Projekten einen Fundus an Wissen und Erfahrungen bereitstellen oder zumindest die Möglichkeit bieten, gezielt auf Wissensträger zuzugehen. 5.4 Yellow Pages Ein anderer Ansatz greift das Problem auf, dass nach dem Ende von Projekten die Mitarbeiter nur noch mit großem Aufwand identifizierbar und kontaktierbar sind. Dies verhindert Ad-hoc-Nachfragen an diese Mitarbeiter aus nachfolgenden Projekten, in denen ähnliche Frage- oder Problemstellungen auftauchen. Daher werden Personenregister aufgebaut, in denen den Mitarbeitern ihre Projektzugehörigkeiten sowie die Schwerpunkte ihrer Projektaufgaben zugeordnet werden. Außerdem werden Angaben zu weiteren Kenntnissen, Fähigkeiten und Merkmalen den Mitarbeiterangaben hinzugefügt (Sprachkenntnisse, Erfahrungen mit speziellen Verfahren, Materialien oder Maschinen, Mitgliedschaften in Netzwerken und Vereinigungen usw.), so dass interne Yellow Pages entstehen (oder: Expertenregister, Werweiß-was-Datenbank). Diese könnte bei Bedarf nach Deskriptoren oder Stichworten durchsucht werden, um schnell einen Ansprechpartner zu einer spezifischen Fragestellung zu finden. Sinnvollerweise werden die Personendaten ergänzt um Daten zu Kommunikationswegen (derzeitiger Arbeitsplatz, Telefonnummer, E- Mail-Adresse …), um eine schnelle und unbürokratische Kontaktaufnahme zu unterstützen. Informationstechnik dient neben der Unterstützung der Verzeichnisfunktionen vor allem der Unterstützung der direkten Kommunikation zwischen Mitarbeitern etwa via Telefon, Bildtelefon, Fax, E-Mail, Videokonferenz, Diskussionsforen, Chat u. Ä. Möglicherweise können in eine derartige Datenbank auch externe Wissens- und Erfahrungsträger aufgenommen werden (z. B. Lieferanten, Berater, ehemalige Mitarbeiter), wenn eine Kontaktaufnahme im Problemfall mit ihnen möglich und gewünscht ist. Der Aufbau von Yellow Pages folgt einer Strategie der Personalisierung, nach der für ein Unternehmen wichtiges Wissen sehr stark an die Personen geknüpft ist, die es aufgebaut und entwickelt haben; dieses implizite Wissen kann zuvorderst über direkte und persönliche Kommunikation ausgetauscht werden [4]. Nach dieser Strategie wird Wissen nicht primär in Dokumenten oder Dateien gesammelt, aufbereitet und verfügbar gemacht, sondern vor allem die direkte Kommunikation zwischen Wissensnachfrager und Wissensanbieter zum Wissensaustausch angestrebt und unterstützt. Dies wird durch Expertenregister forciert, die Auskunft geben, wer in einem Unternehmen zu welchen Themen kompetent Auskunft geben kann. Akzentuiert ausgedrückt geht es bei dieser Strategie der Personalisierung „eigentlich“ gar nicht um das Management von Wissen, sondern um das Management der Kommunikation zwischen Wissenden. Der Aufbau von Yellow Pages ist mit keinem großen Aufwand verbunden, der Nutzen wird im Unternehmen jedoch relativ schnell sichtbar werden. Oftmals bietet sich eine Einbindung in ein unternehmensinternes Intranet an. Allerdings muss bei der Umsetzung ein Konzept für die laufende Ergänzung und Pflege der Einträge vorgesehen werden, da dies für die Qualität der Daten entscheidend ist. 6 FAZIT Projektorganisation wird in Unternehmen immer häufiger eingesetzt, um schnell und flexibel auf innovative und interdisziplinäre Fragestellungen zu reagieren. Projekte gelten zudem als besonders lernintensive Organisationen. Jedoch sind Projekte temporäre Organisationen, nach Projektende sind Unterlagen und Ansprechpartner nur schwer erreichbar. Daher gilt es für Projekte besonders, P M - M E T H O D E N / I N S T R U M E N T E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 36 durch gezielte Maßnahmen neues Wissen und neue Erfahrungen zu identifizieren, aufzubereiten und zu verteilen. Erfolg versprechende Maßnahmen setzen vor allem beim Projektabschluss an, währenddessen ausdrückliche und bewusste Schritte der Reflexion des Projektgeschehens - insbesondere der Identifikation und Darstellung von „Lessons-Learned“ - intensiviert werden müssen. Dabei ist von den Führungskräften eine Arbeitsatmosphäre zu sichern, die eine offene und konstruktive Diskussion erlaubt. Daneben können systematische Sammlungen von Projektsteckbriefen und von Ansprechpartnern für Fachthemen die Wiederverwendung von Wissen im Unternehmen unterstützen. ■ Literatur [1] Backof, M. B./ Hartman, C.: Changing the Future of World. In: Knowledge Edge 1/ 1999, S. 11 [2] Burghardt, M.: Projektmanagement - Leit faden für die Planung, Überwachung und Steuerung von Entwicklungsprojekten. 4. Aufl., Siemens, München 1997 [3] Disterer, G.: Social Barriers for Knowledge Databases in Professional Service Firms. In: Khosrowpour, M. (Hrsg.): Challenges of IT- Management in the 21st Century - Proc. IRM A 2000 Conference. Idea, Hershey-London 2000, S. 1088-1089 [4] Hansen, M. T./ Nohria, N./ Tierney, T.: What‘s Your Strategy For Managing Knowledge. In: Harvard Business Review 2/ 1999, S. 106-116 [5] Hartman, C. P.: Interview with Michael Earl: CKOs - Who Are They and What Do They Do? In: Knowledge Edge 1/ 1999, S. 16-21 [6] Heisig, P.: Erfahrung sichern und Wissen transferieren: Wissensmanagement im Projektmanagement. In: PROJEK TM ANAGEMENT 4/ 98, S. 3-10 [7] Nonaka, I.: A Dynamic Theory of Organizational Knowledge Creation. In: Organization Science 2/ 1994, S. 14-37 [8] Saynisch, M.: Wissensmanagement im PM tut not - aber so einfach ist das nicht! In: PROJEK TM ANAGEMENT 4/ 98, S. 11-13 [9] Steinle, C./ Eickhoff, M./ Vogel, M.: Vitalisierung von Unternehmen durch organisationales Lernen in Projekten. In: Steinle, C./ Eggers, B./ Thiem, H./ Vogel, B. (Hrsg.): Vitalisierung. FA Z, Frankfurt 2000, S. 277-293 Autor Georg Disterer ist Professor für Wirtschaftsinformatik am Fachbereich Wirtschaft der Fachhochschule Hannover. Seine Lehr- und Forschungsgebiete umfassen Informationsmanagement, Projektmanagement, Wissensmanagement; sein beruflicher Werdegang schließt langj ä hrige Stationen als Unternehmensberater und als Verwaltungsdirektor ein. Anschrift Fachbereich Wirtschaft Fachhochschule Hannover Ricklinger Stadtweg 120 D -30459 Hannover Tel.: 05 11/ 92 96-6 51 Fax: 05 11/ 92 96-6 60 E -Mail: georg.disterer@wirt.fh-hannover.de 37 Zusammenfassung Am Ende jeder Projektbesprechung stehen Ergebnisse und Entscheidungen. Moderation ist das Werkzeug, das Sie dabei unterstützt, dieses Ziel zu erreichen: Mit Moderation kommen Sie zeitsparend zu Ergebnissen und Entscheidungen. Als Moderator behalten Sie die Übersicht: Die Diskussionen sind zielorientiert. Es werden keine Punkte vergessen. Voraussetzung für effektive Moderation ist die Kenntnis der Moderationsregeln und Erfahrung in Team-Kommunikation und Visualisierung. Misserfolge in Projektbesprechungen sind das Ergebnis mangelnder Kenntnisse in den „soft facts“. Deshalb sollte jeder Projektleiter seine Moderationsfä higkeiten entwickeln. Abstract The aim of each project meeting is to get results and decisions. Presentation is the tool that supports you to achieve this goal: Presentation helps you to results and decisions without waste of time. The presenter has the overall view: Discussions are single-minded. Points won’t fall into oblivion. Requirement for effective presentation is the knowledge of the presentation rules, experience in team communication and in visualisation. Failures in project meetings are the outcome of lacking knowledge in “soft facts”. Therefore each project leader should develop his presentation abilities. Schlagwörter Ablauf, Abschluss, Maßnahmenplanung, Moderationsregeln, Tagesordnung(spunkte), Themenbearbeitung, Vereinbarungen, Ziel 1 DIE SITUATION: UNBEFRIEDIGEND Neun Personen sind voller Begeisterung dabei. Die Ideen sprudeln, kaum kann der Erste aussprechen, da fällt schon der Nächste ihm mit einem neuem Einfall ins Wort. Alle sind davon überzeugt: Das Projekt „Unser erster Messeauftritt“ wird der Hit! Für den Messestand gibt es schon drei Vorschläge, als Aufmerksamkeitserreger liegen eine Produkt- Show auf Großleinwand, ein sprechender Roboter und ein Schnellzeichner als Ideen auf dem Tisch - gut, dass die Sekretärin mitschreibt! Nach eineinhalb Stunden trennt man sich, geht gut gelaunt auseinander: „Prima, wie gut wir uns verstehen, wie kreativ wir gemeinsam sind. Wir sind eben einfach ein tolles Team! “ Die ersten Zweifel beschleichen die Sekretärin, als sie das Protokoll schreibt. Wer ist jetzt eigentlich wofür verantwortlich? Und bis wann soll was erledigt sein? Es sind ja nur Vorschläge P M - M E T H O D E N / I N S T R U M E N T E So machen Ihre Projektbesprechungen Sinn! Von rituellen Routineveranstaltungen zu Ergebnissen und Entscheidungen U L R I K E W I K N E R P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 38 da und noch keine Entscheidungen! Und sollten nicht auch Einladungen an Kunden und Geschäftspartner geschrieben werden? Darüber wurde ja noch gar nicht gesprochen! 2 DIE URSACHEN: ALTBEKANNT Die Unzufriedenheit über Projekt- Meetings ist weit verbreitet. Nur die Hälfte aller Projektbesprechungen werden als nützlich und effizient empfunden. Die Gründe für die Unzufriedenheit sind vielfältig: ● Einladungen sind ungenau oder nichts sagend, ● die Tagesordnung ist überfrachtet oder nicht strukturiert, ● während der Sitzung schweifen einzelne Teilnehmer ab, andere wiederum halten Monologe, ● Teilnehmer, die sich während der Besprechung passiv verhielten, identifizieren sich nicht mit den Ergebnissen und behindern Entscheidungen oder „karten nach“, ● es werden keine Entscheidungen getroffen, ● die Entscheidungen werden nicht oder mit erheblichem Zeitverzug dokumentiert, keiner weiß mehr so genau, worum es eigentlich ging, ● und das alles hat außerdem noch „ewig“ gedauert. 3 DIE LÖSUNG: MODERATION So komplex wie die Ursachen sind auch die Fähigkeiten, die für effektive Projektbesprechungen erforderlich sind. Gefordert sind hier Kompetenzen wie Organisation, aktives Gestalten von Gruppenprozessen und eine starke Zielausrichtung. Gefordert ist also team- und ergebnisorientierte Gesprächsleitung durch einen Moderator. Die organisatorischen Vorbereitungen von Besprechungen fallen Projektleitern relativ leicht. Schwieriger wird es, wenn es um die gruppendynamischen Prozesse geht. Die meisten Projekt-Manager befassen sich lieber mit Zahlen und Strategien als mit den so genannten „soft facts“. Dabei sind gerade diese für das Gelingen von Sitzungen ausschlaggebend! Wenn eine Besprechung schief läuft, liegt das fast immer an der schlechten oder gar nicht vorhandenen Moderation. Den Beweis dafür anzutreten ist allerdings schwierig. Die Frustration ist bekannt und wird zum Scherz gemacht: „Ich habe die ganze Woche gesessen - völlig umsonst! “ Zahlen, die die verantwortlichen Führungskräfte zum Handeln bringen würden, gibt es so gut wie nicht. Kaum ein Unternehmen weiß wirklich, wie viel Zeit und Energie in Besprechungen verschwendet werden. Sitzungscontrolling ist unbekannt. Für Kaffeefilter gibt es ein Budget, das überwacht wird - für die viel kostbarere Zeit und Kompetenz, die Mitarbeiter in Besprechungen verwenden oder verschwenden, hingegen nicht. 4 DER ABLAUF „Gute“ Projekt-Meetings sind aber weder Zufall noch Zauberei. Generell müssen Sitzungen vom Projektleiter oder einem der Teilnehmer moderiert werden. Der Moderator macht am Anfang noch einmal das Besprechungsziel klar, dann werden Informationen zusammengetragen und Aufgaben verteilt. Am Ende jedes Meetings steht eine Rückblende, bei der über Ergebnisse und Ablauf reflektiert wird. Der klassische Ablauf einer Moderation besteht aus vier Phasen: Einstieg, Bearbeitung der Tagesordnungspunkte, Maßnahmenplanung und Abschluss. 4.1 Der Einstieg Die Sitzung wird eröffnet, das Besprechungsziel, das auf der Agenda steht, noch einmal bekannt gegeben, der Zeitplan abgestimmt. Teilnehmer, die neu in der Gruppe sind, stellen sich vor. Bei der ersten Sitzung werden außerdem Vereinbarungen für Gesprächsführung und Verhalten sowie die Protokollverantwortung festgelegt. Vereinbarungen für Gesprächsfüh- Abb. 1: Die Projektbesprechung 39 rung und Verhalten bei Projektbesprechungen sind z. B.: ● Wir lassen uns ausreden. ● Wir sind gemeinsam für die Erreichung der Ziele verantwortlich. ● Wir achten alle darauf, Aussagen zu visualisieren. ● In Diskussionen fassen wir uns kurz. ● Störungen haben Vorrang u. a. m. Power-Tipp: Als erste Information muss das Ziel des Meetings genannt werden. Achten Sie darauf, nicht mehrere Ziele zu vermischen! Wenn Sie in Ihrem Projekt-Team z. B. über die neue Lagerhalle diskutieren, sind alle mit voller Konzentration bei diesem Thema. Steht dann als letzter Tagesordnungspunkt (TOP) „Ideensammlung für die Gestaltung des Richtfestes“ auf dem Programm, kommen nur wenige Einfälle. Der Schwenk von der Kosten-Nutzen-Diskussion zur Kreativität wird schwer vollzogen, der Themenwechsel wird als frustrierend empfunden. 4.2 Die Themenbearbeitung In der zweiten Phase werden die Themen in der Reihenfolge der Tagesordnung bearbeitet. Ein Projektmitarbeiter prä sentiert Informationen zum TOP und gibt Empfehlungen für die Entscheidung. Aufgabe des Moderators ist es, die konkrete Themenbearbeitung zu sichern. Dazu gehört es, in der Diskussion allen Redegelegenheit zu geben und Killerphrasen, die Argumente oder Personen abqualifizieren, zu unterbinden. Detailverliebtheit muss ebenso entgegengesteuert werden wie dem Ausweichen einzelner Teilnehmer, die sich lieber auf die Sach- oder emotionale Ebene zurückziehen wollen. Power-Tipp: Fragen Sie als Moderator nach, ob allen klar ist, worum es eigentlich geht. Sie werden erstaunt sein, wie oft diese Frage unterschiedliche Sichtweisen zu Tage bringt, die sonst verborgen geblieben wären! Scheuen Sie sich auch nicht vor Fragen wie: Ist dieses Thema für alle von Bedeutung? Was ist das gewünschte Ziel? Gibt es unterschiedliche Interessen und Zielausrichtungen? Welche Wege führen zum Ziel? 4.3 Die Maßnahmenplanung Die Ergebnisse der Themenbearbeitung münden in Maßnahmen. Für jedes Arbeitspaket werden Verantwortung und Termin festgelegt. Damit werden die Teilnehmer zu konkreten Aktivitäten verpflichtet und eindeutige Termine fixiert, um die Durchführung sicherzustellen. Die Ergebnisse aus dem Maßnahmenplan, kurz ToDo-Liste, sind Basis für weitere Entscheidungen, die von allen entwickelt und von allen getragen werden. Festzustellen, dass gemeinsam Ergebnisse festgelegt und dann auch erzielt werden, motiviert für künftiges Engagement und macht Ihre Besprechungen sinnvoll! Die Phasen 2 und 3 wiederholen sich für jeden Tagesordnungspunkt. 4.4 Der Abschluss In diesem Rückblick wird reflektiert: ● Wie ist die Besprechung gelaufen? ● Was war gut, was sollte ge ändert werden? ● Sind wir mit dem Ergebnis zufrieden? ● Wie können wir unsere Effizienz steigern? ● Was steht als Nächstes an? (Zum Beispiel ein neuer Termin, um die Ergebnisse aus dem Maßnahmenplan zu kommunizieren und nächste Schritte festzulegen.) Power-Tipp: Schaffen Sie Standards für Ihre Projekt-Meetings! Dazu gehören eine verbindliche Form für Agenda, Einladung und Protokoll, die Einführung von Gesprächs- und Verhaltensregeln für Besprechungen sowie ein Formblatt für den Besprechungsabschluss, das Ihnen das Verbesserungspotenzial verdeutlicht. 5 DIE PERSON Wer soll die Gesprächsführung übernehmen? Häufig übernimmt dies der Projektleiter. Dieser kann P M - M E T H O D E N / I N S T R U M E N T E beitspakete klar und den Verantwortlichen bekannt ist - damit beugen Sie späteren Schwierigkeiten vor. Power-Tipp: Die zu treffenden Maßnahmen müssen eindeutig sein. Wer nicht genau versteht, was er zu tun hat, kann die an ihn gestellten Erwartungen nicht erfüllen! Häufig scheitert die Durchführung daran, dass Aufwand und Komplexität unterschätzt wurden. Als Moderator achten Sie darauf, dass der Umfang der Ar- P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 40 sich kraft Autorität durchsetzen, wenn es z. B. zu Zeitüberschreitungen kommt oder Diskussionen aggressiv und persönlich werden. Der Sache kommt dies allerdings nicht immer zugute, denn damit können Prozesse unterdrückt werden. Als Folge davon wird das Engagement der Mitarbeiter gebremst und die Ergebnisse werden nicht von allen getragen. Als Projektleiter sollten Sie in Moderation ausgebildet sein. Dann können Sie entscheiden, welche Besprechungen Sie selbst moderieren und wann Sie besser einen anderen Teilnehmer mit der Moderation beauftragen oder einen externen Moderator heranziehen. Power-Tipp: Bilden Sie mindestens einen weiteren Projektmitarbeiter in Moderation aus! So müssen Sie nicht jede Besprechung selbst moderieren, und bei schwierigen Besprechungen unterstützen Sie sich gegenseitig. Das Ziel ist nicht „Moderation um jeden Preis“, sondern gute und zielgerichtete Moderation. Dazu muss der Moderator sehr gute praktische Kenntnisse in Teamkommunikation haben. Hinzu kommt noch das Wissen der nachfolgenden Moderationsregeln, die den guten Moderator auszeichnen: ● Er ist ein guter Zuhörer. ● Er nutzt aktives Zuhören zum Lenken der Besprechung, zur Konfliktentschärfung, wenn die Partner aufeinander prallen, um verständlich zu machen, was nicht allen verständlich ist. ● Er strukturiert den Ablauf und die Argumente. ● Er schafft ein sachliches Verhandlungsklima. ● Er motiviert die Teilnehmer, sich aktiv und ergebnisorientiert an der Projektbesprechung zu beteiligen. ● Er vermittelt jedem Teilnehmer seine Wertschätzung und das Gefühl der Bedeutung seiner Beiträge für den Besprechungserfolg. Mit diesen Regeln moderieren Sie Verhandlungen erfolgreich! Die Moderationsregeln entsprechen teilweise den Regeln, die gute Projektleiter beachten. Wie der Projektleiter für das gesamte Projekt, so ist der Moderator für diese Besprechung derjenige, der in jeder Situation die Übersicht behält, bei dem alle Fäden zusammenlaufen und der mit der Art und Weise der Moderation das Besprechungsklima wesentlich bestimmt. Als Moderator bereiten Sie sich besonders gründlich vor: ● Sie müssen das Thema so weit beherrschen, dass Sie Fragen stellen können, die Entscheidungen vorbereiten und die Zielklarheit unterstützen. ● Sie müssen feststellen können, ob ein Beitrag vom Thema abweicht, und die Partner dann zurückführen. ● Sie müssen wissen, wann ein Bereich erschöpfend behandelt wurde, und dann zum nächsten Aspekt überleiten. ● Sie müssen die Teilnehmer namentlich ansprechen können. ● Sie müssen die Aufgaben der Teilnehmer in diesem Projekt kennen und ihre Spezialgebiete. Als Moderator stehen Sie über den Parteien: ● Sie liefern keine Beiträge zur Sache. ● Sie bewerten nicht die Qualität der Beiträge. ● Sie verhalten sich nicht parteiisch, indem Sie eine Diskussion zugunsten einer Gruppe verlängern oder abbrechen. ● Bei Zusammenfassungen geben Sie eine objektive Sichtweise weiter. ● Sie werten in den Zusammenfassungen nicht im Sinne von Gewinn oder Niederlage. Als Moderator legen Sie die Spielregeln fest: Die Spielregeln werden vor der eigentlichen Verhandlung festgelegt. Zu den Spielregeln gehören: ● die Angabe der Zeitbudgets für die einzelnen Tagesordnungspunkte, für Beiträge und Diskussionen; ● Unterbrechen, wenn ein Teilnehmer die Redezeit überschreitet. Dies gilt bei wiederholtem Überziehen, beim ersten Mal genügt es, den Partner zu mahnen; ● notieren Sie die Wortmeldungen in der Reihenfolge des Eingangs und erteilen Sie auch in dieser Reihenfolge den Partnern das Wort; ● nach Möglichkeit sollte die Worterteilung für die Teilnehmer abwechselnd erfolgen. Als Moderator eröffnen Sie die Verhandlung: ● Bei der Eröffnung nennen Sie das Thema. ● Sie stellen ggf. die Teilnehmer vor. ● Sie fordern die Beteiligten zur Präsentation ihrer Argumente auf. 41 ● Sie stellen danach eine Initialfrage, wenn die Problemstellung noch nicht deutlich wurde. Als Moderator leiten Sie die Verhandlung: ● Sie notieren Wortmeldungen und erteilen das Wort. ● Sie unterbinden Zwiegespräche. ● Sie wehren Angriffe gegen Ihre Führung kurz und bündig ab. Sie verteidigen sich dabei keinesfalls. ● Sie bleiben stets freundlich und gelassen. ● Sie zeigen keine Unsicherheit (selbst wenn Sie diese verspüren), denn eine unsichere Moderation gefährdet den Besprechungserfolg. ● Sie fassen kurz zusammen, wenn ein Punkt erledigt ist, und auch, wenn die Besprechung stagniert. Danach stellen Sie eine Initialfrage, die sich am Stand des Meetings orientiert. ● Sie weisen Beiträge zurück, die nicht zielführend und themenorientiert sind. ● Sie folgen der Besprechung und können sich jederzeit einschalten. ● Sie weisen unfaire Angriffe der Teilnehmer untereinander zurück und verhindern, dass unfaire Methoden eingesetzt werden. Als Moderator schließen Sie die Verhandlung: ● Stellen Sie Fragen, mit denen Sie herausfinden, ob für alle Partner die Besprechung beendet ist. ● Fordern Sie die Teilnehmer zu einem Abschluss-Statement auf. ● Geben Sie eine kurze und unparteiische Zusammenfassung der Besprechung. ● Bedanken Sie sich für die aktive Teilnahme, das kooperative Verhalten u. a. m. Die ausführlichen Moderationsregeln werden ergänzt durch die nachfolgend aufgelisteten sieben goldenen Grundregeln erfolgreicher Moderation. 1. Klarheit schaffen und kommunizieren: Welcher Zweck wird mit diesem Meeting verfolgt? Welches Besprechungsziel soll erreicht werden? 2. Rechtzeitige Einladung mit klar strukturierter Tagesordnung. Jeder TOP erhält einen Zeitrahmen und einen Verantwortlichen: Das ist der Leitfaden für den Moderator! 3. Die richtigen Teilnehmer einladen! 4. Immer wieder auf Zielklarheit achten, die Themenbearbeitung auf das Ziel ausrichten. 5. Auf die Zeit achten, passive Teilnehmer aktivieren, Monologe begrenzen, eine konstruktive Atmosphäre schaffen. 6. In der Rückblende die Ergebnisse zusammenfassen, Verbesserungspotenzial ermitteln. 7. Das Protokoll zeitnah (innerhalb von 72 Stunden) erstellen; es muss in den Punkten mit den TOPs übereinstimmen. Ergebnisse, Beschlüsse und Vereinbarungen müssen als Sätze formuliert werden. Stichpunkte führen zu Missverständnissen. Durch diese sieben Grundregeln werden Ihre Besprechungen effektiv! Sie setzen Ihr Wissen als Moderator ein, Sie werfen Ihre ganze Überzeugungskraft in die Waagschale - und doch stecken Sie in der Projektbesprechung fest. Die Argumente sind ausgetauscht, aber ein gemeinsames Ergebnis ist nicht in Sicht. Versuchen Sie es mit einer oder mehreren der im Folgenden beschriebenen Maßnahmen. Die besten Notausgänge für stagnierende Projektbesprechungen: ● Machen Sie ein „Blitzlicht“, eine Momentaufnahme der Situation: Wo stehen wir? Was haben wir bisher erreicht? Welche Empfindungen haben wir? ● Sprechen Sie über das gemeinsame Ziel! Machen Sie noch einmal deutlich, was das heutige Besprechungsergebnis und was das Projektziel ist und was es für die Teilnehmer und das Unternehmen bedeutet. ● Tauschen Sie den Platz mit anderen Teilnehmern! Wer sich körperlich an den Platz eines anderen setzt, hat es leichter sich dessen Sichtweise anzueignen (ohne sie zu übernehmen oder seine eigene aufzugeben! ). Da dieser Platztausch von manchen als lächerlich empfunden wird, schlagen Sie ihn als Spiel vor. ● Lassen Sie bei unvereinbaren Gegens ätzen die Teilnehmer die Argumente der anderen wiedergeben: Ein Teilnehmer trägt die Argumente eines anderen vor und lä sst sich von diesem so lange korrigieren, bis er mit der Wiedergabe zufrieden ist. Anschließend werden die Rollen getauscht. Das trägt ganz wesentlich zum gegenseitigen Verständnis bei. ● Machen Sie eine Zusammenfassung! Visualisieren Sie dabei noch einmal das Besprechungsziel, das Projektziel und vor allem das bis- P M - M E T H O D E N / I N S T R U M E N T E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 42 her Erreichte. Damit wird klar, dass es nicht nur Trennendes, sondern auch Gemeinsamkeiten gibt, dass nicht nur Schritte bis zum Ergebnis offen sind, sondern dass auch bereits einiges erreicht wurde. Das motiviert und wirkt zielführend! ● Notieren Sie Pro- und Kontra- Argumente für alle sichtbar! Dadurch machen Sie transparent, welche Argumente und welche Gegenargumente vorliegen. Es wird übersichtlich, was bereits „erledigt“ und was „noch offen“ ist. ● Legen Sie eine Pause ein! Ideal ist, wenn dies eine Pause ist, in der sich alle körperlich in Bewegung bringen, um dadurch ihre geistige Beweglichkeit zu steigern. Dazu genügt schon der Gang zur Kantine. ● Verlegen Sie den Besprechungsort, am besten an den Ort des eigentlichen Geschehens, also dahin, wo das Projektergebnis genutzt werden soll. Dies öffnet die Augen für die wirklichen Bedürfnisse zumindest eines Teils der Stakeholder und kann die Glaubhaftigkeit von Argumenten belegen. ● Vertagen Sie den Punkt, an dem sich die Geister scheiden! Handelt es sich dabei nicht um einen Meilenstein, hilft oft zeitlicher Abstand, um beim nächsten Mal zu einer Entscheidung zu kommen. ● Laden Sie einen Experten dazu ein! Seine Meinung gilt doppelt, denn er ist einerseits Experte für das Problem (und hoffentlich auch für die Lösung) und außerdem nicht in die Firmenhierarchie eingebunden. Die Teilnehmer erwarten, von ihm die objektive Sichtweise zu erfahren, nach der sie ihr Handeln ausrichten können. ● Suchen Sie den Konsens! Halten Sie fest, worin Sie übereinstimmen - und sei es die Stagnation der Besprechung -, was Sie bereits erreicht haben, welches Ziel Sie alle anstreben. Sie werden entweder die bislang noch nicht bekannte Ursache für eine Blockade herausfinden oder über den „Konsens im Dissens“ einen neuen Weg zu den Teilnehmern finden. 6 VISUALISIEREN Über Augen, Ohren und über den Tastsinn nehmen wir Informationen auf. Meist dominiert ein Sinneskanal, über den wir besonders ansprechbar sind. Wichtig ist dieses Wissen dann, wenn Sie (Teil-)Ergebnisse visualisieren. Entnehmen Sie Tabelle 1, wie Sie welchen Wahrnehmungstyp am besten erreichen. Visualisierungen werden inzwischen standardmäßig in vielen Projektbesprechungen eingesetzt. Visualisieren heißt aber noch lange nicht, mit Erfolg zu visualisieren, also für die Teilnehmer das Verständnis für Strukturen oder Ergebnisse zu erhöhen! Wie aus der oben stehenden Tabelle hervorgeht, erreichen Sie mit einer Methode noch lange nicht alle Teilnehmer. Nutzen Sie deshalb gerade in schwierigen Projektbesprechungen einen Methoden-Mix und lassen Sie sich dabei von kinä sthetisch ausgeprägten Teilnehmern unterstützen. Gerade diese Teilnehmer erreichen Sie über die „üblichen“ Methoden der Diskussion und der Visualisierung am Flip Chart kaum; wenn sie aber mitwirken können, wird ihr haptisches Bedürfnis gestillt und ihre Motivation, zum Besprechungsergebnis beizutragen, steigt deutlich an. Beachten Sie Folgendes beim Visualisieren: ● Nutzen Sie je nach Situation Pinnwand, Overheadprojektor, Modelle. ● Halten Sie Blickkontakt zu den anderen Teilnehmern, auch wenn Sinneskanal Information Wahrnehmungstyp Auge Visualisierung auf Flip Chart, Overhead Demonstration eines Beispiels Vorführung am Modell Video Schriftliche Unterlagen Visuell Ohr Vortrag Diskussion Kassetten Auditiv Tastsinn Selbstständiges Handeln: Modell anfassen Anderen etwas erklären Kinä sthetisch Tabelle 1: Wahrnehmungstypen 43 Sie visualisieren. Mit etwas Übung gelingt das gut! ● Visualisieren Sie aus der Sicht der anderen Teilnehmer und aus Ihrer eigenen Sicht! ● Verbale Aussagen und visuelle Darstellung müssen übereinstimmen! ● Fertigen Sie die visuelle Skizze life an, bringen Sie keine vorgefertigten Unterlagen mit! ● Nutzen Sie die Wirkung von Farben: - Rot: Begeisterung, Aktivität - Grün: Prestige, Image, Selbstbehauptung - Blau: Zufriedenheit, Statuserhalt, Beruhigung - Gelb eignet sich nicht für Visualisationen, da es nur schwer lesbar ist. 7 WANN WIRD EIN MODERATOR BENÖTIGT? Sie benötigen einen Moderator, wenn einer oder mehrere der nachfolgenden Punkte auf Ihre geplante Projektbesprechung zutreffen: ● Teilnehmer: Mehr als vier Personen nehmen an der Projektbesprechung teil. ● Dauer: Das Meeting dauert voraussichtlich länger als eine Stunde. ● Ergebnis: Das Ergebnis hat für die Teilnehmer strategische Bedeutung. ● Ergebnis: Das Ergebnis ist wirtschaftlich für Sie oder Ihre Geschäftspartner/ Kunden bedeutend. ● Ergebnis: Das Ergebnis wird außerhalb des Unternehmens beachtet. ● Ergebnis: Das Ergebnis hat eine starke Auswirkung in Ihrem Unternehmen. ● Ergebnis: Das Ergebnis wird größere Änderungen auslösen. ● Ziele: Es besteht ein hoher Klärungsbedarf hinsichtlich der Ziele bei allen oder einzelnen Projektpartnern. ● Emotionen: Das Meeting und das zu erwartende Ergebnis rufen große Ängste bei den Beteiligten hervor. ● Widerstände: Es ist mit starken Widerständen von einigen Partnern zu rechnen. ● Historie: Dies ist der zweite oder dritte Versuch, die Besprechung bestimmter Themen zu einem Ergebnis zu führen. ● Emotionen/ Sachzwänge: Nehmen Sie einen (externen) Moderator, wenn Sie sich der Besprechungsleitung aus irgendeinem Grund nicht gewachsen fühlen. ■ Literatur [1] Burghardt, Manfred: Einführung in Projektmanagement. Publicis, Erlangen 1995 [2] DeMarco, Tom/ Lister, Timothy: Wien wartet auf Dich. Hanser, Wien 1991 [3] Fisher, Roger/ Sharp, Alan: Führen ohne Auftrag. Campus, Frankfurt 1998 [4] Kupper: Zur Kunst der Projektsteuerung. Oldenbourg, Wien 1996 [5] Lange, Dietmar: Management von Projekten. Sch ä ffer Poeschel, Stuttgart 1995 [6] Mayrshofer, Daniela/ Kröger, Hubertus: Prozeßkompetenz in der Projektarbeit. Windmühle, Hamburg 1999 [7] Rosner, Siegfried: Wirkungsvolle Kommunikation. Friedrich-Ebert-Stiftung, Bonn 1999 [8] Schneider, Maximilian/ Schwarz, Ekkehard/ Wikner, Ulrike: Kooperation - der direkte Weg zum Erfolg. Campus, Frankfurt 1999 [9] Seifert, Josef: Besprechungs-Moderation. Gabal, Offenbach 1995 [10] Sperling/ Wasseveld: Führungsaufgabe Moderation. WRS, Planegg 1996 [11] Wikner, Ulrike: Networking. Lexika, Würzburg 2000 [12] Wikner, Ulrike: Crashkurs Verhandeln. Campus, Frankfurt 2000 Autorin Ulrike Wikner, Jahrgang 1952. Inhaberin der Unternehmensberatung KESS - Kompetent Effektiv Systematisch Strategisch; Projektmanagement fachfrau (RK W/ GPM), Lehrbeauftragte an der Fachhochschule Ansbach; Fachbuchautorin: Kooperation, Campus 1999; Existenzgründung, Beck 2000. Tätigkeitsschwerpunkte: Projektleitung von Organisations- und Veranstaltungsprojekten, auch in englischer Sprache; Einführung von Projektmanagement in KMU; Moderation von Besprechungen und (Podiums-)Diskussionen; Seminare und Vorträ ge zu Projektmanagement. Anschrift KESS Kompetent Effektiv Systematisch Strategisch Robert-Koch-Straße 12 D -90522 Oberasbach Tel.: 09 11/ 6 48 09 28 Fax: 09 11/ 6 48 09 29 E -Mail: ulrikewikner@aol.com P M - M E T H O D E N / I N S T R U M E N T E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 44 Zusammenfassung Die systematische Erfassung, Beurteilung und Überwachung von Risiken in Projekten wird zunehmend bedeutender. Dies wird von den Projektträ gern erkannt. Sie verlangen einen begleitenden Prozess. Risk Management, wie es von Alpha Project Line vorgesehen ist, wird in die übrigen Projektprozesse integriert und durch geeignete Tools unterstützt. Das Verfahren zur Durchführung der wichtigsten Aktivitäten ist beschrieben, die Beurteilung und Überwachung durch Softwaretools vereinfacht. Mit umfassenden Checklisten wird vom Know-how der Autoren profitiert. Abstract Risk Management is a technique that identifies, assesses, plans for, and controls risks. It is a formal process to plan and control actions, for the avoidance and containment of threats, in order to increase the probabilit y of a project ’s success. Risk Management encompasses the indentification and assessment of threats, definition of probabilities and impacts, and the preparation and implementation of risk avoidance and contingency plans. It also implements controls, responsibilities, and monitoring to ensure effectiveness. It ensures that all risk items are documented, owned, tracked, and controlled throughout the project life cycle. It is performed in parallel with - but as a separate process to - cost, schedule, qualit y, and requirements management activities. Risk Management is accomplished by the project team. Alpha Project Line integrates a separate risk management module which can be used on its own or which can be integrated with any Project Reference Model based on Alpha Project Workbench. Schlagwörter PM-Software, Risikomanagement 1 EINLEITUNG Risk Management ist die Technik, Risiken zu identifizieren, zu analysieren, zu bewerten, Vermeidungs- und Vorsorgemaßnahmen zu planen und zu initiieren sowie zu überwachen. Alpha Project Line bietet das Addon-Produkt zu diesem Thema. 2 INTEGRATION IN EIN PRAXISORIEN- TIERTES PROJEKTFÜHRUNGSSYSTEM Alpha Project Line ist ein einzigartiges und umfassendes Projektführungssystem. Es ist konzipiert, um Informatik-, Organisations- und Engineering-Projekte erfolgreich abzuwickeln. Die Funktionalität von Alpha Project Line beginnt bei der Generierung von Projekten auf Basis von Projektreferenzmodellen; aufbauend auf deren Struktur, unterstützt es die Planung und Budgetierung, die Projektsteuerung (Arbeitsaufträge, Protokolle und offene Punkte) und das Controlling sowie das Qualitätsmanagement, den Änderungsprozess und endet beim Projektabschluss. Alpha Project Line besteht aus den Komponenten ● Projektverfahren (Methode) ● Software (Alpha Project Work- Bench, Alpha Project TeamLink) ● Projektreferenzmodelle (Knowhow) ● Training 3 BEDEUTUNG DES RISK MANAGEMENTS Immer wichtiger in den Projekten wird die Beurteilung von Risiken in den Projekten. Der Risk Manager ist als zus ätzlicher Prozess in das Projektverfahren integriert und wird durch das Softwaretool Alpha Project WorkBench unterstützt. Der Risk Manager verhilft den Projektverantwortlichen, die Projektrisiken frühzeitig zu erkennen und die entsprechenden Vermeidungsmaßnahmen einzuleiten. 4 RISK MANAGEMENT ALS ZUSÄTZ- LICHER PROZESS ABGEBILDET Risk Management wird als zus ätzlicher Prozess abgebildet. Ein Online- Ratgeber führt die Verantwortlichen gezielt zu den benötigten Informationen. Je Projektphase sind Aktivitäten und Lieferobjekte (Ergebnisse) definiert, welche die systematische Durchführung des Prozesses unterstützen. Mit den Lieferobjekten sind Dokument- und Kalkulationsvorlagen (Word, Excel) verknüpft, welche die Systematik der Risikobewertung Alpha Project Line Risk Manager R O B E R T H A S L E R 45 P M - S O F T W A R E enthalten und die Berichterstellung vereinfachen. Der Online-Ratgeber enthält sowohl die Beschreibung des Prozesses bis zur Ebene Arbeitsanweisung als auch umfassendes Know-how in Form von diversen Checklisten. Sämtliche Aufgaben, welche aus diesem Prozess entstehen, werden mit dem Softwaretool Alpha Project WorkBench entweder als Arbeitsaufträge oder als offene Punkte (Pendenzen) auf einfachste Weise erstellt, überwacht und abgewickelt. Die Erledigung von Vermeidungsmaßnahmen können via Webbrowser auch von dezentralen Stellen direkt in die Projektdatenbank zurückgemeldet werden. Der Projektleiter hat so die Übersicht über die durch ihn erteilten Aufgaben. 5 PROJEKTROLLEN Neben den in Alpha Project Line beschriebenen Projektrollen mit deren Aufgaben definiert der Risk Manager weitere Projektrollen: so den Risiko-Manager, den Risikomanagement-Ausschuss usw., jeweils mit einer auf das Risikomanagement bezogenen Aufgabenbeschreibung. 6 EINSATZ UND VERFÜGBARKEIT Der Risiko-Management-Prozess ist verfügbar für das generelle Standardprojektmodell, die Evaluation und Einführung von Standard-Software sowie auch für komplexe Softwareprojekte und wird eingesetzt von Kleinbis zu Großprojekten. Der Einsatz ist erfahrungsgemäß nicht von der Größe eines Projektes abhängig, sondern von dessen Komplexität und Bedeutung für das Unternehmen. Der Aufwand für die Ermittlung der Risiken ist naturgemäß sehr unterschiedlich. Die vielen Checklisten erlauben es jedoch, sehr rasch zu den entscheidenden Ergebnissen zu gelangen. 7 EINFÜHRUNG DES RISK MANAGERS Da es sich um ein Add-on-Produkt von Alpha Project Line handelt, ist dessen Einsatz Vorausset- Abb. 1: Übersicht Alpha Project Line Abb. 2: Risikomanagement- Prozess Abb. 3: Online- Ratgeber Risk Manager P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 46 zung für den Risk Manager. Erfahrungsgemäß wird mit einem eintägigen Initialisierungsworkshop begonnen. Darin wird anhand eines durch den Kunden zu bezeichnenden Projektes die Risikoanalyse gestartet und die Einführung vorgenommen. Alle darauf folgenden Tätigkeiten kann der Kunde selbstständig durchführen. Der Risk Manager unterstützt die einzelnen Schritte des Prozesses. ■ Autor Robert Hasler, Jahrgang 1955, Gründer und Gesch ä ftsführer der HISC AG Projektmanagement in Eschenbach. Seit bald 20 Jahren leitet er Projekte im IT-Bereich. Er führt Projektmanagement-Trainings für Projektleiter und Management sowie für Projektteammitglieder durch und unterstützt die Kunden in der Erstellung von Projektreferenzmodellen und im Aufbau von Projektmanagement-Systemen. Seine Erfahrung aus diversen Projekten fließt permanent in die Weiterentwicklung der Alpha Project WorkBench, um dadurch eine praxisorientierte Toolbox für den effizienten und trendbewussten Projektleiter sicherzustellen. Er ist seit 1998 zertifizierter Project Manager. Anschrift HISC AG Projektmanagement Lehmgruebstraße 7 CH-8733 Eschenbach Tel.: ++41/ 55/ 2 86 46 66 Fax: ++41/ 55/ 2 86 46 60 E -Mail: info@hisc.ch Abb. 4: Übersichtsreport Risiken/ Chancen Abb. 5: Toolunterstützung mit Alpha Project WorkBench Abb. 6: Rückmeldung via Webbrowser 47 P M - S O F T W A R E Zusammenfassung Zu Beginn des 21. Jahrhunderts stehen wir vor großen Herausforderungen und Verä nderungen. Mit immer größer werdender Geschwindigkeit erschließen wir neue technologische Möglichkeiten. Dabei gilt gerade die Baubranche unter Fachleuten als immer noch innovativä rmster Wirtschaftszweig. Um hier aber den Anschluss an die Industrie/ Dienstleistungsbranche herzustellen, werden in den n ä chsten Jahren enorme Anstrengungen nötig sein, um moderne Informationstechnologien in die Planungs- und Bauprozesse zu integrieren und diese dabei gleichzeitig zu reorganisieren. Dem Projektmanagement kommt dabei eine Schlüsselfunktion zu. Das heißt, die Entwicklung der spezifischen Projektarchitektur ist Voraussetzung für den effektiven Einsatz von Informationsmanagementsystemen sowie Infrastruktursystemen. Abstract At the beginning of the 21 st century we are facing big challenges and changes. With tearing speed we develop new technology possibilities. So far, in particular the building trade has been seen by specialists as the least innovative line of business. To achieve the connection to the manufacturing and service industries, enormous efforts will be needed in the forthcoming years in order to integrate modern information technologies into the planning and building processes which will be reorganised at the same time. So project management plays a key role in this process, which means that the development of the specific project architecture is the precondition for the effective use of information management systems as well as of infrastructure systems. Schlagwörter Informationsmanagementsystem, Informationstechnologien, Infrastruktursystem, Projektarchitektur, Prozessorientiertes Projektmanagement, Überproportionale Datenorganisation 1 EINLEITUNG Zu Beginn des 21. Jahrhunderts stehen wir vor großen Herausforderungen und Veränderungen. Mit immer größer werdender Geschwindigkeit erschließen wir uns neue technologische Möglichkeiten. Aber die Forderung nach individueller Kundenorientierung und marktgerechten Lösungen vergrößert den Innovations- und Anpassungsdruck. Fachspezifisches Know-how allein reicht heute nicht mehr aus, um den komplexen und anspruchsvollen Marktbedingungen gerecht zu werden. Kommunikations- und Einfühlungsvermögen, verbunden mit der Fähigkeit ganzheitlich zu denken, wird gerade im Projektmanagement immer wichtiger, denn wir brauchen die Vernetzung unterschiedlichster Nischen. Ganzheitliches Erkennen, Denken und Handeln bilden wichtige Erfolgsfaktoren für die Abwicklung von Projekten, unterstützt durch Tools, die in der Lage sind, die notwendige Infrastruktur bereitzustellen, um alle Projektbeteiligten und Betroffenen Prozessorientiertes Projektmanagement bei Hochbauprojekten G E R D P R I E B E P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 48 gleichzeitig an den Geschehnissen teilhaben zu lassen. Hierbei gilt es gerade für die Baubranche, die immer noch unter Fachleuten als innovativärmster Wirtschaftszweig angesehen wird, den Anschluss an den Dienstleistungs- und Industriesektor herzustellen und die Verwendung von Informationstechnologien in ihre Prozesse zu integrieren. Dies bedeutet für die Projektplanung und das Projektmanagement die Schaffung von unternehmensunabhängigen und projekt- und prozessorientierten Organisationen, die Wissen, Informationen und Fähigkeiten fachübergreifend kommunizieren und managen. Ein Bauprojekt stellt in seinen spezifischen Anforderungen ein sehr komplexes Gebilde dar, welches von vielen Spezialisten geplant, genehmigt und realisiert wird. Ein Projekt ist ein virtuelles Unternehmen auf Zeit, das eine individuelle Struktur, Organisation und Architektur benötigt. Vor diesem Hintergrund haben wir uns bei Priebe Architektur seit Jahren mit der Veränderung von Prozessen beschäftigt. Unser Weg ging dabei über die Entwicklung und Integration des Qualitäts- und Projektmanagements bis zur Entstehung des prozessorientierten Projektmanagements oder auch prozessorientierten Architekturmanagements. Aus diesen Entwicklungsschritten ist im Juni 1999 die Software ProArcM ® hervorgegangen, ein Informationsmanagement- und Infrastruktursystem, welches die unterschiedlichsten Softwaretools der Projektbeteiligten unternehmensübergreifend integriert und dabei alle Informationen und Daten auf einer interdisziplinären Datenplattform ablegt. Die zunehmende Geschwindigkeit und der Bedarf nach durchgängigen Informationsmanagementsystemen in Projekten über Internet, Intranet und Extranet ziehen die Notwendigkeit einer überproportionalen Datenorganisation nach sich. Mit ProArcM haben wir ein Werkzeug geschaffen, welches uns in der täglichen Projektarbeit, aber auch in den Unternehmensprozessen enorm unterstützt. Es ist hierbei zu der starken Bewertung einer ganzheitlichen Projektvorbereitung gekommen. Das heißt, die Entwicklung der spezifischen Projektarchitektur ist Grundvoraussetzung für den effektiven Einsatz eines Informationsmanagementsystems. Dort liegt im Grunde die Projekt- oder auch Unternehmensintelligenz. Wo liegen nun die spezifischen Vorteile der beteiligten Projektunternehmen? ● Durch frühzeitige Abstimmungen der Schnittstellen unter fachlichen, funktionalen, technologischen und projektorientierten Gesichtspunkten werden klare Verfahrensanweisungen fachübergreifend festgelegt. ● Durch das Festlegen der projektweiten Zeichnungscodierung erhält jeder Projektbeteiligte eine größtmögliche Projekttransparenz, die gerade während der Realisierung für den Construction Manager enorm wichtig ist. ● Durch das einmalige Anlegen der Projektorganisation wie z. B. - die Projektbeteiligtenliste, - die Projektverantwortlichen und Vertreter, - die Informations- und R ASI- Matrix Responsable, Approval, Service, Informed und - die Vergabe von Zugangs- und Sektionsrechten werden Personalressourcen und damit Kosten eingespart. ● Durch das Anlegen des Projektnetzplanes erhält jeder Projektbeteiligte Zugang zum Workflowmanagement, zu Arbeitspaketen, Terminen, Dokumenten, Checklisten. Hierbei werden sehr frühzeitig Zielabweichungen erkannt, die automatisch zu einem Prozesscontrolling führen und damit ein Krisenmanagement gar nicht oder weniger wahrscheinlich machen. ● Im Lasten- und Pflichtenheft werden alle projektrelevanten Daten des Kunden dokumentiert und konzentriert. ● Nachdem die Projektparameter und Projektbeteiligten im System integriert worden sind, werden in einer etwa halbtägigen Einweisung die Struktur und der Zugang von ProArcM vermittelt, die jetzt jedem Projektbeteiligten auf der Datenbank zur Verfügung stehen. Hierbei konnten wir ebenfalls die wichtige Erfahrung sammeln, dass Offenheit, Neugierde und Disziplin für eine schnelle Anwendung sehr hilfreich sind. Voreingenommensein und Verharren in Gewohnheiten erfordern Geduld, aber auch Unterstützung des Projektmanagements im Veränderungsprozess. Auch das Bewusstsein für den Stellenwert von Informationen ist sehr 49 P M - S O F T W A R E unterschiedlich ausgeprägt und bedarf einer konsequenten Personalentwicklung. Eines ist auch zu berücksichtigen: Moderne und wenn auch sehr leistungsfähige Tools sind immer Mittel zum Zweck. Sie ersetzen keine Erfahrungen und Kreativität. Sie sind so gut wie das Instrument für den Musiker. Allerdings decken sie Schwächen, Fehler oder Sorglosigkeit wesentlich schneller auf. Abschließend lassen sich daraus die generellen Erfolgsfaktoren für ein Projekt und Unternehmen ableiten: ● Schaffen von standardisierten Automationsprozessen ● Schaffen einer unabhängigen Projektorganisation ● Schaffen einer höheren Planungs- und Produktqualität ● Realisieren von kürzeren Entwicklungszeiten ● Minimierung von Haftungsrisiken ● Sicheres Handling in schnellen komplexen Prozessen ● Verbesserung der Wirtschaftlichkeit ● Lückenloses Datenmanagement nach ISO 9000/ 2000 ● Zunahme von Systemlösungen ● Steigerung der Flexibilität im Änderungsmanagement 2 DIE INTERDISZIPLINÄRE DATENPLATTFORM Der interdisziplinären Datenplattform wird die Zukunft gehören, denn die Zunahme der Komplexität steigt beständig an. Wir arbeiten aber heute immer noch mit längst überholten Verfahren, Methoden und Organisationen. Wenn wir aber Kundenanforderungen und Kundenziele befriedigen wollen und das vielfältige Wissen, welches für die Projektentwicklung und -realisierung erforderlich ist, sinnvoll einsetzen und zum Wohle aller nutzen wollen, sind Veränderungen in unserem Denken und Handeln unumgänglich. Dies führt in der Folge zur Schaffung einer unabhängigen Projektorganisation, der interdisziplinären Datenplattform, die projektorientiert strukturiert ist. Denn für die Zukunft können wir uns nicht mehr leisten, mit unterschiedlichen Unternehmensorganisationen Projekte, Produkte oder Systeme zu realisieren. Wir müssen von Anfang an die Grundlagen schaffen, um Daten projekt- und un- Landschaftsarchitekt Finanzmanagement Entsorgungsberater Tragwerksplaner Prüfingenieur TGA-Planer Innenarchitekt Architekt Bodengutachter Vermesser Fachberater Finanzmanagement Architekturmanagement Auftraggeber Behörden Entsorger Verfahrenstechniker Behörden Sicherheitsberater Brandschutz Baubiologe Bauphysiker Logistikplaner Kosten- Management Einrichtung Möbel Security Bauunternehmen Abnahmen Prüfer Baubetriebs- Management Behörden Technisches Management Dienstleistungs- Management Organisations- Management FM-Verwaltung Gebäudeautomation Einweisung Schulung 2. Testphase Korrektur Abnahme Maschienen Einrichtung 1. Testphase Behörden Bauleiter Technik Bauleiter Architektur Projektleiter Versicherung Lichtdesigner visuelle Leitsysteme Baubetriebsmanagement Bauleiter Außenanlagen Facility Management INBETRIEBNAHME RECYCLING BERATUNG PLANUNG FM-MANAGEMENT BAUAUSFÜHRUNG Kunde Nutzer Projektabschluss Projektvorbereitung ProArcM Datenbank 〉 Abb. 1: Interdisziplinäre Datenplattform Abb. 2: Kommunikationsarchitektur Projektteam Architekt Tragwerkplaner TGA-Planer Bauphysiker CAD Termin AVA Grafik Excel Text Daten Programme Router Projektbeteiligte Projektdaten Landschaftsarchitekt Brandschutz Pro ArcM R Zugangsberechtigung verwaltung Kunden-/ Lieferanten- Datenbank P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 50 ternehmensübergreifend zu kommunizieren und damit die gewünschten Ergebnisse sicherzustellen. Das bedeutet, die heutige Logistik in den Projektabläufen ist zu reorganisieren und prozessorientiert auszurichten. Mit dem prozessorientierten Architekturmanagement wird ein neues Aufgabenfeld in der Projektarbeit geboren. Die Aufgabe des Systemmanagers ist es, das QM- + PM-System ständig zu verbessern, um den Projektablauf weiter zu optimieren. 3 KOMMUNIKATIONSARCHITEKTUR Die Kommunikationsarchitektur bildet das Rückgrat der interdisziplinären Datenplattform. Dadurch ist zum einen das Navigieren unterschiedlichster projektspezifischer Softwaresysteme möglich, zum anderen werden die Daten, Adressen und Dokumente organisiert. Damit ist eine hohe Datenverfügbarkeit für ein effektives Informations- und Kommunikationsmanagement garantiert. 4 PROZESSORIENTIERUNG Die Prozessorientierung ist das zweite wesentliche Element der interdisziplinären Datenplattform. Hierbei werden drei Prozessebenen unterschieden: 1. Ebene Prozessdarstellung aller Prozesse im Projekt 2. Ebene Project Excellence für die interne und externe Wertung der Prozesse und der Projektergebnisse 3. Ebene Planung und Realisierung des Projektes Die Komplexität eines Projektes, vom Projektmarketing bis zur FM- Phase, wird von 11 Phasen vertikal erfasst und geplant. Damit ist ein entscheidender Schritt getan, Planungs- und Bauprozesse schlanker, straffer und effektiver zu gestalten sowie die Koordination und Organisation der Teilprozesse mit den technologischen Möglichkeiten besser managen zu können. 5 SYNCHRONE PROZESSE Die synchrone Prozessorientierung ist eine der wichtigsten Voraussetzungen zur Verkürzung der Entwicklungsprozesse und Strukturierung der Datenflüsse. 6 PROZESSCONTROLLING Die größte Schwäche im Ablauf der Planungs- und Bauprozesse ist ProArcM Project Excellence Phasen Projektstart 1 2 3 4 5 6 7 8 9 10 11 Marketing Projektvorbereitung Konzept Design Konstruktion Ausschreibung Bauphase Inbetriebnahme Projektabschlußphase Kundenservice FM-Phase Kundenanfrage Kick-Off Planungskonzept Entwurf Ausführungsplanung Bauvertrag abstimmmen Baubetriebsmanagement 1. Testphase Projektziele Gewährleistung 60 Monate Organisationsmanagement Leistungsbeschreibung Kundenziele Tragwerkskonzept Tragwerk Detailplanung Massenerstellung Baustelleneinrichtung Auswertung Führungsmanagement Jährliche Objektbegehung technisches Management Rahmenvereinbarungen Kundenerwartung TGA-Konzept TGA-Entwicklung Sonderplanung Leistungsbeschreibung Grundstein Nachbesserung Teammotivation Dienstleistungsmanagement Angebotsabgabe Kundenanforderung Aussenanlagen Brandschutzgutachten Flucht/ Rettungwegeplanung Bieterliste erstellen Rohbauerstellung 2. Testphase Mitarbeiterleistung Kaufmännisches Management PR-Arbeit Bedarfsermittlung Brandschutzkonzept Aussenanlagen Schließanlagenplanung entwickeln des Bauablaufs Richtfest Prüfung Finanzmanagement Vorschriften Securitykonzept Prüfingenieur Prüfingenieur einbinden Einladung Abnahme/ Fachabnahme Inbetriebnahme Terminmanagement Checkliste Sonderberater Kostenberechnung Planliste Ausschreibung erstellen Ausbau Eröffnungsfest Informatiomsmanagement Zielkonflikte Flächenberechnung Security Detailliste Versand Behörden- / TÜV-Abnahme Lieferantenleistung Budget Modellbau Bauphysiker Projektzusammenstellung Auswertung Nacharbeit Prozeßmanagement Lastenheft Funktionsprogramm Sonderberater Kostenfeststellung Schlußabnahme Methodenmanagement Auswahl-Internes-Team Material/ Farbkonzept Farb- und Materialkonzept SUB Mission Rechnungsprüfung Erfahrungsaustausch Auswahl-Externes-Team Layoutplanung Layoutplanung Präsentation Kostenabrechnung Baufirmen Kundenbefragung Organigram Visuelles CAD-Modell Virtuelles CAD-Modell Auswahl Kostenabrechnung Planer Kundenzufriedenheit Terminplanung Kostenschätzung Präsentation Einladung Kostenabrechnung Bank PMA + FK Befragung JurProM Präsentation Vorlage Bauantrag 1. Verhandlung Abgleich Baukonten PMA +FK Zufriedenheit Bankabstimmung Behördengespräche Genehmigungsfähigkeit 2. Verhandlung Schlußdokumentation Befragung sonst. int. Gruppen Vorstudie Funktion+Raumprogramm Prüfung Vertragsprüfung Bestandspläne Zufriedenh. sonst. int. Gruppen Analyse Unterzeichnung Revisionspläne Projektergebnis Pflichtenheft Wartungshinweise Projektperformance Angebot erstellen Änderungsmanagement Änderungsmanagement Änderungsmanagement Änderungsmanagement Änderungsmanagement Interne Archivierung Kostenschätzung Kostenberechnung Kostenabgleich Kostenanschlag Kostenabrechnung Controlling Controlling Controlling Controlling Controlling Controlling Controlling Controlling Controlling Controlling Controlling Kundenbeauftragung Kundenfreigabe Pflichten- Kundenfreigabe Kundenfreigabe Kundenfreigabe Kundenfreigabe Kundenabnahme Projekterfolg Projektmanagement Kundenauftrag Kundenauftrag Projektvorbereitung heft und Hauptauftrag Kundenzufriedenheit Verbesserungsmaßnahmen 80% 85% 90% 95% 100% Projektende Abb. 3: Prozessorientierung Abb. 4: Prozesscontrolling Entwurf F A Priebe Architektur C 29.07.99 29.07.99 86 % 10.08.99 10.08.99 Layoutplanung F A Priebe Architektur C 29.07.99 29.07.99 86 % 10.08.99 10.08.99 Tragwerk F A Priebe Architektur C 29.07.99 29.07.99 86 % 10.08.99 10.08.99 TGA-Konzept F A Priebe Architektur C 29.07.99 29.07.99 86 % 10.08.99 10.08.99 Bauphysiker F A Priebe Architektur C 29.07.99 29.07.99 86 % 10.08.99 10.08.99 Präsentation F A Priebe Architektur C 29.07.99 29.07.99 86 % 10.08.99 10.08.99 5 51 P M - S O F T W A R E die unvollständige Erfassung s ämtlicher Tätigkeiten, Notwendigkeiten oder gar Hindernisse für die Projektrealisierung. Kein Mensch im Automobil- oder Schiffbau würde jemals auf die absurde Idee kommen, ohne Planung der Fertigungsprozesse sein Produkt herzustellen, geschweige denn, eine fertigungsbegleitende Planung in Erwägung zu ziehen. Es wäre einfach Dummheit. Wenn wir das Image „Pfusch am Bau“ ändern wollen, dem schon viele zum Opfer gefallen sind, muss unsere Vorgehensweise wesentlich professioneller werden. Für die Zukunft können wir mit dieser Methode keine anspruchsvollen und komplexen Gebäudesysteme realisieren. Die Entwicklung zu mehr Automation erfordert auch ein effektives und vorausschauendes Management und die lückenlose Erfassung aller Prozessteile. Wir brauchen Werkzeuge, die den Fokus auf Zeitplanung, Verantwortlichkeiten, Arbeitspakete, Dokumente, Freigaben, Abnahmen und Controlling richten: ein Werkzeug wie den dynamischen Netzplan, der ein Prozesscontrolling als Risikomanagement verwendet. Krisenmanagement ade! Das Prozesscontrolling wird das Ergebniscontrolling ablösen, und der Systemmanager, als Qualitäts- oder Projektmanagementbeauftragter, wird laufende Prozesse kontinuierlich verbessern. ■ Autor Gerd Priebe, Dipl.-Ing. Architekt, Jahrgang 1958. Nach mehreren Stationen bei Stararchitekten, wie Prof. Schürmann - Köln, Prof. O. M. Ungers - Frankfurt und Prof. Richard Meier - New York, gründete der Kölner Architekt Gerd Priebe 1995 das Büro Priebe Architektur in Dresden. Seit 1995 besch ä ftigt er sich mit Projektmanagement und der Optimierung von Arbeitsprozessen im Planungsbereich. Bei der Realisierung von großen Bauvorhaben, vor allem für die Automobilindustrie (Ford, Delphi/ General Motors, USA), werden diese Kenntnisse eingesetzt und verfeinert. Nach der QM-Zertifizierung des Unternehmens Priebe Architektur im Jahre 1997 erfolgte 1998 die Teilnahme am Sä chsischen Staatspreis für Qualität. Seit 1999 ist Gerd Priebe A ssessor für Projektmanagement. Das Ergebnis einer langjä hrigen Entwicklung und Optimierung der Prozesse im Planungsbereich war 1999 ProArcM ® . Vorträ ge: TU Magdeburg, TU Dresden, GPM-Regionalgruppe Weimar, Building Performance Frankfurt, Europ ä isches Wirtschaftsforum Berlin. Anschrift Priebe Architektur Bautzner Str. 19 D -01099 Dresden Tel.: 03 51/ 8 29 48-0 Fax: 03 51/ 8 29 48-20 E -Mail: office@priebe-architektur.de P R O J E K T M A N A G E M E N T 4 / 2 0 0 0 52 Zusammenfassung Risk Management ist eine wichtige Disziplin, um den Erfolg von Projekten mit zu sichern. Im Zeichen zunehmenden Wettbewerbsdruckes dient Risk Management auch dem Schutz vor wirtschaftlichem Schaden durch fehlgeschlagene Projekte. Gleichzeitig ist Risk Management immer noch die „große Unbekannte“ der Projektmanagementdisziplinen. Ursachen dafür liegen sowohl im psychologischen Bereich (wer will sich schon bei Projektstart mit den möglichen Risiken besch ä ftigen), in der praktischen Anwendbarkeit als auch in dem unmittelbaren Nutzen für die Projektbeteiligten (welches sind die geeigneten Maßnahmen, um die Risiken einzud ä mmen? ). Im ersten Teil wird die theoretische Basis für den Risk-Management-Prozess gelegt, d. h., die Zusammenh ä nge von Risiken und Projekten werden beschrieben. Im Mittelpunkt stehen dabei solche Risiken, die im Umfeld von Informationstechnologie-Projekten anfallen. Im zweiten Teil werden die Grundlagen des Risk Managements beschrieben und ein neuer Ansatz zur Durchführung von Risk Management entwickelt. Schlagwörter Checkliste Risiken, Close-down, Fr ühwarnsystem, Projektabschluss, Projektprozesse, Risikomanagement, Schwache Signale, Start-Up 1 WAS IST RISIKO IM PROJEKT? Für die Beschreibung des Risk Managements ist es erforderlich zu klären, wie der Begriff Risiko inhaltlich zu verstehen ist und wie sich Risiko auf ein Projekt auswirkt. Umgangssprachlich wird der Begriff häufig gleichgesetzt mit einer drohenden Gefahr: „Es ist riskant, bei Rot über die Ampel zu gehen.“ In diesem Artikel soll für „Risiko“ folgende Definition gelten: „Ein Risiko ist ein Ereignis, von dem nicht sicher bekannt ist, ob es eintreten und/ oder in welcher Höhe es einen Schaden verursachen wird. Es lä sst sich aber eine Wahrscheinlichkeit für den Eintritt dieses Ereignisses (Risikowahrscheinlichkeit) und/ oder für die Höhe des Schadens angeben.“ [10, S. 6] Risiken im Projekt sind mögliche Ereignisse oder Situationen, die für das Projekt gegenüber der Planung nachteilige Folgen haben. Sowohl in der Literatur als auch in der Praxis sind die Einschätzungen zu den Risiken, welche in Projekten entstehen können, breit gestreut. Dennoch sind - zumindest in Teilen - Parallelen zu finden. Einheitlich werden z. B. technische Risiken genannt. Auch Risiken im Bereich von Kosten und/ oder Wirtschaftlichkeit sowie in der Kommunikation und Dokumentation werden übereinstimmend erwähnt. Häufig sind auch unrealistische oder zu Anfang unzureichend konkretisierte Ziele für das Scheitern eines Projektes verantwortlich. Einen groben Überblick über die verschiedenen Risikoarten gibt Abb. 1. Aufgrund der Vielzahl möglicher Risiken ist eine Kategorisierung erforderlich. Diese ist sowohl unter sachlichen als auch zeitlichen Gesichtspunkten möglich. Bei der sachlichen Kategorisierung werden die einzelnen Risiken verschiedenen übergeordneten Gruppen zugeordnet, wie z. B. Risiken fachlicher, technischer, personalpolitischer oder finanzieller Art. Bei der zeitlichen Kategorisie- Risk Management als Projektmanagement-Disziplin Immer noch die „große Unbekannte“? D A N I E L A F R E U N D 53 rung hingegen werden die Risiken den entsprechenden Projektphasen, in denen sie auftreten, zugeordnet. 2 RISK MANAGEMENT Wie bereits angedeutet, treten erfahrungsgemäß bei jedem Projekt Risikopotenziale auf. Die Bandbreite reicht vom einfachen Terminverzug bis zum Abbruch des Projektes. Einen Ausweg bietet die konsequente Integration von Risk Management in den Projektplan und die Projektabwicklung [7, S. 252 ff.]. Im Gegensatz zu den Methoden des klassischen Projektmanagements, bei denen Projektrisiken - wenn überhaupt, dann nur indirekt - berücksichtigt werden, indem man für Abweichungen von Projektzielen in der Projektplanung Sicherheitszuschläge einrechnet, dient Risk Management direkt der Analyse und Gestaltung der Projektrisiken [8, S. 49]. Risk Management stellt heute eine integrierte Teildisziplin des Projektmanagements dar und unterstützt wesentlich die Überwachung, Steuerung und Kontrolle des Projektes. 2.1 Der Prozess des Risk Managements Mit Hilfe des Risk Managements sollen Risiken so gemanagt werden, dass keine Projektkrisen entstehen. Dieses geschieht nicht in Form einzelner voneinander unabhängiger, einmaliger Aktivitäten, sondern als Prozess. Zum besseren Verständnis wird ein kurzer pragmatischer Überblick über die erforderlichen Tätigkeiten im Prozess des Risk Managements gegeben. Der Risk-Management-Prozess lä sst sich in vier Stufen unterteilen: 2.1.1 Risikoidentifikation Die wichtigste Aufgabe des Risk Managements liegt in der Risikoidentifikation [5, S. 172]. Die Notwendigkeit, möglichst alle potenziellen Risiken für das Projekt zu erkennen, zeigt schon das alte Sprichwort „Gefahr erkannt, Gefahr gebannt“. Bei der Risikoidentifikation geht es in erster Linie darum, mögliche Risiken für das spezifische Projekt zu finden. Zur eigentlichen Risikoidentifikation stehen eine Reihe von Hilfsmitteln zur Verfügung. Die gebräuchlichsten sind Checklisten, daneben werden aber auch die Kreativitäts- und Prognosetechniken wie z. B. Brainstorming und Brainwriting verwendet. Aufgrund der Vielfalt der zu berücksichtigenden Aspekte ist eine Zusammenarbeit von qualifizierten Kräften aus den betroffenen Unternehmensbereichen erforderlich. 2.1.2 Risikoanalyse Aufgabe der Risikoanalyse ist „das Durchdringen … komplexer Strukturen mit der Zielsetzung einer möglichst vollständigen und genauen Beschreibung der Risikosituation“ [10, S. 43]. Die Risikoanalyse kann in zwei grunds ätzliche Schritte unterteilt werden: ● die Bewertung der Risiken sowie ● die dem Projekt angepasste Klassifizierung der Risiken, welche auf der Bewertung aufbaut. Bei der Risikobewertung werden die identifizierten Risiken hinsichtlich ihrer direkten und indirekten Folgen für das Projekt bewertet. Zur qualitativen und quantitativen Bewertung werden die Parameter Schadensausmaß und -eintrittswahrscheinlichkeit verwendet. Zur Bewertung von Risiken können verschiedene Methoden wie z. B. die Delphi-Methode, die Monte-Carlo- Simulation oder die Probabilistic- Event-Analyse herangezogen werden [10, S. 44]. Idee, Anforderung, Problem Projektergebnis Projektverlauf Interpersonelle Risiken - Skillmangel - Unstimmigkeiten im Team ungesunder Stress Kostenrisiken unterschiedliche Entwicklungsorte - Kunde zahlt nicht Technische Risiken mangelhafte Entwicklungsumgebung unbekannte Tools und Methoden eingesetzte Produkte sind nicht stabil - SW-Architektur hat MŠngel Terminrisiken keine rechtzeitige †bergabe - Projektende verschiebt sich QualitŠtsrisiken - Mangel an Zwischenergebnissen mangelnde Anwendung der Projektmethoden zu wenig Kontrollen/ Tests Ressourcenrisiken zu wenig qualifizierte Mitarbeiter verfŸgbar - Projektleiterwechsel - Projektleiter ist mangelhaft ausgebildet Abb. 1: Auftretende Risiken im Projekt (Beispiele) Abb. 2: Der Risk-Management-Prozess 1. Risikoidentifikation 4. Risikocontrolling 3. Risikobehandlung 2. Risikoanalyse 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 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.