Start prosjektene dine riktig (med Suze Haworth)

Les transkripsjonen:

Vi prøver ut et program for å transkribere podkastene våre. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Ben Aston:

Velkommen til DPM-podkasten, der vi går utover teorien for å gi ekspertråd innen prosjektledelse for bedre digitale prosjekter. Takk for at du lytter. Jeg er Ben Aston, grunnleggeren av The Digital Project Manager.

Vi vet alle at begynnelsen på et prosjekt er avgjørende for prosjektets suksess, men det kan også være en svært krevende fase. Det er mye uklarhet, mye forvirring, mange uenigheter og stor usikkerhet. Som prosjektledere er det vår jobb å få prosjektet i gang og holde det i bevegelse – og aller helst begynne å lede prosjektet i riktig retning. Men hva kan vi faktisk gjøre for å sikre at vi setter kursen riktig? At vi starter på en god måte? Det er dette dagens podkast handler om. Fortsett å lytte for å finne ut hvordan du kan starte prosjektene dine riktig.

I dag har jeg med meg Suze Haworth. Hei, Suze.

Suze Haworth:

Hei.

Ben Aston:

Suze er en av våre faste DPM-eksperter hos The Digital Project Manager. Hun arbeider som frilansende senior prosjektleder for digitale prosjekter i London. Suze, kan du fortelle litt om noen av prosjektene du har jobbet med den siste tiden?

Suze Haworth:

Ja. Jeg er faktisk frilansende prosjektleder. For noen uker siden avsluttet jeg en kontrakt hos et byrå. Det var en ganske langsiktig kontrakt, og jeg hadde to hovedroller der. Den ene var mer som programdirektør for en kundekonto. Det var for Specsavers, som er en stor britisk merkevare innen detaljhandel for briller, og som også finnes i Norden og Australia. Jeg hadde ansvar for en senior prosjektleder på tvers av alt det kreative arbeidet og brukeropplevelsen for Specsavers innen digitale kanaler. Det var et ganske stort arbeidsprogram. I tillegg jobbet jeg med et prosjekt for Ikea. Det var et prosjekt for å utforme og bygge en prototype av et designsystem for merkevaren.

Ben Aston:

Spennende. Specsavers-prosjektet var altså mer et prosjekt innen netthandel og konverteringsoptimalisering?

Suze Haworth:

Ja, det varierte egentlig fra marked til marked. De pleier faktisk ikke å selge briller på nett på grunn av enkelte regler, så mye av arbeidet handlet om å få folk til å bestille time og besøke butikkene. Men ja, det var mye konverteringsoptimalisering, som du sier.

Ben Aston:

Hva var krevende i disse prosjektene? Hvilke utfordringer håndterte du i selve prosjektet, med kunden eller med teamet? Jeg tror alltid det er interessant for folk å høre at andre har lignende problemer. Hva var vanskelig?

Suze Haworth:

Når det gjelder arbeidsprogrammet for Specsavers, var det faktisk en veldig interessant tid da jeg startet. Jeg begynte i mars, som var starten på det nye året, og vi gikk over til en helt ny arbeidsmåte. Tidligere hadde vi arbeidet som et designbyrå ved siden av utviklingsbyrået deres, og vi hadde sittet i alle Scrum-teamene deres. Vi hadde en designer og en UX-person i hvert Scrum-team på tvers av arbeidsstrømmene. Vi bestemte oss for å ta alle designerne og UX-personene ut av Scrum-teamene og samle dem i ett team hos oss. Deretter gikk vi over til en prosess med to parallelle spor. Vi kjørte det vi kalte et oppdagelsesspor, nesten over leveransesporet, som var det mer Scrum-baserte utviklingsteamet.

Dette ga oss rom til bruker testing, utforskning, hypoteser og antakelser, samt å teste disse med brukere. Vi fikk også gjennomført mer forskning og samlet mer data som kunne brukes videre. Dermed fikk vi større handlingsrom til å levere ting brukerne faktisk ønsket. Det var en veldig interessant tid å innføre denne nye arbeidsmåten, sørge for at den fungerte og få den på plass. Det var en utfordring, men også veldig spennende.

Ben Aston:

Var rollen din da som produkteier?

Suze Haworth:

Ja, det var omtrent slik. Vi oppdaget at det å ha design- og UX-personer sittende i Scrum-teamet og arbeide innenfor toukersperioder var ganske begrensende. Mye tid gikk med til de mer tekniske sidene av arbeidet. De endte opp i lange sprintplanleggingsmøter, der de bare var involvert i mindre deler, eller de deltok i daglige statusmøter og andre møter der det hovedsakelig ble snakket om feil. I stedet for å tenke på kundens faktiske behov ble arbeidet mer teknologidrevet. Derfor tok vi dem ut av dette sporet og lot dem arbeide i et eget spor over utviklingsarbeidet. Da fikk vi tilstrekkelig tid, samtidig som vi beholdt raske leveranser. Vi kunne se på eksisterende data og undersøkelser, identifisere antakelser og formulere hypoteser om hvordan vi kunne løse kundens problemer.

Deretter kunne vi raskt lage UX-design eller prototyper, avhengig av behovet, og få dem foran kundene. På den måten kunne vi validere løsningene før de gikk inn i leveransen. Det gjorde utviklingen mer effektiv, fordi vi ikke bygget ting kundene ikke ønsket. Vi forsøkte å oppdatere design- og UX-beslutninger før arbeidet gikk inn i sprintene. Vi involverte fortsatt tekniske personer i oppdagelsessporet, men i større grad for å vurdere teknisk gjennomførbarhet etter at vi hadde fastslått hva kunden ønsket og likte. Målet var å effektivisere prosessen og samtidig levere det kunden trenger, ikke bare det som lar seg gjøre.

Ben Aston:

Jeg tror dette er en utfordring for mange byråer som prøver å bruke Scrum. Scrum er selvsagt ikke den eneste måten å gjennomføre et agilt prosjekt på, men det virker ofte som om Scrum oppfattes som den aksepterte regelen. En av de største utfordringene i et byrå er hva UX- og designpersoner faktisk skal gjøre i sprinten. Én løsning er at UX og design ligger noen sprinter foran utviklingen. Da oppstår spørsmålet om hva som egentlig blir ferdigstilt. En sprint skal ende med noe som kan leveres og som oppfyller akseptansekriteriene, og det er vanskelig å gå gjennom strategi, UX-design og utvikling av en funksjon på to uker.

Jeg liker derfor ideen om å kjøre to parallelle arbeidsstrømmer. Når ting er validert, kan produkteieren flytte dem inn i utviklingskøen. Da har man to ulike arbeidskøer: én strategisk kø der man stiller spørsmål om hvorvidt dette er riktig å gjøre, og én kø for ting man vet er riktige fordi de er validert. Da kan man bygge dem ferdig.

Suze Haworth:

Ja, nettopp. Det betyr at man faktisk bygger funksjoner som er validert og som kundene ønsker. Det gir mye mindre sløsing og en langt mer effektiv prosess.

Ben Aston:

La oss snakke om prosjektoppstart og det å starte prosjekter. Var du involvert i begynnelsen av Ikea- eller Specsavers-prosjektet?

Suze Haworth:

Når det gjelder Specsavers, var dette et team på fast avtale som var planlagt for året med en bestemt teamsammensetning. Jeg begynte etter at arbeidsmåten var løst definert og arbeidsomfanget var skrevet. Dette er en av utfordringene jeg skriver om i artikkelen min: å overta noe eller et prosjekt som allerede har startet eller er definert av noen andre. Jeg tok over ganske kort tid etter at det var definert, men da arbeidsmåten begynte å bli gjennomført, oppdaget jeg at den måtte justeres. Den måtte endres og utviklet seg ganske mye fra det som opprinnelig var foreslått. Når man faktisk begynner å arbeide på en bestemt måte, finner man ting som ikke fungerer, og som må justeres og tilpasses underveis.

Ikea-prosjektet var delt inn i faser. Jeg arbeidet ikke med den første fasen, men kom inn i fase to. Prosjektet var altså startet før jeg begynte.

Ben Aston:

Det er ofte slik med prosjekter vi overtar som prosjektledere. Vi kommer inn, ikke helt i starten, men et stykke ut i prosjektet. Det kan skape forvirring. Som prosjektleder blir du hentet inn i et prosjekt som er overlevert fra forretningsutvikling, kundeansvarlige eller salg. Du arver noe som er planlagt, men ikke fullt ut planlagt. Det er en viss grad av usikkerhet. Når vi snakker om prosjektoppstart, handler det derfor like mye om å overta et prosjekt på et tidspunkt etter at det har begynt.

La oss snakke om tingene du nevner i artikkelen din: å håndtere menneskene, prosessen og produktet, og å skape samsvar og tydelighet rundt dette. Det handler om hvem, hvordan og hva. La oss først se på menneskene. Når du starter eller overtar et prosjekt, hva forsøker du å gjøre med tanke på menneskene og teamet?

Suze Haworth:

Det er flere sentrale grupper eller personer man må tenke på i et prosjekt. Først kommer teamet. Hvem skal arbeide med prosjektet? I oppstartsfasen definerer du hvem som skal arbeide med det og forsøker å booke disse personene inn. Det er viktig å tenke på mer enn hvem som er tilgjengelig. Du må også vurdere hvem som passer til prosjektet: kompetansen deres, arbeidsmåten deres, typen prosjekt og hvilken kunde du arbeider med.

Hvis du kjenner teammedlemmene, er det viktig å forstå hvem som vil arbeide best sammen. Det kan selvsagt hende at du bare kan bruke dem som er tilgjengelige, men det er nyttig å tenke på dette tidlig. Selv om du må bruke bestemte personer, kan det å forstå hvordan de arbeider hjelpe deg senere dersom det oppstår problemer.

Det er også svært viktig å sørge for at personene som skal arbeide med prosjektet, involveres fra starten. Etter mange år med designere, utviklere og kvalitetssikrere har jeg erfart at noe av det de fleste, om ikke alle, misliker, er å ikke være en del av prosjektet fra begynnelsen. Hvis de ikke vet noe om prosjektet og bare får overlevert noe som allerede er definert, for så å få beskjed om å designe eller bygge det, blir det et problem. Når all selvbestemmelse tas bort og de bare får beskjed om hva de skal gjøre, oppstår det ofte vanskeligheter.

Hvis man har nok tid og budsjett, er det derfor en god idé å involvere dem litt fra starten. Etter det første interne oppstartsmøtet kan man spørre hva de synes om prosjektet, hvordan de ønsker at det skal fungere og hvilke forventninger de har. Da blir de involvert fra starten.

Ben Aston:

Jeg tror dette henger sammen med ressursplanleggingen. Så langt det er mulig bør man tidlig sette sammen teamet man trenger og ønsker, og involvere dem i prosjektet så tidlig som mulig for å få deres støtte. Når prosjektledere overtar noe som en annen har tenkt gjennom, men ikke hatt nok tid til å planlegge ordentlig, reagerer folk ofte. De spør hvorfor man gjør dette, og sier at det ikke er slik de ville gjort det. Vi ønsker at folk skal tenke at dette er deres prosjekt. Når de føler eierskap, i stedet for å reagere på andres halvferdige idé, får vi vanligvis mye bedre resultater.

Suze Haworth:

Ja, nettopp.

Ben Aston:

La oss gå videre til prosessen. Vi har teamet vårt og vet hvem de er. Hvordan skal vi bruke teamet til å levere prosjektet? Det er ofte uenighet i teamet om hvordan prosjektet skal gjennomføres, hvilken prosess man skal bruke, hvilken metodikk og hvilke verktøy man skal velge. Hvordan samordner du teamet og håndterer en slik uenighet?

Suze Haworth:

Man finner aldri en prosess som er perfekt for alle på alle måter. Det vil oppstå spenninger underveis i prosjektet. Noen ganger arver man en prosess som byrået eller organisasjonen allerede bruker, eller kunden kan bestemme den. Hvis man får mulighet til å velge selv, er det bra, fordi man kan finne noe som passer prosjektet og kunden. Hvis prosjektprosessen allerede er definert, er det nyttig å gå gjennom den i et internt oppstartsmøte, forklare hvordan den fungerer og hvorfor den brukes. Da kan man i det minste forsøke å få teamets støtte tidlig.

Det er også viktig å tilpasse prosessen underveis. Man må aldri holde fast ved noe som ikke fungerer. Teamet bør vite at de skal ta opp problemer med prosessen, verktøyene eller kommunikasjonen. Da kan man finne måter å redusere problemene på og tilpasse arbeidet.

Ben Aston:

Fleksibilitet er nøkkelen til suksess. Prosjektledere eller teammedlemmer kan si at noe ikke er slik Scrum fungerer, eller at noe ikke er agilt nok eller er for fossefallsbasert. Men det viktigste er hva som fungerer best for teamet, prosjektet og kunden. Man bør ikke være dogmatisk. Med teamet vi har og arbeidet vi skal gjøre, hva er den beste måten å levere på?

Prosjektene våre er forskjellige, og derfor er det vanskelig å bruke én prosess eller metode på alt. Det kan være fornuftig å standardisere ved vedlikeholdsarbeid eller små, løpende funksjonsoppdateringer. Men når man starter et nytt prosjekt for en ny kunde, må man kunne tilpasse seg.

Vi har snakket om hvem: teamet og interessentene. Vi har snakket om hvordan: prosessen og fleksibiliteten. Når det gjelder hva vi faktisk skal gjøre og levere, kan dette være noe av det vanskeligste i starten. Ofte arver man et løst arbeidsomfang fra salg eller et vagt sett med krav fra kunden. Hvordan forsøker du å rydde bort uklarheten rundt prosjektet eller produktet og komme frem til at dere faktisk er enige om hva som skal leveres?

Suze Haworth:

Det avhenger igjen av prosjekttypen. Ideelt sett bør ikke alt være for svart-hvitt i starten, fordi ting kan endre seg mye. Man kan ende opp med noe helt annet senere. Jeg foretrekker arbeidsomfang som åpner for endringer, og der leveransene ikke er fullstendig låst fra starten. For å avklare dette må man begynne å snakke med kunden og få tydelige krav. Man må forstå brukerbehovene, forretningsbehovene og konteksten for prosjektet.

Deretter må kravene konkretiseres sammen med teamet. Det handler igjen om tidlig involvering, ikke bare av én person, men av flere fagansvarlige eller teammedlemmer. Man må gå gjennom prosjektets omfang og krav med dem og definere noen rammer for hva prosjektet kan bli.

Ben Aston:

I de tidlige arbeidsmøtene der vi forsøker å definere hva vi faktisk skal gjøre, synes jeg det er nyttig å samle folk i et rom i en halv dag med en tavle, lapper og lignende. På et høyt nivå forsøker vi å utforme løsningen. Målet er å skape en felles forståelse og samsvar. I starten har folk ofte ulike oppfatninger av hva ting betyr. Når man tegner ting og fester dem på veggen, tvinger det frem samtaler. Noen sier kanskje at de trodde noe betydde én ting, mens andre har forstått det annerledes. Da kan man avklare eller identifisere hvor uklarhetene ligger, før man går tilbake til kunden med ulike mulige tilnærminger.

Det er nyttig å få oversikt over hele prosjektet, samle alle på samme side og ta et bilde av tavlen. Dette blir en felles referanse som viser hvordan delene henger sammen og hva som skal leveres. Ved å skissere den overordnede arkitekturen og markere en mulig løsning begynner man å avgrense hvor prosjektet starter og slutter. Da kan man definere rammene for prosjektet før man går inn i oppdagelsesarbeidet.

Suze Haworth:

Absolutt. Slike arbeidsmøter er svært nyttige. Det er bra å samle folk for å diskutere og definere ting. Selv om ting endrer seg, har man et utgangspunkt. Det er også nyttig å gjøre dette sammen med kunden. Det er en god måte å starte prosjektet på, og begge parter får bedre innsikt i hvordan den andre tenker. Man kan gjerne ha et internt møte først og deretter ta resultatet med til kunden i halvdagsmøter.

Ben Aston:

Vi har altså snakket om hva vi må håndtere: hvem, altså mennesker, teamet og interessentene; hvordan, altså prosessen og metodikken; og hva, altså løsningen og arkitekturen. Samtidig kan vi begynne å skissere budsjett, tidsplan og suksesskriterier. Å ha alt på én stor tavle i starten, selv om det senere vil endre seg, er svært nyttig.

Men i starten kan man være i ferd med å utforme en løsning før prosjektet faktisk er godkjent. Hvor mye er for mye? Hvor langt skal man gå? Bør man gjøre så mye som mulig, eller være mer forsiktig og gjøre akkurat nok til å flytte prosjektet videre? Man har kanskje ikke full godkjenning, men vet at prosjektet aldri vil nå leveringsdatoen uten mer arbeid. Hvordan håndterer du denne spenningen?

Suze Haworth:

Jeg er nok på den forsiktige siden. Hvis kunden utsetter godkjenningen eller stadig endrer arbeidsomfanget, må man sørge for at kunden forstår eventuelle forsinkelser og hvordan de kan påvirke hele prosjektet. Man må være oppmerksom på risikoen ved at ting ikke er avklart og at prosjektet ikke kan startes formelt.

Samtidig mener jeg det er bra å begynne å drive ting fremover. Selv med en forsiktig tilnærming kan man gjøre akkurat nok til å holde prosjektet litt i bevegelse. Det er viktig å opprettholde fremdriften i starten. Når teamet involveres og blir engasjert i det som skal bygges eller utformes, skapes det entusiasme. Hvis alt deretter stopper opp, kan både teammedlemmer og kunder miste interessen eller bli distrahert. Derfor er det bra å holde noe i gang.

Ben Aston:

La oss snakke om utfordringene. En typisk utfordring er manglende fremdrift i starten. Når folk får høre om et prosjekt, men det ikke skjer noe, eller når prosjektet stopper på grunn av uklarheter og ubesvarte spørsmål, hva gjør du da?

Suze Haworth:

Det er vanskelig, fordi folk kanskje allerede er satt av til prosjektet, mens man ennå ikke har fått den formelle godkjenningen. Da kan man ikke nødvendigvis la dem arbeide mange timer med prosjektet. Men hvis man har litt tid tilgjengelig, er det viktig å la teamet begynne forsiktig. Gjør akkurat nok til å holde fremdriften oppe og holde dem litt involvert. Det kan være bakgrunnsundersøkelser, gjennomgang av eksisterende data eller undersøkelser av konkurrenter. Begynn tankeprosessen og hold dem involvert på et lavere nivå til arbeidet kan starte formelt.

Ben Aston:

Selv et kort møte med teamet kan hjelpe. Man kan si at man trodde prosjektet skulle starte denne uken, men at det ikke gjør det, og forklare siste nytt. Da holder man teamet engasjert og sørger for at prosjektet ikke forsvinner fra oppmerksomheten deres.

Suze Haworth:

Det er ingenting verre enn å bli helt stille og så dukke opp tre uker eller en måned senere og si at man kan starte. Hold teamet involvert i samtalene med kunden i bakgrunnen. Fortell hva som skjer, hvorfor det er forsinkelser, når prosjektet skal starte og hva dere kan gjøre i mellomtiden. Fortsett å holde samtalen i gang.

Ben Aston:

La oss også berøre en situasjon mange prosjektledere møter: å overta et prosjekt midtveis. Da arver vi en annens plan for mennesker, prosess og produkt, men det blir vårt ansvar å levere. Har du noen råd for å skape orden i kaoset?

Suze Haworth:

Det er en av de største utfordringene. Man er ofte ikke involvert helt fra starten, fordi prosjektet begynner på tilbudsstadiet eller når salgsteamet definerer det. Dette håndteres gjerne av en leder for prosjektledelse, leveranse eller andre teammedlemmer. Mange prosjekter man arbeider med, kommer derfor fra et annet sted og har allerede etablerte forventninger. Jeg har ofte arbeidet med forhåndsdefinerte kostnader som er avtalt sammen med et svært løst omfang, og måttet tilpasse dette til budsjettet.

Det handler om å ta utgangspunkt i rammene du allerede har og finne ut hvor det finnes fleksibilitet og handlingsrom. Hvis kostnaden allerede er fastsatt, må du se på omfanget og vurdere hva som realistisk kan leveres. Hvis prosjektet er oversolgt og det er for mye for den avtalte kostnaden, må man være realistisk. Ellers vil man ikke klare å levere. Se på hvor du kan være fleksibel, og hvor du må ha samtaler om omfang eller tidsplan.

Hvis du overtar et prosjekt midtveis, etter at en annen prosjektleder har startet det, er de viktigste tingene å hente inn så mye informasjon som mulig. Finn ut hva prosjektet handler om, hva som har skjedd, hva som er levert, og hva som gjelder for kunden. Deretter kan du nesten begynne på nytt. Ha en ny, liten oppstart, selv om prosjektet allerede er halvveis. Samle teamet, ha et møte med kunden og gjør det tydelig at dette er et nytt startpunkt. Det er viktig, selv om folk føler at de allerede har gjort dette én gang. Det gir prosjektet ny fremdrift og gjør det mulig å forstå hva som har skjedd, hva som ikke fungerer og hva som bør fortsette.

Ben Aston:

Det krever selvtillit å starte på nytt, men det kan være svært kraftfullt. Når du kommer inn i et prosjekt og ikke vet noe, vil vanskelige eller tilsynelatende dumme spørsmål ofte avdekke mye uklarhet som også andre i teamet har. Etter hvert som prosjektet utvikler seg, begynner folk å gjøre antakelser som ikke er dokumentert. En ny gjennomgang kan avdekke problemer som ingen har tenkt på, eller skjulte utfordringer som må håndteres.

Suze Haworth:

Vær aldri redd for å stille mange spørsmål. Jeg sier alltid dette til nye prosjektledere: Still spørsmål. Ikke vær redd for å høres dum ut. Det er mye bedre å stille spørsmålene og finne ut det du trenger å vite, enn å tie og få en overraskelse senere.

Ben Aston:

Dette er gode råd for prosjektoppstart generelt. Kunsten å starte prosjekter godt handler i stor grad om kommunikasjon: å stille de vanskelige spørsmålene som ingen egentlig ønsker å stille, men som alle vet må stilles. Når man har mot til å stille vanskelige, ubehagelige og irriterende spørsmål, får man større tydelighet. Når ting defineres tydelig, går prosjektet langt smidigere, og det blir mindre bortkastet arbeid. Suze, tusen takk for at du ble med oss.

Suze Haworth:

Takk. Det var hyggelig å være med.

Ben Aston:

Som en av våre DPM-eksperter skal Suze også delta i vårt kommende kurs, som starter i februar. Det heter Mastering Digital Project Management og er et sju ukers intensivkurs med interaktive videoleksjoner, panelsamtaler og mulighet for veiledning. Hvis du vil lære mer om hvordan du kan gjennomføre prosjektoppstart bedre og starte prosjekter riktig, kan du gå til DPMSchool.com og melde deg på før kurset blir fullt. Hvis du vil bidra i samtalen om prosjektoppstart og hvordan vi kan gjøre dette bedre, kan du kommentere på innlegget. Du kan også gå til ressursseksjonen på DigitalProjectManager.com, bli med i Slack-teamet vårt og finne mange samtaler om prosjektoppstart og prosjektledelse. Takk for at du lyttet.