Alle grote ict-projecten van de overheid worden vanaf 2010 per projectfase beoordeeld op het resultaat van de afgeronde fase en op de gereedheid voor de volgende fase. Het kabinet kiest daarmee voor een aanpak die is gebaseerd op agility.
De overheid gaat vanaf 2010 alle grootschalige ict-projecten per projectfase tegen het licht houden aan de hand van reviews. Dat schrijft minister Ter Horst (Binnenlandse Zaken) in een brief aan de Tweede Kamer. Het kabinet kiest daarmee voor een meer ‘agile' aanpak van zijn projecten.
Het agile-model leert programmeurs en projectmanagers om niet te werken aan grote, langdurende projecten die pas aan het eind iets opleveren. De twee belangrijkste elementen van de methode zijn het reageren op veranderingen en het tussentijds opleveren van werkende delen, die gelijk kunnen worden gebruikt.
Reviews
Het is de bedoeling dat onafhankelijke instanties de ict-projecten bij de overheid per fase beoordelen. Minister Ter Horst schrijft dat dat bijvoorbeeld de Rijksauditdienst of de departementale auditdienst kan zijn, hoewel de ministeries dit zelf bepalen. Die auditdiensten kijken of de projecten voldoen aan de gestelde eisen.
‘Een review wordt uitgevoerd vóór het beslismoment om de volgende projectfase te starten, waarbij wordt gekeken naar het resultaat van de doorlopen fase en naar de gereedheid voor de volgende fase', luidt de brief. De diensten onderzoeken of de verstrekte informatie op een ordelijke, controleerbare en deugdelijke wijze tot stand is gekomen. Over de belangrijkste gebreken in het proces lichten de instanties jaarlijks de betreffende minister in, die dat vervolgens doorstuurt naar de coördinerend minister van Binnenlandse Zaken.
Rapportagemodel
Ter Horst heeft bovendien bepaald dat elk ministerie jaarlijks aan het ministerie van Binnenlandse Zaken rapporteert of de projectplannen en hun reviews zijn opgesteld en uitgevoerd conform de criteria die de minister stelt. Daartoe heeft Ter Horst een rapportagemodel opgesteld. Het proces van informatieverstrekking wordt opgenomen in de Rijksbegrotingsvoorschriften 2010.
Ict bij de overheid
Ict-projecten van (semi-)overheidsinstanties lopen regelmatig verkeerd af. Voorbeelden hiervan zijn de implementatie van het Wia-systeem bij uitkeringsinstantie UWV, de perikelen bij de Belastingdienst en de mislukte eerste poging tot een elektronisch hrm-systeem voor alle ministeries (P-Direkt). Ook het SPEER-project ter verbetering van materieellogistieke en financiële processen bij de krijgsmacht verloopt met grote vertraging en budgetoverschrijding.
Agile
De vier belangrijkste waarden van agile softwareontwikkeling:
– Individuen en interacties: een goede samenwerking leidt tot de beste resultaten
– Werkende software: boven alles moet het werken
– Samenwerking met de klant: klanten en ontwerpers zijn geen tegenstanders, maar partners
– Reageren op veranderingen: als de omstandigheden veranderen, pas de planning aan
Bron: Alistair Cockburn en het Manifesto for Agile Software Development
Externe reviews aan het eind van een projectfase zijn verstandig uiteraard, maar hebben op zich niets te maken met ‘agility’. Als de eerste fase de analysefase is en de volgende de bouwfase dan betreft het een watervalaanpak (hoeft ook niets mis mee te zijn overigens).
Binnen een agile-projectaanpak zou de lengte van fases kort moeten zijn (twee tot vier weken) en een externe review om de twee tot vier weken lijkt me niet echt realistisch.
Dus wel verstandig maar met ‘agility’ heeft het verder weinig van doen.
Het maakt niet zoveel uit wat agility betekent. Feit is wel dat de regie nu bij de overheid ligt, niet bij afzonderlijke partijen. Feitelijk is daarmee niemand verantwoordelijk. Of allen… Crisismateriaal.
Klopt, dit heeft weinig met agility te maken. Wat men hier beschrijft zijn de traditionele ‘quality gates’ waarbij het product (ahum, vaak een document en _geen_ werkende software) pas door mag naar de volgende fase als het voldoet aan de gestelde entry-criteria van de volgende fase. Het probleem verschuift zich dan, want dan moet je dus wel in staat zijn om goede entry-criteria te definieren…
Het zou pas agile zijn als er werd gesteld dat iedere fase ook een concreet, werkend product oplevert waarbij men er van uitgaat dat dat product nog niet volledig ‘ af’ is maar wel zodanig veel functionaliteit biedt dat het als een goede richtlijn kan worden gebruikt. De agile projectmanagementmethode Scrum heeft het zelfs per iteratie over potentieel productierijp systeem. Als je dat doet dan weet je pas echt waar je aan toe bent. Minder (tussentijdse) documenten, meer werkende software. En daar past het agile manifesto goed onder. 😉
Anko heeft gelijk. De beschreven aanpak heeft niet veel met agile te maken.
Ik denk dat het op het moment van aanbesteding al mis gaat. Het huidige proces van aanbesteding is puur gericht op het zo lang mogelijk leveren van niet echt passende dienstverlening (tot de bom barst.)
Zowel de overheid als de leverancier zijn hieraan schuldig. De overheid kan hier wel iets aan doen door het proces van dergelijke aanbestedingen te herzien. Het huidige proces is gericht op het consolideren van de scope, de juiste procesmatige aanpak en het beperken van de huidige risico’s. Er wordt echter weinig rekening gehouden met wijzigingen en risico?s die in de toekomst kunnen optreden. De leverancier moet zo volledig mogelijk voldoen aan de complete vragenlijst. Anders is er geen kans op gunning. Dit dwingt de leverancier in een starre waterval aanpak. Tijdens de aanbesteding is de prijs ook een belangrijke weegfactor. Er wordt scherp (en soms tegen de kostprijs aan) aangeboden. Op het moment van wijzigingen (en we weten allemaal dat die gaan komen) betaal je als overheid de hoofdprijs in change requests. Dit lage tarief moet toch ergens worden terugverdiend. Zelfs al heb je een prijs en proces voor changes afgesproken zal dit altijd duurder uitpakken dan verwacht.
Een aanbestedingsprocedure zou dus meer gericht moeten zijn op de kwaliteiten in oplevering van een werkend (deel)systeem dan op de goede afwikkeling van het change proces. Daarmee zeg ik niet dat de procesmatige aanpak niet belangrijk is. De veranderlijkheid van de omgeving, overheid ?n leverancier moet in de wijze van samenwerking onderkend worden en gebruikt worden voor het snel opleveren van werkende producten.
Hiermee is de (schijnbare) beheersmatigheid van een aanbestedingsprocedure veel minder. Je kunt echter wel sneller van start. Dit scheelt tijd en geld. Extra voorwaarde is dat je als overheid, bij uitblijven van snelle bruikbare resultaten, ook weer van elkaar afscheid kan nemen.