fredag den 18. marts 2011

Værktøjer til samarbejde mellem it og kommunikation

Mangler du værktøjer til at få en it afdeling og en kommunikationsafdeling til at arbejde bedre sammen om online projekter? Så kan du måske bruge mine ideer til Håndbog for Samarbejdet og Samarbejdsmatricen, som jeg præsenterer nedenfor. Ideer og input er meget velkomne.

Hvem har ansvaret for online projekter

En organisations online tilstedeværelse ejes ofte i en kommunikationsafdeling eller en HR afdeling, der taler et helt andet sprog end it afdelingen. Det kan naturligvis give en del gnidninger, når det skal besluttes, hvilken afdeling der har ansvaret for at levere eller indkøbe løsningen til et nyt online projekt.

Håndbog for samarbejdet

Derfor kan et godt første skridt på vejen være at oprette en fælles håndbog for samarbejde, hvor de to afdelinger kan dele forskellige opfattelser af ord, efterhånden som de dukker op. Håndbogen er efter min opfattelse både et praktisk arbejdsværktøj og en god måde for de to afdelinger at huske på, at der er kulturforskelle, der skal overvindes

Et eksempel fra min egen hverdag: En IT afdeling, skulle programmere et selvstændigt video site. Kommunikationsafdelingen ville gerne ind over i forhold til, hvordan det skulle se ud. I løbet af opstartsmødet opstod der imidlertid en del forvirring, fordi begge afdelinger mente, at det var deres opgave at stå for punktet "præsentation". Forklaringen var naturligvis, at de to afdelinger forstod noget forskelligt ved "præsentation", nemlig i it afdelingens verden: Hvilke af systemets mange data, der skal præsenteres; og i kommunikationsafdelingens optik: Hvordan siden som dataene vises på, skal se ud (layout / webdesign osv.).

Eksempel - Håndbog for samarbejde

Ord: Præsentation
ITs forklaring: Data output og filtrering, så de rette og evnt. ikke alle vises på side
Kommunikations forklaring: Layout, hvordan indholdet på en side visuelt ser ud, brug af grafiske elementer mv.

Ord: Prototype
ITs forklaring: Tegning / beskrivelse / diagram, der beskriver workflowet mellem system og menneske i forbindelse med løsning af en opgave
Kommunikations forklaring: Tegning der visualiserer brugergrænsefladen for et givent system i forbindelse med fx knapstørrelse, knapplacering m.v.

Samarbejdsmatricen

Eksemplet ovenfor affødte også diskussion om, hvad der hører til hvor, altså hvilken afdeling der var ansvarlig for hvilke typer udviklingsopgaver.

Dette problem løste afdelingerne sammen ved at lave et skema, en samarbejdsmatrice over, hvad der var hver af de to afdelingers hovedfokus, hvor de gerne ville have indflydelse, og hvor afdelingernes fokus overlappede.




Mapning af konkrete projekt

Da der først var enighed om modellen, fylde afdelingerne et par eksempler på systemer i modellen for at skabe en fælles konkret opfattelse af, hvem der havde ansvaret for et udviklingsprojekt alt efter, hvad det var for et eller flere eksterende eller potentielle systemer, projektet involverede.

Eksempel:

Projekt: "Find person" funktion på hjemmesiden
Involverede systemer: CMS, Personaleafdelingens persondatabase
Data afhængighed: Begrænset
Målgruppe: primær målgruppe 1+2, sekundær målgruppe
Placering i matrice: A2 - kandidat til samarbejdsprojekt

Kompleksitetsmodel

Modellen blev suppleret af en anden model, der skitserer hvilken type løsning, et givent samarbejdsprojekt skal arbejde mod, afhængig af kompleksitet.


Hvis vi igen kigger på eksemplet ovenfor, skal der laves noget, der kan læse data fra en person database og vise det på hjemmeside. Det vil sige, at det er et projekt med lav kompleksitet, der derfor skal løses ved, at it afdelingen laver en webservice, der leverer data til CMSet, hvor kommunikationsafdelingen står for dataens udseende.

søndag den 2. januar 2011

AGILE og SCRUM for små webteams - introduktion

Hvis du er en del af et lille webteam på 2-4 personer og for nylig har været i kontakt med et konsulenthus, har du sikkert hørt om agil udvikling og SCRUM. Og hvis konsulenthuset holdt en god præsentation, spørger du sikkert dig selv, om SCRUM og agil udvikling er noget for jer.

Det vil jeg se nærmere på i denne Agil/SCRUM føljeton hvor jeg vil gå i dybden med et par metodiske guldkorn og dele ud af mine egne erfaringer fra hverdagens slagmark.
For at skyde blogføljetonen godt i gang, vil jeg starte med en kort introduktion til SCRUM som jeg forstår det.

Introduktion til SCRUM og agil udvikling
SCRUM og Agil udvikling er det seneste skud på stammen hos mange konsulenthusene. Agil udvikling er en overordnet beskrivelse for en række fleksible måder at udvikle software på, og SCRUM, som er meget på mode for øjeblikket, er en af de forskellige agile varianter.

Kernen i SCRUM udvikling er gensidig tillid, tæt samarbejde og plads til justering efterhånden som konsulenthus og kunde bliver klogere på projektet. Ideen er, at kunde og fx konsulenthusets tekniske projektleder ved starten af et projekt lader være med at specificere i detaljer, men i stedet koncentrerer sig om den fælles vision som projektet skal virkeliggøre, den værdi som projektet skal skabe for kunden. Denne vision omsættes ved projekt start til en række overordnede fortællinger (Epics), der vil kunne virkeliggøre visionen.

Selve projektet består herefter af en række udviklingscyklusser (Sprints). Ved indledningen af hvert sprint præciserer kunde og udviklerteam den eller de epics, der skal arbejdes med i dette og det kommende sprint i form af en række brugerhistorier, User Stories. Forskellen mellem epics og user stories er, at epics er løst definerede overordnede beskrivelser, mens user stories er mere detaljerede specifikationer.

Det er lidt et spørgsmål om overbevisning, hvor detaljet en user story skal være. Nogle mener, at hver enkelt user story kun må beskrive én handling for én bestemt brugertype. Andre bruger user stories til at beskrive, hvordan en given user får et givent behov opfyldt (det betyder, at en user story godt kan omfatte flere handlinger). Andre igen bruger som rettesnor, at opfyldelsen af en user story bør tage 4-8 timers udvikling, eller at en user story skal kunne skrives på en post-it.

Den bedste anbefaling er nok at eksperimentere sig lidt frem. Uanset hvordan I definerer jeres user stories, er det vigtigt altid at beskrive klart, hvilken type bruger, historien handler om (altså fx ”som webredaktør vil jeg gerne kunne...), og at det entydigt kan bekræftes, om historien er opfyldt eller ej.

En epic kan for eksempel være, at jeg som kunde i eshop X gerne vil kunne sende en besked til eshoppen. For denne epic kunne user story’erne være, at jeg som bruger gerne vil kunne a) vælge en kategori for henvendelsen, b) indtaste en tekst, c) rette i min tekst, d) slette min tekst, e) se teksten, inden jeg sender den, og f) kunne sende teksten, når jeg er tilfreds med den. Når user story’erne er besluttet, nedbryder udviklerne dette sprints user stories til en række opgaver (tasks) som fx at opsætte en mailserver, lave en formular med felterne x, y, z osv.

Samtidig med formuleringen af user stories aftaler kunde og udviklerteamet klare verificerbare kriterier for, hvornår en user story er opfyldt. Herefter går udviklerne i gang med at udføre opgaverne. Når opgaverne i en user story er gennemført, demonstrerer udviklerne for kunden, at user story’en opfylder de aftalte krav, og kunden ser på denne måde, hvordan projektet løbende akkumulerer resultater, indtil den samlede sum af resultater virkeliggør visionen.

Hvorfor SCRUM
Gevinsten ved at bruge SCRUM i webprojekter for kunde og konsulenthus er, at man løbende forventningsafstemmer og godkender, og dermed minimerer risikoen for graverende misforståelser og uenigheder. Samtidig sikrer SCRUM, at man kun bruger et minimum af tid på at at specificere opgaver, der ender med at blive droppet, og ikke spilder tid på at specificere opgaver tidligt i et projekt, for derefter at være nødt til at specificere dem igen, når de skal løses, fordi de i mellemtiden er blevet radikalt omdefineret i forhold til den gang, man specificerede dem.

Mange af disse gevinster kan også opnås, hvis der er tale om et webteam og teamets interne kunder, i stedet for en kunde og et konsulenthus. Men det er ikke alle, eftersom SCRUM er indrettet efter projekter på omkring 6 måneders varighed, hvor hvert sprint er ca. 3 uger.

Derfor vil jeg i de efterfølgende indlæg præsentere mine udvalgte SCRUM guldkorn, som kan bruges i små teams på et par personer, og mine egne erfaringer med dem. For at skabe lidt forventnings-hype kan jeg løfte en flig af sløret for emnerne i de kommende posts: ikke-funktionelle krav, KANO modellen, estimering og just-in-time beskrivelser.

Inspiration og videre læsning
Dette indlæg er inspireret af Roman Pichlers bog ”Agile Product Management with SCUM – Creating Products that Customers Love”.

mandag den 22. november 2010

Den gode CMS implementering

Det kan være svært at gennemskue, hvad det omfatter at få implementeret et nyt CMS, hvis du står overfor din første implementering. Hvad skal vi sørge for at sikre os, at leverandøren har styr på og har tænkt med i projektplanen, og hvor gemmer de store faldgruber sig? Hvilke beslutninger skal vi begynde at overveje, hvilke oplysninger har vi brug for at samle ind?

Forvirringen er sådan set meget naturlig. CMS teknologien er relativt ny set i forhold til fx styresystemer til personlige computere, og modenheden blandt konsulenter, på grund af stor udskiftning i branchen, og kunder er endnu ikke så stor.
Samtidig gør de mange koblinger mellem CMS og andre interne it systemer og arbejdsgange, at hver implementering er en unik kombination, som leverandøren ikke har prøver før. Det betyder naturligvis, at mange af problemerne også nye for leverandøren, til stor frustration for både kunde og leverandør.

Derfor sker det alt for ofte, at CMS projekter trækker ud, fordyrres eller får et resultat, der ikke lever op til forventningerne på et eller flere punkter.

Men CMS projekter er jo ikke de eneste it projekter, der involverer customiseringer, og selvom hvert projekt er unikt, er der trods alt også en del fællestræk: Elementer, som er med i de fleste projekter, og problemer som går igen projekt efter projekt.
Men det er som om, de involverede endnu ikke har haft tid og overskud til at systematisere deres erfaringer og lære af dem.

Derfor er der akut brug for et fælles overblik over CMS projekter, som kunder og leverandører kan bruge til at støtte hinanden i at komme sikkert over på den anden side.

Oversigten nedenfor er i al beskedenhed et forsøg på i korte træk at give det overblik, baseret på egne og andre projektlederes erfaringer gennem de seneste par år.

Projektleder hovedfokus
Den gyldne trekant:
- Tid (projektplan, fremdrift, deadlines)
- Kvalitet (test og godkendelse)
- Ressourcer (allokering af kompetencer, budgetstyring)

Trekantens centrum
- Scope (-slide)
- Risici
- Intern opbakning til projektet

Generisk projektplan
- Etablering af projektorganisation
- Foranalyse
- Aftaleindgåelse
- Opstart af særligt risikobehæftede aktiviteter
- Implementering af basissite og specialudviklinger: Iterative forløb bestånde af udvikling, tests og deploys
- Supportaftale indgåes
- Roadmap for videreudvikling
- Overdragelse

Etablering af projektorganisation
- Projektrammer (mandater, mødefrekvens mv.)
- Kommunikation i projektet (statusrapportering mv.)
- Change management (issue håndtering, plan for escalering)
- Test & deploy strategi

Foranalyse
Præcisering af strategiske behov:
- Forretningsanalyse (USP - unique selling points, KPI - key performance indicators, ROI - return on investments, projektets relation til diverse strategier)
- Målgruppeanalyse (præferencer og særlige krav)
- Interessentanalyse (fx workshop om forventninger)
- Konkurrentanalyse (SWOT, konkurrenternes websites)

Præcisering af konkrete behov:
- Hosting (krav, leverandørvalg)
- Kundens tekniske miljø (hvilken hardware og software benytter kundens redaktører, administratorer og udviklere, og hvad giver det af begrænsninger / udfordringer)
- Sikkerhedskrav (https, adgang til backend hjemmefra, særlige krav)
- Forventet antal besøgende, redaktører og sites (i forhold til load på frontend og backend samt evnt. licenser)
- Skalerbarhed (CMS og serverkapacitet)
- Platforme CMSet skal kunne føde til (mobil, Facebook, infostandere, storskærme mv.)
- Oplæring (hvor mange, hvilke brugertyper, tekniske forudsætninger)

Aftaleindgåelse
- Projektmål, work breakdown structure og/eller idekatalog (begge kan bruges ved prioritering og scope styring)
- Risikovurdering
- Endelig aftale om scope og kravspecifikation
- User Story formulering og prioritering, etablering af backlog
- projektplan og bemanding

Særligt risikobehæftede aktiviteter
- Integrationer
- Migrering
- Specialudviklinger
- indholdsproduktion (primært for nye sites)

Særligt til kunde-projektledere
I tilgift til ovenstående er det en rigtig god ide på forhånd at overveje, hvordan verden vil se ud efter jeres implementeringen, og få ledelsen til at afsætte budget og ressourcer til at realisere ig understøtte ny tiltag son fx at producere eller oversætte tekst til nye områder på websitet eller til at kunne virkeliggøre nogle af de ideer, I undervejs kommer til at udsætte til efter selve implementeringen, eller som opstår, når I ser de nye muligheder (det vil der rigtig ofte være behov for, hvis I vil hente den gevindst ind, som retfærdiggjorde investeringen i et nyt CMS).

Hvis du vil vide mere:
- Richard Newton, "Project Management, step by step"
- Hans Mikkelsen, "Grundbog i projektledelse"
- John P. Cotter, "Leading Change"
- Russel Nakano, "Web Content Management, a collaborative approach"
- Ashley Friedlein, "Web Project Management - delivering succesfull commercial websites"
- Bob Boiko, "Content Management Bible"
- Ken Schwaber & Mike Beedle, "Agile Software Developments with Scrum"
- Roman Pilcher, "Agile Product Management with Scrum, creating products that customers love"

Disclaimer: Oversigten er baseret på mine egne erfaringer som projektleder på IT-Universitetet af en CMS implementering til hjemmeside og intranet, interviews af andre projektledere i forbindelse med rapporten "CMS implementering - erfaringer og anbefalinger" og en række uformelle samtaler med andre projektledere i samme situation.

onsdag den 17. november 2010

Hvilket CMS skal man vælge

Jonas Heide Smith har for nylig blogget en interessant omend lidt frustretet anmeldelse af Sitecore CMS: http://jonassmith.dk/weblog/sitecore-en-anmeldelse/

Diskussionen fortsætter på Ask Hybels blog, hvor jeg har skrevet en kommentar om udfordringerne i at vælge det rigtige CMS: http://www.askhybel.dk/2010/08/undervisning-i-sitecore-cms/