PROJEKTTYPER

Vil du lykkes med dit it-projekt, er det vigtigt, at du helt fra starten gør dig klart, hvilken type projekt du sætter i gang.

De værktøjer og metoder, du kommer til at bruge undervejs, vil i høj grad være ens, men her stopper ligheden også. Du skal gribe de forskellige projekttyper meget forskelligt an.

I min optik er der, når vi taler it-projekter, 5 væsentlige projekttyper, du skal tage højde for:

​Et andet sted på denne hjemmeside kan ses nogle eksempler på spørgsmål, som kan være med til at afdække hvilken type dit projekt er.

Tilgangen til hvorledes projektmodellen skal bruges, til de projekttyper som er illustreret nedenfor, kan ses et andet stedpå denne hjemmeside.  

De 2 typer projekter som jeg primært vil beskæftige med på denne hjemmeside, er Enterprise-projekter (større projekter) og Proces-projekter (mellemstore projekter). Begge projekttyper er kendetegnet ved, at IT’en kun er et værktøj, som skal understøtte en større forandring i såvel organisation som processer.

Figur 1​

Figur 2

​​HVILKEN TYPE PROJEKT STÅR DU OVER FOR?

Igennem årene har jeg set flere IT-projekter fejle, fordi både virksomheden selv og teknologi-partneren undervurdere projektets kompleksitet.

Lad mig kort skitsere, hvordan og hvorfor kompleksiteten øges i de tre forskellige projekttyper. Det kan give dig en pejling på, hvilket projekt du står med:

BUSINESS IN A BOX

Denne type projekt er kendetegnet ved følgende karakteristika:

  1. ​Entreprenør og opstartsvirksomhed
  2. ​Typisk 0 til 10 ansatte
  3. ​Skal ofte blot have løst de basale økonomiske discipliner
  4. ​Meget vel pakketeret branchepakke som er prækonfigureret og ”låst”
  5. ​Det vil sige, der er ingen udvikling til kundens forretning

Det fremgår af figur til højre, hvilke faser der typisk benyttes af modellen.

​Udstrækningen fra igangsættelse af anskaffelsen til færdigimplementering vil sandsynligvis være 6-9 måneder.

Projekttypens kompleksitet er illustreret i figur 2. Eksempler på spørgsmål der kunne præciserer den teknologiske kompleksitet, kan ses her.​​

​​

PROCESPROJEKT

Allerede her sker der et skred i kompleksiteten, og det giver mening at tale om to forskellige varianter af procesprojekter.

​Denne type projekt er kendetegnet ved følgende karakteristika:

  1. ​​Typisk 10 til 30 bruger
  2. ​ERP’en kan ofte dække alle væsentlige løsningsområder i værdikæden (Eksempel er PDM, ERP, WMS, PIM og WWW
  3. ​Mindre teknologisk kompleksitet da forretningen adoptere standardløsningen
  4. ​Ingen udvikling
  5. ​Kræver en ”branche-pakke” og/eller brancheindsigt af leverandøren

Det fremgår af figuren til venstre, hvilke faser der typisk benyttes af modellen.

​Udstrækningen fra igangsættelse af anskaffelsen til færdigimplementering vil sandsynligvis være 9-12 måneder.

Denne type projekt er kendetegnet ved følgende karakteristika:

  1. ​​Typisk 30-50 bruger og dermed større forretningsmæssig kompleksitet
  2. ​Den teknologiske kompleksitet derfor typisk større
  3. ​Ambitionen gør, at der ofte skal bruges mere end en væsentlig ”løsninger” (Eksempel PDM, ERP, WMS, PIM, WWW)
  4. ​Marginal udvikling er stadig en forudsætning
  5. ​Forandringer og business casen bliver et emne

Det fremgår af figuren til venstre, hvilke faser der typisk benyttes af modellen.

​Udstrækningen fra igangsættelse af anskaffelsen til færdigimplementering vil sandsynligvis være 18-24 måneder. Meget afhængig af egen projekt- og procesmodenhed, og antallet af løsninger der skal implementeres.

Projekttypens kompleksitet er illustreret i figur 3. Eksempler på spørgsmål der kunne præciserer den procesmæssige kompleksitet, kan ses her

Figur 3


Figur 4

ENTREPRISEPROJEKT

Nu taler vi forandringsprojekter, der påvirker organisationen og måden at arbejde på. Igen er der to niveauer af kompleksitet.

​​

Denne type projekt er kendetegnet ved følgende karakteristika:

  1. ​​Typisk 50-100 og dermed både større procesmæssig og organisatorisk kompleksitet
  2. Ingen eller minimal koncernstruktur
  3. ​Ambitionerne gør, at der ofte skal flere væsentlige ”løsninger” til (Eksempel er PDM, ERP, WMS, PIM, POS, WWW)
  4. Ofte nogen udvikling men helst mindre end 5%
  5. Punkt 1 og 2 samt større kritisk masse medfører større teknologiske kompleksitet end i PP2
  6. Stor forandring og business casen bliver et emne – it er kun et værktøj

​​Det fremgår af figur til højre, hvilke faser der typisk benyttes af modellen.


​Udstrækningen fra igangsættelse af projektinitiering til færdigimplementering vil sandsynligvis være 24-36 måneder. Meget afhængig af egen projekt- og procesmodenhed, og antallet af løsninger der skal implementeres.

Denne type projekt er kendetegnet ved følgende karakteristika:

  1. ​​Typisk 100+ bruger
  2. ​Koncernstruktur dermed større kompleksitet i alle 3 dimensioner
  3. ​Ofte skal 5-6 væsentlige løsninger til (Eksempel er PDM, ERP, WMS, PIM WWW, POS)
  4. ​Ofte en del udvikling men helst mindre end 5%
  5. ​Punkt 1 og 2 samt større kritisk masse medfører større teknologiske kompleksitet end i EP1
  6. Radikale forandringer et must
  7. Opfølgning på business case

​​​

Det fremgår af figur til højre, hvilke faser der typisk benyttes af modellen.

​​

​Udstrækningen fra igangsættelse af projektinitiering til færdigimplementering vil sandsynligvis være 36-48 måneder. Meget afhængig af egen projekt- og procesmodenhed, og antallet af løsninger der skal implementeres.

Projekttypens kompleksitet er illustreret i figur 4. Eksempler på spørgsmål der kunne præciserer den organisatoriske kompleksitet, kan ses her.

Det vil altid være karikeret med en så simpel opdeling. Ikke desto mindre giver det en pejling på projektets kompleksitet, hvilket er vigtigt at have bevidsthed om, når du planlægger din tilgang.

Jeg har igennem årene udviklet en projektmodel, der tager højde for, hvilke metoder og værktøjer, der skal i spil undervejs i projektet afhængigt af projekttype. Læs mere på siden for projektmodel, hvor jeg også skitserer modellens anvendelse i de forskellige projekttyper.

HVAD BETYDER GRADEN AF KOMPLEKSITET?

I takt med at kompleksiteten øges, stiger kravene til virksomheden. Jo højere kompleksitet, jo større krav til:

  • ​Projekt- og procesmodenhed
  • ​Forståelse for nødvendige roller og kompetencer
  • ​Evne til ressourcefrigørelse af nøglemedarbejder

Negligerer du disse væsentlige parametre tilfører det projektet væsentlige risici. Risici, som i sidste ende kan resultere i, at de klassiske udfordringer indtræder og i værste fald fejler projektet.

Sådan skaber du klarhed

Der er flere værktøjer du kan benytte dig af, når du scoper dit projekt. Det handler om at blive helt klar på ambitioner og kompleksitet. Jeg har selv gode erfaringer med at anvende forskellige strukturerede tilgange, som sikrer besvarelsen af vigtige spørgsmål omkring ambitioner, forretningen og virksomhedens processer.

Jeg benytter mig især af følgende grundværktøjer til scoping af projekter:

Ved mindre projekter kan det være tilstrækkeligt at arbejde med AKR-modellen mens større projekter vil kræve, at du også kommer struktureret rundt om forretning og processer med hhv. FKR og PCF.

Hvad kræver de forskellige projekter?

Hvor lang tid tager det? Hvad kræver det af min organisation? Væsentlige spørgsmål at stille. Ofte svære at besvare. Omfang og forløb er absolut væsentlige faktorer og i skemaet til højre har du mit bedste gæt på udstrækning i de forskellige projekttyper.

Den lange udstrækning og de mange timer ved projekter med øget kompleksitet skyldes, at der ofte er tale om at udvikle og implementerer en it-strategi, mere en der er tale om en egentlig ERP-implementering.

Et gæt på udstrækning af projektet, beregnet på basis af den kritiske vej, antallet af metoder og værktøjer der skal bruges, samt et estimat på hvad jeg skal bruge af sparringstid i projektet, kan ses til højre i figur 5.

Har du brug for sparring?

Nogle gange er der brug for en afklarende snak om projekttype, scoping af virksomhedens IT-projekt eller valg af projektmetode. Kontakt mig gerne.

​​

Noget af det, der påvirker omfanget af moduler, udstrækning og timetal er blandt andet behovet for at:

  • Analysere de reelle muligheder for at udvikle forretningen og udarbejdelsen af et præcist scope
  • Gøre forretnings mulighederne handlings orienterede
  • Forberede organisationen på forandringen
  • Tage højde for en stor grad af forandringsledelse
  • Følge op på forandringen

Hvorvidt en IT-leverandør forstår, og/eller skal understøtte de enkelte moduler, metoder og værktøjer, der skal sikre ovennævnte, afhænger selvfølgelig af den enkelte leverandørs projekt- og proces-modenhed.

Min påstand er, at det spænder fra 35% til 65% af moduler, metoder og værktøjer, som IT-leverandøren ikke kan/skal involveres i de komplekst projekttyper (PP2, EP1 og EP2).

I de mindre komplekse projekter (BIB og PP1) sikres dette af en intern projektleder eller energiske nøglemedarbejdere. I de større projekter (PP2, EP1 og EP2) bliver denne opgave så stor, så det kræver specifikke roller og kompetencer i virksomheden. Hvis disse ikke er tilstede, fejler projektet ganske simpelt, og de klassiske udfordringer indtræder

Har Proces- og Enterprise-projekter overhovedet noget fælles?

​De 2 projekttyper har fundamentalt rigtig meget fælles, men skal grundlæggende gribes meget forskelligt an. Det som er fælles, er de strukturerede metoder og værktøjer, som kan understøtte og accelererer videns opsamlingen.

De strukturerede værktøjer som jeg benytter, kan ses et andet sted på denne hjemmeside

​​​​​

​Jeg har f.eks. sammen Dansk Mode & Textil, udviklet værktøjerne baseret på den viden og de erfaringerne som jeg har fra en del entreprise-projekterne i fashion-branchen.

Projekttyper er nogle eksempler på nogle pre-konfigureret projektkompleksiteter.  I kompleksitets afsnittet får du et lidt større indblik i og eksempler på, hvorledes man eksempelvis kan fastlægge et projekts kompleksitet.

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