Om een project succesvol uit te voeren is het van groot belang om in een vroeg stadium effectief de klantwensen te beschrijven en om te zetten naar een waardevolle List of Requirements (LoR).
We hebben gemerkt dat het opstellen van de User Requirements niet altijd zonder problemen verloopt en dat er vraag is naar betere input om in de LoR te verwerken. Als antwoord hierop hebben we een stappenplan ontwikkeld om tot een eenduidige, complete en geaccepteerde List of User Requirements te komen.
In dit blog laten we de stappen zien die wij bij Post en Dekker doorlopen om de benodigde User Requirements te achterhalen en delen we een case met jullie om dit proces te illustreren.
Aan het begin van een project is het belangrijk een goede aansluiting te vinden bij de klant. Waarom wil de klant dit ontwikkelen, hoe wordt het product gebruikt en het meest belangrijk: waar moet het nieuwe product aan voldoen. Dit alles leggen we vast in een List of Requirements.
Om tot een complete List of Requirements (LoR) te komen is het belangrijk door te vragen tot de kern van de klantwens duidelijk is. Onze aanpak helpt door middel van een gestructureerde methode op een effectieve manier de beschikbare informatie te vertalen naar geaccepteerde klantwensen. We maken in onze aanpak gebruik van vijf stappen die ervoor zorgen dat het proces soepel verloopt.
De vijf stappen zijn als volgt:
Stap 1: Het bepalen van bronnen en kennis verzamelen
Het hoofddoel van de eerste stap is het verzamelen van kennis per domein. Er wordt in beeld gebracht wat de domeinen zijn die van toepassing zijn op het project, wie daar de kennisdragers van zijn en wie de stakeholders zijn. Dit is snel te achterhalen door een uurtje met de opdrachtgever te zitten.
Afbeelding 1: Mogelijke domeinen waaruit kennis verzameld wordt.
Uit al het verzamelde materiaal worden straks specificaties gehaald. Belangrijk is dat nu ook duidelijk is wie de contactpersonen zijn voor de kennisinput en welke stakeholders van belang zijn.
Stap 2: Specificaties oogsten
Bij de tweede stap wordt er gericht gezocht naar specificaties vanuit diverse bronnen die zijn vastgesteld in stap 1.
Uit de opgevraagde documenten wordt data verzameld, wat de basis vormt van de LoR. De onduidelijkheden die hieruit ontstaan worden bewaard om terug te laten komen in interviews met de kennisdragers.
Naast onduidelijkheden kun je kennisdragers diepgaand interviewen om zo een compleet beeld te vormen van de klant. Vragen die je kan stellen tijdens het interview zijn:
- Waar zit de pijn van de eindklant?
- Waarom kiest de eindklant voor een specifiek product of dienst?
- Wat zijn de Unique Selling Points en key requirements?
Is er sprake van een veranderende marktbehoefte? Dan raden wij aan om diepgaand onderzoek te doen aan de hand van requirement mining sessies. Dit is een kennissessie om samen tot écht nieuwe inzichten te komen. Het is hierbij van belang om van tevoren te bepalen wat er precies onderzocht moet worden om de sessie zo relevant mogelijk te houden.
Met de opgedane kennis kun je verder met het opstellen van de LoR.
Stap 3: Concretiseren van specificaties
Bij stap drie draait het om wat een gebruiker belangrijk vindt in het product en waarom. De specificaties die al zijn verzameld worden concreet gemaakt door middel van architectual reasoning binnen het CAFCR-model. Hierbij wordt per domein gekeken naar het volgende:
- Customer Objectives (Wat wil de klant hebben);
- Application (Hoe wordt het systeem gebruikt);
- Functional (Wat biedt het systeem);
- Conceptual (Hoe werkt het systeem);
- Realization (Hoe wordt beschikbare technologie gebruikt)
Het zwaartepunt ligt door de “waarom” vragen te tellen op de Customer Objectives en Application view. Hierdoor ligt de focus op de User Requirements”.
Wat is er voor een klant belangrijk en waarom?
Door middel van een gezamenlijk sessie met betrokken stakeholders wordt vervolgens een overzicht geschetst waarbij de verzamelde specificaties worden besproken. Na een kritische blik worden hieruit de key requirements gekozen op basis van relatieve belangrijkheid.
Belangrijk in deze stap is om alle gebruikersspecificaties (User Requirements) S.M.A.R.T te maken:
- Specifiek;
- Meetbaar;
- Acceptabel;
- Realistisch;
Met deze verdiepingsslag wordt de LoR geüpdatet met de S.M.A.R.T requirements, key requirements en een weergave van prioriteiten.
Stap 4: Bepalen van waarden
Vervolgens gaan we het concrete en gekwantificeerde doel (target value) van de opgetekende User Requirements bepalen. Het gaat hier niet alleen om waar de User Requirement aan moet voldoen, maar ook hoe en wanneer in het ontwikkeltraject dit te valideren is.
Als je hier meer over wilt wezen, lees ons blog ‘Wat is het V-model’. Hier gaan we in op het vroegtijdig in kaart brengen wanneer je welke requirement wilt valideren.
Om waarden te bepalen wordt er gekeken naar normen, order data, projectdoelen en overige informatie die verzameld is. Probeer alle waarden zo eenduidig mogelijk weer te geven, zodat iedereen de LoR kan begrijpen.
Belangrijk is om tijdens de sessie waarin de waarden worden bepaald met het team een gefocuste discussie te voeren voor een optimale uitkomst.
Na deze stap heeft elke User requirement in de LoR een waarde waar desbetreffende requirement aan moet voldoen.
Stap 5: Acceptatie
Bij de laatste stap staat alles in het teken van de acceptatie van de uit de vorige stappen gedefinieerde User Requirements.
Allereerst worden daarom de User Requirements getoetst bij de binnen het project betrokken stakeholders.
Met een eindpresentatie worden daarna de belangrijkste User Requirements met onderbouwing en validatie gepresenteerd aan de board.
Na het verwerken van eventuele opmerkingen van zowel de stakeholders als de board is er nu een definitieve LoR met User Requirements ontstaan.
In de volgende projectfase zal het toekomstige concept hieraan moet voldoen. Dit biedt handvaten voor een snelle en effectieve conceptontwikkeling.
Als laatste wordt er met deze input ook een projectplan inclusief gekwantificeerde projectdoelen en vervolgstappen opgeleverd
Case: Specs oogsten met Upp
De beschreven 5 stappen klinken wellicht theoretisch, vandaar dat deze hier geïllustreerd worden aan de hand van een case.
Startup Upp kwam bij Post en Dekker met een heel goed idee. Maar hoe ga je nou van een goed idee een hele serie machines maken?
Om deze stap te kunnen maken hebben wij met hun de 5 stappen van het Specs Oogsten doorlopen om concrete user requirements op te stellen. Met als doel voor Upp om hierna effectief het ontwikkeltraject te kunnen beginnen.
Tijdens stap 1 en 2 hebben we veel gepraat met de klant en hun elke keer de waarom vraag gesteld: “waarom wil je dat de machine ‘dit’ of ‘dat’ kan”. Om zo tot de kern te komen van wat ze willen met de nieuwe machine serie en hoopt te bereiken.
Hieronder zie je het resultaat van een concrete CAFCR-sessie in stap 3: het concretiseren van de specificaties. Door uit verschillende invalshoeken, domeinen, functies en proces stappen van de machines te kijken naar de machines, werd het steeds concretere wat voor specificaties er allemaal waren. Veel zweefden wel rond, maar waren nooit concreet opgeschreven of er was alleen op bepaalde aspecten aan specificaties gedacht. Nu hebben we het hele plaatje weten te belichten.
Dit is gedaan met de directeur-eigenaar van Upp en de lead process engineer. Omdat het hier om een startup bedrijf gaat zijn er nog niet veel stakeholders in het spel. Binnen een grotere organisatie zullen er meer stakeholders hun zegje willen doen en hun kennis kunnen delen tijdens een Specs-oogst-sessie.
Met een CAFCR-model cocnretiseren we de specificaties
Na de CAFCR-sessie kon er overgegaan worden naar stap 4: het bepalen van de waarden waar de user requirements aan moet voldoen. Dit resulteerde in een ingevulde LoR, zoals hieronder, waar straks de machine ontwerpen aan gevalideerd kunnen worden. Dit zal gebeuren nadat door alle betrokken de LoR geaccepteerd is (stap 5).
Ingevulde List of Requirement
De beste resultaten met Post en Dekker
Post en Dekker ondersteunt klanten met een integraal ontwerp van productfamilies en brengt hen een succesvolle inrichting van het businessmodel. Wij doen dit aan de hand van verschillende tools om de beste resultaten te boeken.
We vertellen je graag meer over Post en Dekker in de whitepaper ‘Creating New Business for OEM”
