Ist zu Projektbeginn eine genaue Aufwandsschätzung möglich, können Auftraggeber und Auftragnehmer den Leistungsumfang im Rahmen der Projektplanung festlegen. Lassen sich die Aufwände und Dauern für die Realisierung der Anforderungen hingegen nicht genau schätzen, sollte der Auftraggeber die Anforderungen sorgfältig priorisieren. Denn nur so lässt sich erkennen, welche Anforderungen unbedingt notwendig sind, um das gewünschte Projektergebnis zu erreichen, welche verhandelbar und welche lediglich Nice-to-Haves sind. Eine solche Priorisierung garantiert, dass das Projektteam selbst bei Problemen und Verzögerungen im Projektverlauf zumindest die wichtigsten Anforderungen liefert.

Doch wie kann eine gute Priorisierung in der Praxis gelingen? Ein einfaches Vorgehen hierfür ist die sog. MoSCoW-Methode.

Was bedeutet "MoSCoW"?

Die MoSCoW-Priorisierung ist eine vierstufige Prioritätenskala zur Bewertung von Anforderungen (Angermeier, 2014). Ein typischer Anwendungsbereich für diese Methode sind agile Projekte, in denen Anforderungen priorisiert werden und somit die Reihenfolge ihrer Abarbeitung feststeht. Auch PRINCE2 empfiehlt diese Methode, um offene Punkte, d.h. meistens Änderungsanträge, zu priorisieren. Darüber hinaus lässt sich das Vorgehen auch für die eigene Aufgabenplanung verwenden, um z.B. bei einer großen Fülle an Aufgaben Struktur in deren Abarbeitung zu bringen.

Der Begriff "MoSCoW" ist ein Akronym und bezeichnet eine vierstufige Priorisierungsskala (vgl. Angermeier, 2014 und Wikipedia):

• M - MUST (Die Umsetzung ist für die Abnahme zwingend erforderlich.)
• S - SHOULD (Anforderungen müssen ebenfalls umgesetzt werden, sind aber im Gegensatz zu den MUST-Anforderungen durch Change Requests oder Verhandlungen veränderbar.)
• C - COULD (Diese Anforderungen werden umgesetzt, wenn alle Must- und Should-Anforderungen erfüllt sind und noch ausreichend Ressourcen und Zeit zur Verfügung stehen.)
• W - WON'T (Diese Anforderungen werden im aktuellen Projekt noch nicht umgesetzt und stattdessen in einem Ideenpool oder der Anforderungsliste für das nächste Projekt gespeichert)

Vorteil der Methode

Das Besondere an der MoSCoW-Methode ist, dass sie auch Anforderungen dauerhaft festhält, die im aktuellen Leistungsumfang nicht umgesetzt werden können. Dies ist besonders für den Auftraggeber interessant, da dieser aus Angst, dass Features verloren gehen, möglichst alle Features hoch priorisieren möchte; dadurch fällt eine klare Priorisierung in sehr wichtige, durchschnittlich wichtige und weniger wichtige Anforderungen häufig schwer. Werden jedoch weniger wichtige Anforderungen in einem Ideenpool festgehalten und ist dies dem Auftraggeber auch bewusst, fällt die Priorisierung leichter (vgl. Herwarth von Bittenfeld, 2011). Auf diese Weise ermöglicht die MoSCoW-Methode, dass die wirklich entscheidenden Dinge in jedem Fall umgesetzt werden.

Must: Keine Kompromisse!

Die Umsetzung von Anforderungen mit der Priorität "Must" ist Mindestvoraussetzung für die Abnahme des Projektergebnisses. Die Nicht-Umsetzung führt zwangsläufig zum Scheitern des Projekts. Um festlegen zu können, ob es sich bei einem Feature um ein "Must" handelt, benötigt man Entscheidungskriterien. Diese können z.B. sein (s. Kubitz, 2012 oder Herwarth von Bittenfeld, 2011):

• Ist das Produkt ohne dieses Feature funktionsfähig? Beispiel: Bei einer Logistiksoftware ist die Disposition des Fuhrparks nicht möglich.
• Ist ohne dieses Feature die Kundenzufriedenheit gewährleistet? Beispiel: Bei der Logistiksoftware ist zwar der Fuhrpark disponierbar, aber es gibt keine automatische Vorschlagsfunktion für geeignete Fahrzeuge.
• Erreicht das Produkt ohne dieses Feature die notwendige Qualität? Beispiel: Die Antwortzeiten der Logistiksoftware für Einbuchungen ist zu lang, sodass ein effizientes Disponieren nicht möglich ist.

Lassen sich diese Fragen mit "Nein" beantworten lassen, deutet dies auf eine Must-Anforderung hin.

Besonders der Punkt der Kundenzufriedenheit lässt viel Spielraum zu, da aus Sicht des Auftraggebers generell jedes Feature der Kundenzufriedenheit dient. Wird die Frage zur Kundenzufriedenheit mit "Nein" beantwortet, sollte man sich deshalb genau vor Augen halten, welcher "Schaden" dem späteren Nutzer tatsächlich entsteht, wenn er dieses Feature nicht bekommt. Sollte sich herausstellen, dass dieser Schaden zunächst vertretbar wäre, ist hier evtl. auch eine Einordnung unter "Should" sinnvoll. Die Einsortierung unter "Should" bedeutet schließlich nicht, dass das Feature nicht umgesetzt wird.

Should: Darüber können wir nochmal reden

Should-Anforderungen haben einen hohen Nutzen und der Kunde erwartet auch deren Umsetzung. Sie werden in der Projektplanung vollständig berücksichtigt und bilden mit den Must-Anforderungen den gesamten Leistungsumfang.

Kommt es jedoch im Projekt zu massiven Problemen und ist es absehbar, dass sich der gesamte Leistungsumfang (Must- und Should-Anforderungen) nicht innerhalb des gesetzten Budget- und Zeitrahmens realisieren lässt, treten die Should-Anforderungen gegenüber den Must-Anforderungen zurück. Das bedeutet im Umkehrschluss: Das Projekt wird auch dann abgenommen, wenn nicht alle Should-Anforderungen erfüllt sind.

Während Must-Anforderungen entscheidend für die Projektabnahme sind, können Should-Anforderungen in Abstimmung zwischen Auftraggeber und Auftragnehmer evtl. zu einem späteren Zeitpunkt nachgeliefert werden, vereinfacht werden oder mit Genehmigung des Auftraggebers sogar ganz entfallen (Angermeier, 2014).

…