Illustration: Absmeier
Eine hohe Komplexität sowie der Einsatz neuer und noch weitgehend unbekannter Technologien sind nahezu allen IT-Projekten gemein. Nicht wenige scheitern auch daran. Um IT-Projekte erfolgreich umzusetzen, ist ein umfassendes und konsequentes Projektmanagement unabdingbar. Dabei müssen dem Beratungsunternehmen iTSM Group zufolge vor allem 5 Aspekte besondere Berücksichtigung finden.
Klares Projektziel
Die wesentliche Voraussetzung für erfolgreiche IT-Projekte ist ein klar definiertes und abgrenzbares Projektziel, das überdies auch realistisch sein muss. »Kosteneinsparung oder schnellere Bearbeitung von Anfragen sind keine solchen Ziele«, so Tobias Beckmann, Head of Digital Service Advisory bei der iTSM Group. »Die gewünschten Verbesserungen sollten präzise beschrieben werden. Die bekannte SMART-Formel ist eine Möglichkeit Ziele zu beschreiben. Das Ziel sollte spezifisch, messbar, akzeptiert, relevant und terminiert sein, nur so ist der Projekterfolg zu erreichen.«
Alle Stakeholder einbeziehen
Die zweite und oftmals ignorierte Voraussetzung ist die frühzeitige Einbeziehung aller Stakeholder. So sollten schon in der Planungsphase nicht nur Entwickler, Projektmanager und externe Berater involviert werden, sondern insbesondere auch die Mitarbeiter und Endanwender in den betroffenen Abteilungen, von deren Input und Akzeptanz der Erfolg des Projekts letztlich abhängt. Je nach Projekt sollten ebenfalls auch Kunden schon während der Definitionsphase eingebunden sein.
Budget und Ressourcen
Eine klare Festlegung des Budgets und der für die Umsetzung erforderlichen Ressourcen ist die dritte Säule erfolgreicher IT-Projekte. »Viele Projekte scheitern oder verzögern sich, weil schlicht die Kosten aus dem Ruder laufen oder die Personalplanung mangelhaft war«, so Beckmann. »Unrealistisch niedrig angesetzte Budgets mögen die Freigabe vereinfachen, sind aber auf lange Sicht kontraproduktiv.«
Strukturiertes Vorgehen
Nicht nur Ziele und Budget müssen eindeutig definiert sein, wenn ein IT-Projekt erfolgreich sein soll, sondern auch das Vorgehen über den gesamten Projektzeitraum. Dieses muss klar strukturiert sein, wobei Frameworks für das Projektmanagement wie etwa PRINCE2® wertvolle Hilfe leisten können. Wichtig sind in diesem Zusammenhang laut iTSM Group auch ganz eindeutige Verantwortungs- und Entscheidungsstrukturen. »Wer die Verantwortung hat, muss auch Entscheidungen treffen können und umgekehrt«, kommentiert Tobias Beckmann. »Das klingt sehr offensichtlich, aber gerade in abteilungs- oder bereichsübergreifenden Projekten wird häufig gegen diesen Grundsatz verstoßen.«
Realistischer Zeitrahmen
Cloud, Microservices und DevOps versprechen heute eine hohe Agilität, aber dennoch bleibt ein realistischer Zeitrahmen immer noch entscheidend für den Projekterfolg. Dieser darf nicht nur die rein funktionale Umsetzung umfassen, sondern muss auch alle Funktions- und Sicherheitstests, den Rollout und die Schulung sämtlicher betroffenen Mitarbeiter beinhalten.
»In unserer schnelllebigen Welt ist kein Projekt vor dem Scheitern gefeit«, so Beckmann. »Aber wer die grundlegenden Erfolgsfaktoren berücksichtigt, hat deutlich bessere Aussichten auf ein erfolgreiches Ende.«
Darum scheitern IT-Projekte in der Öffentlichen Verwaltung
Illustration: Absmeier, Yuri_B
Eine unpräzise Formulierung der Projektziele, unklare Kompetenzverteilung und zum Teil eine unzureichende Ausbildung und Fähigkeiten in der Anwendung von Projektmanagement-Methoden sind nach Angaben des Beratungsunternehmens iTSM Group die häufigsten Ursachen für das Scheitern von IT-Projekten in der Öffentlichen Verwaltung. Und ein solches Scheitern ist nicht selten – nach unterschiedlichen Studien wird in diesem Bereich nur jedes zweite Projekt erfolgreich abgeschlossen. Das kürzlich vom Bundesrechnungshof massiv kritisierte Digitalisierungsprojekt der Bundesregierung ist hier also nur der Gipfel des Eisbergs.
Präzise Formulierung der Projektziele
Die fehlende Präzision bei der Formulierung der Projektziele führt laut iTSM zum Einen zu Orientierungslosigkeit bei den Projektbeteiligten und zum Anderen zu einem gefährlichen Eigenleben von Teilprojekten, denen ein gemeinsames Ziel fehlt und die sich zum Schluss nicht sinnvoll integrieren lassen. Nachbesserungen, Verzögerungen oder gar das Scheitern des gesamten Projekts sind die Folgen.
Unklare Kompetenzverteilung
Ungeklärte oder gar konkurrierende Kompetenzen sind ein weiteres spürbares Problem, wenn unterschiedliche Fachabteilungen oder multiple Behörden in ein Projekt involviert sind. An die Stelle konstruktiver Zusammenarbeit tritt dann häufig die Verfolgung von Partikularinteressen, die ein zielführendes Handeln erschwert. In einer solchen Konstellation erhält im Extremfall jemand Entscheidungskompetenzen, kann diese aber nicht projektübergreifend durchsetzen. So liegt beim Digitalisierungsprojekt des Bundes die Projektleitung beim Innenministerium, das aber kein Weisungsrecht gegenüber anderen beteiligten Ministerien und Dienstleistern hat.
Wenig Know-how bei Projektmanagement-Methoden
Auch nicht genügend ausgeprägte Fähigkeiten in der Anwendung von Projektmanagement-Methoden führen nicht selten zu erheblichen Problemen. So werden Projektleiter nach Erkenntnis der Berater vielfach überwiegend aufgrund ihrer fachlichen Expertise ernannt, wobei elementare Fähigkeiten für die Steuerung und Kontrolle von Projekten nicht ausreichend berücksichtigt werden. Solche Projektleiter haben dann in der Regel auch wenig oder keine Erfahrung mit Methodenwerken für das Projektmanagement, das daher ineffizient ist – mit der Folge von Kosten- und Terminüberschreitungen. Insgesamt wird nach der Erfahrung der Berater auch dem Controlling kein angemessener Stellenwert beigemessen. An die Stelle messbarer Kriterien trete zu oft ein diffuses Bauchgefühl bei der Bewertung von Teilergebnissen oder des Projektfortschritts.
Notwendige Akzeptanz der Anwender
Doch selbst wenn ein Projekt technisch im gesetzten Kosten- und Zeitrahmen umgesetzt werden kann, ist der Erfolg noch nicht garantiert. Fehlende Akzeptanz bei den Anwendern ist einer der häufigsten Gründe dafür, dass die Projektziele nicht erreicht werden. In einem solchen Fall wurden das interne Projektmarketing und begleitende Change-Management-Aktivitäten vernachlässigt, um die Anwender von Beginn an zu beteiligen, ihnen den Weg zu neuen Technologien transparent zu machen und ihnen auch ihre eigenen Vorteile zu verdeutlichen.
»Eine klare strategische Zielsetzung, eine genaue Nutzenbeschreibung und eine solide wirtschaftliche Kalkulation sind die Grundpfeiler eines jeden erfolgreichen IT-Projekts auch in der Öffentlichen Verwaltung«, kommentiert Tobias Beckmann, Head of Digital Services Advisory der iTSM Group. »Ein kompetentes Projektmanagement und der Einsatz etablierter Projektmethoden helfen ebenfalls dabei, Fehlentwicklungen und Verzögerungen zu vermeiden. Zudem müssen Test und Rollout sorgfältig geplant und die Anwender konsequent begleitet werden, um eine reibungslose Überführung in den laufenden Betrieb zu gewährleisten.«
Projektmanagement: Das sind die Tricks von agilen Projektsaboteuren
Der Projektleiter fühlt sich degradiert, die Fachabteilung lehnt das Projekt ab, die Entwickler haben keine Lust auf Agilität: agile Entwicklungsprojekte können viele Gegner haben. Avision zeigt auf, wie sie vorgehen, um ein Projekt zu kippen.
Illustration: Geralt Absmeier
»Das kleine Handbuch für den Projektsaboteur« ist inzwischen eine Art Klassiker. Kein Wunder, demonstriert es doch anschaulich, wie Projekte von ihren Gegnern manipuliert werden – und gibt Unternehmen damit eine Art Gebrauchsanweisung an die Hand, um sich davor zu schützen. Dabei bezieht sich das Buch allerdings ausschließlich auf das klassische Projektmanagement. Doch was hier gilt, gilt auch für agile Softwareprojekte: Oft gibt es Akteure, denen das Projekt ein Dorn im Auge ist und die deshalb höchst daran interessiert sind, dass es gegen die Wand fährt.
Das kann das Management der Fach- oder IT-Abteilung sein, dem vom Top-Management oder dem Betriebsrat des Unternehmens ein Projekt aufs Auge gedrückt wurde, dass sie eigentlich gar nicht umsetzen möchten. Oder der bisherige Projektleiter hat durch den Umstieg auf agile Methoden die neue Rolle des Product Owner erhalten, fühlt sich dadurch degradiert und fürchtet einen Machtverlust. Aber auch Entwickler können agile Methoden per se oder das konkrete Projekt als solches ablehnen.
Handelt es sich bei dem Projekt um die Modernisierung einer Legacy-Software, wächst der Kreis der Verdächtigen weiter an. Personen, die mit der Anwendung seit Jahren oder vielleicht sogar Jahrzehnten arbeiten, haben dadurch im Lauf der Zeit oft Exklusivwissen angehäuft und sich einen Expertenstatus im Unternehmen aufgebaut; und darauf will nicht unbedingt jeder einfach wieder verzichten.
Avision, Spezialist für Software Revivals, zeigt auf, wie diese Akteure vorgehen, um ein agiles Projekt abzuschießen:
Management
Product Owner
Will er das Projekt sabotieren, hat es für ihn oberste Priorität, dass die Entwicklungssprints keine zufriedenstellenden Ergebnisse liefern. Das kann er unter anderem so erreichen: sich bewusst vor wichtigen Entscheidungen drücken; gestartete Sprints nicht laufen lassen, sondern sich einmischen und kurzfristige Änderungen verlangen; oder ständig auf immer detailliertere Dokumentationen bestehen. Die Tatsache, dass Scrum dem Product Owner keine Anwesenheitspflicht für Meetings auferlegt, lässt sich prima dafür missbrauchen, einige Zeit abzutauchen; nur um dann hinterher zu sagen: »So hab’ ich mir das aber nicht vorgestellt.«
Entwickler
Einer der effektivsten Hebel für die Entwickler, ein agiles Projekt zu kippen, ist die Schätzung der Story Points, die pro Sprint umgesetzt werden, da sich daraus die Geschwindigkeit eines Sprints ergibt. Werden diese Story Points vor dem ersten Sprint bewusst hoch angesetzt und in den folgenden Sprints immer niedriger, sieht es so aus, als ob die Geschwindigkeit kontinuierlich abnimmt; und beim Management muss zwangsläufig der Eindruck entstehen, dass das Projekt in Schieflage gerät.
Fachabteilung
Für das Backlog, das die zu erledigenden Aufgaben enthält, ist zwar nominell der Product Owner zuständig. Über ihn hat die Fachabteilung aber die Möglichkeit, dort absichtlich immer mehr fachliche Anforderungen einfließen zu lassen. Dasselbe gilt übrigens auch für die Entwickler und ihre technischen Anforderungen. So oder so wächst die Zahl der Backlog-Items dann kontinuierlich an, statt zurückzugehen. Damit lässt sich dem Management signalisieren, dass das Projekt komplett aus dem Ruder läuft und gegen die Wand fahren wird.
»Diese Tricks erheben natürlich keinen Anspruch auf Vollständigkeit. Will jemand ein agiles Projekt scheitern lassen, kann er dafür viele Ansatzpunkte finden«, sagt Nadine Riederer, CEO bei Avision. »Um mögliche Motive für eine Projektsabotage abzuschwächen, sollten Unternehmen sämtliche Beteiligte von Anfang an einbinden und ihnen Perspektiven aufzeigen. Ist erkennbar, dass jemand ein Projekt partout nicht unterstützen möchte, hilft alles nichts: er muss dann davon ferngehalten werden. Nur wer eine Rolle in einem Projekt innehat, kann es auch sabotieren.«