Niet geschat is altijd mis

THEMA: INFORMATIEMANAGEMENT drs.ing. P.H.M. Bink is manager estimation & control bij Capgemini (peter.bink@capgemini.com) Voorkom budgetoverschrijding bij ICT-projecten Niet geschat is altijd mis 18 Veel ICT-projecten overschrijden tijd of budget, zo blijkt uit onderzoek. Soms worden projecten zelfs voortijdig gestopt. Dit kan grote gevolgen hebben: de kosten rijzen de pan uit, de deadline wordt niet gehaald, de kwaliteit blijft achter met als gevolg veel productieverstoringen, imagoschade voor het bedrijf, de concurrent die eerder op de markt is met eenzelfde product, mogelijke schadeclaims. Het kan zelfs faillissement tot gevolg hebben. Hoe kunt u met behulp van relatief eenvoudige schattingswijsheden een risico-inschatting maken? PETER BINK

ACHTERGROND OVERZICHT Waarom kost een project meer dan gepland? Redenen zijn onder meer: geen duidelijk beeld van de daadwerkelijke omvang, een hogere verwachte productiviteit, een te krappe deadline, veel wijzigingsverzoeken door de klant, een hogere technische complexiteit dan verwacht of een slechte overeenstemming van de scope. Hoe voorkomt u budgetoverschrijding? Wat is er nodig om te kunnen schatten? Voordat een organisatie kan beginnen met schatten, is het noodzakelijk dat men meetgegevens heeft. Men zal dus moeten meten. En voordat een organisatie kan gaan meten is het noodzakelijk dat er een aantal processen op orde zijn. Dit betekent niet dat de organisatie Capability Maturity Model (CMMi) level 5 gecertificeerd hoeft te zijn, maar wel dat de organisatie volgens een standaard aanpak werkt. Zo zal een projectmanager een planning moeten maken en de voortgang moeten bewaken met telkens min of meer dezelfde diepgang. De bevindingen moeten gedurende het project worden vastgelegd en de voortgang van het project in bijvoorbeeld regels code of functiepunten gemeten. Schatting Meting Proces In de praktijk is het verzamelen van meetgegevens lastig, omdat men afhankelijk is van andere partijen. Daarom is het belangrijk zeker in eerste instantie niet te veel informatie te willen verzamelen. Goede schatting Een autonavigatiesysteem heeft altijd irritant gelijk. Bij het wegrijden berekent het navigatiesysteem het tijdstip van aankomst. Zelfs als het vakantietijd is, rustig of juist druk op de weg of je hebt een snelle auto, zelfs dan zit het systeem er altijd maar een paar minuutjes naast. Hoe doet zo n navigatiesysteem dat toch? Twee zaken die van belang zijn: 1. het navigatiesysteem maakt, voordat de reis begint, een schatting gebaseerd op afstand en voorspelde gemiddelde snelheid; 2. het navigatiesysteem stelt de schatting bij als de feitelijke gemiddelde snelheid lager uitvalt. Hoe gaat dat bij ICT-projecten? Allereerst punt 1: Hoe kan men een goede schatting uitvoeren? De schatter moet goed weten wat de omvang van het te bouwen systeem is. Voorbeelden van omvanggrootheden zijn functiepunten (NESMA, IFPUG, Cosmic), use case punten of smart use case punten. Eigenlijk maakt het niet zo heel veel uit welke methode wordt gebruikt om de omvang te bepalen, als de methode maar eenduidig, consistent en herhaalbaar is. Daarnaast is het aan te bevelen dat men als bedrijf altijd dezelfde methode gebruikt in verband met het verzamelen van ervaringscijfers. Dan punt 2. Naast de omvang moet men de productiviteit kennen. In het voorbeeld van het navigatiesysteem is dat de voorspelde gemiddelde snelheid. De productiviteit wordt bepaald door drie factoren: mensen, proces en technologie. Een gemiddelde productiviteit zal men behalen wanneer: het projectteam over het algemeen ervaren is en goed getraind. Zijn teamleden minder ervaren, dan compenseren de ervaren teamleden dit; de projectprocessen zijn vooraf gemaakt en bekend bij het projectteam. Een voorbeeld is dat de projectmanager weet hoe hij een planning op moet zetten, resources voor zijn project moet regelen en wanneer en hoe hij de voortgangsrapportage moet maken; de gebruikte technologie is normaal in de markt. Voorbeelden van een afwijkende technologie is nieuwe, nog niet uitontwikkelde technologie zoals service georiënteerde architectuur (SOA), maar ook zeer oude technologie zoals Cobol op een mainframe. Bij nieuwe technologie zullen de teamleden meer tijd steken in uitzoekwerk en daarnaast zullen er kinderziektes zijn, zodat geen gemiddelde productiviteit behaald zal worden. De mensfactor is het meest bepalend voor de productiviteit. Zes ervaren teamleden zullen een hoge productiviteit halen, terwijl zeven onervaren teamleden - logischerwijs - een lagere productiviteit behalen. Een verschil van factor twee tussen een ervaren team en een minder ervaren team is zeker niet ongebruikelijk! Effect van doorlooptijd op de kosten Als acht teamleden een systeem kunnen ontwikkelen in tien maanden, kunnen 80 teamleden dan een systeem ontwikkelen in één maand? Kunnen 1.600 teamleden het systeem ontwikkelen in één dag? Het is duidelijk dat de laatste vraag absurd is, maar het effect is duidelijk zichtbaar: door de doorlooptijd te verkorten heb je meer uren nodig en zal er meer budget nodig zijn! De navolgende figuur laat de curve zien van het effect van de doorlooptijdaanpassing op de totale projecturen. De rode stip vertegenwoordigt de optimale doorlooptijd en is bepaald door de tooling (SLIM Estimate(tm), www.qsm.com). Een doorlooptijdverkorting van 10 procent resulteert in ongeveer 30 procent meer uren en dus kosten! Een doorlooptijd rond de rode stip is het beste om een optimale verdeling tussen kosten en doorlooptijd te hebben. Wil men korter dan kost dat dus geld! Buiten het vierkant is het niet aan te raden om een project 19

STOP 25% 10% Gevolgen van doorlooptijd op de inspanning Doorlooptijd (mnd) 20 uit te voeren. Dat betekent niet korter dan 25 procent en niet langer dan 10 procent ten opzichte van de optimale doorlooptijd. Onderzoek wijst uit dat een aantal aanwijsbare oorzaken van de effecten van de doorlooptijdverkorting hieraan ten grondslag liggen. Een verkorting van de doorlooptijd ten opzichte van de ideaal berekende doorlooptijd zorgt voor een groter team, omdat dezelfde omvang gerealiseerd moet worden in een kortere tijd. Dit resulteert in extra uren en dus kosten vanwege: meer overleg; meer overhead; meer tijd nodig voor het inleren van de projectleden; meer afhankelijkheden in het project door meer parallel te werken, waardoor er meer fouten ontstaan en meer tijd nodig is voor herstelwerkzaamheden. Onderzoek Er is onderzoek gedaan naar de gevolgen van de doorlooptijd op de inspanning en kosten. De resultaten van de onderzoeken zijn vaak lastig te begrijpen formules. Om de effecten goed te bepalen zijn commerciële tools op de markt. Voorbeelden zijn de SLIM toolset (www.qsm.com) of Construx (www.construx.com). Als u geen tool heeft, kunt u de volgende vuistregel gebruiken: Doorlooptijd = totale projecturen in manmaanden Dat resulteert in de volgende tabel (uitgaande van 151 uur per maand): Projectinspanning Doorlooptijd (uur) (maanden) 2.000 3,6 5.000 5,8 10.000 8,1 20.000 11,5 Voer meerdere schatting uit op hetzelfde systeem De kans dat één persoon iets vergeet te plannen is aanwezig en zelfs reëel. De kans dat twee personen dezelfde fout maken, is klein. Als twee personen ook nog eens verschillende methoden gebruiken, is de kans nog kleiner. De verschillen tussen de schattingen zijn het meest interessant en moe- Checklist / tips bij de budgetaanvraag Bij de budgetaanvraag is het voor controllers vaak moeilijk te controleren of er goed over het project is nagedacht. Je kunt de projectmanager de volgende vragen stellen. Als hij deze vragen niet kan beantwoorden moet je je dringend afvragen of er budget moet worden vrijgemaakt voor dit project. Vraag de projectmanager: wat het gaat kosten als het project een maand langer mag duren. Vuistregel: 10 procent korter = 30 procent duurder om de projectaanpak (zoals RUP, Waterval, Agile) en bekijk of de aanpak er gedegen uitziet wat de stelpost is voor meerwerk/veranderingen. Een project zonder wijzigingsverzoeken is niet reëel. Een projectmanager die er zelf over heeft nagedacht en er daadwerkelijk iets over kan zeggen, weet in ieder geval waar hij over praat naar de risicomatrix. In de risicomatrix wordt onderscheid gemaakt tussen waarschijnlijkheid (hoog/laag) en impact (hoog/laag). Vraag wat er wordt gedaan om de risico s met een hoge waarschijnlijkheid èn een hoge impact te elimineren wat de productiviteit is en waaruit deze uit is samengesteld wat de omvang is met een bijbehorende onzekerheidsmarge. 100 procent zekerheidsmarge bestaat niet. Iets tussen 10 en 60 procent is reëel wat het gaat kosten of hoe lang het gaat duren als men met 95 procent zekerheid wil

ten vergeleken worden. Door de verschillen toe te voegen of te schrappen aan de schattingen zal de kwaliteit van de totale schatting toenemen. Enkele voorbeelden van typen schattingen zijn: Top down Omvang en productiviteit resulteren in uren en doorlooptijd op basis van ervaringscijfers. Deze schatting is hiervoor beschreven. Bottom up Een workbreakdownstructuur wordt opgesteld, waarbij alle projectactiviteiten en de benodigde uren voor elke activiteit wordt geschat. De uren per activiteit worden opgeteld, wat resulteert in een schatting van de totale uren. Analogie Het te bouwen systeem wordt vergeleken met een eerder gebouwd systeem met ongeveer dezelfde omstandigheden. Gut feeling Bijvoorbeeld 3-3-3 (drie man, drie maanden, drie ton). Het is natuurlijk duidelijk dat de methodes verschillen in nauwkeurigheid. De laatste methode is niet aan te raden als de enige methode. Maar als snelle schatting naast twee andere schattingen is deze methode mogelijk. Blijf meten Als een project vooraf geschat is en er is budget aangevraagd en toegewezen, dan gaat het project van start. Tijdens de uitvoering van een project kan er veel gebeuren, zodat de eerdere schatting aan het begin van het project niet meer klopt. Om dit te voorkomen zal men moeten meten en de gegevens analyseren. Dit is essentieel, omdat een organisatie beter wil worden in het schatten om budgetoverschrijdingen te voorkomen. In de praktijk blijkt dat het periodiek verzamelen van gegevens erg lastig is. Men is meestal afhankelijk van andere partijen en als het verzamelen van de gegevens moeilijk is, dan zal het verzamelen snel stoppen. Houd daarom rekening met de volgende zaken bij het opstellen van een meetprogramma: 1. begin klein, met een paar projecten; 2. verzamel niet te veel gegevens. Beperk je in eerste instantie alleen tot de gegevens die nodig zijn om het schatten te onderbouwen en te verbeteren. Deze gegevens zijn: totale projectinspanning in uren, omvang (in bijvoorbeeld functiepunten, regels code of use case punten), doorlooptijd, testbevindingen. 3. maak het verzamelen gemakkelijk door: gebruik standaard tools die het verzamelen eenvoudig maken. Denk aan een standaard projectmanagement tool waarin de uren worden bijgehouden, zoals Clarity of MS Projects. Het gebruik van standaard tools kent de volgende voordelen: de persoon die de meetgegevens verzamelt, hoeft slechts op een paar standaardplaatsen te zoeken, de organisatie heeft slechts enkele tools die ze moet onderhouden en beheren, de medewerkers hebben altijd te maken met dezelfde tools, zodat het eenvoudig is om deze tools te gebruiken; processen in te richten die het verzamelen eenvoudig maken. Laat bijvoorbeeld de projectmanager elke maandagmiddag de gewerkte uren per week verzamelen. Niet geschat is altijd mis Zoals gezegd gaan veel projecten mis. En dat hoeft helemaal niet. Door een aantal relatief eenvoudige zaken te regelen kunt u grote overschrijdingen van het budget voorkomen. De belangrijkste zaken nog een keer op een rij: 1. zorg ervoor dat de organisatie begint met meten van gegevens die nodig zijn om beter te kunnen schatten: omvang, uren, doorlooptijd en testbevindingen; 2. voer altijd twee schattingen uit: een bottom up schatting op basis van de activiteiten en een top down schatting op basis van omvang en gemeten productiviteit. Vergelijk de twee schattingen op basis van uitgangspunten. Gebruik voor beide schattingen de meetgegevens; 3. probeer ervoor te zorgen dat men geen projecten uitvoert met een verkorte doorlooptijd Als dit toch noodzakelijk is, bepaal dan de consequentie in kosten, kwaliteit en risico s. Voorbeeld wekelijkse rappor tage Tijdens de uitvoering van een project produceren de bouwers in het projectteam evenveel regels code als voorspeld. Ook het realiseren van de functionaliteit verloopt volgens planning. Wekelijks wordt met behulp van de QSM toolsuite (www.qsm.nl) een rapportage gemaakt. Deze toolsuite voorspelt nauwkeurig het aantal testbevindingen op basis van regels code productiviteit en doorlooptijd. Uit de rapportages blijkt dat het aantal gevonden testbevindingen veel lager is dan voorspeld. Op zich vindt een projectmanager dat niet erg; hoe minder testbevindingen hoe beter! Maar wat zal er gebeuren als er testbevindingen in de code zitten die niet worden gevonden in de functionele tests? Het herstellen van fouten die lang geleden zijn gemaakt kost meer tijd dan direct een fout herstellen. De ontwikkelaars weten niet dat ze fouten hebben gemaakt, dus zullen ze waarschijnlijk meer van dergelijke fouten maken. Het resultaat Nadat ongeveer driekwart van het project doorlopen is, worden er opeens veel meer fouten gevonden dan voorspeld. En het worden er alleen maar meer. Dit brengt in de laatste projectfase met zich mee dat: extra teamleden moeten worden ingezet, zodat meer uren nodig zijn dan begroot; 35 procent meer testbevindingen worden gevonden dan voorspeld. Dankzij de wekelijkse rapportage is gelukkig op tijd een discussie opgestart over de testbevindingen en heeft de projectmanager tijdig kunnen reageren, zodat het project met een uitloop van twee weken met 80 extra uren succesvol is opgeleverd. 21

OVERZICHT Wie betaalt bij overschrijding 22 In principe is een bedrijf nooit gebaat bij het overschrijden van budget en/of tijd. Daarom is het verstandig om zeer goed te kijken naar de projectaanpak, referenties van de medewerkers van het projectteam en de continuïteit van een projectteam. En daarnaast te kijken naar de kosten, maar deze niet te laten gelden als voornaamste drijfveer! Als bedrijf ben je gebaat bij een goed werkend systeem dat op tijd wordt opgeleverd met de juiste kwaliteit. Als een project in budget en/of tijd overschreden wordt, dan is afhankelijk van de projectuitvoering wat de gevolgen zijn: Zelf doen Alleen grotere bedrijven hebben de mogelijkheid om projecten door een eigen ICT-dienst te laten uitvoeren. Als een project budget/tijd overschrijdt, dan zal het zelf volledig verantwoordelijk zijn. En dus de kosten zelf moet dragen. Zelf doen, met enkele inhuur Grote bedrijven gebruiken vaak deze vorm van projectuitvoering. Ook kunnen bedrijven met een wat kleinere ICTorganisatie onder eigen verantwoordelijkheid ICT-project uitvoeren. Voordeel van deze vorm van projectvoering is dat de projecten volledig onder eigen verantwoordelijkheid plaatsvinden. Er kan direct worden bijgestuurd waneer er iets mis gaat. Nadeel is dat men minder flexibel is in de projectteam samenstelling. Ook zal een bedrijf haar eigen medewerkers moeten blijven opleiden om de ICT-trends bij te houden, terwijl je bij het inhuren van externen gewoon de juiste kennis kiest. Wanneer een ICT-project in budget en/of tijdoverschreden wordt, dan zal het bedrijf zelf de kosten moeten dragen. De laatste jaren wordt ICT niet meer gezien als core business en is een aantal bedrijven op grote schaal aan het uitbesteden. Uitbesteden op time material basis Het ICT-project is in deze vorm volledig uitbesteed aan een aannemende partij. De uitbestedende partij levert meestal de specificaties aan en zal de accepterende tests uitvoeren. De uren die gemaakt worden door de aannemende partij worden allemaal betaald. Als een project in budget en/of wordt overschreden, dan zal over het algemeen de uitbestedende partij zelf verantwoordelijk zijn en de kosten moeten betalen. Tenzij er vooraf afspraken zijn gemaakt over resultaatverplichting binnen een bepaald aantal uren. Of als blijkt dat het erg veel meer uren heeft gekost, dan oorspronkelijk werd begroot door de aannemende partij. Uitbesteden op fixed price basis Dit is een riskante vorm van uitbesteden. Niet alleen voor de aannemende partij, ook de uitbestedende partij voelt de nadelige gevolgen van het niet op tijd opleveren van een ICT-systeem. Vaak kan de uitbestedende partij een goede deal maken door een aantal aannemende partijen tegen elkaar uit te spelen. De partij die het grootste risico wil nemen, wint de deal. Dit lijkt goed voor de uitbestedende partij. Want als een ICT-project echt niet te realiseren is, dan zullen de kosten door de aanbestedende partij betaald moeten worden. De uitbestedende partij is hier in werkelijkheid niet bij gebaat. Het project wordt niet op tijd geleverd of helemaal niet meer. Of de aanbestedende partij ziet in alles meerwerk, zodat het toch nog heel duur uitvalt voor de uitbestedende partij. Vooral bij uitbesteding in deze vorm is het belangrijk dat een controller vooraf toetst of de projectaanbieding realistisch is. C advertentie