Hier drüben wurde gefragt, wie man die Zurückhaltung bei der Verwendung von RAID-Protokollen überwinden kann (unter ABezugnahme auf Aktionen, nicht auf Annahmen). Der allgemeine Ansatz, der bereits vom OP vorgeschlagen wurde, wäre, das (in diesem Fall agile) Team von Dokumentenformaten und Aspekten zu befreien, die nicht in seine Welt passen, und den PM die Koordination zwischen den beiden Welten übernehmen zu lassen unterschiedlicher Denkweisen und zu pflegender Dokumente.
In dieser Antwort auf die obige Frage wurde vorgeschlagen, das Risikoregister des PM kurz zu halten und das agile Team sein eigenes pflegen zu lassen, wobei sie entweder das Dokument nützlich finden und es selbst pflegen oder dazu ermutigt werden:
Ihre Protokolle sollten nur Ihre fünf oder sechs wichtigsten Elemente enthalten. Vielleicht sieben. Dies sind die Elemente mit der höchsten Priorität, die Sie verfolgen müssen, die teuersten und wirkungsvollsten. Der Rest fällt weg und wird an die Teams delegiert, die wahrscheinlich selbst ihre eigenen Protokolle führen ... oder dazu ermutigt werden sollten. Auf diese Weise bleiben die Protokolle wirklich relevant und wichtig, und selbst ein SCRUM-Team wird sie sich ansehen und für nützlich halten, vermute ich.
Aus meiner Sicht wirft dieser Vorschlag folgende Fragen auf:
Wie immer ist die Antwort von @DavidEspina ausgezeichnet. Da sich dieses Problem jedoch heute Morgen in meiner Umgebung zeigte, dachte ich, ich würde es teilen.
Ich führe eine Risikoaufschlüsselungsstruktur, die Risiken auf einer ziemlich granularen Ebene verfolgt – wir verwenden eine andere Struktur, aber effektiv verfolge ich auf L2 des PSP (L1 ist das Endergebnis, L2 sind die Arbeitspakete, die zur Erstellung dieses Ergebnisses erforderlich sind). . Ich erstelle tägliche Risiko- und Risikodiagramme.
Mein Kollege führt das Risikoregister, das unser Aufbewahrungsort für umsetzbare Risiken ist. Wir eskalieren Risiken nur dann an die Registry, wenn:
Ihre Frage ist sehr scharfsinnig. Es ist ein Axiom des PMBOK, dass der PM ein Autokrat ist, der in der Lage ist, das Projekt abzubrechen, wenn nicht alle dem korrekten Prozess folgen. Das ist eine akademische Annahme, um effektives Projektmanagement darzustellen.
Wir alle wollen an prozessreifen Projekten arbeiten, in denen jeder versteht, dass Zusammenarbeit zu erfolgreicheren Ergebnissen führt. Aber die Wahrheit ist, dass WIFM in den meisten unserer Umgebungen stärker ist als PMBOK. Die Wahrheit ist, dass die meisten PMs an isolierten Arbeitsmodellen arbeiten, damit sie die Projektauswirkungen vorhersagen und nur die Ergebnisse des Modells offenlegen können. (Nach monatelanger Arbeit habe ich mein Projekt endlich reif genug gemacht, um mit EVM zu arbeiten; ich habe die Grafik hochgeladen und bevor ich den ersten Satz beendet hatte, sagte mein Chef: „Du hast mich jetzt schon gelangweilt.“ EVM ist ein fantastisches Werkzeug; Die Anstrengung, EVM durchzusetzen, ist an sich schon wertvoll. Aber alles, was der Chef hören möchte, ist: „Ich habe das Problem untersucht; Team 2 ist in 80 % der Fälle um mindestens 33 % seiner Schätzung zu spät; entweder wir verschieben den Termin das Projekt basierend darauf, wie sie handeln,
Risikomanagement ist am wertvollsten für die Diskussionen, die es erzeugt. Niemand kümmert sich darum, ob das Risiko eine 2 oder eine 3 ist; der Wert ist, wenn jemand sagt: "Ich denke, das wird weniger oft passieren, wenn wir eine dickere Nadel kaufen oder Ted feuern oder QC früher einbeziehen oder ..." Leider kenne ich keine Möglichkeit, die Leute diesen Hügel hinaufzutreiben Reifegrad des Risikomanagements.
Einer meiner Lehrer in der High School sagte, dass "alles als Kunst beginnt, dann zu Wissenschaft, dann zu Ingenieurwesen wird und dann als Handwerk endet". Bei PM beginnt alles als Stammeswissen, dann als privates Modell, eskaliert zu einem schlecht verwalteten Projekt, dann zu einer Skunk-Arbeit und schließlich zum Betrieb. Sie befinden sich in der Phase des Hinterzimmermodels. Es gibt keinen anderen Weg als nach oben.
(WIFM – Was habe ich davon?)
Bei Projekten, die ich beaufsichtigt habe, hatte ich keinen perfekten Erfolg bei der Umsetzung meiner Vision, wie ein Risikoprotokoll auf Projektebene aussehen sollte, dass es die höchsten sechs oder sieben Bedrohungen enthalten sollte, denen das Projekt ausgesetzt ist, und dass Protokolle auf niedrigerer Ebene dies können und sollen von den verschiedenen Teams genutzt werden. Das Protokoll auf Projektebene entwickelt sich schnell zu einem streng kontrollierten Ergebnis, wie die ursprüngliche RAID-Frage vermittelte.
Auf Projektebene würde ich eine Person als Risikomanager des Projekts zuweisen lassen, die zusätzliche Risikomanagementrollen auf Aufgabenebene übernimmt. Diese Person würde die Risikomanager auf niedrigerer Ebene ermutigen oder veranlassen, ihre eigenen Risikoprotokolle zu führen, und sie nach Bedarf „prüfen“, um die Einhaltung und angemessene Bemühungen bei dieser Aufgabe sicherzustellen oder zu erleichtern. Wenn die Protokolle schlecht gepflegt werden, wird dies zu einer Maßnahme, die die Teams beheben müssen, und diese Maßnahme würde vom PMO überwacht. Basierend auf der Risikoanalyse auf den unteren Ebenen hätte der Projektrisikomanager auch die Befugnis, eine identifizierte Bedrohung an das Projektebenenprotokoll zu eskalieren und diese Bedrohung dann auf der höchsten Ebene zu verwalten.
All dies gesagt, die Kultur des nicht risikobasierten Denkens oder das, was ich als Risikomanagement-Widerstand bezeichne, herrscht vor, scheint in allen Projekten systemisch zu sein und ist schrecklich schwer zu überwinden.
Wenn Sie Ihre Teams befragen würden, würde ich vermuten, dass 100 % von ihnen zustimmen würden, dass Risikomanagement eine wichtige – vielleicht die wichtigste – Aufgabe bei jedem Projekt ist. Wir scheinen es jedoch vermeiden zu wollen, sowohl Leute, die Drohungen aussprechen, als auch diejenigen, die sie hören müssen.
Die Menschen bevorzugen Garantien; Ungewissheit scheint uns unangenehm zu sein; und unsere Augen werden glasig, wenn wir anfangen, über Statistiken, Wahrscheinlichkeitsverteilungen, Vertrauen zu sprechen..... Bin eingeschlafen, sorry.
Wir wollen keine Drohungen für Projekte aussprechen, die wir liefern, weil es den Anschein hat, als hätten wir keine Kontrolle, es lüftet unsere schmutzige Wäsche, es überträgt die Verantwortung für seine Minderung auf die Risikoeskalation, wenn, wenn nicht, wir es können höhere Gewalt oder andere Beteiligte verantwortlich machen und so weiter. Uns wird gesagt, dass es kein Ausprobieren gibt, sondern Scheitern ist keine Option, Pessimisten sind negative Menschen, mit denen niemand arbeiten möchte usw. All dies sind Risikomanagement-Killer.
Auf der anderen Seite, für diejenigen, die die Drohungen hören müssen, folgen wir denen, die sie aussprechen. Wir sagen ihnen, sie sollen es reparieren, weil „das ist der Grund, warum ich dich eingestellt habe“. Und am Ende lassen wir sie uns mehrmals pro Woche über diese Bedrohung berichten, wobei sie jeden Schritt im Mikromanagement verwalten. Und wenn die Bedrohung eintritt, geben wir der Risikoeskalation die Schuld, egal wie hart und rigoros die Minderungsmaßnahmen waren, während wir den Feuerwehrmann belohnen, der keine Versuche unternommen hat, raue See vorherzusagen und zu vermeiden. Insgesamt gibt es schwerwiegende Folgen, die Bedrohungen hervorrufen.
Für einen soliden, ausgereiften und fähigen Risikoprozess muss alles oben genannte das Gegenteil von dem sein, was passiert. Das Erhöhen und Mindern von Risiken muss belohnt werden, selbst wenn die Minderung fehlschlägt; während Überraschungen und die heldenhafte Brandbekämpfung auch nach erfolgreicher Bergung „bestraft“ werden müssen. Das Gegenteil scheint derzeit einzutreten.
Alle Lösungen, die ich ausprobiert habe, scheinen der Art und Weise zu widersprechen, wie wir auf natürliche Weise mit Drohungen reagieren. Ich denke, die Lösung hier dreht sich mehr um die menschliche Psychologie als um Prozesse, Tools, Protokolle usw. Dies ist eher ein Schimpfen als eine Antwort, aber dies ist wirklich ein komplexes Thema.
David Espina
Webstuhl mit einer Mannschaft
David Espina