Am Rande der Diskussion zum letzten Artikel über die Rolle des Chefarchitekten beschrieb Thilo Niewöhner eine nützliche Leitlinie für die Besetzung von Projektrollen, die nicht in den Kommentaren untergehen sollte: Besser dieselbe Expertenrolle in verschiedenen Projekten ausüben als mehrere verschiedene Rollen im selben Projekt. Insbesondere wenn es um die Vermischung von Rollen auf Führungs- mit Rollen auf Arbeitsebene geht, möchte ich diese Leitlinie dick unterstreichen.
Manche Rollen im Projekt erfordern einfach keine Besetzung in Vollzeit. Die Rolle des Architekten in Softwareprojekten ist dafür ein gutes Beispiel. Die reine Architektentätigkeit lastet den Mitarbeiter bei kleineren Systemen nur zwischen 20% bis 40% aus. Anfangs bei der Definition und Abstimmung der Architektur sicherlich mehr, später bei der Begleitung der Umsetzung wieder weniger. Ganz ähnlich ist das bei vielen anderen Rollen im Projekt wie beispielsweise dem Testmanager, Scrum-Master, Product-Owner oder eben auch Projektleiter.
Wohin also mit der restlichen Zeit dieser Teilzeit-Experten? Vielfach verbreitert man deren Aufgabenspektrum im Projekt einfach. Schnell ist der Chefarchitekt dann gleichzeitig Product-Owner und Entwickler. Die Synergieeffekte sind sicherlich nicht von der Hand zu weisen. Wenn für alle Rollen ausreichend Zeit bleibt und der Mitarbeiter alle Rollen ähnlich motiviert und engagiert wahrnimmt (was meist nicht der Fall ist), ist aus Sicht des Projekts wenig dagegen einzuwenden.
Neben dieser Verbreiterung auf Arbeitsebene findet man häufig aber auch eine Vermischung von Arbeitsebene und Führungsebene indem der Projektleiter beispielsweise gleichzeitig noch Chefarchitekt und Entwickler im Projekt ist. Wenngleich es auch dabei Synergieeffekte gibt, überwiegen die Nachteile meiner Meinung nach deutlich die Vorteile. Die Führungsebene erfordert Arbeit am System, die Arbeitsebene aber Arbeit im System. Im Zweifelsfall ist die Arbeit im System immer die dringendere und die Führungsarbeit „nur“ wichtig (vgl. Eisenhower-Prinzip auf Wikipedia). Die Folge ist oft hektische Betriebsamkeit bei völliger Orientierungslosigkeit oder mit den Worten von Tom deMarco: „Haben uns verlaufen, kommen aber gut voran!“
Verstärkt wird dieser Effekt der Vernachlässigung der Führungsebene durch einen gewissen Hang der Experten zu ihrer Expertentätigkeit. Wenn also der Chefarchitekt und begnadete Entwickler zusätzlich Projektleiter sein soll, sieht das nur auf den ersten Blick wie ein sinnvoller Karriereschritt in Richtung Führungsverantwortung aus. Ohne eine professionelle Begleitung dieses Schritts wird die für das Projekt so wichtige Führungsarbeit nicht oder nur unzureichend stattfinden, weil die Arbeitsebene nicht nur dringender sondern auch noch erfüllender scheint.
Artikelbild: Bob Mical bei flickr.com (CC BY 2.0)
3 Kommentare
Das Spannende dabei ist, daß das Konzept an sich für die Teammitglieder nach einiger Diskussion völlig schlüssig und logisch ist und auf breite Zustimmung stößt.
Für das Management ist das jedoch offenbar jenseits ihrer Vorstellungswelt (und wahrgenommenen Realität).
Jeder Versuch, eine solche nachvollziehbare (und für uns nützliche, weil unterm Strich zeit- und nervensparende) Umstrukturierung zu erläutern und zu initiieren, scheitert völlig daran, das den Vorgesetzten begreiflich zu machen.
Falls da jemand Vorschläge für eine annahmeverträgliche Fomulierung hat, bin ich sehr dankbar.
Das Problem ist oft, dass das Management von Dienstleistern fast nur an der Auslastung der Mannschaft gemessen wird, was einerseits ja logisch ist, denn daran ist meist 1:1 der Gewinn gekoppelt. Und da ist es eben am einfachsten die Kapazität der Mitarbeiter irgendwie aufzufüllen ohne sich zu fragen, ob das gut für den Mitarbeiter oder gut für das Projekt ist.
Ja, da ist was dran.
Wenn „Aktivierung“ oder „Abrechenbare Leistung“ auf der Balanced Score Card auftauchen, ist es mit der Sinnhaftigkeit meistens vorbei.
Entsprechend eine der „Sieben tödlichen Krankheiten eines Managementsystems“ nach Deming:
„Verwendung von Kenngrößen durch das Management – ohne Berücksichtigung von solchen Größen, die unbekannt oder nicht quantifizierter sind“ (Quelle: Wikipedia; Danke an Frederic für den Hinweis)
Insbesondere die Zufriedenheit der Mitarbeiter wird da gerne mal vergessen, auch wenn sie entscheidenden Einfluß auf den Erfolg eines Projektes oder einer Unternehmung hat.