Verwenden Projektmanager RAID-Protokolle?

Führen Sie unbedingt Protokolle und bringen Sie sie unbedingt an die Oberfläche und bearbeiten Sie sie in einem strengen Rhythmus. Vor allem Risiken. Ohne die Protokolle werden die Leute sie gerne ignorieren. Es gibt einen Widerstand, Risiken einzugehen und einzugehen, ich denke, aufgrund des Mantras, dass optimistische Menschen erfolgreicher sind und etwas können.

Ich habe niemals Protokolle zu Annahmen und Abhängigkeiten geführt, da diese eine Quelle von Risiken darstellen. Wenn eine Annahme getroffen wird, besteht das Risiko, dass dies folgt, und wenn Sie zwei Protokolle führen, würden Sie am Ende genau dasselbe Ereignis in zwei Protokollen nachverfolgen. Gleiches gilt für Abhängigkeiten.

Problem- und Risikoprotokolle haben eine sehr ähnliche Verbindung, die oft übersehen wird. Wenn Sie ein Problem haben, haben Sie nachgelagerte Bedrohungen. Wenn Sie das Problem protokollieren, neigen die Leute dazu, die Bewertung dieser nachgelagerten Bedrohungen zu vergessen. Und wenn Sie die Risikobewertung durchführen, könnten Sie feststellen, dass Sie dasselbe Geschäftsereignis in zwei Protokollen bearbeiten. Das ist ineffizient und öffnet Fehlkommunikation Tür und Tor.

Bearbeiten: Ich habe festgestellt, dass wir bei der Moderation von Risikoarbeitssitzungen in diesem andauernden Streit darüber landen, ob ein identifiziertes Ereignis entweder ein Risiko oder ein Problem ist. Es kommt darauf an, wie eine Person das Ereignis gestaltet hat, entweder taktisch oder strategisch.

Zum Beispiel stellt sich ein Patient seinem Arzt mit Bluthochdruck und Cholesterin, Übergewicht, Herzkrankheiten in der Familie und sitzender Lebensweise vor. All dies sind Probleme, die auf der normalen Definition eines Problems basieren. All dies sind jedoch auch Risikofaktoren für das Herzinfarktrisiko. Der Herzinfarkt ist nicht sicher, noch seine Schwere. Wenn dies ein Projekt wäre, würden Sie den Blutdruck, den Cholesterinspiegel, die Fettleibigkeit, die Familiengesundheit, den Mangel an Bewegung in das Problemprotokoll oder den Herzinfarkt in das Risikoprotokoll eintragen ... oder beides?

Taktisch würden Sie die Probleme behandeln; Strategisch würden Sie den Herzinfarkt abmildern und für die Zeit nach dem Herzinfarkt durch Notfallplanung planen. Die Behandlung der Probleme und die Linderung des Herzinfarkts sind wahrscheinlich genau die gleichen Maßnahmen, aber so wie wir es in Projekten angehen, neigen wir dazu, dies zu stark zu vereinfachen und zu versuchen, diese Dinge getrennt zu behandeln, was zu Meinungsverschiedenheiten, Streit und Ineffizienz führt. Wir neigen dazu, das Gesamtbild aus den Augen zu verlieren, habe ich festgestellt.

Ich denke, dass der Versuch, Risiken und Probleme zu trennen, ein Fehler ist, und vielleicht sollten wir dies eher als außergewöhnliche Ereignisse betrachten. Manchmal sind wir taktisch, manchmal strategisch, manchmal beides.

Meiner Meinung nach verdient ein Projektmanager, der Risiko- und Problemprotokolle nicht aktiv verwendet, diesen Namen nicht. Insbesondere das aktive Risikomanagement ist meiner Meinung nach der größte Teil dessen, was ein Projektmanager ist und tut.

Ich hatte Protokolle zu Annahmen und Abhängigkeiten nie verwendet, bis ich anfing, bei meinem vorherigen Arbeitgeber zu arbeiten, wo ich ihnen zum ersten Mal begegnete und sie bei einer Reihe von Projekten verwendete. Ich fürchte, danach war meine Schlussfolgerung, dass sie keine wirklichen Vorteile boten, obwohl dies leicht an meiner Naivität in Bezug auf ihre Verwendung liegen könnte (für die ich keine Schulung erhalten habe). Leider hatte ich den Eindruck, dass sie nur existierten, um das 'A' und 'D' für das schicke Wort RAID zu liefern!

In Bezug auf Risikoprotokolle tendiere ich zu einer sehr pragmatischen Sicht dessen, was darin enthalten sein sollte ... In PRINCE 2 haben wir gelernt, dass Sie Ihre Maßnahmen zur Risikominderung (Übertragen, Reduzieren, Akzeptieren usw.) und dergleichen kategorisieren und aufzeichnen sollten Dinge. Ich habe noch nie eine andere Verwendung für diese Informationen gesehen, als die Methodik zu erweitern und sie wissenschaftlicher erscheinen zu lassen.

Was ich wissen muss ist:

• Was ist das Risiko und die Konsequenz
• Sein Status - Offen oder Geschlossen
• Wie hoch ist die Wahrscheinlichkeit, dass es passiert
• Wie schwer sind die Auswirkungen, wenn es passiert
• Manchmal seine zeitliche Nähe, aber nicht immer
• Wann wurde es erhoben und von wem
• Wem es derzeit "gehört".
• Wie der aktuelle Status der schadensmindernden Maßnahme ist, daher führe ich ein Protokoll der Kommentare, das zeigt, wie es sich im Laufe der Zeit entwickelt (nur mehr Informationen in einer Tabellenzelle).

Und ich belasse es dabei - mehr ist für mich irrelevantes Detail. Wenn es mir nicht hilft, das Risiko zu lösen, bin ich nicht daran interessiert.

Ich verwende Risiko- und Problemprotokolle und überprüfe sie streng und regelmäßig. Sie sind wesentliche Werkzeuge sowohl für mich als PM als auch für die breitere Stakeholder-Community innerhalb des Projekts. Warum sage ich das?

• Für mich selbst geben sie mir den Fokus, um sicherzustellen, dass ich alles anspreche, was das Projekt zum Scheitern bringen könnte, und sie bringen mich dazu, gründlich über die Maßnahmen nachzudenken, um die Risiken zu mindern oder die Probleme zu lösen, und helfen mir dann, den diesbezüglichen Fortschritt zu verfolgen. In dieser Hinsicht ist das Protokoll also viel mehr als nur eine Beschreibung des Risikos oder Problems: Es ist ein Werkzeug, um die umfassenderen Umstände des Risikos oder Problems zu erfassen.
• Für die breiteren Stakeholder gibt es Vertrauen, dass das Projekt unter Kontrolle ist und dass sie sehen können, was über den normalen Fortschritt hinaus verfolgt und umgesetzt wird. Es ermöglicht mir auch – und das ist entscheidend –, mit ihnen in Kontakt zu treten und sie bei Bedarf um ihre Hilfe zu bitten, da sie oft mit den Risiken und Problemen umgehen und alles tun können, um die Risiken zu mindern oder die Probleme anzugehen.

Ich habe nicht viele Umstände gefunden, in denen ich Annahme- oder Abhängigkeitsprotokolle verwendet habe, außer um meine Gedanken festzuhalten, die dann (falls erforderlich) in Risiken umgewandelt werden, sobald ich mir Zeit nehme, sie zu analysieren (wie von David Espina in seiner Antwort auf erwähnt diese Frage).

Ich definiere ein Risiko als „etwas, das passieren könnte, das sich auf das Projekt auswirkt“, während ein Problem „etwas, das passiert ist, das sich auf das Projekt ausgewirkt hat“ ist. Der Schlüssel ist, dass ein Risiko Auswirkungen haben KANN, wo ein Problem BEREITS Auswirkungen hatte.

Ich finde es hilfreich zu versuchen, Risiken in der Form auszudrücken: „Es besteht das Risiko, dass (etwas passieren könnte), weil (etwas schief gehen könnte), was zu (einer beschriebenen Auswirkung auf das Projekt) führen kann“. Wenn ich mich also wieder auf die Antwort von David Espina beziehe, könnte ich sagen, solange der Patient keinen Herzinfarkt erlitten hat, könnte ich sagen: "Es besteht das Risiko, dass der Patient einen Herzinfarkt erleidet, weil er einen erhöhten Blutdruck und einen hohen Cholesterinspiegel hat, was dazu führen könnte schwerwiegende langfristige Gesundheitsprobleme oder sogar den Tod". Um dieses Risiko zu mindern, ergreifen Sie alle notwendigen Maßnahmen, um den Blutdruck zu senken/den Cholesterinspiegel zu senken, und dokumentieren Sie diese.

Es gibt ein ähnliches Format für Probleme nach dem Motto „Es gibt ein Problem, das (was auch immer schief gelaufen ist) das Ergebnis von (was auch immer es verursacht hat) was zu (einer Auswirkung auf das Projekt) geführt hat“. Also zurück zu Davids Beispiel, wenn der Patient tatsächlich einen Herzinfarkt erlitten hat: „Es gibt ein Problem, nämlich dass der Patient aufgrund von hohem Blutdruck und Cholesterin einen Herzinfarkt erlitten hat, was dazu geführt hat, dass er am offenen Herzen behandelt werden muss Operation und Langzeitmedikation“.

Ich würde diese Formulierungen tatsächlich in meinem Risiko- oder Problemregister verwenden, zusammen mit Minderungsmaßnahmen und einer Bewertung der Auswirkungen oder wahrscheinlichen Auswirkungen und auch (für Risiken) der Wahrscheinlichkeit, dass das Risiko eintritt. Es ist keine Wahrscheinlichkeit für ein Problem erforderlich, da es bereits passiert ist, sodass die Wahrscheinlichkeit 100 % beträgt.

Ich habe sowohl mit Scrum- als auch mit agilen Methoden gearbeitet, daher hängt es von Ihrer Herangehensweise an die Entwicklung ab.

In Scrum werden diese Probleme wirklich auf den Kopf gestellt. Der Scrumaster hat jeden Tag ein Scrum-Meeting mit dem Team, so dass die Risiken täglich überprüft werden, indem jedes Teammitglied gefragt wird, was es gestern getan hat, ob es Blockaden gibt oder ob es Probleme gibt und was sie heute tun werden . Bei größeren Hindernissen wird dem Teammitglied mit dem Blocker geholfen und so wird es zur Teamleistung und fast immer werden alle Probleme gelöst. Am Ende des Sprints gibt es Sprint-Review-Meetings, um zu sehen, wie das Team gut abgeschnitten hat und wo es sich verbessern kann. Und dann gibt es eine Liste umsetzbarer Elemente, die während des gesamten Scrums den Fokus für das Team bildet. Ich mag diesen Ansatz sehr, da er die Dokumentation reduziert und es eine echte Teamleistung gibt.

Allerdings habe ich Scrum in Verbindung mit einem Projektplan verwendet. Zuerst wird die Kundencharta erstellt, falls dies zutreffend ist. Dann ist die qualitative Risikobewertung abgeschlossen.

Anschließend erfolgt die Wirkungsanalyse. Das folgende Diagramm ist ein Beispiel für diese Analyse. Die Wahrscheinlichkeit, dass das Risiko eintritt, wird mit der Auswirkung multipliziert, sollte dies eintreten. Das folgende Diagramm zeigt ein Beispiel

Die qualitative Analyse wird verwendet, um die Auswirkungsanalyse zu betrachten, und dies geschieht, indem die Wahrscheinlichkeit der Wahrscheinlichkeit des Auftretens des Problems mit der Auswirkung multipliziert wird. Normalerweise vergebe ich Punkte von 10 für die Wahrscheinlichkeit des Eintretens des Risikos und die Auswirkungen, wobei 10 die höchste ist. Das hält es einfach. Die Ergebnisse bilden den Rang jedes Risikos und 1 wird zum höchsten Risiko.

Schließlich wird für jedes Risiko ein Minderungsplan erwogen. Das Risiko, die mögliche Ursache und die Reaktion werden berücksichtigt.

Ein Notfallbudget wird dann unter Verwendung des erwarteten Geldwertes oder EMV erstellt. Die Wahrscheinlichkeit des Eintretens des Risikos wird mit einem Prozentsatz der Wahrscheinlichkeit des Eintretens dieses Risikos vorhergesagt. Die mögliche Verzögerung des Risikos wird dann prognostiziert und mit den Kosten pro Tag multipliziert, um die Kostenauswirkung zu erhalten. Die Kostenauswirkung jedes identifizierten Risikos wird dann mit der Wahrscheinlichkeit multipliziert, um das geschätzte Notfallbudget zu erhalten.

Ich habe Problemprotokolle geführt, aber nur mit Live-Vorfällen und nicht mit der Entwicklung von Software. Ich verwende ITIL-Software im Waterfall-Management für die Live-Probleme und Spira für die Fehlerverfolgung. Dies sind wirklich gute Open-Source-Softwarepakete und vermeiden die Notwendigkeit einer Tabellenkalkulation. In einem Shared-Services-Projekt, an dem ich beteiligt war, verwendeten wir ein Problemprotokoll, das nicht wirklich für die Anforderungen des Projekts geeignet war. Die Leute wurden gebeten, es zu aktualisieren, und sie haben es nie getan.

Abschließend bevorzuge ich Scrum und agile Methoden in Verbindung mit einem guten Projektplan und Open-Source-Software, um die Probleme zu verfolgen.

Wenn es noch andere Informationen gibt, die ich bereitstellen kann, lassen Sie es mich bitte wissen. Ich liebe dieses Zeug.

Unser Projekt hat ein RAID verwendet, bei dem es sich um eine Tabelle mit einem Arbeitsblatt für jedes der vier Elemente handelt. Während ich denke, dass ein RAID im Allgemeinen eine gute Idee ist (und andere eine Kritik zu jedem Teil abgegeben haben), bin ich bei der Tabelle auf einige große Nachteile gestoßen:

1. Die Elemente sind in keiner Weise mit dem Zeitplan verknüpft. In vielen Fällen entsteht ein RAID-Element, weil etwas schief geht, wenn jemand versucht, eine geplante Aufgabe auszuführen. Ich würde viel lieber eine Software verwenden, die Aufgaben verfolgt und deren Probleme miteinander verknüpft sind.
2. Da sich jede RAID-Kategorie auf einem separaten Arbeitsblatt befindet, ist es schwierig, verwandte Elemente miteinander zu verknüpfen. Zum Beispiel: Ein Risiko wird protokolliert, es wird später zu einem Problem. Schneiden Sie das Originalrisiko aus und kleben es in das Ausgabeblatt? Duplizieren Sie die Informationen und schreiben Sie „bezieht sich auf Risiko 123“?
3. Da es sich um eine Tabelle handelt, gibt es keine automatische Möglichkeit, Duplikate zu finden (es wäre schön, etwas wie StackExchange zu haben, wenn Sie eine neue Frage erstellen – schlagen Sie vor, ob bereits ähnliche vorhanden sind).

Diese Probleme sind eher auf die Art und Weise zurückzuführen, wie das RAID erstellt wird, als auf das Konzept selbst, aber angesichts der Vorliebe der Unternehmen für Tabellenkalkulationen vermute ich, dass sie auch für andere Personen gelten.

Ich betrachte das Management von Risiken und Problemen als entscheidend für den Projekterfolg. Das A und D in RAID stehen normalerweise für Annahmen und Abhängigkeiten – sie werden immer wichtiger, wenn die Größe und physische Trennung des Projektteams zunimmt.

Entscheidend für ihre Verwendung ist sicherzustellen, dass alle einer gemeinsamen Definition für „Risiko“ und „Problem“ zustimmen. Ich betone im Allgemeinen, dass ein „Risiko“ ungewiss ist, während ein „Problem“ sicher ist.

Der Versuch, mit anderen Mitteln zu unterscheiden, führt meiner Meinung nach zu Problemen. Die Trennung zwischen taktischer und strategischer Reaktion ist meiner Meinung nach nicht der richtige Ansatz, da sowohl Risiken als auch Probleme auf beiden Ebenen auftreten können. Die Trennung nach Zukunft vs. Gegenwart oder Vergangenheit führt ebenfalls zu Problemen – man kann ein Problem haben, das in der Zukunft bestimmte Auswirkungen haben wird, aber noch nicht eingetreten ist, und ein Risiko, das mit der Milderung ungewisser Folgen eines Ereignisses in der Vergangenheit zu tun hat kommen auch vor.

Wenn Sie ein Risiko als etwas definieren, das mit einer Wahrscheinlichkeit von weniger als 100 % Auswirkungen auf das Projekt hat, haben Sie zwei Möglichkeiten, damit umzugehen: Versuchen Sie, die Wahrscheinlichkeit (Vermeidung oder Übertragung) der Auswirkungen zu ändern, und versuchen Sie, die Auswirkungen zu ändern (mildern oder Eventualitäten planen). Bei einem Problem können Sie nur daran arbeiten, die Auswirkungen zu mindern.

In David Espinozas Beispiel eines Patienten sind alle bekannten Symptome Probleme – Sie können die Symptome behandeln, aber nicht die Wahrscheinlichkeit ändern, dass der Patient sie hat. Herzinfarkt ist ein Risiko, dessen Wahrscheinlichkeit durch die Behandlung der Probleme modifiziert werden kann und für das Notfall- und Minderungsplanung wahrscheinlich beide angemessen sind.