Genial användning av Facebook för Ikea

Ikea i Malmö la upp en Facebook-profil för sin butikschef (reklambyrå: Forsman Bodenfors). Där publicerades bilder från visningsrummen i butiken. Den person som först taggade upp en vara med sitt namn vann produkten. Det spred sig naturligtvis enormt snabbt och skapade betydligt mer buzz än bara taggningen av foton.

Bästa stratregi för digital kommunikation hos Socialstyrelsen?

Projektledning och Webbstrategi på Google

Den här bloggen handlar främst om projektledning, webbstrategi och gränslandet däremellan. Projektledning är ett välanvänt begrepp och även webbstrategi börjar bli vanligt. Jag kommer att följa upp hur väl den här bloggen placerar sig på Google för de båda begreppen. Just nu ser det ut så här (google.se, 29 nov 2009):

• "definition of done", plats 7
• "webbstrategi", plats 58
  
• "projektledning", plats 670

Update 2009-12-03:

• "definition of done", plats 6
• "webbstrategi", plats 31
• "projektledning", plats 670

Update 2009-12-10:

• "definition of done", plats 6
• "webbstrategi", plats 24
• "projektledning", plats 78

Update 2009-12-10:

• "definition of done", plats 6
• "webbstrategi", plats 22
• "projektledning", plats 24

Update 2009-12-26:

• "definition of done", plats 5
• "webbstrategi", plats 25
• "projektledning", plats 47

Update 2010-01-08:

• "definition o done", plats 5
• "webbstrategi", plats 23
• "projektledning", plats 45

Update 2010-01-08 (pr5):

• "definition o done", plats 5
• "webbstrategi", plats 23
• "projektledning", plats 16

Update 2010-02-09 (pr5):

• "definition of done", plats 6
• "webbstrategi", plats 19
• "projektledning", plats 68 

Update 2010-03-14 (pr5):

• "definition of done", plats 1
• "webbstrategi", plats 15
• "projektledning", plats 31

Beauvoir, plats n.  2010-01-08 (2010-01-12)

• beauvoir 26 (24)
  
• de beauvoir 23 (24)
  
• simone de beauvoir >200 (>200)
  
• hélène de beauvoir 13 (7)
  
• andra könet >200 (22)
  
• det andra könet 107 (36)

365 Social Media Cases (2010-02-09)(2010-02-16)

• sociala medier 94 (61) (40)
• sociala medier exempel 27 (27) (23)
• exempel sociala medier (27) (24)
• sociala medier case (28) (15)
• case sociala medier (12) (10)
• facebook exempel (25) (28)
• twitter exempel (80) (15)

Slaget om startsidan, ännu fler orsaker

Ännu fler bakomliggande orsaker till att Slaget om startsidan uppstår, de här handlar mer om faktorer som försvårar arbetet med startsidan:

• Tron att allt måste vara klart från början. Slaget om startsidan späs på av att man ofta vill ha en perfekt lösning från början, vilket gör själva arbetsprocessen svår för att hitta en bra balans. Man måste börja nånstans och få ett underlag från riktiga besökare för att kunna utvärdera hur man ska förbättra. 
• Tron att trovärdighet är viktigare än relevans. Detta förtjänar egentligen ett separat inlägg, får återkomma till det senare. Det handlar om att det sker en generell förskjutning av våra värderingar, från den traditionella tilltron till auktoriteter, mot en större tilltro till personliga relationer. Därmed blir det som är relevant för mig viktigare än det som har en trovärdig källa. Ändå 
• Tron att webben sköter sig själv. För att hitta bra lösningar behöver de som jobbar med sakinnehållet vara med hela vägen i projektet. Det finns en tendens att tro att utvecklingen inte är något man behöver bry sig om. Engagemanget från sakkunniga väcks ofta först vid fullbordat faktum och då är möjligheterna att påverka tyvärr små. Engagemanget måste komma tidigit för att lyckas. 
• Tron att allt måste vara med. Många förutsätter att allt innehåll måste vara med och allt måste behandlas med samma prioritet vilket förstås inte är rimligt om man ska skapa något som fungerar. 
• Rädsla att göra fel, förlora kontroll. Man har en alltför perfektionistisk syn på innehållet. Man lämnar inte ifrån sig utkast förrän det är ett "färdigt" material, vilket får till konsekvens att man missar samordningen med annat material. 

Styrning av webbprojekt: Projektstyrning, Effektstyrning, Scrum

Jag har hört några gånger att scrum eller andra agila metoder ersätter mer traditionella projektmetoder som rup, props, eller pps. Det stämmer nog till 90%, många delar i traditionell metodik går bort när man använder scrum. Men en övergripande projektstyrning utöver scrum behövs fortfarande. Jag ser tre nivåer av styrning av webbprojekt:

1. Projektstyrningen fokuserar på att definiera projektets ramar. Istället för en regelrätt projektplan handlar det mer om en "projektdefinition" eller ett "projektupplägg". Dels behöver milstolpar beslutas, som till exempel "Projektdirektiv godkänt", "Förstudie genomförd", "Teamet på plats", "Utvecklingsstopp" eller "Lansering". Dels behöver till exempel en riskanalys och intressentanalys tas fram. Inom projektstyrning lägger jag också att etablera arbetssätt gentemot projektets styrgrupp, det vill säga till exempel förankra att vi kommer att arbeta med effektstyrning och scrum.
2. Effektstyrning går ut på att styra projektet med ständigt fokus på verksamhetsnytta istället för "leverabler" eller "krav". Den nytta som projektet ska skapa kartläggs i en resonemangskedja från syftet med tjänsten som ska tas fram, till målgrupperna som ska använda tjänsten, deras användningsmål och slutligen åtgärder som behöver vidtas. Varje steg prioriteras så att kartan blir ett stöd för projektgruppen och för styrgruppen för att följa och styra projektet. (Exempel på effektkarta finns på Socialstyrelsens utvecklingsblogg).
3. Scrum (eller nån annan agil metod) är den operativa styrningen av projektet. Det handlar om att ha alla kompetenser samlade, planera för högst några veckor i taget och visualisera arbetet så mycket som möjligt. På så sätt uppstår verksamhetsnyttan inom de ramar som definierats för projektet.

Någon som har ett likande upplägg?

Rules of the garage

Rules of the garage:
Believe you can change the world.
Work quickly, keep the tools unlocked,
work whenever.

Know when to work alone and when to
work together.
Share — tools, ideas. Trust your colleagues.

No politics. No bureaucracy. (These are ridiculous
in a garage.)
The customer defines a job well done.

Radical ideas are not bad ideas.
Invent different ways of working.

Make a contribution every day. If it doesn’t
contribute, it doesn’t leave the garage.

Believe that together we can do anything.
Invent.

(HP:s årsredovisning 1999, VD Carly Fiorona)
(På bilden syns det ursprunliga garage där HP startade, ofta ansett vara Silicon Valleys startskott)

Kulturella normer styr sociala medier

Att ge sig ut i social medier möts ofta av stor oro och skepsis i organisationer. Det är sunt att ifrågasätta, men att vara orolig är inte sunt. Oron handlar till exempel om att "det finns ingen roi", "det där är inget för oss" eller "det är bara en fluga".

Ett av de största orosmolnen är rädslan för att "förlora kontrollen". Man oroar sig till exempel för att få negativa kommentarer och kritik om man låter användarna själva delta. Den oron tycker jag bygger på missuppfattningar.

På internet, liksom i alla sammanhang där det finns människor, uppstår kulturella normer. När jag sitter på puben med några vänner beter jag mig på ett visst sätt, när jag är på klubb beter jag mig på ett annat och när jag hämtar sonen från dagis beter jag på ytterligare ett annat. Dels för att förutsättningarna är annorlunda (på puben sitter jag vid ett bord, på klubben rör jag mig i lokalen, på dagis är jag... på dagis), dels för att jag helt enkelt förväntas göra det. Att komma i badrock till puben, blåställ till klubben eller frack till dagis skulle helt enkelt avvika för mycket från normen – alltså gör jag det inte. De kulturella normerna är en förutsättning för hela vår civilisation. Vi beter oss inom vissa socialt givna ramar.

Självklart kan negativa rykten spridas på nätet och tillåter man användarkommentarer eller öppnar en sida på Facebook så kommer det säkert förr eller senare kritiska inlägg. Men här finns tre viktiga saker att tänka på:

1. Normen i de allra flesta social medier är väldigt sund. Det är inte okej att bete sig hur som helst och de som gör det kommer av den absoluta majoriteten att avfärdas eller ignoreras. 
2. Kritiken uppstår inte för att man tillåter kommenterar, den finns där ute ändå. Genom att tillåta kommentarer har man tvärtom en möjlighet att ta hem diskussionen till sin hemarena.
3. Kulturen på nätet – och numera värderingarna i hela samhället – är att man ska vara öppen och transparent. Väljer man att inte vara det så målar man in sig i ett hörn och får betydligt svårare att överhuvudtaget möta sina målgrupper.

Kritiska kommentarer ignoreras eller tystas ner på Facebook
I den grupp jag skapat på Facebook angående vaccineringen mot svininfluensan (se tidigare inlägg om svininfluensan på Facebook) finns två exempel från den senaste veckan. Samma mönster återfinns i alla fungerande sociala nätverk (det är just därför de fungerar! för att det uppstår kulturella normer!).
Med drygt 1100 medlemmar i gruppen, som samtliga vill visa sitt stöd för vaccineringen, spelar det mycket liten roll när ett inlägg postas med det motsatta budskapet. Följande är ett utdrag från loggen (listan med meddelanden) på Facebook. Någon postar ett inlägg och får direkt ett bemötande från andra medlemmar som både tillbakavisar hans inlägg och även avfärdar hela diskussionen.

Tittar man på antalet nytillkomna medlemmar under den tid som denna diskussion pågår så har diskussionen och de kritiska åsikterna ingen negativ påverkan. Tvärtom! Tillväxttakten ökade under denna period och det går inte att se några andra faktorer som förändrats.

Nästa exempel är en kritisk kommentar som totalt ignorerats. Någon har postat ett inlägg som handlar om negativa effekter av vaccinering (undre inlägget). Nästa inlägg struntar fullständigt i detta och skriver bara "Äntligen ska jag få min vaccin på fredag" (övre inlägget).

Förstå och bejaka kulturen
Att kulturer uppstår är inget som bara gäller internet, kulturer uppstår överallt där det finns människor. Varje gång man som organisation kommunicerar med sina anställda eller med marknaden följer man de kulturella normerna för det medium man väljer. Och man tycker inte att det är något konstigt i det. Av någon anledning oroar man sig mycket för hur det är på internet och främst i sociala medier. Man oroar sig så mycket att konsekvensen blir att man gör fel, till exempel genom att inte tillåta kommentarer. För att lyckas måste man förstå och även bejaka den rådande kulturen.

Fortfarande sjukt många misslyckade IT-projekt

Fortfarande misslyckas en överväldigande andel av alla IT- och webbprojekt. Den största undersökningen på området är Chaos Report som i år fastslog att 68% av projekten misslyckas. Förra året redovisade intresse-organisationen Sveriges Kommuner och Landsting att 84% av alla projekt misslyckas. Och 2006 gjorde Projektplace AB sin stora mätning och konstaterade att 82% misslyckas.

Projektledarens och styrgruppens ansvar för riskhantering

Risker är alla de faktorer som kan göra att man inte uppnår syftet med projektet. Uttryckt annorlunda: Risk är skillnaden mellan de förutsättningar du har i projektet och de förutsättningar du behöver för att säkert uppnå målet. I webbprojekt handlar de flesta riskerna om oklara krav, personal, leverantörer, planering och styrning.

Risker kan finnas antingen inom projektet eller i projektets omvärld. Som projektledare ansvarar man för att identifiera alla risker för projektet, både de som ligger inom projektet och de som ligger utanför projektet.

Ansvaret för att hantera riskerna inom projektet ligger på projektledaren

En typisk riskhändelse kan vara: Vi väljer fel teknisk plattform vilket gör att vi inte kan bygga det vi vill. Ansvaret ligger i detta fall på projektledaren och en tänkbar åtgärd är att minimera sannolikheten för att risken inträffar. Risker inom projektet kan hanteras på fyra sätt:

1. Minimera eller undanröj sannolikheten att risken inträffar. I det här fallet kan man till exempel genom att låta en extern konsult göra en förstudie om valet av teknisk plattform.
2. Minimera eller undanröj konsekvensen av att den inträffar. Till exempel genom att säkerställa att de lösningar vi bygger på plattformen är väl dokumenterade och följer standarder, så blir konsekvense lite mindre om vi längre fram skulle behöva byta plattform.
3. Överför konsekvensen på någon annan. Utforma avtal med leverantörer på ett sådant sätt att alla eventuella förseningar eller kostnader som uppstår på grund av fel plattformsval måste täckas av konsultföretaget.
4. Bevaka. Om risken är låg eller kostnaderna är för höga för att göra något åt den, så får man låta den vara men bevaka den.

Ansvaret för att hantera riskerna utanför projektet ligger på styrgruppen och beställaren
Projektledaren har sällan personalansvar och inte alltid fullt budgetansvar, vilket gör att de åtgärder projektledaren kan vidta är begränsade. Många risker ligger därför utanför projektet. Säg att vi identifierar en risk att projektets grafiska formgivare säger upp sig. Har du som projektledare inte personalansvar så måste risken lyftas till styrgruppen. Projektledaren kan jobba med att ge positiv feedback och skapa bra arbetsmiljö för formgivaren så han/hon stannar kvar, men styrgruppen behöver agera på eventuella problem med lönesättning, villkor, vidareutbildning eller alternativ bemanning. För risker utanför projektet:

1. Se till att styrgruppen blir medveten om sitt ansvar för att hantera risken.
2. Se till att öka det egna mandatet som projektledare så att projektet så långt som möjligt kan överta risken från styrgruppen. Till exempel genom att få utökat budgetansvar eller ansvar för delar av personalfrågorna.
3. Se punkt 1-4 ovan. 

Tre revolutionerande saker för en stor organisation med mycket tradition

Min uppgift hos min nya arbetsgivare är att modernisera synsätt och arbetssätt för att "föra oss in i den moderna världen". Här är tre områden jag tänker börja med:

1. Se till att avskaffa alla blockeringar av åtkomsten till internet. I dagsläget är så gott som hela sociala webben och stora delar av det som kan anses vara web 2.0 blockerat för samtliga anställda. Youtube, Facebook, LinkedIn, Blogger etc är spärrade. (Ok, några spärrar kan få vara kvar, typ sidor som sprider skadliga programvaror). √ KLART
2. Starta en utvecklingsblogg. Definitivt internt, men helst externt. Det måste gå att stå för större öppenhet och transparens in i pågående projekt. Samtidigt ger det engagemang och delaktighet.
3. Anordna en "project camp". I sann web camp-anda vore det enormt befriande att låta människor från olika delar av organisationen träffas under öppna och informella former för att utbyta idéer och helst även skapa något tillsammans. (InternetWorld skrev föresten apropå att göra  camps internt.)

Definition of Done: How to Test

Först en mycket kort historisk återblick för att förstå vad Definition of Done (DoD) handlar om. I jordbrukssamhället var det ofta uppenbart när ett arbetet var slutfört. När åkern var plöjd var man klar och kunde ta itu med nästa uppgift eller med gott samvete gå hem för dagen.

Så fungerar det inte i informationssamhället. Allt kunskapsarbete lider av att det aldrig tycks ta slut, det kan alltid göras lite bättre och det är svårt att veta när det egentligen är "klart". Blir det överhuvud taget nånsin klart?

Därför är Definition of Done en helt avgörande del i Scrum och andra agila projektmetoder. För att styra projektet framåt behöver man definiera när respektive uppgift, sprint eller projekt är klart. Definition of Done är helt enkelt en checklista över vad som ska vara klart. Jag har bland annat använt den här varianten:

Definition of Done (exempel från offentlig sektor)

• Kod testad
• Användningstestat
• Fel åtgärdade
• Utvärderat så att kraven för tillgänglighet för människor med funktionsnedsättning uppnås (Verva nivå 1)
• Koden validerad enligt W3C
• Modul-dokumentation upprättad/uppdaterad

Men hur man upprättar en Definition of Done är inte självklart och i praktiken kommer den säkert att förändras under projektets gång. Två utmaningar jag tycker återkommer är att:

• man måste få samsyn på vad Definition of Done innebär och förståelse för varje punkt. Det räcker inte att man förstår "sin del" eftersom de nästan alltid hänger ihop.
• det är ofta i avgränsningen av uppgifter, funktioner, sprintar eller delmål som komplikationerna uppstår. Checklistan ovan är ganska meningslös om man inte vet ifall "Gör det möjligt att skicka nyhetsbrev" även inkluderar "Nyhetsbreven ska kunna innehålla bilder".

Bättre Definition of Done med How-to-test och förändring på scrum-väggen

I nästa projekt kommer jag att prova två åtgärder för att bättre hantera dessa svårigheter.

• Arbeta med konceptet "How-to-Test" som alternativ eller komplement till Definition of Done. Genom att fokusera mer på hur något ska testas uppnår man flera saker: det är ett mer visuellt sätt att beskriv vad som ska åstadkommas, det är något som alla medlemmar i gruppen har lättare att ta till sig och det för arbetet mycket närmre den affärsnytta som projektet ska skapa.
• Se till att alla steg i Definition of Done också har en motsvarighet på scrumväggen. Den traditionella indelningen av en scrumvägg är Ej påbörjat, Pågående, Avslutat. Till detta kanske man ska lägga till exempel Klart för test och utvärdering och Testat och utvärderat?

Lyckas med webbprojekt: (1) Se till att alla har samma målbild

Dags att revidera den traditionella projekt-triangeln

Projekttriangeln är en av grundbultarna i klassisk projektmetodik. Tid ("jag vill att det ska gå snabbt"), pengar ("jag vill ha det billigt") och resultat ("jag vill att det ska bli bra") blir var sin sida i en triangel för att visa på beroendena mellan de tre enheterna. Poängen är förstås att förändras budget så påverkas de båda andra, och så vidare.

Jag tycker att modellen har brister när den tillämpas i moderna projekt, till exempel webbprojekt. Kraven och verkligheten förändras och "resultat" blir ett för trubbigt mått. Jag föreslår därför istället en projektromb.

Tid och pengar är samma enheter som i den traditionella projekttriangeln, men resultat har delats in i kvalitet och omfång. Om kvalitet handlar om hur bra en funktion fungerar ("jag vill att det ska bli bra") så handlar omfång om hur många funktioner som finns ("jag vill ha mycket av 'det'"). Att göra en distinktion mellan kvalitet och omfång är väldigt viktigt i webbprojekt eftersom vi ofta ställs inför valet att förbättra en funktionalitet mer och mer eller att låta det vara och fokusera på att bygga nästa funktionalitet.

Jag har använt en projektromb i två projekt. Det kan se ut till exempel så här:

• Kvalitet framför omfång – vi levererar färdigställda och kvalitetssäkrade resultat stegvis, mängden resultat kan skäras ner.
• Kalendertid framför budget – måste vi välja så utökar vi budgeten, inte kalendertiden.