Van fixed price naar fixed budget

7 april 2015

In mijn ruim 15 jaar in de softwareontwikkeling heb ik vaak van opdrachtgevers dezelfde vraag gekregen en beantwoord: ‘Wat kost dat nou?’.

Eigenlijk zijn er maar twee mogelijke antwoorden:

  1. Je noemt een bedrag dat lager ligt dan het bedrag dat de opdrachtgever zelf voor ogen had (je hebt een stuk complexiteit over het hoofd gezien).
    Gevolg: Je vindt jezelf terug in een dramatisch project.
  2. Je noemt een bedrag dat hoger ligt dan het bedrag dat de opdrachtgever zelf voor ogen had (je ziet complexiteit die de opdrachtgever niet ziet).
    Gevolg: Je krijgt geen project, want je bent te duur.

De uitkomst voor de opdrachtnemer is dus 1) een dramatisch project of 2) geen project….

Voor de opdrachtgever is de uitkomst wellicht nog slechter: Je bent bij een leverancier uitgekomen die je een leuke prijs kon noemen, maar die dus nu aan een voor hem dramatisch project werkt. Goedkoop wordt duurkoop.

Maar gelukkig kan het anders.

Dilbert

Geen tijdsinschatting

Eind 2012 begon Woody Zuill een discussie op twitter met de hashtag: #NoEstimates. Zijn eigen blog over softwareontwikkeling zonder tijdsinschattingen lag hieraan ten grondslag. Een wereldwijde discussie kwam op gang.

Voorstanders, zoals de wetenschapper Aaron Santos, vinden dat softwareontwikkeling eigenlijk veel meer lijkt op wetenschappelijk onderzoek:

“An equivalent question from my field would be, ‘Estimate the amount of time it will take for us to discover what dark matter is.’ I have no idea how long that will take! With problems we’ve never faced before, the usual techniques of estimation don’t always work.”

Of zoals Zuill zelf zegt:

“Let’s stop trying to predict the future,” he says. “Let’s get something done and build on that - we can steer towards better.”

Voor een verdere en betere uiteenzetting van de voor- en tegenstanders verwijs ik naar het blog van Scott Rosenberg (Backchannel): Estimates? We Don’t Need No Stinking Estimates!

Al met al is de discussie levendig en steeds meer mensen begrijpen het no-estimate-principe.

Toch krijg ik nog steeds die vraag: ‘Wat kost dat nou?’.

Het is onmogelijk om hierop een definitief antwoord te geven. Fixed-price-projecten zijn wat mij betreft sowieso uit den boze. Gewoon niet doen, want er blijft altijd een partij berooid achter. Dit is al eens goed verwoord in het blog van onze conculega Salsita SoftwareWhy We Don’t Do Fixed-Price Software Projects (And Neither Should You). Ik sta daar volledig achter.

Fixed price, time, scope of budget

Maar we kunnen de vraag van onze opdrachtgevers ook niet onbeantwoord laten. Je wilt namelijk wel kunnen budgetteren, ook voor jezelf. Je wilt je ergens aan vasthouden, in elk geval iets dat fixed is. En daar ligt volgens mij nu juist oplossing: doe je project niet fixed price, maar fixed budget. Bij Enrise doen we dat al een paar jaar, met succes.

Samen met de opdrachtgever stellen we een budget op, waar eigenlijk maar één vraag aan ten grondslag ligt: Wat wil je er aan uitgeven? Een businesscase is natuurlijk een goed uitgangspunt om deze vraag te beantwoorden. Vervolgens is het zaak om:

  1. Een oplossing te bedenken die past binnen het gestelde budget
  2. Tijdens de ontwikkeling continue inzichtelijk te hebben of het budget toereikend is.

Ook op andere gebieden stel je namelijk een budget op waarvan je nog niet weet of het toereikend is. Denk aan de verbouwing van je pand, de marketinguitgaven voor komend jaar, etc. Het is waarschijnlijker dat het niet toereikend is voor de oplossing die je gaandeweg verlangt. Maar je wilt wel een richtlijn hebben maar dus ook de mogelijkheid hebben af te wijken.

Het is belangrijk om (real-time!?) inzicht te hebben in de besteding van het budget en de prognose van het beoogde doel binnen het gestelde budget. Is het niet haalbaar, dan stuur je bij. De oorzaak is irrelevant, want in een goede relatie van opdrachtgever en opdrachtnemer is er vertrouwen en de wil om samen het project tot een succes te maken. Niemand vertraagt moedwillig je project (tenminste, daar mag/moet je van uitgaan).

Flexibele scope

Als je dus op budget werkt kan het zijn dat je door onvoorziene problemen en/of uitbreidingen van de initiële scope het beoogde budget niet gaat halen. Opdrachtgever en opdrachtnemer moeten daarin dan een gezamenlijk keuze maken hoe hiermee om te gaan in relatie tot het budget. Belangrijk is dat de keuze gezamenlijk wordt genomen.

Dilbert

Dus: Inschattingen heb je nodig om een budget op te stellen. Maar het blijven inschattingen. In de wereld van softwareontwikkeling biedt dit vrijwel geen zekerheid. Beschouw het als een feit dat de scope tijdens een project wijzigt. Altijd. Gegarandeerd.

Het is zaak om niet tegen een veranderende scope te vechten, maar het juist te omarmen en gezamenlijk een team samen te stellen dat optimaal met deze scopeverandering om kan gaan.

Een flexibele scope is de beste garantie voor een succesvol project. En succes wordt nog altijd bepaald aan wat is opgeleverd, nooit aan wat het heeft gekost heeft… Of zoals de familie Gucci het eens verwoordde:

“Quality is remembered long after the price is forgotten”.

PS: Wil je lezen hoe we bij Enrise een projectbudget opstellen? Lees het blog van mijn collega Kai: The Agile Estimation Game

Goed leesvoer?
Abonneer op en ontvang 1x per maand onze artikelen en video's in je mail.
Tech+More

Abonneer op en ontvang 1x per maand artikelen en video's per mail.

Ik wil Tech+More!
->
© 2000-2020, Enrise B.V.