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.

Anders Christian Boisens billede
Anders er manager hos Rambøll Management og rådgiver om juridiske aspekter ved digitaliseringsprojekter og it-udbud i den offentlige sektor. Han blogger om emner mellem teknologi og jura med fokus på offentlige myndigheders gennemførelse af digitaliseringsprojekter.

Kommentarer (2)

Ole Laursen

Ud fra et agilt synspunk vil man jo pege på nogle andre håndtag man kan trække i:

  • Formulér en vision og prioritér funktioner så det er tydeligt hvad der giver mest værdi for organisationen
  • Acceptér aldrig lange leverancer (f.eks. over 2 ugers udviklingsarbejde), for at minimere risici
  • Tjek op på produktet løbende, skrid ind i samme øjeblik noget ser forkert ud
  • Sørg for screening af interne projektdeltagere - er de kompetente nok, kan de finde ud af at kommunikere, holder de øje med projektets udvikling?
  • Sørg for screening af leverandør - er udviklerne kompetente og lyttende, stiller de kritiske spørgsmål og kommer med indspark?
Søren Grundtvig Westh

Kære Anders

Jeg er meget enig i dine betragtninger. Jeg har som konsulent også oplevet kunder komme i klemme, fordi deres krav var for upræcise.

Leverandører er jo som udgangspunkt interesseret i at skabe et godt produkt sammen med kunden. Men leverandørerne skal jo også leve af deres produkter. Så hvis man som virksomhed ikke er afklaret omkring, hvad man vil opnå, så ender det hurtigt med at der kommer en række ændringer til det planlagte. Ændringer der kun er én til at betale.

Agil udvikling har vundet indpas, som svaret på dette. Så kan det jo ikke gå helt galt.. Fordi vi begrænser det tabte arbejde, hvis vi bliver klogere undervejs. Men det laver ikke om på, at der vil komme tabt arbejde. Og det er som direkte konsekvens af, at man ikke har 'tænkt sig godt om' fra start. Og selvom du arbejder agilt, så kan du spilde meget tid, hvis du starter med det forkerte fundament.

Hvorfor tænker alle sig så ikke bare godt om fra start, kan man spørge sig selv? Det skyldes naturligvis at systemudvikling (med eller uden standardsystemer som basis) er en kompliceret størrelse. Det kan være svært at overskue konsekvenserne ved de valg og de krav man stiller.

Jeg har i PA Consulting været med til at udvikle Visuel Kravspecifikation: En metode, hvor vi benytter visuelle virkemidler sammen med kunden til at beskrive deres krav ved hjælp af bl.a. prototyper, filmsekvenser og rollespil. På den måde sikrer vi at der er en konkret forståelse for virksomhedens behov og krav til løsning, der er forstået af alle interessenter. Populært sagt, så skaber vi et fælles billede af løsningen, inden den første byggesten er lagt.

På baggrund af den visuelle kravspecifikation, kan man vælge at arbejde agilt - eller på en fastpriskontrakt.

Uanset, vil man have sikret, at man stiller de 'rigtige' krav fra start og har et stabilt fundament at bygge på.

Log ind eller opret en konto for at skrive kommentarer

IT Businesses