Postindustrielles Projektmanagement

Es könn­te alles so ein­fach sein: Wer macht Was bis Wann. Das ist klas­si­sches Pro­jekt­ma­nage­ment. Das Ziel des Pro­jekts ist eini­ger­ma­ßen bekannt und sta­bil; der Weg dort­hin aus­rei­chend beschil­dert. Weni­ge Pro­jekt­lei­ter pla­nen, koor­di­nie­ren und kon­trol­lie­ren; vie­le Mit­ar­bei­ter füh­ren aus: Pla­nungs­apart­heid. Was aber wenn Zie­le sich ver­än­dern oder sich erst im Lau­fe des Pro­jekts for­men, wenn der Weg sich als Sack­gas­se her­aus­stellt oder erst ein Weg gefun­den wer­den muss? Dann sind Krea­ti­vi­tät und Inno­va­ti­on gefragt und zwar nicht nur die der Projektleiter.

Pro­jek­te sind Zwei-Klas­sen-Sys­te­me: Weni­ge den­ken und len­ken, der Rest führt aus. Unver­kenn­bar die Par­al­le­le zur Orga­ni­sa­ti­on von Groß­un­ter­neh­men, ins­be­son­de­re in der Indus­trie. Ich nen­ne die­se Orga­ni­sa­ti­ons­form des­halb indus­tri­el­les Pro­jekt­ma­nage­ment. Das vor­ran­gi­ge Ziel indus­tri­el­len Pro­jekt­ma­nage­ments ist die Effi­zi­enz. Wenig ver­wun­der­lich, denn dafür wur­de das moder­ne Manage­ment schließ­lich erfun­den. Unter bestimm­ten Rah­men­be­di­nun­gen funk­tio­niert indus­tri­el­les Pro­jekt­ma­nage­ment auch sehr gut. Näm­lich dann, wenn die Kom­ple­xi­tät so gering ist, dass die Krea­ti­vi­tät der pla­nen­den Klas­se aus­reicht, um die auf­tre­ten­den Hin­der­nis­se zu bewältigen.

Die­se Gren­ze der durch weni­ge Füh­rungs­kräf­te beherrsch­ba­ren Kom­ple­xi­tät haben wir in vie­len Pro­jek­ten, ins­be­son­de­re in der IT, schon lan­ge über­schrit­ten. Fol­ge­rich­tig haben sich, wie­der­um ins­be­son­de­re in der IT, For­men von post­in­dus­tri­el­lem Pro­jekt­ma­nage­ment im letz­ten Jahr­zehnt ent­wi­ckelt. Vor­ran­gi­ges Ziel dabei ist nicht mehr die Effi­zi­enz, son­dern krea­ti­ve Lösun­gen, Inno­va­ti­on und Anpas­sungs­fä­hig­keit in insta­bi­lem Umfeld. Agi­li­tät heißt das Schlag­wort (vgl. das Agi­le Mani­fest). Wesent­li­ches Merk­mal die­ser post­in­dus­tri­el­len For­men von Pro­jekt­ma­nage­ment ist die Ten­denz zur Selbst­or­ga­ni­sa­ti­on. Nicht nur weil es mensch­li­che­re Arbeits­be­din­gun­gen bedeu­tet, son­dern weil die Weis­heit der Vie­len in unsi­che­ren Situa­tio­nen bes­se­re Ergeb­nis­se verspricht.

Wenn nun die pla­ne­ri­schen, koor­di­nie­ren­den und kon­trol­lie­ren­den Tätig­kei­ten zuneh­mend selbst­or­ga­ni­siert durch­ge­führt wer­den, was wird dann aus dem Pro­jekt­ma­na­ger? Ich mei­ne: Hil­fe zur Selbst­or­ga­ni­sa­ti­on. Die vor­ran­gi­ge Auf­ga­be eines post­in­dus­tri­el­len Pro­jekt­ma­na­gers ist die Gestal­tung eines tem­po­rä­ren sozia­len Sys­tems, das in der Lage ist selbst­or­ga­ni­siert die Pro­jekt­auf­ga­ben zu bewältigen.

Bildnachweis

Das Arti­kel­bild wur­de von Paul Bai­ley unter dem Titel „bob­by“ auf Flickr unter einer Crea­ti­ve-Com­mons Lizenz (CC BY-SA 2.0) ver­öf­fent­licht.

Share This Post

Von Marcus Raitner

Hi, ich bin Marcus. Ich bin der festen Überzeugung, dass Elefanten tanzen können. Daher begleite ich Organisationen auf ihrem Weg zu mehr Agilität. Über die Themen Führung, Digitalisierung, Neue Arbeit, Agilität und vieles mehr schreibe ich seit 2010 in diesem Blog. Mehr über mich.

10 Kommentare

Mal ehr­lich: mir ist das zu ein­fach. Sicher, Pro­jekt­ma­nage­ment baut auf dem Ope­ra­ti­ons Rese­arch des letz­ten Jahr­tau­send auf und ist heu­te in vie­len Berei­chen so – wie ursprüng­lich gedacht – nicht mehr anwend­bar. Aller­dings: es arbei­tet doch heu­te wirk­lich kaum noch ein Pro­jekt­ma­na­ger mehr so wie sie oben beschrei­ben! Ich arbei­te in der Auto­mo­bil­in­dus­trie, da wird natür­lich auch viel geplant, aber das Pro­dukt ent­steht weit­ge­hend in Selbst­or­ga­ni­sa­ti­on, da sind näm­lich ganz vie­le Unter­neh­men dar­an betei­ligt, denen ich gar nicht vor­schrei­ben kann, was sie wann wie und so wei­ter tun müs­sen, die sind ja recht­lich auto­nom. Pla­nung gibt da einen wich­ti­gen Rah­men vor( Qua­li­ty Gates) und syn­chro­ni­siert die betei­lig­ten Unter­neh­men, ohne das wür­de da nie ein Auto raus­kom­men… Und nun zur IT: da wird immer erzählt, dass die Soft­ware­ent­wick­lung so modern sei, und jetzt „post-indus­tri­ell“, war­um sind dann uralte Ansät­ze aus der Indus­trie wie z.B. Kan­Ban gera­de so en vogue??? Das ist mir echt zu viel Schwarz-Weiß gedacht, ist ja auch leicht, auf die ande­ren zu schimp­fen… Wir müs­sen viel mehr die Anfor­de­run­gen der Pro­jek­te ver­ste­hen und auf der Basis dann ent­schei­den, wel­ches Pro­jekt­ma­na­ge­nent oder Füh­rungs­prin­zip das rich­ti­ge ist, das mag ja in vie­len Fäl­len Selbst­or­ga­ni­sa­ti­on und agi­les Vor­ge­hen sein (z.B. in der Auto­mo­bil-Vor­ent­wick­lung), in ande­ren Pro­jek­ten oder Pro­jekt­pha­sen passt es eben nicht, so wie situa­ti­ves Füh­ren eben auch rich­ti­ger ist als Lais­ser Fai­re oder Auto­ri­tär. Für mich lohnt sich da übri­gens auch eher der Blick in das Zeit­al­ter des Hand­werks oder in das Impro­vi­sie­ren (z.B. im Free Jazz), da kön­nen wir wirk­lich ler­nen, wie wir künst­le­risch, erfah­rungs­ge­lei­tet und spie­le­risch neue Ansät­ze und Lösun­gen fin­den, soweit ist alles was ich bis­lang zum Agi­len Pro­jekt­ma­nage­ment gele­sen und gehört habe bis­lang noch nicht gekom­men (alter Wein in neu­en Schläu­chen?). Übri­gens haben wir all das auf der letz­ten InterPM in Glas­hüt­ten dis­ku­tiert und live den Impro­vi­sa­ti­ons­künst­ler Chris­to­pher Dell dazu erle­ben können…

Dan­ke für den kri­ti­schen Kom­men­tar. Ja, die Dar­stel­lung ist schwarz-weiß. Ganz bewusst. Natür­lich arbei­tet heu­te und schon lan­ge nie­mand mehr nach dem ursprüng­li­chen, hier­ar­chi­schen, indus­tri­el­len Pro­jekt­ma­nage­ment. Viel­leicht hat auch nie jemand so gear­bei­tet. Dar­um geht es mir aber auch gar nicht. Es geht mir um die damit ver­bun­de­nen Glau­bens­sät­ze, die dem klas­si­schen Manage­ment ent­stam­men. Und einer davon ist die Zwei­tei­lung der Auf­ga­be und Manage­ment und Aus­füh­rung. Was effi­zi­ent ist und daher auch in bestimm­ten Situa­tio­nen sei­ne Berech­ti­gung habe, in ande­ren aber eben nicht. Und da kommt für mich die Kom­ple­xi­tät des Pro­jekts und die Sta­bi­li­tät des Umfelds in Spiel. Mei­ne Aus­sa­ge ist letzt­lich: Je weni­ger kom­plex, je kla­rer die Anfor­de­run­gen, je sta­bi­ler das Umfeld, des­to eher funk­tio­niert indus­tri­el­les Pro­jekt­ma­nage­ment und funk­tio­niert dann auch effi­zi­en­ter. Ins­be­son­de­re in der IT sind weder die Anfor­de­run­gen klar, noch ist das Umfeld sta­bil. Daher haben sich mei­ner Mei­nung nach dort post-indus­tri­el­le, agi­le For­men bis­her am wei­tes­ten ent­wi­ckelt. (Na gut, auch die leicht anar­chis­ti­sche Nei­gung vie­ler Infor­ma­ti­ker hat das kata­ly­siert.) Ich bin abso­lut der Mei­nung, dass Scrum kei­nes­wegs alter Wein in neu­en Schläu­chen ist. Scrum gibt der Selbst­or­ga­ni­sa­ti­on von Teams eine sehr kla­ren und strik­ten Rah­men. Es geht mir aber auch weni­ger um die kon­kre­te Metho­de. Es geht mir dar­um, dass sich Glau­bens­sät­ze wei­ter­ent­wick­ln hin zu mehr Selbst­or­ga­ni­sa­ti­on und weni­ger Planungsapartheid.

Ich lese her­aus, dass die IT´ler die bes­se­ren (Projekt-)Manager sind. Das gilt es mei­ner Ansicht erst mal zu bewei­sen, vie­le Stu­di­en wider­le­gen das ja auch in regel­mä­ßi­gen Abstän­den, und das Agi­les Pro­jekt­ma­nage­ment bes­se­re Resul­ta­te bringt, hat mir auch noch kei­ner nach­wei­sen kön­nen… Zuge­ge­ben, Selbst­or­ga­nis­ti­on und agi­les Vor­ge­hen klingt modern, ist bes­ser zu ver­kau­fen als all das „klas­si­sche“ Vorgehen… 

Aber was ist wirk­lich anders? Ja, mehr Kom­mu­ni­ka­ti­on, kür­ze­re Tak­tung, mehr Akti­vi­tät des Teams. Selbst­or­ga­ni­sa­ti­on sieht für mich aber anders aus – sie­he mein Ver­gleich zu Free­jazz – kein Takt (Dai­ly Scrum), kei­ne Vor­ga­ben (Pro­duct Back­log, Pro­duct Owner…), wirk­li­ches ein­füh­len, sich indi­vi­du­ell auf­ein­an­der abstim­men, um zu wirk­lich inno­va­ti­ven Lösun­gen Per­for­man­ces zu kom­men. Des­halb blei­be ich bei mei­ner The­se, dass Scrum nur „alter Wein in neu­en Schläu­chen“ ist. In der Pra­xis erle­be ich eh, dass Agi­les Vor­ge­hen in Rein­form eher sel­ten prak­ti­ziert wird, übli­cher sind Misch­for­men oder agil-tra­di­tio­nel­les Vor­ge­hen. Für mich fehlt auch eine dif­fe­ren­zier­te Betrach­tung, bei wel­chen Pro­jek­ten / Anfor­de­run­gen das agi­le Vor­ge­hen über­haupt sinn­voll ist, und wann eben nicht. Nur so kom­men wir wei­ter, nicht aber mit der plum­pen Behaup­tung „agil ist besser“ ;-)

Kei­nes­wegs woll­te ich die IT’­ler als die bes­se­ren Pro­jekt­ma­na­ger dar­stel­len. (Wenn man sich die ver­hee­ren­den Ergeb­nis­se der Stu­die von McK­in­sey und Oxford vor Augen führt wäre das auch ver­mes­sen.) Ich den­ke aller­dings, dass in IT-Pro­jek­ten aus zwei­er­lei Grün­den mehr mit inno­va­ti­ven Kon­zep­ten für Pro­jekt­ma­nage­ment expe­ri­men­tiert wird: ers­tens, weil der Pro­jekt­ge­gen­stand rein digi­tal ist und mehr Expe­ri­men­te der Zusam­men­ar­beit erlaubt und zwei­tens, weil durch den Fach­kräf­te­man­gel von den Mit­ar­bei­tern mehr Manage­ment-Inno­va­ti­on gefor­dert wird. 

Was anders ist in agi­len Ansät­zen? Ich bin sicher­lich kein Exper­te in agi­len Vor­ge­hens­wei­sen, aber betrach­ten wir die ein­fa­che Fra­ge wer über den Plan und die Vor­ge­hens­wei­se im Pro­jekt ent­schei­det. Im klas­si­schen Pro­jekt­ma­nage­ment sind das immer weni­ge an der Spit­ze. In Scrum ist klar gere­gelt, dass das Team allein die Ent­schei­dung trifft und ver­ant­wor­tet (unter gewis­sen Rah­men­be­din­gun­gen). In der täg­li­chen Pro­jekt­ar­beit mag das wie alter Wein in neu­en Schläu­chen aus­schau­en, tat­säch­lich ist es aber eine völ­lig ande­re Grund­hal­tung dem Team gegenüber.

Ich bin mir nicht sicher, ob weni­ger strin­gen­te Regeln (Takt, Pro­duct-Back­log, etc.) einen Vor­teil bräch­ten. Das wäre aber tat­säch­lich eine inter­es­san­te Unter­su­chung: Wie viel Regeln und Pro­zes­se braucht Selbst­or­ga­ni­sa­ti­on. Ich den­ke dabei immer in wenig an Brain­stor­ming, wo eine Fokus­sie­rung auf ein The­ma und eini­ge weni­ge Regeln wesent­lich zu guten Ergeb­nis­sen beitragen.

Pro­jekt­ma­nage­ment wird als Manage­ment (Auf­trag klären,Planen, Steu­ern, Über­wa­chen) immer sei­ne Bedeu­tung haben und sich im Kon­text aktu­el­ler Anfor­de­run­gen pro­fes­sio­na­li­sie­ren. Und da ist Agi­li­tät eine Ant­wort, die bewähr­te Kon­zep­te der Team­steue­rung, Grup­pen­dy­na­mik und kol­lek­ti­ver Pro­blem­lö­se­tech­ni­ken so über­setzt hat, dass es in der Pro­fes­si­on Pro­jekt­ma­nage­ment ankopp­lungs­fä­hig ist.
Wer z.B. schon eini­ge Zeit mit LEAN Pro­zes­sen und deren Ein­füh­rung zu tun hat, fin­det an „agi­len Metho­den“ wenig Allein­stel­lung. Da ist die Indus­trie selbst dann schon post­in­dus­tri­ell (um bei Dei­ner Nomen­kla­tur zu bleiben :-) ).

Etwas ganz ande­rers ist, dass im PM viel zu häu­fig noch Manage­ment mit Füh­rung ver­wech­selt wird – aber das wäre ein eige­ner blog: http://www.hinz-wirkt.de/lotsenblog/artikel/46-komplex-ist-nicht-kompliziert

Ok, auch in dem von Ihnen „klas­si­schen PM“ plant der Pro­jekt­ma­na­ger nicht allein, das kann er ja schon auf­grund der meist feh­len­den tech­ni­schen Fach­kennt­nis­se nicht, der Pro­jekt­ma­na­ger orga­ni­siert den Pla­nungs­pro­zess, z.B. in einem Pla­nungs­work­shop (bei Sie­mens ist das z.B. ein PACT-Work­shop, das steht für Pro­ject Accel­a­ra­ti­on by Coa­ching & Team­work). Dort wird also die Pla­nung gemein­sam erar­bei­tet, ein Coach unter­stützt dabei, der PM muss natür­lich zum Schluß das letz­te Wort haben, weil ja die Pla­nung nicht im luft­lee­ren Raum statt­fin­det, son­dern sich an den Wün­schen der Kun­den und wei­te­ren Stake­hol­dern ori­en­tie­ren muss. Das ist m.E. in Scrum nichts ande­res, auch hier gibt es natür­lich einen Rah­men, den das Team im Zusam­men­spiel mit dem Pro­duct Owner fül­len muss. Eine zen­tra­le Fra­ge ist aus mei­ner Sicht, wie Ent­schei­dun­gen zustan­de kom­men. Das ist eh eine der zen­tra­len Fra­gen im Pro­jekt­ma­nage­ment. Das hat auch was mit Hal­tung, Wün­schen oder Erwar­tun­gen der Team­mit­glie­der und des Pro­jekt­ma­na­gers zu tun, im Wesent­li­chen geht es da aber um eine gene­rel­le Macht­fra­ge. Wie viel Macht hat ein Pro­jekt­ma­na­ger und wie er das Team dann ein? Da sehe ich wenig Unter­schie­de in „klas­si­schem“ oder „agi­lem“ Pro­jekt­ma­nage­ment. Es kommt viel­mehr auf den Kon­text und die Füh­rungs­kul­tur im Unter­neh­men an. Hier sehe ich durch­aus Unter­schie­de zwi­schen der ange­stamm­ten Indus­trie und der Software„industrie“, letz­te­re sind näm­lich meis­tens klei­ne­re Unter­neh­men mit wenig Hier­ar­chien, die dann auch eine ande­re Kul­tur haben (kön­nen), je grö­ßer das Unter­neh­men wird, umso schwie­ri­ger sind dann auch die Macht­fra­gen zu lösen…

Ich räu­me ja ger­ne ein, dass mei­ne Dar­stel­lung extrem Schwarz-Weiß ist. In der Pra­xis ken­ne ich auch eher Grau­schat­tie­run­gen: natür­lich plant der Pro­jekt­ma­na­ger nicht ohne sein Team; das kann ich in den aller­meis­ten Fäl­len ja gar nicht. Sie haben recht: Die zen­tra­le Fra­ge ist wer die Macht hat, Ent­schei­dun­gen zu tref­fen. Auch in die­ser Fra­ge gibt es in der Pra­xis belie­bi­ge Grau­schat­tie­run­gen zwi­schen strikt-hier­ar­chi­schen Ent­schei­dungs­pro­zes­sen und demo­kra­ti­schen Ent­schei­dungs­pro­zes­sen im Team. Was bei wel­chem Pro­jekt funk­tio­niert, ist nicht zuletzt auch eine Fra­ge der Kul­tur in der Orga­ni­sa­ti­on die die­ses Pro­jekt durch­führt. Dar­um sehen wir agi­le Vor­ge­hens­wei­sen eher bei pro­dukt­ori­en­tier­ten SW-Unter­neh­men, die intern arbei­ten kön­nen wie sie wol­len, als bei dienst­leis­tungs­ori­en­tier­ten SW-Unter­neh­men, die Indi­vi­du­al-SW für gro­ße Indus­trie­un­ter­neh­men bauen.

genau: es braucht unent­scheid­ba­re Ent­schei­dun­gen, denn die Ent­scheid­ba­ren hat die Orga­ni­sa­ti­on längst in Form von Pro­zes­sen, Hand­bü­chern, Stan­dards und Leit­li­ni­en geregelt.

Und dann kom­men wir auf das The­ma Pro­jekt­ma­nage­ment und die Fra­ge, ob die PM Pro­fes­si­on nicht lang­sam zu viel Ener­gie in die Opti­mie­rung der ent­scheid­ba­ren Ent­schei­dun­gen legt und wenig acht­sam gegen­über den unent­scheid­ba­ren ist. Sie ist für mich ‑zuge­ge­ben- rhe­to­risch, denn nach mei­ner Beob­ach­tung wird zu viel in das ers­te­re investiert.

Jun­ge PM Orga­ni­sa­tio­nen soll­ten natür­lich zunächst Ihre Basis gestal­ten und in pro­fes­sio­nel­le Struk­tu­ren (PM Pro­zes­se, PM- Hand­bü­chern, Trai­ning von Stan­dards und Metho­dik) inves­tie­ren. Rei­fe PM Orga­ni­sa­tio­nen müs­sen aber auch den Über­bau ent­wi­ckeln und ein PM jen­seits der Tools & Check­lis­ten beginnen:
Wer so agiert, miss­braucht Pla­nungs­tools und PM-Model­le nicht mehr, um die Kom-ple­xi­tät aus­zu­blen­den, son­dern nutzt sie als Werk­zeug, um das Pro­jekt effek­tiv zu steu­ern. Vor allem aber zeigt er eine Hal­tung, die von Neu­gier, Risi­ko­be­wusst­sein und der Bereit­schaft, unent­scheid­ba­re Ent­schei­dun­gen zu tref­fen, geprägt ist.
Dabei unter­schei­det sich die­se Füh­rungs­kraft vor allem in vier Punk­ten von sei­nem Kol­le­gen, der immer noch Hel­den­kämp­fe ficht:

Er arbei­tet mit Beschrei­bun­gen, anstatt von einer „objek­ti­ven Wahr­heit“ auszugehen.
Er denkt in Alter­na­ti­ven, anstatt nach ein­deu­ti­gen Lösun­gen zu suchen.
Er setzt auf Ver­net­zung statt auf linea­ren Kausalketten.
Er ent­schei­det unter Risi­ko, anstatt bei uner­war­te­ten Situa­tio­nen ent­schei­dungs­un­fä­hig zu sein.

Mit die­sen Anfor­de­rungs­ebe­nen sou­ve­rän umzu­ge­hen, ist die gro­ße Her­aus­for­de­rung. Genau das ist der Grund, war­um ich bei Pro­jekt­lei­tung ger­ne von der Königs­dis­zi­plin der Füh­rung spreche…

Inter­es­san­ter Gedan­ken­gang und Blick­win­kel: Ent­scheid­ba­re und daher opti­mier­ba­re Ent­schei­dun­gen ver­sus unent­scheid­ba­re Ent­schei­dun­gen. Pro­jekt­ma­nage­ment als Königs­dis­zi­plin der Füh­rung fin­de ich sehr schön. Wäre doch ein tol­les The­ma für ein open-space auf dem PM-Camp in Dorn­birn im Novem­ber, oder? Wir sam­meln die The­men ganz lose in Goog­le Mode­ra­tor; ich habe es schon hinzugefügt.

und ich mich schon ange­mel­det; gern mache ich einen Input zu
wirk­sa­mes PM braucht kei­ne Hel­den, son­dern gute Führung

Schreibe einen Kommentar