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.

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.

Insgesamt ist das Verfahren sehr einfach und deutlich besser als die 1-2-3- oder a-b-c-Variante.

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