Betere prijscalculatie voor offerte met maatwerk.

[LittleBit]

Ha HL-vrinden,

 

Wij leveren producten waar we een prijscalculatie voor doen en waar we periodiek een nacalculatie voor doen. Uit deze prijscalculatie komen we wel uit.

 

We bieden diensten aan welke herhalend voorkomen, zodat we het truukje kennen en we weinig rsisico hebben. We zijn bereid daar een fixed prijs voor te bieden en we doen nacalculatie om te leren/corrigeren. Daar komen we ook wel uit.

 

Echter... er is een 3e gebied waar we actief zijn met Speciale maatwerk Ontwikkeldiensten,

waar klanten ons vragen dingen te maken die we nog nooit eerder gedaan hebben.

Het betreft vaak het ontwikkelen van specifieke software.

We hebben de mensen in huis met de vereiste basis-kennis maar ja... het blijft een eerste traject,

er blijven veel risico's en het blijft software met alle ontwikkelknelpunten.

We trachten -op klantverzoek- hier fixed prijzen aan te bieden maar dat is erg lastig.

Als we dan een nacalculatie doen zijn we soms flink nat

en daarbij leren we niks van die nacalculatie want de volgende keer is het toch weer anders.

We hebben getracht eerst een vooronderzoek te doen in het geval van dergelijke aanvragen

met een functioenele specificatie als tussendoel

zodat we beter zouden moeten kunnen calculeren.

Het resultaat is echter geen verbetering, vergelijk het met een specificatie van een auto

met bv "4 wielen, kofferbak, brandstofmotor, handrem, verlichting etc etc"

Deze specificatie kan vele bladzijden lang zijn en desondanks nog steeds een Suzuki of Mercedes zijn

en jullie snappen wel welke auto de klant dan verwacht en welke auto hij bereid is te betalen.

Moeten we dan maar een risico-factor in de prijsaanbieding gaan stoppen ?

Moeten we dan maar afstappen van fixed prijzen en alleen nacalculatie doen ?

 

Kortom.... hoe kunnen wij onze prijsaanbieding/calculatie voor eenmalige product ontwikkelaanvragen verbeteren ?

 

[Spaarvarken]

Geen expert op dit gebied maar het lijkt mij dat het per opdracht bekeken moet worden.

Verschilt namelijk in risico, calculatie & nacalculatie per opdracht en zoals jij al aangeeft het blijft een "eerste traject".

 

Wat je kan doen is de uren die gestoken worden in het technisch ontwerp, inventarisatie huidige situatie, testimplementatie en het Advies onder en fixed prijs laat vallen.

 

[djluc]

Herkenbaar probleem, ook wij gaan zeer vaak nat hiermee helaas. En dan nog is het qua communicatie lastig omdat een klant niet ziet hoeveel uren cq. geld het al heeft gekost.

 

Wij willen nu proberen zoveel mogelijk standaard blokken te maken. Dus alle zaken die je tegenkomt met herhaling in elk geval een vast aantal uren te geven. Dat gaan we dus historisch vergelijken.

 

In de praktijk bij een website zou onze calculatie op basis van historie dus iets zijn als:

 

Bekende onderdelen (uren zijn gemiddeld van verleden):

- Installatie framework 3 uur

- Aanmaken pagina 1 uur x 10 pagina's = 10 uur

- Installatie nieuwsmodule met vervolgpagina 2 uur

- Aanmaken RSS feed van nieuwsberichten 2 uur

 

Onbekende zaken

- Twitter updates automatisch publiceren n.a.v. nieuwsmodule

 

Voor de onbekende zaken maken we dan een specificatie en op basis daarvan doen we de gok inschatting zoals je nu ook al doet.

 

Omdat het dan hele kleine onderdelen zijn wordt het zo hopen wij eenvoudiger om die in te schatten en daarnaast worden er minder fouten gemaakt bij de vaste onderdelen omdat je die op historische kennis kan uitwerken.

[Jeroen Reith]

Dag LittleBit.

 

Herkenbaar alhoewel we in een andere branche opereren.

Bij mij bekruipt dan bij dit soort "onbekende" projecten altijd een onbestemd onderbuik gevoel omdat

je weet dat je deels in het duister tast.

 

Ik kan het met djuc eens zijn om dan maar zoveel mogelijk bekend items in blokken te begroten en te benoemen en daarnaast

probeer ik dan de onbekende zaken in regie uit te voeren of om die tussentijds gedurende het project te voorzien van een prijskaartje als de omstandigheden op dat moment meer duidelijkheid bieden.

 

Ik geef toe: het is soms spitsroeden lopen maar sommige klanten hebben begrip, dus er is hoop :).

 

Groet.

Jeroen

[djluc]

Wat bedoel je precies met je laatste opmerking? Dat begrip vind ik soms nogal mee vallen namelijk!

[Jeroen Reith]

Als je in offertes onderdelen niet fixed-price aanbiedt kan het soms zijn dat klanten dat niet accepteren. In die zin is het

soms lastig om hier mee om te gaan omdat jezelf niet helder hebt hoeveel uur/materiaal er gemoeid is met de klus en de klant

graag toch een fixed-price wil.

Groet.

Jeroen

[StefanO]

Ik maak ook gebruik van fixed price elementen voor afgebakende producten / fasen. Zo heeft een waarderingsrapport min of meer een vaste prijs (afh. van complexiteit varieert de fixed price).

 

Wat ook werkt is met vaste budgetten per fase werken. Gebruik ik ook bij interim & consulting projecten (mijn andere hobby). Per fase stel je een budget, oplevermoment en deliverables (scope) vast. Gedurende het traject bekijk je dan of je kosten in lijn zijn met je realisatie (cost performance index als je wilt Googlen) en idem voor je doorlooptijd (scheduled performance index). Voordeel is dat je afwijkingen zeer snel ontdekt waardoor je nog kunt bijsturen. Dat is essentieel in fixed price trajecten. Maar het kan ook zijn dat er of extra budget komt of minder scope wordt geleverd. Als sluitpost hanteer je een 'potje over' (contingency) dat enkel gebruikt kan worden indien vooraf gedefinieerde risico's zich voordoen. Een aantal grote risico's kan je vooraf al wel onderkennen en ook de impact wel enigszins schatten (€), alleen weet je niet of het zich daadwerkelijk zal voordoen. Als het optreedt, dan mag het geld worden besteed. Als het niet optreedt gaat het terug naar de opdrachtgever en is het NIET beschikbaar voor andere tegenvallers.

 

Bovenstaande klinkt misschien gekunsteld, maar het werkt echt en is ook in simpele vorm toepasbaar. Wordt voornamelijk bij grote projecten toegepast. Methode is ontleend aan project control (ook zoekwoord Google) methodieken en door Prince2, CMMI, PMBok, etc. geïnspireerd. Zelf heb ik het wereldwijd bij de ICT organisatie van Shell geïmplementeerd waar per jaar $ 3 miljard (!!) aan ICT projecten wordt uitgegeven. De besparing bedroeg daar circa 13% per jaar (tel uit de winst)...

 

Edit: met name het inbouwen van contingencies (ken NL term niet) is een mooi wapen in de pricing strategie. Vooraf lijkt het alsof je goedkoper bent (ben je ook echt als het mee zit). Concurrenten prijzen het risico impliciet in en zijn daardoor meteen al duurder dan jullie. Als het mee zit, heeft de klant teveel betaald (klant not amused). Als het tegenzit moet de concurrent maar hopen dat de inschatting voldoende was (meestal niet, want prijs voor risico is vaak hoger dan som van contingencies). Als het bij de contingency benadering tegenzit, kan je terug naar de opdrachtgever om extra budget te vragen omdat er een risico is opgetreden dat niet vooraf kon worden onderkend. Om die reden moet je altijd samen met de opdrachtgever de contingencies opstellen (wat een K woord).

[John B]

Hallo LittleBit,

 

Mijn ervaring is dat bij een nacalculatie vaak alleen gekeken wordt naar de verschillen in kosten, eventueel per deelproject of per activiteit. In jouw geval lijkt mij een uitgebreide projectevaluatie meer rendement opleveren. Wat had jij oorspronkelijk voor ogen, hoe is dit vastgelegd in de specificaties, welke nieuwe inzichten ontstonden tijdens het traject? Welke keuzes zijn er gemaakt, op welke momenten en hoe zijn die gecommuniceerd naar de klant? Kwam jij tijdens het trajct zelf met aanvullende ideeën, of kwam de klant daarmee? Welke ideeën van de klant had jij ook al voorzien en welke kwamen als een verrassing?

 

Menig project loopt uit en kost meer door de manier waarop omgegaan wordt met expectation management en change management? Want waarom denkt die klant aan een Mercedes en jij aan een Suzuki (om jouw voorbeeld maar even te gebruiken)? Is dat omdat jij denkt dat die Mercedes te duur is en de klant dan afhaakt? Dan begroot je dus die Suzuki en worstel je tijdens het traject voortdurend met het verwachtingspatroon van de klant, die uiteindelijk toch - op jouw kosten - die Mercedes krijgt. Of iets daartussenin, waarbij jij ontevreden bent over de kosten en de klant over het resultaat.

 

Je zou bij de begroting of bij het opstellen van de functionele specificaties eens kunnen analyseren welke keuzes en aannamen je daarbij maakt. Je begroot/specificeert bijvoorbeeld "4 wielen" en denkt daarbij aan standaard wielen met goedkope wieldoppen. Maar waarom denk je initieel niet aan lichtmetalen velgen?

 

Drie mogelijkheden:

1) Je denkt er wel aan, maar je vindt die overbodig voor dit traject of te duur, of het past niet in de planning qua doorlooptijd; dan kun je bij je offerte al die keuze aan je klant voorstellen. Een soort lijstje met "meerwerk" dus.

2) Je hebt er geen ervaring mee en kunt dus geen inschatting maken van de kosten, voorzichtigheidshalve kies je voor de bekende weg, waarbij je wellicht al kunt voorzien dat je t.z.t. die keuze zult moeten aanpassen; kun je dat niet aan de klant voorleggen en die post dan eventueel als nacalculatie offreren?

3) Je komt er pas achter tijdens het traject of bij oplevering; de klant krijgt bijvoorbeeld tussen- of eindresultaten te zien, komt erachter dat het geen Mercedes wordt en spreekt jou daarop aan. Wat doe je dan? Voel je je schuldig omdat je de klant "maar" een Suzuki hebt aangeboden en werk je dan alsnog naar die Mercedes toe?

 

Net zoals je een potje kunt reserveren voor risico's, kun je ook zo'n potje maken voor wijzigingen. Je onderkent samen met de klant dat het ondoenlijk is voor dit soort maatwerk om alles tot in detail te specificeren en dat dat ook tot aanzienlijk hogere kosten en een langere doorlooptijd voor het ontwikkelen van de specificaties leidt. Dus voor de specificaties begroot je een hoeveelheid geld en tijd, je accepteert dat er tijdens het traject wijzigingen en aanvullingen komen en komt samen met de klant tot een plafondbedrag hiervoor. Dan hoef je op het moment zelf met de klant alleen te discussieren over de zinvolheid van de wijziging en niet meer over het budget daarvoor. En de klant ziet op een gegeven moment het potje kleiner worden en past daar zijn verwachtingen op aan. Zo snijdt het mes aan twee kanten.

 

Het kan natuurlijk zijn dat je het met de klant niet eens wordt of iets een wijziging is of niet. Wellicht dat je dan nog een van de risico-potjes kunt aanspreken zoals door Stefan aangegeven. Al met al zul je een gedeelte van de tegenvallers op deze wijze een plekje kunnen geven. En door de nacalculaties en projectevaluaties goed te documenteren zul je misschien op een gegeven moment toch gaten gaan onderkennen in de manier waarop je werkt. En dan gaat het leerproces werken.

 

Groet,

 

John

[LittleBit]

een 'potje over' (contingency)

 

Als ik je goed begrijp is dit dus een stelpost voor open items.

 

[djluc]

een 'potje over' (contingency)

 

Als ik je goed begrijp is dit dus een stelpost voor open items.

 

Niet echt toch? Het zijn verwachte problemen toch? Bijvoorbeeld: Een project waarbij vooraf gedacht wordt dat op manier x een probleem opgelost kan worden maar dit blijkt toch niet zo te zijn?

[willemj]

We hebben getracht eerst een vooronderzoek te doen in het geval van dergelijke aanvragen met een functioenele specificatie als tussendoel

zodat we beter zouden moeten kunnen calculeren.

 

Het resultaat is echter geen verbetering, vergelijk het met een specificatie van een auto met bv "4 wielen, kofferbak, brandstofmotor, handrem, verlichting etc etc" Deze specificatie kan vele bladzijden lang zijn en desondanks nog steeds een Suzuki of Mercedes zijn

 

Wat voor techniek / methode gebruik je voor dit vooronderzoek? Met wat formele ontwerptechnieken (klinkt fancy, valt erg mee) moet je echt een héél stuk verder kunnen komen dan 'vier wielen en een kofferbak'. Als de oorzaak van de extra tijd voornamelijk zit in foute uitgangspunten qua ontwerp bij het begin van de ontwikkeling zou ik me daar eens in verdiepen. (In tegenstelling tot keuzes als verkeerd platform, database, hardware etc. Die zijn vast ook te modelleren maar daar heb ik geen ervaring mee)

[LittleBit]

@Willem

> Met wat formele ontwerptechnieken

Blijkbaar denk je hierbij aan wat technieken.

Wil je uitspreken wat je in gedachten hebt ?

 

[StefanO]

Beetje laat, maar contingencies zijn zeker geen stelpost of een potje over voor algemene tegenvallers. Dat is de grootste blunder die je hiermee kunt begaan.

 

Contingencies mogen ALLEEN worden aangewend indien het risico zich manifesteert. Als het zich niet voordoet, valt het geld vrij aan de klant.

 

Voordeel is dat het je dwingt om vooraf over risico na te denken. Zo kan je ook tijdig adequate maatregelen treffen en snel anticiperen. Projecten lopen daardoor veel minder uit En dat is wel handig bij fixed price!

[willemj]

> Met wat formele ontwerptechnieken

Blijkbaar denk je hierbij aan wat technieken.

Wil je uitspreken wat je in gedachten hebt ?

 

Ik heb de theorie meer dan tien jaar geleden geleerd en heb daar in de praktijk m'n eigen mix van gemaakt. Daarom moet ik je de exacte 'vaktermen' schuldig blijven. Wat termen:

 

Textual Analysis (ooit geintroduceerd door Abbott en/of Booch) Grofweg: je leest een tekst en bepaalt wat het onderwerp, de aktie en eventuele participanten zijn. Je stelt je daarbij continue de vragen wie, wanneer, wat, waarom, hoe. Je ontdekt hiermee eenvoudig vragen die niet beantwoord zijn door een interview met je klant.

 

CRC cards. Class-responsibility-collaboration cards. Zit in dezelfde hoek als textual analysis. De links op de wikipedia pagina geven een aardig idee.

 

Als nodig kun je een stap verder gaan en wat technischer modelleren. Ik gebruik hiervoor UML diagrammen. Dat is de tool. Naam van mijn techniek bestaat niet ;)

 

Het boek 'The object primer' van Scott Ambler geeft een aardige introductie in analyse en software design.

[John B]

Contingencies mogen ALLEEN worden aangewend indien het risico zich manifesteert. Als het zich niet voordoet, valt het geld vrij aan de klant.

Toch zijn er ook wel constructies waarbij het geld niet vrijvalt aan de klant. Je kunt je contingencies begroten en de kans van optreden van de betreffende risico's inschatten. Die vermenigvuldig je dan met elkaar. Dus als je een risico hebt van 25k en de kans dat dat risico optreedt schat je in op 50%, dan kom je op een contingency bedrag van 12,5k. Je telt die bedragen bij elkaar op en dat is de risico-toeslag die je op je fixed price project zet. Als je het betreffende risico zodanig onder controle houdt dat het niet optreedt, dan heb je door die inspanning 12,5k verdiend, treedt het alsnog op, dan heb je 12,5k verloren.

 

Je kunt e.e.a. ook combineren. De risico's die je zelf voor een groot deel kunt managen behandel je op deze manier, voor de risico's die voornamelijk beinvloed worden door de klant maak je potjes die weer vrijvallen aan de klant wanneer ze niet gebruikt zijn. Zo motiveer je ook de klant om de risico's te managen.