Underprioriteret kommunikation koster dyrt i webprojekter

Webprojekter kræver tæt kommunikation, som tager højde for at projektdeltagerne har forskellig begrebsverden og forståelse af projekterne. Ellers spilder projektdeltagerne hinandens ressourcer på at arbejde i forskellig retning.

Fra sød musik til frustration

Webprojekter er tværfaglige af natur, og kræver både specialistkompetencer og en projektleder i midten med overblik. Det giver masser af muligheder for, at man kan gå fejl af hinanden. Her vil jeg især kigge på forholdet mellem kunde og leverandør. Kunden kan være en webredaktør eller kommunikationschef; leverandøren kan være et firma, som implementerer webløsninger.

Ofte er der sød musik i luften, når projektet går i gang. Kunden er glad for endelig at have fundet en leverandør, som han har tiltro til, og begge parter glæder sig til at kaste sig over det spændende projekt.

For kunden kan det være flere års ønsker om forbedringer, som skal realiseres. For leverandøren kan projektet betyde penge og vækst.

Men undervejs går det galt. Leverandøren oplever at have strukket sig langt for at imødekomme kundens ønsker, og at den fortsatte strøm af krav fra kunden ikke er rimelig. Kunden oplever, at han ikke får det, som han har krav på.

Begge parter troede, der var en gensidig forståelse af opgaven.

Som et ekstra problem har man måske allerede sprængt budgettet og projektets tidsplan, og det er ikke realistisk for kunden at skifte til en ny leverandør. Nu oplever kunden at være holdt fast til en inkompetent leverandør.

Men hvad gik der galt?

Uudtalte forventninger skaber utilfredshed

Tit har kunde og leverandør i virkeligheden vidt forskellig opfattelse af, hvad der er leverandørens ansvar:

Kunden forventer en i enhver henseende fejlfri og velfungerende løsning, mens leverandøren alene forventer at skulle forholde sig til eksplicit formulerede krav - krav, om alene knytter sig til de specialudviklinger, kunden har bestilt, men ikke krav til systemet som helhed.

Kun meget få IT-systemer er helt fejlfri

Mange kunder har en opfattelse af, at de skal have en helt fejlfri løsning. Og sådan skal det ideelt set også være. Men fejlfrie løsninger er ekstremt dyre.

Software til kritisk hospitalsudstyr, fly og rumraketter - hvor der ikke under nogen omstændigheder må være fejl - koster mange gange mere, måske 10, 100 eller 1000 gange mere, end software hvor der hist og her er ubetydelige fejl.

Operativsystemer som Microsoft Windows og Mac OS er glimrende eksempler på almindelig, fejlbehæftet software. Der er masser af små og store sikkerhedshuller og andre fejl i dem, og derfor udsendes der løbende sikkerhedsopdateringer.

Websystemer er der også masser af fejl i, men de fleste er uden betydning. Og dem, som betyder noget for brugerne, skal naturligvis rettes.

Men ikke ret mange leverandører ønsker at fortælle kunden, at de får leveret et fejlbehæftet produkt. Og hvis kunden ikke ved bedre, tror kunden, at fejl i software er som huller i et par helt nye bukser: helt og aldeles uacceptabelt.

Kunde og leverandør har forskellig referenceramme

Ofte har kunde og leverandør forskellig referenceramme. Gælder det søgning, tænker kunden måske at Google sætter standarden for, hvad en søgemaskine skal kunne. Leverandøren ved godt, at det er meget, meget dyrt og udfordrende at levere den samme kvalitet som Google. Derfor sænker leverandøren - uden nødvendigvis at sætte ord på det - sine forventninger til, hvad en almindelig søgemaskine skal kunne. Men kunden tror stadig, at han skal have en toptunet søgemaskine, selv om det ikke er specificeret, hvad den præcis skal kunne.

Kunden oplever, at søgeresultaterne kommer for langsomt eller at søgemaskinen ikke i tilstrækkelig grad kan finde det, som er relevant. Og derfor synes han ikke, han har fået, hvad han forventede.

Hastighed - og især mangel på hastighed - giver tit skuffelser hos kunden. Det er veldokumenteret, at brugerne ønsker, at alle sider vises hurtigt. Men det kan være krævende at levere en løsning, som kan honorere det.

Første gang leverandøren ser kundens ønsker til, hvad systemet skal kunne, kan det være åbenlyst for leverandøren, at der er tale om ganske komplekse databaseoperationer, som tager lang tid at gennemføre. Og det betyder, at der kan gå tid, før slutbrugeren får vist sit indhold. Og derfor kan det for leverandøren forekommer forventeligt, at nogle sider tager tid at generere. Teknisk set kan det måske godt lade sig gøre at optimere hastigheden, men i leverandørens optik vil det være et selvstændigt "performance optimerings projekt", og kunden har måske i forvejen en presset økonomi.

Men hele denne tekniske dimension står måske ikke tydeligt frem for kunden, som bare forventer at tingene spiller uden problemer. Og som synes, at projektet er rigeligt dyrt i forvejen.


Ofte er der huller i leverandørens kompetencer

En dygtig leverandør har styr på mange forskellige aspekter af et webprojekt. Et godt eksempel er søgemaskineoptimering. Selv om et webprojekt måske ikke rummer eksplicitte krav til søgemaskineoptimering, bør enhver leverandør tage hånd om at teknikken spiller rimeligt sammen med eksterne søgemaskiner, især Google.

Men det er bare langt fra altid tilfældet. En af mine kunder havde et website, som var bygget på et system til intranet. Og selv om systemet var velegnet til intranet, var det en katastrofe til web, fordi det lukkede alle søgemaskiner effektivt ude. Derfor var det meste af indholdet usynligt på Google. Det betød tabt omsætning, og at kunderne søgte andre steder hen. Her burde leverandøren have været opmærksom på problemet fra starten af. Og enten have tilpasset systemet eller valgt et helt andet system.

Mange leverandører har ikke helt styr på alle dele af det, de arbejder med. Derfor er det vigtigt at vælge den rette leverandør og eventuelt få en ekstern konsulent til at tjekke leverandørens arbejde.

Kunder og leverandører giver ofte projektet forskellig prioritet

For den enkelte kunde vil det altid være kundens eget projekt, som er det mest vigtige. For leverandøren er kundens projekt formentlig bare ét blandt flere projekter, som alle skal passes ind i et flow af opgaver.

Men det er sjældent, at en leverandør har lyst til at fortælle kunden, at hans projekt sådan set ikke er det vigtigste lige nu. Måske vælger leverandøren at snakke kunden lidt efter munden og forsikre kunden om, at det er et meget højt prioriteret projekt.

Men har kunden et ønske om at enhver fejl skal være rettet inden for max. 48 timer, og leverandøren mener at alle fejl, som ikke lægger systemet ned, først skal ekspederes, når der er huller i de øvrige opgaver, så må det nødvendigvis føre til skuffelser.

Dårlig kommunikation er dyrt

Hvis ikke kunde og leverandør har samme opfattelse af projektets mål, kommer leverandøren til at levere noget andet, end det som kunden ønsker og slutbrugerne har brug for. I værste fald er man nødt til at starte forfra.

Projektets deltagere kommer også til at arbejde mindre effektivt. Hvis projektets mål er uklart, eller hvis man føler at ens arbejde ikke bliver påskønnet, har det negativ indvirkning på projektdeltagernes motivation. Det betyder højere pris, ringere kvalitet og længere tid for at gennemføre projektet.

Sådan fremmer du god kommunikation som kunde

  • Vær altid opmærksom på, om du og leverandøren har præcis den samme forståelse af projektet, og af de begreber, i anvender.
  • Sørg for at få alle væsentlige ønsker og forventninger skrevet ned. Men lad være med at blive stiv og krakilsk.
  • Afklar, om leverandøren tager ansvar for fejl og mangler i standardsoftware, eller om det kun er leverandørens egne specialudviklinger, som han vil tage ansvar for.
  • Afstem forventninger til, hvor hurtigt leverandøren skal reagere på fejl og mangler.
  • Kommunikér regelmæssigt, fx en gang om ugen, når der arbejdes med projektet.
  • Tilstræb at mødes fysisk, hvis det er muligt - det giver en tættere kommunikation.
  • Vær opmærksom på at skifte mellem at kommunikere overordnet og konkret. Det er de store linier i webprojektet som er væsentlige, men ofte er det først, når man bliver meget konkret, at man finder ud af, hvis man har forskellig forståelse af en problemstilling.
  • Identificer uklarheder så tidligt som muligt.
  • Tilstræb effektiv mødekultur og gode mødereferater. Sørg for let adgang for alle parter til at fremfinde tidligere beslutninger.