Venter på første, store smidig-havari

Venter på første, store smidig-havari

- Bare spørsmål om tid før smidig-prosjekter ender i retten, sier advokat Jan Sandtrø.

I smidige prosjekter blir veien litt til mens man går, dermed åpner det seg juridiske utfordringer rundt det kontraktsmessige. Standard it-kontrakter er for statiske, hvor man gjerne baserer seg på milepæler og delprosjekter - med klare mål for funksjonalitet som skal på plass.

- Rammeverkene er ikke så klare. Men min erfaring er at kontrakter på smidig prosjektstyring er veldig krevende for kunden, sier advokat Jan Sandtrø i advokatfirmaet Simonsen.

Godt forbredt

Sandtrø mener kundene må ha godt med interne ressurser i en smidig-leveranse. Helst like mange som leverandøren.

Å være like mannsterke som leverandøren er imidlertid ikke like lett.

- Nei, det er ikke så lett å få til. Men kunden må ha en solid prosjektledelse som er godt skodd for å følge opp både det som kreves av kunden selv, og det som leverandøren skal levere, sier Sandtrø.

Hvis kunden ikke har et godt apparat må man være ekstra oppmerksom på de elementene som er bindende for kunden, som for eksempel godkjennelsen av den løpende produksjonen, påpeker Sandtrø.

Han får støtte fra advokatkollega Arve Føyen i Føyen Advokatfirma, som mener smidig-prosjekter reiser en del kontraktsmessige utfordringer.

Arbeidsfordeling

På nettsidene til Dataforeningen (DND) er kontrakten PS2000 detaljert beskrevet. Blant virksomhetene som har tatt PS2000 i bruk er Skatteetaten. Randi Thomsen i Skattedirektoratet forteller at de ønsket en utviklingsprosess der systemet ble bygget gjennom del-leveranser og med en kontinuerlig evaluering og kontrollpunkter underveis. Og at de la stor vekt på bilaget om roller og ansvar.

- Vi har gode erfaringer med kontrakten. Men har bare brukt den en gang, men det var et veldig stort og viktig prosjekt, sier Randi Thomsen.

Arve Føyen sier Dataforeningens Smidig-kontrakt PS2000 er grei. Andre it-kontrakter kan også brukes, men det krever mye arbeid. Utfordringen er å få til en kontrakt hvor arbeidsmodellen mellom kunde og leverandør er tydelig, mener Føyen.

- Etter hvert som man i smidig-prosjektet begynner å prioritere arbeidet - finner man kanskje ut at man ikke får den funksjonalitet du hadde tenkt til den avtalte prisen, hva gjør du da, spør han retoriske og legger til:

- Det er noe av problemet med målpris.

Typisk for et smidig-prosjekt vil være å avtale en sum (kontraktssum), og så lager man den funksjonaliteten man rekker. Føyen påpeker at det ofte er dårlig regulert hvordan man styrer det når taket er nådd og kunden ikke er fornøyd med funksjonaliteten man har fått.

- Da blir det en diskusjon om prisen for det videre arbeidet, sier Føyen og påpeker at man også raskt kommer opp i diskusjon om i hvor stor grad kundens involvering underveis har bidratt til at pristaket ble nådd før ambisjonene for funksjonalitet ble tilfredsstilt.

Hvem har skylden?

Foreløpig har det ikke vært noen rettssak etter et havarert smidig-prosjekt i Norge.

- Det er bare spørsmål om tid. Men rettssaker rundt smidig-prosjekter kan være mer problematisk fordi man som kunde er så tett på utviklingen, sier Jan Sandtrø.

I et utviklingsprosjekt basert på Smidig kan kundene bli juridisk bundet gjennom at kundens representanter jobber tett med leverandørene med løpende godkjenninger av det kontinuerlige arbeidet, derfor blir det fort vanskelig å få påpekt feil og mangler senere. Det er ikke lett å komme frem med klager på en bil man selv har vært med å bygge.

Det blir for eksempel en utfordring når man mot slutten av prosjektet finner ut at den nye funksjonaliteten som fungerer perfekt ikke virker mot andre systemer, for eksempel forretningssystemet. Hvem sin feil er det? Har endringer som kunden har gjennomført underveis påvirket sluttresultatet negativt?

- Disse utfordringene kan løses, men det krever en god kontrakt som beskriver leveransen helt frem til mål. Smidig prosjektmetodikk gjør ikke it-kontrakten overflødig, tvert i mot, sier Sandtrø.