De MoSCoW-methode uitgelegd

Elk project start met een idee. Er zijn al diverse zaken bekend die moeten gebeuren om het idee te realiseren. Je zou één hele lange lijst met ideeën, features en taken kunnen maken. Maar dan? Misschien kan de Moscow-methode je helpen!

De Moscow-methode is in 1994 gepubliceerd door Dai Clegg in zijn boek “Case Method Fast-Track: A Rad Approach”. Het doel van de methode was snel grip te krijgen op projecten door prioriteiten aan te brengen in een lijst met taken. Een gratis tip van Q2-software: maak de taken zo klein mogelijk. Hoe kleiner de taken, hoe meer grip op het project. Clegg verdeelt de taken onder in deze vier categorieën, die we hierna verder toelichten:

• Must-haves
• Should-haves
• Could-haves
• Won’t-haves

Must-have

De eerste letter van Moscow verwijst naar de M van Must. Alle features, ideeën, taken enzovoorts moeten uitgevoerd worden wil het product überhaupt slagen. Bij deze categorie moet je erg streng zijn met de vraagstelling. Eigenlijk moet je frisse tegenzin oproepen tegen alles wat je bedacht hebt en steeds nieuwe argumenten bedenken om de taak niet te moeten uitvoeren. Moeilijk, maar zeer nuttig om straks te kunnen focussen.

Voorbeeld: we gaan een auto bouwen. Er moeten wielen onder want iedere auto heeft wielen. Jij: kunnen we echt niet zonder wielen want ik heb geen zin om dat te ontwikkelen… Ik: nee want hoe moeten we anders rijden? Jij: is er misschien een work-around mogelijk? Ik: nee want het wiel is al uitgevonden. Jij: oke maar zullen we dan een driewieler bouwen, dat scheelt weer een wiel. Ik: goed punt, maar er moeten voor de veiligheid vier wielen onder want anders heeft de wagen geen balans in bochten. Nu ben je overtuigd. Die vier wielen zijn echt een must-have omdat de auto anders niet kan rijden én onveilig is!

Een klant zal dit lijstje meestal zo lang mogelijk willen maken, want dit is immers zijn product, zijn droom. Alles moet gerealiseerd worden! Als ontwerpers is het juist onze taak focus te creëren op wat echt noodzakelijk is, want daarmee voorkom je de kans dat het project op langer termijn vastloopt.

Samengevat:

• Deze features zijn minimaal nodig voor een werkbaar product;

• Features zijn verplicht, dit is niet anders aan te pakken;

• Zonder deze features:

  • werkt het product niet;
  • is het product onveilig;
  • is het product waardeloos.

Should-have

De S staat voor Should. Deze features zijn eigenlijk noodzakelijk om erbij te hebben. Ze verfijnen het product en maken het tot een volwaardige tool. Maar belangrijk om te realiseren: in theorie en praktijk kunnen we zonder! Het product zal werken, is niet onveilig en is niet waardeloos zonder deze features.

Wij zien het altijd als een uitdaging om alle must-haves van een klant op should-have te zetten. Het uitgangspunt moet daarin zijn dat we in eerste instantie niets op must zetten, terwijl de klant dat wel wil. Let wel op dat ze hiervan erg teleurgesteld worden. Jij bent hun goede idee namelijk nonchalant aan het degraderen. Het geheim is echter dat we juist dat gevoel willen oproepen. Vanuit die teleurstelling zullen ze namelijk alles uit de kast halen om te motiveren waarom die specifieke feature er echt wel in moet. Dat is voor ons ontwerpers zeer waardevolle informatie om in te leven wat de drive achter het plan is!

Samengevat:

• Belangrijk maar niet onmisbaar;
• Het product kan werken zonder deze features;
• Er is eventueel een work-around die redelijk goed is vol te houden.

Could-have

Dan komt de C. Nu gaan we naar een categorie waar meestal leuke dingen tussen staan. Leg vooral de nadruk op leuk. We hebben het niet echt nodig, maar het zou kunnen: Could-features. We kunnen ze vergelijken met de kersen op taart, de spikkels op een ijsje of het extra sausje bij een fastfoodketen; ze zijn leuk voor wanneer er nog wat budget over is. Soms zijn deze punten ook heel eenvoudig door te voeren.

Terug naar ons voorbeeld: de auto. Stel onze doelgroep zijn jonge mensen (m/v) die op zoek zijn naar een wijs autootje. Om hem er stoer uit te laten zien kunnen we er lichtmetalen velgen onder schroeven in plaats van wieldoppen. We hadden ze nog op de plank liggen! Het kost bij elkaar nog niet eens een uurtje werk maar het spreekt wel tien keer meer aan. We voldoen nog meer aan het doel, maar was het nodig om een betere auto te maken? Nee.

We moeten hierbij wel een kanttekening plaatsen. Het is niet heel hard te zeggen wanneer iets een could-have is. Soms maakt leuk juist een onderscheidende of unieke feature. Dat kan het zomaar een must maken. In dat geval spreken we van een Unique Selling Point (USP).

Samengevat:

• Wenselijk, maar deze features zijn niet zo belangrijk als de Should-features;
• Alleen uitvoeren als er tijd en budget over is;
• Het product is hierna beter.
• Geen could-have als het een USP is.

Won’t-have

Won’t-features zijn vaak wilde ideeën uit brainstormsessies. Ze vertegenwoordigen de visie van een genie of soms leiden ze tot verfijning van andere features. Maar meestal streven ze het doel van het project voorbij. Desondanks wil Q2-software deze informatie niet verloren laten gaan en bewaren we ze graag in een apart lijstje. Er zijn namelijk twee voordelen:

1. Het eerste voordeel is dat we ons tijdens het brainstormen niet beperken.
2. Het tweede voordeel is dat mocht het in een later stadium weer eens gaan kriebelen, kunnen we deze hele lijst direct op tafel leggen en opnieuw afwegen met de kennis van dat moment. Wellicht wordt het vergeten idee een USP!

Sommigen noemen de W ook wel ‘Would-have’. Dit is een andere benadering van deze categorie, welke we hierna nog kort benoemen.

Samengevat:

• Niet per se nodig;
• (Ver) buiten budget;
• Nice-to-have maar heeft niet echt impact op de waarde van het product;
• Feature is zijn tijd vooruit.
• Ideeën van een genie moet je niet weggooien.

Alternatieve benadering

Een alternatieve benadering die soms ook gebruikt wordt is met de volgende vier categorieën:

• Must
• Should
• Could
• Would

De laatste categorie heet nu Would; we zouden willen. Ergens komt dit op hetzelfde neer, want we zouden het wel graag willen maar waarschijnlijk realiseren we het niet. Q2-software heeft gemerkt dat men hierdoor vaak wilde ideeën niet eens op tafel gooit, want “het komt toch niet in de lijst, waarom zou ik het dan roepen?”. Afwijzingen zijn voor niemand leuk en daardoor voelen mensen zich belemmerd in het vrije brainstormen als ze weten dat het misschien niet vastgelegd gaat worden. Het brainstormen moet juist een ultiem moment zijn waar alles bedacht moet kunnen worden. Stel je voor dat een idee net de verborgen parel was die we zochten! Het zou onbewust hopeloos in niets verdwijnen.