Vorsicht bei der Vermischung von Rollen

Am Ran­de der Dis­kus­si­on zum letz­ten Arti­kel über die Rol­le des Chef­ar­chi­tek­ten beschrieb Thi­lo Nie­wöh­ner eine nütz­li­che Leit­li­nie für die Beset­zung von Pro­jekt­rol­len, die nicht in den Kom­men­ta­ren unter­ge­hen soll­te: Bes­ser die­sel­be Exper­ten­rol­le in ver­schie­de­nen Pro­jek­ten aus­üben als meh­re­re ver­schie­de­ne Rol­len im sel­ben Pro­jekt. Ins­be­son­de­re wenn es um die Ver­mi­schung von Rol­len auf Füh­rungs- mit Rol­len auf Arbeits­ebe­ne geht, möch­te ich die­se Leit­li­nie dick unterstreichen.

Man­che Rol­len im Pro­jekt erfor­dern ein­fach kei­ne Beset­zung in Voll­zeit. Die Rol­le des Archi­tek­ten in Soft­ware­pro­jek­ten ist dafür ein gutes Bei­spiel. Die rei­ne Archi­tek­ten­tä­tig­keit las­tet den Mit­ar­bei­ter bei klei­ne­ren Sys­te­men nur zwi­schen 20% bis 40% aus. Anfangs bei der Defi­ni­ti­on und Abstim­mung der Archi­tek­tur sicher­lich mehr, spä­ter bei der Beglei­tung der Umset­zung wie­der weni­ger. Ganz ähn­lich ist das bei vie­len ande­ren Rol­len im Pro­jekt wie bei­spiels­wei­se dem Test­ma­na­ger, Scrum-Mas­ter, Pro­duct-Owner oder eben auch Projektleiter.

Wohin also mit der rest­li­chen Zeit die­ser Teil­zeit-Exper­ten? Viel­fach ver­brei­tert man deren Auf­ga­ben­spek­trum im Pro­jekt ein­fach. Schnell ist der Chef­ar­chi­tekt dann gleich­zei­tig Pro­duct-Owner und Ent­wick­ler. Die Syn­er­gie­ef­fek­te sind sicher­lich nicht von der Hand zu wei­sen. Wenn für alle Rol­len aus­rei­chend Zeit bleibt und der Mit­ar­bei­ter alle Rol­len ähn­lich moti­viert und enga­giert wahr­nimmt (was meist nicht der Fall ist), ist aus Sicht des Pro­jekts wenig dage­gen einzuwenden.

Neben die­ser Ver­brei­te­rung auf Arbeits­ebe­ne fin­det man häu­fig aber auch eine Ver­mi­schung von Arbeits­ebe­ne und Füh­rungs­ebe­ne indem der Pro­jekt­lei­ter bei­spiels­wei­se gleich­zei­tig noch Chef­ar­chi­tekt und Ent­wick­ler im Pro­jekt ist. Wenn­gleich es auch dabei Syn­er­gie­ef­fek­te gibt, über­wie­gen die Nach­tei­le mei­ner Mei­nung nach deut­lich die Vor­tei­le. Die Füh­rungs­ebe­ne erfor­dert Arbeit am Sys­tem, die Arbeits­ebe­ne aber Arbeit im Sys­tem. Im Zwei­fels­fall ist die Arbeit im Sys­tem immer die drin­gen­de­re und die Füh­rungs­ar­beit „nur“ wich­tig (vgl. Eisen­ho­wer-Prin­zip auf Wiki­pe­dia). Die Fol­ge ist oft hek­ti­sche Betrieb­sam­keit bei völ­li­ger Ori­en­tie­rungs­lo­sig­keit oder mit den Wor­ten von Tom deMar­co: „Haben uns ver­lau­fen, kom­men aber gut voran!“

Ver­stärkt wird die­ser Effekt der Ver­nach­läs­si­gung der Füh­rungs­ebe­ne durch einen gewis­sen Hang der Exper­ten zu ihrer Exper­ten­tä­tig­keit. Wenn also der Chef­ar­chi­tekt und begna­de­te Ent­wick­ler zusätz­lich Pro­jekt­lei­ter sein soll, sieht das nur auf den ers­ten Blick wie ein sinn­vol­ler Kar­rie­re­schritt in Rich­tung Füh­rungs­ver­ant­wor­tung aus. Ohne eine pro­fes­sio­nel­le Beglei­tung die­ses Schritts wird die für das Pro­jekt so wich­ti­ge Füh­rungs­ar­beit nicht oder nur unzu­rei­chend statt­fin­den, weil die Arbeits­ebe­ne nicht nur drin­gen­der son­dern auch noch erfül­len­der scheint.

Arti­kel­bild: Bob Mical bei flickr.com (CC BY 2.0)

Teile diesen Beitrag

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.

3 Kommentare

Das Span­nen­de dabei ist, daß das Kon­zept an sich für die Team­mit­glie­der nach eini­ger Dis­kus­si­on völ­lig schlüs­sig und logisch ist und auf brei­te Zustim­mung stößt.

Für das Manage­ment ist das jedoch offen­bar jen­seits ihrer Vor­stel­lungs­welt (und wahr­ge­nom­me­nen Realität).

Jeder Ver­such, eine sol­che nach­voll­zieh­ba­re (und für uns nütz­li­che, weil unterm Strich zeit- und ner­ven­s­pa­ren­de) Umstruk­tu­rie­rung zu erläu­tern und zu initi­ie­ren, schei­tert völ­lig dar­an, das den Vor­ge­setz­ten begreif­lich zu machen.

Falls da jemand Vor­schlä­ge für eine annah­me­ver­träg­li­che Fomu­lie­rung hat, bin ich sehr dankbar.

Das Pro­blem ist oft, dass das Manage­ment von Dienst­leis­tern fast nur an der Aus­las­tung der Mann­schaft gemes­sen wird, was einer­seits ja logisch ist, denn dar­an ist meist 1:1 der Gewinn gekop­pelt. Und da ist es eben am ein­fachs­ten die Kapa­zi­tät der Mit­ar­bei­ter irgend­wie auf­zu­fül­len ohne sich zu fra­gen, ob das gut für den Mit­ar­bei­ter oder gut für das Pro­jekt ist.

Ja, da ist was dran.
Wenn „Akti­vie­rung“ oder „Abre­chen­ba­re Leis­tung“ auf der Balan­ced Score Card auf­tau­chen, ist es mit der Sinn­haf­tig­keit meis­tens vorbei.

Ent­spre­chend eine der „Sie­ben töd­li­chen Krank­hei­ten eines Manage­ment­sys­tems“ nach Deming:
„Ver­wen­dung von Kenn­grö­ßen durch das Manage­ment – ohne Berück­sich­ti­gung von sol­chen Grö­ßen, die unbe­kannt oder nicht quan­ti­fi­zier­ter sind“ (Quel­le: Wiki­pe­dia; Dan­ke an Fre­de­ric für den Hinweis)

Ins­be­son­de­re die Zufrie­den­heit der Mit­ar­bei­ter wird da ger­ne mal ver­ges­sen, auch wenn sie ent­schei­den­den Ein­fluß auf den Erfolg eines Pro­jek­tes oder einer Unter­neh­mung hat.

Schreibe einen Kommentar