Forsinkede projekter betyder, at millioner og atter millioner hældes i kloakken

Mange mener, at projektledelse bare er sund fornuft. Gid det var så vel, men hvis det var så enkelt, så ville man ikke se det kæmpespild, som man har haft og stadig har på sine IT-projekter. Her tænker jeg hverken på Polsag, EFI, EPJ eller andre af kæmpeskandalerne, som vi alle hører om.

Jeg tænker på det spild, der sker hver eneste dag på de projekter, der ryger under radaren, fordi et par millioner hér og et par millioner dér ikke er så interessante at sætte fokus på. Eller måske er disse småkatastrofer faktisk interessante nok. De er bare ikke rigtig til at få øje på, med mindre man selv arbejder på dem.

Disse forsinkede og fordyrede projekter koster virksomheder – private og offentlige – et ukendt, formentlig stort, antal millioner hvert eneste år. Tænk, hvad man kunne udrette med de penge, hvis man stoppede med at hælde dem direkte i kloakken.

Hvorfor er der så ikke nogen, der råber højt om disse projekter?

  • Måske fordi man ikke er stolt af at have medvirket på et forsinket projekt.
  • Der mangler måske erkendelse af, at ens projekter gennemføres af projektledere eller -teams, der ikke har de nødvendige kompetencerne
  • Måske foregår de under en ledelse, der ikke er bevidst om sit ansvar og ikke giver den nødvendige ledelsesmæssige opbakning og strategiske retning.

Eller måske tænker man: ”vi er jo kun en måned forsinkede – det er jo ingenting at tale om”.

Mange bække små….

Dette simple regnestykke viser, at hvis man har et lille internt projektteam på blot 5 personer til en intern timepris på 300 kr. (dette er næsten med garanti for lavt sat), så spilder man 11.250 kr. pr. dag eller ca. 230.000 kr. for hver måned, dette lille projekt er forsinket.

Hertil kommer de nye projekter, som starter op senere end forventet, samt den planlagte gevinstrealisering, som høstes med forsinkelse. For ikke at tale om de ekstra omkostninger, der kommer til, hvis eksterne konsulenter er involveret. Her slipper man ikke med 300 kr. pr. time.

Allerede her, vil jeg slå én ting fast: Forsinkede IT-projekter eller projekter, der overskrider deres økonomiske rammer, er ikke en naturlov.

Jeg gentager lige: Forsinkede og for dyre IT-projekter er ikke en naturlov.

Hvorfor bliver man så ved med at gøre de ting, man ved ikke virker?

Uanset hvordan man vender eller drejer det, så er IT-projektledelse en ganske kompliceret disciplin. Jo før man erkender dette, des hurtigere kan man finde en løsning. Men hvor starter misèren?

En del af problemet består i, at man forsøger at sætte denne komplicerede disciplin på formel, og tror, at det i sig selv er tilstrækkeligt. Ideen om struktur er sådan set god nok, men når formlen enten er en projektmetode, der er voldsomt kompliceret (traditionelle metoder), eller ikke er omfattende nok (agile metoder), så skal det gå galt. Begge dele resulterer nemlig i, at det for de fleste projektledere bliver svært at få det overblik, der er en forudsætning for at lykkes med sit projekt.

Det synspunkt bygger på mine konkrete erfaringer med IT-projekter gennem 25 år.

Jeg har arbejdet i store internationele virksomheder, der bruger veletablerede projektmetoder, men i en ramme, der er så omfattende, at ingen kan finde rundt i den. Resultatet er, at deres projektledere anvender metoden på hver sin måde.

Jeg har arbejdet hos kunder, der har hægtet sig på PRINCE2, men ikke forstår de sammenhænge, der er i metoden, og hvad den kræver af organisationen. Det virker heller ikke.

Jeg oplever ofte, at kunder ønsker at høste fordelene ved at arbejde agilt uden samtidig at være villige til at foretage den investering, det kræver at få de agile systemer til at fungere. Agile metoder stiller krav til ledelsen og til teamet, der ofte mangler viden om, hvordan f.eks. Scrum eller Kanban fungerer.

Ingen af disse eksempler fungerer ordentligt, men man bliver ved med at arbejde sådan, fordi man:

  • Føler sig tryg ved det kendte, selvom man godt ved, at det ikke virker
  • Ikke tror, at det kan være anderledes med IT-projekter (men det kan det)
  • Blot følger med strømmen, og tror, at hvis en metode virker for naboen, så virker den også her
  • Ikke vil kaste sin gode, gamle metode over bord, som man måske har investeret meget i. Dette på trods af dårlige projektresultater 

Hvad kan man gøre, for at stabilt få sunde(re) projekter?

Man skal forstå, at IT-projektledelse ikke kun er sund fornuft, og at en (agil) projektcertificering blot svarer til at få et kørekort. Man kender trafikreglerne, men er ikke nødvendigvis en god bilist endnu. Nogle bliver det aldrig.

Man skal vide, at en projektcertificering er en god genvej til at forstå, hvad man skal have sin opmærksomhed rettet imod som projektleder, men at man ikke kan læse sig til erfaring.

Det er helt afgørende, at man som virksomhed, projekt- eller IT-afdeling overvejer:

  1. Hvordan er kulturen her hos os. Er vi til control-and-command eller uddelegerer vi gerne?
  2. Er vi meget hierarkiske og traditionelt opbygget, eller har vi en flad organisation?
  3. Hvis vi vil stramme op på vores projektkultur, ved vi så, hvordan man gør?
  4. Hvis vi vil være mere agile, forstår vi så, hvad det indebærer?
  5. Skal vi have en specialist ind, som kan rådgive om den bedste og enkleste vej frem?

Én ting er i hvertfald sikkert: Man kan købe sig til meget metoderådgivning for bare en enkelt måneds forsinkelse til 230.000 kr. på det 5 mand store projektteam beskrevet ovenfor. Den investering tjener sig hjem mange gange, når man bliver i stand til at levere projekter til tiden igen og igen.

Selv kan jeg anbefale Context-based Project Management, som er en light-metode, der kombinerer agil og traditionel god projektpraksis. Metoden giver overblik og er enkel og intuitiv at bruge. Også for mindre erfarne projektledere. Det behøver ikke at være så svært!

Vil du vide mere, så kontakt mig på info@xvoto.dk