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.

PRINCE2 giver bedre struktur, 2. del

De første par måneders intens projektarbejde funderet i PRINCE2 projektledelsesmetoden er nu ved at være overstået, og det er tid til en status.
Jeg har forsøgt at gøre mere og mere brug af PRINCE2's tilgang til projektledelse i det daglige arbejde med vores design- og udviklingsprojekter. Hermed har vores implementering af processerne været ret evolutionær, men det har givet os bedre mulighed for at lære metoden i et tempo vi kan følge med i.

Den nye projektledelsesmetode har betydet forandring for hele Skybrud.dk - ikke blot i projektledelsesafdelingen, men også blandt digitale designere, udviklere og hos ledelsen. Alle er med på den og kan efterhånden se meningen med tilgangen og værktøjerne. Det er rigtigt rart. Det virker til at alle kan drage nytte af de nye tiltag. Den menneskelige faktor er som oftest den største udfordring i enhver forandringsproces, men i dette tilfælde må Skybrud.dk helt klart være en undtagelse.

Den produktorientation, som PRINCE2 anbefaler, betyder at vi er begyndt at komme hele vejen rundt om det som vi sidder og laver. Ved at nedbryde projektet i produkter, altså det som vi leverer, i stedet for de aktiviter der er forbundet med at lave en hjemmeside, har vi lært, at kortlægge henholdsvis de mange sidelayouts og funktioner, som hjemmesiden kommer til at bestå af. PRINCE2 giver ikke nogle konkrete retningslinjer for nivauet, så vi har måtte finde vores eget.

At gå fra aktivitetsbaseret projektledelse, som vi hidtil har gjort, til produktorienteret, giver os for det første et bedre fundament for at kunne rådgive vores kunder, da vi kender projekterne bedre fra start. For det andet giver det os et bedre fundament for estimering af projektets samlede økonomi. Hermed får kunden en mere nøjagtig økonomi, hvilket gør at vi ikke behøver at tage højde en masse ubekendte, som trækker prisen op. Konkret betyder dette, at vi kan sætte økonomi på et lavere abstraktionsniveau. Vi kan nu bedre forholde os til hvad helt specifikke funktioner koster, i stedet for at angive en overordnet økonomi for designydelser og programmeringsydelser. Kravspecifikationen er også blevet vendt på hovedet, da vi nu kravspecificerer i slutprodukter i stedet for i moduler eller rene funktioner. Forskellen er blot, at vi ikke længere angiver funktionalitet selvstændigt, men distribuerer dem ud på de mange sidelayouts. For det tredje betyder dette, at vi internt får en mere strømlinet arbejdesproces. Når vi kravspecificerer i produkter fremfor moduler, giver dette vores digitale designere og udviklere en tjekliste over funktionalitet på de enkelte sidelayouts. Sat på spidsen kan de nu fra start bedre vide, hvad forsiden skal indeholde, undersiderne, webshoppens produktvisningssider, webshoppens betalingsprocedure og billedgalleriets visningsmuligheder. Dette gør at projektlederen ikke skal inddrages i det daglige arbejde på samme høje niveau, som før, men blot kan reduceres til et ugentligt statusmøde og løbende afklaringer. For kunden betyder dette bedre kvalitet og en opfyldelse af de reelle behov. Desuden giver det en reduktion i fakturerede projektledelsestimer og dermed en besparelse.

Jeg har også taget hul på PRINCE2's tilgang til projektplanen. PRINCE2 tager udgangspunkt i projektets Business Case, altså formålet med projektet og det som organisationen gerne vil opnå med projektet. Det kan være omkostningsminimeringer, salgsoptimering, branding mv. Projektplanen tager sit afsæt i denne og dokumenterer hvordan formålet med projektet søges opnået. Produkterne nedbrydes i en produktnedbrydningsstruktur, der er et hierarki over produkterne, samt en produkt flow struktur, der angiver i hvilken rækkefølge produkterne leveres. Vi har valgt at nedbryde en hjemmeside i sidelayouts ud fra kravspecifikationen. Dette giver ikke blot et bedre afsæt for at lave tidsplanen, men giver også en forventning om hvornår kunden kan igangsætte sine egne aktiviteter. Jeg har den fornøjelse at arbejde på vores store kommunale udviklingsprojekter. Det er tunge projekter, som kræver et meget forkromet overblik og en skarp planlægning og styring. Ofte skal kommunens portalledere og -webmastere lave intern undervisning af indholdsredaktører og migrere indhold fra den gamle portal til den nye, mens vi stadigvæk udvikler på portalen. Dette kræver sin koordineringsindsats! Her kommer produkt flow strukturen til sin rette, da vi bedre kan integrere vores tidsplan med kundens. Projektplanen indeholder desuden forventninger til budget og tidsramme, samt de aftalte tolerancer i begge.

Vi er kommet et godt stykke videre med implementeringen af PRINCE2. Hidtil har det kun betydet klare fremskridt i vores interne processer.

Odense Kommune får ny jobportal

Odense Kommune har netop lanceret ny jobportal for at forbedre tiltrækningen af arbejdskraft til kommune. Vi har ageret designbureau og foretaget det digitale design. Jobportalen er en del af et samlet employer branding-projekt initieret af kommunen. Formålet er at bekræfte nogle af de gode myter om kommunalt arbejde, og aflive de forkerte. Hertil er vores gode ven, Aakjærs, blevet hidkaldt til at agere primusmotor på det samlede projekt.

Projektet var atypisk i forhold til vores normale proces. Vi var blot en mindre del af det samlede projekt, hvor vi sædvanligvis ofte står på toppen af pyramiden. Derfor har der været mange andre aktører i spil end os. Dette har både gjort processen mere langhåret, men har omvendt også givet os mere af det på brystet. Jobportalen blev implementeret af kommunens sædvanlige implementeringspartner, Oxygen Software, mens portalplatformen bygger på en kombination af content management systemet Sitecore og Stepstone, der har leveret rekrutteringsmotoren. Dette projekt har bevidnet, at på trods af at man til dagligt konkurrerer om samme kundegrundlag, så kan processen godt fungerer. Samarbejdet mellem os og Oxygen Software har været stærkt, ikke blot for vores egen læring, men i højere grad for Odense Kommune. Dette har helt klart været gavnligt for projektet, og skabt et helstøbt slutprodukt! Tak for hidtil godt samarbejde!

Den nye jobportal omfatter foruden rekrutteringsmodulet også omfattende information omkring Odense Kommune som arbejdsplads. I den forbindelse har vi sammen med Aakjærs skabt en ambassadørvideovisning, hvor jobansøgerne og brugerne generelt kan stille spørgsmål til udvalgte medarbejdere fra kommunen.

Du kan besøge Odense Kommunes nye jobportal på odense.dk/job.

Strategi for den indholdsdrevne hjemmeside

Den indholdsdrevne hjemmeside er kendetegnet ved at levere indhold i form af billeder, tekst og video til brugerne. En indholdsdreven hjemmeside kan for eksempel være nyhedssider, kommuneportaler og corporate websites, hvor fokus er på information og videndeling. Jeg oplever dog tit, at folk løber panden mod muren, når strategien skal lægges for den indholdsdrevne hjemmeside. Det er nemlig alt andet lige meget nemmere, at lægge strategi for den transaktionsdrevne hjemmeside, som er kendetegnet ved salg af produkter og tjenesteydelser gennem det elektroniske medie - for eksempel webshops. Fokus er jo salg - og samtidigt er kroner og øre er noget nemmere at måle på end det abstrakte indholdskoncept. Derfor kan det være en svær øvelse at beslutte hvad der er, man skal fokusere på, når man ikke tilbyder varer fra hjemmesiden, men tilbyder information.

Så hvad nu? Hvordan skal strategien lyde for den indholdsdrevne hjemmeside? Umiddelbart er der tre vigtige aspekter for strategien – 1) vækst i trafik, 2) loyalitet og 3) engagement.
Vækst i trafik tager udgangspunkt i at tiltrække brugere til hjemmesiden - altså opfordre brugerne til at besøge hjemmesiden. Men det er ikke nok at tiltrække dem, hjemmesidens indhold skal tilføre værdi i et sådant omfang, at brugerne returnerer af sig selv igen. Dette skaber loyaliteten. Ultimativ leder dette til engagement, hvorved brugerne konsumerer og bruger hjemmesidens indhold til at løfte en given opgave. For en kommuneportal kan det være at en borger bruger specifik information fra en given underside til at holde sig orienteret omkring lokalplaner. For den private virksomhed kan det være en forhandler, som holder sig orienteret omkring priser, for at kunne lægge sin avance og egne priser. Denne sekventielle tilgang, hvor man først søger at tiltrække brugerne, dernæst skabe loyalitet, så de kommer igen, for til sidst at engagere dem, er den traditionelle. Jeg anbefaler dog at vende rækkefølgen på hovedet!

Det er stadigvæk vigtigt, at skabe vækst i trafikken så, så mange brugere som muligt får adgang til indholdet. Det er egentligt ikke unikt for den indholdsdrevne hjemmeside, og er jo ligeså vigtigt for den transaktionsdrevne. Det er også vigtigt, at få dem til at returnere og engagere sig. MEN, når først brugerne har besøgt hjemmesiden er de mærket for livet - det er førstehåndsindtrykket der afgør om folk vender tilbage. Derfor er det vigtigt først at skabe en hjemmeside, som engagerer brugerne til at bruge indholdet. Dette skaber naturligt en loyalitet, der gør at folk returnerer til hjemmesiden, for at bruge indholdet igen. Når først hjemmesiden har det niveau, hvor brugerne er engagerede og loyale, så skal den brede skare af brugere tiltrækkes til hjemmesiden. Ellers er det lidt som at hælde vand i en si – den bliver aldrig fyldt op, da vandet løber gennem hullerne. Dine brugere kommer ind på hjemmesiden, men de bliver skuffede og finder måske ikke det de leder efter. Gør de ikke dette, engageres de ikke, og bliver slet ikke loyale.

Denne strategi kræver dog tålmodighed, for antallet af brugere vil være lavt qua den manglende vækst i antallet af nye brugere. Men tålmodigheden belønner sig i det lange løb. Jeg har desværre tit oplevet webmastere og ledere, både i det offentlige og private, der offentliggører nye hjemmesider uden at have skabt indhold, der engagerer. Dette gør at besøgstallet bliver en nedadgående kurve og hjemmesiden ultimativt dør. Hårdt, men sandt.
Derfor, fokusér på at skabe en hjemmeside, hvis indhold engagerer brugerne. Herefter opbygges loyaliteten helt af sig selv. Formår du at skabe dette, skal du tiltrække den bredde masse af brugere.

PRINCE2 giver bedre struktur

Som led i en optimering og strømlining af projektlederafdelingen i Skybrud.dk a/s har jeg kigget nærmere på PRINCE2 projektledelsesmetoden. Jeg stiftede første gang bekendtskab med PRINCE2 under mit kandidatstudie i IT, Kommunikation og Organisation (ITKO) ved Handelshøjskolen i Århus på vores projektledelseskursus. Dengang tillagde jeg ikke metoden den store betydning, da det var sparsomt hvor dybdegående vi blev introduceret til metoden. Men jo dybere jeg bevæger mig nu, desto mere inspirerende finder jeg metoden.

PRINCE2 er produktorienteret. Det enkelte projekt nedbrydes i en række produkter al efter ønsket detaljeringsniveau. Indtil nu har vi arbejdet aktivitetsorienteret, hvor estimeringen af projekterne, fastlæggelse af projektplan og den løbende projektledelse har været baseret på de aktiviteter som projektet indebærer - altså kort fortalt de design, programmerings og projektledelsesopgaver, som vores designere, udviklere og projektlederer udfører. Ved at vælge produktperspektivet giver dette meget bedre klarhed over hvad projektet skal ende ud med - et sædvanligt projekt ender jo ikke ud med et design, en programmeringsindsats og et projektledelsesforløb, men et corporate website, kampagnesite, kommuneportal, intranet eller lignende. PRINCE2 giver os derfor bedre muligheder for at styre projektet og afrapportere til kunden.

PRINCE2 tager desuden udgangspunkt i projektets Business Case. Dette betyder at for at PRINCE2 skal give effektiv projektledelse og i sidste ende sikre et bedre produkt, så skal vi afklare virksomhedens problemstilling og stille os kritisk for den - hver gang! Skal vi give den bedste rådgivning, skal vi også kende projektets karakter. Det er projektets Business Case, der skal være bannerføre for projektets fremdrift.

Metoden har en meget klart projektprocs, der er fordelt på fem processer: Opstart af projekt, projektetabling, styring af faser, afslutning af faser og afslutning af projekt. Herudover giver PRINCE2 en klar top-down projektorganisation. Dette giver en mere synlig organisation.

Afrapportering er med PRINCE2 også en hel ny verden - i det hele taget projektdokumentation. PRINCE2 omfatter et enormt dokumentationsapparat. Dette kan naturligvis skaleres, og dette gør vi da også fra projekt til projekt. Men som jeg ser formålet med projektdokumentationen, så er dette grundet i erfaringsopsamling og i at gøre tingene på samme måde på tværs af projekterne. Det gør det nemmere at se på tværs af projekter og det gør det nemmere at sammenligne deres resultater - dette gør også estimeringen nemmere, da vi generelt tyer meget til analogimetoden, når vi foretager vores indledende estimeringer.

PRINCE2 skal give os et mere strukturet arbejde med projektledelse og sikre bedre produktkvalitet.

Nyt koncept for Bedst på Nettet

IT- og Telestyrelsen har lanceret et nyt koncept for Bedst på Nettet, der er den årlige kåring af de bedste offentlige hjemmesider. Her er ikke blot tale om nye retningslinjer, men i højere grad et paradigmeskifte. Konceptet er udvidet betragteligt idet, at en stor del af vurderingen nu er lagt på skuldrene af de offentilige institutioner. Konceptet bygger på screening og brugervurdering, som vi kender fra de tidligere år, men det nye består i, at institutionerne nu skal gennemføre en selvevaluering. Der er lagt op til, at hele 50% af vurderingen beror på denne selvvurdering.

Fokus i det nyt koncept er nytteværdien for borgerne ved, at benytte offentlige instutitionernes webløsninger. Derudover lægges der også vægt på, at institutionerne arbejder strategisk med web og, at dette er synlig gennem den organisatoriske struktur. Der er desuden lagt op til, at instutitionernes tilgang til web skal være mere forretningsorienteret end hidtil. Dette vil indgå eksplicit i vurderingen af de enkelte institutioner. Dette tolker jeg som om, at de offentlige institutioner i højere grad skal arbejde visionært med deres web og dermed skabe øget effektivisering.

IT- og Telestyrelsen har i højere grad i denne omgang valgt, at involvere institutionerne i fastlæggelsen af det nye koncept. Der er konceptet et oplæg og det bliver spændende, at følge den nærmeste fremtid, hvor interesserede er inviterede til at komme med kommentarer.

Blog research

Så kom dagen, hvor skridtet blevet taget og jeg fik muligheden for teste blogging. Selvom jeg indtil videre har været tilbageholden med at blogge, da jeg er af den holdning, at blogging kun skal ske med et velovervejet formål, så må jeg også erkende, at få at kunne rådgive, må jeg også have det ind under huden. Derfor er mit formål med blogging, at lære og lege.