​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:

​

1. ​​En projektmodel som sikrer struktureret videns-opsamling og overdragelse i hele forløbet
2. ​​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
3. ​​Ud over IT-implementeringen bør der også være stor fokus på den organisatoriske implementering, change management og forretningstest
4. ​​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.

​