Budgetteringstechnieken: back to basics

De laatste maanden werden de ICT-departementen belaagd met budgetdiscussies. De bedrijfspolitiek is in gesprekken rond geld en mandagen nooit ver af. Om het gesprek een objectieve basis te geven, dringt het management vaak aan op het gebruik van standaardbudgetteringstechnieken. Functiepuntanalyse, use case point estimation, WBS- en LOC-based bieden de houvast van een industriestandaard. Maar uit interviews met project managers blijkt dat ze vaak worstelen met de basisconcepten van deze technieken.

Zo is een functiepunt, bijvoorbeeld, geen intuïtief herkenbaar gegeven in een IT-project. Vele projectverantwoordelijken kiezen dan ook voor een ‘back-to-basics’ aanpak en ontwikkelen hun eigen variant. Daarbij mag men dan wel enkele essentiële principes en bouwstenen niet uit het oog verliezen.

DRIE FAMILIES VAN BUDGETTERINGSTECHNIEKEN
Een IT-budget wordt vanuit verschillende invalshoeken bepaald. Er bestaat dan ook een breed assortiment aan technieken. Je kan ze grosso modo in drie grote families indelen: activity based estimation, product based estimation en tenslotte de vergelijkende analyse. Activity based estimation wordt typisch gebruikt in de opstartfase van een project, bijvoorbeeld tijdens een RFP (Request for Proposal) of een voorstudie. In die fase heeft de projectleider nog weinig gestructureerde informatie rond de beoogde functionaliteit. Daarom wordt teruggegrepen naar een activity breakdown. In essentie komt het erop neer dat de activiteiten van het project worden uitgelijst en voorzien van een budget. Hoe gedetailleerder deze breakdown, hoe correcter de budgetinschatting. In dit artikel concentreren we ons op de familie van de product based estimation technieken. Die technieken veronderstellen het bestaan van een volledig overzicht van de beoogde functionaliteit.

Daarom wordt PBE pas later in een project toegepast. Pas wanneer je een goed overzicht hebt van de services, processen, functies of use cases van je project, kan je een PBE-techniek toepassen. Volledigheidshalve lichten we nog even de laatste familie toe: de vergelijkende analyse. Op basis een benchmark van projecten wordt het budget bepaald. Dit veronderstelt een database met een indrukwekkende hoeveelheid projecthistorische informatie. We gaan dieper in op de familie van product based estimation technieken (PBE). Bij een juiste toepassing van enkele basisprincipes kunnen deze technieken een interessant accuracy level voorleggen (zie figuur 1).

EEN FEATURE
Een PBE grijpt terug op een volledig overzicht van functionaliteiten. En daar nijpt al snel het schoentje bij de standaardtechnieken. In projecten die starten vanuit een BPM-oefening wordt deze basis gevormd door het geheel van elementaire processen. In andere zijn services of use cases die basiselementen.

Met een techniek zoals use case point analysis wordt de basis beperkt tot use cases en actoren. Daarbij komt dan nog dat deze techniek vereisten stelt zoals het exhaustief in kaart brengen van alle actoren. Een volledige lijst van use cases volstaat niet. Bovendien heeft de projectleider de grootste moeite om het concept van een UC-punt uit te leggen. Om deze techniek onder de knie te krijgen moet je al snel enkele uren of dagen training achter de kiezen hebben. De projectleider die onder druk staat om een objectief en toch intuïtief begrijpbaar budget voor te leggen, neemt daarop enkele abstracties en ontwikkelt zijn eigen variant.

Er bestaat dus een hele waaier aan product based estimation technieken en nog veel meer lokale varianten. Gemeenschappelijk aan al die technieken is hun basis van unieke en elementaire processen, services, use cases en functionaliteiten. We geven deze ‘basis-dingen’ de algemene naam features. Een PBE-variant die in afwijking van de standaardtechniek teruggrijpt naar herkenbare features is perfect aanvaardbaar, zolang het principe van de volledigheid gerespecteerd blijft.

EEN VOLLEDIGE LIJST VAN FEATURES
Nemen we features in de vorm van use cases als voorbeeld, dan moet de featureslijst vijf soorten features afdekken: operationele use cases, resource use cases, management use cases, applicatie-ondersteunende use cases en applicatie- gemeenschappelijke use cases. Operationele use cases en resource use cases zijn de meest gekende. Een voorbeeld van de eerste is ‘maak faktuur’ of ‘bevestig levering’. Resource use cases bepalen dan weer het beheer van basisresources.

‘Beheer productenbestand’ is een typische. De management use cases vormen een volgende laag. Zij doen de planning, controlling en analyse van de operationele en resource use cases, zoals ‘rapporteer belastingen’ of ‘budgettering verkoop’. Applicatie-ondersteunende use cases zijn bijvoorbeeld ‘set-up’, ‘conversie’ of ‘back-up’. En tenslotte hebben we nog applicatie-gemeenschappelijke use cases.

Dit zijn generieke of framework services, zoals de ‘security service’, ‘de vertaalservice’ of de ‘output service’. Samen vormen deze use cases de scope van het project en de uitgangsbasis voor het budget. Het is belangrijk om weten dat use cases slechts één soort feature zijn. Ook elementaire processen en services kunnen een goede basis vormen voor een PBE, zolang ook deze features consistent en volledig de functionaliteit afdekken.

DE VIER BOUWSTENEN VAN EEN BUDGETTERINGSTECHNIEK
Heeft het project een duidelijke en volledige basis van features, dan kan de budgetberekening beginnen. We onderscheiden vier belangrijke bouwstenen in de berekening: packaging, complexiteit, de omgevingsfactor en het aandeel van het support budget.

EERSTE BOUWSTEEN: PACKAGING VAN FEATURES
Budgetten verworden snel tot goedbewaarde mysteries, diep ingegraven in de onontwarbare logica van een Excel sheet. Om een budget werkbaar te maken is het dus belangrijk om de lange lijst van features te groeperen in herkenbare packages. Daarvoor grijp je terug naar algemeen gekende basisdocumentatie in het project. Het domeinconceptmodel is zo’n handig referentiedocument voor packaging. Andere voorbeelden zijn de contextdefinitie en de scopestudie van het project.

TWEEDE BOUWSTEEN: DE TWEEDIMENSIONALE COMPLEXITEIT VAN FEATURES
Een feature heeft een bepaalde complexiteit. Men onderscheidt meestal twee soorten: complexiteit uit de businesslogica en userinterfacecomplexiteit. Een feature kan beide bevatten, maar ze moeten duidelijk van elkaar onderscheiden worden. De complexiteit bepaalt het basisgewicht van de feature in termen van mandagen. Om te weten hoe complex een feature is, moet je vele indicatoren bekijken. Het aantal stappen van een use case is er zo één. Maar ook de complexiteit van berekeningen en het aantal alternatieve flows van de use case maken die meer of minder complex.

Op het einde heb je een feature met een lage, gemiddelde of hoge businesslogica en/of userinterfacecomplexiteit. Voeg daarbij het aspect ‘nieuw’ of ‘gewijzigde feature’ en je eindigt met zes complexiteitscategorieën: nieuw/laag, nieuw/medium, nieuw/hoog, wijziging/laag, wijziging/medium en wijziging/hoog. Elke categorie krijgt een aantal mandagen opgeplakt voor businesslogica en voor userinterfacecomplexiteit. Pas die complexiteitscategorie toe op de feature en je eindigt met een aantal mandagen per feature. Het is raadzaam het resulterend aantal mandagen te checken met ervaringsdeskundigen. Dat geeft een eerste cross-check van je veronderstellingen.

DERDE BOUWSTEEN: DE OMGEVINGSFACTOR
Een project doe je niet alleen. De ervaring van het team en aspecten zoals de geografische verspreiding ervan bepalen de kost van het project. Daarnaast speelt de stabiliteit van de behoefteanalyse een rol, alsook de technische risico’s en de architecturale nieuwigheden die je project introduceert. Die omgevingsfactoren kunnen dus best meegenomen worden in de berekening.

Dat doe je door de mandagen van een feature met de omgevingsfactor te vermenigvuldigen. Standaard staat die op 1. Elke afwijking van de standaardpraktijken van het ICT-depar
tement wordt met een factor 0,05 bij deze standaardfactor bijgeteld of integendeel afgetrokken. Zo kan een ervaren technisch team compenseren voor een onstabiele behoefteanalyse en vice versa.

LAATSTE BOUWSTEEN: HET SUPPORT BUDGET
Tot nu toe spraken we enkel over de ontwikkelingsinspanning. Dat is het core budget en dekt de analyse, design, ontwikkeling en testing. Maar ook een projectleider moet betaald worden. En dan is er nog het budget voor architectuur, DBA, QA, deployment en deployment business. En dat budget kan flink oplopen.

Afhankelijk van het aantal stakeholders van het project en factoren zoals de totale duurtijd, kunnen supporttaken 30, 60 tot 100% aan het core budget toevoegen. De spreiding van dit support budget is bovendien verschillend voor elke organisatie. In vele technieken wordt het support budget pro ratio van de core-ontwikkeling toegekend. Dit is een goed uitgangspunt, maar die percentages moeten wel steeds aangepast worden aan de realiteit van het bedrijf en het type project.

EEN WERKBAAR BUDGETTERINGSINSTRUMENT
Eens het budget berekend is, komt de werkelijke test: de bespreking met het management. Jouw management wil het budget met 25% omlaag en jij wilt dit vertaald zien in een vermindering van de functionaliteit. Met een budget gebaseerd op herkenbare features ben je goed gewapend voor dergelijke discussies. Het gesprek beweegt zich dan niet langer op het niveau van metafysische uplifts en budget cuts, maar wordt direct inhoudelijk gevoerd. De oorspronkelijke discussie rond een percentage concentreert zich nu rond het budgettair gewicht van features en packages.

Indien je bovenvermelde principes volgt, doorstaat ook jouw eigen PBE-variant het wapengekletter van een budgetronde. En hopelijk kan je het management er alsnog van overtuigen om die 25% te behouden. Succes !

De auteurs van dit stuk, Eric Callebaut en Jan Bovend’aerde zijn inno.com consultants.