Waarom softwareprojecten uitlopen

Loopt een traject uit, dan gaat de blik vanzelf naar het bouwteam. Daar zit zelden de grootste verliespost. Loop de tijdlijn achteraf terug en markeer per periode wie er aan zet was: een fors deel van de doorlooptijd blijkt tijd waarin niemand aan dit project werkte. Er werd gewacht.

Wachten wordt nergens geregistreerd. Bouwuren staan in een urenstaat, wachtdagen in geen enkel systeem. In de rapportage ziet u dat een fase langer duurde, niet dat die grotendeels bestond uit een vraag waar niemand zich eigenaar van voelde.

Juist dat deel kan een leverancier niet oplossen. Hij kan erop wijzen, maar hij neemt geen besluit dat bij de opdrachtgever hoort en maakt geen testers vrij in een organisatie waar hij niet werkt. Het telt wel mee in dezelfde opleverdatum, en wiens vertraging het was wordt pas achteraf een discussie.

Een beslissing zonder eigenaar

Wie mag een uitzondering goedkeuren, en wat gebeurt er met de openstaande orders uit het oude systeem? De vraag ligt bij drie mensen die alledrie aannemen dat een ander erover gaat.

Testen naast het gewone werk

Wie het beste kan beoordelen of de software klopt, draait het proces dagelijks en test bovenop het eigen werk. Valt de testronde in een drukke periode, dan schuift alles erachter mee.

Content en data die nog moeten komen

Teksten, prijslijsten, een export uit het systeem dat vervangen wordt. Stelselmatig onderschat, omdat het opschonen van gegroeide gegevens vaak meer werk is dan het scherm waar ze in terechtkomen.

Een derde partij die iets moet openzetten

Een koppeling vraagt sleutels, een testomgeving en akkoord van de leverancier aan de andere kant. Die kent uw planning niet en ziet een ticket tussen andere tickets. Rappelleren kan, sturen niet.

Vrijwel niemand besluit halverwege om het project groter te maken, en toch gebeurt het bijna altijd. Elk verzoek is klein en redelijk: een extra veld, een export voor de boekhouding, een rol erbij. Stuk voor stuk te klein voor een formeel besluit, opgeteld genoeg om de oplevering te verschuiven.

Verraderlijk wordt het doordat zulke verzoeken tegen het budget worden gewogen en niet tegen de planning. Past een wijziging binnen wat is afgesproken, of neemt de leverancier hem coulant mee, dan voelt hij kosteloos. Dat is hij niet: hij neemt een plek in de volgorde in en raakt vaak onderdelen die al getest waren.

Zet daarom elke wijziging tegen de datum in plaats van tegen het bedrag. De vraag is niet wat dit kost, maar wat hiervoor opschuift. Dat gesprek verloopt eenvoudiger naarmate vooraf scherper is opgeschreven wat er gebouwd wordt: in een bruikbaar programma van eisen staat ook wat er bewust buiten valt.

De grootste tegenvallers zitten zelden in de nieuwe software, maar in het landschap eromheen. Een koppeling met een bestaand pakket klinkt afgebakend, tot blijkt dat niemand nog precies weet hoe dat pakket werkt.

Het systeem is ooit ingericht door mensen die er niet meer werken, en de documentatie beschrijft de bedoeling en niet de uitzonderingen die er later in zijn gezet. Wat in de velden staat wijkt af van wat het datamodel belooft, omdat een veld ergens onderweg voor iets anders is hergebruikt. Een testomgeving is er niet, dus uitproberen kan alleen in productie.

Het bouwen van een koppeling laat zich redelijk inschatten, het uitzoekwerk ervoor niet. Een leverancier die het systeem nooit van binnen heeft gezien, begroot dat op wat gebruikelijk is. Haal dat risico naar voren: laat eerst één record heen en terug koppelen, voordat de rest van de planning erop wordt gebouwd.

Schattingen wijken niet willekeurig af. Ze wijken vrijwel altijd dezelfde kant op, door twee mechanismen die elkaar versterken.

Aan de kant van de bouwer wordt geschat op het verloop waarin het meezit. Dat is geen onwil: wie een taak voor zich ziet, ziet het gewone pad en niet de omgeving die niet start of het antwoord dat uitblijft. Bij één taak is die afwijking klein, maar een offerte bestaat uit tientallen van die schattingen, allemaal dezelfde kant op afgerond.

Aan de kant van de opdrachtgever wordt uit meerdere aanbiedingen vaak de scherpste gekozen. Dat beloont precies de partij die het meest optimistisch heeft gerekend of de vraag het smalst heeft gelezen; wie realistisch begroot, valt af. Zo selecteert de markt op optimisme. Bij het beoordelen van een offerte is de nuttigste vraag daarom waar de indiener van uitgaat: hoeveel testrondes, welke aanlevering van uw kant, en wie het uitzoekwerk aan de bestaande systemen doet.

1. Knip het op in stukken die zelf al iets opleveren

   Hoe kleiner het eerste stuk, hoe eerder blijkt of het aangenomen tempo klopt. Een planning die pas aan het eind meetbaar wordt, is een verwachting.

2. Wijs één beslisser aan in plaats van een overleg

   Iemand die mag kiezen zonder eerst draagvlak op te halen. Leg vooraf vast wat die persoon zelf afhandelt en wat echt omhoog moet.

3. Plan testcapaciteit in als bezetting

   Zet de testers op naam en stem hun beschikbaarheid af voordat er iets te testen is. Capaciteit waarop u hoopt, is er niet als u haar nodig heeft.

4. Haal het onbekende naar voren

   Koppelingen, datamigraties en aannames waar niemand zeker van is horen aan het begin. Slecht nieuws heeft daar nog waarde, omdat er dan iets te kiezen valt.

5. Lever tussentijds op, ook als het niet af is

   Een versie waar u zelf doorheen kunt klikken zegt meer dan welke rapportage ook, omdat een werkend scherm zich niet mooier laat voorstellen dan het is.

Een traject dat later oplevert omdat er onderweg iets is geleerd dat vooraf niet te weten was, is niet slecht bestuurd. Uitstel is soms de betere uitkomst, vergeleken met op tijd live gaan met iets waar de afdeling omheen werkt.

Het probleem is uitloop die pas zichtbaar wordt op de dag waarop opgeleverd zou worden. Dan valt er niets meer bij te sturen en is er ook geen scope meer die geschrapt kan worden.

De signalen zijn eerder te zien. De eerste tussenoplevering schuift stilletjes op terwijl de einddatum blijft staan, wat neerkomt op inhalen met een tempo dat nog nooit is gehaald. De lijst met openstaande vragen wordt niet korter. Dezelfde onderdelen worden meermaals als bijna klaar gemeld. Demo's tonen losse schermen in plaats van een handeling die van begin tot eind werkt.

Wie dat benoemt zolang er nog tijd is, houdt keuzes over. Dat gesprek verloopt makkelijker als vooraf vastligt wat klaar betekent en wie dat vaststelt, zodat het bij opleveren en accepteren geen onderhandeling wordt.

• Een programma van eisen schrijven
• Een software-offerte beoordelen
• Software opleveren en accepteren
• Wie heeft u nodig aan uw eigen kant