Når først kunden og leverandørens advokater har taget over på et it-projekt, fører det oftest til en lang kamp i bokseringen med venstrehooks, uppercuts og jabs i form af juridiske paragrafer, kontrakter og sagsanlæg.
Det var for eksempel tilfældet med Amanda, der næsten er gået hen og blevet synonym med it-skandale.
Projektet gav store forsinkelser, arbejdsnedlæggelser og gensidige trusler om sagsanlæg mellem Arbejdsmarkedsstyrelsen og CSC, der stod for udviklingen.
Et af konfliktpunkterne var kravene til systemet, som blev fortolket på en måde af leverandøren og en anden af kunden. I sidste ende førte det til et besværligt og ustabilt system, som dog i store træk levede op til de opsatte krav.
Men med en ordentlig forarbejdet kravspecifikation, kan du dog et lang stykke hen ad vejen sørge for, at du aldrig ender i den juridiske boksemølle.
Kravspecifikationen er alfa omega
For den berygtede kravspecifikationen er, hvad sjippetorvet er for bokseren, nemlig helt uundværligt.
"Kravspecifikationer er alfa omega. Vi kan estimere prisen og tiden forkert, men hvis vi ikke ved, hvad det er, vi skal lave, så er vi rigtig på herrens mark. Så kommer alle juristerne rendende," siger Otto Vinter, der betegner sig som software engineering-mentor.
Otto Vinter er også ansat som ekstern lektor på masteruddannelserne i projektledelse og procesforbedring ved Roskilde Universitet. Han fortæller at hans kursister måber, når de ser, hvad en kravspecifikation bør indeholde.
"Når jeg viser dem, hvad der skal stå i en IEEE standard 830 kravspecifikation, bliver de forbløffede og siger 'så meget, så detaljeret?'," siger han, og følger selv op med svaret:
"Ja venner, det fylder en bondegård og en helvedes masse arbejde, og alligevel har I ikke sikkerhed for, at det holder."
Dette er den største fejlkilde
Du skal vide, hvad der skal laves
Men ifølge lektoren er der ingen smutveje, når man skal til at gå i gang med et it-udviklingsprojekt. Du bliver simpelthen nødt til at vide, hvad det er, der skal laves. Det er hele grundlaget for projektet:
"Kravspecifikation er en forudsætning for, at du kan lave en nedbrydning af, hvad der skal leveres. Ved at dele det op i arbejdspakker og aktiviteter kan vi styre projektet, og derved lave en tidsplan og i virkeligheden også komme med et tilbud. Man må derfor sige, at kravspecifikationen er yderst central."
Og hvis du fra start af ryster på hænderne, ja så er det ikke nemt at ramme plet.
"Hvis du har en 'shaky' kravspecifikation, som er formuleret vattet og usikker, hvordan kan man så lave den videre nedbrydning af aktiviteter eller komme op med en holdbar løsning?"
Leverandøren kan selvfølgelig begynde at gætte.
"Ja, de kan da være heldige at gætte rigtigt. Men i praksis viser det sig, at kunden ikke altid ved, hvad han vil have. Der er altid et hjørne, hvor kunden bevidst eller ubevidst har udtrykt sig vagt eller på en måde som kan misforstås," siger han og forsætter:
"Når leverandøren kører på med en misforståelse, og man kommer til en accepttest, vil kunden i værste tilfælde stille sig forurettet op og sige, 'det har jeg da aldrig sagt eller ment'."
Største fejlkilde er misforståelser
Vil du undgå at projektet ender i tolvte runde og juristerne skal tælle pointen sammen i form af brudte aftaler, krav og paragraffer, så handler det blandt andet om at fjerne misforståelserne i kravspecifikationen.
"For en del år siden lavede professor Søren Lauesen og jeg en undersøgelse, der viste, at den største fejlkilde i it-systemer skyldes misforståelser mellem dem som skrev kravspecifikationen, og dem som skal lave it-systemet. Det er selvfølgelig på alle niveauer, og er både fra kunde- og leverandørsiden," siger han.
Det er tilsyneladende stadigvæk sådan, mener Otto Vinter:
"Jeg har ikke lavet eller set andre undersøgelser af fejlkilder siden. Min fornemmelse er dog stadigvæk, at hvis du tager en vilkårlig kravspecifikation i hænderne, skal du ikke mere end fem linjer ned, før du siger 'hvad pokker mener de her?'."
Ramme plet med lukkede øjne
Og det forværrer problemet, hvis du ikke kan gribe telefonen og ringe til kunden og få en forklaring.
"Hvis det er en fleksibel kontrakt, og man har mulighed for løbende kontakt med kunden, så kan en dårlig og spinkel kravspecifikation måske godt gå. Men tager vi for eksempel EU-udbud, har du som leverandør ikke mulighed for at spørge kunden - for det kan give unfair konkurrence."
I nogle tilfælde skal leverandøren derfor forsøge at ramme plet med lukkede øjne.
"Hvad gør man som leverandør, når man ikke præcist ved, hvad kunden vil have, og man ikke har kommunikationen. Ja man forsøger at lægge en sikkerhedsbuffer eller noget andet ind. Men i virkeligheden beder og håber man på, at det her kommer til at gå godt, og at ens tilbud er lavere end de andres," siger Otto Vinter.
Her ligger ansvaret
Og hvis ansvar er det så?
Kravspecifikationen burde sætte klare retningslinjer op for et it-projekt og på den måde styrke samarbejdet - i sidste ende er det kundens ansvar.
"Det er kundens ansvar at lave en fornuftig og god kravspecifikation fra start. Det er den, der skal klargøre reglerne eller mangel på samme i det fremtidige system, og få klargjort, hvad det er, de vil have," mener Otto Vinter, der samtidig tilføjer:
"Jeg synes derfor, det er ligeså vigtigt, at leverandøren påtager sig et ansvar. Det hedder at tjekke kravspecifikationen for huller, uklarheder og krav, som kun svært kan lade sig gøre," fremhæver han.
Her er et paradoks
På den anden side skal man også passe på med regler, begrænsninger og krav. Det skal heller ikke ende med det rene fedtspil på egen banehalvdel, hvor man lurer på, at den anden begår fejl først.
"Kunden vil selvfølgelig gerne have, at leverandøren kommer med den mest moderne, bedste og nyeste teknologi. Derfor bliver nogle kravspecifikationer lidt bløde i kanterne - man lader vær med at tage stilling til for meget, for dermed ikke at udelukke geniale løsninger," siger Otto Vinter.
Men hvis leverandøren ikke kan læse og forstå, hvad brugerne og kunden i virkeligheden vil have, er det gift for leverandøren.
Dette paradoks - at kunden på den ene side gerne vil have innovative og geniale løsninger, men på den anden side vil have hånd i hanke med systemet - løses meget simpelt ved for det første at lave den 'gode' kravspecifikation.
Det handler for eksempel om at beskrive rationalet bagved hvert krav.
"Det vil sige, hvorfor vil jeg som kunde have det her? Herved kan leverandøren nemlig ledes til at forstå bevæggrunden eller rationalet for kundens krav og dermed bedre forstå, hvad det reelt er kunden vil have," forklarer han.
Det skaber bedre afklaring og bedre kommunikation mellem parterne.
"Med en 'god' kravspecifikation bliver det også nemmere for leverandøren at stille intelligente spørgsmål og komme på bølgelængde med kunden, og det er meget vigtigt for at få succes med udviklingsprojekter," siger han.
Vi skal lære at lave 'gode' krav
Derfor er det ikke specielt brugbart bare at sætte sig ned og gætte på, hvad der skal være i en kravspecifikation.
"Kunden er nødt til at have nogle teknikker, redskaber og folk, der hjælper dem med at forbedre kravspecifikationerne. Det kan godt være, de i sidste ende stadig skal være på tekstform og godkendt af kammeradvokaten og alt det der," siger Otto Vinter og pointerer:
"Men det betaler sig i sidste ende, hvis kunden får afklaret de ting, der kan give anledning til misforståelser."
Problemstillingen er ikke anderledes, hvis vi taler om et mere agilt projekt.
"Præcisionen i krav er nøjagtig den samme, hvad enten du arbejder med 3000 siders kravspecifikation eller arbejder med stories til et sprint - forstår jeg hvad kunden reelt siger?"
Konsekvenser er måske bare lidt mindre, når man arbejder i sprints på for eksempel en måned i et agilt projekt.
Men ikke desto mindre er du godt på vej mod en svingende knock-out, hvis du ikke får styr på din kravspecifikation.
"Jo færre misforståelser og ændringer til krav, du har undervejs - desto mere jævn glidende udvikling får du. Så ja, kravspecifikationer er alfa og omega,"
