Som regel når vi bliver undervist i projektledelse så taler man ikke så meget om, hvordan forskellige typer af projekter behøver forskellige metoder i forhold til projektledelse og udførelse. Det vil jeg forsøge at råde bod på her.
Jeg er – ud over egne erfaringer – blevet inspireret af Robert Wysocki’s bog “Effective Project Management“. Her gennemgår han tre forskellige projekttyper og tilsvarende projektmetoder: nemlig “traditionelle, adaptive og ekstreme” projekter. Det kalder jeg “type ud fra usikkerhed om mål og metode”.
Derudover er der naturligvis forskel på indholdet af projekter, som også kan / bør påvirke hvilken metode man bruger. Et IT-projekt hhv. et projekt hvor man afholder et firmaevent er måske begge “udviklingsprojekter”, og kan metodemæssigt have meget til fælles – men kræver stadig væsensforskellige måder at gribe tingene an på.
Type ud fra usikkerhed om mål og metode:
For et traditionelt projekt kan man opstille ret præcise mål, det man kalder “SMART’e” mål (dvs. Specifikke, Målbare, Attraktive & Allokerede (til een ansvarlig person), Realistiske og Tidsfastsatte mål).
Det kan man, fordi man har udført tilsvarende projekter før. Det kunne være at bygge et typehus – så ved man nogenlunde præcist, hvor lang tid det tager, hvad det koster, hvilke ressourcer og roller det kræver, osv. Man kender også udførelsesmetoden, den er velprøvet og udført mange gange før. Først graver man ud til fundamentet og lægger rør og gulv, så vægge og el, derefter tag, osv. Det betyder at man godt kan lægge ret præcise og lineære planer for udførelsen, så både mureren og elektrikeren ved, hvornår det er deres tur. Selvfølgelig kan der ske uforudsete hændelser: undergrunden kan drille, vejret kan drille, leverandøren svigter, osv. Og det må man så forsøge at tage højde for, enten ved at skubbe hele planen, eller ved at flytte rundt på aktiviteter, om muligt.
Men for udviklingsprojekter har man ofte ikke et særligt præcist mål, mere en vision. Her giver det ikke mening med en lineær plan – for hvis man ikke ved præcist hvad man vil opnå, kan man vanskeligt lægge en præcis plan for det? I andre udviklingsprojekter kender man godt målet, men ved ikke hvordan man vil komme hen til det. Her er der også et element af udvikling i projektet, der betyder, at man ikke kan lægge en præcis lineær plan for at nå i land. Man udvikler metoden undervejs for at se, hvordan man bedst opnår målet.
- Traditionelle projekter
- Projektets mål kan beskrives konkret, i “SMART’e” termer.
- Udførelsesmetoden er velafprøvet og velkendt.
- Projektmetode: Man kan derfor lægge traditionelle projektplaner med GANTT-diagrammer, arbejdspakker, osv. Se enhver traditionel projektledelsesbog for hvordan.
- Eksempler: Traditionelt typehus-byggeri. Installation af pc’er i kontorbygning.
- Adaptive projekter
- Projektets mål kan beskrives konkret, i “SMART’e” termer.
- Udførelsesmetoden er helt eller delvist ukendt, og skal derfor udvikles som en del af projektet.
- Projektmetode: Det er derfor mest fornuftigt at dele projektet op i nogle cykliske iterationer, hvor man undervejs fremfinder og afprøver metoden, og dermed kommer tættere og tættere på målet. Men da man kender målet, ved man godt hvor mange penge og ressourcer man vil ofre på projektet – og derfor kan / vil projektet godt på forhånd have en øvre smertegrænse, der definerer tid og ressourcer.
- Eksempler: Bygning af CO2-neutralt etagehus. Mange IT-udviklingsprojekter, hvor man arbejder videre med eksisterende systemer og ideer. Mange PhD-projekter.
- Ekstreme projekter
- Projektets mål kan ikke beskrives konkret, det er mere en vision, eller “vi ved det, når vi ser det”.
- Udførelsesmetoden er ukendt, og skal derfor udvikles som en del af projektet.
- Projektmetode: Man vil udføre projektet med én iteration ad gangen ad højst 2-4 uger. Hver iteration består af fire trin: Initiate, Speculate, Incubate, Review. Det kræver et tæt samarbejde med projektsponsor / ejer / bruger / kunde, så man hele tiden kan vurdere, om vi kommer tættere på visionen eller længere væk. Projektet kan lukkes efter hver cyklus, hvis det vurderes, at projektet ikke er bæredygtigt.
- Eksempler: Udvikling af ny teknologi på vej mod løsning af xx-problem.
Nogle gange vil det give mening at starte projektet op som et Ekstremt projekt, og når man så kender målet, og kan beskrive det præcist, skifte over til et Adaptivt projekt.
Type ud fra indhold:
Udover type på baggrund af usikkerhed om mål og metode, bør projektmetoden også vælges ud fra indholdet af projektet. Store IT-udviklingsprojekter er som udgangspunkt nødt til at være strukturerede og veldokumenterede, ligesom de pr. definition indeholder mange forskellige typer kompetencer og ressourcer, der skal lære at arbejde sammen. Mens for eksempelvis idéudvikling og Research & Development mange gange foregår i meget snævrere teams (hvis det da ikke bare foregår spontant og ad hoc undervejs i eksisterende produktionsprocesser, hvorfor man måske slet ikke behøver at gøre et projekt ud af det). Osv.
Der er en grund til at mange af nedennævnte projekter typisk udføres af fagspecialister, som har udviklet deres egne projektmetoder præcist til området. Det synes jeg giver god mening – og samtidigt tror jeg ofte, de kunne få meget gavn af at lære af hinanden på tværs af brancher.
Og derudover mener jeg, at rigtigt mange med fordel kunne give slip på de traditionelle projektmetoder og indse, at de nok ville have mere gavn af en adaptiv eller endda ekstrem projektmetode!
- Idéudvikling (R&D)
- Forandring af mennesker
- Forandring af organisationer
- IT-projekter
- Byggeprojekter
- Osv.
Det kan være det giver mening at opdele projekter i yderligere andre typekategorier?