Projekte funktionieren nicht in einem ressourcen-limitierten System

Warum funktionieren in unseren heutigen Produktentwicklungs-organisationen die Projekte nicht mehr? Und warum haben sie aber über einen so langen Zeitraum funktioniert?.

.

Es gibt sicher viele Gründe dafür, aber diese lassen sich meiner Ansicht nach auf eine Hauptursache zurückführen: Heutige Entwicklungsorganisationen arbeiten meist nicht nur am Limit, sondern über dem Limit ihrer Kapazität. Auch dafür gibt es wiederum mehrere Gründe:

1. Produktentwicklungsorganisationen haben in den letzten 30 Jahren viele Optimierungs- und Verschlankungsinitiativen durchlebt, die die Kapazitäten der Organisationen auf ein Minimum reduziert haben. Ein falsches Verständnis von Lean hat hierzu geführt. Nun sind die Ressourcen-Reserven gesunken, wenn nicht gar verschwunden.
2. Die Entwicklungsvorhaben sind komplexer geworden, wodurch der Bedarf an Interdisziplinarät und Kommunikation gewachsen ist. Da die Organisationsstrukturen aber häufig nicht in Richtung interdisziplinärer Gruppen und Abteilungen geändert wurden und die Interdisziplinarität dadurch ausschließlich in den Projekten stattfindet, besteht heute ein nicht zu unterschätzender Teil der Projektarbeit in Abstimmungsmeetings, was die Netto-Kapazität reduziert.
3. Die fehlende Transparenz über die benötigten Kapazitäten und der Druck immer mehr Projekte zu starten, führt dazu, dass jeder Mitarbeiter in mehreren Projekten arbeitet, was zu vielen „Task-Wechseln“ und einer weiteren Verminderung der realen Kapazität führt.

Was sollen wir also tun?

• Akzeptieren, dass die Organisation am Limit arbeitet. Es muss klar werden, …
  • dass die pure Definition eines weiteren Projekts mit der Zuweisung von ein paar Prozent der beteiligten Mitarbeiter und das Setzen eines ambitionierten (wenn nicht gar unmöglichen) Zieltermins nicht ausreicht;
  • dass die Organisation nicht alle Projekte und Ideen umsetzen kann. NEIN ist eine valide Antwort;
  • dass die Organisation am effektivsten arbeitet, wenn nur an einigen wenigen Vorhaben gleichzeitig gearbeitet wird;
• Transparenz über die wirkliche Leistungsfähigkeit der Entwicklungsorganisation erlangen. Die reine Summe der Entwicklerstunden sagt dabei nichts über die Leistungsfähigkeit der Organisation aus.
  • Hierbei hilft die Bildung von stabilen und selbstorganiserten Teams mit einem Speicher an Arbeitspaketen (dem sogenannten Backlog).
  • Die Teams schätzen ihre Arbeitspakete selbst ab und arbeiten diese in einem gleichmäßigen Rhythmus von Iterationen ab. Dadurch ergibt sich fast automatisch eine vorhersagbare Arbeitsgeschwindigkeit.
• Priorisieren nach einer möglichst hohen Wertschöpfung gegenüber einem möglichst niedrigem Aufwand. Dies hat den großen Vorteil, dass wir durch die geschickte Auswahl, den Wertschöpfungszugewinn gegenüber früher sogar stark steigern können!
• Aufhören, immer wieder neue Projektteams zu formieren. Die Vorhaben werden nach folgenden zwei Kriterien den stabilen Teams zugewiesen:
  • Eignung des Team: Das Vorhaben wird innerhalb des Backlogs des am besten geeigneten Teams priorisiert, also des Teams mit den geeignetsten Kompetenzen und Erfahrungen
  • Auslastung des Teams: Sind mehrere Teams geeignet, wird das Vorhaben in das Backlog des Teams priorisiert, bei dem die kürzeste Durchlaufzeit erwartet wird

Herausforderungen

• Alle neu aufgesetzten Teams benötigen Zeit, bis sie effektiv und effizient zusammenarbeiten. Das gilt für Projektteams als auch für neu formierte stabile Teams
• Die Stabilität von Teams setzt voraus, dass jemand die Teams so formiert hat, dass die Vorhaben zu bestehenden Teams passen. Da dies sicher nicht immer gewährleistet ist, müssen sich die Teams ein gewisses Maß an Flexibilität erarbeiten. Auch dies benötigt Zeit.
• Große Vorhaben benötigen nicht nur ein, sondern mehrere Teams. Dies lässt sich durch die Einführung von skalierenden Frameworks begegnen, so z.B. dem Scaled Agile Framework für die Software-Entwicklung oder dem P4-Dev-Framework für die Entwicklung physischer Produkte und Systeme

Zu diesem Thema siehe auch: Das Monopol der Projekte.

[Foto: „Beijing highway traffic jam“ auf china.org.cn]