Tjekliste for valg af nyt bureau til digital udvikling

I store digitale projekter er der ofte stort fokus på at finde det rigtige system og den rigtige implementeringspartner. Men mange organisationer overser betydningen af at vedligeholde og udvikle partnerskabet med bureauet, når projektet går i drift. Resultatet er, at samarbejdet stille og roligt mister kvalitet, fordi der kommer færre dedikerede ressourcer fra begge sider af bordet.

Et af vores medlemmer fandt sig for nylig i den situation, at de efterhånden var utilfredse med den implementeringspartner, som de havde haft siden deres komplekse Sitecore-løsning gik live for nogle år siden. De oplevede, at det blev sværere og sværere at få lavet mindre ting tilstrækkelig hurtigt og godt, og derfor besluttede de sig for at finde en ny partner. Opgaven lød på at få ‘driftet’ deres omfattende løsning og lavet mindre udviklingsopgaver (men ikke nogen store projekter).

Her kommer deres liste over de ting, som de fokuserede på i valget af ny implementeringspartner:

  • System-fokuseret: Det skulle være et hus med Sitecore som fokus . Det skulle have et større antal Sitecore udviklere ansat for at sikre robusthed overfor personudskiftninger.
    Test: Spørg konkret til hvor mange udviklere, der netop nu sidder og udvikler på Sitecore, hvor mange systemer de ellers arbejder med, og hvordan arbejdet med Sitecore er vægtet i organisationen i sammenligning med andre systemer.
  • Moden organisation: Det skal være et bureau, som har levet nogle år, og som er kommet sig over ‘vokseværksfænomener’ (større organisatoriske omstruktureringer og indkøringsperioder).
    Test: Spørg til hvor gammel organisationen er og hvordan de har udviklet den gennem tiden. Det skal gerne være en historie som starter med nogle glade udviklere, og som har været igennem mindst to organisationsændringer for kunne håndtere support ordentligt.
  • Håndtering af support: Læg stor vægt på at spørge ind til, præcist hvordan ‘ikke-projekt-sager’ håndteres. Findes der et supportsystem, hvor sager kan rapporteres ind, og er der en organisation bag, som sikrer at sagerne håndteres indenfor en rimelig tid?
    Test: Få fremvist deres supportsystem og kig ind i nogle nuværende kunders sager. Det viser dels, om der overhovedet er et system, plus at når man kikker ind i konkrete projekter, får man hurtigt indblik i, hvor meget det anvendes, hvor ofte der lægges sager ind og om udviklerne rent faktisk bruger det til information om sagerne. Få dem til at forklare processen for, hvordan en supportsag håndteres fra start til slut.
  • Veletablerede rutiner: Undersøg hvordan organisationen fungerer, hvordan projekter håndteres i forhold til drift, og ikke mindst om der er etableret ‘best practice rutiner’. Når dette er etableret (og følges) viser det dels noget om organisationens modenhed, men også hvor let det er for dem at inddrage ekstra ressourcer/håndtere personudskiftninger i projekterne.
    Test: Bed både en projektleder og en udvikler om at forklare deres udviklingsrutiner og check om man får en samstemmende forklaring (helst på to forskellige møder).
  • Personstabilitet: Spørg ind til udskiftningsgraden af personer og tjek om udviklere generelt bliver i lang tid.
    Test: Spørg direkte til hvor længe udviklere typisk bliver i virksomheden. Lyt til hvor hurtigt og præcist der svares, og prøv om muligt at underbygge det ved at spørge referencer, om hvor mange personudskiftninger de har oplevet.
  • Typen af virksomhed: Implementeringspartnere er sjældent lige gode til alt, og det er vigtigt at finde ind til, hvad man får som kunde.
    Test: De fleste vil (naturligvis) sige, at de har dækket det hele, så spørg i stedet dels hvad de er bedst til (og acceptér ikke “vi er bedst til det hele”). Spørg derefter hvordan deres personale fordeler sig på Backend udviklere, Frontend udviklere, Designere, Usability, Salg, Administration etc.
  • Teamet: Prøv så vidt muligt at mødes med de personer, som du helt konkret vil komme til at arbejde med. Det afdækker naturligvis ikke alle mulige problemer, men med nogle har man en god kemi, og det er et vigtigt skridt på vejen.
    Test: Lad ikke kun super-projektlederen, super-udvikleren og super-sælgeren sælge hele organisationen. Sørg i stedet for at insistere på at mødes med de folk, som konkret vil blive tilknyttet jer som kunde.
  • Referencer: Tal med flere referencer for at høre, hvordan implementeringspartneren opleves fra forskellige kundeperspektiver.
    Test: Tal ikke kun med de referencer, som leverandøren selv giver jer. Brugt netværket til at finde andre organisationer, der har arbejdet med kandidaterne. Du kan f.eks. gratis spørge på J. Boyes danske LinkedIn-gruppe.

Med denne tjekliste ved hånden får du nogle rigtig nyttige redskaber, når der skal findes en ny implementeringspartner til jeres digitale aktiviteter. Det er ikke nødvendigvis alle punkterne som giver mening i enhver kontekst; det vigtigste budskab er derfor at lægge et ordentligt stykke arbejde i evalueringen.

Tænk på, at det er arbejdskrævende og dyrt at skifte leverandør – og at det derefter er et samarbejde, som vil blive ved med at koste tid og penge. Lad derfor være med at tage den første og bedste. Find ud af hvad der er vigtigt for jeres organisation og lav så en tjekliste som ovenstående, over hvordan I vil sikre, at jeres behov bliver opfyldt.

Lær mere

  • Kom med i en erfa-gruppe om webprojektledelse og hør fra andre, hvordan de samarbejder med deres implementeringspartner
  • Del dine gode råd i kommentarfeltet nedenfor: Hvad mener du er vigtigt i valget af ny samarbejdspartner?

Tak til Peter Sejersen som bidrog til første udgave af denne artikel