Når der skal gennemføres et portalprojekt, indføres et nyt intranet eller indkøbes et CMS, er der mange både offentlige og private organisationer, der bruger kravspecifikationer som værktøj til indkøb af både systemer og serviceydelser.
Oftest bliver kravspecifikationen sendt ud til flere leverandører, som bliver indbudt til at afgive tilbud på opgaven og vinde projektet. Køberen vælger blandt de indkomne tilbud og køber det, der bedst passer til krav og budget.
I nogle brancher er kravspecifikationer noget, man prøver at undgå. De tager tid at lave, og hvis der går for lang tid, kan realiteterne og vigtige krav have ændret sig inden projektet bliver gennemført. Muligheden for at have en kvalificeret dialog om krav og forventninger er værdifuld, og derfor frarådes det at undlade at udarbejde en kravspecifikation. Manglende kravspecifikation er oftest en alarmklokke og et tydeligt signal på, at kompleksiteten er blevet undervurderet.
Før man går i gang med kravspecificering, er det vigtigt at have gennemført en analyse fase, der som minimum bør afklare formål og målgruppe med projektet. Overordnede rammer som strategi med målbare succeskriterier, budget og organisation skal også være på plads. Tænk også på, hvem der forventes at levere indhold.
Hvad skal en kravspecifikation indeholde?
Det bedste forsvar mod tilbud af ringe kvalitet er at lave en godt organiseret kravspecifikation, som leverandører kan følge.
I grove træk skal en kravspecifikation indeholde følgende afsnit:
- Opsummering: Hvilket problem skal løses, og hvilke behov søges tilfredsstillet Målbare succeskriterier.
- Administrativ information: Kontakt data, deadline, formalia, vigtige definitioner og afgrænsning
- Tekniske krav
- Leverandøren skal kunne forstå det eksisterende IT-landskab, herunder hvilke systemer der skal integreres med. Her nævnes også krav til oppetid, svartider, back-up, clustering, load-balancing, dynamisk/statisk levering
- Implementering: Hvilke krav er der til projektledelse og gennemførelse af projektet. Hvilken rolle er det tilsigtet at leverandøren skal have? Hvilke arbejdsgange skal forbedres? Hvordan ser det ud fra brugerens synsvinkel? Hvad er forbindelsen fra de forretningsmæssige mål til kravene? Skal leverandøren bruge bestemte metoder og værktøjer (f.eks. use cases, prototyping, agile, extreme programming, usability test). Hvor meget træning er nødvendig?
- Leverandør kvalifikationer og referencer.
- Yderligere information fra leverandøren: Hvis leverandøren har relevant, men ikke påkrævet information at tilføje
- Pris: Hvordan skal dette præsenteres?
- Kontrakt og licensaftale: Alle juridiske detaljer
- Bilag, der indeholder relevant information, så som netværksdiagrammer, projektplaner og forretningskrav.
De enkelte punkter i kravspecifikationen kan med fordel markeres med et “K” for krav og et “Ø” for ønske. Kravene er forbeholdt de elementer, som er strengt nødvendige, mens ønskerne forventes tilgodeset. Se eksempler på krav i vores artikel om rimelige forretningskrav.
Typiske faldgruber
Nedenunder følger nogle af de problemstillinger, som organisationer har oplevet, når de har arbejdet med kravspecifikation og valg af leverandør:
- Mangel på markedsforståelse: Det er leverandørens største frygt, at der allerede er valgt et system, og at de spilder deres tid. Dette opleves oftest, når en kravspecifikation tydeligvis er skrevet, så den favoriserer nogle leverandører. Ofte sker dette, når projektdeltagerne ved meget om et enkelt system, men mangler sammenligningsgrundlag. Få aldrig en leverandør til at lave kravspecifikationen
- Dårligt definerede krav: Man skal ikke blive for detaljeret, men alligevel sikre sig, at de krav, der fremsættes, er tilpas definerede og rimelige. Et krav om integration med alle nuværende og fremtidige versioner af SAP er urimeligt og meningsløst. På samme måde giver det heller ikke meningsfulde svar at kræve, at alle W3C standarder bliver overholdt. Vær konkret med dine kravformuleringer
- Mangel på intern koordination: Sørg for, at alle de interne roller er repræsenteret, herunder udviklere, administratorer, redaktører og ledere. Især redaktørerne, som bliver vigtige daglige brugere, er ofte glemt i fasen, hvor der arbejdes med kravspecificering
- Nærmest ens svar fra leverandørerne: Det er vigtigt at få leverandørerne til at beskrive, hvordan krav bliver opfyldt, og ikke kun om de bliver opfyldt. Sørg for at formulere spørgsmålene, så du kan forvente forskellige svar. I stedet for at skrive: “Skal understøtte WYSIWYG redigering”, så skriv: “Hvordan understøttes WYSIWYG redigering?”. Hvis en af leverandørerne beskriver et ActiveX modul, som dine sikkerhedskollegaer alligevel aldrig ville godkende, har du lært noget vigtigt meget tidligt i processen.
Det er kun første skridt i en længere proces at lave og udsende en kravspecifikation. Senere følger besvarelse af spørgsmål fra leverandører, gennemgang af de indkomne tilbud, etablering af evalueringskriterier, besøg ved referencer, møde med demo af systemet og forhandling af kontrakt.
Bemærk, at mens projektet kan være vigtigt for dig, er det ikke nødvendigvis betydningsfuldt for en leverandør. Leverandørerne er ikke tvunget til at afgive tilbud og vil typisk være kritiske og kun investere tid og ressourcer, hvis de føler, at opgaven kan vindes.
En god kravspecifikation vil også være en god støtte i det efterfølgende projektforløb. Dokumentet kan bruges til test og til at definere succes. Det giver en fælles forståelse med den valgte leverandør om hvilken opgave, der skal løftes.
Lær mere:
Læs de relaterede artikler:
- En kort kravspecifikation
- Brug prosa til at formulere dine krav
- Rimelige forretningskrav
- Tænk på brugervenlighed
- Valg af CMS
- Vælg den rigtige partner
Du kan også ansøge om medlemsskab af en J. Boye erfa-gruppe eller deltage i vores internationale konferencer. Hvis du har spørgsmål, kommentarer eller bemærkninger vedr. artiklen, så hører vi meget gerne fra dig.
