Wer schon einmal in einem (IT-)Großprojekt gearbeitet hat, kennt vermutlich folgende Situation: Das Projektmanagement unternimmt alle denkbaren Anstrengungen, um sicher zu stellen, dass zum vorgegebenen Termin das vorgesehene Ergebnis im Rahmen des vorgegebenen Budgets geliefert wird. Entsprechend „straff“ ist der Projektplan. Dies hat zur Folge: Jede Änderung, sei sie noch so klein, jeder Fehler in der Konzeption und jede zu spät entdeckte Anforderung wird als Störung empfunden, weil sie das Einhalten des Projektplans gefährdet.
Also versucht das klassische Projektmanagement solche Störungen entweder zu eliminieren (Risikomanagement) oder in ein zusätzliches Budget umzuwandeln (Change Request Management). Hierbei bleibt leider meist ein entscheidendes Element auf der Strecke: der Kundennutzen. Für klassisch geplante Projekte gilt: Die Kunden erhalten oft
- ein Produkt, das auf einer ein bis zwei Jahre alten Spezifikation beruht, oder
- ein Produkt, das zwar die aktuellen Anforderungen widerspiegelt, aber mehr als geplant kostet.
Kundennutzen gerät oft aus dem Blick
Bei größeren Projekten registriert man oft: Ihre Organisationsarchitektur spiegelt die hierarchische Struktur des Unternehmens wider. Sozusagen ganz oben befindet sich das Projektmanagement mit seinen Stabsstellen; darunter sind die funktionalen Einheiten wie zum Beispiel das Analyse-, das Architektur-, das Entwicklungs- und das Testteam angesiedelt.
Aus gruppendynamischer Sicht geschieht in einer solchen Organisationsstruktur folgendes: Jedes Team identifiziert sich primär mit seinen partiellen Zielen – so zum Beispiel das Analyseteam mit dem Ziel, Use-Case-Spezifikationen termingerecht abzuliefern. In den Hintergrund treten nach und nach die Bedürfnisse der benachbarten Teams und des übergeordneten Projektmanagements. Dies hat zur Folge: Startet zum Beispiel das Architekturteam die Anfrage, ein Review des Architekturdokuments durchzuführen, wird dies von den anderen Teams als Störung empfunden. „Sollen die sich doch selbst um ihre Qualität kümmern. Wir haben schließlich Termine, die wir einhalten müssen.“ Wo bleibt bei einem solchen Verhalten der Kundennutzen? Auf der Strecke!
Nachteile einer klassischen Projektarchitektur
Folgende Faktoren mindern bei einer klassischen Projektarchitektur oft den Kundennutzen:
- Kaum nachprüfbare Resultate. Jedes Team liefert Resultate, die für sich betrachtet, kaum nachprüfbar sind. Erst zusammen mit den Resultaten der anderen Teams entsteht ein Kundennutzen. Das heißt in der Praxis zumeist: 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 tragfähig ist und ob die umgesetzten Anforderungen wirklich zu den aktuellen fachlichen Bedürfnissen passen. In der Regel sind bis dahin sechs bis zwölf Monate vergangen.
- Hoher Aufwand für die Integration. Das Integrieren der Teilergebnisse erfordert einen immensen Zusatzaufwand. Die Spezifikation ist mit der Architektur abzugleichen, die Softwarekomponenten der Teams sind in das Gesamtsystem zu integrieren, die Testfälle und 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. All diese Tätigkeiten liefern keinen direkten Kundennutzen.
- Hoher Aufwand für den Know-how-Transfer. Bei der Übergabe von Zwischenergebnissen (in der Regel sind dies Dokumente) geht stets Know-how verloren. So erarbeitet sich das Analyseteam zum Beispiel nach und nach ein fundiertes Verständnis für die fachlichen Bedürfnisse und die Abläufe. Die anderen Teams erhalten aber nur Spezifikationsdokumente, die nur einen Teil dieses Know-hows widerspiegeln (auch weil eine Spezifikation, die alle Nuancen der Fachlichkeit enthält, wirtschaftlich unsinnig wäre). Also müssen die anderen Teams, um sich das erforderliche Wissen selbst zu erarbeiten, (meist ungeplant) auf die Ressourcen des Analyseteams zurückgreifen. Und 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. Sie entstehen durch Liegezeiten der Zwischenergebnisse, weil die Taktrate der einzelnen Teams nur schwer miteinander zu synchronisieren sind, aufwändige Abnahmeverfahren für Zwischenergebnisse, um die Qualität an den Schnittstellen sicherzustellen, und zeitintensive Korrekturschleifen, da Änderungen an Endergebnissen meist wieder ganz am Anfang der Kette starten müssen und danach sequentiell durch die Teamstruktur weitergereicht werden.
Feature-Teams: Eine organisatorische Alternative
Ein höherer Kundennutzen als bei der klassischen Projektarchitektur entsteht in der Regel bei folgender Organisationsform: Mehrere Teams arbeiten parallel und liefern in Zeitintervallen von jeweils zwei bis vier Wochen Features der Software, die ein fachliches Bedürfnis befriedigen. Jedes dieser Feature-Teams ist funktionsübergreifend zusammengesetzt, und zwar so, dass die Mitglieder alle erforderlichen Fähigkeiten für die Analyse, Architektur, Entwicklung und den Test mitbringen. Die Teams können aus Generalisten bestehen, die alles beherrschen, oder aus Spezialisten, die sich gegenseitig ergänzen. In der Regel sind in den Teams aber beide Mitarbeiter-Typen vertreten.
Aus folgenden Gründen erzeugen solche funktionsübergreifenden Teams einen größeren Kundennutzen:
- Sie liefern lauffähige Software anstelle von Dokumenten. Funktionsübergreifende Teams werden selbstverständlich weiterhin spezifizieren. Sie arbeiten auch weiter an der Systemarchitektur und schreiben Testfälle. Sie tun dies aber primär, um ihre Arbeit zum Beispiel für Wartungszwecke zu dokumentieren. Ansonsten geben sie ihre Erkenntnisse direkt an die anderen Teammitglieder weiter und lassen diese in die Software einfließen. Das reduziert den Dokumentationsaufwand.
- 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 so innerhalb des Teams ohne Zeitverzögerung aufeinander abstimmen, auch wenn es selbstverständlich einer übergreifenden, koordinierenden Abstimmung bedarf. Diese ist jedoch 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 Feature-Teams verbreiten sich neue Erkenntnisse über die fachlichen Bedürfnisse sofort – unter anderem, weil jedes Teammitglied prinzipiell direkt mit dem Kunden, Fachexperten oder seinem projektinternen Stellvertreter reden kann. Zudem kann das Team an einem Tisch besprechen, welche Auswirkungen neue Erkenntnisse auf die jeweiligen Ergebnisse haben und Beschlüsse fassen sowie direkt umsetzen. Und dies geschieht auch, weil das Team sich, gruppendynamisch gesprochen, statt mit Zwischenergebnissen mit den Bedürfnissen des Kunden identifiziert.
- 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 Feature-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 liebgewonnenen Stellen. Teamleiter von Spezialistenteams (zum Beispiel 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 Feature-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 zum Beispiel 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 und es sich an neue Erkenntnisse anpasst.
Die Planung stellt ebenfalls eine neue Herausforderung dar. Wo früher eine verrichtungsorientierte 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 ist dies eine Aufgabe, die einiges von Projektleitern abverlangt. Sie müssen ihren Arbeitsschwerpunkt vom Managen auf das Führen verlagern. Und sie müssen liebgewonnene Methoden durch eine gehörige Portion gesunden Menschenverstand ersetzen.
(Bild: © endostock – Fotolia.com)