IT-Grossprojekte "on time" und "in budget": Die 9 Essentials der Planung und Steuerung

Es kann immer geplant und gesteuert werden. Damit die Planung jedoch belastbare Voraussagen ermöglicht, der Fortschritt stichhaltig überprüft und flexibel auf Änderungen reagiert werden kann, sind im Setup des Projektes einige Voraussetzungen notwendig.

Das Erzeugen von Verbindlichkeit ist Voraussetzung dafür, dass die Planung im Projektalltag zur gegenseitigen Koordination und der aktuell bestmöglichen Projektion der Zukunft wirksam verwendet werden kann. Die Orientierung an Deliverables anstatt an Tätigkeiten ist dabei der Schlüssel. Nicht nur in der Planung, sondern in der gesamten Projektkultur. Ein Deliverable ist ein greifbares, demonstrierbares Resultat, dessen Existenz auch vom Management verifiziert werden kann und dessen Qualität im Rahmen von Tests oder Reviews überprüft werden kann.Zum Beispiel erstellte Konzepte, abgenommene SW-Teile, in Betrieb genommene Testsysteme, geschulte Mitarbeitende. Gelingt es nicht, diese Verbindlichkeit zu etablieren, droht die Planung zum netten Dokument für die Projektvitrine zu degenerieren, welches jedoch nicht zur Steuerung taugt.

Grosse Vorhaben müssen heruntergebrochen werden, damit sie beherrschbar und steuerbar sind. Meistens sind diese Teilvorhaben immer noch gross und komplex. Es bewährt sich, für die Teilvorhaben mit den Verantwortlichen einen formalen Auftrag (im Geiste eines Vertrages) zu etablieren, welcher Scope, Zeit, Budget und Qualität der Deliverables festhält. Oft stellt sich dabei heraus, dass Einiges noch unklar ist. Die durch den Auftrag entstehende Verbindlichkeit, allenfalls sogar durch gegenseitiges Unterzeichnen, bewirkt, dass die Dinge ausreichend geklärt sind, wenn man sich in die Arbeit stürzt. Als Nebenprodukt entstehen wertvolle Hinweise auf Risiken und was noch nachgeschärft werden sollte. Insbesondere bezüglich zugrundeliegender Annahmen «was rundherum geschieht», «wer was zuliefert», dem Kontext. Es ist natürlich wichtig, nicht in Formalismus zu verfallen. Das Formulieren der Aufträge dient lediglich der Verbindlichkeit und dem Abgleichen von Erwartungen und Annahmen. Es geht auch nicht darum, eine Schuldkultur zu etablieren. Selbstredend müssen im Laufe eines grossen und komplexen Vorhabens die Aufträge modifiziert werden können, weil die Dinge sich geändert haben. Der Prozess des expliziten Anpassens ist in der Regel hilfreich, und bringt die oft schleichenden Veränderungen, insbesondere in den Rahmenbedingungen, auf den Tisch. Formale Aufträge und Agilität stehen nicht im Widerspruch. Aufträge (auf der richtigen Flughöhe angesetzt und geeignet mit dem agilen Framework kombiniert) fördern den Übergang zur traditionellen Umwelt und ermöglichen der agilen Entwicklung das Finden der notwendigen stabilen Leitplanken. Wird auf das Ausformulieren und Aushandeln von Aufträgen verzichtet, lässt sich oft beobachten, dass aus den abgeschlossenen Teilvorhaben nicht das vollständige Gesamtresultat entstanden ist. Nachbudgetierung und Projektverlängerungen sind die Folge und die Gap’s treten in der Regel erst in einer späten Phase (Integration / Systemtesting) zu Tage.

In grosse Vorhaben sind viele Menschen involviert. Die Mitarbeitenden müssen ihre Komfortzonen verlassen. Von etlichen wird über längere Zeit ein, aus ihrer Sicht, hoher Einsatz erwartet. Die Wahrscheinlichkeit, dass Partikularinteressen entstehen, ist gross. Die meisten Beteiligten sind zu wenig involviert, um das Bigger-Picture zu erkennen, trotzdem fällen sie eine sehr grosse Menge an Einzelentscheiden. Damit die Ausrichtung aller Beteiligten auf dasselbe Ziel möglich wird, ist daher eine klare Darstellung des angestrebten Endzustandes essenziell. Sie zeigt die grossen Deliverables im Zusammenwirken und wie der zukünftige Alltag für die Betroffenen aussehen wird. Diese Darstellung des Zielbildes ist Bestandteil einer Gesamtplanung. Die Produkt-Vision aus den agilen Frameworks eignet sich gut, insbesondere aus der Sicht verschiedener Personas, idealerweise lustvoll, dargestellt (zB. Filme, Wandbilder). Wichtig ist dabei eine gute Beantwortung der Frage «Wofür» die Veränderung/das Vorhaben durchgeführt wird, damit die Notwendigkeit und der Sinn der Veränderung nachvollziehbar und idealerweise energieliefernd sind. Drei der acht kritischen Erfolgsfaktoren im Change gemäss Kotter werden damit direkt adressiert (Sense of Urgency, Create a Vision, communicate the change vision).

Wie bereits erwähnt, ist es notwendig, auf Stufe Gesamtplanung von den erforderlichen Tätigkeiten weitest möglich zu abstrahieren und sich vor allem darauf zu fokussieren, wann, was (= Deliverables) vorliegt. Nur so wird es möglich, bei der Koordination den Überblick nicht zu verlieren. Die Überprüfbarkeit der Deliverables ist dabei zentral (siehe Essential 5). Die Verantwortlichen der einzelnen Deliverables setzen sich natürlich intensiv damit auseinander, welche Tätigkeiten notwendig sind, um auf Basis der vorhandenen Kapazität realisierbare Deliverables zu einem bestimmten Termin zu nennen. Die Tätigkeiten sind jedoch auf der Gesamtstufe nicht im Fokus. In einem iterativen Verfahren, mittels gegenseitigem Abstimmen der Deliverables, entsteht dann ein machbarer Gesamtplan. Gewisse agile largescale Frameworks bieten erprobte Verfahren, welche die Abstrahierung auf Deliverables und den iterativen Prozess unterstützen (z.B. PI-Planning). Die Ausgestaltung und das konsequente Einhalten von Definition of Ready und Definition of Done sind entscheidend, damit die notwendige Verbindlichkeit entsteht. Gewisse klassische Verfahren (z.B. WBS) müssen adaptiert werden, damit der Fokus nicht auf den Tätigkeiten, sondern auf den Deliverables liegt. Lässt man sich auf Stufe der Gesamtplanung dazu verleiten, Tätigkeiten (Work-Items) zu synchronisieren anstatt Deliverables, ist das Risiko gross, dass einerseits die notwendige Reduktion der Komplexität nicht gelingt und andererseits Verzug, aufgrund unvollständiger Resultate, zu spät erkannt wird.

Damit die Gesamtplanung die Realität abbildet, ist die Möglichkeit zur laufenden Überprüfung gegenüber dem wirklichen Fortschritt zentral. Das wird erreicht, in dem für jedes Deliverable klar vereinbart ist, welche Merkmale es zu einem bestimmten Zeitpunkt verifizierbar aufweist (functional und non-functional). Gut eignen sich lauffähige Zwischenresultate. Entwürfe von Konzepten und Dokumenten eignen sich ebenfalls. Hier gilt es zum Beispiel zu vereinbaren, welche Fragen im Entwurf, in welcher Tiefe, schon geklärt sein werden. Eine Vereinbarung «x% liegt vor» eignet sich nicht. Sie führt zum bekannten Phänomen, dass für die letzten 20% des Resultates plötzlich 80% der Zeit notwendig werden und bergen böse Überraschungen zu einem späten Zeitpunkt. Die agilen Verfahren haben zum Beispiel mit der Definition of Ready (=wann ist eine Anforderung vollständig beschrieben) und der Definition of Done (=was gehört alles zu einem vollständig abgeschlossenen Deliverable) gute Elemente etabliert. Wichtig ist, dass diese wirksam gelebt werden. In klassischen Verfahren, wird über eine laufende Qualitässicherung erreicht, dass Überprüfbarkeit früh etabliert ist (anstatt «am Ende im Testing den Stand festzustellen»). Ist die Überprüfbarkeit von Deliverables zu wenig gegeben, kann die Gesamtplanung nicht zur Steuerung dienen, da die Abkoppelung von der Realität unvollständig und zu spät erkannt wird.

Es hat sich als gute Praxis bewährt, die Planung so auszugestalten, dass alle 2 Wochen verifizierbare Resultate vorliegen. Das ist gut machbar, weil auch Zwischenresultate eines grösseren Deliverables dargestellt werden (Überprüfbarkeit beachten). Diese Granularität erlaubt einerseits eine effektive Fortschrittskontrolle und ermöglicht es andererseits den Gesamtverantwortlichen, festzustellen, wo es nicht gelingt, «den Elefanten in Scheiben zu schneiden». Kleinere Granularität ist unrealistisch, grössere Granularität erhöht das Risiko, Verzug zu spät zu erkennen und zu lange zu benötigen «den Kurs des Tankers zu ändern». Wenn man sich zum Beispiel auf 2-wöchige Sprints einigt und sicherstellt, dass in jedem Sprint abgeschlossene Resultate vorliegen, entsteht eine zweckmässige Granularität.

Die Fortschrittskontrolle stellt die Auslieferung der definierten Lieferobjekte ins Zentrum. Die Gesamtverantwortlichen konzentrieren sich auf das Vorliegen abgeschlossener Deliverables, deren Vollständigkeit verifiziert ist (functional und non-functional). Sie orientieren sich nicht an Aktivitäten. In klassischen Projektsetups ist eine gut aufgesetzte Qualitätskontrolle das Instrument zur Verifikation der Deliverables. Die 2-Wochen-Granularität hilft zudem, sicherszustellen, dass die erforderliche Qualität laufend entsteht und nicht «an Ende in des System getestet werden soll». In agilen Vorhaben sind gut geführte Qualitäts-Gilden notwendig, damit im gesamten Projekt die Resultate gleich verifiziert werden. Ist die Fortschrittskontrolle nicht auf abgeschlossene Deliverables abgestellt, ist es bei entsprechender Grösse des Vorhabens praktisch unmöglich, frühzeitig festzustellen, wo Verzögerungen entstehen und eine proaktive Steuerung stark erschwert.

Es ist in sehr grossen Vorhaben einfach, den Überblick zu verlieren und schwierig festzustellen, wo Steuerung notwendig ist und wo «die Dinge im Moment richtig laufen». Das effektivste Instrument ist aus unserer Sicht ein gut aufgesetztes Status-Meeting. Wenn die vorangehenden Essentials beherzigt wurden, dann kann das PMO mit wenig Aufwand transparent aufbereiten, welche Soll-Deliverables vollständig vorliegen und welche nicht. Auf dieser Basis verfügen die Verantwortlichen über ein realitätsnahes Gesamtbild des Standes; als Basis für Diskussionen etwaiger Massnahmen etc. Das Status-Meeting dient als Instrument an der Spitze, welches transparent macht, wo das Vorhaben wirklich steht. Es ersetzt keinesfalls Demo’s, inhaltliche Diskussionen, Abstimmungen auf allen Stufen und ist umgekehrt unerlässlich, auch wenn man schon Demo’s gesehen hat und viele gute inhaltliche Diskussionen geführt wurden. Grosse Vorhaben bringen immer eine sehr grosse Anzahl an Meetings hervor. Es ist wichtig, regelmässig die Anzahl der Meetings zu hinterfragen und zu reduzieren. Auf ein effizientes, durch das PMO gut vorbereitetes wöchentliches Status-Meeting sollte unserer Meinung nach jedoch nicht verzichtet werden.

Damit auch die Kosten wirklich gesteuert werden können (und nicht einfach resultieren), muss die Projektleitung laufend wissen, wie viele Mittel noch benötigt werden, sodass Diskussionen und Entscheidungsprozesse zu Scopemodifikationen und Budgeterhöhungen rechtzeitig erfolgen. Dafür ist eine monatliche Berechnung der voraussichtlichen totalen Projektkosten in Echtzeit notwendig. Und zwar auf Basis der per dato aufgelaufenen Kosten, sowie der noch zu leistenden Arbeiten und aller noch entstehenden Kosten.

Aufgelaufene Kosten: Es genügt in der Regel nicht, diese auf Basis der eintreffenden Rechnungen zu bestimmen, denn diese treffen mit erheblichem Verzug ein. Die geleisteten Arbeiten / bezogenen Leistungen sollten sofort (zum Beispiel bis am Dienstag der Folgewoche) erfasst und durch die Verantwortlichen plausibilisiert sein, sonst ist man nicht in Echtzeit unterwegs. Das lässt sich mit einem geeigneten Tooling und ein wenig Disziplin etablieren.
Voraussichtliche Restkosten: Jeder Verantwortliche für ein Teilvorhaben (siehe Essential 2) muss einmal pro Monat prognostizieren, wie gross der Restaufwand ist, um den gesamten Auftrag abzuschliessen. Im PMO kann auf dieser Basis effizient und genau berechnet werden, wie hoch die voraussichtlichen Gesamtkosten ausfallen werden. Es kann auch belastbar aufgezeigt werden, wo die potentiell grössten Hebel für Massnahmen sind.

Der Aufbau für das Tooling und das Etablieren der entsprechenden Disziplin erscheint Anfangs aufwändig. Es lohnt sich aber sobald wenn bei den ersten Deliverables grössere unvorhergesehene Probleme auftreten.