Ihr kennt das. Neue oder verbesserte Software für einen neuen oder verbesserten Geschäftsprozess. Beides gleichzeitig entwickelt und ausgerollt. Des schnellen Nutzens wegen. Funktioniert aber in den wengisten Fällen. Und dann? Richtig! Schuld ist die IT. Schaffen es Mal wieder nicht den ungaren Prozess in eine reife Software zu gießen. Ein kurzer Exkurs über das vorprogrammierte Scheitern von IT-Projekten.
Forscher der Universität Oxford und des Beratungshauses McKinsey untersuchten etwa 1500 Projekte mit einem durchschnittlichen Volumen von 170 Millionen US-Dollar. Mit erschreckendem Ergebnis:
Jedes sechste Projekt sprengte das vorgegebene Budget um durchschnittlich 200 Prozent – und zwar inflationsbereinigt. Der geplante Zeitrahmen wurde in diesen Fällen im Mittel um 70 Prozent überschritten.
CIO 11.10.2011 aus einer Studie von Oxford und McKinsey
Industrieunternehmen stehen heute unter sehr großem Druck bedingt durch schnellere und globalere Märkte. Die Unternehmen müssen sehr viel flexibler und schneller im Markt agieren als noch vor 20 oder 30 Jahren. Das Ergebnis sieht man am Beispiel der Automobilbranche sehr schön. Die Modellpalette und Variantenvielfalt ist in den letzten Jahrzehnten deutlich gewachsen. BMW beispielsweise hatte Anfang der Siebziger Jahre des letzten Jahrhunderts eine Produktpalette aus drei Modellreihen mit jeweils 2 bis 3 Motorisierungen; im Jahr 2000 waren es aber bereits 6 verschiedene Plattformen allein für die 3er Reihe mit jeweils 3 bis 6 unterschiedlichen Motorisierungen.
Solche enormen Veränderungen wie diese deutliche Zunahme der Variantenvielfalt haben Auswirkung auf eine Vielzahl von Prozessen im Unternehmen. Und kaum ein Prozess kommt ohne IT aus. Jede Prozessveränderung bedeutet daher in der Regel auch eine Änderung in einer hochkomplizierten und über Jahrzehnte gewachsenen IT-Landschaft.
Nun wäre ja die Anpassung und Optimierung der Prozesse für sich genommen schon eine Herausforderung. Richtig spannend wird die Aufgabe aber immer dann, wenn man die erste halbgare Prozessdefinition in das erstbeste IT-System vom günstigsten Anbieter integrieren lässt und die Prozesse quasi nebenbei über die Software verändert. Schließlich soll ja schnell ein Nutzen der IT-Investion gerechnet werden können.
IT-Projekte sind tickende Zeitbomben. Sie zerstören in unschöner Regelmäßigkeit ganze Unternehmen und ruinieren die Karrieren der Manager, die für sie verantwortlich sind.
CIO 11.10.2011 aus einer Studie von Oxford und McKinsey
Bei derartig komplexen Problemstellungen sollte unbedingt eine iterative Vorgehensweise gewählt werden. Unbedingt abzuraten ist von einem Big-Bang, also dem Versuch, alles gleichzeitig in einem großen Wurf verändern zu wollen. Viel besser sind kleine tastende Schritte mit denen das Neue erkundet wird. Vielleicht kann der neue Prozess ganz oder teilweise zunächst ohne oder ohne volle IT-Unterstüzung erprobt werden. Vielleicht kann man anschließend einen kleinen Prototypen bauen für wenige Key-User. Vielleicht kann man die Umsetzung grundsätzlich agil in Sprints gestalten. Es geht letztlich darum Erfahrungen zu sammeln, es geht um Feedback. Und das kontinuierlich und schnell.
<
p>Foto: Das Artikelbild wurde von Chris-Håvard Berge unter dem Titel „Achtung! Minen!“ auf Flickr unter einer Creative Commons CC BY-SA 2.0 Lizenz veröffentlicht.
Jetzt erhältlich
Das Manifest für menschliche Führung wird erwachsen. Komplett überarbeitet und deutlich erweitert sind die 6 Thesen und 14 Prinzipien für eine neue Führung im Zeitalter der Digitalisierung ab 14. Februar 2024 als Hardcover in hochwertiger Leinenbindung erhältlich.
12 Kommentare
Diese Schlussfolgerung: „Bei derartig komplexen Problemstellungen sollte unbedingt eine iterative Vorgehensweise gewählt werden.… bis .…. Es geht letztlich darum Erfahrungen zu sammeln, es geht um Feedback. Und das kontinuierlich und schnell.“ ist ja eine bekannte Erkenntnis – lässt sich aber nicht mit einem PROJEKT-basierten Vorgehen vereinbaren. Das haben ja auch schon viele Leute erkannt, so etwa Ayelt Komus (siehe Kapitel „3.2. Konzepte und Praktiken des agilen Managements von Projekten“ in http://www.korn.ch/archiv/publikationen/Neuer-Wein-in-alte-Schlaeuche-oder-Deja-vu.pdf) oder Dean Leffingwell.
Aber auch Ken Schwaber schreibt ganz klar in http://www.jeffsutherland.org/oopsla/schwaber.html das:
„Scrum is concerned with the management, enhancement and maintenance of an existing product, while taking advantage of new management techniques and the axioms listed above. Scrum is not concerned with new or re-engineered systems development efforts.“
Es geht also darum, sich endlich davon zu lösen, alles als „Projekte“ zu managen sondern besser eine kontinuierliche Entwicklung über eine längere Zeitspanne anzustreben.
Danke für diesen Kommentar!
Wenn man Projekt tatsächlich sehr klassisch definiert, also als fester Umfang / Ziel, feste Zeit und Kosten, dann stimme ich dem uneingeschränkt zu. Und doch werden weiterhin Projekte gemacht oder solche Vorhaben Projekte genannt, die eigentlich keine sein sollten. Das gilt es zu erkennen und dann wenigstens innerhalb dieses Rahmens des „Projekts“ passend vorzugehen.
„Das gilt es zu erkennen und dann wenigstens innerhalb dieses Rahmens des “Projekts” passend vorzugehen.“
Passend vorzugehen könnte auch bedeuten, die bereits seit den 90er-Jahren bei PRINCE2 vorhandene Möglichkeit intensiver zu nutzen, das Gesamtprojekt in mehrere – eher kurze – „Durchführungsphasen“ zu unterteilen (wobei jede ein „Produktinkrement“ liefert), und nach jeder (genau dem PRINCE2 folgend) den „Business Case“ auf seine weiterhin gegebene Berechtigung zu überprüfen, eine Retrospektive zur gerade abgeschlossenen Phase zu machen und erst JETZT die folgende Durchführungsphase im Detail zu planen.
Offenbar wird PRINCE2 jedoch grossmehrheitlich nicht so genutzt sondern als Rahmen für die üblichen „Wasserfallphasen“.
Da frage ich mich schon:
Was müsste denn anders sein, damit PRINCE2 tatsächlich als Rahmen für ein inkrementell-adaptives Vorgehen genutzt wird? An PRINCE2 als Framework kann es nicht liegen – dieses ermuntert ja genau dazu .…
Mit der Antwort auf diese Frage könnte vielleicht auch erkannt werden, wie es denn möglich wäre, Scrum bei grösseren Projekten nicht erst in der Realisierungsphase von ingesamt „wasserfallartigen“ Projekten einzusetzen, also nicht so, wie z.B. hier in slide 9 beschrieben: http://www.ch-open.ch/fileadmin/user_upload/events/itbeschaffungskonferenz2013/08_DanielWild_AusschreibungAgilerSoftwareprojekte.pdf
Genau darum geht es: iterariv-inkrementell vorzugehen war ja noch nie verboten und wäre oft angeraten. Und zwar nicht nur während der Realisierung. All das findet sich schon seit Jahren im Rational-Unified-Process (RUP). Das Wissen wäre da, wir haben aber ein mächtiges Umsetzungsproblem. Insbesondere in großen, hierarchischen Industrieunternehmen, also dort wo den 5‑Jahres-Plänen und der Steuerung über Budgets gefrönt wird. Ob und in dieser feindlichen Umwelt ein vernünftiges Vorgehen möglich ist, das ist die Frage.
Danke für den guten Blog-Post Marcus. Ja, es ist bemerkenswert, dass sich immer noch viele nicht vorstellen können, dass man Projekte sinnvollerweise nicht so abwickelt, dass die Daumenschrauben auf allen Variablen des Projekts absolut festgezurrt werden. Ich glaube persönlich, dass in dem Fall sogar die erfolgreichen Projekte dadurch erfolgreich sind, indem sie schön geredet werden. Einzig sinnvoller Ansatz in großen Projekten (so die überhaupt als sinnvoll erachtet werden) und in komplexen Umwelten: das oben beschrieben iterative Vorgehen mit kurzen Feedbackschleifen und ein variabler Scope!
Projekt kann dann durchaus „Projekt“ heißen. Aber es läuft nicht mehr mit F. Taylor, H. Ford oder H. Gantt im Team ab. Es hat Leute wie R. Ackoff, E. Deming, P. Drucker, H. Mintzberg, G. Hamel etc etc an Bord und beginnt erstaunlich erfolgreiche Ergebnisse hervorzubringen.
Da ich gerade kürzlich selbst ein Agile-Projekt im Automotive-Business abgewickelt habe – 2 Beispiele in eigener Sache: BMW entwickelt die Prozesse für die Motorenproduktion unter Einsatz von Scrum, Johnson Controls nutzt Scrum, um die neue Fahrzeugsitze zu engineeren.
Wie’s so schön heißt: der Planungsprozess ist alles, Pläne selbst sind wertlos ;)
lg. Mike
Danke Mike für Deinen Kommentar. Ich mache ja auch viele Projekt im Automotive-Umfeld, allerdings nur IT. Ich finde es sehr erstaunlich und befremdlich wie fortschrittlich Automobilhersteller bei den Fahrzeugprojekten selbst agieren und wie anders die Welt im gleichen Konzern bei IT-Projekten aussieht. Hier gibt es einen deutlichen Klassenunterschied zwischen Projekten die direkt was mit dem Fahrzeug zu tun haben und solchen die nur indirekt damit zu tun haben (und das sind ja die meisten IT-Projekte, wenn es nicht gerade Software ist, die ins Auto verbaut wird).
Wahrscheinlich liegt es daran, dass alles was direkt mit dem Fahrzeug zu tun hat eher greifbar ist. Daher setzt man da auch sehr schnell neue Methodiken ein. Man sieht das Ergebnis direkt.
Bei den IT Projekten dauert alles einfach zu lange und bis die Auswirkung dann tatsächlich sichtbar sind dauert es eben nochmal so lange. Schade eigentlich.
Meiner Meinung nach liegt es daran, dass bei einem Automobilhersteller das Auto eben das Produkt ist und das bekommt die allerhöchste Aufmerksamkeit. Das erkennt man auch gut daran welche Ressorts einen eigenen Vorstand haben. Und welche nicht. Beispielsweise die IT.
Ich habe genug Kollegen gehabt, die ihr Selbstwertgefühl über die Größe des Projektes definierten, das sie geleitet haben. In hierarchischen Organisationen ist dieser Ansatz nicht selten: Wichtig ist nur, wer die großen Räder dreht. Da passt die Empfehlung „start small“ überhaupt nicht ins Schema.
Dazu kommt, dass wir keine „Kultur des Scheiterns“ haben. Damit meine ich nicht, dass man Vorhaben gedankenlos zunichte machen sollte, sondern dass man nur durch Versuch und Irrtum lernt und schließlich besser wird. Wer aber den ersten Versuch per Definition zur Ideallösung erklärt, der wird niemals besser.
Zuletzt ist es so, dass in IT-Projekten sich jeder befähigt sieht, in die Planung einzugreifen. In dieser Branche ist das tatsächlich verbreiteter als in nicht-digitalen Bereichen: Wer schreibt schon seiner Autowerkstatt vor, wie die das Fahrzeug repariert? Bei IT-Projekten fühlt sich jeder hingegen ein wenig als Fachmann. Wenn das mit den zwei oben erwähnten Effekten zusammenkommt, dann ergibt das narzistische Idioten, die Projekte versauen und daraus nicht lernen.
qed.
Danke für Deine Ergänzungen! „Kultur des Scheiterns“ passt eben so gar nicht zu klassischen, hierarchisch organisierten Industrieunternehmen.
Sehr schöner Blog, der endlich einmal ein wichtiges Thema aufgreift, dass die Änderung der IT erst nach dem Abschluss des Change Projektes geplant werden sollte. Ich habe auch die Erfahrung des öfteren machen dürfen und kann das nur unterstreichen.
Auch gut: Kultur des Scheiterns => hier sehe ich die Verbände gebetsmühlenartig über Lessons Learned reden, es macht aber keiner! => der Vorteil der Agilisten ist oft, dass die Retrospektive Bestandteil des Projektes während der Laufzeit wird und man nicht erst auf das Ende wartet, um dann doch nichts zu lernen.
Kultur des Scheiterns: Ich habe oft in den Großunternehmen folgende Spielart der „Kultur des Scheiterns“ kennen gelernt => Je höher der Wert (also die Miesen) eines Projektes, das gescheitert ist, war, desto höher wurde anschließend der Projektleiter befördert. => Diese Kultur beflügelt das Scheitern von Projekten enorm :-)
Zur Oxford/McKinsey-Studie: Der Fragebogen war zwar sehr gut, allerdings noch sehr antiquiert klassisch und rein auf Messmethoden wie z.B. Function Points reduziert.
Danke Roland! Ich kenne große Unternehmen in denen sich IT-Projekte in weniger al 12 Monaten rechnen müssen, sprich schnell einen Nutzen bringen sollen. Dann wird eben alles, sprich Change Projekt und IT Projekt, gleichzeitig durchgeführt.
Das ist ja auch konsequent denjenigen dann möglichst weit vom eigentlichen Projektgeschehen wegzubefördern …