Sådan undgår du projektfejl i 3 trin + 4 casestudier

Hvad er projektfejl?

Præcis hvad det lyder som – når et projekt ikke leverer på de projektmål, teamet fastsatte i begyndelsen, ikke lever op til kundens eller centrale interessenters forventninger eller ikke holder tidsplanen, budgettet eller omfanget.

Hvorfor mislykkes projekter?

Som jeg antydede i indledningen, er der en række almindelige grunde til, at projekter kan mislykkes. Det skyldes som regel en risiko, der ikke blev vurderet korrekt, og/eller at teamet (herunder projektlederen) ikke reagerede hensigtsmæssigt på risikoen.

Andre almindelige årsager til projektfejl kan være dårlig kommunikation om status, problemer eller risici; at teammedlemmer ikke overholder (eller ikke forstår) projektets omfang, projektleverancer (dvs. udvidelse af projektets omfang) eller tidsramme; mangel på ressourcer eller manglende overholdelse af fastlagte processer eller metoder.

Sådan undgår du projektfejl: 3 trin

Risikostyring er en vigtig projektledelsesaktivitet. Den er så vigtig, at manglende risikostyring ofte svarer til projektledelsesfejl. Risikostyring består af tre vigtige elementer:

1. Identificér risici.
2. Vurdér det, du har identificeret: Hvor sandsynligt er det, at det sker, og hvor galt går det, hvis det sker? Hvad er sandsynligheden og konsekvensen?
3. Udarbejd afværge- og beredskabsplaner for de risici, der kan vælte dit ellers vellykkede projekt. Et risikoregister er nyttigt til at holde styr på, hvad du har gjort.

1. Identificér risici

Identificér først risiciene. Hvis du gør det grundigt, øger du dine chancer for projektsucces markant. Selvom det er svært at opdage dem alle, kan du som regel finde de største risici, hvis du gennemgår projektet systematisk. Det er normalt en del af processen med at udarbejde en projektplan.

Min baggrund er inden for softwareudvikling, både produktudvikling og IT, samt de tilhørende processer. Softwareprojekter er komplekse og skrøbelige, og med få sjældne undtagelser har de ikke den form for fejlsikring og kontrol indbygget, som man ser i eksempelvis byggebranchen eller produktionen af medicinsk udstyr.

Du bør have projektmål for hver af de fire styringsparametre:

1. Tidsplan
2. Indhold
3. Omkostninger
4. Kvalitet

Hvis du ikke ved, hvad de er, er det dér, du skal begynde. Jeg oplever typisk, at to af de fire ændrer sig en smule undervejs, men jo bedre du forstår, hvor du er på vej hen, desto lettere bliver det at identificere hindringer.

Hvis du forstår, hvilken af de fire styringsparametre der har højeste prioritet, kan du reducere risikoen ved at foretage passende afvejninger i det små.

Det er let at blive opslugt af projektets tidsplan og overse risici, der kan påvirke de andre styringsparametre, men de hænger alle sammen, og det er vigtigt at identificere dem alle.

At overholde tidsplanen med et produkt, der er fyldt med fejl, er normalt ikke en god løsning – selv hvis du sender det ud, ender du med at skulle udsende rettelsesversioner, som skubber tidsplanen for et acceptabelt produkt længere, end det ville have gjort at håndtere problemet fra begyndelsen.

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Get Free Access

Have an account? Log In

Ud over de 4 styringsparametre

Ud over de fire styringsparametre skal du afbalancere tre aspekter af dit projekt:

1. Produktet, som normalt dækkes af styringsparametrene
2. Processen
3. Menneskerne

Procesrisici findes i to varianter: en eksisterende utilstrækkelig proces, der ikke opfylder projektets behov, og mangel på en proces for noget, der er afgørende for det, teamet arbejder med. Procesrisici er forholdsvis lette at afhjælpe ved at oprette eller forbedre processen.

Den menneskelige faktor bliver ofte ignoreret, men dit team og de teams, de samarbejder med, kan få dit projekt til at lykkes eller mislykkes. Vanskelige eller uinteresserede projektinteressenter vil gøre det svært at få det, du har brug for, for at komme videre.

Overarbejdede, stressede eller utilfredse teammedlemmer får ikke arbejdet gjort. Nogle af de potentielle problemer med medarbejdere kan du identificere offentligt, mens andre måske bør håndteres privat, men begå ikke den fejl at ignorere dem.

2. Vurder de identificerede risici

Efter at have identificeret risiciene skal du afgøre, hvor sandsynligt det er, at risikoen opstår. Jeg bruger normalt en procentdel – 100 % betyder, at jeg er sikker på, at det vil ske. Det er også vigtigt at afgøre, hvor alvorligt det bliver, hvis risikoen faktisk opstår. Den nemmeste måde at gøre dette på er at kategorisere risici som høj, mellem eller lav risiko.

Når du har foretaget denne analyse, er det tid til at involvere dit team. Spørg hvert projektteammedlem eller hver bidragyder, hvad de er bekymrede for, føj det til listen over risici, og læg dem frem til gennemgang:

• Kan teamet komme i tanke om andre risici, som du ikke har dækket?
• Hvad synes de om analysen af sandsynlighed og påvirkning?

På baggrund af dette møde kan du foretage justeringer i din risikoplan. Første og anden del er færdige – indtil videre. Du skal gennemgå risiciene mindst ugentligt for at se, om der er kommet nye risici til, om nogle ikke længere er relevante, og om sandsynligheden eller påvirkningen har ændret sig.

3. Udarbejd afbødnings- og beredskabsplaner

Hvis kombinationen af sandsynligheden for og påvirkningen af nogle risici kan få projektet til at køre af sporet, skal du endelig samarbejde med dit team om at udarbejde dokumenterede planer for afbødning og beredskab.

Afbødning handler om at gøre det enten mindre sandsynligt, at risikoen indtræffer, eller om at begrænse påvirkningen, hvis den gør. Beredskab fokuserer på de skridt, du vil tage, hvis risikoen er uundgåelig og indtræffer.

Sørg for, at planerne er dokumenteret, og at alle kender dem. Det er også en god idé at planlægge for potentielle problemer med medarbejdere ud over de 4 drejeknapper og processen, men du bør nok selv foretage analysen og holde den fortrolig.

Sådan overlever du et projekt, der mislykkes

Den anden årsag til fejl i projektledelsen er en dårlig reaktion på en projektrisiko, der indtræffer, uanset om den var forudset eller ej.  Det afhænger i høj grad af dig som projektleder. Før du går i gang med nogle af nedenstående trin, skal du begynde med disse 2 tips:

• Gå ikke i panik. Husk at trække vejret.
• Placér ikke skylden, og lad ikke andre begynde at give nogen skylden.

1. Henvis til din beredskabsplan

Hvis du har en beredskabsplan på plads, skal du straks indkalde til et møde eller som minimum sende en e-mail, der sætter beredskabsplanen i gang. Mind folk om, hvad planen går ud på, og fortæl alle, hvornår og hvordan de skal rapportere status.

Hvis du springer dette over eller forsinker det, vil du opdage, at folk, der gerne vil hjælpe, er gået i gang i paniktilstand. Når det sker, mister du overblikket over, hvad der er blevet gjort, og det gør ofte problemet værre.

Hvis du ikke har en beredskabsplan, skal du straks samle tropperne med en mødeindkaldelse og strenge instruktioner om IKKE AT GØRE NOGET ANDET før efter mødet.

Ellers vil alle forsøge at hjælpe, og du vil ikke have nogen idé om, hvad der er blevet gjort. På mødet skal du beskrive problemet klart – det er altid forbløffende, hvor mange forskellige idéer folk har om, hvad problemet er.

Foretag en samlet analyse af den grundlæggende årsag for at komme til bunds i problemet, og udarbejd planen for, hvem der skal gøre hvad og hvordan, for at genoprette situationen. Når du arbejder med en analyse af den grundlæggende årsag, skal du forstå, hvem der gjorde hvad op til problemet, men hold diskussionen på det niveau.

Med andre ord: hold dig til fakta. Placér ikke skylden, da det at pege fingre distraherer. Hvis dit team ikke er i stand til at finde frem til løsningen, har du nogle muligheder.

Den første er at hente en person ind, som kender det overordnede fagområde, men ikke er med på netop dette projekt – hvis problemet for eksempel ser ud til at være relateret til databasen, kan du hente en databaseadministrator ind, som ikke arbejder på projektet, for at få en anden vurdering.

En anden teknik er at hente en person ind, som slet ikke har praktisk kendskab til projektet. Nogle gange afslører det at skulle forklare hvert trin i detaljer dårlige antagelser eller noget, som folk har overset.

2. Løs problemet

Få alle med på din fremgangsmåde, og fordel opgaverne. Bed folk om at rapportere fremskridt til dig, og fortæl dem, hvor ofte de skal sende statusrapporter – hver time, når de har afsluttet en opgave, ved dagens slutning eller på det tidspunkt, der giver mening i situationen.

Rapporteringen virker måske indlysende for dig, men det vil den ikke være for alle. Regelmæssige opdateringer hjælper med at holde teamet på sporet. Rapportér regelmæssigt de samlede fremskridt til hele teamet.

De teammedlemmer, der ikke har nogen umiddelbare opgaver, vil blive rastløse og til sidst forsøge at blande sig og hjælpe, medmindre du giver dem statusopdateringer og andre oplysninger.

Det er også meget vigtigt at holde ledelsen orienteret. Brug din dømmekraft til at afgøre, hvem der har brug for opdateringer hvornår, men rapportér regelmæssigt de samlede fremskridt til hele teamet.

3. Erklær det afsluttet

Når det faktisk er afsluttet, vel at mærke. Udarbejd en endelig rapport, og gå videre til næste trin. Giv teamet lidt tid til at komme sig.

4. Gennemfør en afsluttende evaluering eller retrospektiv

Det er vigtigt at gennemføre en projektevaluering for at indsamle erfaringer. Sådan strukturerer du den:

• Beskriv problemet, så alle har den samme forståelse
• Begynd med det, der gik godt. Selv i den mest alvorlige situation gik noget stadig rigtigt. Det giver mødet en helt anden stemning fra starten.
• Tal om, hvad der skal forbedres. Hvis der er tid, kan I brainstorme på måder at gennemføre forbedringerne på; ellers skal I tildele opgaver og fastsætte deadlines og følge op på disse datoer.

Hvis det faktisk var nogens skyld, skal du tage det op med den pågældende person – privat. Hvis du gør det offentligt, vil hele dit team spekulere på, hvem der bliver ydmyget offentligt næste gang.

Hvis du helt springer det over, vil dit team føle, at nogen slap af sted med noget, og at problemet ikke blev løst. Vær saglig, og følg op på eventuelle ændringer i de personlige arbejdsprocesser, som nogen har brug for at foretage. Det handler om ansvarlighed og forbedring, ikke om at finde nogen at bebrejde.

3 eksempler fra virkeligheden på mislykkede projekter

Jeg har oplevet min del af mislykkede IT-projekter, selvom de heldigvis – men smertefuldt – blev genoprettet.

Her er et par af mine egne mislykkede IT- og udviklingsprojekter samt et eksempel på et berømt mislykket projekt.

Disse eksempler på projektfejl og casestudier af mislykkede projekter bør også give dig en konkret idé om, hvordan projekter kan mislykkes, og hvordan det kan håndteres.

1. Regnskabssystemet

Tidligt i min karriere arbejdede jeg hos IBM. Mit første rigtige job var at overtage et forholdsvis lille system, der leverede data til virksomhedens regnskabssystemer. En person hos IBM havde skrevet det i et obskurt programmeringssprog kaldet RPG på et lille system.

Jeg administrerede ikke kun projektet – jeg administrerede hele systemet (selvom der var en administrator), herunder indsamling af projektkrav, fejlfinding og programmering.

En dag lagde jeg et nyt program ind, kørte det og fandt en fejl. Jeg rettede fejlen og kørte programmet igen. Næste morgen ringede regnskabsafdelingen og fortalte, at der var dobbeltposteringer (det er meget dårlige nyheder i regnskabsverdenen).

For det første var der ingen, der gennemgik mit arbejde. For det andet involverede jeg ikke folk fra de efterfølgende systemer for at kontrollere posteringerne, før de blev ført videre. Og for det tredje afsatte jeg ikke tid til at analysere nogle af de gamle programmer, som stadig kørte og oprettede dobbeltposteringer. Der var heller ingen proces ud over det, jeg fandt på undervejs.

Og så var min reaktion – panik. Gud, lige efter universitetet, og jeg ødelægger IBMs regnskabssystem. Jeg involverede ikke de rigtige personer – administratoren vidste ikke, hvad der foregik – og han genererede endnu et sæt posteringer uden at vide det. Til sidst arbejdede jeg 48 timer i træk for at finde den grundlæggende årsag, rette den og skrive og køre programmer for at rette regnskabsfejlene.

Og jeg lærte min lektie – undersøg tingene grundigt, få arbejdet gennemgået, tænk over, hvad der kan gå galt, og stop op og tænk, før du kaster dig ud i at forsøge at løse tingene (alt sammen noget, som software til projektstyring af regnskab kan hjælpe med). Forestil dig nu, at jeg ledede et team på 10 personer, og at alle gjorde det samme i forsøget på at løse problemet. Det ville virkelig have været umuligt at genoprette uden at lukke IBMs regnskabssystemer ned for at finde en løsning.

More Articles

• 24 bøger om projektledelse, du skal læse i 2026

2. Det nye interne produkt

Som konsulent ledede jeg et nyt, stort projekt med mange interessenter, der blandede sig i kravene og førte til konstante ændringer i de funktionelle prioriteter. Vi anvendte en agil projektstyringsproces, som denne virksomhed ikke havde brugt før. Kvalitetssikringen var meget dygtig til at teste, men forstod endnu ikke slutbrugerens tankegang og arbejdsgang.

Jeg kendte til alle disse ting og formulerede dem også fra tid til anden, men jeg havde ikke noget risikoregister, ingen vurdering af konsekvens/sandsynlighed, ingen beredskabsplan eller afværgeplan. Jeg var heller ikke den primære informationskanal til projektsponsoren, selvom jeg lejlighedsvis holdt møder med hende.

Vi tilføjede et sprint. Så endnu et. Derefter, da det blev klart, at vi ikke helt var nået til det punkt, hvor vi kunne gennemføre en betatest, tilføjede vi et tredje sprint.

Fordi det ikke var mig, der leverede oplysningerne til projektsponsoren, anede jeg ikke, at hun ikke kendte til alt dette. Den ansvarlige begik den kritiske fejl ikke at fortælle sponsoren det i håbet om, at vi kunne få det til at lykkes.

Og for at være rimelig: Selvom jeg talte om risici, gav jeg ham ikke et konkret sæt risici, som han kunne præsentere for at forberede sponsoren på muligheden for en forsinkelse i tidsplanen.

Midt i alt dette havde jeg et møde med sponsoren og nævnte i forbifarten det sidste sprint, som vi ville tilføje. Hun stoppede mig. Hun vidste intet om det og var ikke tilfreds.

Det viste sig, at hun var mere oprørt over overraskelsen end over forsinkelsen i tidsplanen. Det fik konsekvenser offentligt, og til sidst flyttede den projektansvarlige til en anden del af virksomheden, fordi tilliden var væk.

Endnu en gang lærte jeg vigtige lektioner af fiaskoen. Det er ikke nok at kende risiciene; du er nødt til at samle dem, vurdere dem, have afhjælpnings- og beredskabsplaner og gøre dem offentligt tilgængelige og konstant synlige.

Jeg har aldrig været tilhænger af at skjule risici og problemer, men betydningen af gennemsigtighed i projekter blev gjort helt utvetydig.

3. Kan du huske OS2?

Næh, det er der ingen, der kan. Det er et af mange mislykkede systemudviklingsprojekter. Jeg arbejdede hos IBM, da den oprindelige OS2 udkom – en konkurrent til Windows. Jeg prøvede ikke engang den første version, fordi vi hos IBM alle vidste, at den virkelig var fyldt med fejl. Resten af verden fandt hurtigt ud af, at den havde for mange fejl til, at det var besværet værd.

Den var så fejlbehæftet, at projektteamet umuligt kunne have ment, at den var helt færdig, men på en eller anden måde traf de ikke det rigtige kompromis og udskød ikke udgivelsen. Hvis man ikke tager det menneskelige aspekt i betragtning, vil både ens team og ens kunder hurtigt ødelægge selv den smukkeste plan.

Inden for software er der flere alternativer til denne situation – man kan lave en begrænset udgivelse til personer, der vil acceptere fejlene for at få ny banebrydende software, offentligt meddele, at man venter med at udgive, indtil pålideligheden lever op til ens høje standarder osv.

Det var stadig så tidligt i min karriere, at jeg kunne drage værdifulde lektioner af det faktum, at et produkt, jeg elskede, var endt i en blindgyde ved den anden udgivelse.

Vær tydelig om dine prioriteter – der er nogle få tilfælde, hvor det er vigtigere at udgive på en bestemt dato end at sikre produktkvaliteten, men ikke mange.

Brug dine 4 drejeknapper, og indrøm dine fejl og gør rettelserne synlige, så folk stoler på, at du forstår problemet og ikke begår den samme fejl to gange.

Tag det menneskelige aspekt i betragtning – det er lige så afgørende som teknologien. Jeg tog disse lektioner med mig ind i software- og it-projekter fra det tidspunkt og frem, og de har været uvurderlige.

Konklusionen

Overordnet set skal du huske, at selvom ansvaret i sidste ende er dit, behøver du ikke at udføre alt arbejdet. Faktisk bør du bestemt ikke forsøge at gøre det alene. Du kan drage fordel af dit teams brede vifte af erfaringer og viden. Du er lederen, men du behøver ikke at udgøre hele teamet.

Projektstyringssoftware og andre projektstyringsværktøjer kan hjælpe dig med at spore risici, milepæle, ressourceallokering og andre kritiske indikatorer for, om du er på vej mod et vellykket projekt.