Zes principes voor minder risico bij ICT-projecten

Op basis van jarenlange ervaring binnen de Amerikaanse overheid heeft 18F een handboek uitgebracht over het beperken van risico’s bij het uitvoeren van maatwerk ICT-projecten, De-risking custom technology projects. Dit document is geschreven voor niet-technische medewerkers en beslissers bij overheden. Onderstaand artikel is een samenvatting van de basisprincipes voor software-ontwikkeling uit het handboek. Deze principes zijn ook voor Nederlandse overheden relevant.

18F constateert een gebrek aan kennis over softwareprojecten bij veel overheden. Vaak is er sprake van overschatting van technische kennis en van onderschatting van de capaciteiten om een overheidsinstelling te leiden. En dit terwijl technische kennis in overvloed beschikbaar is, terwijl het vermogen om een overheidsinstelling te leiden schaars en waardevol is. Volgens 18F is het noodzakelijk dat overheden de regie terugnemen en inzien dat ICT-leveranciers altijd vervangbaar zouden moeten zijn. Het handboek biedt daarvoor handvatten in de vorm van zes basisprincipes voor moderne software-ontwikkeling en veertien best practices voor het begroten van en het toezicht houden op technische projecten.

De basisprincipes zijn:

• Gebruikersgericht ontwerpen
  
• Agile softwareontwikkeling
  
• Product ownership
  
• DevOps
  
• Bouwen met ‘loosely coupled parts’
  
• Modulair contracteren
  

Gebruikersgericht ontwerpen

Bij het ontwikkelen van software moeten de behoeften van de eindgebruikers van de software altijd centraal staan. Dit principe reduceert de projectrisico’s door ervoor te zorgen dat daadwerkelijke in plaats van veronderstelde problemen worden opgelost. Deze problemen kunnen op verschillende manieren geïdentificeerd worden, onder andere door interviews en het testen van gebruiksvriendelijkheid.

Het ontwikkelen gebeurt in nauwe en regelmatige samenwerking met eindgebruikers. Het technische team en de eindgebruikers beoordelen het werk regelmatig, en de software wordt pas als af beschouwd wanneer de eindgebruikers het daarmee eens zijn.

Agile softwareontwikkeling

Gedetailleerde langetermijnplannen (‘watervalmethode’) voor grote softwareprojecten zijn lang de norm geweest bij overheden. Keer op keer is gebleken dat dit tot dure aanpassingen, extra kosten en termijnoverschrijding leidt. De veranderingen op het gebied van technologie, beleid, wetgeving en prioriteiten gaan nu eenmaal snel, en te gedetailleerde grote projecten kunnen zich niet aanpassen aan deze veranderingen. Overheden zouden moeten overschakelen naar agile softwareontwikkeling.

Bij agile softwareontwikkeling leveren multidisciplinaire team van vijf tot negen personen in cycli van (meestal) twee weken werkzame software op. Op basis van de input van eindgebruikers worden taken in de vorm van ‘user stories’ gedefinieerd. De complete verzameling van user stories wordt ‘backlog’ genoemd. In elke cyclus (‘sprint’) wordt aan een selectie van user stories gewerkt, waarna het werk wordt beoordeeld door het team en getest met eindgebruikers. De software die aan het eind van een sprint wordt opgeleverd is volledig getest, gedocumenteerd en gebruiksklaar. Bij de volgende sprint worden nieuwe user stories geselecteerd en wordt het proces opnieuw doorlopen. Zo gaat het door totdat alle doelen zijn bereikt of het geld op is.

De leverancier wordt betaald voor de bestede tijd van haar werknemers, niet voor een softwaresysteem. Alles wat de leverancier oplevert - software, documentatie, onderzoek, ontwerpen etc. - is eigendom van de overheid en wordt aan het eind van de sprint aan de overheid overgedragen.

Product ownership

De product owner is de sleutelfiguur bij elk softwareproject. Dit moet iemand zijn die bij de overheid werkt. De product owner werkt samen met gebruikers, belanghebbenden, technici en de leverancier en zet de koers uit. De product owner hoeft geen uitgebreide technische kennis te bezitten, maar moet wel de gebruikers, de organisatie en het relevante beleid kennen.

Een goede product owner zorgt voor duidelijkheid over de visie en strategie. Hierbij gaat het niet om een gedetailleerd vijfjarenplan, maar om een heldere visie op het beoogde resultaat en een globaal plan om dit resultaat te behalen. Daarmee samenhangend zorgt de product owner voor een heldere prioritering van taken voor een optimaal resultaat. De product owner kan belanghebbenden vertegenwoordigen en snelle beslissingen ten aanzien van de software nemen. Op deze manier is gewaarborgd dat deze volledig begrijpt wat het ontwikkelteam doet. Misschien wel de belangrijkste taak van de product owner is ervoor zorgen dat de juiste balans wordt gevonden tussen de behoeften van de overheid en die van de eindgebruikers.

DevOps

Vroeger waren ontwikkelteams gescheiden van de IT-teams die verantwoordelijk zijn voor de operationele taken met betrekking tot de opgeleverde software. Vaak had een leverancier jarenlang aan de software gebouwd, en waren teams bij de overheid vervolgens nog maanden bezig om de software op hun servers te laten draaien. Om moeilijkheden te voorkomen willen overheden vaak dat de leverancier die de software heeft gebouwd deze ook voor onbepaalde tijd op zijn infrastructuur host. Dit kan leiden tot vendor lock-in en onredelijk hoge prijzen. Veel leveranciers vallen immers bij voorbaat af omdat ze geen hosting bieden, waardoor slechts een klein aantal leveranciers overblijft en de concurrentie beperkt is.

DevOps is een oplossing voor deze problemen. Bij DevOps worden de ontwikkeling van software en de operationele taken samengevoegd. Het ontwikkelteam blijft, zowel in de praktijk als contractueel, verantwoordelijk dat hun code goed werkt en schrijft daarvoor een reeks processen. Bij DevOps wordt veel gebruikt gemaakt van digitale tools en methoden zoals het automatisch testen van de software en het automatisch op servers uitrollen van opgeleverde software.

Bouwen met ‘loosely coupled parts’

Grote softwaresystemen zijn vaak zo complex dat geen enkele ontwikkelaar het gehele systeem nog kan overzien. Ondertussen wordt dat systeem met het verstrijken van de tijd en met elke nieuw aangenomen ontwikkelaar complexer, waardoor weer nieuwe personen met structurerende functies nodig worden. Zo komen er bijvoorbeeld softwarearchitecten en managers in het spel. Deze personen moeten er eerst aan te pas komen voordat er überhaupt iets geprogrammeerd kan worden. Kortom, hoe groter het project en het team worden, hoe meer coördinatie vereist is, hoe meer tijd wordt besteed aan projectmanagement en hoe minder aan softwareontwikkeling.

De nieuwe manier van het bouwen van IT-systemen is het werken met ‘loosely coupled parts’, ook wel microservices genoemd. Deze werkwijze behelst het opdelen van grote softwareprojecten in kleinere, quasi-onafhankelijke projecten oftewel componenten. De componenten communiceren met elkaar via eenvoudige, modulaire standaarden. In plaats van een monoliet ontstaat een ecosysteem, waarbij elk onderdeel eenvoudig kan worden aangepast en verbeterd. Elke component heeft een eigen agile team dat de component onderhoudt en de application programming interface (API) documenteert. Via deze API kunnen de andere componenten met de betreffende component communiceren. Tussen de teams is weinig coördinatie nodig, omdat ze simpelweg de API-documentatie van andere teams kunnen raadplegen om met andere componenten te communiceren. Deze werkwijze leidt tot flexibele, duurzame en gebruiksvriendelijke systemen die op de lange termijn goedkoper zijn dan monolieten.

Modulair contracteren

Contracten met leveranciers moeten dusdanig klein zijn dat een leverancier die niet presteert eenvoudig kan worden vervangen. Dit houdt in dat grote, riskante contracten in kleinere contracten worden opgedeeld. De combinatie van gebruiksgericht ontwerpen, agile, product ownership, DevOps en bouwen met ‘loosely coupled parts’ maakt dit mogelijk. Doordat de oude leverancier elke twee weken werkende, geteste en gedocumenteerde software heeft afgeleverd, kan een nieuwe leverancier het stokje eenvoudig overnemen.

Zie ook onze blog over agile en contracten.

Handboek

Voor het gehele handboek van 18F, inclusief best practices, zie het handboek De-risking custom technology projects.