"Bereit sein ist alles." - Hamlet
Ein Projekt ist so unsicher wie das Leben selbst. Risiken werden nicht um ihrer selbst willen identifiziert, sondern um
sie vorwegzunehmen und zu mindern oder, wenn die Risikominderungsstrategien zu kurz greifen, um sie zu reagieren.
Risiken wirken sich auf die Iterationspläne aus. Iterationen werden bei der Behandlung bestimmter Risiken geplant, um
sie zu begrenzen oder zu mindern. Die Liste der Risiken wird regelmäßig überprüft, um die Effektivität der
Risikominderungsstrategien zu bewerten, die wiederum Überprüfungen des Projektplans und folgender Iterationspläne nach
sich ziehen.
Der Schlüssel zum Risikomanagement besteht nicht darin, zu warten, bis ein Risiko auftritt (und zu einem Problem
oder einem Fehler wird), bevor man eine Entscheidung über die weitere Vorgehensweise trifft. So wie bei einem
Transkontinentalflug eine Kursänderung von nur ein paar Grad eine starke Kursabweichung bei der Landung ergibt, ist das
Risikomanagement in einem frühen Stadium fast immer kostengünstiger und einfacher zu bewerkstelligen als in einem
späten Stadium.
Es gibt drei Hauptstrategien [siehe Veröffentlichung BOE91]:
-
Risikovermeidung. Reorganisieren Sie das Projekt so, dass das Risiko keine Auswirkungen hat.
-
Risikoübertragung. Reorganisieren Sie das Projekt so, dass jemand bzw. etwas anders das Risiko trägt (Kunde,
Hersteller, Bank, ein anderes Element usw.). Eine besondere Strategie der Risikovermeidung.
-
Risikoakzeptanz. Entscheiden Sie sich, mit dem Risiko als unabänderlichem Umstand zu leben. Überwachen Sie
die Risikosymptome und beschließen Sie einen Plan für unvorhersehbare Ereignisse, der vorgibt, was zu tun ist, wenn
ein Risiko auftritt.
Auch wenn Sie entscheiden, das Risiko zu akzeptieren, können Sie dennoch ein Interesse daran haben, es zu mindern,
indem Sie direkte Maßnahmen ergreifen, um seine Auswirkungen zu reduzieren.
Es ist wichtig, zwischen direkten und indirekten Risiken zu unterscheiden. Ein direktes Risiko ermöglicht ein gewisses
Maß an Kontrolle, indirekte Risiken hingegen können nicht gesteuert werden.
Indirekte Risiken sollten zwar nicht außer Acht gelassen werden, haben aber für die Praxis wenig Folgen: Da sie nicht
geändert werden können, macht es wenig Sinn, sich ständig Sorgen über sie zu machen. Stattdessen gilt es, sich auf die
anstehende Arbeit zu konzentrieren.
Manchmal ist ein scheinbar indirektes Risiko tatsächlich ein direktes. Beispiel: Die Abhängigkeit von einem externen
Lieferanten, der eine Komponente oder eine Komponentengruppe bereitstellt. Dies scheint ein indirektes Risiko zu sein,
aber mit Plänen für unvorhersehbare Ereignisse hinsichtlich dieser Komponenten kann das Risiko kontrolliert werden. Es
besteht die Möglichkeit, alternative Lieferanten auszuwählen oder die benötigte Funktionalität selbst zu entwickeln.
Oft gibt es mehr Kontrollmöglichkeiten als man glaubt.
Bei indirekten Risiken kann man entweder feststellen, wie man ein bestimmtes Maß an Kontrolle erreicht werden kann,
oder man kann die Risiken dokumentieren und fortfahren. Es macht keinen Sinn, sich den Kopf zu zerbrechen über Dinge,
die man nicht ändern kann.
Organisation
-
Ist das Engagement für das Projekt ausreichend (einschließlich Management, Tester, Qualitätssicherung und andere
externe beteiligte Parteien)?
-
Handelt es sich um das größte Projekt, das diese Organisation jemals in Angriff genommen hat?
-
Gibt es einen klar definierten Prozess für die Softwareentwicklung? Werden die Anforderungen erfasst und gibt es
ein Anforderungsmanagement?
Finanzierung
-
Ist die Finanzierung des Projekts gesichert?
-
Ist die Finanzierung für Schulung und Anleitung gesichert?
-
Ist das Budget so begrenzt, dass das System zu einem Festpreis geliefert werden muss und andernfalls der
Projektabbruch erfolgt?
-
Sind die Kostenvoranschläge präzise?
Personal
-
Ist genug Personal verfügbar?
-
Verfügen die Mitarbeiter über ausreichend Know-how und Erfahrung?
-
Haben die Teilnehmer des Projekts schon früher zusammengearbeitet?
-
Sind sie vom Erfolg des Projekts überzeugt?
-
Stehen Benutzervertreter für Überprüfungen zur Verfügung?
-
Sind Fachleute verfügbar?
Zeit
-
Ist der Zeitplan realistisch?
-
Kann der Umfang der Funktionalität gesteuert werden, um Zeitpläne einzuhalten?
-
Wie kritisch ist das Lieferdatum?
-
Wurde genug Zeit für präzises Arbeiten eingeplant?
-
Wie soll reagiert werden, wenn ein Mitbewerber sein Produkt zuerst auf den Markt bringt?
-
Wie ist vorzugehen, wenn die Finanzierung des Projekts gefährdet ist? Oder, andersherum formuliert: Was kann getan
werden, um die angemessene Finanzierung des Projekts sicherzustellen?
-
Ist der erwartete Nutzen des Projekts größer als die erwarteten Kosten? (Stellen Sie sicher, dass Sie den Zeitwert
des Geldes nachweisen und die Kapitelkosten rechtfertigen können.)
-
Was wäre, wenn keine Verträge mit wichtigen Anbietern geschlossen werden können?
-
Kann der Erfolg gemessen werden?
-
Gibt es Übereinstimmung hinsichtlich der Erfolgsmessung?
-
Sind die Anforderungen stabil und klar definiert?
-
Ist der Projektumfang fix oder nimmt er noch zu?
-
Sind die geplanten Zeiträume für die Projektentwicklung zu kurz und unflexibel?
-
Hat die Technologie sich bereits in der Praxis bewährt?
-
Sind die Ziele für die Wiederverwendung angemessen?
-
Ein Arbeitsergebnis muss bereits einmal verwendet worden sein, bevor es wiederverwendet werden kann.
-
Möglicherweise sind mehrere Releases nötig, damit eine Komponente so stabil ist, dass sie ohne wichtige
Änderungen wiederverwendet werden kann.
-
Sind die Transaktionsvolumen in den Anforderungen angemessen?
-
Sind die Schätzungen für die Transaktionsrate glaubwürdig? Sind sie zu optimistisch?
-
Sind die Datenvolumen angemessen? Können sie gegenwärtig von Großrechnern bewältigt werden, oder, wenn aus den
Anforderungen hervorgeht, dass eine Workstation oder ein Unternehmenssystem Teil des Design ist, können die Daten
auf diesen Systemen angemessen bewältigt werden?
-
Gibt es ungewöhnliche oder schwierige technische Anforderungen, aufgrund derer das Projektteam Probleme in Angriff
nehmen muss, mit denen es nicht vertraut ist?
-
Ist Erfolg abhängig von neuen bzw. nicht erprobten Produkten, Services, Technologien, Techniken oder neuer bzw.
nicht erprobter Hardware oder Software?
-
Gibt es externe Abhängigkeiten von Schnittstellen zu anderen Systemen einschließlich derer außerhalb des
Unternehmens? Gibt es die erforderliche Schnittstellen oder müssen sie erstellt werden?
-
Gibt es Verfügbarkeits- und Sicherheitsanforderungen, die extrem unflexibel sind (z. B. "das System darf niemals
versagen")?
-
Sind die Benutzer des Systems unerfahren mit dem zu entwickelnden Systemtyp?
-
Besteht ein erhöhtes Risiko aufgrund der Größe und Komplexität der Anwendung oder der Neuartigkeit der Technologie?
-
Gibt es Anforderungen hinsichtlich der Unterstützung nationaler Zeichensätze?
-
Ist es möglich, dieses System zu entwerfen, zu implementieren und dann auszuführen? Es gibt Systeme, die einfach zu
groß oder komplex sind, als dass sie ordnungsgemäß ausgeführt werden könnten.
-
Ist das Projekt von anderen (parallelen) Entwicklungsprojekten abhängig?
-
Ist der Erfolg von gebrauchsfertigen oder extern entwickelten Komponenten abhängig?
-
Ist der Erfolg abhängig von der erfolgreichen Integration von Entwicklungstools (Designtools, Compilern usw.),
Implementierungstechnologien (Betriebssystemen, Datenbanken, Mechanismen für Interprozesskommunikation usw.). Haben
Sie einen Backup-Plan, der die Fertigstellung des Projekts ohne diese Technologien vorsieht?
Die Erfahrung zeigt, dass 85 % der Risiken direkte oder indirekte Auswirkungen auf den Zeitplan und daher auch auf die
Kosten haben. Nur etwa 5 % wirken sich auf die Kosten aus. Der Rest hat keine direkten Auswirkungen auf die Kosten oder
den Zeitplan, jedoch auf die Qualität.
Wenn der Terminplan sehr eng ist, nähern Sie sich dem Endtermin schrittweise mit Teillieferungen an. Vermeiden Sie es,
alles auf einmal zu liefern, nur um den Zeitplan zu halten.
Manche Projekte haben unverrückbare Endtermine. Beispielsweise hat Software, mit der Wahlergebnisse in der Wahlnacht
live analysiert werden sollen, keinen Wert mehr, wenn sie eine Woche nach der Wahl geliefert wird. Oder die Software
wird obsolet, weil ein Konkurrent ein besseres Produkt herausbringt als Sie, während Sie sich noch mitten in der
Konstruktionsphase befinden. Plötzlich sind Sie aus dem Rennen, und Sie können nichts daran ändern. Im Allgemeinen
jedoch haben nur wenige Projekt einen solch kritischen Endtermin. Verzögerungen wirken sich meist auf die Kosten aus.
Im Allgemeinen sollten Sie Ihren Zeitplan anhand Ihrer besten Schätzung erstellen und dabei einen angemessenen
Spielraum für unvorhersehbare Ereignisse einkalkulieren.
Festlegung = Schätzung + Spielraum für unvorhersehbare Ereignisse
Andere Methoden sehen vor, dass man die Erwartungen an die Pläne für unvorhersehbare Ereignisse annähert, aber das ist
ein wenig zu pessimistisch, da nicht alle Risiken tatsächlich auftreten.
Planrisiken sind in verschiedene Tools für Schätzung und Kostenberechnung integriert. Beispielsweise sind viele
Kostenfaktoren im COCOMO-Modell, wie
-
Komplexität (cplx)
-
Vorgaben für Echtzeit (time)
-
Vorgaben für Speicher (stor)
-
Erfahrung (Vexp)
-
Verfügbarkeit guter Tools (tool)
-
Zeitdruck (sced)
eigentlich Risikofaktoren.
Höher entwickelte Techniken für das Risikomanagement beinhalten die Verwendung der Monte-Carlo-Simulation, in der eine
große Anzahl von Szenarios von einem Simulationstool ausgeführt werden, um allgemeine Risiken und unvorhersehbare
Ereignisse zu berechnen [siehe Veröffentlichung KAR96].
|