MoSCoW Methode: de uitleg

MoSCoW Methode: in dit artikel wordt de MoSCoW methode praktisch uitgelegd. Naast wat het is (betekenis, acroniem en herkomst), en welke voordelen verbonden zijn aan het gebruik van dit model, belicht dit artikel ook de vereisten van de MoSCoW methode, inclusief een praktisch voorbeeld. Ook leer je hoe het toepassen van deze methode jou en het team in staat stelt om deadlines op tijd te halen. Veel plezier met lezen!

Wat is de MoSCoW methode? De uitleg

Het stellen van prioriteiten is altijd lastig. Zeker als het gaat om het implementeren van nieuwe ideeën en/ of technologieën.

Iedereen binnen een organisatie wil altijd alles direct doorvoeren en dat is praktisch onmogelijk. Voor het stellen van prioriteiten zijn meerdere tools voor handen. De MoSCoW methode is hier één van.

Dai Clegg van softwarebedrijf Oracle bedacht MoSCoW, waarbij eisen een label krijgen en daardoor gemakkelijker te prioriteren zijn.

De oorsprong van deze methode ligt dus in de softwareontwikkeling, maar het is ook uitermate goed van toepassing voor marktintroducties, productintroducties, het opzetten van een nieuw bedrijf of veranderingsprocessen. Er worden met MoSCoW eisen aan het project- of productresultaat gesteld.

Bij de MoSCoW methode gaat het om het pakket van eisen in volgorde van prioriteit, waarbij aan de belangrijkste eisen in eerste instantie moet worden voldaan om een grote kans van slagen te hebben.

Acroniem

MosCoW is een samenstelling van beginletters die ergens voor staan. De 2x o zijn ingevoegd om het woord ‘moscow’ leesbaar te maken, zonder dat ze betekenis hebben. De M staat voor Must-haves, de S staat voor Should-haves, de C staat voor Could-haves en de W staat voor Won’t-haves of Would-haves.

Figuur 1 – MoSCoW acroniem uitgelegd

MoSCoW methode als eisenpakket en aanpak

Voordat men met de MoSCoW methode start is het aan te bevelen om allereerst te starten met het specificeren van het eisenpakket.

Bij het opstellen van de eisen moet zoveel mogelijk rekening gehouden worden met wat belanghebbenden belangrijk vinden. Door met betrokkenen te brainstormen kunnen er uiteindelijk goede kwalitatieve eisen tevoorschijn komen.

Ter voorkoming dat er onrealistische of heel dure eisen worden gesteld, worden ze in volgorde van prioriteit opgesteld. Het gaat er voornamelijk om, welke eisen de meeste toegevoegde waarde voor het bedrijf gaan opleveren. De projecteisen worden ingedeeld in één van de volgende categorieën:

M – Must-haves

Het gaat hier om het minimale eisenpakket dat vooraf gesteld wordt en waaraan het eindresultaat moet voldoen. Zonder deze eis, faalt het project en is het product niet meer bruikbaar. Het is vereist voor een werkbaar product en er is geen alternatief.

De Must-haves zijn essentieel. MUST wordt ook wel uitgelegd als het acroniem dat staat voor Minimum Usable SubseTs.

Voorbeeld: HBO Automotive studenten hebben als eindexamenopdracht een auto te ontwerpen en te maken, die in ieder geval kan rijden (minimale eisenpakket). Het is geen probleem wanneer er alleen sprake is van een chassis, zonder carrosserie.

Het gaat om de constructie van losse onderdelen en aandrijving naar de verbrandingsmotor. De Must-have is in dit geval, dat aan het einde van het studiejaar de auto moet kunnen rijden.

S – Should-haves

Dit zijn aanvullende en zeer gewenste eisen, die wel een hoge prioriteit hebben, maar geen vereiste zijn voor een bruikbaar eindproduct.

Zonder dat deze eisen worden ingewilligd is het product evengoed bruikbaar en met het voldoen aan de eisen krijgt het product alleen maar meerwaarde. Afhankelijk van de tijd kan er altijd later nog aandacht aan deze eisen worden gesteld.

Voorbeeld: De HBO Automotive studenten willen misschien de auto van een trekhaak voorzien (should-have), maar als de auto kan rijden zonder de trekhaak, is hun project toch geslaagd. In een later stadium kunnen zij de trekhaak alsnog aanbrengen.

C – Could-haves

Als er tijd voor is kunnen deze eisen altijd nog aan bod komen. Zo niet, dan is het geen probleem en heeft het geen nadelig gevolg voor het eindresultaat. De could-haves hebben minder prioriteit dan de should-haves. De optie wordt alleen meegenomen als er echt ruim tijd voor is om het te realiseren. Het wordt ook wel ‘nice to have’ genoemd en het is eerder een wens dan een harde eis.

Voorbeeld: De HBO Automotive studenten hebben wellicht de wens om een toerenteller in de auto te installeren. Geen belangrijke (examen)eis, maar wel leuk als het ze lukt.

W – Won’t-haves (en would-haves)

Het gaat hier om toekomstwensen die vaak niet mogelijk zijn of heel veel tijd kosten om te realiseren. Indien niet mogelijk, dan is het verstandig om geen energie hierin te stoppen.

Is realisatie wel mogelijk dan zal er veel tijd (en geld) geïnvesteerd moeten worden en is er sprake van een would-have. Vaak worden would-haves in een vervolgtraject meegenomen.

Voorbeeld: Voor de HBO Automotive studenten is het niet nodig dat de auto daadwerkelijk op de weg gaat rijden. Het is een studieobject. Mocht het toch een wens zijn om op openbare weg te rijden, dan moet de auto een carrosserie krijgen en aan veiligheidseisen voldoen. Ook zal er via een langdurig proces toestemming bij de Dienst Wegverkeer (RDW) moeten worden aangevraagd.

De MoSCoW Methode en deadlines

Als de MosCoW methode goed wordt toegepast en gehandhaafd, dan ontstaat er een overzichtelijke manier om een project te leiden.

Voor iedere deelnemer aan het project is het duidelijk wat als eerste gedaan moet worden, binnen welke termijn en waarom. Met het toekennen van prioriteiten aan eisen is een project hanteerbaar en wordt er sneller naar de deadline toegewerkt.

Door de minder belangrijke eisen voorlopig achterwege te laten is de ontwikkeling en ondersteuning van een project ook eenvoudiger. Door de focus op de sleutelvoorwaarden te leggen, ontstaat een goed verkoopbaar product dat aan minimale eisen voldoet. Op die manier worden must-haves ook unique selling points, waar de afnemer mee gebaat is.

Nu is het jouw beurt

Wat denk jij? Hoe pas jij de MoSCoW methode toe? Herken je de bovenstaande stappen en aandachtspunten of heb je aanvullingen? Wat zijn volgens jou de succesfactoren die kunnen bijdragen aan goede uitwerking van de MoSCoW methode?

Deel jouw kennis en ervaring via het commentaar veld onderaan dit artikel.

Meer informatie

1. Baxter, R. (2004). Software engineering is software engineering. In 26th International Conference on Software Engineering, W36 Workshop Software Engineering for High Performance System (HPCS) Applications (pp. 4-18).
2. den Hoed, T.W. (2013). Alle plannen voor managers en ondernemers. Van Haren Publishing.
3. Hatton, S. (2008). Choosing the right prioritisation method. In Software Engineering, 2008. ASWEC 2008. 19th Australian Conference on (pp. 517-526). IEEE.
4. Robson, W.A., Simon, Shena. (2014). Moscow in the making. Taylor & Francis Ltd.

Citatie voor dit artikel:
Mulder, P. (2017). MoSCoW Methode. Retrieved [insert date] from Toolshero: https://www.toolshero.nl/project-management/moscow-methode/

Oorspronkelijke publicatiedatum: 06/06/2017 | Laatste update: 31/05/2023

Wilt u linken naar dit artikel, dat kan!
<a href=”https://www.toolshero.nl/project-management/moscow-methode/”> Toolshero: MoSCoW Methode</a>

Article by:

Patty Mulder

Patty Mulder is een management expert op het gebied van competentie ontwikkeling, time management, persoonlijke effectiviteit en zakelijke communicatie. Naast content schrijven, is ze een business coach en verzorgt ze bedrijfstrainingen.