Mens vi i del 1 tok for oss de grunnleggende aspektene ved et vellykket webprosjekt, tenkte jeg i del 2 å se nærmere på det jeg mener er det viktigste verktøyet for å realisere websatsingen – nemlig prosjektplanen.
Dette kan nok for mange virke smalt og nisjepreget, men med flere års
erfaring med prosjektstyring så vil jeg karakterisere prosjektplanen som
prosjektets skjebne, og jeg vil videre presentere det jeg tror er den
optimale prosjektplan for et webprosjekt.
Hva er en prosjektplan?
Det er mange meninger om hva en prosjektplan er og hvilket omfang den
bør ha. En anerkjent oppfattelse er nok Project Management Institute
(PMI) sin definisjon i boka A Guide to the Project Management Body of Knowledge;
”a formal, approved document used to guide both project execution
and project control. The primary uses of the project plan are to
document planning assumptions and decisions, facilitate communication
among stakeholders, and document approved scope, cost, and schedule
baselines. A project plan may be summarized or detailed."
Kort sagt er prosjektplanen et dokument akseptert av prosjektdeltagerne,
og som benyttes til planlegging, gjennomføring og styring av
prosjektet. Dokumentet bør si noe om forutsetninger, omfang,
kommunikasjon, leveranse, tid og kostnad. Hensikten er å realisere
prosjektet på en smidig og vellykket måte.
En prosjektplan kan være omfattende og detaljert eller enkel og
overordnet. Personlig er jeg fan av en forholdsvis kortfattet plan. Den
bør inneholde kun det nødvendigste og være kjapp å forstå og sette seg
inn i for alle prosjektdeltagerne. To til tre sider mener jeg som regel
er nok.
Hva bør den inneholde?
Så hva bør den optimale prosjektplanen inneholde? Med en cocktail av
vellykkede og mislykkede prosjekter friskt i minne, er det av min
oppfattning at den optimale prosjektplanen bør bestå av følgende:
• Prosjektnavn
• Initiativtaker
• Bakgrunn for prosjektet
• Hensikt og mål med prosjektet
• Prosjektleveranser
• Prioritering
• Organisering og deltagere
• Framdriftsplan
• Budsjett/økonomi
• Risikovurdering
• Kommunikasjon og rapportering
Prosjektnavnet
Kjært barn har mange navn og prosjekter kan kalles så mangt. Tysklands
invasjon av Sovjetunionen under WW2 gikk under navnet ’Operasjon
Barbarossa’, mens byggingen av det nye operahuset i Oslo hadde den
klingende tittelen ’Prosjekt nytt operahus’. Den trønderske klisjeén
”det enkle er ofte det beste” er nok et greit utgangspunkt, og så fremt
prosjektet ikke er ”top secret” ville jeg anbefalt et navn som sier noe
om hva prosjektet faktisk går ut på. Kort sagt.
Initiativtaker
Initiativtaker til et prosjekt er ofte den personen som er ansvarlig
for prosjektet. Både med tanke på økonomi, tid og hva prosjektet skal
levere. Slik sett er det hensiktsmessig for prosjektdeltagerne å vite
hvem vedkommende er, da vedkommende ofte vil være
beslutningstager/prosjekteier.
Bakgrunn for prosjektet
Hensikten med å avklare bakgrunnen for prosjektet er å tydeliggjøre for
prosjektdeltagerne ”hvorfor de gjør det de gjør”. Altså skape en felles
forståelse og gi alle muligheten til å skjønne hvilke utfordringer
prosjektet skal løse.
Hensikt og mål med prosjektet
Hva skal prosjektet oppnå? En tommelfingerregel for prosjektmål kan være SMART’e, altså spesifikke, målbare, avtalte (felles forståelse), realistiske og tidsbegrensede.
Prosjektleveranser
Med utgangspunkt i bakgrunnen for prosjektet og hensikt/mål, bør det
være en grei sak å spesifisere hvilke leveranser prosjektet innbefatter.
Det er flere grunner til å inkludere prosjektleveranser i
prosjektplanen. For det første bryter man opp prosjektet og definerer de
ulike leveransene (gjør det mer oversiktlig). Videre vil man tydeligere
se hva som underveis i prosjektet må godkjennes av
beslutningstager/prosjekteier. Med klart definerte prosjektleveranser er
det også lettere å sette opp framdriftsplan med milepæler og
ansvarspersoner.
Prioritering
Ingen vet hva framtiden bringer, og en ting som er relativt sikkert er
at prosjektet vil endre seg underveis. Det er derfor hensiktsmessig å
foreta en prioritering av hva som er viktigst for prosjektet og
prosjekteier. Prosjekter består som hovedregel av tre overordnede
faktorer; tid, kostnad og kvalitet/leveranse. Endrer man en av
disse faktorene vil det mest sannsynligvis påvirke den ene eller begge
de øvrige faktorene (teorien om The triple constraint). Man bør derfor i
prosjektplanen prioritere disse tre faktorene opp mot hverandre, og
hvem som er viktigst for prosjektet, så kan dette hjelpe
prosjektdeltagerne å ta korrekte beslutninger når man opplever endringer
i prosjektet.
Organisering og deltagere
Et prosjekt vil kunne organiseres på forskjellige måter. Man bør derfor
være tydelig på ansvarsfordeling og samarbeidsprinsipper. Videre er det
nødvendig at nøkkelpersoner for prosjektet stilles til disposisjon, at
prosjektdeltagerne er motiverte, samt at man har rett person som
prosjektleder. Prosjektlederen må være en person som kan lede, og
trenger nødvendigvis ikke å være en teknokrat selv om det dreier seg om
et teknisk prosjekt.
Framdriftsplanen
Framdriftsplanen bør utarbeides med milepæler. De ulike milepælene bør
inneholde hvilke leveranser innfrielse av de ulike milepælene innebærer,
tidsperspektiv, samt hvem som er ansvarlig for innfrielse av milepælen.
I tillegg er det vanlig å knytte milepælene opp mot økonomi – altså
hvilke økonomiske rammer som eksisterer for de ulike milepælene. En
milepæl skal være knyttet til et konkret resultat og er ikke en
aktivitet. Formålet med milepælene er å kunne kontrollere hvordan man
ligger an i forhold til tid, kostnad og kvalitet/leveranse. Slik sett er
milepælene et viktig styringsverktøy for prosjektet.
Budsjett/økonomi
Prosjektøkonomi er et eget og forholdsvis omfattende fagområde. For
prosjektplanen bør det være en relativ forenklet tilnærming.
Prosjektdeltagerne bør få kjennskap til de økonomiske rammene for
prosjektet og de bør få vite hvilke ressurser som er knyttet til de
ulike leveransene/milepælene. Slik vil man fortløpende kunne kontrollere
hvordan man ligger an i forhold til de økonomiske rammene man er
tildelt, slik at man på best mulig kan håndtere avvik om dette skulle
oppstå.
Risikovurdering
Med erfaring og kjennskap til Murphy’s lov om at ”alt som kan gå galt
vil gå galt” er det hensiktsmessig med en risikovurdering av prosjektet.
For prosjektplanens del anbefaler jeg at man prøver å identifisere alle
aktuelle risikoelementer. Videre bør man se på sannsynligheten for at
de inntreffer (høy eller lav?), samt hva konsekvensen vil være om
faktoren skulle inntreffe (stor eller liten?). På bakgrunn av denne
vurderingen vil man kunne identifisere de mest vesentlige
risikoelementene, for så å se på hvilke tiltak man kan iverksette for å
redusere sannsynligheten for at de inntreffer, samt aktuelle tiltak om
de skulle inntreffe.
Rapportering
God kommunikasjonen før, under og etter et prosjekt er en viktig
suksessfaktor. Spesielt når mange mennesker fra ulike organisasjoner
skal jobbe sammen. Man bør derfor ha klare retningslinjer for dialogen.
En miks av SMS, e-post, post-it lapper, MSN og A4-ark er som regel ingen
god løsning. I dag finnes det heldigvis en rekke gode webbaserte
løsninger for denne type kommunikasjon. Løsninger som kan være med å
forenkle dialogen, rapporteringen og dokumentasjonen av et prosjektet.
For prosjektplanen sin del er det derfor viktig at man sier noe om
hvilket verktøy som skal benyttes, i hvilken form kommunikasjonen skal
foregå, samt hva som skal dokumenteres i prosjektet.
Gjennom artikkelen håper jeg at du har fått øynene opp for viktigheten
av god prosjektplanlegging, og at en prosjektplan kan være et godt
utgangspunkt og verktøy for nettopp dette. Og husk; En god plan i dag er
bedre enn en perfekt plan i morgen!