Garantibevis uten garanti eller bevis

(publisert i Computerworld den 21. Mai, 2010)

Når man publiserer noe kontroversielt så er det alltid litt spennende å se hva slags svar på tale det genererer. Nils Kristian Sveaas replikk på mitt innlegg var på mange måter meget balansert og i god tone. Ikke desto mindre synes jeg at Nils tar grundig feil på flere punkter.

For en jurist som Nils kan det være naturlig (og besnærende) å se på kontrakt og kravspesifikasjon som “kundens garantibevis”. Min erfaring går i en annen retning. Jeg har stor respekt for verdien av gode kontrakter. En dårlig kontrakt nærmest garanterer at prosjektet vil havarere. Dessverre er det likevel sånn at en god kontrakt med en dårlig leverandør noen ganger ikke er verdt papiret det er skrevet på. Jeg kommer gang på gang i kontakt med kunder som trodde de hadde sikret seg via fastpris og en detaljert kravspesifikasjon. Når prosjektet er godt i gang og leverandøren ikke klarer å oppfylle sine forpliktelser oppdager kunden at den er mer beroende av leverandøren en omvendt. Det slutter gjerne med at kunden betaler langt mer enn det som var avtalt for noe som bare til dels oppfyller spesifikasjonen. Deretter holder de kjeft. Det er jo ikke i noen av partenes interesse å snakke om hva som har skjedd.

Nils har også helt klart mer greie på juridikk enn reklame. Påstander om at «reklamebyrået normalt har en total kreativ frihet» og at for reklamebyråer er «tid normalt ikke er en kritisk ressurs» vitner om en mangel på kunnskap om reklamebransjens vilkår og betydning.

Nils synes å tro at alternativet til en detaljert kravspesifikasjon er å gi en leverandør helt frie tøyler og «la kreativiteten løpe fritt et ubestemt antall måneder før utviklingen starter». La meg derfor i korthet beskrive an alternativ tilnærming som kombinerer smidig utvikling med god prosjektstyring.

Et smartere prosjekt

Før kunden velger leverandør gjennomføres en forstudie. Denne kartlegger randvilkår for virksomheten (for eksempel lover som virksomheten er underlagt), teknisk miljø og andre viktige faktorer en leverandør må kjenne til. Forstudien lager også en overordnet kravspesifikasjon som beskriver målene for det nye systemet. Basert på dette gjennomføres en anskaffelse basert på kontraktstandarden PS2000.

Leverandørenes tilbud inneholder overordnede løsningsbeskrivelser samt et prisestimat for gjennomføring. Her skisserer leverandørene blant annet den teknisk miljø de ønsker å benytte. Allerede her skjer noe interessant. I en tradisjonell anskaffelse ville kunden ofte ha spesifisert påkrevd teknisk miljø. Dette for å sørge for en enhetlig driftsmiljø. Problemet er dog at i noen tilfeller vil en leverandør kunne levere en langt rimeligere løsning hvis de kan basere seg på en annen teknisk miljø. For kunden blir det da en kost/nytte vurdering som bestemmer hvilken løsning den skal velge. Med en tradisjonell anskaffelse ville leverandøren aldri ha tilbudt sin løsning da den ikke oppfyller “kravene”.

Når vel leverandør er valgt er det kostnadsoverslag som tilbudet inneholdt ikke så styrende som i et tradisjonelt prosjekt. Prosjektet deles nemlig opp i et antall leveranser der hver leveranse starter med at en detaljert løsningsbeskrivelse lages i felleskap. Her kan leverandør gi mye mer presise (og bindende) kostnadsestimat da den har mye mer inngående kunnskap om hva som skal lages. Kunden kan forholde seg til en konkret skisse til løsning i stedet for abstrakte krav.

Hver leveranse resulterer i noe som kan settes i drift. Kunden står dermed fri til å avbryte prosjektet før alle leveranser er utviklet. Kunden har hele veien gode muligheter til å sikre at prosjektet kommer i mål innenfor den ramme som er gitt men må i noen tilfeller velge bort enkelte funksjoner hvis andre deler av systemet viser seg å være mer komplekse enn antatt.

Denne prosessen sikrer at prosjektet gjennomføres innenfor de økonomiske rammer som er gitt samtidig som både kunde og leverandør kan dra nytte av den læring som skjer underveis. Mange ganger vil kunden oppdage at ting som den trodde var viktige mister sin betydning samtidig som andre ting seiler opp. Sluttresultatet blir et system som løser kundens problem, ikke noe som oppfyller innholdet i et utdatert dokument.