Sterk blanding

Forutsetter din prosjektplan at ingenting endrer seg etter at prosjektet starter eller tar den inn over seg læring? For utviklingsprosjekter av programvare kaller vi sistnevnte “Smidige” prosjekter. I smidige prosjekter verdsetter vi “å tilpasse oss endringer fremfor å følge en plan” og “samarbeid med kunden fremfor kontraktsforhandlinger”. Det betyr ikke at smidige prosjekter ikke har planer og kontrakter. Det betyr bare at jo mer vi forsøker å låse pris og omfang, desto mindre kan kunden og leverandøren dra fordel av det man lærer. I denne blogposten vil jeg legge fram en alternativ måte å tenke rundt smidige kontrakter.

Dilemmaet i smidige kontrakter ligger i noe som kan virke som en umulighet: For å kunne ha konkurranse om en kontrakt må man sammenligne priser. Og dersom man inkluderer pris, må man bestemme omfanget som prisen gjelder. Naturligvis kan omfanget endres når nødvendig, men dette er en smertefull prosess som kunden sjelden setter pris på.

For å kunne levere et tilbud må man forventes det videre at en gruppe leverandører legger ned betydelig mengder arbeid i å produsere papir hvis eneste funksjon er å avgjøre hvem som vinner kontrakten. Hvor mye trygghet dette regimet gir på at kunden faktisk velger en god leverandør kan diskuteres, men det er vel bedre enn å trille en terning.

Mitt forslag ønsker å fjerne begge disse elementene og erstatte dem med Prestasjonbasert konkurranse og Enhetsbasert pris. Helt enkelt konkurrerer leverandører om hvem som leverer best programvare i en konkurransefase. Deretter legges enhetsprisen for den programvaren som ble levert til grunn for enhetspris gjennom prosjektet. Kunden kan fritt velge hva som utvikles når de måtte ønske, mens målingen av fremdrift fra konkurransefasen legges til grunn for prisen.

En mer fullverdig avtaletekst kan se noe slikt ut:

1. Kunden gjør en rask prekvalifisering av 3-4 rimelige konkurrenter. Vurderingen går kun på hvor vidt leverandøren har bemanning til å levere prosjektet og referanser som tilsier at de er en god leverandør. Det er ikke nødvendig å få med den absolutt beste leverandøren, kun et rimelig utvalg.
2. Kunden inviterer de utvalgte leverandørene inn til seg for å analysere, designe, utvikle og levere i en konkurransefase på noen uker. Denne perioden kan helt eller delvis erstatte et forprosjekt, avhengig av leverandørenes bemanning. Den kan være delvis finansiert av kunden dersom man ønsker det. Leverandøren som leverer best funksjonalitet vinner kontrakten. Dersom det er flere leverandører som gjør en skikkelig bra jobb, kan kunden gå videre med flere. Min hypotese: Sammenlignet med dagens regime gir dette lavere kostnader for kunde og leverandør og det gir kunden bedre sjanse til å velge en god leverandør.
3. Leverandøren som vant forplikter seg til å levere funksjonalitet til sammenlignbar pris til det de gjorde i konkurransefasen. Det vil si “referansepris for referanse-brukerhistorier”. Dersom prosjektet har funksjoner som ligner svært på hverandre, kan dette være så enkelt som at fremtidig funksjonalitet skal leveres til samme pris. Jeg tipper målpris vil fungerer best her, ettersom det vil jevne ut mindre forskjeller i funksjonsstørrelse.
4. Kunden forplikter seg til et cirka totalomfang av investeringer, men kan fritt bestemme hvilke funksjoner som skal inngå innenfor dette, så lenge leverandøren har tilstrekkelig kompetanse til å utføre disse oppgavene. Når oppgaver er åpenbart sammenlignbare med allerede utførte oppgaver, skal avtalt referansepris legges til grunn. I motsatt fall… må man finne ut av det.
5. Leverandøren leverer og demonstrerer funksjonalitet i periodiske sprint-gjennomganger. Disse skal foregå med 2-4 ukers intervall. Kunden skal godkjenne funksjonalitet eller rapportere funksjonelle feil innen 15 virkedager fra sprint-gjennomgang. (Tekniske feil skal rettes så lenge programvaren er under garanti). Kunden kan velge om programvaren skal produksjonssettes etter en sprint.
6. Når partene er enige om det, kan man legge en ny måling av en referansebrukerhistorie til grunn for ambisjonsnivå på funksjonalitet og kostnad. Kunden og leverandøren kan også avtale ved prosjektets start tidspunkter der en slik måling skal gjennomføres.

Smidige metoder bygger på observasjonen at å investere mer i planlegging før man har empirisk erfaring øker risikoen, heller enn å redusere den. Fastpriskontrakter forutsetter en fullstendig kunnskap om hva som skal gjøres på starten av prosjektet og undergraver muligheten til å kontrollere prosjektet. Samtidig skaper papirarbeidet en illusjon av kunnskap som øker partenes forpliktelse til ikke-empiriske antagelser.

Ved å se på leverandørenes evne til å forstå kundens behov og levere i henhold til dem, framfor evnen til å produsere overbevisende dokumenter, har kunden bedre sjanse til å velge en kapabel leverandør. Ved å bruke erfaringstall fra det faktiske prosjektet som prisgrunnlag kan vi finne riktig pris og skape et vinn-vinn prosjekt. Ved å bli enige om en erfaringsbasert enhetspris i stedet for hele omfanget, kan kunden ta tømmene i prosjektet, samtidig som leverandøren kan være trygg på å få betalt for jobben.

Det ville vært noe, ville det ikke?