6 vanlige grunner til at prosjekter mislykkes: Eksempler og lærdommer
Hvorfor er det slik at så mange prosjekter mislykkes? En ofte sitert statistikk er at 70 % av prosjekter mislykkes. Selv om det ikke ser ut til å finnes noen opprinnelig kilde til denne statistikken, er det verdt å spørre hvorfor prosjekter mislykkes. Hvis vi kan lære av tidligere prosjektfeil, kan vi unngå å gjøre de samme feilene to ganger.
Da jeg først ble prosjektleder, virket det som om jeg lærte alt om feil i prosjektledelse på den harde måten: feilvurdering av estimater, å glemme å stille viktige spørsmål og å være nølende med å si nei.
Selv om jeg har jobbet som prosjektleder i mange år nå, har jeg fortsatt opplevd at prosjekter har mislyktes spektakulært av alle mulige grunner. I denne artikkelen skal jeg gå gjennom hva som fører til prosjektfeil, hvorfor prosjekter til slutt faktisk mislykkes, og tips for å unngå feil.
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
Når regnes prosjekter som mislykkede?
Prosjekter regnes som mislykkede når de overskrider budsjettet, leveres for sent eller ikke leveres i henhold til det planlagte omfanget. Det finnes imidlertid ofte et visst spillerom. Prosjekter blir ofte forsinket av årsaker som ligger utenfor prosjektlederens kontroll (f.eks. at kunden ikke sendte innholdet til nettstedet sitt i tide).
Omfanget kan også endres underveis i et prosjekt på grunn av endringer i kundens eller interessentenes behov. Selv om ukontrollert utvidelse av prosjektomfanget kan være en årsak til at et prosjekt mislykkes, trenger det ikke å ende i et mislykket prosjekt hvis dette håndteres riktig (med endringsforespørsler og godkjenning fra viktige interessenter).
6 vanlige grunner til at prosjekter mislykkes – og eksempler
Så hvorfor mislykkes prosjekter? Her er fem av mine største feil innen prosjektledelse, som illustrerer vanlige årsaker til prosjektfeil, og de viktige lærdommene jeg tok med meg for å forbedre fremtidige prosjekters suksess.
1. Å ikke kommunisere når ting blir vanskelig
Det er et grunnleggende menneskelig instinkt å ikke ville rette oppmerksomheten mot seg selv hvis noe har gått galt og ingen har lagt merke til det. Det strider mot selve naturen til prosjektledelse, men dårlig kommunikasjon er så ofte grunnen til at prosjekter mislykkes.
Jeg må innrømme at kombinasjonen av en svært vanskelig kunde og et budsjett eller en tidsplan som var i ferd med å sprekke, har fått meg til å vente litt for lenge med å informere en kunde om statusen for prosjektet deres.
Dette gjelder spesielt når det har vært rolig og alt har gått som det skal de siste dagene eller ukene i et prosjekt. Det er også den mest sårbare tiden i prosjektets tidsramme – det er så viktig å bevare og styrke tilliten kunden har til prosjektlederen sin.
Lærdom:
Hver gang jeg er i ferd med å nøle før jeg gir en kunde dårlige nyheter, spør jeg meg selv: Er det bedre å justere forventningene deres nå, eller vil jeg håndtere dette etter at det er for sent? Svaret er å gjøre det ALLTID nå og være proaktiv.
Du legger også grunnlaget for å håndtere fremtidige urealistiske forventninger mens du arbeider med en bestemt kunde.
2. Å ikke holde seg til det avtalte omfanget
I et spesielt detaljert prosjekt foreslo et teammedlem som jobbet tett med meg, at vi skulle prøve et nytt programtillegg for bildefremvisning i en porteføljeseksjon vi arbeidet med på nettstedet til en kunde.
Det brukte et rammeverk vi vanligvis ikke arbeidet med, men bildefremvisningen så mer elegant ut og fungerte bedre enn den vi vanligvis brukte. Jeg var først nølende på grunn av den stramme tidsplanen og prosjektets svært detaljerte designstyring, men jeg lot meg overbevise av løftet om bedre funksjonalitet for kunden OG utviklingsteamet vårt.
Det var ikke noe vi tidligere hadde diskutert å legge til i det vanlige verktøysettet vårt, men tidspunktet virket riktig, og det var en god mulighet til å se det nye programtillegget i praksis.
Det endte opp med å bli en av prosjektets mest kostbare beslutninger, både i arbeidstimer og budsjett. Bildefremvisningen støttet ikke en viktig funksjon, og den støttet ikke responsiv størrelsestilpasning eller bestemte nettlesere på en enkel måte.
Dette gikk ikke gjennom den vanlige vurderings- og beslutningsprosessen med tekniske ledere og andre utviklere som en planlagt oppdatering. Det var en utrolig enkel feil som endte med å koste oss begge mye stress, pinlighet og bortkastede ressurser.
Å utvide prosjektomfanget unødvendig ved å legge til nye leveranser eller gjøre prosjektoppgaver mer kompliserte enn nødvendig er en annen typisk grunn til at prosjekter mislykkes.
Lærdom:
Hold deg til prosessene dine, og ikke oppdater ting på impuls. Hvis teammedlemmene dine virkelig trenger eller vil ha nytte av en endring i prosesser eller verktøy (inkludert prosjektstyringsprogramvare eller andre prosjektstyringsverktøy og teknologier) midt i prosjektet, må du gjennomføre hele vurderingsprosessen for å kvalitetssikre den.
3. Å bli for vennlig med teamet og kundene
Det er et tydelig skille mellom profesjonelle relasjoner og uformelle vennskap, og jeg har lært å holde disse adskilt gjennom bevisst praksis.
Det betyr ikke at du ikke kan være venn med lagkameratene eller kundene dine – bare vær oppmerksom på når du slår profesjonaliteten av eller på i samhandlingene dine.
For flere år siden jobbet jeg i et selskap fullt av mennesker som nettopp var ferdige med college, og som alle hadde lignende interesser og bodde nær hverandre i byen vår. Naturligvis hang vi sammen etter jobb og i helgene, og utviklet sterke vennskap.
En dag måtte jeg be om en rask levering av et prosjekt som ingen egentlig likte – det var verken pent, morsomt eller noe de fleste la merke til eller satte pris på.
Designeren på prosjektet overskred fristen med god margin og jobbet i stedet med et større og mer moderne nettsteddesign som ikke skulle leveres før om flere uker. Jeg konfronterte ham med dette, og han spurte meg hvorfor jeg var så hard mot ham når vi var venner.
En sammenblanding av grensene mellom det personlige og det profesjonelle er noen ganger grunnen til at prosjekter mislykkes, fordi det kan påvirke ansvarsforholdene.
Lærdom:
Vær vennlig, men hold deg profesjonell for å kunne fortsette å holde folk ansvarlige for handlingene sine i et prosjekt. Det er mye lettere å føle at vi får et «frikort» hos vennene våre, og det kan bli en farlig (og pinlig) situasjon når dette blandes med profesjonelle forpliktelser.
4. Å få panikk før du rekker å bearbeide situasjonen
Det er kanskje bare meg, men jeg synes det er lett å reagere på bestemte faresignaler eller nøkkelord i prosjekter.
Ting som e-poster med bare store bokstaver, ordene «ny frist» eller «nettstedet er nede», eller mer harmløse varselsignaler som manglende kommunikasjon på et kritisk tidspunkt i et prosjekt, at en ny interessent blir involvert i et prosjekt like før lansering, eller merkelige feil på et nettsted like før kundedemonstrasjoner.
Det er ingenting som gjør meg mer oppjaget enn å umiddelbart henvende meg til en leder, utvikler eller kunde for å be om en avklaring på noe som ville vært åpenbart (eller mulig å løse selv) hvis jeg hadde tatt meg tid til å trekke pusten, bearbeide situasjonen og tenke gjennom neste steg.
Det har vært så mange tilfeller der jeg trodde det var en alvorlig feil på et nettsted (mens det bare var et problem med min egen eller kundens hurtigbuffer), feiltolket en forespørsel om en funksjon som virket mye større enn det som faktisk var nødvendig, eller en kunde trodde at nettstedet eller serveren var nede, mens de egentlig ikke var koblet til internett (ja, det skjer ofte).
Selv om dette punktet ikke alene utgjør én stor prosjektfiasko, bidrar det til dårlig kommunikasjon og kan utløse panikk når panikk ikke er nødvendig.
Lærdom:
Vær aldri redd for å se bort fra en reaktiv e-post eller melding, ta en pause og ta deg et øyeblikk til å undersøke saken før du ber om mer hjelp.
5. Å ikke følge prosessene
Ja, nettopp: feilslutningen om at «dette punktet kan hoppe over den vanlige utviklings-, design-, gjennomgangs- og QA-prosessen fordi det bare er en liten endring». Dette er så ofte grunnen til at prosjekter mislykkes.
Jeg har sett dette skje i prosjekter så mange ganger. Jeg har gjort denne feilen med tilsynelatende «enkle» vedlikeholdsoppdateringer, små funksjonsforespørsler i større prosjekter og endringer i prosjektomfanget generelt.
Noe som å oppdatere et alternativ i et skjemafelt kan virke enkelt på overflaten, men kan utvikle seg til uoversiktlig kode og en oppdatering av hele systemet når en utvikler begynner å undersøke det.
På samme måte kan en kunde som ber om en liten visuell endring i et prosjekt, velte designprosessen og tvinge deg til å tenke gjennom deler av hele flyten på nettstedet på nytt.
Lærdom:
Stol alltid på prosessen og gå gjennom prosessene for kartlegging, estimering og QA i henhold til dette: Jeg har lært at ingen endring er liten nok til å IKKE forstyrre noe annet underveis.
Beskytt prosessen din, og bli en forkjemper for å gjøre ting på riktig måte – selv om det betyr litt ekstra innsats. Dette innebærer også å velge riktig metodikk eller arbeidsflyt for prosjektledelse, enten det er smidig, fossefallsmetodikk, Kanban eller en hybrid.
6. Å ikke sette tydelige mål
Fra starten av bør prosjekter ha tydelige, målbare prosjektmål (også kjent som SMART-mål). Hvordan kan vi vite om vi jobber med et vellykket prosjekt hvis vi ikke har noe å måle prosjektfremdriften mot?
Som en del av planleggingsprosessen fastsetter du prosjektmilepæler, mål og måleindikatorer for suksess. Tenk på prosjektplanen, prosjektkravene og prosjektbudsjettet. Velg de KPI-ene som gir mest mening for prosjektet eller initiativet ditt.
Dette er en av de vanligste årsakene til at prosjekter mislykkes. Uten dette vil prosjektteammedlemmene (og du!) ikke vite om dere ligger an når det gjelder tidsplan, omfang og budsjett. Dere vil samle opp overskredne tidsfrister og budsjettoverskridelser før dere i det hele tatt legger merke til at noe er galt.
Lærdom:
Fastsett alltid KPI-er og måleparametere for prosjektene dine, også for mindre prosjekter der dette kan føles unødvendig eller som et ekstra steg for å fastslå noe du allerede vet. Du kan oppdage et misforhold mellom prosjektmålene og KPI-ene som sparer deg for hodebry senere.
3 trinn for å unngå prosjektmislykkelse
Én måte å unngå at et prosjekt mislykkes på, er å gjennomføre prosjektevalueringer på flere tidspunkter gjennom prosjektet. Her er tre trinn du bør ha i mente:
- Identifiser risikoer: Vanligvis gjør du dette som en del av prosessen med å utarbeide prosjektoversikten. Registrer risikoer i et risikoregister eller en RAID-logg.
- Vurder risikoer: Vurder sannsynligheten for og konsekvensene av hver risiko. Risikoer som det er svært sannsynlig vil inntreffe, og som vil ha størst negativ innvirkning, bør vies mest oppmerksomhet.
- Utarbeid risikostyringsplaner og beredskapsplaner: Hva vil du gjøre hvis en bestemt risiko blir en realitet? Hvordan kan du redusere sannsynligheten for at risikoen oppstår?
Les mer om hvordan du kan unngå at prosjekter mislykkes her.
Hva synes du?
Dette er noen av de vanligste årsakene til at prosjekter mislykkes, men de er ikke de eneste. Du kan også møte på mangel på ressurser, mangel på samarbeid og en rekke andre utfordringer. Det viktigste er å være årvåken, holde kommunikasjonskanalene åpne og sørge for at du har tatt høyde for risikoer som kan true prosjektet.
Ta prosjektstyringsevnen din til neste nivå med ett av disse grundige kursene i risikostyring.
