Scrumprojecten en Kritische Prestatie Indicatoren

Bedrijven willen voortdurend op de hoogte zijn van de actuele resultaten ten opzichte van de gestelde doelen. Een bekende en in veel organisaties gebruikte manier om de prestaties te meten is de toepassing van Kritische Prestatie Indicatoren (KPI’s). Maar kunnen KPI’s ook gebruikt worden voor het meten van de prestaties en resultaten van Scrumprojecten?

KPI

Elk bedrijf stelt doelen dat het op korte of langere termijn wil bereiken, bijvoorbeeld ten aanzien van omzet, winst, kwaliteitsniveau of return on investment. Uiteraard is het daarbij belangrijk om regelmatig vast te stellen of men op koers ligt voor het behalen van de te bereiken doelen. KPI’s zijn daarbij een belangrijk hulpmiddel. Zo kan bijvoorbeeld de waardering van klanten in de vorm van een rapportcijfer als KPI worden gehanteerd voor de mate van klanttevredenheid. Door met regelmaat dit rapportcijfer vast te stellen (bijvoorbeeld ieder kwartaal), kan een bedrijf ook de veranderingen in de waardering vaststellen. Maar ook de performance van projecten kan een belangrijk aandachtspunt zijn, waarbij KPI’s worden gehanteerd. Projecten lenen zich voor de toepassing van KPI’s doordat ze een aantal (vooraf) vastgestelde variabelen bevatten, die als norm dienen voor een daaraan gekoppelde KPI. De belangrijkste daarvan zijn tijd, geld en kwaliteit. Een KPI voor het meten van tijd kan bijvoorbeeld worden gekoppeld aan de totale doorlooptijd van het project en aan de duur van de fasen waarin het project is opgedeeld.

Een belangrijk kenmerk van KPI’s is dat deze concreet en meetbaar moeten zijn. Een goede KPI voldoet dan ook aan de SMART-criteria:

• Specifiek
• Meetbaar
• Acceptabel
• Realistisch
• Tijdgebonden

Ze helpen zowel het management als de medewerkers bij het monitoren van de (management)doelstellingen en kunnen op verschillende niveaus toegepast worden:

• Strategisch
• Tactisch
• Operationeel

Scrum

Steeds vaker wordt Scrum als software-ontwikkelmethode in projecten toegepast. Het ligt voor de hand dat bedrijven ook van Scrumprojecten willen weten of ze volgens plan verlopen en of de gestelde doelen bereikt worden. Scrum kenmerkt zich echter door de wendbaarheid en de korte sprints van één tot vier weken waarin een team steeds werkende software oplevert. Hoe het eindresultaat na afloop van een project (bestaande uit meerdere sprints) eruit zal gaan zien is vooraf doorgaans nog niet duidelijk, maar wat wel bekend is, is welk probleem dan opgelost of welke wens dan vervuld is. Tijd, geld en kwaliteit zijn daarmee veel minder “hard” dan het geval is voor bijvoorbeeld watervalprojecten. Daardoor is het resultaat van Scrumprojecten veel minder SMART te definiëren dan dat men gewend is te doen met KPI’s.

Wat de toepassing van KPI’s voor Scrumprojecten verder lastig maakt is dat bij Scrum niet wordt gewerkt met planningen in uren, maar dat wordt uitgegaan van schattingen per sprint op basis van punten. Elk Scrumproject ontwikkelt daarbij zijn eigen invulling van de waarde van een punt, waardoor de onderlinge vergelijking van meerdere Scrumteams in een organisatie op basis van het aantal per sprint gerealiseerde punten, eigenlijk het vergelijken van appels met peren is.

De belangrijkste manier om de performance van Scrum-projecten te beoordelen is daarom niet het meten van vooraf gedefinieerde normen voor tijd, geld en kwaliteit, maar het vertrouwen dat een opdrachtgever of product owner gaandeweg het project heeft in het bereiken van het beoogde resultaat in de vorm van het opgeloste probleem of de vervulde wens.

Een onmogelijk huwelijk?

Zijn Scrumprojecten en KPI’s daarmee een onmogelijk huwelijk? Of is het toch mogelijk om het resultaat van Scrumprojecten te meten met behulp van KPI’s? De volgende mogelijkheden om KPI’s voor Scrumprojecten toe te passen lijken op het eerste gezicht mogelijk:

• Het resultaat van Scrumprojecten in de eigen organisatie vergelijken met Scrumprojecten in de markt
• Het resultaat van Scrumprojecten in de eigen organisatie vergelijken met niet-Scrumprojecten in de eigen organisatie

De eerste mogelijkheid is een lastige (zo niet onmogelijke) opgave; gegevens uit de markt zijn niet eenvoudig te verzamelen en als ze al beschikbaar zijn, spelen omgevingsfactoren een zodanig grote rol in het resultaat dat een betrouwbare vergelijking niet mogelijk is.

De tweede mogelijkheid is beter haalbaar, maar dient ook te worden voorzien van een aantal kanttekeningen. Ook hiervoor geldt namelijk dat input intern vaak niet voor het oprapen ligt. En als de benodigde informatie niet eenvoudig verzameld kan worden of als de betrouwbaarheid daarvan ter discussie staat, dan is het doorgaans beter om geen KPI’s toe te passen en bijvoorbeeld liever gebruik te maken van audits als middel om de effectiviteit te toetsen.

SMART-uitwerking

Met deze kanttekeningen in het achterhoofd zijn voor de genoemde tweede mogelijkheid de volgende KPI’s denkbaar.

KPI Doorlooptijd projecten (time-to-market) op basis van methode systeem ontwikkelen

• S – doorlooptijd van projecten die Scrum hanteren versus doorlooptijd van projecten die een andere methode van systeem ontwikkelen toepassen
• M – doorlooptijd gemeten vanaf start tot en met afsluiting van het project
• A – deze KPI geeft het management inzicht in de snelheid van leveren van Scrum ten opzichte van andere methoden van systeem ontwikkelen en biedt het management daarmee de mogelijkheid te sturen op de keuze voor Scrum of juist voor toepassing van andere methodes
• R – elk project rapporteert de doorlooptijd van het project en is in staat om in het eindrapport de doorlooptijd vanaf start tot en met afsluiting van het project te rapporteren
• T – elk project levert bij de afsluiting van het project een eindrapport op.

Welke informatie levert de toepassing van deze KPI op?

Stel dat uit deze KPI blijkt dat Scrumprojecten een langere doorlooptijd kennen dan watervalprojecten. Kan dan worden vastgesteld of dat goed of slecht is? Nee, dat kan niet. Wellicht leveren de Scrumprojecten wel drie keer zoveel waarde op voor de organisatie… Er is daarom een tweede KPI nodig die de netto waardetoevoeging meet.

KPI waardetoevoeging projecten op basis van methode systeem ontwikkelen

• S – netto waardetoevoeging van projecten die Scrum hanteren versus netto waardetoevoeging van projecten die een andere methode van systeem ontwikkelen toepassen
• M – netto waardetoevoeging als resultaat van opbrengsten (benefits) minus kosten van project en daarmee gepaard gaande investeringen
• A – deze KPI geeft het management inzicht in de waardetoevoeging door toepassing van Scrum ten opzichte van andere methoden van systeem ontwikkelen en biedt het management daarmee de mogelijkheid te sturen op de keuze voor Scrum of juist voor toepassing van andere methodes
• R – na afloop van een project rapporteert de opdrachtgever van het project de opbrengsten en de kosten van het project in het eindrapport, waardoor het resultaat van opbrengsten minus kosten van het project kan worden berekend
• T – elk project levert tijdens de afsluiting een eindrapport op, elke opdrachtgever meet gedurende een vooraf vastgestelde periode de opbrengsten

Probleem met deze KPI is dat opbrengsten van projecten vaak niet of in onvoldoende mate gemeten en gerapporteerd worden of dat ze lastig in financiële waarde zijn uit te drukken (bijvoorbeeld aantal nieuwe klanten, klantwaardering, betrouwbaarheid systemen, etc.). Bovendien ontstaan de opbrengsten vaak pas na verloop van tijd en/of gedurende een langere periode (1-2 jaar), waardoor het werkelijke resultaat van het project pas na verloop van tijd kan worden vastgesteld.

Conclusie

Scrumprojecten en KPI’s zijn dus op z’n minst een huwelijk met hindernissen. Het is de vraag of organisaties in staat zullen zijn een echt goede combinatie van deze twee te maken en over voldoende lange adem beschikken om metingen over een langere periode uit te voeren.

Lees verder

• Een succesvolle transitie naar agile werken
• Software ontwikkelen: Agile, Scrum en Lean
• De rol van Product Owner bij Scrum