In Time, in Budget und in Scope erzwingen in Großprojekten oft starre Pläne, die notwendige Änderungen kaum zulassen. Die Folge: Der Kundennutzen bleibt auf der Strecke. Wer dies vermeiden will, muss den Spagat zwischen Sicherheit und Flexiblilität in Großprojekten hinbekommen. In diesem Artikel zeige ich Ihnen, wie Sie mit kleinen, hoch wirksamen Teams dort hinkommen.
Wenn Sie schon einmal in einem Großprojekt gearbeitet haben, kennen Sie diese Situation vielleicht: Das Projektmanagement unternimmt alle denkbaren Anstrengungen, um Gewissheit zu erhalten, dass zum vorgegebenen Termin das vorgesehene Ergebnis im Rahmen des vorgegebenen Budgets geliefert wird. Doch was hat das zur Folge? Jede Änderung, sei sie auch noch so klein, jeder Fehler in der Konzeption und jede zu spät entdeckte Anforderung sind zwangsläufig Störungen. Störungen, die den sorgfältig ausgearbeiteten Plan zerstören. Störungen, die klassisches Projektmanagement daher versucht, zu eliminieren (Risikomanagement) oder in zusätzliches Budget umzuwandeln (Change Request Management). Dabei bleibt jedoch ein ganz entscheidendes Element auf der Strecke: Der Kundennutzen. Denn: Kunden erhalten in klassisch geplanten Projekten oft ein Produkt, das auf einer ein bis zwei Jahre alten Spezifikation beruht oder sie erhalten ein Produkt, das die aktuellen Anforderungen zwar widerspiegelt, dafür jedoch 20 bis 40 Prozent mehr kostet. Bei einem Budget von 5 Millionen Euro sind das ein bis zwei Millionen!
Mein Tipp: Teams nach Kundennutzen strukturieren
In vielen Großprojekten finde ich eine Projektorganisation, die in etwa die hierarchische Organisationsstruktur des jeweiligen Unternehmens spiegelt. Ganz oben das Projektmanagement mit seinen Stabsstellen. Darunter funktionale Einheiten wie z.B. ein Analyseteam, ein Architekturteam, ein Entwicklungsteam (das wiederum hierarchisch unterteilt ist) und ein Testteam. Aus gruppendynamischer Sicht geschieht nun folgendes: Die einzelnen Teams identifizieren sich mehr und mehr mit ihren jeweiligen Zielen. Das Analyseteam zum Beispiel mit dem Ziel, Use-Case Spezifikationen termingerecht abzuliefern. Dabei treten die Bedürfnisse der benachbarten Teams und des übergeordneten Projektmanagements nach und nach in den Hintergrund. So wird zum Beispiel die Anfrage des Architekturteams, ein Review für das Architekturdokument durchzuführen, als Störung empfunden. “Sollen die sich mal selbst um ihre Qualität kümmern. Wir haben schließlich unsere Termine, die wir einhalten müssen.”
Wo bleibt hier der Kundennutzen?
Der Kundennutzen bei der oben beschriebenen Struktur ist aus mehreren Gründen gering:
- Kaum nachprüfbare Resultate. Jedes der Teams liefert Resultate, die für sich betrachtet, kaum nachprüfbar sind. Erst zusammen mit den Resultaten aller anderen Teams entsteht ein Kundennutzen. Ganz konkret: Erst wenn das Testteam die Softwarekomponenten integriert und getestet hat, stellt sich heraus, ob das Entwicklungsteam die Anforderungen aus dem Analyseteam richtig umgesetzt hat, ob die Architektur wirklich tragfähig ist und ob die umgesetzten Anforderungen wirklich zu den aktuellen fachlichen Bedürfnissen passen. In der Regel sind bis dahin schon 6 bis 12 Monate vergangen!
- Hoher Aufwand für die Integration. Um die Teilergebnisse miteinander zu integrieren, entsteht ein immenser Zusatzaufwand: Die Spezifikation ist mit der Architektur abzugleichen, die Softwarekomponenten der einzelnen Teams sind in das Gesamtsystem zu integrieren, die Testfälle sind mit der Spezifikation abzugleichen, die GUI-Entwürfe sind mit der Spezifikation abzugleichen, Erkenntnisse aus dem Design, der Entwicklung und dem Test müssen in die Spezifikation zurückfließen und so weiter. Alles Tätigkeiten, die keinen direkten Kundennutzen liefern.
- Hoher Aufwand für den Know-How Transfer. Bei der Übergabe von Zwischenergebnissen (in der Regel sind dies Dokumente) geht Know-How verloren. So erarbeitet sich das Analyseteam zum Beispiel nach und nach ein fundiertes Verständnis für die fachlichen Bedürfnisse und Abläufe. Die anderen Teams erhalten jedoch nur Spezifikationsdokumente, die immer nur einen Teil dieses Know-Hows widerspiegeln (eine vollständige Spezifikation, die alle Nuancen der Fachlichkeit enthält, ist wirtschaftlich schlichtweg unsinnig). Um das erforderliche Wissen zu erarbeiten, müssen die anderen Teams auf (meist ungeplante) Ressourcen des Analyseteams zurückgreifen. Da die Arbeiten an der Fachlichkeit in der Regel von Team zu Team (Architektur, Entwicklung, Test) weitergereicht werden, erfolgt der Know-How Transfer mehrfach und jeweils zu einem anderen Zeitpunkt.
- Lange Durchlaufzeiten. Diese entstehen a) durch Liegezeiten der Zwischenergebnisse, weil die Taktraten der einzelnen Teams nur schwer miteinander zu synchronisieren sind, b) durch aufwändige Abnahmeverfahren für Zwischenergebnisse, um die Qualität an den Schnittstellen sicherzustellen und c) durch zeitintensive Korrekturschleifen, da Änderungen an Endergebnisse meist wieder ganz am Anfang der Kette starten müssen und danach sequentiell durch die Teamstruktur weitergereicht werden.
Eine organisatorische Alternative
Der größte Kundennutzen entsteht in einer Organisationsform, in der einzelne Teams in kurzen Intervallen von jeweils zwei bis vier Wochen eine lauffähige Software (ein bestimmtes Feature der Software) liefern, die ein fachliches Bedürfnis befriedigen. Solche Funktions-übergreifende Teams (Feature-Teams) bestehen aus Mitarbeitern, die alle erforderlichen Fähigkeiten für die Analyse, Architektur, Entwicklung und den Test mitbringen. Generalisten, die alles beherrschen, Spezialisten, die sich gegenseitig ergänzen oder – der wahrscheinlichste Fall – ein Mix aus beidem.
Abbildung: Funktions-übergreifende (Feature) Teams
Warum erzeugen Funktions-übergreifende Teams einen größeren Kundennutzen?
- Sie liefern lauffähige Software anstelle von Dokumenten. Funktions-übergreifende Teams werden selbstverständlich weiterhin spezifizieren, sie werden auch an der Systemarchitektur arbeiten und sie werden auch Testfälle schreiben. Sie tun dies jedoch für den Zweck, ihre Arbeit z.B. für Wartungszwecke zu dokumentieren. Sie müssen ihre Erkenntnisse nicht aufwändig dokumentieren, sondern können sie direkt an die anderen Teammitglieder weitergeben und in die Software einfließen lassen.
- Sie verschwenden keine Zeit für aufwändige Integrationsprozesse. Funktions-übergreifende Teams arbeiten autonomer. Auf der Basis eines Kernsystems entwickeln sie ihre Features und integrieren diese sofort nach der Fertigstellung. Spezifikation, Architektur und Testfälle lassen sich innerhalb des Teams ohne Zeitverzögerung aufeinander abstimmen (Zugegeben: Bei der Architektur und bei generellen Richtlinien braucht es eine Team-übergreifende Abstimmung. Diese ist jedoch lange nicht so zeitaufwändig, wie das Warten auf die nächste Baseline einer Architekturkomponente oder eines Spezifikationsdokuments).
- Sie entwickeln ein kollektives Verständnis für die Kundenbedürfnisse. In Funktions-übergreifenden Teams verbreiten sich neue Erkenntnisse über die fachlichen Bedürfnisse sofort. Prinzipiell kann jedes Teammitglied direkt mit dem Kunden (Fachexperten) oder seinem projektinternen Stellvertreter reden. Es ist nicht erforderlich, jede neue Erkenntnis zuerst in der Spezifikation festzuhalten, sie dann im GUI-Designteam zu interpretieren, anschließend im Testteam eine möglicherweise unterschiedliche Interpretation einfließen zu lassen und am Schluss im Code etwas ganz anderes zu implementieren. Stattdessen kann das Team an einem Tisch besprechen, welche Auswirkungen neue Erkenntnisse auf die jeweiligen Ergebnisse haben und sie direkt umsetzen. Gruppendynamisch gesprochen: Das Team identifiziert sich mit den Bedürfnissen des Kunden statt mit Zwischenergebnissen.
- Sie werden schneller fertig. Dies dürfte der größte Vorteil sein. Weil ein Funktions-übergreifendes Team Zwischenergebnisse parallel und nicht sequentiell bearbeitet, wird das Endprodukt, die lauffähige Software deutlich schneller fertig. Es ist keine zeitraubende Synchronisation zwischen verschiedenen Teams erforderlich. Die Qualität der Zwischenergebnisse steht nicht über der des Endergebnisses, sie lässt sich nach jeweils zwei bis vier Wochen an der lauffähigen Software ablesen. Korrekturen fließen ebenfalls sofort in das Endergebnis ein.
Voraussetzungen für Funktions-übergreifende Teams
Funktions-übergreifende Teams erfordern in traditionell aufgestellten Unternehmenskulturen eine nicht zu unterschätzende Veränderung: Was früher nach Spezialisierung organisiert wurde, muss zuerst aufgelöst und umgestellt werden. Dies gelingt nicht von heute auf morgen, sondern erfordert in erster Linie Zeit.
- Verlust von lieb-gewonnenen Stellen. Teamleiter von Spezialistenteams (z.B. Testteams) müssen sich neu orientieren, da ihre Leute sich auf Funktions-übergreifende Teams aufteilen. Ihnen könnte eine Rolle als querschnittverantwortlicher Coach oder als Teamleiter eines Funktions-übergreifenden Teams angeboten werden.
- Verlust des Expertenstatus. Spezialisten müssen sich zu Generalisten entwickeln. In Funktions-übergreifenden Teams müssen Spezialisten auch fachfremde Aufgaben wahrnehmen. Ein Tester muss z.B. bei der Erstellung der Spezifikation mitarbeiten.
Auch für Projektmanager bedeuten Funktions-übergreifende Teams eine Herausforderung. In der Startphase eines Projekts müssen sie ein Kernteam formen, das ein gemeinsam getragenes Bild der fachlichen Architektur, der technischen Architektur und der Arbeitsprozesse entwickelt. Dieses Kernteam verteilt sich nach der Startphase auf die neu gebildeten Funktions-übergreifenden Teams und trägt das gemeinsame Bild in die einzelnen Teams. Es muss während des gesamten Projektverlaufs dafür sorgen, dass dieses Bild nicht verwaschen wird bzw. sich an neue Erkenntnisse anpasst.
Die Planung stellt ebenfalls eine neue Herausforderung dar. Wo früher eine verrichtungs-orientierte Planung (“Architekturkonzept entwickeln”, “Spezifikation schreiben”, “Teststrategie entwickeln”, etc.) im Vordergrund stand, erfordern Funktions-übergreifende Teams eine Zerlegung der Gesamtfunktionalität in sinnvolle Produktfeatures. Die Planung muss sicherstellen, dass Features zu sinnvollen Zwischen-Releases gruppiert werden und die Realisierung der Features in einer fachlich und technisch sinnvollen Reihenfolge angegangen wird. Dazu müssen Projektleiter jedoch die Bereitschaft mitbringen, sich in die fachliche Themenstellung einzuarbeiten.
Alles in allem eine Aufgabe, die einiges von Projektleitern abverlangt. Sie werden ihren Arbeitsschwerpunkt dafür vom Managen auf das Führen verlagern müssen. Und sie werden lieb-gewonnene Methoden durch eine gehörige Portion gesunden Menschenverstand ersetzen müssen.
Dein Kommentar