Hvorfor mislykkes prosjekter ?

Et anerkjent miljø innen Prosjektledelse i Norge har vært Metier, som gjennomfører en årlig undersøkelse om hvordan det står til med “prosjektkompetansen” i Norge.

Hvorfor mislykkes så prosjekter?

For det første ser det ut som om antall prosjekter som lykkes går ned.. Det vil si at til tross for at alle snakker om transformasjoner, og gjerne digitale (som jo må inkludere teknologi på en eller annen måte..) så blir vi neppe bedre på å gjennomføre prosjekter. Dette er bekymringsfullt, – og det er etter vår oppfatning merkelig at dette ikke er høyere opp på agendaen på samfunnsdebatten.

Men la oss se på årsakene som undersøkelsen avdekker til at prosjekter mislykkes:

Uklare mål og krav – dette opplever vi “daglig” – man igangsetter et prosjekt nærmest i blinde. Vår oppfatning er at man ofte ikke har tilstrekkelig tålmodighet til å sette opp klare mål for prosjektet, og at man ofte blander driftsoppgaver og prosjektoppgavene. Et prosjekt er avgrenset med tydelige mål og klare leveranser.

Løsning: Ta deg tid til å sette klare leveransemål for prosjektet, og ta deg også tid til å skrive ned et klart mandat for prosjektet.

Mangel på ressurser – når prosjektet ikke er klart definert er det også ofte vanskelig å rekruttere riktige ressurser til prosjektet. En ting er at man ikke setter av tilstrekkelig med ressurser, men ofte opplever man også at feil ressurser blir satt på. Man tilbyr de som kanskje er ledige, skal lære mer om dette, er hyggelig osv..

Hvordan skal man så rekruttere? For det første er rekruttering til et prosjekt ikke mindre men kanskje mer krevende enn å rekruttere til linjen. Prosjektene er tidsbegrenset, og man har ofte ikke de erfarne ressursene å spille på. Vår erfaring er at man nok ofte undervurderer rekrutteringsprosessen, og at dette henger sammen med hva slags prosjekt man faktisk skal gjennomføre.

Løsning: Ha en strukturert prosess på ressursallokeringen. Vær åpen for å hente inn eksperter uten i fra eller andre steder i organisasjonen. Prosjekter er avhengig av å ha en fleksibilitet i organisasjonen – man vil kunne ha behov for forskjellige ressurser i ulike faser av prosjektet.

Endringer i omfang: Alle kjenner godt til dette. Uansett hvor mye tid man setter av til planlegging og nedbryting av alle arbeidspakkene, – opplever man endringer i omfang (scope creep). Vi vil si det så konkret som at det kommer endringer i omfang, – da er det viktig hvordan slike endringer faktisk håndteres. For det første er det viktig med gode rutiner for hvordan endringer skal meldes, både overfor styringsgruppen og eventuelt overfor en sluttkunde om det er et implementeringsprosjekt.

Løsning – vær tydelig på hva som er avtalt omfang, – få signert de nødvendige dokumenter f.eks gjennom Verified eller tilsvarende løsning. Prosjektledelsen må “jakte” endringer, – og meddele disse så snart som mulig, – ikke ha en “det går sikkert bra” holdning. Er det endringer så vil det jo komme for en dag allikevel. Det er heller ikke noe nederlag at det kommer endringer, – det er ofte først når man får stukket spaden i jorda at alle behov faktisk viser seg..

Manglende involvering fra ledelsen og uklar organisering – vi velger å slå sammen manglende involvering og uklar organisering, fordi disse rett og slett hører tett sammen. Husk at et prosjekt er en form for skjebnefellesskap mellom de som blir satt på det, det er en liten organisasjon som kanskje skal gjelde noen få uker eller måneder, for så å oppløses. Vi jobber mye med at det skal være veldig tydelig hvilken rolle styringsgruppen har, og hvem som skal sitte der. På samme måte som i et AS er leder styringsgruppen (styreformann) prosjektlederens (adm.dir) nærmeste foresatte og sjef. Det er jo da ganske åpenbart at disse rollene må være tydelig definert. Vel, – man vil kanskje tro at det er åpenbart, men hvor mange ganger opplever vi ikke at disse rollene er uklart definert, – hvem er det som var leder i styringsgruppen for dette prosjektet igjen? Var det ikke det andre prosjektet da? Og ennå mer uklart blir det dersom prosjektlederen kanskje er inne som leder for flere prosjekter.

Videre er det viktig med klar og tydelig instruks om hvem som er leder for konkrete arbeidspakker, når skal disse leveres, hva er avtalt omfang, hvilket mandat har prosjektleder for å akseptere endringer og når må det skaleres til styringsgruppen? Og hvilke mandater har så styringsgruppen i forhold til linjen?

Det er klart at man ikke i et dokument kan ta høyde for alle slike endringer, – men man vil få mye igjen for å ha klare roller. Uansett så MÅ det være helt klart og tydelig hvem som er prosjektleder og hvem som er leder styringsgruppen. Ikke ta med folk i styringsgruppen bare for å ha de der, alle må ha en rolle. Dersom det er mer for å holde seg orientert, – vurder om de heller skal være medlem i en referansegruppe, og kall de inn når det er behov.

Løsning – skriv inn i prosjektdokumentet (f.eks PID) hvem som er prosjektleder og hvem som er leder i styringsgruppen. Gjennomfør en enkel forventingsavklaring mellom styringsgruppen og prosjektleder, – hvor man avstemmer nivå på rapportering osv.

Leave a Reply