Videregående projektledelse
Helt overordnet er Projektkontoret/Programkontoret den enhed i organisationen, som sikrer at projektledelsen fungerer så godt det er muligt. For at få hold på, hvad et Projektkontor eller Programkontor egentlig er, skal vi først se på nogle definitioner. I praksis – i Danmark – har vi set eksempler et lille strategisk rettet PMO, der var ansvarligt for en projekthåndbog med tilhørende procedurer, uddannelse i og videreudvikling af denne, samt via målrettede indsatser bidrog til højnelse af projektkultur m.m. Der er som nævnt delte meninger om, hvad et projektkontor skal indeholde. At følgende elementer kan indgå, er der dog en vis enighed om: 1. Ansvar for projekteringsmanualen og andre værktøjer Forestå og udvikle IT-understøttelsen til projekterne således at projektgennemførelsen løbende optimeres Uddanne og understøtte projektledere, programledere og projektchefer vha. kurser, sparring, coaching, mentoring m.m. Bibliotek og arkiv for samtlige projekter, programmer og al projektrelevant litteratur Assistance til projektledere, programledere og projektchefer ved gennemførelse af projekterne iht. projekteringsmanualen således at projekterne gennemføres så godt som muligt Udvikle og vedligeholde et ledelsesinformationssystem med KPI’er for hele projektportefølgen således at projektledere, programledere, projektchefer og andre interessenter til stadighed har overblik Skabe overblik og basis for at udvælge projektportefølgen således at virksomheden kun har de aktive projekter den ønsker og har ressourcer til at gennemføre Overordnet ressourcestyring for samtlige projekter og programmer Identificere og hjælpe nødlidende projekter Ansvar for alle projekter og programmer, herunder at sikre, at målene nås og de forretningsmæssige resultater realiseres Ansættelse og afskedigelse af projektledere, samt ressourcestyring af projektlederne Uanset indhold er det en kendsgerning, at flere og flere danske virksomheder i disse år indfører en boks på organisationsdiagrammet, hvor der står: PMO.Projektkontoret
I PMIs (Project Management Institute) PMBOK-Guide (Project Management Body Of Knowledge) er et projektkontor (PMO – Project Management Office) defineret som følger (forfatterens oversættelse):
”En organisatorisk enhed, der har fået tildelt forskellige ansvarsområder relateret til centralisering og koordinering af de projekter, der er under dets domæne. Projektkontorets ansvarsområde kan spænde fra at sørge for supportfunktioner til projektledelsen – til faktisk at være ansvarlig for ledelsen af projektet.”
Denne definition er meget bred og knap så håndgribelig. En mere direkte tilgang, er følgende, som er hentet fra en bog om emnet:
”I dets ideelle form skal projektkontoret være for en organisation, hvad lufttrafikkontrollen er for piloter. Det skal sørge for, at projekterne styres sikkert og så hurtigt som muligt til deres destination. Det skal forhindre kollisioner mellem projekter og ressourcer og det skal være såvel projektledernes som ledelsens bedste ven.”
I den anden ende af ”skalaen” har vi set et PMO, som organisatorisk havde projektlederne ”under sig”, samt dermed det fulde ansvar for ledelsen af projekterne, med alt hvad dertil hører.
Endelig må man sige, at ”kært barn har mange navne” for selvom betegnelsen PMO er ved at vinde indpas, ses stadig mange varianter, så som PO (Project/Program Office), PSO (Project/Program Support Office), PCO (Project/Program Control Office) osv.
Om det er Projektkontor eller Programkontor, afhænger af, om der afvikles projekter eller programmer. Et program er defineret således i PMBOK-Guiden:
”En gruppe relaterede projekter, der ledes på en koordineret måde for at opnå resultater og kontrol, der ikke kan opnås ved at lede projekterne individuelt. Programmet kan indeholde elementer af relateret arbejde, som ligger uden for scope (omfang og indhold) af de enkelte projekter, der indgår i programmet.”
Udarbejde, vedligeholde og udvikle projekteringsmanualen og tilhørende værktøjer således at projektgennemførelsen løbende optimeres
Auditering, dvs. kontrol af at de enkelte projekter overholder projektstandarderne
2. Hjælp til projektledere, programledere og projektcheferne
Sekretariatsfunktion for projektledere, programledere og projektchefer
3. Projekt information og kommunikation
4. Ansvar for projekter og programmer
--
Iterativ inspiration til projektmodellerne
Næsten enhver organisation, der udfører projekter, har – eller ønsker sig – en projektmodel. En projektmodel er en overordnet beskrivelse af, hvordan projektet gennemføres og indeholder typisk et antal faser. Ofte er der også nogle betingelser, der skal opfyldes, for at projektet får lov til at gå videre fra en fase til en anden. Disse faseovergange kaldes ”gates” eller på dansk porte eller beslutningsporte.
Den klassiske projektmodel er den såkaldte vandfaldsmodel, hvor vi gennemfører én fase ad gangen, indtil vi er færdige. Ulempen ved denne model er, at det ikke er muligt at gå tilbage. Lad os tage et eksempel:
Projektmodellen består af følgende faser:
- Idéfasen, hvor vi gennemtænker tingene og beslutter om projektet skal gennemføres
- Planlægningsfasen, hvor vi har besluttet, at projektet SKAL gennemføres – og det derfor skal planlægges og specificeres
- Udførelsesfasen, hvor vi udfører projektet og – naturligvis – følger op på om alt går rigtigt til (ellers griber vi ind!)
- Afslutningsfasen, hvor vi afslutter og afleverer projektets resultat, samt opløser projektgruppen
Lad os nu forestille os, at vi er i udførelsesfasen og pludselig finder ud af, at kunden ønsker en stor ændring i projektet. Faktisk burde vi gå tilbage til planlægningsfasen, men det MÅ vi ikke, så vi bruger proceduren for håndtering af ændringer i projektet, og klarer os med den. Enhver projektleder kender dilemmaet: der kommer ALTID ændringer i projektet – enten har vi selv lavet fejl i specifikationen og må ændre, eller kunden har fået nye (og bedre (!)) idéer og kræver ændringer. Proceduren for ændringshåndtering er normalt tilstrækkelig og kendt på f.eks. enhver byggeplads, hvor der ustandselig laves aftalesedler om ændringer – men hvad hvis nu ændringen er FUNDAMENTAL – faktisk en OMMER??
Den tanke er tænkt før og svaret er: ITERATIVE PROJEKTMODELLER!
En iterativ projektmodel er en model, hvor det er tilladt at gå tilbage.
Projektmodellen i eksemplet ovenfor kan sagtens gøres iterativ. I stedet for at se den som en vandfaldsmodel skal den re-tænkes som en cirkulær model! Lad os se på hvordan eksemplet så bliver:
Idéfasen er uændret, men i planlægningsfasen nøjes vi med at planlægge og specificere det vi er sikre på - meget er overladt til senere diskussion. Vi går så i gang med udførelsesfasen, hvor vi – af gode grunde – kun kan udføre det vi har planlagt og specificeret. Når dette er gjort står tingene måske klarere for kunden og os, og vi er i stand til at gå tilbage til planlægningsfasen, hvor vi planlægger og specificerer en bid mere. Herefter til udførelsesfasen – tilbage til planlægningsfasen osv. Til sidst er vi tilfredse og går så til afslutningsfasen.
Der er fordele og ulemper ved at bruge en iterativ projektmodel. En af ulemperne er, at det kan være svært at få de kommercielle forhold på plads, for hvordan afregner man, når (næsten) alt er til diskussion? Her gælder det selvfølgelig om at få lagt nogle faste rammer ind. Omvendt er der også eksempler på projekter, hvor man krampagtigt holdt fast i vandfaldsmodellen og fik et dårligt projektresultat, fordi man ikke så sandheden i øjnene: at det der var planlagt og specificeret fra begyndelsen slet ikke duede.
En af de ”færdige” iterative metoder, der i de senere år har vundet udbredelse er RUP (Rational Unified Process), der er udviklet af the Rational Software Corporation, som er en division i IBM. En anden er (DSDM) Dynamic Systems Development Method, udviklet af DSDM Consortium i Storbritannien. Vi skal ikke her gå dybere ind i disse metoder, da man ved at Google hh. RUP og DSDM kan finde udførlige beskrivelser på nettet – f.eks. i Wikipedia.
Et af de spørgsmål vi her i Research-Firm – i stigende grad – møder fra vores kunder er: Hvad gør vi, hvis vi på den ene side gerne vil holde fast i en projektmodel baseret på nogle af de kendte standarder og normer for projektledelse, som vores projektledere er certificeret i og vores kunder og samarbejdspartnere kender – og PÅ DEN ANDEN SIDE gerne vil indarbejde de iterative principper i vores projektmodel, fordi vi faktisk – i praksis - har brug for netop DEN tankegang?
Svaret er simpelt: Det kan sagtens lade sig gøre og vi arbejder netop i øjeblikket med flere kunder, hvor opgaven er, at integrere det bedste fra begge de omtalte verdener.
Har du lyst til en snak om iterativ inspiration i projektledelse – så er vi klar!