Die richtige Reihenfolge macht’s

Wenn neue Vorhaben umgesetzt oder Projekte aufgesetzt werden, ist die Kenntnis der Anforderungen essentiell. Aber nicht jede Anforderung ist gleich wichtig. Eine einfache Methode, diese zu priorisieren, ist die MoSCoW-Methode

Auf nach Moskau?

Wie so viele Abkürzungen aus dem Management ist MoSCoW ein Kunstwort – und hat nichts mit der russischen Hauptstadt gemein. MoSCoW steht für Must, Should, Could und Won’t. Die Idee ist, Anforderungen an ein System in Wichtigkeit und Auswirkung zu kategorisieren.

Und wie so viele Methoden ist MoSCoW im Prinzip ziemlich einfach. Und richtig angewandt auch sehr wirksam. 😉

Ausgangslage

Ein Projekt steht vor der Tür, ein Produkt soll entwickelt werden. Oder ein System gebaut oder ein Vorhaben umgesetzt werden. An dieses künftige Endergebnis werden Anforderungen gestellt. Üblicherweise werden diese Anforderungen (gerne auch mit dem englischen Begriff Requirements bezeichnet) an das Endprodukt in einem mehr oder weniger aufwändigen Prozess erhoben. Am Ende gibt es einen Wust von Anforderungen, der die Systementwickler und/oder den Auftraggeber vor ein Orientierungsproblem stellt. Priorisierung ist angesagt.

Abhilfe verspricht die Einteilung der Anforderungen in vier Kategorien

• Muss sein
• Sollte sein
• Könnte sein
• Brauchen wir im Moment nicht

Die jeweiligen englischen Begriffe ergeben das Kunstwort MoSCoW – wobei das erste „o“ schon ein massives Zugeständnis an die Eselsbrücke darstellt 🙂

M – MUST (Muss sein)

Das M für MUST bennent und kennzeichnet Anforderungen, die wichtig und nicht verhandelbar sind. Es handelt sich hierbei um Basisfunktionalitäten, die das Wesen des Produktes oder Ergebnisses ausmachen. Ein Smartphone – egal wie viele Pixel und wie groß der Speicher – muss telefonieren können. Eine ausbleibende Umsetzung würde zum Scheitern des Produkts bzw. Projekts führen.
MUST ist darüberhinaus auch seblst ein Akronym und bedeutet: Minimal Usable SubseT – auf gut deutsch Minimalanforderung.

S – Should (Sollte sein)

Die SHOULD-Anforderungen sind bei weitem nicht so erfolgskritisch wie die MUST-Anforderungen. „Sollte sein“ ist nicht das Gleiche wie „Muss sein“. Trotzdem haben sie für das Produkt bzw. Projektergebnis eine hohe Relevanz. Kein Vorhaben kann nur von „Muss sein“ leben, es braucht auch eine Portion von realisierten „Sollte-sein“ Anforderungen. S-Anforderungen können auch Begeisterungselemente sein, die den Erfolg von Produkten und Projekten erst richtig beflügeln.

C – COULD (Könnte sein)

Die C-Anforderungen sind etwas kritisch zu betrachten. Ganz schnell stehen hier eine ganze Anzahl von Anforderungen, die keinen wirklichen Mehrwert für das Projektprodukt bieten. Es ist sinnvoll, nach der ersten Priorisierungsrunde die C-Anforderungen nochmals genauer unter die Lupe zu nehmen.

Denn COULD-Anforderungen können eine erheblichen Mehrwert generieren: Wenn sie bei geringen zusätzlichen Entwicklungskosten umgesetzt werden, sind es sinnvolle Erweiterungen des Requirement-Portfolios..

W – WON’T (wollen wir jetzt nicht)

W-Anforderungen sind Aspekte, die im Moment keine Relevanz haben, aber trotzdem aufgenommen werden. Sie bilden eine Art Vorratsspeicher für künftige Weiterentwicklungen. Von daher kommt den W-Anforderungen eine ganz besondere Bedeutung zu, weil sie zum bestehenden Zeitpunkt bereits eine Perspektive bilden.

Ein weiterer Vorteil von W-Anforderungen ist die „wertschätzende“ Berücksichtigung von nicht-zeitkritischen Requirements. Sie sind zwar fachlich wichtig, aber eben nicht zum nächsten Termin.

In agilen Umgebungen würden sich die W-User-Stories unterhalb der MVP/MMP-Schwelle befinden.

MoSCoW statt 1, 2, 3, 4

Man mag einwenden, dass diese Priorisierung auch durch einfache Nummernvergabe von 1 bis 4 erreicht werden könnte. Stimmt aber nicht ganz. Eine 4-Anforderung steht einfach nur ganz hinten. Klingt unwichtig und überflüssig. Eine W-Anforderung ist wertschätzender und sagt nichts über Relevanz, sondern nur über Dringlichkeit.

Nachteile von MoSCoW

• Die Kategorisierung ist relativ allgemein und gibt innerhalb der Kategorien keine Hinweise auf die Bearbeitungsreihenfolge. Deshalb ist es ratsam, zumindest die „Muss“- und „Soll“-Anforderungen genauer zu analysieren. Bei der feineren Sortierung sind Faktoren wie technische Abhängigkeiten, Aufwand und Ressourcen von Bedeutung.
• Häufig werden zu viele Anforderungen als unverzichtbar („Muss“) eingestuft. Das Einordnen in andere Kategorien kann dazu führen, dass diese Anforderungen verzögert oder sogar nicht umgesetzt werden. Es gibt Empfehlungen, höchstens 60% der Anforderungen als unverzichtbar zu deklarieren, doch solche Vorschläge sind nicht zielführend. Sie adressieren nicht die Bedenken der Anforderungssteller, ignorieren die Entwicklungskapazitäten und klären nicht, welche Anforderungen zu den besagten 60% gehören.
• Wie bei vielen Methoden ist auch hier eine Momentaufnahme gegeben. Stakeholder können ihre Meinungen ändern, es können technische Probleme auftreten und neue Anforderungen oder Änderungen können hinzukommen. Daher ist es üblich, dass Anforderungen innerhalb der Kategorien verschoben werden.
• Oftmals wird empfohlen, sich an den Wünschen der Stakeholder zu orientieren. Es gibt jedoch differenziertere Konzepte, wie das Kano-Modell der Kundenzufriedenheit. Unternehmen sollten daher in Erwägung ziehen, verschiedene Methoden und Ansätze für eine umfassende Analyse und Priorisierung zu kombinieren.

Letzte Aktualisierung: 12.03.2024 / Copyright Gita GmbH / PMI, PMP und PMI-ACP sind eingetragene Warenzeichen des Project Management Institute, PMI (www.pmi.org) / WTIN: M1016