Håndtering af ukontrolleret omfangsudvidelse: Teknikker og værktøjer for projektledere

Hvad er ukontrolleret omfangsudvidelse?

Ukontrolleret omfangsudvidelse opstår, når leverancerne eller funktionerne i et projekt udvides i forhold til det, der oprindeligt blev aftalt – men projektplanen eller budgettet ikke tilpasses for at imødekomme ændringen.

Dette adskiller sig fra en ændring af omfanget, som omfatter alle officielle beslutninger om at ændre et projekts oprindelige omfang – dets mål, budget, leverancer, tidsplan, ansvarsområder eller andre elementer.

Ukontrolleret omfangsudvidelse kan påvirke alle projekter med et fast omfang. Det kan ske enten bevidst eller ubevidst, og det kan stamme fra alle mulige interessenter, der er involveret i et projekt.

Grunden til, at vi går så meget op i ukontrolleret omfangsudvidelse, er, at det kan føre til projektsvigt. Ukontrolleret omfangsudvidelse kan få dig til at overskride en deadline, opbruge (eller overskride!) dit budget på grund af omkostningsoverskridelser og ovenikøbet stadig levere det forkerte. Åh nej!

3 former for ukontrolleret omfangsudvidelse

Ukontrolleret omfangsudvidelse kan komme i flere forskellige former. Her er nogle almindelige årsager til ukontrolleret omfangsudvidelse:

• Manglende beslutninger og/eller dokumentation af beslutninger: Interessenter skifter ofte mening eller kan ikke nå til enighed om projektets omfang på grund af skiftende organisatoriske prioriteter
• Alt for optimistiske projektestimater: Teamet undervurderer den indsats, der kræves for at gennemføre projektopgaver og nå milepæle, og lover derfor for meget om, hvad der er en del af projektets omfang (i udførelsen kan dette nogle gange komme til udtryk som giftig positivitet)
• Unødvendig ekstraudvikling: Tilføjelse af unødvendige funktioner til produktet, som ikke var en del af de oprindelige krav.

Hvem forårsager ukontrolleret omfangsudvidelse?

Det er nyttigt at se nærmere på dit projekt for at afgøre, hvem der kan forårsage ukontrolleret omfangsudvidelse. Hvis du identificerer ukontrolleret omfangsudvidelse tidligt, kan du finde den bedste tilgang til at håndtere problemet.

P.S.: Hjemsøger ukontrolleret omfangsudvidelse dit projekt?

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

Medlem af projektteamet

Nogle gange kan medlemmer af projektteamet forårsage ukontrolleret omfangsudvidelse. Mulige årsager omfatter:

1. Teammedlemmet er usikker på projektets omfang

I begyndelsen af projektet skal du beskrive alle krav eller projektleverancer i en omfangsbeskrivelse, projektplan eller arbejdsnedbrydningsstruktur (WBS), og sørge for, at teammedlemmerne gør sig bekendt med denne dokumentation. 

Hvis omfanget er ved at blive fastlagt, skal du så vidt muligt inddrage teamet i disse samtaler. Hvis det ikke er muligt, skal du som minimum afholde et projektopstartsmøde for at sikre fælles forståelse. Under udførelsen skal du holde regelmæssige opfølgningsmøder med teamet for at sikre, at alle er på samme side.

2. Teammedlemmet vil udvikle det, de selv ønsker, i stedet for det, der er en del af omfanget

Det er nyttigt at inddrage teamet i fastlæggelsen af omfanget for at skabe opbakning til det, de skal designe og udvikle. Sørg for, at alle arbejder som et team. Hvis nogen på eget initiativ går i gang med at producere noget, der ligger uden for omfanget, skaber det forvirring og potentielle konflikter med andre teammedlemmer.

3. Teammedlemmet træffer beslutninger isoleret

Nogle gange vælger et teammedlem en måde at løse et problem på, som påvirker omfanget, ofte uden at være klar over det.

Selv det at tilføje en halv dags ekstra arbejde for at gøre noget lidt anderledes kan påvirke resten af dit projekt. Hvis en designer for eksempel beslutter at inkludere en funktion på et website (som en søgelinje) uden at drøfte det med udvikleren, kan det påvirke projektets tidsplan.

Skab de bedste forudsætninger for et vellykket projekt ved at opbygge en kultur præget af tillid og gennemsigtighed. Når nogen tager et problem direkte op med dig, skal du dele det bredere, hvis der skal træffes en større beslutning. Få folk til at arbejde sammen om at finde løsninger på problemer. Sørg for, at alle er i kontakt med hinanden (uanset om det er ansigt til ansigt eller på afstand) regelmæssigt. 

De fleste vellykkede projekter udspringer af teams, der arbejder godt sammen.

Interne interessenter

Vigtige interessenter i din organisation kan påvirke et projekts omfang. De kan have en vision for organisationen, som indebærer, at der leveres mere til dit projekt, eller de kan ønske at fremme en anden dagsorden.

For eksempel er et kundeforhold nogle gange vigtigere for en organisation end at holde sig inden for projektets omfang.

Sørg for, at dine interne interessenter forstår, hvad du forsøger at levere, og hvornår det skal være færdigt. Hvis noget vil have en afledt effekt på dit projekt, skal du tydeligt redegøre for, hvilken indvirkning det vil have – hvad enten den er økonomisk, omdømmemæssig eller noget andet.

Eksterne brugere

Brugertest bør (forhåbentlig) være en del af opsætningen af dit projekt eller produkt. Brugerfeedback på et produkt kan påvirke et hændelsesforløb, som i sidste ende øger omfanget. Hvad sker der, hvis du får feedback fra dine brugere, som viser noget, du ikke kan ignorere? Selv hvis det øger omfanget, er du nødt til at håndtere det.

Når du har samlet resultaterne fra testene, skal du gennemgå dem med dit team for at identificere de nødvendige ændringer, der skal implementeres. Prioritér, så du forstår, hvilke ændringer der vil have størst indvirkning på brugeroplevelsen. Definér derefter, hvilke ændringer du uden problemer kan indarbejde uden at påvirke omfanget.

Hvis nogle af de nødvendige ændringer vil medføre et øget omfang, skal du tale med din kunde eller interessent. Mød forberedt op med en forståelse af, hvad der ville ske, hvis du besluttede ikke at implementere ændringen.

Tredjeparter

Hvis du er afhængig af tredjeparter for at levere dit projekt – hvad enten det er en ekstern virksomhed, et API fra en tredjepart eller en indholdsleverandør – skal du identificere afhængighederne ved projektets opstart. Overvej, hvilken indvirkning disse afhængigheder kan have på dit projekt, og hvordan de kan påvirke dit omfang.

Hvad nu hvis din indholdsleverandør for eksempel sendte dig indhold, der ikke var i et format, som var let at implementere eller uploade på dit website? Ville det føje ekstra tid til din tidsplan? 

Du vil ikke kunne dække alle eventualiteter, men hvis du anlægger en risikoplanlægningstilgang og tager disse afhængigheder op med kunden i begyndelsen af et projekt, vil det hjælpe dig med at forstå den potentielle indvirkning, før du står med et problem.

Projektleder

Vi projektledere kan nogle gange selv forårsage en udvidelse af projektets omfang. Det er meget fristende at forsøge at få tingene til at fungere inden for dit eksisterende budget og din tidsramme uden at gøre kunden opmærksom på det.

Selvom det bestemt kan være en vanskelig samtale at sige, at du ikke kan gøre noget uden en ændringsanmodning, er denne samtale meget lettere at tage tidligere end senere i projektets livscyklus.

Hvis du eller dit team identificerer et problem, skal I arbejde jer igennem mulige løsninger. Hvis der for eksempel er behov for ekstra arbejde, skal I se, hvad der i stedet kan tages ud af omfanget – er der noget, I gør i projektet, som ikke er nødvendigt i den første udgivelse? 

Præsentér disse muligheder og en anbefaling for kunden eller interessenten.

Kunde

Vi kan ikke afslutte dette afsnit uden at nævne en vigtig årsag til udvidelse af projektets omfang: din kunde. Pas på kunder eller projektsponsorer, der tilføjer “små” ønsker, som gradvist udvider det oprindelige omfang, skifter mening eller foreslår nye måder at gøre tingene på, som kan påvirke det nødvendige arbejdsomfang. 

Vær ærlig og tydelig over for dem, hvis de beder om noget, der vil medføre en udvidelse af projektets omfang. Formulér også dine svar, så du ikke blot siger “nej”, men i stedet foreslår et alternativ. For eksempel:

“Denne nye anmodning vil have en specifik indvirkning på tid/budgettet. Vi har set på prioriteterne – hvad med at erstatte dette med hint i stedet? Det opnår et lignende resultat, fordi …”

2 eksempler på udvidelse af projektets omfang

Nu hvor vi har gennemgået typerne og årsagerne til udvidelse af projektets omfang, vil vi fremhæve to casestudier, der viser, hvordan en sådan udvidelse kan opstå i dine projekter.

Case om udvidelse af projektets omfang nr. 1

Du tror måske, at du er klog nok til at forhindre en udvidelse af projektets omfang, før den opstår, men så undervurderer du, hvad der gør sådan en udvidelse så, ja, uhyggelig.

Forestil dig, at du arbejder på at indsamle brugerfeedback om, hvordan din prototype fungerer. Du havde aftalt med din kunde, hvor mange brugere du ville tale med, hvilken type feedback du ville acceptere, og hvor lang kommentarrunden skulle være. Du havde også aftalt at håndtere feedback op til en bestemt grænse for det antal timer, der var nødvendige for at implementere eventuelle rettelser.

Da kommentarrunden lukker, bliver kunden ringet op af en seniorperson, som ikke var en del af testgruppen, og spørger, om du kan få denne person involveret. Du havde fastsat en grænse for antallet af kommentatorer, men hvor meget ville det egentlig skade at tilføje én person? Desuden vil du gerne efterlade et godt indtryk hos ledelsen, så du accepterer tilføjelsen i sidste øjeblik.

Før du ved af det, har denne seniorperson tilføjet hele sit team. De ønsker en separat gennemgang af testen, og de er frustrerede over, at deres særlige anvendelsesscenarie ikke er blevet inkluderet.

Selvom det lykkes dig at holde fast og forhindre en ændring af kravene, har den ekstra tid, der er gået med forhandlinger, for slet ikke at nævne den yderligere kommunikation med interessenter for at skabe enighed om projektets formål og målsætninger, kostet halvanden uge i en allerede stram tidsplan. Ukontrolleret udvidelse af projektets omfang slår til igen!

Casestudie nr. 2: Ukontrolleret udvidelse af projektets omfang

Det er også vigtigt at erkende, at en ukontrolleret udvidelse af projektets omfang ikke nødvendigvis behøver at skyldes en kundeanmodning.

Forestil dig, at du er projektleder og overtager et projekt med en klassisk vandfaldsmodel, der omfatter wireframes og en designfase efterfulgt af udvikling.

Du bliver involveret i begyndelsen af udviklingsfasen. Opgaven er ligetil – du skal bygge brugergrænsefladen oven på et bagvedliggende system uden branding fra et andet bureau.

Du havde godkendt wireframes og design og gennemgået alt med kunden og bureauet … hvad kunne der dog gå galt? Jo! Det viser sig, at det andet bureau løbende videreudviklede deres bagvedliggende system og ofte udgav ny kode.

Ironisk nok havde de ikke taget højde for, at dit bureau byggede oven på den gamle kode, så din kode går i stykker ved hver udgivelse.

For at løse dette beslutter du, at teamet skal gennemgå koden igen og opdatere den, så den fungerer sammen med de løbende ændringer fra det andet bureau. Der var ikke taget højde for dette – men det var nødvendigt.

I begyndelsen bestod det ekstra arbejde af en enkelt mindre rettelse efter behov, men der begyndte at opstå flere og flere problemer. Selvom du gjorde kunden opmærksom på dette, forsøgte du at indarbejde det ekstra arbejde i dit projekt i stedet for at gøre kunden opmærksom på behovet for at finde en fælles løsning, før udviklingen fortsatte.

Åh, bagklogskabens klare lys! Hvad skete der? Du sank dybere og dybere ned i at genudvikle den eksisterende kode – tidsplanerne blev forlænget, du missede din deadline, og dit bureau kom under stort pres hen mod projektets afslutning. Teamet mistede motivationen, kunden var ikke tilfreds, og i sidste ende blev projektet forsinket med to måneder.

Sådan undgår du ukontrolleret udvidelse af projektets omfang

Her er nogle strategier til at mindske sandsynligheden for, at projektets omfang udvides ukontrolleret:

• Definér tydeligt projektets omfang fra starten, og involvér helst projektteamet for at opnå opbakning. Brug en projektbeskrivelse til at dokumentere, hvad der er omfattet og ikke omfattet af projektet. Kommunikér derefter omfanget til teammedlemmer og projektets interessenter, herunder kunden.
• Involvér hele teamet for at udarbejde solide estimater baseret på kravene. For at reducere risikoen for forkerte estimater: 1) afsæt tid til en afklaringsperiode for at fastslå, hvad I skal bygge, 2) brug en kontrakt baseret på tid og materialer i stedet for en fast pris, og 3) vær mindre specifik med hensyn til de funktioner, I vil bygge. Fokuser på de ønskede resultater.
• Indarbejd beredskabsplaner for at sikre, at du afsætter tilstrækkelig tid til kvalitetssikring. Overvej også at bruge automatiserede tests for at spare tid – artiklerne Fordele og ulemper ved manuel og automatiseret test og De bedste automatiseringsværktøjer er nyttige referencer.
• Udarbejd en plan for ændringsstyring i begyndelsen af et projekt, som beskriver, hvordan du vil håndtere ændringer i omfanget. Hvis du har til hensigt at bruge ændringsanmodninger, skal du beskrive den ændringskontrolproces, du vil følge.
• Samarbejd tæt med din kunde under projektgennemførelsen. Vis dem projektets fremskridt eller projektstatusrapporten, gentag processen, og involvér dem under hele forløbet, så der ikke opstår overraskelser.
• Tag proaktivt problemer op, enten når de opstår eller helst inden de opstår (forudsat at du har fundet en løsning på problemet!). Brug en risikostyringsplan til at dokumentere din risikostyringsproces. Vedligehold og gennemgå et risikoregister, der holder styr på potentielle risici.
• Stil spørgsmål for at prioritere indkommende anmodninger. Sørg for, at disse anmodninger ikke utilsigtet udvider omfanget, duplikerer arbejde eller fører til udvikling af unødvendige ekstra funktioner. Gå i dialog med teamet for at forstå hver anmodning, dens indvirkning på projektets budget og tidsplan samt det forventede brugerresultat, så du kan prioritere derefter.
• Involvér brugerne tidligt. Det er fristende at narre os selv til at tro, at vi (kunderne, virksomheden, teamet) kender brugerne godt nok til at undgå at interagere med dem. Virkeligheden er, at hvis du ikke indarbejder brugerfeedback tidligt, kan du spilde meget tid på at følge en retning, der ikke skaber værdi. På det tidspunkt kan projektets omfang løbe løbsk.

More Articles

• Eisenhower-matricen: Sådan prioriterer du opgaver på en smart måde
• Tips til at opbygge din Slack-profil
• Sådan mestrer du ressourcestyring i projektledelse

Sådan håndterer du en udvidelse af projektets omfang

Hvis dit projekt bliver ramt af en udvidelse af projektets omfang (eller du har overtaget et projekt med et alt for stort omfang), skal du ikke gå i panik. Du har stadig mulighed for at arbejde dig ud af problemerne. 

Her er nogle trin, jeg har fulgt, når jeg har overtaget et projekt i problemer, der var blevet ramt af en udvidelse af projektets omfang:

• Begynd med at forklare situationen for din kunde eller interessent. Forklar, hvordan I er endt, hvor I er, og hvad dine planer for at afhjælpe situationen er. Der er ingen grund til at forskønne det. Situationen er, som den er.
• Anbefal måder, hvorpå I kan springe over, hvor gærdet er lavest, uden at ofre værdi. Det kan betyde, at visse funktioner nedprioriteres, eller at I går på kompromis med funktioner, der er “gode at have”, indtil I kan udgive noget som en hurtig opfølgning. Forbered en præsentation til din kunde, der tydeligt beskriver kompromiserne ved hver af jeres tilgange.
• Tilpas teamets størrelse og sammensætning. Det kan betyde, at en person, der ikke præsterer tilfredsstillende, skal forlade teamet, eller at en dyrere ressource erstattes af en billigere ressource for at spare på budgettet. Det er ubehageligt at have disse samtaler, men alternativet er potentielt at miste kunden, hvilket kan få større konsekvenser i hele organisationen.
• Håndtér eftervirkningerne. Nogle gange kræver det at rette op på et synkende skib, at du sluger din stolthed og ofrer projektets samlede lønsomhed for at genopbygge et værdifuldt kundeforhold. Det kan være nødvendigt at lægge ekstra timer for at få noget i mål tidligere end planlagt som en måde at gøre skaden god igen på. Det afgørende er at begrænse denne belastning til en kortvarig indsats, så det ikke bliver en dårlig vane.

Husk også, at en udvidelse af projektets omfang nogle gange kan være gavnlig. I stedet for at se det som en snigende fjende kan du ganske enkelt betragte det som en ændring. Og ændringer kan være yderst gavnlige for det produkt, du er ved at skabe. Det er måden, du håndterer ændringen på, der påvirker projektet – ikke anmodningen om at ændre det.

Du skal blot være opmærksom på at opdage det, når det sker, især når det ikke er tydeligt, og tage det op, før det udvikler sig uden nogen form for genplanlægning.

Sådan håndterer du projektets omfang i agil udvikling

En udvidelse af projektets omfang gælder typisk projekter med et fast omfang. Hvad nu, hvis du bruger en agil metode?

Agil udvikling omfavner ændringer – og det bør agile projektledere ærligt talt også gøre. Som et af de grundlæggende principper i agil udvikling siger:

Byd ændrede krav velkommen, selv sent i udviklingen. Agile processer udnytter ændringer til kundens konkurrencemæssige fordel.

Hvis du for eksempel arbejder med Scrum-metoden, skal du, når der kommer et nyt krav, føje det til backloggen, så det kan prioriteres sammen med produktejeren og teamet. Hvis dette krav faktisk kommer med i sprintet under sprintplanlægningsmødet, skal noget andet i stedet nedprioriteres.

Pointen med agile er at iterere, hvilket betyder at designe, bygge, teste, lære og derefter gentage cyklussen. Fordi agile projekter ikke fastlægger detaljerne på forhånd, er der plads til ændringer – du kan udskifte én brugerhistorie med en anden, der kræver samme arbejdsindsats. Det er ændringer, der fører til det bedst mulige produkt inden for den tid, du har.

Så hvad tæller som omfangsglidning i et agilt projekt? Omfangsglidning kan opstå, hvis din produktejer undlader at nedprioritere funktioner eller opgaver, når et nyt krav tages ind.

De kan også undlade at vurdere den nødvendige arbejdsindsats for den nye opgave i forhold til den nedprioriterede, hvilket kan resultere i, at der presses ekstra arbejde ind i en cyklus, der allerede er for stram.

Sørg for, at du for alle nye funktioner, der kommer ind i backloggen, opdeler dem i historier og forstår arbejdsindsatsen, så du kan prioritere dem derefter.

Det er typisk langt lettere at begrænse omfangsglidning i et agilt projekt, netop fordi den agile metode tilskynder til ændringer og indarbejder dem i selve metodens struktur.

I et vandfaldsprojekt bliver dit produkt sandsynligvis bygget trin for trin, indtil du til sidst har færdiggjort det skinnende nye produkt. Det kan føre til, at man tænker, at alt er en prioritet.

Hvis du ikke har tydelige prioriteringer blandt funktionerne, er det svært at forstå, hvad der skal udgå af projektets omfang, når der begynder at dukke justeringer af projektkravene op.

Hvad er det næste?

Vil du i kontakt med andre digitale projektledere for at dele ressourcer og bedste praksis? Bliv medlem af vores fællesskab og få adgang til over 100 skabeloner, prøver og eksempler, og kom i kontakt med hundredvis af andre digitale projektledere på Slack.