Direkt zum Hauptbereich

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/

Kommentare

Beliebte Posts aus diesem Blog

Das neue Outlook - One Outlook - erster Eindruck

Microsoft hat ein Problem: Outlook ist nicht gleich Outlook. Da ist das gute alte Outlook in der Desktop-Version. Das ist das, womit fast alle von uns im Alltag arbeiten und worüber ich hier schon oft berichtet habe. Outlook auf dem MAC sieht aber anders aus. Outlook auf Mobilgeräten sowieso. Dann gibt's noch Outlook im Web. Kein Wunder, dass Microsoft das alles entwirren, verschlanken und vereinheitlichen möchte. Gelingt es? Hier die interessantesten Funktionen des neuen Outlooks . 

In Memoriam Stephan List (1959-2024)

Am 29.01.2024 starb ganz unerwartet unser lieber Freund Stephan List aus Ravensburg.

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

"Denn sie wissen nicht was sie tun ...! Freigeben und teilen in OneDrive und SharePoint und per E-Mail

Neuerdings können Sie bei Ihren E-Mails entscheiden, ob Sie den Anhang als Datei (Kopie) anhängen wollen oder einen Link senden. Doch was kann dieser Link? Wie sicher ist er? Wer kann was damit tun? Lesen Sie hier was sinnvoll ist und was weniger.