Til gengæld kan det være rent gætværk, hvis man kender kravet og prøver at tænke sig frem til, hvad baggrunden er. Desuden har man ofte brug for viden om baggrunden, når man skal tage beslutninger i løbet af et projekt, mens selve kravene mere er skrevet til brug, når systemet er udviklet.
Det er sund fornuft at tænke over, hvordan kravene skal anvendes, allerede mens man skriver dem. Derfor tænker en juridisk rådgiver uvilkårligt over hvordan et krav kan blive misforstået hvis man ender i en retssal, mens IT-specialisten kan tænke over hvordan man kan teste om kravet er opfyldt, uden at vide om det overhovedet er muligt at opfylde det.
Ingen af dem føler at de behøver baggrundsviden om, hvorfor kravet er formuleret præcist som det er. De kan endda være bange for at oplysninger om baggrunden for et krav kan starte diskussioner om, hvordan det egentlig skal forstås.
Beslutninger i løbet af projektet
****I løbet af projektet, er det ofte mindst lige så afgørende at kende baggrunden for de forskellige krav, som at kende selve kravene. Især når man skal tage de beslutninger som er nødvendige for at bringe projektet videre.
De fleste IT-projekter er i dag baseret på eksisterende platforme eller applikationer, hvor man let ryger ind i deres indbyggede begrænsninger. Hvis man har opstillet nogle præcise krav som skal være opfyldt, kan man risikere at der ikke findes en applikation som kan bruges til at opfylde dem, eller at den platform som firmaet har valgt at strategiske årsager, ikke kan opfylde dem.
Her har man brug for baggrundsviden om organisationens og brugernes behov, hvis man på en eller anden måde skal manøvrere sig ud af den knibe, eller i det mindste finde den mindst dårlige løsning.
Det er meget almindeligt, at ledelsen i dag vil se en business case, før den afgør om et projekt skal gennemføres. Det kræver ikke bare en baggrundsviden, så man kan vurdere hvor meget systemet kan spare. Det kræver så god en baggrundsviden, at man kan vurdere om de gevinster som andre tror systemet giver, overhovedet er realistiske.
Realisering af systemet
****Leverandøren eller udviklerne har brug for baggrundsviden, så de kan finde ud af hvordan den enkelte funktion bedst realiseres. For nogle år siden lavede jeg en uformel undersøgelse af kravene til krav. Her blev jeg overrasket over, hvor meget udviklere satte pris på at kende formålet med de enkelte funktioner, hvem der skulle anvende dem og i hvilke situationer. Det var også klart for mig efter undersøgelsen, at udviklere føler sig langt mere motiverede, når de kender baggrunden for det enkelte krav og den enkelte funktion.
Det er ret almindeligt, at der er så mange forskellige krav og ønsker til et projekt, at det er nærmest umuligt at lave et system som kan bruges og som opfylder dem alle sammen. I hvert fald indenfor den tid og det budget der er til rådighed. Nogle gange er man endda nødt til at skære noget væk undervejs, for at undgå at projektet bliver endnu mere forsinket. Det kræver også en baggrundsviden, så man kan vurdere konsekvenserne af at udelade noget. Ellers bliver fravalget i værste fald tilfældigt eller baseret på kompromisser og en magtkamp, og man kan risikere at det der er tilbage, ikke hænger sammen.
**Sikring af, at det hele er med. **
****Endelig behøver man noget baggrundsviden om behovene og organisationen, for at finde ud af hvad der mangler at blive undersøgt, før kravene er komplette. Det kræver at man kender ledelsens mål med organisationen og projektet, og at man har fundet frem til alle de grupper som kan komme i kontakt med systemet eller som forhåbentlig kan få gavn af det.
Det lyder måske indlysende.
****Spørgsmålet er så, hvorfor man ikke gør mere for at skaffe pålidelig baggrundsinformation i kravarbejde. Jeg kan se to forklaringer. Den ene er at der ofte er et tidspres, så man bevidst eller ubevidst fokuserer på bare at få selve kravene færdige. Den anden er, at de fleste som arbejder med krav savner metodikker som kan give en solid og pålidelig baggrundsinformation.
Jeg er ikke nogen synderligt stor fan af udbudsmetodikken, men skal det være var det måske en ide at få baggrunden i stedet for kravene fældet ned i udbuddet og så lade byderene selv skrive en kravspecifikation, ikke blot bør det give en kravspecifikation som er til at arbejde med, det giver også udbyderen en god mulighed for at aflure hvor godt en byder har forstået opgaven.
Dog er en lind strøm af feedback fra kunden nok stadigvæk det vigtigste våben imod afsporede projekter.
Jeg plejer altid at sige til forretningsfolkene at det er meget vigtigt at de starter med at skrive hvorfor de laved de krav de laver. Hvorfor er lige så vigtigt som selve kravet.
