Projektmanagement | IT-Projekte

Systembedingt! IT-Verbundprojekte von Bund und Ländern und ihr hohes Risiko zum Scheitern (1)

21. Oktober 2013 | Von | Kategorie: IT-PROJEKTE

20% aller IT-Projekte scheitern. Steigt die Komplexität, sind es schon mehr als 40%. Entsprechende Untersuchungen werden in Europa und den Vereinigten Staaten seit rund 20 Jahren angestellt. Eine Verbesserung der Werte ist jedoch nicht in Sicht. Doch warum enden so viele IT-Projekte mit dem totalen Misserfolg?! Viele Praktiker, Projekt-Manager, Berater, oder auch Trainer sind dieser Frage nachgegangen. Geben Sie „Warum IT-Projekte scheitern“ in einer Suchmaschine ein und Sie werden eine Fülle von mitunter sehr lesenswerten Artikeln finden.

Das Scheitern von IT-Projekten hat nicht zuletzt immense wirtschaftliche Auswirkungen: Denn einerseits wird für Projekte, die letztlich Schiffbruch erleiden, jährlich allein in Deutschland ein dreistelliger Millionenbetrag vergeudet. Und andererseits trifft der Fehlschlag auch das Unternehmen oder die Behörde, weil die Ziele nicht erreicht werden, die mit dem jeweiligen Projekt angestrebt worden waren. Beispiele gefällig?! Die elektronische Gesundheitskarte Elena [1], das Bundeswehr-Projekt Hercules [2], das polizeiliche Informationssystem Inpol-Neu [3], das Mautsystem Toll Collect [4] oder Fiscus, das Projekt zur Standardisierung der Finanzverwaltungen [5]; zusammen haben sie zwischen zwei und drei Milliarden Euro verschlungen.

Das Scheitern von IT-Projekten hat daher auch Wissenschaftler beschäftigt. Ein Fachmann auf diesem Gebiet ist Prof. Leon Kappelman von der University of Northern Texas, der u.a. das Weiße Haus und die Vereinigten Nationen auf diesem Gebiet berät. Er hat zusammen mit seinen Kollegen Robert McKeeman (Harvard University) und Lixuan Zihang (Charleston School of Business and Economics) schon 2006 eine Bundesregierung zieht Schlussstrich – Projekt Elena gescheitert, in der die häufigsten Risikofaktoren für das Scheitern von IT-Projekten identifiziert und bewertet werden.

Nun sind gescheiterte IT-Projekte – bzw. solche, deren Scheitern mühsam kaschiert wurde – auch in der deutschen Polizei keine Seltenheit. Inpol-Neu-Neu ist jedem geläufig, der sich mit dem Thema beschäftigt, auch die Einführung des Behördendigitalfunks BOS [, obgleich nicht nur ein IT-Projekt, ] ist ein nicht gerade rühmlicher Fall. Und im Projekt für den Polizeilichen Informations- und Analyseverbund PIAV gab es, obwohl er sich noch in einer frühen Pilotphase befindet, bereits mehrfach Verzögerungen und Umdefinitionen des Projektziels [siehe dazu unseren Beitrag ‚Neues vom PIAV (2)‘ ]

Wir wollen in diesem Artikel der Frage nachgehen, ob es Besonderheiten bei den Bund-Länder-Verbundprojekten der deutschen Polizeibehörden gibt, die das Scheitern des Gesamtprojekts begünstigen, ob also das Scheitern sozusagen systembedingt ist. Dabei orientieren wir uns an den zwölf Risikofaktoren, die Kappelman und seine Kollegen als die wichtigsten Risikofaktoren für das spätere Scheitern von IT-Projekten ausgemacht haben:

  1. Fehlende Unterstützung durch das Top Management
  2. Schwächen beim Projekt-Management
  3. Wesentliche Beteiligte sind nicht involviert bzw. beteiligt
  4. Team-Mitglieder unzureichend engagiert für das Projekt
  5. Den Team-Mitgliedern fehlt es an Wissen, Fertigkeiten und Erfahrungen
  6. Fachliche bzw. technische Experten sind überlastet
  7. Fehlende Dokumentation und/oder Definition, was den Erfolg des Projekts ausmacht
  8. Kein Verfahren für den Umgang mit Änderungsanforderungen
  9. Fehlende oder uneffektive Zeit- und Ressourcenplanung
  10. Ab- oder Zusammenbruch der Kommunikation zwischen den Projektbeteiligten
  11. Dem Projekt zugewiesene Ressourcen werden abgezogen für Aufgaben mit höherer Priorität
  12. Der wirtschaftliche Nutzen des Gewinns ist nicht definiert und dokumentiert

IT-Projekte scheitern nicht an mangelhafter Technik

Es fällt auf an dieser Liste, dass es nicht technische Gründe sind oder das Versagen von IT-Fachleuten, Systementwicklern und Programmierern, was IT-Projekte zum Scheitern bringt. Solche Ursachen kommen vielmehr überhaupt nicht und zwar weder in den zwölf Faktoren mit dem höchsten Risiko des Scheiterns, noch in den 53 insgesamt identifizierten Faktoren: Mangelhafte Technik oder Beherrschung der Technik ist es also nicht, was IT-Projekte zum Scheitern bringt.

Sämtliche wesentlichen Risiken für das Scheitern von IT-Projekten liegen vielmehr

  • entweder bei den Menschen, die das Projekt entscheiden, steuern und durchführen
  • bzw. bei den dabei (mangelhaft) angewendeten Prozessen bzw. Verfahren

Meist treffen mehrere Faktoren zusammen.

Was macht ein IT-Verbundprojekt des Bundes und der Länder aus?

Die Komplexität von IT-Projekte wird ausgedrückt durch die Anzahl der kleinsten, für den Anwender sinnvollen Aktivitäten, den so genannten Elementarprozessen. Der Aufwand für jeden einzelnen Prozess wird durch einen ein- oder mehrstelligen Punktwert ausgedrückt, die so genannten „function points“. Projekte mit einer Gesamtkomplexität von mehr als 10.000 function points gelten als IT-Großprojekte.

Wir beschäftigen uns in diesem Artikel mit IT-Verbundprojekten des Bundes und der Länder in Polizeibehörden. Beispiele aus der Vergangenheit sind Inpol-Neu (mit AGIL) oder Inpol-Neu-Neu, mit dem das gescheiterte Inpol-Neu/AGIL-Projekt aufgefangen wurde. Auch das GED-Projekt (Gemeinsame Ermittlungsdatei im Staatsschutz) geht in diese Richtung, besonders aber das aktuell entstehende Projekt PIAV – der Polizeiliche Informations- und Analyseverbund.

IT-Verbundprojekte des Bundes und der Länder sind mit einem IT-Großprojekt auf eine Stufe zu stellen. Neben einer vergleichbaren Komplexität weisen sie jedoch noch einige sonstige Besonderheiten auf, die zu einer weiteren Erhöhung des Projektrisikos führen. Und, wie gesagt: Schon bei den „einfachen“ IT-Großprojekte scheitern 4 von 10 komplett! Hier sind diese spezifischen Besonderheiten:

  • Bund-Länder-IT-Projekte haben die Aufgabe, ein IT-Gesamtsystem zu entwickeln und in Betrieb zu nehmen, das aus einem Verbund einzelner Teilnehmersysteme besteht und dessen Funktionieren und Zielerreichung bestimmt wird durch den Leistungsbeitrag der einzelnen Teilnehmersysteme.
  • In der Projektphase handelt es sich um „Multiprojekte“, bei denen die Projekte der einzelnen Projektteilnehmer zeitlich, fachlich, organisatorisch und wirtcshaftlich aufeinander abgestimmt geplant, durchgeführt und zeitgerecht abgeschlossen werden müssen.
  • Teilnehmer verpflichten sich auf das (meist nicht sonderlich konkret definierte) Projekt-Gesamtziel nur aufgrund freiwilliger Basis. Rechtlich oder wirtschaftlich wirksame Sanktionen zur Durchsetzung des Beitrags eines Teilnehmerprojektes existieren nicht.
  • Jeder Projektteilnehmer ist für die Planung, Durchführung, Finanzierung und den fristgerechten und erfolgreichen Abschluss seines Teilprojekts selbst verantwortlich.
  • Es existiert keine Projektleitung, die allen Projekten übergeordnet wäre und für die jeweiligen Teilnehmerprojekte entscheidungs- bzw. weisungsbefugt bzw. sanktionsberechtigt wäre.

Ein Abgleich der von Kappelman seinen Kollegen identifizierten wesentlichen Risiken für das Scheitern von IT-Projekten mit den gerade genannten besonderen Merkmalen von Bund-Länder-IT-Projekten wird zeigen, dass diese ganz besonders anfällig dafür sind zu scheitern. Man könnten sogar sagen:Das Scheitern ist im System schon angelegt!

Risiko Mensch

Das Top Management

Fehlende Unterstützung durch das Top Management: Dieses Risiko steht ganz oben auf der Liste – übrigens auch in anderen einschlägigen Untersuchungen.
Übertragen auf Bund-Länder-IT-Projekte der Polizei stellt sich allerdings die Frage, wer hier eigentlich das „Top Management“ ist.

Top Management für das Gesamtprojekt

Eine „oberste Ebene in der Projekthierarchie“ existiert nicht, was darin liegt, dass ein Bund-Länder-Verbundprojekt keine festgefügte Organisation (und Infrastruktur) hat. Ein solches Projekt ist vielmehr ein (doch ziemlich loser) Zusammenschluss von teilnahmewilligen Partnern, vergleichbar mit einer Arbeitsgemeinschaft. Über die Teilnahme, ihre Art, Ausstattung und Priorität (gegenüber anderen, zeitgleich laufenden Projekten) entscheidet jeder Teilnehmer selbst. Leistungen gegenüber dem Gesamtprojekt werden auf letztlich freiwilliger Basis erbracht – vom Gruppendruck der anderen Teilnehmer bzw. politischem Druck zur Teilnahme einmal abgesehen.

Wie bei einer Arbeitsgemeinschaft kann man sich in einem Projekt auf einen „Leitungskreis“ verständigen. Dieser ist jedoch nicht in der Lage, die Entscheidungen des Leitungskreises in die Teilprojekte aller Projektpartner hineinzutragen und dort auch durchzusetzen. Es fehlt an der Weisungsbefugnis genauso, wie an Durchsetzungs- und Sanktionsmöglichkeiten.

Auch das BKA als „Primus inter Pares“ aufgrund seiner gesetzlichen Zentralstellenfunktion hat keine Möglichkeiten, in die Teilprojekte der Teilnehmer „hineinzuregieren“, dort zu unterstützen oder Entscheidungen zu forcieren.

Die Konferenz der Innenminister (IMK), die sich zweimal jährlich trifft und dabei entsprechende Empfehlungen ausspricht, kann die Funktion eines Top Managements nicht ausfüllen. So wird zum Beispiel schon an der Wortwahl ihrer Beschlüsse zu PIAV aus dem Dezember 2012 deutlich, dass es sich dabei um nicht mehr handeln kann als einen (unverbindliche) Beschluss über einen gemeinsamen Nenner von Einschätzungen („Die IMK nimmt … zur Kenntnis“ | bekräftigt, dass … erforderlich ist | „stellt fest, dass die Konzeption eine belastbare Grundlage für eine Kostenschätzung darstellt und wesentlich für eine Realisierungsentscheidung ist“ | „… begrüßt, dass ein stufenweiser Ansatz gewählt wird …“ [wer hat den beschlossen??] …“) , sowie um und höfliche Appelle („… bittet den Bund und die Länder …“).
Wirkliche Entscheidungen eines Top Managements und Verfügung zu deren Umsetzung sähen anders aus!

Dass auch der Bundesinnenminister keine entsprechenden Befugnisse und Vollmachten hat, den Ländern Vorgaben zu machen, sei nur der Vollständigkeit halber erwähnt.

Aus der föderalen Struktur der Polizeibehörden in der Bundesrepublik, die übernommen wird auf die Projektorganisation solcher Bund-Länder-Projekte ergibt sich somit zwangsläufig, dass ein entscheidungsbefugtes, geschäftsführendes, verantwortliches und das Projekt nach außen vertretendes Top Management für das Gesamtprojekt nicht existiert und somit dem Gesamtprojekt von dieser Seite auch keine Unterstützung zuteil werden kann.

Top Management für jedes Teilprojekt

Teilprojekt ist, was der einzelne Projektpartner in eigener Regie und eigener Verantwortung, sowie (i.d.R. bzw. weitgehend) auf eigene Kosten rechtzeitig zum Gesamtprojekt beizutragen hat. Vom Sonderfall des BKA als Primus Inter Pares einmal abgesehen, sind also die Bundesländer, sowie die Bundespolizei die Teilprojekt-Partner.

Rein formell ist das Top Management der Länder-Projektpartner im jeweiligen Innenministerium zu verorten. Uneinheitlich und in manchen Ländern auch nicht ganz klar ist allerdings, wer tatsächlich die Entscheidung trifft: Ist es der Innenminister? Der zuständige Staatssekretär? Der Leiter der Polizeiabteilung? Oder der Referatsleiter für Informationstechnik im Innenministerium? Ist es der Direktor des Landeskriminalamts? Der Polizeipräsident bzw. Leiter aller Polizeibehörden im Land? Oder liegt das Top Management faktisch weder im Ministerium noch bei der Polizei, sondern bei dem (in jedem Land vorhandenen) zentralen IT-Beschaffungs- und Dienstleistungsbetrieb?

Die Aufzählung macht bereits deutlich, dass die politische Ebene, in der Praxis vor allem jedoch die Ministerialbürokratie aus dem Innenministerium Kandidat ist für das „Top Management“ eines Bund-Länder-IT-Projekts. Allerdings ist es eher nicht üblich, dass sich ein Mitglied der Ministerialbürokratie in die Niederungen des Projektmanagements begibt. Solche Aufgaben werden dann doch vorzugsweise delegiert. Das Ministerium wird also einen Erlass schreiben (siehe unten) und steht somit als „das Top Management“ für das Bund-Länder-IT-Projekt im jeweiligen Land allenfalls zur Außenvertretung gegenüber anderen Projektpartnern zu Verfügung. Mit der tatsächlichen Arbeit wird die hierarchisch unter dem Ministerium angesiedelte oberste Polizeibehörde beauftragt bzw. der auf vergleichbarer Hierarchiestufe im Geschäftsbereich des Ministeriums angesiedelte IT-Dienstleister und -Beschaffer.

Im Tagesgeschäft haben diese drei Funktionsbereiche – Ministerium, Polizeibehörde und IT-Dienstleister) allerdings ständig miteinander zu tun. Das Ministerium schafft an, der IT-Dienstleister und -Beschaffer hat zu leisten, die Polizei ist der Kunde, von der das Ministerium die Umsetzung der sicherheitspolitischen Vorgaben erwartet. Man kennt sich auf den entsprechenden Ebene, es existieren zahlreiche Berührungspunkte, vielfältige gegenseitige Abhängigkeiten; Und außerdem hat jeder Bereich seine eigenen Interessen und herrscht auf manchen Gebieten, wie z.B. um die fachliche Deutungshoheit oder um gute Mitarbeiter, auch deutlicher Wettbewerb.

Für ein erfolgreiches Bund-Länder-IT-Projekt müssten alle drei Bereiche all dies ausblenden und für die Zwecke und Interessen des gemeinsamen Projekts über einen längeren Zeitraum einmütig zusammenarbeiten, salopp gesagt „an einem Strick“ ziehen. Und es müsste der Funktionsbereich, der im Landes-Teilprojekt die Rolle des faktischen Projektführers zugewiesen bekommen hat, vorbehaltlos unterstützt werden von den beiden anderen Funktionsbereichen. Er müsste also über die sonst bestehenden Grenzen der Behörden hinweg Weisungen in den anderen Bereich hinein erteilen können und aus dem jeweiligen Bereich Ressourcen requirieren können. Für jeden, der den Ablauf in großen Behörden kennt, steht vor Augen, dass dies nicht funktionieren kann und wird.

Wie sieht dagegen die Praxis aus?! Der Startschuss für das Teilprojekt in einem Land fällt mit der Zustimmung des Landes-Innenministers in der relevanten Sitzung der Innenministerkonferenz. Dort hat er sich für das Land verpflichte. In Folge ergeht aus dem Ministerium ein Erlass mit dem Auftrag an Polizei oder IT-Dienstleister, die Federführung im Projekt zu übernehmen und das Projekt umzusetzen. Der nicht federführende, andere Part hat per Erlass den anderen Bereich zu unterstützen. Berichte an das Ministerium sind in regelmäßigen Abständen zu erstatten. Ansonsten bleibt es weitgehend dem nunmehr beauftragten Projektführer überlassen, wie er diese Aufgabe anpackt und umsetzt. Auch wie sich die beiden Funktionsbereiche nun zusammenraufen, bzw. ob überhaupt, bleibt allein den beiden überlassen. Ministerien mögen es nicht, wenn der eine über den anderen „petzt“.

Von einem Top Management für das Landes-Teilprojekt kann dennoch nicht gesprochen werden. Denn egal, wer die Projektführung zugewiesen bekam. Er ist auf den Goodwill des zweiten Funktionsbereichs angewiesen, ihn bei seinen Projektaufgaben zu unterstützen. Entscheidungen treffen kann der nominale Projektleiter zwar, allein fehlt es ihm an der Befugnis und Macht, diese Entscheidungen auch umzusetzen / zu erzwingen bzw. bei Nicht-Einhaltung Sanktionen auszusprechen – zumindest im Bereich des zweiten Funktionsbereichs. Und da Polizei mit dem IT-Dienstleister und umgekehrt der mit seinem „Kunden Polizei“ auch anderweitig gut auskommen muss, wird man Reibereien wegen eines temporären Bund-Länder-Projekts eher zurückstellen, um die Zusammenarbeit im Tagesgeschäft nicht dadurch zu beeinträchtigen.

Es bleibt somit bei der Feststellung: Ein Top Management, das bereit und in der Lage wäre, ein Bund-Länder-IT-Projekt auf Landesebene mit der notwendigen Tat- und Durchsetzungskraft zu unterstützen, existiert nicht. Der wesentliche Risikofaktor für das Scheitern von IT-Projekten – die fehlende Unterstützung durch das Top Management – ist also sowohl im Gesamtprojekt, als auch in den Länder-Teilprojekten sozusagen „systemisch“ angelegt und damit verwirklicht.

____________________________________________________________________________________________________________________________________________

Dieser Beitrag ist Teil der Serie …

Systembedingt! IT-Verbundprojekte von Bund und Ländern und ihr hohes Risiko zum Scheitern
Bisher erschienene Beiträge
Teil 1 am 21.10.2013
Teil 2 am 22.10.2013
sowie ergänzend dazu Bund der Steuerzahler: Warum Großprojekte scheitern oder viel zu viel Geld verschwenden

Quellen zu diesem Beitrag

[1] Milliarden-IT-Projekt Hercules wird zum Debakel, Bild, 19.07.2011
[2] Milliarden-IT-Projekt Hercules wird zum Debakel, Handelsblatt 27.04.2010
[3] Toll Collect: Eine deutsche Blamage, SpiegelOnline, 28.05.2001
[4] Toll Collect: Eine deutsche Blamage, ZeitOnline, 19.02.2004
[5] Early Warning Signs of IT Project Failure: The Dominant Dozen, CIO, 5.01.2006
[6] Early Warning Signs of IT Project Failure: The Dominant Dozen, Fall 2006, Kappelman, McKeeman, Zhang

Schlagworte: , , , , , , , , ,

Schreibe einen Kommentar