Använd projektomfattningsbeskrivningar för att rädda dig ur knipan (med Robyn Birkedal)

Läs transkriberingen:

Vi testar att transkribera våra poddavsnitt med hjälp av ett program. Ursäkta eventuella skrivfel eftersom boten inte har rätt 100 % av gångerna.

Ben Aston:

Du håller nervöst i telefonen med kallsvettiga händer. Kunden är arg. Hen hotar i telefonen med att avsluta projektet och inte betala för arbetet. Och hittills har allt gått så bra. Kunden var helt avslappnad och det var du också. De ville ha sin webbplats omdesignad. Det lät enkelt. Och du brydde dig egentligen inte om att skriva ner något eftersom det kändes som att alla förstod. Alla var avslappnade och nu är de inte det längre. Det de faktiskt trodde att de skulle få var dessutom en omprofilering ovanpå den omdesignade webbplatsen. Nu har du ont i magen eftersom du vet att du har ställt till det här. Ingenting skrevs ner. Och nu står kundens ord mot dina. Jag blir stressad bara av att säga det här. Så om du vill ha mycket mindre stress, fortsätt lyssna på den här podden för att upptäcka varför omfattningsbeskrivningar är så viktiga, hur man skriver dem och hur man använder dem i projekt.

Tack för att du lyssnar. Jag heter Ben Aston och är grundare av The Digital Project Manager. Välkommen till DPM-podden. Vårt uppdrag är att hjälpa projektledare att lyckas och hjälpa personer som leder projekt att leverera bättre. Vi vill hjälpa dig att ta ditt projektarbete till nästa nivå. Besök thedigitalprojectmanager.com för att läsa mer om den utbildning och de resurser vi erbjuder genom medlemskap. Den här podden presenteras av Clarizen, ledande programvara för projekt- och portföljhantering för företag. Besök Clarizen.com för mer information.

I dag har jag Robyn med mig. Robyn är en av våra DPM-experter. Bekvämt nog bor hon precis i närheten av min svärmor, där jag nyligen bodde. Hon gillar emojier, listor och valpar. Hon är alltså en kock som blev projektledare och har mer än tio års erfarenhet av projektledning på byråer och nystartade företag. Hon kommer dessutom snart att vara mer tillgänglig för konsultuppdrag. Om du letar efter en projektledare på kontrakt, leta upp henne på LinkedIn. Men hej Robyn, tack så mycket för att du är med oss i dag.

Robyn Birkedal:

Hej Ben. Det är alltid trevligt att vara med dig.

Ben Aston:

Jag vill faktiskt börja med att återvända till det där med listor och valpar. Har du gjort listan i dag?

Robyn Birkedal:

Det har jag. Jag är verkligen en sådan nörd. Jag har en lista över dagens viktigaste mål. Jag har en lista i min planeringsbok. Och sedan har jag också min Google Kalender. Så uppenbarligen behöver jag tre olika listor när som helst. Och det du inte kan se bakom mig är min brottsplatsvägg med post-it-lappar.

Ben Aston:

Det är alltså listornas bakre katalog.

Robyn Birkedal:

Saker i olika kategorier som jag försöker uppnå personligen och professionellt, eller bara olika innehållsidéer åt dig.

Ben Aston:

Har du en valp med dig också?

Robyn Birkedal:

Jag har min åttaåriga valp, men självklart älskar jag hundar mycket mer än katter och alla får gärna kritisera mig för det. Jag känner mig mindre entusiastisk inför emojier på sistone. Men jag tror att det var den emojin.

Ben Aston:

Jag var sådan förra året.

Robyn Birkedal:

Jag vet inte.

Ben Aston:

Så listor är uppenbarligen en stor sak för dig. Du tycker att de är inspirerande. Men jag är nyfiken på var du hämtar inspiration. Vad läser du? Vad tar du in just nu för att bli inspirerad och fortsätta framåt?

Robyn Birkedal:

Det är en fantastisk fråga. Jag känner att jag skulle kunna prata i trettio minuter om den just nu. The Digital Project Manager är självklart en ständig inspirationskälla. Jag tog en kort paus från att vara så involverad i Slack-gemenskapen. Nu när jag är tillbaka saknade jag många av mina vänner där. Det har varit en fullständig glädje, men också mina lokala vänner och min lokala gemenskap. Jag vill särskilt nämna en fantastisk grupp i Portland som jag har varit engagerad i genom åren. Den heter PDXWIT, vilket står för Portland Women in Technology. Jag uppskattar verkligen den gemenskapen, som organiserar väl genomförda kompetensutvecklingsevenemang, mentorskap och tillgång till jobb i olika gemenskaper. De har lärt mig mycket om mångfald och inkludering. Jag uppmuntrar verkligen alla att skapa något liknande eller besöka dem på pdxwit.org.

Ben Aston:

Det är häftigt. Vad försöker du bli bättre på? Vi har alla lite mer tid över just nu. Jag känner att jag överöses med mästarklasser, träning och alla möjliga saker. När du funderar på vad som inspirerar dig och vad du vill inspireras till att göra – finns det något särskilt du arbetar med? En ny hobby? Lär du dig ett nytt programmeringsspråk eller fördjupar du dig i något? Vad gör du?

Robyn Birkedal:

Jag har inte arbetat med Drupal på ungefär sju år, så nyligen har jag försökt komma ikapp med vad som har hänt där. Utöver det tror jag att det här är något som du, Ben, har känt till om mig i flera år. Det känns nästan som en riktig hemlighet att dela högt med dig. Jag funderar faktiskt på att ta olika certifieringar. Till exempel att ta min PMP-certifiering eller kanske undersöka något som SAFe. Jag måste fortfarande ta reda på exakt vad det är, men jag utforskar om det är något jag vill göra framöver. Jag vill bli mer bekant med de metoderna i stället för att bara nöja mig med det jag redan kan.

Ben Aston:

Det är bra. Lycka till med det. Har du upptäckt något annat nyligen som gör livet bättre? Något litet som får dig att le eller ger dig ett ögonblick av glädje?

Robyn Birkedal:

Det här är också pinsamt. Jag vet inte varför jag är så nervös i dag, men jag har verkligen uppskattat att arbeta hemifrån. I bakgrunden sätter jag på en kanal på YouTube TV som jag prenumererar på. Den består till hundra procent av surfning. Jag bor i Portland och det tar ungefär en och en halv timme att ta sig till stranden. Jag är ingen surfare och kan ingenting om surfing, men jag har verkligen uppskattat att titta på det. Tydligen visas mästerskap i bakgrunden på Ambient Surf TV och nu är jag besatt av så många olika personer, som Andy Irons och Kelly Slater-debaclet. Jag har lärt mig mycket av det, vilket är det märkligaste nya som gör mitt liv bättre.

Ben Aston:

Vem är din favorit bland surfarna?

Robyn Birkedal:

Definitivt Kelly Slater.

Ben Aston:

Du vet, de var här. Det var en bra räddning. När jag var – jag kan kanske skryta med att jag surfade med Kelly Slater på Hawaii.

Robyn Birkedal:

Du kan inte bara säga så och tro att det fungerar.

Ben Aston:

Vi var på väg upp ur vattnet och han var på väg ner i vattnet med sin flickvän. Vi möttes och sa hej, Kelly. Så vi surfade med honom.

Robyn Birkedal:

Ja, ni var i vattnet samtidigt.

Ben Aston:

Ja, precis.

Robyn Birkedal:

Det låter som att du befann dig under de stora vågorna om du var där ute med Kelly.

Ben Aston:

Ja. Det är därför det är min stora merit. Men låt oss återgå till det seriösa ämnet och lämna stranden för att prata om omfattningsbeskrivningar. Låt oss börja med varför. Jag försökte skapa bakgrunden i början genom att förklara varför vi bör bry oss om omfattningsbeskrivningar. Projekt går fel. Missförstånd uppstår och omfattningsbeskrivningar kan rädda oss ur knipan. Men låt oss börja med ditt varför. Har du några skräckhistorier om att inte ha omfattningsbeskrivningar? Jag pratade om det i inledningen. Varför blir du entusiastisk över omfattningsbeskrivningar?

Robyn Birkedal:

Absolut. Bara genom att höra din inledning för en stund sedan började jag tänka på hur det traumat kom tillbaka och hur det alltid kommer att göra det. Omfattningsbeskrivningar är mycket viktiga eftersom det är där du säkerställer att ditt team och kunden har en tydlig förståelse för de övergripande kraven. I slutändan definierar det hur ni kan misslyckas och hur det skulle gå till. Det vi försöker skydda oss mot är konflikter med kunden och det interna teamet, samtidigt som vi försöker få alla att vara samordnade och undvika rättsliga tvister.

Ben Aston:

Vi försöker alltså tydliggöra och förena förståelsen så mycket som möjligt. Jag tycker att omfattningsbeskrivningar är bra för att kodifiera den förståelsen. Ibland kan vi tänka att alla är överens och att alla är vänner. Det är ofta faktiskt värre när man är vänner, eftersom alla kan anta att alla andra förstår varandra. Sedan finns det lömskt tvetydiga ord som ”uppdatera” eller ”förnya”. Det omfattningsbeskrivningar gör är att minska tvetydigheten i gråzonerna och göra saker mycket mer svartvita.

Robyn Birkedal:

Absolut. Även under de tio år jag har arbetat inom det här området har terminologin förändrats nästan varje kvartal. Innan vi verkligen pratar om vad de är och hur de fungerar vill jag säga att det är väldigt underskattat att skriva en omfattningsbeskrivning i den här rollen. Det är det torraste med jobbet. Och vanligtvis är det den svåraste delen av att starta ett projekt. Ingen vill äga den uppgiften. Men jag vill säga att jag personligen älskar det, eftersom den tid du lägger i början av projektet säkerställer en mycket effektiv framtid för projektet.

Ben Aston:

Låt oss prata om det på den mest grundläggande nivån. För den som tänker ”vänta lite, vad är en omfattningsbeskrivning?” Hur skulle du beskriva en sådan?

Robyn Birkedal:

Det finns ett stort antal olika termer som vi kan använda, precis som du nämnde med förnyelse och omdesign. Och hur skiljer de sig från en arbetsbeskrivning? Jag skulle beskriva en omfattningsbeskrivning som ett enkelt sätt att beskriva det arbete du har kommit överens om att leverera. Den beskriver också projektets mest grundläggande begränsningar. Vi pratar om vad som ska levereras, vad som inte ska levereras, antaganden om vad du ska leverera och eventuella ytterligare förtydliganden.

Ben Aston:

Omfattningsbeskrivningen används alltså för att beskriva arbetet. Vi definierar och kodifierar omfattningen. Vi säger: ”Det här är vad vi gör och det här är vad vi inte gör.” Om vi inte kan definiera exakt vad vi gör eller inte gör kan vi åtminstone beskriva processen och vad processen kan innebära. Ibland frågar människor om de behöver en arbetsbeskrivning eller hur en agil arbetsbeskrivning ser ut. Det stora problemet är att vi fortfarande måste definiera vad vi gör och inte gör. Men i stället för att definiera leveranserna kan vi rikta in oss på det resultat vi försöker nå och den process vi ska följa för att nå dit.

Robyn Birkedal:

Det finns vissa grundläggande saker man bör följa, och vi kommer att prata om några tips. Men det finns inte en enda mall som alla digitala projektledare följer. Alla företag är olika och varje projekt eller program är annorlunda. Det vi söker här är konsekvens för att skydda dig – eller som jag skrev i artikeln, för att rädda dig ur knipan. Du behöver skydda ditt team och affärsinitiativet.

Ben Aston:

Har du några berättelser om hur du inte definierade omfattningen så fullständigt som du borde och vad som hände?

Robyn Birkedal:

Det är en farlig fråga eftersom jag i tidigare roller har fått rådet att inte ta med för mycket detaljer, eftersom det potentiellt kunde öppna för rättsliga tvister. Om du skriver för mycket kan det finnas fler saker att argumentera om. Men där jag har haft störst framgång är genom att ta med så mycket detaljer som möjligt. Oavsett om det är vattenfallsmetodik eller agilt arbetssätt bör du definiera allt i beskrivningen och sedan kontrollera det med kunden. Du kommer inte att göra allt perfekt varje gång, och ibland kommer en kund att tolka något annorlunda. Det handlar om att navigera i det landskapet och lägga ner så mycket arbete som möjligt i början. Men vi har alla värre historier.

Ben Aston:

Min skräckhistoria handlar om en stor kund inom konsumentelektronik. Vi skapade anpassade animationer åt dem och kunden ville säkerställa att vi hade köpt rättigheterna till animationen. Det gjorde vi. Jag tror att vi köpte en femårig medieutköpslicens så att vi kunde använda animationerna på vilket sätt vi ville under fem år. Vi skapade dem för en enda kampanj och behövde dem högst ett år, men vi tänkte att vi kunde köpa fem år ifall vi ville återanvända dem nästa år. Senare återkom kunden och sa: ”Vänta, jag bad er köpa rättigheterna.” Vi hade gjort det, men kunden behövde dem för all framtid och i alla medier och format. Vi hade bara köpt dem i fem år. Det blev en enorm stötesten eftersom animationsstudion som producerade dem visste att de kunde ta ut vad som helst. Hela kundrelationen föll till slut samman på grund av en enda omfattningsbeskrivning som inte var tillräckligt tydlig. Den gällde bara hur länge utköpet av animationerna från tredje part skulle gälla. Sådana här saker kan få enorma konsekvenser när ett litet missförstånd skakar om människor.

Det här måste tas på allvar. Det kan inte bara sänka projektet utan även hela kundrelationen. Låt oss prata om hur man faktiskt skriver de här omfattningsbeskrivningarna och om processen. Hur bestämmer du vad som ska stå och hur det ska formuleras? Man kan skriva något ganska öppet, vilket lämnar utrymme för tolkning, eller vara mycket detaljerad och försöka täcka alla tänkbara situationer. Hur skriver du dina omfattningsbeskrivningar?

Robyn Birkedal:

Först tre saker. För det första är jag inte jurist och ger inga formella juridiska råd. Jag pratar bara om mina erfarenheter, främst från min karriär inom reklam. För det andra vill jag skicka lite medkänsla för den där situationen, eftersom det verkligen gör ont. Skillnaden mellan ett år, fem år och all framtid är dramatisk. Det finns en nyttig lärdom där. I våra arbetsmiljöer kan omfattningsbeskrivningar dessutom vara många olika saker. Vi kan kalla dem kostnadsuppskattningar, avgränsade arbetsbeskrivningar, avtal eller förslag. Det är i princip ett knippe saker som kan förekomma i flera olika format. Jag har tidigare använt termer som arbetsbeskrivning, avtal och förslag. Men de är inte samma sak som sekretessavtal, huvudavtal, uppdragsavtal eller servicenivåavtal. Det här är alltså inte det enda du behöver tillhandahålla kunden, utan bara en del av helheten.

Ben Aston:

Tillbaka till din ursprungliga fråga: hur skriver du dem och vilken är din process?

Robyn Birkedal:

Jag har vanligtvis använt mallar som redan tillhandahålls av mitt interna team. Jag har haft turen att arbeta på bra arbetsplatser där det redan funnits en mall. Jag sparar också versioner av tidigare arbetsbeskrivningar i en personlig mapp, så att jag kan gå tillbaka och se hur jag utformade en omfattning eller beskrivning för ett varumärkesprojekt jämfört med ett digitalt projekt, en förnyelse eller en omdesign. The Digital Project Manager är också en bra resurs. Du skrev en bra artikel om hur man skriver en arbetsbeskrivning som även innehåller en mall.

Ben Aston:

Det är viktigt att bygga upp en egen bank av omfattningsbeskrivningar som du kan minska, återanvända och återvinna. När vi beskriver hur arbetet ska levereras är parametrarna ofta desamma: hur många koncept vi utvecklar, hur många revideringsomgångar vi gör, hur kundens interaktion och återkopplingsloop ser ut och vilka de slutliga leveranserna är. Om vi producerar samma typ av leveranser om och om igen och följer samma process kan omfattningsbeskrivningarna återanvändas ganska enkelt.

I inlägget på thedigitalprojectmanager.com/project-scope-statement finns många omfattningsbeskrivningar. Vissa är generiska och kan återanvändas i dina egna projekt genom att du ändrar namnen. Andra är mer specifika. Exempel på återanvändbara beskrivningar är vem som betalar för eller ansvarar för licensering av bilder och videor, hur lång tid kunden har på sig att godkänna eller granska ett arbete och lämna samlad återkoppling samt hur många godkännandeomgångar som ingår. Låt oss prata om bra och dåliga omfattningsbeskrivningar. Det finns en skala från en lös beskrivning till en mycket specifik beskrivning. Det är inte nödvändigtvis så att den ena änden är bra och den andra dålig. Vad tycker du kännetecknar en bra eller dålig omfattningsbeskrivning?

Robyn Birkedal:

Det är en stor fråga. Vi skulle kunna prata i timmar om den. Jag uppskattar verkligen det du sa om att luta sig mot tidigare beskrivningar och mot andra personer på arbetsplatsen. Fråga vänner om de har något liknande som fungerat bra, så att du inte alltid börjar från noll. Använd DPM-gemenskapen och andra människor. Jag kan däremot ge dig fem saker du kan göra för att skydda dig. Vill du höra dem?

Ben Aston:

Ja, kör.

Robyn Birkedal:

Det här bygger på min personliga erfarenhet. Det första är att definiera varför. Jag brukar kalla den delen för översikten eftersom det känns lite mer formellt. Det är den första delen där du definierar arbetet, varför projektet eller programmet finns, varför det genomförs och vad det ska uppnå. Jag brukar låta en kundansvarig skriva den delen, så att personen kan återkoppla till kunden och få fram de nyckeltal vi behöver. Här ska vi inte berätta allt. Håll det kort och koncist. Vi behöver en ram och ett värdeuttalande som beskriver varför arbetet görs och varför det är viktigt.

Ben Aston:

Att börja med varför är viktigt eftersom det fungerar som en säkerhetslina om allt annat misslyckas. Om vi kan visa att det vi levererade uppfyller det ursprungliga syftet har vi något att luta oss mot. Om målet är att öka antalet prenumeranter kanske kunden inte gillar utförandet, men om vi kan bevisa att resultatet faktiskt ökar antalet prenumeranter har vi nått målet. Om vi kan enas om den mest grundläggande nivån – varför vi gör arbetet och vilket resultat vi ska nå – har vi en gemensam grund.

Robyn Birkedal:

Det fungerar i alla projektmetoder. Man måste alltid veta varför man går vidare. Jag tycker också att det är bra att placera det högst upp i Slack-kanalen eller i teamets dokumentation och dela det med alla för att samordna teamen. Mitt andra tips är att beskriva godkännandeprocessen. Det kan verka grundläggande, men det är ofta där saker har blivit besvärliga.

Skriv åtminstone en grundläggande text som beskriver godkännandeprocessen för leveranser. När ska kunden lämna återkoppling? Vem lämnar den? Hur ska den levereras? Du kan börja enkelt i beskrivningen, men den bör utvecklas innan allt sätts i rörelse. Prata alltid muntligt med kunden om återkopplingen och godkännandeprocessen och se sedan till att den finns skriftligt i beskrivningen.

Ben Aston:

Definitivt.

Robyn Birkedal:

Det tredje tipset är att tydligt ange vad du faktiskt kommer att leverera. Det är vanligtvis den största delen av omfattningsbeskrivningen. Den kan vara mycket detaljerad och omfattande i ett vattenfallsprojekt eller mer processinriktad i ett agilt projekt. Den ska ange exakt vad människor får, när de får det och hur de får det. Jag föredrar detaljer, särskilt när det gäller granskningsomgångar, innehållsinförande, migrering, hosting, konfiguration, formell kvalitetssäkring, bildrättigheter och slutlig driftsättning.

Ben Aston:

Jag tror också på att definiera det vi kan definiera och fylla i arbetsytan. Om du inte vet exakt vad du ska leverera kan du använda en ”sandbag”-strategi. Säg att ni åtminstone vet att ni kommer att leverera två koncept och åta er att leverera två. Om ni tror att ni kan skapa upp till fem komponenter på sidan, definiera fem och kom överens om fem, även om det kanske blir sex eller sju.

Att lägga sig lite lågt kan skapa en gemensam grund och göra det lättare att nå det mest sannolika resultatet utan att överlova. Om ni säger sju men bara behöver leverera fem kan kunden fråga om återbetalning eftersom ni bara gjorde fem. Det är därför viktigt att inte överbelasta sig när man definierar leveranserna.

Robyn Birkedal:

Det har hänt mig. Det hjälper också till att kontrollera vad som händer internt i teamet. Designers, utvecklare och strateger kan ha olika uppfattningar om arbetsmängden. Genom att ha de här samtalen tidigt kan vi minska den interna omfördelningen, inte bara hantera kunden.

Det leder till mitt fjärde tips: definiera vad som ingår och vad som inte ingår. Jag placerar det vanligtvis i en separat del efter leveranserna. Om kunden får tre moduler, till exempel, bör du ha en uttömmande lista över gränserna. Jag brukar kalla den delen beroenden och antaganden. Där skriver du ner sådant som ingen ska kunna smita undan från, till exempel att återkoppling ska vara skriftlig och komma från rätt person hos kunden. Om det finns flera driftsättningar och kunden skjuter upp en driftsättningsdag ska en ändringsorder utfärdas, eftersom det kräver mer tid och omfördelning av resurser.

Jag tycker också om en del som heter undantag eller ”utanför omfattningen”. Där tar du upp sådant som kunden kan tänkas be om men som du vill göra klart att du inte tillhandahåller. Det kan gälla utbildningsdokumentation, hosting, teckensnittsavgifter, digitala stilguider eller bildrättigheter för all framtid. Du skyddar dig från att bli ansvarig för saker som aldrig diskuterades.

Ben Aston:

Det är där missförstånd kan uppstå. Sådana kallas också negativa omfattningsbeskrivningar. De listar allt vi definitivt inte gör. Kunden kan säga att de vill modernisera webbplatsen och samtidigt prata om en omprofilering, men sedan visar det sig att budgeten inte räcker till en fullständig omprofilering. Då bör du ta med en negativ omfattningsbeskrivning som säger att ingen omprofilering ingår. När kunden senare tror att en omprofilering skulle ingå kan du hänvisa tillbaka till texten.

När du skriver negativa omfattningsbeskrivningar bör du tänka på allt kunden kan tro att den får men faktiskt inte får. Gå tillbaka till tidigare samtal och notera idéer som nämndes men inte ska ingå.

Robyn Birkedal:

Jag tycker om det. Det finns inget enda rätt sätt. Lita på magkänslan och skriv ner alla sätt som projektet kan gå fel på. Jag har haft chefer som sagt att jag katastroftänker för mycket. För mig är det ändå hjälpsamt att kartlägga vad som kan gå fel och sedan sammanfatta det mer koncist. Det är att tänka framåt och minska riskerna redan i projektets inledande skede.

Det femte och sista tipset är kanske lite kontroversiellt: skapa en matris för omfattningsbeskrivningen. Jag kom på det för några år sedan, även om någon annan kan ha fört vidare idén till mig. Jag hade lagt timmar på aktiva projekt genom att gå igenom versionshistorik i dokument, filer, Slack, e-post, skissfiler och ibland kod för att ta reda på exakt vad vi hade sagt och i vilket format. Det var inte tydligt och många projekttimmar gick åt. Därför gör jag arbetet i början och håller reda på leveranserna från start, så att vi har en tydlig förståelse för hur vi genomför arbetet enligt beskrivningen.

Ben Aston:

Tanken är alltså att arbetsbeskrivningen inte bara ska vara ett engångsdokument. Genom att lägga leveranserna i en matris och följa upp dem kan vi påminna kunden och intressenterna om att dokumentet tas på allvar och används genom hela projektet.

Robyn Birkedal:

Precis. Jag delar inte alltid matrisen direkt med kunden. Ibland behåller jag den i projektets interna filstruktur. Men om en konflikt uppstår kan jag ta fram den och ha alla resurser som behövs för att lösa frågan direkt i stället för att lägga timmar på efterforskning.

Ben Aston:

Det låter som att allt går som på räls om man följer tipsen. Vilka är de största utmaningarna och var går omfattningsbeskrivningar fel?

Robyn Birkedal:

Det fungerar inte att alltid följa reglerna på ett mekaniskt sätt. Man måste vara flexibel och behandla varje projekt individuellt. Tidigare har jag tänkt att en viss mall alltid måste följas, men vi behöver vara mer flexibla i hur vi arbetar och förstå att kunder befinner sig på olika nivåer. Det har oftast varit problemet. Med tiden har jag blivit mer flexibel i arbetssättet men samtidigt striktare i vad vi faktiskt åtar oss att göra.

Ben Aston:

En av de största utmaningarna är att bestämma hur definitiv man ska vara. När man börjar skriva en omfattningsbeskrivning utan att helt veta vad som ska levereras kan man överdriva och lova X, Y och Z. Efter upptäckts- eller designfasen kan det visa sig att Z är överflödigt, onödigt eller för dyrt.

Därför är det bra att tänka på planeringshorisonten. Skriv omfattningsbeskrivningar, men överdriv inte. Dela kanske upp dem i realistiska delar inom planeringshorisonten. Om ni går in i upptäcktsfasen kan ni skriva en beskrivning för just den fasen och sedan definiera nästa del av projektet när ni kommer till den. Att lova för mycket är en stor risk eftersom vi tror att vi vet vad som kommer att hända, men ofta kan vi inte veta det.

Robyn Birkedal:

En annan utmaning är när kunden godkänner omfattningsbeskrivningen utan att alla intressenter har varit involverade. Det kan skada projektet ordentligt. Därför är en muntlig genomgång och ett samordningsmöte där ni pratar igenom allt mycket värdefullt.

Ben Aston:

Den muntliga genomgången är viktig eftersom vi inte vill att kunden ska godkänna något utan att ha läst eller förstått det. Kunden ska förstå vad den åtar sig. Det här ska inte vara ett juridiskt dokument som leder till en domstol där en domare eller advokat tolkar vad som levererats. Poängen är att skapa samordning och få alla på samma sida.

Det är ett samtalsverktyg. När vi går igenom omfattningsbeskrivningarna med kunden försöker vi inte lura kunden eller smyga in något. Vi försöker skapa en gemensam förväntansnivå så att kunden blir nöjd med resultatet och leveranserna. Se det inte som ett juridiskt dokument. Om det går så långt har man misslyckats, och alla kommer sannolikt att förlora pengar och kanske även kunden. Målet är att alla ska vara nöjda med hur arbetet genomförs och produceras.

Robyn Birkedal:

Det finns nästan inget bättre än känslan av att kunna kopiera och klistra in omfattningsbeskrivningen i ett juridiskt bindande dokument och veta att kunden och de interna parterna verkligen är samordnade.

Ben Aston:

Låt oss skapa samordning. Robyn, tack så mycket för att du var med oss i dag. Det har varit fantastiskt att ha dig här.

Robyn Birkedal:

Tack för att jag fick vara med.

Ben Aston:

Till er som lyssnar vill jag gärna veta vilka tips och knep ni har för omfattningsbeskrivningar och arbetsbeskrivningar. Var placerar ni era beskrivningar? Hur tar ni fram dem? Vad fungerar och vad fungerar inte? Berätta om era misslyckanden och framgångar i kommentarerna. Om du vill lära dig mer och utvecklas i arbetet kan du gå med i vår gemenskap genom DPM Membership. Besök thedigitaprojectmanager.com/membership för tillgång till vårt Slack-team, mentorskap, mallar, workshoppar, kontorstider, frågestunder, e-böcker och mer. Om du tyckte om det du hörde i dag, prenumerera gärna och håll kontakten på thedigitalprojectmanager.com. Tack så mycket för att du lyssnade och på återhörande.