Software-Projekte im Griff - Teil II

Bei der Entscheidungsmatrix des MSF handelt es sich nicht um eines jener betriebswirtschaftlichen akademischen Monster, die den Analysten bei der Erinnerung an ihr Studium Schweißperlen auf die Stirn treten lassen. Das Konzept sieht vor, sich ausschließlich um drei Parameter und eine von drei Einstellungsmöglichkeiten für jeden dieser Parameter Gedanken zu machen.
  Es wird gleich gezeigt werden, dass durch einen weiteren produktiven Vorschlag diese drei mal drei Matrix noch weiter vereinfacht wird. Diese fördert somit harte und beständige Entscheidungen nach einem vorher festgelegten und von allen Projektbeteiligten inklusive dem Kunden akzeptierten Entscheidungsschema.

Abb. Die Entscheidungsmatrix des MSF

Um es gleich vorweg zu nehmen, die in dieser Matrix gesetzten Häkchen sind nur einer von vielen möglichen Vorschlägen, wie die Pyramide aus Ressourcen, Zeitplan und Featureliste in der Balance gehalten werden kann. Eine Regel für diese Entscheidungsmatrix gilt jedoch: In jeder Zeile und in jeder Spalte darf nur ein Häkchen stehen. Dies vorausgesetzt, kann das Entscheidungsschema für das Projekt und das Release, zu dem die in B1 gezeigte Matrix gehört, wie folgt abgeleitet werden:
  1. Die Ressourcen (wahrscheinlich Personal und/oder Geld) sind beschränkt.
  2. Der Zeitplan soll möglichst optimiert, das heißt soweit möglich verkürzt werden. Daraus folgt:
  3. Es muss akzeptiert werden, dass in diesem Projekt und diesem Release Features möglicherweise nicht realisiert werden.

Wenn es nun also für das Projektteam zum "Schwur" kommt; wenn sich tatsächlich, wie oben beschrieben, ein wichtiges Planungsdokument während der Development Phase ändert; wenn also zum Beispiel neue unbedingt notwendige Features in das Projekt eingeführt werden - wie sehen dann die Entscheidungsalternativen aus? Können zusätzliche Entwickler in das Projekt gesteckt werden? Nein, die Ressourcen sind ja als beschränkt definiert.
  Kann eine Verzögerung des Zeitplanes hingenommen werden? Nein, die Definition gibt vor, dass in diesem Projekt und für dieses Release der Zeitplan zu optimieren ist (Auslieferung so schnell wie irgend möglich). Die einzig mögliche Entscheidung in diesem Projekt und diesem Release in der oben genannten Situation kann also sein, dass Features mit einer geringen Priorität gestrichen und/oder auf ein späteres Release verschoben werden müssen.

Da alle Projektbeteiligten sich von Anfang an auf dieses Entscheidungsschema als Grundlage für alle kritischen Projektentscheidungen geeinigt haben, kann es an dieser Entscheidung keinen Zweifel geben und die Frage kann nur lauten: welche Features, müssen wir streichen und/oder verschieben?
  Natürlich sind in anderen Projekten und für andere Releases andere Entscheidungsschemata denkbar. In allen Fällen muss aber im Auge behalten werden, dass
  1. alle kritischen Entscheidungen unter den so "eingeschworenen" Projektbeteiligten nur und ausschließlich nach dem vorher festgelegten Schema erfolgen, und
  2. sich nur die variablen Parameter ändern dürfen, während der festgelegte (constraint) unverändert bleibt.
  So ist es im oben genannten Entscheidungsschema zum Beispiel möglich, selbst bei absolut negativem Projektverlauf das Produkt, an dem das Team gemeinsam gearbeitet hat, innerhalb des Budgets und des Zeitplans, wenn auch mit etwas eingeschränktem Featureset auszuliefern.