Thought Leadership
Zur Entwicklung umfangreicher IT-Projekte gibt es eine Vielzahl an Verfahrensmodellen. Fast immer existieren in diesen Modellen definierte Qualitätssicherungs- und Controlling-Punkte, sogenannte Gates. Diese Gates bewirken in der Praxis jedoch häufig etwas anderes als ursprünglich beabsichtigt.
Um in einem umfangreichen IT-Projekt mit mehreren Phasen und vielen Projektmitarbeitern Qualitätsvorgaben und Standards einhalten zu können, werden zumeist Kontroll- und Abnahmepunkte mit definierten Zielvorgaben eingesetzt.
Definition und Zweck eines Multi-Gate-Prozesses (MGP)
Die Absicht, die mit diesen Kontrollpunkten oder Gates verfolgt wird, ist neben der Einhaltung von Qualität und Standards auch eine Segmentierung der Projektplanung und des Gesamtbudgets zur besseren Projektsteuerung.
Zumeist liegen diese Gates zwischen den einzelnen Projektphasen (vgl. Bild 1). Situationsbedingt kann es allerdings auch sinnvoll und notwendig sein innerhalb einer Phase weitere Kontrollpunkte zu setzen. So bieten sich beispielsweise in Testphasen häufig mehrere Gates für System- und Integrationstests an. Die Anzahl an Gates unterscheidet sich dabei generell je nach Branche und Komplexität.
Die Zuständigkeiten für die Abnahme der Deliverables einer Projektphase liegen bei der Programm- oder Projektleitung. Diese können anhand der Aufwandsschätzungen für die einzelnen Projekte beziehungsweise Phasen zudem sehr schnell einen effizienten Zeitplan für die einzelnen Gates festlegen. Das Verhältnis und die wechselseitige Beeinflussung der Phasen und Gates veranschaulicht Bild 2 exemplarisch.
Hier wird deutlich, dass die Aktivitäten des Multi-Projekt- beziehungsweise Programmanagements (obere Schicht) mit den Aktivitäten des Projektmanagements (untere Schicht) in einer definierten Reihenfolge ablaufen. Das Multi-Projekt- beziehungsweise Programmanagement steuert und verwaltet hierbei einzelne Projekte in einer ähnlichen Art wie das spezifische Projektmanagement die konkreten Aktivitäten eines Projekts. Die unteren Aktivitäten können hierbei an den oberen Gates blockieren und umgekehrt. Die Möglichkeit einer Parallelisierung besteht in der Regel nicht.
Von der Absicht zur Praxis
In Unternehmen, die mehrere Projekte durch dieselben Gates führen, können sich die Gate-Termine nicht nach einem einzelnen Projekt richten, das bedeutet, hier wird oft mit einem festen zeitlichen Raster („timeboxed“) gearbeitet. Dies führt dazu, dass ein Projekt oftmals auf einen Gate-Termin warten muss. Scheitert ein Projekt an einem Gate, entstehen wiederum Wartezeiten, da Nachbesserungen bis zum nächsten Gate erfolgen müssen. Durch diese Blockade- und Warte-Situationen entstehen Leerläufe, in denen es beispielsweise nicht immer möglich oder sinnvoll ist das vollständige Personal im Projekt zu halten. Der Verlust von fähigem Personal, insbesondere externe Projektmitarbeiter gehen dem Projekt so häufig verloren, hat wiederum zur Folge, dass in einer späteren Phase projektfremde Kollegen neu angelernt werden müssen.
Erstaunlich in diesem Zusammenhang ist die Tatsache, dass Multi-Gate-Prozesse üblicherweise zwar bis in das kleinste Detail erschöpfend reglementiert und dokumentiert sind, die Auswirkungen dieser Prozesse auf den Projektalltag hingegen nicht betrachtet werden.
Die Tabelle 1 zeigt die Vielzahl an Nebenwirkungen, die durch den Einsatz von Gates entstehen können und die in den allermeisten Unternehmen bislang nicht ausreichend analysiert beziehungsweise im Vorfeld berücksichtigt werden.
Ein wesentlicher Aspekt, der neben den Wartezeiten ebenfalls alle Abteilungen betrifft, ist das unternehmenspolitische Verhalten. So werden oftmals, nachdem in den frühen Phasen an den Gates Zeit „verloren“ wurde, die folgenden Gate-Termine rigoros beibehalten und unvollständige oder fehlerhafte Arbeiten durch die Gates geschoben. Das eigentliche Prinzip des Prozesses wird so außer Kraft gesetzt und daraus resultierende Qualitätsmängel bei Inbetriebnahme bewusst in Kauf genommen.
Wie viel MGP ist nötig und welche Alternativen gibt es?
Multi-Gate-Prozesse sind fester und wesentlicher Bestandteil der klassischen Verfahrensmodelle wie „Wasserfall“, V-Modell oder RUP (Rational Unified Process). Auf der anderen Seite stehen die agilen Methoden, die Qualität und Standards über vollkommen andere organisatorische Methoden sichern.
Während bei den klassischen Modellen die Qualität durch definierte Gates zu festen Zeitpunkten und in großen Abständen überprüft und sichergestellt wird, erstellt man bei den agilen Methoden in sehr kurzen Intervallen Artefakte, die qualitativ der Übergabe in den Produktivbetrieb genügen würden. Artefakte, die der vorgegebenen Qualität zum Ende eines Intervalls nicht entsprechen, werden nicht an spätere Phasen übergeben. Agile Methoden variieren somit nur den Umfang der Anforderungen, nicht jedoch Qualität und Zeit. In Scrum und Extreme Programming (XP) priorisiert man beispielsweise einen kleinen Teil der Gesamtanforderungen eines Projektes und arbeitet diesen dann unterbrechungsfrei ab, also ohne Changes über einen fixen Zeitraum von zwei bis vier Wochen. Im Anschluss daran kann das Unternehmen bei agilen Methoden auf sich ändernde Anforderungen,etwa in Folge von Marktereignissen, sofort reagieren.
Die Frage nach einer möglichst effizienten Anzahl an Gates orientiert sich nicht zuletzt an dem späteren Verwendungszweck des Produktes. Bei der Realisierung einer neuen Software im Bereich der Flugsicherung ist die genaue Einhaltung von Sicherheitsstandards und allerhöchsten Qualitätsansprüchen wesentlich wichtiger als eine möglichst schnelle Markteinführung. Für ein neues Feature in einer Web 2.0-Anwendung ist genau das Gegenteil der Fall. Diese zwei Beispiele liegen an den entgegengesetzten Enden der Skala. Was ist jedoch mit den Produkten und Diensten dazwischen? Wäre es denkbar das Beste aus beiden Ansätzen, den klassischen und den agilen Methoden, miteinander zu verbinden?
Die Verknüpfung von MGP und agilen Methoden
Generell sind Multi-Gate-Prozesse eindeutig im Vorteil, wenn entweder eine exakte Einhaltung der Anforderungen zwingend erforderlich ist oder verschiedene Projektelemente miteinander abgestimmt und zusammengeführt werden müssen. Agile Methoden hingegen sind vorteilhaft, wenn inkrementelle Verbesserungen auf dem Plan stehen, es nur einen geringen koordinativen Abstimmungsbedarf gibt und time-to-market wichtiger ist als die exakte Einhaltung des Umfangs einer Anforderung.
Aus diesem Blickwinkel erscheint es sinnvoll die Basis (Architektur- und Framework-Komponenten) eines umfangreichen IT-Systems nach MGP-Prinzipien zu gestalten und Erweiterungen, die nicht in die generelle Funktionsweise der Architektur eingreifen, nach agilen Prinzipien zu entwickeln. In Projekten mit mehreren Zulieferern müssten die Arbeiten dann an vorher definierten Punkten zusammenführt werden.
Denkbar wäre auch ein agiler Entwicklungsprozess, dem ein „klassisches“ phasenorientiertes Qualitätsmanagement folgt. Hier könnten einerseits Ideen, aufgrund der engen Zusammenarbeit von Fachbereich, Entwicklung und Test, sehr schnell umgesetzt werden. Andererseits würden die Gates, etwa für die Phasen Test und Rollout, die strikte Einhaltung der Anforderungen bei der Produkteinführung sicherstellen.
Eine weitere Kombinationsmöglichkeit ist die Umsetzung unterschiedlicher Unterprojekte nach agilen Methoden und eine koordinierte Zusammensetzung dieser Unterprojekte bei definierten Gates durch die Programmleitung. In diesem Falle würden die Gates wirklich nur dort eingesetzt, wo sie tatsächlich benötigt werden und somit die Vorteile der agilen Methoden gewinnbringend ergänzen.
Effizienter Umgang mit MGP
Wenn Multi-Gate-Prozesse in einem Unternehmen angewandt werden, ist es notwendig den Zweck dieser Gates konsequent zu verfolgen und gleichzeitig die Nebeneffekte möglichst gering zu halten. Um dies zu erreichen, müssen die folgenden fünf Prinzipien umgesetzt werden.
1. Beschränkung auf essentielle Gates
Identifizierung und Vermeidung von Gates, die keinen konkreten Vorteil bringen und somit unnötigen Mehraufwand verursachen.
2. Beschränkung auf essentielle Deliverables
Im MGP entstehen viele sehr umfangreiche Deliverables. Diese müssen bewertet und verwaltet werden. Um die eigentlichen Absichten dabei nicht aus den Augen zu verlieren, muss eine Konzentration auf die absolut notwendigen Deliverables erfolgen.
3. Einbeziehung aller Stakeholder, auch bereits in der Machbarkeitsuntersuchung
Der störungsfreie Projektablauf muss von Anfang an umfangreich überprüft und abgestimmt werden um spätere „show stopper“ zu verhindern, die das gesamte Projekt gefährden können.
4. Vorausschauende Personal- und Budget-Planung
Frühzeitige Allokation von benötigten Ressourcen sowie rechtzeitige Planung und Festlegung der Gate-Termine sparen Zeit und Kosten.
5. Einsatz von zentralen Projektkollaborationswerkzeugen
Die „entkoppelte“ Natur von MGP-Projekten – man sendet sich umfangreiche Dokumente zu – bewirkt einen Informationsverlust, da die persönliche Abstimmung abnimmt. In der agilen Entwicklung ist der Austausch zwischen den Abteilungen intensiver und findet vor allem häufiger statt. Dieses Defizit an zeitnahen Steuerungsmöglichkeiten kann durch zentrale Kommunikationshilfen deutlich verringert werden. Die Projektmitarbeiter aus späteren Phasen erhalten beispielsweise schließlich nur dann die Möglichkeit rechtzeitig Bedenken zu äußern, wenn sie die Deliverables der frühen Phasen frühzeitig einsehen können.
Fazit
Multi-Gate-Prozesse haben einen massiven Einfluss auf fast alle Unternehmensbereiche. Nicht nur die Time-to-Market für neue Produkte und Dienste sondern auch das Personal und die Budgetierung von Projekten wird stark beeinflusst.
Bei dem Einsatz eines MGP sollten daher konsequenterweise auch die damit verbundenen Termine und Gates eingehalten werden. Steht die Einhaltung eines Termins jedoch auf Kosten der Qualität an erster Stelle, sind die Ziele und Absichten des MGP unterwandert. Bei der Konzeption eines MGP muss deshalb genau abgewogen werden wie viele Gates notwendig sind, also welche Gates einen vertretbaren Mehrwert darstellen und welche nicht. Ebenso müssen die Art, Anzahl und Tiefe der Deliverables bei den Gates sinnvoll abgestimmt werden. Wer zu viel Aufwand in die falschen Deliverables steckt, verbrennt Zeit und Geld und lässt die Deliverables zu einem Selbstzweck werden, der dem Projekt eher schadet.
Eine Verknüpfung von MGPs und agilen Entwicklungsmethoden ist dann sinnvoll, wenn die Methoden ihren Stärken entsprechend eingesetzt werden. Die Kombination kann dabei nicht nur entlang der Projektphasen erfolgen (horizontal), sondern auch im Zusammenspiel zwischen Projekt (agil) und Programm (MGP).
Grundsätzlich gilt bei der Arbeit mit MGPs, auch wenn kein Einfluss auf die Prozessgestaltung genommen werden kann, dass durch eine vorausschauende Planung viele Probleme und manche zeitliche Verzögerung bereits im Vorfeld verhindert beziehungsweise kompensiert werden können.
Eric Ballnath
