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.