Dienstleistungsunternehmen: Wie stabile Teams versteckte Kosten im Projektgeschäft reduzieren können

Für Dienstleistungsunternehmen ist das Projektgeschäft täglich Brot. Unter anderem liegt die Herausforderung darin, die richtigen Personen zum richtigen Zeitpunkt im Projekt zu haben. Die klassische Variante ein Projektteam zu Beginn des Projektes zusammenzustellen und dieses nach Projektende aufzulösen bringt erhebliche Nachteile. Diese werden aber nirgendwo transparent.  

1. Ausgangssituation

Für Dienstleistungsunternehmen ist das Projektgeschäft alltäglich Brot:

• Ein neues Produkt wird entwickelt
• Ein neues Gebäude wird geplant und errichtet
• Ein neuer Service wird eingeführt.
• ...

Diese Vorhaben haben alle eins gemeinsam: Sie werden meistens in Form von Projekten abgewickelt. Das bedeutet in einem "zeitlich begrenzten Vorhaben mit dem Ziel, ein einmaliges Produkt, eine einmalige Dienstleistung oder ein einmaliges Ergebnis zu schaffen“ /1/.

Projekte sind also temporär. Sie beginnen zu einem festgelegten Zeitpunkt. Sie enden wenn das Projektziel erreicht wurde oder festgestellt wurde, dass dieses Ziel nicht mehr erreicht wird.

2. Bilden des Teams

Man braucht also zeitlich befristet ein Team. Bei Projekten mit hoher Unsicherheit /2/ ist eine vollständige Planung des Projektes nicht mehr möglich. Daher bietet sich Scrum als Rahmenwerk /3/ an, um schnell Feedback zu bekommen: Wo stehen wir? Was machen wir als nächstes? Was haben wir gelernt?

Im Scrum besteht das Umsetzungsteam aus 3-9 Personen. Sie sind interdisziplinär und haben alle Eigenschaften um das Projekt umzusetzen. Die Teammitglieder sind idealerweise zu 100% dem Team zugeordnet. Das Team ist idealerweise stabil.

Leider sagt Scrum nichts davon, wie das Team zu Beginn des Projektes gebildet werden soll. Es sagt auch nichts davon, was mit dem Team am Ende des Projektes passiert!

3. Herausforderung: das Team wird für das Projekt temporär gebildet.

Häufig wird das Team für ein neues Projekt individuell zusammengestellt. D.h. für jedes neue Projekt, werden Personen gesucht, die ein Team bilden. Nach Projektende wird das Team wieder aufgelöst.

Für einen Dienstleister, der mehrere Projekte gleichzeitig abwickelt, hat diese Vorgehensweise anscheinend Vorteile: Meine Mitarbeiter sind möglichst ausgelastet. Falls ein Projekt zu Ende geht, können die einzelnen Mitarbeiter in andere Projekte verwiesen werden oder mit Zwischenaufgaben betraut werden. Ich muss mich "nur" um die Auslastung der einzelnen Mitarbeiter kümmern. Die häufigste Frage die gestellt wird: "Arbeitest Du in einem Projekt?"

Leider werden diese Vorteile mit erheblichen Nachteilen und Begleiterscheinungen erkauft:

• Für ein neues Team werden dann Mitarbeiter "entsendet", die gerade kein Projekt haben. Das notwendige Skill-Set ist eventuell nicht vorhanden. Die Selbst-Organisation des Teams wird nicht beachtet.
• Experten werden bei Eintritt von Unsicherheiten technischer Art zwischen den Projekten hin- und hergeschoben. Löcher in einem Projekt werden dadurch gestopft, indem Löcher in einem anderen Projekt, welches nicht "so wichtig" ist, aufgerissen werden.
• Gefragte Personen arbeiten an mehreren Projekten gleichzeitig. Sie können sich nicht fokussieren und damit nicht ihre geistige Kapazität in vollem Umfang zur Verfügung stellen /4/.
• Das Management reagiert auf eingetragene Unsicherheiten durch Veränderungen in den Projektteams. Dies führt zu nicht stabilen Teams. Die Velocity (= Anzahl der umgesetzten Story Points pro Sprint) leidet.

Diese Begleiterscheinungen werden schnell sichtbar. Darüberhinaus gibt es zwei Nachteile, die nicht sofort auffallen, aber eine enorme Wirkung auf die Gesamtorganisation haben:

1. Aufwand für Teamfindung verpufft: Jedes neue Team geht durch mehrere Phasen durch (Forming,  Storming, Norming), bevor es in den Arbeitsmodus kommt (Performing) /5/. Der zeitliche Aufwand für diese frühen Teamfindungs-Phasen lag z.B. bei einem meiner letzten Projekte bei ca. 20%. Wenn das Team nach Projektende aufgelöst wird, ist diese Investition verloren.
   
   
   
   
   
2. Steigerung der Team-Velocity nur eingeschränkt möglich: Zu Beginn des Projektes ist die Velocity des neuen Teams unbekannt. Erst mit Erreichen der Performing Phase kann diese sinnvoll gemessen werden. Als Scrum Master, der für die kontinuierliche Steigerung der Velocity verantwortlich ist, ist der verbleibende Zeitraum des Projektes oft zu kurz um diese erheblich zu steigern /6/.
   

Diese versteckten Kosten tauchen nirgendwo auf. Kein Projekt-Statusreport weist sie aus. Sie sind aber da und haben eine Auswirkung auf die kostendeckende Arbeit der Organisation.

4. Idee: Projekte werden von stabilen Teams gezogen und abgearbeitet

Statt ein Team jedesmal neu für ein Projekt zu bilden, wird das Team stabil gehalten und die Projekte anhand eines gemeinsamen Backlogs mit anderen Teams abgearbeitet.

Die Teams ziehen sich dann diese Projekte in einer gemeinsamen Planungsrunde. Eventuelle Ressourcen-Engpässe oder fehlende Fähigkeiten könnten die Teams untereinander feststellen und ggfs. an das Management rechtzeitig addressieren. Das würde bedeuten, dass die Teams größtenteils stabil bleiben.

Dafür braucht es mehrere Voraussetzungen:

• In einem kontinuierlichen Refinementprozess sollte den Teams transparent gemacht werden, welche Projekte gerade in Arbeit sind und welche Projekte in Zukunft mit welcher Priorität anstehen. Diese Verantwortung könnte ein Chief-Product Owner übernehmen.
• Projekte sollten möglichst klein geschnitten werden, um einen Projekterfolg wahrscheinlicher zu machen /7/. Eher 3 Monate Dauer als 9-12 Monate.
• Die Teams werden skaliert. /8/
• Gemeinsame Review- und Retrospektiven über den Gesamtprozess erlauben es, die Organisation kontinuierlich anzupassen.

Diese Vorgehensweise bringt organisatorische Herausforderungen mit sich:

1. Transparenz gegenüber Kunden: Als Dienstleistungsunternehmen muss man seinem Kunden transparent machen, wann ein Team voraussichtlich mit der Arbeit anfangen wird, da es bereits in Arbeit befindliche Projekte erst abschliessen muss. Die Kundenerwartungen sind dementsprechend entweder von einem Chief-Product Owner oder von einem Enterprise Action Team zu managen (Portfolio Management).
2. Teamfähigkeiten kontinuierlich erweitern: Was passiert wenn ein Projekt "fertig" ist? Das Team wird sich ein neues Projekt ziehen. Sollten hierfür andere Fähigkeiten der Teammitglieder nötig sein, dann müssten diese erst geschaffen werden. Hierfür wäre dann Schulung und/oder Coaching der Teammitglieder durch Experten notwendig.

Trotz dieser Herausforderungen glaube ich, dass die Vorteile überwiegen:

• Teamphasen entfallen: Stabile Teams kennen sich. Die frühen Phasen der Teamentwicklung (Forming, Storming, Norming) entfallen.
• Der Scrum Master kann kontinuierlich, über die Projektgrenzen hinweg, an der Velocity-Steigerung des Teams arbeiten.
• Wenn das Projekt einmal angefangen hat, kann sich ein komplettes Team darauf fokussieren. Dementsprechend würden keine Kontext-Switching kosten anfallen.
• Selbst wenn ein Team mehrere Projekte gleichzeitig bearbeitet. Durch die Rolle eines Product Owners wäre sichergestellt dass der Backlog priorisiert ist. Das Team konzentriert sich dann für einen Sprint auf seine Arbeit. Die Abstimmung mit den evtl. verschiedenen Kunden über die Priorisierung wäre Aufgabe des Product Owners.
• Statt auf eingetretene Unsicherheiten im Projekt zu reagieren, kann das Management sich auf die Bildung neuer Teams, der Projektakquise oder das Management von Kunden fokussieren.

5. Eure Erfahrung?

Ich habe hier einen Gedankenanstoß für die Abarbeitung von Projekten in Dienstleistungsorganisationen gegeben. Ein Weg zu einer skalierenden Organisation, die Projekte von stabilen Teams abarbeiten lässt, ist nicht einfach. Die Umsetzung erfordert Geduld und Ausdauer.

Was ist Eure Erfahrung? Über Feedback / Meinungen / Kommentare unten würden ich mich sehr freuen. 

Hinweis: Am 18.-19.09.2018 findet in Karlsruhe unser Seminar zum Aufsetzen von Scrum-Projekten statt. Mehr auf der Webseite von CST.

Anmerkungen

• /1/ Project Management Insitute:A guide to the project management body of knowledge (PMBOK guide), 6. Ausgabe, Newtown Square, PA, 2017
• /2/ vergleiche die Arten von Unsicherheit und sich der daraus ergebenden Konsequenzen im Projekt in Shenhar, Aaaron J.; Dvir Dov: Reinventing Project Management - The diamondaproach to successful growth and innovation. Boston MA, 2007.
• /3/ https://www.scrumguides.org/
• /4/ zum Thema Kosten bei Kontext Switching: Weinberg, Gerald M.: Quality Software Management, 1 : Systems Thinking. New York: Dorset House Pub., 1992
• /5/ zum Thema Team-Phasen siehe Tuckman, B. W. (1965). Developmental sequences in small groups. Psychological Bulletin, 63, 348- 399
• /6/ Selbst wenn ich im Agilen Umfeld handele: Das Team muss sich erst finden und ausprobieren, welche Rituale es schafft. Dafür benötigt es Zeit. Aus eigener Erfahrung liegt dieses "Tal der Tränen" (valley of Tears) für neue Teams bei mindestens 4-6 Sprints. Bei einer Sprintlänge von 4 Wochen also 4-6 Monate.
  Wenn das Projekt nur 6 Monate dauert kann man sich schnell ausrechnen, dass eine Steigerung der Velocity nicht möglich ist, wenn das Team wieder aufgelöst wird.
• /7/ vergleiche zum Thema Einfluss der Projektgröße: https://www.infoq.com/articles/standish-chaos-2015
• /8/ zum Thema Skalierung siehe https://www.scrumatscale.com/