Waarom is het verbeteren van de security en code kwaliteit zo belangrijk voor overheidsorganisaties?

Het belang van ISO 5055 als uitbreiding op ISO 25010 voor het geautomatiseerd meten van software code voor overheidsorganisaties.

De digitale weerbaarheid van de overheid moet sterker. Maar hoe krijgt u dat voor elkaar? Veel overheidsorganisaties geven op dit moment aandacht aan het beter inrichten van Lifecycle Management (LCM). Inzicht in de technische staat van applicaties is een goed startpunt om de kwaliteit en de security te verbeteren en plannen te maken voor de toekomst. Het inventariseren van de omvang en de technische staat van de applicaties in het portfolio is een belangrijke stap, want deze factoren bepalen voor een groot deel de onderhoudskosten. Om goede toekomstplannen te kunnen maken is deze informatie van groot belang.  

Hoe maakt de overheid de technische staat van een applicatie inzichtelijk?

Binnen de overheid wordt er vaak gesproken over de International Standardization Organization (ISO) 25010 standaard als het gaat om het inzichtelijk maken van de technische staat van een applicatie. Deze ISO standaard heeft in 2011 de oude standaard 9126 vervangen en kijkt naar 2 aspecten: de productkwaliteit en de geschiktheid voor gebruik. Onder ISO 25010 worden kenmerken als functionele geschiktheid, prestatie-efficiëntie, uitwisselbaarheid, bruikbaarheid, betrouwbaarheid beveiligbaarheid, onderhoudbaarheid en overdraagbaarheid beschreven. Er zijn verschillende technologieën beschikbaar op de markt die deze kenmerken geautomatiseerd kunnen meten en die kunnen beoordelen in welke mate een applicatie voldoet aan deze kenmerken. Deze technologieën meten de applicatie source code geautomatiseerd door en produceren dan een of meerdere dashboards waarop scores op de ISO 25010 kenmerken getoond worden. Dat klinkt prima, maar het is geen garantie voor succes.  

Hoe zit het met de ontwikkeling en het onderhoud van moderne applicaties?

Een nadeel van veel technologieën is dat de analyse op code niveau wordt uitgevoerd. Bestand na bestand wordt gekeken naar zaken als complexiteit en security. Moderne applicaties bestaan echter uit vele verschillende componenten, lagen, files, frameworks, etc. Als we naar applicaties kijken vanuit een architectuur oogpunt, dan ziet dat eruit als het voorbeeld in de volgende figuur.  

Architectuur overzicht app

Figuur 1: voorbeeld architectuur overzicht van een applicatie

Zoals u waarschijnlijk al doorhad, is de complexiteit groot, mede door de vele aanroepen tussen de verschillende onderdelen. Uit onderzoek blijkt dat veel (tot wel 60%) van de productieincidenten van applicaties worden veroorzaakt door foutieve aanroepen tussen componenten. Deze incidenten zijn moeilijk te reproduceren en op te lossen en leveren mede daarom de meeste downtime op. Het is daarom belangrijk om de kwaliteit van applicaties te meten op codeniveau en op systeemniveau. Een voorbeeld van goede code, maar een matig systeem, staat in de volgende figuur.

goede code slecht systeem

Figuur 2: voorbeeld van goede code, maar een slecht systeem

De man in de figuur wil de pinautomaat gebruiken. Hoewel op codeniveau alles in orde lijkt, is het toch niet mogelijk de pinautomaat te gebruiken, omdat er bijvoorbeeld een incident is opgetreden in een van de slechte aanroepen in het systeem.

Om dit probleem te tackelen is er in 2021 een uitbreiding gekomen op de ISO 25010 standaard. Dit is de ISO/IEC 5055 standaard voor het geautomatiseerd meten van software code kwaliteit. Deze standaard schrijft voor dat er heel specifiek moet worden gekeken naar overtredingen van goede codeerstandaarden en architectuur standaarden. Er zijn duizenden regels vastgelegd in vele verschillende standaarden en best practices, zoals bijvoorbeeld van OWASP, CWE, NIST, CISQ en OMG. Deze regels zijn dingen die je moet doen, of juist niet moet doen bij het ontwikkelen en onderhouden van de applicatie. Een voorbeeld van een van de duizenden regels: „Avoid SQL injection through API requests“. Dit is een van de belangrijke regels op security gebied en een overtreding van deze en vergelijkbare regels levert een groot risico op voor de applicatie, en mogelijk voor de hele organisatie. Uiteindelijk zijn er altijd mensen betrokken bij applicatie ontwikkeling en onderhoud en dus kunnen er altijd issues zijn, ook als de mensen heel goed zijn.

Human error

Figuur 3: software development is mensenwerk, en niemand kent alle duizenden regels uit z’n hoofd, ook Dave niet! (Bron: https://www.jklossner.com/)

Wat is het voordeel van het geautomatiseerd meten van software code kwaliteit?

Het voordeel van de ISO 5055 manier van het onderzoeken van software kwaliteit is dat het ook mogelijk wordt om heel specifiek in de code aan te tonen waar een regel is overtreden, waarom dat een mogelijk kritiek issue is en hoe dit eventueel opgelost kan worden. Dit zorgt ervoor dat het maken van aanpassingen een stuk gemakkelijker wordt. De ISO 5055 standaard maakt het dus mogelijk om de software kwaliteit vast te stellen op codeniveau en op systeemniveau. Door vervolgens de gevonden issues gericht te verbeteren, worden de risico’s in de applicatie snel verminderd en wordt de technische kwaliteit snel verbeterd. Dit kan er in het kader van Lifecycle management weer toe leiden dat toekomstplannen worden aangepast omdat de technische staat van de applicaties wordt verbeterd en de onderhoudskosten omlaag gaan.

Hoe doen we dit bij IDC Metri?

Bij IDC Metri voeren we regelmatig codekwaliteit onderzoeken uit waarbij we CAST technologie inzetten die de code op zowel ISO 25010 als ISO 5055 meten. Het ontwikkelteam krijgt heel specifiek inzicht in de gevonden issues en we geven onze klanten een concreet verbeterplan waarbij het doel is met zo weinig mogelijk inspanning zoveel mogelijk kwaliteitswinst te halen.

Het management kan vervolgens de voortgang monitoren op het management dashboard, waar de trends staan in de scores per applicatie, zodat er een duidelijk beeld is wat de technische staat is van de applicaties en de trends hierin, o.a. als basis om keuzes te kunnen maken in het kader van Lifecycle management. Dit ziet u terug in onderstaande figuur. Het voordeel van de CAST technologie is dat we ook geautomatiseerd de omvang meten in Automatische functiepunten (AFP). Dit stelt ons in staat om ook financiële benchmarks en adviezen te geven op basis van de meer dan 15000 data punten van applicaties en projecten in onze database.

source code
rule documentation

Figuur 4: voorbeeld van het developer dashboard: waar zit de fout, waarom is het een fout en hoe kan deze worden opgelost

 

Meer weten? Kom dan naar onze webinar voor overheidsinstellingen

 

Op donderdag 26 januari om 16.00 uur organiseren we een webinar waar we ingaan op hoe we dit doen en waarbij we Frans Struijk, directeur IV Facilitair Bedrijf bij het UWV, hebben gevraagd om te laten zien hoe wij het UWV geholpen hebben in een specifieke case, waarbij ook een bekende system integrator betrokken was. Inschrijven kan hieronder.

Aanmelden voor Webinar Security binnen overheden 26 januari

Webinar: Hoe vermijd je security issues in applicaties? (voor de overheid)

Datum: 26 januari 2023

Tijd: 16.00-16.45

Locatie: online via Zoom

Hoe heeft IDC Metri samen met partner CAST zicht kunnen bieden aan management op de risico’ t.a.v. de standaarden ISO 25010, ISO 5055 en andere? We laten het u zien aan de hand van een case bij de centrale overheid.

Sommige leveranciers hebben in de afgelopen jaren een dusdanig grote footprint in de Nederlandse overheid opgebouwd, dat ze inmiddels een begrip geworden zijn. Zo ook op het gebied van software risico en kwaliteit assessments. Toch is het goed om af en toe opnieuw te inventariseren wat de verschillende oplossingen op de markt zijn en de waarde die zij leveren. IDC Metri, tesamen met haar partner CAST – wereldwijd marktleider op dit gebied – bieden een state of the art dienst aan op dit gebied waarbij management zicht krijgt op de risico’ t.a.v. de standaarden ISO 25010, ISO 5055 en andere. Daarbij helpen we de teams met een dashboard waarop de gevonden kritieke fouten staan, de reden dat deze kritiek zijn, en hoe deze opgelost kunnen worden. Hands-on verbetering en directe kwaliteitsverbetering en risico verlaging voor de applicatie. Tijdens dit webinar willen we u graag laten zien op welke wijze we dit doen, en ook een succes case vanuit de centrale overheid presenteren.

Nu IDC Metri samen met PWC en Accenture de SIMA-mantel gegund heeft gekregen, opent dat de mogelijkheid om ons mee te nemen in uw selectietrajecten.

Aanmelden voor Webinar Security binnen overheden 26 januari

IT Cost Management Summit

In de sfeervolle omgeving van de Philharmonie in Haarlem deelden experts uit binnen- en buitenland hun ervaringen op het gebied van het begroten en beheersen van IT-kosten.

De aftrap werd verzorgd door Joop Schefferlie, president van de IPMA, één van de grootste organisaties voor projectmanagement. Veel van de veranderingen in de maatschappij komen tot stand in de vorm van projecten. Tegenwoordig vertegenwoordigen projecten al bijna 40% van alle economische activiteiten. De gemiddelde student in het hoger onderwijs krijgt echter niet meer dan drie weken onderwijs in projectmanagement. Het succes van een project is in grote mate afhankelijk van het leiderschap in een project. Een goede projectmanager moet in staat zijn om de juiste expertise om zich heen te verzamelen.

Meer informatie

Daniel Saroff van IDC liet zien dat te pessimistisch begroten en zeker te optimistisch begroten een grote invloed heeft op het uiteindelijke resultaat van een IT ontwikkelproject. Veel agile projecten begroten vooral de hoeveelheid werk, maar houden te weinig zicht op welk deel van het werk echte waarde brengt. Hierdoor neem het risico toe dat een te groot deel van het budget besteed wordt aan zaken die geen waarde toevoegen en er aan het einde van het budget onvoldoende product is voor een geslaagde businesscase. Daarvoor is meer budget en tijd nodig. Door gericht metrieken te gebruiken en deze te volgen kunnen negatieve ontwikkelingen op tijd worden gesignaleerd en aangepakt voor ze problemen worden.

Meer informatie

Paul Marston van SPA ging in op de positieve kanten van agile: het in kleine teams werken aan concrete resultaten met regelmatige terugkoppeling. Dit lijkt niet te matchen met traditioneel projectmanagement dat draait om het uitvoeren van een plan. Maar ook al ben je flexibel, moet je nog steeds plannen en begroten. We moeten af van het idee dat we een volledige en complete begroting moeten maken, maar laten we ook voor het plan en de begroting beginnen met een Minimum Viable Product.

Meer informatie

Megan Jones van ICEAA presenteerde de Cost Estimation Body of Knowledge for Software (CEBoK-S) die de organisatie later dit jaar als een zelfstandig kennisdomein zal worden gelanceerd. Het begroten van software kent een aantal zaken die specifiek zijn voor het softwaredomein. Deze komen bovenop de algemene onderwerpen die al onderdeel zijn van de al bestaande CEBoK. In de loop van volgend jaar wordt het mogelijk om als software cost estimator gecertificeerd te worden.

Meer informatie

Koos Veefkind van de Belastingdienst deelde de ervaringen van de Belastingdienst in het voorspelbaar maken van hun IT projecten. Van het portfolio van bijna een half miljoen functiepunten wordt jaarlijks ruim 10% gewijzigd. Omdat de Nederlandse belastingwetgeving zo complex is, is ook het IT-landschap van de Belastingdienst complex. De opsplitsing van de Belastingdienst in drie delen, maakt het beheer van dit landschap niet eenvoudiger. Om betrouwbaar te kunnen leveren worden projecten kleiner gemaakt, zodat er altijd binnen 12 maanden een Minimum Viable Product wordt opgeleverd. Daarnaast wordt gebruik gemaakt van de historische productiviteitsgegevens om te bepalen hoe realistisch een afgegeven doorlooptijd is.

Meer informatie

Amritpal Singh Agar van The Cost of Everything podcast heeft over de hele wereld mensen geïnterviewd die de kosten hebben bepaald van de meest uiteenlopende zaken van het maken van films tot de bouw van kernreactoren. Wat hieruit naar voren komt is dat de meeste van deze mensen toevallig in deze rol terechtgekomen zijn. Hoe verschillend hun achtergrond ook is en wat ze begroten, de overeenkomst is dat ze nieuwsgierig zijn naar het verhaal achter de cijfers.

Meer informatie

Paul Hussein van de EU Securities & Markets Authority (ESMA) is al 10 jaar betrokken bij de uitbesteding van de IT van ESMA. ESMA heeft geen on-premise IT en het onderhoud is voor 100% uitbesteed. Als EU agentschap staat het IT-budget drie jaar van tevoren vast. De verhouding tussen instandhouding en vernieuwing binnen ESMA is 60:40. Als de onderhoudskosten stijgen betekent dit dat er minder geld is voor vernieuwing. Om de kosten voor de IT voorspelbaar te houden werkt ESMA met een catalogusprijs voor de vernieuwing en het onderhoud van hun IT-systemen. Daarvoor werd gebruik gemaakt van IFPUG functiepunten. Voor hun nieuwe cloud-native dataplatform maakt ESMA nu gebruik van COSMIC functiepunten om de catalogusprijzen op te baseren. Voor  verschillende projecten en systemen zijn verschillende categorieën gedefinieerd op basis van omvang en complexiteit.

Meer informatie

Emmanual Mary van Unison nam ons mee in het domein van software cost estimating in de automobielindustrie. De verwachting is dat in 2030 de kosten voor software 50% van de totale productiekosten van een auto zullen uitmaken. Hoewel het belang groot is, blijft software nog een ondergeschoven kindje. In de auto industrie is er nog een wijdverbreid geloof dat software niet te begroten is. Als de autoproducenten grip willen krijgen op de kosten van de software moeten ze met een omvangsmaat gaan werken om kosten te kunnen begrijpen, vergelijken en controleren. Op basis van patronen kan snel een goede inschatting worden gemaakt.

Meer informatie

Metri adviseert pensioeninstelling over kosten van IT-programma

Na vele jaren onderhandelen ligt er dan eindelijk een nieuw pensioenakkoord. Voor de pensioensector is dat echter pas het begin: de invoering van het nieuwe stelsel zal de komende jaren een megaklus zijn voor de verschillende branchepartijen. Zo ook voor TKP Pensioen. Metri hielp de pensioenuitvoerder met het verkrijgen van inzicht in de omvang van de benodigde ICT-aanpassingen.

Het in 1988 opgerichte TKP verzorgt de pensioenuitvoering voor 23 fondsen en ruim 3,7 miljoen Nederlanders. Daarmee is TKP één van de grootste pensioenuitvoeringsorganisaties van Nederland.

Om het ICT-landschap van TKP voor te bereiden op het nieuwe pensioenstelsel wordt gewerkt aan een groot overkoepelend programma. Voordat dit van start gaat heeft het management objectief en onderbouwd inzicht nodig in de te verwachten kosten en doorlooptijd van de ICT-aanpassingen, om de stakeholders te kunnen informeren.

Dit overzicht wordt verkregen via software cost estimation, oftewel het vaststellen van de omvang van dat wat gerealiseerd moet worden en het bepalen van een realistische productiviteit waarmee men dit kan realiseren. De omvang wordt vastgesteld in zogeheten functiepunten, de enige internationale standaard voor het kwantificeren van functionele omvang.

TKP heeft zelf een indicatieve functiepuntanalyse opgesteld op basis van de logische entiteiten in het domeinmodel dat aan de basis ligt voor de realisatie. Vanwege de omvang, de complexiteit en het belang van de operatie, wilde TKP deze analyse laten toetsten door een gespecialiseerde externe partij. De pensioenuitvoerder schakelde Metri in, een IT-adviesbureau gespecialiseerd in vraagstukken op het gebied van IT intelligence, benchmarking en sourcing.

Metri werd gevraagd om (1) een ‘expert opinion’-validatie te geven op de high-level schattingen van TKP, (2) een extern bruikbare, onderbouwde en betrouwbare prognose op te stellen ten aanzien van doorlooptijd en kosten op dit programma en (3) een intern advies te geven om vanuit metrieken de voorspelbaarheid, bestuurbaarheid en de effectiviteit van agile teams te borgen.

De begroting die Metri heeft opgeleverd betreft (onder meer) een validatie van de indicatieve FPA, een productiviteitsanalyse, de toegepaste begrotingsparameters, de minimale, te verwachten en maximale begroting voor wat betreft uren, kosten en doorlooptijd, de benodigde uren gespecificeerd per functie/rol, antwoord op verschillende scenario’s, en advies ten aanzien van de metrics die kunnen worden ingezet om de voortgang van het project objectief te monitoren en de mogelijkheden om vroegtijdig bij te sturen.

“Metri heeft deze opdracht in een zeer korte doorlooptijd uitgevoerd”, laat het bureau weten. “De opgeleverde begroting verschaft TKP het benodigde inzicht in de minimum, de meest waarschijnlijke en de maximum te verwachten kosten en doorlooptijd. Hiernaast heeft Metri het effect van bepaalde scenario’s aangegeven en een monitorinstrument geadviseerd waarmee TKP het programma kan besturen om het resultaat binnen de gestelde bandbreedtes te houden en eventueel vroegtijdig bij te sturen als dit nodig is.”

Bron: Consultancy.nl

Zero Based Budgeting biedt uitkomst voor CIO in coronatijd

Hoe bepaal je het IT-budget voor het komende jaar? Het is een vraagstuk dat veel CIO’s en IT-afdelingshoofden deze periode bezighoudt. Frank Vogelezang van strategisch adviesbureau Metri zet de voor- en nadelen van twee veelgebruikte methodes op een rij.

“Met afstand de meest gebruikte aanpak is de zogeheten baseline begroten methode”, trapt Vogelezang af. “Hier wordt het budget of de realisatie van het huidige jaar als uitgangspunt genomen en worden de onderdelen geïndexeerd en soms nog even kritisch tegen het licht gehouden.”

Vogelezang geeft aan dat deze aanpak uitermate geschikt is wanneer er tussen de twee jaren “weinig verschillen zijn in digitale strategieën en investeringen”. In dat geval is het een “zinnige keuze”. De baseline begroten methode ligt echter “minder voor de hand”, zo legt Vogelezang uit, wanneer er sprake is van een “grote verandering of koerswijziging”.

Te denken valt aan een fusie of een overname, het afsplitsen van een bedrijfsonderdeel, of het uitbesteden van een deel van de IT naar een externe partner. “Dit soort disrupties maken het budget of de bestedingen van dit jaar een volstrekt irrelevante graadmeter voor het budget van volgend jaar. In dat soort situaties is het goed om voor een andere aanpak te kiezen”, aldus Vogelezang.

Ook de huidige coronapandemie maakt dat er sprake is van een disruptieve omgeving. De pandemie heeft van thuiswerken en digitalisering in één klap het nieuwe normaal gemaakt. En om binnen deze nieuwe situatie effectief te zijn, moet de IT-afdeling investeringen doen om de sterke toename in digitaal werken te faciliteren.

Om te illustreren hoe groot de impact van het nieuwe normaal is op IT – volgens onderzoek van KPMG en Harvey Nash onder CIO’s wereldwijd zijn sinds de start van de uitbraak de totale (IT-)uitgaven van grote corporates met maar liefst $15 miljard per week toegenomen. Vogelezang: “Organisaties van iedere omvang hebben momenteel te maken met extra investeringen in de IT-hoek, hier moeten CIO’s goed naar kijken.”

Thema’s die vooral de aandacht verdienen zijn onder meer extra investeringen in security, in bandbreedte om tijdens meetings ook video te kunnen gebruiken, in werken in de cloud, en het versnellen van het uitfaseren van legacy-applicaties.

Maar als de baseline begroten methode niet ideaal is voor de budgetcyclus, welke dan wel? Vogelezang duikt in een andere mogelijke methode: Zero Based Budgeting.

Zero Based Budgeting

Zero Based Budgeting is een aanpak die het budget vanaf de grond weer opbouwt. “Kijkend naar de huidige omstandigheden en behoeften, wordt het budget bottom-up vanaf nul opnieuw opgebouwd”, vertelt Vogelezang. Terwijl dit meer tijdsintensief is dan baseline begroten, kleven er volgens de Metri-adviseur diverse belangrijke voordelen aan.

“Met Zero Based Budgeting worden kosten snel inzichtelijk en is de beslissing om ermee te stoppen makkelijker gemaakt.”

Om te beginnen kan hiermee gezorgd worden voor een effectievere allocatie van het budget. Vogelezang: “Er wordt nadrukkelijk gekeken naar de uitgaven die de beste return on investment hebben, zonder dat het budget van het lopende jaar daarbij in de weg zit.” Daarbij komt dat er ook wordt gekeken naar toekomstige behoeften, waardoor IT dichter kan komen te staan bij de wensen vanuit de business.

Ook niet belangrijk, het kan in de portemonnee schelen. Volgens experts van McKinsey & Company kan de besparing tussen de 10% tot wel 25% van het budget bedragen. “Omdat er met een frisse blik wordt gekeken, biedt deze manier van begroten ruimte om niet-productieve kosten omlaag te brengen”, legt Vogelezang uit. “Met Zero Based Budgeting worden kosten snel inzichtelijk en is de beslissing om ermee te stoppen makkelijker gemaakt. Doordat er bottom-up gekeken is, vergemakkelijkt dit ook de communicatie over de beslissing om te stoppen.”

Bijkomend voordeel is dat CIO’s en IT-teams tijdens het proces doorgaans efficiënties ontdekken die anders niet boven waren komen drijven. “Zo’n proces kan tegelijk ook dienen als een strategische review van de IT-activiteiten”, legt de Metri-adviseur uit.

Dit werkt vooral goed als binnen de review sectorbenchmarks worden toegepast: “Organisaties kunnen zichzelf afzetten tegen voorlopers in de markt. Hiermee wordt het verbeterpotentieel in kaart gebracht, en dit kan dan meteen worden meegenomen in het plannings- en budgetteringscyclus.”

Beste uit twee werelden

Tot slot geeft Vogelezang aan dat bij het kiezen van een geschikte methode de één de ander niet uitsluit: in veel gevallen kunnen de twee methodes elkaar ook aanvullen

“Een hybridevorm brengt het beste uit twee werelden bijeen: de snelheid van de baseline begroten methode en de voordelen van Zero Based Budgeting”, legt hij uit. “De vaste onderdelen van het budget worden vanuit de baseline opgebouwd en de delen waarop de organisatie meer grip wil hebben of houden worden vanaf nul opgebouwd.”

Wil je meer weten?

Vul onderstaand formulier in om zelf een afspraak in te plannen voor een vrijblijvend gesprek. Kom je er niet uit? Bel ons dan op 020 655 1777.

Het IT-budget voor volgend jaar

Metri Budget

Indexeren huidige budget of doelgericht opbouwen

Op dit moment zijn veel organisaties bezig om het IT-budget voor het komende jaar definitief te maken. De methode die we in de markt het meest tegenkomen is baseline begroten. Hier wordt het budget of de realisatie van het huidige jaar als uitgangspunt genomen en worden de onderdelen geïndexeerd en soms nog even kritisch tegen het licht gehouden. Daar waar de IT-activiteiten van volgend jaar weinig verschillen van die van dit jaar, is dit een zinvolle keuze. Deze aanpak ligt minder voor de hand als er nieuwe dienstverlening wordt toegevoegd, na een fusie of een overname, na het afsplitsen van een bedrijfsonderdeel, of na het met spoed digitaliseren van het hele bedrijf als gevolg van COVID-19. Dit soort disrupties maken het budget of de bestedingen van dit jaar een volstrekt irrelevante graadmeter voor het budget van volgend jaar. In dat soort situaties is het goed om voor een andere aanpak te kiezen.

De coronabezem door het IT-budget

In een eerdere blog is er al voor gepleit om de disruptie die COVID-19 met zich meebrengt aan te grijpen om eens kritisch naar het IT-portfolio te kijken en daar de coronabezem door te halen. Iets vergelijkbaars geldt dan natuurlijk ook voor het IT-budget. Dit jaar hebben veel organisaties hun IT radicaal omgegooid vanwege COVID-19. Een enorme inspanning van veel IT-afdelingen heeft ervoor gezorgd dat vrijwel alle processen buiten de kantoormuren door kunnen draaien. Zo is ING in 7 dagen volledig digitaal gegaan. Dat had niemand vooraf durven plannen.

Dat wil uiteraard niet zeggen dat alles nu vlekkeloos draait. Veel organisaties zijn nu aan het nadenken wat het voor de lange termijn betekent als een groot deel van het werk vanuit de huizen van medewerkers wordt uitgevoerd. Dit vraagt extra investeringen in security, in bandbreedte om tijdens meetings ook video te kunnen gebruiken, maar ook versnelde investeringen in het naar de cloud brengen van (legacy) applicaties die een kritieke rol spelen binnen het primaire proces. Dat laat zich niet vangen in een indexering.

Zero Based Budgeting

Bij Zero Based Budgeting wordt niet gekeken naar de baseline van vorig jaar, maar wordt het budget vanaf nul opnieuw opgebouwd vanuit de huidige omstandigheden en behoeften. Zeker nu de IT zich  sneller ontwikkelt wordt de baseline van het afgelopen jaar voor een toenemend deel van het budget minder relevant. Dit is dus een heel andere benadering en vraagt met name een andere mindset van de mensen die het budget opstellen. Er wordt bottom-up gekeken naar de uitgaven die de beste Return on Investment hebben, zonder dat het budget van het lopende jaar daarbij in de weg zit.

Omdat er ieder jaar met een frisse blik wordt gekeken, biedt deze manier van begroten ook ruimte om niet-productieve kosten omlaag te brengen. Onderzoek van McKinsey liet zien dat die soms wel 10-25% van het budget kunnen bedragen. Iets wat vorig jaar nog een goede investering leek, kan onder de huidige omstandigheden alweer achterhaald zijn. Met Zero Based Budgeting wordt dat snel inzichtelijk en is de beslissing om er mee te stoppen makkelijker gemaakt. Doordat er bottom-up gekeken is vergemakkelijkt dit ook de communicatie over de beslissing om te stoppen.

Een frisse blik op het IT-budget

Door met een Zero Based Budgeting blik naar het IT-budget te kijken krijg je oog voor mogelijkheden om zaken effectiever of efficiënter te doen, zoals:

  • Het zichtbaar maken van de relatie tussen budgetonderdelen en de behoeften en voordelen
  • Het zichtbaar maken van de relatie tussen organisatiedoelen en het budget
  • Het elimineren van verouderde applicaties en/of infrastructuur
  • Het identificeren van mogelijkheden voor outtasking of outsourcing
  • Het identificeren van te zwaar aangezette onderdelen van het budget

Het nadeel van deze manier van werken is dat het vanaf nul opbouwen tijdrovender is dan het baselinen van het bestaande budget. Zeker voor nieuwe activiteiten is het soms lastig om te voorspellen wat dit gaat kosten en wat de verwachte Return on Investment is. Voor de meeste operationele technologieën kan de benchmarkdata van Metri hierbij helpen. De meeste organisaties die met Zero Based Budgeting werken, kiezen daarom voor een hybride vorm. De vaste onderdelen van het budget worden vanuit de baseline opgebouwd en de delen waarop de organisatie meer grip wil hebben of houden worden vanaf nul opgebouwd.

Meer grip op het budget

Binnen organisaties ziet Metri een toenemende behoefte aan inzicht in de cost-drivers, zodat onderbouwde beslissingen kunnen worden genomen om bepaalde kosten terug te brengen. Hiervoor is het nodig om de kosten die aan IT gemaakt worden, te relateren aan de diensten die de organisatie aan haar klanten, gebruikers of burgers levert, hiervoor kan gebruik gemaakt worden van bijvoorbeeld het TBM-framework.

Een toenemend aantal organisaties hanteert striktere processen voor Planning en Control. Dit kan alleen maar effectief zijn als het budget zodanig is opgebouwd dat er zinvol gemonitord kan worden. Terugkerende monitoring van de plannen zorgt ervoor dat geplande verbeteringen ook werkelijk worden doorgevoerd. Zero Based Budgeting kan hier een goede bijdrage aan leveren, als onderdeel van het hele Planning en Control proces.

Wat ook helpt om grip te houden op het budget is het hanteren van een expliciete maatvoering van het IT-budget. Is het IT-budget afhankelijk van groei in klanten/gebruikers of gebaseerd op omzet of winst. Hoe explicieter een budget is opgebouwd, hoe meer de aandacht en energie verschuift van het bewijzen waarom iets is zoals het is naar het actief op zoek gaan naar manieren om zaken beter, sneller of goedkoper te gaan doen. Dit zorgt voor het besef dat geen enkele uitgave te klein is om eens kritisch naar te kijken.

Ook behoefte aan een frisse kijk op uw budget? Laten we eens beginnen met een ‘digitale’ kop koffie.

Wil je meer weten?

Vul onderstaand formulier in om zelf een afspraak in te plannen voor een vrijblijvend gesprek. Kom je er niet uit? Bel ons dan op 020 655 1777.

Webinar: Begroten en beheersen van software-ontwikkeling

Interconnectie in de digitale economie

Krijg meer inzicht en grip op grote IT programma’s met de Cost Estimation Suite. Het vernieuwen van IT landschappen is op zichzelf vaak al uitdagend genoeg. Grote programma’s met complexe afhankelijkheden hebben een grote impact op de organisatie en alle betrokkenen. Door het objectief en berekenen van de realistische kosten en hieraan gekoppelde planning kunnen adequate acties uitgezet worden.

Meer weten?

Spreek direct een specialist, neem contact op met IDC Metri voor een snel en duidelijk antwoord:

De 11 zonden van Software Cost Estimation

Metri blog

Met grote interesse volg ik een twitterdiscussie tussen Glen B. Alleman (@galleman) en Vasco Duarte (@Duarte_Vasco) over de zin en de onzin van het begroten van software projecten. Vasco Duarte is een Agile, Lean and Scrum Speaker en een voorstander van #NoEstimates, de beweging die vindt dat het moeilijk is om sofwareprojecten te begroten en dat er daarom maar geen energie in gestopt moet worden. Hij heeft hier zelfs een boek over geschreven.

Glen B. Alleman is een ervaren project manager die o.a. het boek ‘Performance-Based Project Management: Increasing the Probability of Project Success’ heeft geschreven en een groot voorstander is van het toepassen van professionele cost estimation methoden, ook voor software. Even een paar tweets om er in te komen:

Metri Tweet
Metri tweet

Persoonlijk vind Ik het erg interessant om te zien hoe de hardcore ‘agilisten’ van deze wereld het durven voor te stellen om de fundamentele principes van organisatiekunde overboord te zetten. In mijn ogen heeft Glen gelijk. Iemand besteedt geld en wil begrijpen of datgene waar hij het aan uitgeeft ook zinvol is en of het Value for Money opbrengt. Bij de Agile team Performance Monitor projecten die we vanuit Metri doen zien we het keer op keer: Dezelfde feature wordt meerdere keren (in meerdere sprints) ontworpen, gebouwd en getest. Dit zorgt ervoor dat de functionaliteit die op moment X klaar zou moeten zijn, vaak nog lang niet klaar is. Zeker in het geval van outsourcing vinden leveranciers dat prima, want dan kunnen ze nog een paar extra sprints factureren.

Agile projecten komen net zo vaak in de problemen wat dat betreft als de traditionele watervalprojecten, alleen is het minder zichtbaar omdat er meestal geen vaste prijs en vaste opleverdatum zijn vastgesteld. Soms is dat niet erg, maar wat nou als er een grote marketingcampagne gepland is waar deze functionaliteit voor nodig is, of wat als er een wet ingaat en deze functionaliteit nodig is voor de uitvoering daarvan?
Bij Software Cost Estimation gaat het meer om het begroten van de hoeveelheid functionaliteit die klaar is op moment X en tegen welke kosten die dan klaar is. Het professioneel begroten is bittere noodzaak om de risico’s zoveel mogelijk te beperken.

Toch is het niet zo dat de #NoEstimates beweging nergens op gebaseerd is. Veel organisaties hebben weinig kennis van het begroten van software projecten en gebruiken alleen ‘human judgment’ methodes. Mensen zijn erg optimistisch van nature en als dit de enige methode is, is er een grote kans dat de begrotingen altijd te positief zijn. Dat leidt tot grote (onevenredig grote) problemen! Ik zag onlangs een presentatie van onze partner Galorath, de wereldwijd leider op het gebied van Cost Estimation software, waarbij de 10 deadly sins van Estimation voorbij kwamen. Veel organisaties trappen in een of meerdere van deze valkuilen:

1. Het verwarren van een begroting met een targets.
2. Toegeven aan druk vanuit het Management.
3. Te vroeg commitment geven, terwijl er nog maximale onzekerheid is t.a.v. het te realiseren product.
4. Denken dat een optimistische begroting geen problemen oplevert.
5. Begroten in de onmogelijke zone, iets doen wat nog nooit eerder gedaan is.
6. Denken dat het gebruik van nieuwe tools en technieken enorme productiviteitswinst oplevert.
7. Slechts 1 begrotingstechniek gebruiken (human judgment).
8. Geen gebruik maken van parametrische modellen.
9. Het negeren van risico analyses.
10. Het gebruiken van een ‘Rough order of magnitude’ begroting en deze niet meer aanpassen nadat de onzekerheid minder is geworden.

Ik zou hier zelf nog een 11e aan toe willen voegen:

11. Het luisteren naar de #NoEstimates voorstanders, die denken dat het onmogelijk is accurate begrotingen te maken van software development projecten.. en dit dan ook maar niet meer willen doen.

Het professioneel begroten van software projecten is een echt vakgebied. Metri gebruikt gecertificeerde functiepunt analisten om de te realiseren omvang vast te stellen en gebruikt professionele software cost estimators om vervolgens langs verschillende assen een gedetailleerde begroting te maken van de benodigde uren per functie/rol, de kosten, de doorlooptijd, de teamomvang. Hierbij worden de geavanceerde modellen van Galorath SEER-Sem gebruikt in combinatie met de duizenden projecten in de Metri database. Voor meer informatie, zie die IT Intelligence pagina van Metri.

Hoe maak je een softwarebegroting voorspelbaar?

Het begroten van grote software realisatieprojecten blijkt nog steeds lastig. Geregeld zien we dan ook berichten over budgetoverschrijdingen. Leveranciers laten meestal een team van experts begrotingen maken, maar de praktijk heeft uitgewezen dat deze methode vrijwel altijd leidt tot een te optimistische begroting. Een te optimistische begroting vormt in veel gevallen de basis voor het falen van dit soort complexe projecten. Het uit Finland afkomstige concept van ‘triangle benchmarking’ is een goede manier om inzichtelijk te maken hoe groot de kans van slagen is van een opgestelde begroting.

Het concept van ‘triangle benchmarking’ is gebaseerd op de standaard duivelsdriehoek van projectmanagement waarbij scope, budget en doorlooptijd een driehoek vormen, waarvan de oppervlakte gelijk blijft bij een afgesproken kwaliteitsniveau. Het beïnvloeden van één van de drie hoekpunten leidt automatisch tot een verschuiving van minstens één van de andere hoekpunten om een gelijk oppervlak van de driehoek te houden.

Het onderliggende principe van de duivelsdriehoek is dat projecten altijd onder deze drie beperkingen tot stand komen. Zo is tijd altijd een beperking, omdat de resultaten van het project op een bepaald moment beschikbaar moeten zijn. De beperkingen in de kosten bepalen hoeveel budget of menskracht er is om de projectdoelstelling te realiseren. De projectomvang tenslotte geeft aan wat er moet gebeuren om het project te kunnen realiseren. Deze drie factoren vechten om schaarste: een grotere projectomvang betekent meestal meer tijd en hogere kosten, een strakke deadline brengt juist hogere kosten of een kleinere scope met zich mee en een krap budget betekent meer tijd of een kleinere projectomvang. Evenwicht in die dimensies zorgt dat het project de gewenste kwaliteit krijgt en productief zal zijn. Dit maakt deze driehoek tot een grafisch hulpmiddel dat drie essentiële dimensies uit een complex project kan abstraheren tot een eenvoudig beeld dat de aard van een project goed weergeeft.

Vanuit het onderliggende principe van de duivelsdriehoek bepalen deze beperkende factoren ook de dynamiek van complexe softwareprojecten. Als je één van de dimensies verandert, moet tenminste één van de andere dimensies ook meebuigen, omdat anders de kwaliteit van het project eronder lijdt. De driehoek kan tal van vormen aannemen, afhankelijk van hoe de verschillende factoren zich tot elkaar verhouden. Met ‘triangle benchmarking’ wordt deze dynamiek in één oogopslag inzichtelijk. Hieronder een paar typerende projectvormen:

De bovenstaande voorbeelden laten een viertal succesvol afgeronde softwareprojecten zien. Door een begroting op een gestandaardiseerde manier weer te geven kunnen begrotingen van nieuwe projecten snel worden vergeleken met succesvol afgeronde projecten. Hiervoor is het nodig dat scope, budget en doorlooptijd gestandaardiseerd worden weergegeven. Een conventie hiervoor zou kunnen zijn:

  • Scope 1 cm = 200 functiepunten
  • Budget 1 cm = 100.000 euro of 1.000 uur
  • Doorlooptijd 1 cm = 3 maanden

Budget en doorlooptijd zijn in de meeste begrotingen van grote software realisatieprojecten wel voorhanden. Scope is in veel gevallen een onderbelicht aspect. Dat is een groot risico. Scope is binnen dit soort trajecten de meest bepalende factor voor de benodigde hoeveelheid budget en doorlooptijd. Het is daarom van belang dat de scope wordt uitgedrukt in een objectieve eenheid die meetbaar, herhaalbaar en duidelijk is voor klant en leverancier. Een gestandaardiseerde eenheid voor scope is de functiepunt.

Een ander voordeel is dat een scope uitgedrukt in functiepunten organisaties ook in staat stelt om de eigen softwareprojecten te vergelijken met vergelijkbare projecten uit een omvangrijke database. De International Software Benchmarking Standards Group (ISBSG) beschikt over een database van meer dan 9.100 softwareprojecten uit 32 landen die in te zetten is om een projectbegroting mee te vergelijken.

Door aan de verhoudingen tussen de verschillende factoren kleuren toe te kennen (groen is goed, geel is in orde, rood is slecht) kan ook een opdrachtgever zonder inhoudelijke kennis van IT projecten snel beoordelen welke factoren uit een begroting niet in balans zijn en dus geen realistisch uitgangspunt zijn. Hiermee worden te rooskleurige toezeggingen van een projectteam direct zichtbaar.

Dit maakt het concept van ‘triangle benchmarking’ heel interessant. Door de vorm en de kleur van de driehoek zie je in een oogopslag of het project op een kostenefficiënte manier uitgevoerd wordt in vergelijking met een relevante referentiegroep.

Metri heeft veel ervaring en expertise in het bepalen van de realiteitswaarde van begrotingen van software projecten en het benchmarken van afgeronde software projecten. Metri kan u daarom helpen te bepalen welke vorm de driehoek van uw project is en of uw begroting groen, geel of rood is.

Nut en noodzaak van kwaliteitscontrole op Agile

sofware quality

Reageren op verandering is belangrijker dan het volgen van een vooropgesteld plan. Door deze vuistregel in het Agile Manifesto, is planning en kwaliteitscontrole het kind van de rekening geworden in agile softwareontwikkeling. Bedoeld als methode om met een klein team, kort op de bal software te ontwikkelen slaat dit dogma opdrachtgevers instrumenten uit handen om grip op kwaliteit en productiviteit te krijgen bij agile softwareprojecten.

De agile methode lijkt boven elke twijfel verheven nu het zelfs wordt ingezet bij bedrijfsonderdelen die niets met IT van doen hebben. Maar juist nu de wereld agile en masse omarmt, moeten we toch eens stilstaan bij de risico’s. Er zijn tal van signalen van senior-managers bij grote organisaties die niet tevreden zijn met de prestaties van hun agile teams. Agile is wat dat betreft toe aan een herbezinning.

Wildgroei

Die wildgroei ligt overigens niet alleen aan de teams zelf. Neem bijvoorbeeld het feit dat in agile development de risico’s bij de klant liggen. Dienstverleners lenen mensen uit op basis van uurtje-factuurtje, en na oplevering nemen deze partijen geen verantwoordelijkheid meer voor het resultaat. In de agile-wereld zijn er nu eenmaal nauwelijks resultaat gebaseerde contracten. Daar is de kwaliteit niet bij gebaat met alle risico’s van dien. Inferieure softwarecode kan het voortbestaan van je organisatie bedreigen. Zogenaamde ‘software intelligence’ is daarom een must, was de belangrijkste boodschap van het Software Intelligence Forum in Parijs van organisator Cast en andere experts, dat ik begin dit jaar bezocht.

Zelf mocht ik ook vertellen wat organisaties kan overkomen als zij de greep verliezen op hun applicatieportfolio en wat zij hiertegen kunnen doen. Mijn presentatie ging over het spanningsveld tussen agile werken, controle over het ontwikkelproces en de uiteindelijke softwarekwaliteit. Het verschil in output tussen softwareteams –dus niet alleen agile teams – kan zomaar een factor 10 verschillen. Een belangrijke oorzaak is dat er een groot gebrek is aan uniforme meetmethoden zoals die in veel andere industrieën gemeengoed zijn.

Ook aan de planning van projecten schort regelmatig het een en ander. Zowel de inschatting van kosten als de looptijd kloppen vaak niet. Omdat agile werken organisatorische veranderingen veronderstelt, is dat bijna een uitnodiging tot falen. Op een X-moment is gewoon niet alle benodigde functionaliteit beschikbaar.

De agile-methode geeft teams daarnaast veel invloed. Daar is op zich niks mis mee, maar omdat zij geen standaard metrieken hanteren waarmee hun output te meten is, is er op een hoger niveau geen overzicht. Teams gebruiken storypoint-based metrics, die prima functioneren binnen het team, maar buiten deze context hun betekenis verliezen. Hierdoor weet het hogere management niet waar het aan toe is. Managers hebben daardoor heel weinig controle over ‘hun’ teams, die vaak grotendeels worden bemensd door externen. Ook dit maakt de situatie er niet gemakkelijker op.

Spagaat

Het hoger management is wel verantwoordelijk voor de kosten en de waarde die agile teams moeten toevoegen. Daardoor zitten deze executives in een vreemde spagaat: ze moeten toezicht houden op het ontwikkelproces, maar hebben hier in de praktijk weinig tot geen zicht op. Zonder onderbouwde feiten is het een onmogelijke taak om hier verantwoording over af te leggen. In elke andere discipline is dit een recept voor mislukkingen te noemen.

Want het senior management moet over objectieve, met feiten onderbouwde informatie kunnen beschikken om de organisatie te leiden en teams de juiste kant op te sturen. Executives moeten niet alleen teams kunnen vergelijken op basis van hun output. Ze moeten de kwaliteit en de risico’s in het applicatieportfolio ook kunnen doorgronden. En in organisaties die agile ontwikkeling hebben omarmd, ontbreekt het hier regelmatig aan.

In het eerdergenoemde Agile Manifesto zijn genoeg aanknopingspunten om een duurzame softwareontwikkeling te bevorderen. Een van de twaalf stelregels schrijft voor dat de sponsoren, ontwikkelaars en gebruikers in staat moeten zijn om een constant tempo onbeperkt te kunnen handhaven. Hier is objectieve informatie over de productiviteit en de softwarekwaliteit die teams voortbrengen onontbeerlijk. Door de output van agile teams op een hoger niveau te monitoren krijgen opdrachtgevers weer grip op hun investeringen.

Agile: lenig in een spagaat

Het is verdraaid lastig om met de fiets de Alpe d’Huez te beklimmen. Wat helpt? Knip de klim in stukjes en doe het bochtje voor bochtje. Ga niet voor bocht 1 tot en met 21, maar ga eerst voor bocht 1. Eigenlijk is dit een beetje hoe agile werkt. Een béétje, want agile gaat ook – en vooral – over sprinten en dat kun je op die alp maar beter niet doen.

Alles in de IT moet ineens agile. Het betekent letterlijk: behendig, lenig. In de IT-wereld staat het voor softwareontwikkeling in korte overzichtelijke sprints van meestal niet meer dan een maand. In sommige gevallen zelfs van maar een week. Kleine projecten met groepjes mensen om snel een slag te kunnen maken. Maar werkt het?

Vrijwel iedereen is het er wel over eens dat agile ‘ons’ veel goeds heeft gebracht. De gebruikers vanuit de business zijn blij, omdat gewenste veranderingen sneller in de software doorgevoerd worden. De ontwikkelaars zijn blij, omdat ze direct met de gebruikers in contact zijn en software maken die ook echt gebruikt wordt. In de agile werkwijze zijn blijheid en tevredenheid belangrijke targets en dat is bij de meeste stakeholders prima in orde.

Allemaal top dus? Nou, niet helemaal. Blije werknemers en blije eindgebruikers zijn geen garantie voor blije bestuurders. In veel bestuurskamers maakt men zich toch wel zorgen of dat zelfsturende werken in groepjes enthousiaste mensen, behalve tevredenheid nog wel software oplevert die voldoende businesswaarde genereert. In de praktijk betekent de kreet ‘Wij werken Agile’ bovendien nogal eens dat het nog wel even gaat duren voordat het af is. Dit laatste is overigens een bewering van columnist Jacob Spoelstra maar hij staat hierin niet alleen.

Mensen die floreren in een agile team zijn mensen die niet bang zijn voor verandering en minder geneigd zijn te zoeken naar zekerheden. Ergens aan willen en kunnen beginnen zonder dat het eindresultaat helemaal vaststaat is erg belangrijk. En dat is niet helemaal de wijze waarop mensen uit de financiële rapportagelijnen zijn ingesteld, zoals budgethouders en controllers. Voor hen ligt het blije gevoel van de agilisten minder voor de hand. Zij moeten hun beslissers overtuigen om budget vrij te maken voor agile projecten. Zij moeten ervoor zorgen dat zichtbaar wordt dat de agile ontwikkelde software ook echt waarde toevoegt aan de organisatie.

Hoe bepaal je in een agile omgeving de waarde van de opgeleverde software? Vanuit agile kijken we vooral naar gebruikerswaarde. Hierdoor krijgen user stories met de meeste gebruikerswaarde – ten opzichte van de kosten om ze te realiseren – de hoogste prioriteit. Vanuit het financiële kader denken we eerder in boekwaarde waarbij vooral de kosten van het realiseren van de software een belangrijke rol spelen. En de financiële sturing binnen organisaties gaat nogal eens wringen met een agile aanpak. Afhankelijk van de mate waarin het agile gedachtengoed is doorgedrongen binnen een organisatie ontstaat er ergens een ‘torsiemoment’ tussen het agile gedachtengoed gericht op het creëren van waarde, en de financiële verantwoording.Het is dus de kunst om de balans te vinden tussen de flexibiliteit die je met agile werken wilt bereiken en de voorspelbaarheid die bestuurders zoeken. En dan bij voorkeur op een manier die recht doet aan de drijfveren aan beide kanten. Win-win, inderdaad.

Wat overigens een groot voordeel is: agile software ontwikkelen biedt je de mogelijkheid om te stoppen als de software voldoende businesswaarde biedt. Goed is goed genoeg. Het is dan de kunst om op tijd te stoppen en je aandacht te richten op iets wat meer businesswaarde oplevert.

Daarom is het goed om af en toe eens een frisse blik van buiten te laten kijken naar de agile organisatie. Wordt er wel voldoende waarde geleverd? METRI kan dit vergelijken met andere bedrijven en helpen om de organisatie zo vorm te geven dat er maximale waarde geleverd kan worden.

Volg je ons al?


[/vc_column_text][/vc_column][/vc_row]

Budgetoverschrijding of begrotingstekort?

In de pers verschijnen er geregeld berichten over budgetoverschrijdingen van IT-projecten. De teneur is veelal dat omvangrijke projecten gewoon niet in de hand te houden zijn en dat budgetoverschrijdingen er kennelijk bij horen. De belangrijkste bron van dit soort berichtgeving is de reeks aan CHAOS-rapporten die onderzoeksbureau Standish jaarlijks samenstelt. Eén belangrijk aspect wordt in dit soort onderzoeken systematisch over het hoofd gezien: het tekort aan kwaliteit van de oorspronkelijke begroting.

Ik ben mijn werkzame leven ver buiten de IT begonnen, namelijk op een ingenieursbureau dat zich bezighield met de voorbereiding van één van de grootste infrastructurele werken sinds de Deltawerken, de aanleg van de Betuweroute. Van deze spoorlijn van 160 kilometer tussen het Rotterdamse havengebied en de Duitse grens bij Zevenaar wisten rekenaars al voordat de eerste meter spoor was aangelegd dat de totale kosten aanzienlijk hoger zouden zijn dan de bedragen waar in de politiek over werd gedebatteerd. Waren hun inzichten gebruikt als oorspronkelijke budgetraming, dan was de uiteindelijke budgetoverschrijding veel kleiner uitgevallen. Of de Betuweroute was er nooit gekomen.

Beheersbaar

Toen ik me een aantal jaren later ging bezighouden met het begroten van IT-projecten bleek dat daar soms ook op een vergelijkbare manier begroot werd. Inmiddels heb ik voldoende projecten langs zien komen die eigenlijk al het stempel ‘mislukt’ hadden moeten hebben voordat ze van start gingen. Als het probleem niet uniek is voor de IT, dan kunnen we ook kijken naar oplossingen die buiten de IT hebben geholpen dit probleem beheersbaar te maken.

Eén van die oplossingen is het gebruik maken van de Basis of Estimate die is ontwikkeld door de Nesma, een van oorsprong Nederlandse kennisclub rondom het meetbaar maken van IT-projecten. Zij hebben de principes die zijn ontwikkeld door de AACE (Association for the Advancement of Cost Engineering) voor de bouw en procesindustrie vertaald naar de IT. Als je de aspecten van de Basis of Estimate loslaat op minder succesvolle projecten, dan wordt al snel duidelijk dat een aantal cruciale aspecten van deze projecten niet of onvoldoende ingevuld te zijn. Dit maakt de Basis of Estimate een aardige voorspeller voor de haalbaarheid van een project.

Een andere aanpak is om een begroting naast vergelijkbare projecten uit het verleden te leggen om vast te stellen hoe dit zich met elkaar verhoudt. Nu zijn resultaten uit het verleden geen garantie voor de toekomst, maar zeker grote IT projecten zijn echt niet veel sneller of goedkoper dan een aantal jaar geleden. Als een begroting dat wel voorspelt, is er een goede reden om als opdrachtgever kritische vragen te stellen en een budgetoverschrijding voor te zijn. METRI heeft van veel projecten inzicht in de werkelijke kosten en kan op basis daarvan een uitspraak doen of de begroting te kort door de bocht is of realistisch. Daarmee kunnen we een belangrijke risicofactor voor budgetoverschrijding uit de wereld helpen.