Slik skriver du en RFP for programvare for prosjektstyring
Når du skriver en RFP, blir det enklere å beskrive behovene dine tydelig: Det blir enklere å sammenligne leverandører og finne det som passer best for teamet ditt.
RFP-er passer best for større organisasjoner: Hvis organisasjonen din er liten eller behovene dine er enkle, kan du hoppe over en RFP og heller kontakte noen få leverandører direkte for å få tilbud.
En godt utformet RFP kan føre til bedre priser: Den kan også bidra til å sikre at programvaren oppfyller de spesifikke kravene dine og spare deg for problemer senere.
En forespørsel om tilbud på prosjektstyringsprogramvare, eller en RFP, er et dokument som beskriver kravene, budsjettet og evalueringskriteriene dine, og ber leverandører om å gi tilbud basert på disse.
Siden alle leverandørene svarer på den samme beskrivelsen, kan du sammenligne alternativer for prosjektstyringsprogramvare side om side, i stedet for å sette sammen informasjon fra salgssamtaler og markedsføringssider. Gjort på riktig måte reduserer dette risikoen for å binde seg til et verktøy som ikke passer med måten teamet ditt arbeider på.
Hva bør inngå i en RFP for prosjektstyringsprogramvare?
De fleste RFP-er for prosjektstyringsprogramvare følger den samme grunnleggende strukturen. Hvis du inkluderer alle disse åtte delene, får leverandørene det de trenger for å sende deg et komplett og sammenlignbart tilbud.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
| Del | Hva den omfatter | Det de fleste RFP-er utelater |
|---|---|---|
| Sammendrag | Hvem dere er, hva dere trenger og hvorfor nå | Beslutningstidslinjen deres og hvem som tar den endelige avgjørelsen |
| Arbeidsomfang | Programvaren og tjenestene dere forventer | Datamigrering fra det nåværende verktøyet deres |
| Tekniske krav | Funksjoner, integrasjoner og plattformer | Å spørre hvordan en funksjon fungerer, ikke om den finnes |
| Leverandørkvalifikasjoner og samsvar | Erfaring, sertifiseringer og sikkerhetsstandarder | Å be om den faktiske revisjonsrapporten, ikke en påstand om samsvar |
| Implementering og opplæring | Plan for utrulling, tidslinjer og brukerstøtte | Hvem som utfører arbeidet: leverandøren, en partner eller teamet deres |
| Priser og lisenser | Kostnader, nivåer og lisensmodell | Prisøkninger ved fornyelse og funksjoner som er låst til høyere nivåer |
| Kontraktsvilkår | Betaling, SLA-er og juridiske vilkår | Hvordan dere får ut dataene deres hvis dere avslutter avtalen |
| Instruksjoner for innsending | Frister, format og kontaktpersoner | En felles spørsmål-og-svar-prosess slik at alle leverandører får de samme svarene |
1. Sammendrag
Gi en kort oversikt over hvilken type prosjektstyringsprogramvare dere trenger, hvilket problem dere skal løse, og hvilke resultater dere forventer. Ta med teamstørrelsen, hva dere skal erstatte, og når dere planlegger å ta en beslutning.
Det de fleste team utelater: Leverandørene leser denne delen for å avgjøre om avtalen er verdt et seriøst svar. En tydelig utløsende faktor («det nåværende verktøyet vårt støtter ikke porteføljerapportering på tvers av 12 team») og en fast beslutningsdato signaliserer en reell kjøper, og dere får tilbud fra erfarne salgs- og løsningsmedarbeidere i stedet for standardiserte svar.
2. Arbeidsomfang
Beskriv tydelig hva dere forventer av leverandøren utover selve programvaren: oppsett, konfigurering, datamigrering, opplæring og løpende brukerstøtte. Ta med hvor mange brukere dere har i dag, og hvor mange dere forventer å ha om to til tre år.
Det de fleste team utelater: Det er ved migrering tidsplanene sprekker. Oppgi hvilket verktøy dere flytter fra, omtrent hvor mange prosjekter og hvor mye historiske data dere trenger å ta med, og om vedlegg og kommentarer også skal overføres. Leverandørene priser «importer aktive prosjekter» og «migrer fem års historikk» svært forskjellig.
3. Tekniske krav
List opp funksjonene, integrasjonene og plattformstøtten dere trenger, og merk hver av dem som et absolutt krav, et ønsket krav eller et ekstra pluss.
Det de fleste team utelater: Krav som bare kan besvares med ja eller nei, får et «ja» fra alle leverandører. I stedet for «Støtter løsningen ressursstyring?», bør dere be leverandørene forklare hvordan den håndterer et konkret scenario, for eksempel å omfordele arbeidsbelastningen til en designer på tvers av tre overlappende prosjekter. For integrasjoner bør dere spørre om hver enkelt er innebygd, opprettet via en tredjepartskobling eller bare står på veikartet. Disse tre svarene betyr svært forskjellige ting i praksis.
4. Leverandørkvalifikasjoner og samsvar
Spesifiser hvilken erfaring, hvilke bransjesertifiseringer og hvilken merittliste dere forventer, sammen med kravene deres til sikkerhet og samsvar, for eksempel standarder for databeskyttelse og eventuelle regler bransjen deres må følge.
Det de fleste team utelater: «SOC 2-kompatibel» på en salgsside er ikke dokumentasjon. Be om den nyeste SOC 2 Type II-rapporten (som vanligvis deles under en konfidensialitetsavtale), hvor dataene deres lagres, og hvilke underleverandører som håndterer dem. Hvis IT-teamet deres allerede har et standardisert sikkerhetsspørreskjema, bør dere legge det ved nå i stedet for å gjennomføre det som en separat runde etter at dere har valgt en favoritt. Be også om referanser fra kunder av tilsvarende størrelse og fra samme bransje, ikke bare leverandørens mest fornøyde kunder.
5. Forventninger til implementering og opplæring
Beskriv den planlagte tidslinjen for utrullingen, hvordan dere skal måle om lanseringen er vellykket, og hvilken opplæring dere trenger for både administratorer og sluttbrukere.
Det de fleste team overser: Finn ut hvem som faktisk skal stå for implementeringen: leverandørens eget team, en sertifisert partner eller medarbeiderne dine ved hjelp av selvbetjeningsveiledninger. Be om navngitte roller, et estimert antall timer fra teamet ditt og hvor lenge den dedikerte støtten varer etter lansering. Det er bruken, ikke oppsettet, som gjør at de fleste utrullinger mislykkes, så spør hva leverandøren gjør for å fremme bruken de første 90 dagene.
6. Priser og lisensiering
Be om en fullstendig kostnadsoversikt, inkludert lisensavgifter, implementering, opplæring, premiumstøtte og tillegg. Oppgi antall brukere og forventet vekst, slik at alle leverandørene gir tilbud basert på de samme tallene.
Det de fleste team overser: Det er sjelden prisen det første året som blir problemet. Be om de totale eierkostnadene over tre år, eventuelle begrensninger på økninger i fornyelsesprisen og minimumsforpliktelser for antall lisenser. Sjekk hvilke funksjoner fra kravlisten som krever høyere nivåer, ettersom SSO, avanserte tillatelser og porteføljerapportering ofte bare er tilgjengelig på bedriftsnivå. Spør også hvordan gjeste-, visnings- og klientlisenser faktureres dersom personer utenfor teamet ditt trenger tilgang.
7. Avtalevilkår
Beskriv vilkårene du forventer, inkludert betalingsplan, tjenestenivåavtaler (SLAs), garantier og ansvar.
Det de fleste team overser: To klausuler er viktigst etter at du har signert. For det første dataportabilitet: hvordan du eksporterer dataene dine hvis du avslutter avtalen, hvilket format de leveres i, og hvor lenge leverandøren oppbevarer dem etter oppsigelse. For det andre automatisk fornyelse: hvor lang frist du trenger for å si opp eller reforhandle avtalen. Når du deler vilkårene du ikke kan fravike i RFP-en, skjer juridiske endringer før du har valgt leverandør, ikke etterpå, når forhandlingsposisjonen din er svakere.
8. Instruksjoner for innsending
Gi leverandørene en frist, ett kontaktpunkt og informasjon om hvilket format du ønsker svarene i. Spesifiser detaljene, for eksempel filtyper og leveringsmåte, når du sender ut RFP-en.
Sett sammen teamet for RFP-en for prosjektstyringsprogramvaren
Det krever innspill fra personer på tvers av virksomheten å fylle ut disse åtte delene på en god måte. Når du involverer dem tidlig, får du færre mangler i kravene og mindre omarbeid senere. Her er hvem du bør inkludere.
Prosjektsponsor
Prosjektsponsoren gir strategisk retning og sørger for at RFP-en samsvarer med de overordnede forretningsmålene dine. Vedkommende bidrar til å prioritere krav, sikre ressurser til utvelgelsesprosessen og godkjenne den endelige RFP-en. Denne rollen fylles vanligvis av en seniorleder eller direktør som støtter prosjektet.
Fageksperter
Fageksperter eller eksperter på området kjenner de tekniske kravene programvaren må oppfylle, så innspillene deres former funksjonene og integrasjonene du ber om. Se etter avdelingsledere eller erfarne medarbeidere innen IT, drift eller prosjektstyring.
Innkjøpsansvarlige eller RFP-skribenter
Innkjøpsansvarlige eller RFP-skribenter sørger for at dokumentet er strukturert på riktig måte, følger nødvendige retningslinjer for juridisk prosjektstyring eller organisatoriske retningslinjer, og bruker et språk leverandørene lett kan forstå. Denne rollen fylles vanligvis av en person i innkjøpsavdelingen eller en dedikert RFP-skribent.
Sluttbrukere og interessenter
Sluttbrukere og interessenter kjenner de daglige utfordringene programvaren må løse, noe som hjelper deg med å identifisere nødvendige funksjoner og mulige hindringer tidlig. Vurder å involvere teamledere, prosjektledere og vanlige brukere fra ulike avdelinger.
Definer nødvendige funksjoner og mål
Når teamet er på plass, bør dere bli enige om hva det nye verktøyet må gjøre, og hvorfor, før dere begynner å skrive. Disse svarene blir innholdet i arbeidsomfanget, de tekniske kravene og samsvarsdelene, og gir leverandørene det de trenger for å svare nøyaktig.
Vurder følgende:
- Utfordringer med det nåværende systemet: Hva frustrerer teamet ditt akkurat nå? Identifiser konkrete problemer, for eksempel treg oppfølging av oppgaver eller mangel på oppdateringer i sanntid.
- Nødvendige forbedringer og ønskede resultater: Hvordan ser suksess ut for teamet ditt? Definer viktige forbedringer, for eksempel bedre samarbeid eller mindre manuelt arbeid, og fastsett målbare resultater for å følge fremdriften.
- Funksjonelle, tekniske og regulatoriske behov: Må programvaren integreres med eksisterende verktøy eller oppfylle bransjestandarder? List opp det som er nødvendig, for eksempel API-tilgang eller overholdelse av personvernregler.
- Brukerroller, bruksnivåer og arbeidsflyter: Hvem skal bruke programvaren, og hvor ofte? Tenk over hvordan den må støtte ulike roller, fra prosjektledere til individuelle bidragsytere.
- Preferanser for implementering: Trenger du en skybasert løsning eller en løsning installert lokalt? Basér avgjørelsen på behovene dine for datasikkerhet og IT-infrastruktur.
Definer evalueringskriteriene dine
Tydelig definerte evalueringskriterier hjelper deg med å ta en informert beslutning som er objektiv, transparent og i tråd med forretningsmålene dine. Når du fastsetter disse kriteriene før du går gjennom tilbudene, unngår du skjevheter og holder fokus på det som betyr mest for teamet ditt. Slik definerer du evalueringskriteriene dine.
Hva betyr mest?
Velg 3–5 vektede kategorier som samsvarer med målene og prioriteringene dine. Dette bidrar til å konsentrere evalueringen om det som virkelig er viktig, og til å veie fordeler og ulemper ved leverandører av prosjektstyringsprogramvare på en effektiv måte. Vanlige kategorier for poenggiving i en RFP for prosjektstyringsprogramvare omfatter:
- Funksjonalitet
- Brukeropplevelse
- Kostnad
- Leverandørens omdømme
- Skalerbarhet
Identifiser hvilke kategorier som best gjenspeiler behovene dine, og tildel dem vekter basert på hvor viktige de er for prosjektet ditt.
Bruk en poengmatrise
En poengmatrise bidrar til å tallfeste evalueringsprosessen og gjøre den mer objektiv. Tildel hver kategori en vekt basert på de interne prioriteringene dine. Hvis funksjonalitet for eksempel er avgjørende, kan den ha en vekt på 40 %, mens kostnad kan ha en vekt på 20 %. Gi hvert kriterium poeng på en skala fra 1–5 eller 1–10 for å skille mellom leverandørenes tilbud. Juster vektingen slik at den gjenspeiler det som betyr mest for teamet ditt.
Avklar poenggivingsprosessen
Definer hvem som skal gi poeng til tilbudene, og hvordan de skal opprettholde en konsekvent vurdering. Bruk et standardisert vurderingsskjema for å veilede vurdererne, og planlegg et møte for å samkjøre alle om poenggivingsprosessen før dere begynner. Dette hjelper alle vurdererne med å forstå kriteriene og fremgangsmåten, slik at de kan gjennomføre rettferdige og balanserte evalueringer. Sørg for at hver vurderer kjenner rollen sin og vet hvordan poengsystemet skal brukes.
Send ut RFP-en for prosjektstyringsprogramvare
Å sende ut RFP-en handler ikke bare om å distribuere den – det handler om å gi leverandørene riktig tilgang, tidsfrister og instruksjoner, slik at de kan svare effektivt. En smidig distribusjonsprosess legger grunnlaget for kvaliteten på tilbudene du mottar. Slik sender du ut RFP-en på en effektiv måte.
Velg riktig distribusjonsmetode
Vurder å bruke e-post, plattformer for RFP-programvare eller innkjøpsportaler til å distribuere RFP-en. Et sentralisert system, for eksempel en RFP-plattform, hjelper deg med å følge opp svar og administrere kommunikasjonen. Hvis du bruker e-post, bør du vurdere en rollebasert innboks for å holde all leverandørkommunikasjon organisert. Inkluder en kontaktliste for leverandørene, slik at alle får informasjonen de trenger.
Sett tydelige forventninger til tidslinjen
En tydelig tidslinje sørger for at leverandørene vet hva de kan forvente, og når. Inkluder følgende i RFP-en:
- Dato for utsending av RFP-en
- Periode for spørsmål og svar fra leverandørene
- Endelig frist for innsending
- Periode for evaluering og valg
Del denne tidslinjen i selve RFP-en for å holde alle samkjørte og på rett spor.
Definer kravene til innsending
Sørg for at leverandørene vet nøyaktig hvordan de skal sende inn tilbudene sine. Spesifiser godkjente filformater, for eksempel PDF, Microsoft Word eller Excel-maler. Angi ønsket leveringsmetode, for eksempel en opplastingsportal eller en innboks for svar. Avklar om leverandørene må bruke bestemte maler eller skjemaer, og om sene innleveringer vil bli akseptert. Denne tydeligheten unngår forvirring og sikrer at du mottar komplette tilbud i tide.
Evaluer og velg ut leverandørsvar
Det er her den strukturerte tilnærmingen din gir resultater, når innkjøpsteamet gjør leverandørenes RFP-svar om til en velbegrunnet kortliste. Konsistens, objektivitet og samarbeid mellom alle som deltar i evalueringen er avgjørende. Slik evaluerer og velger du effektivt ut leverandører.
- Planlegge demoer og intervjuer: Avtal demoer og intervjuer med de beste leverandørene for å se løsningene deres i praksis. Dette gir teamet ditt mulighet til å stille spørsmål og få en følelse av hvor brukervennlig programvaren er.
- Kontrollere referanser: Ta kontakt med referansene leverandørene har oppgitt for å høre om erfaringene deres. Spør om utfordringer ved implementeringen og kvaliteten på kundestøtten for å danne deg et bilde av hva du kan forvente.
- Avklare alt som er uklart i tilbudene: Ikke nøl med å kontakte leverandørene for å få avklart uklare punkter. Det er bedre å spørre nå enn å gjøre antakelser som kan føre til problemer senere.
Velg og varsle leverandører
Når teamet ditt har valgt en leverandør, er de siste trinnene like viktige som evalueringsprosessen. Tydelig og profesjonell kommunikasjon med alle leverandører – både de som er valgt og de som ikke er valgt – er avgjørende, i tillegg til å oppnå intern enighet før kontraktsinngåelsen. Her er de viktigste trinnene.
Varsle valgte og ikke-valgte leverandører
Rask og respektfull kommunikasjon med leverandørene gir organisasjonen din et godt inntrykk. Send en kort takkemelding eller gi overordnet tilbakemelding til leverandører som ikke ble valgt, slik at du opprettholder gode relasjoner for fremtidige muligheter. For den valgte leverandøren bør du uttrykke entusiasme og beskrive de neste trinnene for å opprettholde fremdriften.
Forbered deg på de endelige forhandlingene
Vanlige forhandlingstemaer omfatter priser, SLA-er og kontraktsvilkår. Fastsett på forhånd hvilke punkter teamet ditt ikke kan gå på kompromiss med, for å unngå overraskelser. Bruk en sjekkliste eller agenda under diskusjonene for å holde fokus og dekke alle nødvendige punkter. Denne forberedelsen hjelper deg med å forhandle effektivt og komme frem til en rettferdig avtale.
Sikre intern enighet før signering
Før signering må du sørge for at alle nødvendige godkjenninger er på plass. Dette omfatter vanligvis godkjenning fra ledelsen eller økonomiavdelingen samt en juridisk gjennomgang eller innkjøpsgjennomgang. Oppsummer de viktigste faktorene bak beslutningen, slik at interne godkjennere kan behandle saken raskt. Tydelig kommunikasjon med teamet ditt forhindrer forsinkelser og sikrer at alle støtter beslutningen.
RFP-sjekkliste: Vanlige feil du bør unngå
Gå gjennom denne listen før du sender RFP-en. Hvert punkt dekker et hull som fører til generiske tilbud, leverandører som ikke passer godt, eller en langsommere prosess for valg av prosjektstyringsprogramvare.
- Gi leverandørene nok kontekst. Ta med målene dine, teamets størrelse, hvilket verktøy du bruker i dag, og hvorfor du bytter. Uten dette får du generiske svar som ikke tar for seg de faktiske utfordringene dine.
- Oppgi et budsjettintervall. Leverandørene legger enten inn for høye tilbud eller hopper over RFP-er uten et budsjett. Hvis du ikke er sikker på hva som er realistisk, bør du undersøke hvor mye prosjektstyringsprogramvare koster før du fastsetter intervallet.
- Skriv spesifikke krav i et klart språk. Nevn funksjonene i prosjektstyringsprogramvaren du trenger, ranger dem etter prioritet, og spar juridisk språk til kontraktsdelen.
- Del evalueringskriteriene dine. Fortell leverandørene hva de vil bli vurdert på, for eksempel funksjonalitet, skalerbarhet eller kundestøtte, slik at de kan svare direkte på hvert punkt.
Trenger du faktisk en RFP?
Hvis teamet ditt håndterer komplekse krav, eller hvis du er en del av en regulert bransje, er en RFP avgjørende. Den bidrar til å sikre at du finner en leverandør som samsvarer med de spesifikke behovene dine og overholder bransjestandarder. Det er også viktig å utarbeide en RFP når du håndterer et stort budsjett eller trenger støtte fra flere interessenter.
Her er noen situasjoner der en RFP er nødvendig:
- Storskala bedriftsprosjekter
- Sterkt regulerte bransjer
- Komplekse integrasjonskrav
- Flere involverte interessenter
- Betydelig budsjettallokering
Når en RFP kan være unødvendig
Hvis behovene dine er enkle, eller dere er et lite team, kan en RFP være mer bryderi enn det er verdt. I slike tilfeller kan du spare tid ved å utforske alternativer direkte fra en kuratert liste over den beste prosjektstyringsprogramvaren:
Beste prosjektstyringsprogramvare å vurdere
Her er listen min over de 10 beste tilgjengelige alternativene for prosjektstyringsprogramvare, slik at du kan komme i gang med søket ditt:
Clicks on the links below may earn a commission, which supports our independent testing and review of software and services. Learn more about how we stay transparent.
RFI vs. RFP vs. RFQ: Hva er forskjellen?
En RFI brukes til å innhente generell informasjon, en RFP brukes til å be om detaljerte tilbud, og en RFQ brukes til å be om priser. Ved å velge riktig type sparer du tid og reduserer friksjon i innkjøpsprosessen:
| Dokumenttype | Formål | Når det brukes | Hva som skal inkluderes | Nødvendig detaljnivå |
|---|---|---|---|---|
| Informasjonsforespørsel (RFI) | Innhente generell informasjon om potensielle leverandører | Når du undersøker alternativer og funksjoner for prosjektstyringsprogramvare | Leverandørens funksjoner, markedstrender, grunnleggende funksjoner | Lavt |
| Tilbudsforespørsel (RFP) | Be leverandører om detaljerte tilbud | Når du trenger detaljerte løsninger og priser for komplekse behov | Prosjektkrav, evalueringskriterier, leverandørkvalifikasjoner | Høyt |
| Prisforespørsel (RFQ) | Innhente nøyaktige priser for spesifikke funksjoner | Når du har tydelige krav og bare trenger tilbud | Liste over spesifikke funksjoner, prisstruktur, leveringsvilkår | Middels |
Før du sender RFP-en
En RFP fungerer bare så godt som kravene og budsjettet som ligger til grunn for den. Hvis teamet ditt fortsatt diskuterer hva det faktisk trenger, og du trenger et realistisk tall å føre opp i budsjettseksjonen, kan du se vår gjennomgang av hvor mye prosjektstyringsprogramvare koster. På den måten får du tilbud du faktisk har råd til.
