15 feb Meer grip op kwaliteitsmanagement door los te laten, deel II
Past Agile bij Systeemgerichte Contractbeheersing?
In een eerder artikel (Meer grip op kwaliteitsmanagement door los te laten, 2013) besteedde ik aandacht aan de toegevoegde waarde van Systeemgerichte Contractbeheersing (SCB) bij het uitvoeren van projecten en programma’s. In dit artikel werd gesteld dat door de toepassing van het principe SCB: management door los te laten de kwaliteit van projectresultaten wordt verhoogd, terwijl de opdrachtgever op afstand controle en toezicht houdt op het werk dat een opdrachtnemer uitvoert. Bij SCB wordt veel verantwoordelijkheid bij de opdrachtnemer gelegd, beheerst deze zelf de te leveren kwaliteit en moet (op basis van het gehanteerd kwaliteitssysteem) worden aangetoond dat aan de eisen van de opdrachtgever voldaan wordt.
Aan de andere kant kan worden verondersteld dat de ontwikkeling van Informatievoorziening(IV)-oplossingen juist een hoge mate van samenwerking vereist, bijvoorbeeld door het toepassen van iteratieve werkwijzen zoals Agile/SCRUM. Hierbij werken de opdrachtgever en opdrachtnemer juist intensief samen om stap voor stap de gewenste functionaliteit te realiseren.
Hierbinnen ligt ook de kritiek met betrekking tot SCB dat dit niet goed toepasbaar is op IV-projecten. De achtergrond hiervan is dat een aantal factoren het proces van SCB binnen softwareontwikkeling complex maakt. Binnen IV-projecten is:
- het vrijwel onmogelijk om alle requirements tot in detail vooraf inzichtelijk te krijgen, een substantieel deel (gemiddeld 35%) wijzigt tijdens het project;
- het niet mogelijk om het verloop van het proces vooraf tot op taakniveau te plannen;
- het van belang dat mensen intensief samenwerken en communiceren.
Ervaring leert dat het zeer lastig is om het gehele projectproces te standaardiseren en op te delen in traditionele fasen, activiteiten en mijlpaalproducten. De enige zekerheid die er eigenlijk is, is dat de werkelijkheid niet conform plan zal verlopen. Feitelijk betreft het hier dan ook meer een wens van het verloop van het project.
Bij onvoorspelbare processen is continu bijsturen en reageren op de actuele situatie van groot belang. Bij complexe projecten is het einddoel (de stip op de horizon) wel bekend, maar moet de route daarheen gaandeweg het project uitgestippeld worden. Er moet, kortom, gestuurd worden op basis van actuele gebeurtenissen en activiteiten.
In veel gevallen geldt het vooraf vastgestelde contract als eindpunt waar alle projectprocessen naartoe werken. Het gevolg hiervan is dat dit ten koste gaat van flexibiliteit waardoor het lastiger wordt om een product op te leveren dat geschikt is voor het beoogde gebruik. Gesteld kan dus worden dat IV-projecten (in tegenstelling tot andersoortige projecten) vragen om een aanpak die meer is gebaseerd op samenwerking en bewegingsruimte. Hierbij kan gedacht worden aan meer iteratieve concepten zoals Agile. Door meer samenwerking en bewegingsruimte kan stapsgewijs (iteratief) naar de doelstellingen gewerkt worden.
Iteratief ontwikkelen
Meer samenwerking lijkt haaks te staan op SCB, waarbij het uitgangspunt juist is om meer op afstand te sturen. Toch is dit een combinatie die elkaar niet persé bijt. Ook een iteratieve (Agile) aanpak vraagt toepassing van een kwaliteitssysteem, beheersing van processen, beheersing van risico’s en betrouwbare registraties.
De opdrachtgevende partij heeft expertise en ervaring ten aanzien van de domeinkennis, de architectuur en de beheeromgeving. De opdrachtnemer heeft expertise met betrekking tot het ontwerpen, bouwen, testen en beheren van IV-oplossingen. Het ligt dan ook voor de hand om de verantwoordelijkheid langs deze lijnen te scheiden. Bij de opdrachtgever ligt het risico betreffende de kwaliteit van de opdracht en de daarbij te verstrekken informatie. Bij de opdrachtnemer ligt het risico conform de opdracht een oplossing te leveren die geschikt is voor het beoogd gebruik.
Afstemming hierbinnen vraagt om samenwerking. De uitdaging is dan ook om regievoering op zodanige wijze bij elkaar te brengen, dat recht wordt gedaan aan de basisprincipes van SCB en daarbij de sterke kanten van Agile werkvormen zoveel mogelijk worden benut.
Bij een gecombineerde SCB/Agile aanpak worden voor aanvang van het project het einddoel en een aantal randvoorwaarden (bijv. budget en de doorlooptijd) vastgesteld. De scope (functionaliteit) en de uiteindelijke specifieke oplossing staan echter nog open. Bij aanvang van iedere iteratie worden de wensen en eisen geïnventariseerd voor het beoogde tussenproduct, dat daarna op volgorde van prioriteit wordt ontworpen, gebouwd en getest.
Elke iteratie kent nieuwe en vaak andere risico’s, deze worden bij de start van elke iteratie geïnventariseerd en vormen de basis van de SCB binnen de betreffende iteratie. Gedurende de iteratie blijft RWS verantwoordelijk voor het risicomanagement. Deze manier van werken geeft Rijkswaterstaat de mogelijkheid om de regierol te blijven vervullen, terwijl toch flexibel kan worden omgegaan met de invulling van de wisselende requirements en specificaties en relatief meer samenwerking met ON kan worden gezocht.
Conclusie
De iteratieve manier van werken en de frequente samenwerking tussen OG en ON maken een ‘fit-for-purpose’-product goed mogelijk. Door gebruik te maken van elkaars sterke kanten kan tijdens de iteratie inhoudelijk worden bijgedragen aan het beoogde product. Het achteraf constateren en corrigeren van fouten is vaak tijdrovend, kostbaar en niet efficiënt.
