En projekttype er en prædefineret projektkompleksitet, og hvis man matcher en af typerne, kan man beskrive rimelig præcis, hvilke aktiviteter der er nødvendige, for at få succes i projektet.
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 sted på 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.
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:
Denne type projekt er kendetegnet ved følgende karakteristika:
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.
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:
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:
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
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:
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:
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.
I takt med at kompleksiteten øges, stiger kravene til virksomheden. Jo højere kompleksitet, jo større krav til:
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.
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.
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.
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:
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
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
CVR-nummer: 26114144
Østre Kirkevej 30, 7400 Herning
Klik her for rutevejledning
Copyright © 2024 | Moesgaard Consulting ApS
