"Death by RFP"...

Innen digital utvikling har jeg stadig oftere sett hvordan store organisasjoner blir ofre for sine egne RFP-prosesser – og til tross for gode intensjoner, ender opp med feil partner, feil teknologi, feil tilnærming – eller alle tre på én gang.

La oss bruke tre minutter på å se nærmere på noen av de største utfordringene ved å anskaffe digitale tjenester gjennom en tradisjonell RFP-prosess:

Problem 1: Du tror du vet nøyaktig hva du trenger

I de fleste digitale utviklingsløp skjer det læring underveis. Den løsningen som til slutt fungerer best, er sjelden identisk med det du så for deg i starten – spesielt etter brukertesting. Likevel er mange RFP-er bygget på en antakelse om at man vet nøyaktig hva som trengs for å oppnå best mulig resultat – og hvilke kriterier som er riktige for å vurdere leverandørene.

Problemet er at slike RFP-er ofte hindrer leverandører i å presentere løsninger du ikke allerede har tenkt på. Det er som å spørre hvem som har den beste bilen for dine transportbehov – men samtidig si at bare bilforslag vil vurderes – uten å vurdere at et helikopter kanskje koster omtrent det samme, eller at en sykkel faktisk kunne dekket behovet ditt til en brøkdel av prisen. Kort sagt: du antar at ingen vet mer enn deg – når det mest sannsynlig finnes noen som gjør nettopp det.

Problem 2: Å late som om folk er roboter

Mange RFP-er inneholder lange kravlister og vektingstabeller, som til slutt ender i et Excel-ark med rangeringer. Men det som ofte glemmes, er hvor viktig det menneskelige samsvaret er – mellom teamene, prosessene, kulturen og ledelsen hos leverandøren og din egen organisasjon. RFP-prosessen forutsetter nærmest at alle er roboter, og at slike "myke" faktorer ikke spiller noen rolle. I praksis er de ofte avgjørende. Du kan ikke sette en poengsum på kjemi – i bunn og grunn kjøper du kompetanse og samarbeidsevne.

Problem 3: Du trenger produktutvikling, men fortsetter å kjøpe prosjekter

Som nevnt i punkt 1, legger RFP-er ofte opp til en kjøpsprosess hvor selskapet definerer en løsning på forhånd og ber leverandører prise den. Det som ofte skjer da, er at det brukes store budsjetter på å utvikle et prosjekt – men så er det lite eller ingenting igjen til videre utvikling og optimalisering. Verdien av prosjektet er i mange tilfeller uklar helt til hele investeringsbudsjettet er brukt opp. Det er en risikabel strategi.

Sannheten er at det de fleste selskaper egentlig trenger, ikke er digitale prosjekter, men kontinuerlig digital produktutvikling. I stedet for å kjøpe en plattform og ta en stor risiko, kjøper du et leveranseteam med fast kapasitet. Du bygger en MVP raskt, og forbedrer løsningen kontinuerlig. Dette er i praksis hvordan ledende aktører jobber – fra Uber til AirBnB, fra MailChimp til Instagram. Det gir raskere resultater, lavere kostnader og langt mindre risiko. Samtidig flyttes fokuset fra tekniske spesifikasjoner til faktisk forretningsverdi.

Så hva kan man gjøre i stedet?

A) Før du skriver eller sender ut en RFP, inviter de beste leverandørene til en åpen samtale. Bruk anledningen til å lære om hva som finnes av løsninger, hvilke tilnærminger som fungerer – og hvilke fallgruver du bør unngå. Samtidig får du et inntrykk av hvilke team og mennesker som passer din organisasjon best.

B) Hvis du først skal bruke en RFP, sørg for at den ikke låser leverandørene til én bestemt måte å løse problemet på. Gi dem rom til å utfordre deg – og kanskje foreslå noe du ikke selv har vurdert.

C) Still deg selv spørsmålet: er det en løsning du er ute etter – eller en partner som kan bidra til reell forretningsverdi? Utform RFP-en etter det. Tenk også nøye gjennom hvor mye risiko du er villig til å ta – og hvor mye du ønsker at leverandøren skal dele.


Til slutt:
Med mindre du kjøper en standardvare som krever minimal tilpasning, er en fastpris-modell nesten alltid en større kostnad som gir lavere sluttkvalitet for deg som kunde – sammenlignet med en fleksibel MVP-tilnærming der læring og utvikling skjer fortløpende.