Veel organisaties ontwikkelen software niet in eigen huis, maar besteden deze activiteit uit aan gespecialiseerde dienstverleners. Het is algemeen bekend dat veel softwarerealisatie projecten 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 de contractering, het gekozen prijsmodel en afspraken met deze leveranciers valt prima te anticiperen op succes als de juiste accenten maar gelegd worden. Daarom vindt u in deze blogserie over supplier performance management vier aanbevelingen om het outsourcen van applicatieontwikkeling tot een succes maken.

Status quo

In deze aflevering gaan we in op de status quo en laten we zien waarom agile software-ontwikkeling zaken wel sterk verbeterd heeft, maar dat organisaties nog steeds tegen veel voorkomende valkuilen aanlopen. Een bekende lakmoesproef voor het succes van softwarerealisatieprojecten is het ‘Chaos report’ van de Standish group, een expert in projectmanagent die jaarlijks een rapport uitbrengt gebaseerd op hun Chaos-database waarin informatie over budgettering, deadlines en resultaat van duizenden projecten verzameld is. Zoals in de tabel te zien is, werd in 2015 hooguit 29% van alle onderzochte softwareprojecten succesvol afgerond. Dat is geen spat meer dan in 2011, toen dit percentage even hoog uitkwam. Nog steeds loopt meer dan de helft (52%) van de projecten averij op en mislukt maar liefst 19% in zijn geheel.

Figuur 1. Slagingspercentage softwareproejcten

Bron: Standish Group

De uitkomsten zijn opvallend, omdat er door de sterke opkomst van agile werken een veel voorkomend struikelblok uit de weg geruimd is. Door scrum toe te passen en software op te hakken in sprints en daarop feedback te vragen, is er een veel betere interactie tussen de business, IT en het ontwikkelteam. Bij de waterval-methode was de business veel minder aangehaakt, waardoor het projectresultaat nogal eens niet aan de verwachtingen voldeed. Door die nauwe samenwerking tussen business, IT en de leverancier is de kans op ontsporing minder geworden. Uit de Chaos-database blijkt inderdaad dat scrum een positief effect heeft gehad. Het aantal succesvol verlopen projecten is omhooggegaan van 26 procent naar 43 procent als er ingezoomd op de ontwikkelmethode. Voordat we hieruit conclusies trekken is er wel een groot voorbehoud. Bij agile software-ontwikkeling is er formeel geen sprake van projecten, maar van sprints. Dat komt omdat in de agile/scrum wereld het product centraal staat dat vanuit een centrale product backlog in verschillende iteraties ontwikkeld wordt. Omdat iedere sprint erop gericht is om een nieuwe versie van een werkend product op te leveren, stelt Standish Group kun je een sprint of een verzameling van sprints nog steeds als een afgerond project beschouwen.

Figuur 2. Slagingskans gerelateerd aan ontwikkelmethode.

Bron: Standish Group

Punt is wel dat het te bereiken doel een bewegend punt is. Product backlog en sprints zijn communicerende vaten. Het ontwikkelteam bepaalt min of meer zelfstandig wat er toegevoegd wordt aan een sprint en hoeveel er dus wordt gerealiseerd binnen die sprint. In agile/scrum valt dat alleen vaak niet op, omdat de teams de toezegging hebben gedaan om het product op te leveren. Er wordt altijd wel een stapje harder gelopen om de sprint toch te halen. En als er dan nog tekortkomingen in de software zitten, die er volgens de ‘definition of done’ niet meer in zouden mogen zitten, dan kunnen deze tekortkomingen verplaatst worden naar de product backlog om in een volgende sprint mee te gaan.

In gevaar

Valt de productiviteit lager uit gedurende een aantal sprints, dan komt de deadline in gevaar. Ook bij agile softwareontwikkeling is er vaak wel degelijk een moment waarop een bepaalde hoeveelheid functionaliteit geacht wordt in productie te zijn gebracht. Als deze functionaliteit nog niet in de applicatie verwerkt is, ontkomt men er niet aan om extra sprints uit te gaan voeren. Je ziet dit effect in zekere zin ook terug in de Chaos-database van Standish Group. Ook bij de agile ontwikkelmethode belandt nog steeds 45% van de agile projecten in de problemenzone en krijgt 12% van de projecten het stempel mislukt.

Een belangrijk aandachtspunt is dat er vanuit de opdrachtgever en de product sponsor te weinig mogelijkheden zijn of de tijd- en budgetinschattingen adequaat zijn. Die inschattingen zijn bij veel projecten niet realistisch door het toepassen van onvolwassen begrotingstechnieken. Onderzoek van psycholoog Kahnemann heeft aangetoond dat de inschattingen van mensen van nature te optimistisch (‘biased’) zijn. Dat geldt ook voor schattingen van experts. Ook al beschikken zij over een schat aan kennis en ervaring en zelfs al zijn ze zich bewust van deze vertekening. Om deze reden wordt het merendeel van de softwarerealisatieprojecten te optimistisch ingeschat, ook al gaat het om zogenaamde ‘expert opinions’.

In de soep lopen

In de IT-industrie is het niet ongebruikelijk om de omvang in te schatten door bij projectleiders, ontwikkelaars en testers ureninschattingen op te vragen en deze bij elkaar op te tellen. Kom daar maar eens om in de civiele techniek bijvoorbeeld. Daar wordt gewerkt met professionele en gecertificeerde cost engineers omdat de maatschappelijke impact van uitloop en budgetoverschrijding te groot is. In de IT-industrie zijn globaal uitgewerkte bestekken van een applicatie vrij gebruikelijk. Leveranciers schrijven laag in. Dat levert onrealistische verwachtingen op bij de start van veel projecten. Het is een belangrijke reden waarom projecten in een later stadium in de gevarenzone komen. In de volgende aflevering van deze blogserie komt een project voorbij dat gigantisch in de soep liep juist door dit soort fouten bij de start.