In de IT branche blijkt het schatten van software projecten een hele uitdaging. Veel projecten worden niet binnen afgesproken tijd, budget en tegen afgesproken kwaliteit opgeleverd. Dit kan een groot aantal redenen hebben die niet altijd even gemakkelijk zijn toe te lichten. Er is ook geen eenduidig antwoord op te geven, maar het kan wel anders.

In dit artikel worden een aantal vergelijkingen getrokken tussen het bouwen (en inrichten) van een huis en het ontwikkelen van software. Hierbij worden een aantal problemen duidelijk die in andere soorten projecten minder of niet van toepassing zijn. Er zijn echter wel oplossingen welke in de praktijk nog altijd niet, of niet met de juist reden, worden gebruikt.

Software projecten zijn complex

Er zijn veel soorten en maten projecten en er komen veel aspecten bij kijken om een project in te schatten. De schattingen van kosten, hoeveelheid werk en kwaliteit van de op te leveren producten zijn meestal de definitie voor het afronden van een succesvol project. Niet alleen ziet ieder project en de daarbij betrokken organisatiestructuren en procesinrichting er anders uit, het inschatten van de omvang van de te bouwen applicatie zelf is vaak al een hele uitdaging.

Waarom is het schatten van software projecten zo lastig?

Bij het bouwen van een huis kunnen de kosten toch ook goed ingeschat worden?

Schatten met materialen en producten

Het verschil zit in een aantal dingen. Kostenschattingen van bouwprojecten zijn grotendeels gebaseerd op materialen en producten. Als duidelijk is hoe een gebouw ongeveer uit moet zien op welke bouwgrond, dan kunnen de te gebruiken materialen, de hoeveelheid, en de kwaliteit ervan bepaald worden. Het aantal vierkante meters en de inhoud van ruimtes is makkelijk te berekenen. Voeg hierbij een aantal redelijk goed in te schatten activiteiten aan toe, zoals het assembleren en installeren van de materialen, en het totale kostenplaatje is grotendeels af. Veel risico’s, zoals wegzakkende grond, kunnen van tevoren geanalyseerd worden waardoor ook hier maatregelen tegen getroffen kunnen worden. Enkel de afhankelijkheden van verschillende aannemers en volgorde van activiteiten kan nog een onzekerheid in de doorlooptijd van het bouwproject introduceren. Over het algemeen kunnen nauwkeurige schattingen gemaakt worden van de kosten en doorlooptijden.

Schatten met taken en activiteiten

Software projecten worden in de praktijk vaak anders geschat. Schattingen en planningen zijn vaak gebaseerd op werkpakketten en daarbij horende taken en activiteiten, in plaats van materialen en wat opgeleverd gaat worden. Kosten worden vaak gebaseerd op de nodige inspanning welke ingeschat wordt op deze activiteiten, uitgedrukt in aantal mandagen. Er wordt ingeschat hoeveel uren werk het ontwerpen, realiseren en testen in beslag nemen. Daarbij worden vaak nog schattingen gemaakt van de uren die nodig zijn voor documentatie, rapportages, projectmanagement, installatie etc. Dit schatten gebeurt in meer dan 90% van de projecten op basis van ervaring en gevoel. Omdat niet duidelijk is wat de echte omvang is van de te realiseren software kunnen er geen eenduidige antwoorden gegeven worden op de kosten en doorlooptijden hiervan. Er is geen eenheid die aangeeft hoeveel vierkante meter een softwareapplicatie is, toch?

Een eenduidige maat voor de omvang van software

Als sinds de eerste regels programmeercode worden geschreven zijn er manieren bedacht om iets te zeggen over de orde en grootte van software. Er werd toen bijvoorbeeld gerekend met het aantal regels code (Source Lines of Code), maar dit bleek al snel zijn beperkingen te hebben door de grote variëteit aan programmeertalen en doordat er een slecht verband is tussen het aantal regels code en de functionele werking ervan. Later werden er Functional Size Measurement (FSM) methodes bedacht. In plaats van te kijken naar technische eigenschappen van de programmatuur worden met deze methodes enkel functionaliteiten bekeken. De omvang van functionaliteiten, zoals de oppervlakte van een kavel of inhoud van een gebouw, wordt dan uitgedrukt in Functiepunten (FP). Dit zijn de producten of materialen die daadwerkelijk gebouwd of gemaakt worden bij het bouwen van een huis. Maar wat zijn de functionaliteiten dan van een softwareapplicatie?

Afspraken over resultaten

Functionaliteiten van een softwareapplicatie zijn vaak abstract en niet tastbaar, ook voor de opdrachtgever zelf. Er is behoefte aan een applicatie die een bepaald probleem moet oplossen of een bedrijfsproces moet ondersteunen. Hoe dit precies uitziet is vaak niet helemaal duidelijk. Het volledig uitwerken van de functionaliteiten die met de software mogelijk moet zijn is een langdurig proces. Waar je bij een gebouw relatief eenvoudig kunt zeggen welke muren, ramen en deuren er gezet moeten worden en via welke gangen je ergens terecht kunt komen, weet je bij software meestal niet welke schermen, knoppen en navigatie je wilt hebben. Vaak kan dit met software ook op 100en verschillende manieren opgelost worden, waar je bij een gebouw een stuk minder mogelijkheden hebt. Ook is de impact van het plaatsen van een deur of muur op het gebruik daarvan veel duidelijker dan de impact van keuzes in softwareoplossingen op de bedrijfsprocessen en gebruikers van de systemen. Toch moeten de functionaliteiten van een softwareapplicatie in zekere mate duidelijk zijn bij de start van een project, want waarover maak je anders afspraken?

Overeenkomsten op basis van nacalculatie geven vaak, wanneer het erop aan komt, geen garantie op de invulling daarvan. Hierdoor hangt de samenwerking nauw samen met het vertrouwen in de andere partij. Controle op uitgaven en budgetten is er vaak niet, er kan enkel afgeknepen worden als de limieten zijn bereikt. Liefst wil je de leverancier een meetbare resultaatverplichting aan laten gaan. Pas als er een huis is met woonkamer, slaapkamer, keuken en alle daarbij horende aansluiting voor gas, water, elektriciteit etc. is het project opgeleverd en wilt de opdrachtgever betalen voor hetgeen dat is opgeleverd.

Wanneer vanuit het gebruikersperspectief wordt gekeken naar een softwareapplicatie is het mogelijk om functionaliteiten te benoemen op een vaste en te controleren manier. FSM methodes zijn ISO gecertificeerd en er zijn richtlijnen opgesteld, zoals de Nesma Functiepunt telrichtlijnen. Door unieke functionaliteiten te benoemen en te tellen wordt het mogelijk om iets te zeggen over de omvang van een applicatie. Zoals een architect of aannemer al een idee krijgt bij de omvang en kosten van een huis zodra de volumes en oppervlaktes bekend zijn, zo kan een IT projectmanager of software ontwikkelaar een idee krijgen van de omvang, kosten en doorlooptijd zodra deze functionele omvang in FP bekend is.

Omvang bepalen is geen moeite

Traditioneel werden IT projecten op een watervalmethode aangepakt, en zo worden projecten nog steeds vaak uitgevoerd. Pas als de ontwerpfase 100% gereed is wordt aan de realisatiefase begonnen. De ontwerpfase, waarin de functionele omvang bekend wordt in uitgebreide ontwerpen, is hierbij vaak een langdurig proces. Bedrijven en processen veranderen en vaak wijzigen de wensen en eisen aan het ontwerp van de software dan ook tijdens het opstellen van het ontwerp. Een groot gebouw waarbij de ontwerpfase een jaar duurt hoeft geen probleem te zijn want de wensen en eisen hiervan zijn statischer. Er moet in softwareprojecten dus een balans gevonden worden tussen het detailniveau van de ontwerpen en de doorlooptijd van het opstellen van de ontwerpen. Er zijn verschillende detailleringen mogelijk van de functiepunttellingen welke ieder een bepaalde nauwkeurigheid hebben. Het is mogelijk om in een fractie van de ontwerptijd, in enkele dagen of zelfs uren, al een indruk te krijgen van de functionele omvang van grote applicaties. De verdere detaillering die nodig is voor de realisatie van de functionaliteiten kan later plaatsvinden.

Andere aspecten zoals kwaliteit en afwerking

Net zoals er met het aantal vierkante meters gerekend kan worden bij het bouwen van een huis, kan er gerekend worden met het aantal functiepunten van software. Er kunnen in een woonkamer van 45m2 nog altijd mooie marmeren vloertegels gelegd worden, of een praktisch klik-laminaat. Op dezelfde manier kan van een rapportagefunctionaliteit van 20FP de gebruikersinterface en rapporten er grafisch mooi en afgewerkt uitzien, of voldoende om te functioneren en enkel de data weer te geven. Ook kan de garage van het huis een plat dak hebben zodat er nog een verdieping op kan komen, net zoals software gebouwd kan worden met uitbreidbaarheid in het achterhoofd. De omvang is in beide gevallen duidelijk, de hoeveelheid werk en de kosten kunnen nog variëren op basis van de keuzes die gemaakt worden. Als opdrachtgever weet je in ieder geval dat je ermee kunt wat nodig is. De afwerkopties in softwareprojecten zijn nog altijd lastiger te communiceren dan in bouwprojecten, mede doordat software veel abstracter en minder tastbaar is, maar door de omvang inzichtelijk en meetbaar te maken kunnen veel problemen met projectschattingen en daaruit volgende afspraken en overeenkomsten, aangepakt worden.

Afspraken over resultaat, kosten, kwaliteit en productiviteit transparant en bespreekbaar

Wanneer de functionele omvang van softwareapplicaties bekend is kunnen op basis hiervan afspraken gemaakt worden over de andere aspecten. Het is voor alle betrokkenen duidelijk welk resultaat verwacht wordt. Hoe snel en productief een leverancier is, maakt in principe niet meer uit voor de opdrachtgever, dat is iets waar de leverancier zich mee bezig mag gaan houden. De kwaliteit van de leverancier zijn werk en de snelheid waarmee hij dit doet wordt ineens een stuk transparanter. De oorzaken van grote (prijs)verschillen tussen leveranciers kunnen verklaard worden. Het is zichtbaar wanneer een leverancier minder, of andere, functionaliteiten zal realiseren. Ook zijn afspraken over de kwaliteit en afwerking van de producten apart bespreekbaar gemaakt.

Schatten blijft lastig

Met deze aanpak, waarbij de omvang van een softwareproject duidelijk vast te stellen is, zijn de verschillen met het bouwen van een huis een stuk kleiner. Feit blijft echter dat het schatten van softwareprojecten nog altijd een lastige opdracht is door de andere dynamiek in softwareprojecten. Ook is de in dit artikel voorgestelde functiepuntmethode geen oplossing voor alle problemen die gerelateerd zijn aan projectschattingen. Het (beginnen) introduceren van functiepunten heeft in onze ervaring echter wel een groot aantal voordelen waar alle betrokken partijen iets aan hebben.

Mediaan heeft al meer dan 25 jaar ervaring met projectschattingen op basis van functiepunten. We maken de op te leveren producten transparant waardoor we projecten fixed-price en fixed-date uit kunnen voeren. Ook bieden we onze opdrachtgevers de mogelijkheid tot het volgen van cursussen om de functiepuntmethode binnen enkele uren te leren begrijpen en toe te passen in projecten. Mediaan voert als onafhankelijke partij ook controle-tellingen uit in andere projecten van opdrachtgevers. Neem contact met ons op voor meer informatie.