Kent u objectief uw projectstatus?

Heeft u een objectief beeld van de status van uw project? Vermijd het 90% syndroom!

Het realistisch begroten van software-realisatieprojecten blijkt in de praktijk vaak erg moeilijk te zijn. In een vorig blog heeft u kunnen lezen op welke manier het mogelijk is om een realistische begroting te maken. In de blog ‘Vier tips voor een realistische software begroting’ staat dat het uitvoeren van een methodische begroting, naast het uitvoeren van een expertbegroting, de kans op het opstellen van een realistische begroting significant vergroot.

Expertbegrotingen

Helaas maken in de praktijk veel organisaties toch enkel gebruik van de zogenaamde expertbegroting. Dit komt voornamelijk door een gebrek aan kennis van de fundamentele begrotingstheorie, waardoor de invloed van parameters als:

  • omvang,
  • doorlooptijd,
  • teamomvang,
  • snelheid van opbouw van het team
  • en gewenste kwaliteit

als niet relevant worden beschouwd. Expertbegrotingen zijn meestal (veel) te optimistisch en daarom gaan veel projecten met onrealistische verwachtingen van start. Dit resulteert erin dat een te klein team in een te korte doorlooptijd een bepaalde omvang aan functionaliteit moet realiseren.

Projectstatus 90%

90% Syndroom

Op zichzelf hoeft dit nog geen probleem te zijn, als er tenminste effectieve projectmanagementtechnieken zouden bestaan waarmee een project dat achterloopt op planning weer op schema gebracht kan worden. Helaas bestaan deze technieken niet en hier gaat het dus fout. De projectmanager weet niet dat zijn project achterloopt op schema, totdat het project al vrij ver gevorderd is. De teamleden rapporteren dat ze ‘bijna klaar’ zijn en houden deze status soms lange tijd vast. Dit wordt het ‘90% syndroom’ genoemd.

Meer fouten, meer werk

Op het moment dat men er achter komt dat het project achterloopt, is er vaak al weinig meer aan te doen. Door de alarmerende signalen vanuit het project ontstaat er vervolgens extra attentie van het hoger management en komt het project onder druk te staan, resulterend in meer fouten in het product. Meer fouten betekent meer werk, want fouten moeten worden gelogd, geanalyseerd, aangepast en opnieuw getest. En meer werk betekent hogere kosten.

Wet van Brooks

Een bekende grote projectmanagementfout is het toevoegen van extra projectteamleden aan een project dat al achterloopt. Hierdoor wordt het project aanzienlijk duurder en het is nauwelijks sneller klaar, om van de afname van de kwaliteit nog maar te zwijgen. Veel projectmanagers kennen deze ‘wet van Brooks’ maar toch wordt genoemde maatregel in de praktijk vaak toegepast, met de nodige ‘horror stories’ tot gevolg. Vaak gaat dit soort projecten ‘over de kop’, in die zin dat de kosten een stuk hoger uitvallen dan aanvankelijk begroot en de opleverdatum veel verder in de toekomst ligt dan aanvankelijk gepland.

Mate van effectiviteit

Bovengeschetste effecten waren te voorkomen geweest als gebruik was gemaakt van professionele methodes en tools voor projectbewaking. Er zijn tools op de markt die het mogelijk maken om, op ieder gewenst moment, op basis van actuele projectgegevens de status van een project op een objectieve manier te bepalen. Het gaat hierbij niet om de bestede uren versus de geplande uren, dat is voor iedereen eenvoudig na te gaan, het gaat om de mate van effectiviteit waarmee de uren zijn besteed. In feite gaat het om de hoeveelheid product die is opgeleverd op het moment van de meting versus de te verwachten hoeveelheid product op dat moment, op basis van de projectplanning.

Functiepunten

De hoeveelheid product wordt door middel van het vaststellen van het aantal regels code of van het aantal functiepunten (COSMIC of functiepuntanalyse) dat is opgeleverd na programmeurstest bepaald. Het gebruik van functiepunten heeft de voorkeur, omdat het vaststellen van de te verwachten hoeveelheid te realiseren functiepunten veel nauwkeuriger uitvoerbaar is dan het inschatten van het aantal regels code dat gerealiseerd moet gaan worden. De genoemde tools zijn in staat om, op basis van historische data, aan te geven hoeveel product er op ieder moment in het projectverloop afgerond zou moeten zijn om uiteindelijk te kunnen voldoen aan de projectplanning.

Inzicht in potentiële bedreigingen

Het tool vergelijkt de actuele projectgegevens met dat plan en kan vervolgens voorspellen, opnieuw op basis van historische gegevens, wat de te verwachten einddatum is, wat het te verwachten aantal uren is dat besteed gaat worden en hoeveel defects er naar verwachting nog in de code zitten bij oplevering. Door deze voorspelling vervolgens af te zetten tegen het originele projectplan wordt al in een vroeg stadium inzicht gegeven in potentiële bedreigingen voor het projectverloop.

'what if' scenario's

Sogeti neemt de verantwoordelijkheid voor het projectsucces van haar klanten en gebruikt daarom deze professionele tooling om lopende projecten te bewaken. Loopt een project achter op de planning, dan kunnen er direct ‘what-if’ scenario’s worden doorgerekend, waarmee inzicht wordt verkregen in het effect van potentiële bijsturingsmaatregelen. Dit geeft de projectmanager naast een beter beeld van de status van ook meer grip op het project. Daarnaast geeft het de stakeholders rondom het project meer vertrouwen en de overtuiging dat het goed komt met het projectresultaat.

Onderbouwde voorspelling

Sogeti raadt u aan om periodiek een thermometer te steken in uw risicovolle projecten. Hiermee verkrijgt u een duidelijk en objectief beeld van de status van uw project en een onderbouwde voorspelling van de daadwerkelijk te verwachten einddatum en kosten. Tevens kan het effect van een potentiële bijsturingsmaatregel worden getoetst. De kans op een ‘horror story’ wordt hierdoor tot een minimum gereduceerd en uw teams en stakeholders kunnen op een meer ontspannen manier hun werk doen, resulterend in betere software die ook nog eens beter onderhoudbaar is. En dit alles voor een relatief lage investering!

Wilt u meer inzicht in de status van een lopend software realisatie project, stuur dan een e-mail naar Harold van Heeringen, Software Cost Engineer.