Overvåger eller måler du din hjemmeside?

Når jeg er rundt i de danske kommuner (ja, og private virksomheder for den sags skyld), og snakker med webredaktører og webmasterer om deres brug af webanalyse, så fornemmer jeg ofte at man oftere praktiserer overvågning end måling – på trods af at man proklamerer, at man måler(!?) Når jeg bruger de to nært beslægtede, næsten synonyme termer, så er det ikke helt uden mening. Det er nemlig ikke det samme!
Overvågning er i min optik, at følge med – at følge brugerne, at se hvordan brugerne agerer og bruger hjemmesiden, at overvåge hvor mange der besøger hjemmesiden, hvor mange der finder hjemmesiden fra Google, og hvor mange der fundet hjemmesiden ved at søge på “Børnebidrag”, “Pasfornyelse” eller “Snerydning”. Det er jo også fint, for det giver os information om brugernes brug af det indhold og den service, som vi stiller til rådighed for vore borgere og kunder.

Måling derimod handler om at finde frem til om brugerne gør det, som vi gerne vil have dem til at gøre – altså vi har et strategiske formål, som vi gerne vil opfylde. Vil vi gerne have at vores brugere søger efter “Børnebidrag”, “Pasfornyelse” eller “Snerydning” på Google og finder vores hjemmeside på den måde, så måler vi. Er det sort snak fra en rablende gal mand, eller giver det bare en smule mening?
For at sætte det hele på spidsen, kan vi også artikulere overvågning som “at se på noget”, men måling som "at se på noget og sammenligne det med noget andet”. Når man måler bliver man nødt til at holde det op mod noget andet – ellers giver det ikke mening. At måle stuens loftshøjde giver ingen mening uden at gøre det på en skala – på denne side af kloden hyppigst i centimetermål. Ergo man sammenligner det man måler, med det som står på tommestokken. Overvåger jeg stuens loftshøjde ser jeg blot på den, og får aldrig at vide om der er højt nok til loftet, så jeg kan samle den min nyindkøbte IKEA-samle-selv-reol, som jeg fik smidt på traileren sidste weekend.

Min pointe er, at hvis jeg måler min stues loftshøjde, så kan jeg foretage beslutninger – har jeg plads til mit maleri, hvor højt skal lamperne hænge, hvor meget maling skal jeg købe til væggene, og er der plads til den føromtalte reol? Det kan jeg ikke, hvis jeg blot overvåger.
Skal jeg overføre analogien til mit arbejde med hjemmesider, kan jeg måle hjemmesiden i forhold til min strategi og foretage beslutninger på baggrund af dette. Overvåger jeg kun, har jeg ikke et sammenligningsgrundlag og kan ikke argumentere for hvorfor jeg skal investere i en ny selvbetjeningsløsning, netbutik, SMS-løsning eller noget helt fjerde.

Overvågning er helt fint med mig i nogle tilfælde, mens måling i min optik altid er krævet. Overvåger du kun, så har du intet grundlag at foretage beslutninger på. For at hjælpe dig lidt på vej er der to termer jeg gerne vil introducere – HBI og KPI.

• En HBI (Heart Beat Indicator) er noget som fortæller dig hvorvidt din hjemmeside er i live – kører det? To gode eksempler er besøgstal eller sidevisninger. Altså “min hjemmeside har 100.000 unikke besøg om måneden”. Det er jo super godt! Men siger dette tal egentligt noget om din hjemmeside? Er det 100.000 af de besøg du gerne vil have? Er det 100.000 af de 25-45 årige højtuddannede kvinder, som ligenøjagtigt din hjemmeside henvender sig til, eller er det de 12-16 årige unge piger og drenge, som du ikke henvender dig til? Jeg hører ofte webmastere og –redaktører brøste sig hvor mange besøg de har, og når jeg læser kommunalt eller statsligt udbudsmateriale, står der ofte hvor mange mennesker der kommer forbi den kommunale eller statslige hjemmeside, som jeg sidder og læser kravspecifikation på. Det er da også meget rar viden for driftsfolkene, så de ved hvor mange RAM de skal sætte i serveren, men for mig, som rådgiver, er jeg egentligt ligeglad. Desværre er besøgstallet blevet for kommunale og statslige kravspecifikationer, hvad saxofonen var for Danseorkestret, Tøsedrengene, News og samtlige danske 80’er pop-ensembler – fast inventar i enhver komposition. Der er opstået konsensus om at besøgstallet er vigtig viden, men har du ikke en strategi (altså noget at holde det op imod), så kan det vel være ligemeget?
• En KPI (Key Performance Indicator) derimod er noget der fortæller dig hvorvidt din hjemmeside gør det godt eller dårligt. Det er altså et mål på en skala. En KPI er defineret ud fra din organisations strategiske målsætninger og søger at måle hvor god hjemmesiden er til at opfylde dets formål. To gode eksempler på KPI’er er (kort fortalt) brugere der gennemfører en transaktionel selvbetjening eller køber en vare i en netbutik. Altså “der er 150 af mine besøgende der har skrevet deres barn op til en plads i en vuggestue i denne måned”. Se, det er jo rart at vide – specielt hvis du har 100.000 unikke besøg om måneden, og du samtidigt har undersøgt demografien blandt dine besøg den pågældende måned, og har fundet ud af, at 15.000 af dine besøg er foretaget af en person, der har børn i alderen 0-3 år. Så ved du at 1 pct. af dine unikke besøg, der tilhører segmentet, den pågældende måned, har resultateret i en pladsansvisning. Nu kan du så måle på din skala, om dette er godt eller dårligt. Har du forventning om at 500 skriver deres barn op, ja, så står jo lidt skidt til, og du må agere. Regeringen har i deres IT- og telepolitisk redegørelse for 2010 udtalt, at omkostningerne ved en digital henvendelse kun er en brøkdel af en telefonisk henvendelse. Hvis vi antager at det koster 100 kr. at gennemføre en telefonisk henvendelse til pladsanvisningen, men kun 5 kr. at gennemføre en digital via hjemmesiden, så skal lidt hurtigt hovedregning til for, at synliggøre at det koster kommunen 35.000,00 kr. at gennemføre de resterende 425 henvendelser telefonisk, men kun 1.750,00 kr. at gøre det digitalt. Altså en samlet besparelse på 33.250,00 kr. pr. måned ved at flytte de resterende 350 henvendelser til hjemmesiden(!!). Og disse tal er lavt sat. En af de meget få statistikker, der rent faktisk er udarbejdet omkring digitale kontra analoge henvendelser i en kommune, jeg har set tilhører en stor sjællandsk kommune, har ca. 65.000 henvendelser til pladsanvisningen om året i alt, hvor blot 2.000 var gennem deres selvbetjeningsløsning. Hvad der ikke er af økonomiske besparelser for denne kommune ved blot at flytte få procent af disse til hjemmesiden er jo enorm. Nåh, men det er en anden snak! Økonomiske besparelser skal jeg nok komme ind på, på et andet tidspunkt.

Dette er nok den enkelste måde at skitsere forskellen mellem at overvåge og måle, og hvad du kan bruge det til. Overvågning handler om at holde øje med hjemmesiden, men hjælper dig ikke videre. Måling tager udgangspunkt i en sammenligning af flere tal, for at kunne holde dem op imod et strategisk mål. Overvåger du kun, rykker du ingen vegne – måler du, kan du optimere.

Det er dog desværre mere reglen end undtagelsen hos de kommuner jeg kommer rundt i at man nøjes med at overvåge og glemmer at måle. Nogle gange overvåger man heller ikke, men beror udelukkende på antagelser og formodninger.

Det er derfor ultra vigtigt, at du forstår at skelne mellem overvågning og måling – og at du måler i stedet for blot at overvåge!

Så vil du igang, så undgå blot at overvåge – mål! Definer hvad du vil med din hjemmeside, opstil KPI’er og mål! Det det eneste der får dig til at rykke!

Fleksjobbere på nettet er Win-Win-Win!

Hjørring Kommune har netop lanceret en internettjeneste til lokale virksomheder, hvor de kan surfe blandt kommunes mange fleksjobbere. Dette er ikke kun til gavn for borgerne, der får et udstillingsvindue, hvor de kan gøre sig lækre overfor virksomhederne. Erhvervslivet har fået en intuitiv database, hvor de kan finde relevant og kompetent arbejdskraft. Herforuden slipper jobcenteret for en masse telefonsamtaler med virksomheder og borgere, og opnår dermed synlige besparelser. Det må hvad man kalder en Win-Win-Win situation.
Formålet med den nye database er at få flere borgere i arbejde. Borgere som ellers ville sidde derhjemme, da de ikke kan varetage en fuldtidsstilling – det kan enten være pga. sygdom eller ældre borgere, der stadigvæk ønsker at være erhvervsaktive, men ikke kan varetage 37,5 timer om ugen. Det er altså borgere, der af en eller anden personlige årsag ikke kan varetage et fuldtidsjob og derfor ellers ville være tvunget til et liv udenfor arbejdsmarkedet. Borgere der derfor måske må se sig nødsagigt til et liv uden daglig kontakt med andre mennesker, social samværd og selvtilfredsstillelse ved at gøre et godt stykke arbejde. Flekjobordningen gør at borgere, der ellers udelukkende er en økonomisk byrde for Hjørring Kommune og dermed ikke vil “bidrage med værdi” tilbage til samfundet, hermed får mulighed for det.
Den nordjyske kommune har dog valgt at bruge internettet til at facilitere kommunikation mellem virksomhed, kommune og borger. Hermed gør internettet det muligt at løfte en meget stor andel af den opgave det er, at skaffe fleksjobberne i job. Personlige møder, papirstunge brochurer og analoge telefonhenvendelser er erstattet af en strømlinet og effektiv digital proces. Kommunerne lægger profiler om borgerne i en database, som erhvervslivet herefter søger i. Når en virksomhed har fundet en egnet kandidat tager den kontakt til kommunen ved at udfylde en simpel kontaktformular. Kommunen modtager en e-mail, og kontakten er skabt. Kommunen vender altså den sædanvalige tankegang på hovedet – i stedet for udelukkende at pushe, så pull’er den også – altså det som man på handshøjskolemarketingmanagementjargon kalder for en Push-Pull strategi. Den skubber ikke borgerne ud i virksomhederne, den trækker på virksomhedernes efterspørgelse. Hermed sikrer man også at den enkelte virksomhed er reelt interesseret i den pågældende borger, og kommunen slipper for at rette forgæves henvendelse til virksomhed, som i bund og grund ikke har behov for den pågældende borger. Hermed er en selvbetjeningsløsning skabt, som ikke drejer sig om at anmelde flytning eller skrive sit barn op til vuggestue.
De midler der bliver frigjort, kan kommunen så bruge på at markedsføre databasen – her kommer push ind igen. Hermed kan kommunen målrette markedsføringen og skabe synergier på tværs af medier, der gør at flere virksomheder og borgere bliver opmærksomme på databasen. Onde tunger vil nok bemærke, at den økonomiske gevinst ryger i puljen igen. Databasen giver ikke nødvendigvis flere penge på bankbogen, da pengene går til markedsføring, men den giver i høj grad samfundsmæssig og servicemæssig værdi. Samtidigt giver afleder fleksjobdatabasen gevinster i form af færre borgere, der skal have kontanthjælp, færre borgere der belaster det kommunale system og færre borgere, der har ondt i sjælen over at gå ledige.
Så kære kommuner. Tænk kreativt, ud af boksen. Hvordan kan der skabes online tjenester, der er Win-Win-Win for både borgere, erhvervslivet og kommunen?

Brug internettet til borgerinvolvering

Når skrædderen skal sy et jakkesæt for sin nye kunde vil det virke uhørt ikke at lytte til kundens behov. Ja, faktisk kan han slet ikke sy jakkesættet uden at snakke med kunden. Han skal vide hvor høj og hvor bred kunden er, hvor smal eller bred hans talje er, hvordan kropsbygningen er, så jakkesættet passer til kundens kropsbygning. Skal det være nålestribet, blåt, gråt eller sort?
Ovenstående eksempel er selvfølgeligt rimeligt klichéagtigt og søgt. Ja, naturligvis kan skrædderen ikke sy jakkesættet uden at kende sin kundes mål, men hvorfor finder dette så ikke sted i andre brancher eller sektorer? Hvorfor ikke også spørge kunderne i andre butikker? Som i den kommunale butik? Kommunerne er blandt landets største virksomheder. De har endda været så snedige på Christiansborg at opdele markedet geografisk og give kommunebutikken ubetinget monopol indenfor deres eget lille lokale område. Så hvorfor ikke i det mindste høre kundernes stemme ved at spørge dem? Er det gået for meget TDC, Microsoft eller Post Danmark i den? Ikke sagt, at kommunerne skal privatiseres og vi skal tilbage til små konkurrende kommuner, men kunne kommunerne ikke spørge brugerne af deres tjenester tilråds oftere? Kommunens kunder køber ikke bredbånd, operativsystemer eller frimærker, men forbruger tjenester hos miljøstationer, børnehaver og biblioteker m.v. Man ser dog al for ofte, at kommunale og lokale beslutninger trækkes ned over hovedet på borgerne af et ellers borgervalgt byråd.
Hvorfor ikke spørge brugerne af de kommunale tilbud om vejledning til hvordan beslutningerne skal tages? Joh, joh - jeg ved godt at der både arrangeres borgermøder, demonstrationer iværksat af politiske fløje og der skrives læserbreve i dagspressen for at opilne til debat om hvorfor placeringen af en ny Cheminova fabrik skal ske mellem en vuggestue og et ældrecenter eller at en ny motortrafikvej skal gå tværs gennem en naturskøn dal, hvor lokale ornitologer sædvanligvis gør deres weekendvisit. Det er også fint nok, men hvorfor ikke bruge internettet til at facilitere debatten – og hvorfor kun forholde sig til skoldhede debatter som førnævnte eksempler. Hvorfor ikke også stikke klør fem ind i mindre politiske hvepsereder? Web 2.0 giver lige nøjagtigt borgerne mulighed for at udtrykke sig, og Web 2.0 giver politikerne et forum til at lytte.
Web 2.0 handler bl.a. om dialog og brugerinvolvering – men det kommer i mange afskygninger. Web 2.0 er et paradigme, et tankesæt, en digital livsstil. Det handler kun i ringe grad om teknologi. Vel at mærke understøtter teknologier som AJAX (Asyncronus JavaScript) og RIA (Rich Interactive Applications) Web 2.0, men først og fremmest handler det om at gøre tingene lidt anderledes end hvad man er vant til – Web 2.0 handler om dialog og to-vejs kommunikation, hvor man sædvanligvis har arbejdet med at skubbe information i én retning. Det handler om at animere brugerne til inddragelse og deltagelse i budskabet. Lad mig forklare med et eksempel: Hvem kender ikke Facebook? Verdens ukronede konge indenfor opstøvning af gamle klassekammerater, efterskolekærester og fjerne familiemedlemmer. Facebook kommer på næsten alle verdens sprog. Men det er relativt nyt. I langt tid har Facebook kun eksisteret på de store sprog. Da Facebook skulle sprogversioneres til mindre udbredte sprog, som dansk, da spurgte Facebook brugerne. Hvad skal “Requests”, “Status Updates” og “View Message Inbox” hedde på dansk? Det var brugerne der ved simple afstemninger bestemte, at oversættelserne blev “Anmodninger”, “Statusopdateringer” og “Vis beskedindbakke”. Facebook spurgte så resten af sine nu registerede 350.000.000 brugere om hvad termene skulle hedde på andre sprog. Dette har gjort, at Facebook på ét døgn havde oversat Facebook til størstedelen af verdens sprog. Tænk på hvis Facebook skulle hyre translatører til at gøre oversættelsesarbejdet. Tænk på hvor mange mennesker der skulle til for at dække alle sprog, og tænk på hvor mange timer, der skulle bruges på det. Ved at spørge brugerne kunne Facebook altså få gratis oversættelsesassistance på en hundrededel af den tid, som ellers skulle have været brugt! Snak om optimering, hva’? Tænk så på hvad Web 2.0 kan bringe det kommunale Danmark?
Hvornår får kommunerne øjnene op for at Web 2.0 kan hjælpe med at gøre livet nemmere for både borgere og politikere? Når jeg snakker med beslutningstagerne i de kommunale webgrupper, så slår de stort set alle på tromme for Web 2.0, men har svært ved at artikulere hvordan Web 2.0 kan bruges i ligenøjagtigt deres situation. Ellers kan de godt, men tør ikke at tage skridtet fuldt ud og implementere Web 2.0. Jeg møder dog også ofte frygten for, at Borgerne kommer med snavs og skidt, fremfor at holde kammertonen. Samtidigt mangler der måske opbakning fra byråd og kommunaldirektion til at allokere midlerne til et ordentligt Web 2.0 projekt. Det er ærgerligt!
Hjørring Kommune har dog formået at omsætte teorietisk sniksnak til benhård praksis, og opbakningen fra organisationen er tilstede. Hjørring Kommune lancerede ny kommuneportal på http://www.hjoerring.dk d. 01/02/2010, hvor Web 2.0 er et af hovedelementerne. Konkret spørger Hjørring Kommune blandt andet sine borgere på hjemmesiden om hvor placeringen af en ny genbrugsplads skal være nær Løkken. Det skal nok give lokal debat, da Løkken jo er kendt for sit sprudlende turistliv. Dette giver kommunen mulighed for at lade borgerne præge beslutningen og foretage et valg baseret på hvad borgerne reelt ønsker og ikke på politkernes antagelser. Borgerne har mulighed for at kommentere direkte på kommunens portal og det indhold som kommunen publicerer, så andre borgere kan deltage i debatten. Dette kræver ikke borgermøder, demonstrationer eller læserbreve, men faciliterer debatten på internettet – og det eneste kommunen betaler for er den strøm, som portalen bruger. Ergo, er der også et rationaliseringspotentiale i Web 2.0. Ved at bruge portalen til borgerinddragelse kan kommunen foruden øget dialog med borgerne også nedbringe omkostninger til fysiske tiltag – dobbel op på fordelene, der!
Én af de nok mere almenkendte Web 2.0 tiltag er weblogs, også blot kaldt for blogs. En blog kan sammenlignes med det traditionelle, trykte læserbrev. Det er et domæne, hvor en given person kan give sine meninger til kende om et selvvalgt område. Borgerne, eller brugerne i almindelighed, kan herefter kommentere på personens meninger på tværs af tid og sted. Dette øger sandsynligheden for at folk giver sine egne holdninger til kende qua den øgede tilgængelighed som internettet stiller sammenlignet med den oldnordiske arbejdsgang med at sende et læserbrev ind til et givent lokalmedie. Samtidigt øger blogs sandsynligheden for brugerinvolvering, da borgerne kan svare tilbage hurtigt, på tværs af tid og sted. Nøjagtigt som de gode gamle læserbreve, afføder blogindlæggene ofte hede debatter, der ender ud i ganske konkrete idéer og forbedringsforslag.
Men ja ja, fint nok! Onde tunger vil her til sidst udbryde at ved at “omlægge” borgerinvolveringen til internettet fremfor fysiske lag, så er der udvalgte grupper af befolkningen der står af, heriblandt den ældre generation! Ikke nødvendigvis, er svaret. Sidst It- og Telestyrelsen gennemførte sin store undersøgelse “Borgernes IKT-færdigheder i Danmark” i 2007 blev det konkluderet at 60 % i aldersgruppen 60-69 år bruger computere i det daglige. Dette er da ganske betydeligt, taget i betragtning at hjemmecomputere og internet først er blevet allemandseje for 10-12 år siden. Og hvis undersøgelsen blev gennemført i 2010 er jeg helt sikker på, at denne andel er vokset. Derfor mener jeg ikke at argumentet om at de ældre befolkningsgrupper udelukkes fra borgerinvolveringen holder. Desuden handler det også om opdragelse. Formår kommunerne via andre kanaler at markedsføre kommuneportalen som platform for borgerdialogen, så skal borgerne nok følge med. Jeg vil faktisk mene at kommunerne kan nå ud til flere borgere ved at bruge internettet. Web 2.0 fordrer spontaniteten og når mennesker, der normalt ikke deltager i hverken demonstrationer eller borgermøder – derfor vil jeg våge at påstå at kommunerne på denne måde kan få flere med på vognen!
Så kære beslutningstagere i de danske kommune, lad være med at være så berøringsangst overfor brugen af Web 2.0 og lad os komme ud over stepperne. Der er masser af fordele og gode eksempler, og dem jeg har nævnt her er blot toppen af isbjerget.

7 spørgsmål til afdækning af nytteværdi i et webudviklingsprojekt

Nedenstående blogindlæg bygger på de erfaringer jeg har draget mig i kommunale webudviklingsprojekter, men er ligeså gældende for private.


Jeg synes ofte at jeg møder beslutningstagere hos danske kommuner, der ikke tager stilling til nytteværdien, når midler til et nyt webudviklingsprojekt skal allokeres. Beslutningsårsagen “so-ein-ding-muss-ich-auch-haben” lever sin trygge tilværelse hos de danske kommuner. Men bare fordi at kommunaldirektøren i nabokommunen har fået nyt legetøj, er det vel ikke sikkert, at dette giver mening for andre end ham? Min påstand underbygges af Rambøll Management og DANSK IT’s store årlige publikation, IT i Praksis, der i sin 2009 rapport dokumenterer, at en tredjedel af de danske kommuner ikke tager stilling til nytteværdi ved hjælp af en Business case og ROI (Return-on-Investment) analyse, samt at en tredjedel af dem, som rent faktisk gør det, slet ikke følger op! Alt for meget udbudsmateriale og al for mange udviklingsprojekter bærer desværre præg af dette.

Jeg har løbende arbejdet som projektleder med udvikling af en ikke unævneværdig del af de danske kommunale portaler, samt skrevet svar på materiale fra kommunale udbud på portaler og intranets. Og jeg undrer mig tit når jeg læser kravspecifikationerne. For en meget stor andel af kravene, virker nytteværdien absurd lav. Det virker ofte som om, at kravidentifikationen ikke har taget udgangspunkt ved at kigge på sin egen situation, men ved at surfe rundt på andre kommuners hjemmesider. Det er også fint nok at holde sig ajour med hvad andre gør, men når en beslutningstager direkte henviser til en specifik underside på en anden kommunal hjemmeside, og fortæller mig, at den der dims vil han også have, ja, så står jeg af. Jeg besvarer ofte i et kryptisk, halvarrogant, businessbullshitagtigt sprog om han kender de punkter, hvor netop den funktionalitet vil løfte hans forretning. Og det gør han sjældent.

Jeg tør ikke tage stilling til antallet af kommuner, der ikke direkte estimerer nytteværdien, ligesom Rambøll Management og DANSK IT, men jeg mærker at der er langt mellem snapsene. Nogle kommuner er rigtig dygtige og tydeligt dokumenterer forventninger til nytteværdi i metodebaserede Business Cases, mens det hos andre er tydeligt at se, at den førnævnte beslutningsårsag florerer som den netop overståede svineinfluenza. Det er lidt sørgeligt, når man tænker på, hvordan kommunerne er finansierede, og man skulle tro at pengene kunne benyttes bedre.

Så hvad gør vi nu? Den danske offentlige webverden mødes på den røde løber til det årlige awardshow, “Bedst på Nettet”. Her hædres de bedste danske offentlige webløsninger og et klap på skuldrene gives til nr. 2. Med et helt nyt vurderingsgrundlag for “Bedst på Nettet” kunne mange kommuner, der førhen har triumferet sig vejen til podiet, se sig placeret bagerst i feltet, når der skulle deles statuetter ud - af den simple grund, at “Bedst på nettet” i 2009 har handlet om organisatoriske forankring, og hermed også om nytteværdi. Der er simpelthen for mange kommuner, der har sovet i timen. På trods af at det videnskabelige fundament i en sammenligning mellem 700 vidt forskellige webløsninger, som “Bedst på nettet” blandt andet tager udgangspunkt i, kan ligge på et meget lille sted, så tager jeg hatten af for denne kovendning. Hvor “Best på nettet” de tidligere år, har været baseret på en kvantitativ undersøgelse baseret på et fælles spørgeskema til alle brugere på tværs af de 700 vidt forskellige webløsninger, og en underlig, forældet vurdering af den teknologiske platform, så er årets duks, en selvevaluering baseret på de offentlige myndigheders organisatoriske og strategiske arbejde med webløsningerne, som sød musik og går direkte i hjertet på en Handelshøjskoledreng som mig.

Men at lave ordentlige Business Cases og ROI analyse er heller ikke just en nem øvelse. En investering kan kan have meget kort time-to-market (den tid det tager for at gennemføre projektet), men lang time-to-value (den tid det tager før at projektets output skaber værdi). Derfor er det ikke altid lige nemt at estimere nytteværdien. Jeg har dog forsøgt at stille en række spørgsmål i vilkårlig rækkefølge, som en Business Case, der dokumenterer nytteværdi i et webudviklingsprojekt, efter min mening, bør besvare:

1. Hvorfor er projektet nødvendigt? Hvilken given opgave skal projektet løfte og hvorfor er det vigtigt at gennemføre projektet? Skal projektet f.eks. effektivisere processer og work flows, være med til at nedbringe driftsomkostninger, forbedre borgernes opfattelse af kommunen, forbedre servicekvaliteten eller noget helt andet?
2. Hvilke optioner er til stede? Er der forskellige muligheder for at gennemføre projektet? Er der forskellige systemer, som kan løfte opgaven og hvad er alternativerne til disse? Eller er der et alternativ til projektet? Hvad betyder det, hvis ikke projektet bliver gennemført? Jeg oplever desværre ofte at systemvalget foretages først og så skabes projektet rundt om det – i min optik er det helt klart den anden vej rundt.

3. Hvilke synlige fordele forventes af projektet? Hvilke konkrete, målbare resultater skal komme ud af projektet? Hvis projektet skal flytte henvendelser til kommunen fra analoge til digitale medier, kan dette ekspliciteres som en andel af månedlige borgerhenvendelser. F.eks. at projektet skal flytte 500 henvendelser om måneden fra analoge til digitale medier. Dette vil give kommunen en synlig økonomisk besparelse, da analoge henvendelser alt andet lige er mere omkostningstunge end digitale. Dette kan eventuelt danne præcedens for efterfølgende KPI’er. Læs desuden blogindlægget “Sådan måler man om en offentlig hjemmeside har succes!” om hvordan man arbejder med KPI’er for hjemmesider i offentligt regi, som jeg tidligere har skrevet.

4. Hvornår kan vi begynde at se synlige resultater? Hvornår forventer vi at have gennemført projektet (time-to-market) og hvornår forventer vi at de synlige fordele begynder at manifestere sig som værdiskabende (time-to-value)? Det er fint nok at projektet hurtigt kan gennemføres, men hvis vi først oplever fordelene om ti år, er det så realistisk at gennemføre projektet? Jeg oplever desværre også projekter, som har potentiale til at skabe stor nytteværdi, men da gennemførelsesomkostningerne (se nedenfor) er meget høje, så vil nytteværdien først vise sig om rigtigt mange år. Er et sådant projekt rentabelt at gennemføre?

5. Hvilke omkostninger er der i forbindelse med projektet? Hvad koster det i kroner og ører at gennemføre projektet? Og nok ligeså vigtigt, hvad koster den efterfølgende drift? Det kan være fint at etablere et intranet, der optimerer kommunens work flows, men hvis de efterfølgende driftsomkostninger er så høje, at de to ting udligner, eller omkostningerne ligefrem overgår fordelene, hvad er så formålet? Hvad koster projektet i mandetimer, samt frustrationer og lavere produktivitet hos medarbejderne pga. ændrede arbejdsgange indtil time-to-value, uddannelse af medarbejderne og eventuelle systemnedbrud pga. løsningens kompleksitet?

6. Hvordan er projektet relateret til kommunens overordnede strategi og øvrige projekter? Er projektet i tråd med kommunes projektprogram? Kunne det tænkes at det pågældende projekt ligefrem modstrider nogle af de øvrige eller at det ligefrem er redundant?

7. Hvilke risici er forbundet med projektet? Især indenfor webudviklingsprojekter kan antallet af interessenter i projektet skabe risici, der både har høj påvirkelighed for projektets succes, og høj sandsynlighed for at manifestere sig. Interessenterne omfatter både de interne, herunder webgruppen, beslutningstagere, kommunaldirektøren, politikerne, medarbejderne og hvem projektet nu måtte influere på, men i høj grad også eksterne, underforstået leverandøren, borgerne, interesseorganisationer, virksomheder m.fl. Antallet og karakteren af disse kan have evident betydning for projektgennemførelsen. Risikoanalysen bør derfor identificere de mest sandsynlige og mest påvirkelige risici.

Det er ikke betydningsfuldt at der skrives side op og side ned. Business Casen skal jo også læses og godkendes eller forkastes. Og det er lige nøjagtigt det, som Business Casen skal gøre! Den skal danne grundlag for en beslutning. En konkret vurdering af om projektet er fornuftigt at gennemføre eller ej. Jeg vil faktisk gå så langt, som at påstå, at man hellere bør gå glip af gennemførelsen af et godt projekt, end at få gennemført et dårligt.

Er kravspecifikationen virkelig død?

Nej! Gu’ er den ej! Jeg er ved at være træt af at læse blogindlæg på blogindlæg om agile metoder, der konkluderer at kravspecifikationen er fortiden til. Intet kan være mere forkert!
Dette lyder nok som et rimeligt surt fredagsopstød ovenpå en nat, hvor min datter har holdt sine forældre løbende orienteret omkring nattens eskapader fra sin seng i det tilstødende børneværelse, når de helst gerne bare vil sove. En hård juleperiode er i vente, ikke blot på grund af det årlige panikgaveræs, snestorm og familietamtam hos tante tut, men også fordi at der både er store projekter skal afleveres og store projekter er ved at blive opstartet. Når jeg så læser, at kravspecifikationen er død og borte, til fordel for agile metoder, ja, så har jeg svært ved at holde igen.
Jeg vil gerne forklare mit synspunkt herunder. Det hører sjældenhederne til, at kunden ikke gerne vil kende en smule til økonomien i et projekt inden opstart. Ja, faktisk, har jeg ikke mødt en kunde endnu, der ikke har spurgt “hva’ koster’d?” Jeg tror ikke, at dette er unikt for vores branche, men må være et rimelig generisk og fair krav. Personligt ville jeg nok heller ikke bede en leverandør om bare at gå i gang, og tales ved efter to måneder, når fakturaen kommer dumpende. Kravspecifikationen er yderst vigtig i dette scenario, og her kommer f.eks. SCRUMS product backlog efter min overbevisning desværre til korte.
Jeg havde en snak med en kunde omkring funktionalitet til den kommende hjemmeside. Han havde ikke rigtigt noget fast budget og han havde nogle klare overordnede forventninger til hvad hjemmesiden skal kunne kunne. Et krav gik på at han gerne ville sende et nyhedsbrev til sine kunder pr. e-mail. Et meget basalt krav, som mange hjemmesider understøtter. Men skal nyhedsbrevet også kunne sendes pr. SMS? Skal han kunne vedhæftet en fil? Skal han kunne opdele modtagerne i segmenter, så han kan sende forkellige nyhedsbreve al efter hvilke karakteristika modtageren har? Skal nyhedsbrevet sendes som PLAIN TEXT eller skal det være HTML, så det kan have et visuelt udtryk? Svarene var nej, ja, ja og ja. Denne løsning giver én økonomi, men havde svarene været ja, nej, ja, nej, så havde økonomien været en anden. Desuden giver kravspecifikationen en forventning om hvad nyhedsbrevet kan, _inden_ udviklerne går i gang. Kundens røde lamper vil straks lyse, hvis han havde en klar forventning om, at han skulle kunne vedhæfte et PDF dokument til sit nyhedsbrev, og ikke kan det efter implementeringen. Derfor kan kunden forholde sig til den økonomi han har fået første gang, og skal ikke vente på ubehageligheder, når vi først efterfølgende finder ud af, at han også har et behov for at vedhæfte PDF dokumenter. Samtidigt er der en klar forventning, leverandør og kunde imellem, om hvad kunden får for den estimerede økonomi.
For at jeg kan estimere en økonomi, skal jeg kende alle projektets omstændigheder – ergo skal ubekendte og risici minimeres, for ellers kan jeg komme til at under- eller overestimere og projektet går ikke op. Underestimerer jeg bærer jeg en risiko, hvilket betyder at jeg må gå på kompromis med kvalitet for at holde mig indenfor økonomien. Overestimerer jeg betaler kunden for meget i forhold til hvad han får af værdi. Samtidigt kan jeg skitsere en forkert løsningsmodel, der ikke tilfredsstiler kundens reelle behov. Og det er er værre, end at projektet ikke går op. Dette afhjælpes ved at skrive en fyldestgørende kravspecifikation, hvor hvert eneste krav til hjemmesiden er specificeret entydigt og konkret. Jeg er tilhænger af planlægning og mener ikke at udviklingsmodeller, som QADAD (Quick-and-Dirty-Application-Development) eller CAF (Code-and-Fix) afføder stabile eller særligt kvalitetsorienterede løsninger – giver det ikke lidt sig selv? Desværre kan SCRUM hurtigt blive QADAD eller CAF, da analysefasen begrænser sig til en product backlog, der udetaljeret skitserer løsningens overordnende design. Misforstå mig ikke, dette har også sine helt klare fordele i visse situationer, som jeg nok skal komme ind på i et fremtidigt blogindlæg. Men man har tendens til at kaste sig over tastaturet og kode derudaf. Det kan også være fint nok i nogle situationer, men hvis ikke kunden føler sig særlig hjemme i SCRUM eller har erfaring med systemudvikling generelt, så er det traditionelle paradigme og kravspecifikation at foretrække.
Kravspecifikationen giver altså en mere detaljeret estimering af projektets samlede omkostninger (Total Cost of Acquisition). Den giver også en forventning om hvad projektet ender ud med. Og dette gør at kunden nemmere kan vurdere projektet i forhold til dets Business Case. Giver projektet derfor overhovedet mening at gennemføre? Ved de agile metoder ved man først dette, når man står på den anden side, da man først kender projektets leverancer, når det er gennemført. Det er ikke særligt forretningsorienteret, vel? Agilitet er godt i projekter, hvor vi ikke har klare forventninger til funktionalitet og ikke kender vores behov. Det er lige nøjagtigt her, at de agile metoder kommer til sin rette.
Når ressourcerne bruges til at skrive en kravspecifikation, så sikrer dette også en mere lean proces. Flaskehalse elimineres, da afklaringer holdes på et minimum. Jeg lærte i skolen, at kravspecifikationen bør sikre at alle afklaringer omkring funktionalitet er gjort på forhånd, således at udviklerne har en madopskrift de kan følge – punkt for punkt. Dette holder nok i teorien, men i praksis er det ikke muligt. Kravspecifikationen vil altid have mangler – jeg tror ikke på, at du kan få alt med. Onde tunger vil her sige, at SCRUM netop sikrer, at kunden har mulighed for at tage stilling til krav løbende. Ja, ja, men det kan man jo også ved at udvikle traditionelt! Ved kravspecifikationen er der blot markant færre ting der skal afklares med kunden løbende, hvilket gør selve konstruktionsfasen væsentligt kortere og mere strømlinet.
Desuden sikrer kravspecifikationen et testgrundlag, da man binært kan angive “1” ved krav der er opfyldt, og “0” ved krav, der ikke er opfyldt. Ergo kan kvaliteten i højere grad sikres. Langt størstedelen af de webprojekter der igangsættes i Danmark er af så kort varighed (hvilket er under 6 måneder), at kundens situation eller krav næppe når at ændre sig betydeligt. Ofte opdeles projekterne alligevel i iterationer med selvstændige kravspecifikationer.
Så hvad kan vi lære af dette? Kravspecifikationen er ikke død! Kravspecifikationen lever i bedste velgående og aflives næppe af de agile metoder. Kravspecifikationen er et vigtigt element i ethvert forretningsorienteret webprojekt. Den synliggør økonomi, projektleverancer og skaber fælles forventninger mellem kunde og leverandør. Kravspecifikationen er til nytte både for kunden, projektlederen og udvikleren.

Aabenraa Kommune får ny hjemmeside

Så kom dagen, hvor Aabenraa Kommune lancerer ny hjemmeside.

Læs mere på http://www.skybrud.dk/blog/post/Aabenraa-Kommune-far-ny-hjemmeside.aspx

Sådan måler man om en offentlig hjemmeside har succes

Jeg har på Skybrud.dk skrevet et blogindlæg om hvordan kommuner og offentlige myndigheder kan måle hvorvidt deres hjemmeside har succes. Jeg fokuserer meget på brugen af OKR'er og KPI'er.

Læs det fulde indlæg på Skybrud.dk/blog

Indlægget er skrevet efter inspiration fra Avanish Kaushik, Google's Analytics evangalist, som har skrevet et indlæg om hvordan offentlige myndigheder kan lave webanalyse.