Issue Log nicht mit Risikoregister verwechseln

Lassen wir zunächst die Theorie sprechen

Prozess 10.3. im PMBOK Guide besagt: Issue resolution addresses obstacles that can block the team from achieving its goals.Und weiter im Glossar über das Issue Log: A project document used to document and monitor elements under discussion or in dispute between project stakeholders.

Ein „Log“ ist zunächst mal eine Liste. Mehr nicht. Ein Issue Log ist also eine Liste mit Issues – und Issues sind Themen bzw. Probleme. Eine Themen- oder Problemliste also.

Logs gibt es viele im Projektgeschäft, berühmt sind die der agilen Fraktion: Dort gibt es Backlogs, die im Prinzip auch „nur“ Listen sind, allerdings mehr im Sinne von Vorratsspeichern. Und das Issue Log nennt sich dort „Impediment Backlog“. Hmm.

Außerdem gibt es auch Projektkulturen, in denen Risiken nicht in einem Risikoregister stehen sondern in einem Risk Log. Auch okay. (PMPs und solche, die es werden wollen aufgepasst: Bei PMI heißt das Ding aber Risk Register!).

Soweit zur Theorie.

Issues kontra Risiken – Abgrenzung zum Risikoregister.

Warum ist eine Abgrenzung des Issue Logs zum Risikoregister (oder Risk Log) so wichtig? Ganz klar, damit man das eine nicht mit dem anderen verwechselt. Risiken sind Risiken und Probleme sind Probleme. Bedeutet das denn im Tagesgeschäft noch eine Excel-Tabelle mehr?

Eigentlich ja.

Zugegeben, es gibt schon genug Listen und noch mehr Excel lässt die Sache nicht übersichtlicher werden. Stimmt. Also tragen viele ihre Issues in das Risikoregister ein. Oder lassen sie als Issues drin, wenn  aus einem Risiko ein Problem geworden ist.

Ungünstig. Aus Sicht des Risikomanagements ist es bedauerlich, dass in vielen Risikolisten gar keine Risiken mehr drin stehen, sondern eigentlich Probleme. Und um im Sprachgebrauch zu bleiben: Dadurch verkommt das Risk Log zum Issue Log. Aus Sicht des Projektes sind das aber zwei grundlegend verschiedene Dinge und wir berauben uns der Sicht auf die Risiken, wenn wir beides (Probleme und Unsicherheiten) zusammenpacken.

Weniger Issues durch mehr Risiken. Und umgekehrt.

Ich hatte vor einiger Zeit eine Projektsituation, in der beide Listen getrennt wurden. Nach drei Monaten erfolgte ein erneuter Blick in dieses Projekt und in beide Listen. Das Issue Log hatte deutlich über 100 Einträge, im Risk Log hatte sich die letzten Wochen nichts getan. Das Ding war ziemlich leer, von drei müden Einträgen abgesehen. Augenscheinlicher kann man einen Handlungsbedarf gar nicht erkennen als in diesem Fall.

Eine Nachfrage ergab, dass das Projekt einfach keine Zeit hatte, sich um Risiken zu kümmern.

„Wir müssen heute Probleme lösen statt für zukünftige Situationen irgendwelche Gehirngespinste zu fabulieren“, meinte der Projektleiter.

Nur: Beide hängen zusammen. Ein Problem war früher mal ein Risiko – als es noch klein, jung und unschuldig war. Je weniger man sich um seine Risiken in der Vergangenheit gekümmert hat, desto mehr Probleme hat man heute, desto häufiger muss Feuerwehr gespielt werden. Wenn in einem Projekt die Risikoliste nicht gefüllt ist, kann man sicher davon ausgehen, dass das Issue-Log munter wachsen wird.