Start dine projekter rigtigt (med Suze Haworth)

Læs transskriptionen:

Vi afprøver et program til at transskribere vores podcasts. Tilgiv venligst eventuelle stavefejl, da robotten ikke er korrekt 100 % af tiden.

Ben Aston:

Velkommen til DPM-podcasten, hvor vi går videre end teori for at give ekspertråd om projektledelse, så du kan lede bedre digitale projekter. Tak, fordi du lytter med. Jeg er Ben Aston, grundlægger af The Digital Project Manager.

Vi ved alle, at begyndelsen på et projekt er afgørende for dets succes, men det kan være en meget vanskelig periode. Der er masser af uklarhed. Der er masser af forvirring. Der er stor uenighed og en hel del usikkerhed. Som projektledere er det vores opgave at få projektet i gang og holde det i gang – og ekstra point, hvis vi rent faktisk begynder at lede projektet i den rigtige retning. Men hvad kan vi gøre for at sikre, at vi sejler i den rigtige retning? At vi kommer godt fra start? Det handler dagens podcast om. Så lyt med for at finde ud af, hvordan du kan få dine projekter godt fra start.

I dag har jeg selskab af Suze Haworth. Hej, Suze.

Suze Haworth:

Hej.

Ben Aston:

Suze er en af vores faste DPM-eksperter hos The Digital Project Manager. Hun arbejder som freelance seniorprojektleder inden for digitale projekter i London. Suze, vil du ikke fortælle lidt om nogle af de projekter, du har arbejdet på for nylig?

Suze Haworth:

Jo. Jeg er faktisk freelanceprojektleder. For nogle uger siden afsluttede jeg en kontrakt, som havde været ret langvarig, hos et bureau. Jeg havde to centrale roller der. Den ene var mere en programdirektørrolle på tværs af en kunde. Det var for Specsavers, som er et meget stort britisk detailbrand inden for briller, og de findes også i Norden og Australien. Jeg ledede en seniorprojektleder på tværs af Specsavers' kreative arbejde, brugeroplevelse og digitale løsninger. Det var altså et ret stort arbejdsprogram. Derudover arbejdede jeg på et projekt for Ikea. Det var et projekt, hvor vi skulle designe og bygge en prototype til et designsystem for brandet.

Ben Aston:

Spændende. Så Specsavers var mere et projekt inden for e-handel og konverteringsoptimering?

Suze Haworth:

Ja. Det afhang virkelig af markedet, men de sælger faktisk normalt ikke briller online på grund af forskellige regler. En stor del af arbejdet handlede derfor om at få folk til at bestille tid og besøge butikkerne. Men ja, det var i høj grad konverteringsoptimering, som du siger.

Ben Aston:

Hvad var vanskeligt ved de projekter? Hvilke udfordringer håndterede du i selve projektet, med kunden eller med teamet? Jeg synes altid, det er interessant for folk at høre, at andre har lignende problemer. Hvad var svært?

Suze Haworth:

Med Specsavers' arbejdsprogram var det faktisk et meget interessant tidspunkt, da jeg begyndte, fordi jeg startede i marts, som var begyndelsen på det nye år, og vi gik over til en helt ny arbejdsform. Tidligere havde vi arbejdet som designbureau sammen med deres udviklingsbureau, og vi havde siddet i alle deres scrumteams. Vi havde haft en designer og en UX-medarbejder i hvert scrumteam på tværs af arbejdsområderne. Vi besluttede at fjerne alle vores designere og UX-medarbejdere fra scrumteamene, samle dem hos os som ét team og derefter gå over til en mere parallel proces. Vi kørte det, vi kaldte et opdagelsesspor, næsten oven over leveringssporet, som i højere grad var det scrum-baserede udviklingsteam.

Det gav os plads til brugertest, udforskning, hypoteser og antagelser samt til at teste dem med brugerne. Vi lavede også langt mere research og arbejdede med data, så vi fik bedre grundlag for at levere det, brugerne ønskede. Det gav os større handlefrihed til rent faktisk at levere løsninger, som brugerne havde brug for. Det var derfor et meget interessant tidspunkt at indføre den nye arbejdsform og sikre, at den fungerede. Det var også en udfordring, men virkelig spændende.

Ben Aston:

Var din rolle så … Hvem havde rollen som produktejer? I havde disse to parallelle arbejdsstrømme. Den ene handlede om strategi, UX og design, og jeg går ud fra, at det var dem, der udførte brugertests for at identificere brugernes behov. Derefter blev behovene prioriteret, nogle blev sendt videre til UX- og designsporet, og til sidst røg de ned i udvikling. Var det sådan, det fungerede?

Suze Haworth:

Ja. Det, vi oplevede, var, at når designeren og UX-medarbejderen sad i scrumteamet og arbejdede inden for de to uger, var det meget begrænsende for dem. Meget af tiden blev brugt på de mere tekniske aspekter. De endte med at sidde i lange sprintplanlægningsmøder, hvor de kun var involveret i mindre dele, eller de deltog i daglige statusmøder og andre møder, hvor der blev talt meget om fejl. I stedet for at fokusere på kundernes faktiske behov blev arbejdet mere teknologidrevet. Derfor besluttede vi at flytte dem ud og arbejde på et spor oven over udviklingen, så vi fik tilstrækkelig tid. Det gik stadig hurtigt, men vi kunne se på eksisterende data, eksisterende research eller ny research, vi havde lavet. Derefter identificerede vi antagelser og hypoteser om, hvordan vi kunne løse kundernes problemer.

Så kunne vi hurtigt lave UX-design, prototyper eller det, der passede til det konkrete behov, og få det foran kunderne. De kunne validere det, før det faktisk blev sendt videre til levering. På den måde kunne vi strømline udviklingen, så vi ikke byggede ting, kunderne ikke ønskede. Vi forsøgte at opdatere design- og UX-beslutninger, før arbejdet kom ind i sprintene. Vi involverede stadig tekniske medarbejdere i opdagelsessporet, men i højere grad for at sikre, at løsningen kunne gennemføres teknisk, efter at vi havde fastslået, hvad kunden ønskede, og at de kunne lide den funktion, vi havde designet. Det handlede altså både om at strømline processen og om at levere det, kunden havde brug for, frem for blot det, der kunne bygges.

Ben Aston:

Jeg tror, det er en udfordring for mange bureauer, der forsøger at arbejde med scrum. Scrum er tydeligvis ikke den eneste måde at gennemføre et agilt projekt på, men det virker ofte som den almindeligt accepterede regel, at man skal bruge scrum. En stor udfordring ved scrum i et bureau er, hvad UX- og designfolk egentlig skal lave i sprintet. En mulighed er, at UX og design ligger et par sprint foran udviklingen, men så er intet færdigt. Ideen med et sprint er, at man ved slutningen har udviklet noget, der kan leveres og opfylder acceptkriterierne. Det er meget svært at nå strategi, UX-design og udvikling af en funktion på to uger.

Derfor kan jeg godt lide ideen om at køre dem som to parallelle arbejdsstrømme. Når tingene er valideret, kan produktejeren sende dem ned i udviklingsbackloggen. Så har man to forskellige backlogs: en strategisk backlog, hvor man spørger, om det er det rigtige at gøre, og en anden, hvor man ved, at det er det rigtige, fordi det er blevet valideret. Derefter kan man bygge det.

Suze Haworth:

Ja, præcis. Det betyder, at man bygger funktioner, som man har valideret, at kunderne ønsker. Det giver langt mindre spild og gør processen mere effektiv.

Ben Aston:

Godt. Lad os tale om projektinitiering og om faktisk at starte projekter. Var du involveret fra begyndelsen i Ikea- eller Specsavers-projekterne?

Suze Haworth:

I Specsavers-projektet var den nye arbejdsform en del af et fast team, som var planlagt for hele året med en bestemt teamsammensætning. Jeg kom faktisk ind, efter at arbejdsformen var blevet løst defineret, og efter at arbejdsomfanget var blevet beskrevet. Det er en af de udfordringer, jeg skriver om i min artikel: at overtage noget eller et projekt, som allerede er startet eller afgrænset af en anden. Jeg overtog det kort efter, at det var blevet afgrænset, men da arbejdsformen kun var løst defineret. Da vi begyndte at gennemføre den, viste det sig, at den skulle justeres og ændres. Den udviklede sig en del fra det oprindelige forslag, fordi man opdager ting, der ikke fungerer, når man begynder at arbejde på en bestemt måde. Man er nødt til at justere og tilpasse undervejs.

Ikea-projektet blev gennemført i etaper. Jeg arbejdede heller ikke på projektets første etape, men kom ind i etape to. Projektet var altså allerede startet, da jeg begyndte.

Ben Aston:

Det er ofte sådan med projekter, vi overtager som projektledere. Vi kommer tit ind, ikke helt fra begyndelsen, men et stykke inde. Det kan øge forvirringen. Som projektleder bliver man bragt ind i et projekt, der er overdraget fra forretningsudvikling, kundeansvarlige eller salg, og man arver noget, der er planlagt, men ikke fuldt ud planlagt. Der er en vis usikkerhed. Når vi taler om projektinitiering, handler det derfor også om at overtage et projekt på et tidspunkt efter begyndelsen.

Lad os tale om de ting, du nævnte i din artikel: det, man skal styre, nemlig menneskerne, processen og produktet, og hvordan man skaber overensstemmelse og klarhed om dem. Det er altså hvem, hvordan og hvad. Lad os begynde med menneskerne. Når du overtager eller starter et projekt, hvad forsøger du så at gøre ud fra et menneskeligt perspektiv?

Suze Haworth:

Der er nogle få centrale grupper eller personer, man skal tænke på i et projekt. Først og fremmest teamet. Hvem skal arbejde på projektet? I initieringsfasen definerer man, hvem der skal arbejde på projektet, og forsøger at booke dem. Det er vigtigt ikke kun at se på, hvem der er ledig, men også på, hvem der passer til projektet. Man skal se på deres kompetencer, arbejdsform, projekttype og den kunde, man arbejder med.

Hvis man kender teammedlemmerne, er det vigtigt at forstå, hvem der arbejder bedst sammen. Det kan selvfølgelig være en luksus, og det kan ende med at afhænge af, hvem der er tilgængelig, men det er godt at tænke over fra starten. Selv hvis man er nødt til at bruge bestemte personer, kan det hjælpe senere at vide, hvordan de arbejder.

Det er også vigtigt, at de personer, der skal arbejde på projektet, bliver involveret fra begyndelsen. Efter mange års arbejde med designere, udviklere og kvalitetssikringsfolk har jeg oplevet, at de fleste – hvis ikke alle – hader at blive holdt udenfor fra starten og derefter få noget udleveret, når alt allerede er defineret og besluttet, og få besked på: “Kan du ikke bare designe det her?” eller “Kan du ikke bare bygge det?” Når de mister enhver form for selvbestemmelse og blot får at vide, hvad de skal gøre, opstår der problemer.

Hvis man har tid og budget, er det derfor en god idé at involvere dem lidt fra begyndelsen. Efter det første interne opstartsmøde kan man tale med dem om deres syn på projektet, hvordan de gerne vil arbejde, og hvilke forventninger de har. På den måde bliver de involveret fra starten.

Ben Aston:

Det hænger sammen med bemandingen. Man bør så vidt muligt bemande teamet med de mennesker, man har brug for og ønsker, og engagere dem i projektet så tidligt som muligt, så man får deres opbakning. Folk reagerer ofte, når de overtager noget, som en anden har tænkt over, men ikke haft tid til at tænke ordentligt igennem. De spørger: “Hvorfor gør vi det her? Det er ikke sådan, jeg ville gøre.” Vi vil gerne have, at de tænker: “Ja, det her er mit projekt.” Når de føler ejerskab i stedet for at reagere på en andens halvfærdige idé, får vi normalt meget bedre resultater.

Suze Haworth:

Præcis.

Ben Aston:

Lad os gå videre til processen, for den hænger også sammen med det. Vi har et team og ved, hvem teamet er. Hvordan bruger vi så teamet til at levere projektet? Der er ofte uenighed om, hvordan projektet skal leveres, hvilken proces, metode og hvilke værktøjer man skal bruge. Hvad gør du for at skabe enighed i teamet og håndtere denne næsten uundgåelige uenighed?

Suze Haworth:

Man finder nok aldrig en ideel proces, der passer alle på alle måder. Der vil opstå spændinger omkring processen undervejs. Nogle gange arver man en proces, som bureauet eller organisationen allerede har, eller kunden bestemmer den. Hvis man selv får lov til at fastlægge den, kan man forsøge at finde noget, der passer til projektet og kunden. Hvis der allerede er defineret en proces, er det godt at gennemgå den på et internt opstartsmøde, forklare teamet, hvorfor den bruges, og forsøge at få deres opbakning tidligt.

Det er også vigtigt at tilpasse processen undervejs. Man skal ikke holde fast i noget, der ikke fungerer. Teamet skal vide, at de skal sige det højt, hvis der er problemer med processen, værktøjerne eller kommunikationen. Derefter kan man finde måder at mindske problemerne på og tilpasse arbejdet.

Ben Aston:

Fleksibiliteten er nøglen til succes. Projektledere eller teammedlemmer kan sige: “Sådan fungerer scrum ikke,” “Det er ikke agilt” eller “Det er for meget vandfald.” Men det afgørende er ikke, hvad det hedder. Det afgørende er, hvad der fungerer bedst for teamet, projektet og kunden. Man skal ikke være dogmatisk. Med det team, vi har, og det arbejde, vi skal udføre, hvad er så den bedste måde at levere det på?

Projekterne er forskellige, så det er svært at anvende én proces eller metode på alt. Standardisering giver mening ved vedligeholdelse eller løbende små funktionsopdateringer, men på et nyt projekt for en ny kunde bør man kunne tilpasse processen.

Når vi taler om begyndelsen af projektet, er “hvad” – det, vi faktisk laver og leverer – ofte noget af det vanskeligste. Man overtager måske et løst arbejdsomfang fra salg eller et løst kravsæt fra kunden. Hvordan skaber du klarhed om projektet eller produktet og når frem til: “Lad os blive enige om, at vi leverer dette”? Hvordan bliver tingene mindre grå og mere tydelige?

Suze Haworth:

Det afhænger igen af projekttypen. Ideelt set bør alt ikke være helt fastlåst fra begyndelsen, fordi ting ændrer sig, og man ellers kan ende med noget helt andet senere. Jeg foretrækker arbejdsomfang, der giver plads til ændringer, og hvor leverancerne ikke er fuldstændig fastlagt på forhånd. For at afklare det skal man tale med kunden og få tydelige krav. Man skal forstå brugerbehovene, forretningsbehovene og projektets kontekst.

Derefter skal kravene udfoldes sammen med teamet. Det handler igen om tidlig involvering – ikke kun af én person, men af flere faglige ledere eller teammedlemmer. Man gennemgår projektets omfang og krav med dem og fastlægger nogle rammer for, hvad projektet kan blive til.

Ben Aston:

I de tidlige sessioner, hvor vi forsøger at definere, hvad vi faktisk laver, synes jeg, det er nyttigt at samle folk i et rum en halv dag med en tavle, post-it-sedler og andre materialer. På et højt niveau forsøger vi at tegne løsningen. Målet er at skabe fælles forståelse og enighed, fordi folk i begyndelsen ofte har forskellige opfattelser af, hvad ting betyder. Når man tegner tingene og sætter dem op på væggen, tvinger det samtalen frem. På den måde opdager og afklarer man uklarheder, som man senere kan drøfte med kunden.

En samlet oversigt over projektet hjælper alle med at være på samme side. Man kan tage et billede af tavlen, som bliver et fælles referencepunkt. Det giver et overblik over, hvordan delene hænger sammen, og hvad vi leverer. Når man fastlægger en overordnet løsningsarkitektur, sætter man en foreløbig retning og begynder at afgrænse, hvor projektet starter og slutter. Det er nyttigt at beskrive projektets rammer og derefter gå ind i opdagelsesfasen med en fælles forståelse af, hvad projektet kan være.

Suze Haworth:

Helt sikkert. Workshops som den er gode til at samle folk og definere ting. Selv hvis tingene ændrer sig, har man sat en foreløbig retning. Det er også godt at lave den slags workshop med kunden. Det er en god måde at starte projektet på, fordi man får en bedre forståelse af kundens syn på projektet, og kunden kan se, hvordan man selv ser det. Man kan eventuelt starte internt og derefter tage resultatet med til kunden i en halvdagssession.

Ben Aston:

Vi har altså talt om, hvad vi skal styre: hvem – menneskerne, teamet og interessenterne; hvordan – processen og metoden; og hvad – løsningen og arkitekturen. Samtidig kan man begynde at skitsere budget, tidsplan og succeskriterier. Selv hvis det ændrer sig senere, er det nyttigt at have det hele på én stor tavle i begyndelsen.

Men nogle gange arbejder vi med projektinitiering, før projektet er godkendt. Hvor meget er for meget? Hvor langt skal man gå? Skal man gøre så meget som muligt, eller være mere forsigtig og kun gøre nok til at flytte projektet lidt fremad? Man har måske ikke fuld godkendelse, men ved, at projektet aldrig når leveringsdatoen, hvis man ikke arbejder videre. Hvordan håndterer du spændingen mellem at gå for langt og ende i et kaninhul og at være så forsigtig, at du ikke er langt nok fremme om nogle uger?

Suze Haworth:

Jeg hælder nok mest til den forsigtige tilgang. Hvis kunden er langsom til at godkende noget eller bliver ved med at ændre arbejdsomfanget, skal man sikre sig, at kunden forstår forsinkelserne, og hvordan de kan påvirke hele projektet. Man skal være opmærksom på risikoen ved, at ting ikke er fastlagt, og på hvornår man kan starte mere formelt.

Jeg mener dog stadig, at det er godt at skubbe arbejdet fremad og tænke over tingene. Selv med en forsigtig tilgang kan man gøre lige akkurat nok til at holde projektet lidt i bevægelse. Der skal være momentum i starten. Når teamet bliver involveret og begynder at glæde sig til det, der skal bygges eller designes, er det vigtigt at holde det engagement ved lige. Hvis arbejdet går i stå, kan teammedlemmer og kunder begynde at fokusere på noget andet og miste interessen. Derfor er det godt at holde momentum og få noget til at ske.

Ben Aston:

Lad os tale om nogle af disse udfordringer. Manglende momentum i begyndelsen er typisk. Projektet bliver præsenteret, men kommer ikke rigtigt i gang, eller også går det i stå på grund af uklarheder og ubesvarede spørgsmål. Hvad gør du, når tingene går helt i stå?

Suze Haworth:

Det er vanskeligt, fordi folk måske allerede er booket på projektet, men man har endnu ikke fået den officielle godkendelse, så de kan ikke rigtigt arbejde på det. Hvis man har lidt tid, der kan bruges, er det vigtigt at give projektteamet mulighed for at begynde forsigtigt. Man kan holde momentum ved at engagere dem en smule. Det kan være baggrundsresearch, gennemgang af eksisterende data, konkurrentanalyse eller lignende. På den måde starter man tankeprocessen og holder dem involveret på et lavere niveau, indtil arbejdet officielt kan begynde.

Ben Aston:

Selv et kort møde med teamet kan hjælpe. Man kan sige: “Vi troede, projektet ville starte i denne uge. Det gør det ikke, men her er den seneste status.” På den måde holder man teamet engageret, så projektet ikke forsvinder fra deres radar.

Suze Haworth:

Der er ikke noget værre end at tie helt stille om noget og så dukke op tre uger eller en måned senere og sige: “Fantastisk, nu kan vi begynde.” Det er bedre at holde teamet orienteret om samtalerne med kunden, fortælle hvad der sker, hvorfor der er en forsinkelse, hvornår arbejdet starter, og hvad man kan gøre i mellemtiden. Man skal bare holde samtalen i gang.

Ben Aston:

En anden udfordring, som mange projektledere møder, er at overtage et projekt midtvejs. Man arver en andens plan for mennesker, proces og produkt, men det bliver ens eget ansvar at levere. Hvilke råd har du til at skabe mening i det kaos?

Suze Haworth:

Det er en af de største udfordringer, fordi man sjældent er involveret helt fra begyndelsen. Det sker ofte på tilbudsstadiet, eller når salgsteamet definerer projektet. Det håndteres typisk af en projekt- eller leveringschef eller andre teammedlemmer. Mange projekter, man kommer til at arbejde på, kommer derfor et andet sted fra og har allerede fastsatte forventninger. Jeg har ofte arbejdet med foruddefinerede omkostninger, der er aftalt sammen med et meget løst arbejdsomfang, og derefter skullet tilpasse det til budgettet.

Man skal tage de eksisterende rammer og finde ud af, hvor der er fleksibilitet og handlemuligheder. Hvis omkostningen allerede er fastlagt, skal man se på omfanget og vurdere, hvad der realistisk kan leveres. Hvis projektet er blevet oversolgt, skal man tage den samtale. Hvis der er for meget arbejde til den pris, skal man være realistisk om, hvad der kan leveres. Man må undersøge, hvor man kan være fleksibel, og om der er behov for samtaler om omfang eller tidsplan.

Hvis man overtager et projekt midtvejs, som allerede er startet af en anden projektleder, er de to vigtigste ting at indsamle så meget information som muligt om projektet, hvad der er sket, hvad der er leveret, kunden og så videre. Derefter bør man næsten nulstille projektet. Hold endnu et lille opstartsmøde, selv om projektet er halvvejs. Saml teamet, hold et møde med kunden, og gør det tydeligt, at dette er et nyt udgangspunkt. Det er vigtigt, fordi det giver mulighed for at forstå, hvad der er sket, hvad der ikke fungerer, og hvad der skal ændres eller fortsætte.

Ben Aston:

Det kræver selvtillid at nulstille et projekt, men det er meget effektivt. Når man kommer ind i et projekt, ved man måske ikke noget i begyndelsen. Ved at stille vanskelige eller tilsyneladende dumme spørgsmål åbner man ofte for en masse uklarheder, som andre i teamet også har. Efterhånden som et projekt skrider frem, begynder folk at lave antagelser, der ikke bliver dokumenteret. Selvom man starter med en workshop ved tavlen, kan folks forståelse igen begynde at bevæge sig i forskellige retninger. En nulstilling, hvor man spørger: “Det er måske et dumt spørgsmål, men hvordan fungerer det her, og hvordan hænger det sammen med det andet, vi bygger?” kan afdække problemer, som ingen endnu har tænkt på, eller skjulte udfordringer, der skal håndteres. Det kan være meget nyttigt.

Suze Haworth:

Man skal bestemt aldrig være bange for at stille mange spørgsmål. Det har jeg altid sagt, og det siger jeg også til nye projektledere: Stil spørgsmål. Vær ikke bange for at lyde dum. Det er meget bedre at stille spørgsmålene og finde ud af det, man har brug for at vide, end at tie stille og få en overraskelse senere. Stil masser af spørgsmål.

Ben Aston:

Det er et godt råd til projektinitiering generelt. Kunsten at starte projekter godt handler i høj grad om kommunikation. Det handler om at stille de vanskelige spørgsmål, som ingen rigtigt ønsker at stille, men som alle ved er nødvendige. Man skal have modet til at stille vanskelige, akavede og irriterende spørgsmål, fordi det er sådan, man skaber klarhed. Når man får defineret tingene, kommer projektet til at forløbe langt mere gnidningsfrit, og der bliver mindre spildt arbejde, fordi alle får klarhed over den fælles retning. Suze, tusind tak, fordi du ville være med. Det har været fantastisk at have dig med.

Suze Haworth:

Tak. Det har været fantastisk.

Ben Aston:

Som en af vores DPM-eksperter medvirker Suze også i vores kommende kursus, som starter i februar. Det hedder “Mastering Digital Project Management” og er et syv ugers intensivt kursus med interaktive videolektioner, paneldiskussioner og mulighed for coaching. Hvis du gerne vil lære mere om, hvordan du kan blive bedre til projektinitiering og starte projekter rigtigt, så gå til DPMSchool.com og tilmeld dig, før kurset bliver fyldt op. Hvis du gerne vil bidrage til samtalen om projektinitiering og om, hvordan vi kan gøre det bedre, så skriv en kommentar til indlægget. Du kan også gå til ressourcesektionen på DigitalProjectManager.com og tilslutte dig vores Slack-team. Her finder du alle mulige samtaler om projektinitiering og projektledelse. Indtil næste gang: Tak, fordi du lyttede.