Het is algemeen bekend dat veel softwarerealisatie projecten, die uitbesteed zijn aan een leverancier spaak lopen en minder rendement opleveren dan vooraf gedacht en gehoopt. Het is minder bekend dat de plank al misgeslagen wordt door keuzes bij de start van een project. In deze aflevering is er aandacht voor de impact van prijsafspraken.[/vc_column_text]

[/vc_column]

Wat klant en leverancier aan het begin overeenkomen kan later voor grote problemen zorgen, zoals blijkt uit een voorbeeld waar het gierend uit de hand is gelopen. Maar eerst even terug. In aflevering 1 van deze blogserie haalde ik recente cijfers uit de Chaos-database van Standish Group aan om te laten zien dat de scores bij softwarerealisatie projecten nog steeds niet hoopgevend zijn. De gangbare ontwikkelmethode, het scrummen, zorgt er wel voor dat meer projecten slagen. Het aantal organisaties dat in de problemen raakt bij softwareontwikkeling gaat alleen nog niet substantieel omlaag.

Hoe kunnen we dit verbeteren? Door te leren van de fouten. Het artikel ‘Towards a new IT model contract: changing the pricing method’, dat kort geleden verscheen op de website van de ‘Society for Computers and Law’, gaf een illustratief inkijkje wat er misgaat als een organisatie niet de juiste keuzes maakt bij de start van een project. Het artikel is geschreven door software metrics goeroes Charles Symons en

[/vc_column]

Meten is weten 

Meten is weten, ook bij applicatieontwikkeling. METRI, een fact based IT adviesorganisatie gespecialiseerd in sourcing en benchmarking, is een samenwerking aangegaan met CAST, een vooraanstaande internationale leverancier van hulpmiddelen voor het doormeten van softwarecode. De samenwerking heeft tot doel organisaties te helpen op een kostenefficiënte manier inzicht te krijgen in de objectief vastgestelde omvang en kwaliteit van applicaties. Hiermee zijn de prestaties te meten van leveranciers die het onderhoud en beheer van applicaties uitvoeren ook vanuit de agile ontwikkelmethode. Op CIODay 2016 zal METRI volop aandacht besteden aan het adequaat sourcen van applicatieontwikkeling in het agile tijdperk. Kijk voor meer informatie op https://metrigroup.com/events/

[/vc_row]

Richard Stephens, een bekende Engelse IT-advocaat. Zij laten overtuigend zien dat de manier waarop softwareontwikkeling afgerekend wordt met de leverancier een grote impact heeft op de slagingskans van projecten. Ongewild en onbedoeld, maar wel een mega impact.

Rechtszaak

De auteurs halen een interessante casus aan: de rechtszaak die diamantbedrijf De Beers in 2010 aanspande tegen zijn IT-dienstverlener. De leverancier had bij het contracteren op verzoek van de klant een vaste prijs en deadline opgegeven voor het project van start ging. Projecten met zo’n vaste deadline en een van tevoren bepaald budget worden ook wel ‘fixed price, fixed date’ projecten genoemd. De klant is met zo’n vaste prijs en opleverdatum blij omdat het duidelijkheid schept. Maar schijn bedriegt.

Dat het zo uit de hand zou lopen, was niet voorzien bij de start. De Beers, één van de grootste en bekendste diamantbedrijven in de wereld, had in de markt een opdracht uitgezet voor de ontwikkeling van een nieuw softwaresysteem dat de kernprocessen beter ondersteunde. De IT-dienstverlener had net als andere marktpartijen tijdens de tenderfase de systeemeisen kunnen onderzoeken om een bod uit te brengen. Zoals vaker voorkomt, waren de eisen niet gedetailleerd genoeg opgesteld om een realistische prijs te kunnen berekenen. Dat is geen belemmering voor marktpartijen. Zij schrijven laag in omdat zij verwachten later tijdens de realisatie van het project met nieuwe facturen voor meerwerk te kunnen komen. Zo ook bij dit project, waar De Beers voor een offerte van een leverancier koos die met een lage prijs kwam.

Oorzaak

Volgens de rechter was deze beginfase waarin de eisen aan het systeem onderzocht werden om een prijs op te kunnen geven een belangrijke oorzaak voor de onmin. De schets wat er precies moet komen, was veel te globaal opgesteld. Het was voor De Beers ook niet voldoende duidelijk dat het zelf verantwoordelijk was voor het detailleren van de applicatie. Na de beginfase, waarin de partijen een vaste prijs en een deadline overeenkwamen ontstonden de problemen. De Beers dacht goed bezig te zijn en was niet blij toen de IT-dienstverlener aankondigde dat het meer tijd en een grote zak geld nodig had om het systeem af te kunnen ronden. Het management van de IT-dienstverlener had intern kostenoverschrijdingen op dit project een halt toegeroepen door meer tijd en geld bij de klant te vragen. De IT-dienstverlener stelde dat De Beers als klant tekort was geschoten en te weinig duidelijk had gemaakt door tot in voldoende detail te inventariseren aan welke eisen het nieuwe systeem precies moest voldoen. Deze claim wees de rechter gedeeltelijk toe. Halverwege het project ruilde de IT-dienstverlener de agile ontwikkelmethode in voor de watervalmethode om paal en perk te stellen aan steeds nieuwe systeemeisen en zo het eigen rendement overeind te houden.

De casus van De Beers staat niet op zichzelf. Als je uitzoomt en generaliseert, is dit rijtje een opsomming van fouten, die vaker in fixed price projecten sluipen:

  • De leverancier hanteert onvolwassen begrotingstechnieken waardoor er geen realistische inschatting en planning ligt. Dit geeft het softwareproject een valse start.
  • De klant heeft onvoldoende gezorgd voor helderheid over de systeemeisen. De inventarisatie is niet compleet en niet gedetailleerd genoeg, zodat marktpartijen er een realistisch bod op kunnen doen.
  • De klant leunt achterover en spant zich te weinig in tijdens de requirements analyse fase. Hierdoor blijven de systeemeisen ook later in het project vaag en onduidelijk.
  • Dit resulteert erin dat zowel klant als leverancier met te optimistische verwachtingen van start gaan en met een te klein team. Als later in het project bij klant en leverancier alles uit de kast wordt getrokken om het project recht te trekken, ontstaat een gevaarlijke cocktail die de kans op mislukking sterk vergroot.

Zoals je aan dit voorbeeld hebt kunnen zien is de manier waarop software ontwikkelingsprojecten worden gecontracteerd een belangrijke oorzaak voor het ontsporen en mislukken van projecten. Klanten moeten zichzelf niet rijk rekenen met een bodemprijs. Te weinig zicht op het op te leveren product gecombineerd met een onrealistische inschatting van het budget en het tijdspad plaatst klant en leverancier later in het traject voor dilemma’s. Daarom is een goed begin het halve werk. In de volgende blog van deze serie komt aan de orde hoe je leveranciers afrekent op resultaat in plaats van inspanning.