Slik unngår du prosjektfiasko i 3 trinn + 4 eksempler

Hva er prosjektfiasko?

Akkurat det det høres ut som – når et prosjekt ikke leverer på prosjektmålene teamet satte i begynnelsen, ikke innfrir forventningene til kunden eller andre sentrale interessenter, eller ikke holder tidsplanen, budsjettet eller omfanget.

Hvorfor mislykkes prosjekter?

Som jeg antydet i innledningen, finnes det en rekke vanlige grunner til at prosjekter kan mislykkes. Vanligvis skyldes dette en risiko som ikke ble vurdert ordentlig, og/eller at teamet (inkludert prosjektlederen) ikke håndterte risikoen på riktig måte.

Andre vanlige årsaker til prosjektfiasko kan være dårlig kommunikasjon om status, problemer eller risikoer; at teammedlemmer ikke følger (eller forstår) prosjektomfanget, prosjektleveransene (det vil si omfangsutvidelse) eller tidsrammen; mangel på ressurser eller at man ikke følger fastsatte prosesser eller metoder.

Slik unngår du prosjektfiasko: 3 trinn

Risikostyring er en viktig prosjektledelsesaktivitet. Den er så viktig at manglende risikostyring ofte tilsvarer svikt i prosjektledelsen. Risikostyring har tre viktige komponenter:

1. Identifiser risikoer.
2. Vurder det du har identifisert: Hvor sannsynlig er det at det skjer, og hvor ille blir det hvis det skjer? Hva er sannsynligheten og konsekvensen?
3. Utarbeid tiltak og beredskapsplaner for risikoer som kan velte prosjektet ditt, som ellers ville vært vellykket. Risikoregistre er nyttige for å holde oversikt over det du har gjort.

1. Identifiser risikoer

Identifiser først risikoene. Hvis du gjør dette grundig, øker du sjansene for at prosjektet lykkes betydelig. Selv om det er vanskelig å fange opp alle, kan du vanligvis finne de største risikoene hvis du ser systematisk på prosjektet. Dette er vanligvis en del av prosessen med å lage en prosjektplan.

Jeg har bakgrunn fra programvareutvikling, både produktutvikling og IT, samt de tilhørende prosessene. Programvareprosjekter er komplekse og sårbare, og med noen få sjeldne unntak har de ikke den typen feilsikring og inspeksjoner som er innebygd i for eksempel bygging eller produksjon av medisinsk utstyr.

Du bør ha prosjektmål for hver av de fire målerne:

1. Tidsplan
2. Innhold
3. Kostnad
4. Kvalitet

Hvis du ikke vet hva disse er, er det der du bør begynne. Jeg opplever vanligvis at to av de fire vil endre seg noe, men jo mer du forstår om hvor du skal, desto enklere blir det å identifisere hindringer.

Ved å forstå hvilken av de fire målerne som har høyest prioritet, kan du redusere risikoen ved å gjøre hensiktsmessige avveininger i det små.

Det er lett å bli oppslukt av måleren for prosjektets tidsplan og overse risikoer som kan påvirke de andre målerne, men de henger alle sammen, og det er viktig å identifisere dem alle.

Å nå målene for tidsplanen med et produkt som er fullt av feil, er vanligvis ikke et godt alternativ – selv om du sender det ut, vil du ende opp med feilrettingsversjoner som forskyver tidsplanen for et tilstrekkelig produkt lenger enn det ville ha gjort å håndtere problemet med én gang.

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

Utover de fire målerne

I tillegg til de fire målerne har du tre aspekter ved prosjektet som må balanseres:

1. Produkt, som vanligvis dekkes av målerne
2. Prosess
3. Mennesker

Prosessrisikoer finnes i to varianter: en eksisterende prosess som ikke er tilstrekkelig og ikke dekker prosjektets behov, og mangel på en prosess for noe som er kritisk for det teamet ditt gjør. Prosessrisikoer er ganske enkle å redusere ved å opprette eller utbedre prosessen.

Den menneskelige delen blir ofte ignorert, men teamet ditt og teamene de samarbeider med, vil være avgjørende for om prosjektet lykkes eller mislykkes. Vanskelige eller uinteresserte prosjektinteressenter vil gjøre det vanskelig å få det du trenger for å komme videre.

Overarbeidede, stressede eller misfornøyde teammedlemmer vil ikke få jobben gjort. Noen av de potensielle personalutfordringene kan du identifisere offentlig, mens andre kanskje bør tas opp privat, men ikke gjør den feilen å ignorere dem.

2. Vurder risikoene du har identifisert

Etter at du har identifisert risikoene, må du fastslå hvor sannsynlig det er at risikoen oppstår. Jeg bruker vanligvis en prosentandel – 100 % betyr at jeg er sikker på at det kommer til å skje. Det er også viktig å fastslå hvor alvorlig det vil være hvis risikoen faktisk oppstår. Den enkleste måten å gjøre dette på er å kategorisere risikoene som høy, middels eller lav risiko.

Når du har gjort denne analysen, er det på tide å involvere teamet. Spør hvert prosjektteammedlem eller hver bidragsyter hva de er bekymret for, legg dette til på listen over risikoer, og legg listen frem for gjennomgang:

• Kommer teamet på andre risikoer du ikke har tatt med?
• Hva synes de om analysen av sannsynlighet og konsekvens?

Basert på dette møtet kan du gjøre justeringer i risikoplanen. Del én og to er ferdige – foreløpig. Du må gjennomgå risikoene minst ukentlig for å se om det finnes nye risikoer, om det er noen som ikke lenger er relevante, og om sannsynligheten eller konsekvensen har endret seg.

3. Utarbeid planer for risikoreduksjon og beredskap

Til slutt: Hvis kombinasjonen av sannsynlighet og konsekvens for noen av risikoene kan føre til at prosjektet sporer av, bør du samarbeide med teamet om å utarbeide dokumenterte planer for risikoreduksjon og beredskap.

Risikoreduksjon innebærer å gjøre risikoen mindre sannsynlig eller redusere konsekvensen hvis den oppstår. Beredskap fokuserer på trinnene du skal ta hvis risikoen er uunngåelig og oppstår.

Sørg for at planene er dokumentert, og at alle kjenner til dem. Det er også en god idé å planlegge for potensielle personalutfordringer i tillegg til de fire styringshjulene og prosessen, men du bør sannsynligvis gjøre analysen selv og holde den konfidensiell.

Slik overlever du et prosjekt som mislykkes

Den andre årsaken til at prosjektstyring mislykkes, er en dårlig reaksjon på at en prosjektrisiko oppstår, enten den var forutsett eller ikke.  Dette er i stor grad opp til deg som prosjektleder. Før du gjør noen av trinnene nedenfor, bør du begynne med disse to tipsene:

• Ikke få panikk. Husk å puste.
• Ikke pek ut syndebukker, og ikke la andre begynne å legge skylden på noen.

1. Se på beredskapsplanen

Hvis du har en beredskapsplan på plass, bør du innkalle til et møte umiddelbart, eller i det minste sende en e-post som utløser beredskapsplanen. Minn folk på hva planen går ut på, og fortell alle når og hvordan de skal rapportere status.

Hvis du hopper over dette eller utsetter det, vil du oppdage at personer som gjerne vil hjelpe, har kastet seg inn i situasjonen i panikkmodus. Når dette skjer, mister du oversikten over hva som er gjort, og det gjør ofte problemet verre.

Hvis du ikke har en beredskapsplan, må du umiddelbart samle troppene ved å sende ut en møteinnkalling med strenge instrukser om å IKKE GJØRE NOE ANNET før etter møtet.

Ellers vil alle prøve å hjelpe, og du vil ikke ha noen anelse om hva som er gjort. På møtet må du beskrive problemet tydelig – det er alltid utrolig hvor mange ulike oppfatninger folk kan ha av hva problemet er.

Gjennomfør en samlet årsaksanalyse for å komme til bunns i problemet, og utarbeid en plan – hvem, hva og hvordan – for å rette det opp. Når du arbeider med en årsaksanalyse, må du forstå hvem som gjorde hva frem mot problemet, men hold diskusjonen på dette nivået.

Med andre ord: Hold deg til fakta. Ikke fordel skyld, siden det å peke ut syndebukker virker distraherende. Hvis teamet ditt ikke klarer å finne løsningen, har du noen alternativer.

Det første er å hente inn noen som kjenner det generelle fagområdet, men som ikke er med på dette spesifikke prosjektet – hvis problemet for eksempel ser ut til å være knyttet til databasen, kan du hente inn en databaseadministrator som ikke arbeider med prosjektet, for å få et annet perspektiv.

En annen teknikk er å hente inn noen som ikke har noen arbeidskunnskap om prosjektet i det hele tatt. Noen ganger vil det å måtte forklare hvert trinn uttrykkelig avdekke dårlige antakelser eller noe folk har oversett.

2. Løs problemet

Få alle med på handlingsplanen din, og fordel oppgaver. Be folk rapportere fremdriften til deg, og fortell dem hvor ofte de skal sende fremdriftsrapporter – hver time, når de har fullført en oppgave, på slutten av dagen eller når det ellers passer ut fra situasjonen.

Rapporteringen kan virke opplagt for deg, men det vil den ikke være for alle. Regelmessige oppdateringer vil hjelpe teamet med å holde seg på sporet. Rapporter samlet fremdrift til hele teamet regelmessig.

De i teamet som ikke har umiddelbare oppgaver, kommer til å bli rastløse og til slutt prøve å kaste seg inn og hjelpe til, med mindre du gir dem statusoppdateringer og annen informasjon.

Det er også svært viktig å holde ledelsen orientert. Bruk skjønnet ditt til å avgjøre hvem som trenger oppdateringer og når, men rapporter samlet fremdrift til hele teamet regelmessig.

3. Avslutt saken

Når det faktisk er ferdig, vel å merke. Utarbeid en sluttrapport, og gå videre til neste trinn. Gi teamet litt tid til å komme seg.

4. Gjennomfør en etteranalyse eller retrospektiv

Det er viktig å gjennomføre en prosjektevaluering for å samle inn lærdommer. Slik kan du strukturere dette:

• Beskriv problemet slik at alle har samme forståelse
• Begynn med det som gikk bra. Selv i den mest kritiske situasjonen gikk noe likevel riktig. Dette gir møtet en helt annen tone fra starten av.
• Snakk om hva som må forbedres. Hvis det er tid, kan dere finne ideer til hvordan forbedringene kan gjennomføres. Hvis ikke, fordeler dere oppgaver, setter frister og følger opp på disse datoene.

Hvis det faktisk var noens skyld, bør du ta det opp med vedkommende – privat. Hvis du gjør dette offentlig, kommer hele teamet til å lure på hvem som blir ydmyket offentlig neste gang.

Hvis du hopper over dette helt, vil teamet ditt føle at noen slapp unna med noe, og at problemet ikke ble løst. Vær saklig, og følg opp eventuelle personlige prosessendringer som noen må gjøre. Det handler om ansvarlighet og forbedring, ikke om å finne noen å skylde på.

3 eksempler på prosjektfeil fra virkeligheten

Jeg har opplevd min del av mislykkede IT-prosjekter, selv om de heldigvis – men smertefullt – ble gjenopprettet.

Her er et par av mine egne mislykkede IT- og utviklingsprosjekter, samt ett eksempel på et berømt mislykket prosjekt.

Disse eksemplene på prosjektfeil og casestudiene av mislykkede prosjekter bør også gi deg en konkret forståelse av hvordan prosjekter kan mislykkes, og hvordan dette kan håndteres.

1. Regnskapssystemet

Tidlig i karrieren min jobbet jeg hos IBM. Den første ordentlige jobben min var å overta et ganske lite system som leverte data til selskapets regnskapssystemer. Noen hos IBM hadde skrevet det i et lite system ved hjelp av et obskurt programmeringsspråk kalt RPG.

Jeg administrerte ikke bare prosjektet – jeg administrerte hele systemet (selv om det fantes en administrator), inkludert innsamling av prosjektkrav, feilsøking og programmering.

En dag la jeg inn et nytt program, kjørte det og fant en feil. Jeg rettet feilen og kjørte programmet på nytt. Neste morgen ringte regnskapsavdelingen og fortalte at det var blitt opprettet doble poster (dette er svært dårlige nyheter i regnskapsverdenen).

For det første var det ingen som gjennomgikk arbeidet mitt. For det andre involverte jeg ikke folk fra de etterfølgende systemene for å kontrollere postene før de ble sendt videre. For det tredje brukte jeg ikke tid på å analysere noen av de gamle programmene som fortsatt kjørte og opprettet doble poster. Det fantes heller ingen prosess, bortsett fra det jeg fant på underveis.

Og så var reaksjonen min – panikk. Herregud, jeg var nettopp ferdig med universitetet og ødela IBMs regnskapssystem. Jeg involverte ikke de rette personene – administratoren visste ikke hva som foregikk – og han genererte enda et sett med poster uten å vite det. Til slutt jobbet jeg 48 timer i strekk for å finne den egentlige årsaken, rette den og skrive og kjøre programmer som korrigerte regnskapsfeilene.

Og jeg lærte leksen min – se nøye etter, få arbeidet gjennomgått, tenk på hva som kan gå galt, og stopp opp og tenk før du kaster deg inn i et forsøk på å løse ting (alt dette kan prosjektstyringsprogramvare for regnskap hjelpe med). Forestill deg nå at jeg ledet et team på ti personer, og at alle gjorde det samme i forsøket på å løse problemet. Det ville virkelig ha vært umulig å gjenopprette uten å ta ned IBMs regnskapssystemer for å finne løsningen.

More Articles

• Eisenhower-matrisen: Slik prioriterer du oppgaver på en smart måte
• Tips for å bygge Slack-profilen din
• Slik mestrer du ressursstyring i prosjektledelse

2. Det nye interne produktet

Som konsulent ledet jeg et nytt, stort prosjekt der mange hadde meninger om kravene, noe som førte til uendelige endringer i funksjonelle prioriteringer. Vi brukte en smidig prosjektstyringsprosess, som dette selskapet ikke hadde brukt før. QA var svært flinke til å teste, men forsto ennå ikke sluttbrukerens perspektiv og arbeidsflyt.

Jeg visste alt dette og satte ord på det fra tid til annen, men jeg hadde ikke noe risikoregister, ingen vurdering av konsekvens/sannsynlighet, ingen beredskapsplan eller risikoreduserende tiltak. Jeg var heller ikke den primære informasjonskanalen til prosjektsponsoren, selv om jeg av og til møtte henne.

Vi la til en sprint. Så en til. Da det deretter ble tydelig at vi ikke helt var kommet dit vi måtte være for å gjennomføre en betatest, la vi til en tredje sprint.

Fordi jeg ikke var den som ga informasjon til prosjektsponsoren, ante jeg ikke at hun ikke visste alt dette. Den ansvarlige gjorde den kritiske feilen å ikke fortelle sponsoren om det, i håp om at vi skulle klare det.

Og for å være rettferdig: Selv om jeg snakket om risiko, ga jeg ham ikke et konkret sett med risikoer som han kunne presentere for å forberede sponsoren på muligheten for en forsinkelse i tidsplanen.

Midt oppi alt dette hadde jeg et møte med sponsoren og nevnte i forbifarten den siste sprinten vi skulle legge til. Hun avbrøt meg. Hun visste ingenting om dette og var ikke fornøyd.

Det viste seg at hun var mer opprørt over overraskelsen enn over forsinkelsen i tidsplanen. Det fikk konsekvenser som ble synlige for alle, og til slutt flyttet den prosjektansvarlige til en annen del av selskapet fordi tilliten var borte.

Igjen lærte jeg viktige lekser av fiaskoen. Det er ikke nok å kjenne til risikoene; du må sette dem sammen, vurdere dem, ha planer for risikoreduserende tiltak og beredskap, og gjøre dem offentlige og hele tiden synlige.

Jeg har aldri vært en som skjuler risikoer og problemer, men betydningen av åpenhet i prosjekter ble gjort umiskjennelig tydelig.

3. Husker du OS2?

Nei, det gjør ingen. Det er ett av mange mislykkede systemutviklingsprosjekter. Jeg jobbet i IBM da den opprinnelige OS2 kom ut – en konkurrent til Windows. Jeg prøvde ikke engang den første versjonen, fordi vi alle i IBM visste at den var full av feil. Resten av verden oppdaget raskt at den hadde for mange feil til at det var bryet verdt.

Den hadde så mange feil at prosjektteamet umulig kunne ha ment at den var ferdig, men på en eller annen måte tok de ikke den riktige avveiningen og utsatte ikke lanseringen. Hvis du ikke tar hensyn til menneskene – både teamet ditt og kundene dine – vil de raskt ødelegge selv en vakker plan.

I programvare finnes det mange alternativer i en slik situasjon – gjennomfør en begrenset lansering for personer som tåler feilene for å få ny og banebrytende programvare, gjør det offentlig at du venter med å lansere til påliteligheten holder dine høye standarder, og så videre.

Dette skjedde tidlig nok i karrieren min til at jeg kunne lære verdifulle lekser av det faktum at et produkt jeg elsket, var kommet til en blindgate allerede ved den andre lanseringen.

Vær tydelig på prioriteringene dine – det finnes noen få tilfeller der det er viktigere å lansere på en bestemt dato enn å sikre produktkvaliteten, men det er ikke mange.

Bruk de fire bryterne dine, innrøm feilene dine og gjør rettingene synlige, slik at folk stoler på at du forstår problemet og ikke gjør den samme feilen to ganger.

Ta hensyn til menneskene – de er like viktige som teknologien. Fra og med den tiden tok jeg med meg disse lærdommene inn i programvare- og IT-prosjekter, og de har vært uvurderlige.

Konklusjonen

Alt i alt må du huske at selv om ansvaret til syvende og sist ligger hos deg, trenger du ikke å gjøre alt arbeidet. Faktisk bør du absolutt ikke forsøke å gjøre det alene. Du kan dra nytte av teamets brede spekter av erfaringer og kunnskap. Du er lederen, men du trenger ikke å være hele teamet.

Prosjektstyringsprogramvare og andre prosjektstyringsverktøy kan hjelpe deg med å følge opp risikoer, milepæler, ressursallokering og andre kritiske indikatorer på om du er på vei mot et vellykket prosjekt.