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

Datum: 26 januari 2023

Tijd: 16.00-16.45

Locatie: online via Zoom

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

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

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

Aanmelden voor Webinar Procurement 26 januari

Het belang van Performance Measurement

Dit rapport is het resultaat van het afstudeeronderzoek van Jelle Snijder in samenwerking met Metri, de organisatie die hem heeft begeleid bij dit onderzoek. De titel van de thesis is: “A reconceptualization of uncertainty in enterprise-wide IT-projects to understand its challenges and responses”.

Grote IT-projecten gaan nog steeds vaak mis. Uit recent onderzoek is gebleken dat slechts 5% van de grote IT-projecten succesvol zijn in termen van kwaliteit, budget en tijd. Een belangrijke reden voor dit falen kan worden herleid tot de hoge mate vanonzekerheid waarmee dit soort projecten vaak te maken hebben, denk hierbij aan omgevings- en milieu onzekerheid, politieke onzekerheid, economische onzekerheid of aan de opkomst van nieuwe technologieën. Bovendien neemt de mate van onzekerheid alleen maar toe in het huidige turbulente business klimaat en een wereld waar pandemieën en klimaatproblematiek het speelveld domineren.

Dat deze onzekerheden niet helemaal nieuw zijn, blijkt uit de transitie die gaande is naar agile manieren van werken. Waar men voorheen in een waterval approach lineair toewerkte naar het eindproduct, acht de agile methodiek het accepteren vanwijzigingen belangrijker dan het strikt volgen van een plan waarmee het inspeelt op veranderende requirements. Dit is een aspect dat hoort bij het omgaan met onzekerheid, maar het schiet nog tekort in het overzien van de daadwerkelijke consequenties van deze veranderingen op de organisatie en het managen hiervandoor de decision makers.

Zeven vooraanstaande bedrijven uit de Nederlandse markt hebben deelgenomen in een multiple case studie om onzekerheid opnieuw te conceptualiseren om zo een beter begrip te krijgen van de uitdagingen en reacties in grote IT-projecten. Hierbij is een model gebruikt dat naar onzekerheid kijkt op drie niveaus: Als eerste de state uncertainty wat gaat om het onvermogen om veranderende elementen uit de business omgeving te voorspellen, als tweede de effect uncertainty wat het onvermogen om de invloed die deze veranderende elementen uit de businessomgeving hebben op de organisatie te voorspellen omvat en als derde de response uncertainty waarbij het gaat om het uitblijven van inzichten in hoe te reageren op de veranderende elementen uit de business omgeving en wat de consequenties zijn vandeze reacties.

In dit onderzoek beschrijven we de manier waarop we zien dat de markt omgaat met onzekerheid en hoe dit verbeterd kan worden door middel van het invoeren van performance measurement technieken.

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.

Accelerate software value creation by hyperautomated requirements analysis.

Metri - Scopemaster

Benchmarking and consultancy organization Metri and ScopeMaster® technologies have entered into a exclusive collaboration for the Dutch market. Companies that are seeking to reduce risk on large projects, and cheaper, better, faster software development, can now benefit from the combined experience and wisdom of Metri and the hyperautomation of requirements analysis and measurement from ScopeMaster. According to Colin Hammond, CEO of ScopeMaster: 

“We are delighted to have signed this agreement with Metri. Metri has a philosophy we share about driving transparency and measurement in IT work.

Metri also has an excellent background as software measurement experts. We look forward to working together to improve Metri’s capability and bring more transparency to IT work, especially for organizations in the Netherlands that want to use the power of ScopeMaster® to determine software size and quality of requirements at an early stage of the development cycle.”

Colin Hammond

Recent research by Accenture shows that 35% of production disruptions originate from incomplete or unclear requirements. Finding and repairing defects in the User Stories as early as possible therefore saves a lot of money and effort. ScopeMaster is a SaaS solution that measures the quality of User Stories fully automatically. ScopeMaster is the winner of the Computing DevOps Excellence 2020 award.

Scientific research has shown that this significantly improves the predictability of agile teams compared to the usual Story Points. Metri also uses the measured size in its Cost Estimation and Agile Team Performance studies.

According to Harold van Heeringen, Principal Consultant IT Intelligence services at Metri, the partnership offers Metri the opportunity to deliver even more value.

“In addition to the automated measurement of team performance, we also help the teams to improve in a targeted manner. In this way we help our customers to maximize the delivered business value for the spent budget and we also ensure a predictable and the lowest possible Total Cost of Ownership of the applications ”.

Harold van Heeringen

De kosten van slechte softwarekwaliteit

Quality Software

Onlangs kwam het rapport ‘The Cost of Poor Software Quality in the USA 2020’ onder mijn aandacht, en ik was er behoorlijk onder de indruk van. Daarin staat dat organisaties tegenwoordig worstelen met de balans tussen snelheid van ontwikkeling en de kwaliteit van de applicaties en het onderhoud ervan. Omdat softwarekwaliteit vaak wordt beschouwd als ‘impliciet OK’, of ‘moet goed zijn omdat we alle bugs die we in al onze tests hebben gevonden hebben verwijderd’, wordt softwarekwaliteit en het effect ervan op de kosten voor onderhoud in de praktijk niet op grote schaal gemeten.

Het rapport toont aan dat de kosten van slechte software kwaliteit in de VS meer dan 2 biljoen dollar is. De meeste van deze kosten zijn gerelateerd aan productie-incidenten en het verlies van business als gevolg daarvan. Echter, daarnaast wordt 260 miljard US Dollar besteed aan mislukte IT-projecten. In de meeste gevallen is er onvoldoende aandacht voor kwaliteit en vaak worden deze projecten ook te optimistisch geschat.

Hoewel de bedragen in Nederland gelukkig veel lager liggen, worden dezelfde uitdagingen geconfronteerd als in de VS. Veel organisaties hebben een agile manier van werken gekozen, waarbij er de focus ligt op het zo snel mogelijk leveren van de meeste bedrijfswaarde. Het kwaliteitsaspect wordt vaak gedekt door tests en ontwikkelaarstools die op codeniveau meten, zoals bijvoorbeeld het veelgebruikte SonarQube. Dit zijn goede maatregelen, maar meestal niet voldoende. Het is belangrijk om te meten op systeemniveau, waarbij alle verbindingen tussen componenten, modules en lagen worden geanalyseerd. Bij Metri gebruiken we technologie om de kwaliteit van software op systeemniveau objectief te meten, tegen alle internationale normen en best practices. We rapporteren dit op managementniveau en bieden bruikbare inzichten aan ontwikkelaars: waar in de code kritische schendingen worden ontdekt, waarom dit kritieke schendingen zijn (met referentie naar de betreffende standaard of best practice) en vaak ook hoe deze op te lossen. Op deze manier kan het management inzicht krijgen in de trends in kwaliteit en bijbehorende risico’s en kunnen ontwikkelaars de code op een systematische en gerichte manier verbeteren, waardoor de systeemkwaliteit wordt verhoogd tegen weinig mogelijk inspanning.

De algemene aanbevelingen van het Consortium for IT Software Quality (CISQ) voor 2021 en daarna blijven de nadruk leggen op preventie. De beste aanpak is om zwakke punten en kwetsbaarheden in software zo snel mogelijk te detecteren en te corrigeren, bij voorkeur daar waar ze zijn geïnjecteerd, om de aangerichte schade en kosten voor het repareren te beperken. Meer specifiek  worden de volgende aanbevelingen gedaan voor softwareontwikkelingsorganisaties:

  • Vermijd ontwikkeling standaarden van lage kwaliteit en pas veilige coderingsstandaarden toe.
  • Erken de inherente moeilijkheden van het ontwikkelen van software en gebruik effectieve tools om te helpen omgaan met deze problemen.
  • Zorg voor een vroege en perdiodieke analyse van de ontwikkelde broncode om kritieke schendingen, zwakke punten en kwetsbaarheden vroegtijdig op te sporen.
  • Meet structurele kwaliteitskenmerken, zoals Robuustheid, Efficiency, Security, Onderhoudbaarheid en Overdraagbaarheid.
  • Focus op de evaluatie van opgenomen componenten (bijvoorbeeld open source) en platforms die onbekende zwakke punten of kwetsbaarheden kunnen hebben.
  • Verkrijg meer informatie over de typische kwetsbaarheden en misbruikbare zwakke punten die zijn toe te schrijven aan bepaalde programmeertalen.
  • Gebruik de best practices voor het beheer van een legacy-systeem – vooral als het gaat om het kennismanagement van hoe het systeem intern werkt. Benchmarking van de software risico’s en kwaliteit is een goede plek om te beginnen.
  • Vermijd mislukte projecten door deze professioneel te begroten door gecertificeerde Software Cost Estimators.
  • Besteed aandacht aan gedefinieerde kwaliteitsdoelstellingen en meet deze doelstellingen gedurende de hele levenscyclus van het project.
  • Investeer slim in verbeteringen in de kwaliteit van de software op basis van CPSQ-nummers.
  • Focus op de verschillende resultaten van goede versus slechte softwarekwaliteit in uw organisatie  en relevante benchmarkorganisaties. Door te proberen CPSQ te verbeteren, zullen andere economische doelgebieden worden beïnvloed, bijvoorbeeld eigendomskosten, winstgevendheid, menselijke prestatieniveaus, innovatievermogen en de effectiviteit van uw bedrijfskritieke IT-systemen.

Het klinkt misschien ongelofelijk, maar de diensten die Metri biedt als onderdeel van haar IT Intelligence propositie dekken eigenlijk al deze aanbevelingen.

Het is interessant om te zien dat CISQ een factor 5 tot 10 verschil ziet tussen goed presterende teams en slecht presterende teams, vergelijkbaar met de resultaten die Metri ook waarneemt in de Agile Team Performance Monitor studies die we hebben uitgevoerd. CISQ analyseerde de verschillen tussen de top 10% performers en de onderste 10% organisaties die ze bestudeerden. Wanneer u dieper in de gegevens graaft, is de duidelijke reden de toepassing van bepaalde kwaliteit en proces best practices.  

De belangrijkste enablers voor het bereiken van de beste kosten, planning en kwaliteitsprestaties zijn:

  1. Een goed gedefinieerd, maar aanpasbaar ontwikkelingsproces
  2. Uitstekende begrotingsmethoden (zie de Metri Cost Estimation suite: link)
  3. Projectmanagement discipline
  4. Uitstekende medewerker vaardigheidsniveaus
  5. Kwaliteitsvisie
  6. Focus op klanttevredenheid
  7. TQM managementcultuur
  8. Foutpreventie
  9. Voortgang en kwaliteit meten

Metri helpt haar klanten bij het implementeren van deze key enablers, terwijl ze verbeteringen en de voordelen meet. In bijna elke organisatie zal een verhoogde focus op kwaliteit resulteren in een lagere Total Cost of Ownership, vooral wanneer softwarefouten op een gerichte en kostenefficiënte manier worden opgelost.

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.

De kosten meten van change versus run binnen agile teams

Bron: Harold van Heeringen (Metri) en AGconnect

De meeste CIO’s hebben de opdracht om zo veel mogelijk business value te leveren, via IT, tegen zo laag mogelijke kosten. De vraag dient zich dan aan: hoe meten we business value en over welke kosten hebben we het dan? Business value is een zeer lastig te meten concept, volgens velen zelfs onmeetbaar. Daar zijn gestandaardiseerde methodes voor. Harold van Heeringen wijst er echter op dat niet alleen de functionaliteit die wordt opgeleverd bepalend is voor de business value, maar dat de kwaliteit daarvan ook zeer sterkt meetelt in deze metingen.

Over het algemeen is men het er wel over eens dat het ontwikkelen, wijzigen en/of verwijderen van softwarefunctionaliteit in ieder geval een belangrijk onderdeel van het creëren van business value is, mits de gevraagde en geleverde functionaliteit daadwerkelijk waarde oplevert voor het bedrijf. De ontwikkelkosten bestaan onder andere uit werkplekken en ontwikkeltoollicenties, maar vooral ook uit de bestede uren van mensen. Hoewel het zeker interessant is om bijvoorbeeld via een benchmark te besparen op werkplekken en licenties, focust dit artikel zich vooral op de bestede mensuren.

‘Vroeger’ werden er projecten opgestart om softwarefunctionaliteit te ontwikkelen, tegenwoordig zijn het vaak de agile werkende teams die aan een product werken en die periodiek een werkende versie van het product ter beschikking stellen aan de gebruikers. Je zou kunnen stellen dat hoe meer nieuwe en gewijzigde functionaliteit in een softwareproduct wordt verwerkt, hoe meer waarde dit zou moeten hebben voor de organisatie. De vraag is dan: hoe productief zijn de teams?

Productiviteit

Productiviteit is een kengetal waarmee de verhouding tussen inspanningen en resultaten inzichtelijk wordt gemaakt. De universele definitie is output gedeeld door de input. In softwareontwikkeling is dit bijvoorbeeld een aantal eenheden geproduceerde software gedeeld door een aantal uren inspanning.

In veel industrieën is dit een van de belangrijkste stuurmetrieken. In de IT weet men echter meestal niet hoe productiviteit objectief en gestandaardiseerd gemeten kan worden. Men wil het vaak wel, maar weet niet hoe. De reden hiervoor is dat het vaak relatief eenvoudig is de input te meten van de teams: de uren die worden besteed aan de verschillende activiteiten. Het wordt echter als moeilijk beschouwd om de output van softwareontwikkeling te meten op een gestandaardiseerde, objectieve manier.

Veel organisaties denken dat de output van agile teams gemeten kan worden in story points. Story points zijn een superhandig middel en nuttig voor het team, maar het betreft een subjectieve maat om een groepsinschatting te maken voor de hoeveelheid uren die nodig zijn. Metrieken gebaseerd op story points kunnen daarom niet buiten het team worden gebruikt om te schatten of om de productiviteit te meten. Zonder een gestandaardiseerde outputmetriek is vergelijken moeilijk.

Lastig maar belangrijk

Productiviteit is daarom in veel organisaties lastig te meten over de teams heen. Veel CxO’s hebben geen idee wat de productiviteit is van hun teams en hoe deze zich verhoudt met de markt. Maar de productiviteit bepaalt wel voor een groot deel de business value die geleverd kan worden, gegeven een bepaald budget. Het meten, vergelijken en verbeteren van de productiviteit van de teams is daarom een zeer belangrijke managementtaak.

Met formal-sizingtechnieken kan de functionele output van teams worden vastgesteld volgens ISO-gecertificeerde methoden, zodat teams onderling en met de markt vergeleken kunnen worden. Deze methode is al decennialang in gebruik en er zijn inmiddels veel data beschikbaar van gestandaardiseerde productiviteitscijfers in vrijwel alle technologieën. De standaard agile team performance metrics die worden gemeten en gebenchmarkt, zijn gebaseerd op de gerealiseerde functionele omvang: productiviteit, cost efficiency, delivery speed en sprint quality.

Metri Business Value

Business value

In de praktijk bevat het werk van agile teams meer dan het ontwikkelen van functionaliteit. In de bovenstaande figuur wordt duidelijk dat in de eerste sprint nog volop aan de functionaliteit kan worden gebouwd, maar dat naarmate er meer sprints zijn uitgevoerd, ook andere werkzaamheden de kop opsteken: de rode blokken. Daar waar de blauwe blokken te maken hebben met het creëren van businesswaarde, zijn de rode blokken weliswaar belangrijk, maar leveren deze niet direct zichtbare business value op.

Als er bijvoorbeeld een hoge-prioriteitincident optreedt door een probleem in de code, dan moet die code snel gerepareerd worden. De business vindt echter dat het incident nooit had mogen voorkomen. Onafhankelijk van de mate van volwassenheid van het team geldt dat hoe meer rode blokken er zijn en hoe groter deze rode blokken zijn, hoe lager de productiviteit is en hoe minder zichtbare business value geleverd kan worden. Er is echter een uitzondering hierop.

Kwaliteit

Bovenstaande figuur laat zien dat ook de kwaliteit van de applicatie belangrijk is. Een hoge productiviteit gaat soms ook gepaard met een steeds lager wordende kwaliteit van de applicatie, soms tot een punt waar in een of meerdere sprints moet worden gewerkt om de onderhoudbaarheid weer op peil te brengen. Binnen onze Agile Team Performance Monitor (ATPM)-metingen zien we dit vaak terug. We meten de kwaliteit van de software op de aspecten onderhoudbaarheid, robuustheid, security, efficiency en overdraagbaarheid tegen alle gangbare internationale standaarden en best practices. Het gericht verbeteren van de kwaliteit leidt tot minder verstoringen en snellere oplostijden. Door te focussen op de juiste code refactoring, en dan met name gericht op de onderhoudbaarheid, wordt dat rode blok mogelijk tijdelijk wat groter, maar vervolgens worden de andere rode blokken kleiner, terwijl de blauwe blokken groter worden bij gelijk bestede uren. Het gericht oplossen van technical debt lijkt dus in eerste instantie uren te kosten die ten koste gaan van de doorontwikkeling, maar uiteindelijk zien we in onze onderzoeken dat dit uiteindelijk veel oplevert: meer business value voor hetzelfde budget, minder verstoringen, lagere runkosten en uiteindelijk meer tevreden gebruikers en medewerkers.

Een praktijkvoorbeeld van twee teams 

Het standaardteam waarin geen extra aandacht is voor technical debt management, realiseert bij gelijkblijvende productiviteit minder functionaliteit door de tijd heen, omdat er steeds meer tijd besteed wordt aan het oplossen van issues. Het team dat voldoende tijd besteedt aan het voorkomen van deze issues, wordt productiever en levert uiteindelijk meer business value, terwijl het aantal verstoringen lager is.

De change-versus-run-kostenbalans binnen agile teams is dus sterk afhankelijk van de kwaliteit van de applicatie. Het gericht verbeteren of in stand houden van de kwaliteit lijkt counterproductief, maar levert uiteindelijk de meeste business value.

Meer weten?

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

Metri gaat partnership aan met begrotingsguru Galorath

Metri Galorath

IT adviesbureau Metri is een exclusieve partnership aangegaan met de wereldwijd toonaangevende leverancier van begrotingssoftware Galorath. Metri, van oudsher bekend om haar onafhankelijke IT benchmarking en IT sourcing dienstverlening, is in snel tempo haar IT Intelligence dienstverlening aan het uitbreiden. Volgens Harold van Heeringen is het partnership met Galorath het ontbrekende puzzelstukje waarmee de dienstverlening binnen de Estimation Suite nu compleet is.

Dankzij deze samenwerking worden de IT projectbegrotingen feitelijk gemaakt met minder onzekerheden. Veel klanten kijken terug op succesvolle programma’s dankzij onze langjarige samenwerking. Ik ben trots dat we deze diensten exclusief aan IT Nederland blijven bieden.
– Sergej Berendsen, Algemeen directeur Metri

Veel organisaties beseffen het niet, maar het nauwkeurig begroten van software realisatieprojecten is extreem belangrijk, zeker ook in de agile wereld, en verhoogt het succespercentage van projecten enorm. Hierbij gaat het om vragen als ‘Hoeveel functionaliteit is er klaar per team op bijvoorbeeld 31 december?’ of ‘Hoeveel mensen moet ik in de teams zetten om de doelen te bereiken en wat kost dat?’ Gecertificeerde Metri consultants kwantificeren de requirements en geven onderbouwd antwoord op dit soort vragen, uiteraard met gebruik van de Galorath tooling en de Metri database met de data van tienduizenden projecten, releases en sprints.

De Metri IT Intelligence dienstverlening bestaat nu uit 4 suites met onderliggende diensten:

Metri helpt haar klanten met de meeste waarde uit hun IT te halen, altijd fact-based en gebaseerd op internationale standaarden, data en best practices.

Het onzichtbare gevaar van open Source!

Open Source

Vrijwel alle software bevat tegenwoordig open source componenten. Sommige onderzoeken rapporteren dat meer dan 95% van de applicaties één of meerdere open source componenten heeft. Superhandig natuurlijk, maar dit komt wel met een prijs. En die prijs kan heel hoog zijn! De risico’s zitten met name in de licentie waaronder de component gebruikt mag worden en in zogenaamde ‘vulnerabilities’ die mogelijk in de versie van de component zitten, bijvoorbeeld met betrekking tot security.

Licenties en kwetsbaarheden

Er zijn twee soorten open source licenties: ‘permissive’ licenties en ‘copy-left’ licenties. Permissive licenties bieden geen enkele zekerheid over kwaliteit. Deze kunnen worden gebruikt op eigen risico en bieden ‘garantie tot de deur’. Hierbij moet alleen een statement worden gedaan dat de component wordt gebruikt. We zien vaak dat de kwaliteit van deze componenten laag is, en dat er tal van ’vulnerabilities’ inzitten, bijvoorbeeld als er wordt getoetst tegen de Common Vulnerabilities & Exposures (CVE’s) in de National Vulnerability Database die door het ‘National Institute of Standards and Technology (NIST)’ wordt bijgehouden in de USA. Voorbeelden van dit soort licenties zijn de Apache (b.v. Kubernetes en Swift) en MIT (b.v. Angular.js, .Net Core, JQuery) licenties. In deze licenties zitten de risico’s vooral in de vulnerabilities. Vaak worden de open source componenten wel geüpdate door de tijd heen, waarbij de kwetsbaarheden worden verminderd, maar het is geen automatisme dat de ontwikkel- en beheerteams in organisaties dit monitoren en ook een upgrade uitvoeren als er een nieuwe versie beschikbaar is. Het resultaat is dat er vele stukken sterk verouderde open source code in de meeste applicatie landschappen verborgen zit, soms vol met risico’s, waar vrijwel niemand iets van weet, maar die enorme gevolgen kunnen hebben voor de organisatie. Zeker als het bedrijfskritische systemen betreft.

Daarnaast zijn er de ‘Copy-left’ licenties. Deze licenties zijn strenger en verplichten om alle wijzigingen die worden aangebracht ter beschikking te stellen aan de community. Een strenge variant is de GNU-GPL licentie. Als de gebruiker open source componenten onder deze licentie gebruiken in hun eigen source code, worden ze verplicht de gehele source code met de community te delen. Een bekend voorbeeld hiervan is Linux. Hoewel er in componenten onder deze licentie ook risico’s zitten, zeker bij wat oudere versies, zit hier ook een groot risico in de licentie voorwaarden. Vaak is de maatwerk software Intellectual Property van de organisatie die het heeft ontwikkeld of van de organisatie die hier opdracht voor heeft gegeven. Met name kritische systemen zijn extreem belangrijk voor organisaties en ze willen niet dat anderen de broncode kunnen inzien, of zelfs gebruiken. Dit kan een directe impact hebben op de concurrentiepositie immers. Iedereen in de community kan een audit doen of de voorwaarden worden nageleefd, dus deze licenties zijn echt een groot gevaar. Er zijn zelfs organisaties die als doel hebben om bedrijven op te sporen die zich niet aan de voorwaarden houden. Deze spannen dan rechtszaken aan om de voorwaarden af te dwingen.

Kortom, het gebruik van Open Source componenten lijkt handig, maar kan voor reële gevaren zorgen. Metri helpt organisaties om zeer snel een compleet inzicht te krijgen van de gebruikte open source componenten, de licenties, de versies (gebruikte en beschikbare) en de Common Vulnerabilities & Exposures die in de gebruikte versies zitten. Hiertoe gebruiken we een Portfolio Health & Risk scan, waarbij met behulp van een SaaS technologie een scan van alle applicaties in het portfolio wordt uitgevoerd. Dit kan binnen enkele dagen en uw code verlaat de organisatie niet! Zo krijgt u razendsnel een compleet inzicht in de onzichtbare gevaren in uw portfolio en kunnen snel gerichte acties worden ondernomen om deze te verminderen.

Metri open source

Per component wordt ook de complete project tijdslijn getoond, met daarbij de huidige versie en alle andere beschikbare versies, met daarbij de licenties en de bekende vulnerabilities. Zie bijvoorbeeld het volgende screenshot.

Dit inzicht maakt het voor uw ontwikkelaars en beheerders mogelijk om snel en gericht verbeteringen door te voeren en de risico’s te verminderen.

Voorkom dat het onzichtbare gevaar van de door u gebruikte open source componenten uw business in gevaar brengt!

Besparen op IT kosten: 10 tips van Metri

Wie wil er nu overbodige kosten? Niemand. Toch worden ze bij vele bedrijven gemaakt. Terwijl besparen makkelijker is dan u denkt, als je het in één keer goed aanpakt met de juiste partijen aan tafel. En dan gaat het soms maar om een uur werk per dag en voor je het weet heb je een maandelijks overschot van soms duizenden euro’s gerealiseerd. Dat is snel verdiend. Metri helpt je graag op weg naar een gezonder uitgavepatroon en een enorme besparing op de IT-kosten, zodat er ook nog eens gespaard kan worden of nieuwe investeringen gedaan kunnen worden. Kortom: aan de slag!

Webinar: Bouw snel uw roadmap voor digitale transformatie, gebaseerd op feiten!

Veel organisaties willen een digitale transformatie opstarten, maar weten niet goed waar te beginnen. Er is geen duidelijk overzicht op het applicatie portfolio en het is erg moelijk te bepalen wat te doen met welke applicatie. Het opbouwen van dit overzicht kost veel tijd en moeite, en is vaak gebaseerd op subjectieve meningen en niet op feiten. In dit webinar laat Metri zien hoe haar Application Portfolio Strategizer dienst in zeer korte tijd een op feiten onderbouwd inzicht krijgt in de kwaliteit, business impact, cloud readiness en de aan te bevelen transformatie strategie per applicatie. Dit levert veel tijdwinst op en zorgt ervoor dat organisaties veel sneller de vruchten van de digitale transformatie kunnen plukken en daarmee succesvoller kunnen zijn.

Meer weten?

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

De revival van de functiepunt

Metri

Ik spreek met veel CIO’s en IT managers en ik merk dat veel van hen worstelen in dit ‘Agile’ tijdperk. Vaak hebben ze een groot aantal (zelfsturende) agile teams, en ontbreekt het hen aan grip. Als het om software ontwikkeling gaat bijvoorbeeld, hebben ze vaak geen idee welke functionaliteit er op welk moment klaar is, hoeveel dat dan werkelijk gekost heeft, wat de kwaliteit is en wat de risico’s zijn die de organisatie loopt met iedere nieuwe oplevering van software in het portfolio. Hoe groter het aantal teams, en hoe meer zelfsturend deze zijn, hoe moeilijker het wordt om het overzicht te houden. De teams werken vaak met door henzelf gedefinieerde Story Points om hun inschattingen te maken. Erg nuttig op teamniveau, maar het management heeft niets aan story point metrics, aangezien deze niet gestandaardiseerd zijn en niet gebruikt kunnen worden om teams te vergelijken.

Echte Agilisten zeggen misschien: “Dat hoort erbij, vertrouw op de teams”, maar de ‘echte wereld’ kent principes als accountability. Er gaat erg veel geld om in software ontwikkeling en beheer teams en er zijn mensen verantwoordelijk voor de juiste besteding van de budgetten, en hetgeen wat daarvoor wordt geleverd. Sterker nog, het snel kunnen leveren van nieuwe functionaliteit tegen lagere kosten dan de concurrent kan het verschil betekenen tussen een succesvol bedrijf en een bedrijf dat failliet gaat. Het management heeft behoefte aan solide management informatie, gebaseerd op standaarden, om inzicht te krijgen en om de juiste beslissingen te kunnen nemen.

Om applicatie dienstverlening te kunnen vergelijken is het vrijwel altijd nodig om de omvang van een applicatie of van een project vast te stellen. Voor Metri is dit cruciaal. Omdat we moeten kunnen vergelijken met andere organisaties, kunnen we hier alleen standaarden voor gebruiken. Aangezien de gebruikers normaal gesproken alleen geïnteresseerd zijn in de functionaliteit die hen wordt geboden, en niet in hoe die functionaliteit wordt geleverd (agile of traditioneel) of welke technologie er wordt gebruikt door de ontwikkelaars (Java, .Net, etc.), gebruiken we methodes om de hoeveelheid aan de gebruiker geboden functionaliteit te meten in een ISO/IEC omvangmaat: de functiepunt.

Veel lezers haken nu helaas af, want ja… functiepunten… dat deden we 30 jaar geleden al en zelfs toen werkte het niet. Nu in deze agile wereld kunnen we dat helemaal wel vergeten! Zeg het woord functiepunten tegen een willekeurige agile coach en hij zal je glazig aankijken en meewarig met zijn hoofd schudden. Blijft u toch nog even lezen alstublieft…

Functiepunt Analyse (FPA) is inderdaad in de jaren 70 ontwikkeld bij IBM, met als doel de productiviteit van de ontwikkelteams te meten. Omdat alleen de functionele user requirements worden gemeten, oftewel wat moet de software doen voor de gebruikers (niet hoe of waarom) is de methode onafhankelijk van de technische manier van ontwikkelen en van de manier waarop wordt ontwikkeld. FPA is daarmee de vierkante meter van de Software industrie. Een korte analogie: Of een muur van 20 vierkante meter nu wordt gebouwd met grote bakstenen, kleine steentjes, of in glas, aluminium of ander materiaal, de omvang in vierkante meters blijft hetzelfde. Dit is met functiepunten en de omvang van een bepaalde hoeveelheid functionele requirements exact hetzelfde. De kosten worden bepaald door de prijs per vierkante meter, en die hangen af van bijvoorbeeld de productiviteit van de metselaars en voegers en van de materiaalkosten.

Er is dus geen enkele reden waarom functiepunten niet kunnen worden gebruikt in de agile wereld. Sterker nog, de tegenwoordig gangbare user stories kunnen vaak heel eenvoudig nauwkeurig worden gemeten met FPA. Dit is met name van belang als het gaat om het begroten van software ontwikkeling. Ook in de agile wereld gaan veel software projecten mis: Het Minimum Viable Product (MVP) wordt niet binnen tijd en budget opgeleverd, en/of de technische kwaliteit is zo bedroevend dat daarna een inhaalslag moet worden gemaakt om de technische schuld te verminderen en de openstaande defects eruit te halen. Functiepuntanalyse is ook zeer geschikt om vroeg in de Project (of Product) Lifecycle een accurate begroting te maken van de kosten en doorlooptijd van het ontwikkelen van het Minimum Viable Product (MVP). Om dit te doen zet Metri gecertificeerde functiepunt analisten in om de omvang van de backlogs te meten. Daarnaast wordt professionele software cost estimation technologie ingezet, in combinatie met de Metri database waarin duizenden projecten zitten die zijn gemeten met functiepuntanalyse, om tot een accurate en goed onderbouwde begroting te komen.

Om echt grip te krijgen op de agile teams, zetten we de Agile Team Performance Monitor dienst in, waarbij de code kwaliteit gedetailleerd wordt vastgesteld, en waarbij de team performance in termen van Productiviteit (uren per functiepunt), Cost Efficiency (kosten per functiepunt), Delivery Speed (functiepunten per maand) en Project Quality (Defects per functiepunt) worden gemonitord en onderling en met de markt worden vergeleken. De binnen een sprint of release gerealiseerde functionaliteit meten we in Enhancement Function Points (EFP). Dit zijn het aantal functiepunten toegevoegd, gewijzigd en/of verwijderd in een bepaalde periode. Dit meten we handmatig, of op een geautomatiseerde manier. Op basis van de daadwerkelijk gerealiseerde Productiviteit en Delivery speed, kunnen dan de begrotingen worden bijgesteld op basis van de werkelijke performance.

Deze op functiepunten gebaseerde metrics geeft het management gedetailleerd inzicht in de trends in de performance van de teams en hoe deze teams presteren ten opzichte van elkaar en ten opzichte van de markt. Zie bijvoorbeeld de volgende figuur waarin de productiviteit is omgeslagen naar een index om deze onderling vergelijkbaar te maken en te vergelijken met de markt (1 is marktgemiddeld en bijvoorbeeld 1,12 is 12% boven marktgemiddeld).

Hoewel veel teams dit in eerste instantie vaak zien als een bedreiging, zien we juist ook dat ze gericht willen verbeteren en willen aantonen op de goede weg te zijn. Steeds vaker begrijpt men dat het gebruik van internationale standaarden en best practices een absolute noodzaak zijn om op organisatie niveau de juiste beslissingen te nemen.

CIO’s en IT managers krijgen weer grip op de teams en kunnen voorspellen welke functionaliteit op welk moment wordt opgeleverd tegen welke kosten en wat de kwaliteit van de applicaties is in combinatie met de te verwachten beheerkosten. En de teams kunnen hun professionaliteit bewijzen en gericht van elkaar leren. En dat allemaal dankzij de revival van de good old functiepunt, de vierkante meter van de software wereld!

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.

Wat kost een uurtje software ontwikkeling?

Laatst was een vriend van me op zoek naar een nieuwe schoonmaker (m/v) voor een dag in de week. Hij was daarbij uurtarieven aan het vergelijken en vond het vreemd dat er zo veel verschil in die tarieven zit. Ik werk natuurlijk bij een bedrijf dat aan benchmarking doet, dus hij vroeg aan mij hoe dit kon en welke hij moest kiezen. Op zich een uitstekende vraag! Het antwoord wat ik gaf komt later…

Metri wordt veel gevraagd om uurtarieven onderzoeken uit te voeren. Leveranciers die IT personeel, op basis van Time & Material (uurtarief), inzetten in de markt willen bijvoorbeeld weten hoe marktconform hun tarieven zijn. We zien ook veel contracten tussen klanten en leveranciers, waarin applicatie ontwikkeling wordt gecontracteerd op basis van uurtarieven. Dit is dan vaak een ratecard die per functie/rol en skill level aangeeft voor welk tarief een leverancier een bepaalde functies/rol wil leveren aan die klant. Dit zijn dus geen specifieke mensen, maar tarieven voor een aantal functie/rollen. Klanten vragen ons dan om de ratecard op marktconformiteit te checken. Iets wat we uiteraard graag doen, maar je kunt je afvragen hoe effectief dat is.

Met name als het gaat om het (door) ontwikkelen van software zijn de verschillen in productiviteit en geleverde kwaliteit erg groot. In de Agile Team Performance Monitor onderzoeken die we doen, zien we soms enorme verschillen in productiviteit en kwaliteit. Zie het volgende figuur voor de verschillen die we zien in de markt tussen ‘high performing’ en ‘low performing’ teams.

De eerste 4 metrieken geven de performance van het team aan, de laatste 5 metrieken geven aan wat de kwaliteit is van de opgeleverde code.

Gegeven deze verschillen in performance en kwaliteit, zou je dan niet liever een paar euro per uur meer betalen voor mensen die erg productief zijn en goede kwaliteit leveren? Je zou zelfs kunnen beargumenteren of het averechts werkt om te proberen zo goedkoop mogelijke uurtarieven of ratecards te contracteren voor dit soort werkzaamheden, want dan krijg je als klant waarschijnlijk niet de beste mensen geleverd. Gezien de grote verschillen, wil je voor het door ontwikkelen van bepaalde kritische applicaties, die veel business waarde genereren, misschien wel de allerbeste en dus duurste mensen hebben en dat zijn lang niet altijd de senior of managing skill levels.

Metri uurtarieven

Je kunt je ook afvragen of leveranciers belang hebben bij het zo productief mogelijk ontwikkelen, of juist meer belang hebben bij het zoveel mogelijk besteden van uren. Ze worden immers per uur betaald. Zeker in agile omgevingen, waar vaak toch al niet heel erg gestuurd wordt op productiviteit, zien we vaak dat de kosten gierend uit de bocht vliegen, de datum, waarop bijvoorbeeld het MVP klaar zou moeten zijn, bij lange na niet gehaald wordt en dan blijkt vaak ook nog dat de code kwaliteit bedroevend slecht is en vol risico’s zit.
Ik ben zelf voorstander van output of outcome based contracting. Spreek bepaalde targets af met betrekking tot productiviteit en kwaliteit en bepaal vervolgens wat de prijs is wat daarvoor betaald moet worden. Metri noemt dit Value Driven Contracting. De klant betaalt vervolgens extra bij performance die beter is als afgesproken en minder als de performance slechter is dan afgesproken. Om discussies te voorkomen moet de performance dan wel objectief gemeten worden uiteraard!

Ik heb mijn vriend geadviseerd niet zozeer naar de tarieven te kijken van de schoonmakers, maar iemand te kiezen die bereid is om voor een bepaalde prijs zijn huis schoon te maken en die daarbij garanties wil afgeven ten aanzien van het resultaat. Duidelijke afspraken over welke werkzaamheden worden uitgevoerd en het resultaat daarvan. Eventueel zou je kunnen afspreken wat extra te betalen als je super tevreden bent of wat minder als het resultaat minder is dan afgesproken. Dit heeft als voordeel dat een goede en productieve schoonmaker meer kan verdienen in minder tijd en dat het huis goed wordt schoon gehouden. Mijn vriend is superhappy en zijn schoonmaker doet echt zijn best om de extra inkomsten te verdienen. Een echte win-win dus!

Waarom de begroting van grote, agile softwareprojecten beter moet

De begrotingsvolwassenheid in de IT-sector is bedroevend laag. Het is een belangrijke reden waarom de slagingskans van veel grote softwareprojecten zo laag uitvalt. Bij overheidsinstellingen gaat er veel mis, maar ook het bedrijfsleven heeft er een handje van. Dit ligt hoofdzakelijk aan de populariteit van de expertbegroting, terwijl er ook statistische methodes en modellen beschikbaar zijn in de markt. Dit mentaliteitsprobleem bestaat al decennia en wordt door de agile community nog eens versterkt.

Een realistische begroting is een essentieel instrument om tot een aanvaardbare slaagkans van projecten te komen. Als je met onrealistische verwachtingen aan een project begint, is er een grote kans dat er forse tot zeer forse overschrijdingen gaan komen qua uren, geld en doorlooptijd en dat de kwaliteit tegenvalt. Die extra kosten stijgen alleen exponentieel.

Expertbegrotingen zijn de basis voor problemen

Het slordig omspringen met projectinschattingen is een ingesleten gewoonte in de IT-industrie waar we van af moeten. Waar in andere sectoren de projecten alleen door gecertificeerde ‘cost estimators’ worden begroot, nemen organisaties er genoegen mee om het begroten van een miljoenen project in de IT over te laten aan de inschatting van één of een paar experts. Zelfs grote system integrators gaan voor een groot deel af op gevoel en ervaring van mensen, die soms niet eens expert zijn op het gebied waar ze een begroting voor moeten maken.

Gemiddeld schatten experts de kosten van grote projecten 30 procent te laag in. Nobelprijs-winnaar professor Kahnemann toonde al aan dat mensen geprogrammeerd zijn om optimistisch te zijn, zelfs als ze expliciet te horen krijgen dat ze optimistisch zijn. Opdrachtgevers gaan hier graag in mee en selecteren rustig de goedkoopste aanbieder in plaats van de meest realistische. Eventuele onwelgevallige signalen en kritische vragen over de plannen komen op deze manier aan de onderhandelingstafel niet aan bod. Zeker als er een flinke druk is om voor de goedkoopste aanbieding te kiezen.

Deze gang van zaken is maar al te menselijk. Als je iets heel graag wilt, ben je snel geneigd om risico’s of bedenkingen te negeren. Dat is zeker zo in de agile wereld waar een sterke aversie bestaat tegen alles wat met objectieve metingen en financiële verantwoording te maken heeft. Onder het mom van kleine stapjes en sprints vooruit wordt er zo voor miljoenen euro’s aan software geproduceerd zonder dat er afdoende controles zijn op het behalen van projectdoelstellingen.

Op een voetstuk

Agile teams, op een voetstuk gehesen door de markt, houden vast aan hun geliefde storypoints. Deze inschatting voor de moeite en de tijd van een sprint backlog item verschilt per team. Het biedt veel te weinig houvast om de kosten en de productiviteit en kwaliteit van een softwareproduct goed in te kunnen schatten en te kunnen bewaken. Een adequate inschatting en verantwoording van budgetten voor agile softwareprojecten is er meestal niet.

In agile projecten zijn er niet zozeer budgetoverschrijdingen, maar is het softwareproduct op een bepaald moment in de tijd (soms veel) minder ver ontwikkeld dan oorspronkelijk ingeschat. Uiteindelijk is er wel meer geld nodig omdat er meer sprints nodig zijn dan vooraf gedacht om het product met een bepaalde functionaliteit te kunnen aanbieden. Minder zichtbaar is dat de kwaliteit en onderhoudbaarheid van de software ook relatief laag is, omdat product owners vooral oog hebben voor functionaliteit en minder oog hebben voor kwaliteitsaspecten. Een problematische kwaliteit zorgt voor relatief hoge beheerkosten en daarmee hoge TCO van de applicatie. De plannen en onderbouwing van agile projecten worden inmiddels door senior management met de nodige scepsis bekeken. Deze managementlaag is verantwoordelijk voor de bedrijfsresultaten, maar heeft weinig tot geen grip op de agile teams en wanneer wat klaar is tegen welke kosten. Het draagvlak voor nieuwe plannen is hierdoor zo verminderd dat innovatie dreigt te stagneren.

Doorbreken spiraal

Deze negatieve spiraal is te doorbreken door projectbegrotingen van grote programma’s realistisch in te schatten en risico’s te verkleinen. De methodes zijn er en ook de kennis en vaardigheden krijgen een impuls door nieuwe certificering. Op initiatief van het van oudsher Nederlandse standaardisatie-orgaan Nesma, die vorig jaar een update van de internationale standaard voor een ‘kubieke meter’ software op de markt bracht, komt er nu een internationale certificering voor het vak van de ‘Software Cost Estimator’.

Dit wordt gedaan in samenspraak met de International Cost Estimation and Analysis Association (ICEAA), die gespecialiseerd is in het certificeren van ‘cost estimators in andere industrieën, waaronder de vliegtuigindustrie. Voordat je denkt dat het hier om een fictieve rol gaat. Op internationaal niveau zijn er momenteel duizenden specialisten bezig met hun calculaties omvangrijke softwareprojecten in goede banen te leiden. Hopelijk komt hier ook in Nederland de nodige aandacht voor.

Geen taak van BIT

En dan het liefst voordat de wal het schip keert. Bij de overheid lijken de kansen op meer realisme en verbetering verkeken door het recente schappen van het Bureau ICT Toetsing (BIT). Deze waakhond, die in opdracht van de Tweede Kamer grote IT-projecten bij de overheid screende, moet binnen twee jaar het veld ruimen voor een gedecentraliseerde, over de betrokken departementen uitgesmeerde aanpak van controle (zie ook deze blog). In deze beleidswijziging wordt toegezegd dat de kennis van het BIT zo goed mogelijk wordt overgedragen, maar het is belangrijk om vast te stellen dat deze kennis nooit is opgebouwd. Het toetsen van begrotingen aan de realiteit is nooit tot de taak van het BIT gerekend. Het heeft zich hier ook nooit mee bezig gehouden, terwijl begroting aan de basis staat van alles.

Op dit punt valt er formeel weinig over te dragen, maar informeel is er wel het nodige gebeurd. Zo heeft Nesma aan het voltallige BIT personeel een presentatie gegeven over het opzetten van software cost estimation op basis van het internationaal veel toegepaste ‘Basis of Estimate for Software Services’. Dit is een document dat in veel andere industrieën een verplichte bijlage van een aanbieding is, waarin de begroting gestructureerd is onderbouwd en waarin onder andere de scope, de aannames, de gebruikte methodes, data en gebruikte modellen worden vastgelegd. Hoe eenvoudig is het om aanleverende partijen te vragen deze Basis of Estimate mee te sturen met de begroting die gecheckt moet worden, zodat er een adequaat beeld te maken is van de volwassenheid van een begroting? In de praktijk is dit waarschijnlijk nooit gebeurd.

Marktstandaarden

Software Cost Estimation, op basis van eigen volgens internationale marktstandaarden gemodelleerde ervaringsdata is van onschatbare waarde om de slagingskans van IT-projecten te verbeteren. 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. Rijksoverheden hebben veel te winnen bij zo’n gestandaardiseerde begrotingsaanpak. Het effect zal in deze sector sterker zijn, omdat bij grote projecten praktisch exclusief voor de goedkoopste aanbieders gekozen wordt. En dit zijn uitgerekend de partijen die het meest onrealistisch begroten, waardoor het vragen is om projecten die op een mislukking uitdraaien.

Wat kan de markt ondertussen doen aan de lage begrotingsvolwassenheid? Simpel: ‘gevoel’ en ‘ervaring’ op een laag pitje zetten en afgaan op data, modellen en normen. METRI is als geen ander in staat om daarbij te ondersteunen. Grote organisaties moeten ruimte gaan maken voor een software cost estimator in hun beslisteam. Als dit eenmaal een normale, gewaardeerde rol is, worden we allemaal nog eens begrotingsvolwassen! Organisaties, of ze nu in de profit of not-for profit sector zitten, hebben een grote behoefte aan een solide begroting van agile softwareprojecten. Bij te veel stakeholders is er nu sprake van onaangename verrassingen vanwege gebrek aan grip en transparantie. Dat is slecht voor technologie gebaseerde innovatie.