IT-Verbundprojekte der Polizei: Die sechs Kardinalfehler

Die amerikanischen Forscher und Experten für Projektmanagement, Leon Kappelman, Robert McKeeman und Lixuan Zhan, haben eine Studie [1] durchgeführt, um herauszufinden, welche Fehler in frühen Stadien der Durchführung von IT-Projekten besonders negativen Einfluss haben. Sie wollten wissen, welche frühen Warnzeichen darauf hinweisen, dass ein IT-Projekt später scheitert bzw. seinen Zeit- und Kostenrahmen wesentlich überzieht. 53 Fehler haben die Befragten bei dieser Studie insgesamt genannt. Unter den zwanzig mit dem größten negativen Einfluss ist interessanter Weise kein einziger Fehler im Bereich der Technik oder Entwicklung. Vielmehr kreisen alle zwanzig „Kardinalfehler“ um nur zwei Aspekte: Menschen im Projekt, sowie Prozesse.
Lesedauer: Ca. 5 Minuten

Worum es in Teil 1 und 2 dieses Artikels ging …

Im Teil 1 dieses Artikels ging es um die gravierendste Ursache für das Scheitern von Projekten überhaupt: Den fehlenden Support durch das „Top Management“. Systemisch bedingt, gibt es in Bund-Länder-Verbundprojekten der Polizeibehörden kein „Top Management“, das allen Bundes- und Landesbehörden übergeordnet wäre. Allein das ist schon eine Bürde, die in solchen Projekten vorhanden ist und aufgefangen werden müsste.

Teil 2 des Artikels beschäftigte sich mit den Menschen, die ein Projekt durchführen und voranbringen sollen: Projektmanager und die Mitglieder des Projektteams. Keine Teilnehmerland/-behörde in einem Verbundprojekt kann es sich leisten, Mitarbeiter von ihren Aufgaben in der allgemeinen Aufbauorganisation (AAO) komplett freizustellen und monate- oder jahrelang nur für ein Projekt abzuordnen. Daraus ergeben sich Mehrfachbelastungen, aber auch Konfliktsituationen. Und nicht zuletzt werden die meisten Mitarbeiter für Projekte von großer strategischer und auch finanzieller Tragweite teilzeit- bzw. zeitweise abgeordnet, sind für Projektaufgaben aber weder aufgrund ihrer Ausbildung qualifiziert, noch hat sie der Arbeitgeber zuvor fit gemacht für die neuen Aufgaben im Projektmanagement.

In diesem dritten und letzten Teil dieses Artikels geht es um die fünf Projektphasen bzw. -Prozesse, die endgültig über Erfolg bzw. Scheitern entscheiden. Wir werden in diesem Teil vor allem die Fachleute Kappelman et.al. zu Wort kommen lassen, deren knappe Analyse der sechs schlimmsten, prozess-bezogenen Kardinalfehler wir hier einfach wiedergeben. Eine Übertragung in die Wirklichkeit von IT-Projekten in deutschen Polizeibehörden wird jeder Projektbeteiligten und -betroffenen anhand dessen leicht selbst vornehmen können …

Kardinalfehler #1: Fehlende Definition und Dokumentation von Anforderungen und Zielen des Projekts

Sofern Anforderungen an die Funktion, Leistung (Performance) und Zuverlässigkeit und Sicherheit nicht schriftlich niedergelegt werden, hat jedes Mitglied des Projektteams und jeder Projektbeteiligte andere Erwartungen und Vorstellungen, da jeder seine eigene, individuelle Blaupause im Kopf hat. Es ist daher notwendig darauf zu dringen, dass die schriftliche Dokumentation der Anforderungen von jedem abgezeichnet wird. Damit werden unterschiedliche Erwartungen und Vorstellungen an die Oberfläche geholt, wo sie diskutiert und aufgelöst werden können.
Wenn nicht alle an einem Strang ziehen, wird das Projekt fehlschlagen.
Projektbeteiligte, die für das Projekt Ressourcen oder sonstigen Support beisteuern sollen, werden dies nicht tun bzw. solche Ressourcen schon nach kurzer Zeit wieder abziehen, wenn das Ziel und der Nutzen nicht deutlich zum Ausdruck gebracht wurden.
Projekte, deren Erfolgskriterien nicht bestimmt sind, können nicht erfolgreich sein. Sie sind zum Scheitern verurteilt.

Kardinalfehler #2: Fehlende Prozesse / Vereinbarungen über den Umgang mit Änderungen

Eine Auswertung von mehr als 10.000 IT-Projekten [Jones, 1995] hat ergeben, dass sich monatlich 2% die Anforderungen ändern. Das Team kann zwar beim Start des Projekts erklären, dass alle Anforderungen nun „eingefroren“ sind. Das ändert jedoch nichts an der Tatsache, dass sich die Änderungen in der realen Welt dennoch vollziehen: Der Wettbewerb ändert sich, ebenso Geschäftsprozesse, Verordnungen und Regeln, Gesetze werden zwischenzeitlich verabschiedet, der Markt ändert sich und nicht zuletzt auch das Senior Management. Was vor sechs Monaten als unumstößliche Anforderung galt, ist heute längst nicht mehr unantastbar. Veränderungen sind unausweichlich und daher muss jedes Projekt Prozesse vorsehen, wie mit solchen Veränderungen umgegangen wird.

Kardinalfehler #3: Uneffektive Zeitplanung bzw. Zeit-Management

Vier von den 17 folgenreichsten Fehlern beim Management von IT-Projekten betreffen die Zeitplanung.

Zerlegung in Teilphasen, -ergebnisse und Meilensteine

Jede Reise besteht aus vielen Einzelschritten. Wenn jedoch nicht festgelegt und dokumentiert ist, was als Teilergebnis zu den Meilenstein-Terminen abzuliefern ist, wird es eine Vielzahl von Meinungen darüber geben, was tatsächlich zu erledigen ist und (bis) wann.
Das Projektteam muss verstehen und sich einig darüber sein, welche kurzfristigen Aufgaben jeweils erledigt werden müssen, damit die langfristigen Ziele erreicht werden. Für die verschiedenen Phasen des Projekts werden vielfältige und unterschiedliche Kenntnisse und Fähigkeiten benötigt. Teilergebnisse im späteren Verlauf eines Projekts sind davon abhängig, dass frühere Teilergebnisse erbracht worden sind. Um ein Projekt zeitgerecht fertigzustellen, ist es notwendig, dass alle Teammitglieder ein gemeinsames Verständnis haben von den Zwischenergebnissen, Meilensteinen und damit verbundenen Terminen.

Den aktuellen Projektstatus feststellen und dokumentieren

Wenn es keinen Prozess gibt, um den Status aufzunehmen und zu dokumentieren, bedeutet dies auch, dass kein Projektbeteiligter oder Teammitglied feststellen kann, ob die Aufgaben termingerecht erledigt wurden oder rückständig sind.
Da spätere Projektphasen/-aufgaben abhängig davon sind, dass vorangehende Teilaufgaben vollständig und richtig erledigt wurden, gibt es für ein Projekt, das den eigenen Status nicht feststellen kann, keine realistische Chance innerhalb des Zeitplans bzw. Kostenplans fertig zu werden.

Projektplan erstellen für den gesamten Projektablauf, Zeitbedarf abschätzen

Ein Projekt muss von unten nach oben aufgebaut werden, indem festgelegt wird, welche Teilschritte von welchen früher zu erledigenden Teilschritten abhängig sind und indem dann für jeden dieser Teilschritte der notwendige Zeitbedarf abgeschätzt wird. Auch wenn manche Aufgaben parallel bearbeitet werden können, gibt es einen minimalen Gesamt-Zeitbedarf für das Projekt.
Ein willkürlich gewählter Projekt-Endtermin kann diesen minimalen Zeitbedarf zwar ignorieren. Das bedeutet allerdings nicht, dass das Projekt dadurch weniger Zeit braucht, als minimal eben notwendig ist.

Auswirkungen von Verzögerungen in frühen Projektphasen

Ein weiterer häufig begangener Fehler besteht darin, dass Verzögerungen in den frühen Projektphasen nicht beachtet werden. Man könnte erwarten, dass die ersten zehn Prozent des Projekts der Teil mit den wenigsten Problemen sein, weil man die Anfangsaufgaben kennt, diese gut geplant sind und nicht beeinträchtigt sein können von Verzögerungen aus vorangehenden Projektphasen. Die Annahmen über den Zeitbedarf der ersten Phase sind, so sollte man meinen, relativ genau geschätzt und es gab noch nicht viel Zeit und Raum, dass Anforderungen sich ändern konnten. Wenn das Projekt allerdings schon zu spät startet, werden eingeplante Ressourcen nicht zeitgerecht zur Verfügung stehen. Wenn Verschiebungen aus anderen, dringenden Gründen notwendig sind, ist es alles andere also logisch zu erwarten, dass spätere Projektphasen / Aufgaben wie geplant abgewickelt werden können oder gar früher abgeschlossen werden können, um den anfänglichen Zeitverzug wieder herein zu holen.

Kardinalfehler #4: Abbruch bzw. Zusammenbruch der Kommunikation zwischen den Projektbeteiligten

Jedes größere Projekt hat eine Vielzahl von Projektbeteiligten und erfordert daher die fortwährende Abstimmung der verschiedenen Aufgaben und Ressourcen mit den Beteiligten. Veränderungen während des Projektes sind unvermeidlich – im geschäftlichen Umfeld, der Strategie des Wettbewerbs und daraus resultierenden taktischen Schachzügen, Gesetze und Verordnungen werden angepasst, das Management Team ändert sich, es kommt zu personellen Veränderungen, Verfügbarkeit von Ressourcen und Finanzmitteln – um nur ein paar zu nennen. Wenn die Projektbeteiligten nicht permanent miteinander kommunizieren, d.h. miteinander reden und einander zuhören und zusammenarbeiten, wird das Projektteam zwischen den verschiedenen Stakeholdern verschlissen und zerrieben.

Sollte inzwischen (siehe auch Kardinalfehler #1) das gemeinsame Verständnis über die Ziele und Erfolgskriterien für dieses Projekt verloren gegangen sein, gibt es nur noch wenig Hoffnung, das Projekt zeit- und kostengerecht abzuschließen – bzw. es überhaupt zum Abschluss zu bringen.

Kardinalfehler #5: Ressourcen werden für ein Projekt mit höheren Prioritäten abgezogen

Wenn Ressourcen, die ursprünglich dem Projekt zugewiesen waren, für ein anderes Projekt mit höheren Prioritäten abgezogen werden, ist es unrealistisch zu erwarten, dass das betroffene Projekt, wie geplant, zeit- bzw. kostengerecht bzw. überhaupt zu Ende gebracht werden kann.

Kardinalfehler #6: Der Business Case wurde nicht bedacht

Auch wenn er erst am Ende daherkommt und sich tarnt hinter der leicht misszuverstehenden, englischen Bezeichnung „Business Case“. Hier handelt es sich – nach meiner Ansicht – um den Fehler, der nahezu immer begangen wird und der die schlimmsten Auswirkungen hat: Weil die wichtigsten Fragen überhaupt für ein Projekt – und die damit einhergehende Investitionsentscheidung – weder gestellt noch beantwortet werden: Die Fragen nämlich, welchen strategischen Nutzen (oder auch Nachteile) es bringen soll/wird, dieses Projekt zu realisieren, welche Voraussetzungen geschaffen werden müssen, damit das Projekt vernünftig ausgestattet und zum Leben gebracht werden kann, welche finanziellen Konsequenzen sich aus diesem Projekt ergeben, nicht nur während der Projektentwicklungs- und -Einführungsphase, sondern auch langfristig danach und welche Konsequenzen auf Management, Mitarbeiter und Betroffene das Projekt haben wird und wie die notwendigen Kompetenzen rechtzeitig aufgebaut werden.

Zusammenfassung

Diese Artikelreihe hat wesentliche Fehler aufgezeigt, die als Hauptursachen gefunden wurden, wenn IT-Projekte scheitern.
Wenn man diese Fehler kennt und darauf achtet – je früher im Projektverlauf, desto besser – ob der eine oder andere um die Ecke lugt, steigt die Wahrscheinlichkeit erheblich, dass das Projekt zu einem erfolgreichen Abschluss kommt. Für manche Projekte wird man feststellen, dass sie besser abgebrochen werden sollten. Auch solche Fälle hilft die Liste der häufigsten Projektmanagement-Fehler zu identifizieren, bevor sich diese Projekte zu „Todesmärschen“ für die Beteiligten bzw. Millionengräbern für den Steuerzahler entwickeln.

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]   Early Warning Signs of IT Project Failure: The Dominant Dozen,
     Fall 2006, Kappelman, McKeeman, Zhang
http://www.csb.uncw.edu/people/rosenl/classes/OPS100/Early%20Warning%20Signs%20of%20IT%20Project%20Failure.pdf

Bücher zum Thema

Wer kurzweilige Lektüre sucht gepaart mit hoher Fachkenntnis und Erfahrungen über das Projektmanagement von IT-Projekten, der ist bei dem Klassiker überhaupt bestens aufgehoben: Tom de Marco
In ‚Wien wartet auf Dich‘ widmen sich de Marco und sein Koautor Timothy Lister dem ‚Faktor Mensch im DV-Management‘
Mit ‚Der Termin‚ legte de Marco einen Roman (sic!) vor über Projektmanagement; eine äußerst kurzweilig zu lesende, amüsante und lehrreiche Lektüre über die Entwicklung von Software-Produkten.
Bärentango‚ vom eingangs erwähnten Autorenteam ist nicht unbedingt ein Muss für den, der in Projektmanagement näher einsteigen möchte, jedoch sehr zu empfehlen für jeden, der sich mit Risikomanagement in Projekten vertraut machen möchte.