Das Contingency-Reserve-Diagramm

Mehr Transparenz für Ihre Sicherheitsreserven

Um langwierige Diskussionen mit den Stakeholdern, insbesondere mit dem Projektauftraggeber zu vermeiden, weisen Projektleiter ihre Sicherheitsreserve häufig nicht transparent aus. Ein sinnvolles Werkzeug, das die notwendige Contingency Reserve für die Stakeholder nachvollziehbar macht, fehlte dem Projektleiter bisher. Beat R. Schybli hat eine Methode entwickelt, mit der er anhand konkreter Kriterien die Sicherheitsreserve bestimmt und diese in den Planungsdokumenten zur Zeit- und Kostenplanung nachvollziehbar angibt.
Das Contingency-Reserve-Diagramm

Mehr Transparenz für Ihre Sicherheitsreserven

Um langwierige Diskussionen mit den Stakeholdern, insbesondere mit dem Projektauftraggeber zu vermeiden, weisen Projektleiter ihre Sicherheitsreserve häufig nicht transparent aus. Ein sinnvolles Werkzeug, das die notwendige Contingency Reserve für die Stakeholder nachvollziehbar macht, fehlte dem Projektleiter bisher. Beat R. Schybli hat eine Methode entwickelt, mit der er anhand konkreter Kriterien die Sicherheitsreserve bestimmt und diese in den Planungsdokumenten zur Zeit- und Kostenplanung nachvollziehbar angibt.

Wenn es um die Termin- und Kostenplanung geht, werden Sicherheitsreserven (Contingency Reserve) für die identifizierte Risiken oft als verdeckte Marge auf die Basis-Planung aufgeschlagen. Diese Vorgehensweise macht es jedoch nach Projektabschluss unmöglich, die Unterschiede zwischen der ursprünglichen Planung ohne Reserve und den realen Projektausgaben zu erkennen.

Projektleiter vermeiden es häufig, die Contingency Reserve in ihrer Projektplanung gesondert auszuweisen, da diese Transparenz leicht zu Diskussionen mit dem Projektauftraggeber führen kann. Dies liegt sicherlich daran, dass einer mit "Bauchgefühl" geplanten Sicherheitsreserve – selbst wenn die Planung durch einen erfahrenden Projektleiter erfolgte – immer ein Hauch Willkürlichkeit anhaftet.

Ein sinnvolles Werkzeug, um die notwendige Contingency Reserve gegenüber den Stakeholdern gut erklären zu können, fehlte dem Projektleiter bisher. Dieses Werkzeug sollte die Kalkulation der Sicherheitsreserven nachvollziehbar machen, um so für die Stakeholder, insbesondere den Projektauftraggeber, die gewünschte Transparenz zu schaffen.

Das brachte mich auf die Idee, selbst ein solches Werkzeug zu entwickeln, das es ermöglicht, anhand konkreter Kriterien die Sicherheitsreserve zu bestimmen und sie in den Planungsdokumenten für die Auftraggeber klar ersichtlich darzustellen: das Contingency-Reserve-Diagramm. Ich verwende das Diagramm als Hilfsmittel in der Planungsphase, um die Zeit- und Kostenplanung zu erstellen. Ich behandle die mit dem Diagramm verbundene Vorgehensweise als einen standardisierten, neuen Prozess innerhalb meines Projektmanagements. Meine folgenden Ausführungen orientieren sich nicht an bestehenden Standards, sondern sind das Ergebnis meiner persönlichen positiven Erfahrung mit dem Diagramm in meinen IT-Projekten, die ich gerne weitergeben und hier zur Diskussion stellen möchte.

Das Contingency-Reserve-Diagramm

Verzögert sich ein Projekt, sind die Ursachen dafür meiner Erfahrung nach meist ein ungenau spezifizierter Projektumfang und Risiken, die durch die Verwendung neuer Technologien auftreten.

Projektumfang

Sehr oft ist der Projektumfang ungenau spezifiziert und es sind noch viele Details unklar nach dem Motto: "Das klären wir dann noch später." Meistens ist diese mangelhafte Beschreibung des Projektumfangs verantwortlich für Projektverzögerungen, da sie viele zeit- und kostenintensive Änderungen während der Projektausführung nach sich zieht. Oder aber der Projektumfang ist nicht von allen Stakeholdern akzeptiert. In diesem Fall entsteht früher oder später Widerstand, was sich nach meiner Erfahrung häufig ebenfalls in Änderungen des Projektumfangs mit den dazugehörenden zeitlichen Verzögerungen und Kostensteigerungen widerspiegelt.

Technologie

Unter der Dimension Technologie verstehe ich die eingesetzte Technik und die verwandten Prozesse. Es ist einleuchtend, dass die Benutzung neuer Technologien Risiken beinhaltet, z.B. wenn die Mitarbeiter das entsprechende Know-how im Umgang mit der Technologie noch nicht erworben haben. So macht es einen Unterschied, ob für ein Software-Projekt ein bekanntes und gut eingeführtes Betriebssystem verwendet wird oder ein vergleichsweise neues. Die Fähigkeit einer Organisation, sich schnell in neue Technologien einzuarbeiten, hat hier ebenfalls einen entscheidenden Einfluss auf den notwendigen Umfang der Sicherheitsreserve. Zudem enthalten neue Software-Versionen und -Releases stets einige Fehler, welche sich negativ auf die Entwicklung des Projektergebnisses auswirken.

Die Kriterien "Projektumfang" und "Risiken durch die Verwendung neuer Technologien" eignen sich daher gut, um daraus Rückschlüsse auf die Höhe der benötigten Sicherheitsreserven zu ziehen. Bei einem Projekt, bei dem der Projektumfang mit allen Stakeholdern abgestimmt ist und in dem bewährte Technologien eingesetzt werden, kann die Sicherheitsreserve deutlich geringer ausfallen, als bei einem noch nicht ausreichend geklärtem Projektumfang und dem Einsatz neuer Technologien.

Stellt man diesen Zusammenhang grafisch dar, ergibt sich die in Bild 1 dargestellte Grundstruktur eines Contingency-Reserve-Diagramms mit den Achsen "Grad der Neuartigkeit der verwendeten Technologien" sowie "Spezifikationsgrad des Projektumfangs" (Bild 1). Die darin dargestellte Abstufung der Sicherheitsreserven muss unternehmensspezifisch angepasst werden. Sie wird, wie später beschrieben, anhand von abgeschlossenen Referenzprojekten mit bekannter Sicherheitsreserve ermittelt.

Bild 1: Das Contingency-Reserve-Diagramm.

Hat der Projektleiter für sich abgeschätzt, wie spezifisch und abgesichert die Beschreibung dessen ist, was mit dem Projekt erreicht werden soll, und wie bekannt die verwendete Technologie für die Mitarbeiter ist, kann er diese beiden Dimensionen in das Diagramm eintragen. Der Wert am Schnittpunkt der beiden Linien gibt an, wie hoch er die Sicherheitsreserve in Prozent der Gesamtkosten ansetzen muss.

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 3
Kommentare 2

Alle Kommentare

Guest
unklar ist mir die Abgrenzung zum Risikoplan. Heute habe ich einen Basisplan und dann aufgrund der eingeschätzten und gewichteten Risiken ein Zuschlag (incl. der Risikoreduzierkosten) gebildet und damit meinen Expected Case. Auch eine Worst Case konnte ich zeigen, wenn nämlich alle Risiken eintreffen. Soll man jetzt auf diese Summen die CRD Ergebnisse drauflegen oder den Risikoplan durch die pauschale Statistiksumme CRD ersetzen? oder soll dies eine Vereinfachung für Kleinprojekte sein?
Guest
Das CRD ersetzt die Risikoplanung im Projekt nicht. Risiken mit einer Eintrittswahrscheinlichkeit und bekannter Auswirkung auf das Projekt sind eine feste Grösse, mit der man planen kann. Die Sicherheitsreserve hingegen deckt das Unbekannte / Unplanbare ab, weshalb man m.E. hier auch nur empirisch vorgehen kann. Das heisst die mit CRD ermittelte Sicherheitsreserve wird dem Zeit- und Kostenplan inkl. den bekannten Risiken aufgeschlagen. Im übrigen erhöht sich der Unsicherheitswert für die Projektplanung, so wie ich das CRD anwende, wenn keine oder eine nur unvollständige Risikoplanung vorliegt. Auf diese Weise deckt das CRD auch eine fehlende Risikoplanung ab, was - da gebe ich Ihnen vollkommen Recht - in Kleinprojekten durchaus Sinn machen kann.
Alle anzeigen