​Kompleksitet kan jo være et meget abstrakt begreb, men i forhold til et projekt kan det faktisk, gøres meget specifik.

Til højre ses et simpelt eksempel på, hvorledes man lave den første vurdering af kompleksiteten af et projekt, og det billede som man har af sit projekt i de 3 dimensioner:

​​Til højre ses nogle spørgsmål, som kan være med til at afdække kompleksiteten i hver af de 3 dimensioner. Summen af disse 3 dimensioner giver projektets total kompleksitet (Projektets scope) og dermed:

  1. ​Hvilke metoder og værktøjer er relevante/nødvendige
  2. ​Ressourcebehov fra såvel forretning som IT
  3. ​Realistisk udstrækning for projektet

​​

Hvis projektet har kompleksitet som en Enterprise Projekt (EP2), vil det resultere i at minimum 90% af moduler og værktøjer, jeg har i værktøjskassen, skal i brug.

​Hvis mine erfaringer passer, vil minimum 35% af disse moduler og værktøjer være enten ukendte for leverandøren eller af intern karakter.

Så hvis der ikke er fokus på disse fra anden side, bliver de formodentlig ikke løst, og da slet ikke af it-leverandøren.

IT’en vil i sådan et projekt kun være et værktøj, og det er primært modulerne i de ”35%” der skal drive forandringen.

Den simple vej til at finde ud af, hvad der skal bruges fra værktøjskassen, er f.eks. at få scoret sit projekt ind, på en figur som er illustreret til højre.

Dette vil give et billede af, hvor mange og hvilke moduler der skal benyttes, for at understøtte den forretnings-mæssige- og teknologiske kompleksitet. Man skal så være opmærksom på, at IT-leverandøren primært har fokus på at løse den teknologiske kompleksitet, og ofte ikke involverer sig i eller forstår at afhjælpe den forretningsmæssige kompleksitet, og det er præcis derfor, at der minimum er 35% af moduler og værktøjer, som IT-leverandøren ikke er involveret i eller forstår.

Jeg har ud fra mine erfaringer, har jeg prøvet at lave et simpelt billede af de 3 projekttyper, jeg har nævnt i figuren til højre. Jeg har yderligere opdelt både enterprise- og proces-projekter i 2 kompleksiteter.

Mosgaard Consulting

​Bent Mosgaard ©

Mobil: 20859431

Teknologisk kompleksitet:

  1. Valget af teknologi og infrastruktur
  2. Antal løsninger, moduler og komponenter
  3. Standard kontra special udvikling
  4. Kompleksitet i konfigurere og opsætte løsning
  5. Omfanget af uddannelse og træning
  6. Projektledelsens nødvendige omfang
  7. Kontraktens rammer

Procesmæssig kompleksitet:

  1. ​Hvor stor en del af produktLivscyklussen der ønskes digitaliseret
  2. ​Ambitionsniveauet indenfor de enkelte procesområder i produktlivscyklussen - Visionen
  3. ​Standard kontra special udviklingen
  4. ​Eksisterende videns opsamling og it-strategi
  5. ​Forventninger til en business case
  6. ​Vil der kunne følges op på forandringen lykkes

Organisatorisk kompleksitet:

  1. Antal medarbejder der berøres af digitaliseringen​
  2. Leverandørens modenhed og forretnings-forståelse
  3. ​Procesmodenhed eller mangel på samme hos kunden:
    1. ​Organisering omkring It
    2. ​Forretningen - Forstå nødvendigheden for forandring
  4. ​Organisationens evne til:
    1. ​At gør strategier handlings orienteret
    2. Videns overdragelse
  5. ​Organisations omfang og roller til forretningsudvikling
  6. Tilstrækkelig frigørelse af nøglemedarbejder
  7. Tilstrækkeligt overblik over porteføljen og sammenhænge i denne (IT-strategi)

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