Hantera omfattningsglidning: Tekniker och verktyg för projektledare

Vad är omfattningsglidning?

Omfattningsglidning uppstår när leveranserna eller funktionerna i ett projekt utökas jämfört med vad som ursprungligen avtalats – men projektplanen eller budgeten justeras inte för att rymma förändringen.

Detta skiljer sig från en omfattningsändring, som innebär alla officiella beslut om att ändra den ursprungliga omfattningen av ett projekt – dess mål, budget, leveranser, tidsplan, ansvarsområden eller andra delar.

Omfattningsglidning kan påverka alla projekt med fast omfattning. Den kan uppstå avsiktligt eller oavsiktligt och kan komma från vilken som helst av de intressenter som är involverade i ett projekt.

Anledningen till att vi bryr oss så mycket om omfattningsglidning är att den kan leda till projektmisslyckanden. Omfattningsglidning kan göra att du missar en deadline, förbrukar (eller överskrider!) din budget genom kostnadsöverskridanden och dessutom fortfarande levererar fel sak. Aj då!

3 typer av omfattningsglidning

Omfattningsglidning kan ta sig flera olika uttryck. Här är några vanliga orsaker till omfattningsglidning:

• Underlåtenhet att fatta och/eller dokumentera beslut: intressenter ändrar ofta uppfattning eller kan inte nå enighet om projektets omfattning på grund av förändrade organisatoriska prioriteringar
• Överdrivet optimistiska projektuppskattningar: teamet underskattar den arbetsinsats som krävs för att slutföra projektuppgifter och nå milstolpar och lovar därför för mycket om vad som ingår i projektets omfattning (under genomförandet kan detta ibland ta sig uttryck som giftig positivism)
• Guldkantning: att lägga till onödiga funktioner i produkten som inte ingick i de ursprungliga kraven.

Vem orsakar omfattningsglidning?

Det är bra att granska ditt projekt för att avgöra vem som kan orsaka omfattningsglidning. Om du identifierar omfattningsglidning tidigt blir det lättare att utforma det bästa sättet att hantera problemet.

PS: Håller omfattningsglidning på att hemsöka ditt projekt?

Scope Creep Made Even Creepier: Keep Him Away from Your Projects

Medlem i projektteamet

Ibland kan medlemmar i projektteamet orsaka omfattningsglidning. Möjliga orsaker är bland annat:

1. Teammedlemmen är osäker på projektets omfattning

I början av projektet ska du beskriva alla krav eller projektleveranser i en omfattningsbeskrivning, projektplan eller arbetsnedbrytningsstruktur (WBS), och se till att teammedlemmarna bekantar sig med denna dokumentation. 

Om omfattningen håller på att fastställas bör du involvera teamet i dessa diskussioner så mycket som möjligt. Om det inte är genomförbart ska du åtminstone hålla ett uppstartsmöte för projektet för att säkerställa samsyn. Under genomförandet bör du ha regelbundna avstämningar med teamet för att hålla alla uppdaterade.

2. Teammedlemmen vill utveckla det hen själv vill, snarare än det som ingår i omfattningen

Att involvera teamet när omfattningen fastställs är ett bra sätt att skapa engagemang för det de ska utforma och bygga. Se till att alla arbetar som ett team. Om någon på eget initiativ börjar producera något som ligger utanför omfattningen skapar det förvirring och potentiella konflikter med andra teammedlemmar.

3. Teammedlemmen fattar beslut i ett vakuum

Ibland väljer en teammedlem ett sätt att lösa ett problem som påverkar omfattningen, ofta utan att inse det.

Även att lägga till en halv dags extra arbete för att göra något lite annorlunda kan påverka resten av projektet. Om en designer till exempel beslutar att inkludera någon funktionalitet på en webbplats (som ett sökfält) utan att diskutera det med utvecklaren, kan det påverka projektets tidsplan.

Skapa goda förutsättningar för att lyckas med projektet genom att bygga en kultur präglad av förtroende och transparens. När någon tar upp ett problem direkt med dig bör du dela det med fler om det finns ett större beslut som behöver fattas. Få människor att samarbeta för att hitta lösningar på problem. Se till att alla har regelbunden kontakt (antingen ansikte mot ansikte eller på distans). 

De flesta framgångsrika projekt kommer från team som arbetar bra tillsammans.

Interna intressenter

Viktiga intressenter inom din organisation kan påverka ett projekts omfattning. De kan ha en vision för organisationen som innebär att ni ska leverera mer inom ditt projekt, eller så kan de vilja driva en annan agenda.

Exempelvis är en kundrelation ibland viktigare för en organisation än att hålla sig inom projektets omfattning.

Se till att dina interna intressenter förstår vad du försöker leverera och när det ska vara klart. Om något skulle få följdeffekter för projektet bör du tydligt redogöra för vilken påverkan det skulle få – oavsett om den är ekonomisk, anseendemässig eller något annat.

Externa användare

Användartester bör (förhoppningsvis) vara en del av projektets eller produktens upplägg. Användarfeedback på en produkt kan påverka händelseförloppet och i slutändan leda till en ökad omfattning. Vad händer om du får feedback från dina användare som visar något du inte kan ignorera? Även om det ökar projektets omfattning måste du hantera det.

När du har sammanställt testresultaten bör du gå igenom dem med teamet för att identifiera de nödvändiga förändringar som ska genomföras. Prioritera så att du förstår vilka förändringar som skulle ha störst påverkan på användarupplevelsen. Definiera sedan vilka förändringar du utan problem kan inkludera utan att påverka omfattningen.

Om någon av de nödvändiga förändringarna skulle innebära en ökad omfattning bör du prata med kunden eller intressenten. Kom förberedd med en förståelse för vad som skulle hända om du beslutade att inte genomföra förändringen.

Tredje parter

Om du är beroende av tredje parter för att leverera projektet – oavsett om det handlar om ett externt företag, ett API från tredje part eller en innehållsleverantör – måste du identifiera beroendena vid projektets uppstart. Reflektera över vilken påverkan dessa beroenden kan ha på projektet och hur de kan påverka omfattningen.

Vad skulle till exempel hända om din innehållsleverantör skickade innehåll i ett format som inte var enkelt att implementera eller ladda upp på webbplatsen? Skulle det lägga till extra tid i tidsplanen? 

Du kommer inte att kunna täcka in alla eventualiteter, men genom att inta ett riskplaneringsperspektiv och ta upp dessa beroenden med kunden i början av projektet får du en bättre förståelse för den potentiella påverkan innan du hamnar i problem.

Projektledare

Vi projektledare kan ibland orsaka omfattningsglidning. Det är väldigt frestande att försöka få saker att fungera inom din befintliga budget och tidsram utan att informera kunden.

Även om det definitivt kan vara ett svårt samtal att säga att du inte kan göra något utan en ändringsbegäran, är det mycket enklare att ta samtalet tidigare än senare i projektets livscykel.

Om du eller ditt team identifierar ett problem bör ni arbeta igenom möjliga lösningar. Om ytterligare arbete behövs kan ni till exempel se vad som i stället kan tas bort från omfattningen – finns det något ni gör i projektet som inte behövs i den första lanseringen? 

Presentera dessa alternativ och en rekommendation för kunden eller intressenten.

Kund

Vi kan inte avsluta det här avsnittet utan att nämna en viktig orsak till omfattningsglidning: kunden. Se upp för kunder eller projektsponsorer som lägger till ”små” önskemål som gradvis bygger ut den ursprungliga omfattningen, ändrar sig eller föreslår nya sätt att göra saker som kan påverka den arbetsinsats som krävs. 

Var ärlig och tydlig med dem om de ber om något som kommer att orsaka omfattningsglidning. Formulera också dina svar så att du inte bara säger ”nej”, utan i stället föreslår ett alternativ. Till exempel:

”Den här nya begäran kommer att få den här specifika påverkan på tid och budget. Vi har tittat på prioriteringarna – vad sägs om att ersätta detta med det i stället? Det ger ett liknande resultat eftersom …”

2 exempel på omfattningsglidning

Nu när vi har gått igenom typerna av och orsakerna till omfattningsglidning ska vi lyfta fram två fallstudier som visar hur omfattningsglidning kan uppstå i dina projekt.

Fallstudie om omfattningsglidning nr 1

Du kanske tror att du är tillräckligt smart för att förhindra omfattningsglidning innan den inträffar, men då underskattar du vad som gör omfattningsglidning så … ja, smygande.

Föreställ dig att du arbetar med att samla in användarfeedback om hur din prototyp fungerar. Du hade kommit överens med din kund om hur många användare du skulle prata med, vilken typ av feedback du skulle ta emot och hur länge kommentarsperioden skulle pågå. Du hade också kommit överens om att hantera feedback upp till en viss timgräns för att genomföra eventuella korrigeringar.

När kommentarsperioden är över blir kunden uppringd av någon senior som inte ingick i testgruppen och frågar om du kan ta in den här personen. Du hade satt en gräns för antalet personer som fick lämna kommentarer, men hur mycket skulle det egentligen skada att lägga till en person? Dessutom vill du göra ett gott intryck på ledningen, så du går med på det sena tillägget.

Innan du vet ordet av har den seniora personen tagit med sig hela sin personal. De vill ha en separat genomgång av testningen och är upprörda över att deras särskilda användningsfall inte har inkluderats.

Även om du lyckas stå på dig och förhindra en förändring av kraven har den extra tiden som gått åt till förhandling, för att inte tala om den ytterligare kommunikationen med intressenter för att komma överens om projektets syfte och mål, ätit upp en och en halv vecka i ett redan pressat schema. Omfattningsglidning slår till igen!

Fallstudie 2 om omfattningsglidning

Det är också viktigt att inse att omfattningsglidning inte behöver bero på en kundförfrågan.

Föreställ dig att du är projektledare och tar över ett projekt med en klassisk vattenfallsmodell som omfattar trådramskisser och en designfas, följt av utveckling.

Du blir involverad i början av utvecklingsfasen. Uppgiften är enkel – du bygger frontend ovanpå en backend från en annan byrå som har försetts med er varumärkesprofil.

Du hade godkänt trådramskisser och design och gått igenom allt med kunden och byrån … vad skulle egentligen kunna gå fel? Jo! Det visade sig att den andra byrån itererade på sin backend och ofta släppte ny kod.

Ironiskt nog hade de inte tagit hänsyn till att din byrå byggde ovanpå den gamla koden, så din kod går sönder vid varje lansering.

För att åtgärda detta bestämmer du att teamet måste gå tillbaka genom koden och uppdatera den så att den fungerar med de kontinuerliga förändringarna från den andra byrån. Detta var inte medräknat – men det var nödvändigt.

Till en början bestod det extra arbetet av någon enstaka liten korrigering vid behov, men allt fler problem började uppstå. Även om du tog upp detta med kunden försökte du baka in det extra arbetet i projektet i stället för att påpeka för kunden att ni behövde hitta en gemensam lösning innan ni fortsatte med bygget.

Vilken nytta efterklokhet ändå kan ha! Vad hände? Du fastnade allt djupare i att utveckla om den befintliga koden – tidsplanerna förlängdes, du missade din deadline och din byrå utsattes för ett stort tryck mot slutet av projektet. Teamet tappade motivationen, kunden var inte nöjd och projektet blev till slut försenat med två månader.

Så undviker du omfattningsglidning

Här är några strategier för att minska risken för att omfattningen börjar växa i dina projekt:

• Definiera tydligt projektets omfattning från början, helst genom att involvera projektteamet för att skapa engagemang. Använd en arbetsbeskrivning för att dokumentera vad som ingår i och ligger utanför omfattningen. Kommunicera sedan omfattningen till teammedlemmar och projektets intressenter, inklusive kunden.
• Involvera hela teamet för att ta fram välgrundade uppskattningar baserade på kraven. För att minska risken för felaktiga uppskattningar: 1) avsätt tid för en upptäcktsfas för att fastställa vad ni ska bygga, 2) använd ett avtal baserat på tid och material i stället för ett avtal till fast pris och 3) var mindre detaljerad när det gäller vilka funktioner ni ska bygga. Fokusera på önskade resultat.
• Bygg in beredskapsplaner för att säkerställa att ni avsätter tillräckligt med tid för kvalitetssäkring. Överväg också att använda automatiserade tester för att spara tid – artiklarna För- och nackdelar med manuella och automatiserade tester och Bästa verktygen för automatisering är användbara referenser.
• Skapa en plan för förändringshantering i början av ett projekt som beskriver hur ni ska hantera förändringar av omfattningen. Om ni tänker använda ändringsbegäranden ska ni beskriva den process för ändringskontroll som ni ska följa i detalj.
• Samarbeta nära med kunden under projektgenomförandet. Visa dem projektets framsteg eller statusrapport för projektet, iterera och involvera dem under hela resan så att det inte uppstår några överraskningar.
• Ta proaktivt upp problem antingen när de uppstår eller helst innan de uppstår (förutsatt att ni har utarbetat en lösning för att hantera problemet!). Använd en riskhanteringsplan för att dokumentera er riskhanteringsprocess. Upprätthåll och granska ett riskregister som håller reda på potentiella risker.
• Ställ frågor för att prioritera inkommande förfrågningar. Se till att dessa förfrågningar inte oavsiktligt utökar omfattningen, duplicerar arbete eller leder till att onödiga ytterligare funktioner byggs. Samarbeta med teamet för att förstå varje förfrågan, dess påverkan på projektets budget och tidsplan samt det förväntade användarresultatet, så att ni kan prioritera därefter.
• Involvera användarna tidigt. Det är frestande att lura oss själva att tro att vi (kunderna, verksamheten och teamet) känner användarna tillräckligt väl för att slippa interagera med dem. Verkligheten är att om ni inte tar hänsyn till användarfeedback tidigt kan ni slösa mycket tid på att följa en väg som inte skapar något värde. Då kan omfattningen börja växa okontrollerat.

More Articles

• Så bemästrar du resurshantering i projektledning

Så hanterar du omfattningsglidning

Om ert projekt drabbas av omfattningsglidning (eller om ni har tagit över ett arbete med en alltför stor omfattning), få inte panik. Ni har fortfarande möjlighet att ta er ur situationen. 

Här är några steg som jag har följt när jag har tagit över ett problemfyllt projekt som hade drabbats av omfattningsglidning:

• Börja med att förklara situationen för kunden eller intressenten. Förklara hur ni har hamnat där ni är och vilka åtgärdsplaner ni har för att hantera situationen. Det finns ingen anledning att försköna den. Situationen är som den är.
• Rekommendera sätt att förenkla utan att offra värde. Det kan innebära att vissa funktioner får lägre prioritet eller att ni kompromissar med sådant som är ”trevligt att ha” tills ni kan lansera något som en snabb uppföljning. Förbered en presentation för kunden som tydligt visar kompromisserna mellan de olika tillvägagångssätten.
• Anpassa teamets storlek och sammansättning. Det kan innebära att någon som underpresterar får lämna eller att ni ersätter en dyrare resurs med en billigare resurs för att spara pengar i budgeten. Det är obehagligt att ha dessa samtal, men alternativet kan vara att förlora kunden, vilket får större konsekvenser för hela organisationen.
• Hantera följderna. Ibland kräver det att man räddar ett sjunkande skepp att man sväljer stoltheten och offrar projektets övergripande lönsamhet för att reparera en värdefull kundrelation. Det kan krävas extra arbetstimmar för att få något i mål tidigare än planerat som ett sätt att gottgöra situationen. Nyckeln är att begränsa detta till en kortsiktig insats så att det inte blir en dålig vana.

Tänk också på att omfattningsglidning ibland kan vara positivt. I stället för att se det som en lömsk fiende kan ni helt enkelt betrakta det som förändring. Och förändring kan vara mycket värdefull för produkten ni skapar. Det är hur ni hanterar förändringen som påverkar projektet – inte själva begäran om att ändra det.

Ni behöver bara vara uppmärksamma på att upptäcka det när det händer, särskilt när det inte är uppenbart, och ta upp det innan det fortskrider utan någon form av omplanering.

Så hanterar du omfattningen i agila projekt

Omfattningsglidning gäller vanligtvis projekt med en fast omfattning. Men vad händer om ni använder en agil metodik?

Agilt arbete välkomnar förändring – och ärligt talat bör även agila projektledare göra det. Som en av de grundläggande principerna inom agilt arbete lyder:

Välkomna förändrade krav, även sent i utvecklingen. Agila processer utnyttjar förändringar till kundens konkurrensfördel.

Om du till exempel arbetar med Scrum-metodik och ett nytt krav kommer in, lägger du till det i backloggen för prioritering tillsammans med produktägaren och teamet. Om kravet faktiskt kommer med i sprinten under sprintplaneringsmötet, nedprioriterar du i stället något annat.

Poängen med agilt arbete är att iterera, vilket innebär att utforma, bygga, testa, lära sig och sedan upprepa cykeln. Eftersom agila projekt inte kartlägger alla detaljer i förväg finns det utrymme för förändringar – du kan byta ut en användarberättelse mot en annan som kräver samma arbetsinsats. Förändringar är det som leder till den bästa möjliga produkten inom den tid du har.

Så vad räknas som omfattningsglidning i ett agilt projekt? Omfattningsglidning kan uppstå om produktägaren inte nedprioriterar funktioner eller uppgifter när ett nytt krav tas in.

De kan också misslyckas med att väga den arbetsinsats som krävs för den nya uppgiften mot den nedprioriterade uppgiften, vilket kan leda till att extra arbete kläms in i en redan alltför snäv cykel.

Se till att du, för alla nya funktioner som kommer in i backloggen, bryter ner dem i berättelser och förstår arbetsinsatsen för att kunna prioritera dem på rätt sätt.

Det är vanligtvis mycket enklare att begränsa omfattningsglidning i ett agilt projekt, just eftersom den agila metoden uppmuntrar till förändringar och tar hänsyn till dem i själva metodens struktur.

I ett vattenfallsprojekt byggs produkten sannolikt steg för steg tills du slutför den glänsande nya saken i slutet. Det kan leda till att man tänker att allt är prioriterat.

Om du inte har tydliga prioriteringar bland funktionerna är det svårt att förstå vad som ska tas bort när justeringar av projektkraven börjar dyka upp.

Vad händer härnäst?

Vill du komma i kontakt med andra digitala projektledare för att dela resurser och bästa praxis? Gå med i vår medlemscommunity och få tillgång till över 100 mallar, exempel och prov samt möjlighet att få kontakt med hundratals andra digitala projektledare på Slack.