Mirakel-moppedreng? Agil K03-kontrakt skal redde offentlige it-projekter

Den nye standardkontrakt K03 for offentlige it-projekter er på vej, med plads til en agil udviklingsmetode. Prisen for projektet vil dog ligge fast, forklarede Kammeradvokaten.

Utallige fejlslagne it-projekter har ført til selvransagelse i den offentlige sektor, og en af grundene til, at der kan opstå problemer, er den typisk helt fastlåste kontrakt med leverandøren og brugen af den såkaldte vandfaldsmodel, hvor projektet gennemløber bestemte faser fra kravspecifikation til færdigt produkt.

Derfor skal den offentlige sektor have en ny standardkontrakt til it-projekter, K03, hvor juraen giver plads til mere agile metoder, altså med mulighed for at ændre på projektets indhold undervejs.

Men hvordan kan sådan en fleksibel model kombineres med faste, offentlige budgetter og kravet om en stram snor i leverandøren?

Det paradoks har Kammeradvokaten fået til opgave at løse, og den foreløbige løsning blev præsenteret på konferencen Digitaliser Danmark 2012 i Aarhus af advokat Tom Holsøe, som er en af hovedarkitekterne på den nye K03-kontrakt hos Kammeradvokaten.

»Erfaringen har vist, at det skaber problemer at låse sig fast til en løsning på forhånd,« sagde han om baggrunden for, at staten nu gerne vil have en kontrakt til agile projekter.

Læs også: Agil standardkontrakt skal lægge skodprojekter i graven - og gøre resten bedre

Men hvis man er ret sikker på, hvad man skal have, eller måske indkøber et standardsystem med kun en smule tilpasning, er der ingen grund til at begynde med den agile kontrakt. Så kan man holde fast i den gamle K02-standardkontrakt, lød vurderingen.

»Vi vil ikke gå ud og fremhæve denne kontrakt som særligt anbefalelsesværdig frem for andre. Det er utrolig vigtigt, om man kender løsningen, man vi anskaffe sig, på forhånd, eller om det er et udviklingsprojekt,« sagde Tom Holsøe.

I et rendyrket agilt projektforløb i det private erhvervsliv kan man finde en leverandør, man stoler på, aftale en pris for et antal konsulenttimer, og så gå i gang med sammen at finde frem til den bedste løsning.

Men i den offentlige sektor er det ikke gangbart først at kende projektets samlede pris, når det hele er overstået, lød det fra advokaten.

»Prisen ligger fast i K03-kontrakten. Jeg tror heller ikke, at dem med store chefdrømme i det offentlige vil have glæde af at overskride det ene budget efter det andet. Helt åbne kontrakter kan vist kun lade sig gøre, hvis man leverer Joint Strike Fighter til det amerikanske forsvar,« sagde han.

Læs også: Ny kontrakt til agil udvikling på vej

Den nye K03-kontrakt er blevet lidt af en moppedreng på 90 sider, men det var primært fordi, der er meget vejledning undervejs, sagde han og droppede derfor at gennemgå standardkontrakten fra ende til anden.

Konceptet er, at kunden laver en liste over absolutte krav og øvrige krav på en overordnet kravliste - altså ikke en meget detaljeret kravspecifikation. Omvendt skal kravene også være ret konkrete, så leverandøren har en chance.

»Det nytter ikke, hvis man ikke er klar, og det hele bliver overladt til leverandøren. Der er også et endnu større behov for en business case med agil udvikling, så man undervejs kan forklare sin leverandør, hvorfor man går til højre eller til venstre,« sagde Tom Holsøe.

Højst 60 procent absolutte krav

Når listen over krav til systemet er klar, skal der helst ikke være mere end 60 procent absolutte krav. Er der flere, har kunden jo næsten lagt hele løsningen fast, og så kan man i stedet bruge en af de ikke-agile kontrakter, lød vurderingen.

For når et K03-projekt sættes i gang med de korte iterationer, man kender fra agile projekter, skal der være plads til at skære noget fra. Det er nemlig sådan, man sørger for, at budgettet holder.

Allerede ved første iteration, altså første korte udviklingsrunde, skal man vurdere, om tidsplanen og budgetterne holder, lød rådet.

»Hvis den første iteration går 10 procent over budget, skal man reagere med det samme og fjerne noget funktionalitet fra kravslisten. På den måde kan man komme i mål til tiden og til prisen. Men det forudsætter, at der er noget fedt på projektet,« forklarede Tom Holsøe.

Hvordan undgår man så, at en sløv leverandør så betyder, at kunden må pille den ene funktion efter den anden ud, uden at få kompensation, lød et spørgsmål fra salen.

»Kunden kan træde ud af kontrakten. Og som leverandør laver man kun det nummer én gang, for kunden kan jo godt huske og kan spille leverandøren af brættet ved et genudbud, så samme firma ikke får opgaven igen,« sagde advokaten.

Det rejste så spørgsmålet, om leverandøren så bliver kompenseret, hvis kunden trækker stikket efter bare fire ugers arbejde. Der er ikke lagt op til en exit-fee, forklarede Tom Holsøe.

»Men jeg har ikke oplevet nogen statslige kunder, som hoppede fra for sjov og tænkte ’det var så sjovt at lave et udbud - lad os prøve en gang til’,« sagde han.

Undgå 'Kim Larsen-paradokset'

Som i andre agile projekter er det et spørgsmål om tillid mellem kunde og leverandør, forklarede Tom Holsøe. Er tilliden først forsvundet, vil projektet aldrig blive en succes.

»Vi har aldrig oplevet, at et projekt, hvor der er advokater med til alle møder mellem kunde og leverandør, er endt med et godt produkt,« sagde han.

En måde at sikre fælles mål hos de to parter er at sammensætte betalingen, så leverandøren først får de gode penge, når grundstammen i systemet er klar, og der bliver bygget oven på fra listen over ’øvrige krav’.

»Så kan kunden sige: Den fede avance får du, når du leverer flødeskummet på kagen. Bundene og fyldet får du en rimelig avance på, men det er drysset, du skal gå efter,« sagde Tom Holsøe.

Løbende i projektet vil kunde og leverandør så kunne revidere listen over krav og ændre på dem, hvis det giver mening ud fra det, man lærer undervejs. Men hvordan sikrer man så projektet mod ’Kim Larsen-paradokset’, spurgte en tilskuer, altså hvor man ikke nåede det, man ville, men nåede så meget andet?

»Du kan nemt opleve, at der opstår andre krav undervejs i projektet, og derfor kan kravene cykle ud og ind. Men der skal være fuld transparens og enighed omkring det. Og de absolutte krav er undtaget,« sagde Tom Holsøe.

Arbejdet med K03-kontrakten, som skal supplere de eksisterende K01 og K02, begyndte formelt, da den daværende IT- og Telestyrelse nedsatte en arbejdsgruppe til formålet i december 2010.

K03 vil være klar til brug i den offentlige sektor inden udgangen af 2012.

Se hele oplægget på video

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Anonym

Umiddelbart lyder et jo godt nok.

Dog syntes jeg det lyder som om, at der nu skal nye hoveder ind, for at rydde op efter de tidligere meget dårligt kørte projekter, og gøre det for en stramt pris.
Det er jo også en måde at spille sorteper videre på, imens man selv beholder de fede kort.

Normalt, så vinder man lidt på et projekt og taber lidt på et andet.
Hvis der ikke er plads til "flødeskum", så er det en dårlig kage.

  • 0
  • 0
Joe Sørensen

Faktisk betyd K01 og K02 også fast pris.

Når prisen på projekter stiger, er det både fordi forsinkelser i projektet betyder at kundens besparelser udebliver, samtidig med at de skal have ressourcer til at samarbejde med kunden i længere tid end planlagt.

Derefter kan det også blive fordi kunden bliver utilfreds og utålmodig og af den grund begynder at bruge konsulenttimer på at undersøge hvem der er skyld i hvad.

I sidste ende kan det ende med, at kunden beslutter sig til at lave et nyt udbud, sent i processen. Dermed er alt den tid kunden har brugt spildt, og der kommer måske et efterspil, hvor leverandøren mener at kunden skylder dem penge, fordi kunden også har en del af ansvaret. Ofte ender det dog med at kunden og leverandøren vil undgå den situation, ved at lave en ny og mere realistisk aftale, der retter de fejl der var i udbudet. Det betyder dog også at leverandøren får flere penge, da man nu er blevet klar over at opgaven var større end hidtil antaget.

  • 0
  • 0
Joe Sørensen

Jeg er ikke sikker på at nye og uprøvede kræfter gør et bedre, end de der allerede har erfaringer med et et forfejlet projekt.

Der er dog mange, der har været en del af et software projekt, som allerede begynder at fortryde det kort efter. De finder ud af, at det er sindssyg svært at have overblik over alle dele af projektet.

  • 0
  • 0
Anonym

Jeg er ikke sikker på at nye og uprøvede kræfter gør et bedre, end de der allerede har erfaringer med et et forfejlet projekt.

Det er jeg heller ikke.

Men i forbindelse med udvikling, så er der kun 2 muligheder. Enten køber man det ind, som man ikke selv kan løse, eller også afsætter man midler og tid til at udvikle uden for eget metier.
Her er det min erfaring, at det oftest er billigst at købe noget som allerede er udviklet.

Der skal være en mekanisme, som styrer hvad der sker, når en given leverandør ikke kan levere dele af en opgave, ellers fungerer et sådant oplæg ikke.

  • 0
  • 0
Log ind eller Opret konto for at kommentere