Inleiding
Onderhoud op de technische infrastructuur in een datacenter is voor veel organisaties een vast onderdeel van het jaarbudget. Als dit onderhoud grootschalig is, en dat is het al gauw in grote datacentra, dan zal de beste aanpak een projectmatige zijn.
Omdat volgens de Standish Group het falen van projecten vaak veroorzaakt wordt door een slechte projectraming, moeten we voor deze infrastructurele projecten een goede methodiek voor het begroten hebben.
In deze blog doe ik een voorstel hoe organisaties hun eigen begrotingsmodel voor infrastructurele projecten in de ICT kunnen opstellen.
Begroten van projecten voor applicatieontwikkeling
Om projecten voor applicatie ontwikkeling te begroten staan een projectmanager verschillende hulpmiddelen ter beschikking. De omvang van een dergelijk project kan geraamd worden met behulp van functiepunten. In de markt beschikbare benchmarks helpen om de project omvang te bepalen. Zie bijvoorbeeld de informatie bij de organisaties van de Nesma en bij ISBSG.
Hoe begroot je als projectmanager een project waarin de ontwikkeling van IT infrastructuur de voornaamste component is?
Het valt me op dat voor het begroten van infrastructurele projecten op internet weinig bruikbaars te vinden, helemaal niets eigenlijk. Ook in de praktijk ben ik geen bruikbare methodiek tegengekomen.
In het kader van deze blog over het begroten van IT infrastructuur activiteiten, heb ik het over de volgende typen projecten.
- Het betreft het plaatsten, installeren of upgraden van infrastructuurcomponenten: hardware, operating systemen, database management software, applicatie servers en middleware
- Applicaties worden (functioneel) NIET gewijzigd
- De werkzaamheden zijn substantieel van omvang (anders organiseren we er geen projecten voor)
- Organisaties voeren dergelijke projecten periodiek uit, veelal als onderdeel van het Life Cycle Management van de technische infrastructuur
Verder is mijn stelling dat kosten van deze projecten specifiek zijn per organisatie. Dit wordt vooral veroorzaakt doordat in dit domein het beheer van de te onderhouden componenten veelal zal zijn uitbesteed. Deze uitbesteding is op verschillende manieren georganiseerd en verschillende (combinaties van) leveranciers zijn erbij betrokken. Hoe deze kosten voor projecten vervolgens tot stand komen is daarom heel divers.
Op zoek naar een model voor begroten
Vergelijkingen van kosten in dit domein en het geven van benchmarks gebeurt in de markt door consultancy organisaties. Maar aan dergelijke cijfers heb je als projectmanager niet veel als je voor de opgave van het begroten van een specifiek project staat.
Wat volgens mij wel goed mogelijk is, is om ervaringscijfers binnen de eigen organisatie op te bouwen. Dat moet relatief snel en eenvoudig kunnen omdat Life Cycle Management projecten jaarlijks plaats vinden en, op een zeker abstractieniveau, qua aard, aanpak en producten sterk op elkaar lijken.
Als ik een expertraming zie van een dergelijk project is dit meestal een spreadsheet met veel regels met benodigde activiteiten. De planning is opgesteld door verschillende experts en vervolgens geconsolideerd. Ik verwacht in de spreadsheet regels met servers, pakketten, uren van diverse specialismen, op te leveren documenten, inrichtingsactiviteiten, testactiviteiten, enzovoort.
Hoe kom je nu van dergelijke ramingen tot een begrotingsmodel? Ik zocht naar een model dat voldoet aan de volgende voorwaarden: Maximaal voorspellend vermogen met zo min mogelijk ingrediënten, bruikbaar voor het complete scala aan IT infrastructuur projecten.
Een uitgebreid model voor het begroten van IT infrastructuur projecten
Om tot een model te komen heb ik het volgende gedaan.
- Van een aantal projecten onderzocht ik in de detailplanningen hoeveel uur elk “soort” product van het project kostte. Bijvoorbeeld in een projecten worden 21 servers opgeleverd, per server bedragen de kosten gemiddeld 44 uur.
- Per product heb ik de range van de ramingen in kaart gebracht. Deze range diende vervolgens als benchmark. Dus bijvoorbeeld: Het opleveren van een server kost minimaal 30 uur, gemiddeld 40 uur en maximaal 50 uur.
- Elk project werd vervolgens langs de benchmark gelegd om zowel het project als de benchmark te toetsen. Afwijkingen werden verklaard, de benchmark werd indien nodig bijgesteld.
Resultaat was een uitgebreid model dat er uitzag als in de figuur hieronder. Een dergelijk model is per organisatie op te stellen en de regels met producten en waarden hierin kunnen per organisatie specifiek worden gemaakt.
| Begrotingsmodel per infrastructuur component | Uren per eenheid | |||
|---|---|---|---|---|
| Product | Eenheid | Min | Norm | Max |
| Server bestaande uit hardware en OS | Aantal te installeren servers | 30 | 40 | 70 |
| Database | Aantal te installeren databases | 20 | 40 | 90 |
| Middleware | Aantal te installeren pakketten | 40 | 55 | 70 |
| Applicatie server (inclusief applicaties) | Aantal te installeren applicatie servers | 20 | 40 | 50 |
| Job scheduling | Aantal in te stellen schema’s | 8 | 12 | 40 |
| Batch en native applicaties | Aantal te installeren applicaties | 1 | 8 | 12 |
| Citrix package | Aantal te ontwikkelen packages | 40 | 60 | 80 |
| Support technisch applicatiebeheer | Aantal applicatie servers + aantal applicaties | 2 | 4 | 8 |
| Network en loadbalancing | Aantal omgevingen | 8 | 10 | 16 |
| Firewall | Aantal mutaties | 40 | 40 | 40 |
| Decommissioning | Aantal te verwijderen componenten | 2 | 4 | 8 |
| Projectmanagement | Duur van het project in weken | 24 | 32 | 40 |
| Architectuur, ontwerp documenten | Aantal documenten | 40 | 50 | 60 |
| Change plan (document) | Aantal changes | 8 | 16 | 24 |
| Technische coördinatie en ondersteuning | Duur van het project in weken | 8 | 16 | 32 |
| Diverse specifieke ondersteuning | Aantal nieuw te ontwikkelen componenten | 40 | 100 | 200 |
Een eenvoudiger model voor het begroten van IT infrastructuur projecten
Het model dat hierboven gepresenteerd is, helpt om begrotingen van individuele LCM projecten op te stellen en te toetsen. Vraag is of we op basis hiervan een eenvoudiger model kunnen maken dat toch voldoende betrouwbaar de omvang van projecten voorspelt. Ik onderzocht welke producten in de ramingen nu het de grootste correlatie vertonen met de totale projectomvang. Kun je op basis van alleen het aantal servers de omvang goed voorspellen, of alleen het aantal databases, of alleen servers en databases? Voor de projecten in de onderzochte projectportfolio vonden we dat de som van het aantal servers, databases, middleware pakketten, applicatie servers en applicaties met een redelijke nauwkeurigheid (per project ± 25%) de projectomvang voorspelde. In een specifieke situatie bij een organisatie werden projectkosten bijvoorbeeld bepaald door de volgende formule.
| Projectkosten = 8500 euro x (som aantal servers, databases, middleware pakketten, applicatie servers en applicaties) |
|---|
Toepassingsmogelijkheden van het model
Hiervoor heb ik laten zien hoe een organisatie een model voor het begroten van IT infrastructuur projecten kan opzetten. Dit kan relatief snel en eenvoudig gedaan worden door een organisatie, door begrotingen en realisatiekosten van projecten uit haar Life Cycle Management portfolio in kaart te brengen. Hieronder staan 4 toepassingsmogelijkheden van zo’n model opgenomen.
1. IT infrastructuur projecten kunnen (beter) geraamd worden met behulp van het model. Natuurlijk zal nog steeds een expertraming opgesteld worden, maar door deze tegen de raming op basis van een model te houden, kan de expertraming getoetst worden. In de praktijk merk ik dat met behulp van een model fouten en slordigheden uit expertramingen worden gehaald, alleen al door deze te bespreken. Dit levert kwalitatief betere ramingen op. En met goede ramingen is de kans op projectsucces groter!
2. Er is nog een groot voordeel aan een begrotingsmodel. Het probleem van een (gedetailleerde) expert planning is dat deze moeilijk te doorgronden en te controleren is voor niet-experts. En omdat infrastructuur projecten vaak geen nieuwe functionaliteit voor eindgebruikers opleveren, worden dit soort projecten al gauw als “duur” ervaren. En daarmee bestaat het risico dat ze van de projectenkalender geschrapt worden omdat nieuwe functionaliteit meer prioriteit heeft in de ogen van de business. Dit uitstel heeft als gevolg dat noodzakelijke upgrades vertragen en daardoor duurder, complexer en meer risicovol worden. Ook de kans op storingen wordt groter met alle gevolgen van dien. Als we in staat zijn de expertramingen beter presentabel, begrijpelijk en controleerbaar te maken, dan blijkt uit de praktijk dat de kans op goedkeuring van deze projecten aanzienlijk toeneemt.
3. Het model is niet alleen op projectniveau bruikbaar. Het kan ook gebruikt worden om de omvang van de een projectportfolio te bepalen. Bijvoorbeeld kan het grofweg benodigde jaarbudget voor de IT infrastructuur projecten geraamd worden door de voornaamste kostendrijvers in kaart te brengen en vervolgens met behulp van het (eenvoudige) kostenmodel een totaalraming op te stellen voor de portfolio.
4. Je kunt zelfs nog verder gaan dan de bepaling voor alleen een portfolio. Je kunt een raming maken van de kosten voor het Life Cycle Management van de complete infrastructuur. Gebruik makend van het model, de informatie uit de CMDB over aantallen te onderhouden componenten, en de gemiddelde levensduur van deze componenten (bijvoorbeeld 6 jaar), kan bepaald worden wat de globale kosten zijn voor het up-to-date houden van de gehele infrastructuur. Hiermee kan dus bepaald worden welk budget jaarlijks gereserveerd moet worden voor onderhoud van de IT infrastructuur.
Conclusie
Het hebben van een model voor het begroten van IT infrastructuur projecten helpt bij het maken van kwalitatief betere planningen, waardoor de kans op projectsucces toeneemt. Het zal ook helpen bij het verkrijgen van acceptatie bij (en budget van) relevante stakeholders. En een model helpt om ramingen voor specifieke projectportfolio’s, jaarbudgetten of het totaal benodigde budget voor de infrastructuur te bepalen.
Marinus Spaan
Spaan Project Services
