Husk de detaljerede krav i kravspecifikationen

Den konkrete formulering og fastlæggelse af det rigtige detaljeringsniveau af krav til et it-system er ikke en enkel øvelse. Den gældende anbefaling synes at være, at kunden skal fokusere på det overordnede forretningsbehov frem for at fortabe sig i detaljer.

Særligt har det store fokus på agile metoder været med til at trække kundens krav op på et højt niveau, der - afhængig af projektet karakter - evt. kan detaljeres i løbet af projektet.

Som anført i vejledningen til behovsopgørelsen i K03 statens nye standardkontrakt til agile projekter (kontraktens bilag 3a):

”Ved Kontraktens indgåelse er kravene til løsningen overordnet og behovsorienteret formuleret. Kravene nedbrydes og detaljeres herefter løbende.”

Højniveaukrav giver leverandøren et manøvrerum til at opfylde kundens behov med et løsningsdesign, der passer til leverandørens kompetencer og evt. standardkomponenter. Det giver en lav projektrisiko og en god pris. Med andre ord vejen til et succesfuldt projekt.

Man skal dog ikke have gennemført mange it-projekter, før man erfarer at åbne og overordnede krav ikke er en risikofri affære.

Rigtig mange kunder der har anvendt højniveau krav kender til den situation, at det man selv opfatter som helt sædvanlige og for kunden kritiske funktioner i et givent forretningssystem ikke finder vej til den løsning, der tilbydes.

Og hvis kravet ikke står sort på hvidt i kravspecifikationen, eller entydigt kan udledes af de beskrevne forretningsmæssige behov, kan kunden stå i en juridisk svag position, der betyder, at det kan være vanskeligt at flytte leverandøren. Resultatet er altid forstyrrelse af projektet og ikke så sjældent ender det med, at kunden skal bestille en ændring med ekstrabetaling og evt. udskydelse til følge.

Kunder, der har prøvet dette et vist antal gange, begynder at skærme sig af. Resultatet bliver at detaljerede krav stadig fylder op i kravspecifikationen. Det kan synes at stride mod de gængse anbefalinger og ideelle visioner om grundlaget for det gode it-projekt. Men er efter min vurdering udtryk for sund fornuft.

Jeg ser ikke en modsætning mellem en række detaljerede krav og en høj grad af frihed for leverandøren til at præsentere det konkrete løsningsdesign. Det afhænger helt og holdent af, hvilke krav der stilles.

Den realiserbare vej til et godt it-projekt, der kan afvikles inden for den fastlagte økonomiske ramme, er den rette kombination af overordnede forretningsmæssige krav kombineret med udvalgte detailkrav, der afspejler specifikke præcise behov, som kunden vægter højt. At identificere disse krav og adskille skidt fra kanel er ikke enkelt og kræver ofte et høj grad af kendskab til kundens forretning og de løsninger, der er på markedet. Men indsatsen er efter min mening besværet værd frem for at forlade sig på at de overordnede krav blot succesfuldt kan brydes ned i dialog med leverandøren.