Projekte im Dickicht der Rollen

Weni­ger, aber bes­ser. Die­sen Leit­spruch des berühm­ten deut­schen Desi­gners Die­ter Rams wür­de ich mir auch für Vor­ge­hens­mo­del­le wün­schen. Je mehr Rol­len ein Vor­ge­hens­mo­dell ent­hält und je mehr mehr die­ser Rol­len „Mana­ger“ ent­hal­ten, des­to kaput­ter ist es.

Orga­ni­sa­tio­nen geben ihren vie­len Pro­jek­ten mit einem Vor­ge­hens­mo­dell gern einen fes­ten Ori­en­tie­rungs­rah­men zur Durch­füh­rung. Ein sol­ches Modell beschreibt also die Art und Wei­se, wie in der jewei­li­gen Orga­ni­sa­ti­on Pro­jek­te durch­ge­führt wer­den, wel­che Pha­sen und Ergeb­nis­se erwar­tet wer­den und auch wel­che Rol­len es geben muss oder kann. So weit, so verständlich.

In Pro­jek­ten gibt es ganz unter­schied­li­che Auf­ga­ben, die ganz unter­schied­li­che Exper­ti­se ver­lan­gen. Gera­de die­se Inter­dis­zi­pli­na­ri­tät kenn­zeich­net ja ein Pro­jekt. In Soft­ware­pro­jek­ten wird spe­zi­fi­ziert, pro­gram­miert, gebaut, instal­liert, getes­tet, betrie­ben und vie­les mehr. Die Auf­ga­ben müs­sen im Team ver­teilt und erle­digt wer­den. Und es scha­det dazu auch sicher nicht die Auf­ga­ben zu beschrei­ben. Ob es dafür jeweils Rol­len und Rol­len­be­schrei­bun­gen braucht, ist aller­dings eine ganz ande­re Frage.

Unter­schei­de ohne zu tren­nen – ver­bin­de ohne zu egalisieren.
Her­bert Pietschmann

Eine Rol­le hat auch immer etwas Tren­nen­des. Es wer­den neben den Auf­ga­ben auch Kom­pe­tenz (was darf die­se Rol­le ent­schei­den) und Ver­ant­wor­tung (wofür ist die­se Rol­le ver­ant­wort­lich) beschrie­ben. Und damit eben auch, was die Rol­le nicht ent­schei­den darf und wofür sie nicht ver­ant­wort­lich ist. Vor­ge­hens­mo­del­le mit vie­len Rol­len und detail­lier­ten Rol­len­be­schrei­bun­gen sehen Pro­jek­te also eher mecha­nis­tisch. Wie bei einer Maschi­ne wer­den die Kom­po­nen­ten und wie sie zusam­men­ge­setzt wer­den beschrie­ben. Die Grund­idee dabei ist, dass die Maschi­ne wie geplant funk­tio­niert, wenn jedes Teil sei­ne Funk­ti­on wie beschrie­ben erfüllt. Die Ein­zel­tei­le küm­mert es dabei nicht und muss es auch nicht küm­mern, wel­chen Zweck die Maschi­ne erfül­len soll.

Tra­di­tio­nal hier­ar­chies and their ple­tho­ra of built-in con­trol sys­tems are, at their core, for­mi­da­ble machi­nes that breed fear and distrust.
Fre­de­ric Laloux

Für wie­der­keh­ren­de, plan­ba­re und immer­glei­che Tätig­kei­ten ist die­se mecha­nis­ti­sche Sicht­wei­se effi­zi­ent und ziel­füh­rend. Sobald aller­dings, wie bei den meis­ten Pro­jek­ten, Unsi­cher­heit in Spiel kommt und der Weg zum Ziel gemein­sam gefun­den wer­den muss, sind abge­grenz­te Rol­len kei­ne Lösung, son­dern ein Pro­blem. Statt neben­ein­an­der (und oft genug gegen­ein­an­der) die Auf­ga­ben abzu­ar­bei­ten, braucht es mehr Mit­ein­an­der im inter­dis­zi­pli­nä­ren Team mit einem kla­ren Blick auf den gemein­sa­men Auf­trag und die gemein­sa­me Ver­ant­wor­tung. Agi­le Model­le wie Scrum oder Kan­ban ken­nen daher auch nur ganz weni­ge Rollen.

Letzt­lich sind Vor­ge­hens­mo­del­le mit ihrem Dickicht an Rol­len aber auch nur Abbild der umge­ben­den Orga­ni­sa­ti­on. Je mecha­nis­ti­scher und je höher der Grad an funk­tio­na­ler Tei­lung, des­to mehr Rol­len wer­den auch den Pro­jek­ten vor­ge­schrie­ben. Das Ergeb­nis sind see­len­lo­se Pro­jekt­ma­schi­nen vom Fließ­band, in denen jeder peni­bel auf sei­ne Auf­ga­be schaut und die Schuld beim ande­ren sucht. Eine fata­le Kon­stel­la­ti­on bei immer kom­ple­xer wer­den­den Auf­ga­ben­stel­lun­gen, die nur noch mit­ein­an­der durch gemein­sa­mes Aus­pro­bie­ren und Ler­nen bewäl­tigt wer­den können.

The sto­ry of the glo­bal work­force is a sad tale of was­ted talent and energy.
Fre­de­ric Laloux