Succes med agile projekter – i light variant

Mange offentlige myndigheder ønsker at gøre brug af de principper, der er en del af det agile metodeapparat. Men de fleste kommer ikke i gang, da skiftet fra den klassiske projektmodel kan virke uoverskueligt i forhold til ændringen i det kontraktlige risikobillede.

Den klassiske projektmodel, bl.a. repræsenteret ved K01 og K02 kontakterne for it-anskaffelser baserer sig på vandfaldsmodellen, hvor grundlaget for leverandørens udvikling er kundens kravspecifikation, der præcist og endeligt fastsætter kravene til systemet. Kontrakterne baserer sig på én samlet afprøvning af systemet, hvor leverandøren efter endt udviklingsforløb står på mål for, at kravspecifikationen er overholdt – krav for krav. Til en fast aftalt pris.

Den klassiske projektmodel passer godt til det offentlige bevillingssystem og ansvarsregime. Man ved, hvad man får, og hvad det kommer til at koste, og man ved også, at man kan få pengene igen, hvis det går galt. I hvert fald i teorien.

Agile projekter baserer sig på den grundlæggende antagelse, at det ikke er hensigtsmæssigt eller muligt at specificere et færdigt system, inden udviklingen påbegyndes. Den overordnede løsningsramme, der er skitseret af kunden, skal i udviklingsforløbet fyldes ud af parterne i fællesskab. Fordelen ved dette er, at parternes fælles erfaringer og den løbende opnåede (mer)viden kan afspejle sig i projektet.

Selv om agile metoder har meget godt at byde på, så glemmer mange af fortalerne at eksekvering heraf i offentligt regi ikke er uden formelle og praktiske ufordringer.

Et skifte til agile metoder med fravær af garanti for slutprodukt samt en væsentlig ændring i ansvarsfordelingen mellem kunde og leverandør er uomtvisteligt et stort spring for de fleste offentlige projektansvarlige. Ud over de formelle udfordringer ved at få de bevillingsansvarlige med på legen vil mange ordregivere være nervøse for, om de kan håndtere de agile metoders indbyggede risiko for, at man undervejs i projektet træffer beslutninger uden at kunne overskue den fulde konsekvens heraf.

Hvis de agile metoder skal finde fodfæste og få en reel udbredelse er der behov for at tage transitionen fra den klassiske metode til den agile proces i mindre skridt.

Man skal huske, at agile projekter ikke er en entydig størrelse. Anvendelsen af agile metoder i praksis kan være meget forskellig – fra løse projekter med en høj grad af åbenhed i kundens behovsbeskrivelse og høj grad af interaktion med leverandøren, til projekter der kombinerer den klassiske vandfaldsmodel med agile elementer.

Mulighederne, der ligger i dette spænd af projektmetoder, er yderst interessant for de ordregivere, der gerne vil have en højere grad af fleksibilitet og leverandørdialog ind i projekterne, samtidig med at han ikke ønsker at miste den kontraktlige og budgetmæssige sikkerhed, som de klassiske modeller tilbyder.

Pointen er, at anvendelsen af agile metoder ikke nødvendigvis står i kontrast til den klassiske projektmodel, men at modellerne sagtens kan benyttes i forening. Vandfaldsmodellen med den kontraktregulering, der følger af denne vil eksempelvis egne sig godt ved udvikling af grundlæggende kernefunktionalitet eller systemintegrationer, hvor kunden præcist kan specificere sine krav.

Agile metoder kan anvendes som supplement til dette til eksempelvis at udvikle den brugerrettede funktionalitet, hvor kontinuerlig prioritering af kundens ønsker til systemet vil give en særlig høj grad af forretningsmæssig værdi.

I praksis kan man faseopdele et projekt på en sådan måde, at en del af leverancen leveres på baggrund af en klassisk kravspecifikation til en fast pris, og en anden del leveres på baggrund på baggrund af agile principper.

Kombinationen af de to modeller er ikke ukompliceret, men rigtigt implementeret er det min overbevisning, at parterne får mere værdi ud af samarbejdet, end de ville have fået ved anvendelse af den klassiske kontrakt, som ordregiver traditionelt ville have anvendt.

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Anonym

Det du skitserer, vil medføre, at en række virksomheder, skal lade sig kigge i kortene af andre virksomheder. Det har jeg svært ved at tro fungerer i praksis.

Merviden, har langt større værdi for leverandøren, end selve leverancen til en enkelt kunde. Knowhow deler man ikke med andre. Knowhow er alt ! Man kan gå ned og købe en Mercedes, og dermed have udvikling for milliarder i hånden. Det er helt ligegyldigt for Mercedes, deres værdi ligger i, at de kan bygge en Mercedes i en kvalitet og til en pris, der overgår hvad du kan gøre det for. Uanset, om så du får alle tegningerne.

Kunden, må lære at sætte realistiske kravspecifikationer op, på grundlag af en arkitektur der hænger realistisk sammen.

  • 0
  • 1
#2 Anders Christian Boisen

Jeg er ikke sikker på, at jeg forstår din kommentar. Jeg introducerer ikke et set-up, der giver leverandørerne særlige udfordringer i forhold til beskyttelse af knowhow, end hvad der i øvrigt følger af at deltage i offentlige it-projekter hvor leverandørens projekt-/udviklingsmetode bringes i spil sammen med kunden.

  • 0
  • 0
#3 Anonym

Så fostår jeg måske ikke hvor du vil hen.

Hvis man skal leverer ind på et agilt marked, er man tvunget til, kun at levere det produkt der indeholder specialistviden. Man konkurrerer på laveste fællesnævner. I forbindelse med IT, vil dette medføre, at man afgiver viden, uden at kunne kontrollerer i hvilken sammenhæng denne viden anvendes.

Polsag ? Skulle CSC stille op på deres specialistviden, som man jo var nået langt med, og har brugt mange penge på, for at denne viden kan bruges sammen med en anden leverandørs produkt. Nej vel, det ville jo være ren vidensoverførsel, fra CSC til en efterfølgende virksomhed. I den forbindelse, har jeg fuld forståelse for, hvis CSC trækker stikket.

Man får intet ud af at købe ind på den måde. Staten skal holde sig til det de kan, De skal være gode til at administrerer og kontrollerer deres indkøb. Der spares intet, ved den agile "gør det selv" fremgangsmåde, fordi Staten ikke kan "gøre det selv". Man opnår, at Staten kommer til at betale meget mere, for den samlede løsning.

Fra Statens side, savner jeg seriøs strategisk tænkning. En arkitektur der skaber et klart billede af, hvor man vil hen og på hvilket grundlag. Grundlaget, er det meget vigtigt at Staten har helt styr på, hvilket jeg ikke kan se man har. Fordi der ikke er et ordentligt grundlag, så skabes der ikke en sikker arkitektur.

  • 0
  • 0
#4 Anders Christian Boisen

Jeg tror vi skriver forbi hinanden :-)

Den model jeg gerne vil introducere er, at kunden opdeler sit projekt i to logiske dele. Den ene del leveres ud fra en klassisk projekttilgang og den anden del leveres ud fra en agil tilgang. Den samme leverandør leverer begge dele.

I øvrigt bør man blive bedre til at lave projekter, hvor Kunden opnår en mindre grad af binding til den leverandør, der oprindeligt har leveret et system (også uden at forretningskritisk knowhow kompromitteres). Det er f.eks. standardregulering i mange it-kontrakter, at kunden kan overlade vedligehold til tredjepart. Men i praksis sker det yderst sjældent. Jeg har ikke en løsning på udfordringen, men en ordentlig arkitektur og brug af standarder er nok en del af svaret.

  • 0
  • 0
#5 Deleted User

Hej Anders,

Super spændende indlæg som rammer præcist ned i problemstillingerne / uhensigtsmæssighederne ved de nuværende udbudsrammer, formaliseret i K01, K02 og K03.

Uden at gå i detaljer, vil jeg henlede opmærksomheden på de forsøg der er gjort i Arbejdsmarkedsstyerlsen (AMS), hvor man har gennemført udbud og eksekvering af Agile projekter, og det arbejde der foregår hos kammeradvokaten med udarbejdelse af en ny udbudsramme (K04), som har til formål at afstikke rammerne for Agile udbudsprojekter. K04 forventes klar i April 2012.

Med andre ord: Der er gode folk som allerede nu arbejder på at smidiggøre samarbejdet mellem det offenlige og de private IT-leverandører, og fremtiden vil (sandsynligvis) også åbne for agile projekter i det offentlige.

Mvh

Engagement Director, Capgemini

Ole Samuelsen

  • 0
  • 0
#6 Torsten Hagemann

Vi har med stor succes gennemført projekter efter præcist den model som Anders beskriver. Der var en garanteret minimumleverance fra start, samt at der blev aftalt en mindsteaflevering for hvert sprint, samt en fast ramme for det samlede projekt.

De aftalte minimumsleverancer var ikke i nærheden af at udfylde rammen, så der var luft til den nødvendige fleksibilitet i projektet.

Jeg opfatter de nævnte "logiske" dele som henholdsvis vores minimumsleverancer og vores fleksible leverancer, og vi oplevede faktisk kombinationen som temmelig ukompliceret.

Mvh

Torsten B. Hagemann Senior projektleder, principal konsulent Rehfeld Partners

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