Der Business Analyst muss nicht nur Anforderungen sammeln und dokumentieren, sondern auch die damit verbundenen Risiken analysieren, um die erfolgreiche Umsetzung des Projekts sicherzustellen. Wichtige Schritte:
Risikidentifikation: erfolgt parallel zur Anforderungsanalyse mithilfe von Interviews, Brainstorming, Ursachen-Wirkungs-Diagrammen. Der Analyst dokumentiert potenzielle Bedrohungen (unvollständige Anforderungen, Widersprüche in den Erwartungen, technische Einschränkungen).
Risikobewertung: nach der Identifikation der Risiken bewertet der Analyst die Wahrscheinlichkeit jedes Risikos und dessen mögliche Auswirkungen auf das Projekt. Häufig wird eine Risikomatrix (Risk Matrix) verwendet.
Planung von Reaktionsmaßnahmen: für ernsthafte Risiken werden Aktionspläne (vermeiden, reduzieren, akzeptieren oder übertragen des Risikos) erstellt. Maßnahmen zur Minderung werden dokumentiert: Durchführung von Klarstellungssitzungen mit dem Auftraggeber, Hinzufügen von Zeitpuffern, Erstellung klarer Abnahmekriterien usw.
Überwachung: Risiken werden in allen Phasen des Projektlebenszyklus überprüft, wozu Risikolisten (risk register) erstellt werden und eine regelmäßige Validierung der Relevanz von Bedrohungen erfolgt.
Wichtige Merkmale:
Kann ein Business Analyst alle Risiken im Zusammenhang mit Anforderungen vollständig ausschließen?
Nein, es ist unmöglich, alle Risiken vollständig zu beseitigen. Das Ziel ist es, Schlüsselbedrohungen rechtzeitig zu erkennen, zu minimieren und angemessen zu reagieren.
Versteht der Kunde immer all seine Bedürfnisse und kann diese zu Beginn des Projekts klar formulieren?
Nein, Bedürfnisse werden oft im Verlauf der Arbeiten präzisiert. Der Analyst muss einen Geschäftsdialog führen, verborgene Erwartungen herausarbeiten und potenzielle Unklarheiten als Risiken dokumentieren.
Reicht die Risikomatrix für ein qualitatives Risikomanagement im Projekt aus?
Nein, die Matrix ist nur ein Bewertungsinstrument. Entscheidend ist die kontinuierliche Kommunikation und Überprüfung der Risiken, nicht nur ein einzelnes Artefakt.
Negativer Fall: Der Analyst hat bei der Anforderungserhebung die mit Unklarheiten im Datenschutzrecht verbundenen Risiken nicht dokumentiert. Nach dem Release stellte sich heraus, dass das Produkt nicht den neuen Vorschriften entspricht.
Positiver Fall: Der Analyst diskutiert zu Beginn der Projekte regelmäßig mit dem Auftraggeber über rechtliche und normative Risiken und dokumentiert diese. Nach dem Auftreten neuer gesetzlicher Anforderungen passt das Team das Produkt schnell an.