Requirements Optimization

Het rapport “Lessen uit ICT-projecten bij de overheid; Deel B” schetst een vrij mild beeld van de IT-debacles die de afgelopen jaren bij de Nederlandse overheid zijn gepasseerd. Dat kon ook bijna niet anders, want er bleken geen betrouwbare gegevens beschikbaar die scherpere conclusies zouden kunnen onderbouwen. De belangrijkste conclusies gaan noodgedwongen over het verzamelen van “betrouwbare gegevens over tijd, omvang, beschikbare mensen en kosten” op basis van “definities over kostensoorten en begin- en eindpunt van projecten”.

De Kwestie

Deel A was nog zo veelbelovend begonnen. Een scherpe analyse: “ICT-projecten van de overheid [worden] vaak te ambitieus en te complex [...] door de combinatie van politieke, organisatorische en technische factoren. Bij deze te complexe projecten is er geen balans tussen ambitie, beschikbare mensen, middelen en tijd”. Politici, ambtenaren en leveranciers blijken vanuit geheel verschillende belangen allemaal aan te sturen op het vergroten van de omvang en (dus) het verhogen van de complexiteit van projecten. Er is geen of weinig ruimte voor concessies aan het ambitieniveau – alles moet vanaf het eerste begin in alle gevallen volledig correct, volledig betrouwbaar en volledig geautomatiseerd verlopen.

Deze requirements frenzy is heel herkenbaar. Ook in het bedrijfsleven komt het niet zelden voor dat het resultaat van een requirementsstudie een eenvoudige optelsom van alle eisen en wensen van alle stakeholders beschrijft – met enig geluk zijn de meest opzichtige tegenstijdigheden er nog uitgehaald. Opdrachtgevers lijken te redeneren dat als je op voorhand al concessies aan het eisenpakket doet, de leverancier zijn best niet gaat doen om een zo goed mogelijke oplossing te realiseren. De leverancier heeft op zijn beurt geen enkele baat bij het versimpelen van de opdracht. Immers, hoe meer functiepunten en hoe meer technologische vernieuwing, hoe hoger het omzetpotentieel.

Het is niet moeilijk om in te zien dat beide redeneringen kortzichtig zijn. Projectrisico's nemen meer dan evenredig toe als het aantal en de complexiteit van requirements toenemen. Hogere projectrisico's vertalen zich onvermijdelijk in langere doorlooptijden, hogere kosten en grotere afbreukrisico's. Planningen van grote, complexe projecten hebben van nature een hoog speculatief gehalte. Dus, als opdrachtgever en leverancier het succes van een project zouden willen bevorderen, dan zouden ze tegen-intuïtief moeten handelen, door actief de complexiteit van het project maximaal terug te managen.

Helaas is matigheid een deugd die in moderne projectorganisaties nauwelijks wordt gewaardeerd. Kleine, simpele oplossingen met een hoge impactfactor, leveren nauwelijks interessante financiële of reputationele prikkels op. Het is jammer dat de rekenkamer daar niet op heeft gewezen. Het stelselmatig belonen van ongewenst gedrag – zowel van bestuurders, ambtenaren als leveranciers – is tenslotte een belangrijke bron van geldverspilling. Een beloningssysteem dat meer rekening zou houden met “value for money” zou dan ook een voordehand liggend advies zijn geweest.

De rol van de archITect

ArchITecten hebben iets met Requirements. Requirements zijn de belangrijkste grondstof voor architectuurproducten. Dat zie je bijvoorbeeld ook terugkomen in TOGAF, waar Requirements Management het centrale proces in de Architecture Development Method (ADM) is. In de woorden van the OpenGroup: “the ADM is continuously driven by the requirements management process”.

Het cruciale woord in deze definitie is “continuously”. Het is zaak dat gedurende het ontwerpproces de ambities continue op de haalbaarheid worden afgestemd. In de loop van het traject ontstaan nieuwe inzichten, waardoor de onzekerheid afneemt en er scherper gekozen kan worden tussen functionaliteit, kwaliteit, kosten en duur van het project.

Het is een verspilling van energie (dus tijd en geld) om aan het begin van zo'n traject een omvangrijke requirementsstudie te doen en op basis daarvan de specialisten aan het werk te zetten. Het werkt veel beter om in een verkennende fase op basis van een beperkte set aan globale requirements een archITect te vragen een aantal alternatieve oplossingsscenario's te schetsen. Zulke schetsen zijn namelijk prima hulpmiddelen om requirements aan te scherpen en om gerichte haalbaarheidsonderzoeken te doen. Zo'n haalbaarheidsonderzoek kan prima in de vorm van een bescheiden project uitgevoerd worden en is een uitstekend hulpmiddel om onzekerheden te elimineren en risico's te reduceren.

Architecten kunnen in de loop van het proces een waardevolle rol spelen bij het helder formuleren en het valideren van requirements. Requirements krijgen op deze manier de kans om geleidelijk, in balans met het ontwerp van de gewenste oplossing, te evolueren. Ze zijn niet langer een bron van conflict, maar een mechanisme voor wederzijdse afstemming. En daar is iedereen bij gebaat.

Requirements Optimization zou een goede term kunnen zijn om een dergelijke werkwijze te beschrijven. Risico's minimaliseren door requirements te optimaliseren. Zo krijg je een maximaal resultaat tegen minimale kosten. En dat is niet alleen voor ministers interessant!

In deze kwestie wordt een actueel thema op een scherpe manier geanalyseerd. Het is de 8^ste in een reeks die op dit weblog gepubliceerd zal worden.