Resultat klassisk tilgang

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.

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

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
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
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 projekts kompleksitet, og så bør denne hjemmeside have din interesse, da jeg her vil gennemgå, hvorledes alle 3 hovedpunkter ovenfor kan minimeres/fjernes.

På denne side får du bla. en forklaring på, hvad der klassisk går galt i disse 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.

I et projekter taler man om frustrationer, og om at denne frustrationens dal kan blive bundløs. 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 på vej til at blive bundløs, og dette skal vurderes løbende 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 .

Slutresultatet af kaosset vil med stor sandsynlighed blive:

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 orange linje i figur 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
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 en længere periode, 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.

Ligeledes giver jeg et bud på, hvorledes man bør håndtere frustrationer løbende i projektet.

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.