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 var det så enkelt, så ville man ikke se det kæmpespild, som man har på sine IT-projekter. Her tænker jeg ikke på Polsag, EFI, EPJ eller andre kæmpeskandaler, som 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 dér ikke er så interessante at sætte fokus på. Eller måske er disse småkatastrofer interessante nok. De er bare ikke til at få øje på, med mindre man selv arbejder på dem.
Disse løbske projekter koster virksomheder – private og offentlige – et ukendt, formentlig stort, millionbeløb år efter år. Tænk, hvad man kunne udrette med de penge, hvis ikke man hældte 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 arbejdet på et forsinket projekt.
- Der mangler måske erkendelse af, at projekterne gennemføres af projektledere eller –teams uden de nødvendige kompetencer
- Måske foregår de under en ledelse, der ikke sit ansvar bevidst og ikke giver den nødvendige opbakning og strategiske retning.
Eller måske tænker man: ”vi er jo kun en måned forsinkede – det er jo ingenting!”
Mange bække små….
Dette simple regnestykke viser, at man med et lille projektteam på 5 personer til en intern timepris på 300 kr. (hvilket næsten med garanti er for lavt sat) vil spilde 11.250 kr. pr. dag = 230.000 kr. for hver måneds forsinkelse.
Hertil kommer forsinket opstart af nye projekter, planlagte gevinster, som høstes med forsinkelse, evt. ekstra licensomkostninger m.v. For ikke at tale om evt. ekstra omkostninger til eksterne konsulenter. Her slipper man ikke med 300 kr. pr. time.
Allerede her, vil jeg slå én ting fast: Forsinkede IT-projekter eller projekter, der overskrider de ø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 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 er tilstrækkeligt.
Ideen om struktur er bestemt rigtig god, 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 projekt-ledere bliver svært at få det overblik, der er forudsætningen 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 så omfattende ramme, 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 tit, at kunder ønsker at høste fordelene ved at arbejde agilt, men ikke er villige til at foretage den investering, det kræver at få de agile systemer til at fungere. Agile metoder stiller bl.a. krav til ledelsen og til teamet, der ofte mangler viden om, hvordan fx. Scrum eller Kanban fungerer.
Ingen af disse eksempler virker særlig godt, men man bliver alligevel 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 så 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 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 certificering er en god genvej til at forstå, hvad man skal rette sin opmærksomhed imod som projektleder, men at man ikke kan læse sig til erfaring.
Man skal vide, at projektlederen er dybt afhængig af en ledelse, der tager ansvar for den forretningsmæssige og strategiske retning, samt af et kompetent projektteam.
Man skal have en projektmetode på plads, der passer til organisationen og dens projektmodenhed, og det er en god tommelfingerregel, at småt er godt!
Det er helt afgørende, at man som virksomhed, projekt- eller IT-afdeling overvejer:
- Hvordan er kulturen hos os. Er vi topstyrede eller uddelegerer vi gerne?
- Er vi meget hierarkiske og traditionelt opbygget, eller har vi en flad organisation?
- Hvis vi vil stramme op på vores projektkultur, ved vi så, hvordan man gør?
- Hvis vi vil være mere agile, forstår vi så, hvad det indebærer?
- Hvordan skal vi uddanne vores organisation, så den bliver bedre til at levere projekter?
- Skal vi have en specialist ind, som kan rådgive om den bedste og enkleste vej frem?
Én ting er sikkert: Man kan købe sig til meget metoderådgivning for bare én måneds forsinkelse til 230.000 kr. for et 5-mands projektteam, jf. ovenfor. Den investering tjener sig hjem mange gange, når man kan levere projekter til tiden igen og igen.
Jeg anbefaler Context-based Project Management. Det er en light-metode, der kombinerer agil og traditionel god projektpraksis, og tilpasses den enkelte virksomhed. Metoden sikrer, at projektgrundlaget er i orden, den giver overblik og er intuitiv at bruge. Også for mindre erfarne projektledere. Det behøver nemlig ikke at være så svært!
Vil du vide mere, så kontakt mig på info@xvoto.dk
