Att hantera (omfattnings-)kryp (med Suze Haworth)

Läs transkriberingen:

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

Ben Aston:

Välkommen till DPM-podden, där vi går bortom teorin för att ge expertråd om hur man leder bättre digitala projekt. Tack för att du lyssnar. Jag heter Ben Aston och är grundare av The Digital Project Manager. Om det finns en sak som spårar ur nästan alla projekt så är det omfattningskryp. Vi vet alla att det är dåligt. Vi vet alla att vi vill undvika det. Men hur känner man igen det i alla dess olika former? Vad orsakar det? Vems fel är det? Och viktigast av allt: hur hanterar man det faktiskt? Allt kommer att avslöjas i dagens podd, där vi pratar om att hantera kryp av den typ som rör projektets omfattning.

Den här podden presenteras av Clarizen, ledaren inom programvara för företagsprojekt och projektledning.

Läs mer på clarizen.com

I dag har jag Suze Hayworth med mig. Suze är en av våra fasta DPM-experter på The Digital Project Manager, och hon arbetar som frilansande senior digital projektledare i London i Storbritannien. Hon har mer än tio års erfarenhet av att arbeta på byråer och har upplevt mycket omfattningskryp, så hon är en utmärkt person att prata med om detta i dag. Suze, välkommen.

Suze Hayworth:

Hej, Ben.

Ben Aston:

Suze, vi pratade precis innan vi började spela in. Kan du berätta lite om vilken typ av projekt du arbetar med just nu och några av utmaningarna du möter?

Suze Hayworth:

Ja, just nu arbetar jag frilans på en byrå i London, så jag är ungefär hälften senior projektledare och hälften projektdirektör i två olika kunduppdrag. I det ena arbetar jag för IKEA, alltså ett stort företag inom detaljhandel och e-handel. Vi tar fram ett designsystem åt dem, ett slags prototyp för ett designsystem. Sedan arbetar jag också med en annan e-handelsaktör i Storbritannien. Så just nu är det mycket detaljhandelsprojekt. Och när det gäller utmaningar är det alltid svårt att prata om dem, särskilt när de fortfarande pågår. Jag tror att—

Ben Aston:

Är det den där besvärliga kunden?

Suze Hayworth:

Ja. Nej, faktiskt inte. De är verkligen—jag måste säga det här ändå.

Ben Aston:

Det måste du.

Suze Hayworth:

Det är sant. Det är sant. De är väldigt bra kunder som jag arbetar med just nu. Jag tror att det handlar om att arbeta med människor, vilket både är det bra och det dåliga med projekt och med att vara projektledare i allmänhet. Det är fantastiskt. Jag tycker om att arbeta med människor, olika personligheter, egenheter och sådant. Men ibland kommer man också till en punkt där man blir frustrerad över att försöka få saker ur människor som inte vill göra saker. Så ja, jag har nog haft en del av det på sistone.

Ben Aston:

Roligt och spännande. Berätta då om projektet med att bygga ett designsystem, för jag tycker att det är ett intressant projekt, och faktiskt den typen av projekt ser vi allt mer av. Tidigare kanske alla ville behandla varje projekt som en unik snöflinga, och kreatörerna ville vara kreativa. Berätta, vad är ett designsystem? Och vilket projekt arbetar du faktiskt med? Och hur rullar ni ut det?

Suze Hayworth:

Ja, det är faktiskt väldigt spännande eftersom designsystem, precis som du säger, blir allt vanligare i den digitala världen. I grund och botten är de som ett slags stilbibliotek för ett företags eller varumärkes digitala design. De fastställer en basuppsättning designkomponenter, moduler och mallar som alla designers eller utvecklare som arbetar med varumärket kan använda för att utveckla sina egna designer och sin kod. Det är alltså en baslinje och ett sätt att skapa en grundläggande design, vilket främjar effektiviteten. Återanvändbar kod och återanvändbara designer, men också effektivitet och konsekvens inom företaget.

För ett företag som IKEA, som är ett enormt varumärke med många olika byråer, personer och organisationer som arbetar för dem, kan designsystemet sätta en standard som designers och utvecklare kan arbeta efter. Exempelvis kan knappen på en sida, en uppmaning till handling, vara konsekvent på flera plattformar, enheter och så vidare, samt i appar. Vilka digitala egenskaper de än använder.

Ben Aston:

Berätta om processen för att, antar jag, hantera projektet. Det kan nästan vara ett projekt av typen ”hur långt är ett snöre?”. Hur gör man? Börjar man bara någonstans? Vad itererar ni kring? När tar produkten slut?

Suze Hayworth:

För IKEA är det så att många varumärken faktiskt inte gör detta externt, utan som interna projekt. IKEA sökte däremot extern hjälp och stöd, och ville att vi skulle delta i designarbetet. Jag tycker att det var ett väldigt smart drag, eftersom vi kan komma in utifrån och granska saker med ett perspektiv som inte är lika präglat av företagets interna arbetssätt. Vi började konceptuellt med att bedöma principerna, de centrala digitala principerna och konceptet bakom vår design, samt IKEAs varumärkes- och designprinciper. Det var startpunkten. Vi gjorde alltså en mer strategisk genomgång av hela upplevelsen och designprinciperna bakom den. Därefter började vi gå mer konkret in i designarbetet och skapa en grunddesign baserad på befintliga grundelement. Det handlar om saker som färg, typografi och rutnät, och sedan utvecklade vi detta vidare.

Vi gjorde sedan användartester av designen mot några plattformar som vi valde ut från IKEAs olika digitala egenskaper. Därefter gick vi vidare till att designa och bygga specifika komponenter och publicera dem på en webbplats för designsystemet, som för närvarande bara är intern. Det vi tittar på är en mer flexibel prototyp för att först få igång detta, och sedan utvecklas den till en fullständig lösning när vi är klara med den här fasen.

Ben Aston:

Coolt. Vad innebär den fullständiga lösningen? Är det en levande stilguide med kodsnuttar som folk bara kan hämta? Eller mallar som de kan använda? Är det ungefär dit ni är på väg?

Suze Hayworth:

Ja, jag tycker att alla designsystemprojekt måste vara pågående och levande. De har alltså inget slut i egentlig mening. Det är inte en produkt som man bara slutar arbeta med och sedan är det klart. Den behöver utvecklas. Vi har precis börjat och bara skrapat på ytan när det gäller de ursprungliga principerna, grunderna och komponenterna. Därifrån handlar det om att gruppera komponenterna, utveckla moduler och sedan även mallar. Därefter måste man fundera på hur man får människor att använda detta och hur man sprider det, samt hur man introducerar människor till det. Det här är ett enormt projekt, särskilt med tanke på hur många olika parter som är involverade i företaget. Så vi har egentligen bara kommit igång, även om vi har hållit på i nästan ett år.

Ben Aston:

Låter som ett roligt projekt. Jag är alltid nyfiken på att fråga människor om de nyligen har hittat några verktyg, eller vad som gör deras liv bättre just nu. Finns det något du har hittat? Något du har läst? Vad har du upptäckt nyligen som andra borde känna till?

Suze Hayworth:

Jag har faktiskt inte använt så många nya verktyg på sistone. Jag håller mig till det jag känner till. Men det är ganska ironiskt med tanke på att jag är med i en podd: jag har lyssnat på fler poddar på sistone. Vanligtvis lyssnar jag på musik på väg till jobbet, ungefär en timme under pendlingen, men nyligen har jag faktiskt börjat använda tiden lite mer effektivt och lyssnar på olika poddar. Det har varit väldigt bra eftersom det är ännu ett sätt att lära sig och samtidigt använda tiden när jag står på—jag tänkte säga sitter, men jag får aldrig någon sittplats—står på tåget till jobbet. Så jag använder tiden ganska effektivt.

Ben Aston:

Finns det några poddar som du har tyckt varit särskilt hjälpsamma eller intressanta?

Suze Hayworth:

Jag måste säga Digital Project Manager-podden, definitivt. Det var självklart. Sedan lyssnade jag faktiskt nyligen på en podd för—var det Drunken …? Efter mitt framträdande på DPM Summit nyligen pratade jag med honom om vad min session handlade om. Och The Bureau of Digitalists på DPM Summit. De gör några bra avsnitt, och Brett, som driver konferensen, har nyligen publicerat ett som heter Sprints and Milestones. Det bygger på hans bok om digital projektledning och är en ganska användbar resurs.

Ben Aston:

Bra saker. Börja alltså lyssna på poddar. Något jag har tyckt varit väldigt intressant—jag vet inte om du har hört talas om det—heter Blinkist. Och vet du vad? Jag måste vara ärlig. Jag lyssnar inte på särskilt många, om ens några, poddar förutom min egen där jag pratar. Men något jag alltid märker är att jag tänker att jag verkligen borde läsa den där boken, och sedan köper jag antingen boken och läser den aldrig, eller så kommer jag aldrig till skott. Blinkist har en funktion där de i princip erbjuder mycket koncentrerade sammanfattningar av böcker. Det är lite som en—

Suze Hayworth:

Jag tror faktiskt att jag har hört talas om det, ja.

Ben Aston:

Ja, det tar i princip ungefär 15 minuter att läsa sammanfattningen, eller så kan man lyssna på den. Någon läser sammanfattningen av boken och de viktigaste punkterna. Det är ungefär som en podd, och det fina är att man kan spela upp den snabbare också. Man kan inte bara lyssna i normal hastighet, utan även i dubbel hastighet. Då tar det sju och en halv minut att läsa eller lyssna på en bok.

Suze Hayworth:

Det är fantastiskt. Jag måste prova det, för jag har också försökt läsa lite mer på sistone. Det vore bra att få plats med fler böcker.

Ben Aston:

Ja. Det är mitt boktips till er alla: Blinkist. Nåväl, vi skulle egentligen prata om omfattningskryp i dag. Så låt oss prata om omfattningskryp. För den som inte känner till begreppet: vad är det och varför bör vi bry oss om det?

Suze Hayworth:

Det är i princip när omfattningen, alltså leveranserna eller allt du har kommit överens om och funktionerna i ett projekt, utökas eller växer jämfört med det ni ursprungligen kom överens om. Utan att man tar hänsyn till den extra tiden eller kostnaden. Projektet kan påverkas på flera olika sätt, men det handlar helt enkelt om att saker börjar smyga sig in och förlänger tiden eller gör att saker förskjuts i projektet.

Ben Aston:

Det är alltså extra arbete som vi inte hade räknat med, och det påverkar vår budget, vår tidsplan och förstås omfattningen, alltså mängden arbete vi utför. Det finns många anledningar till att detta händer. Arbetet vi trodde eller planerade att utföra blir plötsligt mer omfattande. Vi är väldigt bra på att skapa arbete åt oss själva. I artikeln du har skrivit kommer vi inte att gå igenom alla orsaker, eftersom det finns en hel mängd olika orsaker.

Suze Hayworth:

Ja, det finns många.

Ben Aston:

Vilka skulle du säga är de vanligaste? Låt oss prata om de mest typiska och sedan om de mest lömska.

Suze Hayworth:

De vanligaste jag har sett är först och främst att man inte är tydlig med omfattningen från början. När man fastställer leveranser och skriver en arbetsbeskrivning i början av ett projekt kan man vara för vag eller otydlig i hur man beskriver saker. Man kanske inte har en tillräckligt exakt definition av vad man faktiskt levererar. Det kan naturligtvis komma tillbaka senare, och kunden eller personer internt kan tolka det på helt olika sätt. Då börjar omfattningen växa utifrån en ganska vag beskrivning av leveranserna från början.

Det första är alltså att vara tydlig med omfattningen från början och att se till att den som godkänner omfattningen verkligen förstår vad den får. En arbetsbeskrivning är naturligtvis bra för att lägga fram alla leveranser och vad man ska göra i projektet, men det är ofta ett långt dokument. Man lämnar det till kunden och förväntar sig att kunden ska läsa, ta till sig och förstå allt. Därför är det mycket viktigt att kärnpunkterna, det kunden faktiskt får, tidsplanen och budgeten lyfts fram och förklaras uttryckligen. Även om man tror att kunden har läst dokumentet är det viktigt att gå igenom det tillsammans i ett möte när man presenterar den ursprungliga projektomfattningen. Se till att kunden verkligen förstår vad den får.

Det är där jag har sett många problem tidigare också. En arbetsbeskrivning godkänns, och sedan säger människor längre fram: ”Men jag trodde att jag skulle få det där”, även om det kanske står mer uttryckligt någon annanstans.

Ben Aston:

Vi är alltså inte tydliga från början. Vi kanske säger: ”Ja, kunden, vi ska skapa en sidmall åt dig”, men vi definierar inte vad som faktiskt ska ingå i mallen. Ofta är en av utmaningarna, och det är vad du var inne på med den andra punkten, att vi inte är tydliga eller att vi helt enkelt inte har kommunicerat vad vi menar med en mall.

Suze Hayworth:

Precis. Det är två saker: att tydligt fastställa och förstå leveranserna från början, men också se till att den som godkänner omfattningen verkligen förstår det du har sagt. Det är det andra lagret, eftersom kunden fortfarande kan ha en föreställning om att den får något annat, även om du har varit ganska tydlig och det inte står med i omfattningen.

Ben Aston:

Så det du har tagit upp är att vi inte är tydliga och att kunden inte förstår. Jag tror att det förmodligen är de två vanligaste sätten som omfattningskryp uppstår på.

Men låt oss prata om den mer lömska sidan. Vad har du stött på som varit mest ovanligt, eller vilken typ av omfattningskryp sker utan att man märker det? Hur uppstår det i de projekt du har arbetat med?

Suze Hayworth:

Det typiska sättet som projektledare ser omfattningskryp på är att det kommer från kunden. Kunden ber om något annat, utökar saker eller vill ha mer hela tiden. Men jag har också sett att det kan komma från interna team och interna intressenter. Om de interna teammedlemmarna inte har en tydlig förståelse för vad de ska göra kan de börja gå åt olika håll och, utan att inse det, förlänga tiden eller utöka funktionaliteten. En designer kan designa något utan att tänka igenom hur det påverkar utvecklingens omfattning. Det kan ske helt oavsiktligt. Eller så kan de nästan ha en egen agenda och vilja bygga något på ett visst sätt. Jag har sett situationer där någon vill lägga till något som de själva vill designa eller bygga.

Det är kanske mer överraskande när det kommer internt, eftersom man vill att alla ska vara överens, men det kan hända. Även andra interna intressenter kan föra in affärsbehov. Interna intressenter kanske vill att man levererar mer ur ett kundrelationsperspektiv, eller så kan de komma överens om saker utan att man känner till det. Det är också en klassiker. Där kommer de lite lömskare varianterna in.

Ben Aston:

Jag håller helt med. En av de vanligaste orsakerna till lömskt omfattningskryp är att det kommer internt, när det handlar om överleverans. Våra egna interna team försöker lägga på extra kvalitet eller funktionalitet. Det händer ofta inom strategi, UX och design, men det kan också ske i utvecklingen. Någon vill göra ett fantastiskt jobb eller tänker: ”Vi kan göra detta till ett skyltfönsterprojekt, något vi kan skicka in till priser, så låt oss lägga ned extra arbete.” Men ingen har egentligen pratat om vem som betalar för det extra arbetet.

Suze Hayworth:

Exakt.

Ben Aston:

Eller vem som tar ansvar för det. Att gå sin egen väg är definitivt—

Suze Hayworth:

Ett bra sätt att uttrycka det.

Ben Aston:

Ja, när självständiga tänkare skapar sin egen tolkning av vad de ombetts göra. En annan sak jag vill prata om, som du nämnde i din artikel, är kvalitetssäkring. När vi är i kvalitetssäkringsfasen kanske vi inte har definierat acceptanskriterierna tillräckligt tydligt när vi skrev användarberättelsen. Eller så har vi inte sagt till kvalitetssäkringsteamet: ”Testa inte på IE9, vi bryr oss inte längre om IE9.” Då svarar kvalitetssäkringsteamet: ”Men det finns alltid buggar i IE9, så det borde vi göra.” Eller så upptäcker man att de testar på Blackberry eller något annat slumpmässigt, och plötsligt lägger de inte bara mycket tid på att testa saker vi inte bryr oss om, utan utvecklarna försöker dessutom åtgärda saker som egentligen inte behöver åtgärdas. Har du råkat ut för det?

Suze Hayworth:

Absolut. Kvalitetssäkring är ett av de stora områdena i projekt, särskilt i större projekt. I början kan man ungefär uppskatta hur mycket tid utvecklingsperioden kräver utifrån det man vet. Men det är mycket svårt att uppskatta hur mycket kvalitetssäkring som behövs, hur många ändringar som måste testas igen och hur många omtester som krävs. Det kan bara växa, särskilt om man inte fastställer parametrarna från början. Man behöver alltså fastställa acceptanskriterierna, definiera webbläsar- och enhetsmatrisen och bestämma prioriteten för buggar och problem som uppstår. Vilka måste åtgärdas för att vi ska kunna lansera? Vilka är högprioriterade och vilka har lägre prioritet? Vilka kan vi faktiskt lansera utan att åtgärda, exempelvis vissa design- eller ytrelaterade ändringar?

Det handlar återigen om att definiera kärnomfattningen så mycket som möjligt och minska osäkerheten från början. Men genom hela projektet handlar det framför allt om tydlig kommunikation och att hålla kommunikationen öppen. Om man kvalitetssäkrar och märker att mer tid läggs på en viss enhet eller webbläsare, till exempel IE, som kan vara en mardröm, måste man vara öppen och snabbt synliggöra detta för kunden eller intressenten.

Berätta att IE till exempel tar mycket mer tid i kvalitetssäkringen. Föreslå sedan alternativ. Vi har de här webbläsarna och enheterna att täcka. Vi kan prioritera IE eftersom det är viktigt och användarbasen är stor för kunden. Vi prioriterar det och fortsätter där, och behandlar sedan de andra webbläsarna utifrån deras prioritet. Det handlar om att så snabbt som möjligt synliggöra problem där man ser att omfattningen växer, men också erbjuda alternativa lösningar när man gör det.

Ben Aston:

Det tycker jag är väldigt hjälpsamt. Vi har pratat om några saker som orsakar omfattningskryp: otydlig omfattning, att gå sin egen väg och kvalitetssäkring. Låt oss prata om vems fel det är. För att hantera problemet hjälper det ofta att identifiera vem som bär ansvaret, inte för att peka finger utan för att förstå hur vi ska hantera det. Vi har pratat om kunden, som ber om mer. Kanske ber kunden om mer eftersom den inte förstod vad vi skulle leverera. Vi har pratat om interna intressenter och om att teamet överlevererar och skapar mer arbete åt sig självt.

Men du nämnde även andra parter i din artikel: tredje parter, användare och oss projektledare. Jag vill gärna prata om oss som projektledare. De flesta som lyssnar är projektledare. I vilken utsträckning är detta vårt problem och vårt fel? Är det vårt problem eller alla andras?

Suze Hayworth:

Det handlar inte om att skylla omfattningskrypet på någon, utan om att försöka identifiera riskerna. Man kan alltså titta på vilka personer i projektet som kan orsaka omfattningskryp och vad de kan göra. Det är ett bra sätt att se på riskerna från början och fundera på vad människor kan göra längre fram.

När det gäller oss själva tittar vi ofta utåt på vad teamet kan göra, hur kunden kan påverka och så vidare. Men personligen tror jag att det handlar om att inte uppmärksamma eller tydliggöra när saker faktiskt händer. Det finns en tendens – och jag erkänner att jag själv har gjort det tidigare – att man försöker lösa ett problem i projektet men samtidigt begraver det. Man vill inte hela tiden behöva flagga problem för kunden, särskilt om det redan finns många problem, och utsätta sig för den negativa bilden av det som händer.

Man vill nästan göra sitt bästa för att hålla projektet igång och kämpa mot tidsplanen. Man vill få ut saker och säger därför: ”Okej, vi kan ta hänsyn till det där här” eller ”Vi kan ta hänsyn till det där där”, men man visar inte kunden det eftersom man försöker lösa problemet. Jag tror att det är ett område där vi faktiskt kan bli bättre. Jag har själv tänkt på det tidigare.

Det är mycket enklare att ha ett samtal om problemet om man är ärlig och öppen och tar upp det snabbt. Då kan man prata igenom det. Som jag nämnde tidigare är det viktigt att kunna presentera lösningar. Man ska inte bara säga: ”Vi har ett problem” och sedan famla medan man försöker lista ut vad man ska göra åt det tillsammans med kunden. Först måste man konstatera att det finns ett problem och förstå vilket problemet är. Sedan går man till kunden med några alternativa lösningar.

Om omfattningskrypet kommer internt kan man arbeta med att begränsa det, men samtidigt vara tydlig mot kunden med att det har hänt. Om kunden ber om något som ligger utanför det ni kommit överens om ska man inte bara svälja det och försöka få plats med det. Titta på vilken påverkan det får och ta fram några olika alternativ. Därefter kan man återvända till kunden och diskutera påverkan och vad kunden till exempel vill prioritera ned.

Ben Aston:

Vi har nästan hoppat direkt till hur man hanterar det.

Suze Hayworth:

Förlåt.

Ben Aston:

Det är helt okej, för när vi tänker på vad som orsakar det handlar det ju om vad vi gör när vi faktiskt har konstaterat att omfattningskryp pågår. Men som projektledare kan vi också försöka vara tydligare med omfattningen. Jag tycker alltid att det är bra att be en annan projektledarkollega att granska den. Det är också bra att fråga kvalitetssäkringsteamet. De är ofta duktiga på att hitta luckor i det man har skrivit och säga: ”Har du tänkt på det här?” Eller fråga en affärsanalytiker. De är bra på att hitta luckor i omfattningen och fråga: ”Har du tänkt på det här?” eller ”Varför har du inte definierat detta?”

Det handlar alltså om att vara tydlig med omfattningen och om den kommunikationsaspekt vi pratade om tidigare. Man ska inte bara kasta en arbetsbeskrivning över muren och hoppas på det bästa, hoppas att kunden skriver under och sedan bli glad när projektet kan börja. Det är mycket bättre att gå igenom den tillsammans med kunden för att förhindra problemet från början.

Jag gillar det du säger om hur man hanterar problemet. Sopa det inte under mattan. Som projektledare kan vi lätt tänka att vi, särskilt om vi också har kundkontakt, inte ska ta upp problemet eller vara proaktiva eftersom det kanske löser sig. Vi vill behålla relationen med kunden, vilket är viktigt. Därför är vi inte transparenta från början, och sedan växer problemet. Det du skriver om att vara proaktiv och transparent, prioritera och analysera konsekvenserna är mycket användbart.

En sak jag vill ta upp, som du berörde i din artikel, är att omfattningskryp ofta förknippas med vattenfallsprojekt, där man planerar mycket i början och sedan genomför projektet fas för fas. Men är detta också ett problem i agila projekt? Hur ser det ut i ett agilt projekt? Vad bör man se upp med i ett mer iterativt och till synes flexiblare projekt?

Suze Hayworth:

Det var verkligen det jag ville förmedla i min artikel. Vi ser omfattningskryp som något ganska negativt eftersom vi försöker hålla oss till en fast omfattning som vi kommit överens om och bekämpa allt som förändrar den. Det fina med agilt arbetssätt och agila metoder är att det handlar om att välkomna förändring. Det är en av de centrala principerna i agilt arbete. Förändring kan faktiskt skapa en bättre produkt eller tjänst i slutändan. Man gör alltså något ganska bra genom att tillåta förändring i projektet.

Min poäng är att förändring inte ska ses som fienden. Den kan faktiskt vara något bra när man ser på den på rätt sätt. Det viktiga är hur man hanterar den.

När det gäller hur det kan uppstå i agila projekt kan man ta ett Scrum-baserat projekt som exempel. Det är fortfarande ett agilt projekt, men man kommer ändå överens om vad som ska göras under den tidsbegränsade perioden, alltså sprinten i det här exemplet. Man fastställer innehållet i backloggen. Produktägaren eller kunden kan komma in under en sprint och lägga till något i backloggen när ni redan har planerat och kommit överens om vad som ska ingå. Det kan påverka det ni ska leverera och även lanseringen.

Det gäller alltså att se till att det som introduceras inte bara läggs till utöver allt annat. Man behöver omprioritera utifrån detta och säkerställa att den arbetsinsats som krävs för de nya användarberättelserna eller epikerna kan balanseras genom att något annat prioriteras ned. Det händer även i agila projekt. Men det fina med agilt arbete är att de kortare tidsperioderna gör det lättare att hantera förändringar när man lanserar något.

Ben Aston:

Jag gillar verkligen det: att förändra samtalet och välkomna förändring. När vi pratar om omfattningskryp blir samtalet ofta väldigt negativt, eftersom det vanligtvis innebär högre kostnader. Vi måste säga till kunden: ”Du ber oss om den här extra saken. Den var inte planerad från början, så den kräver mer tid och en större budget.”

Men om vi har en mer transparent och pågående dialog med kunden om budgetens verklighet och begränsningar kan vi bara göra en viss mängd arbete. Då kan vi prioritera tillsammans och göra prioriteringen till en pågående diskussion. Kunden behöver inte oroa sig för att den kanske inte får den funktion som den ursprungligen trodde var viktig. Under projektets gång kan vi ha identifierat något som är viktigare. Det är en bra förändring, och det är ett samtal man kan ha under hela projektet, i stället för att överraska kunden i sista stund: ”Tyvärr, du måste antingen betala mer eller avstå från den funktionen. Vi gör X i stället för Y.” Då blir det negativt. Jag gillar det du säger om hur en pågående dialog kan göra samtalet enklare.

Suze Hayworth:

Jag håller helt med. Det är viktigt att kontinuerligt prata om vad man levererar, eftersom det i grunden bör kopplas till vad som är mest värdefullt för användarna av produkten eller tjänsten. Om kunden eller någon annan säger att de faktiskt vill ha något ska man inte bara tänka: ”Åh nej, vi har redan planerat allt.” Man ska inte heller bara säga att det inte går om de inte betalar mer och att tidsplanen kommer att förlängas. Fundera i stället på hur man kan formulera och forma frågan. Vilken nytta ger det kunden vill ha användarna? Varför kommer detta krav nu? Tillgodoser det ett nytt behov? Vad ligger bakom önskemålet?

Om det är relevant och faktiskt kommer att vara mer användbart för användarna kan man jämföra det med andra leveranser och säga: ”Den här funktionen vi vill införa kommer faktiskt att vara mycket mer användbar än den andra. Låt oss prioritera ned den andra i stället.”

Det handlar om att ha en pågående dialog, hålla kunden involverad i det man gör och analysera nya önskemål för att förstå varför de har kommit och vilken den faktiska nyttan blir.

Ben Aston:

Det är verkligen goda råd. Gör det till ett samtal och tänk på användaren. Det vi har diskuterat har varit fantastiskt, och det som verkligen fastnat hos mig är att förändra samtalet från något negativt till en pågående dialog. Omfattningskryp behöver inte vara negativt. Det kan vara bra för användarna, kunden, projektet och våra team. Det är alltså inget vi måste fly från eller vara rädda för. Att välkomna det är ett mycket bra råd.

Men om vi tänker på personer som säger: ”Mitt stora problem är att alla mina projekt alltid slutar över budget. De blir alltid försenade och vi har enorma problem med omfattningskryp.” Det här är nog något många projektledare möter, särskilt i början av sin karriär. Projektet fortsätter att växa, allt tar längre tid, alla överlevererar och kunden ber om mer. Vilket är det viktigaste rådet du skulle ge någon vars projekt verkar ha sprungit iväg? Vad är ditt första tips för att få kontroll igen?

Suze Hayworth:

Om du ombeds komma in i ett helt nytt projekt, alltså ett projekt som precis ska starta, är det viktigaste att arbeta med själva uppskattningen och med hur du avgränsar projektet. Se till att du inte arbetar isolerat. Gör uppskattningen tillsammans med teamet och se till att uppskattningarna är så bra som möjligt, med insikten att de fortfarande bara är uppskattningar. När det sedan är dags att leverera det ni har avgränsat ska du inte plötsligt upptäcka att tidsplanen och budgeten skenar.

Om du kommer in i ett pågående projekt är det viktigt att stanna upp och se var ni befinner er, hur mycket ni ligger över plan och att få en korrekt bild av vad som återstår. Prata sedan med kunden om problemen, var projektet ligger över plan och vad som händer. Var tydlig med detta och ha en öppen dialog.

Ben Aston:

Suze, tack så mycket för att du ville vara med. Det har varit fantastiskt att ha dig här. Som en av våra DPM-experter kommer Suze också att medverka i vår kommande kurs som börjar i februari. Den heter ”Mastering Digital Project Management”. Om du inte vet vad jag pratar om men vet att du behöver utbildning inom projektledning, kan du kolla in den. Det är en intensivkurs på sju veckor med interaktiva videolektioner, uppgifter, webbinarier, gruppdiskussioner och även möjlighet till coachningssessioner. Gå till DPMschool.com och anmäl dig innan kursen blir full. Om du vill bidra till samtalet om omfattningskryp kan du kommentera inlägget och gå till resurssektionen på TheDigitalProjectManager.com för att gå med i vårt Slack-team, där du hittar alla möjliga intressanta samtal. Men tills nästa gång: tack för att du lyssnade.