Middeleeuwse Business Cases

De ICT heeft een zeer slechte reputatie op het gebied van het succesvol uitvoeren van projecten. Veel van die projecten zijn helemaal geen slechte projecten als je kijkt naar de uitvoering er van. Waarom voldoen ze dan toch niet aan de verwachtingen van de opdrachtgever? Vaak blijkt dat vooraf al duidelijk had kunnen zijn dat het project niet zou kunnen slagen als het ICT-deel van de business case serieus begroot was en dat die begroting ook serieus genomen was in de uitwerking van de business case. Dit betekent niet dat ICT het eigenlijk best aardig doet. Aardig is namelijk een groot probleem. ICT wil gewoon te graag. Onmogelijke projecten moet je niet willen, maar wie durft er nee te verkopen?

Er zijn boeken vol geschreven over het maken van een goede business case. Toch heeft het er de schijn van dat bij het maken van een business case met een ICT-component alle goede raad en ervaring ineens het raam uitgaat. De ICT-component wordt veel te duur en/of duurt veel te lang, waardoor de business case ineens een stuk minder valide blijkt te zijn. Hoe komt dat toch?

In een discussie over ICT-prestaties vatte de eind 2011 overleden metriekengoeroe Grant Rule het probleem als volgt samen: teveel projectmanagers en contractmanagers denken nog teveel in 'Middeleeuwse metrieken'. Dergelijke metrieken kijken op een ambachtelijke manier naar de hoeveelheid te verrichten werk en zijn heel geschikt voor activiteiten die door een enkele ambachtsman, eventueel met enkele gezellen, worden verricht of voor eenvoudig daglonerswerk. In een modern jasje komen we deze metrieken tegen in de vorm van mandagen, uren per functiepunt of story points.

Middeleeuws ambachtsdenken
Op zich is het niet fout om deze metrieken te gebruiken, alleen vormen ze een directe bedreiging voor een business case als ze gebruikt worden met een 'Middeleeuws' wereldbeeld. Dat beeld is dat als ik het werk twee keer zo snel gedaan wil hebben, ik twee keer zoveel mensen nodig heb. Dat werkt voor eenvoudig productiewerk, maar niet voor werk waarbij veel onderlinge afhankelijkheden zijn en er vele specialismen op elkaar afgestemd moeten worden, zoals in de bouw of in de ICT. Als er op een dergelijk project tijdsdruk gezet wordt, exploderen de benodigde uren, en daarmee ook de kosten, en neemt de kwaliteit van het opgeleverde product af. Juist de clash tussen 'Middeleeuws' ambachtsdenken en 21e eeuwse ICT-projecten vormt vaak de basis voor een teleurstellend projectresultaat, nog voor het project goed en wel begonnen is.

Hoe moet het dan wel? Zodra er een beeld is van wat er in de ICT-component gerealiseerd moet worden, moet een eerste schatting worden opgesteld van alle ict-projectdelen met een eigen dynamiek. Zo heeft de ontwikkeling van software een andere dynamiek dan de configuratie van een pakket of migratie van bestaande gegevens. Die schatting wordt bij voorkeur gebaseerd op een output gebaseerde omvangsmaat, zoals functiepunten volgens de COSMIC-, NESMA- of IFPUG-methode. Hierbij dient tenminste een minimale, waarschijnlijke en maximale omvang te worden vastgesteld. Hiervoor zijn vanuit de verschillende methoden allerlei schattingstechnieken beschikbaar, zoals FPAi vanuit de NESMA-methode of Early & Quick op basis van IFPUG.

Goede begroting
Voor velen is dat al de eerste cultuurschok, omdat men zo snel mogelijk 'zekerheid' wil hebben over de omvang van het project. Deze zekerheid bestaat niet. Al in 1981 liet Barry Boehm in zijn boek 'Software Engineering Economics' zien dat voor de omvang van een project een 'cone of uncertainty' geldt, waarbij de onzekerheid over de omvang aan het begin van een project altijd groot is en afneemt naarmate een project vordert. Een goede begroting baseert zich dus ten minste op een minimale, waarschijnlijke en een maximale omvang.

Vervolgens dient die omvang vertaald te worden naar een doorlooptijd en kosten. Hiervoor zijn verschillende databases met ervaringscijfers beschikbaar, veelal gekoppeld aan een commerciële tool, zoals bijvoorbeeld SEER van Galorath, TruePlanning van PriceSystems of SLIM van QSM. Bij deze vertaling is het verstandig om per omvang te kiezen voor een aantal scenario's met een verschillende doorlooptijd. Bij het verkorten van de doorlooptijd van een ICT-project neemt de benodigde hoeveelheid uren exponentieel toe. Dit kan lonend zijn als het snel realiseren van de ICT-component veel geld kan opleveren of bijvoorbeeld gekoppeld is aan een marketingcampagne die rond een vast evenement als het WK voetbal is gepland. Vaak zijn de einddata van een project relatief willekeurig gekozen en laat de business case best ruimte voor een wat ruimer geplande ICT-component die aanzienlijk goedkoper gerealiseerd kan worden.

Voor veel organisaties is dit een tweede cultuurschok, of helaas een eye-opener. De deadline wordt binnen veel organisaties nog steeds heilig verklaard en niet gezien als speelruimte. ICT heeft nog te vaak een servicemodel van 'U vraagt, wij draaien' en dat komt een goede business case niet altijd ten goede. Bij het opstellen van de business case moet de inbreng van ICT bestaan uit het duidelijk maken in welke mate er een trade-off mogelijk is tussen snelheid en zaken als kostenbeheersing, volledigheid van functionaliteit en projectrisico's.

Langere doorlooptijd

Als deze elementen in een vroegtijdig stadium al in beeld gebracht worden, dan kan een goede afweging gemaakt worden. Als snel opleveren belangrijk is, maar er nog de nodige risico's zijn, dan kan er voor gekozen worden een project op te knippen. Kleine projecten zijn namelijk beter te managen. Als vooral kwaliteit en kostenbeheersing belangrijk zijn, dan kan gekozen worden voor kleinere teams en een langere doorlooptijd.

Bij het opstellen van een business case zijn er drie elementen belangrijk die in ICT veel door elkaar lopen en ook te vaak in de verkeerde volgorde.

• De eerste is de doelstelling van het ICT-project, eigendom van de sponsor van de business case. Vanuit de business case komen vaak verschillende doelstellingen op het gebied van tijd, geld en functionaliteit.
• De tweede is de begroting, zoals ik die hiervoor beschreven heb. Deze begroting moet duidelijk maken in hoeverre de doelstellingen uit de business case met elkaar in verband gebracht kunnen worden. Hiervoor zijn de verschillende scenario's op basis van ervaringsgegevens belangrijk. Hoeveel extra tijd is er nodig voor de gewenste kwaliteit? Hoeveel geld is eerder opleveren waard? Het maken van dergelijke scenario's is een discipline die zich niet moet laten leiden door de wensen vanuit de business case, maar door de mogelijkheden die verschillen in projectinrichting en -fasering kunnen bieden.
• De derde is de keuze. Op basis van de wensen vanuit de business case en de opties vanuit de begroting moet gekozen worden hoe het project het beste uitgevoerd kan worden. Daar kan best een planning uit komen die optimistischer is dan op basis van ervaringscijfers is begroot. Door op deze manier te werk te gaan is dat dan wel vanaf het eerste moment een nadrukkelijk te managen risico.

Onmogelijke uitdagingen

 

Bij veel projecten die negatief in het nieuws komen is in het voortraject de tweede stap overgeslagen of pas na de derde stap uitgevoerd. Vanuit de business case is een keuze gemaakt en ICT moet maar zien hoe ze het voor elkaar krijgt. En ICT doet daar nog steeds vrolijk aan mee. 'We willen veel te graag' was een deel van de boodschap die Sogeti-CEO Jeroen Versteeg het publiek in zijn keynotelezing voor de IWSM-conferentie voorhield in november 2010. ICT zou vaker 'nee' moeten verkopen bij het aannemen van onmogelijke uitdagingen. En dat blijft een uitdaging zolang er onmogelijke uitdagingen geboden worden en er concurrenten blijven die 'ja' zeggen.

 

Deze post is oorspronkelijk geplaatst op de website van Computable.