de de de en es es de de de de en it de tr cv en ru es es de de de de en it de de tr cv en ru de de de de de en en de de de de de de de de de nb de en de de de de de de de de de de de de de en de de de de de de de de fi de de de de de de de de de de de de de de de de de de de de de de de de de de de fr de de de de de fr de de de de de de de sv fa it en de en de de en de de
Wir leben in einer Zeit, in der es „nor­mal ist, dass vie­les anders ist und immer schnel­ler anders wird“, wie der Zeit­for­scher Karl-Heinz Geiß­ler tref­fend fest­stell­te. Für die­ses Phä­no­men der Beschleu­ni­gung, der Kom­ple­xi­tät und der damit ein­her­ge­hen­den Unsi­cher­heit hat sich in letz­ter Zeit das Akro­nym VUCA (kurz für vola­ti­li­ty, uncer­tain­ty, com­ple­xi­ty und ambi­gui­ty) eta­bliert. An die Stel­le von Sta­bi­li­tät und Effi­zi­enz tre­ten Agi­li­tät und Effek­ti­vi­tät. Ver­än­de­rung wird die Regel. Pro­jek­te, als Kon­strukt zur Über­füh­rung eines sta­bi­len Zustands in den nächs­ten, haben ausgedient.
Intel­li­gence is the abi­li­ty to adapt to change.
IT-Sys­te­me wer­den in den meis­ten Orga­ni­sa­tio­nen behan­delt wie Maschi­nen: Sie wer­den beschafft oder gebaut und dann betrie­ben und gewar­tet. Sowohl die initia­le Bereit­stel­lung als auch jede grö­ße­re Ver­än­de­rung wird als Pro­jekt durch­ge­führt. Die­se Umbau­maß­nah­men stö­ren den sta­bi­len Regel­be­trieb und müs­sen mini­miert wer­den. Einer­seits. Ande­rer­seits sichern die­se Umbau­ten die Wett­be­werbs­fä­hig­keit der Orga­ni­sa­ti­on, weil sie Geschäfts­pro­zes­se opti­mie­ren und im Zuge der Digi­ta­li­sie­rung immer mehr auch völ­lig neue Geschäfts­mo­del­le ermög­li­chen.
Je mehr „VUCA“ also das Umfeld einer Orga­ni­sa­ti­on ist, des­to wich­ti­ger wer­den time-to-mar­ket und cost-of-delay neben einem sta­bi­len Betrieb. Des­to weni­ger passt aber auch die­se eta­blier­te Sicht auf IT-Syte­me und Sys­tem­land­schaf­ten. Die zugrun­de­lie­gen­de Annah­me, dass IT-Sys­te­me wie Maschi­nen beschafft, betrie­ben und gewar­tet wer­den müs­sen, ist zwar nicht falsch, igno­riert aber die prin­zi­pi­ell viel höhe­re Fle­xi­bi­li­tät von Soft­ware. Solan­ge das alle so machen und solan­ge die Märk­te trä­ge und weit sind ist das auch kein Pro­blem. Es wird aber schnell zum Pro­blem, wenn neue agi­le­re Wett­be­wer­ber in die inzwi­schen gesät­tig­ten Märk­te ein­tre­ten, wie das im Moment bei­spiels­wei­se im Auto­markt der Fall ist. Und dann nutzt es auch wenig, wie in dem Comic von Geek&Poke (ver­öf­fent­licht unter einer Crea­ti­ve Com­mons CC BY 3.0 Lizenz) oben, einen Teil der Pro­jek­te agil zu machen.
Wir arbei­ten in Struk­tu­ren von Ges­tern mit Metho­den von heu­te an Stra­te­gien für Mor­gen vor­wie­gend mit Men­schen, die die Struk­tu­ren von ges­tern geschaf­fen haben und das Über­mor­gen in der Unter­neh­mung nicht mehr erle­ben werden.
Der eigent­li­che Wan­del in der agi­len Trans­for­ma­ti­on ist es also, nicht Pro­jek­te jetzt nach ande­rer Metho­de durch­zu­füh­ren, son­dern die Ver­än­de­rung als gewünsch­ten Nor­mal­zu­stand zu begrei­fen, frei­lich ohne Sta­bi­li­tät zu ver­lie­ren. Nicht ohne Grund ist Scrum eine Metho­de zur Pro­dukt­ent­wick­lung und nicht ohne Grund heißt eine der zen­tra­len Rol­len im Scrum Pro­duct-Owner und eben nicht Pro­ject-Owner. IT-Pro­jek­te sind Aus­lauf­mo­del­le. Sie wer­den abge­löst durch Pro­duk­te mit zuge­hö­ri­gen fes­ten Teams, die ihren Aus­schnitt der IT-Sys­tem­land­schaft per­ma­nent an die Anfor­de­run­gen der Märk­te und der Orga­ni­sa­ti­on anpas­sen und gleich­zei­tig sta­bil betreiben.
Bernd 2. Oktober 2016 Antworten
das Bild err­in­nert mich an Dei­nen „Tanz auf der Tita­nic“… Dau­men hoch ;o)
Bin noch ein wenig im Wider­stand mit der Vorstellung,
dass IT-Pro­jekt­ma­nage­ment aus­ge­dient haben soll.
Dass „das Drei­eck“ eher ins Muse­um gehört – ok,
aber ich fra­ge mich, wer „erkennt“ zB die „Win­dows of Oppor­tu­nities“ (Kom­ple­xe IT-Sys­te­me nei­gen doch sehr zur Pfad­ab­hän­gig­keit) und bringt zB einen Tech­no­Chan­ge an den Start bzw. zur Umset­zung (wenn neue Tech­no­lo­gien zu neu­en – deut­lich ver­bes­ser­ten – Mög­lich­kei­ten führen)?
Ich per­sön­lich könn­te mir genau­so­gut Vor­stel­len, dass das IT-PM zukünf­tig deut­lich anspruchs­vol­ler wird…
Frei nach dem Mot­to: Inte­grier­tes Pro­jekt- und Pro­zess­ma­nage­ment zur Pro­dukt­ent­wick­lung. – oder ähnlich.
In dem Fal­le wäre der Out­put (und Fokus) ein Produkt,
der Input Pro­duk­te (aus ande­ren „Pro­jek­ten oder Prozessen“)
ein lern­fä­hi­ger! „Pro­zess“ wür­de das Pro­dukt erstellen
– …und der Rah­men des Gan­zen, wäre ein Pro­jekt (zB Für die Dau­er des Lebens­zy­klus der Technologie)
ME wäre durch die Pro­jekt­form „der Rah­men“ eben auch anpassbar…
.…nur mal so als Idee.
Ich per­sön­lich hal­te einen Tech­no­chan­ge an sich schon für deut­lich anspruchsvoller,
als es ein rei­nes IT-Pro­jekt (oder eine Pro­dukt­ent­wick­lung) ist.
Marcus Raitner (Autor) 2. Oktober 2016 Antworten
Lie­ber Bernd, vie­len Dank für dei­nen Kom­men­tar. Das klas­si­sche IT-Pro­jekt hat aus­ge­dient, da sind wir uns glau­be ich einig. Ich könn­te mir tat­säch­lich noch Pro­jek­te vor­stel­len, um Ände­run­gen an vie­len Sys­te­men / Pro­duk­ten zu koor­di­nie­ren, aber da mag es auch ande­re Mög­lich­kei­ten geben.
Bernd 3. Oktober 2016 Antworten
kann sein, dass es da ande­re Mög­lich­kei­ten gibt. Schließ­lich erge­ben sich vie­le Din­ge auch „von allein“…
Genau sol­che Koor­di­na­ti­ons­ge­schich­ten mein­te ich.
Nicht unbe­dingt um das Gan­ze zu kon­trol­lie­ren, son­dern eher um Rei­bung zu minimieren…
…und ein­ma­li­ge Din­ge, deren Ver­lauf abseh­bar End­lich ist und die Zeit + Ener­gie benö­ti­gen von den Kon­ti­nu­ier­li­chen zu unterscheiden.
Aller­dings gibt es ja nicht nur tech­nik­feind­li­che Men­schen, son­dern auch sol­che, für die Tech­no­lo­gie eine
.…also soll­te man da vlt tat­säch­lich bes­ser die Fin­ger von las­sen. ;o)
Nun hab ich aber genug „phi­lo­so­phiert“ – in die­sem Sin­ne einen schö­nen Feiertag!
Marcus Raitner (Autor) 3. Oktober 2016 Antworten
Lie­ber Bernd, dann sind wir uns ja einig: es wird auch wei­ter­hin kom­ple­xe Koor­di­na­ti­ons­auf­ga­ben geben. Das als Pro­jekt zu gestal­ten und zu mana­gen ist nur eine Lösung, die wenn es wirk­lich ein­ma­li­ge Vor­ha­ben sind, auch sinn­voll sein kann, dann aber sehr anspruchs­voll sein wird.
Bernd 16. Oktober 2016
Ja Mar­cus, da sind wir uns einig.
Viel­leicht ist der Begriff DevOps:
für den Einen oder Ande­ren noch interessant.…
Marcus Raitner (Autor) 16. Oktober 2016
Bestimmt. Beson­ders bei Dev­Ops erkennt man näm­lich, dass es nicht um Pro­jek­te (zeit­lich befris­tet), son­dern um die kon­ti­nu­ier­li­che und fle­xi­ble Wei­ter­ent­wick­lung von Pro­duk­ten geht.
Max 3. Oktober 2016 Antworten
Ihr erkennt aber schon die Ironie
„Pro­duk­te mit zuge­hö­ri­gen fes­ten Teams“
Als ob du Ver­än­de­rung nicht auch die Team­zu­sam­men­set­zung betref­fen würde.
Ins­ge­samt fin­de ich das die Buz­z­word zu Wör­ter­quo­te im Text zu hoch ist.
Marcus Raitner (Autor) 3. Oktober 2016 Antworten
Eigent­lich habe ich das „End­lich agil“ auf den fal­schen Ansatz des einen roten Pro­jekts im Bild bezo­gen. Kann man aber miss­ver­ste­hen. Zwi­schen ich ände­re die Team­zu­sam­men­set­zung ein biss­chen und ich höre auf in Pro­jek­ten zu den­ken ist aber doch ein klei­ner Unter­schied, oder?
Bernd 3. Oktober 2016 Antworten
einen Tech­no­chan­ge zeich­net aus, dass sich die Team­zu­sam­men­set­zung bzw. das sich die Orga­ni­sa­ti­on ändert.
Tut sie das nicht, kann man wun­der­bar erken­nen, daß die Struk­tu­ren die Pro­zes­se behindern…;o)
Frü­her hat man man­cher­orts eben nicht auf Gemein­schafts­bil­dung, son­dern auf Cli­quen­Bil­dung und Kon­kur­renz gesetzt, wo Gemein­schaft und Koope­ra­ti­on ange­brach­ter gewe­sen wäre…
…Bleibt die Fra­ge was wie iro­ni­scher ist. Beim Alten blei­ben zu wol­len, wäh­rend sich Alles immer schnel­ler ver­än­dert, oder „mit­zu­zie­hen“.
Michael Puls 3. Oktober 2016 Antworten
Vie­len Dank für den Blog­ar­ti­kel. Er hat mich gera­de mit dem Satz „Pro­jek­te, als Kon­strukt zur Über­füh­rung eines sta­bi­len Zustands in den nächs­ten (…)“ zum Nach­den­ken über eine gro­ße IT-Infra­struk­tur­än­de­rung in unse­rem Unter­neh­men gebracht, wel­ches ich zu stark als die Über­füh­rung eines fes­ten Zustands in einen nächs­ten betrach­tet und viel­leicht zu wenig agil gedacht habe. Das letz­te­re ist eigent­lich mein Wunsch für mei­ne Denk­wei­se und Planungsart.
Ich hät­te den Arti­kel ger­ne geflatt­red, lei­der gibt es für den Arti­kel ein Feh­ler bei flattr: „User could­n’t be found and no owner specified.“.
Marcus Raitner (Autor) 3. Oktober 2016 Antworten
Vie­len Dank für Dei­nen Kom­men­tar, lie­ber Micha­el. Es freut mich sehr, wenn ich Dich zum Nach­den­ken anre­gen konn­te. Und dan­ke für den Hin­weis mit Flattr: jetzt soll­te es funktionieren.