Et softwareprojekt bliver sjældent dyrt, fordi koden er svær. Det bliver dyrt, når forventninger, ansvar og rammer er uklare, og når leverandørens tilbud er baseret på gæt.
En RFP (Request for Proposal) er et praktisk værktøj til at få sammenlignelige tilbud fra flere leverandører. Den hjælper dig med at beskrive behovet, stille de rigtige spørgsmål og få svar, der kan bruges til både valg af leverandør og den senere kontrakt- og projektstyring.
Den gode nyhed: Du behøver ikke skrive en roman. Du skal skrive præcist.
— Du kan få dem tilsendt herunder! —
Hvornår giver en RFP mening i et softwareprojekt?
Hvis du kun har én oplagt leverandør og et meget afgrænset køb (fx “opsætning af et standard plugin”), kan en RFP være mere proces end værdi. I de fleste tilfælde, hvor der er udvikling, integration eller flere interessenter, betaler den sig hurtigt.
Tænk RFP som et filter: Den sorterer leverandører fra, der ikke kan løfte opgaven, og den tvinger de resterende til at forholde sig til dine krav på samme måde.
En RFP er særlig relevant når der er flere af disse forhold:
- Der er flere mulige leverandører
- Der er integrationer til eksisterende systemer
- Der er krav til sikkerhed, drift og support
- Der er uklarhed om scope, og du vil teste løsningsforslag
- Der er behov for dokumentation og sporbarhed i beslutningen
Skabelon: en robust struktur du kan genbruge
Strukturen skal gøre det let at læse, let at svare på og let at evaluere. Den skal også være “skalerbar”: kort til små projekter, mere detaljeret til større.
Start med at skrive dokumentet, som om du var leverandøren: Hvilke oplysninger mangler du for at kunne prissætte og planlægge? Og hvilke svar vil du selv have, før du tør vælge?
En enkel kerne-struktur kan se sådan ud:
Hent vores bøger og skabeloner herunder
- Baggrund og formål
- Projektmål og succeskriterier
- Scope og afgrænsninger
- Krav (funktionelle og ikke-funktionelle)
- Nuværende miljø (systemer, data, integrationer)
- Ønsket samarbejds- og leverancemodel
- Tidsplan og milepæle (inkl. tilbudsproces)
- Krav til leverandørens tilbud (format, indhold, bilag)
- Evalueringskriterier og vægtning
- Juridiske og kommercielle vilkår (på et passende niveau)
- Kontakt og Q&A-proces
- Bilag (kravspec, user stories, arkitekturprincipper, scorecard osv.)
Det vigtige er ikke, om der står 10 eller 12 punkter. Det vigtige er, at leverandørerne kan finde det, de skal bruge, og at du kan sammenligne deres svar.
Skriv det leverandøren skal svare på (ikke kun det du gerne vil fortælle)
Mange RFP’er bliver en lang “historie om os” og en kort “send en pris”. Det giver uens tilbud, uklare forbehold og mange opfølgende møder.
Gør det omvendt: kort kontekst, tydelige spørgsmål, tydelige krav til svaret. Bed gerne leverandøren svare i en skabelon eller i en fast disposition, så du ikke ender med 6 vidt forskellige tilbudsdokumenter.
Her er en enkel måde at formulere krav til leverandørens besvarelse på med to spor: “hvad” og “hvordan”.
- Hvad: Hvilke leverancer indgår, hvilke antagelser gør leverandøren, og hvad er ikke inkluderet?
- Hvordan: Metode, bemanding, governance, test, kvalitetssikring, risikostyring, og hvordan ændringer håndteres.
Et enkelt, men effektivt greb er at bede om konkrete eksempler: “Beskriv et projekt med lignende integrationer og kompleksitet. Hvad gik godt, og hvad gjorde I anderledes næste gang?”
Krav: fra forretning til teknik uden at drukne i detaljer
Du skal ramme et niveau, hvor leverandøren kan estimere, men uden at du låser projektet i en kravspec, der alligevel ændrer sig.
Skriv krav, så de kan testes. Skriv også det, du ikke vil diskutere. Det er ofte de ikke-funktionelle krav, der senere skaber konflikter: performance, sikkerhed, logning, audit, oppetid, supportvinduer og datalivscyklus.
Et godt kravafsnit bliver stærkere, hvis du kombinerer flere “syn” på behovet. Det kan være en kravspecifikation, et sæt user stories, og en kort beskrivelse af procesflows eller skærmbilleder.
Her er eksempler på kravkategorier, som typisk bør være med:
- Funktionalitet: Hvilke brugeropgaver systemet skal understøtte, og hvilke “must-have” der findes.
- Integrationer: Systemer, dataflow, frekvens, fejlscenarier, og hvem der ejer endpoints.
- Sikkerhed og compliance: Roller og rettigheder, logging, kryptering, databehandlerforhold, og krav til miljøer.
- Drift og support: Overvågning, alarmer, incidenthåndtering, svartider og patching.
- Kvalitet og test: Testtyper, acceptkriterier, automatisering og releasekrav.
Hvis du allerede bruger skabeloner som kravspec, user stories, RACI eller interessentanalyse, kan de med fordel vedlægges som bilag. Det reducerer risikoen for, at RFP’en bliver en blanding af alt, og giver leverandøren konkrete artefakter at svare på.
Agile softwareprojekter: få bedre tilbud ved at spørge til samarbejdet
Hvis projektet køres agilt, bør RFP’en afspejle det. Ikke med buzzwords, men ved at gøre samarbejdsformen målbar: Hvem deltager i sprintplanlægning, hvem prioriterer backlog, og hvordan ser “færdig” ud?
Skriv tydeligt, hvad du forventer af din egen organisation. Mange agile projekter får problemer, fordi kunden tror, at leverandøren kan “køre Scrum” uden adgang til forretningen og uden hurtige beslutninger.
En kort, konkret beskrivelse kan være nok: sprintlængde, demo cadence, beslutningsforum, og hvordan ændringer prioriteres.
Og bed om at få leverandørens bud på, hvordan de vil håndtere typiske vilkår:
- Uklarhed i starten
- Afhængigheder til interne systemer
- Sikkerhedsgodkendelser
- Tilgængelighed af nøglepersoner
Et stærkt signal på modenhed er, når leverandøren beskriver, hvordan de minimerer risiko tidligt, fx med en discovery-fase, en teknisk spike eller en proof of concept, før fuld produktion.
Standardsoftware eller specialudvikling: tilpas RFP’en
En RFP til køb af standardsoftware handler ofte mindre om udviklingsproces og mere om produktets egenskaber, licens, integrationer og driftsmodel. Ved specialudvikling skal du typisk have mere fokus på metode, bemanding, code ownership, test og arkitekturprincipper.
Skriv derfor eksplicit, hvilken type indkøb du forventer:
- Standardplatform med konfiguration?
- Standardprodukt med tilpasninger?
- Specialudviklet løsning fra bunden?
- Videreudvikling af eksisterende kodebase?
Det ændrer, hvilke spørgsmål der giver mening, og hvordan du bør evaluere tilbuddene.
Evalueringskriterier: gør valget gennemsigtigt med et scorecard
Hvis du ikke skriver, hvordan du evaluerer, ender du med at evaluere på mavefornemmelse. Og så risikerer du at vælge det pæneste PowerPoint frem for den bedste løsning.
Gør kriterierne synlige i RFP’en, og brug en simpel vægtning. Den behøver ikke være perfekt. Den skal være brugbar og konsistent.
Nedenfor er et eksempel på en vægtet evalueringsmatrix, som kan tilpasses projektets karakter:
| Kriterium | Hvad vurderes | Vægt (eksempel) |
|---|---|---|
| Løsningsfit | Dækker løsningen behov og afgrænsninger | 30% |
| Teknisk kvalitet | Arkitektur, integrationer, sikkerhed, skalerbarhed | 20% |
| Leverance- og projektmodel | Plan, governance, samarbejde, ændringshåndtering | 15% |
| Team og kompetencer | Nøgleprofiler, erfaring, stabilitet, kapacitet | 15% |
| Pris og kommercielle vilkår | Prisniveau, transparens, forudsætninger | 15% |
| Support og drift | SLA, overdragelse, driftssetup, monitorering | 5% |
Del gerne scorecardet internt før RFP’en sendes ud, så styregruppe og nøgleinteressenter er enige om, hvad der betyder mest. Det gør også leverandørinterviews mere fokuserede, fordi I kan dykke ned i lavt scorede punkter med konkrete spørgsmål.
Tidsplan og proces: giv plads til spørgsmål og bedre svar
En RFP-proces bliver bedre, når leverandørerne får lov at spørge og når alle får samme svar. Det er ikke “besværligt”. Det er kvalitetskontrol.
Sæt en enkel proces op med deadlines, format og kommunikationskanal. Hold også fast i, at alt væsentligt bliver besvaret skriftligt, så du undgår at én leverandør får en fordel via et møde.
En typisk, enkel proces kan beskrives med få linjer og et par tydelige milepæle:
- Udsendelse af RFP
- Spørgefrist
- Svar på spørgsmål deles til alle
- Tilbudsfrist
- Udvælgelse til præsentation/interview
- Referencecheck
- Forhandling og kontrakt
Jo mere komplekst projektet er, jo mere giver det mening at afsætte tid til en kort “afklaringsrunde” efter tilbudsafgivelse, hvor leverandørerne kan præcisere forbehold og antagelser.
Typiske faldgruber og hvordan du undgår dem
En god RFP handler lige så meget om det, du vælger fra, som det du tager med. Overdetaljerede krav kan give falsk tryghed, og for løse beskrivelser giver upræcise tilbud.
Her er fejl, der ofte går igen i softwareprojekter:
- RFP’en beskriver funktioner, men ikke succes: Hvad betyder det, at løsningen virker i praksis?
- “Alt er vigtigt”: Hvis alt vægtes højt, er intet styrende, og evalueringen bliver uklar.
- Manglende afgrænsninger: Leverandører prissætter risiko, når de ikke kan se rammerne.
- Ingen krav til besvarelsesformat: Du får uensartede tilbud, der er svære at sammenligne.
- Ingen beskrivelse af jeres kapacitet: Leverandøren gætter på, hvor meget I selv kan bidrage med.
Skriv hellere få, skarpe krav, og vær tydelig om, hvad der er “skal”, og hvad der er “ønske”. Og få en kollega til at læse dokumentet igennem med ét formål: “Kan du ud fra dette afgive et tilbud uden at ringe fem gange?”
Praktisk mini-skabelon du kan kopiere ind i dit dokument
Hvis du vil i gang hurtigt, kan du kopiere teksten nedenfor som start og udfylde den med dit projekt. Hold hvert punkt kort, og læg detaljer i bilag.
A. Formål og baggrund
Beskriv kort hvad der skal opnås, og hvorfor projektet sættes i gang nu.
B. Projektmål og succeskriterier
Skriv 3 til 7 mål, gerne målbare. Tilføj gerne et par “anti-mål” (hvad projektet ikke skal).
C. Scope og afgrænsning
Hvad er med, hvad er ikke med, og hvilke afhængigheder er kendte.
D. Krav og bilag
Henvis til kravspecifikation, user stories, integrationsoverblik, datakilder, UI-skitser.
E. Samarbejdsmodel
Agil eller klassisk, jeres forventede deltagelse, mødestruktur, beslutningsveje.
F. Leverandørens tilbud skal indeholde
Løsningsbeskrivelse, plan og milepæle, team, prisstruktur, risici og antagelser, forbehold.
G. Evaluering
Kriterier, vægtning, proces, forventet antal leverandører i finalerunden.
H. Tidsplan
Datoer for spørgefrist, tilbudsfrist, præsentationer og forventet kontraktstart.
Hvis du allerede arbejder med værktøjer som kravspec-skabeloner, user stories og et scorecard til leverandørvalg, får du ekstra effekt ved at samle dem som bilag og referere til dem fra RFP’en. Det holder hoveddokumentet læsbart, uden at du mister detaljerne.
Sprog og form: små ting der giver bedre tilbud
Sproget er ikke pynt. Det er styring. Korte sætninger og faste begreber reducerer misforståelser, især når leverandører tolker krav forskelligt.
Hold også styr på definitioner: Hvad betyder “go-live” hos jer? Er det første release til få brugere, eller fuld udrulning? Hvad betyder “færdig”? Er det udviklet, testet, dokumenteret, og driftsoverdraget?
Et enkelt afsnit med definitioner kan spare mange timers diskussion senere, især ved større projekter og flere interessenter.
Og brug 30 minutter på korrektur. En RFP med modstridende datoer, uafklarede begreber og uklare krav inviterer til forbehold, og forbehold bliver næsten altid til ekstraomkostninger.
— Du kan få dem tilsendt herunder! —
