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)

Du willst keinen Artikel mehr verpassen?

Mit mei­nem News­let­ter bekommst du ein­mal wöchent­lich die neu­es­ten Arti­kel direkt in dei­nen Eingangskorb.

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