Das steht im Teil 1 dieses Artikels:
20% aller IT-Projekte scheitern. Steigt die Komplexität, sind es schon mehr als 40%. 12 Risikofaktoren sind besonders fatal für das Scheitern von IT-Projekten. Und gerade die so teuren und wichtigen IT-Verbundprojekte des Bundes und der Länder (für Polizeibehörden) weisen – systembedingt – genau diese Faktoren auf. Es beginnt mit dem Risikofaktor Nr. 1: Einem zu Entscheidungen befähigten und zu Weisungen gegenüber den Teilprojektpartnern befugten Top Management.
Lesedauer: Ca. 8 Minuten
Der Projektmanager
Wen das Verdikt auch getroffen haben mag: IT-Dienstleister oder Polizeibehörde. Innerhalb der projektführenden Behörde wird nun ein Projektmanager bestimmt.
Der ideale Projektmanager
An der Praxis vorbei ginge die Vorstellung, dass ein Mitarbeiter, frisch und motiviert, sachkompetent und projekterfahren, kommunikativ und gut vernetzt, familiär ungebunden und erpicht darauf, viele Montage und Freitage auf dem Weg zu und von gemeinsamen Bund-Länder-Projektbesprechungen auf der Autobahn zu verbringen, dass also ein solcher Mitarbeiter vorhanden ist und der aktuell auch nichts anderes zu tun hat und nur darauf gewartet hat, zum verantwortlichen Projektmanager für das neue Projekt gemacht zu werden.
Dieser Fall ist schon deshalb hochgradig unwahrscheinlich, weil alle Polizeiorganisationen der Bundesländer mittendrin sind in der Umsetzung ihrer Personalabbaupläne. Wer also als Projektmanager (PM) überhaupt in Frage kommt, ist froh, dass er den aktuellen Job hat [der kein Job im Polizeivollzugsdienst ist!], den möchte er/sie auch behalten und hat daher auch bisher schon – also ohne zusätzliches Projekt – gut zu tun.
Einbindung in die AAO und Hierarchie
Dieser Kandidat kriegt nun also auch noch das neue Bund-Länder-Projekt übergestülpt. Gefragt wird er in der Regel nicht … Auftraggeber ist jemand relativ hoch droben in der Hierarchie der Polizeibehörde oder des IT-Dienstleistungsbetriebs, ein Boss, mit dem der neu ernannte Projektmanager auch anderweitig noch zu tun hat. Oder, um im Polizeijargon zu sprechen: „In der AAO, der Allgemeinen Aufbauorganisation„. Solche Projektmanager-Jobs pflegen in vielen Bundesländern als „Zugleichaufgaben“ vergeben zu werden, anders ausgedrückt: Sie entsprechen einem zeitweiligen (und teilzeitigen) zusätzlichen Arbeitsauftrag zur Mitarbeit in einer BAO – einer Besondere Aufbauorganisation, also einer Art von „Sonderkommission“ neben dem normalen Aufgabenbereich. Abgesehen von der Mehrfachbelastung, die jeder nachvollziehen kann, der im Job mehrere Aufgaben gleichzeitig (und gleich gut) bearbeiten soll, liegt hier auch ein systemisches Konfliktpotenzial: Nämlich in der Abhängigkeitsbeziehung zwischen dem Projektmanager und seinem Auftraggeber, der meist auch sein Vorgesetzter ist:
Unser PM wird daher danach bestrebt sein, den Erwartungen seines Vorgesetzten im Rahmen der AAO zu entsprechen, also zunächst einmal seinen „eigentlichen“ Job gut zu machen, das ist der, der in seiner Stellenbeschreibung steht. Er wird sich orientieren an den Prioritäten, die sein Vorgesetzter setzt: Wenn es dessen oberstes Ziel ist, die Aufklärungsquote für die Kriminalstatistik des laufenden Jahres zu erhöhen, wird unser PM sich daran orientieren. Wenn er beim polizeilichen IT-Dienstleister arbeitet und der Boss die Erhöhung der Kundenzufriedenheit zum Ziel erklärt hat, wird unser PM vorrangig daran arbeiten. Das ist nachvollziehbar und menschlich.
Es wäre ungewöhnlich, wenn ein Bund-Länder-IT-Projekt in einem Land mehr Priorität und die notwendigen Ressourcen erhalten würde, als die Aufgaben der normalen AAO. Bund-Länder-IT-Projekte kommen erfahrungsgemäß dann an die Reihe, wenn alle AAO-Aufgaben erledigt sind bzw. kurz bevor es im Projekt lichterloh brennt und Beschwerden von dritter Seite zu befürchten sind.
Denkbar wäre allenfalls, dass sich ein Land durch herausragende Leistungen in einem solchen Projekt gegenüber den anderen Projektteilnehmern profilieren möchte. Obwohl theoretisch denkbar, handelt es sich um ein Vorkommnis, das seit der Jahrtausendwende meiner Übersicht nach an den Fingern einer Hand abzuzählen war.
Somit steht für den neu ernannten PM nunmehr fest: Er muss seinen bisherigen Job mindestens so gut machen, wie bisher. Den neuen Job als Projektmanager muss er auch noch machen – irgendwie. Und wie er Frau und Kindern klar macht, dass der Mann und Papa (=Beamter, mindestens im gehobenen Dienst) Überstunden machen und viele Wochen auf Reisen sein muss – das ist ausschließlich sein Problem.
Die beschriebene Situation und Motivlage für unseren Projektmanager macht deutlich, dass auch der zweitgrößte Risikofaktor für IT-Projekt, nämlich ein Projektmanager mit Schwächen, sich aus dem „System“ ganz zwangsläufig ergibt. Fälle, in denen dieses Risiko erkannt und bewusst vermieden worden wäre, sind bisher nicht bekannt. Alle Landes-Projektmanager arbeiten mehr oder minder unter den gleichen, unbefriedigenden Bedingungen.
Der Projektmanager als Führer des Projektteams
Einmal abgesehen von den gerade beschriebenen Problemen, die sich aus der inneren Struktur der projektführenden Organisation ergeben: Eigentliche Aufgabe des Projektmanagers ist es ja, nach außen zu wirken, sein Projektteam zu bilden zu formen, zu führen und zur zeitgerechten Erledigung der Aufgaben zu bringen.
Eine noble und anspruchsvolle Aufgabe! Leider sind Ausstattung und Vollmachten, die man dem PM für diese Aufgabe mitgibt, der Aufgabe im Projekt in keiner Weise angemessen: Ein wesentliches Problem besteht darin, dass das Projektteam (, dem der PM vorsteht,) Leistungen erbringen muss, der PM jedoch nicht dienstlicher Vorgesetzter oder fachlich weisungsbefugt ist gegenüber den Mitgliedern seines Teams. Hier kann er seine „Führungsqualitäten“, Kommunikationsfähigkeiten oder „social skills“ zwar trainieren. Es wird dennoch immer wieder vorkommen, dass abgesprochene Zuarbeiten von einem Teammitglied nicht rechtzeitig angeliefert werden, weil dieses Mitglied Aufträge mit höherer Priorität von seinem Vorgesetzten erhalten hatte, dass lang vereinbarte Team-Besprechungen zum Kaffeekränzchen im kleinen Kreis verkümmern, weil Team-Mitglieder aus der Fachabteilung just an diesem Morgen zu einem Einsatz abkommandiert wurden, oder Teammitglied Dieter oder Katja ausfallen, weil das Kleinkind zum Arzt muss.
Da Vollmachten und Ressourcen nicht klar und „einklagbar“ zugewiesen sind, ist Projektmanagement unter den beschriebenen Bedingungen eigentlich ein Himmelfahrtskommando. Dass dennoch relativ viel erreicht wird, ist [meiner Einschätzung nach] der überdurchschnittlich hohen Kollegialität – auch länderübergreifend – unter Polizeibeamten zu verdanken. Wieviel mehr allerdings zu erreichen wäre, wenn man Projektmanager mit angemessenen Vollmachten und die -Teams mit angemessenen Ressourcen ausstatten würde, ist gar nicht abzusehen.
Die Mitglieder des Projektteams
Für solche Projekte wird immer mindestens ein Projektteam gebildet. Das hat einerseits etwas damit zu tun, dass mehr Arbeit zu erledigen ist, als ein einzelner (z.B. der PM) allein bewältigen kann. Es hat zweitens damit zu tun, dass die fachliche oder technische Expertise von Fachleuten aus der Organisation einbezogen werden soll. Es hat aber drittens und vor allem auch damit zu tun, dass Verantwortung verteilt werden soll. Je mehr Dienststellen / Behördenbereiche durch Team-Mitglieder vertreten sind, desto mehr verteilt sich die Verantwortung und liegt nicht mehr beim PM allein, bzw. seinem Behördenbereich und auf den Schultern des Leiters dieses Bereichs. Und das kann wichtig werden, vor allem, wenn sich das Problem nicht so entwickelt, wie es sich alle zu Beginn wünschen.
Dass ein entsprechendes Projektteam gebildet wird und welche Behördenbereiche daher mit „an Bord genommen“ werden, ist meist die Entscheidung der politischen Ebene. Der Erlass aus dem Innenministerium, mit dem das Projekt gestartet wurde, enthält dazu i.d.R. die entsprechenden Details.
Wie man Mitglied des Projektteams wird
Die Verfügung zur Bildung des Projektteams kommt also von oben und sie trifft die Leitung des entsprechenden Behördenbereichs. Erneut von oben trifft es den einzelnen Menschen, den seine Organisation auserkoren hat als Vertreter im Projektteam zu wirken. In Grenzen wird er/sie sich wehren können, z.B. mit Verweis auf Unabkömmlichkeit bei den aktuell wahrgenommenen Aufgaben. Irgendeine(n) trifft es jedoch. Und die Frage, ob er oder sie befähigt ist oder sich ausreichend qualifiziert fühlt oder Interesse für die Sache aufbringen kann, wird weder gestellt, noch wird Rücksicht genommen auf die Antwort. Es soll schon vorgekommen sein, dass sich in solchen Projektteams vorzugsweise solche Mitarbeiter finden, die in der AAO ihrer jeweiligen Dienststelle noch am leichtesten zu entbehren waren.
Ab und zu gibt es auch das hochmotivierte Team-Mitglied, jemanden, der freiwillig und gerne im Projektteam mitarbeitet. Da liegt ein Fall von echtem Engagement oder Gestaltungswillen für die Sache vor, die im Bund-Länder-IT-Projekt behandelt wird. Und mitunter soll auch die Aussicht auf regelmäßige Dienstreisen in andere Bundesländer bzw. Treffen mit Kollegen aus anderen Ländern das persönliche Engagement befördern.
Einfluss über die Team-Mitglieder auf das Projekt
Was für den Projektmanager gesagt wurde, gilt in gleicher Weise für jedes Team-Mitglied. Er/sie ist in erster Linie seiner Dienststelle und deren Vorgesetzten gegenüber verpflichtet. Und selbstverständlich wird dort darüber berichtet, was sich im Projekt so tut, bzw. was nicht: Es wäre weltfremd anzunehmen, dass Vorgesetzte aus der AAO / Heimat-Dienststelle nicht über ihren jeweiligen Vertreter im Projektteam (, denn als solcher wird er/sie betrachtet,) Einfluss nehmen würden auf Entscheidungen, den weiteren Verlauf bzw. Ressourcen-Einsatz. Und der Vorgesetzte, dem das Ganze überhaupt nicht passt, hat beste Möglichkeiten, seine „Ressource“, d.h. das Team-Mitglied, anderweitig zu beschäftigen oder an der Teilnahme an Projekt-Veranstaltungen zu hindern. So lässt sich effektiv Projektarbeit gestalten, ohne selbst in irgendeiner Weise in Erscheinung zu treten.
Kenntnisse und Fähigkeiten, die ein Team-Mitglied mitbringen sollte
Es sind die Team-Mitglieder, die die Arbeit im Projekt zu leisten haben. Dazu gehört Fachwissen, meist als Polizist bzw. Techniker, mitunter auch aus Sozialwissenschaft, Betriebswirtschaft oder Jurisprudenz. Zusätzlich braucht jedes Team-Mitglied zumindest Basiskenntnisse aus dem Projektmanagement, Verwaltungspraxis und eine gehörige Portion an social skills und Kommunikationsfähigkeiten. Denn bei Team-Arbeit geht es auch um das Verstehen und sich Verständlich-Machen, um Kompromisse und gemeinsame Ergebnisse.
In großen IT-Projekten werden Projektmanagement-Standards verwendet, nur wenig bekannt ist, dass das DIN-Institut eigene Normen für Projektmanagement erlassen hat. In der DIN-Norm 69001-5 sind zum Beispiel die im Projektmanagement verwendeten Begriffe definiert. Ähnliche Standardisierungen gibt es von der ISO – der International Standardization Organisation.
Damit soll gesagt sein: was im Projektmanagement zu leisten ist und worüber man spricht, ist national und international normiert und standardisiert und daher eigentlich nicht den ‚kreativen Interpretationsspielräumen‘ einzelner Mitglieder des Projektteams überlassen, z.B. darüber, was ein Lastenheft ist oder wie eine Vorstudie zu gestalten ist.
Phasen und Teilergebnisse jedes IT-Teilprojekts werden mit den Projektpartnern aus anderen Ländern und Bundesbehörden abgestimmt. Art und Umfang von Ergebnisdokumenten (engl. deliverables genannt), die am Ende der Teilleistungsabschnitte zu erstellen sind, sind gemeinsam festgelegt. Eine Zeitplanung mit Meilensteinen ist üblich und sinnvoll, ebenso die Kostenplanung, sowie Zeit- und Kostenkontrolle. Diese Aufzählung ist alles andere als abschließend, vermittelt jedoch einen Eindruck davon, dass ein Team-Mitglied wissen sollte, wovon hier die Rede ist – über die minimal zu erwartenden Fachkenntnisse aus dem eigenen Ausbildungsgebiet hinaus.
Mehr als allenfalls ein paar Stunden über Grundbegriffe des Projektmanagements gehört jedoch weder zur Ausbildung des Polizeibeamten im gehobenen Dienst (und auch der höhere Dienst hört nicht wesentlich mehr im Studium), noch zu der eines IT-Technikers. Und so kommt es dann, dass im Gesamtprojekt ganz selbstverständlich „deliverables“ = Ergebnisdokumente verlangt werden, von denen unser wackeres neues Team-Mitglied bisher allenfalls mal etwas gehört hat: Fachkonzepte, Lasten- und Pflichtenhefte, Risikobewertungen, Plan-, Soll- und Istwerte, usw. usw.
Niemand mag sich eine Blöße geben und frank und frei einräumen, dass er/sie nur eine vage Vorstellung davon hat, wie man solche Ergebnisse erarbeitet und entsprechende Dokumente erstellt. Man schaut halt mal bei den anderen Ländern, was die denn so machen, orientiert sich an den erfahreneren oder eloquenteren Kollegen und gestaltet das eigene Dokument dann in enger Anlehnung an solche Vorlagen.
(Mangelnde) Qualität der Ergebnisdokumente / Deliverables
Was man als Außenstehender dann zu sehen bekommt als Ergebnisdokumente aus solchen Projekten ist bemerkenswert. Viele Dokumente haben mit dem, was in der Fachwelt z.B. von einer Vorstudie oder einem Lastenheft erwartet wird, nicht viel mehr gemeinsam als den Titel. Die fachliche Qualität der Projektplanung und -steuerung, wie sie niedergelegt ist in der Projektdokumentation, ist also völlig unzureichend. Dies fällt allerdings nicht sonderlich auf, da die Probleme bei allen Partnern, die am Verbundprojekt teilnehmen, die gleichen Ursachen haben: Es fehlt an Kenntnissen, Fertigkeiten und Praxis im IT-Projektmanagement. Das generell schwache Niveau auf diesem Gebiet bei allen Projektpartnern definiert damit den durchschnittlichen Level im Gesamtprojekt und es gibt niemanden, der auf die schwache Qualität hinweisen und auf Verbesserung dringen würde. Denn – siehe ‚Systembedingt! IT-Verbundprojekte von Bund und Ländern und ihr hohes Risiko zum Scheitern (Teil 1)‘ – ein Top Management existiert nicht!
Hinzu kommt – wir sind in der Polizei! – dass man sich mit Kritik an anderen Polizeiangehörigen oder
Das soll nicht missverstanden werden als persönliche Kritik an den Team-Mitgliedern, die solche Papiere erarbeitet haben. Meist wussten sie es nicht besser und keiner sagt ihnen, was z.B. in einem Lastenheft zu stehen hat und was nicht. Die Krux ist, dass die Projektteams mit Team-Mitgliedern „beschickt“ werden, denen schlicht das Handwerkszeug fehlt für die Mitarbeit in solchen Projekten. Projektmanager sind von dieser Kritik nicht ausgenommen. Und leider wird wenig unternommen, um diese Schwächen auszumerzen und eigene Mitarbeiter für die Projekt-Arbeit besser zu qualifizieren.
Systemische Schwächen im Projektmanagement und die Folgen
Der Bund der Steuerzahler liefert in seinem Schwarzbuch (Die öffentliche Verschwendung 2013) [1] eine Analyse, warum so viele öffentliche Großprojekte scheitern. „Das Projektmanagement ist schlecht und die Entscheidungskompetenz mangelhaft“, heißt es dort. [Wir hatten in diesem Beitrag schon eine Zusammenfassung geliefert.] Kappelman und seine Kollegen gehen in ihrer Studie [2] noch weiter. Sie beschreiben, welche Fehler bei den Prozessen im Projektmanagement bzw. in den Phasen im Projektablauf besonders häufig vorkommen und schon frühe Indikatoren dafür sind, dass ein Projekt einmal scheitern wird. Schon jetzt kann gesagt werden – in Übereinstimmung mit dem Schwarzbuch des Steuerzahlerbunds:
„Die mangelhafte Planung … ist Grundstein für Probleme, die sich anschließend durch das gesamte Projekt ziehen und zu Zeit- und Kostenüberschreitungen führen. Daher ist es wichtig, mehr in die Projektplanung und -vorbereitung zu investieren – beispielsweise für exakte Bedarfsermittlungen – auch wenn das die Planungskosten erhöht. Am Ende zahlt sich jedoch eine solide Vorbereitung für alle aus.“
Darum und um weitere Risikofaktoren bei der Projektdurchführung geht es im Teil 3 dieses Artikels.
Dieser Artikel ist Teil der Serie Informationstechnik |
Polizeiliche IT-Verbundprojekte
Eine Übersicht sämtlicher bisher erschienener Artikel dieser Serie finden Sie hier.
Quellen zu diesem Beitrag
[1] Die öffentliche Verschwendung 2013, Bund der Steuerzahlerhttp://www.steuerzahler.de/Die-oeffentliche-Verschwendung-2013/55064c64453i1p637/index.html [2] Early Warning Signs of IT Project Failure: The Dominant Dozen,
Fall 2006, Kappelman, McKeeman, Zhang