Hoe stel je project prioriteiten?

Prioriteiten stellen is vaak lastig. Thuis, zakelijk, wat eerst, wat is belangrijk? Het speelt ook bij het (laten) maken van software. Het onderwerp komt geregeld in allerlei varianten terug: bij offertetrajecten of tijdens de realisatie van applicaties. Op meerdere niveaus: de afweging welke applicatie(onderdelen) heb ik wanneer nodig, of wat ontwikkel ik vandaag voor de realisatie van deze nieuwe feature.

Een objectieve en onderling overeengekomen werkwijze voor het stellen van prioriteit is een prettig hulpmiddel bij het succesvol afronden van automatiseringsprojecten.

Als deskundige wordt ik ingeschakeld als projecten mislukken zijn of dreigen te mislukken. Bij mijn onderzoeken naar de oorzaak van het (mogelijk) falen van het automatiseringsproject is een onduidelijke prioriteitstelling een belangrijke probleemfactor. Onduidelijkheid over prioriteiten kan voorkomen worden door een objectieve, goed gedefinieerde en gedocumenteerde methode voor het stellen van prioriteiten te gebruiken.

De MoSCoW prioriteitstelling is zo’n methode

Twee voorbeelden

Ik wil alles, toch? In een offerte-aanvraag voor een maatwerkoplossing staat het programma van eisen, of de requirements, meestal alleen globaal per hoofdfunctionaliteit beschreven. Dat is niet vreemd want een gedetailleerde omschrijving voor iets wat nog niet bestaat is lastig. Los van andere onderwerpen is de kern van de vraag toch meestal ‘Wat kost dit?‘.

Maar wat wil je echt? Dan begint de fase van het analyseren van de vraagstelling. Wat wordt bedoeld met de omschrijving, hoe breed is de scope van het betreffende requirement? Om daar antwoord op te kunnen geven en om daarna de omvang te kunnen kwantificeren, ordenen we de requirements. Er ontstaat een (eerste) rangorde in prioriteit.

De uitkomst van deze prioriteitstelling kan gebruikt worden voor afstemming met de klant over de vraag ‘Wat wilt u echt‘, of beter ‘Wat heeft u echt nodig?‘

Dit om het antwoord voor te zijn ‘ik wil alles’

MoSCoW prioriteitstelling?

De kern van het prioriteren gaat om het bepalen van de essentie van het gevraagde. Van absolute noodzaak tot leuk voor een mogelijke volgende keer. Ongetwijfeld is alles nuttig en misschien ook wel nodig, maar er moeten keuzes gemaakt worden, zelfs als het budget en de beschikbare tijd meer dan ruim zijn (wat ze meestal niet zijn). Een praktisch handvat is MoSCoW prioriteitstelling:

M – Must haves: functionaliteit die gerealiseerd moet worden. Ze zijn essentieel, zonder werkt de toepassing niet voor het beoogde doel.

S – Should haves: belangrijk, zeer gewenst, maar zonder is het product (soms met een omweg) bruikbaar.

C – Could haves: overige eisen, komen alleen aan bod als er ruimte in budget en/of tijd is.

W – Would haves (won’t haves this time): onderdelen die nú niet worden meegenomen, maar mogelijk in de toekomst wel.

Deze MoSCoW indeling is zinvol als duidelijk is wat het beoogde doel is van de oplossing. Dat vereist doorvragen, omdat er vaak impliciete keuzes of vooronderstellingen gemaakt zijn. Niet de vraag: “Wil ik het, is het nuttig, betaalbaar of is het handig”, maar hoeveel draagt het bij aan wat ik nú nastreef. De methode helpt om objectief vast te stellen wat daadwerkelijk nodig is en zorgt ervoor dat het subjectieve, gevoelsmatige stellen van prioriteiten naar de achtergrond wordt gedrongen.

Let op: De definitie van de Must have prioriteit is niet onderhandelbaar, het is geen keuze van de opdrachtgever, nee, het volgt uit de doelstelling van het nieuwe systeem. Stel de vraag: “Wat gebeurt er als deze functionaliteit niet wordt gerealiseerd?”. Als het antwoord daarop is: “Dan annuleren we het project, het heeft geen enkele zin het systeem te realiseren als deze functionaliteit er niet in zit.” dan praat je over en Must Have. In alle andere gevallen niet.

Wat koop ik er voor?

De prioritering komt tot stand in afstemming van opdrachtgever en -nemer. De opdrachtgever heeft het doel voor ogen. De opdrachtnemer moet dienen als challenger en moet dus doorvragen. Is het gevraagde essentieel voor de werking van het systeem en het doel dat wordt beoogd, of “vind” de opdrachtgever het essentieel (“Ik vind dat het moet, we willen het”), maar is die requirement in zijn essentie niet nodig voor de werking, zonder kan het ook werken.

Het verschil tussen ‘ik vind’ en ‘het is’

Dagelijks tijdens het IT-project

Een ander moment waarop de MoSCoW indeling te gebruiken is, is tijdens het project voor de realisatie van de software. Dat gebeurt meer en meer op een agile manier: realisatie opgedeeld in korte perioden (sprints) en functionaliteit gedefinieerd van grof naar fijn. De lijst met features voor een oplevering is geprioriteerd. De verdere detaillering naar uiteindelijke dagelijkse werkzaamheden (workitems) ook. Het dwingt opdrachtnemer, en opdrachtgever als onderdeel van het projectteam, steeds weer om na te denken over de bijdrage van de (deel)functionaliteit voor het inzetbare product. Het oneindig schaven aan de lay-out of liever de extra functionaliteit? Of mag dat ook later?

Het klinkt logisch. Toch is het lastig.

Iedereen heeft op z’n tijd last van eigen vooringenomenheid: dit moet echt, dit is nuttig.

MoSCoW in combinatie met een budget/timeframe helpt het goede in de juiste volgorde te doen.