Projekttidslinjer hjælper os med at besvare de vanskelige spørgsmål om – hvad skal du levere? Og hvornår skal du levere det? For at opnå ethvert meningsfuldt mål og få noget af betydning gjort, har du brug for en plan.
At skabe en god plan er et vigtigt skridt for at kunne levere et projekt succesfuldt. Hvis du ikke har en plan, ved du ikke, hvad du leverer, for ikke at nævne hvornår eller hvordan du kan levere det.
Her er, hvad du vil lære i dette indlæg:
- Du vil forstå nogle vigtige principper for projektplanlægning, som vil informere din tilgang til planlægning af ethvert projekt.
- Du vil kunne hjælpe dine teams og interessenter med at forstå, hvad vi kan planlægge og forudsige på vores projekter, hvordan vi gør det, og hvorfor vi skal tage os tid til at planlægge projekter ordentligt.
- Du vil blive sikker på at oprette og arbejde med projekttidslinjer – fra højt niveau projekttegninger til mere detaljerede Gantt-diagrammer. Når nogen spørger dig ‘hvor lang tid vil dette projekt tage?’, vil du kunne give dem nogle svar.
- Du vil have din egen projektplanlægningscheckliste, så når du starter et nyt projekt, ved du præcis, hvad du skal gøre for at få projektplanen i orden.
- Og du vil forstå, hvordan du navigerer planlægningshorisonten og tager højde for ukendte faktorer i din projekttidslinje.
Lad os starte med at tale om nogle grundlæggende principper for at skabe projektplaner. Dette er tingene, du skal have i baghovedet, når du skaber en projektplan eller tidslinje. Men måske skal vi starte med at tackle elefanten i rummet her. Har vi virkelig brug for at gøre dette overhovedet?
Det korte svar er ja. Men her er nogle af de typiske argumenter imod projektplaner:
Nogle mennesker mener, at projektplaner er ren fantasi – de er bare luftkasteller. De er ikke forankret i virkeligheden af projektet, teamet eller opgaven. Og så bliver disse fantasifulde projektplaner bare håndjern for projektlederen og teamet, der er ansvarlig for leveringen. Man bliver bundet til en tilfældig halvbagt plan, som ingen rigtig har gennemtænkt ordentligt, og det gør det meget vanskeligt at levere.
Du vil også høre folk indvende, at projektplaner kan begrænse et teams evne til at iterere og selvoptimere. Hvis vi virkelig vil have folk til at yde deres bedste, burde vi så ikke fjerne de begrænsninger, der vil holde dem tilbage?
Og jeg tror, den tredje store indvending, jeg hører, er, at der ikke er nogen mening i at gøre det, fordi projektplaner konstant er forældede. Hvad er pointen med at have en plan, hvis ingen følger den, og den hele tiden ændrer sig?
Alle gode punkter, ikke? Men jeg synes, Winston Churchill udtrykker det godt: “De, der planlægger, gør det bedre end dem, der ikke planlægger, selvom de sjældent holder sig til deres plan.”
Sandheden er, at en projektplan måske ikke er perfekt, men det er meget bedre end slet ingen plan!
Lad os hurtigt tage fat på disse indvendinger direkte.
For det første, lad os tackle den indvending, at projektplaner er ren fantasi, som derefter binder projektlederen og teamet, der forsøger at levere. Hvis din projektplan er ren fantasi, gør du, eller den person, der skabte den fantasifulde plan, det forkert. Hvis planen ikke er forankret i virkeligheden, så er det ikke rigtig en projektplan overhovedet, det er en projektdrøm! Og vi skal rette det for at gøre det realistisk.
Og hvis du føler, at projektplaner er som håndjern – husk, at begrænsninger ikke altid er en dårlig ting. Begrænsninger skaber muligheder for at være kreative. Projektplaner kan give os nogle sunde rammer at være kreative indenfor.
Den anden indvending er, at projektplaner kunstigt kan begrænse et teams evne til at selvoptimere. Jeg vil hævde, at bare fordi du har en projektplan, betyder det ikke, at du ikke kan selvoptimere og iterere, mens du går.
Det er ikke projektplanen, der skaber disse typer begrænsninger – det er projektlederens forhold til den, de laver projektet for. Hvis der er et godt forhold til klienten eller projektsponsoren – og en god begrundelse for at dreje projektet, mens du går – så vil de sandsynligvis ønske at optimere deres projekt lige så meget som du gør – de vil trods alt have de bedste resultater!
Den tredje indvending – at projektplaner konstant er forældede – er en populær en. Det er sandt – du skal opdatere dem konstant! Men vi kan ikke rigtig sige, at det er et problem at opdatere vores projektplaner, fordi det er vores job! Bare fordi du skal tilpasse din plan og regelmæssigt opdatere den, betyder det ikke, at der ikke er værdi i det. Så selvom det måske er meget arbejde, skal du ikke undgå projektplanlægning – det er måske ikke perfekt, men det er meget bedre end slet ikke at gøre det.
Lad os komme i gang med principperne for projektplanlægning.
Det er en proces, ikke en ting
Først skal vi huske, at projektplanlægning er en proces, ikke en engangsforeteelse. Projektplanlægning er noget, du skal gøre kontinuerligt gennem et projekt. Det er ikke noget, du kan gøre én gang og så glemme! Så mens versioner af projektplaner kan blive ubrugelige og forældede, vil projektplanlægning aldrig være ubrugelig eller nyttesløs.
Når projektet udvikler sig, skal din plan udvikle sig med det. Tilbage til vores skibsanalog fra andre indlæg – hvis vinden blæser dig ud af kurs, og du er på en båd, giver du ikke bare op og tænker – ‘nå, det var så det, lad os bare sejle i cirkler nu i stedet’.
Nej, du ville finde ud af, hvor du er, sørge for, at du stadig ved, hvor du skal hen, og du ville planlægge en ny kurs for at komme dertil. Bare fordi den første plan ikke helt virkede, betyder det ikke, at den første plan var ubrugelig. Husk, projektplanlægning er en proces, ikke en ting.
Projektplaner er et kommunikationsværktøj
Vi skal også huske, at vores projektplaner er et kraftfuldt kommunikationsværktøj. Her er sagen: projekter kræver ressourcer, der kan være værdifulde, knappe og dyre. Så før du starter et projekt, vil folk normalt gerne vide et par irriterende små detaljer som, hvornår bliver projektet leveret? Hvor meget vil det koste? Hvad præcis vil blive leveret? Hvordan vil det blive leveret?
Hvis du vælger tilgangen uden projektplan, bliver det svært at besvare disse tilsyneladende grundlæggende projektstyringsspørgsmål.
Hvis alt, hvad du kan sige som svar, er – ‘nå, det må vi se – ingen ved det rigtig endnu, det vil alt afhænge af, hvor hurtigt teamet kan få arbejdet gjort!!’ Det vil muligvis ikke flyve. Det kan være sandt, men din klient eller sponsor vil normalt have brug for at have en idé om, hvad de får, hvornår, og for hvor meget, før de godkender et projekt.
De har brug for en slags kort for at se, hvor tingene er på vej hen. At kunne give en klar visuel ved hjælp af en projektplan gør det meget lettere at forklare. Det er også vigtigt for teamet, fordi det af en eller anden grund altid føles mere gennemtænkt, når noget er nedskrevet. Det begynder at indgyde teamet lidt tillid til, at der er en plan.
Så husk, projektplanen er et kraftfuldt kommunikationsværktøj til at kommunikere med dit team, din klient eller sponsor og enhver med interesse i dit projekt.
Projektplanen er rygraden
Projektplaner er rygraden i vores projekter. De holder alt på plads. Projektplaner hjælper os med at kortlægge faser, opgaver, afhængigheder og milepæle, være i stand til at estimere levering af et projekt og holde styr på fremskridtene i et projekt.
Som projektledere skal vi vide, om vores projekt holder sig inden for budget, tidsplan og omfang. Du kan ikke vide det, medmindre du har noget at måle imod.
Så projektplanen præciserer processen og opgaverne, der vil generere projektets output og leverancer. Det giver dig også informationer, der gør det muligt for dig at estimere projekt
et korrekt. Udover det, gør det det muligt for alle at visualisere hele projektet og se de indbyrdes afhængigheder og potentielle konflikter eller overlapninger mellem opgaver.
Det hjælper med at vise, hvem der skal gøre hvad og hvornår, så du kan forudsige dine personalebehov. Og det giver dig noget at måle imod, så du kan baseline og spore dine projektfremskridt med nøjagtighed. Det gør det muligt for dig at levere milepæle til godkendelse fra interessenter og andre vigtige kontrolpunkter undervejs.
Og det gør det muligt for dig at have den samtale omkring den vigtige go-live eller projektets afslutningsdato. Så en projektplan hjælper os med at udføre al vores projektstyring. Uden en er det meget svært at styre et projekt ordentligt.
Mere end bare en plan
Men en projektplan er også mere end bare en plan. Der er også et vigtigt ledelsesaspekt ved projektplaner, der er værd at overveje. En del af vores rolle som projektledere er at kaste en vision. Og en projektplan kan hjælpe os med det.
Hvis vi arbejder på et projekt, og der ikke er en plan, kan projektet nogle gange føles lidt formålsløst. Men når der er en solid plan at følge, er der noget for teamet at stå bag. Der er noget at arbejde hen imod, der er en mening og et formål med det arbejde, de udfører.
Så husk, at bare det at have en plan kan gøre en massiv forskel for teamets motivation og formål. For vores interessenter kan projektplanen også give forsikring, den kan give den klarhed af vision, de har brug for – nordstjernen, de kan stræbe efter – for at bryde sig om projektet. Og for os hjælper projektplanen med at holde os i tjek og på toppen af projektets fremskridt.
Den bedste version af sandheden
Du husker nok den indvending mod projektplaner – de er bare luftige projektdrømme? Nå, hvis vi ikke er forsigtige, kan vi blive skyldige i netop det. For at projektplanen kan gøre alt det, vi lige har talt om, skal den være den bedste version af sandheden, som vi kan opnå.
Opgjorte projektplaner er ofte den dovne løsning – vi kopierer bare en projektplan fra et andet projekt, eller smider bare noget hurtigt sammen, fordi vi ikke har tid til at gøre det ordentligt. Så nogle få uger senere bliver det sat i sten, fordi det bliver sendt til klienten eller ledelsen, og vi fik aldrig tid til at opdatere det.
For at være nyttige og værdifulde skal vi tage ejerskab over at lave bedre projektplaner. Vores projektplaner bør udsende sandheden, ikke ende med at være et sæt håndjern, der ender med at lænke projektteamet eller den næste uheldige sjæl, der arver dit halvt planlagte projekt.
Så ordentlig projektplanlægning kan være vanskelig, og det tager tid at gøre det ordentligt, men det er værd at gøre. Husk, det er ikke en engangsforeteelse, du skal skabe en plan og derefter løbende raffinere den.
Sandheden om vores projekt ændrer sig dag for dag, og du har brug for en måde at foretage justeringer og derefter kommunikere disse justeringer til dine interessenter for at holde forventningerne styret. Så spring ikke over projektplanlægning, det er værd at gøre rigtigt.
Sådan opretter du en projektplan
Nu dykker vi ned i processen med at oprette en projektplan. Lad os antage, at vi har fået en projektbeskrivelse, der i det mindste begynder at besvare nogle af de store spørgsmål om projektet: vi har en forståelse af rationalet for, at projektet eksisterer i første omgang, og vi tror, vi ved, hvad vi skal levere. Så nu skal vi begynde at udarbejde, hvordan vi vil gøre det, og hvornår vi kan gøre det.
Vi starter med at arbejde på en løs projektplanskitse, så vi kan begynde at få en idé om, hvordan alting passer sammen. Hvad vi prøver at gøre, er at definere arbejdsprocessen. Arbejdsprocessen bestemmer de opgaver, der passer ind i den overordnede projektproces og struktur. Dette handler om at udarbejde processen for, hvordan vi vil levere projektet – de ting, vi skal gøre, for at få tingene til at ske.
Normalt vil vi have en slags organisatorisk proces, som vi skal overholde i strukturen af din arbejdsproces, der definerer, hvilken fase der går forud eller følger den næste. Hvis ikke, så tag lidt inspiration fra, hvad vi dækkede i vores indlæg om projektmetoder og projektlivscyklusser, og udarbejd arbejdsprocessen med dit team.
Når den overordnede arbejdsproces og faserne af arbejdet er defineret, kan du begynde at lave en grov plan. Formålet med den grove plan er at sætte en streg i sandet og give dig selv og dit team noget at give feedback på.
Gå tilbage til projektbeskrivelsen og tænk over de endelige leverancer for projektet. Arbejd tilbage fra leverancerne, og find ud af de forskellige aktiviteter, der skal ske for at levere dem.
Skitser den overordnede flow af dit projekt fra initiering til afslutning, arbejde i en eller to ugers intervaller. Tilføj derefter vigtige datoer, som du skal overveje, såsom kickoff-møder og den krævede live-dato. Sørg derefter for at kortlægge hver projektfase og de overordnede aktiviteter og opgaver, der kræves i hver fase for at fuldføre projektet.
På dette tidspunkt tænker du ikke på de faktiske opgaver, men hvordan opgaverne kan grupperes sammen og delmængder af arbejde inden for hver fase. For eksempel, inden for ‘Planlægnings’-fasen kan der være en kundeoplevelses-underfase, der inkluderer yderligere underfaser for udvikling af informationsarkitektur og wireframe-design.
Gør denne skitse stor. Det er nyttigt at starte på et whiteboard, så du tvinger dig selv til at holde dig ude af detaljerne. Det gør det også lettere at dele med dit team og få deres mening. Hvis du kan få arbejdsprocessen på plads, gør det det meget lettere at tilføje specifikke opgaver, milepæle og afhængigheder bagefter.
Når du har defineret arbejdsprocessen inden for hver fase, kan du begynde at tænke på at tilføje specifikke opgaver. Men ved at sikre, at du begynder med at definere arbejdsprocessen, sikrer du, at du producerer en projektplan, der er i overensstemmelse med din virksomheds proces og indeholder alle trin, der er nødvendige for at kunne levere dit projekt med succes.
Husk, at vores projektplan har forskellige målgrupper. Den er til dig, men husk, det er også et kommunikationsværktøj for vores team og vores interessenter. Vi ønsker at producere en projektplan, der er brugbar, så tænk over, hvem der skal bruge og forstå din plan. Sørg for at strukturere arbejdsprocessen og projektet på en måde, som enhver involveret i dit projekt forstår og er enig i. Hvis ikke, kan du ende med at skulle omstrukturere din projektplan og smertefuldt genlinke opgaver og afhængigheder.
Etabler din planlægningshorisont
Når arbejdsprocessen er defineret, begynder opgaven med at samle detaljerne i projektplanen. Når du opretter projektplanen, skal du spørge dig selv – ‘Er jeg realistisk? – er dette virkelig den bedste version af sandheden?’ Eller kører jeg bare på frihjul her?
Før du dykker ned i detaljerne, er det vigtigt, at du foretager en ærlig vurdering af projektet. Du skal finde ud af, hvor langt du realistisk set kan planlægge fremad. At planlægge længere end det er ren gætteværk, der kun vil skabe en verden af smerte senere. Planlægningshorisonten er din grænse for forudsigelig og nøjagtig projektplanlægning – det er, hvor langt frem du tydeligt kan se.
Præcis hvor langt frem du kan se, og længden af planlægningshorisonten, dikteres normalt af graden af ekstern usikkerhed og overordnet projektkompleksitet. Jo højere usikkerheden eller uforudsigeligheden er, jo tættere vil din planlægningshorisont være. Du kan se og dermed planlægge alt op til eller før en planlægningshorisont. Men alt derudover er gætteværk.
Der er masser af usikkerhed, hvor du ikke kan se eller vide, hvad der er der, så planlægningsdetaljer i projekter ud over det er farlige. På større projekter er det højst usandsynligt, at du vil være i stand til at planlægge hele projektet i detaljer med nogen forventning om nøjagtighed.
Både interne og eksterne projektafhængigheder skaber usikkerhed. For eksempel, indtil en indholdsstrategi eller informationsarkitektur er godkendt af en kunde eller sponsor, er det meget svært at vide, hvor meget tid der vil være nødvendig til wireframes, design, indholdsudvikling eller bygning, fordi du ikke ved, hvor mange skabeloner der vil være nødvendige eller hvor stort webstedet vil være.
Så hvad gør du? Planlæg i detaljer kun for det, du ved i den fase, du er i, og giv generøse tillæg for resten af projektet. I vores eksempel ovenfor – uden den definerede informationsarkitektur kan vi ikke vide, hvor mange skabeloner vi vil have brug for.
Men du kan lave et godt gæt (enten baseret på erfaring eller samtaler, du har haft med dine interessenter) på, at det ikke vil kræve mere end, lad os sige, 10 skabeloner. Du tager så det tal og arbejder ud fra det, og sørger for, at du inkluderer det som en antagelse i din omfangserklæring eller arbejdsopgørelse, der erklærer, at vi har baseret alt på maksimalt 10 skabeloner.
Som projektledere elsker vi at have alt pakket ind, pænt i en kasse – og det er sådan, vores klienter og sponsorer også kan lide det. Det kan være fristende at forsøge at planlægge hele projektet i mindste detalje, så det er gjort.
Men med ethvert projekt, så snart du starter det, vil planen uundgåeligt kræve ændringer, da interessenter ikke leverer materialer i tide eller godkender ting. Du ender med projektforsinkelser, tilføjelser af omfang, budget- eller tidsplansændringer, der kan kræve betydelige ændringer af projektplanen nedstrøms.
Så for at undgå at spilde tid på fantasifuld planlægning og vildlede magthaverne til at tro, at du har en slags speciel projektplanlægningskrystalkugle, der kan forudsige fremtiden. Du er bedre stillet ved bare at planlægge i detaljer, så langt som du tydeligt kan se.
Vi skal blive komfortable med at sige, ‘Vi ved det ikke…’ Som projektledere er det ofte fristende at fortælle vores klienter og sponsorer, hvad de vil høre. Det er faktisk rigtig nemt at give gode nyheder – at fortælle dem, at de ønskede tidsrammer vil passe perfekt til projektet.
På kort sigt kan det være en god løsning: vores interessenter får den bekræftelse og forsikring, de leder efter, og du, som projektleder, stopper med at blive generet. Og i et stykke tid kan alt dette være godt. Men så snart et projekt går af sporet, er det for sent at trække sig tilbage på din lovede leveringsdato, og du har pludselig skabt en masse pres for dig selv og dit team. Det er et kortsigtet væddemål, der sjældent betaler sig!
Lektien er denne – hvis du ikke kan bekræfte din fulde projekttidslinje, og din planlægningshorisont ikke tillader dig at give en endelig leveringsdato – så lad være med at gøre det.
Hvis der er for mange risici, ukendte eller eksterne afhængigheder, skal du fortælle din klient eller sponsor, at du ikke kan bekræfte den præcise tidslinje, men at du kan give et overslagsinterval baseret på dine antagelser og projektets nuværende fremdrift.
Bryd det ned
Når du er klar over den overordnede projektarbejdsproces og grænserne for din planlægningshorisont, er det tid til at forvandle den højniveau projektplanlægningsskitse til noget mere detaljeret. Den gamle talemåde “Hvordan spiser man en elefant? En bid ad gangen” gælder også her.
Når du forsøger at estimere, hvor lang tid en fase af et projekt vil tage, er det vigtigt at opdele opgaverne i delopgaver, ideelt set ikke mere end et par dage hver. Ved at opdele projektet i delopgaver vil du opdage, at ikke kun er estimering lettere, men det er også meget mere nøjagtigt. Mindre opgaver er lettere at kvantificere og sammenligne, når man estimerer mod lignende opgaver.
Oprettelse af delopgaver gør det også meget lettere for dit team at estimere mod: estimering af en lille, klart defineret opgave er meget lettere end en stor og vag opgave.
Som en bonus gør det at tilføje et detaljeringsniveau til vores opgaver det meget lettere for vores interessenter at forstå processen og gør det muligt for os at spore vores projektfremskridt meget mere præcist.
Processen med at bryde det ned hjælper dig ofte med at finde huller i din arbejdsproces og identificere afhængigheder. Processen med at nedbryde projektet kan føles besværlig, men det hjælper dig med fuldt ud at fordøje og tænke igennem præcis, hvad du forsøger at bede dit team om at gøre.
At gennemgå den fornødne omhu med opgaveopdeling – eller nedbrydning af arbejdet – forbereder dig til at dele projektplanen med teamet og giver dig tilliden til at sætte en pæl i jorden, når du arbejder gennem estimater med dit team.
Spørg, gæt ikke
Nu har du en udkast til projektplan, du skal begynde at tilføje nogle detaljer. Vi skal sikre os, at processen vil fungere, at afhængighederne er korrekte, og at opgaverne er estimeret. For at gøre det skal du begynde at samarbejde med dit team.
At skabe gode projektplaner er en slags mørk kunst. Dybest set forudsiger du fremtiden. Men ideelt set gætter du ikke bare – du baserer disse forudsigelser på noget – tidligere projekter, tidligere præstationer, hvad du ved om teknologien, og hvad du ved om projektet og den klient eller afdeling, du arbejder med.
Det kan ofte fremskynde projektplanlægningsprocessen og være nyttigt for dig selv og dit team, hvis du selv tager en første omgang på projektplanen. Det kan være en stråmand for folk at reagere på, men det kan også hjælpe dig med at få en idé om, hvordan det hele kunne passe sammen.
Du skal lave nogle kvalificerede gæt på opgaver, varigheder og afhængigheder. Men ved at give teamet noget at arbejde ud fra i stedet for at starte fra ingenting kan du komme forbi den indledende lammelse af et tomt lærred. Giv dit team konteksten, en grov plan at starte med, og forklar dem, hvordan du kom dertil. Fortæl dem, hvad du baserede det på, og lidt om din tilgang.
Hjælp dem med at samarbejde om at gennemgå planen ved at gå linje for linje gennem din plan. Hjælp dem med at forstå, hvorfor du har planlagt det ud på den måde, du har gjort. Del antagelser, afhængigheder og find ud af, hvem der kan gøre hvad, hvornår. Dette er begyndelsen på at optimere dit projekts kritiske sti – den centrale sekvens af vitale projektaktiviteter, der forbinder starten af projektet til slutningen.
Det kan være fristende hurtigt at nippe rundt og tale med de forskellige mennesker, du har brug for, og få estimater fra hver af dem. Udfordringen er, at du ved at gøre det ikke effektivt fanger afhængighederne mellem hver disciplin. Det kan være, at en afdeling utilsigtet antager noget om en anden – for eksempel antager kreative team, at ingeniørteamet kan finde ud af mobilversionerne.
Eller det kan være, at de har glemt noget helt, og at de ved at diskutere det med hinanden pludselig husker elementer, de burde have inkluderet. Udnyt kraften i teamplanlægning. Få alle sammen i et rum og gennemgå projektplanen linje for linje sammen, så alle afhængigheder og eventuelle effektiviseringsmuligheder for potentielle parallelle arbejdsstrømme kan fanges.
Gør mødet mere afslappet ved at gøre det til en kreativ øvelse – en dramatisering af, hvordan projektet kunne gå. Når du har valideret med teamet, er det altid nyttigt at forsøge at validere planen og få en anden mening. Du vil opdage, at når du gennemgår planen med andre, vil effektiviseringer eller yderligere elementer også blive afsløret.
Folk har en tendens til at være lidt glemsomme. Så efter at alle har haft chancen for at veje ind på projektplanen, send dem en kopi af dit udkast. Du vil blive overrasket over, hvor ofte de vil ændre mening eller lægge mærke til noget, når de ser det på skrift. Bekvemt fungerer det også som en smart lille forsikring for dig.
Nogle gange vil dit team dog sige, ‘beklager, jeg kan ikke fortælle dig, hvor lang tid denne aktivitet vil tage, fordi jeg ikke ved X, Y eller Z.’ Når ingen ved, hvor lang tid noget kan tage, fordi de aldrig har gjort det før, skal du forsøge at basere det på noget.
Så prøv at finde eksempler fra deres eget arbejde, som du mener udgør fundamentet for, hvad der skal gøres, og hjælp dem med at arbejde op fra det. Byg din projekttidslinje først omkring de dele, de kender, og udvid derefter ud over det, og sørg for, at du kraftigt caveater det i dine antagelser og afhængigheder.
Og husk igen – planlæg ikke ud over din planlægningshorisont!
Når du er under pres for at producere en projektplan, er den nemmeste ting at gøre bare at gætte, hvor lang tid hver opgave kan tage at fuldføre, og lade det blive ved det. Det er en mulighed, men ikke en særlig klog en.
At gætte vil ikke kun give dig en dårlig projektplan, det vil give dig ingen grundlag for dine diskussioner med din klient eller projektsponsor, og der vil ikke være nogen anden at dele skylden med, hvis du gætter forkert. Så sørg for, at denne projektplanlægning er en gruppeaktivitet!
Spørg, når du spørger
Når du gennemgår projektplanen med teamet, skal vi stille mange spørgsmål. Vi skal blive ved med at spørge ‘hvorfor’ og ‘hvordan’ for at hjælpe teamet med at tænke igennem deres tilgang, identificere eventuelle effektiviseringsmuligheder og sikre, at du forstår, hvad der er inkluderet. At stille gode spørgsmål er sandsynligvis en af de vigtigste og mest kraftfulde projektledelsesevner.
Francis Bacon siger “Et fornuftigt spørgsmål er halvdelen af visdom.” – bare at vide, hvad man skal spørge sit team, vil gøre os meget bedre til at skabe projektplaner.
Når vi taler med vores team om projektplanen, skal vi gøre mere end blot at bede dem om at estimere, hvor lang tid noget vil tage. Vi skal hjælpe dem med at forstå konteksten omkring deres estimat. Så når de giver dig et tidsestimat, skal du begynde at grave i, hvordan de kom til det tal.
Du vil ofte opdage, at når du begynder at lokke detaljerne ud af deres estimat, vil de huske ting, de glemte at inkludere, og du vil begynde at få en forståelse af dybden og afhængighederne omkring individuelle opgaver.
Så hvordan stiller du de rigtige spørgsmål?
En effektiv tilgang er at bruge en kombination af både åbne og lukkede spørgsmål. Åbne spørgsmål er vigtige, fordi de fører til mere end et et-ords svar, de giver bredde og har tendens til at starte med, Hvad? Hvornår? Hvor? Hvordan? eller Hvilken? Disse er gode spørgsmål at bruge til at få en forståelse af det store billede, da de giver dig detaljerede og bedre kvalitetsinformationer og hjælper dem med at krystallisere deres tanker.
Lukkede spørgsmål er også vigtige – de sikrer et meget klart og snævert fokus og giver normalt et et-ords svar. De begynder normalt med: Kunne? Skulle? Ville? Har du? Gør du? Disse spørgsmål er vigtige, når du afklarer fakta, et punkt eller måske nogle tal.
Men lige så vigtigt som det er at stille de rigtige spørgsmål, skal du også være opmærksom på at undgå at stille de forkerte spørgsmål. Undgå at stille ledende spørgsmål, hvor du antyder et svar eller en løsning, ‘i’ spørgsmålet eller ladede spørgsmål, der er politiserede eller ubeantagelige. Husk at holde det enkelt, og undgå at stille flere spørgsmål eller sammenkædede spørgsmål på én gang – bare spørg om én ting ad gangen.
Og prøv at undgå “Hvorfor” spørgsmål, da de kan lyde kritiske. Du kan stadig få lignende svar på det spørgsmål ved at vælge en anden måde at stille et spørgsmål på. For eksempel: ‘fortæl mig mere om…’, eller ‘hvad tror du er årsagerne til…’
Når du har stillet dit spørgsmål, skal du sørge for at spille de svar, du får, tilbage for at sikre, at du har forstået dem ordentligt. Husk, du skal forstå hver opgave i din projektplan, dens varighed og dens afhængigheder. Vi skal sikre, at vi ved, når vi bliver spurgt, hvorfor alle elementerne i projekttidslinjen er estimeret, som de er – hvad de inkluderer, og hvad de ikke inkluderer.
Tillad tid til ændringer og rettelser
En ting, der ofte bliver glemt i oprettelsen af projektplaner, er at tillade tid til gennemgang og ændringscyklusser. Ændringer eller ændringer af et projekt er uundgåelige. Men hvis der er for mange, vil de også meget sandsynligt lamme et projekt, forlænge projektets tidslinje, bruge yderligere budget og potentielt påvirke den overordnede kvalitet af projektet.
En ting, der ofte kan blive glemt, er at tillade tid til interne ændringer. Det er nogle gange de interne ændringer, der kræver mest tid. I stedet for at liste disse som linjeposter på din projektplan, kan det nogle gange hjælpe at bage dette ind i opgaveudviklingstiden. Ikke kun er det en del af din interne proces, men det er svært at forklare din klient eller sponsor, hvorfor de skal vente eller betale for, at dit team ikke får det rigtigt første gang!
Og selvfølgelig skal vi tillade ændringer fra din klient eller sponsor eller enhver interessent, der vil godkende projektleverancer. Generelt kan godkendere lide at sætte deres præg på et projekt – så uanset hvor tæt du tror, du er på linje med godkenderne på dit projekt, skal du tillade noget tid til et par runder med revisioner og ændringer.
Når du har samlet din idé om, hvor meget tid der skal tillades til anmeldelser og ændringer, skal du sikre dig, at du har opbakning fra hele teamet! Det er essentielt, at alle ved, hvor meget tid og budget der er til at foretage ændringer.
Planlæg, at det ikke går efter planen
Det er simpelthen ikke godt nok kun at planlægge for det bedst mulige scenarie. Lige så meget som vi har brug for en Plan A, har vi også brug for at bage en Plan B og Plan C, hvis vi kan. At skabe en projektplan, der giver fleksibilitet til at afbøde mod uforudsete ændringer, er afgørende for projektets succes.
At træde linjen mellem optimisme og pragmatisme kan være en svær en, når man skaber projektplaner. At være optimistisk er rart, det er sjovt, det er afslappet. Men det er også en meget hurtig måde at forkorte projektets fiasko på. Du skal være realistisk og forudse, at uanset hvor god en projektleder du måtte være, går projekter ikke efter planen.
Tingene tager altid længere tid, end de burde. Tingene kommer til at gå galt, folk bliver syge, du får ikke de ressourcer, du har brug for, når du har brug for dem, vokale interessenter kan ikke lide designet, din klient eller sponsor ændrer omfanget, og udviklerne vil kæmpe i evigheder for at få ældre teknologiske stakke til at fungere ordentligt.
Det er værd at sætte sig ned med teamet i begyndelsen af projektet og udforske med dem de dele af projektet, der gør dem nervøse. Der vil altid være noget, der gør folk en smule utilpasse.
Det kan være, at der er en ny version af content management-systemet, et nyt prototypingværktøj, eller endda bare at nogen ikke har den software, de har brug for. Uanset hvad de potentielle faldgruber og risici kunne være, skal du sørge for, at du kender hver enkelt af dem, så du kan tage højde for dem.
Så hvordan håndterer du aktivt og afbøder risiko inden for din projekttidslinje? Nøglen er at smide din optimisme til side og tænke på de værst tænkelige scenarier. Du skal spørge dig selv ‘Hvad ville der ske, hvis…’ og udvikle en middel af vejen-tidslinje baseret på disse scenarier.
Der er kendte ukendte, som vi kan forsøge at planlægge. Men at håndtere ukendte ukendte er meget sværere. Der er en stor sandsynlighed for, at noget vil dukke op i projektet, som du ikke havde forventet (uanset om det er din skyld eller ej).
Så den eneste måde at afbøde denne type risiko på er at planlægge for det på den eneste måde, du kan: tilføj en ekstra buffer til din projekttidslinje og forklar din klient eller sponsor, hvad den er til.
Kryds målstregen godt
At afslutte projekter ordentligt kan også være en sv
ær forretning. I vores plan skal vi gøre Implementeringsfasen detaljeret. Vi skal give rigelig tid til de afsluttende faser af dit projekt, mens vi indlæser indhold, udfører QA, tester med vores kunder og sponsorer, tester med brugere, får godkendelser og implementerer vores løsning.
Du ville håbe, at de afsluttende faser af et projekt kunne være ligetil, men i virkeligheden er de langt fra det. Slutningen af et projekt samler alle mulige afhængigheder – nogle af dem måske ikke har været arbejdet på i måneder – for at fuldføre projektet.
De slags ting, der bliver overset i de afsluttende faser, er normalt de ting, der har mange afhængigheder, så de ikke kan handles tidligere. Indhold, SEO, servere, hosting, database migrationer, DNS-konfiguration og tredjepartsintegrationer skal alle indarbejdes i tidslinjen med de specifikke afhængigheder defineret, så der ikke er nogen forsinkelser i den sidste fase af projektet.
En del af at afslutte godt er at sikre, at vores produkt er blevet testet grundigt og afkrydser alle felter. Det betyder, at vi skal afsætte tid til at sikre, at testteamet har rigelig tid til ordentligt at validere, hvad vi end bygger. Bare fordi vi bare bekræfter, at alt fungerer, betyder det ikke, at det ikke tager meget tid!
For at teste ordentligt, sørg for at indregne tid i din plan for, at dit testteam kan opbygge testcases, udføre iterativ test og lave en fuld end-to-end test inden lanceringen. Når et projekt har bestået intern test, vil der også være behov for at få den endelige godkendelse af projektets leverancer. Det er altid nyttigt, hvis du kan bygge tid ind til en intern godkendelsescyklus, så du kan få grønt lys fra alle interne afdelinger om, at projektet er godkendt til levering til klienten eller sponsoren.
Men der er næsten altid problemer med godkendelser. Den formelle godkendelse fra din klient eller sponsor kan ofte være den længste, da der normalt er en større pulje af interessenter, der gerne vil konsulteres og nu har mulighed for at give feedback. Af en eller anden grund har interessenter tendens til at føle sig ‘dårlige’, hvis de ikke forsøger at ændre noget. Så sørg for ikke kun at inkludere ekstra tid til godkendelser, men også yderligere tid til ændringscyklusser.
Og sørg for, at du definerer din implementeringsstrategi. At gå live er sjældent en simpel switch. Husk at fuldt definere implementeringsstrategien og definere de trin, der kræves for implementering fra det lokale miljø, gennem staging, UAT, produktion og endelig trinene til at gå live. Sørg for, at du indregner tilstrækkelig tid til at migrere databaser, koordinere ændringerne til DNS-posterne og lade server-side caches rydde eller indlæse.
Og hvad end du gør, sørg for, at planen om at gå live ikke er på en fredag eller før en offentlig ferie. Det vil sandsynligvis ikke gå helt efter planen, så det er bedst, hvis du og teamet ikke skal fikse ting på din fridag.
Gennemgang efter projektet
At gå live er ikke slutningen på projektet. Vi skal også planlægge for den post-projektfase i vores projektplaner. Byg ind i projektplanen en fase for post-live test og analyse for at måle ydeevne, lave eventuelle optimeringer og tage noter af alle læringer.
En af de mest oversete dele af et projekt er, hvad der sker, efter det er gået live. I euforien og spændingen ved at levere et projekt bliver planlægningen af den effektive afslutning af et projekt ofte glemt.
Selvom et projekt er live, er det ikke overstået. Faktisk bør slutningen af et projekt virkelig signalere begyndelsen på det næste. Efter go-live, sørg for, at der er en ekstra post-live fase af Quality Assurance (QA).
Hvis du ikke tager højde for dette på forhånd, vil dine interessenter ikke kun blive overraskede, når alt ikke fungerer perfekt, men du vil opdage, at dine ressourcer allerede er blevet omfordelt til et andet projekt, og det kan være svært at få dem tilbage! Så inkluder i din plan noget planlagt røgtest efter projektet er gået live og yderligere ressourcer til at rette de irriterende bugs, der kun nogensinde dukker op i et live miljø.
Det kan være fristende at afslutte din projektplan med en bekvem milepæl mærket Live. Det føles godt. Problemet med at gøre det er, at det ikke rigtig er nøjagtigt. Der vil altid være post-live aktiviteter, der skal tages højde for og planlægges ordentligt. I stedet for at blive fanget uforberedt med den uundgåelige periode med reaktive post-live hot-fixes, prøv at være lidt mere strategisk.
Planlæg en kodefrysning og byg ind i projektplanen en fase for test og analyse for at måle, hvordan projektet præsterer mod KPI’erne. Denne fase vil gøre det muligt for dig og dine interessenter at fastslå, i hvilket omfang projektet får resultater.
Planlæg tid til arbejdssessioner med interessenter, brugertests, fokusgrupper og anmeldelser af analyserne for at identificere eventuelle problemer og udforske muligheder for at optimere projektets indvirkning. Når du er klar over problemerne og mulighederne, skitsér opdateringerne og opret en køreplan for opdateringerne, og opret en ny projektplan for at planlægge implementeringen.
Det er dog vigtigt at være klar over, hvor et projekt slutter, og hvor det næste begynder. Omfangserklæringen eller arbejdsopgørelsesdokumentet skal klart definere, hvornår et projekt er afsluttet.
Milepæle i projekter
Vi har nu dækket de grundlæggende elementer i at skabe en projektplan, og nu skal vi tænke på, hvordan vi repræsenterer de vigtige datoer inden for vores projekt. En af de enkleste måder at opnå dette på er at definere dine deadlines og afskæringsdatoer, der sikrer, at dit projekt forbliver på sporet og tydeligt angive dem i din projektplan.
For interessenter, der har svært ved at læse Gantt-diagrammer, kan du endda beslutte at give en sammenfatning i tabelformat for at hjælpe dem med at forstå projektets flow og de vigtige datoer inden for projektet.
Alright, det er klart, at når vi bygger en projektplan, er der mange ting, vi skal tænke på, og en tjekliste er en god måde at sikre, at vi dækker alle baser for at lave projektplaner, der virker.
Definér din arbejdsproces, fastlæg din planlægningshorisont, nedbryd opgaverne, samarbejd med dit team om tilgangen og estimaterne. Stil masser af spørgsmål, tillad tid til ændringer og planlæg, at det ikke går efter planen.
Endelig, husk at planlægge at afslutte projektet godt og tillad tid til gennemgang og optimeringer efter projektet.
Opsummering
Vi har lige dykket dybt ned i, hvordan man skaber projekttidslinjer. Du har nu et sæt vigtige principper for projektplanlægning generelt og hvordan man argumenterer for at lægge indsatsen i stedet for at improvisere.
Du bør nu være i stand til at nærme dig processen med at bygge en projekttidslinje med selvtillid, hvad enten det er en grov skitse, et detaljeret Gantt-diagram eller en sprint-for-sprint opdeling. Du har nu din egen projektplanlægningscheckliste, så du ved præcis, hvad du skal gøre for at få projektplanen i orden.
Og du bør nu have nogle strategier for at navigere i planlægningshorisonten og tage højde for ukendte faktorer i dine projekttidspunkter.
