Jede Organisation hat ihr Tagesgeschäft. Die einen verkaufen online Waren, die anderen bauen Autos und die nächsten vermitteln Privatwohnungen als Hotelzimmer. Dafür haben diese Organisationen ihre jeweiligen Prozesse, Rollen und jede ihre IT und insbesondere ihre Software, die immer wichtiger wird. So weit, so generisch. Die viel spannendere Frage ist, wie Organisationen den Status quo ihres Tagesgeschäfts, ihre Prozesse und ihre Software weiterentwickeln. Und noch spannender ist, wie schnell ihnen das gelingt und wie anpassungsfähig sie das macht.
In den meisten Organisationen findet diese Weiterentwicklung im Rahmen von Projekten statt. Nicht weil das die am besten geeignete Methode ist, sondern weil es die einzige bekannte und akzeptierte ist und weil wer als Werkzeug nur einen Hammer hat in jedem Problem einen Nagel sieht (Paul Watzlawick). Das dauert dann natürlich gerade in hierarchischen Organisationen immer ein bisschen bis man sich zu einem Projekt entschlossen hat. Schließlich muss man ja genau wissen, was es kostet und was es bringt, einen Business-Case eben mit Return-on-Invest und so. Wie soll man denn sonst entscheiden? Und weil das immer ein bisschen dauert, macht man Projekte lieber größer und am besten gleich zu Programmen. Dann lohnt sich der ganze bürokratische Aufwand wenigstens und man hat ein paar Jahre Ruhe.
Die Erfolgswahrscheinlichkeit solcher Großprojekte ist im IT-Bereich eher überschaubar, wie zum Beispiel die Studie der Universität Oxford und des Beratungshauses McKinsey mit etwa 1500 Projekten mit einem durchschnittlichen Volumen von 170 Millionen US-Dollar zeigte: „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.“ (Quelle: CIO 11.10.2011 aus einer Studie von Oxford und McKinsey). Entsprechend deutlich das ernüchternde Fazit:
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
Doch selbst wenn solche Projekte erfolgreich wären nach der klassischen Definition und den geforderten Umfang in Zeit, Kosten und Qualität lieferten, könnten sie trotzdem paradoxerweise ein Misserfolg sein. Nämlich dann wenn sie zwar liefern, was damals gewünscht war, das aber nicht mehr zu dem passt, was heute wirklich gebraucht wird. Gerade in der IT sind drei oder gar fünf Jahre eine Ewigkeit, für Großprojekte aber ein ganz normaler Planungshorizont. Das Problem sind also nicht Projekte per se oder fehlende Fähigkeiten im Projektmanagement, sondern dass die Veränderung als Ausnahme betrachtet und entsprechend schwerfällig gehandhabt wird: Ein Projekt ist etwas was zusätzlich gemacht werden muss oder was andere machen und man danach wieder „normal“ und vielleicht sogar besser seiner eigentlichen Arbeit nachgehen kann.
So gesehen ist ein agiles Großprojekt zwar in gewisser Weise besser als eines nach Wasserfall-Methode, aber eben auch keine Lösung für die Schwerfälligkeit der Organisation im Großen. Im Gegenteil der Versuch, das richtige Leben im falschen zu realisieren verhindert echte Agilität auf Organisationsebene, denn sie lässt das Projekt als wesentlichen Mechanismus, die Organisation und ihre Abläufe zu verändern, unangetastet. Oder mit den Worten von Richard David Precht: „Wir dekorieren auf der Titanic die Liegestühle um!“
Gerade in schnelllebigen Branchen – und durch die immer stärkere Durchdringung mit Software und eine Vielzahl neuer Technologien mit disruptivem Potential sind dies immer mehr Branchen – sind Projekte als Methode der Veränderung zu langsam, egal wie agil sie sind. Darum findet man bei agilen Unternehmen wie Spotify, Amazon und Co. in der Regel keine Projekte. Stattdessen kleine autonome interdisziplinäre Teams mit einer Ende-zu-Ende-Verantwortung für ihren (kleinen) Ausschnitt der Wertschöpfung. Und diese entwickeln ihr Produkt oder ihren Service in Abstimmung mit anderen Teams anhand gemeinsamer Leitlinien und einer gemeinsamen Vision kontinuierlich weiter. Sie probieren aus, verwerfen, passen an, verwerfen wieder, passen erneut an. Dieser Kreislauf endet eigentlich nie oder nur wenn es das Produkt oder den Service nicht mehr braucht. Die Veränderung ist integraler Bestandteil des Tagesgeschäft geworden und muss nicht umständlich als Projekt beauftragt werden. Diese organische Entwicklung kann man gar nicht zentral steuern – Führung ist deshalb umso wichtiger.
2 Kommentare
Schöner Artikel. Was ich noch unterstreichen möchte, ist der scheinbare Wandel mit dem Umgang von Veränderung. Vor einiger Zeit erlebte ich noch Manager, für die war die Veränderung eher der „Feind“ des Tagesgeschäftes – Zusatzaufgaben, Zusatzaufwand, womöglich noch Störung in operativen Abläufen. Heute kann ich immer mehr eine veränderte Haltung wahrnehmen – Veränderung gehört zum „Tagesgeschäft“, ist Chance und Herausforderung. Hier entsteht die spannende Frage, wie sollten wir uns Wandeln (Strategie, Strukturen/Prozesse, Menschen, Kultur), damit Veränderung und Weiterentwicklung zum „Normalbetrieb“ gehört und nicht in Projekte ausgelagert wird / werden muss.
Löse ich mich etwas von der IT-/Organisationswelt, sehe ich als Aufgabe und Chance der einzelnen Person, den eigenen Umgang mit Veränderung (Neues, Förderliches, Aufregendes, Fremdes, Unvorhergesehenes, Plötzliches, …) immer wieder zu hinterfragen und ggfs. weiterzuentwickeln. Die Arbeit an der eigenen Haltung, die dann in den unterschiedlichen Welten zur Wirkung kommt – sei es in Organisation, Profession oder Privat.
Sehr richtig: die entscheidende Frage ist, wie wir mit Veränderung und Unsicherheit umgehen. Eher ängstlich und vermeidend oder eher neugierig und offen. Dazu kommt bald noch ein neuer Artikel.