Bruk prosjektomfangsbeskrivelser for å redde skinnet (med Robyn Birkedal)

Les transkripsjonen:

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

Ben Aston:

Du sitter nervøs med telefonen i hånden og kaldsvetter. Kunden er sint. De truer på telefonen med å avbryte prosjektet og ikke betale for arbeidet. Og så langt har alt gått så bra. De var helt avslappet, og det var du også. De ville ha nettstedet sitt designet på nytt. Det hørtes enkelt ut. Og du brydde deg egentlig ikke om å skrive noe ned, fordi … vel, det føltes bare som om alle forsto det. Alle var avslappet, og nå er de ikke det lenger. Det de faktisk trodde de skulle få, var en ny merkevare i tillegg til det nye nettstedet. Nå har du vondt i magen fordi du vet at du rotet dette til. Ingenting ble skrevet ned. Og det er deres ord mot dine. Nå blir jeg bare stresset av å si dette. Så hvis du vil ha mye mindre stress, bør du fortsette å lytte til denne podkasten for å finne ut hvorfor omfangsbeskrivelser er så viktige, hvordan du skriver dem og hvordan du bruker dem i prosjektet ditt.

Takk for at du lytter. Jeg heter Ben Aston og er grunnlegger av The Digital Project Manager. Velkommen til DPM-podkasten. Vi har som mål å hjelpe prosjektledere med å lykkes og hjelpe mennesker som leder prosjekter, med å levere bedre. Vi er her for å hjelpe deg med å ta prosjektarbeidet ditt til neste nivå. Besøk thedigitalprojectmanager.com for å lære mer om opplæringen og ressursene vi tilbyr gjennom medlemskap. Denne podkasten er sponset av Clarizen, lederen innen programvare for styring av virksomhetsprosjekter og prosjektporteføljer. Besøk Clarizen.com for å lære mer.

I dag har jeg med meg Robyn. Robyn er en av våre faste DPM-eksperter. Og beleilig nok bor hun like i nærheten av stedet der jeg nylig leste. Hun liker emojier, lister og valper. Hun er en tidligere kokk som ble prosjektleder, med mer enn ti års erfaring fra prosjektledelse i byråer og oppstartsbedrifter. Hun kommer også snart til å være mer tilgjengelig for konsulentoppdrag. Så hvis du ser etter en innleid prosjektleder, kan du finne henne på LinkedIn. Men hei, Robyn, tusen takk for at du blir med oss i dag.

Robyn Birkedal:

Hei, Ben. Det er alltid hyggelig å være sammen med deg.

Ben Aston:

Jeg vil faktisk begynne med å gå tilbake til dette med lister og valper. Har du laget listen din i dag?

Robyn Birkedal:

Det har jeg. Jeg er virkelig litt av en nerd. Jeg har én liste over dagens viktigste mål. Jeg har én liste i planleggeren min. Og så har jeg også Google Kalender. Så tydeligvis trenger jeg tre forskjellige lister til enhver tid. Og det du ikke kan se bak meg, er kriminalitetsveggen min med post-it-lapper.

Ben Aston:

Og det er liksom arkivet over alle listene.

Robyn Birkedal:

Ting i forskjellige kategorier som jeg prøver å oppnå personlig og profesjonelt, eller bare ulike innholdsideer for deg.

Ben Aston:

Har du en valp sammen med deg også?

Robyn Birkedal:

Jeg har den åtte år gamle valpen min, men jeg elsker selvfølgelig hunder mye mer enn katter, og alle kan bare kritisere meg for det. Jeg er også mindre entusiastisk over emojier for tiden. Men jeg tror det var det ansiktet.

Ben Aston:

Jeg var slik i fjor.

Robyn Birkedal:

Jeg vet ikke.

Ben Aston:

Så lister er åpenbart viktig for deg. Du synes noen av dem er inspirerende. Men jeg er nysgjerrig på hvor du henter inspirasjon. Hva leser du? Hva konsumerer du akkurat nå for å bli inspirert og holde deg oppdatert?

Robyn Birkedal:

Dette er et flott spørsmål. Jeg føler at jeg kunne snakket i 30 minutter om dette akkurat nå. The Digital Project Manager er selvfølgelig en konstant kilde til inspirasjon. Jeg tok en kort pause fra å være så involvert i Slack-fellesskapet. Og nå som jeg er tilbake, har jeg på en måte savnet mange av vennene mine der. Det har vært en stor glede, men også lokalt, gjennom vennene mine og fellesskapet mitt. Jeg vil likevel trekke frem en av de virkelig flotte gruppene i Portland som jeg har vært involvert i gjennom årene. Den heter PDXWIT, som står for Portland Women in Technology. Jeg setter stor pris på dette fellesskapet, som har arrangert svært godt gjennomførte arrangementer for ferdighetsutvikling, mentorordninger og tilgang til jobber i ulike fellesskap. De har lært meg mye om mangfold og inkludering. Derfor oppfordrer jeg dere alle til å skape noe lignende eller besøke dem på pdxwit.org.

Ben Aston:

Det er kult. Og hva prøver du å bli bedre på? Vi har alle litt mer tid til rådighet for øyeblikket. Jeg føler at jeg blir overøst med mesterklasser, trening og alle slags ting. Men når du tenker på hva som inspirerer deg, hva blir du inspirert til å gjøre? Er det noe spesielt du jobber med, en ny hobby du holder på å begynne med, et nytt programmeringsspråk du lærer eller noe du går dypere inn i? Hva gjør du?

Robyn Birkedal:

Jeg har nylig begynt å sette meg inn i Drupal igjen etter å ikke ha jobbet med det på omtrent sju år. Så jeg prøver å finne ut hvor det står nå. Utover det tror jeg dette er noe, Ben, som du har kjent meg lenge nok til å vite at det føles som en ekte hemmelighet å dele høyt med deg. Jeg vurderer faktisk å ta flere sertifiseringer. Kanskje ta PMP, eller utforske noe som SAFe. Jeg må fortsatt finne ut nøyaktig hva det er, men jeg undersøker om det er noe jeg ønsker å gjøre fremover. Jeg vil bli mer kjent med disse metodikkene i stedet for å fortsette å være komfortabel med det jeg allerede kan.

Ben Aston:

Det er kult. Lykke til med det. Har du oppdaget noe annet nylig som gjør livet ditt bedre? De små tingene som gir deg et smil eller et øyeblikk med glede.

Robyn Birkedal:

Dette er også litt pinlig. Jeg vet ikke hvorfor jeg er så nervøs i dag, men jeg har virkelig likt å jobbe hjemmefra. I bakgrunnen setter jeg på én kanal på YouTube TV, som jeg abonnerer på. Det er en kanal som bare viser surfing. Jeg bor i Portland, og det tar halvannen time å komme til stranden. Jeg surfer ikke og kan ingenting om surfing, men jeg har likt å se på det. Nå er jeg visst blitt besatt av å se på surfemesterskap i bakgrunnen, og av så mange forskjellige personer, som Andy Irons og Kelly Slater. Det er bare den merkeligste nye tingen som gjør livet mitt bedre.

Ben Aston:

Hvem er favorittsurferen din?

Robyn Birkedal:

Definitivt Kelly Slater.

Ben Aston:

Vet du, han var her. Det var en god start som redningsplanke. Min påståtte berømmelse er at jeg surfet med Kelly Slater på Hawaii.

Robyn Birkedal:

Du kan ikke bare si det og tro at det fungerer.

Ben Aston:

Vi var på vei opp av vannet, og han var på vei uti sammen med kjæresten sin. Vi møttes og sa «hei, Kelly». Så vi surfet med ham.

Robyn Birkedal:

Ja, dere var i vannet samtidig.

Ben Aston:

Ja, altså …

Robyn Birkedal:

Det høres ut som om du var ute i de store bølgene sammen med Kelly.

Ben Aston:

Ja. Det er derfor. Det er min påståtte berømmelse. Men la oss gå tilbake til det alvorlige temaet og bort fra stranden, tilbake til omfangsbeskrivelser. La oss begynne med hvorfor. Jeg prøvde å forklare i begynnelsen hvorfor vi bør bry oss om omfangsbeskrivelser. Prosjekter går galt. Det oppstår misforståelser, og omfangsbeskrivelser kan redde skinnet vårt. Men la oss begynne med hvorfor du mener dette er viktig. Har du noen skrekkhistorier om å ikke ha omfangsbeskrivelser? Jeg snakket om det i introduksjonen. Hvorfor blir du engasjert av omfangsbeskrivelser?

Robyn Birkedal:

Absolutt. Bare det å høre introduksjonen din for noen øyeblikk siden fikk meg virkelig til å tenke på hvordan dette traumet kom tilbake, og hvordan det alltid vil komme tilbake. Omfangsbeskrivelser er svært viktige fordi det er der du sikrer at teamet og kunden har en tydelig forståelse av hva de overordnede kravene er. Til syvende og sist vil de definere hvordan du kan mislykkes, og hvordan det vil se ut. Det vi prøver å beskytte oss mot her, er å åpne for konflikt med kunden og det interne teamet, samtidig som vi prøver å samkjøre alle og unngå rettstvister.

Ben Aston:

Vi prøver altså å tydeliggjøre og samle forståelsen så mye som mulig. Jeg mener omfangsbeskrivelser er gode til å kodifisere denne forståelsen. Noen ganger kan vi tenke at alle er på samme side og at vi alle er venner. Det er faktisk ofte verre når man er venner, fordi alle kan anta at alle andre forstår hverandre. Og så finnes det lumske ord som «oppdatere» eller «fornye», som er svært tvetydige. Det omfangsbeskrivelsene gjør, er å redusere tvetydigheten i gråsonene og gjøre ting mye mer svart-hvitt.

Robyn Birkedal:

Absolutt. Selv i løpet av de ti årene jeg har jobbet med dette, har terminologien endret seg nesten hvert kvartal. Før vi virkelig snakker om hva omfangsbeskrivelser er og hvordan de fungerer, vil jeg bare si at det å skrive en omfangsbeskrivelse er svært undervurdert i denne rollen. Det er den tørreste delen av jobben. Og vanligvis er dette den vanskeligste delen av å starte prosjektet. Ingen vil ta eierskap til det. Det er noe du må gjøre. Men personlig elsker jeg det. Jeg er ganske nerdete, men tiden du legger ned i begynnelsen av prosjektet, sikrer en svært effektiv videre gjennomføring av prosjektet.

Ben Aston:

Definitivt. La oss snakke om dette på det mest grunnleggende nivået. For de som tenker «vent litt, hva er en omfangsbeskrivelse?» Hvordan vil du beskrive en omfangsbeskrivelse?

Robyn Birkedal:

Det finnes mange ulike begreper vi kan bruke, slik du nevnte, Ben, med «fornyelse» kontra «redesign». Og hvordan skiller det seg fra en arbeidsbeskrivelse? Jeg tror vi kan diskutere dette frem og tilbake. Men slik jeg forstår det, er en omfangsbeskrivelse ganske enkelt en måte å beskrive arbeidet du har sagt deg enig i å levere. Den beskriver på det mest grunnleggende nivået prosjektets begrensninger. Vi skal altså snakke om hva som skal leveres, hva som ikke skal leveres, hvilke antakelser som gjelder for leveransen, og eventuelle ytterligere avklaringer.

Ben Aston:

Omfangsbeskrivelsen brukes altså til å beskrive arbeidet. Vi definerer omfanget og kodifiserer det. Vi sier: «Dette er det vi gjør. Dette er det vi ikke gjør.» Og noen ganger, hvis vi ikke kan definere nøyaktig hva vi gjør eller ikke gjør, beskriver vi i det minste prosessen og hva den prosessen kan innebære. Folk spør noen ganger om de trenger en arbeidsbeskrivelse, eller hvordan en smidig arbeidsbeskrivelse ser ut. Dette er en stor utfordring. Vi må fortsatt definere hva vi gjør og ikke gjør. Men i stedet for å definere leveransene kan vi rette oppmerksomheten mot resultatet vi prøver å oppnå, og prosessen vi skal følge for å komme dit.

Robyn Birkedal:

Absolutt. Det finnes noen grunnleggende prinsipper man bør følge, og vi skal snakke om noen tips. Men det finnes ikke én mal som alle prosjektledere følger. Det finnes ikke én løsning alle bruker, og du kan ikke bare kopiere og lime den inn. Alle virksomheter er forskjellige. Alle prosjekter og programmer er forskjellige. Det vi ønsker, er ganske enkelt en konsekvent praksis som beskytter deg. Eller, som jeg skrev i artikkelen, som redder skinnet ditt. Du må beskytte teamet ditt og forretningsinitiativet.

Ben Aston:

Jeg vil gjerne høre om du har noen historier om situasjoner der du ikke definerte omfanget så fullstendig som du burde, og hva som skjedde.

Robyn Birkedal:

Dette er litt av en glatt bakke, fordi jeg i tidligere roller har blitt rådet til å ikke ta med for mange detaljer, ettersom det potensielt kunne åpne for juridiske søksmål. Hvis du tar med for mye, kan det bli et problem. Men der jeg har hatt mest suksess, er ved å ta med så mange detaljer som mulig. Enten det er fossefallsmetodikk eller smidig metodikk: Definer alt i omfangsbeskrivelsen og kryssjekk den deretter med kunden. Du kommer ikke alltid til å gjøre det perfekt, og kunden kan oppdage at noe er annerledes enn de trodde. Det handler om å navigere i dette landskapet og legge ned arbeidet på forhånd så godt du kan. Men ja, vi har alle verre historier.

Ben Aston:

Min skrekkhistorie handler om en stor kunde innen forbrukerelektronikk. Vi laget noen spesialtilpassede animasjoner, og kunden ville forsikre seg om at vi hadde kjøpt rettighetene til animasjonen. Det gjorde vi. Jeg tror vi kjøpte en femårig medieutløsning slik at vi kunne bruke animasjonen på den måten vi ønsket i fem år. Dette var bare en animasjon for én kampanje, så vi trengte den i maksimalt ett år. Vi tenkte derfor at vi like gjerne kunne kjøpe fem år, i tilfelle vi ønsket å bruke den på nytt året etter.

Senere kom kunden tilbake og sa: «Vent litt. Jeg ba dere kjøpe rettighetene til dette.» Vi svarte at det hadde vi gjort. Men kunden ville ha rettighetene i all fremtid, slik at de kunne bruke animasjonen for alltid, i alle medier og formater. Vi hadde bare kjøpt fem år, og dette ble et stort problem. Animasjonsstudioet som hadde produsert materialet, visste at de satt med makten og kunne kreve hva som helst. Til slutt raknet hele kundeforholdet på grunn av én omfangsbeskrivelse som ikke var tilstrekkelig definert. Det handlet bare om hvor lenge tredjepartsrettighetene skulle gjelde. Disse tingene kan få enorme konsekvenser når en liten misforståelse oppstår. Noen ganger starter folk konflikter bare fordi de kan, og det var tilfellet her. Kunden trengte egentlig ikke rettighetene i all fremtid, men det var det de ville ha.

Dette er ting vi må ta svært alvorlig. De kan ikke bare velte prosjektet, men også hele kundeforholdet. La oss derfor snakke om hvordan man faktisk skriver disse omfangsbeskrivelsene og hvilken prosess man følger. Hvordan setter du dem sammen? Hvordan avgjør du hvordan omfanget skal formuleres når du på den ene siden ikke vil gjøre det for spesifikt, men på den andre siden ønsker å dekke alle mulige scenarioer?

Robyn Birkedal:

Før vi snakker om det, vil jeg si tre ting. For det første er jeg ikke advokat og gir ikke formelle juridiske råd. Jeg snakker bare om mine erfaringer, hovedsakelig fra reklamebransjen. For det andre vil jeg sende deg litt medfølelse for den situasjonen, for den gjorde vondt. Jeg kjenner godt til vilkår om bruk i all fremtid. Kontrasten mellom ett år, fem år og all fremtid er dramatisk, og det ligger en viktig lærdom i det.

Det jeg vil gå tilbake til, er at omfangsbeskrivelser kan være mange forskjellige ting i arbeidsmiljøene våre. Vi kan kalle dem estimater, avgrensede arbeidsbeskrivelser, kontrakter eller tilbud. Det er i praksis en samling av elementer som kan inngå i flere ulike formater. Noen av navnene jeg har brukt tidligere, er arbeidsbeskrivelse, kontrakt og tilbud. Men de er ikke en konfidensialitetsavtale, en hovedtjenesteavtale, en uavhengig oppdragsavtale eller en servicenivåavtale. Du kan lese mer om definisjonene i artikkelen min. Poenget er at dette ikke er det eneste du må levere til kunden. Det er bare én komponent.

Ben Aston:

Definitivt.

Robyn Birkedal:

Tilbake til spørsmålet ditt: Hvordan skriver jeg dem? Hva er prosessen min?

Ben Aston:

Ja.

Robyn Birkedal:

Jeg har vanligvis brukt maler som allerede er levert av det interne teamet. Heldigvis har jeg jobbet på mange gode arbeidsplasser som allerede har hatt en mal tilgjengelig. Jeg oppbevarer også versjoner av tidligere arbeidsbeskrivelser i en personlig mappe, slik at jeg kan se hvordan jeg utformet en omfangsbeskrivelse for et merkevareprosjekt sammenlignet med et digitalt prosjekt, en fornyelse eller en redesign. The Digital Project Manager er selvfølgelig også en flott ressurs. Du har skrevet en god artikkel om hvordan man skriver en arbeidsbeskrivelse, og den inneholder også en mal.

Ben Aston:

Det er viktig å bygge opp sin egen bank med omfangsbeskrivelser som kan reduseres, gjenbrukes og resirkuleres. Måten vi beskriver leveransen på, følger ofte de samme parameterne. I et merkevareprosjekt vil vi for eksempel beskrive hvor mange konsepter vi utvikler, hvor mange revisjonsrunder vi har, hvordan kundens involvering og tilbakemeldingssløyfe ser ut, og hvilke endelige leveranser som inngår. Når vi stadig produserer samme type leveranser og følger samme prosess, kan omfangsbeskrivelsene ofte gjenbrukes ganske enkelt.

I innlegget finner du mange omfangsbeskrivelser på thedigitalprojectmanager.com/project-scope-statement. Noen er generiske og kan gjenbrukes i dine egne prosjekter ved at du bare endrer navnene. Andre er mer spesifikke. Det er også omfangsbeskrivelser som kan resirkuleres fra prosjekt til prosjekt, for eksempel hvem som skal betale for eller ha ansvar for lisensiering av bilder og videoer, hvor lang tid kunden har på å godkjenne eller gjennomgå materiale og gi samlet tilbakemelding, eller hvor mange godkjenningsrunder som inngår.

La oss snakke om gode og dårlige omfangsbeskrivelser. Det finnes vel to måter å gjøre dette på: en løs omfangsbeskrivelse og en svært spesifikk omfangsbeskrivelse. Det er ikke nødvendigvis slik at den ene enden er god og den andre dårlig. Hva mener du gjør en omfangsbeskrivelse god eller dårlig?

Robyn Birkedal:

Det er et stort spørsmål. Jeg tror vi kunne snakket i timevis om det. Det jeg satte pris på i det du sa tidligere, var at man bør støtte seg på tidligere omfangsbeskrivelser og på andre i virksomheten eller venner som kan ha noe tilsvarende. Da slipper man å begynne helt fra bunnen hver gang. Bruk DPM-fellesskapet og menneskene rundt deg. Men jeg kan gi deg fem ting du kan gjøre for å beskytte deg. Vil du høre dem?

Ben Aston:

Ja, kjør på.

Robyn Birkedal:

Dette bygger på mine personlige erfaringer. Det første er å definere hvorfor. Jeg liker vanligvis å kalle denne delen en oversikt, fordi det føles litt mer formelt. Dette er den første delen, der du definerer arbeidet og forklarer hvorfor prosjektet eller programmet finnes, hvorfor det gjennomføres og hva det skal oppnå. Vi har alle skrevet oversikter i skoleoppgaver. Nå bruker vi den samme strukturen som voksne. Jeg pleier å la en kundeansvarlig utforme denne delen, slik at vedkommende kan ta den med tilbake til kunden og hente inn de viktigste resultatindikatorene. Vi trenger ikke fortelle alt her. Jeg holder det kort og konsist. Vi trenger bare å etablere verdien og rammen for hvorfor arbeidet gjennomføres.

Ben Aston:

Det å begynne med hvorfor er viktig fordi dette er sikkerhetsnettet vårt hvis alt annet svikter. Hvis vi kan vise at det vi leverte, oppfyller den opprinnelige hensikten, har vi et godt utgangspunkt. Hvis målet er å øke antallet abonnenter, kan kunden mislike utførelsen, men hvis vi kan bevise at løsningen faktisk øker antallet abonnenter, har vi oppnådd hvorfor-et. Når vi er enige om det mest grunnleggende resultatet, har vi et felles grunnlag å arbeide ut fra.

Robyn Birkedal:

Det fungerer i alle prosjektmetodikker. Du må alltid vite hvorfor dere går videre. Jeg har også opplevd at det er nyttig å plassere dette øverst i Slack-kanalen eller i teamdokumentasjonen, slik at alle blir samkjørt. Det andre tipset mitt er å beskrive godkjenningsprosessen. Dette kan virke grunnleggende, men det er ofte her ting har blitt kompliserte.

Jeg anbefaler at du minst utarbeider en enkel formulering som beskriver godkjenningsprosessen for leveranser. Når skal kunden gi tilbakemelding? Hvem skal gi den? Hvordan skal den leveres? Du kan begynne enkelt i omfangsbeskrivelsen, men dette bør utvides før arbeidet virkelig kommer i gang. Det er best å snakke muntlig med kunden om tilbakemeldinger og godkjenning, og deretter sørge for at prosessen også er skriftlig beskrevet.

Ben Aston:

Definitivt.

Robyn Birkedal:

Det tredje tipset er å identifisere nøyaktig hva dere skal levere. Dette er vanligvis den største delen av omfangsbeskrivelsen. Den kan være svært detaljert og omfattende i et fossefallsprosjekt, eller mer prosessorientert i en smidig tilnærming. Den skal beskrive hva folk får, når de får det og hvordan de får det. Jeg mener det er viktig å være detaljert når det gjelder revisjonsrunder, innlegging, migrering, hosting, konfigurasjon, formell kvalitetssikring, bilderettigheter og til slutt produksjonssetting.

Ben Aston:

Jeg tror også på å definere det vi kan definere. Hvis vi ikke vet nøyaktig hva vi skal levere, kan vi bruke en forsiktig tilnærming. Vi kan si: «Vi vet i det minste at vi skal levere dette.» Hvis vi tror vi kan utvikle fire konsepter, men er sikre på at vi kan levere to, bør vi definere og forplikte oss til to. Hvis vi tror vi kan bygge opptil fem komponenter på siden, bør vi definere fem, selv om det kanskje ender med seks eller sju.

På den måten finner vi et felles grunnlag og unngår å forplikte oss for mye. Hvis vi sier sju, men det viser seg at kunden bare trengte fem, kan kunden spørre om refusjon fordi vi bare leverte fem. Derfor må vi være forsiktige når vi definerer leveransene.

Robyn Birkedal:

Det har absolutt skjedd med meg. Det kan også bidra til å kontrollere det interne arbeidet i teamet. Designere, utviklere og strateger kan ha ulike oppfatninger av arbeidsmengden. En strateg kan mene at det trengs 20 maler, mens designeren ser for seg noe annet. Ved å ha disse avklaringssamtalene tidlig kan vi redusere intern uro, ikke bare misforståelser med kunden.

Det leder oss til det fjerde tipset: Definer hva som er inkludert og ikke inkludert. Jeg legger dette vanligvis i en egen del, adskilt fra leveransene. Når jeg har identifisert at kunden for eksempel skal få tre moduler, lager jeg en omfattende liste for å beskytte meg mot det jeg vet og ikke vet. Jeg kaller dette grenser. Teknisk sett bruker jeg begrepene avhengigheter og antakelser. Her beskriver du ting som skriftlige tilbakemeldinger, hvem de skal komme fra, flere produksjonssettinger og hva som skjer hvis kunden ikke ønsker å gå videre.

Hvis produksjonssettingen utsettes, bør det stå at det utstedes en endringsordre, fordi dette krever ekstra tid og omdisponering av ressurser. I artikkelen min finner du flere eksempler. Deretter liker jeg en del som heter unntak eller «utenfor omfang». Dette er alt du tror kunden kan komme til å be om, men som du vil gjøre det tydelig at du ikke leverer. Det kan være opplæringsdokumentasjon, hosting, skrifttyper, digitale stilguider eller rettigheter til bilder i all fremtid. Listen kan bli lang, men hensikten er å tydeliggjøre hva du ikke har ansvar for.

Ben Aston:

Eller kanskje du faktisk snakket om det, og det er nettopp der misforståelsene kan oppstå. Disse kalles også negative omfangsbeskrivelser. De lister opp alt vi helt sikkert ikke skal gjøre. Kunden kan si at de vil fornye nettstedet og samtidig snakke om en ny merkevare. Men hvis de ikke har budsjett til en fullstendig merkevareendring, må omfangsbeskrivelsen si at det ikke inngår noe merkevarearbeid.

Da kan du senere vise til dokumentet og si: «Jeg vet at du trodde vi skulle gjøre en merkevareendring, men vi skrev faktisk ned at dette ikke skulle inngå i prosjektet.» Når du utarbeider negative omfangsbeskrivelser, bør du tenke gjennom alt kunden kan tro at de får, men som de ikke får. Gå tilbake til samtalene dere har hatt, og ta med ideene som ble nevnt, men ikke inkludert.

Robyn Birkedal:

Jeg liker det. Det finnes ingen eneste riktig måte å gjøre dette på. Det handler mer om å stole på magefølelsen og liste opp alle måtene prosjektet kan gå galt på. Jeg har hatt ledere som mente at jeg katastrofiserte for mye. For meg handler det om å kartlegge hva som kan gå galt og deretter oppsummere det på en kortere måte. Det er slik jeg prøver å redusere risiko allerede i prosjektets tidlige fase.

Det femte og siste tipset er kanskje litt kontroversielt. Jeg liker å lage en matrise for omfangsbeskrivelsen. Jeg kom på dette for noen år siden, og tror kanskje ideen ble gitt videre til meg av noen andre. Jeg har tidligere brukt timevis i aktive prosjekter på å gå gjennom versjonshistorikken til dokumenter, filer, Slack, e-post, skissefiler og til og med kode, bare for å finne ut nøyaktig hva vi hadde sagt. Det var ikke tydelig, og jeg kastet bort mange prosjekttimer.

Jeg har derfor lært at jeg kan gjøre arbeidet på forhånd når omfangsbeskrivelsen leveres, og holde oversikt over leveransene. Da får vi en tydelig forståelse av hvordan vi følger opp beskrivelsen.

Ben Aston:

Tanken er at arbeidsbeskrivelsen ikke bare skal være et engangsdokument. Ved å legge leveransene inn i en matrise kan vi følge dem opp, minne kunden og interessentene på at dokumentet tas på alvor, og bruke det aktivt gjennom prosjektet. Det er en god måte å følge utviklingen på og holde dokumentet og samtalen levende.

Robyn Birkedal:

Jeg har ikke alltid delt disse matrisene direkte med kunden. Noen ganger oppbevarer jeg dem bare i prosjektets interne filstruktur. Men jeg tar dem frem når det oppstår uenighet, slik at jeg har alle ressursene jeg trenger for å løse problemet umiddelbart, i stedet for å bruke timevis på å lete.

Ben Aston:

Dette høres jo enkelt ut. Hvis man følger disse tipsene, burde alt gå fantastisk, ikke sant? Hva er noen av de største utfordringene, eller hvor går omfangsbeskrivelsene galt?

Robyn Birkedal:

Det som ikke har fungert, er å alltid følge reglene uten å tilpasse seg. Du må være fleksibel og tilnærme deg hvert prosjekt individuelt. Tidligere har jeg tenkt at malen alltid måtte følges. Men vi må forstå at kunder befinner seg på ulike nivåer når det gjelder hvordan de ønsker å arbeide. Det har ofte vært problemet. Etter hvert har jeg blitt mer fleksibel, men også strengere på hva vi faktisk forplikter oss til å gjøre.

Ben Aston:

En av de største utfordringene er å bestemme hvor definitiv du skal være. Når du begynner et prosjekt og ikke er helt sikker på hva som skal leveres, kan det være fristende å overdrive og si at dere skal levere X, Y og Z. Etter oppdagelses- eller designfasen kan det vise seg at Z er unødvendig eller for dyrt.

Derfor er det viktig å tenke på planleggingshorisonten. Det er bra å skrive omfangsbeskrivelser, men du bør ikke strekke deg for langt. Del heller prosjektet inn i realistiske deler innenfor planleggingshorisonten. Hvis du går inn i oppdagelsesfasen, kan du skrive omfangsbeskrivelsen for denne fasen og senere utvikle omfanget for produksjons- eller designfasen. Vi tror ofte at vi vet hva som kommer til å skje, men det gjør vi ikke alltid.

Robyn Birkedal:

En annen utfordring er når du får kundens godkjenning av omfangsbeskrivelsen, men kunden ikke har involvert alle interessentene. Det kan skade prosjektet. Derfor er det nyttig å ha en muntlig gjennomgang og en samkjøringsøkt der dere snakker om dokumentet sammen.

Ben Aston:

Det viktige er nettopp den muntlige gjennomgangen. Vi vil ikke at kunden skal signere uten å ha lest eller forstått dokumentet. Kunden må forstå hva de har forpliktet seg til. Dette skal ikke være et juridisk dokument som ender i retten, der en dommer eller advokat skal tolke om leveransen var korrekt. Hensikten er å legge til rette for en samtale og avstemme forventningene.

Når vi går gjennom omfangsbeskrivelsen med kunden, prøver vi ikke å lure dem eller finne smutthull. Vi prøver å komme på samme side, slik at kunden blir fornøyd med resultatet når arbeidet er utført. Ikke tenk på dette som et juridisk dokument. Hvis det går så langt, har du mislyktes, og alle kommer sannsynligvis til å tape penger og kanskje kunden. Målet er å avstemme forventningene slik at alle er fornøyde med hvordan arbeidet utføres og leveres.

Robyn Birkedal:

Det finnes ikke mye som føles bedre enn å kunne kopiere omfangsbeskrivelsen inn i et juridisk bindende dokument og vite at ordet «samkjørt» faktisk gjelder mellom kunden og de interne partene.

Ben Aston:

La oss få alle på samme side. Robyn, tusen takk for at du ble med oss i dag. Det har vært flott å ha deg her.

Robyn Birkedal:

Takk for invitasjonen.

Ben Aston:

Til dere som lytter: Jeg vil gjerne vite hvilke tips og triks dere har for omfangsbeskrivelser og arbeidsbeskrivelser. Hvor oppbevarer dere dem? Hvordan utarbeider dere dem? Hva fungerer, og hva fungerer ikke? Fortell oss om feilene og erfaringene deres i kommentarfeltet. Hvis du vil lære mer og komme videre i arbeidet ditt, kan du bli med i stammen vår gjennom DPM-medlemskap. Gå til thedigitalprojectmanager.com/membership for tilgang til Slack-teamet vårt, mentorordning, maler, workshops, kontortid, spørretimer, e-bøker og mer. Hvis du likte det du hørte i dag, kan du abonnere og holde kontakten på thedigitalprojectmanager.com. Takk for at du lyttet, og vi høres neste gang.