Um die Digitalisierung verlässlicher voranzutreiben und schneller auf ein sich änderndes Marktumfeld reagieren zu können, wollte die DB Netz AG die Zielerreichung ihrer IT-Projekte (agil und Wasserfall) und die Reaktionsfähigkeit des Portfolios deutlich erhöhen. Das Ergebnis ist ein erstaunlich einfaches Phasenmodell mit nur zwei Quality Gates, die gegenläufig arbeiten: Eines sammelt möglichst viel Wissen für Portfolioentscheidungen; das andere filtert – es lässt nur durch, was reif ist. Dieses Modell fokussiert sich auf Ergebnisse und lässt den Projekten die Freiheit, wie diese sie erreichen. Es gibt agilen Projekten einen Rahmen, um mit einem Mindestmaß an Planung erfolgreich zu sein. Zudem fördert das Modell die KommunikationKommunikationIm Projektmanagement ist der Austausch von Informationen zwischen den Projektbeteiligten ein entscheidender Erfolgsfaktor und Kommunikation ist ein eigenständiger Aufgabenbereich für die Projektleitung. und Nutzung von Freiheitsgraden und trägt so zum Kulturwandel bei.

Die üblichen Verdächtigen

Jeder, der sich mit der Durchführung von Projekten in Unternehmen auskennt, weiß um die üblichen Ursachen, warum Projekte nicht so erfolgreich sind, wie sie sollten. Für die Entwicklung des Phasenmodells waren vorrangig drei Schwachstellen ausschlaggebend:

• Viele Projekte waren auf viele Jahre und mit hohem Budget geplant, während die Produktivsetzung oftmals am Ende erfolgte. Das Phasenmodell sieht eine maximale Projektdauer von zwei Jahren und ein maximales Budget im niedrigen einstelligen Millionenbereich vor. Dazu müssen Großprojekte völlig anders angegangen und im Vorfeld in kleinere, unabhängige Einheiten zerlegt werden – mit dem Vorteil, dass die Ergebnisse früher zu Nutzen führen, das Lernen früher einsetzt und die Risiken minimiert werden.
• Es gab vor dem Modell praktisch nur einen einzigen Detaillierungsgrad der Projektanmeldungen. Mit dieser Anmeldung wurde ein Projekt genehmigt und ging damit unverzüglich in die Durchführung. Wurde das Projekt abgelehnt, war diese Detaillierung verlorener Aufwand. Wurde das Projekt genehmigt, war diese Informationslage für den Start der Software-Entwicklung meist zu ungenau. Im Phasenmodell sind daher zwei Quality Gates mit zwei unterschiedlich detaillierten Projektanmeldungen vorhanden, die jeweils nur die zum jeweiligen Zeitpunkt sinnvollen Informationen verlangen. Vor dem zweiten Quality Gate reift die Idee durch ein Vorprojekt zu einem effektiv und effizient ausführbaren Projekt.
• Das Portfolio wurde einmal jährlich festgelegt. Die Reaktionsfähigkeit auf geänderte Umweltbedingungen oder Prioritäten war gering. Projektideen, die nach dem Abschluss des Portfolioprozess aufkamen, mussten im schlimmsten Fall mehr als ein Jahr warten, bis das Projekt starten konnte. Mit dem Modell können nun in einer vierteljährlichen Portfolioüberprüfung zum einen Vorprojekte aus einem Innovationsbudget finanziert werden, zum anderen wird geprüft, welche Projekte ausreichende Reife – und immer noch ausreichende Attraktivität – besitzen, um in die Umsetzung zu gehen.

Das Phasenmodell für IT-Projekte

Bild 1: Phasenmodell mit zwei gegenläufigen Quality Gates, die IT-Ideen sammeln und für die Umsetzung filtern
Bild vergrößern

Ziel des Phasenmodells war, die identifizierten Schwachstellen zu beseitigen, um ein effektiveres Projektmanagement und ein reaktionsfähigeres Portfoliomanagement zu erreichen. Der Weg dorthin bestand nicht darin, neue Vorschriften aufzustellen oder die Anwendung der vorhandenen Regeln stärker zu überwachen, sondern wenige entscheidende Meilensteine in Form von Quality Gates und Auslieferungsterminen festzulegen, zwischen denen das Projekt auf die Weise arbeiten kann, wie es jeweils am besten ist und seine Freiheitsgrade nutzen kann. Wir entwickelten das Phasenmodell in rund vier Monaten mit 50% FTE. Besonders viel Zeit investierten wir in die Abstimmung mit den unterschiedlichen Stakeholdern, was eine termingerechte Verabschiedung durch den Vorstand und eine glatte Einführung ermöglichte.

Eine besondere Herausforderung war, dass das Phasenmodell sowohl für die tendenziell abnehmenden Wasserfallprojekte als auch für Projekte nach agiler Vorgehensweise passen sollte. Die Projektvorgehensweise ergibt sich aus den Präferenzen des jeweiligen Fachbereichs, dem Rahmen des Vorprojekts oder dem Projektinhalt; ein Ausschreibungsprojekt zum Einkauf von Standard-Software wird z.B. wasserfallartig durchgeführt.

Bestandteile und Phasen im Modell

IT-Ideen

IT-Ideen stellen neue, mit IT umzusetzende Anforderungen i.d.R. des Fachbereichs dar. Auch die IT selbst kann IT-Ideen in das Portfolio einbringen, um z.B. neue Technologieplattformen einzuführen. Damit werden auch diese aus einer Investitionssicht mit Business Case betrachtet und im Rahmen der üblichen Portfoliopriorisierung behandelt.

Das IT-Budget wird weiterhin jährlich in der Gesamtunternehmensplanung durch den Vorstand festgelegt und üblicherweise ist ein relevanter Anteil bereits durch Projekte aus Vorjahren belegt. Das vierteljährlich zusammenkommende Portfoliogremium, das sich aus dem Gesamtvorstand zusammensetzt, wählt IT-Ideen aus, die mit Budgetmitteln weiter ausgearbeitet werden sollen, und bereits ausgearbeitete Ideen, die in die Umsetzung gehen sollen. Das Gremium entscheidet somit über die Initiativen, die jeweils das Quality Gate "Idee" oder "Planung" abgeschlossen haben.

Definitionsphase und Quality Gate "Idee"

Ziel des Quality Gate "Idee" ist es, möglichst viele im Unternehmen vorhandene Ideen zu priorisieren. Daher sind die Anforderungen des Quality Gate vergleichsweise gering. Die Informationen zu einer IT-Idee müssen aber ausreichen, um eine Beurteilung im Portfoliogremium zu ermöglichen. Z.B. müssen die Projektziele grob beschrieben sein (siehe Tabelle 1).

Beispiel: Es soll ein deutschlandweites Bestellportal für Service-Einrichtungen eingeführt werden, die bisher per Formular bestellt wurden. Hier sind als Projektziele zu nennen: eine zunächst noch nicht quantifizierte aber qualitativ vorhandene Kostenreduktion sowohl im Unternehmen als auch beim Kunden sowie eine höhere Benutzerfreundlichkeit, die zu erhöhter Prozessqualität und Anwenderzufriedenheit führt.

Durch die geringen Anforderungen an die IT-Ideen kann mit verhältnismäßig wenig Aufwand eine möglichst vollständige Bedarfssituation des Unternehmens aufgestellt werden: Ein ggf. vorhandener Innovationsstau oder Digitalisierungsdruck wird deutlicher und entsprechende Maßnahmen können eingeleitet werden. Darüber hinaus geht im Falle der Ablehnung eines Vorhabens nur ein überschaubarer Aufwand verloren.

Die Themenfelder des Quality Gates "Idee"

Das Portfoliogremium wählt nach Abwägung von fachlicher/strategischer Notwendigkeit und Ergebnis des Business Case IT-Ideen zur Ausarbeitung aus. Diese Ideen werden bis zu einem festgelegten Höchstbetrag aus dem reservierten Innovationsbudget ausgestattet, damit sie im Rahmen der Phase "Konzeption und Planung" inhaltlich detailliert und projektmanagementmäßig grob geplant werden.

Da die Enterprise Architekten aus der IT bei allen IT-Ideen bereits grob einbezogen wurden, können sie Synergien identifizieren und im Vorfeld durch Abstimmung mit den Projekten Vorschläge zur Optimierung des Portfolios einbringen, z.B. zwei Anforderungen für eine ähnliche Technologie gemeinsam zu untersuchen.

Projektschnitt

IT-Ideen können umfangreiche Projekte nach sich ziehen, z.B. die Einführung einer technischen Plattform für die Digitalisierung der Kundeninteraktion. Aufgrund der negativen Erfahrung mit langen und umfangreichen Projekten wird durch die Enterprise Architekten gemeinsam mit dem Fachbereich eine Aufteilung derart großer Ideen in steuerbare Projekte vorgenommen, die die Größen- und Laufzeitrestriktionen des Phasenmodells einhalten (Projektschnitt). Ebenso können IT-Ideen in ein Projekt zusammengeführt werden, wenn dies sinnvoll erscheint.

Dieser Projektschnitt bedeutet oft eine völlig andere Herangehensweise an IT-Projekte als früher. Er zwingt zu einer echten strategischen Auseinandersetzung mit dem Projektziel, den Geschäftsprozessen und dem Unternehmensumfeld. Das Großprojekt wird in Teile aufgeteilt, die einzelne Geschäftsfunktionen erzeugen und über die Zeit verteilt produktiv gesetzt werden – und so frühzeitig Nutzen schaffen, Lernen fördern und Risiken mindern.

Es geht hierbei weniger um Programm- und Multiprojektmanagement, das nötig ist, um personelle und andere Abhängigkeiten zu managen. Durch den architektonischen Projektschnitt sollen so weit wie möglich unabhängige Projekte parallel arbeiten. Vorhandene Abhängigkeiten werden in sequentiellen Projekten abgebildet. Diese Entflechtung kann auch Interimslösungen oder Koexistenzphasen mit abzulösenden Altanwendungen nötig machen. Das kann zusätzlichen Aufwand bedeuten, gleichzeitig aber erreicht das Unternehmen seine Business-Ziele schneller und mit einer höheren Wahrscheinlichkeit.

Konzeptions- und Planungsphase und Quality Gate "Planung"

Vor jedes dieser Projekte wird in der Phase "Konzeption und Planung" ein Vorprojekt geschaltet, in dem mit festgelegtem Budget – im Vergleich zum späteren Umsetzungsprojekt niedrig, ca. 10% – die IT-Idee so ausgearbeitet wird, dass der Nutzen (auch nicht-monetär) des späteren Einsatzes von erheblichen Budgetmitteln und Personalkapazität bewertet werden kann.

Ein grober Projektplan mit wichtigen Release-Terminen und -Inhalten ist ebenfalls Ergebnis des Vorprojekts. Hierdurch erhält das spätere Projekt regelmäßige, prüfbare Meilensteine, an denen über Fortsetzung oder vorzeitige Beendigung entschieden wird. Oberstes Gebot ist die Einhaltung dieser Termine – eine Parallele zu Scrum, bei dem die Länge des Sprints stets gleich bleibt, auch wenn die Erreichung des Scopes gefährdet ist. Die Release-Inhalte werden hierbei nicht durch exakte Anforderungen beschrieben, sondern durch die grundsätzlich zu liefernde Geschäftsfunktionalität. Diese grobe Festlegung ermöglicht auch die quasi "geplante" Durchführung von agilen Projekten.

Waren die Anforderungen an den Reifegrad der Idee beim Quality Gate "Idee" noch relativ gering, muss das Projekt für das Bestehen des Quality Gate "Planung", das die Umsetzung freigibt, einen deutlich höheren Reifegrad aufweisen (siehe Tabelle 2). Im Beispiel des Bestellportals müssen für dieses Quality Gate die erwarteten Einsparungen quantifiziert werden, so dass diese ab dem Zeitpunkt der produktiven Nutzung auch in die Unternehmensplanung einfließen. Die Entscheidung für die Umsetzung der IT-Idee hängt wesentlich von der Vorteilhaftigkeit des Business Case ab.

Die Themenfelder des Quality Gates "Planung"

Priorisierung der Umsetzungsprojekte

Über die Fortsetzung der Vorprojekte in Umsetzungsprojekten entscheidet erneut das Portfoliogremium. Dem Gremium steht nun ein detaillierter Business Case zur Verfügung sowie aussagefähigere Begründungen für strategische Zielbeiträge und gesetzliche oder regulatorische Anforderungen.

Für die Priorisierung der Projekte hat sich bewährt, zwei Alternativszenarien zu prüfen. Eine Alternative stellt die Option dar, eine Anforderung, insbesondere eine gesetzliche oder regulatorische Vorgabe, ohne IT-Mittel zu lösen. Zum Teil kann durch geringen Personalaufbau ein millionenschweres IT-Projekt ersetzt werden. Das kann zur Abwendung von sehr langen Amortisationsdauern führen und noch wichtiger, es setzt IT-Kapazitäten frei, die mit einem höheren Nutzen in andere Projekte investiert werden können. Die zweite Alternative ist die Option, gar nichts zu tun – sie stellt damit die Baseline für die Business Case-Berechnung dar. Somit können z.B. die finanziellen Auswirkungen von nicht umgesetzten rechtlichen Vorgaben (z.B. Strafzahlungen) ein Projekt mittels Opportunitätskosten – richtigerweise – auch zahlenmäßig attraktiver erscheinen lassen.

Umsetzungsphase

Bis zum Quality Gate "Planung" ist die Logik, nur so viel Aufwand im Vorprojekt zu erzeugen, wie für eine Priorisierungsentscheidung nötig ist. Nach der Entscheidung zur Durchführung des eigentlichen Projekts fällt somit neben den administrativen Themen wie Beschaffung der bereits angefragten und idealerweise reservierten Räumlichkeiten, personellen und technischen Ressourcen vor allem die Überarbeitung der Planung an. Je nach Vorgehensmodell wird eine Feinplanung durchgeführt oder das agile Projekt mit dem Aufbau des Product Backlogs gestartet.

Aufgrund der Vorbereitungen zum Projektstart ist die erste Produktivlieferung nach sechs Monaten obligatorisch und jede weitere nach drei Monaten. So erhält das Projekt nachprüfbare Meilensteine in einem überschaubaren Zeitraum, die sowohl dem Fachbereich die Möglichkeit zum Lernen und besseren Beeinflussen des weiteren Projektverlaufs geben, als auch eine Einschätzung über das Erreichen des Gesamtprojektziels und das frühzeitige Einleiten adäquater Maßnahmen erlauben.

Ist das noch agil?

Durch das Phasenmodell werden auch agile Projekte mit einem Vorprojekt und einem bei Beginn der Umsetzung vorgegebenen Raster aus Release-Terminen und -Inhalten durchgeführt. Denn auch eine agile Umsetzung einer Geschäftsfunktion hängt nicht im luftleeren Raum. Die Process Owner der zuliefernden und abnehmenden Geschäftsprozesse (was auch Unternehmensexterne, also Kunden und Lieferanten, sein können) werden im Vorprojekt eingebunden. Diese Gespräche sorgen dafür, dass der Product Owner noch mehr über die erfolgskritischen Anforderungen lernt und ggf. neue, bessere Ideen bekommt – bevor die ersten, schwer zu ändernden Richtungsentscheidungen durch das ProjektteamProjektteamDas Projektteam umfasst alle Personen, die aktiv am betrachteten Projekt beteiligt sind. Dies umfasst u.a. den Lenkungsausschuss , den Auftraggeber , den Projektmanager und alle Projektmitarbeiter umgesetzt werden. Das Vorprojekt trägt somit wesentlich zum Lernen bei und erhöht sowohl Effektivität als auch Effizienz des Projektergebnisses.

Meilensteinplanung auch für agile Projekte sinnvoll

Die vorangehende Festlegung von Release-Terminen und -Inhalten unterstützt die Zielerreichung des agilen Projekts und lässt ihm gleichzeitig Freiheit. Nach dem Vorprojekt sollte der Product Owner so viel über sein Ziel und den Projektauftrag gelernt haben, dass die groben Anforderungen stabil sind. Für das Bestellportal z.B. können an drei Release-Terminen die Geschäftsfunktionen Anzeige Produktkatalog, Pflege Warenkorb und Bestellung/Backend-Prozess festgelegt werden. Innerhalb jedes der drei Releases kann das Projekt agil die jeweilige Geschäftsfunktion entwickeln.

Im magischen Dreieck Time-Scope-Quality ist damit sichergestellt, dass Time und Scope eingehalten werden. Quality im Sinne von Benutzerfreundlichkeit (nicht Fehlerfreiheit, diese ist nicht verhandelbar!) ist variabel: Der Produktkatalog mag noch nicht der schönste sein – aber für die Kunden, die bisher Formulare gewohnt waren, ist das echter Fortschritt. Die Anbindung der Backend-Prozesse kann immerhin 80% aller Fälle automatisiert verarbeiten. Hier entspricht der Automatisierungsanteil dem Grad der variablen Qualität im magischen Dreieck.

In dieser Release-Taktung sind auch Abhängigkeiten zu anderen Projekten realisierbar. Sowohl zu liefernde als auch zu erhaltene Services können auf Termin gelegt werden, ebenso kann die Nutzung von Schlüsselpersonen zeitlich begrenzt werden.

Fazit – was hat's gebracht?

Das Phasenmodell sorgt dafür, dass der Macro-Scope für agile Projekte festgelegt ist und der Micro-Scope variabel bleibt. Somit wird man auf jeden Fall das gewünschte Ziel, z.B. eines durchgängigen Prozesses, erreichen, wenn auch nicht alle Prozessschritte gleich gut. Das ist in vielen Fällen sinnvoller, als am Projektende einen Teil der Anforderungen sehr gut erfüllt zu haben, das Versprechen des Business Case aber nicht erfüllen zu können.

Neben der Release-Taktung ist die erhöhte Kommunikation vor allem vor der Umsetzung ein wesentlicher Beitrag zu einem größeren Projekterfolg. Die Einbindung der Architektur, der IT-Sicherheit, des Datenschutzes, des Betriebsrats und der benachbarten Process Owner sorgt nicht nur für Anforderungen, die vom Projekt zu erfüllen sind, sondern sie fördert das Commitment, das Projekt gemeinsam erfolgreich durchzuführen. Da ein Projekt nicht erfolgreich ist, wenn es seinen Scope "in time and budget" ausgeliefert hat, sondern erst, wenn es durch die Anwendung des Projektergebnisses Nutzen einfährt, ist die Mitarbeit dieser Bereiche essentiell. Ein Stopp der Nutzung z.B. wegen missachteter Sicherheitsauflagen, fehlender Betriebsvereinbarungen oder Verstößen gegen den Datenschutz macht jeden Business Case zunichte.

Auf Portfolioebene führte das Phasenmodell durch die gestiegene Transparenz sowohl bei den IT-Ideen als auch bei den zu genehmigenden Umsetzungsprojekten zu einer intensiveren inhaltlichen Auseinandersetzung und einem datenbasierten Entscheidungsprozess. In den IT-Projekten wird somit nicht nur mehr "richtig gemacht" – es wird auch mehr "das Richtige" gemacht.

Wohin geht die Reise?

Auch wenn das Phasenmodell viele Schwachstellen angeht, bleibt die Frage, ob es in Zeiten der Digitalisierung insbesondere für kundennahe IT-Projekte schnell und flexibel genug ist. Der Trend verstärkt sich weiter, dass ein beträchtlicher Anteil von IT-Budget nicht mehr über den IT-Bereich gesteuert wird: Fachbereiche beschaffen Hardware, beschäftigen Entwickler oder kaufen Cloud-Dienste.

Diese kundennahe IT setzt ihre Software-Entwicklung oft in einem mehr oder weniger kleinen Team um, das je nach Markt- und Wettbewerbssituation manchmal täglich die Entscheidung zwischen Feature-Entwicklung und Fehlerbeseitigung neu trifft. Damit verschmelzen Projekt- und Wartungsbudget. Es kommt zu einer dauerhaften Weiterentwicklung von digitalen Produkten, um im Markt zu bestehen.

Arbeiten Teams künftig in BizDevOps zusammen?

Eine Lösung können vollständig erfolgsverantwortliche Teams aus Business, Entwicklung und Betrieb – BizDevOps – sein. Diese Teams entwickeln eine Idee zunächst zu einem Minimum Viable Product. Ist es erfolgreich, entwickeln sie es weiter. Wenn nicht, versuchen Sie die nächste digitale Innovation (Fail Fast). Wenn das Produkt noch erfolgreicher wird, wird das Team größer und teilt sich, damit es nicht zu groß wird. Das IT-Budget geht auf im Budget und Business Case dieses Teams, das im Zielzustand disziplinarisch im Fachbereich angesiedelt ist – volle Profit&Loss-Verantwortung.

Die Kern-IT übernimmt in einem solchen Szenario die übergeordneten und shared ressources-Aufgaben: Governance, Enterprise Architektur, Plattformbetrieb, Beratung zu IT-Sicherheit und Datenschutz etc. Die Enterprise Architektur z.B. berät die Teams zum Einsatz von Technologie, beispielsweise zu den Betriebskosten unterschiedlicher Technologien, und sorgt für teamübergreifendes Lernen. Auch bei einer leichtgewichtigen Governance wird sie einige harte Leitplanken hinsichtlich Technologie und Prozesse setzen – damit erst wird Fail Fast sicher und akzeptabel.

Ein großer Teil der Komplexität im Portfolio- und Projektmanagement – und damit auch nutzlose Prozesskosten – wird durch eine solche Struktur abgebaut, gleichzeitig werden Kundennähe und Innovationsfähigkeit gewonnen. Der Kern des Phasenmodells – eine Idee reifen zu lassen und ein hartes Quality Gate einfügen, bevor man an die Umsetzung geht – bietet auch in einer dezentralen Struktur einen unschätzbaren Nutzen.