IT projektledelse: Det burde være enkelt – alligevel går det galt

23. november 2016

Styring af projekter. Det burde være enkelt – der er nogle aktiviteter, forløb og spilleregler, som både projektledelse og projektdeltagere skal have in mente og agere efter. Og hvis alle husker, hvad der er aftalt, er muligheden for at komme i mål faktisk rigtig god. Alligevel kikser det den ene gang efter den anden…

Ligesom ’Best Practice’ for projektledelse og projektdeltagelse er ganske velkendte og beskrevet i utallige lærebøger og artikler, så er årsagerne til kiks faktisk lige så kendte, - og genbrugte. Vi har samlet 6 typiske grunde til, at projektet ikke når i mål som planlagt. 

1. Projektets mål er ikke beskrevet godt nok

"Skal vi ikke bare gå i gang? Så sparer vi en masse tid på papirfnidder og lange diskussioner frem og tilbage."

Hvis ikke der investeres i at beskrive projektet med tilhørende forretningsmål og krav går projektejeren glip af et par rigtig gode fordele. 

Det er under dette arbejde, at man i virksomheden - helt uden at tænke over det - får lejlighed til at afstemme forventningerne internt. Hvis man sætter fem medarbejdere fra forskellige dele af virksomheden sammen om opgaven vil det hurtigt vise sig, at de kommer til arbejdet med forskellige billeder af hvad formålet med projektet faktisk er. Derfor vil de under arbejdet være nødt til at finde ind til kernen af projektet, og da der jo kun er én projektbeskrivelse må de også ved fælles hjælp finde frem til ét sæt af mål og krav.

2. Andet forarbejde håndteres med let hånd

Godt begyndt er halvt fuldendt. Fristelsen for at komme i sving i en fart er stor. Det betyder at kerneområder for projektstyring eksekveres med hurtig hånd.

Eksempler er: 

  • interessentanalyse,
  • vurdering af projektets risici samt tilhørende plan for håndtering deraf
  • den interne projektbemanding i projektforløbet. En bemanding som ofte ikke findes i virkeligheden, da projektopgaven typisk bare fyldes ind på toppen af et fuldtidsjob

- og så slipper virksomhederne ofte meget let igennem det arbejde, det er, at foretage et kvalificeret valg af leverandør og dermed produkt. Forbavsende ofte kontaktes kun den leverandør man kender. Det synes for krævende at opsætte en kravbeskrivelse sådan at man kan bede flere kvalificerede leverandører udarbejde deres forslag og tilbud - på et ensartet grundlag.

3. Projektets indhold og mål ændrer sig løbende undervejs

"Kan vi ikke også lige...?"

Jo, naturligvis, - men husk at afstemme med projektrekvirent, med interessenterne, med leverandøren og den økonomi, der kan følge med, med konsekvens for leveringstiden, - og før projektdokumentationen ajour.

Ellers kan det ende som jævnligt set: Leverandører, samarbejdspartnere og projektdeltagere vil så snart det måtte være nødvendigt bruge ændringen som begrundelse for ændret projektøkonomi og/eller funktionalitet og/eller leveringstid.

Og ingen var faktisk klar over de konsekvenser ændringen ville få.

4. Leverancestyring undervurderes

"Nu har vi endelig valgt og har skrevet kontrakt, så kan bruge vores tid på andre ting indtil leverancen kommer."

Men dén går ikke. Når leverandøren går i gang med at udvikle og konfigurere løsningen vil virksomheden løbende få ganske mange spørgsmål til afklaring. Og de er typisk ikke enkle. Det kan være spørgsmål til algoritmen for produktionsplanlægningen, forretningsproces omkring kvalitetssikring, osv., - spørgsmål som er afgørende for den nye løsning, og som der skal arbejdes for at svare på. Og så er det under arbejdet med leverancen at projektet er udsat for høj risiko for at forandre sig i forhold til oprindeligt aftalte Kravbeskrivelse.

5. Implementeringen undervurderes.

Tag ikke fejl: Når en IT leverandør siger Implementering betyder det oftest, at løsningen er installeret og klar til brug, og at den aftalte undervisning er foretaget. Men den nye løsning er på ingen måde indarbejdet i organisationen.

Sædvanligvis koster det ekstra tid de første dage og uger med en ny løsning. Medarbejderne skal på samme tid bruge en ny løsning med en komplet anderledes brugergrænseflade og struktur samtidig med at arbejdsrutinerne sandsynligvis også er ændret. På den måde står de virkelig på gyngende grund uden de velkendte gamle platforme. Det tager tid at få det nye ind under huden.

Læg dertil at medarbejderne kun har haft kort tid til at vænne sig til tanken om at der kommer en ny løsning, og at de måske ikke er holdt orienteret om hvad de kan forvente, - så er der helt naturligt en mental procestid. Og indtil den er fordøjet er det meget let for medarbejderen bare at synes at alt er noget bras.

Implementering kræver fuld tilstedeværelse af ledelse, projektledelse, support, og det i så lang tid, som det er nødvendigt. Til gengæld er det faktisk muligt at få et forløb, hvor medarbejderne føler sig båret på hænder i forløbet med det resultat, at de får en positiv holdning til fornyelsen.

Læs også: Hvordan bliver jeg en effektiv forandringsagent? 

6. Gevinsterne realiseres ikke

Når virksomheden og dets ledelse endelig er så langt, at den nye løsning er i daglig brug er det meget fristende at sætte et flueben, - og rette energien andetsteds hen.

Men projektet har ikke leveret endnu. Det er nu, man skal have fat i de forretningsmål, der motiverede til at tegne og gennemføre projektet. Der skal altså nu foregå en måling i forhold til de forretningsmål, som projektet skal levere, - tid, kvalitet, service, leveringstid, rapportering, effektivitet, udvikling og bundlinje….

Selvfølgelig leverer projektet ikke fuldt fra dag et, men de løbende målinger kan indikere hvor og hvornår det er værd at gennemføre en opfølgningsrunde for at finde ud af, hvad der gør, at et bestemt mål endnu ikke er nået. Ved større projekter og ændringer kan der sagtens være behov for at holde øje med leverancen på mål i ganske lang tid, - og det er der på ingen måde noget galt i.


Tilmeld sure'it nyhedsmail

Tilmeld dig vore nyhedsmails, og hold dig opdateret med hvad der sker i sure'it, og hvad sure'it kan hjælpe dig og din virksomhed med.

Vi tilstræber at udsende 3 til 4 nyhedsmails om året.