Arbejdsmodellen | Mosegaard i Herning

PROJEKTMODEL OG MODULER

"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".

Det er også vigtigt at forstå, at det at gennemføre en kompleks forandring, er en modningsrejse, hvor det ikke er muligt at forudse alt, og lave et 100% præcist scope up front. Det er selvfølgelig teoretisk muligt, men i praktikken vil det være alt for tidskrævende, og den ofte manglende procesmodenhed i forretningen vil forhindre, at det er muligt i praksis indenfor en acceptabel tidsramme.

Hvad er løsningen på klassiske udfordringerne?

Den simple løsning på dette er, at interessenterne blot skal bruge mere tid sammen, for at sikre, at videns-opsamlingen og overdragelsen sker rigtigt Figur 1. Men det er nok de færreste, der er interesseret i den løsning alene, da dette vil gøre projektet dyrere. Den rigtige løsning er:

En projektmodel som sikrer struktureret videns-opsamling og overdragelse i hele forløbet
Nogle grundværktøjer der reducerer tid til at:
1. Beskrive forandringen/projektet tilstrækkelig præcist og relativt hurtigt
2. Overdrage den præcise opgave til IT-leverandøren, så opgaven bliver forstået
Ud over IT-implementeringen bør der også være stor fokus på den organisatoriske implementering, change management og forretningstest
Det samme gælder for gevinstrealiseringen

Alt ovennævnte styret af en projektleder og med den nødvendige involvering og ressourcer fra forretningen.

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.

Nu mangler vi den overordnede model, som kan understøtte løsningen, der er skitseret i foregående afsnit!

Jeg har i mange år arbejdet med komplekse projekter, og har fået kombineret forandringsledelse og en del metoder og værktøjer fra gængse modeller (se væsentlige erfaringer), . Derigennem er opnået en model, som tidligere har bevist, at den kan minimere udfordringerne i, og optimerer succes i komplekse projekter.

En sådan model kan ses til venstre, og der er følgende kommentar til modellen:

Modellen er en videreudvikling af Microsofts projektmodel Surestep (er dog også prøvet påkoblet andre projektmodeller)
Jeg har udviklet mere end 200 moduler igennem mine projektet, som primært understøtter de "grønne" faser i modellen (uddybning af disse kan ses under mine ydelser)
Modulerne kan bestå af:
- Metode til at indsamle af viden
- Værktøjer til at opsamle af viden
- Skabeloner til at kommunikere viden
Der er 5 væsentligste frameworki fundamentet af modulerne
Modulerne der er uafhængigt af den valgte proces- og projektmodel
Der er opbygget kompetenceudvikling som overdrager viden til de enkelte roller

Metoden, som jeg arbejder efter omkring modellen, er, at ”jeg vil lære jer at fiske i stedet for at fiske for jer”, og jeg arbejder primært med Enterprise- og Proces-projekter.

Hvis mine erfaringer passer, vil minimum 35% og helt op til 70% af disse moduler og værktøjer, der skal bruges være enten ukendte for leverandøren eller af intern karakter. Som såvel kunden som IT-leverandør skal man forstå, at IT-løsningen i sådan et projekt kun vil være et værktøj, og det er primært modulerne i de ”35-70%” som skal drive forandringen.

Den simple vej til at finde ud af hvad der skal bruges fra værktøjskassen, er f.eks. at vurdere projektets kompleksiteten og dermed få et billede af projekttypen.

Dette vil igen give en indikation af, hvor mange og hvilke moduler, der skal benyttes, for at understøtte de organisatorisk og forretningsmæssige forandring (de ”sorte” faser).

Man skal være opmærksom på, at IT-leverandøren primært har fokus på at løse den teknologiske kompleksitet, og det vil være meget usandsynligt, at de kan understøtte den de organisatorisk og forretningsmæssige forandring.

I det ideelle projekt vil såvel IT-leverandør og kunde have den samme projektmodel og referencerammen som udgangspunkt. Dette vil sjælden være tilfældet i praksis, så derfor skal man forvente i et projekt, at der også skal investeres timer i, at få IT-leverandøren opgraderet omkring både virksomhedens struktur og referencerammen.

Baseret på projekttypen har jeg et forslag til hvilke moduler, der ofte vil være relevante. Men det vil altid ændre sig i takt med, at jeg får indsigt i organisationens projekt- og procesmodenhed.

I dette afsnit burde der være links til alle de elementer, der er uddybet på denne hjemmeside. Årsagen til dette er, at alle disse elementer er væsentlige elementer at forstå, og er elementer, som har en stor indflydelse på og et sammenhæng til projektmodellen.

Klik på de "Mintgrønne" ord

Jeg vælger derfor blot, at ”linke” til de øvrige hovedområderne, derfra er det muligt fra disse forsider, at "linke" sig ned i underpunkterne:

Fundament (de øvrige afsnit under denne fane)
Specielt vigtigt er det dog at forstå, hvilke faser af modellen der benyttes i de forskellige projekttyper
Rammeværk
Enterprise projekt eller Proces projekt

Hvis du ønsker en forklaring på, hvorfor du skal bruge denne model, skal du blot kigge under punkterne i klassisk tilgang og resultatet af denne.