Bei vielen größeren (IT-)Projekten verhindern starre Organisationsstrukturen und Projektpläne ein flexibles Reagieren auf neue Anforderungen. Eine häufige Folge: Der Kundennutzen bleibt auf der Strecke. Mit funktionsübergreifenden Feature-Teams gelingt der Spagat zwischen Sicherheit und Flexibilität.
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!