Projecten opknippen? Hoe dan?

Met risicomanagement!

Op 22 november 2018 werd door de Commissie BZK van het parlement een vervolgdebat gehouden over het mislukte project/programma BRP. Deze keer ging het specifiek over de aanbesteding van het project en de merkwaardige wijze waarop hiermee werd omgegaan.

Tweede Kamerlid Kees Verhoeven (D66) pleitte tijdens dit debat voor het opknippen van projecten in kleinere delen. Dit zou moeten leiden tot verbeterde beheerbaarheid.

Kees Verhoeven op Twitter

Maar hoe knip je een project op? Door naar risico’s te kijken.

Dat heeft veel voordelen; ook voor het aanbesteden van het project (zie het einde van deze bijdrage).

De terugkerende roep om opknippen.

De roep om projecten te beheersen door ze op te knippen is niet nieuw. Zowel in praktische als in theoretische discussies wordt dit aanbevolen. Helaas wordt maar zelden gesuggereerd hoe dat dan zou moeten gebeuren.

Tijdens het onderzoek van de Tijdelijke Commissie ICT (Commissie Ton Elias) werd opknippen ook aanbevolen door een opgeroepen expert. Deze persoon beval aan dat “megalomane projecten” voortaan niet meer zouden mogen bestaan en zouden moeten worden opgedeeld in kleinere projecten.

Klinkt goed. Maar deze aanpak kan maar al te snel resulteren in een situatie die kan worden vergeleken met een fragmentatiebom. Een grote bom die uit elkaar valt in vele kleinere bommen. In plaats van één grote klap die veel ophef tot gevolg heeft, vinden ook op langere termijn vele kleinere explosies plaats die stuk voor stuk te klein zijn om in het nieuws te komen. Samen richten de kleinere bommen veel meer schade aan dat de ene grote bom ooit had kunnen aanrichten

Op dezelfde manier kan het ophakken van een “megalomaan project” leiden tot vele kleinere projecten die tot in lengte van dagen schade berokkenen maar die geen aandacht krijgen vanwege de relatieve geringe schade per project. Maar geaggregeerd richten ze samen veel meer schade aan dan dat ene “megalomane project”.

Conclusie: Achter het opknippen van een project moet een gedachte en coördinatie zitten. Bijvoorbeeld een project met deelprojecten of een programma met daarin meerdere projecten.

Opknippen in Fases: Waterval.

In het verleden was het in zwang om “ICT-projecten” op te knippen in fases; de zogenaamde Waterval methode. Deze aanpak was afgeleid van bouw/constructieprojecten. Eerst ging een architect aan de slag, vervolgens ging men bouwen en werd er getest. Uiteindelijk werd het geheel opgeleverd aan de opdrachtgever. Volgens de Waterval methode gingen “ICT-projecten” ook zo aan de slag, alsof men een gebouw of een brug ging bouwen.

Maar deze aanpak bleek in de praktijk toch niet te werken voor “ICT-projecten” voor maatwerk. Tussentijdse producten die na een fase werden opgeleverd, bleken veel te abstract om te gebruiken voor het nemen van beslissingen door een opdrachtgever of gebruiker (go/no-go beslissingen). Het waren technische documenten waar geen touw aan cast te knopen was tenzij de lezer een ICT-professional was.

Verder bleek dat veel interpretatieverschillen tussen opdrachtgever en opdrachtnemer pas bij oplevering aan het licht kwamen. Het oplossen daarvan kostte vervolgens erg veel tijd en geld omdat veel werk overgedaan moest worden. Ook leidde wijzigingsverzoeken op dezelfde wijze tot hoge overschrijdingen door de ingebouwde rigiditeit van de Waterval aanpak.

Conclusie: De traditionele Waterval methode heeft alleen kans van slagen als het beoogde resultaat van tevoren goed kan worden gedefinieerd en redelijk stabiel blijft.

De Agile-hype

Als weerwoord op de Waterval aanpak propageert de ICT-sector nu de Agile aanpak; wendbaarheid tijdens projecten. Helaas komt men met deze aanpak van de regen in de drup.

In het kort komt het er bij de Agile aanpak op neer dat gebruiker en ontwikkelaar in korte cycli (Sprints) intensief samenwerkend tot een oplossing komen. De Sprints worden beperkt door beschikbare tijd en geld per Sprint vast te leggen: de Timebox.

Maar is dat wendbaar/agile? Nee, bepaald niet! Het idee van beheersing door volledige focus te leggen op tijd en geld heeft in de dagen van Henry Ford en Frederick Taylor geleid tot standaardisatie waarbij de eisen en wensen van de gebruiker secondair werden geacht.

Ford en kwaliteit

Met regelmaat spreek ik gebruikers van ICT. Wanneer de discussie gaat over Agile, krijg ik zonder uitzondering hetzelfde commentaar. Er wordt nu inderdaad veel vaker iets opgeleverd. Maar het duurt nu ook veel langer voor het eindelijk werkt.

Dit is uiteraard volledig in lijn met mijn voorspellingen. Focus op tijd en geld levert gebrekkige kwaliteit op. De correctie hiervan kost veel meer tijd en geld dan gekost zou hebben om het in één keer goed te doen.

Toen de bank waar ik mijn betaalrekeningen heb ondergebracht een tijd geleden met trost aankondigde voortaan Agile te werken, maakte ik mij zorgen. Dat bleek terecht. Toen de nieuwe website werd opgeleverd, zat ik als gebruiker na inloggen minimaal vijf (!) minuten te kijken naar een scherm met als enige melding “even geduld a.u.b.”. Vervolgens werd een scherm getoond waar je als gebruiker niet al te veel aan had. Hoe beheer ik mijn rekening? Hoe verkrijg ik inzage in mijn overboekingen? Geen idee.

Na een aantal maanden was blijkbaar een nieuwe Sprint opgeleverd. De gebruikersinterface werd enigszins verbeterd en met enig zoeken (uiteraard nog steeds irritant te veel zoeken) was het inderdaad mogelijk om details te bekijken. Weer een aantal maanden later hoefde de gebruiker ook minder geduld te betrachten maar de gebruikersinterface werd weer naar de stand “onbruikbaar” teruggebracht. Nu, na de zoveelste Sprint, is de website eindelijk werkbaar.

Inderdaad: focus op tijd en geld levert lage kwaliteit op. Door het gebruik van Timeboxen zorgt de Agile aanpak ervoor dat er vaker wordt opgeleverd. Maar het duurt veel langer (en is veel duurder) voor het eindelijk werkt.

Werken volgens de Agile aanpak is dus geen oplossing.

Conclusie: De ontwikkelaanpak Agile is geen aanpak voor projectmanagement. Agile is slechts bruikbaar op operationeel niveau voor kleine wijzigingen die goed te overzien zijn en is daardoor het best passend voor onderhoud van bestaande situaties (vandaar ook de integratie met ITIL in het zogenaamde DevOps).

Beheersing door Risicomanagement en Go/NoGo beslissingen

Het opdelen van een project in behapbare stukken is zeker aan te raden wanneer het opdelen gebaseerd is op onzekerheden in de planning. Het idee is dat een projectplan slechts globaal wordt uitgewerkt waarbij onzekerheden, bijvoorbeeld externe afhankelijkheden, tijdens het maken van het plan worden geïdentificeerd. Vervolgens wordt alleen het eerste deel (een managementfase) van het projectplan in detail gepland; vanwege de onzekerheden is het verspilde moeite om de rest van het plan ook in detail te plannen. De details worden vervolgens verwerkt in het globale plan zodat de grote lijn kan worden beoordeeld en kan worden beoordeeld door een stuurgroep om te bepalen of het project (in deze vorm) nog te rechtvaardigen is.

Eisenhower over plannen

Wanneer het detailplan volledig is uitgevoerd, wordt een volgend deel, tot de volgende onzekerheid, van het overkoepelende projectplan gepland en uitgevoerd. Uiteraard wordt na elke fase gekeken naar de beoordeling van de details, het overkoepelende projectplan en de rechtvaardiging van het project (in deze vorm). Hierbij  is het voor de hand liggend en zeker aan te raden om slechts per fase aan te besteden.

MacArthur over plannen

Overigens zullen ook tijdens de uitvoering van een plan onvoorziene zaken optreden die van invloed zullen zijn. Dit zal vaak leiden tot tussentijdse aanpassing van de plannen. Ook hier zal weer sprake moeten zijn van beoordeling door een stuurgroep die bepaalt of het project nog (in deze vorm) kan doorgaan.

Valkuilen

Dit klinkt eenvoudig. Maar er zijn valkuilen.

Beoordeling van de rechtvaardiging (Business Case) van een project kan alleen worden gedaan door de klant van een project. Een leverancier zal een project altijd rechtvaardigen omdat stoppen of beperken gelijk staat aan verlies van omzet. Een klant heeft nu eenmaal altijd een Business Case die conflicteert met die van de leverancier. Daarom leidt het beleggen van de regie bij de leverancier, een merkwaardig verschijnsel dat bij overheidsprojecten regelmatig voorkomt, vrijwel zeker tot kostbaar falen van een project. Het project SPEER van het Ministerie van Defensie is hiervoor een groot en bekend voorbeeld.

Waar het voor velen duidelijk is dat een commerciële leverancier andere doelen en belangen heeft dan de klant, wordt dit vaak onterecht niet onder ogen gezien wanneer een interne leverancier betrokken is. Een interne leverancier heeft ook andere belangen. Dat is een belangrijke reden waarom ICT-projecten geleid door een CIO meestal mislukken. Ook dit was bij het SPEER project een belangrijke factor, maar komt net zo goed in het bedrijfsleven voor.

ICT-projecten komen in de problemen omdat het ICT-projecten zijn

Het was in dit kader een bewonderingswaardige uitzondering dat het door de CIO-Rijk aangestuurde BIT adviseerde om oBRP voortijdig te stoppen vanwege onvoldoende rechtvaardiging. Maar waarschijnlijk was een effectieve stuurgroep of een effectieve adviseur (borging) aan de klantenkant van het project veel eerder tot deze conclusie gekomen. Wanneer een advies om te stoppen van de specialisten/leverancier komt, is het project echt reddeloos verloren.

Een andere belangrijke valkuil is dat het denken in rechtvaardiging en Business Cases, zeker bij de Overheid, nauwelijks ontwikkeld is. Dit wordt meestal belegd bij een financiële functionaris en heeft hooguit de status van een budget. Dat heeft zeer weinig te maken met beoordelen van rechtvaardiging; dit gaat hooguit om financiële haalbaarheid.

Ook hier geldt dat de haalbaarheid moet worden beoordeeld door de klant van het project. En dus niet door een niet betrokken financiële man die niet verantwoordelijk is voor de lange termijneffecten. Een goede Business Case kijkt naar nut en noodzaak en naar de kosten van het project, maar ook naar de kosten van de gewijzigde situatie na het project.

Daarnaast spreekt men van over de variabelen "Product-Tijd-Geld" wanneer men het over beheersing van overheidsprojecten heeft. Uit het voorgaande zal blijken dat dit te beperkt is (kijk hier voor nadere uitwerking). Hierbij moet men zich ook realiseren dat het bij maatwerkprojecten met een ICT-component vrijwel ondoenlijk is om een leverancier aan te spreken op resultaten. Vanwege de onzekerheden en de vele wijzigingen die gepaard gaan met dit soort projecten is inspanningsverplichting het hoogst mogelijke.

Een goede opdrachtgever die effectief omgaat met een Business Case is van het grootste belang voor een project. Daarvoor is de achterliggende cultuur essentieel. Is de organisatie verandergezind? Of is men wars van projecten en gericht op stabiliteit, beheersing met budgetten en risicomijdend? Dat laatste is helaas bij veel bureaucratieën het geval, waardoor effectieve projecten uitzonderingen zijn en verklaart grotendeels de vele falende projecten binnen de overheid van de afgelopen jaren. Den naast de al genoemde projecten ook aan de  problemen bij de Nationale Politie, de Belastingdienst, de UWV, de Sociale Verzekeringsbank (PGB) en helaas vele andere.

Deze aanpak heeft haken en ogen, vooral door de organisatiecultuur van de overheid die gericht is op stabiliteit en op budgettaire beheersing. Beheersing die haaks staat effectieve projectbeheersing.

 

Gedetailleerde beschrijving (PRINCE2)

De hier gehanteerde aanpak is uiteraard niet nieuw. Het idee wordt in meer (theoretisch) detail beschreven op deze pagina.

Uw visie?

Wat denkt u? Heeft u een mening (of vraag), wilt u reageren? Heel graag!

Daarvoor heeft u hieronder de gelegenheid. Alvast bedankt!

Over de auteur

Specialist in effective change.

Accredited MSP™ and PRINCE2® trainer.

comments powered by Disqus