In diesem Artikel stelle ich ein Beispiel für eine Risikoliste vor. Mit dieser lassen sich im Projektverlauf alle Risiken managemen.
| Nr. | Datum | Beschreibung | S. | Eintr. | Entd. | RPZ | Kategorie | Maßnahme | Indikatoren |
| 1 | 12.16.2012 | Liste der möglichen Risiken für das Projekt ist unvollständig | 3 | 2 | 2 | 12 | Allgemeine planerische Risiken | – Review der Risikoliste mit allen Projektbeteiligten – Prüfen ob im Skript erwähnte Risiken auf das Projekt zutreffen und noch nicht in der Risikoliste enthalten sind |
– zu wenige Risiken identifiziert – es treten häufig unerwartete Probleme auf |
| 2 | 12.16.2012 | Anforderungen sind zu unklar definiert, was zu verschiedenen Interpretationen führen kann | 4 | 2 | 2 | 16 | Fachliche Risiken | – die Anforderungen an das System werden frühzeitig mit dem Kunden besprochen – regelmäßiges Feedback über den Projek- und Entwicklungsstand |
– Der Anforderungstext enthält unklare Begriffe wie sollte, könnte, müsste |
| 4 | 12.16.2012 | Design (CSS) der Anwendung führt zu Darstellungs- problemen | 2 | 2 | 1 | 4 | Personelle Risiken | – manueller Test durch die Entwicklung und den Test | – Tests durch die Entwickler und Tester mit verschiedenen Browsern |
| 5 | 12.16.2012 | fehlende oder nicht ausreichende Kompetenzen für die Ausführung der rollen- spezifischen Aufgaben | 2 | 1 | 2 | 4 | Personelle Risiken | – Rollenverteilung anhand der Eigeneinschätzung der Teammitglieder – Rückfragen, Absprachen und Unterstützung durch das gesamte Team – Aufgabenverteilung & Definition von Lieferterminen (z.B. Dokument X wird von Y bis zum Tag Z fertiggestellt) |
– Lieferungen von Aufgaben zu definierten Terminen werden nicht eingehalten – Lieferungen entsprechen nicht der geforderten Qualität |
Quelle: Projekt des Autors mit Stefan Kleih, Michael Ruhnau, Matthias Köhler, Kim Jansen