Die Universität Oxford hat ein Studie durchgeführt, bei der 1.471 IT-Projekte in einem Gesamtwert von 241 Milliarden Dollar untersucht wurden: Mindestens 20%, bei komplexen IT-Projekten sogar 40% scheitern komplett. Bei weiteren 17% verdoppeln sich die Kosten und verlängert sich die Zeit bis zur Fertigstellung um zwei Drittel. Vom Rest werden die IT-Projekte als „ganz gut“ bewertet, bei denen die Kosten „nur“ um mehr als ein Viertel und der Zeitplan um mehr als die Hälfte überzogen werden. Diese Zahlen besagen: Scheitern ist nicht ungewöhnlich, eine erhebliche Überschreitung der ursprünglich angesetzten Kosten und des Zeitaufwands ist die Norm, alles, was besser ist, als diese Werte, kann schon als Erfolg gelten.
Projektplanung für polizeiliche IT-Verfahren
Solche Auswertungen sind Balsam auf die Seele des IT-Verantwortlichen in Polizeibehörden; geben sie ihm doch das beruhigende Gefühl, dass sein nächstes Projekt vollkommen im Rahmen des Üblichen liegt, wenn es erheblich mehr kostet und bedeutend länger dauert, als in der Planung vorgesehen.
Hinzu kommt – aus der Sicht des IT-Verantwortlichen – dass es ja nicht er ist, der hier die Entscheidung trifft, sondern immer noch die politische Ebene. Wer wollte also, als zwar hochrangiger aber doch weisungsabhängiger Beamter, sich mit mühsam erstellten Planungsdaten und Kalkulationen dem widersetzen, was die Leitungsebene vorgegeben hat. Zumal letztlich jede Prognose falsch sein kann und sich immer erst hinterher herausstellt, was bei einem Projekt reingesteckt wurde und rausgekommen ist.
Auch sollte man mit den Anforderungen an die Projektplanung doch die Kirche im Dorfe belassen: Solange keine Definition vorliegt, was bei dem ganzen Projekt eigentlich herauskommen soll, geschweige denn messbare Erfolgskriterien definiert sind, ist es einfach nicht machbar, irgendwelche Einzelheiten zu planen.
Zum Zeitaufwand und Personaleinsatz
Das trifft insbesondere zu für den Zeitaufwand und notwendigen Personaleinsatz. Wenn es denn ein Lastenheft gäbe, das diesen Namen verdient, wenn – Gipfel des Glücks – gar ein Pflichtenheft vorhanden wäre, könnte man – als IT-Verantwortlicher – die eigenen Leute ja mal tun lassen, was sie vor Jahren an der Hochschule gelernt haben: Das Projekt in Phasen unterteilen, Teilleistungsabschnitte definieren, Teilziele und -ergebnisse festlegen, den Zeitaufwand planen, den notwendigen Personaleinsatz. Man könnte sogar berücksichtigen, dass es in jedem Projekt Änderungen gibt, entsprechende Zuschläge vorsehen, den „kritischen Pfad“ ermitteln …
Hätte – Würde – Wenn …
Dass die Praxis anders aussieht, dass in jedem Projekt so getan werden muss, als stünde das Projekt auf einer gesunden Planungsgrundlage, weiß jeder Praktiker. Vermutlich ist das der Grund, warum die notwendigen Dokumente – dem Titelblatt und Umfang nach – den Anschein erwecken, dass tatsächlich drin steht, was der Titel besagt. Und sich damit jeder Entscheidungsverantwortliche beruhigt zurücklehnen kann. Wurde doch wieder einmal formal der Anschein einer fundierten Projektplanung gewahrt! Und um die Inhalte solcher Dokumente kümmert sich ohnehin kaum jemand: Hauptsache: Die Fassade stimmt!
Falls Sie das für übertrieben halten, hier eine kleine Anekdote. Erzählt hat sie der ehemalige IT-Leiter einer sehr, sehr großen öffentlichen Einrichtung in der Bundesrepublik Deutschland. Der fand in einer Vorstudie, die seine Organisation für viel Geld bei einer sehr, sehr großen und renommierten Beratungsfirma in Auftrag gegeben hatte, einen dicken Packen Papier, worauf Texte aus dem Neuen Testament gedruckt waren. Die Studie sah damit einfach viel „gewichtiger“ aus, als sie dem Inhalt nach tatsächlich war. Wir nehmen an, dass damit ausgedrückt werden sollte, dass der Glaube an eine höhere Macht nicht schaden kann, wenn man ein großes IT-Projekt beginnt. Weniger wohlmeinende Kommentare weisen allerdings darauf hin, dass auch die Apokalypse im Neuen Testament eine Rolle spielt. Doch wir wollen nicht abschweifen …
Zeitplanungen und Kostenplanungen in der Praxis
[Wie immer, gilt auch für diesen Text, dass Ähnlichkeiten mit lebenden oder bereits verschiedenen Projekten und den dort Handelnden keinesfalls beabsichtigt sind und reiner Zufall wären.]Zur Zeitplanung
Die Zeitplanung in solchen Projekten ist eigentlich kein großes Problem: Ein konkretes, ausgefeiltes Pflichtenhefet liegt ja (in polizeilichen IT-Projekten) in der Regel ohnehin nicht vor. Projektmanager und Projektteam können also auf sich zukommen lassen und von Fall zu Fall entscheiden, wann was zu geschehen hat. Sinnvoll ist es jedoch, in die Planungsdokumente markige Sätze aufzunehmen, die den Lesern Entschlossenheit demonstrieren und die Überzeugung vermitteln, dass der Autor dieses Werks schon wusste, wann was erledigt sein soll. Es ist vollkommen akzeptabel, statt eines konkreten Zeitplans Wunschtermine zu dokumentieren. Sie haben den erwünschten Nebeneffekt, die Entscheider noch nachträglich in ihrer positiven Grundeinstellung gegenüber dem Projekt zu bestärken. Zwar hat die Festschreibung solcher Wunschtermine keinerlei Einfluss auf den tatsächlichen Fertigstellungstermin des Projekts – denn das ist fertig, wenn’s eben fertig ist [die so genannte „erste Normalform“ der Projektplanung] – bestärkt jedoch über eine lange Zeit bei allen erfolgshungrigen Beteiligten den Glauben daran, dass dieser Termin schon haltbar sein wird.
Die beschriebene Vorgehensweise hat darüber hinaus den Vorteil, dass das Projektteam seine Zeit nicht für Planungsarbeiten vergeudet. Wo doch an deren Stelle wesentlich effektiver Arbeiten geleistet werden können, die das Projekt tatsächlich voran bringen.
Personal(kosten)planung
Hilfreich ist es, wenn für das Projekt frühzeitig ein Stab von Mitarbeitern beschafft und zugewiesen wird. 8 bis 25 sollten es schon mindestens sein, wenn man bedenkt, welcher Arbeitsumfang zu bewältigen sein wird. Und um auch hier in der späteren Projektabwicklung möglichst frei zu sein, sollten diese Mitarbeiter dem Projekt summarisch für einen ausreichend langen Zeitraum zur Verfügung stehen.
Als Ansatz in der Personalkostenplanung ist es vollkommen ausreichend, die Zahl der jeweiligen VZÄ [=Vollzeitäquivalente] pro Dienstgruppe für die gesamte Projektlaufzeit anzusetzen. Eine genauere Kostenplanung wäre übertrieben, umso mehr als es sich nur um nicht haushaltswirksame Kosten handelt, mit anderen Worten: Beamte immer bezahlt werden müssen, egal, wofür sie eingesetzt werden.
Übrigens: Aufwand, der dem Wesen nach zwar getätigt werden muss, jedoch der Höhe nach noch nicht bekannt ist, muss natürlich auch nicht angesetzt werden. Wer wollte sich schon dem Verdacht aussetzen, Zahlen in die spätere WiBe (Wirtschaftlichkeitsbetrachtung) zu übernehmen, die nicht hieb- und stichfest ermittelt wurden. Da setzt man entsprechende Positionen besser – der Vorsicht folgend – auf Null. Wenn man also zum Planungszeitpunkt nur spekulieren kann über Einführungskosten, Kosten der Migration von Daten aus dem Altsystem, Schulungskosten und ähnliches: Einfach auf Null setzen! Dass mehrere solcher Null-Posten die ganze WiBe zur Luftnummer machen, ist nicht das Problem des Autorenteams. Schließlich dient ein solches Dokument – siehe oben – auch ganz anderen, höheren Zwecken. Demzufolge werden die eigentlichen Auftraggeber gerne darüber hinwegsehen, dass das ganze Dokument eine Luftnummer ist, solange im Executive Summary nur die gewünschte, richtige Entscheidungsempfehlung steht.
Über Annahmen bei der Projektplanung und die spätere Wirklichkeit
Bei der Planung von IT-Projekten darf nie außer Acht gelassen werden, welches Bild vom Projekt die Entscheidungs- und Leitungsebene hat bzw. in der Öffentlichkeit präsentiert. Jeder Projektmanager und jedes Teammitglied tut gut daran – aus mehreren Gründen, die auf der Hand liegen, sich dieses Bild zu eigen zu machen und Beobachtungen und Feststellungen aus dem wirklichen Leben mit diesem Bild kompatibel zu machen. Gewarnt sei in diesem Zusammenhang auch davor, Meinungen oder Ratschläge von Externen oder gar Experten ins eigene Blickfeld rücken zu lassen. Denn keiner von denen hat doch auch nur annähernd einen Überblick, worum es wirklich geht in diesem Projekt.
Daten großzügig vernachlässigen, die nicht ins Bild passen wollen
Als besonders problematisch ist die Erhebung oder – noch schlimmer – die Messung von Daten zu betrachten. Es zeigt sich immer wieder, dass Daten diesbezüglich einen eigenen Kopf haben und nicht ins Bild passen wollen. Es hilft dann nur eines: Großzügig weglassen, was sich nicht fügen möchte!
Eine gute Projektplanung lebt von gesundem Optimismus und ungetrübter Zuversicht. Und es wird auch gutgehen! Denn – erstens – liegt ja eine Planung vor, die den Erfolg sozusagen vorwegnimmt. Glaubt man also dieser Planung, so kann gar nichts schiefgehen!
Zum Waffenarsenal guter Projektplanung
Zweitens sind es ja vor allem die Macher aus der Organisation, die sich im Projekt(planungs)team gefunden haben. Die haben ihr Handwerkszeug bestens im Griff: Leistungswertbestimmungen, monetäre Kennwerte, qualitative Kennwerte, Umfragen, Workshops, Kick-Off-Veranstaltungen, Project Meetings und entsprechende Protokolle, Balanced Score Cards usw. usw. liefern ein ganzes Arsenal von Methoden, das im Macher die Zuversicht reifen lässt, dass so viel Aktionismus zwangsläufig zu einem guten Ergebnis führen muss. Der positive Nebeneffekt besteht darin, dass nur am Rande Beteiligte, über denen ein solches Füllhorn hängt, von der Lawine von Arbeitsergebnissen, die sich über sie ergießt, überrollt werden. Dies wiederum beeinträchtigt deren Aufmerksamkeit für das, was sich im Projekt tatsächlich tut, doch nachhaltig. Ein Schelm, wer Schlechtes dabei denkt …
Risiken sind voll beherrschbar
Diese Überzeugung ist einem guten Projektplaner förmlich in die Wiege gelegt. Denn er ist ja Planer. Daher plant er auch – immer am gewünschten Ergebnis orientiert! – welche Risiken seiner Meinung nach vorkommen dürfen. Andere Risiken haben in (s)einer Projektplanung nichts verloren und würden von Lesern wahlweise als zu hasenfüßig bzw. als Miesmacherei missinterpretiert.
Schwarze Schwäne – „habe noch nie einen gesehen!“ …
Wenn ein Projektplaner schon normale Risiken für vollkommen kontrollierbar (bzw. weitgehend ignorierbar) hält, gilt das umso mehr für schwarze Schwäne [Schwarzer Schwan = bildhafter Ausdruck für ein ganz und gar als unwahrscheinlich angesehenes Ereignis nach dem römischen Satirendichter Juvenal bzw. dem libanesischen Finanzmathematiker Nassim Nicholas Taleb, Autor des internationalen Bestsellers ‚Fooled by Randomness‘ – ‚Vom Zufall zum Narren gehalten‘ hier mehr dazu bei Wikipedia]. Und es kommt ja wirklich nur alle Jubeljahre mal vor, dass – beispielsweise – in einem bedeutenden Bund-Länder-Projekt jahrelang auf die Pilotierung im OK-Deliktsbereich hingearbeitet wird, diese Planung aber innerhalb weniger Monate umgewidmet wird und man sich nun auf Waffen- und Sprengstoffdelikte fokussiert. Ob so etwas allerdings tatsächlich ein „Schwarzer Schwan“ ist oder einfach nur eine von Anfang an sehr unflexible Projektausrichtung und damit einen systemischen Fehler dokumentiert – ist — — — Ansichtssache.
Dieser Beitrag enthält, wenn auch in Form einer Glosse, die wesentlichen Inhalte der Studie „Double Whammy – How ICT-Projects are Fooled by Randomness and Screwed by Politicial Intent“ [1] [zu deutsch etwa: ‚Doppeltes Pech. Wie IT-Projekte vom Zufall zum Narren gehalten und von politischen Interessen vermasselt werden‘], erschienen als Zwischenergebnis einer länger andauernden Untersuchung an der University of Oxford im Juli 2012.
Dieser Artikel ist Teil der Serie Projektmanagement | IT-Projekte
Eine Übersicht über sämtliche bisher erschienenen Artikel dieser Serie finden Sie hier.
Quellen zu diesem Beitrag
[1] Double Whammy – How ICT Projects are Fooled by Randomnessand Screwed by Political Intent, Working Paper, 09.07.2012,
Alexander Budzier, Bent Flyvberg, University of Oxford