Als die Polizei Niedersachsen Anfang 2001 begann, im Rahmen des Projekts "Mikado-neu" ein modernes IT-System mit dem Namen "Nivadis" zu realisieren, zeichnete sich bereits ab, dass mit erheblichen Schwierigkeiten zu rechnen war. Die Verantwortlichen mussten mit vielen beteiligten Behörden, sowie einer Reihe von externen Dienstleistern kooperieren. Das neue System sollte alle vollzugspolizeilichen Prozesse der Vorgangsbearbeitung, Auswertung und Statistik beinhalten sowie die Nutzung des neuen Fahndungssystems des Bundeskriminalamts (BKA) "Inpol-neu" gewährleisten.
Zu den Herausforderungen zählte unter anderem, dass das erste Nivadis-Release fertig werden musste, bevor das technisch veraltete Vorgangsbearbeitungssystems Mikado-alt ausfiel. Schon 2001 konnte man davon ausgehen, dass dieses System und damit die Polizei Niedersachsens mit Ablauf des Jahres 2003 nicht mehr arbeitsfähig sein würde. Zudem erfüllte das alte Mikado weder die technischen noch die fachlichen Voraussetzungen für einen Anschluss an Inpol-neu, welches zu dieser Zeit vom BKA entwickelt wurde. Aufgrund des Realisierungsstandes in Niedersachen mussten die Verantwortlichen jedoch damit rechnen, dass zu Beginn der Inpol-neu-Einführung das System Nivadis noch nicht so weit entwickelt sein würde, um es daran anzubinden. Niedersachsen trat daher der Bund-Länder-Kooperation Agil (Arbeitsgruppe Inpol-Land) bei, die den zeitgerechten Anschluss der Länder an die Zentralapplikation des BKA sicherstellen sollte.
Die in diesem Rahmen entwickelte Software-Schnittstelle sollte im Projekt Mikado-neu als zeitlich befristete Übergangslösung im Land Niedersachsen bis Ende 2001 eingeführt werden und damit den Zugriff auf das neue Inpol-System gewährleisten.
Durch die enge Verknüpfung zu Agil, Inpol-neu sowie die hohe Ausfallwahrscheinlichkeit von Mikado-alt war das Termin-Management besonders erfolgskritisch. Das Innenministerium hatte deshalb beschlossen, mit Hilfe eines externen Controllers und einer polizeiinternen Controllerin aus dem Verwaltungsbereich Beschaffung eine zusätzliche Sicht auf das Projekt zu schaffen.
Dieses Team nahm zwei Monate nach Projektstart im April 2001 die Arbeit auf. Seine Aufgabe war es, die betriebswirtschaftliche und organisatorische Planung, Steuerung und Kontrolle des Projekts zu begleiten und zu beurteilen. Als die Controller aktiv wurden, waren die Arbeiten bereits in vollem Gange. Daher galt es, zunächst eine kritische Bestandsaufnahme des Projekt-Managements und der schon erreichten Ziele vorzunehmen.
Das Ergebnis der Voruntersuchung war zunächst viel versprechend. Die inhaltliche und organisatorische Steuerung des Projekts konnte als gut bewertet werden. Es verfügte über einen klaren Projektauftrag sowie eine gute Strukturierung in Teilprojekte mit definierten Projektfunktionen und schlüssigem Organigramm. Zudem waren Richtlinien, Standards und Vorgehensweisen fast vollständig. Außerdem existierten Projektpläne und Arbeitspaketbeschreibungen inklusive Plan-Aufwand, Dauer, Ist-Aufnahme und Restaufwandsschätzungen sowie eine Qualitätssicherung.
Problem Risiko-Management
Im Bereich Risiko-Management gab es allerdings erhebliche Schwachstellen. Das Controlling forderte daher, entsprechende Strukturen für die Früherkennung von Problemen einzuführen.
Auch die Kostenplanung erwies sich zu Beginn des Projekts als unvollständig. Die Haushaltsverwaltung und damit auch die Budgetplanung und -überwachung waren außerhalb des Projektes angesiedelt. Dadurch gab es viele Teilprozessverantwortliche, ohne dass die Informationen bei einem Gesamtverantwortlichen zusammenliefen. Somit war es nicht möglich, eine realistische Darstellung der Budgetsituation zu bekommen.
Drohende Mittelüberschreitung
Dadurch drohte permanent die Überschreitung der zugewiesenen Haushaltsmittel. Erst nachdem das Controlling das Problem in den Lenkungsausschuss verwiesen hatte, wurden organisatorische Lösungen erarbeitet und implementiert. Die Gesamtverantwortung für die Haushaltsverwaltung und -beschaffung erhielt daraufhin das Controlling.
Im operativen Bereich stellte das Controlling gleich zu Anfang seiner Arbeit die mangelnde Steuerung des Teilprojekts IT-Infrastruktur und dessen Ressourcenengpass fest. Die zentrale Aufgabe des Teilprojekts bestand in der flächendeckenden Einführung einer Infrastruktur, die die technischen und terminlichen Anforderungen der Projekte Agil, Inpol-neu und des eigenen Projekts Mikado-neu erfüllen musste. Dazu zählte unter anderem die Bereitstellung von dezentralen Servern, eines zentralen Rechenzentrums und von Sicherheitslösungen.
Unstimmige Planung
Die Analyse des Controllings ergab, dass die einzelnen Arbeitspakete teilweise so definiert waren, dass logisch-funktionale Abhängigkeiten nicht erkannt und berücksichtigt werden konnten. Die gesamte Planung war unstimmig und größtenteils nicht nachvollziehbar. In der Konsequenz litt das Projekt an einer geringen Lösungsreife. Die engen Terminvorgaben seitens des BKA zwangen zudem das Teilprojekt Infrastruktur, entsprechende Lösungen sehr schnell aufzusetzen. Dadurch entstanden offene Baustellen mit enormen Nacharbeiten. Das änderte sich erst, nachdem sich das Teilprojekt auf die zu erstellende Systemlandschaft konzentrierte und diese in Test-, Referenz-, Pilot- und Produktivsysteme unterteilte. Damit wurde ein Steuermechanismus eingeführt, welcher die Abhängigkeiten einzelner Arbeitspakete offenlegte und den Kommunikations- und Problemlösungsdruck förderte. Statt einzelne Gewerke parallel zu produzieren, mussten sie nun im Verbund funktionieren.
Die bisherige Planung der gesamten Projektgruppe orientierte sich strategisch an den Terminen des BKA. Beim Projekt Agil wurden weder Termine noch Qualitätsanforderungen eingehalten. Diese Probleme belegten erhebliche Ressourcen innerhalb des Projekts Mikado-neu, was dort zu einer angespannten Situation führte. Die weitere Verschiebung von Terminen seitens des BKA stellte die gesamte strategische Ausrichtung in Frage. Eine Inpol-Ver- sion für das Einpflegen von Daten wurde auf praktisch unbestimmte Zeit verschoben, die für die Datenabfrage entwickelten Clients liefen nicht stabil. Letztendlich empfahl das Controlling, das Projekt strategisch neu auszurichten. Die Projektgruppe entschied nach umfangreicher Analyse, nicht weiter auf Agil zu warten und stattdessen eine Direktanbindung an Inpol-neu selbst zu entwickeln.
Der Entwicklungsbereich, der die Vorgangsbearbeitungssoftware Nivadis erstellte, verfügte über eine hervorragende Infrastruktur. Dort waren die Prozesse, Methoden und eingesetzten Tools gut strukturiert und implementiert. Lediglich die Anforderungsanalyse verursachte erhebliche Verzögerungen. Für sie fehlte ein effektiver Regel- und Entscheidungsprozess. Die daraus entstandenen Divergenzen und Inkonsistenzen erhöhten den Nachbearbeitungs- und Rückkopplungsaufwand. Statt die Management-Prozesse zu verbessern, wurden geplante Inhalte in andere Versionen verschoben. Dadurch verzögerte sich der interne Fertigstellungstermin des Systemmodells immer weiter, bis die Situation Ende 2002 untragbar wurde und offizielle Meilensteintermine verschoben werden mussten. Das Controlling hatte frühzeitig auf diesen Missstand aufmerksam gemacht und kritisierte kosmetische Reparaturen, die die eigentlichen Ursachen nicht beheben konnten.
Trotz des gut strukturierten Entwicklungsprozesses gab es zudem große Verzögerungen bei der Entwicklung von Formularen. Es fehlten genaue Spezifikationen und damit auch die Möglichkeit, Tests und Qualitätssicherungen vorzunehmen. Somit bildete sich ein großer Bugfixing-Aufwand, der erst sehr spät erkannt wurde.
Nivadis sollte Ende 2002 mit dem Produktionsbetrieb beginnen. Das System ist auf eine zentrale Betriebsorganisation ausgerichtet. Nivadis muss also unter Rechenzentrums-Bedingungen betrieben werden. Ende 2001 warnte das Controlling bereits davor, dass die Personalausstattung der Polizei eine Übernahme des Betriebs von Nivadis-Komponenten kaum zulässt. Das Anfahren und der Betrieb eines hochverfügbaren Systems dieser Größe und Komplexität benötigt eine lange Vorlaufzeit und stellte ein großes Risiko dar. Als Gegenmaßnahme richtete die Projektleitung daraufhin eine Stabsstelle "IT-Betrieb" ein, die die Betriebsübergabe zwischen allen Beteiligten koordinierte und ein IT-Betriebskonzept erstellte. So gelang es, die Probleme organisationsübergreifend weitgehend zu beseitigen.
Ein Jahr Verzögerung
Letztendlich hatte das Projekt eine Verzögerung von einem Jahr. Trotz der längeren Dauer gelang es, unterhalb des Budgets zu bleiben. Dies lag vor allem an Einsparungen bei der Hard- und Softwarebeschaffung, dem Einsatz von Linux als Betriebssystem und dem Wegfall der für das BKA fälligen Kosten. Die erste Nivadis-Version konnte eingeführt werden, bevor das alte System komplett zusammenbrach. (rg)