Het doel van de 5 waaroms is om de onderliggende oorzaak van een probleem te achterhalen door de lagen van oppervlakkige problemen weg te pellen die eigenlijk symptomen zijn van het probleem, niet de oorzaak. Dit doe je door herhaaldelijk de vraag "Waarom?" te stellen en de reacties te onderzoeken. Zo kun je de diepere en vaak over het hoofd geziene oorzaken van een probleem ontdekken. 

Het doel is om op het punt te komen waarop verdere vragen geen zinvolle inzichten meer opleveren en je de hoofdoorzaak hebt vastgesteld. Zodra je de hoofdoorzaak hebt vastgesteld, kun je praktische oplossingen implementeren om de oorzaak aan te pakken en te voorkomen dat het probleem zich opnieuw voordoet.

Voorbeeld van de sjabloon 5 waaroms

Dit is een voorbeeld van hoe je de sjabloon 5 waaroms op een probleem kunt toepassen:

Probleemstelling: de softwaretoepassing crasht regelmatig tijdens zware gebruikersbelasting, wat leidt tot een slechte gebruikerservaring.

1. Waarom crasht de software tijdens zware gebruikersbelasting?

• Antwoord: De server wordt overweldigd door gelijktijdige gebruikersverzoeken.

2. Waarom wordt de server overweldigd door gelijktijdige gebruikersverzoeken?

• Antwoord: de capaciteit van de server moet op de juiste manier worden geschaald om hoge verkeersbelastingen aan te kunnen.

3. Waarom is de capaciteit van de server niet geschaald om veel verkeer aan te kunnen?

• Antwoord: het team heeft tijdens de ontwikkeling geen proactieve monitoring- en belastingstests uitgevoerd. 

4. Waarom werden er tijdens de ontwikkeling geen proactieve monitoring- en belastingstests uitgevoerd?

• Antwoord: het ontwikkelingsteam beschikte niet over de nodige tools en expertise het uitvoeren van belastingstests.

5. Waarom beschikte het ontwikkelingsteam niet over de nodige tools en expertise voor het uitvoeren van belastingstests?

• Antwoord: de initiële projectscope omvatte geen belastingstests en het team had geen toegang tot de juiste hulpmiddelen voor het uitvoeren van belastingstests. 

Hoofdoorzaak: de onderbreking van de software tijdens zware gebruikersbelasting wordt veroorzaakt doordat belastingstests ontbraken in de oorspronkelijke projectscope en door een gebrek aan toegang tot de benodigde middelen en expertise voor belastingstests.

Oplossing: om toekomstige onderbrekingen tijdens zware gebruikersbelasting te voorkomen, moet het team belastingstests opnemen als standaard onderdeel van hun softwareontwikkelingsproces en ervoor zorgen dat toegang tot de vereiste hulpmiddelen en expertise voor belastingstests beschikbaar is. Hierdoor kunnen prestatieproblemen vroeg in de ontwikkelingscyclus geïdentificeerd en aangepakt worden, wat zorgt voor een vlottere gebruikerservaring wanneer de software wordt geïmplementeerd.

In dit voorbeeld toonde de analyse van de 5 waaroms dat dit de hoofdoorzaak van de veelvuldige softwareonderbrekingen tijdens zware gebruikersbelasting was: het ontbreken van belastingstests in de oorspronkelijke projectscope en het gebrek aan middelen om tijdens de ontwikkeling belastingstests uit te voeren. 

De oplossing pakt dit probleem rechtstreeks aan, waardoor een domino-effect ontstaat dat de voortvloeiende symptomen van het probleem en, ten slotte, de oorspronkelijke probleemstelling oplost. 

Door belastingstests een standaard onderdeel te maken van het softwareontwikkelingsproces en ervoor te zorgen dat de benodigde middelen en expertise beschikbaar zijn, worden toekomstige onderbrekingen voorkomen. Daardoor kan het team ook de gebruikerservaring verbeteren.