Problem, Risiko oder Änderungsantrag: die Unterschiede

In jedem Projekt tauchen drei Arten von „Dingen, um die man sich kümmern muss“ auf, die oft verwechselt werden: was bereits passiert ist, was passieren könnte und was jemand verlangt. Sie gleich zu behandeln ist ein teurer Fehler: Jede wird anders gesteuert, mit anderer Verantwortung, anderen Fristen und anderen Folgen. Dieser Ratgeber gibt eine einfache Regel zur Unterscheidung und je ein Beispiel.

Die drei Definitionen

Die Entscheidungsregel

Stellen Sie sich drei Fragen, in dieser Reihenfolge:

1. Verlangt jemand etwas, das nicht vereinbart war? Dann ist es ein Änderungsantrag, auch wenn die Bitte als Problem getarnt kommt („im Bericht fehlt die Spalte Region“ kann ein Fehler sein, wenn es im Umfang lag, oder eine Änderung, wenn nicht).
2. Wenn nicht: Ist es schon eingetreten? Dann ist es ein Problem.
3. Wenn nicht: Könnte es eintreten? Dann ist es ein Risiko.

Die erste Frage ist die wichtigste, denn sie schützt den Umfang: Eine als Problem behandelte Änderung wird „gratis“ im Budget gelöst.

Je ein Beispiel

• Problem: „Der Ladevorgang der Kunden ist fehlgeschlagen: 300 Datensätze fehlen.“ Es ist schon passiert. Es wird jemandem zugewiesen, erhält Schweregrad und Priorität, es werden Stunden erfasst, bis es gelöst ist, und es wird geschlossen.
• Risiko: „Liefert der Kunde die Artikeldaten nicht vor dem 15., verzögert sich die Migration.“ Es ist noch nicht passiert. Es wird mit Wahrscheinlichkeit und Auswirkung notiert, dazu ein Plan: die Daten frühzeitig anfordern, einen Teilladevorgang vorbereiten.
• Änderungsantrag: „Wir möchten einen Umsatzbericht nach Region ergänzen.“ Es war nicht vereinbart. Er wird mit dem Antragsteller erfasst, der Aufwand wird geschätzt, und es wird entschieden, ob und zu welchen Kosten er genehmigt wird.

Wie sie ineinander übergehen

Die drei Kategorien sind keine dichten Schubladen:

• Ein Risiko, das eintritt, wird zum Problem. Hat der Kunde die Daten nicht geliefert, wird es nicht mehr beobachtet: Es wird gelöst.
• Ein Problem kann eine Änderung offenlegen. Zeigt sich bei der Untersuchung eines „Fehlers“, dass das System das Vereinbarte tut, der Kunde aber etwas anderes erwartete, bleibt ein Änderungsantrag übrig.
• Ein wiederkehrendes Problem verbirgt oft ein Risiko, das man nicht gesehen hatte: Es lohnt sich, es zu notieren, damit es nicht wieder vorkommt.
• Eine genehmigte Änderung kann neue Risiken bringen: mehr Umfang, weniger Spielraum.

Häufige Fehler

1. Alles in eine einzige Liste „Offenes“ werfen. Der Unterschied zwischen dringend, wichtig und optional geht verloren.
2. Änderungen als Probleme behandeln, um das unangenehme Gespräch mit dem Kunden zu vermeiden. Der Umfang frisst das Budget, ohne dass es jemand sieht.
3. Risiken erst erfassen, wenn sie zu Problemen werden, wenn kein Spielraum mehr zum Vorbeugen bleibt.
4. Allen Problemen denselben Schweregrad geben. Schweregrad (wie viel Schaden) und Priorität (wann es bearbeitet wird) sind verschiedene Achsen: Ein Problem kann gravierend und nicht dringend sein oder geringfügig und dringend.
5. Schließen, ohne die Ursache festzuhalten, sodass die Erkenntnis verloren geht.

So geht es in PjMan

PjMan hat in jedem Projekt für jedes ein eigenes Register, damit sie sich nicht vermischen:

• Probleme: eine von den Aufgaben unabhängige Einheit mit Status (aus einem Katalog der Organisation, den der PM konfiguriert; standardmäßig Offen, In Analyse, In Bearbeitung, Gelöst und Geschlossen), Schweregrad und Priorität als getrennte Achsen, Zuständigen, geschätzten und erfassten Stunden, Erkennungs- und Abschlussdatum (Letzteres wird beim Wechsel in einen Endstatus automatisch gesetzt) und optionaler Verknüpfung mit einer Phase oder Aufgabe. Sie haben Liste und Kanban-Board und zählen in den Berichten (offen, geschlossen, durchschnittliche Lösungsdauer, nicht zugewiesen). (Probleme)
• Risiken: mit Wahrscheinlichkeit, Auswirkung, Priorität, Status und Maßnahmenplan. (Risiken)
• Änderungsanträge: mit Antragsteller, geschätztem Aufwand, Kosten und Dauer sowie dem Status offen, genehmigt oder abgelehnt. (Änderungsanträge)

Jedes hat seinen Kurzcode (I0003, R0002, S0001), mit dem man es im Gespräch nennt oder den Assistenten darauf anspricht. Auch die Sichtbarkeit unterscheidet sich: Die Projektleitung sieht alle drei, ein Berater kann Probleme zu seiner Arbeit ansehen und anlegen, hat aber keinen Zugriff auf Risiken oder Änderungsanträge. (Rollen und Zugriff) Berichte bündelt die Kennzahlen zu Problemen Ihrer Projekte. (Berichte)

Zum Vertiefen behandeln die Ratgeber zum Risikoregister und zu Änderungsanträgen jeden Fall ausführlicher.

Konto erstellen oder Demo ausprobieren.

Häufige Fragen

Ist ein Fehler des Kunden in seinen eigenen Daten ein Problem oder eine Änderung? Blockiert er die geplante Arbeit, ist es ein Problem (die Blockade muss gelöst werden). Beinhaltet die Behebung Arbeit, die nicht im Umfang lag, ist zusätzlich eine Änderung zu entscheiden.

Wohin schreibe ich etwas, das passieren könnte, dessen Wahrscheinlichkeit ich aber nicht kenne? In die Risiken, mit mittlerer Wahrscheinlichkeit. Wichtig ist, es festzuhalten und zu überprüfen.

Kann ich eines in ein anderes umwandeln? In PjMan ist jeder Eintrag eigenständig; tritt ein Risiko ein, erfassen Sie das Problem und schließen das Risiko. Der Verlauf bleibt in jedem Eintrag.