Wat Infra- en IT-projecten van elkaar kunnen leren vanuit opdrachtgeversperspectief
Het afgelopen half jaar ben ik risicomanager bij het Programma Implementatie Omgevingswet (PIOW). Kort gezegd heeft dit programma de taak om de implementatie van de aankomende omgevingswet binnen de verschillende overheidsorganen te faciliteren.
Onderdeel van deze implementatie is een digitaal stelsel. Alle geografische data moet straks digitaal beschikbaar zijn, zodat je met 1 klik op de kaart weet wat je wel en niet mag op een bepaalde locatie, je vervolgens digitaal een vergunning kan aanvragen en vervolgens snel en goed uitslag krijgt en aan de slag kan. Meer info: https://youtu.be/cNdrDF4ZBJ4
De software-ontwikkeling volgt het principe van Agile/SAFE (link: https://youtu.be/RXzurBazN-I)
Hoe zinnig is risicomanagement bij IT-projecten? Daar wordt een zogenaamde “Definition of Done” (DoD) gehanteerd. Hierin staat waaraan een product moet voldoen qua functionaliteit, security, onder houdbaarheid etc. Zodra een product hieraan voldoet, is het af. En ja, de risico’s dat je onderdelen van de Dood niet haalt worden tijdens SCRUM-sessie besproken en mocht het toch mis lopen, dat is het voordeel van Agile, dat je dankzij de korte periodes makkelijk wat kan schuiven. Een beetje zoals bij de metro. Als de metro maar vaak genoeg rijdt, pak je gewoon de volgende als je er eentje mist.
Is Agile daarmee het IT-antwoord op risicomanagement?
Niet helemaal.
Want zo flexibel als Agile is, zo star zijn de harde deadlines vanuit het wetstraject en de gereserveerde budgetten. De programmaplanning bestaat uit 4 harde knooppunten die zijn vastgelegd in een bestuursakkoord. En het risico dat die knooppunten gemist worden, is natuurlijk best denkbaar, zeker gezien het feit dat er meer dan 15 IT-projecten parallel lopen en deels van elkaar afhankelijk zijn.
Wat kan de GWW-sector van de IT/Agile-wereld leren?
Een belangrijk onderdeel van Agile is het fysiek samenwerken in kleine, doelgerichte teams. Dit helpt enorm om de communicatie goed te houden, onderlinge misverstanden snel te ondervangen en kortom goed samen te werken. Ook voorkomen korte cycli dat optredende risico’s leiden tot grote vertraging.
En tenslotte is Agile een goed middel om beslis-onzekerheden aan te pakken. De methode nodigt uit om snel iets op te leveren dat niet perfect hoeft te zijn. Hierdoor voorkom je beslissingsvertraging en vanuit een tastbaar resultaat is het makkelijker sturen, dan vanuit een aantal fictieve scenario’s.
Ook in de infra-wereld zijn het vaak de vele belangen en het grote aantal stakeholders, dat besluitvorming moeilijk maakt en daarmee voor veel vertraging zorgt. Ook het contractueel uitkauwen van eisen voorafgaand aan een jarenlang uitvoeringstraject is voer voor vertraging en discussie tijdens de bouw. Met name als er sprake is van technische installaties, ziet de wereld er bij oplevering heel anders uit dan vooraf voorspelbaar is.
Ook wordt de (vaar)wegbeheerder niet altijd even goed meegenomen in het ontwerptraject, waardoor oplevering van de weg problematisch is “Leuke weg, maar die gaan wij niet overnemen want de maaistroken zijn te smal of het geheel is te onderhoudsgevoelig voor ons budget.”
Agile helpt om de klantvraag centraal te stellen. Een vertegenwoordiger van de klant schuift aan bij het technisch team en vertelt wat hij over 13 weken wil kunnen doen, een zogenaamde Epic. Na 13 weken levert het team een eerste ruwe maar werkende versie op en kan de klant zien hoe zijn wensen zijn geïnterpreteerd. En doordat het team in 13 weken in principe het hele ontwerp doorloopt, komen knelpunten snel boven.
En los van de procesverbetering, zorgt deze manier van werken ook voor een hechtere band tussen opdrachtgever, klant en technisch team. Daar pluk je het hele traject de vruchten van en zorgt voor een ander niet te onderschatten voordeel: Het is leuk.
