Kan man skære alle projekter over én kam?
Rigtig mange organisationer har valgt at indføre en bestemt standard for, hvordan projekter i organisationen skal gennemføres. En skabelon, der f.eks. indeholder krav om, at der laves en business case, gennemføres en interessentanalyse og udarbejdes en risikovurdering. Nogle går længere og ophøjer en egentlig projektmodel som f.eks. Prince2 til ’lov’ i organisationen.
Argumenterne er bl.a., at en fælles måde at gøre tingene på, sikrer at alle projekter kommer igennem den samme ’checkliste’, at der skabes et fælles sprog om projektstyringen på tværs af organisationen, og at projekterne bedre kan vurderes og prioriteres (af ledelsen), når de er sat op efter den samme metodik.
Men jeg kan godt blive i tvivl om, hvorvidt dette alligevel er hensigtsmæssigt. Om ikke det risikerer at ’mekanisere’ projektarbejdet uden hensyn til, hvilken opgave det er, man ønsker at løse gennem et projekt. Min erfaring siger i hvert fald, at genstandsfeltet for projekter er vidt forskellige. Nogle opgaver er enkle, mens andre er uhyre komplekse. Nogle opgaver kræver en velafprøvet og rutinemæssig tilgang, mens andre kræver en mere afsøgende og eksperimenterende holdning fra projektteamet. Skal der uagtet denne forskellighed benyttes samme projektmodel i alle tilfælde?
- Danmarks største job- og karrieresite for ingeniører og it-professionelle.
IMHO er alle projektredskaber primært til for at forsøge at hæve udviklerne mv. op på et niveau over, hvad de ellers måtte være på. F.eks. overføre erfaringer til uerfarne medarbejdere.
PHK skrev for et par år siden et meget rammende indlæg (her: http://www.version2.dk/blog/agil-min-bare-16318)
"En stensikker opskrift på success i software udvikling er en kompetent og inspirerende leder, med op til et dusin motiverede [og kompetente] medarbejdere."
Og deri kan jeg kun give ham ret. Problemet er bare, at ligesom jægersoldater, så udgør de virkelig dygtige og erfarne udviklere kun en mindre del af den samlede udviklerskare. I resten af forsvaret har man strukturerede regelsæt for soldaterne, så de ved, hvordan de skal gebærde sig. På samme måde er projektmodeller til for at sikre, at man som minimum gør tingene på en bestemt måde, man så håber er god.
Om et projekt passer ind i en model er vel altid en vurdering, som kun kan tages, hvis beslutningstageren har en nødvendige erfaring og dygtighed.
-C
OG - de faste rammer betyder også at der lettere kan "måles" på succes på tværs af projekter - sjovt nok også noget man ynder at bruge rundt omkring, især for at kunne sammenligne businesscases. - Jeg er sikker på jeg så også vil være uenig i fortalerne for det, men det er jo desværre ofte sådan det går.
Men det er også de samme mennesker som udelukkende ser 2 tal - drift og indkøb. hvis noget går galt på grund af dårlig drift eller dårlig indkøb, så er det jo ikke noget der råbes op om. For det passer så ikke ind i deres skabelon.
Du giver jo faktisk svaret selv 'Min erfaring...' :) Og helt korrekt min erfaring fortæller også, at så længe projektet vedrører samme gruppe personer, uddannelsesniveau, udstyr etc. så kan der 'mekaniseres'.
Men du betjener jo mange særdeles differerende grupperinger, så projekt'mekanisering' er kun delvis mulig hos dig.
Men den dygtige og erfarne udvikler/projektleder ved (erfaring) hvad, hvor meget og til hvem, der kan 'mekaniseres'. Det ligger i rygraden hos personen, og det kan der ikke uddannes til via teoretisk læsning af litteratur.
De fleste moderne metoder for projektstyring, inklusiv PRINCE2, inkluderer at man i projektets opstart tilpasser projektmodellen til projektet - men metoderne og projekt-"systemet" forbliver det samme. Netop fordi projekter er forskellige. Hvis man prøver at bruge samme model, for eksempel samme dokumentskabeloner, på alle typer og størrelser af projekter, så har man ikke den rigtige forståelse for moderne projektstyring og så vil det være en fordel at starte med noget læring. Som det ganske rigtigt er kommenteret så kan selv den bedste projektstyringsmetode ikke erstatte en erfaren og dygtig projektleder. Og deltagerne skal også have en god forståelse for projektmetoden.
@Alex - Spot on.
Hvis man tager en model som PRINCE2 "ned fra hylden" uden at skalere til ens behov "brækker man nakken".
Efter man har kørt det første projekt efter ens skalerede model bruger man som regel den læring man har fået undervejs til en sidste justering. Den fremkone model kan man betragte som ens model for et "typisk" projekt.
Når næste projekt går igang bør man igen skalere op/ned på den typiske model alt efter ens behov....og igen bør læring indgå i en stadig forbedring af ens model.
Med tiden vil man have en række "standard" modeller som kan strække sig fra agile/Lean udviklingsprojekter til mere stringente projekter.
Den dygtige og erfarne projektleder kan sagtens styre et LILLE team igennem et projekt uden standard modeller, men der er et rationale i at anvende modeller som PRINCE2 hvis man har flere projekter/projektledere og/eller ønsker at øge organisationens modenhed - ikke at forglemme at ens medarbejdere fra starten af projektet har en rimelig føling med projektlederens forventninger til projektforløbet.
@Ole - helt enig.
Det er også derfor f.eks. PRINCE2 lægger vægt på at opsamle Lessons Learned undervejs - altså opsamling af erfaringer omkring projektmodellen og projektets forløb. Udover læring om selve projektets indhold. Lessons learned er desværre ofte nemt og bekvemt at springe over.
Det er korrekt at den dygtige og erfarne projektleder kan styre et lille team igennem et projekt uden standardmodeller. Men det kræver ofte en mindre heroisk indsats. Men det kan man selvfølgelig profilere sig på :-) Men så snart projekter bliver større eller har en vis kompleksitet er det nødvendigt med en struktur og et system. Eller en stor heroisk indsats - og en vandtæt flugtplan når det hele kollapser ;-) En af de større fordele ved en projektmetode - udover de mere åbenlyse omkring f.eks. kommunikation - er at det frigiver tid og mulighed for at fokusere mere på projektets indhold og en hel del mindre på at styre selve projektets rammer og struktur. En klar gevinst. Men så er vi tilbage ved start: Projektmodellen skal være tilpasset projektet for at dét virker.
Der er i min optik stor forskel på en projektmodel, en projekt metode, en projekt standard og konkret projekt gennemførelse, omend den konkrete gennemførelse naturligvis bør baseres på en velegnet metode, der hviler på en god standard inden for rammerne af virksomhedens governance projekt-model.
En god projektmæssig standard, såsom PMI's PMBOK, beskriver direkte både tilpasning af projektet såvel som ledelsen deraf til opgaven og anvendelse af relevante erfaringer.
Samling af strategiske initiativer, omhandlende projekter, opgaver og drift, i programmer kan være en måde at omfavne forskellige ting der dog har samme strategiske formål i en periode, under en fælles styring.
Omvendt bør projekter ikke belemres med at styre de repeterende processer der hver gang kører efter helt samme læst. Det hører hjemme i en liniemæssig organisering, også selvom indsatsmængden kan variere betydeligt.
Projekter bør reserveres til tidsmæssigt klart afgrænset skabelse af unikt resultat, service eller produkt, og at dimsen denne gang er rød i stedet for grøn er ikke altid tilstrækkeligt til at kvalificere et helt projekt til opgaven. Blandt andet fordi projektet netop kan være underlagt en vis governance, der i sig selv fylder en del.
Til gengæld synes de fleste beslutningstagere på portefølje niveau, altså over programmer og projekter, nok om en ensartet struktur og proces som basis for deres beslutninger, bevillinger og opfølgning.
Derfor værdsætter øvre ledelse ofte, at organisationen overholder projektmodellen for alle de initiativer, de som beslutningstagerne aktivt skal forholde sig til.
Det er i min optik og erfaring bestemt ikke ensbetydende med, at alle de faktiske projekter skal være skåret over samme læst. Det er bare enkelte elementer af governance, der her er stillet krav til, for enkelthed og effektivitet på et overordnet niveau.
Disse ting, og skelnen imellem dem, har man som succesfuld projektleder behov for at have placeret rigtigt på sit landkort.
I det lys bliver det ikke længere en diskussion om, hvorvidt alle projekter skal skæres over samme læst, men om hvad der er governance, hvad der er projekter, hvad projektledelse, metode og standard er, og hvad der er liniemæssige opgaver..
God pointe. Men det kan måske blive endnu værre, når et initiativ ikke kommer i mål og derfor er primært læring (dokumenteret eller ej). I samme forbindelse kan jeg ikke lade være med at tænke på om tilpasning af en projektmodel rækker, hvis formål og resultat er markant forskellige fra andre projekter. Måske det er bedre at lade et team arbejde i helt nye rammer? "Det kommer an på..." tænker jeg.