Ulike tilnærminger

Virksomhetens tilpasning av Prosjektveiviseren kan i prinsipp gjøres gjennom tre ulike tilnærminger.

Publisert: 03. Mai 2019, Sist endret: 14. okt 2019

A. En «veileder» som beskriver avvik og tillegg til Prosjektveiviseren

En slik «veileder» kan henvise til diverse maler, metoder, modeller, retningslinjer, rollebeskrivelser, rutiner, verktøy, etc som virksomheten allerede har (eller legger inn) på sitt eget intranett. Veilederen skal beskrive hvordan disse kan brukes i samspill med Prosjektveiviseren. På denne måten bygges tilpasningene «utenpå» Prosjektveiviseren. Det gjør at denne løsningen vil være svært enkel/billig å forvalte i forbindelse med Difis lansering av nye versjoner av Prosjektveiviseren.

Denne tilnærmingen er mest brukt av relativt små statlige virksomheter og kommuner som har begrenset kapasitet til å bygge og vedlikeholde sin egen prosjektmodell, og vurderer at denne tilnærmingen dekker deres behov på en god måte. Asker kommune er et godt eksempel på dette.

En iboende ulempe med denne tilnærmingen er at brukerne av modellen kanskje i større grad må forholde seg til generell begrepsbruk og generiske beskrivelser av faser, aktiviteter, etc og at modellen dermed blir tyngre for brukerne å tilegne seg. Dette kan kompenseres ved en mer omfattende «veileder» eller ved større vekt på opplæring.

B. En egen lokalt implementert prosjektmodell basert på Prosjektveiviseren

Noen virksomheter har valgt å lage sin egen prosjektmodell, basert på Prosjektveiviseren, hvor avvik og tillegg er bygget inn i en kopi av Prosjektveiviseren slik den var på det tidspunktet virksomheten laget sin prosjektmodell. Dette er et ganske omfattende arbeide som krever egen lokal kompetanse og kapasitet. Det gir virksomheten en skreddersydd løsning som gir maksimal gjenkjennelighet for brukerne i egen virksomhet.

Gjort med grundighet og god prosjektfaglig forståelse kan dette der og da være en god og fristende løsning, men den har flere ulemper:

  • Dersom virksomheten skal kunne nyte godt av de forbedringene som Difi gjør i nye versjoner/oppgraderinger av Prosjektveiviseren, må virksomheten selv bruke mye ressurser på å forvalte/oppdatere sin lokale modell.
  • Utviklingen av en egen prosjektmodell, basert på Prosjektveiviseren, må gjøres med varsomhet og omtanke slik at viktige prinsipper og budskap i Prosjektveiviseren ikke blir «tilpasset bort», og kanskje i verste fall erstattet med gammel og uhensiktsmessig prosjektpraksis som egentlig burde vært forbedret.

Vedlikehold av virksomhetens egen tilpassede prosjektmodell blir virksomhetens eget ansvar. Dere må selv sørge for å oppdatere egen modell i henhold til nye versjoner av Prosjektveiviseren. Ved lansering av nye versjoner bidrar Difi med dokumentasjon av hva som er endret, men kan ikke bistå med praktisk hjelp til oppdatering av lokale prosjektmodeller.

Denne tilnærmingen er mest brukt av store virksomheter som har kompetanse og kapasitet til å bygge sin egen prosjektmodell, og har vurdert det slik at denne tilnærmingen er nødvendig for å gi dem en tilstrekkelig spesialtilpasset prosjektmodell. Politidirektoratet, Helsedirektoratet og Direktoratet for e-helse er eksempler på dette. En alternativ tilnærming for denne gruppen kunne vært å velge tilnærming C, som er beskrevet nedenfor.

Både tilnærming A og tilnærming B krever kompetanse og kapasitet i forbindelse med utarbeidelse og innføring av en (ny) prosjektmodell, mens forvaltningen av en egen prosjektmodell i henhold til tilnærming B vil kreve større lokal kapasitet enn ved tilnærming A. Vær bevisst på dette før beslutningen om å utarbeide en egen lokal prosjektmodell tas.

C. En egen prosjektmodell hvor egne maler, metoder, modeller, etc. integreres med gjeldende versjon av Prosjektveiviseren

Denne tilnærmingen baserer seg på bruk av et prosessverktøy eller tilsvarende hvor virksomheten beskriver sin egen prosjektmodell, med faser og aktivitetsstruktur, slik de ønsker at modellen skal presenteres for brukerne i sin egen virksomhet. Fra hver aktivitet i dette verktøyet kan det da legges inn lenker både til tilsvarende aktivitet(er) i prosjekveiviseren.no og til sine lokale maler, metoder, etc på eget intranett. På denne måten bygges de de to kunnskapskildene sammen på en måte som i stor grad ivaretar de positive trekkene fra både tilnærming A og B ovenfor.

Denne tilnærmingen er mest aktuell for relativt store virksomheter som ser behov for å beskrive alle sine virksomhetsprosesser – deriblant prosjektprosessen – på en enhetlig måte, og har kompetanse på området. Direktoratet for økonomistyring (DFØ) og NAV er eksempler på dette.

Virksomhetens prosjektmodell vil da fremstå som tilpasset til virksomhetens eget virkefelt og prosjektomgivelser, samtidig som vedlikeholdet i forbindelse med nye versjoner av Prosjektveiviseren blir relativt enkelt og oversiktlig.

  • Aktivitetsstrukturen vil kunne tilpasses til virksomhetens behov, f.eks. ved å slå sammen eller detaljere aktiviteter, eventuelt supplere med egne i tillegg.
  • Prosjektveiviserens aktivitetsbeskrivelser blir alltid tilgjengelig i siste gjeldene versjon på prosjektveiviseren.no.
  • Knytningen mellom modellens faser/aktiviteter og elementer fra virksomhetens eget intranett blir oversiktlig og tydelig.
  • Utfordringen ved vedlikehold av modellen blir vesentlig mindre.
    • Det er bare strukturelle endringer i Prosjektveiviseren som vil kreve oppdatering i den lokale prosjektmodellen, men dette vil være relativt enkelt å håndtere i prosessverktøyet.
    • Rene tekstlige oppdateringer i Prosjektveiviseren vil ikke kreve noen oppdatering lokalt.

Det finnes ulike varianter av slike prosessverktøy i markedet, utviklet for å definere/beskrive prosesser på en oversiktlig måte. Disse verktøyene er i stor grad generiske slik at de kan brukes til å beskrive alle virksomhetens ulike prosesser, og dessuten vise sammenhengene mellom alle disse prosessene. Ved å bruke samme verktøy til alle virksomhetsprosesser vil kostnadene til anskaffelse og drift av prosessverktøyet lettere kunne forsvares ved at det «fordeles» på flere behov og anvendelser.

Deldette