Prijs per blunder

Bij de aanbesteding van projecten komt al snel het onderhoudscontract op tafel. We gaan er vanuit dat het project succesvol opgeleverd wordt en we het nieuwe systeem op de geplande datum ingebruik gaan nemen. Er zijn een aantal opties om het beheer van systemen onder te brengen in een SLA, een service level agreement. Eén van de nieuwere contractvormen is gebaseerd op een prijs per defect, dat wil zeggen dat de leverancier storingen in uw systeem verhelpt met een vaste prijs per gevonden fout.

Het traditionele uurtje factuurtje model raakt langzamerhand uit de gratie omdat u als opdrachtgever vaak niet vooraf weet wat uw onderhoudskosten zullen worden. Sommige kleine storingen in de systemen zijn arbeidsintensief om te verhelpen en het aantal onderhoudsuren overtreft dan wel eens uw verwachtingen in negatieve zin. Om meer grip te krijgen op de onderhoudskosten lijkt het een voor de hand liggende optie te zijn om een vaste prijs per defect af te spreken, ongeacht of het nu 1 uur of 3 weken kost om deze te verhelpen. Met deze contractvorm kunt u zeker uw voordeel doen als u weet wat u kunt verwachten aan defects, en dat kunt u!

Als u niet weet wat u kunt verwachten komt u in een riskante situatie terecht. Zeker wanneer het systeem onderhouden gaat worden door dezelfde leverancier die het systeem voor u gebouwd heeft. Het komt voor in sommige gevallen dat grote IT Leveranciers een project ‘kopen’ door in een aanbestedingsfase sterk onder de marktprijs te gaan zitten. Tijdens het project, in de uitvoering, wordt er op diverse onderdelen bezuinigd en het aantal defecten loopt exponentieel op -zeker wanneer er realistisch gezien te vroeg opgeleverd moet worden.

De kans bestaat dat andere aanbieders de kwaliteit van de software code dusdanig slecht vinden dat zij het niet aandurven het in beheer te nemen en dus krijgt de ‘bouwer’ ook het onderhoudscontract. Met een prijs per defect wordt dan ruimschoots de investering die ze initieel gedaan hebben door te goedkoop aan te bieden terug verdient omdat ze gegarandeerd een groot aantal defects zullen vinden. U betaald uw leverancier dus extra voor de fouten die ze gemaakt hebben.

U kunt zich tegen dit soort instinkers wapenen als u in de aanbesteding van uw project rekening houdt met project metrieken. Door ISO gecertificeerde omvangbepalingen zoals de FPA Functiepunt analyse van de NESMA of COSMIC analyse kunt u vooraf een inzicht krijgen in de omvang van uw project. U kunt uw leveranciers vragen naar hun benchmark gegevens, hun productiviteits index (PI) voor een bepaalde ontwikkeltaal zoals JAVA of .NET om te bepalen hoeveel uur zij gemiddeld over de realisatie van een functiepunt doen. Met deze benchmark gegevens kunt u met metrieken als die van QSM een indicatie krijgen van het te verwachten aantal defects en er juist bij uw leverancier op aansturen dat er met een bonus malus gewerkt wordt wanneer deze uw project met meer dan gemiddeld aantal defects oplevert.

Door gebruik te maken van de analyses van de Project Dojo in de aanbestedingsfase zult u zeker beslagen ten ijs komen en winst boeken op uw beheerscontracten.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *