6 almindelige årsager til, at projekter mislykkes: Eksempler og lærdomme
Hvorfor er det, at så mange projekter mislykkes? En ofte citeret statistik siger, at 70 % af projekterne mislykkes. Selvom der ikke ser ud til at være nogen oprindelig kilde til denne statistik, er det værd at spørge, hvorfor projekter mislykkes. Hvis vi kan lære af tidligere projektfiaskoer, kan vi undgå at begå de samme fejl to gange.
Da jeg først blev projektleder, lærte jeg tilsyneladende alt om fejl i projektledelse på den hårde måde: ved at fejlbedømme estimater, glemme at stille vigtige spørgsmål og være tøvende med at sige nej.
Selvom jeg på dette tidspunkt har arbejdet som projektleder i mange år, har jeg stadig oplevet projekter mislykkes spektakulært af alle mulige årsager. I denne artikel gennemgår jeg, hvad der får projekter til at mislykkes, hvorfor projekter i sidste ende mislykkes, og tips til at undgå fiasko.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Hvornår betragtes projekter som fiaskoer?
Projekter betragtes som fiaskoer, når de overskrider budgettet, leveres for sent eller ikke leveres i henhold til det planlagte omfang. Der er dog ofte en vis fleksibilitet. Projekter bliver ofte forsinket af årsager, som ligger uden for projektlederens kontrol (f.eks. sendte kunden ikke indholdet til deres websted til tiden).
Omfanget kan også ofte ændre sig undervejs i et projekt på grund af ændringer i kundens eller interessenternes behov. Selvom omfangsudvidelse kan være en årsag til projektfiasko, behøver det ikke at ende med et mislykket projekt, hvis det håndteres korrekt (med ændringsanmodninger og godkendelse fra de vigtigste interessenter).
6 almindelige årsager til, at projekter mislykkes & eksempler
Så hvorfor mislykkes projekter? Her er fem af mine største fejl inden for projektledelse, som illustrerer almindelige årsager til projektfiasko, samt de vigtige erfaringer, jeg tog med mig for at forbedre fremtidige projekters succes.
1. Ikke at kommunikere, når tingene bliver vanskelige
Det er et grundlæggende menneskeligt instinkt ikke at ville henlede opmærksomheden på sig selv, hvis noget er gået galt, og ingen har lagt mærke til det. Det strider mod selve projektledelsens natur, men dårlig kommunikation er så ofte årsagen til, at projekter mislykkes.
Jeg må indrømme, at kombinationen af en meget vanskelig kunde og et budget eller en tidsplan, der var ved at blive overskredet, har fået mig til at tøve lidt for længe med at informere en kunde om status for deres projekt.
Det gælder især, når der har været roligt, og alt har været i orden i de seneste dage eller uger i et projekt. Det er også det mest sårbare tidspunkt i projektets tidsramme – det er så vigtigt at bevare og styrke den tillid, en kunde har til sin projektleder.
Erfaring:
Hver gang jeg er ved at holde en pause, før jeg giver en kunde dårlige nyheder, tænker jeg ved mig selv: Er det bedre at afstemme deres forventninger nu, eller vil jeg håndtere dette, efter det er for sent? Svaret er, at det ALTID skal gøres nu, og at man skal være proaktiv.
Du lægger også grunden til håndteringen af fremtidige urealistiske forventninger, mens du arbejder med en bestemt kunde.
2. Ikke at holde sig til det aftalte omfang
På et særligt detaljeret projekt foreslog et teammedlem, der arbejdede tæt sammen med mig, at vi prøvede et nyt skydermodul til en porteføljesektion, som vi var ved at udvikle til en kundes websted.
Det brugte en ramme, som vi typisk ikke arbejdede med, men skydermodulet så bedre ud og fungerede mere elegant end det, vi normalt brugte. Jeg var i begyndelsen tøvende på grund af den stramme tidsplan og projektets særligt detaljerede designanvisninger, men jeg blev overtalt af løftet om bedre funktionalitet for kunden OG vores udviklingsteam.
Det var ikke noget, vi tidligere havde drøftet at opgradere i vores sædvanlige værktøjssæt, men tidspunktet virkede rigtigt, og det var en god mulighed for at se det nye plugin i aktion.
Det endte med at blive en af projektets mest omkostningstunge beslutninger målt i arbejdstimer og budget. Skydermodulet understøttede ikke en vigtig funktion og understøttede heller ikke nemt responsiv skalering eller bestemte browsere.
Det gik ikke gennem den sædvanlige vurderings- og beslutningsproces med tekniske ledere og andre udviklere som en planlagt opdatering. Det var en utrolig simpel fejl, som endte med at koste os begge meget stress, forlegenhed og spildte ressourcer.
Unødvendigt at ’forgylde’ omfanget ved at tilføje nye projektleverancer eller gøre projektopgaver mere komplicerede er en anden typisk årsag til, at projekter mislykkes.
Erfaring:
Hold dig til dine processer, og opdater ikke ting på et indfald. Hvis dine teammedlemmer virkelig har brug for eller kan drage fordel af en ændring i processer eller værktøjer (herunder software til projektledelse eller andre projektstyringsværktøjer og teknologier) midt i projektet, skal du gennemføre hele processen for at vurdere det.
3. At blive for venlig med dit team og dine kunder
Der er en tydelig forskel mellem professionelle relationer og uformelle venskaber, og jeg har lært at holde dem adskilt gennem omhyggelig praksis.
Det betyder ikke, at du ikke kan være venner med dine teammedlemmer eller kunder – du skal bare være opmærksom på, hvornår du slår professionaliteten til eller fra i dine interaktioner.
For flere år siden arbejdede jeg i en virksomhed fyldt med mennesker, der lige var blevet færdige med deres uddannelse, og som alle havde lignende interesser og boede tæt på hinanden i vores by. Naturligvis hang vi ud sammen efter arbejde og i weekenderne, og vi udviklede stærke venskaber.
En dag var jeg nødt til at bede om en hurtig levering på et projekt, som ingen rigtig kunne lide – det var hverken flot, sjovt eller noget, som de fleste mennesker så eller satte pris på.
Designeren på projektet overskred afleveringsfristen markant og arbejdede i stedet på et større, mere moderne webstedsdesign, som først skulle afleveres flere uger senere. Jeg konfronterede ham med det, og han spurgte mig, hvorfor jeg var så hård ved ham, når vi nu var venner.
En udviskning af grænserne mellem det personlige og det professionelle er nogle gange årsagen til, at projekter mislykkes, fordi det kan påvirke ansvarligheden.
Lektion:
Vær venlig, men forbliv professionel, så du fortsat kan holde folk ansvarlige for deres handlinger på et projekt. Det er meget lettere at føle, at vi får et “fripas” hos vores venner, og det kan være en farlig (og akavet) situation at havne i, når det blandes sammen med professionelle forpligtelser.
4. At gå i panik, før du får mulighed for at bearbejde det
Måske er det bare mig, men jeg synes, det er nemt at reagere på bestemte røde flag eller nøgleord i projekter.
Ting som e-mails skrevet med versaler, ordene “ny deadline” eller “websted nede”, eller mere harmløse advarselstegn som manglende kommunikation på et afgørende tidspunkt i et projekt, at en ny interessent bliver involveret i et projekt lige før lanceringen, eller mærkelige fejl på et websted lige før kundedemonstrationer.
Der er ikke noget, der gør mig mere forvirret end straks at henvende mig til en leder, udvikler eller kunde for at bede om en afklaring på noget, der ville have været indlysende (eller muligt for mig selv at løse), hvis jeg havde taget mig et øjeblik til at trække vejret, bearbejde situationen og tænke over mit næste skridt.
Der har været så mange tilfælde, hvor jeg troede, at der var en alvorlig fejl på et websted (mens det blot var et problem med min egen eller kundens cache), fejlfortolkede en forespørgsel på en funktion, der virkede meget større end det, der faktisk var nødvendigt, eller hvor en kunde troede, at deres websted/server var nede, selvom de i virkeligheden ikke havde forbindelse til internettet (ja, det sker ofte).
Selvom dette punkt ikke i sig selv udgør én stor projektfejl, bidrager det til dårlig kommunikation og kan udløse panik, når der ikke er behov for panik.
Lektion:
Vær aldrig bange for at se væk fra en reaktiv e-mail eller besked, holde en pause og tage dig et øjeblik til at undersøge sagen, før du beder om mere hjælp.
5. Ikke at følge processer
Ah ja: fejlslutningen om, at “dette element kan springe vores normale udviklings-/design-/gennemgangs-/QA-proces over, fordi det kun er en lille ændring”. Det er så ofte grunden til, at projekter mislykkes.
Jeg har set det ske på projekter så mange gange. Jeg har begået denne fejl med tilsyneladende “nemme” vedligeholdelsesopdateringer, små funktionsforespørgsler på større projekter og ændringer af projektomfanget generelt.
Noget så simpelt som at opdatere en formularfeltsindstilling kan se enkelt ud på overfladen, men kan udvikle sig til spaghetti-kode og en opdatering af hele systemet, når en udvikler går i gang med det.
På samme måde kan en kunde, der beder om en lille visuel ændring i et projekt, vende op og ned på designprocessen og tvinge dig til at gentænke en del af hele webstedets brugerflow.
Lektion:
Stol altid på processen, og gennemgå afdæknings-, estimerings- og QA-processerne i overensstemmelse hermed: Jeg har lært, at der aldrig findes en lille nok ændring til IKKE at forstyrre noget andet undervejs.
Beskyt din proces, og bliv en forkæmper for at gøre tingene på den rigtige måde – også selvom det kun betyder en lille smule ekstra arbejde. Det betyder også, at du skal vælge den rigtige projektledelsesmetodik eller arbejdsgang, uanset om det er agilt, vandfald, Kanban eller en hybrid.
6. Ikke at opstille klare mål
Fra begyndelsen bør projekter have klare, målbare projektmål (også kendt som SMART-mål). Hvordan kan vi vide, om vi arbejder på et vellykket projekt, hvis vi ikke har noget at måle projektets fremskridt op imod?
Som en del af planlægningsprocessen fastlægger du projektmilepæle, målsætninger og succeskriterier. Tænk over din projektplan, dine projektkrav og dit projektbudget. Vælg de KPI'er, der giver bedst mening for dit projekt eller initiativ.
Dette er en af de mest almindelige årsager til fiasko. Uden dette ved projektteamets medlemmer (og du!) ikke, om I er på rette spor, når det gælder tidsplan, omfang og budget. I vil ophobe overskredne deadlines og budgetoverskridelser, før I overhovedet opdager, at noget er galt.
Erfaring:
Fastlæg altid KPI'er og målepunkter for dine projekter, også for de mindre projekter, hvor det måske kan føles unødvendigt eller som et ekstra trin for at fastslå noget, du allerede ved. Du opdager måske en uoverensstemmelse mellem dine projektmål og KPI'er, som kan spare dig for hovedpine senere hen.
3 trin til at undgå projektfiasko
En tilgang til at undgå projektfiasko er at gennemføre projektevalueringer på flere tidspunkter undervejs i projektet. Her er tre trin, du bør huske:
- Identificer risici: Normalt gør du dette som en del af processen med at udarbejde projektoversigten. Registrer risici i et risikoregister eller en RAID-log.
- Vurder risici: Vurder sandsynligheden for og konsekvenserne af hver risiko. Risici, der med stor sandsynlighed vil opstå og vil have den mest negative indvirkning, bør have mest opmærksomhed.
- Udarbejd risikostyringsplaner og beredskabsplaner: Hvad vil du gøre, hvis en bestemt risiko bliver til virkelighed? Hvordan kan du reducere sandsynligheden for, at risikoen opstår?
Læs mere om hvordan du undgår projektfiasko her.
Hvad synes du?
Dette er nogle af de mest almindelige årsager til projektfiasko, men de er ikke de eneste. Du kan også støde på mangel på ressourcer, mangel på samarbejde og en række andre problemer. Det vigtigste er at være årvågen, holde dine kommunikationskanaler åbne og sikre, at du har håndteret de risici, der kan true dit projekt.
Tag dine evner inden for projektledelse til det næste niveau med et af disse dybdegående kurser i risikostyring.
