IT-advokat Tue Goldschmieding, Gorrissen Federspiel og bestyrelsesmedlem i Danske IT-Advokater. Han er certificeret IT-Advokat og arbejder med IT-sourcing, digitalisering og persondatabeskyttelse.
Af bestyrelsesmedlem Tue Goldschmieding, Danske IT-Advokater
Store udviklingsprojekter har ofte vist sig at være en udfordring for både offentlige myndigheder og for private virksomheder. Derfor tager flere IT-organisationer agile udviklingsmetoder til sig. Men hvordan styres kontraktansvaret med agile udviklingsmetoder?
Mange virksomheder i ind- og udland har taget de agile udviklingsmetoder til sig i de seneste år. Det sker i mange tilfælde som et alternativ eller et supplement til de udviklingsmodeller som eksempelvis vandfaldsmodellen, hvor beskrivelsen af kundens krav låses fast i en kravspecifikation i kontrakten og leverandører byder ind på opgaven på baggrund af disse faste krav. Kontrakten bruges som et instrument til at styre leverandøren med, hvis der ikke bliver leveret det, der er aftalt i forhold til de oprindelige krav.
Med agile udviklingsprocesser forholder det sig anderledes. Agile
udviklingsmetoder har gennem de seneste år vundet indpas i mange virksomheder. Agil udvikling giver en stor grad af fleksibilitet sammenlignet med de traditionelle udbudsprocesser og udviklingsmetoder som vandfaldsmodellen.
En ny udfordring
Set fra et kontraktuelt perspektiv kan agil udvikling dog være en ny udfordring – for hvem er ansvarlig for resultatet, når kunde og leverandør i fællesskab løbende justerer funktionalitet og prioriteter gennem projektet. Det er præcis her den klassiske metode afviger fra den agile. Forløbet i den klassiske metode er nøjagtigt beskrevet i kravspecifikationen, så her kommer ændringer og justeringer i leveranceperioden som et problem for projektet og er ofte årsagen til en tvist mellem kunde og leverandør.
I den agile verden er ændringer og justeringer et vilkår. Men det rejser nye udfordringer for kunderne med styringen af leverandøren, hvis det ender med, at leverancen ikke er som forventet. Pointen med agil udvikling er, at hverken kunde eller leverandør kender slutproduktet. Man aftaler at bygge en bil, men ved bare ikke, hvordan den ser ud, når den er færdig.
De nye agile udviklingsmetoder, som vinder indpas i store organisationer og virksomheder, er ikke sat i verden for at skulle skrives ind i en IT-kontrakt. Det giver udfordringer for kunder og leverandører.
Der er flere forskellige rammeværk inden for projektstyring og udvikling. Der er mange ord og begreber i de forskellige rammeværker. Samtidig popper nye rammeværk og udviklingsmetoder op, som rører sig i markedet. Agile, DevOps, Scrum – og ikke mindst SAFe. Fælles for dem er, at de ikke forholder sig til det kontraktuelle.
Ingen af de forskellige metoder og værktøjer er lavet til, at der skal skrives en kontrakt. Det betyder også, at der ikke findes en slags IT-kontrakt, der dækker alle agile udviklingsmetoder. Derfor bør kunder og leverandører sikre, at den kontrakt, som de indgår, reflekterer den agile udviklingsmetode, som parterne ønsker at anvende i det konkrete IT-projekt – både hvad angår tid, penge og funktionalitet. Det er afgørende, at parterne i et agilt udviklingsprojekt er enige om, hvornår hver parts ansvar og forpligtelser starter og slutter.
