Projectresultaat en business value

Inmiddels worden steeds meer projecten Agile aangevlogen. Dit heeft een flinke impact op de wijze waarop projecten invulling dienen te geven aan wat onder het kopje ‘projectresultaat’ in het projectplan staat. Inmiddels is business value, klantwaarde en waardecreatie de standaard. Heeft het zelfde beestje een nieuw naampje gekregen, of is er fundamenteel wat aan het veranderen? 

Projectresultaat en business value

In de praktijk is projectresultaat vaak niet de invulling van de waarde die een project voor de klant zal moeten opleveren. Zo zal het succesvol implementeren van een nieuw systeem, of het opleveren van een nieuwe waterpomp bij het waterleidingbedrijf als projectresultaat – niet per se verband houden met business value.

Levert elk project ‘business value’ of klantwaarde?

Een klant is gebaat bij goedwerkende producten en diensten. Dit betekent een goede balans tussen ‘vernieuwing’ en ‘uitvoering’. Niet voor niets is er vaak sprake van ‘change’ en ‘run’ in een bedrijf – een deel is verantwoordelijk voor het behoud en de uitvoering van de te leveren producten en diensten en een ander deel buigt zich over vernieuwing. Het antwoord is dus impliciet JA – elk project levert business value – al is het soms indirect, simpelweg preventief. Zo schilder ik mijn huis periodiek, niet omdat er dan MEER verf op de kozijnen zit, maar omdat de kozijnen zo in goede staat blijven. Onderhoud als meerwaarde voor de klant.

Maar, projectresultaat is concreet, klantwaarde een tikkeltje vager?

Nu komen we tot de essentie van het verschil tussen projectresultaat en klantwaarde. Het draait principieel om een denkwijze, die zich in een metafoor eenvoudig uit laat leggen.

Dat zelfde huis met kozijnen:

• Projectresultaat: alle kozijnen binnen een bepaalde termijn, voor een bepaalde prijs, geschilderd, volgens een bepaalde kwaliteit.
• Business value: lage onderhoudskosten en mooie glanzende kozijnen. 

Dat lijkt simpel – hoe pas ik het toe in de praktijk?

Het begint bij de business case en aanleiding van een project. Het vreemde is dat uiteindelijk iedereen begrijpt dat onderhoud belangrijk is – alleen hoe belangrijk, wordt zelden gekwantificeerd. In de denkwijze van organisaties is het belangrijk die functionele vraag van klanten te benoemen en op basis daarvan verandering, vernieuwing of gewoonweg onderhoud uit te voeren. Op die manier komt niemand in de verleiding wellicht zaken te doen die belangrijker zijn voor iemand binnen het bedrijf, dan die zelfde klant. Overigens is de crux wel dat het vaststellen van ‘wanneer is het project nu klaar, volgens de business value’ alsnog gedefinieerd zal moeten worden – al is het projectresultaat vooraf daarmee wellicht minder concreet. En dat is dan weer de essentie van Agile – bekommer je om je klant en de klantwaarde die je gaat leveren en laat de invulling over aan de professionals, wanneer de tijd rijp is. En dus niet vooraf.

Anders, maar toch het zelfde!

Kortom – het is niet helemaal hetzelfde beestje met een ander naampje. Het falen van grote projecten, met de Fyra als schrijnend recent voorbeeld, laat zien dat die klantwaarde snel uit het zicht raakt wanneer een project gestart wordt. De topman van NS bood vanmorgen zijn excuses aan de reiziger aan – hij heeft hen gefaald, doordat ze nu nog steeds niet met een HSL naar Brussel kunnen reizen. Klantwaarde beneden nulpunt, terwijl er toch zo’n 800 miljoen euro is uitgegeven aan treinen, sporen, concessies en een lijvig project.