Så här skapar du en projektplan: 7 steg och exempel

Bent Flyvbjerg har studerat 258 projekt i 20 länder under en period på 70 år. 9 av 10 projekt överskred budgeten. I genomsnitt låg kostnaderna 28 % över prognosen.

Orsaken var inte dåligt genomförande, utan hur teamen hanterade planen. De skrev den en gång, fick den godkänd och slutade sedan använda den. När förutsättningarna förändrades förblev planen oförändrad.

De flesta planer läggs åt sidan redan i vecka tre. De har utformats för att godkännas, inte för att användas. De blandar ihop planering (vad som ska göras och varför) med tidsplanering (när det ska göras). Och de har ingen tydlig strategi för att hantera ändringar i projektets omfattning utan att bryta samman.

Den här guiden visar hur du skriver en projektplan i sju steg som fungerar i vilket verktyg som helst. Du får också se praktiska exempel från Waterfall, Agile, marknadsföring och byggbranschen. Dessutom får du en jämförande översikt över var planerna faktiskt finns: kalkylark, delade dokument och dedikerade projektledningsverktyg.

Vad är en projektplan?

En projektplan är ett formellt dokument som beskriver hur ett projekt ska genomföras, övervakas och avslutas. Den omfattar omfattning, tidsplan, resurser, risker och kommunikationsrutiner, och fungerar som den utgångspunkt som teamet arbetar utifrån när genomförandet inleds.

Vad en projektplan inte är

En projektplan är inte samma sak som ett projektmandat. Projektmandatet godkänner projektet och ger projektledaren befogenheter. Det besvarar frågorna ”ska vi göra detta, och vem har ansvaret?”. Projektplanen tar vid där projektmandatet slutar och besvarar frågorna ”hur, när, av vem och till vilken kostnad?”.

En projektplan är inte heller samma sak som en omfattningsbeskrivning. En omfattningsbeskrivning definierar vad projektet ska leverera och vad det inte ska leverera. Den beskriver hur det ser ut när projektet är ”klart”. Projektplanen omfattar omfattningsbeskrivningen plus tidsplan, resurser, risker, kommunikation och ändringshantering. Den beskriver hur teamet ska nå målet, vem som gör vad och vad som händer när något ändras.

De fem faserna i en projektplan

En projektplan omfattar de fem faser som Project Management Institute (PMI) definierar som projektets livscykel: initiering, planering, genomförande, övervakning och styrning samt avslutning.

Planen i sig ingår i planeringsfasen, men den används aktivt även under genomförande- och uppföljningsfaserna. En plan som läggs undan när planeringen är klar är en plan som snart överges.

Varför är en projektplan viktig?

Uteblir planen, återkommer samma problem gång på gång. Omfattningsglidning, eftersom ingen definierade gränserna, resurskonflikter, eftersom två arbetsflöden gjorde anspråk på samma ingenjör, och missade deadlines, eftersom dolda beroenden upptäcktes för sent.

En projektplan förhindrar sådana misslyckanden genom att synliggöra arbetet innan genomförandet påbörjas.

Planen är en utgångspunkt, inte en färdig ritning

De flesta projektledare betraktar planen som ett leveransdokument. Man skriver den för att visa intressenterna vad man ska bygga, och uppdaterar den sedan endast när man tvingas till det. Då får man bara en ögonblicksbild, inte ett beslutsverktyg.

Projektplanens egentliga syfte är att ge dig något konkret att utgå ifrån när framtiden ser annorlunda ut än väntat. Förslag på ändringar av projektets omfattning utvärderas mot baslinjen, inte mot en känsla. Förseningar mäts mot en plan, inte mot ett minne. Den plan som lyckas bäst är den som uppdateras vid varje milstolpe.

Av detta följer två regler, och resten av denna guide bygger på dem:

Denna metod tar itu med det som Flyvbjerg kallade optimismbias: den systematiska tendensen hos planerare att underskatta kostnader, tidsplaner och risker samtidigt som de överskattar fördelarna. Planer som utformas som statiska prognoser är präglade av denna bias redan från första början och korrigeras aldrig för den.

Viktiga delar i en projektplan

Varje projektplan, oavsett om den är övergripande eller mycket detaljerad, bygger på samma grundläggande komponenter. I listan nedan beskrivs var och en av dem och vad de bör omfatta.

Det är dock inte alla projekt som behöver alla åtta avsnitt i samma detaljnivå. Ett internt projekt som pågår i två veckor kan sammanfatta flera avsnitt på en enda sida. Ett projekt inom en reglerad bransch, till exempel ett initiativ för efterlevnad av läkemedelslagstiftningen, kan utvidga varje avsnitt till ett eget underdokument med formella godkännandesteg.

Så här skriver du en projektplan i 7 steg

Dessa sju steg fungerar oavsett vilken metodik du använder: vattenfallsmetoden, agil metodik eller en hybridmodell. Ordningen är viktig eftersom varje steg lägger grunden för nästa. Att hoppa över steg leder till omarbetningar som blir dyrare än att planera ordentligt från början.

Steg 1: Definiera dina mål och identifiera intressenterna

Börja med dina mål. Det vanligaste misstaget vid planering är att direkt gå vidare till frågan ”vad behöver vi göra?” innan man har besvarat frågan ”hur ser framgång ut?”. Koppla varje mål till ett mätbart resultat och en tidsfrist.

Till exempel är ”Omdesigna webbplatsen” en uppgift. ”Öka konverteringsgraden på prissidan med 15 % före tredje kvartalet” är ett mål som styr alla efterföljande beslut.

Gör sedan en lista över alla som har befogenheter, inflytande eller är beroende av projektet. Dela in dem i kategorier efter roll. Sponsorn godkänner ändringar i budget och omfattning, medarbetarna utför arbetet och informerade parter behöver uppdateringar men fattar inga beslut. En enkel intressentkarta hjälper dig att hålla ordning på detta.

Steg 2: Fastställ projektets omfattning och leverabler

Omfattningen är gränsen. Allt som ligger inom omfattningen tilldelas resurser och schemaläggs; allt utanför skjuts uttryckligen upp eller avvisas. En lista med två kolumner – ”inom omfattningen/utanför omfattningen” – förhindrar den tvetydighet som senare leder till att omfattningen kryper.

Skillnaden mellan projektleveranser och uppgifter. En leverans är ett konkret resultat som intressenterna får: ”migrerad databas”, ”godkänd designmodell”, ”publicerad API-dokumentation”. Uppgifter är det arbete som krävs för att åstadkomma detta. Denna distinktion är viktig eftersom intressenterna bryr sig om leveranserna, medan ditt team bryr sig om uppgifterna.

Det vanligaste misstaget när det gäller projektets omfattning? Att formulera gränserna så vagt att de inte kan användas för att säga ”nej” till tillägg.

”Förbättra användarupplevelsen” kan betyda vad som helst. ”Omforma betalningsflödet för mobila webbläsare, exklusive layouter för surfplattor och ändringar av betalningsleverantörer” ger dig en dokumenterad anledning att säga nej när någon begär stöd för surfplattor mitt i projektet.

Steg 3: Skapa en arbetsfördelningsstruktur

Ta varje delmål från steg 2 och dela upp det i de minsta uppgifterna som kan tilldelas, beräknas och följas upp individuellt. Denna hierarki – projekt -> delmål -> arbetspaket -> uppgift – är din arbetsfördelningsstruktur (WBS).

En användbar tumregel: om en uppgift tar längre tid än några dagar kan den troligen delas upp ytterligare.

WBS utgör grunden för tidsplanen och resursplanen. Om den är ofullständig blir allt som följer därefter opålitligt. Din tidsplan blir felaktig eftersom du har missat vissa arbetsmoment, och din resursplan kommer att innehålla luckor.

Här är ett exempel på hur det skulle se ut i ClickUp:

Steg 4: Skapa projektets tidsplan och milstolpar

Ta dina WBS-uppgifter och ordna dem i rätt ordning: vilka uppgifter är beroende av att andra slutförs först (beroenden), och vilka kan utföras parallellt.

Projektmilstolpar markerar slutförandet av större faser eller leveranser. De fungerar som kontrollpunkter: ”designfasen avslutad” eller ”UAT-godkännande mottaget”. Använd dem för att skapa naturliga granskningspunkter tillsammans med intressenterna. För komplexa projekt kan du visualisera tidsplanen i form av ett Gantt-diagram för att tydliggöra beroenden och den kritiska vägen.

Bygg in en buffert i tidsplanen för att ta hänsyn till realistiska oförutsedda händelser. Lägg sedan till en reserv inom de olika faserna, särskilt testning och granskning, istället för en samlad reserv i slutet som skärs bort när trycket ökar.

Steg 5: Tilldela roller och fördela resurser

Tilldela varje uppgift från WBS till en specifik ansvarig. Delat ansvar innebär inget ansvar. Resursallokering innebär att man säkerställer att de personer som tilldelats uppgiften har kapacitet under den planerade tidsramen.

Det är här planerna kolliderar med verkligheten. Din huvudutvecklare kan till exempel vara tilldelad tre projekt samtidigt. Planen tvingar fram den konflikten i öppen dager innan den leder till att en deadline inte hålls.

RACI-modellen (Responsible, Accountable, Consulted, Informed) klargör vem som gör vad utan att det blir för mycket dokumentation. Om projektet kräver ny programvara eller en underleverantör godkänns detta tillsammans med planen.

Steg 6: Bedöm risker och planera för kommunikation

Identifiera vad som kan gå fel, bedöm sannolikheten och konsekvenserna av varje risk samt dokumentera en åtgärd för varje risk.

Dokumentera vanliga projektrisker i ett riskregister så att de blir synliga och att ansvaret för dem tydliggörs. Här är ett exempel.

Steg 7: Få godkännande från intressenterna och fastställ en utgångsbas

Planen är inte slutgiltig förrän uppdragsgivaren och de viktigaste intressenterna formellt har godkänt den. Detta godkännande utgör projektets utgångsläge: den överenskomna omfattningen, tidsplanen och budgeten som alla framtida förändringar mäts mot.

Utan en utgångspunkt går det inte att skilja en berättigad ändring från det ursprungliga avtalet.

När planen väl är fastställd ska alla ändringar av omfattning, tidsplan eller budget gå igenom den förändringshanteringsprocess som du har definierat i planen. Dela den godkända planen med alla intressenter. Spara den på en gemensam, versionskontrollerad plats som alltid är tillgänglig – inte begravd i en e-posttråd från för tre månader sedan.

Exempel på projektplaner

Exemplen nedan visar hur samma grundläggande komponenter kan anpassas till olika sammanhang. Varje exempel beskriver strukturen, vad som utmärker den och när den ska användas.

Exempel på en projektplan enligt vattenfallsmodellen

En vattenfallsplan följer en fast ordning: krav, design, utveckling, testning, driftsättning. Varje fas avslutas med en formell milstolpe. Intressenterna granskar arbetet och godkänner nästa steg. Inget går vidare förrän den föregående fasen har godkänts.

Exempel på upplägg:

Vad som utmärker den: Hela omfattningen fastställs redan i kravfasen. Gantt-diagrammet är det viktigaste verktyget och visar varje fas i tur och ordning. Ändringsbegäranden är formella och kostsamma. Vattenfallsmodellen byter flexibilitet mot förutsägbarhet.

Lämpar sig bäst för: Projekt med fasta krav, regler och föreskrifter, eller externa team som behöver en fastställd omfattning. Offentliga upphandlingar, compliance-arbete och tillverkningsindustrin passar väl in här.

Inte lämpligt om: Du inte med stor säkerhet kan definiera vad som menas med ”klart” redan vid projektstarten. Att låsa fast ett projektomfång som du inte förstår kostar mer än att göra justeringar under arbetets gång.

Exempel på en agil projektplan

En agil plan fastställer produktvisionen, en prioriterad backlog, ett sprinttempo (vanligtvis två veckor) och teamrollerna. Den detaljerade planen utvecklas sprint för sprint. Teamet lär sig av varje omgång och anpassar sig.

Exempel på upplägg:

Vad som utmärker den: Planen låser inte omfattningen bortom nästa sprint. Intressenterna ser en färdplan med teman per kvartal, inte en lista över leverabler per sprint. Retrospektiven fungerar som återkopplingsloop. Utan den förvandlas Agile till omfattningsglidning med extra steg.

Passar bäst för: Projekt där behoven förändras, där kundernas feedback styr arbetet eller där teamet levererar i små omgångar. Agil metodik är vanligt inom mjukvaruutveckling, produktdesign och interna verktyg.

Hoppa över detta om: intressenterna behöver en fastställd omfattning och ett fastställt datum redan från början. Agiles flexibilitet blir en nackdel när avtalet är strikt.

Exempel på projektplan för marknadsföringskampanj

En marknadsföringskampanj i flera kanaler sammanför innehåll, betald media, e-post och evenemang. Den resulterar i kreativa leverabler med granskningscykler, samordnar externa leverantörer (byråer, frilansare) och ser till att alla kanaler lanseras på samma datum.

Exempel på upplägg:

Vad som utmärker det: Marknadsföringsplaner har fler intressenter som har åsikter än sådana som har beslutsrätt. Utan ett tydligt godkännandeprocess dras varje tillgång genom fem omgångar av redigeringar, och lanseringsdatumet skjuts upp. En RACI-matris är inte valfri här. Det är den som skyddar lanseringsdatumet.

Den andra tydliga risken: Kanalerna sammanfaller på ett datum, men varje kanal har olika ledtider. Tryckta medier kräver sex veckor. Betalda sociala medier kräver två. E-post kräver en. Om du planerar framåt från kickoff istället för bakåt från lanseringen, är kanalerna med lång ledtid redan försenade redan från dag ett.

Passar bäst för: Produktlanseringar, säsongskampanjer, omprofileringar eller annat arbete som publiceras i mer än två kanaler på samma datum.

Hoppa över detta om: Du driver ett program med en enda kanal som alltid är aktivt (bara en blogg, bara ett betalkonto). Då räcker det med en innehållskalender och en veckovis uppföljning. En fullständig kampanjplan är onödiga omkostnader som du inte kommer att använda.

Exempel på projektplan för byggprojekt

Byggprojekt genomförs enligt strikta regler (tillstånd, besiktningar) och med stora fysiska beroenden. Du kan inte installera el innan stommen är uppförd.

Exempel på upplägg:

Vad som utmärker den: Tidsplanen är den största risken, inte omfattningen. En försening i en fas påverkar alla efterföljande faser. Om stomarbetet drar ut på tiden med en vecka förskjuts el-, VVS- och ventilationsarbetena. Byggplaner bygger in en buffert inom varje fas, inte i slutet. Varför? Bufferten i slutet av projektet äts alltid upp av steg som blivit försenade tidigare.

Lämpar sig bäst för: Alla typer av arbeten med fysiska beroenden, väderrisker eller flera olika yrkesgrupper som måste samordnas.

Hoppa över detta om: Du bedriver kunskapsarbete. Att låna byggbranschens tunga portar för en marknadsföringskampanj medför extra kostnader utan att ge något verkligt skydd.

Börja inte ditt nästa projekt från ett tomt ark. ClickUps mall för övergripande projektplan ger dig en färdig struktur med uppgiftsstatusar, anpassningsbara fält för att spåra godkännanden och teamuppdrag samt fem inbyggda vyer, inklusive en tidslinje och en lista över leverabler.

Hämta en gratis mall

Var ska projektplanerna förvaras?

Metoden avgör hur du ordnar arbetet i rätt ordning. Verktyget avgör om planen överlever längre än tre veckor. Du har tre alternativ.

Kalkylblad (Google Sheets, Excel)

Det här är standardverktygen för team som alltid har använt kalkylblad. Ett kalkylblad för uppgifter, ett för tidsplanen och ett för riskregistret. Alla kan redigera. Inget går sönder om någon är offline.

Vad som fungerar

Var det går snett

Lämpligast för: Projekt med ett enda team som omfattar färre än 20 uppgifter, med en tydlig ansvarig och utan inbäddade beroenden.

Hoppa över detta om: Fler än två team behöver samordna sitt arbete, eller om tidsplanen ändras mer än en gång i veckan.

Delade dokument (Google Docs, Notion, Confluence, ClickUp Docs)

En dokumentbaserad plan fungerar när planen huvudsakligen består av löptext: omfattningsbeskrivning, intressentkarta, framgångskriterier och ett riskregister. Uppgifterna presenteras i punktlistor med ansvariga och datum.

Vad som fungerar

Var det går snett

Passar bäst för: Korta projekt (under en månad), beskrivande planer eller som inledning till en uppgiftshanterare. Projektets omfattning och intressenter finns i dokumentet. Uppgifterna finns någon annanstans.

Hoppa över det här om: Du behöver se vem som står i vägen för vad, just idag.

Specialiserade projektledningsverktyg (ClickUp, Asana, Jira, Monday)

Specialutvecklade system där uppgifter, beroenden, ansvariga och tidsplaner delar en gemensam datamodell. Planen och arbetet är samma objekt.

Vad som fungerar

Var det går snett

Passar bäst för: Projekt som spänner över flera team, har föränderliga beroenden och behöver en utgångspunkt som klarar av ändringar i projektets omfattning.

Hoppa över detta om: Det är ett enkelt projekt med en ansvarig, ett team, fastställd omfattning och en varaktighet på under tre veckor. Då går det snabbare att använda ett dokument.

6 skäl till varför en projektplan misslyckas

De flesta projektplaner tappar fart av förutsägbara skäl.

1. Formulera projektets omfattning så brett att det inte går att säga nej

Omfattningen är endast användbar när den ger dig en dokumenterad anledning att avböja tillägg. Om du inte kan hänvisa till dokumentet om omfattningen och säga: ”Det ligger utanför omfattningen”, är omfattningen för vag för att skydda projektet.

Formulera varje avgränsning av projektets omfattning som ett testbart påstående. ”Omforma betalningsflödet för mobila webbläsare, exklusive layouter för surfplattor och ändringar hos betalningsleverantörer” är en avgränsning. ”Förbättra användarupplevelsen” är det inte.

2. Inhämta uppskattningar från chefer

Top-down-uppskattningar är genomgående optimistiska. Detta är den optimistiska snedvridningen som nämndes tidigare, tillämpad på uppskattningar. Den som fördelar arbetet underskattar nästan alltid arbetsinsatsen jämfört med den som utför det.

Det är utvecklaren som utför arbetet som vet var friktionen faktiskt finns. Skapa WBS i samarbete med teamet, annars kan du räkna med omarbetningar.

3. Att lägga all din buffert i slutet

En tidsplan som lägger till en två veckors ”reserv” i slutet av ett fyra månaders projekt är en tidsplan utan någon verklig reserv. Denna buffert är det första som skärs bort när trycket ökar.

Lägg till reservtid inom faserna, särskilt vid testning och granskning, där den vanligtvis förbrukas. Den buffert som finns inbyggd i arbetet består. En buffert som placeras i slutet försvinner innan projektet behöver den.

4. Att lämna begreppet ”klart” odefinierat

När kriterierna för färdigställande inte är specificerade betyder ”klart” något olika för varje intressent:

Skriv ner vad ”färdigt” innebär för varje delmål. Notera vilka kriterier det ska uppfylla, vilket format det ska ha och vem som ska godkänna det. Otydliga kriterier är den främsta orsaken till omarbetningar i ett projekts slutskede.

5. Att låta planen ligga kvar som en bilaga i ett e-postmeddelande

En plan som ingen kan hitta är i praktiken detsamma som ingen plan alls.

Om teamet måste fråga var den aktuella versionen finns kommer de inte att använda den som underlag för beslut, inte märka när den är inaktuell eller uppdatera den när förutsättningarna förändras.

Spara planen där teamet arbetar, och se till att den är versionshanterad och länkad till de uppgifter den styr. Planen ska vara tillgänglig med två klick från vilken teammedlems arbetsyta som helst.

6. Att betrakta planen som ett engångsdokument

Det tydligaste tecknet: Planens senaste ändringsdatum är äldre än den senaste uppgiften du lade till. Om arbetet har gått vidare men planen inte har uppdaterats, har planen slutat styra projektet för länge sedan, utan att någon har märkt det.

Avsätt 15 minuter för en genomgång av planen vid varje milstolpe och varje gång en ändringsbegäran godkänns. Syftet är inte att skriva om planen från grunden, utan att bekräfta att utgångsläget fortfarande stämmer överens med verkligheten, eller att dokumentera om så inte är fallet.

Hur vi skapar och hanterar projektplaner i ClickUp

Vi skriver inte projektplaner i ett Google Doc-dokument och hoppas på det bästa. Våra planer finns i ClickUp, precis bredvid det arbete de beskriver. På så sätt blir planen aldrig inaktuell.

Dokument för projektomfattning och kartläggning av intressenter (steg 1 och 2)

I ClickUp Docs finns projektbeskrivningen, framgångsmätvärdena och tabellen över intressenter. Eftersom dokumentet finns i samma arbetsutrymme som uppgifterna är det enkelt att svara på frågan ”ingår detta i projektet?”. När någon föreslår en ändring hänvisar vi dem till samma dokument som beställaren har godkänt, inte till ett Google Doc från för tre månader sedan.

Uppgifter och deluppgifter för WBS (steg 3)

Gantt-vy för beroenden och den kritiska vägen (steg 4)

Dra en linje mellan uppgifterna i <14>ClickUp Gantt-vyn för att ange ett beroende. Den kritiska vägen syns, och när en uppgift försenas förskjuts efterföljande uppgifter i takt med den. Tidsplanen förblir realistisk utan att någon behöver bygga om den manuellt. Det är just detta som oftast går fel i ett kalkylblad, och det är därför projektledningsverktyg har sin berättigade plats.

Översiktspaneler för baslinjen (Steg 7)

När sponsorn har godkänt planen hämtar ClickUp-dashboarden realtidsdata om färdigställandegrad, försenade uppgifter och arbetsbelastning. Svaret på frågan ”var står vi?” kommer från samma data som teamet arbetar med, inte från ett separat statusdokument. Intressenterna tittar på dashboarden istället för att begära ett statusmöte.

När ClickUp inte är rätt val

ClickUp kommer verkligen till sin rätt när projekt involverar flera personer, rörliga tidsplaner och överlämningar mellan olika avdelningar. Ju mer samordnat ditt arbete behöver vara, desto större nytta har du av verktyget.

Hoppa över detta om: Du är frilansare som hanterar ett fåtal leveranser, eller ett team som behöver komplexa finansiella modeller och pivottabeller. I sådana fall är ett enkelt dokument eller kalkylblad ett bättre alternativ.

Skapa en projektplan som ditt team kommer att använda

En projektplan fungerar bara om den ger en helhetsbild: alla leverabler, ansvariga, beroenden och risker samlade på ett ställe. Dessutom måste den användas som referens under arbetets gång och inte glömmas bort redan när den första milstolpen nås.

I hundratals projekt behandlar de team som levererar konsekvent sina planer som levande dokument. De granskar dem vid varje milstolpe, uppdaterar antaganden när förutsättningarna förändras och hanterar varje begäran om ändring av omfattningen genom en dokumenterad ändringsprocess. Det är det som håller projekten på rätt spår.

Om ditt team har vuxit ur delade dokument och enkla kalkylark är det värt att prova ett verktyg som ClickUp. Du kan samla projektomfattning, uppgifter, beroenden, ansvariga och översiktspaneler på ett och samma ställe, med vyer som hålls synkroniserade i takt med att planen utvecklas.

Registrera dig på ClickUp redan idag!

Vanliga frågor om projektplaner

Vad är skillnaden mellan en projektplan och en projektledningsplan?

En projektplan fokuserar på specifika leverabler, tidsplan och resurser för ett enskilt projekt. En projektledningsplan (ett PMI-begrepp) är mer omfattande och inkluderar underordnade planer för förändringshantering, riskhantering, kommunikation och upphandling som styr hur projektet hanteras. För de flesta team utanför formella PMI-miljöer omfattar begreppet ”projektplan” båda delarna.

Kan man skapa en projektplan utan projektledningsprogram?

Ja, för korta projekt med en ansvarig och färre än cirka 20 uppgifter. Ett delat dokument med en beskrivning av projektets omfattning, en lista över intressenter och en enkel tabell över ansvariga och förfallodatum går snabbare än att sätta upp ett projektledningsverktyg. Gränsen dras vanligtvis vid beroenden mellan team: när fler än två team behöver samordna sitt arbete börjar kalkylbladet förlora i precision.

Vad är den kritiska vägen i en projektplan?

Den kritiska vägen är den längsta kedjan av beroende uppgifter i ditt schema, som avgör det tidigaste möjliga slutdatumet för projektet. Varje försening i en uppgift på den kritiska vägen försenar hela projektet; förseningar i icke-kritiska uppgifter kan kompenseras av tidsmarginalen. Gantt-diagram visualiserar den kritiska vägen så att projektledare vet vilka förseningar som faktiskt spelar roll och vilka som inte gör det.

Vem ansvarar för att utarbeta projektplanen?

Projektledaren ansvarar för planen, men ska inte skriva den på egen hand. Fackexperter ger uppskattningar av arbetsinsatsen, uppdragsgivaren godkänner omfattning och budget, och de som bidrar till projektet validerar beroendeförhållanden. Top-down-planer som utarbetas utan synpunkter från de som utför arbetet underskattar konsekvent arbetsinsatsen – ett mönster som Bent Flyvbjergs forskning har dokumenterat i tusentals projekt.

Vad är skillnaden mellan en projektplan och en projektkalkyl?

En projektplan definierar vad som ska göras, av vem, till vilken kostnad och hur riskerna ska hanteras. En projektplan är en del av planen som visar när uppgifterna ska utföras och i vilken ordning. Att blanda ihop de två leder till att tidsplanerna styr omfattningen istället för tvärtom, vilket är ett av de vanligaste planeringsfelen.

Hur ofta bör du uppdatera en projektplan?

Du bör uppdatera projektplanen vid varje större milstolpe och varje gång en ändringsbegäran godkänns. En plan som i månad tre fortfarande speglar antaganden från vecka ett skapar en falsk trygghet. PMI rekommenderar formella planöversyner vid varje fasgräns, med ad hoc-uppdateringar när risker materialiseras eller när ändringar av projektets omfattning godkänns genom ändringshanteringsprocessen.