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.

Je höher der Wert (also die Miesen) eines Projektes, das gescheitert ist, war, desto höher wurde anschließend der Projektleiter befördert.

Das ist ja auch konsequent denjenigen dann möglichst weit vom eigentlichen Projektgeschehen wegzubefördern …

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 für Deine Ergänzungen! „Kultur des Scheiterns“ passt eben so gar nicht zu klassischen, hierarchisch organisierten Industrieunternehmen.

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.

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.

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.

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.

„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

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).

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