Meget ofte bliver der lagt forholdsvis meget energi i opstart af projekter. Men blot fordi et projekt er kommet godt i luften, er det ikke ensbetydende med, at det går resten af vejen på autopilot. Det er også set mange gange at eksterne konsulenter mister interessen hen ad vejen.

Det holder ikke! Eksterne konsulenter skal levere kvalitet under hele processen – det kan kunden forvente. Kunden må endda kunne forvente mere af en konsulent end af en fastansat, også selv om projektet varer i flere måneder eller måske år.

Vi har talt en del om brugen af konsulenter i J. Boyes erfa-grupper og nedenfor følger de vigtigste råd.

Friske, erfarne øjne udefra

Blandt det vigtigste som kunden betaler ekstra for, er friske eksterne og erfarne øjne. Som konsulent bidrager man med erfaringer fra andre projekter – både succeser og fiaskoer – og den erfaring er værdifuld for organisationerne. Det er med til at retfærdiggøre, at konsulenten bliver betalt mere end den fastansatte.

Flere virksomheder har efterhånden rigtig gode erfaringer med, at den eksterne konsulent stiller de “dumme” og uddybende spørgsmål, som de ikke selv ser, fordi det for dem er en selvfølge.

Hjælp til selvhjælp

I længerevarende projekter kan eksterne konsulenter nemt at forfalde til at lulle lidt ind i organisationen og blive en del af problemet. Men det er efter min mening vigtigt at undgå, for som konsulenter er den vigtigste rolle netop at komme ind i organisationen med friske øjne.

Da vi tidligere lavet meget rådgivning, var jeg selv på flere opgaver af forskellig længde, fra ganske korte på under en uge til projekter med op til et års tilknytning. De første måneder er der oftest meget nyt at sætte sig ind i og forstå, såsom de daglige rutiner, hvordan og hvem der træffer beslutninger og organisationens charme. Jeg har flere gange oplevet efter et stykke tid at blive mere eller mere behandlet som en fastansat. Sådan kan det nemt gå, når man møder hver morgen og kommer hver dag. Det er på sin vis godt, idet konsulenter i bund og grund blot er en ressource, men det er også problematisk, hvis det betyder, at vi ikke kan undværes.

Derfor er det meget vigtigt, at konsulenter sikrer sig en vis afstand og ikke bliver en del af virksomhedens fnidder-fnadder. Konsulenten må sørge for ikke at være på nogens side og forholde sig upartisk til de organisationsgrupperinger, der eksisterer. Samtidig må konsultenten også sørge for at give sin viden videre, så kunden kan klare sig selv.

Konsulenter med store ører

Egentlig burde man kunne kende konsulenter på lang afstand, for de burde være udstyret med meget store ører og en knap så stor mund, da én af konsulentens vigtigste opgaver som bekendt er at lytte og stille spørgsmål. Ved at stille de rigtige spørgsmål kommer en konsulent tættere ind på kundens behov. Og når de bliver opfyldt, får kunden en fornemmelse af succes og kvalitet. Især i et forandringsprojekt, er det utroligt vigtigt at lytte hele tiden til dem der arbejdes sammen med – og ikke kun til dem, konsulenten arbejder for.

En anden vigtig rolle, konsulenter har, er at være synligt usynlige. I et af mine projekter skulle jeg hjælpe en medarbejder med en enorm arbejdspukkel. Sammen skulle vi drible bolden i mål, men jeg skulle også sørge for, at det var den fastansatte, der kom til at fremstå som den gode. Det var ikke mig, men kunden, der havde æren. Sammen kunne vi dog fejre succesen, da der var kommet mere styr på opgaverne.

Men kunderne er også meget forskellige. I værktøjskassen er der nødt til at være mange forskellige værktøjer. Hammeren virker måske hos én kunde, men ikke hos en anden. Det finde den gode konsulent ud af ved at lytte og have situationsfornemmelse.

Modet til at tage en konflikt

Specielt når krisen af og til kradser i konsulentverdenen, har mange medlemmer oplevet, at konsulenthuse tager opgaver ind under forudsætninger som de måske allerede fra starten kan se ikke kan lade sig gøre.

Som flere medlemmer har sagt: Det er ikke altid den billigste løsning at få den laveste timepris!

En god konsulent kan se udfordringerne undervejs og i god tid gøre opmærksom på dem.

Som Peter Drucker sagde:

There is nothing so useless as doing efficiently that which should not be done at all

Faglig og menneskelig udvikling

Og så er vi ved noget af det centrale. For at konsulenten kan levere kvalitet fra start til slut, er det nødvendigt, at konsulenten kan udfylde to roller, som jeg mener er lige vigtige.

1. Den faglige rolle for ofte er det den faglige viden, der etablerer engagement i et projekt.
2. Den medmenneskelige rolle er lige så vigtig. Det er nødvendigt at beherske empati, integritet, og forstå grænserne mellem det at være ansat og det at være konsulent.

Den faglige viden er de fleste dygtige konsulenter ofte gode til at vedligeholde, men det kniber ofte med de mere menneskelige sider.

Som konsulent er det ikke ligetil at udvikle sig som konsulent-menneske, men jeg mener, at dette er lige så vigtigt som at deltage i faglige kurser og læse fagblade. At være konsulent er en livsindstilling – det er noget, man har i sig. Men det er også en livsstil der skal være i udvikling.

Hidtil har mange behandlet deres hjemmeside som en one-size-fits-all løsning, hvor alt skulle passes ind. For mange har dette vist sig at være dyrt, besværligt og ofte med et ringe resultat for målgruppen. Med ønsket om at ramme en speciel målgruppe, profilere et årsregnskab eller lancering af et nyt produkt, søsættes der konstant mange minisites. Dette stiller krav til forvaltning og genbrug af indhold samt processer og planlægning, for at undgå et truende kaos.

Nogle sites bliver planlagt lang tid i forvejen, mens andre opstår pludseligt. Uanset tidshorisonten, er der en række punkter, det er vigtigt at overveje, så man ikke mister overblikket.

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

Denne artikel opridser de vigtigste overvejelser der kan hjælpe dig til en bedre og kortere kravspecifikation, typisk på under 20 sider.

Som du spørger får du svar

Som en god tommelfingerregel kan man forvente at tilbudsmaterialet altid er længere end udbudsmaterialet. Med kravspecifikationen som en væsentlig del af udbudsmaterialet betyder det, at hvis kravspecifikationen er på 60 sider, kan man forvente at modtage tilbud på mindst 60 sider. Jeg har set udbudsmateriale på flere hundrede sider, og efterfølgende tilbud der naturligvis var endnu længere. Hvis du, hvilket ikke er usædvanligt, vælger at sende udbuddet til 12 leverandører, betyder det nemt, at du efterfølgende skal bruge uger på at læse og vurdere tusinder af sider.

Selvom det var målet at lave et kort dokument, er det ikke altid lige nemt. Alle involverede har deres egne krav og ønsker som de vil have tilføjet. Kravspecifikationen har det med blot at blive længere og længere efterhånden som den kommer rundt internt.

Det er nødvendigt at én påtager sig den tidskrævende rolle som den der kan fokusere og skære dokumentet til.

Forskellen på krav og udvælgelseskriterier

At kræve et brugervenligt og hurtigt system er fornuftigt. Det giver også god mening at kræve stabil drift, god dokumentation, let integration, relevante referencer og meget mere. Det er dog vigtigt tidligt at skelne mellem krav og deciderede udvælgelseskriterier:

• Krav kan der være rigtig mange af. Hver afdeling kan have deres egne fornuftige krav af både indholdsmæssig og teknisk natur.
• Udvælgelseskriterier er de vigtigste krav. Dem der rent faktisk bruges til at vælge og fravælge leverandører.

Uanset størrelsen på din organisation, er der sjældent mere end 10 udvælgelseskriterier mens der kan findes hundredvis af krav. I kravspecifikationen skal udvælgelseskriterierne beskrives så det tydeligt forklares hvorfor de er vigtige og samtidig hvad der egentlig menes. Der er uenighed omkring de fleste fagudtryk, så vær hellere overtydelig end indforstået.

Fokuser på hvordan og ikke hvad

Det er spild af tid at bede leverandøren blot sætte kryds i højre kolonne som et tegn på om et krav eller udvælgelseskriterium er opfyldt. Desværre er denne metode stadig ofte brugt og når tilbudene bliver læst, går mange i gang med at tælle antallet af “ja”-svar. Med en vægtning på forskellige krav bruges dette så til at vælge den rette leverandør.

Der er mange problemer ved at bruge denne metode. Det værste er, at du som køber ikke bliver klogere af de svar du får. Et eksempel: Hvis en leverandør har afkrydset at der findes integration med Facebook, er det langt fra sikkert at leverandøren mener det samme med Facebook-integration som du gør. Ved blot at tælle antallet af ja-svar får man muligvis det system der kan mest, men det er typisk dyrt og sjældent det bedste!.

Det vigtige er at tilbudsgiverne, altså dem der skal svare på din kravspecifikation, fokuserer på at besvare hvordan dine udvælgelseskriterier kan opfyldes. Leverandørerne skal beskrive hvordan deres workflow opfylder dine krav, eller hvordan integration med dine systemer kan lade sig gøre. På denne måde lærer du som køber meget om systemet undervejs, og leverandøren bliver samtidig tvunget til at tage stilling til dine beskrevne problemstillinger.

Lav to dokumenter

Det er såmænd fornuftigt nok at samle hele organisationens krav i en lang liste, men lad være med at inkludere dem i din kravspecifikation. Den lange liste med krav kan bruges når du går i gang med at læse de mange tilbud igennem. Den kan også bruges som en tjekliste når du har inviteret til tilbudspræsentation eller prototype.

Kravspecifikationens fokus skal være på dine udvælgelseskriterier.

Forventningsafstemning

For mange er arbejdet med kravspecifikationen det første synlige skridt på vejen mod en bedre arbejdsdag. Der er mange forventninger knyttet til processen, og der bliver lagt mærke til alle detaljerne. Projektnavnet ligger der f.eks. stor betydning i.

Det er vigtigt ikke at starte processen hvis beslutningen om fremtidig leverandør allerede er truffet. Dette lyder logisk, men alligevel vælger mange at starte processen blot for at tilgodese interne hensyn, ofte for at alle skal “føle sig hørt”. Det er spild af tid, useriøst og dårligt for omdømmet. Det rygtes hurtigt hvis man ikke har styr på sagerne.

Husk også at behandle alle leverandører ens. Hvis du er en offentlig organisation er du lovmæssigt forpligtet til dette, men også som privat firma er det værd at overholde god skik og huske at leverandørerne også fra tid til anden taler sammen. Det giver også en bedre beslutning hvis der ikke blev forskelsbehandlet. Tænk igen på dit omdømme!

Sidst, men ikke mindst, fortæl i udbudsmaterialet hvad der forventes. Hvis du vil indbyde til tilbudspræsentation og derefter forventer en gratis prototype hvor leverandør skal stille software og ressourcer gratis til rådighed i en uge så meddel dette på forhånd. Hvis leverandøren kender betingelserne når der afgives tilbud, undgår du overraskelser undervejs.

Held og lykke med projektet!

Bemærk at kun de kommuner, der har valgt en ny CMS-platform i perioden, er taget med i oversigten.

Informationerne er ikke i alle tilfælde baseret på oplysninger fra kommunerne, men i vid udstrækning baseret på andre kilder, herunder leverandører og web-konsulenter.

Hvis du har ændringer og tilføjelser, så skriv gerne en kommentar nederst.

Listen er i et regneark via Google Docs og bliver regelmæssigt opdateret

Hjemmesider og intranet: Hvilket CMS vælger kommunerne?