Prosjektdirektiv. for. <prosjektnavn>

Transkript

1 1 / 26 Prosjektdirektiv for <prosjektnavn> Leverandører Styrings gruppe Interessenter Prosjekt gruppe Prosjekt leder Referanse gruppe Organisasjon

2 2 / 26 SAMME DRAG For større prosjekter bør det skrives et sammendrag. Sammendraget bør omfatte hovedtrekkene for prosjektet og inneholde følgende elementer: hensikt, mål og resultater ansvarlige for prosjektet start og sluttdato nytteverdier og kostnader

3 3 / 26 Originaldokument avn Timm Sanders Rolle Stilling Enhet Mail / telefon Styringsgruppeleder Prosjektdirektør Adm.dir. stab Timm.sanders@evry.com, Prosjektnivå ivå 1, prosjekter er på konsernivå Rapporterer til adm.dir. Prosjektet går over flere divisjoner ivå 2, prosjekter er på divisjonsnivå Rapporter til divisjonsdirektør Prosjektet går over flere avdelinger innen en divisjon ivå 3, prosjekter er på avdelingsnivå Rapporterer til avdelingsleder Prosjektet går i en avdeling Distribusjon Prosjektdirektivet distribueres til oppdragsansvarlig, styringsgruppen, prosjektgruppen, referansegruppen, andre... avn Timm Sanders Rolle Stilling Enhet Mail / telefon Styringsgruppeleder Prosjektdirektør Adm.dir. stab Timm.sanders@evry.com, Endringslogg Versj. Dato: Kapittel Endring Godkjent av: Referanser til andre dokumenter r. Dokumentnavn Dok.id. Versjon Arkiv Dato Vedlegg r. Dokumentnavn 1 Verktøyboks.exl Dok.id. Versjon Arkiv 0.1 Dato Arkivering r. Dokumentnavn Dok.id. Versjon Arkiv Dato

4 4 / 26 Terminologi Forkortelser og forklaring av begreper som brukes i prosjektdirektivet Ord Forklaring

5 5 / 26 I HOLDFORTEG ELSE 1. I LED I G BAKGRUNN HENSIKT OPPDRAGSANSVARLIG... FEIL! BOKMERKE ER IKKE DEFI ERT. 2. PROSJEKTETS OMFA G KORT BESKRIVELSE AV PROSJEKTETS OMFANG PROSJEKTTILHØRIGHET (DELPROSJEKTER/HOVEDPROSJEKT) AVGRENSNING AV PROSJEKTET EKSTERNE / INTERNE RAMMEBETINGELSER KRITISKE SUKSESSFAKTORER MÅL OG RESULTATKRAV RESULTATMÅL (LEVERANSEMÅL, KVALITETSMÅL) EFFEKTMÅL PROSJEKTMÅL KOST/NYTTE ANALYSE (LØNNSOMHETSANALYSE) PROSJEKTMILJØ (VERDIER) METODER, TEKNIKKER OG VERKTØY MASKINVARE, PROGRAMVARE OG TEKNISKE FORUTSETNINGER STANDARDER, REGLER OG RETNINGSLINJER ORGA ISERI G ROLLER OG ANSVAR I PROSJEKTET KOMPETANSEBEHOV EIERSKAP / GRENSESNITT (ORGANISASJONENS DELTAGELSE) PRI SIPPER FOR STYRI G OG OPPFØLGI G OPPFØLGING OG STATUSRAPPORTERINGAPPORTERING Fra prosjektdeltaker til prosjektleder/delprosjektleder Fra prosjektleder eder til styringsgruppen Styringsgruppemøter KOMMUNIKASJONSPLAN PROSJEKTOPPFØLGING Resultatoppfølging Fremdriftskontroll Ressursoppfølging Kostnadsoppfølging Risikohåndtering AKTIVITETS- OG TIDSPLA MILEPÆLSPLAN FASER/HOVEDAKTIVITETER GANTT-DIAGRAM LEVERANSER KVALITETSSIKRI G OG E DRI GSHÅ DTERI G EKSTERN KVALITETSSIKRINGING INTERN KVALITETSSIKRING ENDRINGS- (PROBLEM)HÅNDTERING Prosedyre Registrering Innstilling - utredning, analyse og konsekvens... 22

6 6 / Beslutning Gyldig status Styring RISIKOHÅ DTERI G BUDSJETT BUDSJETT ADMI ISTRATIVE RET I GSLI JER KRITERIER FOR AVSLUT I G AV PROSJEKTET EVALUERING UTARBEIDE SLUTTRAPPORT T SOM INNEHOLDER FØLGENDE OPPLYSNINGER: OPPLØSING AV PROSJEKTETET OVERFØRING TIL FORVALTNING... 26

7 7 / I LED I G 1.1 Bakgrunn Bakgrunn for at prosjektet ble etablert. Referanse til beslutning, prosjektforslaget, -handlingsplan eller strategidokumenter dersom dette finnes. r. Dokumentnavn 1 Prosjektmandat 2 Verktøyboks Dok.id. Versjon Arkiv Dato 1.0 KLJ Verk.exl Hensikt Hensikten med prosjektet skal beskrives, ofte er dette de overordnede effektene prosjektets resultater skal bidra til. Det er kun en kort beskrivelse som trengs her. Utdyping av mål med effekter og resultater kommer i kapittel 2. Hensikten skal kort legitimere prosjektet. Det bør også beskrives (kort) de viktigste grunnene til at prosjektet gjennomføres, f.eks: Løse et akutt problem Forebygge et problem Utnytte en mulighet Prosjekteier Oppdragsansvarlig for prosjektet skal navngis, både med stilling eller rolle, avdeling og navn. avn Ola Nordmann Rolle Styringsgruppeleder Stilling Enhet Mail / telefon Administrerende Ledelsen O.nordmann@månen.no direktør

8 8 / PROSJEKTETS OMFA G 2.1 Kort beskrivelse av prosjektets omfang Prosjektets oppdragsbeskrivelse, hentes i fra prosjektforslaget, eller i fra beslutningsdokumentet for etablering av prosjektet. Det tenkes her på ½ side som gir et godt inntrykk av hva prosjektet dreier seg om. : XXX Prosjekt Prosjektet skal utvikle et gjennomføringsmal for klinikken. Malen/prosessen skal bestå av... Malen skal lages som et standardsystem, slik at det er mulig å brukes i andre klinikker Overordnet ansvarlig Prosjektet XXX er ansvarlig for å gjennomføre prosjektet for klinikken. Klinikken er ansvarlig for å bidra med ressurser for å muliggjøre gjennomføring av prosjektet i henhold til Prosjektmandat. Start dato, slutt dato Overordnet plan : Prosjekt start : Leveranse : Leveranse : Akseptanse av leveranse 2 Kontraktstype Leveranseoppdrag med fast budsjett Plassering / lokaler Prosjektet gjennomføres i klinikkens lokaler, med unntak av arbeidsmøter som avholdes i bygg 60. Bakgrunn I mars og april 2011 ble det gjennomført et forprosjekt i regi av klinikken, hvor resultatet var en kravspesifikasjon til et XXX system. Kravspesifikasjonen ble utarbeidet i samarbeid med prosjekt XX. Kravspesifikasjonen har dannet grunnlaget for kundens vurdering av anskaffelse av et malverk og metodikk. Prosjektet XXX fikk invitasjon til å levere fremdriftsplan og prosjektdirektiv på malverket, basert på foreliggende kravspesifikasjon. Hovedaktiviteter WS nå analyse WS prosjektkort WS - tiltak Dokumentasjon Validering, godkjenning Opplæring Økonomi / budsjett Totalt ca. kr ,- Kr i lønnskost (intern) Kr i konsulenthjelp (ekstern) Resultat Mer enhetlig prosjekt gjennomføring. Alle ledere i klinikken skal kunne modellen. Mer effektiv pasientbehandling, øke gjennomstrømningen med 6 % Eksempel på beskrivelse av prosjektplan 2.2 Prosjekttilhørighet (delprosjekter/hovedprosjekt) Her beskrives sammenhengen mellom dette prosjektet og andre prosjekter eller programmer. Om dette prosjektet er et delprosjekt eller en del av et større hovedprosjekt/program. 2.3 Avgrensning av prosjektet Her beskrives oppgaver og ansvar som ikke tilligger prosjektet. Særlig viktig er dette der det ikke er åpenbart og dermed kan skape misforståelser. 2.4 Eksterne / Interne rammebetingelser Her beskrives eventuelle rammebetingelser som prosjektet må forholde seg til. Økonomiske rammebetingelser skal ikke beskrives her, men under kapittel 11 (budsjett).

9 9 / 26 edenfor finnes noen eksempler hentet fra IT-organisasjonsprosjektet. Trygdeetatens arbeidsoppgaver Etaten skal fortsatt løse de oppgaver den løser i dag - administrasjon av trygde- og bidragslovene og hjelpemiddelsystemet i orge. Prinsippmodell RTV har startet en prosess for å forbedre ansvars- og rollefordelingen på IT-området med utgangspunkt i en prinsippmodell hvor strategisk styring, leverandørrollen og kunderollen er hovedelementene. Denne modellen skal videreutvikles. Eksempler på interne og eksterne rammebetingelser Interne rammer Personalressurser Økonomiske og finansielle forutsetninger Produkter/Sortiment Produksjon/Teknologi Eksterne rammer Økonomiske Politiske/juridiske Kjøpere Konkurrenter Distributører Teknologi Kultur Naturressurser Andre faktorer 2.5 Kritiske suksessfaktorer De kritiske suksessfaktorene er satt opp ut ifra en helhetsvurdering med tanke på leveranser, tilpasning av rutiner og organisasjon, innføring, opplæring og informasjon. Suksessfaktorene (kriteriene) for et prosjekt, vil alltid ha en nær tilknytning til prosjektets risiko. Derfor bør risikovurderingen (kapitel 9) avspeile dette. Utdyp gjerne suksesskriteriene. Følgende faktorer (eksempel) er de mest kritiske for at prosjektets leveranse skal være vellykket: 1. Eierskap i ledelsen 2. Bedriftens representanter har tid til å delta aktivt i prosjektet 3. Stabil organisasjon 4. Budsjett går i orden 5. At det blir avsatt lokaler 6. At effektmålene blir som forventet 7. At leveransen er som avtalt 8.. Eierskap At det fattes nødvendige beslutninger og at disse følges slik at leveransen kan gjennomføres Informasjon i linjen til de som berøres, også av vernetjeneste og tillitsvalgte (se kommunikasjonsplan) At prosjektet kan styre planlegging og gjennomføring av leveransen Lokal kontaktperson At støtteressurser er tilgjengelige og utfører avtalt arbeid til avtalt tid At prosjekter som skal gjennomføres starter i rimelig tid etter fraflytting (motivasjonsfaktor)

10 10 / MÅL OG RESULTATKRAV Her beskrives hovedmål for prosjektet. Målene skal være forankret enten i sykehusets virksomhetsmål og strategi, eller i strategier avledet av disse. Videre skal effektmål og resultatmål dokumenteres. Det er svært viktig at målene er definert slik at de støtter sykehusets sin visjon og overordnede mål. Om ikke et prosjekt støtter sykehusets visjon og målsetning (eller et av delmålene), så skal ikke prosjektet prioriteres, eventuelt forkastes. Resultatmål og effektmål skal følgelig avspeile dette. Målene som beskrives her er også grunnlaget for senere gevinstrealisering. Sterke sider Svake sider Dagens situasjon Organisasjon og ledelse HF skal gi ledere og medarbeidere muligheter til å ta ansvar og til å levere resultater Pasientbehandling HF skal gi pasientene et godt og likeverdig tilbud i samsvar med deres behov for helsetjenester Muligheter Trusler Ressurser HF skal tilby sine tjenester innenfor tilgjengelige ressursrammer, for å forbedre ressursutnyttelsen Kompetanse HF skal legge forholdene til rette for utvikling, forskning og utdanning Visjon HF skal være pasienter og fagfolks førstevalg Kvalitet HF skal kjennetegnes av kvalitet i alt vi gjør 3.1 Resultatmål (leveransemål, kvalitetsmål) Resultatmål skal uttrykke de konkrete resultatene prosjektet skal levere innenfor gitte tids- og kostnadsramme (kjennetegn på leveransen). Resultatmål skal beskrive egenskapene ved prosjektresultatene Resultamål(ene) skal være beskrevet i prosjektforslaget/mandatet Sammenhengen mellom resultatmål og effektmål er illustrert i figuren nedenfor. Prosjekt Prosjektresultat Effektmål Visjon (PSO prinsippet) år du lager en visjon, prøv å få visjonen til å innholde noe om Person, System og Organisasjon Mål (SMARTE mål!) år du jobber med prosjektets resultater og mål, tenk SMARTE mål! Dette betyr at målene skal være: Spesifikke Målbare Aksepterte Realistiske Tidsavgrensede Engasjerende Resultatmål delmål 1 delmål 2 delmål 3 delmål = etto =========== Resultatmålene skal være helt konkrete, slik at når prosjektet er ferdig kan man gå tilbake til resultatmålene og si at dette har prosjektet levert! Resultatmålene er også grunnlag for å beskrive milepæler Eksempel på resultatmål: resultatet skal være et operativt ledelsesinformasjonssystem, som dekker krav fastsatt i kravspesifikasjon datert dd.mm.åå. resultatet skal være en rapport som anbefaler tiltak innenfor IT-sikkerhet resultatet skal være at minst 80% av avdelingsledere skal ha gått ledelseskurs bedre ledelse

11 11 / Effektmål Effektmål skal uttrykke hensikten med prosjektet: Hva ønsker vi å oppnå med prosjektet? Hva er den egentlige hensikten og hvorfor gjør vi dette? Effekt som er ønsket i organisasjonen på sikt Grunnen til at prosjektet starter Beskriv effektmålene og de forutsetningene som ligger til grunn for mulig gevinstrealisering. Effektmål er ønskede forbedringer i forhold til dagens situasjon. Effektmål finnes ofte innenfor følgende områder: ressursinnsats (redusert tid til saksbehandling) produkt og tjenester (økt servicenivå, bedre sikkerhet, færre feil) styring (tidsriktig informasjon, tilgjengelig informasjon) arbeidsmiljø (mer variert arbeid, økt selvstendighet) Eksempel på effektmål: saksbehandlingstiden skal reduseres med 10% i forhold til dagens situasjon kunnskap om anvendelse av GAT skal økes blant alle ledere i bedriften sykefraværet skal på grunn av bedre ledelse gå ned 3% 3.3 Prosjektmål Tid og kostnader Her beskrives prosjektets totale omfang i tid og kostnader. Disse opplysningene kan også, der det er hensiktmessig, bakes inn milpælsplanen i kapittel Kost/nytte analyse (lønnsomhetsanalyse) Fullstendig kost/nytteanalyse utføres i de tilfeller oppdragsgiver eller styringsgruppen krever det. Alle prosjekter skal verbalt beskrive forventede nytteverdier. Disse sammen med mål og resultatkrav danner grunnlag for arbeidet med gevinstrealisering. Lønnsomhetsanalyse danner utgangspunkt for prosjektets gevinst- og resultatmål. Lønnsomhetsanalysen bør inkludere: Prosjektkostnader og årlige driftskostnader Inntekter / kostnadsbesparelser åverdivurderinger eller andre aktuelle lønnsomhetsbetraktninger Sensitivitets- og risikoanalyser Lønnsomhetsanalysen må minimum ta utgangspunkt i prosjektets start- og sluttdatoer. år langsiktige gevinster (effektmål) skal beregnes, må dette spesifiseres nøye. Tallmaterialet i lønnsomhetsanalysen må være detaljert nok til at det er mulig å etterprøve estimatene mot reelle resultater. Driftskostnadene bør som et minimum være inndelt i faste og variable kostnader for å kunne gjennomføre risikovurderinger basert på volum.

12 12 / PROSJEKTMILJØ (VERDIER) 4.1 Metoder, teknikker og verktøy Her skal det beskrives hvilke retningslinjer som gjelder for prosjektet, prosjektstyringsverktøy, arbeidsmetodikk og kvalitetssikringstiltak. 4.2 Maskinvare, programvare og tekniske forutsetninger Er skal en beskrivelse av de tekniske forutsetninger som prosjektet må ha for at det skal bli gjennomført på en tilfredsstillende måte. Det skal også være en beskrivelse av hvem som har ansvaret for anskaffelse, og hvem som har ansvaret for utstyret under prosjektperioden. Aktivitet Dokumentasjon Metode/teknikk Utstyr/rekvisita Hardware Software Ansvarlig Aker pr.metodikk Hevepult Stasjonær PC Office 2007 PL 4.3 Standarder, regler og retningslinjer Tabellen nedenfor angir dokumenter vedrørende standarder, regler og retningslinjer for prosjektet. r. Dokumentnavn Dokument id. Versjon Dato

13 13 / ORGA ISERI G 5.1 Roller og ansvar i prosjektet Beskriv prosjektets organisasjon, gjerne med et diagram som viser de ulike gruppene og rapporteringsveiene. Roller som prosjektet bruker skal beskrives. Det anbefales å beskrive hovedrollene detaljert, dvs. oppdragsansvarlig, styringsgruppen og prosjektleder. avn Roller Ansvar Prosjekteier (oppdragsansvarlig) Styringsgruppeleder Styringsgruppemedlem Styringsgruppemedlem Prosjektleder Prosjektdeltaker Prosjektdeltaker Tilhørighet Veiledning til organisering og bemanning Roller Prosjekteier: Første leddet i bemanningen starter med å Skriver kontrakt/direktiv (hensikt, mål og rammer) utpeke de roller som er nødvendige for Utpeker styringsgruppe prosjektet. Rapporter til bedrift ledelsen Gå nøye gjennom rollebeskrivelsene lebeskrivelsene i kapittel Godkjenner sluttresultatet 2 og tilpass dette til prosjektets behov. Følgende roller finnes normalt i et prosjekt: Styringsgruppe: Utpeker prosjektleder prosjekteier Starter prosjektet i henhold til kontrakt/direktiv styringsgruppe Godkjenner Prosjekt Kvalitets Plan prosjektleder Sørger for tilstrekkelig ressurser til prosjektet prosjektdeltaker Vurderer løpende prosjektets utvikling Beslutter om tiltak ved avvik Bemanning av styringsgruppen Godkjenner milepæls resultat og videre planer ormalt skal oppdragsansvarlig lede Ivaretar samordning med andre forandringer i organisasjonen styringsgruppen. Øvrige deltakere er gjerne Avslutter prosjektet ledere for de fagenhetene som skal bruke og forvalte prosjektets resultater. Dette er også Prosjektleder: oftest de som avgir ressurser til prosjektet og Driver arbeidet i henhold til direktiv og kvalitetsplan som dermed fatte beslutninger ved viktige Detaljplanlegger på aktivitetsnivå prioriteringer. Det er viktig at Følger opp p.r. uke styringsgruppens medlemmer er Rapporterer til styringsgruppen periodevis beslutningsdyktig i egen enhet. For større Foreslår handlingsplan ved forstyrrelser prosjekter skal det alltid finnes en Gjennomfører kvalitetssikringstiltak styringsgruppe, mens det for mindre prosjekter Har ansvar for standard på prosjektdokumentasjon holder med at oppdragsansvarlige er Informerer ulike interessenter styringsgruppen. Støtter og samordner prosjektets arbeidsgrupper Sørger for at prosjektet har arbeidsro og motivasjon Bemanning av referansegruppen De som bør sitte i referansegruppen(e) er: ledere av avdelinger som blir berørt av resultatet, men som ikke deltar i prosjektgruppen representanter for berørte avdelinger ressurspersoner med fagkompetanse som prosjektet trenger råd og fra

14 14 / 26 Bemanning av prosjektgruppen Ved bemanning og sammensetning av prosjektet er det viktig å ta hensyn til: 1. Riktig faglig kompetanse Prosjektet må totalt sett sikre seg at alle kompetansebehovene dekkes. Manglende kompetanse må evt suppleres ved opplæring. 2. Riktige egenskaper En prosjektgruppe skal fungere godt sammen over en lengre periode, og det er viktig at gruppen har egenskaper som utfyller hverandre. Utfyllende egenskaper skaper normalt god effektivitet. 3. Deltakelse av nøkkelpersonell Oppdragseier Styringsgruppe Referansegruppe økkelpersonell både med hensyn til kunnskap om detaljer innenfor fagområdet, men også brukere og de som skal ivareta resultatet når Prosjektleder prosjektet er ferdig. 4. Hel-/halvtidsengasjement Dette bør vurderes nøye. For å sikre kontinuitet bør prosjektet ha noen personer på heltid. Dette gjelder først og fremst nøkkelpersonell. For Stab/sekr. Gruppe 1 Gruppe 2 Referansegruppe Gruppe 3 deltidsengasjement bør innsatsen sen minimum være 40% - 2 dager per uke. Eks. på en prosjektorganisasjon 5. Organisasjonens deltakelse 6. Bruk av eksterne konsulenter bør ikke dominere prosjektet. Ved bruk bør det sikres kompetansetilførsel til etatens egne prosjektdeltakere. I størst mulig grad skal etatens egne ansatte være prosjektledere. 5.2 Kompetansebehov Dette punktet fylles kun ut hvis bemanningen ikke er klar når prosjektdirektivet utarbeides for godkjenning. Dersom personene er avgitt til prosjektet navngis alle deltakerne med en beskrivelse av hvor mye den enkelte deltar (50%, 100% ol.) For prosjekter som ikke har bemanningen klar beskrives krav til de rollene som prosjektet har behov for. Tabellen under kan være et godt hjelpemiddel for kompetanse- og ressursbehov. Rolle Prosjektdeltaker Person Kompetanse % tilgjengelig Tidsperiode Systemutvikling Ansvar 5.3 Eierskap / grensesnitt (organisasjonens deltagelse) Et prosjekt kan være komplisert og involvere mange parter. Det er viktig å kartlegge hvem som har grensesnitt mot prosjektet, hvem som skal involveres og ikke minst hvilket ansvar de skal ha. Følgende enkle matrise(ansvarskart) kan være til hjelp for å lage seg en oversikt (en mer omfattende modell finnes i verktøyboksen) Aktiviteter Lage prosjektplan Gi info til SG Lage budsjett Ola H HU H Ansvarlige / Personer / Instanser Per Kari Eva U I I I K K U K Leverandører Styrings gruppe Interessenter Prosjekt leder Prosjekt Referanse gruppe gruppe U = Utførende K = Konsulteres H = Hovedansvarlig I = Informeres Organisasjon

15 15 / A SVARSFORDELI G Det er viktig å definere og å beskrive ansvarsfordeling mellom aktørene i prosjektet, slik at misforståelser unngåes. Også ubesatte roller skal beskrives. Dette kan gjøres som i eksempel: avn Roller Utvikling Sinsen Styringsgruppen Prosjektleder Divisjonssjef Prosjektdeltaker Etc Ansvar Beslutte flyttetidspunkt for den enkelte flytting For å avklare at interne aktører/ressurser bidrar (renhold, IKT, Teknisk, transport, andre ) Utarbeide overordnet flytteplan Utarbeide mal for aktiviteter ved enkeltflyttinger Planlegge den enkelte flytting sammen med lokal flyttekoordinator Koordinere andre interne og eksterne aktører ifm. flyttingene Klargjøre midlertidige lokaler Å informere de som skal flytte Oppnevne lokal flyttekoordinator At klinikkens verneombud og tillitsvalgte er informert og involvert på riktig nivå Fordele rom som skal tilflyttes Skaffe interne ressurser til å gjennomføre flyttingen Være tilgjengelig til avtalt Rett kompetanse. 6.1 Prosjektets forhold til linjen Definer og beskriv ansvarsfordeling mellom linjen og prosjektet og beskrive hvordan kommunikasjon mellom prosjektet og linjen skal foregå. Det bør beskrives hva prosjektet forutsetter fra linjen og hva linjen krever av prosjektet. Planer for håndtering av overgang fra prosjekt til linjen bør inkluderes som en oppgave i prosjektet der det er relevant. Det bør beskrives hvilke andre pågående prosjekter eller linjeoppgaver som prosjektet må forholde seg til og hvordan en slik koordinering skal ivaretas.

16 16 / PRI SIPPER FOR STYRI G OG OPPFØLGI G 7.1 Oppfølging og statusrapportering En god møteplan er viktig å få på plass. Disse møtene danner grunnlag for videre fremdrift. Man må derfor ha kontroll på de møtene som skal gjennomføres. Kontroll innen måloppnåelse, agenda, tidspunkt og ikke minst hvem som skal delta. Møteplan for prosjekt Arbeidsgruppe XXX Møte bedrift / leverandør Hensikt Fastsette leveranser godkjenne planer. Agenda Agenda tidsplan Godkjenne referat fra forrige møte. Status aksjonsliste Utvikling /prosess Eventuelt Oppdatere aksjonsliste Ansvarlig for invitasjon Prosjektleder Ansvarlig for Leder for delprosjekt, gjennomføring Prosjektleder Referent Prosjektleder Distribusjon referat Brukergruppe, prosjekt Deltakere Brukergruppe leverandør og prosjektgruppe. Delprosjektleder deltar ved behov. Tid Annenhver onsdag kl (start ) Sted Møtelokale Leverandør Eksempel på oppsett av møteplan. Internt prosjektmøte Status / framdriftsmøte for prosjektgruppen Agenda tidsplan Referat fra forrige møte Aksjonsliste / milepæler Eventuelt Oppdatere aksjons- liste Prosjektleder Prosjektleder Prosjektleder Prosjektleder Delprosjektleder Prosjektleder Delprosjektleder Prosjektgruppe Hver mandag kl Møtelokale bedrift Styringsgruppe møter bedrift / prosjekt Status / framdriftsmøte. Godkjenning av leveranser og eventuell endringshåndtering. Agenda tidsplan Orientering fra prosjektleder angående status, framdrift, leveranser, og eventuell endringshåndtering. Vedtak / beslutning Aksjonsliste Leder styringsgruppe Leder styringsgruppe Prosjektleder Medlemmer i styringsgruppe. Kopi til ledergruppen Medlemmer av styringsgruppen, prosjektleder, sekretær, observatør Følgende datoer : 17.09, 15.11, 17.01, kl Møtelokale bedrift Statusrapportering omfatter både rapportering fra deltakerne til prosjektleder/delprosjektleder og til styringsgruppen Fra prosjektdeltaker til prosjektleder/delprosjektleder Følgende bør beskrives her: hvem som skal rapportere når statusrapportering skal skje hva som skal rapporteres hvordan det skal rapporteres. Et eksempel: Prosjektdeltakerne skal rapportere status ormalt innrapporteres det status ukentlig til prosjektleder/delprosjektleder -mandag Det rapporteres timer forbruk pr aktivitet, estimert gjenstående og ferdighetsgrad (for større prosjekter). I tillegg kommenteres eventuelle endringer, risiko el. som den enkelte deltaker ser kan inntreffe i perioden fremover. Det skal rapporteres i form av utfylt Aktivitetsrapport

17 17 / Fra prosjektleder til styringsgruppen Følgende bør beskrives her: hvem som skal rapportere når statusrapportering skal skje hva som skal rapporteres hvordan det skal rapporteres Et eksempel Prosjektleder skal utarbeide statusrapport til hvert styringsgruppemøte Statusrapporten skal være styringsgruppen i hende 1 uke før styringsgruppemøtet er berammet. Ved større avvik skal styringsgruppen underrettes umiddelbart Statusrapporten skal inneholde: vurdering av fremdrift foreløpige resultater ressursbruk i forhold til prosjektplanen eventuelle avvik risiko Mal for statusrapportering til styringsgruppen skal følges Styringsgruppemøter Tidsplan for styringsgruppemøtene er ofte knyttet opp mot viktige milepeler i prosjektet, hvor det er påkrevd med godkjenning og vedtak i styringsgruppen. Dersom datoene er kjente settes disse opp her. Dato Ansvarlig (innkalling) Hvor Kommentar Prosjektleder Store møterom Inviter leverandør Prosjektleder Store møterom 7.2 Kommunikasjonsplan Det er viktig å ha en formening om hvem som skal ha informasjon, om hva og når. Her kan en kommunikasjonsmatrise (lignende ansvarsmatrisen) brukes. Aktiviteter / Dokumenter Ansvar Per Kari Mottakere Avd. A Avd. D (øko) Prosjekt status PL 1. mandag hver mnd 1. mandag hver mnd 1. mandag hver mnd Timeoppfølging PL Hver fredag Budsjettrapport PL Kurs I II - III Anne Informasjon om prosjekt Tor Leverandør Prosjektoppfølging Under dette punktet kan prosjektet beskrive de elementene som prosjektet bruker under gjennomføringsfasen Resultatoppfølging

18 18 / Fremdriftskontroll Ressursoppfølging Kostnadsoppfølging Risikohåndtering

19 19 / AKTIVITETS- OG TIDSPLA Innholdet i dette kapittelet vil avhenge av størrelsen på prosjektet. For mindre prosjekter der prosjektdirektiv og plan er slått sammen, skal hovedaktivitetene beskrives her. For større prosjekter holder det med fasebeskrivelser. Milepælsplan skal beskrives for alle prosjekter. 8.1 Milepælsplan Beskriv milepælene og tidspunktene for når disse skal nås. Det er kun de milepælene som skal være gjenstand for styringsgruppebehandling som skal beskrives her. Definisjon av milepæler Milepælene skal være indikatorer på: tilstander i prosjektet i forhold til resultater/leveranser tilstander i prosjektet i forhold til fremdrift kontrollpunkter som skal passeres før videre aktiviteter startes En milepæl er en beskrivelse av en tilstand som skal nås og som er ønsket som en tilstand på veien til en full realisering av prosjektets målsetting. Milepælnr Milepælsbeskrivelse Dato Resultat M1 Når prosjektdirektiv og plan er godkjent av styringsgruppen M2 Når analyse av nåsituasjonen er verifisert av linjen M3 Når kvalitetstest av leveransen er utført og arbeidet godkjent av styringsgruppen Eksempel på en milepælsplan En milepælsplan er en logisk plan som viser sammenhengene mellom milepælene som er aktuelle for prosjektet. M 2 M 1 M 5 M 3 M 4 Figuren til venstre side illustrerer sammenhengene mellom et prosjekts milepæler. Denne figuren viser rekkefølgen av milepælene, samt at det er mulig å kjøre parallelle løp. M1 er felles milepæl som indikerer at løpene M2 og M3 kan startes. M5 kan ikke nås før både M2, M3 og M4 er nådd. ormal legges det milepæler med 1-2 måneders mellomrom. M 6 M 7 M 8

20 20 / Faser/hovedaktiviteter Verbal beskrivelse som inneholder: hensikten med aktivitetenen oppstartskriterier (beslutninger eller andre aktiviteter som må være gjort først) beskrivelse av aktiviteten resultater fra aktiviteten Akt.nr. Hensikt 1.1 Alle prosjektledere skal ha samme kunnskap om prosjektledelse 1.2 Begynne delprosjekter Oppstartskriterie Klinikksjefene må ha funnet egnede personer. Kurs må ha blitt laget Ha egnede prosjektledere, eierskap i linjen Beskrivelse Kurs av fremtidige prosjektledere Fordele og starte opp prosjekter Resultat Alle prosjektledere skal ha samme oppfatning av metodeverk Prosjektene startes opp i følge metode og under full kontroll 8.3 Gantt-diagram Både milepælsplan og aktiviteter kan med fordel legges inn i et Gantt diagram. Dette vil ofte gi et klarere inntrykk og oversikt over milepælene, aktivitetene og ikke minst sammenhengene mellom disse i et prosjekt. Gantt-diagram vil ligge i verktøyboksen. Hovedaktiviteter 2007 feb mars april mai juni juli aug sept okt nov des Prosjektledelse Rutiner og igangsetting Informasjon Rutiner av innleggelse av dokumentasjon Etablere lokaler Kartlegging av utstyr og plassering Anskaffelse av utstyr Ansettelse av personell Opplæring Oppfølging og avslutning av prosjekt Gjennomføre hovedprosjekt Vurdere antall journalkgruppeskannere Overføring av journalgruppeskanning til linje Støtte/tuning av dokumentskanning M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M Leveranser Dersom milepælsbeskrivelsene også omfatter resultater r kan denne utelukkes. Leveranseplanen skal omfatte hele prosjektets samlede leveranser. Gjøres kun dersom direktiv og plan er slått sammen. Hører ellers normalt til i leveranseplanen (plandokumentet). Dato Til Dato Leveranse Prosjektdirektiv og -plan Beskrivelse av dagen situasjon (funksjoner) og hvorledes de er ivaretatt med roller og ansvarsfordeling. Oversikt over kompetanse, budsjetter og de viktigste problemstillinger.. Ansvar PL PL

21 21 / KVALITETSSIKRI G OG E DRI GSHÅ DTERI G Kvalitetssikring av et prosjekt er ofte en løpende aktivitet. Hensikten er følgelig å sikre at prosjektet blir gjennomført og leverer til avtalt kvalitet (tid, økonomi, leveranse). Om det oppstår en risiko eller en endring i forhold til avtale, da må en endringsanmodning sterkt vurderes. 9.1 Ekstern kvalitetssikring Kun for større prosjekter. Bør avklares tidlig mot styringsgruppen eller oppdragsansvarlig. Beskriv kort opplegget for ekstern kvalitetssikring. Hvem år Veritas, v. J. Dieter Hva Prosjektgjennomføring og budsjett Hvor Store møterom, bygg Intern kvalitetssikring Dette skal alltid gjennomføres. Beskriv følgende: hva skal kvalitetssikres (resultater, dokumenter, prosesser ol.) hvem som skal gjennomføre kvalitetssikringen når og hvordan Hvem år Timm Sanders, G&S Timm Sanders, G&S Hva Prosjektdirektiv, prosjektorganisasjon ALT! Forberedelse til ekstern revisjon Hvor Prosjektrom Prosjektrom 9.3 Endrings- (problem)håndtering Hensikten medendringskontroll er å styre håndteringen av alle endringer i prosjektet. Dette avsnittet regulerer aktiviteter forbundet med endringer, fra utarbeidelse av endringsanmodningen til godkjenning Prosedyre En endring kan defineres i to alvorsgrader 1. Anmodninger om endringer i forutsetningene, som oppstår i prosjektet og som ikke påvirker tid (prosjektplanen), kvalitet (leveranse) eller økonomi (omfanget), behandles av prosjektleder. Prosjektleder vil være den som normalt vil avgjøre om endringene skal taes med eller ikke i inneværende fase. Ved usikkerhet, skal dette rapporteres til styringsgruppen/oppdragsansvarlig. 2. Om endringsanmodningen påvirker prosjektet i tid, kvalitet eller økonomi skal dette rapporteres til styringsgruppen/oppdragsansvarlig og styringsgruppen/oppdragsansvarlig skal ta beslutning om tiltak Registrering Endringsanmodninger registreres på formular endringsskjema, Alle mottatte endringsanmodninger registreres i prosjektarkivet og i endringslogg (se verktøykassen). Det skal klart fremgå av endringsanmodningen hvorfor endringen er ønsket, hva endringen består i, og hvem som har initiert endringen. Konsekvensen av å foreta (evt. ikke foreta) endringen skal beskrives. Endringsanmodninger leveres styringsgruppe/oppdragsansvarlig med innstilling.

22 22 / Innstilling - utredning, analyse og konsekvens Prosjektleder har ansvar for innstilling, men aktiviteten (anmodningen) utføres av de som har best forutsetninger for å vurdere: Arbeidsomfang (timer og kalendertid) Konsekvenser for ferdigtidspunkt Kvalitetsmessige konsekvenser Budsjettmessige konsekvenser Beslutning Beslutning om videre behandling tas av oppdragsansvarlig eller styringsgruppen, avhengig av omfang og konsekvenser. Endringsanmodningen skal påføres den prioritet den skal ha ved eventuell gjennomføring. Alle endringsanmodninger skal etter behandling signeres, ny status registreres og endringslogg oppdateres. Aktiviteten kan resultere i: 1. Endringen vedtas. Endringsanmodningen går tilbake til prosjektleder med beslutning om og prioritet for gjennomføring. y status registreres. 2. Endring avvises. y status registreres og endringsanmodningen arkiveres Gyldig status Status for endringsanmodninger skal oppdateres i tråd med behandlingen. Følgende status skal benyttes: Status Registrert Bearbeidet Forkastet Utført Utredning Vedtatt Verifisert Akseptert Registrert Dato og hvem som har registrert Dato og hvem som har bearbeidet Dato og hvem som har forkastet Dato og hvem som har utført endringen Dato og hvem som har vedtatt utredningen Dato og hvem som har vedtatt Dato og hvem som har verifisert Dato og hvem som har akseptert Styring Oversikt over hvem som har ansvaret for de ulike trinn i endringsprosedyren Trinn Mottak av endringsanmodning Analyse av endringsanmodning Beslutning Oppfølging Kontroll Lagring Informere om endringsanmodninger Ansvarlig Prosjektleder, oppdragsansvarlig, styringsgruppe Utnevnt ekspert Oppdragsansvarlig, styringsgruppe Utnevnt ekspert Utnevnt ekspert, kvalitetssikrer Prosjektleder Prosjektleder

23 23 / RISIKOHÅ DTERI G I prosjektmandatet er det første versjon av en overordnet risikoanalyse som skal beskrives. Risikoene er nært knyttet til suksesskriteriene (se kap. 3.3). I prosjektdirektivet suppleres risikoanalysen dersom det er flere risiko som oppdages i løpet av planleggingsprosessen. Risikostyring er en løpende oppgave, og skal vurderes ved statusrapportering til styringsgruppen. gruppen. Mal for risikologg Sannsynlighet, kode S: Aktuell bedømmelse av sannsynligheten for at hendelsen inntreffer dersom planlagte tiltak ikke gjennomføres 5 Svært stor (> 90 % sannsynlighet) 4 Stor (60 90 %) 3 Moderat (30 60 %) 2 Liten (10 30 %) 1 Meget liten (< 10 %) 0 Ingen Risikon er bortfalt eller eliminert Konsekvens, kode K: Bedømmelse av konsekvensene om hendelsen inntreffer: 5 Svært alvorlig Hele (del)prosjektet er i fare 4 Alvorlig Hele (del)prosjektets planer må gjøres om 3 Moderat Hele (del)prosjektets planer påvirkes, men totalrammen for prosjektet kan holdes 2 Lav Planer for (del)prosjektet påvirkes, men totalrammen holdes 1 Ubetydelig Begrenset virkning, kan innhentes 0 Ingen konsekvens r Risiko/problem/hendelse S K 17 Test av budsjettrapport, viser feil data 3 Ny server kan bli forsinket 11 Forsinkelse, glemte helligdag 5 Ekspert på rapport er opptatt i andre prosjekter S K Konsekvens Gardering /tiltak 16 Programmet vil være ubrukelig 4 Vil ikke kunne starte opp til avtalt dato 6 Blir forsinket med rapport, 2 dag 5 Forsinkelse på utskrift Ny modul fra leverandør Finne alternativ leverandør Jobbe overtid Snakke med leder Kommentar Be om at Steinar installerer! Risiko forventet eliminert Høy prioritet Dette er nå løst Risiko eliminert Status A Ans. PL PL OK TL U Risikomatrise Bruk av malen r ummer på risiko. Den høyeste (mest Svært stor alvorlige) risiko skal stå først. 5 Risiko/prob. Beskrivelse av risikoen, så detaljert 17 Stor 4 som mulig Risiko S Sannsynlighetskode Kritisk K Konsekvenskode Moderat 3 Høy S*K Summen av S addert med K Moderat Konsekvens Hva skjer om risiko slår til? Liten 2 Lav Gardering Hvilke tiltak kan iverksettes 5 Kommentar Ekstra opplysninger Meget liten 11 R. forv.el. år skal risikoen være løst. Den dato tiltaket skal være gjennomført. Dersom 3 1 Ubetydlig Lav Moderat Alvorlig Svært Alvorlig denne datoen overskrides, skal dette Konsekvens forklares i statusrapporten, og ny dato settes En risikologg bør alltid vises i følgende figur. Den vil med Risk. el. Risiko faktisk løst et raskt blikk fortelle status på risiko i prosjektet Status Feltet kan ha fire mulige verdier: "Blankt" betyr at tiltaket ikke er påbegynt "A" betyr at tiltaket er under arbeid "OK" betyr at tiltaket er gjennomført "U" betyr at tiltaket utgår Ansvar Skal innholde initialer til den som har ansvaret for at tiltaket skal gjennomføres. Det er viktig at man følger opp tiltak selv om det er andre som står som ansvarlig. Sannsynlighet

24 24 / BUDSJETT Dette kapittelet skal beskrive de økonomiske betingelsene som prosjektet må styres innenfor. Det må avklares med oppdragsgiver om budsjette skal gjelde hele prosjektperioden eller bare det første året. Dette av hensyn til fordeling av budsjettmidler Budsjett Dette er utgangspunktet, det første budsjettet som lages for prosjektet, og det lages for planen er lagt. Det betyr at den er en ramme for planleggingen, men kan justeres avhengig av om dette e prosjektdirektiv sier noe om en økonomisk toleranseramme. ormalt kan en slik toleranseramme være +/- 15%. Dette er en forhandling som gjøres mellom prosjektet og oppdragsgiver/styringsgruppen. styringsgruppen. Eksempel på et budsjett Økonomirapportering iht.periodisert budsjett, PAS/EPJ hovedprosjekt Revidert budsjett pr revidert budsjett pr Kostnad Totalt budsjett revidert budsjett Budsjett pr Kostnader pr Avvik pr merknad Prognose totalt budsjett Forventet avvik Totalt budsjett Totalt PAS/epj prosjektet Internt forprosjekt Felles forprosjekt prosjektets reserve Hovedprosjektet Moduler DIPS eksklusive integrasjoner Modulkostnader DIPS-funksjonalitet E-læring Modulkostnader e-læring fullført Opplæring Kostnader for kurs i regi av DIPS Skanning /EPJ/sykepleiedok/dig.diktering Prosjektet annen kompetansebygging Diverse (herunder servering med mer) pr.mars, Opplæringsfasiliteter fulført Eksterne konsulenter inkl. reise apr.06 Timekostnader Støtte til økonomirapportering Reise Interne personalressurser Lønnskostnader prosjektdeltakere Overtid Frikjøp av ressurser i linjen Integrasjoner Modulkostnader grensesnitt Fast tilasningsavgift DIPS Kostnader 3. Parts leverandør Konverteringer Konverteringer fast pris fullført Uttrekk fra Doculive fullført Konvertering SPINN Konvertering Profdoc fullført Produksjons- og lagringsmiljø DIPS Økning i antall terminalservere grunnet DIPS (SW+HW) Nye produksjonsservere til PAS/EPJ Oracle lisenser fullført Lagringskapasitet Rack Dette er en måte å vise et budsjettet på. Det kan også være hensiktmessig å periodisere budsjettet. Vedlegg 2 til statusrapportering utsatt aktiviteter Miclis er fakt

25 25 / ADMI ISTRATIVE RET I GSLI JER Her beskrives hvilke av de administrative retningslinjene fra prosjekthåndboken som prosjektet skal benytte. Samtidig vises det til maler og standarder som prosjektet skal bruke. Eventuelle avvik i fra prosjekthåndboken skal også beskrives.

26 26 / KRITERIER FOR AVSLUT I G AV PROSJEKTET Her skal kriteriene for at prosjektet kan avsluttes beskrives. ormalt vil dette være å gjenta resultatkravene fra Kapittel Det kan i tillegg være krav til formell overlevering, kompetanseoverføring eller lignende som skal ha vært utført før avslutningen kan skje Evaluering Formålet med aktiviteten er å evaluere prosjektet med hensyn til kvalitet på resultater, på selve prosjektarbeidet og fremdrift og økonomi i forhold til plan. Det anbefales at evalueringer gjennomføres som arbeidsmøte der viktige deltakere i ulike grupper av prosjektet deltar. Det er viktig at mulighetene for læring som settes i fokus, slik at ikke denne aktiviteten oppfattes som et negativt møte der man fordeler skylden for hvorfor ikke alt gikk 100 % etter planen. For det siste gjør det sjelden og hele hensikten her er å lære hvordan man neste gang kan gjøre det bedre. edenfor er listet opp noen områder som anbefales evaluert: det styringsmessige - sammensetning av prosjektet beslutningsprosesser prosjektmandat planlegging og oppfølging økonomi og framdrift ledelse og deltakelse bruk av metoder, retningslinjer, verktøy og standarder Evalueringen bør munne ut i en rapport med forslag til forbedringer Utarbeide sluttrapport som inneholder følgende opplysninger: beskrivelse av de mål og resultater prosjektet har nådd, samt sannsynliggjøre at gevinstmålene kan realiseres kort oppsummering av prosjektprosessen (prosjektforløpet) avsluttende regnskap og evt. avviksforklaring 13.3 Oppløsing av prosjektet Formålet med aktiviteten er å markere at prosjektet er avsluttet. Beskriv hvordan det praktisk skal gjennomføres. Denne aktiviteten bør også stå på fremdriftsplanen. Oppløsing av prosjektet omfatter oppryddingsaktiviteter, informasjon til alle om at prosjektet avsluttes og gjennomføring av avslutningsmøte. Avslutningsmøte er tilsvarende oppstartsmøte, en faglig (og sosial) samling for å markere at prosjektet er avsluttet Overføring til forvaltning