SaaS Begroting en projectrapportage

De begroting van SaaS projecten klopt in veel gevallen niet. Daarom moeten we die tussentijds bij kunnen stellen. Er zijn echter momenten waarop we cruciale beslissingen nemen over een project, namelijk na elke projectfase. Dat is niet alleen het moment om de stand van zaken van het project op te nemen en een tussenrapport te schrijven, maar ook om de activiteiten die nog moeten komen opnieuw te begroten.

Dit zijn de momenten waarop het projectteam met de opdrachtgevers om tafel moet om met elkaar beslissingen over het project te nemen. Het zijn ook de momenten waarop we het SaaS project, waar nodig, kunnen bijsturen. Als bijvoorbeeld blijkt dat er na de requirementsfase veel nieuwe eisen boven zijn geaccepteerd, kan het dat een project veel duurder uitvalt. Het heeft dan het echter weinig zin om door te gaan met de bestaande begroting.

De momenten waarop we dit soort beslissingen nemen zijn vaak ook ‘go-no-go-momenten’, momenten waarop we besluiten of we definitief doorgaan met het project of dat we er mee stoppen.

Belangrijke beslismomenten bij een SaaS project

Wat vaak gebeurt bij organisaties die niet met faseringen van projecten werken, is het volgende: in het begin wordt een projectplan geschreven, waarin de projectdriehoek wordt beschreven. Er is een tijdpad uitgezet, er is een begroting opgesteld en de projectscope is beschreven. Tevens is het projectteam geformeerd en zijn de hulpmiddelen voor de informatievoorziening in en rond het project zijn bepaald.
Tijdens het project zal de projectleider nog wel controleren of het project enigszins binnen het totale begroting en tijdpad blijft. Hij of zij stuurt dit echter niet echt bij. Tegen het einde van het project blijkt het allemaal toch weer duurder te worden of langer te duren dan verwacht. Om te voorkomen dat het nóg veel duurder wordt of langer duurt, knijpt de opdrachtgever het project af. Het projectresultaat is daardoor helaas niet echt naar tevredenheid.

Had de projectleider echter wel op de deliverables gestuurd, dan had het team waarschijnlijk al tijdens de software selectie of misschien al na het opstellen van de requirements geconcludeerd dat het oorspronkelijke tijdpad en begroting onvoldoende zou zijn. Als de projectleider dan had ingegrepen, hadden we voor een eenvoudigere oplossing kunnen kiezen dat sneller en goedkoper te realiseren was. Of we hadden om meer tijd en/of geld kunnen vragen bij de opdrachtgever. In ieder geval was er al eerder duidelijkheid geweest over de status van het project. Er zou sprake zijn geweest van het daadwerkelijk bijsturen van ons SaaS project.

Onzekerheid in de begroting

Onzekerheid hoort bij software projecten. Als we het project starten weten we niet precies hoeveel tijd we nodig zullen hebben, of hoeveel geld het project gaat kosten. Bij innovatieve projecten is het zelfs onzeker of we het beoogde doel überhaupt zullen bereiken. Daarnaast komt het soms ook voor dat in een snel veranderende wereld de verwachtingen van een project al verouderd zijn voordat een project klaar is. Bijvoorbeeld door technologische vernieuwingen of ontwikkelingen in de markt of politiek.

Bij het schrijven van een projectplan kan de projectleider slechts schattingen maken op de driehoek van een project. Schattingen over tijd, geld, kwaliteitsdoelen, benodigde informatie en het team. Pas door het project uit te voeren ontstaat er meer kennis over het project zelf.

• In de initiatiefase beperkt het project zich nog tot een idee.
• Tijdens de requirementsfase bakenen we het idee verder af door middel van concrete eisen en wensen.
• In de selectiefase zijn de mogelijke oplossingen onderzocht waardoor er weer meer duidelijk is.
• Na de implementatiefase weten we hoe onze requirements gerealiseerd worden.
• Bij de invoering is het daadwerkelijke projectresultaat gebouwd en nemen we de software in gebruik.

Onzekerheid neemt af naarmate het project vordert

Dus hoe verder het project is, des te meer duidelijkheid er ontstaat. Daarom heeft het geen zin om bij de start van een project een nauwkeurige begroting te maken voor de nazorg die pas na de invoering plaatsvindt. Het project kan nog alle kanten op en het idee is nog nauwelijks uitgewerkt. We weten dan waarschijnlijk ook pas op hoofdlijnen hoe de nazorg er uit komt te zien. We hebben echter te weinig informatie om een realistische budget voor nazorg te kunnen maken. Een begroting op hoofdlijnen is op dat moment dus het maximaal haalbare.

We volgen daarom deze werkwijze in onze projectplannen: We maken telkens een globale begroting voor het hele project en daarnaast een concrete begroting voor de eerstvolgende activiteit. Als een projectteam bijvoorbeeld op het punt staat om de invoering te starten (na de implementatie), is het goed bekend uit welke werkzaamheden deze fase bestaat. Pas op dat moment is het mogelijk een nauwkeurige begroting van de invoering te maken.

De globale projectbegroting voor het hele project zullen we dus na elke fase moeten bijstellen. Na elke fase is er meer bekend en zijn er beslissingen genomen waardoor we de globale begroting exacter kunnen uitwerken. Op die manier maken we na elke fase de totale begroting van het project steeds nauwkeuriger.

De begroting verfijnen

Het maken van een globale begroting voor het hele project en een concrete voor de eerstvolgende fase is niet alleen van belang voor het financiële aspect van het project. Ook voor de andere factoren van de project driehoek geldt dat we van globaal naar concreet werken.

Samenvatting voor het maken van de begroting

• Begroting vindt plaats vóór iedere fase.
• De globale begroting voor het hele project telkens bijstellen.
• Concrete begroting maken voor de volgende fase.
• Alle projectaspecten moeten we opnieuw bekijken en begroten voor een nieuwe fase.

Door op deze manier te begroten (met name van tijd en geld) gaan we realistisch om met de onzekerheid van ons SaaS project. Die onzekerheid is groter bij de start en kleiner aan het einde van een project. Deze werkwijze levert echter wel een probleem op voor organisaties die gefinancierd worden door overheidssubsidie en/of maatschappelijke fondsen. Dit probleem geldt met name voor organisaties die innoverende en dus onzekere projecten doen.

De meeste fondsen en subsidieverstrekkers eisen namelijk een complete en vaststaande begroting van een projectvoorstel vóórdat zij overgaan tot financiering. Het gevolg is dat, als we een project gefinancierd willen krijgen al in het begin een exacte begroting moeten maken. Op dat moment is het project echter pas in de ideeënfase. Op dat moment is het helemaal nog niet mogelijk een reële kostenschatting en een tijdpad te maken.

Kantelpunt na selectie

Pas na de software selectie, als we weten hoe ons idee nader is uit te werken, is er met voldoende nauwkeurigheid te zeggen hoeveel het project zal gaan kosten en hoe lang het gaat duren. Dat moment is in de meeste gevallen echter pas enkele maanden na aanvragen van de subsidie.

Het gevolg van soort subsidieprocedures is dat veel organisaties een subsidie aanvragen op basis van een onnauwkeurige begroting van de projectkosten. Vervolgens moeten we de projectactiviteiten vaak verminderen naar het verkregen budget. Dit zet het projectteam helaas al klem bij de start van een project. Als we echter van globaal naar concreet werken is op dat moment juist nog veel flexibiliteit nodig.

Her-begroting

Tijdens het uitwerken van het idee in de requirementsfase en de selectiefase blijkt vaak dat het tijdpad in de subsidieaanvraag niet haalbaar is. De begroting is niet passend. Soms te veel voor sommige posten maar meestal te weinig voor andere posten. Als de subsidieverstrekker dan ook nog eens eist dat we bijvoorbeeld niet meer dan 5% van de posten mogen afwijken, komt het projectteam onder grote druk te staan. De implementatie moeten we dan realiseren binnen een te kleine begroting en in te korte tijd. Het leidt dan weer tot een hoop geschuif met posten. In de projectverantwoording is vervolgens veel tekst en analyses nodig waarom het gewenste resultaat niet is bereikt.

Als subsidieverstrekkers de financiering zouden koppelen aan de verschillende fases (in plaats van het hele project in één keer vooraf te financieren) is deze situatie is te verbeteren. De initiële financiering zou dan bijvoorbeeld zijn voor het doorlopen van de requirementsfase en de selectiefase. Met een eerste beperkte begroting bepalen we eerst de requirements en maken we een shortlist met een aantal alternatieve SaaS oplossingen. Op basis van deze shortlist doen we dan een vervolgaanvraag voor de implementatie, de invoering en de nazorg. Op deze manier zetten we projecten niet onnodig onder druk. Bijkomend voordeel is bovendien dat de verwachtingen van betrokken partijen een stuk realistischer zullen zijn. Deze aanpak scheelt dus tijd, geld en teleurstellingen.

Discussieer mee op LinkedIn.