I dette indlæg skal vi kigge på en række af de mest populære projektmetoder. Der mange metoder at vælge i mellem, men i dette indlæg kigger vi kun på de fire mest populære, nemlig:
- Vandfald
- Agile
- Scrum
- Kanban
Vi skal se på hvad de er, hvorfor de er vigtige, og hvad de er bedst egnet til.
Hvis du allerede er bekendt med projektmetoderne, vil dette være en god måde at genopfriske styrker og svagheder ved de forskellige projektmetoder.
Og hvis du har hørt disse udtryk før, men ikke er helt sikre på, hvad de indebærer, bliver dette en god introduktion til at vælge den rette metode til jeres projekter.
Projektmetoder kan lyde komplicerede, men det er egentlig bare en måde at beskrive forskellige måder at arbejde på.
Grundlæggende er projektmetoder de rammer og filosofier, der kan bruges til, hvordan du leverer projekter.
Det er vigtigt at vide dette, primært så du kan være på samme side som dit team og dine interessenter i forhold til den bedste måde at arbejde sammen på.
Der er mange tilgange til at styre og levere projekter og masser af forskellige metoder, du kan bruge og anvende.
Ikke alle vil fungere for dig, men forståelsen af nogle af dem vil helt sikkert hjælpe dig med at skabe en god proces for dine projekter, dit team og dine interessenter.
Valget af den rigtige projektledelsesmetode er vigtigt, fordi det definerer den måde, vi arbejder sammen på, se det gerne som din “arbejdsmetode”.
En metode kan indeholde en hvilken som helst blanding af temaer, principper, processer og standarder til at strukturere den måde, vi leverer projekter på.
Et tema er som en filosofi – altså det er en mindset for levering.
Når vi begynder at tilføje specifikationer til metoden med principper, processer og standarder, bliver disse metoder mere definerede og specifikke i forhold til at diktere præcis, hvordan du skal styre et projekt.
Nogle projektledelsesmetoder definerer kun temaer, som Lean-metoden.
Andre definerer kun et sæt principper, som Agile.
Nogle definerer en ‘full-stack’ metode med temaer, principper og processer, såsom PRINCE2, som står for Projects In Controlled Environments.
Nogle er et omfattende bibliotek af standarder med nogle anbefalede processer, som Project Management Institute’s Project Management Body of Knowledge (også kendt som PMBOK), eller Extreme Programming-metoden (også kendt som XP).
Og nogle er bevidst lette rammer, der kun definerer en håndfuld processer at følge, som Scrum.
Hvis alt dette lyder som volapyk, så er det okay – vi går mere i dybden med nogle eksempler nu her.
Lad os kigge på de tre primære metoder, som folk typisk bruger: Vandfald, Scrum og Kanban.
Vandfald
Vandfald er en simpel, forudsigelig tilgang, der har fokus på solid planlægning før projektet starter – Man har fokus på at lave planlægningen én gang og forudser derfor hvordan hele projektet skal forløbe.
Denne metode er nemt at forstå, fordi du laver en meget detaljeret plan og derefter udfører den. Så alle kan følge med, og ved præcis hvad der kommer.
Kravene defineres fuldstændigt i begyndelsen af projektet. Det er i konceptfasen, øverst i vandfaldet, før noget arbejde starter. Arbejdet flyder derefter – som vand ned ad et vandfald – gennem hver af de efterfølgende faser af projektet. Hver fase afsluttes, før den næste fase kan begynde.
En almindelig anvendelse af vandfaldsmetoden er i videoproduktion.
- Først udvikles et koncept til manuskripter og storyboards.
- Når manuskripter og storyboards er udviklet, kan filmingen begynde.
- Redigering kan starte, når de første stykker færdige optagelser kommer ind.
- Og så kan den første redigering gennemgås for at samle feedback og planlægge forbedringer eller genoptagelser.
Hvad der gør vandfald til et godt valg her, er, at der ofte er behov for at have forudsigelige datoer, og der er nogle hårde afhængigheder mellem nogle af aktiviteterne.
Men vandfaldsprojekter har den svaghed, at det ikke er nemt at justere ind undervej i projektet:
- En plan laves og derefter udføres den plan. Dette betyder, at der ikke er mulighed for at revidere og tilpasse sig, når du er midtvejs i projektet.
- Når du er i deploy-fasen, er det svært at gå tilbage og ændre noget, der ikke var designet helt rigtigt tidligere i processen.
Der er heller ikke nødvendigvis noget færdigt at vise interessenter, mens du arbejder på projektet.
Når du leverer det endelige produkt, skal du derfor håbe, at de beslutningstagere kan lide det.
Det er potentielt meget risikabelt og antager, at du har fanget alle kravene korrekt i begyndelsen af projektet.
Tilbage til vores eksempel med videoproduktion: når optagelserne er afsluttet, er det ikke let at foretage ændringer andet end gennem yderligere redigering.
For det meste vil en ændring udløse genoptagelser, hvor du skal samle alle igen for at få de nødvendige optagelser.
Derfor er det så vigtigt at sikre, at alle er klar over, hvad det betyder, når manuskriptet, storyboards og optagelseslisten er låst.
Når det er sagt, kan vandfald være en nyttig og forudsigelig tilgang, hvis kravene er faste, velbeskrevne og klare.
Det er en god tilgang at bruge, hvis teknologien er velkendt og moden. I en sådan type miljø kan en vandfaldsmetode give et mere forudsigeligt slutresultat i forhold til budget, tidsplan og omfang.
Agile
Nu skal vi kigge på alles favorit buzzword inden for projektledelse, nemlig agile.
Sandheden er, at agile ikke er en metode, men et sæt principper der oprindeligt er fremsat for udvikling af software.
Principperne beskriver fire værdier:
- Individuelle personer og interaktioner over processer og værktøjer;
- Fungerende software over omfattende dokumentation;
- Kundesamarbejde over kontraktforhandling;
- Reagerer på ændringer over at følge en plan.
Faktisk er det at være agile mere en filosofi og en tankegang end en proces, vi kan anvende direkte på et projekt.
Så når folk siger ‘jeg tror, vi skal køre dette projekt agile’, er et godt opfølgende spørgsmål altid ‘hvad mener du præcist med det?’
Agile er et sæt principper, ikke en proces, og du kan tilpasse dig disse principper på mange forskellige måder!
Men typisk, når folk taler om en agile projektledelsesmetode, beskriver de normalt en adaptiv og iterativ design- og byggeproces.
Det agile team skifter ofte gennem flere komprimerede versioner af vandfaldsprocessen: de tager et lille stykke funktionalitet og samarbejder om at definere det, planlægge det, bygge det og implementere det, så de kan evaluere og korrigere kursen undervejs.
Dette betyder, at et agile team kan bygge, implementere og evaluere noget, før de beslutter sig for, hvad der skal bygges næste gang.
Agile projekter udføres og tilpasses efter behov. Dette betyder, at i stedet for at følge en forud planlagt proces som vandfald, kan en agile tilgang lettere tilpasse sig uforudsigeligheden der er i projektet. Du kan hurtigt og ofte dreje da det er en iterativ proces, der er meget fleksibel.
Agile metoder er gode at bruge i mere dynamiske sammenhænge, hvor der potentielt er hurtigt skiftende krav – og hvor budgettet og tidsplanen kan være fleksible for at matche.
Så ja, kort sagt er Agile ikke en metode du kan bruge, men en filosofi du kan bruge, og en paraply der dækker over en række metoder der bruger de agile principper.
De mest populære agile metoder er uden tvivl Scrum og Kanban, så dem vil jeg tage et hurtigt kig på nedenfor.
Scrum
Scrum er en mere proces-drevet agil metode. Scrum er klart den mest udbredte agile metode, og bruges i mere end 80% af agile projekter.
Men lad os kigge på Scrum metoden, fordi det sandsynligvis er den bedst definerede, mest almindelige og også sandsynligvis mest hyppigt tilpassede agile metode. Det er også relativt ligetil at implementere for de fleste organisationer og teams.
Målet med Scrum er at forbedre kommunikation, teamwork og fremdriften i projektet.
Hvis du hører folk tale om sprint, daglige stand-ups, backlogs og burndown charts, taler de sandsynligvis om Scrum eller en form for tilpasning af det.
Så hvad er Scrum? Scrum er en simpel “undersøg og tilpas”-ramme, der definerer tre roller, tre ceremonier og tre artefakter, der hjælper teams med at levere fungerende slutprodukter i faste længder af sprint på 2 til 6 uger.
Men Scrum handler i bund og grund om at skabe et produkt, der potentielt kan leveres til kunden ved slutningen af hver sprint, eller hver 2-6 uger.
Det betyder, at sprintens output er et produktinkrement, der er grundigt testet og stabilt, velstruktureret, og veludført.
Det kan både være et stykke software som er klar til at blive brugt, men det kan også være dele af et projekt der er klar. Eksempelvis ved produktdesign kan det være at en knap er blevet udviklet, samt den funktion den skal udføre. Men at produktet som helhed kun er delvist færdig.
Pointen med Scrum er at undersøge, hvad der i øjeblikket er kendt om projektet, og derefter lave en plan for at forsøge at levere noget, der er komplet inden for en sprint.
Derefter kan teamet ved slutningen af sprinten tilpasse retningen og visionen for projektet efter behov for at maksimere forretningsværdien af projektet.
Dette giver teams mulighed for at føle at de kommer i mål med deres opgaver, og ser fremskridt i projektet, i modsætning til at intet i projektet føles færdigt før i slutningen af projektet.
Men processen med at undersøge og tilpasse giver også teams mulighed for at skifte retning, efterhånden som de lærer mere om det produkt, de bygger, og den værdi, det kan levere til kunden.
Lad os se på, hvordan Scrum kan se ud på et overordnet niveau. Processen begynder med en product backlog, som er den prioriterede ønskeliste over ting, der skal gøres, oprettet af en product owner, som repræsenterer kunden eller brugeren.
Disse backlog opgaver gennemgås derefter i et sprint-planlægningsmøde, hvor udviklingsteamet estimerer arbejdet og er enige med deres product owner om, hvilke elementer de tror kan afsluttes i den næste sprint.
Dette udvalg af opgaver går derefter ind i sprint-backlogen – listen over ting, teamet har forpligtet sig til at levere i den kommende sprint.
Derefter går vi ind i udviklingsfasen, eller sprinten, hvor arbejdet udføres for at skabe det leverbare inkrement eller produkt.
Hver dag under udviklingssprinten er der et daily stand-up-møde, hvor alle i teamet giver en opdatering.
Og ved slutningen af sprinten vurderes arbejdet i sprint-gennemgangsmødet, hvilket informerer om re-prioriteringen – eller “grooming” – af produktbacklogen, så cyklussen kan starte igen. Og det er kort fortalt Scrum.
For at forstå dette lidt mere detaljeret, lad os tage et hurtigt kig på roller, ceremonier og artefakter.
Der er tre roller i Scrum; product owner, Scrum-master og udviklingsteamet.
En product owner repræsenterer den værdi, der leveres til kunden. De planlægger funktioner og er ansvarlige for investeringsafkastet i projektet. De ejer produktbacklogen og er dem, der kan tage beslutninger om prioritering af opgaver.
På nogle måder ligner dette en projektlederrolle. Men hovedforskellen er, at product owner får lov til at træffe alle beslutninger. De kan prioritere og flytte ting rundt, som de vil!
Normalt kan vi som projektledere ikke det, fordi vi normalt ikke har beføjelse til det. Så tænk på product owner som en slags blanding mellem kunden eller sponsoren og projektlederen.
Den næste rolle er Scrum-masteren. Deres opgave er at eje Scrum-processen. Dette er rollen, der fjerner blokeringer for teamet, så de kan yde optimalt. Scrum-masteren er virkelig en facilitator. De hjælper product owner og udviklingsteamet med at gøre det bedste arbejde, de kan, og de forsøger at beskytte dem mod eksterne forstyrrelser.
Igen ligner dette lidt vores projektlederrolle, men vores rolle er typisk bredere end denne form for facilitering.
Og endelig er der udviklingsteamet. Udviklingsteamet er en selvorganiseret enhed. De forpligter sig til at levere funktioner eller opgaver fra backlogen til en product owner og er ansvarlige for produktets kvalitet.
Så det er vores tre roller – product owner, Scrum-masteren og udviklingsteamet.
Nu lad os dykke ned i de ceremonier, der kendetegner Scrum. De kaldes ceremonier, men de er egentlig bare møder!
Sprint-planlægningsmødet er et stort møde og det er et todelt møde. Det er her product owner og udviklingsteamet mødes for at gennemgå produktbacklogen.
Product owner præsenterer deres prioriterede produktbacklog-elementer, og som et team diskuterer de opgaverne for at få en fælles og detaljeret forståelse af, hvad der skal gøres.
Sammen diskuterer teamet, hvordan de bedst implementerer de vigtigste opgaver fra backlogen. Målet med denne ceremoni er at sikre, at alle er på samme side med, hvad der skal gøres, og er enige om tilgangen til at tackle specifikke problemer.
I den anden del af mødet, når teamet mener, at de har nok opgaver til at starte en sprint, begynder teamet at bryde historierne ned i opgaver for at fylde sprint-backlogen.
De bliver enige om, hvad de kan forpligte sig til at levere inden for sprinten. Ideen er at inkludere klynger af opgaver i sprinten, som – i kombination – vil skabe en slags leverbar værdi.
Vores anden ceremoni er den daglige Scrum, eller daglige stand-up. Det er et tidsbestemt møde på omkring 15 minutter, der hjælper med at give hele teamet et overblik over, hvad der foregår og eventuelle udfordringer eller blokeringer, der kan hindre fremskridt.
Til mødet giver hvert medlem i teamet en opdatering om, hvad de gjorde den foregående dag, deres plan for dagen forude og eventuelle blokeringer, de står overfor.
Mødet hjælper teamet med at forstå, hvordan deres arbejde bidrager til det større billede og giver dem mulighed for at løse eventuelle problemer så tidligt som muligt. Ofte bruger teamet et burndown-diagram til at gennemgå fremskridt mod planen.
Ved slutningen af hver sprint er der et sprint review, hvor alle samles for at gennemgå arbejdet udført i sprinten.
Målet med mødet er at gennemgå arbejdet, der er blevet udført med product owner. Teamet præsenterer og demonstrerer elementer fra sprint-backlogen, som de tror er leverbare, og product owner accepterer eller afviser funktioner baseret på, om de opfylder opgaven, acceptkriterierne og deres samlede forventninger. Teamet diskuterer derefter, hvordan de skal gå videre.
Så vores tre ceremonier er sprint-planlægning, den daglige Scrum og sprint-gennemgangen.
Når det kommer til artefakter, er der tre: produkt-backlogen, sprint-backlogen og sprint-burndown-diagrammet.
Produkt-backlogen er en kontinuerligt prioriteret liste over krav sorteret efter forretningsværdi. Produkt-backlogen sorteres af product owner med de mest værdifulde opgaver øverst og de mindst værdifulde nederst.
Ved altid at arbejde i prioriteret rækkefølge er teamet i stand til at maksimere værdien af det produkt, der udvikles. Det gør også at der fokuseres på at levere værdi tidligt i projektet, og at der hele tiden er fokus på at levere det som giver dem mest værdi.
Sprint-backlogen inkluderer de opgaver, som teamet har forpligtet sig til for den nuværende sprint. Så det er den totale liste af opgaver som de skal levere de næste 2-6 uger.
Her kan du se, hvordan en produkt- og sprint-backlog kan se ud. Øverst er den aktuelle sprint og nedenunder produkt-backlogen.
Lad os kigge på disse opgaver et øjeblik, da de repræsenterer den værdi, vi skaber i en sprint. Inden for Scrum hedder disse opgaver “user stories”.
En user story er et krav skrevet fra slutbrugerens perspektiv. Det følger en specifik struktur, der beskriver problemet i kontekst uden at beskrive løsningen.
Med hver user story inkluderer vi også acceptkriterier, der fortæller os, hvordan vi ved, om opgaven løser problemet korrekt.
Her er et eksempel på en user story: Som en <persona>, der udfører en handling i <kontekst>, ønsker jeg <nogle muligheder>, så jeg kan <forretningsværdi eller brugerens mål>.
Nedenunder dokumenterer vi acceptkriterierne: hvordan ved vi, om det der er lavet løser problemet ordentligt?
Det er en liste med krav til opgaven, som er så detaljeret, at man efterfølgende kan bruge dem til at teste op opgaven er fuldført.
Til sidst, lad os tale om det sidste artefakt vi kigger på i denne omgang – Sprint-burndown-diagrammet.
Det viser den resterende mængde arbejde, der er tilbage for at fuldføre det planlagte arbejde til slutningen af sprinten.
Dette er særligt nyttigt til at vurdere teamets fremskridt under en sprint og lade disse data informere ændringer i fremtidige sprints.
Burndown-diagrammet er et meget vigtigt værktøj til at holde teamet fokuseret, det gør det muligt hurtigt at se status for udviklingen og om teamet er på tidsplan med den estimerede plan.
Så det er kort fortalt Scrum, men der er meget mere i det end dette. Men vi kan ikke gennemgå det hele her. Hvis du vil vide mere, bør du kigge på vores Scrum kursus og certificering.
Kanban
En anden metode inden for Agile, der kan være en god metode til både bureauer og interne teams, er Kanban.
Kanban er egentlig en præsentationsmetode, der fokuserer på lean-principper om at maksimere værdistrømmen og øge effektiviteten.
Filosofisk set ligner den på mange måder Scrum – det handler om at producere værdi tidligt og ofte med et samarbejdende og selvstyrende team.
I Kanban kan du beslutte at have daglige stand-ups, en product-backlog og testmøder og retrospektive efter behov.
Så der er nogle ligheder. Men sammenlignet med Scrum er det en blødere indgang til den agile verden, da der er færre faste processer eller bestemte måder at gøre tingene på.
Kanban er let på processer – det er fleksibelt, det har ikke forudbestemte roller, og det forsøger simpelthen at forbedre gennemstrømningen ved at øge teamets fokus på de ting, der virkelig betyder noget.
Her kan du se et Kanban-board vist i hvad der sandsynligvis er det mest populære Kanban-værktøj, Trello:
Kanban-boardet er, hvad du kan bruge til visuelt at repræsentere teamets arbejdsgang, med kolonner, der repræsenterer hvert trin i processen.
Et Kanban-board kan have kolonner så simple som ‘To-do’, ‘Estimeret’, ‘In Progress’ og ‘Done’.
I stedet for at køre projektet i periodiske sprinter, er Kanban udviklet til produktionssektoren og er tænkt som en kontinuerlig proces. Elementer trækkes fra produkt-backlogen ind i processen, indtil de er færdige.
En interessant funktion ved Kanban er, at det definerer grænser for, hvor meget arbejde man som person kan arbejde på af gangen.
For eksempel kan du have sat en grænse på tre igangværende opgaver pr. teammedlem. Man kan også sætte denne begrænsning på andre kolonner, eksempelvis
Ideen med dette er, at det sikrer, at arbejdet bevæger sig hen over boardet på den kortest mulige tid uden distraktioner, der introducerer ineffektivitet.
Du kan se fra Kanban-board-eksemplet, hvordan denne proces gør det muligt for dig at visualisere arbejdsgangen og begrænse igangværende arbejde.
Det giver også teamet en visuel fremvisning af, hvad der kommer op næste gang, hvilket gør det lettere at prioritere tiden, det afslører problemer i processen og forhindre opgaver i at gå i stå.
Det hjælper også teamet (og nogle gange andre interessenter) med at se, hvordan enhver ny opgave, der tilføjes i backloggen, kan påvirke det igangværende arbejde.
Kanban er velegnet til arbejde, der kræver stabil output, som produktion eller support og vedligeholdelse.
Inden for bureauverdenen kan det også være et nyttigt værktøj til kunder, der er ubeslutsomme eller ofte ændrer mening.
Kanban er mere imødekommende over for ændringer: nye opgaver kan tilføjes når som helst – normalt på bekostning af en anden opgave, men med mere umiddelbarhed end at vente på, at opgaven planlægges ind i en fremtidig sprint.
Men Kanban fungerer ofte bedst i et miljø, hvor ethvert medlem af teamet kunne udføre enhver opgave i backlogen, hvilket måske ikke er tilfældet i hvert projektteam.
Men overordnet set, hvis Scrum virker for rigidt en tilgang, men du vil arbejde agilt, kan Kanban være et enklere alternativ.
Hvad skal du vælge?
Så vi har gennemgået 3 af de mest populære metoder, men hvordan vælger du en?
I sidste ende kommer det ned til behovene, prioriteterne og begrænsningerne i dit projekt – nemlig projektets kontekst.
Bredt sagt vil din beslutning sandsynligvis blive drevet af fem overvejelser: projektets natur, teamstørrelse og erfaringsniveau, det forventede niveau af kundens involvering, tidsplanen og budgettet.
Med hensyn til projektets natur skal du spørge dig selv: er projektet veldefineret og usandsynligt at ændre sig?
Eller vil det næsten helt sikkert ændre sig, efterhånden som projektet udfolder sig? Hvis det er det sidstnævnte, kan en adaptiv tilgang være mere passende.
Men hvis du driver et projekt i en stærkt reguleret branche, kan en fuldt adaptiv tilgang muligvis ikke hjælpe dig med at opfylde bestemte krav til en bestemt dato.
Overvej også teamets størrelse og erfaring: de lean-principper, der er indeholdt i mange agile metoder, er en god pasform til små, smidige teams. Men i stor skala begynder de at kræve særlige overvejelser og tilpasning.
Derudover, hvis du arbejder med et udviklingsteam, der kun har erfaring med én bestemt metode, skal du overveje, om det er det rigtige tidspunkt at introducere en helt ny metode for dem, eller om du muligvis skal bringe en coach ombord for at uddanne og guide teamet gennem projektet ved hjælp af en specifik metode.
Og ligeledes kan et lille team udelukkende med erfaring i Vandfald og ingen erfaring i agile måske producere bedre resultater ved at holde sig til, hvad de kender.
En anden vigtig overvejelse er graden af kundens involvering, du forventer. Mange agile metoder som Scrum er afhængige af kundens involvering.
Dette kan både være gennem rollen som product owner, der repræsenterer værdi for kunden, eller gennem kunderne selv, der kan give feedback til projektet gennem iterative brugertests.
Men hvis dine nøgleinteressenter foretrækker, at dit team bare tager sig af det og kun vil gøre sig tilgængelige på bestemte planlagte milepæle, kan du overveje at læne dig mod en mere forudsigelig tilgang som vandfald.
Naturligvis vil tidsplanen også være en overvejelse. Er din projektlancering bundet til en fast dato? Vil andre projekter blive blokeret fra at starte, indtil dit projekt rammer bestemte milepæle? Hvis ja, kan en mere forudsigelig tilgang som Vandfald være bedst.
Og selvfølgelig, den store en: budget. Og med ‘budget’ mener jeg ikke, at nogle metoder ender med at koste mere. Det handler mere om finansieringskrav og organisatorisk kultur.
Hvis projektet har et fast budget med en fastlagt omfang, kan det muligvis ikke være let at tilføje en ny idé til produkt-backlogen uden at springe gennem en masse processer i virksomheden for at få godkendt yderligere budget.
Men hvis projektets sponsorer er villige til at bruge lidt mere eller stole nok på dig til at levere den rigtige værdi, selvom det ikke er de specifikke leverancer, de oprindeligt bad om, kan en adaptiv tilgang fungere godt.
Men der er ikke én enkelt “bedste” projektledelsesmetode. At vælge den rigtige til dit projekt vil være et valg udfra disse faktorer samt andre variabler inden for og uden for din kontrol.
Nogle gange vil en organisation standardisere en metode, så du måske ikke engang har noget valg!
Men hvis det er din beslutning at træffe, er det vigtigste at starte med et velinformeret gæt og derefter få input fra andre.
Brug disse overvejelser til at drive samtaler med dit team, dine interessenter og den bredere organisation, du arbejder med, for at forstå, hvad der vil være bedst for dit projekt.
Vi kunne blive ved med at diskutere dette i timevis. Men lad os stoppe her.
Uanset om du vælger Scrum, Kanban, Vandfald eller en anden hybrid wagile, waterscrum, agilefall ting, eller noget du selv opfinder, er det ikke så vigtigt.
Det der betyder noget er en forpligtelse til at udføre kvalitetsarbejde, der opfylder brugerens behov og leverer stor værdi til dine interessenter.
Den bedste metode er en, der konstant forbedrer og tilpasser sig. Det er en tilgang, der inkluderer stærkt samarbejde i dit team og med din kunde eller projektets sponsor.
Husk gerne at have en pragmatisk tilgang til disse metoder. Det er fint at følge Scrum til punkt og prikke, men du må også meget gerne tilpasse den til din organisation, dit team eller til dine egne ønsker.
Det gør jeg nemlig også selv. Jeg tilpasser tit disse metoder til det projekt eller team jeg sidder med.
Husk også, at din organisation, dine interessenter og dine projekter er unikke for dig – der er ingen grund til at tage en andens projektledelsesmetode, forsøge at implementere den trin-for-trin og forvente de samme resultater. Det kan passe til deres behov, men ikke nødvendigvis dine.
Opsummering
Du bør nu have en overordnet forståelse af nogle nøgle projektledelsesmetoder – måden, vi tackler projekter på. Du har nu en forståelse af de nøglekarakteristika ved forudsigelige metoder som Vandfald såvel som agile tilgange som Scrum og Kanban. Og du bør vide, hvilke betingelser der er bedst for agile og forudsigelige projekter, og hvordan du argumenterer for at bruge den rigtige metode til det pågældende projekt og de involverede teams.
