Dynamische Märkte fordern ein aktives Risikomanagement

Neue Schlüssel zum Projekterfolg

Stefan Luckhaus

Die IT ist ein Schlüsselfaktor für die Umsetzung von Geschäftsideen. Der harte Wettbewerb in dynamischen Märkten reduziert die Time-to-Market für neue Business-Anwendungen drastisch, eine kurze Projektlaufzeit und absolute Termintreue sind dementsprechend kritische Erfolgsfaktoren. Während es früher als ausreichend galt, ein IT-Projekt durch das Controlling von Zeit und Budget sowie Qualitätsmanagement zu steuern, rückt heute zunehmend eine weitere Dimension ins Blickfeld: Risiken. Je kürzer die Projektlaufzeit und je kritischer der Endtermin, desto weniger Zeit bleibt dem Projektverantwortlichen, um in kritischen Situationen angemessen zu reagieren. Vor diesem Hintergrund wird das aktive Risikomanagement zum entscheidenden Faktor für den Projekterfolg.

Ein Risiko lässt sich als Ereignis definieren, das ein Projekt oder einzelne seiner Erfolgsfaktoren gefährdet. Sein Ursprung und seine Auswirkungen können sehr vielfältig sein: Die möglichen Einflüsse reichen von fehlenden Skills der Projektmitarbeiter über eine ungenaue Projektkalkulation bis hin zu Naturkatastrophen. So lässt sich für jedes Projekt – in Abhängigkeit vom Projektumfeld – ein spezifisches Risikoportfolio erstellen, die darin enthaltenen Risiken bewerten und geeignete Maßnahmen festlegen, um die Erfolgswahrscheinlichkeit zu erhöhen.

Wissen schafft Sicherheit

Ihren Zweck kann die Risikoanalyse nur dann erfüllen, wenn sie bereits in der Planungsphase eines neuen Projekts erfolgt. Spezielle Tools oder wissenschaftliche Methoden können hier unter Umständen hilfreich sein, unbedingt erforderlich sind sie aber nicht. Meist reichen Projekt-Erfahrung und der gesunde Menschenverstand aus. In der Praxis hat es sich bewährt, bei der Recherche der spezifischen Einflussfaktoren ein Template mit relativ abstrakt umrissenen Standardrisiken zu verwenden. Um es mit konkreten Inhalten zu füllen, erhebt der Projektmanager beispielsweise gezielt Hintergrundinformationen aus dem Kundenumfeld oder verschafft sich in vorgelagerten Mitarbeitergesprächen Klarheit über Stärken und kritische Eigenschaften der Projektteilnehmer. Beschreiben lässt sich jedes potenzielle Schadensereignis durch zwei Attribute, nämlich seine Eintrittswahrscheinlichkeit und die zu erwartende Schadenshöhe. Gemeinsam bestimmen sie das Risikoausmaß. Um das spezifische Risikoprofil eines Projekts zu erstellen, bewertet der Projektmanager die Einflussfaktoren auf beiden Dimensionen. Der Aufwand einer wissenschaftlichen Erhebung exakter statistischer Kennzahlen ließe sich unter dem Kosten-Nutzen-Aspekt für die meisten Projekte allerdings kaum rechtfertigen. Vielmehr beruhen solche Einschätzungen in der Praxis im Allgemeinen auf Erfahrungswerten. Daher reicht auch die Einordnung auf einer Skala mit den Werten High (H), Medium (M) und Low (L) in diesem Zusammenhang völlig aus: Je höher die Eintrittswahrscheinlichkeit und die Schadenshöhe, desto größer die Rolle eines Risikos für den Projekterfolg. Vernachlässigbar sind dagegen Bagatellrisiken mit sehr geringer Schadenshöhe sowie die so genannten Groß- und Katastrophenrisiken, die der Projektleiter ohnehin nicht beeinflussen kann.

Abb. 1: Risikoprofil in der Darstellung in einem Koordinatensystem

Prävention und Reaktion

Oberstes Ziel jeder Risikoanalyse ist es, das Eintreten kritischer Situationen zu verhindern, und wenn dies, wie in den meisten Fällen, nicht möglich ist, zumindest ihre Eintrittswahrscheinlichkeit oder die Schadenshöhe zu reduzieren. Hierfür definiert der Projektleiter zu jedem relevanten Schadensereignis realistische Präventivmaßnahmen, beispielsweise spezielle Verträge, notwendige Trainingsmaßnahmen oder bestimmte Versicherungen. Indem er bereits vor Projektbeginn für ihre Umsetzung sorgt, erhöht er die Erfolgswahrscheinlichkeit des Projekts. Trotzdem besteht immer die Möglichkeit, dass bestimmte Schadenssituationen auch bei einer breiten Palette an Präventivmaßnahmen eintreten. Die Risikoanalyse sieht deshalb immer auch so genannte reaktive Maßnahmen vor, die erst dann zu ergreifen sind, wenn ein Schadensereignis im Projektverlauf eingetreten ist. Nur so ist der Projektleiter im Fall des Falles sofort handlungsfähig und kann negative Auswirkungen auch nachträglich noch minimieren.

Interkulturelle Einflüsse

Viele Risiken spielen für nahezu jedes Projekt eine Rolle. Für solche Standardrisiken liegen häufig bereits umfangreiche Erfahrungswerte vor, so dass sich die Auswirkungen gut abschätzen und geeignete Maßnahmen leicht festlegen lassen. Relativ neu dagegen sind Problemlagen, die sich im Gefolge der Globalisierung ergeben. Die Chancen einer solchen internationalen Zusammenarbeit sind unbestreitbar – gleichzeitig ist es aber möglich, dass die Projektteilnehmer aus völlig unterschiedlichen Kulturkreisen stammen, was insbesondere vom Projektleiter interkulturelle Kompetenz erfordert: Er muss die Gepflogenheiten der jeweiligen Kulturen kennen und sie in seiner Planung angemessen berücksichtigen. Nur dann können sich die verschiedenen Skills der Projektmitarbeiter optimal ergänzen. In der Praxis geht die Internationalität weit über eine gemeinsame Projektsprache hinaus. So müssen die Projektleiter der PASS Consulting Group beispielsweise mit der Tatsache umgehen, dass deutsche Geradlinigkeit nicht in allen Kulturen der Königsweg ist: Von Mitarbeitern aus dem westlichen Kulturkreis können sie üblicherweise erwarten, dass sie konstruktive Kritik annehmen und gemeinsam mit dem Projektleiter nach Verbesserungsmöglichkeiten suchen. Ein asiatischer Mitarbeiter dagegen, der noch keine Erfahrung mit dieser Vorgehensweise hat, wertet eine solch offene Fehleransprache mit hoher Wahrscheinlichkeit als persönlichen Angriff. Dem Projektleiter obliegt in diesem Fall die Aufgabe, behutsam auf Optimierungsmöglichkeiten hinzuweisen, ohne die vorliegende Arbeit als fehlerhaft zu brandmarken. Ein weiteres Beispiel für grundlegende interkulturelle Unterschiede zeigt sich beim Qualitätsmanagement: Während es im Westen üblich ist, dass die Mitarbeiter selbst ihre Verständnislücken durch offenes Nachfragen schließen, bedeutet ein solches Vorgehen in vielen asiatischen Kulturen einen Gesichtsverlust. Ob die Mitarbeiter ein Konzept korrekt aufgefasst haben, muss der Projektleiter also auf anderem Weg verifizieren, etwa durch regelmäßiges Monitoring der Arbeitsergebnisse.

Den Fortschritt einkalkulieren
Eine weitere Entwicklung im Projektgeschäft, die vielfältige Chancen, aber auch Risiken mit sich bringt, ist der Einsatz moderner Technologien. Kommen beispielsweise modellbasierte, generative Entwicklungswerkzeuge zum Zug, verändert sich die gesamte Aufgaben- und Rollenverteilung im Team: Nutzt etwa PASS in einem Projekt seine Software Factory, definiert zunächst wie früher der Business-Analyst die fachlichen und nichtfunktionalen Anforderungen, der klassische Bruch zum technischen Konzept entfällt jedoch. Denn nicht ein technischer Mitarbeiter interpretiert das Fachkonzept und setzt es um, vielmehr erstellt der Business-Analyst selbst mithilfe grafischer Werkzeuge ein Anwendungsmodell. In diesem sind bereits große Teile der Dialoge, Business-Objekte und der Navigation realisiert, womit der Business-Analyst sich schon mitten in der Entwicklungsphase befindet. Er verfeinert das Anwendungsmodell sukzessive, ergänzt Services, in denen er Business-Logik abbildet, fügt Adapter zur Integration von Drittsystemen hinzu oder modelliert die Prozesssteuerung. So kann der Kunde jeden beliebigen Zwischenschritt als Prototyp nutzen, um die Konformität der entstehenden Applikation mit seinen Anforderungen zu überprüfen. Den voll wartbaren Sourcecode schließlich erstellen nicht mehrere Programmierer manuell, sondern die Generatoren auf Basis wieder verwendbarer Komponenten. Generative Technologien bergen also die Chancen einer wesentlich höheren Effizienz sowie eines hohen Grades an Transparenz für den Kunden, der die Anwendung während des gesamten Entstehungsprozesses aktiv mit gestalten kann. Um ihre Möglichkeiten voll auszuschöpfen, muss der Projektleiter allerdings auch die Risiken dieser Technologien kennen und kontrollieren. Da der Factory-Ansatz die klare Rollentrennung zwischen Business-Analysten und Software-Entwicklern aufhebt, besteht die Basis des Projekts aus Fach- und Tool-Spezialisten in einer Person: Sie beherrschen neben den Business-Anforderungen auch die grafischen Werkzeuge und können sie dadurch effizient einsetzen. Momentan sind Mitarbeiter mit diesem Skill-Profil allerdings eher noch die Ausnahme. Zu den obligatorischen Präventivmaßnahmen eines Factory-Projektes gehört es daher, dass jederzeit ein Factory-Spezialist als Coach zur Verfügung steht, der bei eventuell auftretenden Schwierigkeiten sofort eingreift und damit Überschreitungen von Zeit oder Budget verhindert.

Abb. 2: PASS Software-Factory: Chancen und neue Risiken

Unverzichtbar ist beim Einsatz generativer Technologien auch die Konformität zum Entwicklungs-Framework: Während in weitgehend manuellen Entwicklungsprojekten jeder Programmierer seinen individuellen Stil pflegt und ein gewisses Maß an redundantem Code akzeptabel ist, verlangt der Factory-Ansatz die Wiederverwendbarkeit aller Komponenten, Services und Methoden. Mehrfaches Erstellen derselben Elemente würde die Produktivität und damit auch die Termintreue des Projekts gefährden. Geeignete Präventivmaßnahmen sind in diesem Zusammenhang beispielsweise die Einführung eines technisch Verantwortlichen im Projekt sowie regelmäßige Code Reviews. Unter dem Aspekt der Teamorganisation stellt die Generatorentechnologie den Projektmanager ebenfalls vor völlig neue Herausforderungen. Die Business-Analysten werden von Spezialisten wie Web-Designern, Datenmodellieren oder Architekturexperten unterstützt. Diese sind aber nur zeitweise Mitglieder des Projektteams: Sie kommen an verschiedenen Stellen des Entwicklungsprozesses zum Einsatz und erstellen die Templates, Daten- oder Architekturmodelle, auf deren Basis die Generatoren später die konkrete Anwendung produzieren. Da sie häufig parallel Aufgaben in mehreren Projekten zu erfüllen haben, muss der Projektmanager sicherstellen, dass jeder genau dann zum Projektteam stößt, wenn sein Skill benötigt wird. Präventivmaßnahmen sind hier eine präzise zeitliche Planung, alternative Spezialisten mit entsprechenden Skills als Backup sowie eine entsprechende Management-Attention, die wiederum bei Priorisierungskonflikten wichtig ist.

Pläne in die Tat umsetzen
Um im Schadensfall dann tatsächlich vorbereitet zu sein, reicht es nicht aus, die Risiken zu kennen und geeignete Gegenmaßnahmen festzulegen. Vielmehr wird dieses so genannte Risk Assessment mit Projektstart zu einem Teil des Projektberichtswesens. Statusberichte betrachten neben Meilensteinen und Budgets auch jedes identifizierte Projektrisiko. Als sehr übersichtlich hat sich hier beispielsweise die Darstellung des Risikostatus durch eine Ampel bewährt: Schaltet sie auf Rot, sind sofort die vorab festgelegten reaktiven Maßnahmen zu ergreifen. In den meisten Fällen wird der Projektleiter Mitarbeiter sowie Kunden in das Risikomanagement einbinden. Wer seine detaillierte Risikoliste offen und ehrlich führt, wird allerdings schnell feststellen, dass sie selten vollständig zur direkten Weitergabe an andere geeignet ist: Budgetbezogene Risiken eines Festpreisprojektes oder unternehmensinterne Probleme sind in einem Statusbericht für den Kunden deplaziert. Mitarbeiterbezogene Risiken beruhen häufig auf vertraulichen Informationen, die nicht einmal an das eigene Management weitergegeben werden sollten. So muss der Projektleiter zwar zwingend alle Risiken kennen und kontrollieren, gleichzeitig sollte er aber auch genau auswählen, welche Informationen er den jeweiligen Projektbeteiligten weitergibt. Was in der Theorie aufwändig klingt, bedeutet in der Praxis erfahrungsgemäß einen Mehraufwand von etwa ein bis zwei Tagen für die Analyse sowie einem halben Tag pro Woche für das fortlaufende Controlling. Der Nutzen dagegen äußert sich gleich dreifach: In einer höheren Erfolgswahrscheinlichkeit durch die Umsetzung der Präventivmaßnahmen, im rechtzeitigen Erkennen von Problemen durch das regelmäßige Risikocontrolling und in der Prozesssicherheit durch das Festlegen der reaktiven Maßnahmen.

Geschrieben von
Stefan Luckhaus
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.