Hvad er bedst for kunde og leverandør: fastpris eller timer og materialer (T&M)? Det har der været skrevet og sagt rigtig meget om – og realiteten er vel, at det afhænger af situationen, synsvinklen og relationen.
Lad mig slå fast, at Axcon leverer projekter på både fast pris og T&M. Men vi foretrækker og anbefaler så klart T&M af årsager, som jeg vil forklare her. Samtidig vil jeg gerne tage diskussionen, så kom endelig med din vinkel i kommentarene.
Ulykkeligvis er argumentationen lige negativ nok i formen, da T&M står frem som det bedste valg, udelukkende fordi fast pris er sådan en dårlig løsning.
Hvad er fast pris?
Fast pris på udvikling er en aftale, hvor kunde og leverandør aftaler en fast pris (typisk opdelt i 3-4 betalinger for opnåelse af delmål) for udvikling af et system til et givet niveau.
Det er en god forretning for leverandøren, hvis leverandøren kan udvikle det aftalte på kortere tid end det estimat, som ligger til grund for prisen. Der er flere måder at opnå dette på for leverandøren, hvor lavere udviklingskvalitet er en af de oplagte muligheder. Der er som bekendt forskel på et apparat der virker, og et apparat, der er i god ingeniørmæssig kvalitet. Stor forskel (se et konkret eksempel på et kinesisk modul der virker, men med en indbygget en svaghed).
Elektronik og software kan være mere eller mindre velforberedt for fremtidige udvidelser, forudseelige ændringer i komponenter, testbarhed, servicerbarhed, risiko ved softwareopdateringer i felten osv. Alle disse ting er del af det, vi kalder udviklingskvalitet. Det er hurtigere at se lidt stort på, for at komme frem til noget der virker i en fart.
Leverandøren vil i en fastprisaftale være økonomisk motiveret til at skære hjørner af, så det udviklede netop opfylder specifikationen – men ikke mere.
De mange trade-off’s mellem udviklingstid og den pris per enhed, som betales igennem produktion, levetid, support osv. kan også let forskyde sig i ugunstig retning for det totale projekt, hvis den økonomiske aftale motiverer leverandøren til at tage de hurtige løsninger på udviklingsdelen.
En ansvarlig leverandør vil naturligvis tage den løbende dialog med kunden omkring de små ændringer og ideer til forbedringer, som opstår undervejs i projektet. Men leverandøren finder hurtigt ud af, at den slags bliver til budgetforhandlinger. Ofte om mindre beløb, hvor fortjenesten ikke står mål med den tid, der reelt skal bruges på forhandlingen, ændringer i kontraktgrundlaget osv.
En fastprisaftale ligner en god aftale for kunden, hvis det udviklede viser sig at indeholde overraskelser, som gør at projektet tager længere tid og flere ressourcer end forventet. Men det er nok en illusion. Overraskelser i et udviklingsprojekt skal føre til at både de dyre konsekvenser og de mindre dyre konsekvenser overvejes – det er usundt at udlukke fixes af the root cause, bare fordi det gør ondt her og nu.
En anden ting er, at i praksis holder en fast pris kun, hvis leverandøren kan komme igennem projektet uden at tabe alt for meget på det.
Bliver leverandørens tab for stort, må der enten forhandles en ny pris eller leverandøren må opgive, nedprioritere eller på anden måde reducere indsatsen på projektet – det ender ofte efter mange lange forsinkelser i, at en ny leverandør må overtage projektet. Det er ikke attraktivt for nogle af parterne, men det er set flere gange. Specielt i situationer, hvor leverandøren har fejlvurderet opgaven – måske pga. manglende kompetencer. Vi ser de pinefulde situationer, når vi overtager projekter der er “kørt i hegnet”.
Hvad kræver fast pris?
I bund og grund er fast pris jo simpelt. Man specificerer hårdt, kontant og fyldestgørende hvad der skal udvikles – og til hvilken pris.
Vi er ved punkt A, og vi vil til punkt B. Hvad koster det at køre turen?
Med udviklingsopgaver er specifikationen af punkt B lidt mere kompleks. Og med de store beløb – ofte flere millioner kroner – som er på spil for leverandøren, når projektet nærmer sig aflevering, er det yderst vigtigt, at leverandøren kan bevise, at vi er ved punkt B.
Det hedder en testplan. Altså som leverandør må vi altid forlange, at have både en fyldestgørende specifikation og en testplan, som fortæller, hvad der skal udvilkes, og hvordan vi afgør om det er opnået.
Det er sund og fornuftig vandfaldsmodel tankegang at starte med at skrive en udtømmende specifikation og en testplan. Der ligger hurtigt et par mandemåneder i den opgave.
Med et typisk udviklingsprojekt, som kører 6-12 måneder fra idé til produktion, er det ikke bare hyppigt – men stensikkert – at der kommer ændringsforslag undervejs. Den omhyggeligt udarbejdede specifikation og til hørende testplan kommer ikke til at passe med det produkt, der udvikles. Det kan være ændringer, som giver bedre fremtidsmuligheder, lavere stykpris, bedre forsyningssikkerhed eller noget helt syvende. Ændringer vil der være.
Den tid som blev brugt på den omhyggelige specifikation og tidsplan tidligt i projektet, hvor det meste var ukendt land, er delvis spildt og kunne være brugt mere effektivt. Det er den agile tankegang, som er gennemtærsket utallige gange. Det bliver det ikke mindre rigtigt af. Udskift “software” med “system” i the Agile Manifesto, og du har grundprincippet på få linier.
Lægger vi ydermere en udbudsrunde ind efter specifikation og tesplan er udarbejdet, så går der bare endnu mere kostbar tid (time-to-market tid er dyr tid), men den historie må vi tage en anden gang.
Kort sagt: En stiv aftaleform, som gør ændringer mere besværlige, er ikke attraktiv for en kollaborativ kunde/leverandør arbejdsform og derfor ikke befordrende for at få det bedste produkt ud af anstrengelserne.
Hvordan laver man en fast pris?
Der er vel et par elementer, som indgår i enhver form for fastprisaftale for overhoved at gøre det muligt at bruge det på udviklingsprojekter – som jo er karrakteriseret ved at inden holde et elemenet af usikkerhed.
- Opgaven begrænses, så leverandøren ikke hænger på at levere noget som tager ekstra lang tid. Jo mere opgaven kan begrænses – og stadig ligne det som kunden ønsker – jo lavere pris kan der gives. Måske uden hensyn til, hvad der er ingeniørmæssig sund fornuft.
- Der tages forbehold for en række ting, så der kan sendes ekstra regninger for de ting, som ikke er regnet med. Jo flere forbehold leverandøren kan tage – formuleret så det ikke ser for voldsomt ud – jo lavere pris kan der tilbydes.
- Tilbudet “paddes” med ekstra margin på tid og økonomi for at give luft til de “uforudsete” ting, som garanteret indtræffer (ellers ville det jo ikke være udvikling).
Det er i princippet meget simpelt, men i praksis en svær kunst. Det er ikke samarbejdet, der er i fokus i den proces.
Hvorfor ønsker kunden fast pris?
Det typiske argument er, at man med T&M er bange for, at økonomien løber løbsk. Det er er fair argument, og en oplagt fare ved T&M. Vi forsøger gerne at modvirke dette ved den tætte dialog, hvor kunden på ugebasis er med til at træffe de beslutninger, der udvider eller indskrænker projektets omfang. Jeg mener dette primært, er et spørgsmål om leverandørens egen etik (forretningsmoral) og styring/samarbejde. Hyppige afleveringer, som er normen i agile projekter, hjælper helt klart her.
Et andet hyppigt argument er, at kunden ved for lidt om det tekniske, til at kunne forholde sig til fremdriften i et T&M projekt. Det er et pudsigt argument, fordi der i et T&M er god tid, til at leverandøren kan forklare kunden alt om konsekvenser osv., på et niveau alle kan forstå. Modsat i et fastpris projekt, hvor f.eks. forbehold og tekniske afgrænsninger i et tilbud kræver en virklig stor teknisk indsigt at forstå og vurdere konsekvenserne af.
Er der en konklusion?
Står valget mellem fast pris og T&M for et udviklingsprojekt med embedded software, hardware osv., så er jeg ikke i tvivl om min anbefaling. Både set fra kundens og leverandørens synsvinkel: T&M giver flest fordele.
Begge metoder kræver – og det er også noget vi altid kræver af vores kunder – en tæt åben dialog. I praksis bør det sættes i system, så det f.eks. er et ugentligt statusmøde på et fast tidspunkt suppleret med en kort skriftlig status/referat.
Vores venner hos BestBrains eksperimenterer med en anden kontraktmodel, som er en blanding mellem fast pris og timebetaling. En lavere timepris og nogle faste bonusbetalinger ved vigtige milepæle. Det er interessant – og vi lytter til deres erfaringer.
Dine kommentarer er velkomne herunder.
Jeg er meget enig. Vi ser typisk tættere kobling og større efterfølgende teknisk gæld ved fastpris-projekter, og løsere kobling samt mere fleksibilitet i den modsatte ende.
Der bør dog for en god ordens skyld lægges stor vægt på det faktum at T&M IKKE betyder at man ikke kan give et bud på den endelige pris. Der er bare netop kun tale om et estimat, som kan ændre sig.
Handler det ikke mere om en tættere tilknytning mellem leverandør og kunde, frem for afregningsformen?
@Kasper: Helt enig. Og som beskrevet er fast pris IKKE en garanti for den endelige pris.
@Lars: Jeg vil sige at den tætte dialog mellem kunde og leverandør er afgørende for at projektet opleves succesfuldt af begge parter. Min argumentation går på at de to forskellige kontraktformer påvirker samarbejdsformen i hver sin retning. T&M i retning mod mere åben dialog, hvilket er en fordel hvis leverandøren har høj etik/moral.