Debat

Debat: Drop illusion om fuld beskrivelse af krav og behov i it-projekter

DEBAT: Kunde og leverandør skal sammen opnå indsigter og justere løsninger i agile it-projekter. Vi må droppe illusionen om at foregribe alle behov og krav, skriver Dina Raabjerg.

Fordelen ved agile projekter er, at man hurtigere får udviklet noget, der kan give en reel værdi
for den forretning, der skal understøttes, skriver Dina Raabjerg.
Fordelen ved agile projekter er, at man hurtigere får udviklet noget, der kan give en reel værdi for den forretning, der skal understøttes, skriver Dina Raabjerg.Foto: Ólafur Steinar Gestsson/Ritzau Scanpix
Dette indlæg er alene udtryk for skribentens egen holdning. Alle indlæg hos Altinget skal overholde de presseetiske regler.

Af Dina Raabjerg
Senior Manager, Systematic

Mange tror, at alle offentlige it-projekter er de rene it-katastrofer.

Mange it-projekter bliver imidlertid både implementeret og understøtter forretningen ganske godt.

Nogle projekter lykkes på trods af elendige rammer.

Fakta
Dette indlæg er alene udtryk for skribentens egen holdning. 

Alle indlæg hos Altinget skal overholde de presseetiske regler.

Debatindlæg kan sendes til [email protected].

Andre projekter lykkes, fordi der både er vilje, fleksibilitet og indsigt hos deltagerne.

Jeg har tidligere skrevet om, hvordan kunden og leverandøren først får det fulde indblik i behov og muligheder, når man er i gang med at udvikle og teste en løsning i dens kontekst.

Vi må droppe forestillingen om, at leverandøren i tilbudsfasen kan regne ud, præcis hvad der skal til for at skabe den rigtige løsning. 

Dina Raabjerg
Senior Manager, Systematic

Jeg har desuden argumenteret for, at vi bliver nødt til at flytte fokus fra jura og processer til forretningens behov.

Det betyder, at vi må droppe illusionen om, at kunden på forhånd kan foruddiskontere og beskrive alle behov og krav.

Og vi må droppe forestillingen om, at leverandøren i tilbudsfasen kan regne ud, præcis hvad der skal til for at skabe den rigtige løsning.

De optimale rammer for succes i de store og komplekse it-projekter kræver en proces, hvor kunden og leverandøren sammen opnår indsigt og designer, tester og justerer løsningen i takt med, at alle bliver klogere.

Tag en agil tilgang
Vi ser derfor i stigende grad it-projekter, hvor en kunde gennemfører et såkaldt Proof-of-Concept med en leverandør. Her tester parterne nogle teknologier og designs for at se, hvordan de virker i praksis.

Med afsæt i resultatet fastlægger kunden det endelig scope og overordnede krav for sin it-løsning. Og leverandøren fastlægger det endelige tekniske design. Nu baseret på viden og ikke kun hypoteser.

Fælles for denne type projekter er, at kunden ender med at ændre sine oprindelige krav og mål.

Fælles er også, at det typisk er samme leverandør, der har lavet Proof-of-Concept, som også udvikler den endelige løsning. Fordi denne leverandør kan gøre det hurtigere, bedre og billigere end en leverandør uden samme indsigt.

Denne type projekter forhindrer derfor, at man kommer skævt fra start.

Vi ser også flere projekter, hvor man reelt arbejder agilt. Det vil sige projekter, hvor man efter den første planlægning af projektet hele tiden tester, evaluerer, prioriterer og justerer sin udvikling undervejs i projektet i forhold til det, der giver allermest værdi for forretningen.

Fordelen ved denne type projekter er, at man hurtigere får udviklet noget, der kan give en reel værdi for den forretning, der skal understøttes.

Kontrol må vige for fornuft
Mange kunder er desværre bange for agile projekter. Fordi de er bange for at miste kontrollen med projektet og resultatet, som jo flytter sig. Og de er også bange for, at de ikke får det, de havde tænkt at betale for, eller at projektet sprænger økonomien.

Mange er også bange for at knytte en leverandør for tæt til sit projekt i et Proof-of-Concept af hensyn til et ligebehandlingsprincip.

Imidlertid mener jeg, at behovet for kontrol må vige pladsen for fornuft. Med et Proof-of-Concept får alle parter viden om mål, økonomi og rammer, inden det er for sent at sadle om. Det er fornuft.

Læs også

Derfor må man skære sit udbud på en måde, så denne type afklaringsprojekt kan indeholdes.

Dernæst skal man sikre at det agile projekt bliver styret af kompetente og erfarne nøglepersoner, som evner at lede og justere projektet, så økonomi, løsning og forretningens behov hele tiden balanceres.

Dette er også fornuft.

Budskabet er således, at ved at være bevidst inkompetente, kan vi vælge en metode i it-projektet, der tager højde for usikkerheder.

Og kun ved at vælge en sådan metode, kan vi sammen kan skabe en succesfuld it-løsning.

Politik har aldrig været vigtigere

Få GRATIS nyheder fra Danmarks største politiske redaktion

Omtalte personer

Dina Myrup Raabjerg

MF (K)
cand.oecon. (Aalborg Uni. 1996)

0:000:00