Svakhetene i standard it-kontrakter

Forskningsresulter fra Simula Research Laboratory bekrefter dette.

Dagens kontraktsformer har flere svakheter:

a. Det er mer fokus på hva som skal skje dersom ting går galt, enn på at kontrakten skal fungere som et styringsredskap underveis. Det er tilstrekkelig å bruke målestokken for å finne ut hvor mye tekst som er viet henholdsvis det ene eller det andre temaet.

b. Det gis signaler til at systemet/produktet skal beskrives, men det gis så og si ingen signaler om at arbeid og samarbeid også må beskrives. Hvilke roller omfattes og hvordan skal ansvar og myndighet være for disse rollene? Det er også et tankekors at ISO 9001-standarden og flere andre utbredte standarder, legger stor vekt på å beskrive prosesser, grensesnitt, samarbeid, roller, ansvar og myndighet, men likevel gis det ingen kontraktsformuleringer som kan hjelpe i tilsvarende retning. Hvorfor? Det hjelper lite å si at det skal utpekes en brukergruppe, dersom det ikke også beskrives hvordan samarbeidet med leverandøren skal foregå. "Hvem" og "at" er sjelden nok – "hvordan" er vel så viktig!

c. Kontraktene forutsetter bruk av en sekvensiell prosjektmodell, mens prosjektvirkeligheten oftest ikke stemmer overens med dette. "Alt" ansvar legges på leverandøren, mens kundens ansvar "glemmes" eller blir ikke definert klart nok.

Kontraktsstandarden PS2000 er riktignok et unntak. Her stilles det konkrete krav til arbeid og samarbeid. Men også her er det feller å gå i. Siden kontraktsformen er omfattende og detaljert, blir den ofte valgt bort i mindre prosjekt. For mange detaljer kan i verste fall begrense den friheten som leverandøren bør ha.

Standardkontraktene har alle sine svakheter. Det er likevel ikke noe i veien for å benytte dem som et grunnlag, men da må det gjøres en solid skreddersydd innsats som kan omfatte det å gjøre endringer i standardteksten. Det er arbeidskrevende og krever kompetanse. Resultatet blir at de fleste faller ned på det komfortable; bruke kontraktene som de er, se på eksempler fra tidligere og beskrive det systemet som skal lages. Det føles trygt, men er det ikke.

For 30 år siden var systemene små og enkle. Det var lett å beskrive hva man ønsket seg og hvordan det skulle fungere. Allerede ti år senere var størrelsen, og dermed kompleksiteten, økt til det tidoble. Nå, tyve år senere, kan vi igjen multiplisere med en faktor på 100. Størrelse og kompleksitet ser ut til å legge på seg med en faktor på ti per tiår. Viktigheten av gode samarbeidsformer mellom leverandør og kunde er blitt essensielt. Dessverre har ikke kontraktsformene fulgt den samme utviklingen.

Kontrakten må formulere overordnede krav til leverandørens måte å arbeide på (i tillegg til krav til det systemet som skal lages). Det bør ikke bli for detaljert, kunden skal ikke "ta over" ansvaret for leverandørens arbeid. Det er behov for it-/kvalitetssikringskompetanse for å sørge for at kontraktene blir godt nok balansert i forhold til oppgavens størrelse, risiko og kompleksitet. Advokatbistand kan være nødvendig, men er sjelden tilstrekkelig.

En leverandørvurdering før inngåelse av kontrakt i form av gjennomgang/kvalitetsrevisjon, er en aktivitet som betaler seg godt. Resultatet kan være overraskende. Det gir et godt grunnlag for hvilke kontraktskrav som er nyttige å stille. Nyttig er det også å gjøre tilsvarende gjennomganger av prosjektarbeidet underveis. Det hjelper begge parter og bør være en naturlig og preventiv del av arbeidet. Derfor anbefales det at den tid som medgår fra leverandørens side, betraktes som del av leveransen og dekkes av kunden.

Her er noen anbefalinger til kundene:

a. Vurder leverandørenes arbeidsmåter og evne til å kvalitetssikre seg selv, som ledd i forarbeidet før valg av leverandør.

b. Benytt resultatet fra leverandørvurderingen til å formulere overordnede kontraktskrav til arbeid og kvalitetssikring i prosjektet. Nøkkelroller, ansvar og myndighet må klargjøres. For andre roller må det være et krav at de klarlegges som del av prosjektet.

c. Sett krav til kundens mulighet for innsyn i leverandørens arbeid underveis (og bruk muligheten!).

d. Sett krav til at leverandøren skal sette inn tiltak når det oppdages at arbeidet ikke er utført som avtalt. Dette bør omfatte det å rydde opp økonomisk dersom dårlig arbeid har ført til forsinkelser, risiko og merutgifter.

e. Skygg unna formuleringer som at "leverandøren har alt ansvar..".

f. Som kunde, sett tilsvarende krav til egen organisasjon.

Det ligger i sakens natur at ovenstående råd også resulterer i et tilleggsråd: Når komplekse systemer skal implementeres bør det vurderes andre kontraktsformer enn fastpris.

Av Marit Søholt Stokes, konsulent/daglig leder Accent AS