En god kravspecifikation er mere end de rigtige krav
Kravspecifikationen spiller en central rolle i enhver kontrakt om levering af it-ydelser. Det er kravspecifikationen, der beskriver, hvad det er for en ydelse, som kunden ønsker at anskaffe og er oftest styrende for, hvad det er, leverandøren skal levere.
Uanset valg af kravspecifikationsmetode er det selvfølgelig væsentligt, at kravspecifikationen er formuleret præcist og entydigt. Erfaringsmæssigt er det dog vanskeligt at udarbejde gode kravspecifikationer. Det kræver godt håndværk og et samspil mellem forretningsmæssige, juridiske og tekniske kompetencer.
Kravene i kravspecifikationen suppleres af krav/vilkår i de øvrige kontraktbilag, der f.eks. regulerer servicemål, afprøvning og samarbejde.
Trods et stort fokus på at formulere relevante krav glemmer ordregiver alt for tit, at kravet i sig selv ikke kan stå alene.
Jeg ser ofte to overordnede problemer ved kravspecifikationen (og krav i øvrige faglige bilag):
- Ordregiver har ikke gjort sig det klart, hvordan leverandøren skal besvare kravene
- Krav om besvarelse af trivielle detaljer tager overhånd
Ad 1. Den konkrete besvarelse af krav. Trods meget omfattende kravspecificeringsprocesser er det min oplevelse, at der ofte ikke er taget kritisk stilling til, hvordan leverandøren mest hensigtsmæssigt skal besvare kravene, og hvordan leverandøren samtidig skal udarbejde og strukturere sit løsningsforslag.
Leverandørens løsningsforslag (inklusive kravbesvarelse) tjener flere formål: Løsningsbeskrivelsen skal både kunne anvendes som grundlag for en kvalitativ evaluering med henblik på valg af det bedste tilbud og skal efterfølgende kunne indgå som et forpligtende dokument, der entydigt beskriver hvordan kundens krav i praksis udmøntes i en løsning. Endelig skal løsningsforslaget i forening med kravspecifikationen og øvrige bilag sikre, at kunden som led i en løbende contract management tydeligt kan verificere, at det der leveres som aftalt.
De beskrevne formål opfyldes ikke nødvendigvis på samme tid. Man skal derfor sikre sig, at alle dele er håndteret.
Ad. 2. De trivielle detaljer tager overhånd. Flere ordregivere glemmer, at selv om leverandørerne naturligvis gerne vil vinde opgaven, så er det voldsomt dyrt at udarbejde tilbud, dvs. der er en naturlig øvre ramme for, hvor mange ressourcer leverandøren kan kaste efter tilbudsudarbejdelsen.
Ordregiver gør derfor både sig selv og leverandøren en tjeneste ved at lave et udbudsmateriale, der hjælper leverandøren til at fokusere på de dele, der giver reel forretningsmæssig værdi.
Inden man beder om bekræftelse eller redegørelse for alle mulige detaljer i udbudsmaterialet, bør man kritisk spørge sig selv, om der nu også er et konkret behov for at få en aktiv tilbagemelding fra leverandørens side, eller om større dele af udbudsmaterialet i praksis udgør generelle og acceptable grundvilkår for leverancen.
Hver gang leverandøren aktivt skal svare tilbage, er der en risiko for, at han enten svarer forkert eller afgiver en uklar/uhensigtsmæssig besvarelse.
Min anbefaling er derfor: Overvej nøje den form, du vil have besvarelsen af krav på og efterspørg alene tilbagemelding på de dele af udbudsmaterialet, hvor du reelt er interesseret i at få et svar.
Om Anders Christian BoisenAnders 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 (4)
Netop en fejlfortolkning af kravspec'en er en af hovedårsagerne til, at mange offentlige IT-projekter er endt i skandaler. Hyrede konsulenter (i f.t. det offentlige) har ikke sjældent en tendens til udelukkende at se på de eksisterende arbejdsgange og forsøger at please myndigheden, der til gengæld meget ofte har en overbevisning om, at de er så unikt specielle og specialiserede netop hos dem, at ingen standardvare passer til deres behov, men at de absolut må have noget skræddersyet.
Måske man kunne forestille sig en situation, hvor netop de hyrede konsulenter til kravspec'en pludselig bliver til leverandører - eventuelt i et partnerskab, når de indser, at ingen andre er interesserede i at deltage i dette cirkus.
Og mon det måske netop den situation, der dækker over, at udbudsmaterialet til et BI-system til Christiansborg måtte trækkes tilbage? (http://www.version2.dk/artikel/jura-broeler-vaelter-udbud-bag-stort-bi-s...)
-
1 -
1
Det største problem med den klassiske kravsspecifikation er at lige så snart projektet er en lille smule omfattende ved kunden ikke hvad han reelt vil have, og det kan man faktisk ikke fortænke ham i.
Det er de færreste der kan overskue bare et lille IT projekt, hvilke implikationer det vil have, hvordan det bliver modtaget af brugerne, hvordan krav og den omkringliggende verden, vil forandre sig, hvordan tekniske forudsætninger ændrer sig etc. Med mellemstore og store IT projekter er det umuligt. Det er den helt grundlæggende problemstilling som specielt det offentlige slet ikke fokuserer på. Selvfølgelig kan man ikke specificere et projekt som F.eks. Polsag der har en omfattende funktionalitet og skal snakke med et hav af legacy databaser og forvente at få et godt resultat.
Gode IT projekter bliver bygget i tæt kontakt med kunden, og en byggesten ad gangen. Hvis vi vil have bedre IT projekter er det metoden der skal ændres. Den klassiske waterfall metode er forældet og fungerer simpelthen ikke med dagens komplicerede projekter.
-
3
-
0
Jeg er enig i at man er nød til at fokusere på muligheden for at indbygge (og efterfølgende nyttiggøre) fleksibilitet i kontrakterne.
En del af en løsning kan naturligvis være at bide projekterne op i mindre dele og arbejde med agile/iterative elementer suppleret af krav på et højere niveau. På papiret lyder det enkelt, men hvis der skal værdi ud af den slags processer stiller det store krav til ordregiver. Mit indtryk er, at de fleste organisationer på nuværende tidspunkt ikke er klar til det.
I mange projekter baseret på klassiske kontrakter tror jeg dog også, at man kan komme langt, hvis ordregiver blot husker på, at man ikke for enhver pris skal holde fast i alle ender af kravspecifikationen. Her må leverandøren gerne spille en mere aktiv rolle, så han hjælper kunden til at træffe de rigtige valg.
-
0
-
0
En del af en løsning kan naturligvis være at bide projekterne op i mindre dele og arbejde med agile/iterative elementer suppleret af krav på et højere niveau. På papiret lyder det enkelt, men hvis der skal værdi ud af den slags processer stiller det store krav til ordregiver. Mit indtryk er, at de fleste organisationer på nuværende tidspunkt ikke er klar til det.
Medstifter af et mindre firma der laver kundetilpassede systemer agilt from scratch. Min erfaring er at det stiller små krav til ordregiver. Det arbejde du beskriver med at opstille en fornuftig bindende kontrakt, er overordentligt svært - i modsætning hertil består vores proces gerne af nogle mundtlige interviews fulgt op af nedskrivning af hovedpunkter på stikordsform og diskussioner om tvivlspørgmål. Og så er man i gang. Det at der tages små bidder, gør at risikoen for begge parter er lille, og projektet er let at styre fordi der løbende er konkret kørende output.
Hvis du læser Fred Brooks' Design of Design (kan findes på f.eks. Amazon), vil du erfare at vandfaldsmodellen af dens navngiver blev opstillet som et tænkt eksempel på hvordan man IKKE skal gøre. :)
De erfaringer jeg har gjort mig med nedskrevne kravsspecifikationer, er at de er temmelig dårlige at implementere ud fra i forhold til den mundtlige metode. Der opstår hurtigt situationer hvor man må vælge mellem at opfylde kontrakten eller opfylde behovet.
-
1
-
0
Tilføj kommentar
