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.

Goedkope software kan u veel geld gaan kosten…

Dure kleren kopen heb ik altijd onzin gevonden. Je betaalt voor het merk, voor het labeltje in de kraag dat toch niemand ziet. Daar ben ik van teruggekomen. Ik heb een peperduur T-shirt in de kast hangen dat al vier jaar meegaat en het kraagje is nog steeds in bloedvorm. Bij het kopen van producten doe je er echt goed aan om niet de goedkoopste variant aan te schaffen. Gek genoeg geldt dit ook voor software.

Bedrijven die bij het uitbesteden van softwareproductie erop letten dat hun leverancier een code van goede kwaliteit maakt, zijn aantoonbaar goedkoper uit tijdens de hele levensduur van een softwareapplicatie. Dat bleek recent tijdens de recent gehouden Cyber Resilience Summit in Brussel. Fouten en kwetsbaarheden in de software zijn een belangrijke prooi voor hackers om in te breken op een IT-omgeving en zo hun slag te slaan. Tijdens de levensduur van een applicatie steken organisaties veel geld in het onderhoud om deze onvolkomenheden eruit te halen en zo de risico’s op hackaanvallen te verkleinen. En om de beschikbaarheid en het goed functioneren van de software te kunnen garanderen.

Kwaliteit checken

Je kunt al die inspanningen en extra onderhoudskosten drastisch naar beneden schroeven door als klantorganisatie de structurele kwaliteit van de applicatie tijdens de bouw te laten checken. Internationaal is er een standaard voor zogenaamde structurele kwaliteit, de total quality index, die door het Consortium for IT Software Quality gedefinieerd is en ook vergelijkbaar gemaakt kan worden met applicaties die in specifieke programmeertalen en methoden geschreven zijn.

Tijdens het evenement kwam het voorbeeld voorbij van een grote internationale investeringsbank die besloot afdoende aandacht aan softwarekwaliteit te besteden om business risico’s zoveel mogelijk te minimaliseren. Het bleek dat dit bedrijf over de levensduur van de applicatie aanzienlijk voordeliger uit zou zijn doordat de geprogrammeerde software minder structurele fouten bevatte. Onder die structurele kwaliteit vallen zaken als betrouwbaarheid, prestaties, efficiency, security en hoe de applicatie goed onderhouden kan worden.

Wie denkt dat het hier om klein bier gaat heeft het mis. Bij een lage total quality index, waarbij de applicatie vele tientallen productie-incidenten kende, was het bedrijf 2 miljoen dollar kwijt aan onderhoud en het bijwerken van de applicatie. Bij een hoge score op de total quality index en een laag aantal incidenten waren deze onderhoudskosten teruggebracht naar 5.000 dollar. Dit voorbeeld laat zien dat het loont om er zeker van te zijn dat de software van de applicatie die gebouwd is van goede kwaliteit is.

Toezeggingen

Veel klantorganisaties gaan hierbij uit van de toezeggingen van de leverancier en zijn reputatie in de markt. Gezien de risico’s en de mogelijk hoge kosten van onderhoud is het raadzaam om als klantorganisatie toch meer tijd, geld en expertise te steken in het scannen van de software op een goede kwaliteit. Zo voorkom je dat een op het oog flitsende applicatie tijdens het gebruik een molensteen blijkt te zijn, omdat er een enorme bak met geld nodig is voor onmisbaar onderhoud. METRI heeft samen met Cast een methode ontwikkeld om de kwaliteit en de omvang tijdens het ontwikkelen van de applicatie te screenen. Ik vertel u graag meer over de aanpak en de mogelijkheden. En dan doe ik gelijk met dit prachtige zomerweer mijn T-shirt aan. Met de kraag in topvorm.


Bent u klaar voor IT-dienstverlening uit meerdere keukens?

Soms, als ik lang in de wacht sta voordat ik eindelijk word ‘doorverbonden’, teken ik wat. Doedels heten die creaties volgens de moderne psychologie en ze schijnen wat te zeggen over je karakter. Mijn laatste doedels zeggen echter veel meer over de dienstverlening in de wereld van private- en public cloud oplossingen.

Ik tekende twee torenflats. Daartussen een iets te slap gespannen koord. Op het koord juristen, die fanatiek aan het stoeien waren op dat slappe koord. Hoe kwam ik erop om deze doedel te tekenen?

Even terug naar een eerder blog. Hierin pleitte ik voor een datacenter met nummerbehoud als een prachtige optie in de verdere standaardisering van cloud oplossingen. Dat klinkt helaas nog als toekomstmuziek. Echter, in de wondere wereld van private- en public cloud oplossingen is veel beweging en roering. Er wordt me wat gediscussieerd over voorwaarden, over beschikbaarheid, over data, connecties, combinaties en multi vendor oplossingen met gedeelde verantwoordelijkheden in vernieuwende eco-systemen en de complexe wereld die daarachter zit. Wat je vooral ziet is dat klanten de regie steeds meer richting de leverancier schuiven.

De leveranciers krijgen een steeds grotere rol in het afstemmen van diensten met de verschillende leveranciers aan een en dezelfde klant. Verschillende contractpartijen van een klant moeten gaan samenwerken om de totale dienstverlening voor de klant te realiseren zonder dat de klant de regie hierover moet voeren. Multi Vendor Management-initiatieven schieten uit de grond in een wereld die meer en meer aan het differentiëren is. Klanten verwachten een duidelijke verbetering in de gedeelde verantwoordelijkheid van de geboden services door de partijen. Denk hierbij bijvoorbeeld aan een wijziging binnen een applicatielandschap waarbij ook de infrastructuur aangepast dient te worden. De klant verwacht een werkende oplossing waarbij de verschillende leveranciers samenwerken, zonder tussenkomst van de opdrachtgever.

Dit alles vraagt nogal wat van de old school service integrators. Openheid van zaken in geleverde dienstverlening kunnen pijnlijk duidelijk gaan maken waar elkaars kwaliteiten liggen. Nieuwe samenwerkingsverbanden liggen in het verschiet. En uiteindelijk gaat het over het managen van risico’s en zo kwamen mijn doedels tot stand. Misschien verstandig om in deze discussie ook de klant mee te nemen, die zit namelijk in een van de torenflats die ik voor me zag.

Ik stond nog een tijdje in de wacht. Mijn gedachten dwaalden af naar vliegtuigen, mijn nieuwe doedel op mijn kladblok. Na jarenlange studies in de vliegtuigindustrie is namelijk gebleken dat vleugels die buigen veel meer kunnen dragen en langer meegaan. Door deze eyeopener is de veiligheid in de luchtvaart enorm verbeterd. Flexibele eco-systemen lijken op hun beurt de rechtlijnige processen in ego-oplossingen te buigen.

Toch ben ik benieuwd of de nieuwe ontwikkelingen een bijdrage gaan leveren in klantgerichte duurzame en betrouwbare oplossingen. De eerste stap in die richting lijkt gezet. Dat is het goede nieuws. De technologische ontwikkelingen van vandaag maken het mogelijk om verschillende kleinere oplossingen samen te voegen tot één geheel. Deze kleinere oplossingen kunnen ook geleverd worden door meer gespecialiseerde partijen. Het slim gebruiken van gestandaardiseerde en geaccepteerde ‘producten’ maakt gespecialiseerde dienstverlening mogelijk. Langzaam maar zeker ontstaat er een soort menukaart van IT-dienstverlening waarmee de maaltijd door de consument samengesteld kan worden. Van ster-kwaliteit tot foodtruck-niveau. Voor ieder wat wils. Leve de diversiteit. Als je maar wilt.

Langzaamaan krijgt de klant weer de regie over de benodigde oplossing waarbij de regievoering meer en meer naar de leveranciers verschuift. Multidisciplinaire dienstverlening uit verschillende keukens, bent u er klaar voor?