Wir leben in einer Zeit, in der es „normal ist, dass vieles anders ist und immer schneller anders wird“, wie der Zeitforscher Karl-Heinz Geißler treffend feststellte. Für dieses Phänomen der Beschleunigung, der Komplexität und der damit einhergehenden Unsicherheit hat sich in letzter Zeit das Akronym VUCA (kurz für volatility, uncertainty, complexity und ambiguity) etabliert. An die Stelle von Stabilität und Effizienz treten Agilität und Effektivität. Veränderung wird die Regel. Projekte, als Konstrukt zur Überführung eines stabilen Zustands in den nächsten, haben ausgedient.
Intelligence is the ability to adapt to change.
Stephen Hawking
IT-Systeme werden in den meisten Organisationen behandelt wie Maschinen: Sie werden beschafft oder gebaut und dann betrieben und gewartet. Sowohl die initiale Bereitstellung als auch jede größere Veränderung wird als Projekt durchgeführt. Diese Umbaumaßnahmen stören den stabilen Regelbetrieb und müssen minimiert werden. Einerseits. Andererseits sichern diese Umbauten die Wettbewerbsfähigkeit der Organisation, weil sie Geschäftsprozesse optimieren und im Zuge der Digitalisierung immer mehr auch völlig neue Geschäftsmodelle ermöglichen.
Je mehr „VUCA“ also das Umfeld einer Organisation ist, desto wichtiger werden time-to-market und cost-of-delay neben einem stabilen Betrieb. Desto weniger passt aber auch diese etablierte Sicht auf IT-Syteme und Systemlandschaften. Die zugrundeliegende Annahme, dass IT-Systeme wie Maschinen beschafft, betrieben und gewartet werden müssen, ist zwar nicht falsch, ignoriert aber die prinzipiell viel höhere Flexibilität von Software. Solange das alle so machen und solange die Märkte träge und weit sind ist das auch kein Problem. Es wird aber schnell zum Problem, wenn neue agilere Wettbewerber in die inzwischen gesättigten Märkte eintreten, wie das im Moment beispielsweise im Automarkt der Fall ist. Und dann nutzt es auch wenig, wie in dem Comic von Geek&Poke (veröffentlicht unter einer Creative Commons CC BY 3.0 Lizenz) oben, einen Teil der Projekte agil zu machen.
Wir arbeiten in Strukturen von Gestern mit Methoden von heute an Strategien für Morgen vorwiegend mit Menschen, die die Strukturen von gestern geschaffen haben und das Übermorgen in der Unternehmung nicht mehr erleben werden.
Knut Bleicher
Der eigentliche Wandel in der agilen Transformation ist es also, nicht Projekte jetzt nach anderer Methode durchzuführen, sondern die Veränderung als gewünschten Normalzustand zu begreifen, freilich ohne Stabilität zu verlieren. Nicht ohne Grund ist Scrum eine Methode zur Produktentwicklung und nicht ohne Grund heißt eine der zentralen Rollen im Scrum Product-Owner und eben nicht Project-Owner. IT-Projekte sind Auslaufmodelle. Sie werden abgelöst durch Produkte mit zugehörigen festen Teams, die ihren Ausschnitt der IT-Systemlandschaft permanent an die Anforderungen der Märkte und der Organisation anpassen und gleichzeitig stabil betreiben.
11 Kommentare
Hallo Marcus,
das Bild errinnert mich an Deinen „Tanz auf der Titanic“… Daumen hoch ;o)
Bin noch ein wenig im Widerstand mit der Vorstellung,
dass IT-Projektmanagement ausgedient haben soll.
Dass „das Dreieck“ eher ins Museum gehört – ok,
aber ich frage mich, wer „erkennt“ zB die „Windows of Opportunities“ (Komplexe IT-Systeme neigen doch sehr zur Pfadabhängigkeit) und bringt zB einen TechnoChange an den Start bzw. zur Umsetzung (wenn neue Technologien zu neuen – deutlich verbesserten – Möglichkeiten führen)?
Ich persönlich könnte mir genausogut Vorstellen, dass das IT-PM zukünftig deutlich anspruchsvoller wird…
Frei nach dem Motto: Integriertes Projekt- und Prozessmanagement zur Produktentwicklung. – oder ähnlich.
In dem Falle wäre der Output (und Fokus) ein Produkt,
der Input Produkte (aus anderen „Projekten oder Prozessen“)
ein lernfähiger! „Prozess“ würde das Produkt erstellen
– …und der Rahmen des Ganzen, wäre ein Projekt (zB Für die Dauer des Lebenszyklus der Technologie)
ME wäre durch die Projektform „der Rahmen“ eben auch anpassbar…
.…nur mal so als Idee.
PS:
Ich persönlich halte einen Technochange an sich schon für deutlich anspruchsvoller,
als es ein reines IT-Projekt (oder eine Produktentwicklung) ist.
Ein schönes verlängertes
Wochenende wünschend,
Bernd
Lieber Bernd, vielen Dank für deinen Kommentar. Das klassische IT-Projekt hat ausgedient, da sind wir uns glaube ich einig. Ich könnte mir tatsächlich noch Projekte vorstellen, um Änderungen an vielen Systemen / Produkten zu koordinieren, aber da mag es auch andere Möglichkeiten geben.
Ja Marcus,
kann sein, dass es da andere Möglichkeiten gibt. Schließlich ergeben sich viele Dinge auch „von allein“…
Genau solche Koordinationsgeschichten meinte ich.
Nicht unbedingt um das Ganze zu kontrollieren, sondern eher um Reibung zu minimieren…
…und einmalige Dinge, deren Verlauf absehbar Endlich ist und die Zeit + Energie benötigen von den Kontinuierlichen zu unterscheiden.
Allerdings gibt es ja nicht nur technikfeindliche Menschen, sondern auch solche, für die Technologie eine
Art Religion ist…
.…also sollte man da vlt tatsächlich besser die Finger von lassen. ;o)
Nun hab ich aber genug „philosophiert“ – in diesem Sinne einen schönen Feiertag!
Bernd
Lieber Bernd, dann sind wir uns ja einig: es wird auch weiterhin komplexe Koordinationsaufgaben geben. Das als Projekt zu gestalten und zu managen ist nur eine Lösung, die wenn es wirklich einmalige Vorhaben sind, auch sinnvoll sein kann, dann aber sehr anspruchsvoll sein wird.
Ja Marcus, da sind wir uns einig.
Vielleicht ist der Begriff DevOps:
https://de.wikipedia.org/wiki/DevOps
für den Einen oder Anderen noch interessant.…
Bestimmt. Besonders bei DevOps erkennt man nämlich, dass es nicht um Projekte (zeitlich befristet), sondern um die kontinuierliche und flexible Weiterentwicklung von Produkten geht.
Ihr erkennt aber schon die Ironie
„Endlich agil!“ durch
„Produkte mit zugehörigen festen Teams“
Als ob du Veränderung nicht auch die Teamzusammensetzung betreffen würde.
Insgesamt finde ich das die Buzzword zu Wörterquote im Text zu hoch ist.
Eigentlich habe ich das „Endlich agil“ auf den falschen Ansatz des einen roten Projekts im Bild bezogen. Kann man aber missverstehen. Zwischen ich ändere die Teamzusammensetzung ein bisschen und ich höre auf in Projekten zu denken ist aber doch ein kleiner Unterschied, oder?
Lieber Max,
einen Technochange zeichnet aus, dass sich die Teamzusammensetzung bzw. das sich die Organisation ändert.
Tut sie das nicht, kann man wunderbar erkennen, daß die Strukturen die Prozesse behindern…;o)
Früher hat man mancherorts eben nicht auf Gemeinschaftsbildung, sondern auf CliquenBildung und Konkurrenz gesetzt, wo Gemeinschaft und Kooperation angebrachter gewesen wäre…
…Bleibt die Frage was wie ironischer ist. Beim Alten bleiben zu wollen, während sich Alles immer schneller verändert, oder „mitzuziehen“.
Moin, moin.
Vielen Dank für den Blogartikel. Er hat mich gerade mit dem Satz „Projekte, als Konstrukt zur Überführung eines stabilen Zustands in den nächsten (…)“ zum Nachdenken über eine große IT-Infrastrukturänderung in unserem Unternehmen gebracht, welches ich zu stark als die Überführung eines festen Zustands in einen nächsten betrachtet und vielleicht zu wenig agil gedacht habe. Das letztere ist eigentlich mein Wunsch für meine Denkweise und Planungsart.
Ich hätte den Artikel gerne geflattred, leider gibt es für den Artikel ein Fehler bei flattr: „User couldn’t be found and no owner specified.“.
Grüße,
Michael.
Vielen Dank für Deinen Kommentar, lieber Michael. Es freut mich sehr, wenn ich Dich zum Nachdenken anregen konnte. Und danke für den Hinweis mit Flattr: jetzt sollte es funktionieren.