Teamübergreifende Projekte in agilen Unternehmen? So gehen Sie damit um!

Erst kürzlich habe ich mit einem Kunden über folgende Frage gesprochen: Wie gehen komplett agil ausgerichtete Organisationen damit um, wenn sie ein Projekt umsetzen wollen, das wirklich alle Bereiche des Unternehmens betrifft?

Denken Sie beispielsweise an die Einführung der DSGVO in europäischen Unternehmen: Vertrieb, Personal, Controlling, Fachabteilungen – alle sind betroffen. Wie aber packt man so etwas an, wenn die Organisation sich bereits komplett auf den Kunden ausgerichtet hat? Wenn essenzielle Stellen, wie etwa ein zentrales PMO mit eigenen Kapazitäten, nicht mehr existieren?

Der Trend: weg vom Projekt, hin zum Produkt

Nachdem viele Unternehmen insbesondere in der IT schon seit längerem agiles Projektmanagement betreiben, beobachten wir weltweit einen neuen Trend. Im Fokus steht nun nicht mehr nur, wie die Arbeit innerhalb eines Projekts agil organisiert wird. Es geht auch darum, wie die ganze Organisation „agilisiert“ werden kann.

Eine Ausprägung dieses Trends führt weg vom Denken in Projekten. Die „alte“ Welt wird verlassen, in der Projektleiter noch um Ressourcen rangelten und über Prioritäten schacherten. Stattdessen denkt man in längeren Zeiträumen. Es wird nicht mehr über einzelne Projekte verhandelt oder über Projekt-Verspätungen geschimpft. Auch werden nicht mehr Projektteams mühsam zusammengesucht, auf die Verfügbarkeit der richtigen Experten gewartet und anschließend über Change Requests gestritten.

Nein, man denkt jetzt in „Produkten“ oder in „Wertströmen“ – also in Investitionen von Dauer. In diesen werden Teams so geschnitten, dass sie nicht auf Zuarbeit anderer Organisationseinheiten angewiesen sind. Kurz: Sie arbeiten in gleichbleibender Besetzung und in multi-disziplinären Konstellationen dauerhaft zusammen.

Produkte brauchen kein Ressourcenmanagement mehr

Um was es mir geht, ist die Frage, ob man denn noch Ressourcenmanagement braucht, wenn man feste und dauerhafte Teams hat. Wenn ein Team aus Fachexperten, technischen Spezialisten und Managern zusammenarbeitet, dreht sich Ressourcenmanagement quasi „herum“: Das Projekt wartet nicht mehr auf die Ressourcen, sondern die Ressourcen warten auf die Projekte. Ein Team arbeitet ein Thema ab und „zieht“ sich dann das „Nächst-Wichtigste“ aus der priorisierten Warteschlange.

Interessanterweise sprechen unsere Kunden schon gar nicht mehr von „Projekten“, sondern von „Business Epics“, „Features“, „Versicherungsprodukten“ oder etwa „Kundenangeboten“. Stattdessen verwenden sie also mittlerweile genau die Begriffe, die auch die Fachabteilungen schon immer verwendet haben.

Statt klassischem Ressourcenmanagement hat man bei Produkten:

• Dedizierte Teams
• Direkte Zusammenarbeit von technischen Experten und Fach-Experten,
• Priorisiertes Backlog statt Projekt-Portfoliomanagement
• Priorisierungen auf mehreren Ebenen (ganz unten für den Sprint, darüber für das Produkt, darüber für ein Programm/Release Train etc.)

Machs gut, alter Weggefährte Ressourcenmanagement – oder doch nicht?

Und somit schließen wir das Ressourcenmanagement-Buch und verabschieden uns mit gemischten Gefühlen von Jahren des Beantragens von Ressourcen, Soft- und Hart-Buchens, der kurzfristigen Intervention und dem Vergleich von Plan- und Ist-Zahlen.

Allerdings, und Sie merken schon, hier kommt das „Aber“, ist das Thema Ressourcenmanagement auch in 100 % agilen Organisationen nicht obsolet. Es verbleiben wichtige Tätigkeiten zur Steuerung des kurz-, mittel- und langfristigen Personalbedarfs:

• Zusammensetzung der Teams, Entscheidung zur Kapazität und der notwendigen Skills
• Steuerung der Kapazitätsentwicklung des Teams
• Steuerung der Skill-Zusammensetzung und Entwicklung innerhalb des Teams
• Kurzfristige Einplanung von Abwesenheiten, um die Sprint-Kapazität realistisch festlegen zu können

Gleichzeitig, und hier nun wird es spannend, gibt es auch in optimal geschnittenen Organisationen solche Situationen, in denen Ressourcen über Teams hinweg geteilt werden müssen. Das betrifft folgende Umstände:

Knappe Schlüsselressourcen

Einige Skills sind so knapp, dass sie nicht dediziert einem Team zur Verfügung gestellt werden können. Es existieren also weiterhin Engpassressourcen, um die sich Teams herumorganisieren und die Verfügbarkeit in ihrer eigenen Planung berücksichtigen müssen.

Projektbezogene Notwendigkeiten

Die Notwendigkeit eines unternehmens- oder abteilungsübergreifenden Projekts (unser Beispiel oben: die Einführung der DSGO) erfordert die Einbeziehung vieler Personen und muss unternehmensweit koordiniert werden, um die Erreichung des Projektziels zu einer bestimmten Deadline zu erreichen.

Wie geht man mit „un“-agilen Umständen um?

Die Auflösung der Engpassressourcen wird auch in agilen Umfeldern recht „klassisch“ gelöst. Die Anforderungen der verschiedenen Teams werden entweder in einem eigenen Backlog gesammelt und priorisiert oder es werden den Teams Kapazitäts-Kontingente zur Verfügung gestellt. Die Teams müssen die zeitlichen Abhängigkeiten anschließend in ihre eigene Sprint-Planungen mit einbeziehen.

Die Koordination übergreifender Projekte wird in der Praxis auf zwei verschiedenen Wegen umgesetzt:

Dekonstruktion und Verteilung

Dekonstruktion bedeutet, dass ein abteilungsübergreifendes Vorhaben so zerlegt wird, dass die einzelnen Arbeitspakete/Features/Epics in verschiedenen Teams abgearbeitet werden können. Die Projektleitung des Cross-Abteilungs-Projekts erhält dann die Verantwortung, die Umsetzung über die Teams hinweg zu „orchestrieren“. Gleichzeitig erhalten die Product-Owner der einzelnen Teams Anweisung, die entsprechenden Arbeitspakete zu priorisieren. In den Teams werden somit also spezielle „wertstrom-fremde“ Arbeitspakete umgesetzt.

Dedizierte Kapazität

Anstatt die Arbeit auf Teams zu verteilen, wird Kapazität aus den Teams ausgekoppelt. Das bedeutet, dass Personen teilweise oder komplett aus ihren Teams herausgenommen werden und ein „klassisches“ Projektteam bilden. Die Projektleitung kann auf diese Weise einfacher steuern, Tätigkeiten in Abfolge setzen und muss weniger Puffer- sowie Wartezeiten einplanen.