Ich beschäftige mich schon länger mit dem Thema Risikomanagement in der Softwareentwicklung. Entsprechend der unterschiedlichen Literatur kann es Bekannte Bekannte (typische Risiken), Bekannte Unbekannte (produktbezogene Risiken) und Unbekannte Unbekannte (schwarze Schwäne) geben.
bekannte Bekannte
Sie haben einige Branchenstatistiken und können einige Simulationen (z. B. RISKOLOGIE) verwenden, sodass Sie Umfang und Zeitplan um beispielsweise 20 % erweitern können.
bekannte Unbekannte
Hier können Sie mit dem Team ein Brainstorming durchführen und eine Liste der projektbezogenen Risiken erstellen sowie Präventivmaßnahmen erstellen und diese abschätzen, damit diese in den Umfang aufgenommen werden können. Aber was ist mit dem Rest der bekannten Unbekannten? Sollten Sie für Eventualitäten planen? Wie viel? 10 %?
schwarze Schwäne
Nur für den Notfall planen? Wie viel? 20-30%?
Wie planen Sie diese Risiken in der Projektinitiierungs- oder Planungsphase, insbesondere wenn der Kunde um Kostenvoranschläge bittet? Wie stellen Sie dem Kunden normalerweise all diese verschiedenen Arten von Risiken dar, insbesondere wenn die Risiken die Budget- oder Zeitplanschätzungen verdoppeln?
Risiken werden typischerweise in diese beiden Kategorien eingeteilt: Bekannte Unbekannte und Unbekannte Unbekannte. Letztere können Sie in Unknown Knowable Unknowns und Unknown Unknownable Unknowns unterteilen. Bekannte Bekannte sind keine Risiken, da dies Gewissheit impliziert.
Sie haben zwei Arten von Treibern, wenn es um Ihr Budget und Ihre Zeitplanrisiken geht. Der erste Treiber ist aleatorischer Natur oder zufällige Variablen, die Ihre Ergebnisse beeinflussen. Am besten lässt sich eine 3-Punkte-Schätzung erstellen – z. B. im besten Fall 1.000 $; höchstwahrscheinlich 1.500 $; im schlimmsten Fall 2.800 $ – und zeichnen Sie eine Dreiecksverteilung, die diese drei Werte verbindet. Nehmen wir der Einfachheit halber an, Sie legen Ihr Budget auf 1.600 € fest, 100 € über dem wahrscheinlichsten in Ihrer Schätzung. Damit bleibt der Bereich von 1.601 $ bis 2.800 $ als Ihr ungünstiges Engagement und alles unter 1.600 $ als Ihr günstiger.
Ihr zweiter Treiber sind eher diskrete Risiken oder epistemische Risiken. Dies sind spezifische Bedrohungen, die Sie identifizieren und deren Wahrscheinlichkeit und Auswirkungen Sie berechnen können. Aufgrund der Spezifität der Bedrohung können Sie die Minderungskosten berechnen sowie den Wert, den Sie für den Notfall vorschlagen möchten, möglicherweise basierend auf dem erwarteten Geldwert.
Ihre letzte Frage ist nicht einfach zu beantworten. Dies hängt davon ab, wie Sie mit Ihrem Kunden vertraglich verbunden sind. Wenn Sie ein Risiko eingehen, dh einen Festpreisvertrag, muss Ihr Kunde nicht wissen, was Sie in Ihren Risikovorschlag eingebaut haben. Geht ihn nichts an. Ob T&M oder Kosten plus, dann wird es eine gemeinsame Diskussion über Ihre Bedrohungsbewertungen, die von Ihnen kalkulierten Kosten und eine gemeinsame Entscheidung darüber, was in die Reserve eingestellt werden soll. Ihre Zielwerte sind das, was Sie unter Vertrag nehmen. Die Reserven sind nicht vertraglich, sondern werden vom Kunden gehalten, falls etwas Schlimmes passiert.
So oder so ist die Präsentation Ihres Vorschlags nicht einfach. Kunden möchten einen garantierten Erfolg zu nahezu null Kosten hören. Das ist Ihre Herausforderung als Verkäufer von Dienstleistungen.
Risiken können akzeptiert, kontrolliert oder übertragen werden. Ihr Projektplan sollte auf jeden Fall eine Risikoanalyse und empfohlene Kontrollen enthalten, aber die Risiken gehören eigentlich den Projektbeteiligten. Als Projektmanager sollten Sie sich darauf konzentrieren, die Risiken zu dokumentieren und angemessene Projektkontrollen für die Risiken bereitzustellen, die nicht akzeptiert oder übertragen werden.
Jedes Projekt hat ein Ziel. In den meisten Fällen sind die Managementziele für Projekte unrealistisch. Beispielsweise ist ein Projekt, das mit einer Best-Case-Planung und ohne Puffer im Prozess geschätzt wird, leider üblich und repräsentiert Ihr Best-Case-Szenario für das betreffende Projekt.
Eine Schätzung hingegen misst, was Sie zu wissen glauben, und berücksichtigt dann Ihren Unsicherheitskegel und andere Risikoanalysezahlen, um zu einer realistischeren Schätzung zu gelangen. Je mehr Sie über den Problembereich wissen und je mehr Sie über die Risiken wissen, denen Sie möglicherweise ausgesetzt sind, desto genauer werden Ihre Schätzungen sein.
Im Allgemeinen finden Sie es möglicherweise hilfreich, Ihre Schätzungen als Bereich und nicht als Satz fester Zahlen anzugeben. Die Größe des Bereichs impliziert von Natur aus Unsicherheit, und das ist wirklich der Punkt: Sie treffen eine fundierte Vermutung, die auf einer Reihe von Annahmen basiert.
Eine alternative Methode besteht darin, einen "Fudge-Faktor" auf Ihre Schätzungen anzuwenden. Dies kann auf historischen Messwerten basieren (z. B. liegen Ihre Projekte typischerweise bei +/- 20 % der realistischen Schätzung) oder auf Risikotoleranz (z. B. kann Ihr Projekt Terminabweichungen von <= 10 % tolerieren).
Ich bin ein großer Befürworter von Transparenz in der Planung. Wenn Sie also diesen Weg einschlagen, würde ich sicherlich anerkennen, dass diese Zahl eher ein Fudge-Faktor als das Ergebnis einer quantitativen Analyse ist. In Scrum wende ich normalerweise einen Fudge-Faktor von 0,6 für neue Teams und 0,8 für etablierte Teams an, aber Ihre Laufleistung kann definitiv variieren.
Das Risiko ist nie null, und Schätzungen sind keine Garantien. Im Allgemeinen habe ich festgestellt, dass der beste Weg, mit dieser Realität umzugehen, darin besteht, sie einfach als Teil Ihrer Projektannahmen zu dokumentieren.
Ihre Projektdokumentation kann beispielsweise eine formelle oder informelle Risikoanalyse sowie einen Zielzeitplan oder eine Reihe von Schätzungen enthalten. Indem Sie die Annahmen dokumentieren, die Ihrem Projektplan zugrunde liegen, verbessern Sie die Kommunikation und sorgen gleichzeitig für Eventualitäten.
Stellen Sie sich ein imaginäres Projekt vor, bei dem Sie davon ausgehen:
Wenn sich eine dieser Annahmen irgendwann während des Projekts als falsch herausstellt, können die Beteiligten neu bewerten. Die Organisation kann beschließen, eine beliebige Anzahl von Maßnahmen zu ergreifen, wenn das Projekt außerhalb der Toleranz liegt, einschließlich der Änderung des Plans oder der Absage des Projekts.
Wenn Sie Dienstleistungen zum Festpreis verkaufen, müssen Sie dieses Risiko auch in Ihre Schätzungen einbeziehen. Manchmal hat Ihre Organisation die Nase vorn, manchmal nicht. Wenn Ihr Unternehmen dieses Risiko nicht tolerieren kann, schließen Sie keine Festpreisverträge ab.
Denken Sie daran, dass Ihre Rolle als Projektmanager in erster Linie darin besteht, angemessene Kontrollen auf das Projekt anzuwenden und den Projektbeteiligten routinemäßig den Status des Projekts mitzuteilen. Aus politischer Sicht können Projektmanager beschuldigt werden, wenn ein Projekt aus dem Ruder läuft, aber denken Sie daran, dass es Ihre Aufgabe ist, das Projekt zu verfolgen und Projektkontrollen anzuwenden . Sie können ein Endergebnis nicht wirklich garantieren, noch sollten Sie es versuchen.
Wenn Sie Kunden die Katze im Sack verkaufen wollen, wechseln Sie in den Vertrieb. Nutzen Sie andernfalls Ihre Position, um Stakeholder über den Umfang und die Annahmen Ihres Projektplans aufzuklären, und seien Sie darauf vorbereitet, zu erklären, wie Sie zu den Planungszahlen gekommen sind, die das Management und die Kunden genehmigen müssen, um das Projekt voranzutreiben.
Ruslan
David Espina