RESULTAT AF KLASSISK TILGANG​

​"For stor en hammer" er lige så forkert som "for lille en hammer". Så det vigtige i et projekt er at vælge den rigtige "hammer".

Jeg hører rigtig tit et af følgende udsagn:

  • ​”Vi er bare en lille simpel virksomhed, og kan arbejde ligesom alle de andre”
  • ​”Vi skal bare have ren standard”
  • ​”Jeg er overbevist om, at brancheløsningen passer perfekt til os”
  • ​”De kender os (at læs it leverandøren), så de ved, hvad vi skal bruge”

Og i lyset af ovenstående, er den efterfølgende kommentaren, ”hvor svært kan det være”. Kommentaren er til tider måske sagt i håbet om, at få den lavest mulige ”omkostningen” til den fremtidige it-løsning.

Der er en chance for, at man slipper heldigt af sted med ovennævnte holdning i mindre komplekse projekter (BIB og PP1), Men med de mere komplekse typer (PP2, EP1 og EP2), vil man med sikkerhed komme til at opleve, det som er gengivet herunder i en eller anden grad.

Hammerens størrelse skal ikke blot være et udtryk for en drøm, om at gøre det så billigt som muligt. Hammerens størrelse skal fastlægges ud fra projektets kompleksitet, og dermed hvad der skal til, for at få et succesfuldt projekt. Alternativt vil jeg anbefale, at projektet udskydes, til man har den økonomi og de ressourcer, der skal til, for at opnå projektets succeskriterier. 

​Alle ”projektes omfang” er ikke ens, men fælles for alle projekter er, at de indeholder de 3 dimensioner, som er illustreret i figur 1. Forskellen på projekterne og valget af "hammerstørrelsen" ligger i omfanget af hver af de 3 dimensioner. Denne kompleksitet uddyber jeg et andet sted på denne hjemmeside.

Der har desværre været en tendens til i mange projekter, at kunden og IT-leverandøren har haft følgende oplevelser:

  1. ​​Opgaven ændrer sig radikalt i forløbet og med følgende virkning (Scope creep):
    1. ​​Investering i projektet forøges markant
    2. ​​Udstrækningen af forløbet ændrer sig væsentlig
    3. ​​Ressourcebehovet for at gennemføre projektet stiger voldsomt
  2. ​​Ligeledes er der en risiko for at kunden:
    1. Ikke er enig i, at de har modtaget "den løsning" de har bestilt
    2. Er i tvivl om, hvorvidt de opnår – de gevinster/fordele, de har regnet med
    3. Får startet forkert med virksomhedens løsningsarkitektur
  3. Kaos/frustrationer i virksomheden op til og lige efter go live, og her taler vi om:
    1. Omfanget af disse
    2. Udstrækningen af perioden det foregår
​​​​​​

​​​​​Hvis du har oplevet nogle eller alle ovennævnte punkter i et eller flere projekter, har du/i med sikkerhed fejlvurderet jeres projektskompleksitet, og så bør denne hjemmeside have din interesse, da jeg her vil gennemgå, hvorledes alle 3 hovedpunkter ovenfor kan minimeres/fjernes.

​På denne hjemmeside får du bla. en forklaring på, hvad der klassisk går galt i disse projekttyper, samt indsigt i en projektmodel som sammen med en værktøjskasse beviseligt har minimeret eller fjernet ovennævnte udfordringer i de 2 oven nævnte projekttyper

Figur 1​

​​

Figur 2​

​​​I afsnittet ovenfor forklar jeg, at mange forandringsprojekter er udsat for scope creep, udeblivende forbedringer og frustrationer og kaos i forbindelse med implementeringen.

En klar forudsætning for at kunne bearbejde frustrationerne er, at der er arbejdet seriøst i de indledende faser med at præcisere scopet, som det er beskrevet under Projektmodel. Dette skal sikre en reduktion/udjævningen af de udfordringer, der ellers vil dukke op i den sidste fase (Go live).

Herunder vil jeg beskrive, hvorledes en virksomhed kan minimere de frustrationer, der opstår i forbindelse med forandringer. I den forbindelse er det vigtigt at understrege, at mængden af frustrationer i et projekt er ligefrem proportionalt med projektets kompleksitet og størrelsen af de forandringerne.

Fustration opstår på grund af en kombination af:

·​Manglende forståelse for nødvendigheden af forandring og manglende adoption af det fremtidige setup

·​Fald i effektiviet i dagligdagen

·​Dårlig planlægning af projektet med ressourcespild og pres på nøglemedarbejder til følge

Alt sammen kan forebygges, men det kræver en målrettet indsats. Måden som det sker på, er at man sikre at den ”bundløs dal” indtræffer (Figur 2).

Bundløs skal forstås på den måde:

·​At mængden af udfordringer i perioder bliver uoverskuelige

·​At medarbejderne vil løbe ukoordineret rundt, og på anarkistisk vis løse udfordringer uden tanke for, hvad der vil være det optimale for helheden.

Det er nødvendigt i en forandring/projekt løbende vurderer, om ”frustrationens dal” er bundløs, og dette skal starte tidligt i projektet.

Det som kan ske herefter, er, at frustrationerne og kaosset bliver så stort, at der af mange forskellige årsager mangler et overblik over, hvilke udfordringers der skal løses for at komme kontrol. Ledelsen træffer i kaosset en beslutning om at gå i luften på det nye setup, godt presset af at metaltrætheden i organisationen er ved at blive så stor efter flere måske mange måneders arbejde, at ledelsen er bekymret for, hvad der vil ske, hvis projektet ikke bliver lukket nu.

Hvis ikke virksomheden får kontrol over kaosset, vil resultatet ofte ende som illustreret i figur 3 (Numrene i bunden er et udrtyk for fasen i projektmodellen).

Slutresultatet af kaosset vil med stor sandsynlighed blive:

1.​at effektiviteten i det nye setup bliver væsentlig ringer (illustreret ved den blå linje i figur 2), end den effektivitet virksomheden kommer fra (Illustreret ved den røde linje i figur 2)

2.​at der vil være en lang periode efter go live, hvor der skal bruges såvel interne som eksterne timer, på at stabilisere og trimme løsningen, uden man dog skal forvente at nå fortidens effektivitet

3.​at kaosset fortsætter i hele og gør stabiliseringsfasen efter go live

Som det fremgår, vil dette sætte virksomheden effektivitetsmæssigt tilbage, hvilket vil være ensbetydende med, at virksomheden risikerer at skulle bruge flere år, på at bringe sig tilbage til tidligere års effektivitet, hvilket jo åbenlyse ikke er attraktivt

​​Hvis ikke virksomheden får kontrol over kaosset, vil resultatet ofte ende som illustreret i figur 3 (Numrene i bunden er et udrtyk for fasen i projektmodellen).

Slutresultatet af kaosset vil med stor sandsynlighed blive:

1.​at effektiviteten i det nye setup bliver væsentlig ringer (illustreret ved den blå linje i figur 2), end den effektivitet virksomheden kommer fra (Illustreret ved den røde linje i figur 2)

2.​at der vil være en lang periode efter go live, hvor der skal bruges såvel interne som eksterne timer, på at stabilisere og trimme løsningen, uden man dog skal forvente at nå fortidens effektivitet

3.​at kaosset fortsætter i hele og gør stabiliseringsfasen efter go live

Som det fremgår, vil dette sætte virksomheden effektivitetsmæssigt tilbage, hvilket vil være ensbetydende med, at virksomheden risikerer at skulle bruge flere år, på at bringe sig tilbage til tidligere års effektivitet, hvilket jo åbenlyse ikke er attraktivt

​​

​Figur 3

​​

Under ”Fundament” giver jeg et bud på de overordnede elementer, som en virksomhed skal have styr på, hvis den vil minimere de udfordringer, som er skitseret ovenfor i et komplekst projekt.

Med den rigtige projektmodel inklusiv strukturerede metoder og værktøjer er min påstand, at et kompliceret projekt kan gennemføres for færre ressourcer, end der bruges i klassisk projektforløb i dag, og det samtidig med, at projektet vil opleve en væsentlig høje kvalitet.

Det der kræves, er skitseret ovenfor, og at gennemføre de nødvendige aktiviteter. Dette fastlægges i første omgang af projektets kompleksitet og ikke af økonomien.

Mosgaard Consulting   /   Østre Kirkevej 30, 7400 Herning   /   Telefon: 20 85 94 31   /   E-mail: bent@mosgaard.consulting   /   CVR: 26114144