PROJEKTKOMPLEKSITET


Projekttyper er en simpel måde, at illustrer et projekts kompleksitet på, og denne gruppering vil for indviede give et billede af, hvad der skal til for at få succes i et projekt. Hvis man ønsker at gå skridte videre, og ønsker at forstå det enkelte projekts natur, og få en dybere indsigt i hvad der reelt skal til for at få succes i et projekt, er man nød til at forstå projektets kompleksitet.

I figur 1 er illustreret de 3 væsentligste områder, der skal håndteres i en forandring (et projekt), og dermed  de emner der er med til at fastlægge projektets scope og den nødvendige  ”størrelse af hammeren”. Disse områder er:

  • ​Projektets omfang (se nedenfor)
  • ​Ressourcer
  • ​Timeboks

​​

​​​Typisk fastlægges ”projektets omfang” først, herefter kan man fastlægge ressourcebehovet og en realistisk udstrækning af projektet. Det er sandsynligt, at virksomheden konstaterer, at denne ikke har de nødvendige ressourcer eller den for nødende udstrækning til rådighed. Dette kan man f.eks. tage hensyn til i projektet ved enten at:

  • ​Reducere opgavens omfang
  • ​Acceptere risiko i projektet - evt. med "dårlig kvalitet" til følge (se nedenfor)

​​​​​

​​Denne øvelse kommer man til at lave en del gange i et projektforløb. Projekttrianglen er efter min mening, en meget vigtig figur at forstå mekanismerne i, når man arbejder med projekter.

Alle ”projekters omfang” er ikke ens, men fælles for alle projekter er, at de indeholder de 3 dimensioner, som er illustreret i figur 2 neden for. Forskellen på projekterne og valget af "hammerstørrelsen" ligger i omfanget af hver af de 3 dimensioner.

Figur 1​

Figur 2​

​Opgavens omfang (fra figur 1) afhænger af kompleksiteten i de 3 dimensioner, som er illustreret i figur 2. Dette kan forekomme at være et meget abstrakt begreb, at skulle fastlægge et projekts kompleksitet, men kan det faktisk gøres med de rigtige værktøjer.

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

·​​Hvilke metoder og værktøjer er relevante/nødvendige

·​​Ressourcebehov fra såvel forretning som IT

·​​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.

​Eksempler på væsentlige spørgsmål der er med til at afdække den teknologisk kompleksitet, er:

  1. Valget af teknologi og infrastruktur
  2. Antal løsninger, moduler og komponenter der skal til for at dække scopet
  3. Standard kontra specialudvikling
  4. Kompleksitet i konfigurer og opsætte løsning
  5. Omfanget af uddannelse og træning
  6. Projektledelsens nødvendige omfang
  7. Kontraktens rammer

Ovennævnte skal bruges til at afdække prisen for teknologien.

Figur 3​

Figur 4​

Eksempler på væsentlige spørgsmål der er med til at afdække den procesmæssige kompleksitet, er:

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

Ovennævnte skal bruges til at afdække det forretningsmæssige scope og forventningen til forandringens omfang.

Eksempler på væsentlige spørgsmål der er med til at afdække den procesmæssige kompleksitet, er:

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

​​

Ovennævnte skal bruges til at afdække det forretnings modenhed og forretningens evne til at gennemføre forandringen.

​Figur 5

Figur 6​

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

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-70%”, 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å valideret sit projekt i forhold til de 3 dimensioner i figur 2.

Dette vil give et billede af, hvor mange og hvilke moduler der skal benyttes, for at understøtte den forretningsmæ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.

​​Hvis du sender mig en mail, så vil jeg besvare den, med at fremsende et simpelt værktøj, som du kan bruge til at afdække kompleksiteten i jeres projekt i de 3 dimensioner. Hvis i med sikkerhed ved, at det er et enterprise projekt, vil værktøjet ikke dække, da det er et mere kompliceret værktøj, der så skal bruges

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