Teknisk due diligence: Vurder leverandøren før du signerer
Teknisk due diligence er en strukturert gjennomgang av en leverandørs tekniske evne før en stor forpliktelse. I tillegg til referanser og kundecaser ber du om å få se arbeidsprøver, utviklingsprosesser og sikkerhetsrutiner. Ved større avtaler kan en ekstern fagperson gi en uavhengig second opinion, mens mindre prosjekter klarer seg med et enklere miniformat.
Referanser og pene kundecaser sier noe, men de er håndplukket: Leverandøren viser frem sine beste sider. Før en stor og langvarig forpliktelse vil du vite mer enn at det har gått bra tidligere. Teknisk due diligence er den strukturerte gjennomgangen av evnen bak resultatene: hvordan leverandøren bygger, tester og beskytter det de leverer. Her ser vi på hva du kan be om, når en ekstern fagperson lønner seg, og hvordan du gjør det i passende skala for mindre prosjekter.
Hva du kan be om å få se
En seriøs leverandør er vant til å bli vurdert og svarer åpent. Tre ting er det rimelig å be om, i tillegg til referanser:
- Arbeidsprøver. Kodeeksempler eller en gjennomgang av et tidligere system viser hvordan de faktisk bygger: struktur, lesbarhet og kvalitet. Mye er konfidensielt, men en leverandør som ikke kan vise noe som helst, er et varselsignal.
- Utviklingsprosesser. Hvordan blir arbeidet planlagt, bygget og kvalitetssikret? Hvordan testes det, og hvordan håndteres feil som oppdages? En gjennomtenkt prosess er det som gjør kvaliteten til noe som kan gjentas, ikke noe tilfeldig.
- Sikkerhetsrutiner. Hvordan håndteres sensitive data, tilganger og sårbarheter? Hvordan holder de seg oppdatert når nye trusler dukker opp? Jo mer sensitivt systemet er, desto viktigere blir svarene.
Be også om å få møte de personene som faktisk skal jobbe i prosjektet, ikke bare selgeren. Selskapets samlede merittliste sier lite om hva teamet som skal jobbe for dere, kan.
En second opinion fra en ekstern fagperson
Noen ganger er forpliktelsen så stor, eller teknologien så vanskelig å vurdere, at du trenger hjelp til gjennomgangen. Da kan en uavhengig teknisk fagperson engasjeres for en second opinion.
En slik fagperson kan vurdere det en kunde uten teknisk bakgrunn har vanskelig for å bedømme selv: Holder kodekvaliteten, er arkitekturvalgene sunne, finnes det skjulte risikoer i måten systemet er bygget på? For en investering på flere millioner kroner i et system virksomheten skal støtte seg på i mange år, er kostnaden ved en ekstern gjennomgang liten i forhold til det den kan fange opp. Et risikabelt veivalg som oppdages før avtalen, er uendelig mye billigere enn et som oppdages etter lansering.
Den eksterne fagpersonen fyller altså rollen som uavhengig vurderer mellom deg og leverandøren, en person med én eneste oppgave: å se kritisk på det du er i ferd med å kjøpe.
Et miniformat for mindre prosjekter
Full due diligence er feil verktøy for et lite oppdrag. En tung gjennomgangsprosess for et prosjekt på noen hundre tusen kroner ville koste mer i tid enn den beskytter. Men helt uten kontroll bør du heller ikke kjøpe. Løsningen er et miniformat:
- Be om et par kodeeksempler, og se på struktur og ryddighet.
- Still noen målrettede spørsmål: Hvordan sikrer dere kvalitet, hvordan tester dere, og hvordan håndterer dere feil etter lansering?
- Gjennomfør gjerne en liten, avgrenset prøveleveranse før den store forpliktelsen, for eksempel en forstudie eller en første modul.
Det gir deg mye av tryggheten ved en full gjennomgang for en brøkdel av innsatsen, avpasset etter prosjektets størrelse. Poenget med due diligence er å tilpasse omfanget av gjennomgangen til det som står på spill.
Et konkret scenario
En organisasjon skulle bestille et virksomhetskritisk system til flere millioner kroner. To leverandører gjensto, med likeverdige kundecaser og gode referanser. På papiret var de vanskelige å skille fra hverandre.
I due diligence-steget ba organisasjonen begge leverandørene om kodeeksempler, en prosessbeskrivelse og et møte med det tiltenkte teamet. Den ene viste frem gjennomarbeidet kode, en tydelig teststrategi og et samkjørt team. Den andre var unnvikende når det gjaldt arbeidsprøver og kunne ikke beskrive konkret hvordan kvaliteten ble sikret. Referansene hadde sett like ut, men det gjorde ikke gjennomgangen. Valget ble enkelt, og det hvilte på evne snarere enn på salgsbudskap.
Gjennomgang i riktig skala
Teknisk due diligence handler ikke om mistillit, men om å ta en stor beslutning på et bedre grunnlag enn en brosjyre. Tilpass dybden til det som står på spill: et miniformat for det lille prosjektet og en grundig gjennomgang, gjerne med ekstern hjelp, for det store og kritiske.
Vi i Weapp er vant til å bli vurdert og til selv å gjøre tekniske vurderinger av systemer og leverandører som en del av tjenestene våre. Står dere foran et viktig leverandørvalg? Ta kontakt, så drøfter vi hvordan en gjennomgang i passende skala kan se ut for akkurat prosjektet deres.
Ofte stilte spørsmål
Hva er forskjellen på due diligence og å innhente referanser?
Referanser forteller hvordan det gikk i tidligere prosjekter, ofte sett fra fornøyde kunders perspektiv. Teknisk due diligence ser under panseret på hvordan leverandøren faktisk jobber: kodekvalitet, prosesser og sikkerhet. Referanser sier noe om resultatet, due diligence om evnen til å gjenta det. De utfyller hverandre og erstatter ikke hverandre.
Hva er det rimelig å be om å få se?
Arbeidsprøver eller kodeeksempler, en beskrivelse av utviklingsprosessen, inkludert hvordan kvaliteten sikres, og sikkerhetsrutinene. Man kan også be om å få møte de personene som faktisk skal jobbe i prosjektet, ikke bare selgeren. En seriøs leverandør er vant til spørsmålene og svarer åpent, så langt konfidensialiteten tillater.
Når er en ekstern fagperson verdt pengene?
Når forpliktelsen er stor og teknisk vanskelig å vurdere selv. Skal dere investere flere millioner kroner i et system dere blir avhengige av, kan en uavhengig teknisk fagperson gi en second opinion som lett betaler seg ved å fange opp risikoer tidlig. For mindre prosjekter er kostnaden ved en gjennomgang i full skala som regel ikke berettiget.
Hvordan gjør man due diligence på et lite prosjekt?
Med et miniformat. Be om et par kodeeksempler, still noen målrettede spørsmål om hvordan de sikrer kvalitet og tester, og gjennomfør gjerne en liten, avgrenset prøveleveranse. Det gir mye av tryggheten ved en full gjennomgang for en brøkdel av innsatsen, uten at det blir en tung prosess som står i misforhold til et lite oppdrag.
Hvilke varselsignaler bør man være oppmerksom på?
Motvilje mot å vise arbeidsprøver eller slippe til teamet bak selgeren, vage svar om hvordan kvalitet og sikkerhet håndteres, og løfter om at alt er enkelt. En leverandør som ikke kan beskrive sin egen prosess eller aldri ser ut til å ha støtt på problemer, har enten lite erfaring eller skjuler noe. Begge deler er grunn til å grave videre.