Software-Projekte im Griff - Teil I

Während also die Rollen User Education, Product Management, Logistics Management und Program Management eher nach außen gewandte kommunikative Rollen haben, sind die Rollen Development und Testing eher interne Rollen, die keinen Kontakt nach außen haben sollten. Insbesondere bei der Rolle Development ist Kontakt zum Kunden oder zu den Benutzern nach Meinung des MSF geradezu zu unterbinden. In diesem Fall wird die steuernde Funktion des Projektteams, zum Beispiel bei der Entscheidung welches Feature wann und mit welcher Priorität realisiert wird, konterkariert. Es kann sogar geschehen, dass durch direkten Kontakt der Entwickler mit den Endbenutzern Features Aufnahme in das Projekt finden, welche weder geplant wurden noch jemals bezahlt werden (es entsteht der sogenannte Feature Creep).

Abb. Innere und äußere Teamrollen

Eine weitere wichtige Stärke des MSF-Teammodells wird sichtbar, wenn den Hauptverantwortlichkeiten der einzelnen Rollen die wichtigsten Ziele eines Projektteams gegenüber gestellt werden. So kann zum Beispiel festgestellt werden, dass für jedes der sechs Haupt-Projektziele je ein Hauptverantwortlicher Rolleninhaber definiert ist. Die Rollen können immer als Erinnerung und Gedächtnisstütze für die sechs Blickwinkel betrachtet werden, aus denen heraus ein erfolgreiches Projekt ständig beobachtet werden muss. Dies gilt besonders dort, wo Rollen in Personalunion ausgefüllt werden oder sogar auch ganz losgelöst vom MSF gearbeitet werden muss.