# P3.express Den minimalistiske metoden for prosjektledelse [image] Dette en en nedlastbar versjon av online boka. (https://omimo.org/no/), generert på 2026‑07‑02. Sjekk gjerne websiden for en nyere versjon. Denne boka kan brukes og distribueres fritt under Creative Commons Navngivelse 4.0 Internasjonal lisens OMIMO er delfinansiert av Den europeiske union. Synspunktene og meningene som uttrykkes er imidlertid utelukkende OMIMOs egne og gjenspeiler ikke nødvendigvis synspunktene til Den europeiske union eller EPOS VZW. Verken Den europeiske union eller tilskuddsmyndigheten kan holdes ansvarlig for dem. Oversatt av Terje Hult, med god hjelp fra Brendan Martin, Geraldine Sletten og Øivind Haugland ## Aktivitetsliste Liste over ledelsesaktiviteter: - Prosjektstart - A01 – Utnevn prosjekteieren - A02 – Utnevn prosjektlederen - A03 – Utnevn sentrale medlemmer i prosjektteamet - A04 – Beskriv prosjektet - A05 – Identifiser og planlegg leveranser - A06 – Identifiser usikkerheter og planlegg tiltak - A07 – Få oppstarten av prosjektet fagfellevurdert - A08 – Avgjør om prosjektet skal fortsette eller ikke - A09 – Sett i gang prosjektet - A10 – Gjennomfør en tydelig kommunikasjon - Månedsstart - B01 – Revider og detaljer planene - B02 – Få den månedlige syklusen fagfellevurdert - B03 – Avgjør om prosjektet skal fortsette eller ikke - B04 – Sett i gang den månedlige syklusen - B05 – Gjennomfør en tydelig kommunikasjon - Ukentlige aktiviteter - C01 – Mål og rapporter fremdrift - C02 – Planlegg avvikstiltak - C03 – Sett i gang den ukentlige syklusen - C04 – Gjennomfør en tydelig kommunikasjon - Daglige aktiviteter - D01 – Håndter usikkerheter, hendelser og forespørsler om endringer - D02 – Aksepter ferdige leveranser - Månedsavslutning - E01 – Evaluer interessentenes tilfredshet - E02 – Registrer erfaringer og planlegge forbedringer - E03 – Gjennomfør en tydelig kommunikasjon - Prosjektavslutning - F01 – Overlever produktet - F02 – Evaluer interessentenes tilfredshet - F03 – Gjennomfør en fagfellevurdering av avslutningsaktivitetene - F04 – Arkiver prosjektdokumentasjonen - F05 – Feire! - F06 – Gjennomfør en tydelig kommunikasjon - Aktiviteter etter prosjektet - G01 – Evaluer gevinstene - G02 – Skap nye ideer - G03 – Gjennomfør en tydelig kommunikasjon ## Introduksjon P3.express bruker en enkel prosess, som vist i diagrammet ovenfor. Denne prosessen består av 33 ledelsesaktiviteter i 7 grupper. Klikk på en av aktivitetene i diagrammet for å åpne beskrivelsen, eller bare start med den første aktiviteten, A01. ### Prinsipper Arbeidet som gjøres i et P3.express prosjektet skal følge Principes Quasi Universels de Projets (NUPP). P3.express er spesielt designet for å gjøre dette. ### Organisasjon Det er et ledelsesteam som er ansvarlig (responsible) for alle ledelsesaktivitetene. Dette teamet består av ett eller flere medlemmer, avhengig av størrelse og kompleksiteten på prosjektet, prosjektlederen leder teamet og er hovedansvarlig (accountable) for aktivitetene. Denne personen rapporterer til den eksterne prosjektlederen hos kunden (hvis denne finnes) og til prosjekteieren. Prosjekteieren er en intern sponsor som er ansvarlig for det endelige resultat av prosjektet, finansieringen av prosjektet, at prosjektet får tilstrekkelige ressurser m.m. Det finnes ett eller flere produksjonsteam i prosjektet. Hvert av de interne produksjonsteamene (med teammedlemmer fra egen organisasjonen) ledes av en teamleder, som rapporterer til deres egne funksjonelle ledere (hvis noen) og til prosjektlederen. Hvert av de eksterne produksjonsteamene (leverandørene) ledes av en prosjektleder fra leverandøren, som rapporterer til deres interne ledere og til prosjektlederen. ### Dokumenter Dette er de dokumentene som finnes i P3.express: - Prosjektbeskrivelse (mal) - Produktkart - Oppfølgningsregister (mal) - Helseregister (mal) Malene kan brukes slik de er, eller som et utgangspunkt når man skal tilpasse dette til egen organisasjon. Det er viktig å ha ett sentralt sted for all dokumentasjonen, som det må tas backup av jevnlig, og som er tilgjengelig selv om man ikke sitter lokalt, men med krav om både autentisering og autorisasjon. Hvis man ikke har et slikt lagringssted, så finnes det private skybaserte løsninger som dekker disse behovene: - nextcloud - Cryptpad Hvis teamet ikke er på samme lokasjon, så trenger man også en chat platform, og her har et forslag til slike: - élément - rocket.chat Det er viktig at man umiddelbart registrerer usikkerheter, hendelser og forespørsler om endringer i Oppfølgningsregisteret. Det er derfor viktig at man har et system som gjør tilgangen til dette registeret så enkel som mulig, også fra mobiltelefonen. Hvis det ikke er mulig å registrer disse med en gang, må man ha en personlig journal hvor de kan legges inn og at de så flyttes til Oppfølgningsregisteret så fort som mulig. Her er et forslag til slike plattformer: - Joplin - Notes standard - Turtl ### Tilpasning Man må gjerne gjøre endringer i P3.express for å tilpasse metoden til omgivelsene den skal fungere i, men vær forsiktig slik at man ikke ødelegger tanken bak det opprinnelige systemet. Gjør ting så enkelt som mulig. Det er normalt best å starte med å bruke P3.express slik den var tiltenkt, og så justere gradvis i henhold til behovet. Så må disse valgene avgrenses ved å gjennomføre revisjoner, og basere videre tilpasning på dem. ### Perspektiv Hvis man hverken har eksterne kunder eller leverandører, så vil det bare være ett perspektiv på prosjektet. Alternativt så vil hver enkelt organisasjon som er involvert ha sitt perspektiv på prosjektet. Alt i P3.express skal sees fra ditt perspektiv i prosjektet, f.eks når du beskriver begrunnelsen for prosjektet i Prosjektbeskrivelsesdokumentet, så beskriver du din egen begrunnelse, og ikke begrunnelsen som den eksterne kunden har for prosjektet. P3.express er ikke ett enkelt system som skal brukes av alle som er involvert i prosjektet, men et system du bruker for å administrere prosjektet innenfor dine egne grenser. I tillegg til å tenke perspektiv når du jobber med dokumentene må man også vurdere perspektivet når man tenker på rollene. Du er kanskje prosjektleder i ditt perspektiv, men sees på som «prosjektleder fra leverandøren» fra kundens ståsted, eller en «prosjektleder fra kunden» sett fra leverandøren sitt ståsted. ### Historien bak Den første versjonen av P3.express ble publisert i juni 2016, og den ble fulgt av 2 mindre revisjoner i 2018 og 2020. Utkastet til versjon 2 av P3.express ble publisert i mars 2021 for å få inn eksterne synspunkter, og så ble den endelige versjonen utgitt i mai 2021. ## A01 - Utnevn prosjekteieren [image] Den første aktiviteten i prosjektet er å utnevne en leder som har litt innflytelse, eller helst et styremedlem, som prosjekteier. Prosjekteieren er den øverste rollen i prosjektet og prosjektleder rapportere til denne. Prosjekteieren er: - Hovedansvarlig for lønnsomheten og effekten av prosjektet. - Ansvarlig for å ta de store beslutningene i prosjektet. - Ansvarlig for at prosjektet er riktig finansiert og at det har nok ressurser. ### HENSIKT Det er nødvendig å ha rollen prosjekteier fordi: - Prosjektlederen skal ha fokus på de daglige oppgavene og produktet som prosjektet skal lage. og har derfor hverken tid eller energi til å håndtere de store beslutningene i prosjektet. - Prosjektledere har kanskje ikke nok myndighet innad i organisasjonen for å allokere ressurser til prosjektet eller har ikke nok strategisk innsikt til å sørge for at prosjektet er samkjørt med resten av organisasjonen. ### VANLIGE FALLGRUVER Det vi må tenke på når vi velger prosjekteier er: - Prosjekteieren kommer ikke til å bruke mye tid på prosjektet, men trenger å være noe involvert og sette av noe tid til prosjektet. - Prosjekteieren må føle et eierskap til prosjektet og være klar til å beskytte det, men må heller ikke nøle med å stoppe det hvis lønnsomheten forsvinner. - Dersom det er mulig bør en ikke ha kun én person som prosjekteier for alle prosjektene, fordi alt har en tendens til å endre seg og dermed kan selve formålet for prosjektet forsvinne. - En bør ikke ha samme person som prosjekteier og prosjektleder for det samme prosjektet (unntatt om det er 1-manns prosjekt) fordi vedkommende ellers lett kan blir for opptatt av de konkrete oppgavene som prosjektleder og glemme de mer abstrakte oppgave som prosjekteier. - Prosjektlederen eller prosjekteieren bør ikke drive med detaljstyring ## A02 - Utnevn prosjektlederen [image] Så vil prosjekteieren diskutere prosjektet med flere mulige prosjektledere og kommer til enighet med disse. Det er viktig at prosjektlederen har troen på prosjektet og ser at prosjektmålene er oppnåelige. Dersom det er et internt prosjekt (uten eksterne kunder), skal prosjektlederen komme fra virksomhets- eller ledelses-siden av organisasjonen og ikke fra den tekniske siden. Ledere fra det tekniske siden blir teamledere i P3.express. Ved siden av å realisere prosjektmålene og resultatene er også prosjektlederen ansvarlig for helse og sikkerhet for prosjektteamet, og for å skape et godt arbeidsmiljø for dem hvor de også kan videreutvikle sine egne karrierer. ### HENSIKT Selv om det er mulig for små team og ha distribuerte systemer for prosjektledelse, så er det mere praktisk og produktivt for de fleste prosjekter å ha en sentralisert koordinering og at prosjektlederen er sentral i denne koordineringen. På den måten slipper de tekniske eksperten å bli forstyrret av ansvar for prosjektledelse og kan heller holde fokus på de tekniske aspektene ved prosjektet. ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - Prosjektlederen må aldri seg på seg selv som sjefen til teammedlemmene, men heller som en støtte, fasilitator, koordinator og problemløser for dem. - Prosjektlederen eller prosjekteieren bør aldri drive med detaljstyring. - Det er vanlig å utnevne den beste tekniske eksperten som prosjektleder, men det er ikke en god ide. Prosjektleder er en ledelses rolle og ikke en teknisk rolle og en trenger derfor en person med kunnskap og evne til å lede prosjektet. Det å bli utnevnt som prosjektleder må aldri sees på som en forfremmelse, men heller som et bevisst karrierevalg. - Prosjektledere bør aldri involvere seg i de tekniske aspektene i prosjektet fordi det bare avleder dem. Det finnes allerede tekniske eksperter som tar seg av dette i prosjektet. ## A03 - Utnevn sentrale medlemmer i prosjektteamet [image] Nå setter prosjektlederen i gang med å sette sammen et team for hele prosjektet (prosjektteamet). Selv om prosjektet hverken er formelt godkjent eller har startet, så trenger man disse for å bli ferdig med alle aktivitetene rundt prosjektstart. Disse utnevnelsen regnes ikke som midlertidige for det forventes at disse fortsetter i rollene, og deltar i prosjektet når det startes. De medlemmene i prosjektteamet som vi trenger på dette punktet er: - Medlemmene i prosjektteamet. - Teamlederne (for de interne produksjonsteamene). - Leverandørenes prosjektledere (for eksterne produksjonsteam). - Noen av de tekniske deltagerne i produksjonsteamene. ### HENSIKT En av hensiktene med disse aktivitetene er å evaluere lønnsomheten for prosjektet, og den brukes til å avgjøre hvorvidt det er fornuftig å starte med prosjektet. Denne informasjonen baserer seg på en overordnet plan og for å få til det kreves det at eksperter på mange fagfelt samarbeider. Gjør man ikke dette skikkelig så vil man oppleve at gode prosjekter avvises, og at dårlige prosjekter godkjennes. ### VANLIGE FALLGRUVER Noen ser ikke hensikten med å jobbe i et prosjekt som kanskje ikke skal startes. Prosjektlederens oppgave er da å sørge for at alle forstår at dette tross alt er et viktig arbeid fordi dette gir dem en mulighet til å velge de gode prosjektene, som så vil være en lønnsom investering for organisasjonen. Selv om prosjektet blir avvist så er heller ikke innsatsen bortkastet, fordi man reddet organisasjonen fra å starte et prosjekt som ikke var lønnsomt. Når det gjelder det å utnevne eksisterende personer i prosjektet kontra det å leie inn nye, så vil organisasjonens styringssett spille en stor rolle. Det er ansvaret til prosjekteieren å gjøre det mulig for prosjektlederen å ha noe påvirkning når det gjelder disse valgene. ## A04 - Beskriv prosjektet [image] Gjennomfør en workshop for å samle all nødvendig informasjon og skriv Prosjektbeskrivelsen, som bør inneholde: - Hensikten og forventede gevinster. - Forventet kostnad og tidsbruk. - Kravene til og forventninger om kvalitet. - En overordnet beskrivelse av hva som skal, og hva som ikke skal, være med i prosjektet. - En liste over interessenter. Siden noe av denne informasjonen ikke er tilgjengelig på dette tidspunktet i prosjektet, så bør en heller konsentrere seg på det man vet pr nå og legge til mere informasjon på et senere tidspunkt. For dette dokumentet vil uansett bli både revidert og mere detaljert utover i prosjektet. Hvis et tilsvarende prosjekt er gjennomført tidligere er det lurt å sjekke hva som ble arkivert fra dette, og bruke det for å få en mere realistisk beskrivelse av prosjektet. Mal for Prosjektbeskrivelse ### HENSIKT Dette dokumentet hjelper prosjektteamet med å være i samsvar med de overordnede målene for prosjektet gjennom hele gjennomføringen. Dokumentet er også en god ressurs for nye medlemmer i teamet, ledere eller andre som ikke er en del av prosjektteamet, men som allikevel ønsker å forstå hva prosjektet handler om. ### VANLIGE FALLGRUVER Det er en passende grad av detaljering og nøyaktighet i dette dokumentet, og det nivået er normalt lavere enn hva de som skal gjennomføre prosjektet antar. Sørg for å lage et dokument som kan brukes, fremfor det å bare ha forutinntatte meninger om hva som trengs av informasjon for å lede et prosjekt. Beskriv alt klart og kort, og unngå typiske organisasjonsmessige erklæringer som egentlig ikke sier noe som helst. ## A05 - Identifiser og planlegg leveranser [image] Gjennomfør en workshop for å vise hvordan produktet ser ut når det brytes ned i de enkelte leveransene og om nødvendig skriv ytterligere kommentarer for å utdype omfang, kvalitet eller andre viktige faktorer ved disse. Denne informasjonen lagres i Produktkartet, men hva slags format dette skal ha er likegyldig og en type tankekart vil fungere. Produktkartet kan utdypes videre ved å vise avhengigheter mellom de forskjellige leveransene. Dersom det er mange avhengigheter, lages en tidsplan basert på avhengighet og estimert varighet for hver leveranse. Er det derimot få avhengigheter så prioriteres leveransene etter et sett med kriterier og velges ut ifra disse, men med rom for improvisasjon, for det er bedre enn å følge en vedtatt tidsplan slavisk. Mange prosjekter kan med fordel bruke en tilnærming basert på avhengighet for leveranser på et høyt nivå i Produktkartet, og basert på prioritert på et lavere nivå. Hvis tilsvarende prosjekter har blitt gjennomført tidligere, så sjekk de arkiverte dokumentene og bruke den informasjonen for å lage et bedre Produktkart. Basert på det som gjøres her så kan det hende at en må endre litt på Prosjektbeskrivelsen. Mal for Prosjektbeskrivelse ### HENSIKT Selv om det er nødvendig å lage en Prosjektbeskrivelse som prosjektet forholder seg til, så er den ofte abstrakt og vanskelig å bruke i det daglige arbeidet. Produktkartet, som er en ganske konkret ressurs, hjelper til med å gjøre omfanget til prosjektet lettere å forholde seg til. Produktkartet er også et utgangspunkt til det som blir en form for tidsplan for prosjektet, som også vil være en ressurs når vi senere skal bestemme hva som gjøres og når fremdrift i prosjektet skal måles. ### VANLIGE FALLGRUVER Det er vanlig at de som gjennomfører prosjekter tenker «arbeid» i istedenfor «leveranser» når man lager Produktkartet. Det kan derfor være nødvendig å gjennomføre en workshop for å hjelpe alle til å ha søkelyset på leveranser. For å sikre et best mulig resultat fra vår workshop er det også lurt å bruke substantiver og ikke verb når leveranser beskrives. Bruken av et tankekart kan også hjelpe ved å gi et hierarkisk bilde av hvordan leveransene henger sammen. ## A06 - Identifiser usikkerheter og planlegg tiltak [image] Gjennomfør en workshop med nøkkelmedlemmene for først å identifisere usikkerheter, og deretter planlegge tiltak mot disse, og legg alt dette inn i Oppfølgningsregisteret. Basert på de usikkerheter en finner, og hvilke tiltak en planlegger så må kanskje både Prosjektbeskrivelsen og Produktkartet oppdateres. Dersom et tilsvarende prosjekt har blitt gjennomført tidligere så sjekk all informasjonen som ble lagret for å lære mere om usikkerheter som kan knyttes til dette prosjektet. Mal for Oppfølgningsregister Mal for Prosjektbeskrivelse ### HENSIKT Den viktigste hensikten til å identifisere usikkerheter er for å kunne planlegge tiltak på forhånd, fordi det er både enklere og billigere å kontrollere usikkerheter før de skjer, enn å måtte reagere i ettertid. ### VANLIGE FALLGRUVER Disse punktene hjelper til med å unngå de vanligste fallgruvene i usikkerhetshåndtering: - Ikke registrer vanlige uklare ting som usikkerhet. - Ikke registrer vanlige uklare ting som tiltak mot usikkerhet – lag bare usikkerhetstiltak som kan gjennomføres og evalueres. - Ikke registrer en mulig innvirkning av en usikker hendelse som usikkerhet – det er de usikre hendelsene i seg selv som skal evalueres, og de kalles usikkerheter. - Pek ut en ansvarlig som har ansvaret for å følge opp hver enkelt usikkerhet. Det er bedre å spre ansvaret på flere teammedlemmer enn bare på noen få av dem. ## A07 - Få oppstarten av prosjektet fagfellevurdert [image] Nå er oppstarten av prosjektet nesten ferdig og det er på tide å spørre en annen prosjektleder i organisasjonen om å hjelpe til med å vurdere det som er gjort så langt. Resultatet av denne vurderingen legges inn i Helseregisteret. Hvis det blir lav poengsum så må en bruke mere tid på de aktivitetene som er gjennomført før en går videre med prosjektet. Men vel så viktig er å finne ut hvorfor det ble så lav score og finne ut hvordan en kan unngå det neste gang. Mal for helseregister ### HENSIKT Hensikten med denne aktiviteten er å ta en fot i bakken for å sjekke ut om det en holder på med er det rette. Det å kunne ha en uavhengig person som skal sjekke arbeidet er absolutt en fordel fordi prosjektlederen selv sitter alt for tett på for å se de utfordringene som eventuelt finnes. Dette gir også personer som leder andre prosjekter i organisasjonen en mulighet til å se på hverandres arbeid og lære av det. ### VANLIGE FALLGRUVER En utfordring er at personer som gjennomfører denne vurderingen nøler med å peke på problemer, fordi de frykter at det blir tatt personlig. Det er opp til prosjektleder å skape et så godt forhold til dem at de tør være komfortable og ærlige. ## A08 - Avgjør om prosjektet skal fortsette eller ikke [image] Nå sender prosjektlederen prosjekt dokumentasjonen til prosjekteieren og prosjekteieren bestemmer om prosjektet skal fortsette eller ikke. For å ta denne beslutningen så må kanskje prosjekteieren diskutere dette med andre beslutningstakere i organisasjonen, slik som porteføljestyret – men det er opp til prosjekteieren å avgjøre dette og ikke prosjektlederen. Hvis prosjektet har en ekstern kunde og prosjektet er et svar på en forespørsel fra en kunde må prosjekteier, i tillegg til å avgjøre hva som skal skje med prosjektet, også sende forslaget til kunden og avvente deres valg av leverandør før det tas en beslutning. Denne aktiviteten er ferdig når kontrakten er signert, eller det er inngått en annen form for juridisk binding. Hvis det skal brukes eksterne leverandører, som ble valgt i A05, så vil det muligens bli inngått kontrakter med dem nå. Andre leverandører kan dog velges og kontrakter med dem inngås senere på ad hoc basis. ### HENSIKT Prosjekter som har eksterne kunder, må alltid ha klare beslutninger på hvorvidt de skal gå videre eller avsluttes. De interne prosjektene mangler noen ganger denne avgjørelsen og fortsetter bare på gammel vane. Det er viktig at vi har klare beslutningspunkter og at vi får de signaturene og forpliktelsene vi skal ha før vi fortsetter prosjektet. På den andre siden er det noen selskaper som investerer i hva som helst av prosjekter, så lenge de har ressurser ledige. Denne aktiviteten er på slutten av en kjede med aktiviteter som alle leder frem til av vi tar en velbegrunnet beslutning basert på lønnsomheten i prosjektet. ### VANLIGE FALLGRUVER Alle organisasjoner som jobber med prosjekter, må ha en form for porteføljestyring som evaluerer og velger de rette prosjektene. Disse må sees ut ifra en balansert helhet og i tråd med organisasjonen strategi. Mange av de problemene som knytter seg til prosjektledelse har bakgrunn i porteføljestyringen, som f.eks. det å ha for mange prosjekter samtidig. Vær sikker på at alle forstår at det å avslutte et prosjekt ikke er å feile. Det er snarere et tegn på at vi har gode systemer som fanger opp hva som er lønnsomt for organisasjonen. Dette hadde ikke vært mulig uten at medlemmene i prosjektteamet hadde gjort den den jobben de har gjort i denne startfasen av prosjektet. ## A09 - Sett i gang prosjektet [image] Hvis prosjektet ble godkjent i A08, er det nå tid for at interessentene fra kunden og leverandøren møtes og at prosjektet startes med et lite arrangement (kick-off event). Det er best å bruke en hel dag på dette og helst gjennomføre det utenfor organisasjonen. Prosjektleder og resten av teamet (hvis det er noen) skal legge til rette for arrangementet og sørge for at det blir en hyggelig opplevelse for alle. ### HENSIKT Hensikten med dette arrangementet er: - Gjøre prosjektet offisielt. - La både interne og eksterne interessenter bli kjent med hverandre og knytte kontakter. - Sørge for at hovedbudskapet til prosjektet blir kommunisert. ### VANLIGE FALLGRUVER Sørg for at arrangementet ikke blir et tørt og kjedelig arrangement som bare går gjennom alle detaljene i prosjektet, men at det heller blir en hyggelig opplevelse med fokus på teambygging. ## A10 - Gjennomfør en tydelig kommunikasjon [image] Heng opp et banner i organisasjonen for å annonsere at prosjektet starter (eller gjør noe tilsvarende for virtuelle team). Send en mail til alle hvor det forklares hvorfor prosjektet har startet og hvilke gevinster som forventes. ### HENSIKT I mange organisasjoner er det slik at prosjekter startes og avsluttes uten at det markeres, og at mesteparten av de ansatte (også sjefene) ikke engang vet hva slags prosjekter som gjennomføres i organisasjonen. Dermed blir alle fokusert på sine spesialistaktiviteter uten å tenke på helheten i prosjektet, ta hensyn til målene eller samarbeide med alle andre slik at målene nåes. En tydelig kommunikasjon er en mulighet til å unngå dette ved å skape forpliktelser og oppmuntre til samarbeid. ### VANLIGE FALLGRUVER En kan ikke yte godt i prosjektet hvis en ikke er begeistret for det. Når en er begeistret, så vis dette gjennom kommunikasjon med andre for å skape tilsvarende følelse hos dem. Unngå tørr og kjedelig kommunikasjon. ## B01 - Revider og detaljer planene [image] Gjennomfør en workshop for å revidere de overordnede planene, fyll ut flere detaljer og utnevn de ansvarlige for denne månedens leveranser. Denne detaljeringen vil påvirke Prosjektbeskrivelsen, Produktkartet og Helseregisteret. Hvis et tilsvarende prosjekter har blitt gjennomført tidligere, så sjekk den lagrede dokumentasjonen og bruk den for å gjøre planene mer realistiske. Mal for Prosjektbeskrivelse Mal for Oppfølgningsregister ### HENSIKT Planene, som ble laget i forbindelse med Prosjektstart, er overordnede og ikke bra nok for en gjennomføring. Planene trenger derfor en nærmere utdyping, og det gjøres for én måned av gangen i denne aktiviteten. Alle planer må oppdateres kontinuerlig for å tilpasse seg virkeligheten. ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - Bruk teknikker for å tilrettelegge workshopen, og dermed få en mere effektiv workshop til planleggingen. - Ikke ha fokus kun på den nærmeste måneden, men sørg for at den overordnede planen for hele prosjektet også oppdateres. - Ikke legg alt for mye detaljer inn i planene – bare legg inn det som er nødvendig for den praktiske gjennomføringen. ## B02 - Få den månedlige syklusen fagfellevurdert [image] Spør en annen prosjektleder, eller en med god kompetanse på prosjektledelse, om å få hjelp til å sjekke og evaluere de månedlige aktivitetene som er gjennomført, og legg resultatet fra dette inn i Helseregisteret før prosjektet fortsetter. Mal for Helseregister ### HENSIKT Hensikten med denne aktiviteten er å ta en fot i bakken for å sjekke ut om det en holder på med er det rette. Det å kunne ha en uavhengig person som skal sjekke arbeidet er absolutt en fordel fordi prosjektlederen selv sitter alt for tett på for å se de utfordringene som eventuelt finnes. Dette gir også personer som leder andre prosjekter i organisasjonen en mulighet til å se på hverandres arbeid og lære av det. ### VANLIGE FALLGRUVER En utfordring er at personer som gjennomfører denne vurderingen nøler med å peke på problemer, fordi de frykter at det blir tatt personlig. Det er opp til prosjektleder å skape et så godt forhold til dem at de tør være komfortable og ærlige. ## B03 - Avgjør om prosjektet skal fortsette eller ikke [image] På dette stadiet i prosjektet skal prosjekteier, basert på den reviderte planen, bestemme seg for om prosjektet skal fortsette eller avsluttes. Prosjekteieren tar denne beslutningen selv, men kan diskutere det med andre i organisasjonen, slik som f.eks. de som driver med porteføljestyring. Hvis beslutningen blir å stoppe prosjektet, så vil vi starte med aktivitetene for prosjektavslutning og prosjekteier avgjør da om aktivitetene som skal gjøres etter prosjektet også skal gjennomføres. ### HENSIKT Hensikten er å være sikker på at prosjektet fortsatt er lønnsomt og minne alle om at målet for prosjektet ligger langt utover det bidraget som kommer fra de isolerte aktivitetene til spesialistene. ### VANLIGE FALLGRUVER Prosjekteieren må ta sin oppgave seriøst og ikke bare godkjenne prosjektet automatisk uten å sjekke det. Det er viktig at alle forstår at det å avlyse et prosjekt er et tegn på god prosjektledelse. Noen ganger kan et prosjekt isolert sett vært lønnsomt, men kanskje ikke så lønnsomt som andre mulige prosjekter. Derfor er det viktig å se helheten når man evaluerer lønnsomheten i prosjektene, og det gjøres best om vi har porteføljestyring, som i så fall har den totale oversikten over alle prosjektene i organisasjonen. ## B04 - Sett i gang den månedlige syklusen [image] Når du får godkjenningen i B03 er det på tide ta starte den månedlige syklusen. ### HENSIKT Denne aktiviteten har 2 hovedmål: - Teambygging. - Informere interessentene om planen for den kommende måneden. ### VANLIGE FALLGRUVER Ikke begrens dette til å bli et kjedelig og tørt arrangement med gjennomgang av den kommende måneden, men la det bli en hyggelig opplevelse for alle med fokus på teambygging. Du kan samle hele teamet (samt eksterne interessenter om det er mulig) og dra på tur, arrangere en piknik el.lign. men legg til rette for at de 2 målene blir oppfylt. ## B05 - Gjennomfør en tydelig kommunikasjon [image] Send en melding til alle, som forteller hva som er tenkt oppnådd denne måneden, og hvilke usikkerheter som er involvert. Det er viktig at alle kjenner sin rolle i hvordan prosjektet skal oppnå de målene vi har satt. ### HENSIKT Hensikten er å sørge for at alle som er involvert i prosjektet fortsetter å være samkjørte mot de store målene og ikke begrenser seg til sine isolerte tekniske aktiviteter. ### VANLIGE FALLGRUVER Hold meldingene korte og konsise og ha søkelyset på hva som skal oppnås – i stedet for hva som skal gjøres. ## C01 - Mål og rapporter fremdrift [image] Mål fremdriften i forhold til målene og lag realistiske prognoser for målene (f.eks tid og kostnad). Lag deretter en eller flere rapporter, med fokus på prognosene, og send de til de forskjellige interessentene. Sjekk at rapportene er mottatt og forstått. Sjekk listen over interessenter, som står i Prosjektbeskrivelsen, for å være sikker på at alle får rett rapport. Viser det seg at formatet på en av rapportene ikke passer for én av interessentene, så kan den endres eller lages i en ny utforming, men legg i så fall denne informasjonen inn i listen over interessentene. ### HENSIKT Hensikten er å forstå hvordan prosjektet ligger an i forhold til resultater og mål, som vi trenger for å kunne korrigere for et mulig avvik så fort som mulig. Det andre målet er å holde alle relevante interessenter informert om statusen i prosjektet, noe som skaper tillit og gir en mulighet for et enda bedre samarbeid. ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - Ikke vær altfor nøyaktig med målingene, men finn det nivået på nøyaktighet og detaljering som passer best. - Vær forsiktig med hva som måles: Alle målinger må relateres til prosjektets mål og resultater, heller det enn for eksempel å måle hvor mye ressurser som er brukt. - Holde rapportene korte, konsise og med søkelyset på å måle effekten av fremdrift. Hvis det sendes en detaljert rapport til en av interessentene, sørg også for at det sendes en kortversjon på én side. ## C02 - Planlegg avvikstiltak [image] Hvis det avdekkes et avvik i forhold til målene, basert på målingen av fremdrift fra C01, må disse håndteres slik at prosjektet kan komme tilbake på rett spor igjen. Er det en komplisert situasjon kan det arrangeres en workshop for å få hjelp fra alle, eller i hvert fall noen av teammedlemmene, for å planlegge hvordan avviket kan rettes opp. Er det et kritisk eller sensitivt avvik, så må prosjekteier informeres. Prosjekteier blir først bedt om gi et råd og deretter om å godkjenne en avviksplan for å løse avviket. Hvis det ikke er mulig å komme tilbake til normal situasjon i prosjektet, så må det søkes godkjenning fra prosjekteier om å sette reviderte mål og resultater for prosjektet, og denne informasjonen må legges inn i Prosjektbeskrivelsen. Hvis det er en underliggende årsak til dette avviket, som kan forårsake tilsvarende situasjoner også i fremtiden, så må det legges inn som en usikkerhet i Oppfølgingsregisteret. Så må det planlegges tiltak mot dette. Mal for Prosjektbeskrivelse Mal for Oppfølgningsregister ### HENSIKT For å oppnå målene til prosjektet, så må avviket ordnes opp i så fort som mulig. Det må gjøres før dette, og andre avvik, hoper seg opp. Men like viktig er at hvis forsøket på å rette opp avviket ikke lykkes, og det samtidig er en illevarslende trend i prosjektet, så vil ikke målene til prosjektet oppnås. Da må målene vurderes på nytt, for da er kanskje ikke lønnsomheten i prosjektet like god lenger. Da må kanskje prosjektet avbrytes helt for å unngå et større tap i fremtiden. ### VANLIGE FALLGRUVER Husk at en generell, vag og håpefull formulering som: «Vi må jobbe 15% bedre fra nå av» ikke er en avviksplan. Avviksplaner må være realistiske og inneholde handlinger som kan gjennomføres og evalueres i ettertid. Hvis man må velge mellom å gjenopprette avviket eller løse den bakenforliggende årsaken til avviket, som kan forårsake samme hendelse senere, så prioriter det siste. Ellers vil man hele tiden måtte opptre som en brannslukker. ## C03 - Sett i gang den ukentlige syklusen [image] I små prosjekter, kan hele teamet samles, men i større prosjekter samles om nødvendig bare teamledere, prosjektlederen fra leverandøren, ledelsesteamet og andre interessenter, for å gå gjennom følgende punkter: - Gå igjennom det som skal skje i den kommende uken. - Se på usikkerheter som kan dukke opp i den kommende uken og se på eksisterende hendelser som kan utvikle seg videre og legg disse inn i Oppfølgningsregisteret. - Teamene må oppmuntres til å begrense det totale antallet leveranser som de jobber med til enhver tid, og heller prioritere å bli ferdige med de leveransen som raskt kan ferdigstilles. Mal for Oppfølgningsregister ### HENSIKT Hensikten er å være sikker på at alle er samkjørte og at det ikke blir noen konflikter mellom teamets oppgaver og teammedlemmenes individuelle arbeidsoppgaver. ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - Ikke bruk dette møtet for å måle fremdriften (Det ble gjort i C01). - Ikke bruk dette møtet til å lage tiltak for identifiserte hendelser og usikkerheter (Det ble gjort i D01). - Møtet må styres for å sikre at det ikke tar for mye tid, men at vi bruker nok tid på hvert emne. ## C04 - Gjennomfør en tydelig kommunikasjon [image] Send en kort melding til alle som er involvert i prosjektet og informer dem om hva som skal gjøres i den kommende uken, om usikkerheter som kan påvirke prosjektet og tiltak mot disse. ### HENSIKT Hensikten er å sørge for at alle er samkjørte om det overordnete målet for prosjektet, og at det ikke blir konflikter mellom arbeidet som utføres av enkeltpersoner, team eller leverandører. ### VANLIGE FALLGRUVER Ikke bli for detaljert i denne kommunikasjonen, men hold den på et enkelt og overordnet nivå. ## D01 - Håndter usikkerheter, hendelser og forespørsler om endringer [image] Usikkerheter, hendelser og forespørsler om endringer i prosjektet bør håndteres proaktivt. Når en ny sak identifiseres så må den umiddelbart legges inn i Oppfølgningsregisteret. Så må det utpekes en ansvarlig for å følge den opp (en av teammedlemmene) og man må starte planleggingen for hva som skal gjøres med den. Det er viktig å være i kontakt med teammedlemmene og andre interessenter hele tiden for å identifisere usikkerheter og hendelser. Andre teammedlemmer, eller også eksterne interessenter, kan også hjelpe til med å finne ut hva som skal gjøres med alle sakene. Når det er kompliserte saker så samles hele teamet og gjennomfører en workshop slik at de, i fellesskap, skal komme frem til en løsning, ved å bruke wisdom of the crowd. Er det kritiske saker det gjelder så bør prosjekteier involveres for å godkjenne den nye planen for å håndtere saken. Mal for Oppfølgningsregister ### HENSIKT Hensikten er å være proaktive med usikkerheter, hendelser og forespørsler om endringer, istedenfor for å tro at det løser seg av seg selv. På den måten kontrolleres prosjektet bedre og muligheten for å få det beste resultatet vil øke. Å stole på å at man husker alt eller på bare å bruke ustrukturerte notater tar for mye av den mentale energien og åpner opp for at saker forsvinner eller glemmes. Derfor er det bedre å ha et enkelt register og nok selvdisiplin til å legge inn saker der så fort de oppstår. Det tar mye tid å følge opp alle sakene og det er derfor lurt å utnevne ansvarlige personer for hver av dem. I tillegg til å spre arbeidsbyrden vil dette også hjelpe prosjektet fordi alle sammen jobber mot et felles mål. ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - Ikke legg for mye informasjon om vurderingen av saken inn i oppfølgningsregisteret. - For å sikre at alle saker blir avsluttet innen rimelig tid, kan det settes tidsfrister og at alle forplikter seg til å løse sakene innen disse. - Unngå generiske beskrivelser som er umulige å gjennomføre. Tiltaket må være noe teamet kan gjennomføre og den ansvarlige kan måle. - Ikke bruk all tiden din på brannslukking uten å se på usikkerheter, siden usikkerheter du ikke gjør noe med er en stor kilde til saker som kan dukke opp senere. ## D02 - Aksepter ferdige leveranser [image] Leveranser som er tildelt teamledere og prosjektledere hos leverandørene kan bli ferdigstilt når som helst og da må prosjektleder gjøre en kjapp sjekk og godkjenne leveransen. Godkjennelsen i denne ledelses aktiviteten har status som foreløpig. Er det snakk om store eller kritiske leveranser så kan det, om mulig, søkes om godkjenning fra prosjekteier eller kunden. ### HENSIKT Å ha for mange baller i luften samtidig forårsaker problemer – fordi det krever for mye ressurser. Det kan gå utover kvaliteten noe som vil redusere hele forutsigbarheten i prosjektet. Så, om det er mulig, ikke jobb med for mange leveranser parallelt. Alle bør i stedet oppmuntres til å avslutte en oppgave før de går videre til neste. ### VANLIGE FALLGRUVER Godkjenning av leveranser medfører et ansvar, og noen prosjektledere utsetter godkjenninger for å unngå dette ansvaret, men det er ikke produktivt så det må unngås. Ikke vær redd for å ta ansvar; noen av de godkjente leveransene kan forårsake problemer senere, men det er ikke så farlig som det å ha for mange leveranser som venter på godkjenning. Mange leveranser kommer fort frem til status «Nesten-ferdig» og så møter problemer fordi noen småting dukker opp. Det kan være fristende å gi de status som «Ferdig» fordi mesteparten av arbeidet er gjort, men det må ikke gjøres. Det er bare leveranser som er «Helt ferdig» som skal godkjennes. ## E01 - Evaluer interessentenes tilfredshet [image] Send et spørreskjema til teammedlemmene, kunden, leverandørene, eller andre interne og eksterne interessenter for å finne ut hvor fornøyde de har vært med prosjektet denne måneden, og legg resultatet inn i Helseregisteret. Denne undersøkelsen må være anonymisert. Mal for Helseregister ### HENSIKT Det er viktig å få evaluering ofte nok både for å finne ut om problemer, men også for å få løst dem så fort vi kan. Vi bør ikke sitte å vente på at en uønsket hendelse kanskje oppstår. Denne evalueringen er ikke begrenset kun til kunden – inkluder også teammedlemmene, siden deres opplevelse har stor påvirkning på prosjektet. Det er viktig at dette gjennomføres anonymt, fordi ellers skjer det ofte at mange ikke vil dele sine virkelige synspunktet om prosjektet. ### VANLIGE FALLGRUVER Ikke begrens denne evalueringen av kundens tilfredshet til bare noen få personer – spør alle som har påvirkningskraft. Ikke ha med for mange spørsmål, men hold det til et akseptabelt antall for å få svar fra flest mulig av interessentene. Selv om dette etter beste evne holdes anonymt, så er det ofte slik at hvis det bare er noen få som svarer, så kan noen av svarene brukes for å kunne identifisere dem. Hvis det skjer, så prøv å fjern det som er identifiserbart og bruk det heller ikke i fremtiden, ellers vil man oppleve at noen av interessentene ikke stoler på anonymiteten til undersøkelsen. For å forsikre seg man ikke ser informasjon som kan identifisere noen, så kan man fokusere kun på det samlete resultatet av undersøkelsen og ikke vise de individuelle svarene. ## E02 - Registrer erfaringer og planlegge forbedringer [image] Etter å ha å samlet inn svarene fra undersøkelsen, så bør alle teammedlemmene inviteres til å delta på en workshop. Dette gjøre vi for å finne ut hva vi kan gjøre bedre, basert på svarene som kom inn, og for å dele erfaringene som vi har fått denne måneden. Legg alt inn i Oppfølgningsregisteret og utpek ansvarlige for hver av oppgavene. Mal for oppfølgningsregister ### HENSIKT Det er 2 to viktige årsaker for denne workshopen: lage en god plan for gode forbedringer og teambygging. For prosjektlederen er det er bedre å bruke en workshop for å planlegge forbedringene enn å gjøre alt arbeidet på egen hånd. Dette fordi gruppas samlede kunnskap the Wisdom of Crowds vil bidra til mye bedre planer og sørge for enighet med teammedlemmene om dette fordi de knyttes tettere til arbeidet. ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - For å få et godt resultat fra en workshop må den tilrettelegges. Teknikker som Delphi kan brukes til det. - Når det er mulig, må innsamling av data gjøres anonymt for å forsikre at deltagerne er komfortable nok til å uttrykke seg fritt. Bruk gjerne en passende programvare som både sørger for anonymiteten og for at prosessen skal gå raskere. - Unngå å bli anchoring i én eller noen får ideer. Det er viktig å være nøytral når man jobber med dette. ## E03 - Gjennomfør en tydelig kommunikasjon [image] Send en melding til alle teammedlemmene for å fortelle dem om hva prosjektet har oppnådd denne måneden, og takk dem for deres bidrag. ### HENSIKT Dette minner alle på å holde søkelys på målene til prosjektet og ikke på de enkelte spesialistaktivitetene. Når dette gjøres riktig, vil det bidra til å samle teamet. ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - Sett søkelyset på hva som er oppnådd istedenfor arbeidet som er gjort. - Vær tydelig og unngå forretningsmessige ord og uttrykk. - Vær kort – fortrinnsvis bare noen få linjer. ## F01 - Overlever produktet [image] Når prosjektet er ferdig, så må det godkjennes og produktet kan overleveres til intern eller ekstern kunde. I de tilfellene hvor prosjektet har blitt avbrutt underveis så er ikke dette en aktivitet vi alltid trenger å gjøre. Noen ganger vil kunden akseptere produktet, men man blir enige om noen ekstraoppgaver som skal gjøres ferdig i løpet av en viss tid. I slike tilfeller kan prosjektet avsluttes og så overlater man de resterende oppgavene til driftsorganisasjonen. ### HENSIKT Målet er å ha en offisiell overrekkelse og godkjenning av produktet, noe som er en forutsetning for å kunne avslutte et prosjekt. Husk at det å ha prosjekter som er nesten ferdigstilt, men som blir lagt på is i den siste delen er å sløse med ressurser og gjør det vanskelig å drive med porteføljestyring. Det er best å kunne avslutte noe, for så å gå videre med nye oppgaver. ### VANLIGE FALLGRUVER Denne aktiviteten er den store avslutningen av prosjektet og vil ofte by på utfordringen og ta tid hvis man ikke har tatt de tidligere godkjennelsene og overleveringer seriøst nok. Når det er mulig bør man søke om godkjennelse fra prosjekteier og kunden for de største leveransene så fort der er ferdige, fremfor å vente til prosjektet skal avsluttes. Det vil i så fall gjøre denne avslutningen enklere. ## F02 - Evaluer interessentenes tilfredshet [image] Send det avsluttende spørreskjemaet til både interne og eksterne interessenter og legg resultatet inn i Helseregisteret. Men mens den tilsvarende månedlige undersøkelsen dreier seg om hver enkelt måned, så vil dette dreie seg om hele prosjektet. Mal for Helseregister ### HENSIKT Nå det ikke lenger er noe som kan påvirke interessentenes tilfredshet, så er hovedhensikten til denne evalueringen å få den gjort og få resultatet lagret, for så å kunne lese den senere og kunne ta læring for fremtidige prosjekter. ### VANLIGE FALLGRUVER Ikke begrens denne evalueringen av kundens tilfredshet til bare noen få personer – spør alle som har påvirkningskraft. Ikke ha med for mange spørsmål, men hold det til et akseptabelt antall for å få svar fra flest mulig av interessentene. Selv om dette etter beste evne holdes anonymt, så er det ofte slik at hvis det bare er noen få som svarer, så kan noen av svarene brukes for å kunne identifisere dem. Hvis det skjer, så prøv å fjern det som er identifiserbart og bruk det heller ikke i fremtiden, ellers vil man oppleve at noen av interessentene ikke stoler på anonymiteten til undersøkelsen. For å forsikre seg man ikke ser informasjon som kan identifisere noen, så kan man fokusere kun på det samlete resultatet av undersøkelsen og ikke vise de individuelle svarene. ## F03 - Gjennomfør en fagfellevurdering av avslutningsaktivitetene [image] Spør en annen prosjektleder, eller en som er ekspert på prosjektledelse, om å se over det som er gjort av ledelsesaktiviteter og legg resultatet inn i Helseregisteret. Hvis det blir en veldig lav poengsum så må en endre litt på de aktivitetene som er gjennomført, og så gjøre denne aktiviteten en gang til. ### HENSIKT Denne aktiviteten gjøres av 2 årsaker: - For å være sikker på at denne gruppen av aktiviteter og prosjektet som helhet kan avsluttes. - For å frem nyttig informasjon, som kan brukes til å gjøre organisasjonen vår bedre til å gjennomføre prosjekter. Selv om det individuelle resultatet for dette prosjektet er viktig, så er det vel så viktig å se trenden i score for alle prosjektene i organisasjonen. ### VANLIGE FALLGRUVER En utfordring er at personer som gjennomfører denne vurderingen nøler med å peke på problemer, fordi de frykter at det blir tatt personlig. Det er opp til prosjektleder å skape et så godt forhold til dem at de tør være komfortable og ærlige. ## F04 - Arkiver prosjektdokumentasjonen [image] Nå som vi nærmer oss slutten på prosjektet er det på tide å arkivere dokumentene. ### HENSIKT Arkivet må være lagret trygt og må i fremtiden kun være tilgjengelig for autoriserte personer, slik at de kan bruke den informasjonen i sine prosjekter istedenfor å måtte finne opp hjulet på nytt hver gang. De som driver med porteføljestyring, kan også ha behov for å sjekke denne informasjonen for å få en bedre forståelse av tidligere prosjekter. ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - Når det er mulig bør man sørge for at dette lagres på ett samlet sted og ikke spres rundt. - Sørg for at det kun er lesetilgang til arkivet. - Sørg for at det er et godt system for backup av dette området så filer ikke blir borte. - Sørg for at arkivet er trygt og at kun autoriserte personer har tilgang. I tillegg til dette så er det et vanlig problem at teksten ikke er klar nok, og at kun personer som har jobbet med dokumentene forstår innholdet i forhold rett tid og kontekst. Sørg for at det ikke skjer, men at hvem som helst når som helst skal kunne forstå dokumentene. Dette gjelder også for lange prosjekter hvor interne interessenter allerede etter noen måneder blir usikre på hva de egentlig hadde ment. ## F05 - Feire! [image] Nå er det på tide å ha en feiring for teammedlemmene og resten av organisasjonen. For etter denne aktiviteten blir prosjektteamet oppløst. ### HENSIKT Dette er en investering for fremtidige prosjekter, siden det minner folk på at de alle jobber sammen mot det samme felles målet. ### VANLIGE FALLGRUVER Sørg for at dette blir noe som folk husker og ikke et kjedelig arrangement med lange og tørre taler. ## F06 - Gjennomfør en tydelig kommunikasjon [image] På dette stadiet sender prosjekteier ut en melding til hele organisasjonen hvor han forteller at prosjektet avsluttes og takker alle team medlemmene fro deres bidrag. ### HENSIKT Det er to årsaker til denne aktiviteten: - Det viser at arbeidet team medlemmene har lagt ned verdsettes, noe som vil oppmuntre dem til fremtidige prosjekter. - Det holder alle informert om prosjekter som organisasjonen holder på med, og hjelper dem med å justere seg inn mot målene. ### VANLIGE FALLGRUVER Holde denne meldingen kort og konsis. Hvis prosjektet ble avlyst eller ikke vellykket, sørg for at meldingen er positivt ladet og at folk oppmuntres til å se fremover for å gjennomføre bedre prosjekter i fremtiden. ## G01 - Evaluer gevinstene [image] Prosjekteieren (eller noen på deres vegne) bør bruke noen timer i hver syklus med «Aktiviteter etter prosjektet» til å måle prosjektgevinstene. Bortsett fra de forventede gevinstene, bør også prosjekteieren aktiv se etter uforutsette gevinster, potensielle gevinster og negative effekter. ### HENSIKT Prosjektgevinstene bør evalueres av følgende grunner: - Det er en påminnelse for prosjekteiere og andre interessenter om at prosjekter gjennomføres for å oppnå gevinster. - Det hjelper oss å forstå våre omgivelser og bli mer realistiske i fremtidige prosjekter. - Det hjelper oss finne veier til å øke gevinstene (G02). ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - Prosjekteieren kan få noen andre til å evaluere gevinstene, men bør selv ha fullstendig styring over dem, og anse denne aktiviteten som en viktig ledelsesaktivitet som tilhører de høyere ledelsesnivåene. - En utydelig og ordrik beskrivelse av gevinstene har ingen hensikt. Resultatet kan gjerne være overordnet og usikkert, men det må være meningsfullt og brukbart for G02. - Husk at gevinster ikke er begrenset til finansielle gevinster, men kan dekke omdømme, markedsandel, muligheter og tilegnet kunnskap. ## G02 - Skap nye ideer [image] Etter å ha evaluert gevinstene (G01), så bør prosjekteieren sjekke om det finnes noen måter å øke disse på. Resultatet kan være små aktiviteter som utføres av operasjonelle team, eller større endringer som kan bli til nye prosjekter i fremtiden. ### HENSIKT Hovedarbeidet i prosjektet er nå fullført, og man fortjener å dra fordeler av dette. Imidlertid blir noen at de potensielle gevinstene ikke automatisk realisert uten at det gjøres ytterligere, ustrukturerte tiltak, og vi ønsker ikke å miste den muligheten. På en annen side, gevinstevaluering i tidligere prosjekter er en god idekilde for fremtidige prosjekter og den er best gjort på en strukturert måte. ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - Unngå uttalelser som ikke lar seg gjennomføres, og fokuser istedenfor på å designe reelle løsninger som kan både implementeres og evalueres. - Man trenger ikke å gjøre denne ledelsesaktiviteten alene – inviter andre å være med og ta en fellesbeslutning. - Begrense seg til å evaluere gevinstene av hvert prosjekt hver for seg. Noen ganger fungerer det bedre hvis man (og andre ansvarlige i andre prosjekter) kommer sammen og evaluerer gevinstene i flere prosjekter samtidig. Vær påpasselig med at gevinstene i hvert prosjekt man er ansvarlig for blir evaluert på en eller annen måte. ## G03 - Gjennomfør en tydelig kommunikasjon [image] Send en kort beskjed om gevinstene som ble realisert av prosjektet og planer for å forbedre disse. Denne informasjonen kan deles med en mindre gruppe av autoriserte mennesker i organisasjonen (f.eks. ledere og direktører), eller med alle. Det foretrukne er å dele med alle. ### HENSIKT Dette er en kontinuerlig påminnelse til mottakerne om at prosjekter gjennomføres til deres fordel, og at de trenger å ta hensyn til dette i nåværende og fremtidige prosjekter. ### VANLIGE FALLGRUVER Vurder disse tipsene for å unngå de vanligste problemene rundt denne aktiviteten: - Ikke vurder alt som sensitivt, men del helst informasjon med hele organisasjon når det er mulig. - Hold budskapet kort og tydelig. - Hvis du er ansvarlig for flere mindre prosjekter, kan du slå sammen rapportene til én rapport, men vær påpasselig med at hvert prosjekt er dekket.