Het is vaak moeilijk om grote software realisatieprojecten goed te begroten. Leveranciers laten vaak een expert een begroting maken, maar de praktijk heeft laten zien dat deze altijd te optimistisch ingeschat worden en dat dit een belangrijk struikelblok vormt voor het falen van softwareprojecten. Bruikbare abstracties om een vinger achter de productiviteit van applicatieontwikkeling te krijgen in een complex project lijken niet voorhanden te zijn. Of zijn ze er wel als je anders kijkt?[/vc_column_text][/vc_column][/vc_row]

Tijdens de IT Confidence 2015-conferentie in Italië kwam ik een interessant idee tegen om betere beslissingen over grote softwareprojecten die zeker ook interessant zijn voor projectmanagers. Voordat ik van wal steek eerst een korte uitleg over deze bijeenkomst en het aanwezige publiek. De IT-Confidence conferentie gaat over het verzamelen van data rond grote softwareprojecten en het benchmarken ervan door eigen projecten te vergelijken met vergelijkbare projecten van andere organisaties. In 2015 vond de derde editie plaats, georganiseerd door de Italiaanse Function Point User Group / Italiaanse Software Metrics Association (GUFPI-ISMA) in Florence.

Een van de meest interessante en nieuwe ideeën die ik tegenkwam was het concept ‘Triangle Benchmarking’ van consultant Pekka Forselius uit Finland. De meesten projectmanagers zijn vertrouwd met het concept van de ‘Iron Triangle’. In een driehoek plaats je de omvang, de duur en het beschikbare budget van een veranderingsprogramma elk op een punt om in te kunnen schatten of de projectaannames realistisch zijn en het project succesvol zou kunnen zijn. Google maar eens op Iron Triangle en je zult heel veel voorbeelden vinden.

Het principe van dit soort driehoeken is dat projecten altijd onder deze beperkingen tot stand komen. Zo is tijd altijd een bepalende beperking, omdat er een deadline is om een project af te ronden. De beperkingen in de kosten bepalen hoeveel budget of menskracht er is om de projectdoelstelling te realiseren. De projectomvang tenslotte geeft aan wat er moet gebeuren om het eindresultaat van het project te kunnen halen. Deze drie factoren vechten om schaarste: een grotere projectomvang betekent meestal meer tijd en hogere kosten, een strakke deadline brengt juist hogere kosten of een kleinere scope met zich mee en een krap budget betekent meer tijd of een kleinere projectomvang. Evenwicht in die dimensies zorgt dat het project de gewenste kwaliteit krijgt en productief zal zijn. Dit maakt deze driehoek tot een grafisch hulpmiddel dat drie essentiële dimensies uit een complex project kan abstraheren de van een project goed weergeeft.

De boodschap is natuurlijk dat deze beperkende factoren ook de dynamiek van complexe softwareprojecten bepalen. Als je één van de dimensies verandert, moet tenminste één van de andere dimensies ook meebuigen, omdat anders de kwaliteit van het project eronder lijdt. De driehoek kan tal van vormen aannemen, afhankelijk van verschillende variabelen. Forselius heeft op deze manier het concept van Triangle benchmarking toegepast op afgeronde softwareprojecten zoals in onderstaande voorbeelden te zien is.

Fast and Productive

Shit happens

Fast but Expensive

Government Typical

Deze vier driehoeken tonen de resultaten van verschillende softwareprojecten. Het laat zien hoe belangrijk het is om de omvang van een softwareproject op een kwantitatieve manier weer te geven, net zoals je dat met tijd en budget doet. Een gangbare manier om die projectomvang en de hoeveelheid te leveren functionaliteit te berekenen is het inschatten of tellen van functiepunten in de software. Het is een objectieve eenheid die meetbaar en herhaalbaar is en duidelijk is voor de klant en de leverancier.

Een ander voordeel is dat een ‘statement of work’ uitgedrukt in het aantal functiepunten organisaties ook de mogelijkheid biedt om de eigen softwareprojecten te vergelijken met vergelijkbare projecten uit een omvangrijke database. De International Software Benchmarking Standards Group (ISBSG) beschikt over een database van meer dan 7500 softwareprojecten die in te zetten is om de productiviteit in grote softwareprojecten in te schatten en te beoordelen.

Forselius stelt voor om de volgende eenheden te gebruiken bij het tekenen van driehoeken:

• 1 cm = 200 functiepunten
• 1 cm = 100.000 euro of 1.000 uur
• 1 cm = 3 maanden

Op deze manier kun je driehoeken trekken en deze vergelijken met bijvoorbeeld industrie specifieke driehoeken uit de ISBSG-database, zoals hierboven in het voorbeeld van softwareprojecten bij overheidsinstellingen. Forselius voegt een andere normatieve dimensie aan zijn driehoeken toe door het opnemen van kleuren. Deze kleuren laten zien welke verhoudingen goed, normaal of slecht zijn. Net als bij verkeerslichten is rood slecht, geel ok en groen is goed. Dit maakt het makkelijker voor projectmanagers om te doorzien welke softwareprojecten haalbaar en realistisch zijn en welke te ambitieus zijn. Op deze manier wordt het mogelijk om visueel te laten zien of scope, tijd en budget van je softwareproject realistisch zijn. Hetzelfde geldt voor de toezeggingen van leveranciers. In een oogopslag is te zien of deze realistisch of te rooskleurig zijn.

Dit maakt het concept van Triangle Benchmarking heel interessant. Door de vorm en de kleur van de driehoek zie je in een oogopslag of het project op een kostenefficiënte manier uitgevoerd is of tot stand zal komen in vergelijking met een relevante referentiegroep. Dus nu wordt de vraag waarschijnlijk: wat is de vorm van jouw driehoek? Heeft het de juiste vorm en kleur als je het naast vergelijkbare projecten legt?

METRI heeft veel ervaring en expertise in het bepalen van de realiteitswaarde van begrotingen van software projecten en het benchmarken van afgeronde software projecten. METRI kan u daarom helpen te bepalen welke vorm de driehoek van uw project is en of de vlakken van de driehoeken de groene, de gele of de rode kleur krijgen.