SSA-S eller SSA-L: kontraktsvalget som avgjør om leveransen kan gjøres i etapper

Kontraktsvalget behandles ofte som en formalitet etter at løsningen er beskrevet. I praksis er det motsatt: kontrakten bestemmer hvor detaljert løsningen må beskrives på forhånd, og dermed hvor mye risiko som flyttes til et tidspunkt der ingen ennå vet nok.

Fastpris krever at dere vet svaret

En fastpriskontrakt forutsetter at omfanget kan beskrives presist før arbeidet starter. Det fungerer når oppgaven er godt kjent.

For et fagsystem som skal integreres mot systemer ingen har dokumentert, er forutsetningen sjelden oppfylt. Da blir prisen satt med et påslag for usikkerhet, og hver endring blir en endringsordre.

Smidige avtaler flytter beslutningen dit kunnskapen er

SSA-S, statens standardavtale for smidig utvikling, er laget for det motsatte tilfellet: at omfanget avklares underveis, i etapper, mens begge parter lærer.

Det passer en modulvis modernisering godt. De første modulene finansierer læringen som gjør estimatene på de neste realistiske, og dere kan justere retning uten at det er et kontraktsbrudd.

SSA-L er for løpende tjenester

SSA-L dekker leie av programvare som tjeneste, altså der dere abonnerer på en løsning i stedet for å få den utviklet. Det er en annen situasjon enn utvikling, og valget mellom dem er egentlig et valg om hva dere kjøper.

Skal dere ha noe bygget for dere, er det en utviklingsavtale. Skal dere ta i bruk noe som finnes, er det en tjenesteavtale. Blandingsformene finnes, men de bør være bevisste.

Etappevis leveranse gir en reell exit

Det underkommuniserte argumentet for etapper er at de gir dere en vei ut.

Fungerer ikke samarbeidet, har dere et fungerende delsystem og dokumentasjon, ikke et halvferdig prosjekt og en tvist. Det er en betydelig forskjell i forhandlingsposisjon, og den koster ingenting å bygge inn.

Beskriv behovet, ikke løsningen

Uansett kontraktsform: et konkurransegrunnlag som beskriver ønsket effekt gir bedre tilbud enn ett som beskriver en teknisk løsning.

Beskriver dere løsningen, får dere tilbud på den løsningen, også fra leverandører som ser at den ikke vil virke. Beskriver dere problemet, får dere forslag, og forskjellene mellom dem er informasjon dere kan bruke.

Ofte stilte spørsmål

Kan en smidig avtale brukes i en offentlig anskaffelse?

Ja. SSA-S er laget for det, og smidig utvikling er en etablert form i offentlige anskaffelser. Det som må gjøres godt er evalueringskriteriene, siden dere ikke kan sammenligne på en detaljert kravliste dere bevisst ikke har skrevet.

Hvordan prises en etappevis leveranse?

Vanligvis per time innenfor en avtalt ramme, eller som fastpris per delleveranse der omfanget avklares før hver etappe starter. Det siste gir forutsigbarhet uten å kreve at alt beskrives på forhånd.

Hva om vi allerede har en fastpriskontrakt?

Da bør endringshåndteringen avtales tydelig, og første leveranse bør være en kartlegging med egen pris. Det er det billigste stedet å oppdage at forutsetningene ikke holdt.

Hvem eier koden?

I en utviklingsavtale er hovedregelen at oppdragsgiver får rettighetene til det som utvikles. Bygges det videre på leverandørens eksisterende produkt, avtales lisens for den delen. Det bør stå eksplisitt i avtalen, ikke forutsettes.