Så undviker du projektmisslyckanden i 3 steg + 4 fallstudier

Vad innebär ett projektmisslyckande?

Precis vad det låter som – när ett projekt inte uppfyller de projektmål som teamet satte upp i början, inte lever upp till kundens eller viktiga intressenters förväntningar eller inte håller tidsplan, budget eller omfattning.

Varför misslyckas projekt?

Som jag antydde i inledningen finns det flera vanliga orsaker till att projekt kan misslyckas. Vanligtvis beror det på en risk som inte bedömdes korrekt och/eller att teamet (inklusive projektledaren) inte hanterade risken på rätt sätt.

Andra vanliga orsaker till projektmisslyckanden kan vara bristfällig kommunikation kring status, problem eller risker; att teammedlemmar inte följer (eller inte förstår) projektets omfattning, projektleveranser (dvs. omfattningsglidning) eller tidsram; brist på resurser eller att man inte följer fastställda processer eller metoder.

Så undviker du projektmisslyckanden: 3 steg

Riskhantering är en viktig projektledningsaktivitet. Den är så viktig att bristande riskhantering ofta innebär att projektledningen misslyckas. Riskhantering består av tre viktiga delar:

1. Identifiera risker.
2. Bedöm det du har identifierat: Hur sannolikt är det att det inträffar och hur allvarliga blir konsekvenserna om det gör det? Vilken är sannolikheten och påverkan?
3. Förbered åtgärds- och beredskapsplaner för de risker som kan kullkasta ditt annars framgångsrika projekt. Riskregister är praktiska för att hålla reda på vad du har gjort.

1. Identifiera risker

Börja med att identifiera riskerna. Om du gör detta på ett bra sätt ökar du avsevärt dina chanser att lyckas med projektet. Även om det är svårt att upptäcka alla risker kan du vanligtvis identifiera de största riskerna om du granskar projektet systematiskt. Detta är vanligtvis en del av processen med att skapa en projektplan.

Min bakgrund är inom programvaruutveckling, både produktutveckling och IT, samt tillhörande processer. Programvaruprojekt är komplexa och sårbara och har, med några få undantag, inte den typ av inbyggda felsäkringar och kontroller som exempelvis byggprojekt eller produktion av medicintekniska produkter har.

Du bör ha projektmål för var och en av de fyra reglagen:

1. Tidsplan
2. Innehåll
3. Kostnad
4. Kvalitet

Om du inte vet vad de är, är det där du ska börja. Jag tycker vanligtvis att två av de fyra kommer att förändras något, men ju bättre du förstår vart du är på väg, desto lättare blir det att identifiera hinder.

Om du förstår vilket av de fyra reglagen som har högst prioritet kan du minska risken genom att göra lämpliga avvägningar i små steg.

Det är lätt att fastna i reglaget för projektets tidsplan och missa risker som kan påverka de andra reglagen, men alla hänger ihop och är lika viktiga att identifiera.

Att nå tidsmålen med en produkt full av buggar är vanligtvis inte ett bra alternativ – även om du lanserar den kommer du till slut att behöva göra korrigeringsversioner som förskjuter tidsplanen för en tillräckligt bra produkt mer än vad det hade gjort att åtgärda problemet från början.

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

Bortom de fyra reglagen

Utöver de fyra reglagen måste du balansera tre aspekter av projektet:

1. Produkt, som vanligtvis täcks av reglagen
2. Process
3. Människor

Processrisker finns i två varianter: en befintlig brist i processen som inte uppfyller projektets behov och avsaknad av en process för något som är avgörande för det teamet arbetar med. Processrisker är ganska enkla att minska genom att skapa eller förbättra processen.

Den mänskliga aspekten ignoreras ofta, men ditt team och de team som det samarbetar med kommer att avgöra om projektet lyckas eller misslyckas. Svåra eller ointresserade projektintressenter gör det svårt att få det du behöver för att gå vidare.

Överarbetade, stressade eller olyckliga teammedlemmar kommer inte att få jobbet gjort. Vissa av de potentiella personalproblemen kan du identifiera offentligt, medan andra kanske bör hanteras privat, men gör inte misstaget att ignorera dem.

2. Bedöm de risker du har identifierat

När du har identifierat riskerna ska du fastställa hur sannolikt det är att risken inträffar. Jag brukar använda en procentsats – 100 % betyder att jag är säker på att det kommer att inträffa. Det är också viktigt att fastställa hur allvarliga konsekvenserna blir om risken faktiskt inträffar. Det enklaste sättet att göra detta är att kategorisera riskerna som hög, medelhög eller låg risk.

När du har gjort den här analysen är det dags att involvera teamet. Fråga varje projektteammedlem eller bidragsgivare vad de är oroliga för, lägg till detta i listan över risker och ta upp den för granskning:

• Kan teamet komma på andra risker som du inte har tagit upp?
• Vad tycker de om analysen av sannolikhet och påverkan?

Utifrån det här mötet kan du justera din riskplan. Del ett och två är klara – för tillfället. Du behöver gå igenom riskerna minst varje vecka för att se om det finns nya risker, om vissa inte längre är tillämpliga och om någon sannolikhet eller påverkan har förändrats.

3. Förbered åtgärds- och beredskapsplaner

Slutligen, om kombinationen av sannolikheten för och påverkan av någon risk kan få projektet att spåra ur, bör du tillsammans med teamet ta fram dokumenterade planer för riskreducering och beredskap.

Riskreducering innebär att göra risken mindre sannolik eller att minska påverkan om den ändå inträffar. Beredskap fokuserar på de åtgärder du kommer att vidta om risken är oundviklig och inträffar.

Se till att planerna dokumenteras och att alla känner till dem. Det är också en god idé att planera för potentiella personalproblem utöver de fyra reglagen och processen, men du bör förmodligen göra analysen själv och hålla den konfidentiell.

Så överlever du ett projektmisslyckande

Den andra orsaken till misslyckanden inom projektledning är en bristfällig reaktion på att en projektrisk inträffar, oavsett om den var förutsedd eller inte.  Det här ligger i hög grad på dig som projektledare. Innan du genomför något av stegen nedan bör du börja med de här två tipsen:

• Få inte panik. Kom ihåg att andas.
• Skyll inte på någon och låt inte någon annan börja leta efter syndabockar.

1. Hänvisa till din beredskapsplan

Om du har en beredskapsplan på plats ska du omedelbart kalla till ett möte eller åtminstone skicka ett e-postmeddelande som aktiverar beredskapsplanen. Påminn alla om vad planen innebär och tala om för dem när och hur de ska rapportera status.

Om du hoppar över detta eller skjuter upp det kommer du att upptäcka att personer som gärna vill hjälpa till har börjat agera i panik; när det händer tappar du överblicken över vad som har gjorts, och det förvärrar ofta problemet.

Om du inte har någon beredskapsplan ska du omedelbart samla styrkorna genom att kalla till ett möte och ge strikta instruktioner om att INTE GÖRA NÅGOT ANNAT före mötet.

Annars kommer alla att försöka hjälpa till och du kommer inte att ha någon aning om vad som har gjorts. Beskriv problemet tydligt under mötet – det är alltid häpnadsväckande hur många olika uppfattningar människor kan ha om vad problemet är.

Genomför en samlad grundorsaksanalys för att gå till botten med problemet och ta fram en plan – vem, vad och hur – för att återhämta situationen. När du arbetar med en grundorsaksanalys behöver du förstå vem som gjorde vad fram till dess att problemet uppstod, men håll diskussionen på den nivån.

Med andra ord: håll dig till fakta. Fördela inte skulden, eftersom skuldbeläggning distraherar. Om ditt team inte kan komma fram till en lösning har du några alternativ.

Det första är att ta in någon som kan det allmänna ämnesområdet men som inte arbetar med just det här projektet – om problemet till exempel verkar ligga i databasen kan du ta in en databasadministratör som inte för närvarande arbetar med projektet, för att få ett annat perspektiv.

En annan metod är att ta in någon som inte alls har praktisk kännedom om projektet. Ibland leder kravet på att förklara varje steg uttryckligen till att felaktiga antaganden eller sådant som människor har förbisett blir synliga.

2. Lös problemet

Se till att alla ställer sig bakom din handlingsplan och fördela uppgifter. Be personer att rapportera sina framsteg till dig och tala om hur ofta de ska skicka framstegsrapporter – varje timme, när de har slutfört en uppgift, i slutet av dagen eller vad som nu är rimligt utifrån situationen.

Rapporteringen kan verka självklar för dig, men det gör den inte för alla. Regelbundna uppdateringar hjälper teamet att behålla fokus. Rapportera regelbundet samlade framsteg till hela teamet.

De i teamet som inte har några omedelbara uppgifter kommer att bli rastlösa och till slut försöka hoppa in och hjälpa till, om du inte förser dem med statusuppdateringar och annan information.

Det är också mycket viktigt att hålla ledningen informerad. Använd ditt omdöme för att avgöra vem som behöver uppdateringar och när, men rapportera regelbundet samlade framsteg till hela teamet.

3. Avsluta det

När det faktiskt är klart, alltså. Skapa en slutrapport och gå vidare till nästa steg. Ge teamet lite tid att återhämta sig.

4. Genomför en efteranalys eller retrospektiv

Det är viktigt att genomföra en projektutvärdering för att samla in lärdomar. Så här kan du strukturera den:

• Beskriv problemet så att alla har samma utgångspunkt
• Börja med det som gick bra. Även i den mest allvarliga situationen gick något fortfarande rätt. Det ger mötet en helt annan ton från början.
• Prata om vad som behöver förbättras. Om det finns tid, brainstorma kring sätt att genomföra förbättringarna; annars tilldelar ni uppgifter och sätter förfallodatum samt följer upp dem på dessa datum.

Om det faktiskt var någons fel, ta upp det med personen i fråga – privat. Om du gör det offentligt kommer hela teamet att undra vem som står näst på tur att bli förödmjukad inför alla andra.

Om du hoppar över det helt kommer teamet att känna att någon kom undan med något och att problemet inte blev löst. Var saklig och följ upp eventuella personliga processförändringar som någon behöver genomföra. Det handlar om ansvarstagande och förbättring, inte om att hitta någon att skylla på.

3 exempel på verkliga projektmisslyckanden

Jag har själv varit med om en del misslyckade IT-projekt, även om de som tur var – men smärtsamt – återhämtade sig.

Här är ett par av mina egna misslyckade IT- och utvecklingsprojekt samt ett exempel på ett berömt misslyckat projekt.

Dessa exempel på projektmisslyckanden och fallstudier av misslyckade projekt bör också ge dig en konkret bild av hur projekt kan misslyckas och hur detta kan hanteras.

1. Bokföringssystemet

Tidigt i min karriär arbetade jag på IBM. Mitt första riktiga jobb var att ta över ett ganska litet system som matade in data i företagets bokföringssystem. Någon på IBM hade skrivit det i ett obskyrt programmeringsspråk som kallades RPG, på ett litet system.

Jag ledde inte bara projektet – jag ansvarade för hela systemet (även om det fanns en administratör), inklusive insamling av projektkrav, felsökning och programmering.

En dag lade jag in ett nytt program, körde det och hittade ett fel. Jag korrigerade felet och körde programmet igen. Nästa morgon fick jag ett samtal från ekonomiavdelningen om att det fanns dubbla poster (vilket är mycket dåliga nyheter i bokföringsvärlden).

För det första granskade ingen mitt arbete. För det andra involverade jag inte personer från de efterföljande systemen för att kontrollera posterna innan de skickades vidare. Och för det tredje tog jag mig inte tid att analysera några av de gamla programmen som fortfarande kördes och skapade dubbla poster. Det fanns inte heller någon process, förutom den jag improviserade fram under arbetets gång.

Och sedan kom min reaktion – panik. Herregud, direkt efter universitetet höll jag på att förstöra IBMs bokföringssystem. Jag involverade inte rätt personer – administratören visste inte vad som pågick – och han skapade ytterligare en uppsättning poster utan att veta om det. Till slut arbetade jag 48 timmar i sträck för att hitta grundorsaken, åtgärda den samt skriva och köra program för att korrigera bokföringsfelen.

Och jag lärde mig min läxa – granska noggrant, be om granskningar, tänk på vad som kan gå fel och stanna upp och tänk innan du kastar dig in i ett försök att lösa saker (allt sådant som projektledningsprogram för bokföring kan hjälpa till med). Föreställ dig nu att jag ledde ett team på 10 personer och att alla gjorde samma sak i sina försök att lösa problemet. Det hade verkligen varit omöjligt att återhämta sig utan att stänga ner IBMs bokföringssystem för att reda ut situationen.

More Articles

• Eisenhower-matrisen: Så prioriterar du uppgifter på ett smart sätt
• Så bemästrar du resurshantering i projektledning

2. Den nya interna produkten

Som konsult ledde jag ett nytt, stort projekt där många personer hade synpunkter på kravbilden, vilket ledde till ständiga förändringar av de funktionella prioriteringarna. Vi använde en agil projektledningsprocess, något som företaget inte hade använt tidigare. Kvalitetssäkringen var mycket bra på att testa, men hade ännu inte förstått slutanvändarens perspektiv och arbetsflöde.

Jag kände till allt detta och uttryckte det då och då, men jag hade inget riskregister, ingen bedömning av påverkan och sannolikhet, ingen beredskapsplan och inga riskreduceringsplaner. Jag var inte heller den primära informationskanalen till projektets beställare, även om jag träffade henne ibland.

Vi lade till en sprint. Sedan ytterligare en. När det därefter blev tydligt att vi inte riktigt hade kommit så långt att vi kunde genomföra ett betatest lade vi till en tredje sprint.

Eftersom det inte var jag som förmedlade information till projektets beställare hade jag ingen aning om att hon inte kände till allt detta. Den ansvariga personen gjorde det kritiska misstaget att inte berätta för beställaren, i hopp om att vi skulle kunna ro det i land.

Och för att vara rättvis: även om jag pratade om risker gav jag honom inte en konkret uppsättning risker att presentera för att förbereda beställaren på möjligheten att tidsplanen skulle förskjutas.

Mitt i allt detta hade jag ett möte med beställaren och nämnde i förbifarten den sista sprinten som vi skulle lägga till. Hon avbröt mig. Hon visste ingenting om den och var inte glad.

Det visade sig att hon var mer upprörd över överraskningen än över att tidsplanen hade förskjutits. Det fick offentliga konsekvenser, och till slut gick den projektansvariga personen vidare till en annan del av företaget eftersom förtroendet var borta.

Återigen lärde jag mig viktiga saker av misslyckandet. Det räcker inte att känna till riskerna, du måste sammanställa dem, bedöma dem, ha planer för riskreducering och beredskap samt offentliggöra dem och ständigt hålla dem synliga.

Jag har aldrig varit den som döljer risker och problem, men vikten av transparens i projekt blev omisskännligt tydlig.

3. Kommer du ihåg OS2?

Nej, det gör ingen. Det är ett av många misslyckade systemutvecklingsprojekt. Jag arbetade på IBM när det ursprungliga OS2 lanserades – en konkurrent till Windows. Jag provade inte ens den första versionen, eftersom vi på IBM alla visste att den verkligen var full av buggar. Resten av världen upptäckte genast att den hade alldeles för många fel för att vara värd besväret.

Den hade tillräckligt många buggar för att projektgruppen omöjligen kunde ha trott att den var helt färdig, men på något sätt gjorde de inte rätt avvägning och sköt inte upp lanseringen. Om du inte tar hänsyn till den mänskliga faktorn kommer både ditt team och dina kunder snabbt att rasera en vacker plan.

Inom programvara finns det många alternativ i en sådan situation – gör en begränsad lansering till personer som tolererar buggarna för att få tillgång till den allra senaste programvaran, offentliggör att du väntar med att lansera tills tillförlitligheten motsvarar dina höga krav, och så vidare.

Det här skedde tillräckligt tidigt i min karriär för att jag skulle kunna dra värdefulla lärdomar av det faktum att en produkt jag älskade hade nått en återvändsgränd redan vid den andra lanseringen.

Var tydlig med dina prioriteringar – det finns några få fall där det är viktigare att lansera ett visst datum än att ha hög produktkvalitet, men de är inte många.

Använd dina fyra reglage, erkänn dina misstag och gör korrigeringarna synliga så att människor litar på att du förstår problemet och inte kommer att göra samma misstag två gånger.

Ta hänsyn till människorna – de är lika viktiga som tekniken. Från och med den tiden tog jag med mig dessa lärdomar till programvaru- och IT-projekt, och de har varit ovärderliga.

Slutsatsen

Kom framför allt ihåg att även om ansvaret i slutändan är ditt behöver du inte göra allt arbete. Faktum är att du absolut inte bör försöka göra det på egen hand. Du kan dra nytta av teamets breda erfarenhet och kunskap. Du är ledaren, men du behöver inte vara hela teamet.

Projektledningsprogramvara och andra projektledningsverktyg kan hjälpa dig att följa upp risker, milstolpar, resursfördelning och andra viktiga indikatorer på om du är på väg mot ett framgångsrikt projekt.