Definieer het deliverable voordat je uren schat
Voor een vaag woord als website, campagne, integratie of redesign kun je geen verdedigbare schatting maken. Beschrijf eerst het waarneembare resultaat: pagina’s, toestanden, formaten, integraties, apparaten, aangeleverde content, goedkeuringsproces en acceptatiecriteria.
Schrijf voor elk deliverable een korte definitie van klaar. Als twee redelijke mensen kunnen verschillen over de vraag of het werk af is, is de scope nog niet specifiek genoeg om te schatten. Nu verduidelijken is goedkoper dan discussiëren wanneer het budget al op is.
- Wat wordt opgeleverd en in welk formaat
- Wat de klant moet aanleveren en wanneer
- Welke apparaten, browsers of platforms ondersteund moeten worden
- Hoeveel concepten, varianten en revisierondes zijn inbegrepen
- Wat expliciet buiten de schatting valt
Verdeel het werk in brokken die klein genoeg zijn om te toetsen
Splits het deliverable in taken die meestal één tot acht uur duren. Een taak als bouw de applicatie in 60 uur verbergt te veel aannames. Authenticatie, accountstatussen, formulier-validatie, responsive layout, analytics en deployment kunnen afzonderlijk worden geschat en gecontroleerd.
Scheid herhaalbaar werk van onzeker werk. Een pagina op basis van een bestaande componentbibliotheek heeft niet hetzelfde risico als een ongedocumenteerde externe integratie. Door alles in één getal te stoppen laat je bekend werk het onbekende subsidiëren.
Gebruik driepuntsschattingen voor onzekere taken
Noteer voor een taak met echte onzekerheid een optimistische, meest waarschijnlijke en pessimistische duur. Een praktische gewogen schatting is: verwachte uren = (optimistisch + 4 × waarschijnlijk + pessimistisch) ÷ 6.
Stel dat een integratie 4 uur kost als documentatie en toegang kloppen, waarschijnlijk 8 uur en 20 uur als de API lastig doet. De gewogen schatting is 9,3 uur. De formule haalt onzekerheid niet weg; ze voorkomt dat het optimistische scenario stilletjes het officiële plan wordt.
Als het pessimistische scenario het project zou breken, verstop het dan niet in een percentage. Bied betaalde discovery, een urenfase of een beslismoment aan voordat je je vastlegt op een totaalprijs.
Tel verborgen werk en klantafhankelijkheden mee
Productietijd is maar een deel van de levering. Discovery, meetings, statusupdates, bestanden voorbereiden, feedback verwerken, testen, toegankelijkheidscontroles, overdracht en deployment kosten capaciteit. Als ze nodig zijn, horen ze in de schatting.
Afhankelijkheden hebben een eigenaar en deadline nodig. Wachten op toegang of content levert misschien geen factureerbare uren op, maar kan de opleverdatum verschuiven en dure contextwissels veroorzaken. Leg vast wat er gebeurt als input te laat komt in plaats van te doen alsof de planning immuun is voor de werkelijkheid.
- Discovery, onderzoek en verduidelijking van requirements
- Projectmanagement en gebundelde klantcommunicatie
- Contentvoorbereiding, migratie of datacleaning
- Kwaliteitscontrole, toegankelijkheid en apparaattests
- Inbegrepen revisies, deployment en overdracht
- Directe kosten en gespecialiseerde onderaannemers
Rekenvoorbeeld: kleine website-update
Een refresh van een website met vijf pagina’s vraagt 4 uur discovery en structuur, 10 uur design, 22 uur implementatie, 8 uur content en kwaliteitscontrole, 5 uur communicatie en overdracht en 5 uur voor de inbegrepen revisieronde. Het gedefinieerde werk komt op 54 uur.
Een CRM-integratie blijft onzeker. De driepuntsschatting is 4, 8 en 20 uur en levert 9,3 verwachte uren op. Voeg alleen voor deze onzekere taak een vasteprijsbuffer van 20% toe: 1,9 uur. Het planningstotaal komt uit op ongeveer 65 uur, niet 54 en niet een willekeurige 70.
Intern bewaar je de schatting per taak. In het klantvoorstel toon je deliverables, aannames, inbegrepen revisies, prijs en planning. Uren zijn bewijs voor je beslissing; ze hoeven geen proces-verbaal te worden dat aan elk voorstel hangt.
Maak van elk afgerond project betere schattingsdata
Registreer werkelijke tijd in dezelfde categorieën als de schatting. Noteer na oplevering waar het verschil vandaan kwam: onduidelijke requirements, klantvertraging, technische verrassing, herstelwerk of simpelweg een te optimistische schatting.
Na meerdere projecten kun je generieke buffers vervangen door je eigen bandbreedtes. Misschien blijkt implementatie voorspelbaar, terwijl content en goedkeuringen dat niet zijn. Dat is waardevolle operationele informatie en nuttiger dan online vragen hoe lang een website hoort te duren.
- Vergelijk geschatte en werkelijke uren per taak, niet alleen totaal
- Noteer de oorzaak van elke relevante afwijking
- Werk herbruikbare taaktemplates bij na oplevering
- Laat grote schattingen door een andere professional controleren vóór toezegging
Maak van de methode een echte raming
Verdeel het werk in taken, voeg tijd en tarieven toe en maak een duidelijke raming voor de klant.
Open de gratis calculatorVeelgestelde vragen
Hoeveel buffer moet ik op een projectschatting zetten?
Er is geen universeel percentage. Benoem de onzekere taken en voeg tijd of kosten toe voor die risico’s. Als onzekerheid het project domineert, kies dan betaalde discovery of urenwerk in plaats van een grote verborgen buffer.
Wat als ik geen historische projectdata heb?
Begin met een gedetailleerde taakverdeling, gebruik driepuntsschattingen voor onbekend werk, laat aannames door een collega challengen en scheid discovery van uitvoering als de bandbreedte te groot is.
Moet ik elke geschatte uur aan de klant tonen?
Niet per se. Houd details intern en toon duidelijke deliverables, aannames, grenzen, mijlpalen, prijs en het proces voor wijzigingen.
