Das Microsoft Solutions Framework (Teil 1)

Veröffentlicht: 07. Sep 2001 | Aktualisiert: 16. Jun 2004

Von Michael W. Dietrich

Das Microsoft Solutions Framework (MSF) ist ein Prozessmodell, das Infrastrukturprojekte genauso unterstützt, wie die Softwareentwicklung. Diese zweiteilige Artikelfolge gibt eine kurze Einführung und ordnet das MSF in das Lebenszyklusmodell für IT-Systeme, das Enterprise Solutions Framework ein.

Auf dieser Seite

 Kritik bestehender Vorgehensmodelle
 Das Teammodell des MSF
 Die Verantwortung der Teammitglieder im Detail
 Skalierung des Teammodells
 1. Feature Teams
 2. Function Teams
 Das MSF Prozessmodell
 Ausblick

Diesen Artikel können Sie hier lesen dank freundlicher Unterstützung der Zeitschrift:

Die IT-Branche wird besonders in den Bereichen Client/Server- und webbasierte Systeme weitgehend von Quereinsteigern geprägt. Daher wird bei der Entwicklung von IT-Systemen meist nicht ingenieurgemäß vorgegangen. Damit ist nicht nur das Scheitern der Bemühungen vorprogrammiert. Auch der Erfolg, sofern er sich einstellt, ist nicht reproduzierbar.

Die Standish-Group, die jährlich die sogenannte Chaos-University veranstaltet, hat kürzlich die neuesten Untersuchungsergebnisse veröffentlicht. Diese belegen, hier in der historischen Reihung besonders eindrucksvoll, dass die IT-Branche besonders das Problem gefährdeter Projekte nicht in den Griff bekommt. (Als gefährdet gelten dabei Projekte bei denen Budget- oder Zeitpläne um mindestens 10% überzogen wurden oder in denen Teile der Funktionalität nicht realisiert wurden).

Als Top 5 Ursachen für das Scheitern beziehungsweise die Gefährdung von IT-Projekten nennt die Standish Group

1. fehlende Einbeziehung der Benutzer in alle Projektphasen (dadurch mangelnde Benutzerakzeptanz)

2. mangelnde Unterstützung des Projekts durch das Management

3. unerfahrene Projektmanager

4. fehlende betriebswirtschaftliche Begründung

5. unzuverlässige Aufwandsabschätzungen

All diesen Problemen rücken die sogenannten Vorgehens- oder Prozessmodelle auf den Leib. Die in Deutschland bekanntesten dieser Modelle sind das V-Modell und der Rational-Unified-Process (RUP). Was also bewegte Microsoft bereits vor mehr als 5 Jahren mit dem Microsoft Solutions Framework selbst ein Modell vorzustellen?

Kritik bestehender Vorgehensmodelle

Die bekannten Vorgehensmodelle geraten trotz der tatsächlich bestehenden Probleme in der IT-Branche, dort, wo sie in Reinkultur eingeführt werden sollen, schnell in die Kritik. Dabei sind die folgenden Fragestellungen durchaus ernst zu nehmen:

1. Passen die im Modell genannten Vorgehensweisen zur Unternehmenskultur? Wenn nein: Ist eine Änderung der Unternehmenskultur ohne große Verluste (Personal, Zeit etc.) überhaupt möglich?

2. Kann ein Vorgehensmodell überhaupt Top-Down und in Reinkultur eingeführt werden oder muss es aus dem Unternehmen heraus wachsen?

3. Induzieren diese Vorgehensmodelle mit und nach ihrer Einführung nicht einen übermäßigen Verwaltungsaufwand? Ist dieser kalkulierbar? Sind Kunden bereit, dafür zu bezahlen?

4. Warum beschäftigen sich die bekannten Modelle nur mit Softwareprojekten, nicht aber mit Infrastrukturprojekten?

5. Welche Antworten haben die Vorgehensmodelle auf die Probleme, die sich im Lebenszyklus eines IT-Systems außerhalb von Projekten ergeben (Stichworte: Unternehmensplanung, Betrieb des Systems, strategische Systemarchitektur ...)?

Aus diesen Fragestellungen heraus hat Microsoft das Solution Framework entworfen:

1. Das MSF stellt ein Framework (eine Art Fachwerk) dar, das Gedächtnisstützen formuliert, deren Ausgestaltung aber der Unternehmenskultur überlässt.

2. Das MSF lässt sich mit beliebigen im Unternehmen bereits vorhandenen Organisations- und Ablaufschemata kombinieren. Es kann in das Unternehmen organisch hineinwachsen.

3. Das MSF schreibt die Verwaltungsvorgänge nicht explizit vor. Deshalb können mit Hilfe des MSF nicht nur sehr großen Projekten sondern auch kleine Projekte erfolgreich gestaltet werden.

4. Das MSF stellt Infrastrukturprojekte gleichberechtigt neben Software-Entwicklungsprojekte.

5. Das Enterprise Solutions Framework (ESF) beinhaltet neben dem MSF (welches nur die "Projekt"-Phase des Lebenszyklus beschreibt) weitere Modelle.

Bei allen in der Folge erwähnten Details sollte also im Auge behalten werden, dass das MSF lediglich Vorschläge für eine mögliche Realisierung, nicht aber die tatsächliche Implementierung vorgibt.

 

Das Teammodell des MSF

Beim Teammodell des MSF handelt es sich nicht um ein Organigramm. Stattdessen werden sechs Rollen definiert, die den Hauptverantwortungsbereichen innerhalb eines IT-Projektes entsprechen. Die Besetzung der Rollen mit Personen, sowie die möglichen Kombinationen von Rollen, beschreibt das MSF getrennt von der Beschreibung der Teamrollen.

B2. Die Definition der Teamrollen des MSF

Beim Teammodell des MSF handelt es sich um ein sogenannte „Team of Peers"-Modell, was mit "Team gleichberechtigter Partner" nur ungenügend übersetzt werden kann. Wie gesagt handelt es sich nicht um ein Organigramm, das heißt: wer wessen Vorgesetzter ist wird nicht durch das Teammodell festgelegt. Stattdessen legt das Teammodell eine Verteilung der Verantwortlichkeit für die gemeinsame Sache (das Projekt) fest und regelt die Zusammenarbeit innerhalb eines kleinen Teams mit multidisziplinären Rollen.

An dieser Stelle ist übrigens in den MSF-Kursen regelmäßig die lauteste Kritik zu hören. Wie kann Verantwortung geteilt werden, wer kriegt denn nun den Kopf gewaschen, wer wird gefeuert, wenn das Projekt nicht den gewünschten Erfolg hat oder gar scheitert? Die Antwort des MSF ist so verblüffend einfach, wie die Frage das bisher falsche Verständnis von Projektmanagement offenbart. Die Antwort des MSF lautet: Niemand wird gefeuert! Wieso auch - wir planen für den Erfolg und nicht für das Scheitern.

Meiner Meinung nach beinhaltet diese Antwort des MSF übrigens den entscheidenden Kritikpunkt an dem Verwaltungs-Overhead, den andere Prozessmodelle produzieren: So dient die Mehrzahl der Dokumente im V-Modell lediglich der Entschuldigung des Erstellers für den Fall, dass das Projekt scheitert. Mit Hilfe dieser Dokumente wird ausschließlich das persönliche Risikomanagement von Menschen gefördert, die nicht bereit sind, Verantwortung für das Gelingen zu übernehmen. Wer aber nicht Verantwortung für den Erfolg übernimmt, ist automatisch für den Misserfolg mitverantwortlich.

So ist eines der wichtigsten Prinzipien des MSF-Teammodells die "Ermächtigung" des Projektteams. Das heißt, das Projektteam hat die Macht, im Rahmen der Beschränkungen des Projektes (Budget, Zeitplan, Featureliste) alle wichtigen Entscheidungen selbst zu treffen. Nur so kann Verantwortung übernommen werden. Wie könnte ein Projektmitarbeiter Verantwortung übernehmen, wenn wichtige Entscheidungen bezüglich der Projektrahmenbedingungen von außen diktiert würden?
Ein weiteres wichtiges Prinzip ist die sogenannte "Shared Project Vision". Dabei geht es nicht so sehr darum,
T-Shirts mit einem Projektslogan zu drucken (obwohl dies hin und wieder keine schlechte Idee sein mag). Es geht vielmehr darum, dass alle Projektbeteiligten (Team und Kunde) die Ziele und Maßgaben des Projektes in gleicher Weise verstehen. So werden unterschiedliche und sich widersprechende Visionen vermieden. Statt dessen wird ein Konsens darüber hergestellt, was das Projekt erreichen soll, warum es durchgeführt wird und innerhalb welcher Grenzen und Schranken sich das Projektteam frei bewegen kann.

Daneben gibt es weitere wichtige Prinzipien. Zum Beispiel betrachtet das MSF das Ziel eines jeden Projekts als Produkt. So wird das Team auf die Produktion statt auf den Prozess fokussiert und die Identifikation der einzelnen Teammitglieder mit dem Endergebnis verstärkt. Besonders aber wird so der Gedanke eines gemeinsam zu schaffenden Ganzen gegenüber den Teilaufgaben der einzelnen Teammitglieder in den Vordergrund gerückt. Zero-Defect (Fokussierung auf höchste Qualität), Kundenorientierung und Lern­bereitschaft jedes Einzelnen sind weitere allgemein anerkannte Prinzipien, die das MSF durch sein Teammodell fördert und verstärkt.

 

Die Verantwortung der Teammitglieder im Detail

Nun zu den Verantwortlichkeiten der Rollen im Einzelnen. Wie bereits erwähnt, handelt es sich hierbei noch nicht um konkrete „Posten".
Product Management beschreibt die Rolle des "Anwaltes" (oder im deutschen besser Sachwalters) des Kunden im Team. "Der Kunde" ist dabei als der Geldgeber oder "Der, der bezahlt" definiert.

• Product Management vertritt die Sache des Kunden dem Team gegenüber, aber auch das Team dem Kunden gegenüber.

• Product Management ist für eine teamübergreifende Projekt-Vision und die Ausrichtung des Projektteams auf das jeweils nächste zu erreichende Teilziel verantwortlich.

• Das Management der Kundenerwartungen ist eine weitere wichtige Aufgabe dieser Rolle.

• Wenn es darum geht, Entscheidungen Feature vs. Zeitplan zu treffen, dann ist diese Rolle die treibende Kraft.

• Das Verständnis des betriebswirtschaftlichen Ziels im Team und wie man es mit Hilfe des Projekts erreicht, wird durch diese Rolle getragen und weiterentwickelt.

Die Rolle Program Management des MSF entspricht wohl am ehesten dem, was in klassischen Projekten als "Projektleiter" verstanden wird. Wichtige Aufgaben dieser Rolle sind

• die Verantwortung für Projekt- und Zeitpläne sowie deren Reporting

• die Belegung von Ressourcen (Einsatzplanung)

• die Moderation der Teamkommunikation

• das Vorantreiben kritischer Entscheidungsprozesse

Im Gegensatz zur betriebswirtschaftlichen Sicht des Product Managers hat der Program Manager eher eine technische Sicht (Systemarchitekt) auf das Projekt.
Die Rolle Development wird in Infrastrukturprojekten etwas anders definiert, als in Software-Entwicklungsprojekten. Beiden Projektarten gemeinsam ist die Verantwortung der Development Rolle für

• das Erstellen der Features zur Erfüllung der Erwartungen des Kunden

• das Systemdesign mit Schwerpunkt auf dem physischen Design (das logische Design liegt eher beim Program Manager)

• die Abschätzung des Aufwandes (Arbeitszeit und Dauer) für die Realisierung einzelner Features

Im Infrastrukturprojekt hat Development darüber hinaus in der Hauptsache die Verantwortung für

• die Auswahl der Technologie für das Deployment

• das Schreiben von Scripts als Unterstützung für Installation und Deployment

• die Konfiguration und kundenspezifische Anpassung

Im Software-Entwicklungsprojekt liegt dagegen die Betonung der Verantwortung der Rolle Development zusätzlich auf

• der Beratung des Teams in technischen Fragen.

Die Hauptaufgabe der Testing-Rolle ist, zu gewährleisten, dass alle Problemquellen bekannt sind. Dafür

• entwickelt sie eine Teststrategie und Testpläne

• entwickelt sie Testscripts

• übernimmt die Verantwortung für die Systemintegration (Build)

• stellt den Status des Systems aufgrund der regelmäßig durchgeführten Tests fest

• nimmt an der Definition der zu erreichenden Qualitätskriterien teil

User Education ist der "Anwalt" (oder besser Sachwalter) des Systembenutzers im Team. Seine Hauptaufgaben sind somit

• die Sache des Anwenders dem Team gegenüber, aber auch die Sache des Teams dem Anwender gegenüber zu vertreten. Darüber hinaus verantwortet der „User Ed" (wie er manchmal genannt wird)

• die Definition der Benutzeranforderungen

• die Erstellung von Support- und Helpdesk-Systemen

• die laufende Verbesserung der Benutzerfreundlichkeit des Systems

• die Teilnahme am Design benutzerrelevanter Features, sowie

• die inhaltliche Vorbereitung und Durchführung der Enduser Trainings sind eine weitere wichtige Aufgabe des User Ed.

Bei der Einführung des MSF entzündet sich oft die Diskussion an dem Punkt, warum diese Aufgabe - insbesondere bei der Erstellung von Individualsoftware - nicht auch vom Product Manager übernommen werden kann. Es darf aus der Erfahrung, nicht nur der Standish Group, berichtet werden, dass gerade der Anwalt des Kunden und der Anwalt des Anwenders innerhalb eines Projektteams die größten Konflikte auszutragen haben.

Zum Beispiel ist dem Kunden die Realisierung eines bestimmten Features oft zu teuer. Die Anwender andererseits aber glauben, ohne dieses Feature gar nicht arbeiten zu können. Andererseits aber werden die Anwender einen unter Umständen neu einzuführenden betriebswirtschaftlichen Ablauf (Business Case) in all seinen Auswirkungen noch nicht so gut beurteilen können, wie die betriebswirtschaftlichen Organisations- und Planungsabteilungen, die diesen definiert haben. Das Konfliktpotential in diesen beiden Rollen ist einer der wesentlichen Gründe dafür, dass "mangelnde Benutzerakzeptanz" die Hitliste der Standish Group für das Scheitern von Projekten anführt.

Aus dem Microsoft-Nähkästchen darf vielleicht soviel geplaudert werden, dass das einzige bisher bei Microsoft intern als "gescheitert" betrachtete Projekt ("Bob", eine grafische Benutzeroberfläche für Kinder) vor vielen Jahren genau an diesem Punkt (Benutzerakzeptanz) scheiterte.
Logistics Management In dieser Rolle wird deutlich, warum nach MSF jedes Software-Entwicklungsprojekt auch ein Infrastrukturprojekt beinhaltet. Jede Software muss, nachdem Sie entwickelt und stabilisiert wurde, irgendwann mindestens einmal ausgeliefert und installiert werden. Je häufiger, desto besser, möchte man sagen, soweit man Geld mit Software-Lizenzen verdient. Aber Hand aufs Herz, wann beginnt man in einem Projekt wirklich, sich Gedanken um die Auslieferung, die Installation oder gar eine Support-Hotline und ein Helpdesk-System zu machen? Die Aufgabe der Logistics Management Rolle ist also

• Vertreten der Sache des Betriebsteams im Projektteam und umgekehrt

• Die Planung des Rollout (Deployment)

• Die Teilnahme an allen Designaktivitäten mit Fokus auf Wartbarkeit, Unterstützbarkeit und Auslieferungs-/Installationsfähigkeit des zu erstellenden Systems - eine allzu häufig auch in sogenannte "erfolgreichen Projekten" weit unterschätzte Eigenschaft eines IT-Systems

• Die Planung und Organisation der Anwender-Trainings, sowie

• das Training der Betriebsmannschaft und der Helpdesk-Mitarbeiter

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).

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.

Rolle	Haupt-Projektziele
Product Management	Zufriedener Kunden
Program Management	Lieferung innerhalb der Projektgrenzen (Budget, Zeitplan, Featureset)
Development	Lieferung gemäß Produktspezifikation
Testing	Release nach Lösung aller Probleme
User Education	Gesteigerte Benutzerzufriedenheit und Benutzerperformance (Leistung)
Logistics Management	Reibungslose Auslieferung und Installation

T1: Zuordnung von Rollen zu Haupt-Projektzielen

 

Skalierung des Teammodells

MSF unterstützt Teams sowohl kleiner als auch großer Projekte. Es wurde bereits in Mini-"Teams" mit nur einem einzigen Teammitglied eingesetzt, und auch in Projektteams mit mehreren hundert Projektmitgliedern kann es erfolgreich eingesetzt werden.

Für kleine Projektteams müssen unter Umständen Rollen kombiniert werden. Dafür schlägt das MSF folgende Matrix vor
Die mit U wie "Unwahrscheinlich" oder N wie "geht NICHT" gekennzeichneten Rollenkombinationen sind dabei häufig vor allem inhaltlich unwahrscheinlich oder unmöglich. Dies gilt besonders, weil die unterschiedlichen KnowHow-Schwerpunkte einzelner Personen berücksichtigt werden müssen. So setzen das Product Management mit betriebswirtschaftlichem Hintergrund und das Program Management mit technischem Hintergrund sehr unterschiedliche Fähigkeiten voraus, die sich nur schlecht kombinieren lassen.

Vor allem gibt diese Matrix aber eine gute Grundlage für das später noch tiefer zu erörternde Risikomanagement, das zu den Empfehlungen des MSF gehört. Dabei sind Rollenkombinationen, die mit "P" gekennzeichnet sind normalerweise eher mit einem geringeren Risiko behaftet als Rollenkombinationen, die mit einem "U" oder einem "N" gekennzeichnet sind.

Ausdrücklich gewarnt wird aber aus persönlicher Erfahrung nochmals vor der Kombination der Rollen User Education und Product Management, soweit es sich um ein Software-Entwicklungsprojekt für Individualsoftware handelt. Insbesondere, wenn diese Rollen vom Kunden selbst besetzt werden, ist dort oft die Einsicht noch nicht gereift, wie sehr die Ziele von Kunde und Benutzer voneinander abweichen können. Sollte sich die Rollenkombination dennoch nicht vermeiden lassen, ist sie dringend als Risiko zu identifizieren und entsprechend zu bewerten.

Für große Projekte muss das Teammodell unter Umständen so erweitert werden, dass zusätzliche Teammitglieder integriert werden können. Es bieten sich hier zwei Ansätze an, die nach Belieben kombiniert werden können und gegebenenfalls auch müssen.

 

1. Feature Teams

B5. Scalierung des Team Modells (Feature teams)

Feature Teams sind wohl die Alternative, die jedem mit Projektmanagement befassten als erstes einfallen. Es werden Teilprojektteams gebildet, deren Aufgabe die Realisierung eines bestimmten Features, oder besser Featuresets, ist. Im MSF bedienen sich die Feature Teams dort, wo sie keine eigenen Besetzungen für ihre Rollen haben, der Rollen aus dem sogenannten Lead Team. So sind in einem Feature Team ausschließlich die Rollen Program Management, Development, Testing und User Ed besetzt. Das heißt, die Aufgaben Product Management und Logistics Management für dieses Team werden von Mitgliedern des Lead-Teams wahrgenommen.

 

2. Function Teams

Die sogenannte Function Teams tragen der Arbeitsüberlastung einzelner Teammitglieder in großen Projekten Rechnung. Es ist leicht einzusehen, dass in Projekten ab einer gewissen Größenordnung einzelne Rollen nicht mehr nur von einer Person wahrgenommen werden können, sondern stattdessen ein Product Management Team oder auch ein Development Team gebildet werden. Im Schaubild sieht dies dann zum Beispiel wie im Bild B6 gezeigt aus.

B6. Scalierung des Team Modells, hier function Team Product Management

Die Kombination von Feature Teams mit Function Teams lässt die Integration mehrerer zig, wenn nicht gar hunderter, Teammitglieder im Rahmen des MSF zu.

 

Das MSF Prozessmodell

So wie das MSF-Teammodell hilft, den Fallstricken und Gefahren rein hierarchischer Teammodelle und Kommunikationsstrukturen (Berichtswesen) zu entgehen, so hilft es als Spiralmodell den Fallgruben reiner Wasserfallmodelle alten Stils zu begegnen (Bild B7). Allerdings nimmt das MSF-Prozessmodell den Gedanken der Meilensteine aus der Welt der Wasserfallmodelle. Das Prozessmodell ist nicht exakt vorgeschrieben, sondern kann den Gegebenheiten im konkreten Betrieb angepasst werden.

Bei der Definition für einen Meilenstein steht die Übereinstimmung aller Teammitglieder (Konsens) über das Ziel im Mittelpunkt und nicht so sehr der Zeitablauf. Und schließlich kombiniert das MSF-Prozessmodell die Vorteile eines Meilenstein-getriebenen Prozesses mit der Flexibilität eines iterativen Prozessmodells.

Das MSF-Prozessmodell beschreibt also einen von Meilensteinen getriebenen Prozess. Dabei wird zwischen extern sichtbaren und Interim-Meilensteinen unterschieden. Die extern sichtbaren Haupt-Meilensteine stehen dabei für einen Synchronisationspunkt, an dem alle Team-Mitglieder, wie auch der Kunde, Einigkeit darüber erzielen, dass jetzt die nächste Projektphase beginnen wird. Die Meilensteine des MSF sind daher Zeitpunkte der Synchronisation zwischen den Teammitgliedern und keine Fixpunkte, an denen unverrückbare Tatsachen geschaffen werden.

Das MSF definiert für jeden Meilenstein sogenannte Deliverables. Ein Meilenstein wird entsprechend nicht etwa durch reinen Zeitablauf erreicht, sondern eben dadurch, dass alle Deliverables in dem Zustand vorliegen, in dem sie für das Erreichen des Meilensteins definiert wurden.

Das Spiral-Modell (andernorts auch Rapid Application Development Modell genannt) beschreibt dabei einen Prozess, bei dem die unterschiedlichen Projektphasen für jedes Release erneut durchlaufen werden.

Die Vorteile der versionierten Releases des Spiralmodells liegen dabei klar auf der Hand.

• Klare motivierende und erreichbare Ziele können gesetzt werden (zum Beispiel entsteht kein Projektmoloch über mehrere Jahre, der weder Urlaub noch Fort- und Weiterbildungsphasen erlaubt).

• Eine schnelle, abschließende Entscheidung über Projektprobleme wird erzwungen. Die Verschiebung eines Features in ein weiteres Release zum Beispiel stellt keine Katastrophe mehr dar, wenn klar ist, wann dieses Release kommen wird und dass der Zeitplan eingehalten werden wird. Die Priorisierung von Features wird erleichtert.

• Die Unsicherheit, die der Zukunft nun mal per Definition innewohnt, wird durch kurze Releasezyklen minimiert.

• Eine kontinuierliche inkrementelle Lieferung von Features wird unterstützt. Dadurch steigt das Vertrauen von Kunden und Benutzern in die Fähigkeit des Projekt-Teams, ein Produkt auszuliefern.

• Es ist wichtig für Investoren, denen mit dem Geld auch die Geduld auszugehen droht, dass der Zeitpunkt, ab dem mit dem ersten Release bereits Geld verdient werden kann, entscheidend vorverlegt wird.

• Neue Versionen und Features mit niedriger Priorität werden möglicherweise zu einem späteren Zeitpunkt gar nicht mehr gebaut und ausgeliefert, weil sich herausstellt, dass sie keinen zusätzlichen betriebswirtschaftlichen Nutzen mehr generieren können.

Das Mapping der Teamrollen als primäre Treiber bezogen auf die einzelnen Meilensteine ist dabei laut MSF so zu verstehen, wie es in Tabelle T2 dargestellt ist.

Meilenstein	Primär treibende Rolle
Vision Approved	Product Management
Project Plan Approved	Program Management
Scope Complete	Development und User Ed
Release	Testing und Logistics Management

T2: Zuordnung von Rollen zu Haupt-Meilensteinen

Wobei diese Tabelle wiederum nicht so zu verstehen ist, dass die genannten Rollen nur in dieser Projektphase aktiv sind, sondern, dass sie zur treibenden Kraft bei der Erreichung des jeweiligen Meilensteins werden.

Später wird noch gezeigt, dass zum Beispiel die Aufgaben der Testing Rolle, wie auch der Logistics Management Rolle, bereits mit der ersten Projektphase - der Envisioning Phase - beginnen. Das heißt nicht, dass diese Rollen in dieser Phase bereits eine 100prozentige Arbeitsbelastung haben, das heißt aber auch, dass diese Rollen in dieser ersten Projektphase bereits Aufgaben haben, die erledigt werden müssen, um den ersten major Meilenstein überhaupt zu erreichen.

 

Ausblick

In der kommenden Ausgabe widmen wir uns noch dem Thema der Konzeption und Dokumentation. Sie werden feststellen, dass MSF hier mit den „lebenden Dokumenten" ein sehr praxisgerechtes Modell aufweist, das gerade bei kleineren Projekten das Ersticken in sinnlosem Verwaltungsaufwand verhindert. Des weiteren geht es um Entscheidungsprozesse, die Anwendungsarchitektur und das Risiko-Management. Wer ausgiebigere Informationen zu diesem Thema sucht, sollte den Workshop zum Thema MSF im Rahmen der Advanced Developers Conference am 6. November dieses Jahres nicht versäumen.