Starta dina projekt rätt (med Suze Haworth)

Läs transkriberingen:

Vi testar att transkribera våra poddar med hjälp av ett program. Ha överseende med eventuella stavfel eftersom boten inte är korrekt till 100 procent hela tiden.

Ben Aston:

Välkommen till DPM-podden, där vi går bortom teorin för att ge expertråd inom projektledning för att leda bättre digitala projekt. Tack för att du lyssnar. Jag heter Ben Aston och är grundare av The Digital Project Manager.

Vi vet alla att början av ett projekt är avgörande för dess framgång, men det kan också vara en mycket utmanande tid. Det finns mycket tvetydighet, förvirring, oenighet och osäkerhet. Som projektledare är det vårt jobb att få projektet i rörelse och hålla det i gång – och extra pluspoäng om vi faktiskt börjar leda projektet i rätt riktning. Men vad kan vi faktiskt göra för att se till att vi sätter kursen åt rätt håll? Att vi börjar på rätt sätt? Det är vad dagens poddavsnitt handlar om. Fortsätt lyssna för att ta reda på hur du kan starta dina projekt rätt.

I dag har jag sällskap av Suze Haworth. Hej, Suze.

Suze Haworth:

Hej.

Ben Aston:

Suze är en av våra DPM-experter på The Digital Project Manager. Hon arbetar som frilansande senior digital projektledare i London. Suze, kan du berätta lite om några av de projekt du har arbetat med på sistone?

Suze Haworth:

Ja. Jag är faktiskt frilansande projektledare. För några veckor sedan avslutade jag ett uppdrag på en byrå. Det var ett ganska långsiktigt uppdrag och jag hade två huvudsakliga roller där. Den ena var mer av en programdirektörsroll för ett konto. Det var för Specsavers, som är ett mycket stort varumärke inom detaljhandel för glasögon i Storbritannien och även finns i Norden och Australien. Jag ansvarade för en senior projektledare inom allt kreativt arbete, UX och digitalt för Specsavers. Det var alltså ett ganska stort arbetsprogram. Jag arbetade också med ett projekt för Ikea. Det var ett projekt för att utforma och bygga en prototyp för ett designsystem för varumärket.

Ben Aston:

Kul. Så Specsavers var mer ett projekt inom e-handel och konverteringsoptimering?

Suze Haworth:

Ja. Det berodde egentligen på marknaden, men de brukar faktiskt inte sälja glasögon online på grund av vissa regler. Mycket handlade därför om att få människor att boka tider och besöka butikerna. Men ja, det handlade till stor del om konverteringsoptimering, som du säger.

Ben Aston:

Vad var svårt i de projekten? Vilka utmaningar hanterade du när det gällde själva projektet, kunden eller teamet? Jag tror alltid att det är intressant för människor att höra att andra har liknande problem. Så vad var svårt?

Suze Haworth:

När det gäller Specsavers arbetsprogram var det faktiskt en mycket intressant tid när jag började där, eftersom jag började i mars, i början av det nya året, och vi gick över till ett helt nytt arbetssätt. Tidigare hade vi arbetat som designbyrå parallellt med deras utvecklingsbyrå och suttit i alla deras scrumteam. Vi hade alltså en designer och en UX-person i vart och ett av deras scrumteam inom de olika arbetsströmmarna. Vi beslutade att ta bort alla våra designers och UX-personer från scrumteamen, samla dem i ett eget team och sedan gå över till en mer parallell process. Vi drev det vi kallade ett upptäcktsspår ovanför leveransspåret, som bestod mer av det scrum-baserade utvecklingsteamet.

Det gav oss utrymme att göra användartester, utforska, formulera hypoteser och antaganden och testa dem med användare. Vi kunde också göra mycket mer research och använda data för att ge underlag åt arbetet. Det gav oss mer handlingsutrymme att faktiskt leverera sådant som användarna ville ha. Det var en mycket intressant tid att införa det nya arbetssättet och se till att det fungerade. Det var en utmaning, men också väldigt spännande.

Ben Aston:

Var din roll då som … vems roll var det? Produktägarens? Ni hade alltså två parallella arbetsströmmar. Den ena handlade om strategi, UX och design, och jag antar att det var där användartester genomfördes för att identifiera användarnas behov. Sedan prioriterades behoven, några gick vidare till UX- och designspåret och därefter ner till utveckling. Var det så det fungerade?

Suze Haworth:

Ja. Det vi upptäckte var att design- och UX-paren, när de satt i scrumteamet och arbetade i tvåveckorsperioder, blev ganska begränsade. Mycket tid gick åt till tekniska frågor. De satt i långa sprintplaneringsmöten och deltog i mindre delar av arbetet, eller i dagliga möten där man ofta pratade om buggar. I stället för att tänka på kundernas faktiska behov blev arbetet mer teknikdrivet. Därför tog vi bort dem från scrumteamet och placerade dem i ett spår ovanför, så att de fick tillräckligt med tid. Det gick fortfarande snabbt, men vi kunde titta på befintlig data och research, identifiera antaganden och formulera hypoteser om hur vi kunde lösa kundernas problem.

Vi kunde sedan snabbt göra UX-design eller prototyper, beroende på behovet, och visa dem för kunderna. Då kunde de validera lösningen innan den gick vidare till leverans. På så sätt kunde vi effektivisera utvecklingen och undvika att bygga sådant som kunderna inte ville ha. Vi försökte fatta design- och UX-beslut innan arbetet gick in i sprintarna. Vi involverade fortfarande tekniska personer i upptäcktsspåret, men i stället för att enbart validera teknisk genomförbarhet kunde vi först säga: ”Det här är vad kunden vill ha och de gillade funktionen vi har utformat.” Det handlade alltså om att effektivisera processen och samtidigt fokusera på att leverera det kunden behöver, snarare än det som bara går att göra.

Ben Aston:

Jag tror att det där är en utmaning för många byråer som försöker arbeta med scrum. Scrum är uppenbarligen inte det enda sättet att genomföra ett agilt projekt, men det verkar ofta finnas en allmänt accepterad uppfattning om att man måste använda scrum. En stor utmaning när man använder scrum på en byrå är vad UX- och designpersonerna egentligen ska göra under sprinten. Ett sätt är att låta UX och design ligga några sprintar före utvecklingen, men då blir frågan vad som faktiskt blir färdigt. Tanken med en sprint är att man i slutet ska ha utvecklat något som kan lanseras och som uppfyller acceptanskriterierna. Det är svårt att hinna gå igenom strategi, UX, design och utveckling av en funktion på två veckor.

Jag gillar därför idén att driva två parallella arbetsströmmar. När saker har validerats kan produktägaren lägga in dem i utvecklingens backlogg. Då har man två olika backlogger: en strategisk där man ställer frågan om detta är rätt sak att göra, och en där man säger: ”Vi vet att detta är rätt sak att göra eftersom det har validerats. Nu bygger vi det.” Det löser definitivt några av utmaningarna.

Suze Haworth:

Ja, precis. Det innebär att man faktiskt bygger funktioner som man har validerat att kunderna vill ha. Det minskar mängden slöseri och gör arbetet mer resurssnålt, vilket bara kan vara bra.

Ben Aston:

Bra. Låt oss prata om projektinitiering och om att faktiskt starta projekt. Jag är nyfiken på om du var involverad från början i Ikea- eller Specsaversprojekten.

Suze Haworth:

När det gäller Specsavers var det ett nytt arbetssätt och ett team på löpande uppdrag, med en omfattning för året och en definierad teamstruktur. Jag började när arbetssättet hade definierats ganska löst och arbetsomfattningen hade skrivits. Det är en av de utmaningar jag tar upp i min artikel: att ta över något eller ett projekt som redan har startat eller redan har definierats av någon annan. Jag tog över projektet ganska snart efter att det hade definierats, men arbetssättet hade bara löst fastställts. När det började genomföras märkte jag att det behövde justeras och förändras. Det utvecklades ganska mycket från det som först hade föreslagits, eftersom man upptäcker vad som inte fungerar när man börjar arbeta på ett visst sätt.

Ikea-projektet genomfördes i etapper. Jag arbetade inte med den första etappen utan kom in i den andra, så projektet hade redan startat innan jag började.

Ben Aston:

Det är ofta så med projekt som vi tar över som projektledare. Vi kommer ofta in, inte riktigt i början, utan någonstans på vägen. Det kan bidra till förvirringen. Som projektledare blir man inkopplad efter att projektet har lämnats över från affärsutveckling, kundansvariga eller försäljning. Man ärver något som har planerats, men inte helt färdigplanerats. Det finns en viss osäkerhet. När vi pratar om projektinitiering handlar det därför lika mycket om att ta över ett projekt senare i processen som om att börja från början.

Låt oss prata om det du nämner i din artikel: att hantera människor, process och produkt och skapa samsyn och tydlighet kring dessa delar. Det handlar alltså om vem, hur och vad. När man tar över ett projekt, antingen genom att starta det för första gången eller genom att komma in senare, vilka saker försöker man göra ur ett människoperspektiv?

Suze Haworth:

Det finns några centrala grupper eller personer man behöver tänka på i ett projekt. Först och främst teamet: vilka ska arbeta med projektet? I projektinitieringsfasen definierar man vilka som ska bokas in och arbeta med det. Det är viktigt att inte bara tänka på vem som är tillgänglig, utan också på vem som passar för projektet. Man behöver titta på deras kompetenser, arbetssätt, typen av projekt och vilken kund man arbetar med.

Om man känner sina teammedlemmar är det viktigt att förstå vilka som kan fungera bäst tillsammans. Det är förstås en lyx och ibland avgör tillgängligheten, men det är bra att tänka på detta från början. Även om man måste använda vissa personer i ett projekt hjälper det att förstå hur de arbetar, eftersom det kan underlätta senare om problem uppstår.

Det är också mycket viktigt att personerna som ska arbeta med projektet involveras från början. Efter många år av arbete med designers, utvecklare och QA-personer har jag märkt att det är något de flesta, om inte alla, ogillar: att inte vara en del av projektet från början, inte veta något om det och sedan få något färdigdefinierat i knät med instruktionen: ”Kan du bara designa det här?” eller ”Kan du bara bygga det här?” När de inte får någon självständighet och bara blir tillsagda vad de ska göra blir det ofta ett problem.

Om man har tillräckligt med tid och budget är det därför en bra idé att involvera dem åtminstone lite från början. Efter det första interna uppstartsmötet kan man prata med dem om vad de tycker om projektet, hur de vill att det ska fungera och vilka förväntningar de har. På så sätt blir de delaktiga från start.

Ben Aston:

Jag tror att detta hänger ihop med resursplaneringen. Så tidigt som möjligt behöver man bemanna teamet man behöver och vill ha och få dem engagerade i projektet, så att man får deras stöd. Människor reagerar ofta när de ärver något som någon annan har tänkt igenom, men inte haft tillräckligt med tid att tänka igenom ordentligt. Då säger de: ”Vänta, varför gör vi det här? Det är inte så här jag skulle göra.” Vi vill att människor ska känna: ”Ja, det här är mitt.” När de får en känsla av ägarskap i stället för att reagera på någon annans halvfärdiga idé brukar resultaten bli mycket bättre.

Suze Haworth:

Precis.

Ben Aston:

Jag tänkte gå vidare till processen, eftersom den också hänger ihop med detta. Vi har teamet och vet vilka som ingår. Hur ska vi använda teamet för att leverera projektet? Det finns ofta oenighet om hur projektet ska genomföras, vilken process, metod och vilka verktyg som ska användas. Hur skapar man samsyn i teamet och hanterar den oenighet som nästan är oundviklig?

Suze Haworth:

Man hittar förmodligen aldrig en idealisk process som passar alla på alla sätt. Det kommer att uppstå spänningar under projektets gång. Ibland ärver man en process som byrån eller organisationen redan använder, eller så styr kunden processen. Om man själv får definiera den är det förstås bra, eftersom man kan försöka hitta något som passar projektet och kunden. Om processen redan är fastställd är det bra att gå igenom den på ett internt uppstartsmöte, förklara varför den används och försöka få teamets stöd tidigt.

Det är också mycket viktigt att anpassa processen under arbetets gång. Man ska inte hålla fast vid något om det inte fungerar. Teamet behöver förstå att de ska lyfta problem med processen, verktygen eller kommunikationen och vara ärliga om dem. Då kan man hitta sätt att minska problemen, anpassa arbetet och föra projektet framåt.

Ben Aston:

Jag tror att flexibiliteten är nyckeln till framgång. Projektledare och teammedlemmar kan ibland säga: ”Så fungerar inte scrum”, ”Det där är inte agilt” eller ”Det där är för mycket vattenfall.” Men egentligen spelar det mindre roll vad något kallas. Det viktiga är vad som fungerar bäst för teamet, projektet och kunden. Det gäller att inte vara dogmatisk. Med det team vi har och det arbete vi behöver göra – vilket är det bästa sättet att leverera?

På sätt och vis uppfinner man hjulet på nytt, men alla projekt är olika. Att försöka tillämpa en enda process eller metod på allt är mycket svårt, förutom när man arbetar med underhåll eller små löpande funktionsuppdateringar. Då kan det vara klokt att standardisera. Men när man kastas in i ett nytt projekt för en ny kund tycker jag att det mesta är tillåtet.

Vi har pratat om vem: att sätta samman teamet och intressenterna. Vi har pratat om hur: att navigera i processen och vara flexibel. När det gäller början av projektet kan vad vi faktiskt gör och levererar vara en av de svåraste frågorna. Ofta ärver man en mycket lös arbetsomfattning från ett säljteam eller en lös uppsättning kundkrav. Hur försöker du skapa tydlighet kring projektet eller produkten och komma fram till: ”Okej, låt oss enas om att vi ska leverera det här”?

Suze Haworth:

Det beror återigen på typen av projekt. Idealt vill man inte att allt ska vara helt svart eller vitt i början, eftersom saker förändras så mycket. Man kan annars hamna med något helt annat längre fram. Jag föredrar omfattningar som tillåter förändring och där leveranserna inte är helt låsta från början. Samtidigt finns det projekt som är mycket fasta. För att avgöra vad som gäller måste man börja prata med kunden och få tydliga krav. Man behöver förstå användarnas behov, verksamhetens behov och projektets sammanhang.

Därefter behöver man utveckla kraven tillsammans med teamet. Det handlar återigen om tidig delaktighet – inte bara med en person, utan med flera disciplinansvariga om teamet inte är sammansatt, eller med flera teammedlemmar. Man går igenom projektets omfattning och krav och definierar vissa ramar för vad projektet kan bli.

Ben Aston:

I de tidiga sessionerna där man försöker definiera vad man faktiskt ska göra tycker jag att det är bra att samla människor i ett rum under en halvdag, med en whiteboard, post-it-lappar och liknande. På en hög nivå försöker man utforma lösningen. Jag försöker skapa en gemensam förståelse och samsyn, eftersom människor ofta har olika uppfattningar om vad saker betyder i början av ett projekt. När man ritar upp saker och sätter upp dem på väggen tvingas man ha samtal. Någon kan säga: ”Jag trodde att det betydde det här”, medan någon annan säger: ”Nej, så är det inte.” Då börjar man reda ut eller åtminstone identifiera alla områden där tvetydighet finns, så att man kan gå tillbaka till kunden och föreslå olika angreppssätt.

Den övergripande bilden av projektet och att få alla på samma sida är mycket värdefull. Om man fotograferar whiteboarden blir den något som alla kan återvända till. Den visar hur delarna hänger ihop och vad vi ska leverera. Att på en övergripande nivå beskriva lösningens struktur och sätta en första riktning gör det lättare att se var projektet börjar och slutar. Det minskar osäkerheten kring hur långt man ska gå och hur mycket man ska göra. Man definierar ramarna för projektet och går sedan vidare till upptäcktsarbetet.

Suze Haworth:

Absolut. Sådana workshoppar är mycket bra. Att samla människor i ett rum, diskutera och definiera saker är värdefullt även om sakerna förändras senare. Det är också bra att göra detta tillsammans med kunden. Det är ett mycket bra sätt att starta ett projekt och ger en bättre förståelse för hur kunden ser på projektet. Kunden kan samtidigt se hur ni tänker. Man kan börja med en intern workshop och sedan ta den vidare till kunden i halvdagssessioner.

Ben Aston:

Vi har alltså pratat om vad vi behöver hantera: vem, alltså människorna och teamet; hur, alltså processen och metoden; och vad, alltså att börja skissa på lösningen och strukturen. Vi kan också börja skissa på budget, tidsplan och framgångsmått. Att ha allt på en stor whiteboard i början är användbart även om det förändras senare.

Men ibland initierar man projektet och försöker utforma en lösning innan projektet faktiskt har godkänts. Då uppstår frågan hur mycket som är för mycket. Hur långt ska man gå? Gör man så mycket som möjligt eller är man mer försiktig och gör tillräckligt för att föra projektet framåt? Ofta har man inte ett fullständigt godkännande, men vet samtidigt att projektet aldrig kommer att nå leveransdatumet om man inte arbetar vidare. Hur hanterar du risken att gå för långt och fastna i ett sidospår jämfört med risken att vara för försiktig?

Suze Haworth:

Jag lutar nog åt det mer försiktiga hållet, men är samtidigt helt öppen. Om kunden dröjer med att godkänna något eller går fram och tillbaka kring omfattningen behöver man se till att de förstår eventuella tidsförskjutningar och hur de kan påverka hela projektet. Man måste vara medveten om riskerna med att saker inte är fastställda innan man startar formellt.

Samtidigt tycker jag att det är bra att börja driva arbetet framåt och tänka igenom saker. Även med ett försiktigt angreppssätt kan man göra precis tillräckligt för att hålla projektet lite i rörelse. Det behövs ett momentum i början av ett projekt. När teamet engageras och börjar prata om vad man ska bygga eller utforma blir de entusiastiska. Om det sedan saktar ner och stannar av kan teammedlemmar och ibland även kunder börja rikta uppmärksamheten mot annat. De blir mindre engagerade och distraherade. Därför är det bra att hålla momentumet vid liv och fortsätta med något.

Ben Aston:

Låt oss prata om några av de utmaningarna. En typisk utmaning är brist på momentum i början av projektet. När människor får höra om ett projekt men inget händer, eller när projektet stannar på grund av oklarheter eller obesvarade frågor, vad gör man då?

Suze Haworth:

Det är svårt, eftersom personer kanske redan är bokade på projektet utan att ni officiellt har fått klartecken. Då kan ni inte låta dem arbeta fullt ut. Men om ni har lite tid som kan användas är det viktigt att låta projektteamet börja försiktigt. Gör precis tillräckligt för att behålla momentumet genom att hålla dem lite engagerade. Om det handlar om bakgrundsresearch, befintlig data, konkurrenter eller liknande kan man börja tankeprocessen. Det är bra att hålla dem involverade på en lägre nivå tills arbetet officiellt kan börja.

Ben Aston:

Även ett kort möte med teamet kan hjälpa. Man kan säga: ”Jag vet att vi trodde att projektet skulle starta den här veckan. Det gör det inte, men här är den senaste informationen.” Då hålls teamet engagerat och projektet försvinner inte helt från deras medvetande.

Suze Haworth:

Det finns nästan inget värre än att helt tystna om något och sedan dyka upp tre veckor eller en månad senare och säga: ”Bra, nu kan vi börja.” Fortsätt involvera teamet i det ni diskuterar med kunden i bakgrunden. Berätta vad som händer, varför det är försenat, när det ska starta och vad ni kan göra under tiden. Håll helt enkelt samtalet levande.

Ben Aston:

En annan situation som många projektledare möter är att ta över ett projekt halvvägs. Då ärver man någon annans plan för människor, process och produkt, men ansvaret för leveransen blir ens eget. Vilka råd har du för att skapa ordning i det kaoset?

Suze Haworth:

Det är en av de största utmaningarna, eftersom man sällan är involverad från projektets allra första början. Den delen sker ofta på säljnivå eller när säljteamet definierar projektet. Det hanteras ofta av en projektledningschef, leveransansvarig eller andra teammedlemmar. Många projekt man arbetar med kommer därför från någon annan och har redan fastställda förväntningar. Man arbetar kanske med kostnader som redan har godkänts och en mycket lös omfattning som måste anpassas till budgeten.

Det handlar om att ta de ramar som redan finns och förstå var det finns flexibilitet och handlingsutrymme. Om kostnaden redan är fastställd behöver man granska omfattningen och vad som realistiskt kan levereras. Om projektet har sålts in för stort i förhållande till kostnaden måste man vara realistisk. Annars kommer man inte att kunna leverera. Se var man kan vara flexibel och var man behöver prata om omfattning eller tidsplan.

Om man tar över ett projekt halvvägs, efter att en annan projektledare redan startat det, är två saker särskilt viktiga. Först ska man samla in så mycket information som möjligt om projektet, vad som har hänt, vad som har levererats hittills och om kunden. Därefter bör man nästan göra en omstart. Ha en ny, mindre uppstart även om projektet redan pågår. Samla teamet och ha ett möte med kunden. Se till att alla förstår att detta är en ny startpunkt. Det är viktigt även om människor tycker att de redan har gjort detta en gång. Det är ett bra sätt att föra projektet framåt, förstå vad som har hänt och vad som inte har fungerat, samt avgöra vad som behöver göras annorlunda och vad som ska fortsätta.

Ben Aston:

Jag tycker att den omstarten är viktig. Att ha självförtroendet att starta om är kraftfullt. När man kommer in i ett projekt vet man kanske ingenting i början. Men genom att ställa svåra och potentiellt dumma frågor öppnar man ofta upp en mängd oklarheter som även andra i teamet har. När projektet fortskrider börjar människor skapa antaganden som inte dokumenteras. Även om man börjar med en whiteboard-session kan människors förståelse börja glida isär igen. En omstart där man vågar fråga: ”Det här kanske är en dum fråga, men hur fungerar detta och hur hänger det ihop med det andra vi bygger?” öppnar nästan alltid upp frågor, problem och latenta utmaningar som ingen ännu har tänkt på.

Suze Haworth:

Var aldrig rädd för att ställa många frågor. Jag har alltid sagt det, och jag säger det till nya projektledare: ställ frågor. Var inte rädd för att låta dum. Det är mycket bättre att ställa frågorna och ta reda på det man behöver veta än att vara tyst och få en överraskning senare. Ställ många frågor.

Ben Aston:

Det är goda råd för projektinitiering i stort. Konsten att initiera projekt väl handlar i grunden om kommunikation. Det handlar om att ställa de svåra frågorna som ingen riktigt vill ställa men som alla vet behöver ställas. Man måste ha självförtroendet att ställa svåra, obekväma och irriterande frågor, eftersom det är där tydligheten börjar växa fram. När saker definieras tydligare blir projektet smidigare och mindre arbete och ansträngning går till spillo. Alla får en tydligare bild av den gemensamma riktningen. Suze, tack så mycket för att du var med oss. Det har varit fantastiskt att ha dig här.

Suze Haworth:

Tack. Det har varit fantastiskt.

Ben Aston:

Som en av våra DPM-experter kommer Suze också att medverka i vår kommande kurs, som börjar i februari. Den heter ”Mastering Digital Project Management” och är en sju veckor lång intensivkurs med interaktiva videolektioner, panelsamtal och möjlighet till coachningssessioner. Om du vill förstå mer om hur du kan förbättra projektinitieringen och starta projekt rätt kan du gå till DPMSchool.com och anmäla dig innan kursen blir full. Om du vill bidra till samtalet om projektinitiering och hur vi kan göra det bättre kan du kommentera inlägget. Besök också resurssektionen på DigitalProjectManager.com för att gå med i vårt Slack-team. Där hittar du många samtal om projektinitiering och projektledning. Tack för att du lyssnade.