Användbarhet - projektledarens dröm eller mardröm Thomas Jarhede Projektledare, Guide Konsult Stockholm

Projekt ur ett PL-perspektiv Budget Styrning Planering Uppföljning Kommunikation Nu tänkte jag ge er en projektledares perspektiv på projekt för att ni ska förstå vår världsbild Vi är ytterst ansvariga för projektresultatet Och när det ansvaret föreligger har man som PL fokus på vissa aspekter i ett projekt som kanske inte övriga i projektet är så värst intresserade av Budget Det finns alltid en budget, det finns INGA organisationer som inte budgeterar sina investeringar (borde ialla fall inte finnas!) Beställaren skall ha en budget för projektet, som en del av budgeten för sin verksamhet annars är det en tydlig risksignal! Det är lika bra att plocka fram en siffra, att tydligöra detta så snart man känner sig färdigplanerad. Kom dock ihåg, har man givit en siffra så etsar det sig fast, beställaren vill att man tar ansvar för den oavsett hur avtalet är konstruerat eller vilka förbehåll du gör. Det finns dessutom alltid andra personer inom beställarens organisation som kontrollerar om budgeten hålls, för någon kommer att tvingas redovisa detta internt. Styrning En projektledare ska ju styra projektet så att resultatet blir det önskade, dvs projektmålen uppfylls. En fördel är om det används en projektstyrningsmodell, som må heta, PPS, PROPS, eller något annat. Kanske egendefinierad Det finns ju hyllmeter skrivna om detta, när man ska följa en formell styrmetod kan det ibland innebära att man lägger för mycket energi på att genomföra projekt på rätt sätt (metodfokus) istället för att styra mot det uppställda målet, dvs den nyttoeffekt man vill uppnå Det vanligaste är dock att projekt saknar modell överhuvudtaget och styr mer på ”sunt förnuft” Planering Projektet ska vara planerbart, dvs aktiviteterna ska definieras map varaktighet, omfattning, beroenden, ansvar osv Så sätter vi upp det i ett vackert gantschema, så är vi lyckliga! BILD, då har vi kontroll! Uppföljing Det man planerar vill man kunna följa upp, = TIDRAPPORT! Den projektledare som inte kan redogöra för framdriften i projektet kommer att hamna I I svårigheter gentemot sin beställare/styrgrupp och tappa kontrollen över projektet. Progress ska vara mätbar. Kommuniation Kommunikation utgör minst hälften av en projektledares tid

Välja projektmetod Typ av system Typ av organisation Beställare Målgrupp Avtalsform Befintliga metoder hos kund Tillgång till kunden ... Hur ska vi jobba I ett projekt? Val av angreppssätt ska bero på vilka förutsättningar som finns Olika grupper av expertis och kultur hos leverantörer styr ofta vilka aspekter det blir fokus på I ett projekt, om inte beställaren/kunden har mycket specifika krav, men även då slår detta igenom. Det är naturligtvis rätt att det slår igenom I viss mån om man som organisation har en viss profil man vill framhäva. Men man behöver mer förutsättningslöst titta på vad som kan vara lämpligt I det enskilda fallet Tex låter man en Systemarkitekt dominera projektgruppen blir det kanske en tekniskt fulländad produkt trots att det behovet inte fanns Låter man en Användbarhetsdesigner styra blir det fokus på de aspekterna. Dvs valet ska inte vara beroende av enskilda Projektmedlemmars Intressen och dominans Om vi istället för att låta oss styras av sådant eller traditioner, ser mer förutsättningslöst på projektet, så bör vi ställa oss ett antal frågor Vad ska vi ta fram för typ av IT-system, administrativt?, tekniskt?, finns standardprodukt? Vad är det för organisation, vilken kultur har man? Beställare, IT-chef?, verksamheten?, Mognadsgrad?, Inställning?, Fokus på användarnas behov?, Aktiv användarmedverkan? Målgrupp, eller målgrupper, ålder?, datorvana?, (användbarhetsdesigners vana att gör sådana beskrivingar), har vi tillgång till målgruppen? Avtalsform, fast pris?, målpris?, löpande räkning? Befintliga metoder hos kund, formella sådana, vana vid Iterativt arbetssätt?, vana vid Prototyper o utvärderingar? Tillgång till kunden, vilken personal hos kunden har vi tillgång till för avstämning och aktivt deltagande i projektet? Med mera, med mera Jag tänkte att vi skulle titta på 4 projekt som jag varit med om att genomföra och i något fall pågår det i detta nu Vilka förutsättningar har just detta projekt?

Projekt 1 Typ av system: tekniskt system Typ av organisation: teknikinriktad telekom Beställare: ovan beställare av IS-system, ingen aning vad användbarhet är Målgrupp: tekniker, vana att jobba med att göra egna små hack, vill ha stora frihetsgrader, god tillgång till användare Avtalsform: löpande Befintliga metoder hos kund: officiella metoder finns men används begränsat i praktiken Tillgång till kundens personal i detta fall god Genomförande, närmast total avsaknad av användbarhetsaktiviteter, det var liten fokus på gränssnitt. Mer fokus på smarta funktioner för att effektivisera flödet, arbetsuppgifter Resultat, lyckat! Trots allt?

Projekt 2 Typ av system: administrativt system inom skogsbranschen. Hanterar stora mängder pengar Standardprodukt finns i botten Typ av organisation: IT-frågor hanteras av IS-chefen mha liten egen IT-enhet. Hyr in konsulter för genomförande av projekt och förvaltning av befintliga system Beställare: IS-chef som styr mycket, har en mycket tydlig och detaljerad bild av vad man vill Målgrupp: olika typer av målgrupper, mer ovana slutanvändare och rena expertanvändare Avtalsform: målpris, tuffa avtalsskrivningar Befintliga metoder hos kund: inga officiella, praxis av mycket avstämningar med prototyper Tillgång till kunden: liten grupp av adminstrativ personal som är engagerad i projeketet Genomförande: Flera underleverantörer, huvudleverantör med låg medvetadegrad om moderna iterativa arbetsmetoder, arbetar enligt vattenfallsmodell. Klickar I kommunikationen och avstämning Ett fåtal användbarhetsaktiviteter, utvärdering av gränssnitt lite expertstöd för utformning av gränssnitt Resultat, arbete pågår

Projekt 3 Typ av system: Ansökningar och administration av forskningspengar Typ av organisation: statligt verk Beställare: visar sig intresserad av användbarhet I teorin men är I praktiken inte beredd att genomföra de aktiviteter som Behövs för att genomföra projeketet enligt ett användarcentrerad metod. Fokus på att göra klart lösningen så fort som möjligt, det gäller att förbruka en mängd pengar inom ett budgetår. Användbarhet har man intresserat sig för bla pga att man fått kritik på oanvändbara system Målgrupp: Många ovana användare Avtalsform: löpande till att börja med, efter ett tag vill man göra om det till ett fast pris bla pga att man inte fått klart med sin finansiering för kommande år och inte vet hur mycket pengar man har för projektets genomförande Befintliga metoder hos kund: saknas, vana vid att IT-avdelningen styr framtagandet av systemen med liten inblandning av verksamheten i övrigt Tillgång till användare: begränsad tillgång I praktiken, hänvisade till ett par resurser på IT-enheten Genomförande, användbarhetsdesigner inne i projeketet, förbättring av flöden och av kunden ritade gränssnitt Vi fick en ”färdig” bunt bilder som man arbetat fram internt innan vi kom in, små frihetsgrader att göra mycket som avviker från det Tekniskt Resultat, lyckat! Budgetmässigt och avtalsmässigt misslyckande

Projekt 4 Typ av system: kommersiell produkt, administrativt, standard plattform = office Typ av organisation: Branschorganisation Beställare: mycket god kunskap om användbarhet, villiga att skaffa fram användare, Man månade verkligen om att resultatet skulle bli något som marknaden ville ha Målgrupp: yrkesgrupp på företag inom branchen Avtalsform: löpande enligt avtalet, i praktiken fast pris Befintliga metoder hos kund: Inga officiella, dock så kickade man ut tidigare leverantör bla pga att de inte förstod sig på användbarhet och att arbeta användarcentrerat Tillgång till kunden: god tillgång till interna resurser Bra slutresultat, goda vitsord vid utvärdering Genomförande Intervjuer och observationer Framtagande av användarprofiler Prototyper, 2 iterationer med olika användargrupper Workshops Utvärderingar med kund och användare Diskussioner med utvecklare för att diskutera lösningar Betatester - utvärdering

Mindre lämpligt med användarcentrerat Hård styrning mot i förväg upprättad kravspec Liten Människa-datorinteraktion Traditionellt teknikfokus i organisation Flera inblandade delleverantörer med låg medvetande grad Svårt att få tillgång till användare Pressad tidplan Fokusera på att få in några användarbarhets aktiviteter Baserat på dessa projekts erfarenheter och andra projekt, kan jag inte se annat att än att i de flesta fall går det alldeles utmärkt med en användarcentrerad metod för genomförande av projektet, Användarcentrerat arbetssätt Projekt1, mindre intressant Projekt2, inte möjligt pga av flera orsaker, det skulle krävas en stor insäljningsinsats gentemot underleverantörer, hade man skrivit in detta I upphandligen som en grundförutsättning hade vi fått mer fokus på de frågorna Projekt3, fullt möjligt med ett användarcentrerat arbetssätt, hade vi kommit in tidigare i projektet kunde vi arbetat på det sättet fullt ut, en hel del gjordes dock Projekt4, klockrent, knappast möjligt med något annat arbetssätt I vissa fall kan man dock se att det finns faktorer som gör det svårare att applicera ett rent användarcentrerat angreppssätt på ett projekt Vi kan titta på några sådana, (enligt lista) Däremot ser jag inte någon anledning till att inte genomföra ett användarcentrerat projektupplägg, enbart av det skälet att vi har ett fast pris En invändning man hör ibland. Eller att det skulle bli dyrare att genomföra projeketet med ett sådant arbetssätt Kan man inte jobba helt användarcentrerat får man fokusera på att göra en del sådana aktiviteter Utvärderingar, gräsnsnittsstöd etc

Varför misslyckas vi så ofta Varför går det snett ofta generellt sett? Generellt dessa punkter, rulla bild Så gott som alla dessa punkter kan också inträffa med ett användarcentrerat arbetssätt Vissa av dessa risker kan vi dock reducera med ett användarcentrerat arbetssätt I det stora hela anser jag dock att det spelar egentligen ganska liten roll vilken metod vi använder, en metod i sig garanterar inget bra resultat Rimliga grundförutsättningar och ett strukturerat arbetssätt måste vi ha. Men jag tror att det är främst människorna i projektet som är viktiga för ett projekts framgång, Det är deras engagemang, yrkeskunskap och förmåga att kommunicera, som ger ett lyckat resultat

Genomförande, att tänka på Involvera utvecklarna Stäm av även med beställare Ta hänsyn till vald teknik vid prototyputveckling Kravbild ändras av användarsynpunkter men ska kravhanteras på normalt sätt Kommunicera Om vi specifikt tittar på användarcentrerade projekt, kan följande punkter vara något att tänka på Involvera utvecklarna i prototyparbetet och avstämningar Stäm inte bara med slutanvändarna, ta med beställare och expertanvändare i avstämningar också Prototyper som görs helt utan hänsyn till om de går att implementera i den valda tekniken eller produkterna har ganska litet värde när man ska realisera lösningen, riskerar att bli en helt frikopplad prototyp och oanvändbar i det fortsatta arbetet Tänk på en möbeldesigner eller industridesigner tex, han/hon tar naturligvis hänsyn till det material man har att jobba med Det är ingen mening att designa en lösning som inte är realiserbar eller realiserbar till mycket hög kostnad Synpunkter från användare måste inte implementeras in direkt eller över huvudtaget, en hård prioritering av nya krav viktig andra krav ska då kunna tas bort Och sedan måste jag bara ta upp den allra viktigaste aspekten i alla projekt för ett lyckat resultat och det är kommunicera, kommunicera, kommunicera och stäm av. Min erfarenhet är att det ofta är huvudorsaken till att man misslyckas

Projektleda användarcentrerade projekt jämfört med andra Styrning Planering av aktiviteter Kravhantering Budget Bättre avstämd produkt Främjar kommunikation Kräver mer kalendertid Kan kräva insäljning hos beställare Det är inget svårare eller lättare att styra ett användarcentrerat projekt, vi siktar som vanligt på att nå målen med systemet Användbarhetsaktiviteter hjälper oss att få ett fokus på detta, inte ha fokus på att pricka av funktionalitet i en lista Aktiviteter kopplade till användbarhet ska planeras precis som vilka andra som helst, de är ofta tydliga och enkla att planera in Vi ska i botten ha en ”normal” kravhantering med prioritering av genomförande. Fler nya krav, mer vildvuxna krav dyker upp som kan konfliktera med andra, det gäller att hålla i sina huvudlinjer. Vi släpper på användaråsikter men vi är inte rädda för det eller känner oss bundna till att följa dessa Projekten har en budget, ska ha en budget på samma sätt som vanligt, inget speciellt bara för att vi jobbar användarcentrerat Vi får i grunden en mer förankrad produkt både hos beställare och slutanvändare, vi undviker överraskningar, tidiga avstämningar Arbetssättet främjar kommunikation som jag tidigare lyfte fram som en huvudorsak till problem i projekt, Kommunikation inom projektgruppen gynnas, men framför allt med beställare och slutanvändare Vi behöver mer kalendertid för att genomföra Intervjuer, observationer, avstämningar med stora mängder människor i olika konstellationer, svårt att hinna rulla runt tillräckligt fort annars, man ska få tag i folk och boka in många personer, det tar tid Medvetandet om vad användbarhet är och vad ett fokus på det kan ge för effektivitetsvinster är fortfarande ganska lågt och man behöver ofta jobba en hel del med att sälja in det arbetssättet.

Tips hur får man in fler användbarhetsaktiviteter i projekt Projektanpassa metoden Förankra hos leverantör Förankra hos beställare Utbilda pojektledare och säljare Ta med användbarhetsexpert ut på säljmöten

Frågor?