Tips nodig bij inschatten van uren IT-projecten

[peer1979]

Ben al verschillende jaren werkzaam als zelfstandige ondernemer in de IT. Ik bouw allerlei maatwerk PHP-applicaties, modules en webshops. Maar met één ding blijf ik moeite houden: Inschatten van het aantal uren. Het probleem zit hem in de maatwerk en de variatie. Ik bouw zelden tweemaal dezelfde zaken.

Wat is nou een goede methode om een realistische inschatting te maken van het aantal uren?

Vroeger ging ik voor grotere projecten elk scherm/stukje functionaliteit langs en hing daar een gevoelsmatige aantal uren aan. Vervolgens deed ik dat aantal uren keer 1,4 - 1,6, afhankelijk van de complexiteit. Tegenwoordig doe ik het wat sneller (op een kladje), maar het gaat gewoonweg te vaak mis (lees: het kost meer tijd).

• Wat is nou een goede methode om tijd (snel) in te schatten?
• Hoe 'verkoop' je uitloop aan de eindklant? Of neem je het verlies?

[bregweb]

Ik denk dat de factor 1.4/1.6 een beetje natte vingerwerk is, of heb je daar een stevige onderbouwing voor? Is het niet gewoon een idee om die factor op te hogen? Gebruikers worden veeleisender, dus ook het maatwerk vereist meer werk.

Het is en blijft een inschatting en als je merkt dat je continue te laag zit, moet je dat wat ruimer inschatten.

Een tip is misschien om het maatwerk in meerdere kleinere stappen op te leveren, minder werk is beter in te schatten

[ Voor 14% gewijzigd door bregweb op 18-12-2017 11:11 ]

[Daan_]

Eerste vraag die bij mij opkomt, waarom kost het meer tijd?
* veranderd de vraag van de opdrachtgever gaande weg. (requirements)
* of heb je zelf gaande weg onderdelen niet voorzien?
* hoe is het contact gaande weg deze projecten/opdrachten. Laat je tussentijds resultaten zien (demo's etc etc...) Of ga je aan de slag en kom je bovenwater, zodra alles klaar is?
* etc etc

[Ascension]

Het allerbelangrijkste is een hele duidelijke scope af te spreken en vast te leggen samen met je klant. Het komt namelijk heel vaak voor dat de scope gedurende een project af gaat wijken van wat is afgesproken, dat is niet zo erg natuurlijk maar als je duidelijke afspraken hebt gemaakt kan je daar ook naar verwijzen aan geven dat het meerwerk is tegen x-uurtarief.

[peer1979]

bregweb schreef op maandag 18 december 2017 @ 11:09:
Ik denk dat de factor 1.4/1.6 een beetje natte vingerwerk is, of heb je daar een stevige onderbouwing voor? Is het niet gewoon een idee om die factor op te hogen? Gebruikers worden veeleisender, dus ook het maatwerk vereist meer werk.

Het is inderdaad natte vingerwerk. Ik kan inderdaad de factor omhoog brengen, maar omdat dan de bandbreedte groter wordt (x-y uur werk), is het lastiger te verkopen. Daarnaast is het commercieel een probleem, ik loop door te hoge schattingen werk mis.

Mijn ideaalplaatje zou inderdaad zijn: Dit project kost tussen de 100-500 uur werk en vervolgens specifiek worden over de kleinere stapjes. Maar dat is een hard sell.

Superdaantje schreef op maandag 18 december 2017 @ 11:20:
Eerste vraag die bij mij opkomt, waarom kost het meer tijd?
* veranderd de vraag van de opdrachtgever gaande weg. (requirements)
* of heb je zelf gaande weg onderdelen niet voorzien?
* hoe is het contact gaande weg deze projecten/opdrachten. Laat je tussentijds resultaten zien (demo's etc etc...) Of ga je aan de slag en kom je bovenwater, zodra alles klaar is?
* etc etc

Heb beide problemen wel gezien. Verandering in vraag kan ik gelukkig verklaren en verkopen. Maar het is vaker zo dat ik werk onderschat (in uren) of simpelweg niet alles voorzie. En ik heb regelmatig contact met opdrachtgevers, ook als het lastig wordt.

Ascension schreef op maandag 18 december 2017 @ 11:21:
Het allerbelangrijkste is een hele duidelijke scope af te spreken en vast te leggen samen met je klant. Het komt namelijk heel vaak voor dat de scope gedurende een project af gaat wijken van wat is afgesproken, dat is niet zo erg natuurlijk maar als je duidelijke afspraken hebt gemaakt kan je daar ook naar verwijzen aan geven dat het meerwerk is tegen x-uurtarief.

Vroeger was ik daar vrij extreem in, maar dat koste bij grotere projecten soms wel dagen / enkele weken. En die tijd kan je niet berekenen (is mijn gedachte in elk geval). Of doe je dat wel?

[BLACKfm]

Een klant houdt natuurlijk wel van vaste prijzen, maar is op regiebasis werken niet een optie?

Als je zelf de uren niet goed inschat dan is dat mijn inziens het probleem van de opdrachtnemer (TS dus).
Dat je de 'meerwerk-factor' niet in je prijs vooraf wilt steken is dan je eigen risico. Als je stelselmatig te veel uren maakt in eigen tijd (je kunt ze niet doorberekenen omdat je zelf een lager inschatting hebt gemaakt), zou ik net zo hard zeggen dat je stelselmatig je uren wat op moet plussen.

Dat je dan duurder wordt is een nadeel voor je klanten en succes in het aannemen van klussen. Maar je bent óf te goedkoop óf te duur.

Mogelijk een hybride oplossing? De omschreven klus voor een maximumprijs insteken? Werkzaamheden binnen opdracht kosten maximaal 5000 euro (voor jezelf is de factor 1,4-1,6 hier al in berekend) en geeft aan de klant aan dat het bij meevallende uren ook 4000 euro kan worden.

Een klant weet dan in ieder geval waar die aan toe is en krijgt mogelijk nog een korting mee en jijzelf hebt sowieso de kosten gedekt.

[Basszje]

Bij een vorige werkgever deden we 'realitsche' schatting + 10% standaard. De 10% was voor klantgezeur, onderhandelen over niet-gemaakte afspraken etc ( een klant wil achteraf altijd iets anders )

- Naar mate ervaring weet je ongeveer hoe lang je bezig bent met een onderdeel. Neem gemiddelden van oude projecten en maak daar een excel van, zodat je makkelijk kan rekenen.

- Zorg voor optimale mogelijkheden voor codehergebruik en factuur dat in een project a 70% oid.

- Als je uit je uren loopt maar er zijn onderdelen afgesproken, kan je dat altijd nog compenseren met niet-afgesproken werk / meerwerk als de klant daarom vraagt.

- Werk met milestones. Lever een basis op voor de klant met een strakke inschatting. En na de basis extra opties voor X uur. Als er eenmaal wat staat is het ook veel simpeler de rest in te schatten.

- Bij het opstellen van offertes kijk naar de technische kwaliteit van een klant. Klant X weet veel over internet, en automatisering, Klant Y weet het verschil niet tussen browser of web. De ene klant heeft *veel* meer tijd nodig om te komen van business probleem -> technische oplossing en de kans op teleurstelling / 'dit is niet wat ik had verwacht', of ' ons factuursysteem werkt helemaal niet met primary keys' is veel groter.

Als het echt standaard niet lekker loopt, wellicht moet je dan ook eens kijken naar studie-opties. Er zijn wel wat boeken en studies te vinden over projectmanagent, management van verwachtingen en wat niet meer.

Leren van een klantprobleem een abstract model van programmeerbare modules te maken met realistische inschatting en dat terugcommuniceren als een product is op zich een vak apart

offtopic:
En je wil niet elke opdracht hebben. Als ik kijk naar freelance opdrachten ala ' bouw facebook voor 500 dollar en we worden samen rijk ' dan mjah

[ Voor 26% gewijzigd door Basszje op 18-12-2017 12:49 ]

[Yucon]

Ascension schreef op maandag 18 december 2017 @ 11:21:
Het allerbelangrijkste is een hele duidelijke scope af te spreken en vast te leggen samen met je klant. Het komt namelijk heel vaak voor dat de scope gedurende een project af gaat wijken van wat is afgesproken, dat is niet zo erg natuurlijk maar als je duidelijke afspraken hebt gemaakt kan je daar ook naar verwijzen aan geven dat het meerwerk is tegen x-uurtarief.

Dit is een hele goede. Het geeft de klant daarnaast ook duidelijkheid over wat er geleverd gaat worden. En vergis je niet, dat is voor klanten vaak een heel onzekere factor.

[P_Tingen]

Bij een ruwe schatting ga ik meestal in redelijk tempo door de requirements heen, maak een globale schatting en doe die keer pi. Waarom pi? Omdat het net zo goed is als elk ander getal en het in de praktijk redelijk goed uitkomt.

Als dat niet acceptabel is, hak ik het werk net zo lang in deelblokjes op tot elk deelblokje concreet is gespecificeerd is en max 2 uur werk is. Waarom 2 uur? Omdat het dan voor mij beter in te schatten is of ik het echt in 2 uur af kan krijgen. Daarnaast is - als je eenmaal met de klus bezig gaat - al na 2 uur te zien of je voor of achter op schema loop. En vergis je niet, dat bedoel ik niet als grapje of zo. Als je het boek The Mythical Man Month van Fred Brooks hebt gelezen, dan herken je misschien de quote

"How does a project get to be a year late? … One day at a time.".

En als je het boek niet hebt gelezen kan ik het van harte aanraden, maar dat is een ander verhaal.

Als je direct weet of - en hoeveel - je uitloopt heeft dat als voordeel dat je voor jezelf leert waar je niet goed in kan schatten en naar je opdrachtgever dat hij mogelijk wat langer moet wachten op jouw output.

Als je je werk van te voren niet in blokjes van 2 uur is in te schatten, bijvoorbeeld omdat er veel onduidelijk is, is het project niet geschikt voor een fixed price. Je kunt dan beter technieken als Scrum gebruiken waarbij je opdrachtgever je op basis van je uren betaalt en na elke iteratie bepaalt of het goed genoeg is.

[johnwoo]

Ik ben ook zelfstandig ondernemer in de IT (iets meer dan 10 jaar) en ook in dezelfde hoek (maatwerk webapps). Ik heb hier ook mee geworsteld, hier mijn bevindingen:

1. Zoals gezegd, maak vooraf requirements duidelijk. Focus daarbij vooral op functionele requirements en stel een lijst met use-cases op van wat klant allemaal kan doen met zijn webapp. Ga niet al vooraf proberen elk scherm/detail uit te denken, want vooral met maatwerk is dat niet te doen: het kost enorm veel tijd en je vindt toch niet alle uitzonderingen (of soms valkuilen) die je pas tegenkomt bij het daadwerkelijk ontwerpen/maken van de software (tenzij je echt al een detailontwerp doet als onderdeel van een betaald offertetraject en je deze uren dus ook al kunt rekenen). Deze fout maakte ik vroeger teveel. Maak in je offerte duidelijk dat het om functionele zaken gaat en dat cosmetische details zoals kleurtjes, fonts, exacte positionering van elementen (waarover vooral MKB nog wel eens wil vallen) erbuiten vallen, of reken dat mee in je marge.

2. Pak vervolgens een factor/marge zoals je nu al doet, maar houd voor jezelf wel een urenregistratie bij! Na elk project stel je dan die factor bij zodat je mettertijd steeds nauwkeuriger wordt met je offertes. Uiteraard zal ervaring ook helpen met het überhaupt beter inschatten van de benodigde tijd, maar zo'n feedback loop in je factor beschermt je in elk geval enigszins tegen het geven van te lage (maar ook te hoge) offertes.

3. Probeer een groot project, of iets wat de klant wellicht niet ineens nodig heeft, op te splitsen in modules of subprojecten die apart (en liefst sequentieel, niet tegelijk) uitgevoerd kunnen worden. Je kunt dan op de aparte modules een wat gunstiger marge hanteren dan wat op het complete pakket als geheel mogelijk zou zijn.

Een voorbeeld van dit punt: stel je hebt een tweeledig product waarvoor je zelf op €15.000 uitkomt, maar het tweede deel kan best als uitbreiding gebouwd kunnen worden. Stel je factor is 1.5. In plaats van dit project als geheel voor €22.500 te offreren, kun je het beter als €10.000 + €5.000 splitsen en een iets hogere marge pakken (bv. 16.500 + € 8.000 offreren). Het totaal komt daarmee €2.000 hoger uit, maar omdat er lagere bedragen staan lijkt het voor "het gevoel" minder (of in elk geval behapbaarder). Klanten kunnen hier gevoelig voor zijn. Bovendien geeft het een mogelijkheid om het eerste (vaak grootste) deel sneller "af te kunnen sluiten".

4. In opvolging van punt 1 over de cosmetische details: overweeg om samen te werken met een ontwerper/ontwerpbureau of tekstschrijver, om jezelf op de techniek te kunnen focussen en het vele meer/nawerk over kleine details in het ontwerp te voorkomen. Of market jezelf nadrukkelijk als professional (behalve op technisch- ook op ontwerpgebied) en geef de klant hooguit 2 of 3 alternatieven en/of de mogelijkheid tot wat kleine variatie, maar geen ellenlang natraject. Market jezelf als professional en geef aan dat men vertrouwen kan hebben in de manier waarop je een webapp ontwerpt. Jij bent tenslotte degene met de ervaring die weet wat wel en niet werkt. Met name bij kleine bedrijfjes (ondernemers die gewend zijn zelf de regie over alle details van hun zaak te hebben) kun je wel eens onverwacht veel nawerk hebben op detailniveau.

5. Probeer waar mogelijk om werk uit een vaste-prijs offerte te halen en variabel facturabel te maken (uurtje factuurtje). Met name cosmetische details en support zijn hiervoor geschikt (met als argument dat het aantal van deze uren vooral van de klant afhangt), maar soms krijg je ook kleinere na-projecten (die achter het hoofdproject geplakt worden b.v. als men tijdens het hoofdtraject nieuwe requirements verzint) wel op uurbasis verkocht.

Afhankelijk van de complexiteit van de te bouwen software en het kennisniveau bij de klant calculeer ik wel tijd in om instructie te geven, maar er zijn mensen die het wel makkelijk vinden om vervolgens alsnog verzoeken tot wijzigingen (die ze zelf met het product ook kunnen doen) op de mail te blijven zetten. Dat soort dingen moet je dan ook gewoon rekenen; je bent developer, geen webmaster! Daarbij heb je minder kennis binnen het specifieke vakgebied van je klant. Uiteraard meld je dit soort dingen wel vooraf in je offerte.

Of, als het kan met het project in kwestie, gebruik überhaupt een facturering op basis van tijd (voor het hele project dus) ipv fixed price, zoals hierboven al werd opgemerkt. Zeker met wat grotere projecten in opdracht van c.q. in samenwerking met bedrijven die zelf ook wat IT-kennis in huis hebben, is dat wel doable, omdat zij het werk zelf al beter kunnen inschatten. Bij kleine klanten zonder IT-kennis gaat dat doorgaans wat moeilijker, die willen toch vooral vooraf weten waar ze aan toe zijn en zullen niet snel akkoord gaan met een factuur voor meerwerkuren. In dat geval moet je commercieel zijn, je verlies pakken en zo snel mogelijk de requirements afwerken zodat je in elk geval geen slechte mond-op-mondreclame krijgt. Met ZZP/kleinbedrijf klanten is netwerken en goede mond-op-mondreclame de beste manier om aan werk te komen.

[MagicTempest]

Wat wij vaak doen is het design los verkopen van de daadwerkelijke realisatie. Het maken van een design is iets wat je (na een aantal keer) redelijk in kan schatten qua doorlooptijd. De klant krijgt er iets tastbaars voor terug en jij hebt een veel duidelijkere basis om een correcte ureninschatting te kunnen maken.

Er zullen klanten zijn die het vervelend vinden om op die manier te werken, maar dat is over het algemeen goed uit te leggen door te vertellen dat het ontwerp voor iedereen voordelen heeft. Beide partijen weten hoe het resultaat er uit komt te zien en krijgen een realistische prijs.

Mocht de klant het alsnog niet willen dan kan uurtje-factuurtje natuurlijk ook altijd :-)

[pirke]

Als je structureel te laag zit moet je structureel hoger gaan schatten. Reken met een factor 2 ipv 1.4-1.6.

Dat klanten je dan te duur vinden, tja nu vind jij jezelf te goedkoop. Je zal altijd weerstand krijgen als je je effectieve uurtarief verhoogd. Dus als jij je huidige effectieve uurtarief niet toereikend vind zul je het linksom of rechtsom moeten verhogen.

En door meer uren te schatten is het makkelijker om de deadline te halen, wat weer minder stress oplevert.

[peer1979]

Allereerst, hartelijk dank voor al jullie reacties. Top dat jullie meedenken, hier heb ik heel veel aan. Zoals ik aangaf, inschatten van software-ontwikkeling ben ik zwak in en het kost me teveel geld. Ik was gelukkig al wel duidelijk in requirements en heb geen probleem in het factureren van meerwerk

Ik vat dit alles samen en wil de volgende zaken voor mezelf aanpakken:

• Bijhouden planningen + verbeteren factor
• Grotere projecten -> deelprojecten
• Factor verhogen naar 2 - 3 (dus als ik 100 uur inschat wordt het tussen de 200-300 uur)
• Variabele zaken zoals design op basis van nacalculatie (uurtje / factuurtje)
• Bekijken welke onderdelen ook geschikt zijn voor variabele uren
• Lezen over plannen / projectmanagement, ik ben op zoek naar wat goede boeken.

Is er wellicht ook een website / serious game / etc. waar je het schatten van dit soort projecten kunt oefenen? Dus dat je een voorbeeld project ziet en dat andere ontwikkelaars hun inschatting geven.

Bedankt allemaal!

[pirke]

Schatten in software development is nooit accuraat. Toen ik zelf teamleider was deed ik altijd een factor 2 op de schattingen vd teamleden voordat ik commitment richting het project gaf, en meestal was dat ook wel nodig. De projectleider deed daar vaak nog 25% bovenop voordat hij commitment gaf richting de business unit. En de business unit zet er weer marge op voor commitment richting de klant. Elke laag bouwt zijn eigen marge in. Zolang iedereen op tijd oplevert is er niks aan de hand, maar als je afhankelijk bent van iemand anders wil je marge voor het geval de ander z'n beloftes niet nakomt, het hebben van marge betekent dat niet automatisch dat jij je beloftes ook niet nakomt

In een team schatten is overigens heel anders dan als je individueel wat moet schatten. Als je 10 teamleden laat schatten, en 75% vd schattingen zit op X story points, een paar erboven en een paar eronder, dan zal het wel ongeveer rond X liggen. Story points zijn ook geen uren, maar staan in verhouding tot eerder werk. Een vergelijkbaar feature zal ongeveer een vergelijkbare hoeveelheid werk zijn. De velocity geeft dan aan hoe lang het daadwerkelijk gaat duren, en de velocity is ook van persoon tot persoon anders: iemand die 2x zo snel werkt zal het in de helft vd tijd doen, maar de hoeveelheid werk (in story points") is hetzelfde.

[iamcj]

Je kunt ook uitleggen waarom ict projecten vaak mislukken. Jij en de klant spreken af wat ze willen in de vorm van requirements, scope etc. Dit is gewoon een verkapte watervalmethode. De klant krijgt of niet wat hij wil, gaat lopen zeuren en jij gaat meerwerk vragen of jij gaat door je budget.

Met maatwerk weet de klant pas wat hij echt wil als hij op de knoppen heeft gedrukt. Biedt aan om eerst een design/prototype te maken en lever iedere 4 weken nieuwe functionaliteit op. Testen -> nieuwe requirements -> ontwerp -> sprint +1 bouwen. Als de klant het te duur vind worden, kan hij stoppen met een bruikbaar product. Een sprint kost x. Dan kun je een indicatie geven hoeveel sprints je denkt nodig te hebben. Dat dat niet uitkomt maakt toch niet uit en is altijd uit te leggen aan de hand van nieuwe requierements.

Uiteindelijk krijgt de klant wat hij nodig had, niet wat hij wilde en is nog goedkoper uit ook.

Haal technische uitdagingen met prototyping naar voren, communiceer.

Als die klant dit niet wil, moet jij de klant niet willen. Op die klanten verlies je altijd geld.

[Lethalis]

Ik gebruik hiervoor in grote lijnen een functiepuntanalyse.

Simpelweg: welke functies omvat het project en hoeveel tijd ben je per functie kwijt?

De truc is iig om het project zoveel mogelijk in kleine stukjes op te delen waarvan je de omvang beter kunt inschatten.

Vervolgens tel je alles bij elkaar op en dan komt er nog een marge bij en je zal goede afspraken moeten maken over de oplevering.

Bijvoorbeeld dat alle aanpassingen na goedkeuring / oplevering per uur worden betaald.