Agile fastpriskontrakt

Jeg har længe gået og tænkt over hvordan man håndtere en fastpriskontrakt i en agile verden. Jeg har de sidste dage gået og leget lidt med tanken om hvad der gør det besværligt og hvordan disse ting vil kunne afhjælpes.

De fleste fastpriskontrakter bygger på, som navnet også antyder, at den indeholder en række ting der skal opfyldes og et fast beløb det så koster. Det vil altså sige kunden siger “jeg vil have det og det” og leverandøren siger “så koster det så mange kroner”. Tager det så leverandøren længere tid en forventet at løse opgaven, må han selv dække disse udgifter. Men kan han løse det hurtigere en forventet, så giver det leverandøren ekstra penge i kassen.

Man kunne sige at hvis leverandøren undervudere opgaven vinder kunden på det, fordi han har fået noget billigere end det skulle have været, og hvis leverandøren overvuderere opgaven, så vinder leverandøren.

Nogen vil mene at det må være i kundens interesse at presse leverandøren så langt ned i pris som muligt, og i leverandørens interesse at presse prisen så højt i vejret som muligt. For kundens eneste interesse er “at få så meget som muligt, for så lidt som muligt” og leverandøres eneste interesse er “at lave så lidt som muligt, for så meget som muligt”. Men er der i virkeligheden nogen af dem der vinder hvis de tænker sådan?

Jeg tror derimod på at både kunde og leverandør begge bliver en vinder hvis de begge ønsker at ramme lige præcis den pris det tager at lave det på. Hvis begge parter tænker på den måde, er det ikke noget med “vi skal se om vi ikke kan klemme noget mere ud af dem” eller “hvordan får vi det her biligst løst” (quick-and-dirty-løsningen). Begge mål for at vinde er at få noget godt og brugbart ud af de penge man har.

Min teori bygge på at man istedet for at basere sin kontrakt på en pris istedet baserer den på en tidsperiode. Kontrakten skal selvfølgelig stadig indeholde en pris for det er jo det der skal betales. Men istedet for at der står “Vi levere A og B til X kroner.”, så står der “Vi levere X mandedage til at løse A og B.”. På den måde er det begge parters ansvar at A og B bliver løst inden for den tidsperiode man har aftalt. Begge parter er derfor med til at sætte ambisionsniveauet for hver af delopgaverne.

Dette betyder at leverandøren spiller med åbne kort om hvad en mandedag koster. Det er her altså ikke muligt at skjule nogle udgifter på samme måde som det er muligt i en normal fastpriskontrakt, for kunden vil hurtigt gennemskue at en mandedag sidste gang kostede 1.000 men denne gang koster 1.100.

Jeg forestiller mig at man i en sådan kontrakt, istedet for de tradisionelle kravlister, istedet laver en liste af User Stories. Til hver User Story aftales så en timebox man ønsker at bruge på den, fx 10 mandedage. Nå alle User Stories er på plads, er det så ikke det store problem at finde den samlede pris, da man bare ligger alle de aftalte tider på hver User Story sammen, og gange med prisen for en mandedag.

Alle User Stories prioriteres så af kunden i forhold til hinanden, hvor ingen kan have samme prioritet. Kan også illustreres ved at man skriver hver User Story på et stykke papir, og man så skal ligge dem i en bunke, hvor den der ligger øverst er den vigtigste. Denne prioritering kan så bruge til flere ting. Dels kan den bruges til at hvis den samlede pris bliver for høj, kan man pille nogle af de User Stories der ligger i bunden ud, for at få prisen ned. Prioriteringen kan også bruges når man begynder at udvikle på opgaven, for så et det jo givet hvad man skal starte med og hvad man skal løse derefter.

Ideen er at når man har fastsat at kontrakten er på X mandedage, ja så har man X mandedage til i fællesskab (kunde og leverandør) at få de bedste ud af opgaverne. Finder kunden undervejs i opgaven ud af at han gerne vil ændre prioriteringen på de opgaver der endnu ikke er påbegyndt, for det har jo ingen betydning for antallet af tid der skal bruges.

Derudover ser jeg en mulighed for at kunden frit kan udskifte hvad de opgaver der ikke er påbegyndt med nogle andre med tilsvarende estimater. Dette skal dog nok håndteres med noget change management, for at kontrakten juridisk set forsat kan overholdes. Men for projektet vil det være ligemeget om der bliver taget to opgaver ud på henholdsvis 2 og 4 mandedage, og der så istedet kommer et nyt til på 6 mandedage. Så længe der ikke ændres ved det samlede antal mandedage for hele kontraktet, kan den endelige leveringsdato stadig overholdes.

Det betyder at man tillader kunden at blive klogere mens udviklingen står på. Det kan fx. være at når kunden har set de første 3 User Stories færdige, så opdager at User Story X og Y, faktisk ikke giver nogen videre værdi, men at det måske ville give mere værdi at bruge lidt mere tid på at arbejde lidt mere med User Story A, som nu er færdig. Og denne form for fleksibilitet giver denne måde at arbejde på.

Det hele baseres altså må gensidig tillid. Kunden afsløre hvor mange penge de har til projektet og leverandøren afsløre hvor meget de kan lave på en mandedag. Faktisk kunne det være det første man gør når kunde og leverandør mødes, være lige præcis af afsløre disse ting overfor hinanden, så har begge parter smidt kortene på bordet og spille herfra med åbne kort. Derefter indleder man så en fælles afklaring af hvad man forventet at kunne når på det antal mandedage pengene rækker til.

Det lyder alt sammen som gul og grønne skove, men kan det lade sig gøre i praksis? Jeg tror på at det kan lade sig gøre, det store spørgsmål er om kunde og leverandør tør stole på hinanden, og tror på at de begge har det ene mål at få det bedste ud af de penge man har, virkelig at ende med noget der kan bruges til noget.

Konklusionen er altså, stol på hinanden (kunde og leverandør) – det er jeres fælles projekt at løse projektet, og hvis i arbejder sammen får I det bedste resultat. Lad dog være med at bruge kræfter på at finde ud af hvordan i sniger jer om hjørner med den anden part, for det ender med at gå ud over dig selv. Brug istedet tiden på at få noget godt og brugbart ud af det. Jeg vil gætte på at det sikkert tager dobbelt så lang tid at udtænke og udføre en beskidt handling end det gør at udføre en god handling.

Lav en kontrakt hvor I aftaler at i har så lang tid til i fællesskab at lave den bedste løsning af et projekt. Skriv de opgaver i mener projekt indeholde ind i kontraktet, med et estimat på hvor lang tid de tager at løse. Men tillad at man bliver klogere undervejs, og at man ændre på indholdet af projektet, men aldrig på den aftalte tid. Har man i kontraktet aftalt 100 mandedage, så er man også færdig efter 100 mandedage, men det er ikke sikkert at man kommer ud med det man skrev i kontraktet, men man kommer istedet ud med det man rent faktisk kan bruge til noget.