Få gode råd til dig som offentlig kunde i mødet med den agile og innovative leverandør af it-løsninger.
I Lakeside oplever vi, at den offentlige kunde ønsker, at arbejde mere agilt i forbindelse med it-anskaffelser – særligt for at imødekomme leverandørerne. Den offentlige kunde oplever det dog som ganske vanskeligt at honorere leverandørernes agile setup. Der er indbyggede forudsætninger og vilkår ved den offentlige kunde, som fordre traditionel vandfaldsorienteret styringsmekanismer og mindset. Det er vilkår som fx. spredt beslutningskompetence, tværorganisatoriske styregrupper, manglende erfaring i nye udbudsformer og detailstyring fra politiske interesser osv. Så hvordan kan den offentlige kunde, trods vilkårene, give plads til den agile og innovative leverandør og sikre samskabelse ved it-anskaffelser uden at slippe styringen?
Vilkår for det offentlige
Den offentlige kunde, der foretager it-anskaffelser, skal som udgangspunkt gennemføre et udbud med en efterfølgende kontraktindgåelse. Inden at udbuddet påbegyndes, er der ofte et ønske om at have kvalitet, økonomi og tid på plads. Bl.a. for at kunne forventningsafstemme business casen med tværoffentlige, private og/eller politiske interessenter og tildele personer og midler til formålet.
Udfordringen er, at de problemområder som offentlige it-løsninger skal afhjælpe, bliver mere og mere komplicerede. Det gør det vanskeligt at definere kvaliteten/scope, med faste krav og høj detaljegrad, på forhånd. Og uden detaljerede krav til kvaliteten i starten af udbudsprocessen kan leverandørerne have svært ved at byde ind med en veldefineret økonomi og tid til efterfølgende styring.
Problemområdets karakteristika
Så længe problemområdet er simpelt, vil det være kendetegnet med en række “Known Knowns”. Altså som opskriften på pandekager, der udgør veldefinerede og velafprøvet ingredienser og fremgangsmåde (Known knowns) – og som kan gentages med samme resultat. Her er der oplagt mulighed for at kravspecificere med en høj detaljegrad, som komplette, korrekte og verificerbare krav.
Det bliver dog udfordret når problemområdets kompleksitet øges, hvor kravspecifikationen nødvendigvis må holdes mere konceptuelt. Den agile tilgang er i mange tilfælde nødvendig, når den offentlige kunde skal imødegå kompliceret eller komplekse problemområder og anskaffe en it-løsning. Uforudsete hændelser og erkendelser for kapabiliteter undervejs i anskaffelsen kan være vanskelige at definere og formalisere på forhånd – før virkeligheden rammer. Disse problemområder vil være karakteriseret ved en række “Known Unknowns”, men også “Unknown unknowns”. Altså som at foretage turen til månen, hvor der vil være begrænset praktisk erfaring, men dog med en række velkendte trin (Known unknowns), som der skal afklares inden afrejsen kan foretages. Mens hvis turen går til Mars, vil der pludselig ingen praktisk erfaring være og ingen veldefineret trin, så her vil der være mange ukendte og udefineret trin (Unknown unknowns).
Simpel og Kompliceret problemer er karakteriseret ved at være relativt “tamme problemer”:
- Regler giver retning
- Der findes rigtigt eller forkert
- Bygger på overensstemmelse
- Regulering sker bagefter
- Fokus på eksperter
Kompleks og Kaos problemer er karakteriseret ved at være relativt “vilde problemer”:
- Principper og visioner giver retning
- Der er fyldt med gråzoner (for rigtig og forkert)
- Bygger på mangfoldighed
- Beslutninger bliver taget undervejs
- Fokus på samskabelse
Så tilbage til spørgsmålet: Hvordan kan den offentlige kundes vilkår ved it-anskaffelse, give plads til den agile og innovative leverandør som samarbejdspartner? Og hvordan kan de meget forskelligartede verdener bøje sig mod hinanden for at opnå det bedste resultat?
Nedenfor har jeg samlet seks gode overvejelser, som den offentlige kunde bør gøre sig i arbejdet med det agile set-up.
Sådan skaber du et agilt udbud
1 | Afgør om problemområdet kræver en agil tilgang
Du bør overveje i hvilket omfang der er tale om et problemområde, der kræver en mere agil tilgang. Hvad er graden af innovation og samskabelse for it-anskaffelsen? Og hvor uklare er de funktionelle krav til løsningen samt hvor oplagt er det, hvordan IT-løsningen understøttes rent teknisk?
2 | Afgør om kontrakten kan indrettes mere fleksibel
Du bør overveje om der er dele af kontrakten, der kan være fleksibel og ikke fast-defineret ved kontraktindgåelse. Fx om enten omkostninger/tid eller scope først bør fastlægges senere i processen – efter kontraktindgåelse når erkendelserne står mere klart. Som udgangspunkt vil den agile Leverandør prioriterer det Agile manifest:
- Individer og interaktion – i stedet for proces og værktøjer
- Fungerende software – i stedet for omfattende dokumentation
- Kunde samarbejde – i stedet for kontraktforhandlinger
- Respondere på forandring – i stedet for at firkantet følge planen
Frit oversat fra Fowler and Highsmith (2001)
3 | Skærp it-anskaffelsens scope, definer mindre leverancer og tænd for det lange lys på strategien
Du bør fra starten tilstræbe at mindske kompleksiteten for, hvad løsningen skal imødekomme. Husk i den forbindelse at der skal være fokus på, at fastholde et fælles strategisk blik for problemområdet, så der altid er fokus på den lange bane – fx ved brug af målbillede eller målarkitektur for at afstemme, hvad der er en attraktiv fremtid. Du får mest ud af den agile leverandør, hvis du er i stand til at definere små leverancer og dermed forenkle de styringsmæssige opmærksomhedspunkter, men stadig have blik for det overordnet mål – fx ved at en forretningsansvarlig har til formål at fokusere på værdiskabelsen af it-løsningen og realisering af den attraktive fremtid.
4 | Match leverandørens profiler og beslutningskompetence
Du bør forberede dig på, at alt ikke kan analyseres og afklares via en ellers veldefineret foranalyse. I stedet skal du sikre dig, at der løbende kan tages stilling til det uforudsete og nye erkendelser.
Opbyg en samarbejdsorganisation med veldefineret beslutningskompetence på få hænder omkring udviklingen af it-anskaffelsen. Der bør tilstræbes, at uafklarede emner løbende kan afstemmes og besluttes (hurtigt og effektivt), uden at de skal i høring i diverse udvalg – og etablér en kontrakt, der kan rumme det. Det gør du bl.a. ved at matche leverandøren på ansvarsområder, som fx. forretningsansvarlig, tester, it-arkitektur og jura – enten med interne eller eksterne uvildige ressourcer.
5 | Balancer ressourceforbrug på foranalyse og udvikling
Du bør sikre plads til at invitere leverandøren med på rejsen for en bedre it-løsning ved at formulere krav til løsningen på et lidt højere konceptuelt abstraktionsniveau. Således er der bedre plads til innovation fra leverandøren i samskabelse med de relevante aktører, interessenter og slutbrugerrepræsentanter. Tilstræb altid at gøre krav komplette, korrekte og verificerbare og relatér dem til det større målbillede så du derudfra kan prioritere dem. Funktionelle og nonfunktionelle krav bør i højere grad tage udgangspunkt i hvad, der skal understøttes, og ikke hvordan det skal understøttes.
6 | Betragt IT-anskaffelserne som et produkt, der skal leve med vekslende leverandører over tid
Du bør overveje ejerskabet af din it-løsning samt hvordan den skal leve videre – også efter næste udbudsrunde. Hvis du vælger at hjemtage ejerskabet af løsningen, så betragt det som et produkt, der skal udbygges og videreudvikles over tid med en tilstrækkelig grad af dokumentation (fra dokumentation af forretningsmæssig, konceptuel strategi for arkitektur til dokumentation af de komponenter, der bygges og videreudvikles over tid). Sådan sikrer du, at it-løsningen kan overdrages til eventuelt nye leverandører.
