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.

10 tips om te besparen op IT

(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.

Digitalisering: scheid het kaf van het koren

Het uitvoeren van brede digitaliseringsprogramma’s staat bij veel CIO’s momenteel hoog op de agenda. In veel gevallen speelt software een essentiële rol. Op het eerste gezicht lijken bestaande applicatieportfolio’s één, groot brandend platform die het beste in zijn geheel vervangen kunnen worden. CIO’s die in hun transformatieprogramma code analyse toepassen, krijgen een instrument in handen waarmee waardevolle zaken van bijzaken te onderscheiden zijn. Deze onschatbare informatie onderbouwt strategische ingrepen in het applicatieportfolio en biedt adequaat zicht op de juiste prioriteiten in de roadmap voor softwarevernieuwing.

Voor veel CIO’s is applicatieontwikkeling een blackbox. Die situatie kan veranderen door het onzichtbare zichtbaar te maken, stelde Jean-Patrick Ascenci, senior solution specialist voor het Highlight-product van Cast Software. Ascenci was één van de sprekers op het seminar over het moderniseren van software, dat METRI en CAST op donderdag 4 april 2019 organiseerden in Bunnik om hun strategische samenwerking te onderstrepen. Door de softwarecode van maatwerk applicaties te scannen krijg je zicht op hoe robuust, veilig, efficiënt, overdraagbaar en onderhoudbaar applicaties zijn. Door dit scannen van code te combineren met vragenlijsten, waarin de toegevoegde waarde van applicaties voor de business duidelijk wordt gemaakt, ontstaat concreet zicht op de toegevoegde waarde en de risico’s in het applicatieportfolio.

Beide benen
De eerste spreker van de middag, Paul Thysens, ex-CIO BNP Paribas Fortis, zette zijn toehoorders van CIO’s en hoofden softwareontwikkeling even met beide benen op de grond. “Je zou met het huidige marketing geweld rond digitalisering de indruk kunnen krijgen dat vandaag de dag de grootste veranderingen plaatsvinden in IT”, aldus de door de wol geverfde CIO die na een lange loopbaan als IT executive in de bankwereld nu een adviesrol heeft. “Vanaf de start van het vakgebied draait IT om modernisering. Voortdurend komen er nieuwe zaken bij die als bij een ui met iedere nieuwe laag complexiteit toevoegen aan de stack. Als CIO ben je voortdurend bezig om die verandering te faciliteren. In het huidige digitale tijdperk verwachten consumenten eenvoudige systemen en processen, op maat getekend naar hun specifieke behoeftes en afgestemd op de kleine schermervaring van de smartphone. Dat is niet de enige uitdaging. Decennia oude systemen functioneren niet goed in de open omgeving van internet. Het ondersteunen van deze nieuwe security architectuur in bestaande systemen is een uitdaging, omdat er een grote schaarste is aan programmeertalent. De vraag is tien keer groter dan het aanbod. Deze klok tikt ook steeds harder, omdat programmeurs die de bestaande systemen kunnen onderhouden in toenemende mate de arbeidsmarkt verlaten.”

Vernieuwing van software is dus een belangrijk thema, maar dat is niet de enige prioriteit die zich aandient. Veel CIO’s zitten vast aan legacy en tal van andere zaken die om voorrang schreeuwen. “Als je als CIO bij de business voortdurend geklaag hoort over het innovatietempo en de kwaliteit van IT en tegelijkertijd een aanzienlijk veranderprogramma moet ondersteunen, kan het lastig zijn om een goede richting te vinden”, vervolgde Thysens. Hoe stel je vast of je als CIO op het goede spoor zit? Het verzamelde dagtarief van externe experts is een gegeven dat bijdraagt aan kostenbeheersing. Toch is het volgens Thysens geen adequate graadmeter in welke mate deze kennis bijdraagt aan de productiviteit van IT. De stabiliteit van de applicatie-omgeving en de gemiddelde doorlooptijd van projecten zijn wat dat betreft betere bakens voor de CIO die met grote veranderingen bezig is. De stabiliteit van applicaties is een belangrijk gegeven omdat het goed zicht geeft op de kwaliteit en het functioneren van applicaties. Doordat incidenten en onderbrekingen van applicaties rechtstreeks impact hebben op de gebruikerservaring, wint dit cijfer verder aan belang. De andere niet te missen indicator voor succes heeft te maken met de gemiddelde duur van projecten. Als je in een portfolio van honderden projecten een gemiddelde haalt van 15 maanden, moet je als CIO onderzoeken met welke maatregelen je de doorlooptijd kunt versnellen. Tot slot zijn ook gebruikerstevredenheidsonderzoeken goede graadmeters voor de algehele kwaliteit van de IT-dienstverlening.

Helikopterblik
Waarmee krijg je een alles overziende blik, een totaaloverzicht dat een brede kijk biedt op modernisering van het applicatielandschap? Het Highlight hulpmiddel van Cast biedt in een grafische weergave van het applicatieportfolio zicht op de veerkracht van applicaties en het gemak waarmee deze software over te hevelen is naar een cloudplatform. “Zo’n helikopterweergave laat zien in wat voor mate applicaties bijdragen aan het bedrijfsresultaat, welke software-onderdelen problematisch zijn en welke applicaties goed over te zetten zijn naar een nieuw platform”, vervolgde Ascenci. “Als een toepassing niet belangrijk is voor het bedrijf, veel bugs heeft en problematische softwarecode zijn dat belangrijke aanwijzingen om deze applicatie uit te faseren en naar een andere oplossing te zoeken. Anders dan bij andere methoden om de applicatie roadmap breed aan te vliegen, is bij de werkwijze van Cast wel de onderliggende softwarecode beschikbaar. Op die manier kun je een applicatie waarvan het beheer te kostbaar is, gedetailleerd bestuderen.”

Een andere mogelijke toepassing is een scan uitvoeren op mogelijk verkeerd gebruik van privacygevoelige data. Door op sourcecode niveau te checken of er manipulatie van data plaatsvindt, kunnen CIO’s vaststellen of software voldoet aan de AVG (Algemene Verordening Persoonsgegevens). Ook systemen die opgebouwd zijn met open source softwarecode zijn gedetailleerd te checken op kwetsbaarheden. Er wordt een link gelegd met bekende kwetsbaarheden in populaire frameworks. Ook problematische open source licenties komen boven drijven. Soms verplicht een open source licentie organisaties de code die zij verwerkt hebben in hun applicatie te publiceren. Ook dat risico wordt geïnventariseerd. Centraal thema bij het opmaken van de applicatie inventaris is de ondersteuning van cloud als leveringsvorm. Bij de scan komt er integraal zicht op de bouwblokken in de softwarecode die vernieuwing nodig hebben bij het overzetten van de applicatie naar een cloudplatform. Dit is een essentieel ingrediënt voor een cloud transformatie roadmap.

Van legacy naar digitaal
Centrale boodschap tijdens het seminar was dat organisaties die van legacy door willen groeien naar een digitaal bedrijf de huidige blackbox van softwareontwikkeling open moeten gooien. De feiten en informatie die hierbij boven water komt, hebben een adequate vertaler nodig vond Ascenci. “Bij Cast Software kunnen we spreekwoordelijk gezegd de deur van applicaties openen, maar je hebt een adviseur als METRI nodig om de aanbevelingen te concretiseren en op te kunnen volgen.” Iedere organisatie heeft weer andere criteria en voorkeuren voor het moderniseren van de applicatiestack. In dit verband is ook het 6R-model van AWS relevant, dat ook richting geeft bij de vervanging van maatwerksoftware door standaard SaaS-software. Sourcing vraagstukken zijn relevant. Uitdagingen rond het beheer van softwarecode, het vinden van de juiste onderhoudsteams en het minimaliseren van beheerkosten en vergroten van het innovatiebudget zijn belangrijke voorwaarden voor een CIO om verder te komen met een digitaliseringsagenda. En die modernisering gaat natuurlijk veel verder dan software alleen. Zo is de overstap op een database-as-a-service-concept een veel gemaakte eerste stap naar de cloud.

De metertjes in de softwarefabriek
Het meekijken in de softwarecode heeft ook zeker zijn waarde op het moment dat applicaties nieuwgebouwd worden. Dat liet senior consultant Harold van Heeringen van METRI treffend zien met zijn metafoor van de metertjes die in een fabriek die gebruikt worden voor procescontrole. Op een feestdag leidde een vriend hem rond in een lege fabriek. De grote verzameling meters, klokken en meetinstrumenten op het controlepaneel inspireerden hem om bij financiële analyses van softwareontwikkeling ook met gestandaardiseerde metrics en data te werken. “Software bouw je ook in een fabriek”, aldus Van Heeringen. “Het vreemde is dat binnen de tegenwoordig gangbare agile methode er bijzonder weinig meetgegevens over het functioneren van ontwikkelteams beschikbaar is. Er is een lage volwassenheid in meten, omdat bedrijven ervan uitgaan dat de experts zelf in voldoende mate weten wat ze moeten doen. Het voornaamste controlemechanisme is de producteigenaar die de verzamelde functionaliteit van de backlog in beheer heeft.”

Het is de vraag of die ingeslagen weg wenselijk is. Het produceren van software is tegenwoordig essentieel voor de toekomst. Bij agile zijn in veel gevallen de risico’s opnieuw volledig bij de klant komen te liggen doordat contracten time en material gebaseerd zijn. Dat levert voorspelbare kosten op doordat in de teams de functies en rollen schijnbaar overzichtelijk ingedeeld zijn. Maar wil je onafhankelijk vaststellen of je als klantorganisatie waar voor je geld krijgt, dan is deze methode niet transparant genoeg. Neem een functie in de applicatie die in verschillende sprints 3 of 4 keer opnieuw wordt gebouwd. Heb je niet de beschikking over dit soort detailinformatie rond de productiviteit, dan kun je kun niet sturen op deadlines en kosten. Voor de langere termijn hebben stakeholders inzicht in de productiviteit en kwaliteit van softwarecode nodig om omvangrijke agile projecten bij te kunnen sturen. Ook op dit punt kan code analyse bijdragen aan het productief maken van de software-industrie.

Meer informatie
Elke CIO en IT-beslissers moeten in staat zijn om het portfolio aan applicaties te analyseren en te beoordelen. Code analyse gecombineerd met de meer traditionele aanpak van surveys levert Software Intelligence op die de business value van software verhoogt, applicatiebeheerkosten verlaagt en vooral risico’s rond security verkleint. Dat is niet alleen voor legacy interessant. In de agile wereld wordt er continu nieuwe software in het portfolio geïntegreerd. Het is een absolute noodzaak om de structurele gezondheid te blijven monitoren om dure incidenten te voorkomen en de TCO behapbaar te houden, of zelfs te verlagen. Het Highlight product van CAST, waar METRI de financiële data analyse dienstverlening gedeeltelijk op baseert, maakt duidelijk wat de score is van applicaties ten aanzien van aspecten als agility, resilience en cloud readiness. Door te segmenteren wordt het mogelijk om snel onderbouwde keuzes te kunnen maken. In een kortdurend traject van maximaal enkele weken, wordt een integraal beeld geschetst van het portfolio, gebaseerd op facts en internationale standaarden, waar CIO’s en hun ontwikkelteams direct mee aan de slag kunnen. Zie voor meer informatie deze webpagina.

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.

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.

Is uw dure software al winterklaar?

Het huis van de buren werd vorige maand geschilderd. En niet alleen hun huis. Voor ik het goed en wel doorhad stond bijna de hele straat in de steigers. Behalve nummer 44.  De eigenaar vond het geen goede investering want zijn kinderen waren de deur al uit hij wilde binnenkort een bord in de tuin zetten. Een kapitale denkfout van nummer 44, maar hij is daarin niet uniek. In de IT worden vergelijkbare (dure) fouten geregeld gemaakt…

Het huis van de buurman op nummer 44 kon duidelijk wel een likje verf gebruiken. Maar hij vond onderhoud te veel geld kosten. In plaats van de winterschilder nodigde hij de taxateur uit. En toen kwam de teleurstelling: 350.000 euro. Hij had toch zeker op vier ton als taxatiewaarde gerekend. De makelaar had nieuws voor hem: mensen willen een huis dat óf af is óf dat als klusproject kan worden bestempeld. Een huis met achterstallig onderhoud valt tussen de wal en het schip. Als hij de winterschilder ook had ingeschakeld, ja dán had de taxatie een stuk gunstiger uitgepakt.

Voor auto’s geldt hetzelfde. Een z.g.a.n.-auto doet het altijd goed op de markt. Een zwaar beschadigde auto die rijp is voor de sloop, kan ook op niet geringe belangstelling rekenen bij hobbyisten. Maar één deuk in de deur verpest alles. Zo is het ook met software. Die heeft van tijd tot tijd ook een likje verf nodig om de invloeden van de buitenwereld te kunnen doorstaan. Sterker nog: het heeft niet alleen een likje nodig, er staan soms zelfs sancties op achterstallig onderhoud.

Soms is aan de software niet direct te zien dat er inhoudelijk iets veranderd is. En anders dan een huis of een auto wordt software die de business van een bedrijf ondersteunt, zelden te koop gezet. Toch kan de prijs van het niet onderhouden van software hoog zijn. Als het niet (meer) in staat is om met mobiele apparaten te communiceren, kun je zomaar de klandizie van jongeren verliezen, omdat die alleen nog op hun telefoon zaken met je willen doen. En dat kost geld. Als je data niet op orde is, kun je zomaar een boete krijgen van het College Bescherming Persoonsgegevens, omdat je niet voldoet aan de Algemene Verordening Gegevensbescherming die op 28 mei 2018 van kracht wordt. En dat kost veel geld. Die boetes kunnen oplopen tot 20 miljoen (!) of 4% van de wereldwijde jaaromzet als die meer is dan die 20 miljoen. Of je nu klanten verliest of een draconische boete krijgt, het kan je je bedrijf kosten.

Het is dus van belang om zicht te houden op de kwaliteit van je applicatie. Maar de grote vraag is: hoe weet je of jouw software een likje verf nodig heeft? Merti kan je daarin adviseren op basis van de analyses van technologiepartner CAST. Want voorkomen is beter dan nooit meer genezen… Bekijk hier ons volledig dienstenaanbod.

Goedkope software kan u veel geld gaan kosten…

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

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

Kwaliteit checken

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

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

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

Toezeggingen

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


Papa, jij bouwt toch Nintendo’s?

Laatst vroeg mijn dochter van 11: ‘Papa, jij doet toch iets in de i tee? Wat doe je dan precies? Nintendo’s bouwen?’

‘Nou Linda’, antwoordde ik, ‘je vader helpt klanten met het benchmarken van hun leveranciers, bijvoorbeeld de leveranciers die hun software ontwikkelen en beheren.’ Ik zag haar denken: benchmarken, leveranciers, software beheren… waar gaat dit over? Dus ik moest haar uitleggen dat er een hele wereld is met software buiten de Mario Karts, Pokémon Go’s, Youtubes en Spotify’s en dat het ontwikkelen van goede software voor veel organisaties van extreem groot belang is. ‘Denk maar eens aan de programma’s die je op school gebruikt. Je moet je voorstellen dat er veel leveranciers zijn van lesmateriaal op de computer, maar waarschijnlijk heeft jouw school gekozen voor de pakketten die jullie gebruiken op basis van de afweging van prijs en kwaliteit maar ook op basis van de functionaliteit die het pakket biedt.’

Functionaliteit. Nóg zo’n moeilijk woord. Ook dat moest ik natuurlijk uitleggen. Mensen communiceren met software door middel van de functionaliteit die hen wordt geboden. Zo kun je een Engelse les openen, oefeningen maken, die laten corrigeren en je leerresultaten en voortgang opslaan. Dat is allemaal functionaliteit die de software jou als gebruiker biedt. Andere softwarepakketten bieden mogelijk dezelfde, of heel andere functionaliteit. En ja, de hoeveelheid functionaliteit kun je meten met een internationale standaard, zoals je ook jouw lengte kan meten in centimeters en jouw gewicht kunt meten in kilo’s.  Omdat het een internationale standaard is, kun je metingen vergelijken en op basis daarvan conclusies trekken.’

‘Ah’, zei ze, ‘je kunt dus meten hoeveel functionaliteit een app aan de gebruikers biedt en aan de hand hiervan meten of de klant een goede prijs heeft betaald.’ Briljant. Ze leek het echt te snappen.

‘En jij helpt organisaties om de beste functionaliteit te kiezen?’

‘Nou, dat niet’, zei ik. ‘Maar ik meet wel hoeveel functionaliteit een leverancier levert voor het bedrag dat de klant betaalt en met welke kwaliteit deze software wordt opgeleverd. In de IT-wereld komt het nog vaak voor dat er geen goede afspraken worden gemaakt met betrekking tot zaken als productiviteit, kosten efficiency, leversnelheid en kwaliteit. En zeker nu tegenwoordig het risico in applicatieontwikkeling weer volledig naar de klant is geschoven in de huidige wereld van Agile en DevOps teams. ‘Time en Material’ projecten, gebaseerd op ongrijpbare en niet gestandaardiseerde meeteenheden als storypoints, zorgen ervoor dat de klant nooit volledig grip krijgt op de voortgang. De klant betaalt soms heel veel geld en moet de leverancier dan maar geloven dat alles goed komt. Soms komt het goed, maar heel vaak ook niet. Dan is het geld op en is nog maar een deel van de software gerealiseerd dat op dat moment gereed zou moeten zijn.  Ik help organisaties grip te krijgen op de geleverde prestaties, deze objectief te meten en op basis hiervan kunnen verbeteringsinitiatieven worden gestart of kan de leverancier worden gevraagd zijn beloftes na te komen of de prijs te verlagen.’

Dit was toch duidelijk een brug te ver om allemaal te bevatten voor een meisje dat in groep 8 zit van de basisschool.

‘Tjonge, dat klinkt best heftig’, zei ze. ‘Maar ik zou het leuker vinden als je Nintendo’s zou bouwen, dan kon ik misschien korting krijgen op zo’n mooie DS.’

Tja, kinderen blijven kinderen…

Applicaties meten: een hoop kluitjes in het riet

Laatst was ik in een schoenenwinkel. ‘Volgens mij heeft u maat 9,5’ zei de vriendelijke dame die al een doos met sneakers voor mijn neus had gezet. Ik dacht: 9,5? Ik heb 42,5! Bleek 9,5 de US-maat te zijn. Zo kan het dus ook: er wordt gemeten met twee maten maar je kunt eenvoudig een vergelijking maken met behulp van een vertaaltabel. Gaat het om het meten van applicatie omvang dan heb je een hoop kluitjes in het riet. Het wordt tijd dat meetvarianten met elkaar in verhouding worden gebracht zodat we geen appels en peren meer hebben.

Er zijn talloze meetvarianten om applicatie omvang te meten. Enerzijds heb je de regels code die in de applicatie zitten, ofwel de fysiek getypte code die zegt wat de applicatie doet. Daarnaast zijn er varianten die meer uitgaan van functionaliteit, de documentatie en van de gebruiker. Die beoordeling wordt uitgedrukt in functiepunten. En dan heb je daarin ook nog veel verschillende smaken, bedacht door verschillende instanties. En ze proberen allemaal hun methode te standardiseren en beschrijven tot norm. In Nederland hebben we de Nesma, in de VS de IFPUG en Cosmic in Canada. Om er maar een paar te noemen.

En dan heb je nog de agile-clubs. Zij schatten met het spelletje Planning Poker of Scrum Poker in om te zien hoe groot de functionaliteit is en hoeveel effort je er in zou moeten steken om de applicatie te kunnen bouwen. Zij drukken dat uit met storypoints. Weer een methode. Weer een schoenmaat. Het is eenvoudigweg een complex landschap met verschillende maten. En omdat er zoveel ‘eilandjes’ zijn krijg je natuurlijk nooit één grote dataset.

De vraag is: hoe creëer je een methode waardoor al die waarden omrekenbaar zijn en je van functiepunten regels code kunt maken, van storypoints functiepunten, van functiepunten storypoints… Toch ook een vertaaltabel zoals bij de schoenmaten? In de sociologie bestaat het principe dat als je maar genoeg mensen dezelfde vraag stelt, het gemiddelde antwoord altijd goed is, of vrijwel goed. Vraag honderd mensen hoe zwaar een bepaalde koe is en het gemiddelde zit griezelig dichtbij de waarheid. Als al die mensen op verschillende manieren de applicatie gaan meten, lukt het ook om één waarheid te vinden. Er moet dus een standaard komen, om alle kennis die er is om de juiste maat van een applicatie te kunnen aangeven, echt goed te kunnen gebruiken.

Maar het is net politiek. Er zijn officiële, internationale groepen die zeggen: wat wij hebben bedacht is een goede manier om te meten, een waarheid. En dus zijn maten moeilijk vergelijkbaar, ieder team heeft zijn eigen methodes, zijn eigen dynamiek.

Er zouden rekenregels moeten komen. Iedereen mag het op zijn eigen manier doen, applicaties meten. Maar laten we in ieder geval vaststellen dat we dezelfde applicatie aan het meten zijn. Daar moeten dus relaties tussen zijn. Een model dat alles bij elkaar brengt, omrekent en vertaalt. Een omrekenmethode, zoals bij buitenlandse valuta. Of bij schoenmaten.

Nu nog een list verzinnen hoe. Wie de schoen past…

Koop geen kat in de zak met software-ontwikkeling

Veel organisaties ontwikkelen software niet in eigen huis, maar besteden deze activiteit uit aan gespecialiseerde dienstverleners. Het is algemeen bekend dat veel softwarerealisatieprojecten spaak lopen en minder rendement opleveren dan vooraf gedacht en gehoopt. Het is minder bekend dat de plank al misgeslagen wordt door keuzes bij de start van een project.

Een bekende lakmoesproef voor het succes van softwarerealisatieprojecten is het ‘Chaos report’ van de Standish group, een expert in projectmanagent die jaarlijks een rapport uitbrengt waarin informatie over budgettering, deadlines en resultaat van duizenden projecten verzameld is. Uit deze cijfers blijkt dat nog steeds meer dan de helft (52%) van de projecten averij oploopt en maar liefst 19% in zijn geheel mislukt.

Anticiperen

Deze uitkomsten zijn opvallend, omdat er door de sterke opkomst van agile werken een veel voorkomend struikelblok uit de weg geruimd is. Door scrum toe te passen is er een veel betere interactie tussen de business, IT en het ontwikkelteam. Toch gaat er nog steeds het nodige mis en dat komt vooral doordat in de contractering, het gekozen prijsmodel en afspraken met leveranciers te weinig geanticipeerd wordt op succes.

Het is staande praktijk dat organisaties een tender voor applicatieontwikkeling in de markt zetten waarin de wensen en eisen op zijn best op hoofdlijnen te ontwaren zijn. De specificaties zijn eigenlijk niet gedetailleerd genoeg om een realistische prijs te kunnen berekenen. Dat is geen belemmering voor marktpartijen om met een bodemprijs in te schrijven en het project te winnen. Het is gebruikelijk om tijdens de realisatie van het project met nieuwe facturen en deadlines te komen als er meer sprints nodig zijn. Klanten moeten zichzelf niet rijk rekenen met zo’n bodemprijs. Te weinig zicht op het op te leveren product gecombineerd met een onrealistische inschatting van budget en tijdspad plaatst klant en leverancier later voor dilemma’s. Daarom is een goed begin het halve werk.

Prijsmodel

Bij het agile ontwikkelen van software is het gebruikelijk om applicaties in nauw overleg met de opdrachtgever in meerdere stappen of sprints te ontwikkelen. Bij dit soort projecten is de prijs doorgaans gebaseerd op de omvang en de ervaring van het team bij de leverancier. Hierdoor heeft de leverancier alleen een inspanningsverplichting en komen wijzigingen in de omvang en de deadlines volledig voor rekening van de klant. Het is beter om het prijsmodel ook bij scrum-projecten te baseren op realistische productiviteitscijfers. De beste eenheid om dat te doen is de functiepunt. Deze objectieve en internationale meeteenheid is aangepast aan de moderne tijd en is ook geautomatiseerd in te zetten.

Lees meer hierover op METRI Research.


Een voordelig uurtarief: trap er niet in!

Mijn buurman zocht een schilder. Hij zette een oproepje via een klus-site en kreeg twee reacties: de ene deed het voor 30 euro per uur, de ander voor 25. Hij koos voor die van 25 per uur. Wat hij niet wist: die van 30 gebruikte twee kwasten tegelijk en zou daarom veel minder uren nodig hebben. Was mijn buurman per saldo toch veel meer geld kwijt…

In de outsourcing-wereld gaat het te vaak precies zo. Veel organisaties outsourcen (een heel groot deel van) hun applicatie management én development, aan één of meerdere leveranciers. Bij applicatie management wordt er heel erg gekeken naar de prijzen van de services, terwijl dat bij development gek genoeg veel minder het geval is. Daar wordt vaak alleen naar uurtarieven gekeken, ook omdat men niet goed weet hoe de output van software development projecten gemeten kan worden.

De afdeling inkoop kijkt daarom vooral (of uitsluitend) naar de zogenaamde rate cards. Ofwel de Excel sheets met daarin de functies en de uurtarieven die de betreffende partijen aanbieden. Daarin staat dan bijvoorbeeld dat een tester on shore 80 euro kost, off shore kost hij 25 euro en komt-ie uit Roemenië of Polen – near shore – dan gaat het misschien om zo’n 50 euro per uur.

De uitbesteder gaat dan meestal voor de goedkoopste optie. Kort door de bocht gezegd, is de ene tester 50 euro en de andere 52 euro per uur, dan krijgt de eerste de klus. Terwijl de tweede misschien veel sneller werkt, dus productiever is. Of met twee kwasten tegelijk. Nu zal een leek zeggen: je kunt toch vragen hoe effectief hij werkt en hoeveel uur hij erover doet? En de leek heeft gelijk. Echt, uitvragen gebeurt echter veel te weinig.

Heel simpel: vraag gewoon wat de productiviteit is uitgedrukt in uren en functiepunten voor een, bijvoorbeeld, gemiddeld Java-project van gemiddelde omvang, gemiddelde complexiteit en zonder tijdsdruk. Ga de diepte in, vraag door. Neem geen genoegen met alleen een uurtarief. Hier enkele voorbeelden van concrete vragen die je in een uitvraag kunt meenemen:

  • Wat is uw productiviteit voor een gemiddeld complex Java-project met een omvang van 500 functiepunten (FP) in een doorlooptijd van zes maanden uitgedrukt in uren per functiepunt (technisch ontwerp, coding, systeemtest, ondersteuning acceptatietest en project management)?
  • Wat zijn de kosten per functiepunt voor ditzelfde project?
  • Wat is het maximaal aantal defects per functiepunt dat u oplevert in de acceptatietest en in productie (eerste 3 maanden) in ditzelfde project?
  • Welk % productiviteitsverbetering in uren/FP denkt u te kunnen realiseren per contractjaar en op welke manier denkt u dat te kunnen bewerkstelligen?
  • Welk % kostenvermindering (kosten/FP) denkt u te kunnen realiseren per jaar en op welke manier denkt u dat te kunnen bewerkstelligen?
  • Bent u bereid om de prestaties van uw ontwikkelteams te laten meten en benchmarken tijdens de looptijd van het contract en contractuele afspraken te maken ten aanzien van deze prestaties?
  • Bent u bereid een Basis of Estimate-document (een document waarin de begroting gedetailleerd wordt onderbouwd) mee te leveren met de afzonderlijke projectbegrotingen?

De meer volwassen softwareleveranciers schrikken overigens niet van dit soort vragen. Die zijn gewend hun eigen capablities te meten en te verbeteren en zijn daarom prima in staat dit soort vragen te beantwoorden.

Laatst sprak ik een klant die dolblij was dat hij voor een bepaald contract het uurtarief van 80 naar 76 euro had weten te krijgen. Wat hij niet beseft is dat die leverancier zeer waarschijnlijk wat extra uren zal maken, zolang jij niet meet wat hun productiviteit is. Om die reden levert METRI de service supplier performance measurement (SPM). Het meten van leveranciers op productiviteit, kosten, time-to-market en kwaliteit geeft organisaties veel meer grip op de value for money die ze krijgen en ook stuurmogelijkheden in handen om deze zaken tijdens de looptijd te laten verbeteren. Door middel van objectieve metingen kunnen we de performance meten, vergelijken met de markt en kunnen er duidelijke en realistische  targets vastgesteld worden om met elkaar naartoe te werken. Zo kun je de prijs per vierkante meter benchmarken en kijken hoe die prijs zich verhoudt met vorig jaar, of vorige maand. Als je dat allemaal weet, dan pas heb je als organisatie grip op de zaak en kun je pas echt sturen en keuzes maken.

Gratis lenen is het nieuwe sparen

‘Gratis geld!’, riep mijn zwager triomfantelijk op de verjaardag van mijn zus toen we het over de rigoureuze – en in mijn ogen onverstandige – acties van de Europese Centrale Bank hadden. Maar hoe moet het nu met al die IT-beheerders, die straks allemaal werkloos thuiszitten? Hij vond mij een azijnplasser. Ik hoop dat hij gelijk heeft.

Op verjaardagen ontstaan de heftigste discussies. Ik mag ook graag grote, wereldse zaken met een vileine glimlach aanroeren. Wat mij momenteel nogal bezighoudt zijn de capriolen van de ECB. ‘Ze zetten de rente op nul of zelfs, in sommige gevallen, iets negatief en dat is een gek idee’, zei ik tegen mijn zwager die net een slok uit z’n bierpijpje nam. ‘Je leent geld en krijgt daarvoor dus geld toe’, ging ik verder. Dat is voor mensen van mijn generatie, die zijn opgevoed met de Zilvervloot-spaarrekening, onbegrijpelijk. De ECB van nu wil liever niet dat we sparen; lenen en uitgeven, dát is het devies. Druist volledig tegen mijn gevoel en opvoeding in.
Mijn zwager schudde met het hoofd en trok de koelkast van mijn zus open. Ik legde uit dat er de afgelopen tijd behoorlijk wat bedrijven winst maken en ook aardig wat kapitaal op de bank hebben staan. Maar daar krijgen ze dus bijna of helemaal niks voor. Als je een investering doet, kijk je naar de return on investment en de terugverdientijd. Nu maakt die laatste niet heel veel meer uit, aangezien de kapitaallasten nihil zijn. Maar het rendement op je investeringen tellen wel. Als jij, zo zei ik tegen mijn zwager, een nieuwe auto koopt die 20% zuiniger is, wil je natuurlijk wel weten hoe lang het duurt tot je de aanschaf hebt terugverdiend en hoeveel geld je ermee bespaart. Maar je kijkt niet meer naar de kosten van de lening of de derving als je je spaarrekening leegtrekt.
Mijn zwager zei doodleuk: ‘Jij zit toch in de IT?’ En daar wilde ik precies naartoe. In de IT is veel hardware nodig, of je dat nu zelf koopt of een ander dat voor je regelt. Daar gaat veel geld inzitten. En als de rente nul is kun je flinke investeringen doen. Je hoeft in een keer geen rekening te houden met de kostenpost rente door leningen. En dat was precies het moment waarop mijn zwager triomfantelijk riep: ‘Gratis geld!’
Maar nu de schaduwzijde. Als het kapitaal niets meer kost, is het aantrekkelijker om meer te investeren. Om een nog zuinigere auto te nemen. Je hoeft immers alleen maar met de terugverdientijd rekening te houden. Je hebt weliswaar een duurdere auto en daar geld voor geleend, maar als je daar bijna niets voor hoeft te betalen, wat maakt jou het dan uit als het daardoor allemaal goedkoper wordt? Zo denken veel IT-bedrijven er ook over. Waarom niet het allerbeste, het allernieuwste aanschaffen als het toch ‘niets’ kost?
En als je het nieuwste van het nieuwste in huis of in de cloud hebt, heb je ook geen beheerders meer nodig, omdat alles veel makkelijker en beter te automatiseren is waardoor je veel minder arbeid nodig hebt. De ECB zorgt er dus voor dat mensen hun werk kwijtraken. Dit is een proces dat al in gang wordt gezet als er nieuwe generaties hard- en software worden ontwikkeld, maar dat proces wordt nu flink versneld omdat investeringen niets kosten. Gevolg: minder beheerders, meer werkloosheid.

Toen werd ik dus azijnplasser genoemd in de keuken van mijn zus. Hij nam er nog een. Z’n laatste, zo beloofde hij vooral zichzelf. ‘Ik ben met de fiets, hoor!’ zei hij. ‘Jij zeker met die zuinige auto van je?’  Ik knikte. Ik heb inderdaad een zuinige auto. Nieuwste van het nieuwste, uiteraard.

METRI is een Fact Based IT adviesorganisatie gespecialiseerd in sourcing en benchmarking die organisaties helpt bij het verbeteren van de inrichting en besturing. Via een maandelijkse nieuwsbrief blijf je op de hoogte van marktontwikkelingen en trends.

[wysija_form id=”1″]