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 teknologi-projekter, tre forskellige projekttyper, du skal tage højde for:

​Til højre er en figur der illustrer de 3 typer it-projekter. 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.

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:

  • ​Entreprenør- og opstartsvirksomheder
  • ​Typisk 0-10 ansatte
  • ​Skal ofte blot have løst de basale økonomiske discipliner

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.

Procesprojekt 1 (PP1):

  • ​Typisk 10-30 brugere
  • ​Mindre teknologisk kompleksitet, da forretningen adopterer standardløsningen

Procesprojekt 2 (PP1):

  • ​Typisk 30-50 brugere og derved større kompleksitet
  • ​Større teknologisk kompleksitet
  • ​Større kompleksitet gør, at der ofte skal mere end én løsning til for at understøtte virksomhedens produktlivscyklus.
  • ​Forandringer og business casen bliver et emne.

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

​​

ENTERPRISEPROJEKT

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

Enterpriseprojekt 1 (EP1):

  • ​Typisk 50-80 brugere, men ingen koncernstruktur og dermed reduceret kompleksitet
  • ​Større teknologisk kompleksitet gør, at der ofte skal flere løsninger til for at understøtte virksomhedens produktlivscyklus (større kritisk masse)
  • ​Teknologisk kompleksitet typisk større end i PP1
  • ​Forandringer og business casen er et emne

Enterpriseprojekt 2 (EP2):

  • ​Typisk 100+ brugere og koncernstruktur, hvilket øger kompleksiteten
  • ​Større komplesitet gør, at der ofte skal 5-6 løsninger til for at understøtte virksomhedens produktlivscyklus
  • ​Den teknologiske kompleksitet bliver typisk større i denne end i EP1
  • ​Radikale forandringer er et “must” og opfølgning på business case nødvendig.

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 væ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 i disse projekttyper.

I de mindre komplekse projekter (BIB og PP1) sikres dette af en intern projektleder eller energiske nøglemedarbejdere. I de større projekter 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.

Baseret på besvarelse af nogle få strukturspørgsmål kan relativt hurtigt opnås et overblik i en lille eller mellemstore fashion-virksomheder over hvilke processer og kritiske områder, der er væsentlig at få bearbejdet ved anskaffelse af nyt it og ved en større forandring. Jeg har nogle tilsvarende værktøjer, i de andre brancher jeg har arbejdet i

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