Best practices voor minder risico bij ICT-projecten

In onze vorige blog Zes principes voor minder risico bij ICT-projecten hebben we de zes principes beschreven uit het handboek De-risking custom technology projects van 18F over het beperken van risico’s bij het uitvoeren van maatwerk ICT-projecten.

Naast deze zes principes bevat het handboek veertien best practices voor het begroten van en het toezicht houden op technische projecten, die in deze blog aan de orde komen.

De best practices zijn:

• Risico’s op een nieuwe manier benaderen
  
• Softwareontwikkeling inkopen als dienst
  
• Pas op met ‘gebruiksklare’ commerciële software
  
• Demo’s in plaats van memo’s
  
• Haal technisch talent in huis
  
• Minimaliseer vervangingskosten
  
• De waarde voor eindgebruikers bepaalt het succes
  
• Beperk de totale uitgaven
  
• Beperk de grootte van contracten
  
• Financier ‘loosely coupled’ systemen, geen monolieten
  
• Vergroot de leverancierspool
  
• Deel software
  
• Begroot software als operationele kosten
  
• Stel technische vragen
  

Risico’s op een nieuwe manier benaderen

Overheden zijn gewend om externe leveranciers in te huren voor het bouwen van hun missiekritieke technologie. Dit lijkt minder risicovol dan gebruik te maken van eigen werknemers. Het is echter de overheid die verantwoordelijk wordt gehouden bij het mislukken van ICT-projecten. Het risico op mislukking kán ook niet worden uitbesteed, want uiteindelijk is de overheid verantwoordelijk voor het uitvoeren van haar publieke taak. Daarom moet de overheid zelf de controle en de verantwoordelijkheid hebben over de projecten die in dienst staan van haar taak.

Overheden zouden zichzelf moeten beschouwen als eigenaren van projecten en projectresultaten. Dit betekent niet dat overheden alles intern moeten doen, maar wel dat zij ICT-leveranciers moeten beschouwen als vervangbare middelen om een doel te bereiken. Tenslotte worden worden ICT-leveranciers slechts ingehuurd om te helpen. Bovendien is technische kennis goedkoop en in overvloed beschikbaar, terwijl het leiden van een overheidsinstelling een zeldzame en waardevolle vaardigheid is.

Een overheid die leiding geeft aan een ICT-project moet een goede product owner in huis hebben, zie onze vorige blog Zes principes voor minder risico bij ICT-projecten. Deze persoon moet in staat zijn om het project richting te geven, prioritering aan te brengen en het werk van het ontwikkelteam te overzien. Om de nieuwe agile aanpak te laten slagen is het daarnaast noodzakelijk dat men het er op alle niveaus binnen de overheid over eens is dat de watervalmethode meestal faalt en dat de nieuwe, agile aanpak in feite minder riskant is.

Softwareontwikkeling inkopen als dienst

Overheden zouden het inkopen van maatwerksoftware niet als het inkopen van een product moeten beschouwen, maar als het aanschaffen van een dienst. Deze dienst bestaat uit het uitvoeren van werk door een team van ontwikkelaars en ontwerpers, zoals geprioriteerd door de product owner. Dit onderscheid tussen het inkopen van een product en het inkopen van een dienst leidt tot een hele andere benadering van inkoop, het aanbestedingsproces en contracten.

De aanbestedingsdocumenten zouden het globale doel van het project en een eerste versie van de backlog, een door de product owner opgestelde lijst van het uit te voeren werk, moeten bevatten. Uit deze documenten moet blijken dat erkend wordt dat het werk voortdurend zal veranderen vanwege verschuivende prioriteiten en doorlopend gebruikersonderzoek. De aanbestedingsstukken moeten dan ook de doelen van het project in plaats van specificaties van de software bevatten. Ook moeten de documenten een kwaliteitsplan bevatten, waarin staat voorgeschreven dat na elke sprint wordt gecontroleerd of de software getest, veilig, toegankelijk, gedocumenteerd en geïmplementeerd is. Daarnaast moeten duidelijke vereisten zijn vastgesteld over de regelmatige oplevering van werkende software.

Wat betreft contracten is het beter om een contract op uurbasis met een maximumbedrag af te sluiten dan een contract met een vaste prijs voor het ontwikkelen van een softwareproduct. Dit geeft ook meer mogelijkheden om een leverancier te vervangen wanneer deze kwalitatief slechte software oplevert of anderszins inadequaat blijkt te zijn.

In de aanbestedingsdocumenten zou duidelijk moeten staan dat het alleen gaat om de inkoop van diensten. Voor zover mogelijk in het licht van de gewenste uitkomsten zou de eenvoudigste aanbestedingsprocedure gekozen moeten worden.

Pas op met ‘gebruiksklare’ commerciële software

Commerciële kant-en-klare software en Software as a Service (SaaS) kunnen erg geschikt zijn om nieuwe software snel in gebruik te nemen zonder deze eerst te hoeven bouwen. Dit kan de beste keuze zijn voor een nieuw groot overheidssysteem. Ga er echter niet zomaar vanuit dat deze software zonder (dure) aanpassingen bij een overheid zal werken, ook niet als een leverancier dit beweert. In de praktijk zijn overheden vaak duurder uit dan verwacht en is er een hoog risico op vendor lock-in. Bij kant-en-klare software geldt dit omdat leveranciers vaak hoge tarieven in rekening brengen voor toekomstige upgrades van de aangepaste software, bij SaaS omdat vaak hoge extra kosten worden gerekend om de software op de oude systemen van de overheid aan te sluiten.

Overheden moeten de ruimte hebben om te kiezen voor het kopen of het ontwikkelen van verschillende onderdelen van het systeem, of voor een combinatie daarvan. Ze doen er goed aan om naar ervaringen van andere overheden te informeren voordat ze de keuze maken voor specifieke kant-en-klare software of SaaS. Ook is het raadzaam om vooraf duidelijkheid te verkrijgen over het updaten van aangepaste software, eventuele verdere noodzakelijke aanpassingen als gevolg hiervan en wie dit betaalt. En wat gebeurt er wanneer een SaaS-leverancier failliet gaat? Ook is belangrijk om te waarborgen dat de overheid kosteloos en gemakkelijk toegang tot haar data, datamodellen en API’s behoudt.

Demo’s in plaats van memo’s

De agile methode heeft een eigen manier om de voortgang van een project te meten, namelijk door te kijken naar het functioneren van de opgeleverde software. Rapportages vinden daarom plaats in de vorm van demonstraties van werkende software. Ook kunnen ‘burn down charts’ worden overgelegd, diagrammen met daarin het werk dat nog gedaan moet worden en hoeveel tijd dat zal kosten. Er wordt geen gebruik gemaakt van (voorheen gangbare) Gantt-grafieken en lijsten van afgeronde taken. Demo’s in plaats van memo’s dus.

Om de kwaliteit van de software te waarborgen wordt in het contract een kwaliteitsplan opgenomen met daarin standaarden waaraan de software moet voldoen en methoden om de kwaliteit van de software te toetsen. Een software-ontwikkelaar van de overheid moet worden aangewezen om te waarborgen dat de software aan het eind van elke sprint aan de kwaliteitseisen voldoet.

Deze aanpak kan alleen slagen als er geen vereisten zijn die tegen de agile methodiek indruisen, zoals data waarop specifieke taken voltooid moeten zijn of exacte specificaties van functionaliteiten. Ook is het belangrijk dat de mensen die hiërarchisch boven de product owner zijn geplaatst deze wijze van rapporteren steunen.

Haal technisch talent in huis

Als niemand in het projectteam van een overheid ervaring heeft met softwareontwikkeling, dan kan deze overheid niet goed leiding geven aan een project waarbij software wordt ontwikkeld. Het lijkt misschien verleidelijk om te vertrouwen op de kennis van een leverancier of andere externe partij, maar uiteindelijk moeten overheden deze kennis zelf in huis hebben om te kunnen beoordelen wat ze precies nodig hebben, wat ze van leveranciers kunnen verlangen, of leveranciers redelijke tarieven hanteren en wat de kwaliteit van het geleverde werk is.

Als een overheid niemand met de benodigde kennis in huis heeft, zal iemand die die kennis wel heeft, desnoods tijdelijk, moeten worden ingehuurd. Bij voorkeur een ontwikkelaar of ontwerper die ervaring heeft met het ontwikkelen van software, het liefst voor overheden. Het is ook een optie om een of meerdere werknemers te trainen in de basisprincipes van agile software ontwikkeling.

Op termijn heeft een project minder ontwikkelaars nodig om het werk voort te zetten. Dan wordt het extra belangrijk om meerdere personen in overheidsdienst te hebben die de software volledig begrijpen en kunnen onderhouden. Idealiter worden deze personen bij het ontwikkelproces betrokken. Voor grotere projecten kan het noodzakelijk zijn om een ontwikkelteam voor onbepaalde tijd te contacteren.

Minimaliseer vervangingskosten

Elk nieuw softwaresysteem zal op een dag verouderd zijn en geheel of gedeeltelijk vervangen moeten worden.

Projecten die vooraf zeer gedetailleerd zijn gepland, blijken niet flexibel genoeg om mee te bewegen met de snelle veranderingen op het gebied van technologie, wet- en regelgeving en prioriteiten. Dit leidt vaak tot hoge kosten, overschrijdingen van deadlines en mislukking van projecten. In plaats van over te gaan tot het aanschaffen van gigantische, monolithische systemen, moet de overheid van leveranciers vergen dat zij gebruik maken van open source software en microservices. Op deze manier wordt voorkomen dat de overheid afhankelijk raakt van een specifieke leverancier of een specifiek product.

Om vervanging van systemen en leveranciers te vergemakkelijken moet data worden opgeslagen in open, niet-geoctrooieerde formaten. Waar mogelijk wordt open source software verkozen boven commerciële software. De overheid moet eigenaar zijn van al het werk dat de leverancier verricht. Als gebruik wordt gemaakt van commerciële kant-en-klare componenten moet het contractueel en technologisch eenvoudig zijn om op een kostenefficiënte manier over te stappen naar een concurrent en alle opgeslagen data mee te nemen.

De waarde voor eindgebruikers bepaalt het succes

Het succes van een project wordt bepaald door de waarde die aan eindgebruikers wordt geleverd. Deze waarde zou niet pas na afronding van een project moeten ontstaan, maar zo snel mogelijk na gunning van de opdracht, en vanaf dat moment continu. Sowieso wordt na elke sprint werkende code opgeleverd die door eindgebruikers wordt geëvalueerd, ongeacht of het werk al voor dagelijks gebruik wordt ingezet.

Progressie wordt niet afgemeten aan het aantal geschreven regels code, afgeronde taken of gewerkte uren, maar alleen aan de geleverde waarde voor eindgebruikers. Dit kan doorgaans het best worden beoordeeld door de tweewekelijkse sprintevaluaties bij te wonen en door de scrum master en de product owner te spreken.

Beperk de totale uitgaven

Hoe groter het bedrag dat aan softwareproject wordt besteed, hoe groter de kans dat het project mislukt. En hoe kleiner het bedrag, hoe groter de kans dat het project slaagt. Dit blijkt uit een onderzoek van The Standish Group naar 25.000 softwareprojecten uit 2014. Volgens dit onderzoek hebben projecten van boven de 10 miljoen dollar een zeer kleine kans van slagen.

Als wordt beweerd dat een project 20 miljoen dollar kost, is het zinvol om na te gaan welke waarde voor eindgebruikers kan worden geleverd voor 10 miljoen, of 2 miljoen. Als het antwoord ‘geen’ is, dan is het project gedoemd tot falen. Ook kan het nuttig zijn om te checken of er personen zijn die baat hebben bij toewijzing van een zo hoog mogelijk budget voor een softwareproject.

Beperk de grootte van contracten

Het gebruik van één leverancier voor een lange periode of voor een groot aantal teams mag misschien comfortabel zijn, het leidt onvermijdelijk tot vendor lock-in. Het opdelen van grote projecten in meerdere kleine contacten stimuleert leveranciers om een duurzaam software-ecosysteem te bouwen in plaats van een monolithisch systeem. Bovendien kan zo de kans van slagen van de afzonderlijke projecten aanzienlijk worden verhoogd, zie het hierboven aangehaalde onderzoek van The Standish Group.

Naarmate het aantal personen dat aan een project werkt stijgt, kost het iedereen ook meer tijd om het werk met elkaar te coördineren. De oplossing hiervoor is om teams parallel te laten werken en losse microservices te laten ontwikkelen (‘loosely coupled parts’).

Als een project zo groot is dat meerdere contracten nodig zijn, zorg dan dat het reikwijdte van het eerste contract is vastgesteld en dat er globaal idee is van de inhoud van een aantal andere contracten. Kies als eerste deelproject voor een project met een relatief lage technische complexiteit, een laag politiek risico en een hoge waarde voor eindgebruikers, zodat teams kunnen wennen aan deze werkwijze onder relatief lage risico’s.

Financier ‘loosely coupled’ systemen, geen monolieten

Vervang een oud legacy systeem niet door een nieuw legacy systeem. Kies voor ecosystemen van microservices (‘loosely coupled’ systemen) die stapsgewijs worden gebouwd. Op deze manier hoeft nooit een systeem als geheel worden vervangen, maar kunnen afzonderlijke componenten worden vernieuwd.

In de aanbestedingsdocumenten moet de keuze voor microservices worden vermeld. De formulering van de afzonderlijke contracten wordt toegespitst op de waarde die aan eindgebruikers wordt geleverd. Een doel wordt bijvoorbeeld niet omschreven als ‘het opzetten van een database’ maar als ‘het vereenvoudigen van het intakeproces’. Wanneer er meerdere scrumteams zijn, worden er normaliter geen gezamenlijke besprekingen ingepland. En wanneer één leverancierscontract wordt beëindigd, dan kunnen de andere teams in principe zonder onderbreking verder werken.

Vergroot de leverancierspool

Bestaande leveranciers werken waarschijnlijk niet volgens de methoden zoals hier beschreven. Het kan een uitdaging zijn om nieuwe leveranciers te vinden die moderne methoden voor software-ontwikkeling gebruiken. Waarschijnlijk is het nodig om kleine leveranciers actief te benaderen en ze aan te moedigen om mee te dingen naar overheidsopdrachten. Deze leveranciers moeten wel bekend zijn met het bouwen van systemen die technisch verwant zijn aan het gewenste systeem, maar ze hoeven niet eerder een nagenoeg identiek systeem te hebben gebouwd. Een dergelijke eis is technisch niet noodzakelijk en zou bovendien de leverancierspool tot een paar grote, internationale bedrijven verkleinen. Het kan financieel voordelig zijn om leveranciers in te schakelen die op afstand werken.

Plaats de aanbestedingsdocumenten niet op een aanbestedingswebsite waarvoor registratie is vereist, maar publiceer deze openlijk op internet zodat leveranciers ze kunnen delen. Sta leveranciers toe te werken met hulpmiddelen zoals een desktopgebaseerde dienst voor videogesprekken, een real-time chat tool en een openbaar, op Git gebaseerd versiebeheersysteem.

Deel software

De software van een overheidsorganisatie is waarschijnlijk gedeeltelijk of geheel bruikbaar voor andere overheden. Het openbaar maken van softwarecode is om die reden gunstig, maar heeft ook andere voordelen. Zo kunnen ontwikkelaars hun werk delen en in hun portfolio opnemen. En leveranciers kunnen alvast een indruk krijgen van het project waaraan ze gaan werken of waarmee ze hun systemen gaan koppelen.

Neem in de aanbestedingsdocumenten het vereiste op dat alle softwarecode op een openbaar platform zoals GitHub of GitLab wordt geschreven en onderhouden en dat de code onder een open source licentie wordt gepubliceerd. Leg ook als vereiste vast dat best practices op het gebied van veiligheid worden gevolgd zoals het scheiden van software en data en het automatisch testen daarvan. Neem ook als voorwaarde op dat software dusdanig goed gedocumenteerd wordt dat iedere programmeur die niet aan het project verbonden is het kan gebruiken.

Begroot software als operationele kosten

Het onderhouden van software is functioneel hetzelfde als het bouwen ervan, ook al begroten overheden deze soms ten onrechte als twee wezenlijk verschillende posten.

Software is nooit ‘af’, en dus is het belangrijk om er vanaf het begin rekening mee te houden dat de software voortdurend moet worden aangepast. Voor kleine systemen kan dit het toevoegen van maximaal een FTE aan het ontwikkelteam betekenen, voor grote systemen het inhuren van een ontwikkelteam voor onderhoud en doorontwikkeling. Als vuistregel kost een scrum team van vijf tot negen ontwikkelaars in de Verenigde Staten 1 tot 2 miljoen dollar per jaar. Het is mogelijk om de financiering over meerdere begrotingscycli te verdelen, als een voorspelbare stroom van operationele financiering, in plaats van een bedrag ineens toe te wijzen.

Wanneer er bij de financiering van grote projecten om bedragen van tientallen miljoenen wordt gevraagd, kijk dan eerst welke waarde aan eindgebruikers kan worden geleverd met 2 miljoen, en daarna met de volgende 2 miljoen, etc. Wijs bij risicovolle projecten hooguit een aantal miljoen toe in het eerste jaar, en vermeerder het naarmate het project meer waarde levert.

Stel technische vragen

Bij projectvoorstellen voor maatwerksoftware komt het er vaak op neer dat niet-technici een technisch voorstel voor andere niet-technici maken. Dit leidt niet automatisch tot het stellen van de juiste technische kernvragen, waarvan er hierboven veel zijn beschreven. Het is belangrijk om alle moeilijke technische vragen te stellen en de juiste antwoorden te krijgen.

Wat wil de overheidsorganisatie precies kopen? Waarom? Wie heeft er baat bij? Welke onderdelen van het systeem zullen maatwerk zijn? Welke onderdelen zullen commerciële kant-en-klare software zijn? Wat zal er worden gedaan als de leverancier van een commerciële component stopt of failliet gaat? Wie zijn de eindgebruikers van het systeem? Wat willen zij? Andere voorbeeldvragen en antwoorden om de kansen op succes in te schatten zijn te vinden in bijlage A van het handboek De-risking custom technology projects.