Als hochinteressierter Projektbeteiligter kennen Sie die Litanei der guten Ratschläge für effektive Projekte. Such dir einen Sponsor, plane gut und vorausschauend, definiere deine Ziele, steck Liebe ins Design, nimm Meilensteine als STEINE. Alles gut und schön, trotzdem scheinen es das IT-Projekt – die kleine gutaussehende Schwester des klassischen Projekts – immer etwas schwerer zu haben.
Die schwere Bürde
Oft zitiert ist die CHAOS Studie von The Standish Group vermutlich die bekannteste Studie zum Erfolg von IT-Projekten. Ihr zufolge erreichten im Jahr 2015 knapp 20% der Projekte das Projektende nicht, weil sie abgebrochen wurden. Da die Projekte aufgrund des Abbruchs nicht mehr existieren, die Unternehmen aufgrund Ihrer Teilnahme an der Umfrage aber durchaus noch, können wir davon ausgehen dass der Grund für den Abbruch in den meisten Fällen im Projekt oder in dessen direkten Umfeld zu suchen ist. Von einem durchschnittlichen Homo Sapiens Projectensis ausgehend – man verzeihe mir diesen günstigen Ausdruck totaler Unbeschlagenheit in toten Sprachen – ist es im Mittel also weder das Unternehmen, noch der Projektbeteiligte der den Misserfolg zu verantworten hat. Sind IT-Projekte einfach anders als die anderen Kinder?
Mit einer Vergleichsstudie für Projekte die nicht auf den IT-Bereich fokussieren ist es schwierig. Als noch am Besten geeignet erscheint mir die Studie der Uni Kassel zum PM-Reifegrad, auch wenn diese für unsere Zwecke nur mit Einschränkung verwendbar ist. Bei der dreistufigen CHAOS-Einteilung können die Stufen sehr klar durch Kriterien wie Abbruch oder volle Zielerreichung gegeneinander abgegrenzt werden. Das kann man von der fünfstufigen Zielerreichungs-Skala plus 10%igem Weiß-Nicht-Anteil nicht gerade behaupten. Zudem sind die freiwilligen Teilnehmer einer Studie mit dem Thema „Projektmanagement-Reifegrad und Projekterfolg“ möglicherweise kein repräsentativer Querschnitt. Dafür haben wir viele Branchen dabei und immerhin eine kleine bis mittlere Projekt- (6-20 Mitglieder) und Unternehmensgröße (85% Großunternehmen).
Dieser Studie zufolge erreichten gut 70% der Projekte Ihre Ziele zu einem hohen Grad (4 oder 5 von 5 Stufen). Wie vorweggeschickt, mir ist bewusst dass diese statistische Basis wackelt, aber es ist alles was wir haben. Lassen Sie uns also der Einfachheit halber annehmen, dass Industrieprojekte im Allgemeinen besser laufen als IT-Projekte im Besonderen.
Woran könnte es liegen? Ein IT-Projekt hat Eigenheiten, denen andere Projekte nur eingeschränkt ausgesetzt sind, und ich stelle die Behauptung auf, dass diese Eigenheiten uns IT-Projektleitern ein Stück weit die Erfolgsquote verderben.
Kostenstruktur
Zuallererst sind IT-Projekte in Ihrer Kostenstruktur vor allem Personalprojekte. Sicher kann je nach Ausrichtung die eingeführte Hardware (Rechenzentrumsaufbau) oder die anzuschaffenden Lizenzen (SAP Einführung) durchaus beachtliche Summen verschlingen, aber das typische IT (Software) Projekt skaliert nicht mit den Lizenz- oder Hardwarekosten, sondern mit der Komplexität der Organisation. Das bedeutet, eine zusätzliche Menge von 100 Usern kostet (im Asset) gemäß Standardpreisliste lizenzseitig (in der gängigen Mischung) eine mittlere bis hohe 5-stellige Summe. Es entsteht für 100 weitere User (bspw. ein weiterer Standort, oder ein bisher nicht berücksichtigter größerer Fachbereich) in Bezug auf die Personalkosten des Projektteams jedoch erheblich mehr Aufwand. Auch das passt sicher nicht auf jedes Projekt (denken wir an sehr große und sehr homogene Strukturen, wo 100 oder 1000 User mehr kaum einen Unterschied machen, weil sie sich in das bestehende Globaldesign einfügen), lässt sich aber mit gutem Willen für den durchschnittlichen IT-Projekt-Kunden verallgemeinern.
Und wozu diese steile These? Nun, wer für einen (Asset-intensiven) Brückenbau Stahlträger beschaffen muss, prüft die Investition, den Bauplan, das beauftragte Unternehmen und die Zeitplanung sehr genau. Wenn aber der Anteil des aktivierbaren Projektwertes den des nicht (so klar) aktivierbaren Wertes bei weitem unterschreitet, ist die Prüfung nicht ganz so einfach. Sicher ist es in beiden Fällen wichtig, einen kompetenten Partner zur Seite zu haben. Die Abhängigkeit von der Erfahrung und der Methodik des Partners ist für die Kosten- und Zeit-Planung eines IT-Projekts jedoch um ein Vielfaches höher. Da die konkreten Fettnäpfchen oft auch noch produktspezifisch sind, ist die Restmenge an fähigen und produkterfahrenen Projektberatern wesentlich geringer als in einem typischen Konstruktionsprojekt.
Transparenz
Aus dem gleichen Grund ist es für den Kunden auch in der Umsetzung wesentlich schwerer, den konkreten Fortschritt des Projekts zu bewerten. Der Kunde hat das Tiefen-Know-How normalerweise nicht im Haus, einer der Hauptgründe warum er sich an einen externen Partner wendet. Damit steht jedoch das Kunden-Monitoring auf einigermaßen tönernen Füßen. Zu diesem Zweck schafft man natürlich auch in der IT entsprechende Meilensteine, bei denen der Kunde Teilabnahmen vornimmt und punktuell und gezielt den Systemzustand prüft. Das ist aber nur bedingt vergleichbar mit einer Begehung bei einem Lieferanten für ein „klassisches Projekt“. Kurz gesagt: ist die Brücke zu 70% fertig, sehe ich das. Beim ERP-System ist das nicht so leicht.
Wie im IT Service Management kommt es also auch für IT-Projekte vor allem darauf an, auf Seiten des Kunden Beurteilungskompetenz sicherzustellen, die gemeinsam mit dem externen Lieferanten geeignete Mess- und Beurteilungsverfahren entwickelt, um den Fortschritt gemeinsam zu tracken. Werden Abweichungen festgestellt, muss die Projektorganisation willens und in der Lage sein, darauf zu reagieren.
Schmetterlinge
Zudem hat das ERP-Projekt (im Vergleich zu weniger ambitionierten IT Projekten) einen unerhörten Grad an Integration zwischen Prozessen, Anwendungsbereichen und damit Fachabteilungen. Diese Komplexität muss in jeder Phase des Projekts, von der Initiierung, über Planung, Umsetzung, Test und Abnahme vollständig im Griff der Projektorganisation sein. Verliere ich zu den Phasenwechseln (insbesondere zwischen Design und Umsetzung) den Gesamtüberblick, kann es mir passieren dass ein unbedachter Schalter im PP (SAP Production Planning) mir mein schönes PS (SAP Project System) Prozessdesign zerschießt.
Folgend der Chaos-Theorie strebt bei der Arbeit mehrerer Kollegen am gleichen System in integrierten Prozessen die Gesamtlösung einem immer höheren Maß an Unordnung zu. Jedes Design-Paradigma und jede Einstellung muss jedoch mit den anderen abgestimmt sein, und dazu bedarf es einer Extra-Portion Projekt-Governance in puncto Kommunikation und Dokumentation. Um diese Aufgabe zu meistern, empfiehlt sich neben dem Projektleiter je nach Größenordnung ein oder mehrere Softwarearchitekten, die über die einzelnen Prozessbereiche und deren Workstreams wachen und die Integration dieser sicherstellen.
Frankenstein
“Nothing is so painful to the human mind as a great and sudden change.” (Mary Shelley, Frankenstein)
Und noch ein Problemkomplex trifft auf IT-Projekte in besonderem Maße zu – IT-Systeme an sich sind grundsätzlich äußerst flexibel. Auch SAP erlaubt mir, im Code meinem kundenindividuellen Willen freien Lauf zu lassen. Natürlich sträubt sich auch jede Organisation dagegen, ihre branchenspezifischen und höchst anforderungsgerechten Prozesse an einen beliebigen Produktstandard anzugleichen.
Allerdings verliert man hier schnell etwas aus den Augen: der Produktstandard ist nicht willkürlich gewählt, SAP-Software war und ist schon immer eine Lösung die beim und mit dem Kunden entwickelt wurde. Eine Standardlösung mit Branchenausprägungen, deren Stärke eben darin besteht nicht für jeden Kunden individuell zugeschnitten werden zu müssen. Was genau unterscheidet meine Schweinwerferproduktion von anderen Serienfertigern im Automotive-Umfeld? Ich kann mich demnach zwar in Customizing, Strukturen und Stammdaten austoben – den Code anfassen, das sollte ich jedoch nicht.
Denn mit der gelebten Individualität kommen einige unerwartete Fallstricke auf mich zu. Ich muss einerseits bei Modifikationen des Standards (nennen wir sie „Y“) wie auch bei Nutzung von Zusatzprogrammen (nennen wir sie „Z“) die reibungslose Integration meiner „Y“ und „Z“ zu den Standardprozessen im SAP und zu den Umsystemen sicherstellen. Ich kann nämlich nur im Standard davon ausgehen, dass die SAP-Prozesse und -Strukturen zueinander passen, und über die Standard-Schnittstellen sauber Daten austauschen. Bei „Y“ und „Z“ setze ich da sehr viel Vertrauen in den Entwickler, dass er alle Abhängigkeiten (was muss ich beachten) und Design-Prinzipien (warum muss ich es beachten) der SAP im Kopf hat.
„Y“ und „Z“ haben auch im täglichen Change und Incident Management einen hohen Preis. Selbst vollständige und aktuelle Dokumentation bewahrt mich nicht davor, die Lösung bei jeder Änderung wieder mit dem SAP Standard abzugleichen. Das gilt für das Einspielen von SAP Notes (Codekorrekturen) ebenso wie für die Implementierung von SAP Support Packages (Bugfixes) und Enhancement Packages (Functional Updates). Das mündet neben dem oft erheblichen Zusatzaufwand oft auch in eine Risikobetrachtung für die Entwicklerressourcen. Ist mein Entwickler in der Lage (ist er noch da und hat er die Zeit?) und willens (versteht er das Ausmaß des Problems?) mich hier dauerhaft und umfassend abzusichern, so wie es die SAP mit ihren Wartungsverträgen macht? Kann ich davon nicht mit Sicherheit ausgehen, habe ich in einem durchschnittlichen SAP-Lebenszyklus von 15 Jahren ein massives Problem und muss mich der Frage stellen wie wichtig mir die Verfügbarkeit meiner im SAP implementierten Prozesse grundsätzlich ist.
Die aufgeführte Argumentation zu den ach so schweren IT-Projekten soll uns IT-Projektleiter keineswegs entlasten – wir sind trotzdem unseres (und des Kunden) Glückes Schmied. Allerdings kann sie Kunden wie auch Dienstleister sensibilisieren, denn im schwierigeren Umfeld besteht eine besondere Verantwortung den Kunden methodisch und inhaltlich professionell durch das Projekt zu begleiten.
Auf gutes Gelingen,
