Goed begroten is duur

metri event cost estimation

IT-projecten kosten veel geld en hebben de neiging te mislukken of veel meer extra geld te kosten. Dat is een vrij hardnekkig beeld. En volgens langjarig onderzoek ook in ongeveer 40% van de gevallen waar. Dus vragen steeds meer bestuurders om een goede onderbouwing van de investering in nieuwe IT. Goed nieuws zou je zeggen. Toch spreken we nog te vaak bestuurders die de ervaring hebben dat zo’n goed onderbouwde begroting heel duur is en het aantal missers niet afneemt. Waar gaat het mis?

Voor een complex project heb je veel experts nodig

Veel IT-projecten worden in een bestaand applicatieportfolio ingepast en er is dus veel verschillende expertise nodig om dit goed inhoudelijk vorm te geven. De fout die vaak gemaakt wordt is om ook op deze inhoudelijke experts te vertrouwen voor het maken van een projectbegroting. Een totaalbegroting voor een IT-project opstellen samen met de inhoudelijke experts vraagt al gauw een doorlooptijd van zes weken. Deze aanpak vereist ook een goed overzicht om vast te stellen of alle onderdelen van het project begroot zijn en er geen overlap zit in de onderdelen.

De ervaring van Metri is dat deze aanpak leidt tot een begroting die gemiddeld 30% te  optimistisch is in zowel kosten als doorlooptijd. Inhoudelijke expertise is geen garantie voor een goede begroting. Het maken van een goede begroting is een expertise op zich. Hiervoor is voldoende kennis nodig om de architectuur van een complex IT-project te doorgronden, maar vooral kennis hoe zich dit vertaalt in een begroting. Een goede begroting is meer dan de optelsom van een aantal losse activiteiten. Met de inzet van de juiste expertise kan in een kortere doorlooptijd een kwalitatief betere begroting worden gemaakt.

Ieder project is uniek

Een veelgehoorde reden om te vertrouwen op inhoudelijke experts is dat ieder project uniek is en er dus kennis nodig is van de inhoud om dit te begroten. Het unieke karakter definieert het verschil tussen een project en een terugkerende activiteit. Maar ook unieke projecten voldoen aan een aantal wetmatigheden. Hierdoor is de begroting van een project meer dan de optelsom van een aantal activiteiten. Deze activiteiten moeten gepland, afgestemd en bestuurd worden. Deelproducten moeten worden geïntegreerd, getest en geaccepteerd worden. Naar het begroten van unieke projecten is al meer dan veertig jaar onderzoek gedaan en daar zijn een aantal wetmatigheden uit naar voren gekomen die ook gelden voor de huidige manier van werken.

Externe expertise kost veel geld

Niet iedere organisatie die IT-projecten doet heeft eigen begrotingsexpertise in huis. Dat is begrijpelijk, want tegenwoordig gebruikt iedere organisatie IT-voorzieningen en doet vrijwel iedere organisatie wel een IT-project. Als je dat goed wilt doen, moet je daarvoor externe expertise inhuren. Dat kost zichtbaar geld. Soms wel 1% van het totale budget. Dat lijkt voor sommige organisaties veel geld. Maar is dat zo? Hoeveel geld kost het om inhoudelijke experts zes weken bezig te laten zijn met een begroting? Die kosten zijn vaak niet direct zichtbaar, omdat de inhoudelijke experts toch al met het project bezig zijn. Als je die kosten inzichtelijk maakt is een (externe) begrotingsexpert zo duur nog niet.

Slecht begroten is duurder

Bovendien brengt een begroting door inhoudelijke experts nog een verborgen risico met zich mee, namelijk dat een kwalitatief onvoldoende begroting extra kosten met zich meebrengt voor het project. Het klinkt misschien wat vreemd, maar een slechte begroting kost gewoon geld.

Als er te optimistisch is begroot, nemen de kosten exponentieel toe. Bijvoorbeeld doordat zaken parallel moeten worden uitgevoerd die beter achter elkaar uitgevoerd kunnen worden. Of doordat mensen aan het project toegevoegd moeten worden om deadlines te halen. Dit is relatief kostbaar en geeft weinig rendement.

Maar ook te pessimistisch begroten kost geld, al wordt dat meestal niet inzichtelijk. Als een begroting te ruim is dan wordt de extra ruimte meestal besteed. Bijvoorbeeld aan extra features die niet echt nodig zijn. Het project had dan goedkoper uitgevoerd kunnen worden met dezelfde waarde voor uw organisatie.

Geïnteresseerd in wat een goede begroting uw organisatie kan opleveren? Neem eens vrijblijvend contact op. Een verkennend gesprek is geheel gratis.

Stel je vraag

Heeft u nog vragen of wilt u advies op maat? Laat uw telefoonnummer of email achter en wij nemen zo snel mogelijk contact met u op.

Je krijgt wat je vraagt

Dankzij Corona is wandelen de nieuwe nationale sport geworden. Het is het gezonde alternatief geworden voor vergaderen en borrelen. Tijdens zo’n wandeling komen de meest diverse onderwerpen ter sprake. Veel onderwerpen gaan over persoonlijke dilemma’s, maar soms gaat het ineens over werk.

Mijn wandelpartner werkt vanuit een opdrachtgever aan een groot fixed-price contract. Dit contract is na een aanbesteding gewonnen door een partij die een prijs had neergelegd die twintig procent lager was dan de andere partijen. Nu het contract gaat lopen blijkt dat de geselecteerde leverancier het verkeerd lezen van requirements tot kunstvorm heeft verheven. De contractmanager had duidelijk gemaakt dat de opdrachtgever niet ging krijgen wat hij nodig had, maar wat hij gevraagd had. Om te leveren wat er nodig is, had hij een kwart hogere prijs moeten vragen.

Voor mijn wandelpartner was dit een schokkende ervaring. Zijn werkgever had een lange historie om zelf alles te bouwen met collega’s. Iedereen wist wat er nodig was en iedereen deed wat nodig was. Als de informatieanalist iets niet helemaal duidelijk had gespecificeerd, begrepen de ontwerpers toch wat er nodig was. En als de ontwerpers niet alle details scherp geformuleerd hadden, dan wisten de bouwers toch wel wat er nodig was om te bouwen wat er nodig was.

Ik vind dit soort bedrijven prachtig om voor te werken. Er lopen daar soms ook externen rond, waarvan je erachter komt dat ze extern zijn op het moment dat je de contracten te zien krijgt voor bijvoorbeeld een benchmark. Helaas heeft die cultuur ook een keerzijde als zij gebruik gaan maken van diensten van externe partijen. Voor mij is dat de realiteit van de laatste twintig jaar werkervaring. Zeker als je dat werk in competitie gaat aanbesteden aan wat je denkt dat de beste partij is. Dan kom je erachter dat bedrijven in dat soort situaties het antwoord gaan geven wat hen de meeste kans op de opdracht oplevert. En vervolgens gaan ze zich daar tijdens het contract naar gedragen.

Zijn dit soort leveranciers dan onmensen? Zeker niet! Jaren geleden heb ik daar een leuke presentatie over gegeven op een proposalseminar met als titel: “Leveranciers zijn ratten.” Veel mensen hebben daar een negatieve connotatie bij, maar ik heb ze laten zien dat dat niet terecht is. Ratten zijn ontzettend slimme beesten. Zij doen binnen hun mogelijkheden alles om zo snel mogelijk aan voedsel te komen. Als je dat op een goede manier doet, kun je een rat van alles leren, zolang je maar beseft dat een rat gewoon wil eten.

Als je leverancier negatief “rattengedrag” vertoont, zoals het stelselmatig verkeerd lezen van requirements om maar aan meerwerk te kunnen komen, heb je waarschijnlijk niet de goede vraag gesteld. Het stellen van goede vragen aan leveranciers is ook niet makkelijk, zeker als je het niet vaak doet. Wil je niet verrast worden door je leverancier? Neem dan eens contact met ons op.

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.

Software Estimation Challenge

Metri

Afgelopen donderdag, 29 oktober j.l. heeft Metri meegedaan aan de eerste Software Estimation Challenge. De challenge is een nieuw onderdeel van de International Workshop on Software Estimation (IWSM). Deze conferentie beleefde alweer de 30e editie, maar werd dit jaar voor het eerst volledig virtueel gehouden. IWSM  is gewijd aan het promoten van onderzoek en ervaring naar goede software cost estimation praktijken. Vorig jaar werd de conferentie in Haarlem gehouden door de Nesma. Dit jaar was de organisatie in handen van de Mexicaanse AMMS.

Om mee te doen aan deze challenge heeft Metri een team samengesteld van gecertificeerde experts op het gebied van Cost Estimation.

De opdracht bestond uit het begroten van een applicatie voor het managen van filmcollecties op basis van een beknopt aantal User Requirements. Vervolgens moest de impact van een aantal Non-functional Requirements inzichtelijk worden gemaakt. Uiteindelijk moest ook een urenbegroting worden gepresenteerd om de applicatie als Java webapplicatie te realiseren en implementeren. De methoden en uitkomsten van de opdracht zijn tijdens een interactieve sessie door de deelnemende teams gepresenteerd onder de aanwezigheid van een professioneel panel aan experts. Het was aan Frank Vogelezang de eer om Metri te vertegenwoordigen tijdens de sessie.

Het Metri team heeft alle onderdelen het meest uitgebreid uitgewerkt door voor elk van de deelopdrachten meerdere technieken naast elkaar te gebruiken. Voor Metri een vanzelfsprekende aanpak om de onzekerheden in beeld te brengen, voor de andere teams bleek die aanpak een eye-opener. Tijdens het komende Nesma congres rondom het begroten van softwareprojecten op 25 november zal collega Diederik Wortmann meer vertellen over de ins en outs van deze challenge.

De coronabezem door het portfolio

Coronabezem

De effecten van COVID-19 zijn wereldwijd voelbaar. In de gezondheidszorg, in stilgevallen bedrijven, maar ook in de politiek en de onderwijswereld heeft deze pandemie in een korte periode vele levens geraakt. Ook de IT van veel organisaties kraakt in zijn voegen. In een tijd die vorig jaar nog voor onmogelijk werd gehouden hebben veel organisaties het voor elkaar gekregen om hun bedrijfsprocessen door te laten draaien vanuit de huizen van hun medewerkers. Nu dat geregeld is en we tijd hebben om na te denken wat het ‘nieuwe normaal’ gaat worden en wat voor gevolgen dat heeft voor de bedrijfsvoering.

We zien steeds meer organisaties even een stap terug doen en nog eens kritisch kijken naar hun IT-portfolio. Hoe praktisch is het nog om de belangrijkste bedrijfsapplicaties on-premise te hebben, als daar nauwelijks nog gebruikers zijn te bekennen? Ook heeft COVID-19 laten zien dat lang niet alle applicaties zo essentieel blijken te zijn om de bedrijfsvoering door te laten draaien. Nu is het tijd om eens kritisch te bekijken wat er nodig is aan technologie om klaar te zijn voor de nieuwe toekomst. Tijd voor een – wat verlate – voorjaarsschoonmaak.

Waar de voorjaarsschoonmaak precies vandaan komt is niet helemaal duidelijk, maar het is een wijdverbreid gebruik in landen met koude, natte winters. In het voorjaar wordt het warm genoeg om de ramen open te zetten om het huis goed door te laten waaien, zonder je druk te hoeven maken over schadelijke insecten. Hierdoor kan de muffigheid uit het huis en kan het huis worden klaargemaakt voor het warmere seizoen met meer sociale activiteiten en vrije dagen. Door de voorjaarsschoonmaak wordt het huis weer gezond, zodat er weer efficiënt geleefd kan worden en er ruimte is voor nieuwe spulletjes.

Ook in het applicatieportfolio is het nu juist het moment om de ramen eens goed open te zetten en applicaties op te ruimen die we eigenlijk niet meer nodig hebben. Zo kunnen we ruimte maken voor nieuwe technologie die organisaties in staat stelt waar dan ook te werken en elkaar op een veilige manier te ontmoeten, zonder ons druk te hoeven maken over schadelijke virussen.

Helaas zijn er zijn nog te weinig betrouwbare statistieken, maar de verwachting is dat er minder op kantoren en meer in de buurt van thuis gewerkt gaat worden. Hierdoor moeten organisaties kritisch kijken naar hun vaste infrastructuur en zich meer richten op toegankelijk zijn via het internet. Zowel voor werknemers als klanten. Ook lijkt het erop dat COVID-19 zorgt voor een versnelde adoptie van cloudgebaseerd werken in veel organisaties.

Veel organisaties willen een digitale transformatie opstarten en hun applicatie landschap moderniseren, maar hebben geen goed overzicht van de technische staat van het portfolio en het bedrijfsbelang van de individuele applicaties. Ze weten niet goed waar te beginnen, kunnen geen gerichte keuzes maken en het opbouwen van het benodigde inzicht kan vele maanden duren.

Wacht dus niet tot het voorjaar, maar begin nu met het voorbereiden op uw nieuwe toekomst.

Meer weten?

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

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:

Hoeveel rente betaal je over je technische schuld?

Geld lenen kost geld

Let op, geld lenen kost geld! Alle reclame-uitingen die ook maar iets naar krediet ruiken moeten deze slogan in Nederland gebruiken. Maar ja, waarom geldt dat nu niet voor de aanschaf van nieuwe software?

Het klinkt misschien gek maar ook hier is sprake van rente. We bouwen ‘technische schuld’ op doordat we nieuwe features snel laten opleveren om de architectuur up-to-date te houden. Het idee erachter: nu geld verdienen met nieuwe features, zodat die inkomsten straks gebruikt kunnen worden om de zaken die zijn blijven liggen weg te werken. Deze focus levert dus technische schuld op. Soit. Maar ook daar moet rente over betaald worden. En omdat er ook over die rente weer rente betaald moet worden, leiden zaken die we ‘even laten liggen’ tot zwaar achterstallig onderhoud.

Overuren

Rente op rente? Jazeker. Dit heeft vele oorzaken. Zo verspillen ontwikkelaars tijd door te bekijken hoe ze stukken code kunnen repareren waar ze niet meer zo bekend mee zijn en die ze er beter gelijk goed op hadden kunnen zetten. Ook het refactoren van code om te zorgen dat deze beter te beheren en te schalen is, had beter gelijk gedaan kunnen worden. Ook in de infrastructuur wordt rente betaald door het in de lucht houden van verouderde apparatuur. Of het maken van overuren door het snel opzetten en configureren van noodinfrastructuur om de IT draaiend te houden. Okay, een deel van dit soort rente is niet te voorkomen, maar je houdt de zaken wel beheersbaar als je regelmatig aandacht besteedt aan het afbetalen van technische schuld.

Hoe dan? Je kunt kijken naar de Cost of Delay en de Opportunity Cost van het wegwerken of niet opbouwen van technische schuld. Het kan zeker helpen om budget en tijd vrij te maken voor het wegwerken of voorkomen van technische schuld. Een van onze klanten heeft becijferd dat 5-10% van de nieuwe features niet kan worden uitgevoerd, omdat er te veel technische schuld zit in de systemen waar die features in verwerkt zouden worden.

Wetmatigheid

Toch gaat het niet alleen over te veel focus op nieuwe features. Het is voor een deel een wetmatigheid van het maken van software. Als je een systeem verstoort blijft de wanorde gelijk – of neemt toe. Dit geldt ook voor software.

Zelfs het beste systeem staat in de loop van de tijd bloot aan verval. Moeten we ons daarbij neerleggen? Zeker niet. We moeten ons wel meer bewust zijn van de natuurwetten. Zo moeten we voldoende aandacht geven aan de architecture runway van onze applicaties om te zorgen dat de architectuur van applicaties meegroeit met de complexiteit. Bij het realiseren van nieuwe features moet er een realistische balans zijn tussen de gewenste functionaliteit en de beschikbare doorlooptijd. Sneller opleveren gaat ten koste van de kwaliteit op langere termijn. Realistisch begroten van software ontwikkeling is een vak apart, waar we u graag bij helpen.

Ook het inzichtelijk maken van de complexiteit van applicaties helpt bij het tegengaan van technische schuld. Het af en toe bespreken van de architectuurplaat tijdens een retrospective is daarbij niet genoeg. Voor zeer complexe applicaties kan Metri zelfs de architectuur visualiseren.

Door breder te kijken dan alleen de nieuwe features waar (nieuwe) klanten blij van worden blijft de technische schuld beheersbaar. En daar helpt Metri u graag bij.

Kleine moeite, grote winst

IT kost veel geld. Vaak te veel als je het ons vraagt. Overal stijgen de kosten, want, zo is de redenering, alles wordt duurder en de vraag naar IT wordt door de vele veranderingen en vernieuwingen steeds groter. Toch laten veel bedrijven ook ontzettend veel geld liggen, zo blijkt uit onderzoek van Metri. Natuurlijk moet de focus altijd gericht zijn op het verbeteren en behouden van IT-diensten. Maar er zijn ook veel kansen op het besparen van kosten. Metri schotelt u er 10 voor.

Prijsschieten in de applicatiestack

Prijsschieten

Kwetsbaarheden in het applicatieportfolio worden een heet hangijzer. Hackers krijgen ruim baan, omdat traditionele beveiligingsmaatregelen, zoals functiescheiding en toegangscontrole bedrijfskritische systemen onvoldoende beschermen. De CIO moet er op toezien dat bij de bouw van nieuwe applicaties Security by Design expliciet wordt meegenomen. Ook in de bestaande applicatiestack moet de security naar een hoger plan. Transparantie is hierbij het sleutelwoord om tot aanvaardbare risico’s te komen.

Lange tijd hebben maakten hackers vooral dankbaar gebruik van fouten in webservers en desktopsystemen om bedrijfsnetwerken aan te vallen. Voor het uitbuiten van kwetsbaarheden richten zij zich in toenemende mate op de applicatiestack. Niet-gepatchte systemen en misconfiguraties van ERP-systemen zijn een nieuw, gewild middel om binnen te komen op een bedrijfsnetwerk zo blijkt uit het rapport ‘ERP Applications under fire’ van Onapsis. Standaard worden ERP-implementaties geacht onbereikbaar te zijn voor de buitenwereld door firewalls en het niet toestaan van directe internetconnectiviteit. Die maatregelen voldoen niet langer. En wat voor ERP geldt, is van toepassing op een brede verzameling business applicaties. Het is tijd om applicatiebeveiliging op een andere manier te benaderen.

Verraderlijke dreigingen

Hoog tijd. Zeker als je kijkt naar de hoge positie van applicatie issues. In de top twaalf van grootste bedreigingen van de Cloud Security Alliance prijken de kwaliteit van applicaties (interfacing) en de structuur van softwarecomponenten respectievelijk op nummer drie en vier. Die hoge plek komt ook doordat veel internationale standaarden voor informatiebeveiliging zich primair richten op de beveiliging van IT-infrastructuur. Applicatiebeveiliging is secundair. Daarnaast worden de nodige kwetsbaarheden over het hoofd gezien door de manier waarop software getest wordt.

Hoe groot het probleem is, wordt duidelijk uit het Crash Report van CAST Software. In dit onderzoek werd de veiligheid en kwaliteit van 1.850 business applicaties (in totaal 1,03 miljard regels softwarecode) onder de loep genomen aan de hand van ruim 1.200 architectuur principes voor robuuste en veilige software. Die principes zijn samengesteld uit de input van CWE, OWASP, SANS en US-CERT over veel voorkomende kwetsbaarheden in software die door hackers misbruikt worden voor hun aanvallen. Met gemiddeld 1 op elke 10,5 regels code bleek iets mis. Kijk je alleen naar security, dan is dat 1 op elke 108 regels code. Hoewel security maar een klein deel van de fouten vertegenwoordigt, ligt hier wel de oorzaak van de meeste bedrijfsschade.

Bestaande manier van testen onvoldoende

Hoe kan dat toch? De eerdergenoemde architectuurprincipes zijn openbaar toegankelijk en er zijn voldoende hulpmiddelen beschikbaar die direct bij het inchecken van nieuwe of gewijzigde softwarecode de broncode screenen. Zeker bij bedrijfskritische systemen wordt er bij de bouw serieus aandacht besteed aan het testen van applicaties. En ook het voorkomen van bekende security fouten krijgt de nodige aandacht in het ontwikkelproces.

Desondanks levert het gebruik van deze tools geen garantie op voor foutvrije software. Dat komt doordat de vele controleregels alleen toegepast kunnen worden op een deel van de applicatie en niet op het applicatieportfolio in zijn geheel zoals deze in een productieomgeving draait. De bestaande manieren van testen zijn niet in staat om kwetsbaarheden in de structuur van applicaties en het portfolio bloot te leggen. Ook de meeste code analysetools houden geen rekening met de systeemarchitectuur, waardoor onvolkomenheden in de samenhang tussen verschillende softwarecomponenten over het hoofd gezien worden. Dat is nummer drie op het eerdergenoemde dreigingslijstje van de CSA.

Verantwoordelijkheid

Security krijgt tijdens de ontwikkeling van software op dit moment niet de juiste aandacht. Het gaat dan niet alleen om onvoldoende aandacht. Ook het moment waarop dit gebeurt, is meestal niet goed gekozen. Veilige software wordt veelal gezien als een verantwoordelijkheid van de ontwikkelaar of de leverancier. Door de opdrachtgever worden nog vaak te weinig eisen gesteld op het gebied van Security by Design. Dit leidt ertoe dat zwakheden in de software, systemen of hun inzet in de productieomgeving pas laat aan het licht komen. De aangescherpte regels vanuit de AVG geven organisaties die software toepassen meer verplichtingen om datalekken te voorkomen. Voor het achteraf laten weghalen van kwetsbaarheden betaal je de hoofdprijs.

Het foutvrij maken van software is meestal een van de laatste stappen in het ontwikkelproces. Zo ontstaat een suboptimale situatie, omdat de dreigingen van vandaag nog niet bestonden toen de software werd ontwikkeld. Daarom is Security by Design zo belangrijk, het vanaf het begin secure ontwerpen van het geheel van software en de onderliggende IT-infrastructuur of clouddienst. Alleen dan worden risico’s op het misbruik van kwetsbaarheden geminimaliseerd.

Prioriteiten

Een pragmatisch onderdeel van Security by Design is het principe van een ‘defensible infrastructure’ zoals deze door de cybersecurity experts Joshua Corman en Gene Kim uitgewerkt is in hun model van een ‘security survival piramide’. Schadelijke praktijken van internet worden beschouwd als fact-of-life, niet alleen naar buiten toe, maar ook in de semi-veilige omgeving van een eigen datacenter. Geen enkele gebruikerssessie in een applicatie is te vertrouwen en de software heeft voorzieningen om de schade van misbruik tot een minimum te beperken. De ontwerpprincipes voor de structuur en de code vormen de basis van inherent veilige software. In de Metri whitepaper ‘Een business aanpak van security’ wordt dit principe uitgewerkt.

Business risico

Applicatiebeveiliging is nu hoofdzakelijk een technisch issue, terwijl het vooral aandacht moet krijgen als een business risico. Kwetsbaarheden in de software verhogen de kans dat de bedrijfsvoering wordt lamgelegd. Dit businessrisico kan inzichtelijk worden gemaakt door de structurele kwaliteit van software te relateren aan concrete business eisen zoals prestaties, onderhoudbaarheid, robuustheid en veiligheid. Deze scan rond risico’s voor de bedrijfsvoering is het beste uit te voeren op basis van gangbare industriestandaarden voor de kwaliteit van software, zoals ISO/IEC 25010 of OMG Automated Source Code Security Measure. Deze standaarden geven de scan en de risico’s die het blootlegt een objectief extern kader. Die transparantie stel je idealiter op een zo hoog mogelijk niveau vast. Want een brede scan van de totale broncode in een applicatiestack geeft inzicht in de zwakke punten in de digitale operatie van een organisatie. Een analyse op portfolio niveau legt onvolkomenheden in de samenwerking van de verschillende softwarecomponenten in de applicatiestack vast.

De business case

Hier zit ook een duidelijk verband met de onderbouwing van een eventuele businesscase. Ik zie u namelijk al denken: met dit soort scans van de applicatiestack gaat een nog groter deel van het IT-budget naar beheermaatregelen. Dat hoeft zeker niet het geval te zijn. In het eerder aangehaalde Crash rapport waarin de softwareportfolio’s van in totaal 329 organisaties geanalyseerd werden, werden ruim 97 miljoen overtredingen van architectuurregels ontdekt. Een tiende hiervan had impact op de security van de onderzochte applicaties en een honderdste had impact op de architectuur van de applicaties. Hoewel deze laatste categorie geen directe impact heeft op de security kunnen dit soort onvolkomenheden wel de helft van een onderhoudsbudget opslokken. Een Prio 1 incident brengt in Nederland gemiddeld een kostenpost van 80.000 euro met zich mee. De transparantie in de business risico’s die de scan inzichtelijk wegen al snel op tegen de besparingen door een verminderd aantal incidenten.

Aangezien software steeds meer het concurrerend vermogen van organisatie bepaalt, is het van belang om grip te houden op de veiligheid en kwaliteit van de opgeleverde software. Goed zicht op de structurele kwaliteit van een applicatieportfolio is hierbij cruciaal. Wilt u meer weten wat Metri voor u kan betekenen in deze aanpak van beveiliging van applicatieomgevingen? Kijk dan eens naar de voordelen van een Applicatie Portfolio Health & Risk scan of een Business Impact Assessment.

Kleine moeite, grote winst

IT kost veel geld. Vaak te veel als je het ons vraagt. Overal stijgen de kosten, want, zo is de redenering, alles wordt duurder en de vraag naar IT wordt door de vele veranderingen en vernieuwingen steeds groter. Toch laten veel bedrijven ook ontzettend veel geld liggen, zo blijkt uit onderzoek van Metri. Natuurlijk moet de focus altijd gericht zijn op het verbeteren en behouden van IT-diensten. Maar er zijn ook veel kansen op het besparen van kosten. Metri schotelt u er 10 voor.

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.

(Hoe beheers je) het risico van maatwerk

Voor veel mensen zijn maatwerksoftware en risico’s bijna synoniem. Regelmatig komen er maatwerkprojecten in het nieuws die kampen met grote vertragingen of ernstige budgetoverschrijdingen. Vijf jaar geleden is er zelfs een parlementaire enquete geweest naar ICT-projecten van de Nederlandse overheid. Dit heeft geresulteerd in de oprichting van het Bureau ICT Toetsing voor de Rijksoverheid. Er lijkt nog weinig te veranderen in het beeld dat maatwerksoftware een garantie is voor problemen.

In de dagelijkse praktijk van Metri komen we regelmatig voorbeelden tegen van projecten met maatwerksoftware die in moeilijk vaarwater terecht zijn gekomen. Voor een deel komt dat omdat maatwerksoftware in de regel grotere en complexere projecten oplevert. Maatwerk is nodig om specifieke dienstverlening te automatiseren die organisaties uniek maken of een competitief voordeel geven. Hiervoor zijn per definitie geen standaardoplossingen voorhanden. Maatwerk moet ook veelal integreren met een divers applicatielandschap dat niet altijd even gestandaardiseerd is. Dit brengt meer risico’s met zich mee dan het uitrollen van standaardsoftware voor veel voorkomende bedrijfsprocessen, waar meer sprake is van best practices en standaardisatie.

Een belangrijk deel van de risico’s is vanuit de literatuur wel bekend, maar worden door organisaties onderschat. Hierdoor worden er te weinig of te laat beheersmaatregelen ingezet. Dat is jammer, omdat voor veel van die risico’s passende maatregelen beschikbaar zijn die een groot deel van de risico’s beheersbaar maakt.

Recent heeft een normcommissie van de NEN een praktijkrichtlijn uitgebracht die de Risicobeheersing bij ontwikkeling en onderhoud van maatwerksoftware beschrijft. Deze norm is gratis verkrijgbaar bij de NEN. In deze norm worden de belangrijkste risico’s benoemd en worden de belangrijkste beheersmaatregelen beschreven. Als ieder projectplan voor maatwerksoftware vooraf getoetst wordt aan deze norm, zijn de risico’s van projecten voor de realisatie van maatwerksoftware een stuk beter beheersbaar.

Uiteraard zijn zowel de risico’s als de beheersmaatregelen generiek. Om de risico’s voor maatwerksoftware effectief te verkleinen moeten deze nog wel specifiek gemaakt worden voor ieder maatwerkproject. De praktijkrichtlijn is een goede eerste stap. Behoefte aan hulp bij de vervolgstappen? Wil je meer weten Neem dan even contact met ons op.

IT Intelligence

METRI’s IT Intelligence diensten geven u grip, gebaseerd op objectieve metingen, data, parametrische modellen en internationaal toonaangevende technologieën. METRI consultants helpen daarbij om de metingen om te zetten in daadkracht en hier duiding aan te geven. Grip op de kosten, grip op de productiviteit, grip op de hoeveelheid functionaliteit die geleverd wordt in combinatie met een continue aantoonbare verbetering binnen de teams.

De groeiende risico’s van open source software

Open source is al sinds jaar en dag populair, vooral voor toepassingen als databases, storage, analytics, cloud management tools en in toenemende mate ook security. Hoewel open source vanaf de start juist werd geroemd om het hogere veiligheidsniveau zijn de risico’s door een combinatie van populariteit en een flinke toename van kwetsbaarheden flink gestegen. Het is tijd voor maatregelen.

Open broncode speelt tegenwoordig een belangrijke rol in grote vernieuwingsprojecten zoals digitale-transformatieprojecten. Volgens onderzoek van Red Hat speelt open source bij 40 procent van dit soort grote veranderingstrajecten een aanzienlijke rol. Dat open source serieuze business is geworden waarin grote bedragen omgaan, zie je ook af aan de recente aankoop van Red Hat door IBM. En wat te denken van de acquisitie van GitHub door het concern dat juist op gesloten software zijn succes heeft gebouwd: Microsoft.

Zorgwekkend

Er zit een flinke keerzijde aan de wijdverbreidheid van open source. De uitkomsten van een andere studie door open source security platform Snyk, onder 500 respondenten die verantwoordelijk zijn voor onderhoud van open source software, zijn zorgwekkend. Omdat sommige open source frameworks en applicaties veel in gebruik zijn, zijn ze uitgegroeid tot een aantrekkelijk doelwit voor hackers. Aan aanvalsmogelijkheden geen gebrek. In twee jaar tijd is er een groei van 88 procent waar te nemen in het aantal kwetsbaarheden. En alleen al in 2018 vonden onderzoekers 500 kwetsbaarheden.

Net als bij reguliere software denken veel gebruikers dat de ontwikkelaars security serieus nemen. Maar terwijl een zeer ruime meerderheid van gebruikers van open source verwachten dat ontwikkelaars prioriteit geven aan security in hun softwarecode, denken slechts drie op de tien ontwikkelaars dat ze voldoende kennis hebben van beveiliging. En bijna vier op de tien developers testen dan ook helemaal niet op security gedurende continuous integration (CI). Verbaast het dan nog dat het bij open source gemiddeld meer dan twee jaar duurt voordat een gesignaleerde kwetsbaarheid wordt verholpen?

Uitblijvende patches

Aan de gebruikerskant is het automatisch aanbrengen van patches problematisch. Voor op Windows en Linux gebaseerde applicatielandschappen zijn er tal van volwassen oplossingen voor automatisch patch management voorhanden. In veel gevallen worden deze volledig ondersteund door de softwareleverancier, zodat de window of opportunity voor kwaadwillenden beperkt blijft. Maar voor open source zijn deze oplossingen dun gezaaid, waardoor veel systemen onnodig lang gevaar lopen. Dit komt dus nog bovenop de al eerdergenoemde twee jaar voordat er een oplossing voor een fout opgeleverd wordt.

Zo kon het credit ratings bureau Equifax – en meer dan 140 miljoen argeloze consumenten in de VS, Canada en het VK – in 2017 slachtoffer worden van een van de meest omvangrijke datadiefstallen ooit, door een remote code execution die kon worden ingezet vanwege een ontbrekende patch in Java webapplicatie-software van Apache. Een inbraak die eenvoudig voorkomen had kunnen worden, ware het niet dat de relevante verantwoordelijken bij Equifax even niet zaten op te letten – en al helemaal niet beschikten over een automatische patch-oplossing.

Als de enthousiaste open source community daarom eens één procent van zijn tijd in volwassen patch-oplossingen zou investeren, zou zij die reputatie kunnen hooghouden, ofschoon het genoemde Snyk, dat ontwikkelaars helpt kwetsbaarheden vóór te zijn, zeker een stap in de goede richting is. Dit soort hulpmiddelen zijn onontbeerlijk om adequaat zicht te krijgen op de afhankelijkheden tussen open source softwarebibliotheken en de risico’s die hieruit voortkomen.

Intellectueel eigendom

Ook de onduidelijke intellectuele-eigendomsstructuur van open source is reden tot zorg. Zoals bijna alle software een opeenstapeling is van code afkomstig van diverse bronnen, is dit juist bij open source een complicerende factor. Wie commerciële software afneemt, is met één klik op de gebruikerslicentie van eventueel gedoe bevrijd.

Maar wie er zeker van wilde zijn dat er bij het gebruik van open source geen rechten worden geschonden, moest tot voor kort handmatig allerlei documentatie doorpluizen, omdat open source regelmatig op zogenaamde dual-licensed projects is gebaseerd. Sommige open source licenties verplichten organisaties die deze code voor hun project gebruiken het resultaat te delen met de community door de broncode openbaar te maken.

Broncode scannen

Als een organisatie voor een belangrijk deel gebruik maakt van open source software is het verstandig om met een scan van de broncode veiligheidsrisico’s in kaart te brengen. Frequente inzet van software composition analysis (SCA) kan hier een oplossing voor zijn. Daarmee verzeker je je ervan dat software die in ontwikkeling is of reeds wordt gebruikt, voldoet aan beveiligingsstandaarden, juridische vereisten én regulering.

METRI heeft in samenwerking met partner Cast een dienst ontwikkeld, die gebruik maakt van het product Cast Highlight. Deze SaaS-oplossing voert een scan van de broncode uit op applicaties die op open source gebaseerd zijn. De tool scant de werkelijke bron van de software die in gebruik is, en kijkt daarbij zowel naar compliance, kwetsbaarheden en verouderde code door de code te vergelijken met een enorme database van meer dan 20 miljoen open source componenten en 3 miljard file fingerprints.

Met deze informatie en check kan open source op een verantwoorde wijze een belangrijke rol blijven spelen in de vernieuwing van IT en digitalisering van de business.

Meer informatie over deze dienst en Cast Highlight.

Opheffen BIT is risico maar ook een kans voor Rijks IT

Cloudkosten Metri

Er komt vooralsnog geen verlenging voor het Bureau ICT-Toetsing (BIT), die in opdracht van de Tweede Kamer, grote rijksbrede IT-projecten vooraf en tijdens de looptijd controleert. De kennis en ervaring wordt de komende twee jaar overgebracht naar de CIO Offices van ministeries zelf. Deze vrijblijvende verplaatsing van de controlefunctie lijkt op het eerste gezicht desastreus. Tegelijkertijd biedt het ook tal van nieuwe kansen voor versteviging van grootschalige IT-programma’s bij de rijksoverheid.

De positie van BIT als waakhond, die grote lopende en nieuwe projecten op onafhankelijke wijze screent, krijgt geen verlenging. Dat blijkt uit de ‘Strategische I-agenda Rijksdienst 2019-2021’ die minister Kasja Ollongren van BZK enkele weken terug naar de Tweede Kamer stuurde. Op zich is dit geen verrassende ingreep. Vanaf de start was bepaald dat BIT een tijdelijke organisatie is. Toch heeft deze bijna terloopse opmerking veel stof doen opwaaien, en terecht.

Gouden greep

Want het was destijds een gouden greep om een derde lijn van controle toe te voegen met als enige belang de Tweede Kamer te informeren hoe grote IT-projecten werkelijk verlopen. Het was de belangrijkste aanbeveling van de commissie Elias vijf jaar terug. BIT zou tussen de 5 en 7 jaar nodig hebben om een cultuuromslag te bewerkstelligen in de opzet en aansturing van grote Rijks IT-programma’s. Meerdere onderzoeken van BIT toonden aan dat zelfs tweede lijn controles van onafhankelijke externe adviesbureaus lang niet altijd de faalfactoren van projecten boven water kregen. Zowel in vraagstelling als in de antwoorden daarop bleven in dit soort onderzoeken tal van kritische vragen onderbelicht. Er is een levensgroot risico dat de praktijk van op feiten gebaseerde en onafhankelijke feedback zoals het BIT dat doet sterk verwatert als het ondergebracht wordt bij departementale CIO offices.

Als de onderzoeken van het BIT iets duidelijk hebben gemaakt, dan is het wel dat onafhankelijk kijken naar ICT-projecten van doorslaggevend belang is voor de slagingskans. Het verschil tussen succesvolle en falende ICT-projecten zit hem erin dat in de eerste lijn, bij het programmamanagement zelf, voldoende controlemechanismes aanwezig zijn om op basis van feiten programma’s bij te sturen. Die zijn er nu vaak niet. Veelal heeft een externe leverancier onder aansturing van een ingehuurde projectmanager een te grote vrijbrief om het functioneren van een programma te beoordelen. Beiden hebben een te groot belang bij het doorgaan van het project om onafhankelijk naar de faalfactoren te kijken. Want vergis je niet: voor flink bijsturen heb je een kritische blik nodig en de nodige moed. Een voorbeeld waar het advies van BIT deze effecten had was het schrappen van het Multi Regelingen Systeem van de SVB. Een falend nieuw systeem werd niet in productie genomen en de ontwikkeling gestaakt. In plaats daarvan werd er teruggevallen op de bestaande, bewezen functionerende systemen. Is het te verwachten dat de onafhankelijke kijk vanuit een opdrachtgever zelf komt in plaats van een onafhankelijk opererende waakhond.?

Basis op orde

Die kans wordt een stuk groter als de CIO offices vanuit een gezamenlijke basis gaan werken, waarbij tot op detailniveau gestandaardiseerde meetinformatie aanwezig is over productiviteit, kwaliteit en voortgang van programma’s. Succesvolle projecten hebben met elkaar gemeen dat er veel aandacht is voor de betrouwbaarheid van het systeem. Eén van de verdiensten van het BIT is dat ICT-projecten kleiner worden. Hierdoor veranderen de systemen op een meer gecontroleerde manier en blijft de betrouwbaarheid beter gewaarborgd. Maar het echt kijken naar de betrouwbaarheid van de code van systemen is nog geen gemeengoed. Bij software betekent dit dat je specialisten naar de code van applicaties laat kijken. De klantorganisaties, die deze moeite nemen, hebben een aanzienlijk grotere kans op goed werkende, samenhangende en robuuste ICT, blijkt regelmatig uit de adviespraktijk van Metri die dit soort controles veelvuldig uitvoert.

We staan niet alleen in deze mening. Professor Chris Verhoef, hoogleraar informatiesystemen aan de VU, waarschuwde voor een terugval als BIT als onafhankelijke waakhond opgeheven wordt. Toen hij de Tweede Kamer recent adviseerde over dit voorgenomen besluit, onderstreepte hij de zegeningen van een orgaan dat feitelijk en onomfloerst het parlement informeert over de risico’s van overheids IT-investeringen. Ook Verhoef noemde de transparantie op detailniveau waar BIT regelmatig op hamerde van levensbelang om de geformuleerde doelstellingen van betrouwbare, goedwerkende en samenhangende ICT voor elkaar te krijgen. Als je het aantal defecten in een applicatie per tijdseenheid consequent meet, krijg je een goed beeld van de betrouwbaarheid van het systeem en de risico’s die in deze applicatie zitten.

Juist door gedetailleerd te kijken in een breed aantal programma’s kunnen rijksoverheden leren van hun fouten en de juiste dingen doen om de betrouwbaarheid van software en data te verbeteren. Die kennis en kunde zou geborgd moeten zijn. De transparantie waar BIT regelmatig voor pleitte is juist op detailniveau van levensbelang om de geformuleerde doelstellingen van betrouwbare, goedwerkende en samenhangende ICT voor elkaar te krijgen. Dit moet doorlopend gebeuren en op een methodische manier die idealiter breed gedeeld wordt binnen de rijksoverheid.

Deskundigheid

Zo’n centrale en gedeelde aanpak van het portfoliomanagement is niet terug te vinden in de strategische I-agenda van de rijksoverheid. De deskundigheid die nu binnen en rondom het BIT wordt opgebouwd, kun je en moet je niet willen verdelen over dertien departementen. Het gaat om specialistische kennis die slecht past bij het profiel van de gemiddelde CIO offices die juist drijven op mensen met een meer generalistische insteek. Bovendien zullen de specialisten hun heil elders gaan zoeken als wordt aangekondigd dat hun werk voor het BIT eindig is. En dat is ontzettend jammer en een groot risico voor de rijksoverheid. De kennis en ervaring die BIT heeft opgedaan is uniek. Dat mochten we vorig jaar zelf ervaren toen het BIT tijdens een congres van het standaardisatie intiatief voor softwaremetrieken Nesma hun bevindingen deelde over het lerende vermogen van de Rijks ICT. Hun analyse was pittig en ambitieus zoals uit dit puntenlijstje blijkt:

  1. Bepaal een helder en gedragen doel. Wie veertig jaar geleden bedrijfskunde studeerde, leerde toen al dat dat belangrijk is. En toch blijkt dat in de praktijk lastig te bereiken;
  2. Kies een realistische aanpak. Hier wordt – echt waar – nog te weinig naar gekeken. Experimenteer klein en tuig pas een groot project op bij een bewezen aanpak. Deze methode van stapsgewijs ontwikkelen is een van de leerpunten die nu in de praktijk gebracht wordt;
  3. Zorg voor voldoende resources en een goede voortgangsbewaking. Dankzij het BIT heeft er op die bewaking een flinke verbeterslag plaatsgevonden. Dat smaakt naar meer;
  4. Zorg voor een goede krachtsverhouding met externe leveranciers. Hier is nog veel werk te doen, omdat veel opdrachtgevers niet voldoende professioneel omgaan met hun demand rol;
  5. Wees je bewust van de huidige status van het IT-landschap van een organisaties. Bedrijven worstelen al heel lang met hun IT-legacy en dat is voor een belangrijk deel onnodig want er zijn bewezen goede oplossingen voor dit issue;
  6. Wees geen one trick pony maar neem verschillende scenario’s in overweging. Dankzij het BIT zien we dit gelukkig wel steeds vaker gebeuren. Zorg voor een plan B voor als er zaken misgaan. Veel grote veranderprogramma’s zijn zeer gebaat bij dit soort realisme.

Cultuuromslag

Het zal nog zeker een generatie duren voordat de ICT-cultuuromslag waar de commissie Elias op hoopte een feit is, voorspelde de eerder aangehaalde professor Verhoef tijdens de commissievergadering. Hij heeft gelijk. Het BIT voortijdig opheffen gaat zeker niet helpen in het maken van die mentaliteits- en gedragsverandering. Toch is er ook bij deze beleidswijziging wel een kans om zaken die door BIT geagendeerd zijn te verbeteren en een logisch vervolg te geven. Zo ligt het voor de hand om de plannen en begrotingen van IT-projecten op realisme te checken. Ook dit soort kennis en kunde zou een nieuwe vorm kunnen krijgen als een basis controlemechanisme in de eerste lijn als onderdeel van het portfoliomanagement. Onze collega Harold van Heeringen behandelt binnenkort in een andere blog de mogelijkheden van Software Cost Estimation om begrotingen van grote programma’s realistisch in te schatten en projectrisico’s te verkleinen.