Vejledning Projektinitieringsdokumentet (PID) August 2013
INDHOLD 1 INDLEDNING... 1 1.1 FORMÅL... 1 1.2 PROJEKTINITIERINGSDOKUMENT (PID)... 1 1.3 VEJLEDNINGENS SAMMENHÆNG MED DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL. 2 2 ANVENDELSE AF PID I DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL... 3 2.1 ANVENDELSE AF PID EN I PROJEKTFORLØB... 3 3 UDFYLDELSE AF PID... 4 3.1 STAMDATA... 4 3.2 FORRETNINGENS FORMÅL MED PROJEKTET... 4 3.3 AFGRÆNSNING... 5 3.4 MÅL OG SUCCESKRITERIER... 5 3.5 ØKONOMISKE HOVEDTAL OG FINANSIERING... 6 3.6 GEVINSTER... 7 3.7 TEKNISK LØSNING... 8 3.8 LEVERANCER... 8 3.9 ORGANISERING... 10 3.10 TILRETTELÆGGELSE OG TIDSPLAN... 11 3.11 AFHÆNGIGHEDER... 11 3.12 KVALITET... 12 3.13 RISICI... 12 3.14 INTERESSENTER... 13 3.15 KOMMUNIKATION... 13 3.16 TOLERANCER... 14 3.17 RAPPORTERINGSKRAV... 14 3.18 REVISIONSHISTORIK... 14 3.19 BILAG... 14 3.20 PRODUKTBILAG A: GEVINSTDIAGRAM... 14 3.21 PRODUKTBILAG B: GEVINSTDETALJER... 15 3.22 PRODUKTBILAG C: RISIKOREGISTER... 17 4 KVALITETSSIKRING AF PID EN... 20
1 Indledning I dette afsnit beskrives, hvem denne vejledning henvender sig til, hvilke emner vejledningen behandler, samt hvad et projektinitieringsdokument er. 1.1 Formål Denne vejledning henvender sig til ministerier, der ønsker at gennemføre it-projekter. Formålet er at understøtte myndighederne i udfyldelsen af projektinitieringsdokumentet (refereret som PID) Vejledningen retter sig specifikt mod projektledere, der skal i gang med opgaven at udarbejde PID en. Vejledningen beskriver, hvad en PID er og med hvilket formål man anvender og udarbejder PID en. Afsnit 2 beskriver PID ens placering og anvendelse i forhold til den fællesstatslige itprojektmodel og faserne heri. I afsnit 3 gennemgås PID ens indhold detaljeret, hvor der gives eksempler på, hvordan PID en udfyldes. Vejledningen afsluttes med råd og vejledning til kvalitetssikring af PID en. 1.2 Projektinitieringsdokument (PID) 1.2.1 Hvad er en PID? PID en er det dokument, der fastholder de overordnede forventninger til og rammer for projektet. Dokumentet kan opfattes som kontrakten mellem styregruppen (herunder forretningen) og projektlederen. I dokumentet udstikkes projektets kurs og projektets omfang fastsættes. Dokumentet udgør således aftalen om projektet og skal godkendes af styregruppen. PID en definerer projektet og udgør grundlaget for ledelsen og styringen af projektet. I sidste ende er PID en dermed også grundlag for vurderingen af, hvorvidt projektet har været en succes. Dokumentet er et ledelsesprodukt i den fælles statslige it-projektmodel. Skabelonen er obligatorisk at anvende for it-projekter over 10 mio. kr. ved risikovurdering hos Statens ITprojektråd. 1.2.2 Formålet med at udarbejde en PID PID en har to primære formål: det skal sikre, at projektet har et stabilt grundlag, før styregruppen forpligter sig til projektet, herunder afholdelse af væsentlige udgifter. det skal fungere som et grunddokument (baseline) således, at styregruppen og projektlederen kan vurdere fremdrift, afvigelsesstyring og løbende stillingtagen til, om projektet skal fortsætte. PID en skal også give styregruppen et grundlag til at vurdere, om det overordnede formål med projektet dækkes af projektets leverancer og fremgangsmåde. Ved brugen af PID en sikres det, at ledelsen involveres og træffer forretnings- og prioriteringsmæssige beslutninger i forhold til de godkendte rammer og den ajourførte business case. Samtidig sikres forretningsledelsens mulighed for at forventningsafstemme i forhold til det produkt, som forretningen skal overtage ejerskab af, drifte og vedligeholde, når projektet slutter. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [1]
1.2.3 Modtagere af PID en Styregruppen er den primære modtager af PID en. Styregruppen skal godkende PID en. PID en skal tillige indsendes til IT-projektrådet i forbindelse med risikovurdering, hvis projektet har et budget over 10 mio. kr. PID en skal kunne bruges af projektlederen og projektmedarbejderne som fælles referencegrundlag. 1.3 Vejledningens sammenhæng med den fællesstatslige itprojektmodel Denne vejledning tilbyder hjælp til udfyldelse af et af de to primære ledelsesprodukter i den fællesstatslige it-projektmodel PID en. Det andet bærende dokument for projektgennemløb i den fællesstatslige it-projektmodel er business casen. Business case og vejledninger kan hentes på Digitaliseringsstyrelsens hjemmeside. Den fællesstatslige it-projektmodel er udarbejdet med baggrund i eksisterende bedste praksis i staten samt principper fra projektstyringsmetoden PRINCE2. It-projektmodellen er endvidere udarbejdet med henblik på at understøtte de 5 principper for it-projekter i staten, som er beskrevet i Professionalisering af arbejdet med it-projekter i staten og videreudviklet af Statens IT-projektråd. Du kan læse mere om og den fællesstatslige it-projektmodel i vejledning om den fællesstatslige it-projektmodel. It-projektmodellen opdateres to gange årlige med fx ændrede produkter, nye værktøjer eller vejledninger. Specifikt bemærkes PID ens produktbilag C, indeholdende risikoregisteret. Risikostyring er et kritisk element i gennemførelsen af projekter, hvorfor der er udarbejdet en særskilt vejledning til risikostyring - vejledning om risikostyring og anvendelse af risikoregisteret. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [2]
2 Anvendelse af PID i den fællesstatslige it-projektmodel PID en anvendes som styringsdokument under gennemløbet af analyse-, anskaffelses- og gennemførelsesfasen i den fællesstatslige it-projektmodel. Dette afsnit placerer PID en i modellen. Den fællesstatslige it-projektmodel er en one-size-fits-all projektmodel, beregnet for anvendelse på alle statslige it-projekter. Modellen omfatter overordnet set: En model for faseopdeling af projektforløbet Principper for overgang fra en fase til næste fase Et antal ledelsesprodukter og skabeloner hertil (også kaldet produkter) Beskrivelser af roller og ansvar PID en er sammen med business casen de bærende ledelsesprodukter i modellen. I tillæg til ledelsesprodukter indeholder den fællesstatslige it-projektmodel en række værktøjer og vejledninger til understøttelse af projektforløb og anvendelse af produkterne. Produkter, værktøjer og vejledninger er tilgængeligt på ministeriernes projektkontors hjemmeside. 2.1 Anvendelse af PID en i projektforløb It-projektmodellen er en fasemodel hvor resultatet af hver fase er produkter, som støtter styringen af projektet hen imod projektets samlede leverancer, herunder i særdeleshed PID en. Fasemodellen inkl. ledelsesprodukter er angivet i figuren nedenfor. Figur 1. Den fællesstatslige it-projektmodel inkl. ledelsesprodukter. Idé Analyse Ledelsesfase > Ledelsesfase Anskaffelse Specificering > Udbud Gennemførelse Ledelsesfase > Ledelsesfase Realisering Projektgrundlag Projektinitieringsdokument (PID) Projektafslutningsrapport Gevinstrealiseringsrapport Business case It-projektmodellen indeholder fem hovedfaser: Idéfase: Ideen kvalificeres og udmøntes i et projektgrundlag. Analysefase: Projektet defineres og beskrives i PID en med tilhørende business case og evt. risikotjekliste til Statens IT-projektråd. Anskaffelsesfase: Specificering af krav og behov samt gennemførsel af anskaffelsesproces typisk via udbud. Gennemførselsfase: Kontrakter underskrives, og projektets leverancer realiseres. Fasen løber frem til systemet er idriftsat og implementeret organisatorisk. Realiseringsfase: Business casen realiseres, og gevinsterne hjemtages. Den endelige opdeling i faser for det aktuelle projekt dokumenteres i PID en. Projektlederen er ansvarlig for udarbejdelse af PID en. PID en udarbejdes i analysefasen og opdateres ved hver faseovergang indtil projektet afsluttes og dokumenteres i projektafslutningsrapporten. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [3]
3 Udfyldelse af PID Ministeriernes projektkontor har udgivet og vedligeholder en skabelon for en generisk PID. Dette afsnit gennemgår i detaljer afsnittene i PID en samt giver eksempler på udfyldelse. Den generiske skabelon for PID en, som kan hentes på ministeriernes projektkontors hjemmeside, er udarbejdet på basis af best practice i staten samt principper fra projektstyringsmetoden PRINCE2. PID en består af 19 hovedafsnit samt 3 produktbilag. Disse afsnit gennemgås efterfølgende. Underafsnitsnumrene refererer til hovedafsnit i PID en, eksempelvis er afsnit 3.1 Stamdata afsnit 1 i PID en. Det understreges, at PID skabelonen er en generisk skabelon. Ikke alle afsnit og overskrifter i skabelonen er relevante for alle projekter. Det er projektlederens ansvar at tilpasse skabelonen til det aktuelle projekt. Projektlederen har mulighed for at tilføje yderligere afsnit til skabelonen, hvis dette er relevant for styringen af det konkrete projekt. Ligeledes har projektlederen mulighed for at indsætte yderligere produktbilag eller vedlægge bilag til PID en efter behov. Afsnit som eksempelvis kvalitet eller gevinstrealisering kan også udpindes i selvstændige dokumenter, hvis PID en bliver for omfangsrig til at give det ønskede overblik. Det kan udelades at udfylde eksisterende afsnit i PID en, blot skal der i forhold til evt. risikovurdering hos Statens IT-projektråd indføjes en begrundelser under afsnittet. Når PID en udfyldes, er det vigtigt at man som projektleder holder sig de fem principper for it-projekter for øje. Principperne findes i vejledning om den fællesstatslige it-projektmodel. 3.1 Stamdata I første afsnit angives stamdata for projektet. Projektets formål angives til en af de tre i business casen beskrevne muligheder effektiviseringsprojekt, kvalitetsløft eller lovprojekt. 3.2 Forretningens formål med projektet 3.2.1 Den nuværende situation (baggrund) Her beskrives kort den nuværende situation og tilhørende arbejdsprocesser som projektet er rettet mod. Anvend gerne procesdiagrammer. Afsnittet udgør baggrunden for før-situationen i business casen. Eksempel: Ministeriets nuværende ESDH-system blev udviklet til ministeriet for ca. 10 år siden. Produktets grundlæggende udviklingsplatform er forældet, vanskelig at vedligeholde og besværlig at opgradere, når ministeriets andre platforme opgraderes (styresystemer og kontorpakker). Ministeriet afholder høje årlige driftsomkostninger til vedligehold og support på grund af ovenstående faktorer samt afholdelse af separate licensomkostninger til specialtilpasninger. En proces for en typisk sagsgang med anvendelse af systemet ser ud som følgende (..). 3.2.2 Formålet med projektets løsning Her angives formålet med projektet for forretningen. Det skal fremgå om det primære formål er relateret til effektivisering, kvalitetsløft eller overholdelse af lovgivning. Kategorierne er beskrevet i business casen. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [4]
Eksempel: Projektets primære formål er effektivisering. Projektet skal nedbringe den årlige udgift til vedligehold samt optimere arbejdsopgaven i kontoret Dokumentation. Et nyt system vil levere en moderne platform med øget funktionalitet, som kan danne grundlag for andre senere digitaliseringsinitiativer i Ministeriet. 3.2.3 Projektets bidrag til strategiske mål Beskriv, hvordan projektets gennemførsel understøtter myndighedens strategiske mål, mission og vision. 3.2.4 Den fremtidige situation efter indførelse af løsningen Beskriv situationen efter løsningen er implementeret. Overvej om løsningen kan illustreres med en model og/eller visualiseres via procesdiagrammer. Beskrivelsen udgør baggrunden for 1-scenariet i business casen. For opgørelse af målbare effekter kan henvises til projektets business case og senere afsnit om gevinster. Eksempel: Ministeriet vil anskaffe et nyt fælles ESDH system. Kontoret Dokumentation vil kunne realisere en stillingsbesparelse på 1 årsværk gennem effektivisering af arbejdsgangene vedrørende oprettelse af akter, scanning og kvalitetssikring. Den årlige udgift til vedligehold og support af den nye løsning estimeres til at være mindre end den nuværende, både fordi opgaven bliver konkurrenceudsat, og fordi den nye løsning vil være et standardsystem. Et nyt system vil levere en moderne platform som med øget funktionalitet vil kunne danne grundlag for andre senere digitaliseringsinitiativer i Ministeriet. 3.2.5 Situationen hvis ikke projektet gennemføres (business as usual) Beskrivelse af situationen, hvis projektet ikke gennemføres, men med det billigste alternativ til at løse samme opgaver som projektet påvirker. Udgør baggrunden for 0-scenariet i business casen. Eksempel: Videreførelse af gammelt system: Ministeriet vil fortsat skulle afholde høje årlige driftsudgifter til sin nuværende leverandør. Systemet blev udviklet og tilpasset Ministeriet for over 10 år siden. Systemets alder og teknologiske platform gør det i stigende grad vanskeligt at vedligeholde og opgradere. Fortsat brug af eksisterende system og arbejdsgange vil fastholde et højt ressourceforbrug i Dokumentationskontoret. 3.2.6 Alternative løsningsscenarier Endelig beskrives under afsnit 2 i PID en hvilke alternative modeller for løsninger, der har været overvejet samt kort begrundelse for, hvorfor disse alternativer er blevet fravalgt. Eksempel: Alternativt scenarie A: Projektet udskydes to år for at anskaffe ESDH sammen med resten af Ministeriets koncern i et fælles udbud. Scenariet er fravalgt, da resten af Ministeriets koncern ikke er interesseret i et strategisk samarbejde. Alternativt scenarie B: Dele af systemet opgraderes for at nedsætte systemets driftsomkostninger. Scenariet er fravalgt da systemets funktionalitet ikke kan videreudvikles uden omkostninger i en størrelsesorden som skal konkurrenceudsættes, både pga. systemets alder og fordi det vil være specialudvikling. Scenariet er derfor ikke økonomisk rentabelt i forhold til valgt løsningsscenarie. 3.3 Afgrænsning Under dette afsnit beskrives afgræsninger til projektet, der ellers naturligt kunne opfattes som del af projektet. Hver begrænsning beskrives, og der gives en begrundelse for afgræsningen. 3.4 Mål og succeskriterier Her beskrives de overordnede mål for projektet. Mål bør være SMARTE (Specifikke, Målbare, Accepterede, Realistiske, Tidsfastsatte). Beskriv også succeskriterier for hvert mål, dvs. minimumskriteriet for, hvordan det opgøres, om målet er nået. Der kan være flere succeskriterier for et mål, ligesom succeskriterierne både kan relatere sig til projektets udførelse, til Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [5]
projektets output, dvs. de leverancer som projektet skal levere, samt til resultaterne af projektet de gevinster og den nytte, som implementeringen af projektets leverancer i organisationen skal høste. Målhierarkiet for et projekt er illustreret i følgende figur. Figur 2. Målhierarki for et typisk projekt. Nedenfor er givet et eksempel på, hvorledes tabellen i PID en afsnit 4 kan udfyldes. Eksempel: Projektets mål Beskrivelse Succeskriterier Lavere driftsudgift Nedbringelse af årlig driftsudgift til vedligeholdelse af system I år X skal den årlige driftsudgift til systemet være reduceret med 15 pct. og 2 år senere med 20 pct. Årsværksbesparelse gennem optimering af arbejdsgange Moderne infrastruktur Årsværksbesparelse efter optimering af opgaverne i kontoret Dokumentation Levering af en standard platform for ESDH, der understøtter senere digitaliserings- og effektiviseringstiltag I år X skal der være en besparelse på 1 årsværk i kontoret for Dokumentation Dette mål er tæt knyttet til projektets gevinst x4. Succeskriteriet fremgår af afsnit 6 om gevinster, samt af produktbilag A og B, ligeledes om gevinster 3.5 Økonomiske hovedtal og finansiering I dette afsnit indsættes nøgletal fra tabel 1.2 Økonomiske nøgletal fra den udarbejdede business case-model. Modellen kommenteres ift. den indledende forventning til projektets økonomiske hovedtal. Bemærk at kun nettonutidsværdien og intern rente kan afgøre, om et projekt økonomisk set er attraktivt, da en positiv nettogevinst ikke i sig selv er det samme, som at projektet økonomisk set er attraktivt. Projekter kan anses for at være økonomisk attraktive, hvis såvel den forventede som den risikojusterede nettonutidsværdi er positiv. Er worst case-scenariet for nettonutidsværdien negativt, bør dette ikke i sig selv føre til, at projektet stoppes, da sandsynligheden for worst case-scenariet antages at være lav. Men projektet bør kun iværksættes, såfremt det kan accepteres, at projektet potentielt set kan føre til et økonomisk tab som målt ved nettonutidsværdien. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [6]
Effektiviseringsprojekter evalueres efter, at der bør være en positiv business case. For kvalitetsløfts- og lovprojekter er der derimod ikke krav om positiv business case. Projektet skal i forhold til økonomien være opmærksom på risikopuljen, som udgøres af den beløbsmæssige forskel på de risikojusterede projektudgifter og de ikke risikojusterede projektudgifter. Denne forskel opgøres i business casen, men bør kommenteres tekstuelt i dette afsnit i PID. Som udgangspunkt bør en negativ risikopulje være genstand for stor opmærksomhed for projektet og for validiteten og robustheden af business case i særdeleshed. Endelig beskrives i afsnittet hvordan projektet påtænkes finansieret i projektets levetid (ekskl. drift) fx STS, gennem lovgivning, via egen ramme, direkte bevilling mv., samt om finansieringen er afklaret. 3.6 Gevinster Seniorbrugeren i projektets styregruppe er ansvarlig for at høste projektets gevinster. Det er derfor vigtigt at inddrage seniorbrugeren i beskrivelsen af gevinster. 3.6.1 Strategi for gevinstrealisering Her beskrives projektets strategi for gevinstrealisering, organisering af arbejdet i realiseringsfasen samt relationen til de i gevinstdiagrammet (produktbilag A) identificerede gevinster. Henvis til produktbilag A: Gevinstdiagram. Indsæt evt. figur af realiseringsfasens organisering. Gevinster til projektet er kvantificerbare og der kan opsættes målepunkter for realisering og høst. Findes der i projektet typer af fordele af projektet, som ikke kan måles, kan der gøres opmærksom på disse forhold i dette afsnit i PID en. Ikke-målbare fordele indgår ikke i business casen. Typiske spørgsmål, der bør besvares af en strategi for gevinstrealisering kan være: Er der risici, som kan forhindre gevinstrealiseringen og hvis ja, hvordan kan denne risiko reduceres? Hvilke interessenter har betydning for realiseringen, og hvordan klæder vi dem bedst muligt på til det? Hvordan udmøntes økonomiske gevinster (eksempelvis kan økonomiske gevinster reinvesteres i myndigheden, fx minutbesparelser, der ikke kan beskæres direkte i kontor-, eller myndighedsbevillinger, eller de kan beskæres i den årlige drift mhp. opsparing eller mindre bevilling på Finansloven)? Hvilke aktiviteter skal vi sikre os gennemføres i realiseringsfasen (hvor projektet jo er lukket, dvs. gevinstejeren eller seniorbrugeren skal tage ansvar for disse)? Skal der defineres særlige roller i realiseringsfasen for at understøtte gevinstrealiseringen hvis ja, hvordan skal disse roller spille sammen med gevinstejer og seniorbruger? Etc. 3.6.2 Effektiviseringsgevinster La en liste over de økonomiske gevinster fordelt på gevinstejer for projektet. Du finder oversigten over økonomiske gevinster i business casen, tabel 1.12. Detailbeskrivelse af gevinster findes i produktbilag B: Gevinstdetaljer. 3.6.3 Kvalitetsløftsgevinster Kvalitetsløftsgevinster opsplittes på to: Ikke-økonomiske gevinster og økonomiske gevinster for private og virksomheder. Dette gøres, da tiltag hos den offentlige sektor i mange tilfælde fører til gevinster for borgere og private virksomheder, men da dette ikke monetært bidrager direkte til det statslige budget medtages det ikke som økonomisk gevinst. Det anses dog stadig for et centralt bidrag, og kan i flere tilfælde være selve formålet med projektet. Alle typer gevinster bør derfor kvantificeres og opgøres, og der skal være fokus på at høste gevinsterne. 3.6.3.1 Ikke-økonomiske gevinster Lav en liste over de ikke-økonomiske gevinster fordelt på gevinstejer for projektet. Du finder oversigten over ikke-økonomiske gevinster i business casen, tabel 1.6. Detailbeskrivelse af gevinster findes i produktbilag B: Gevinstdetaljer. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [7]
3.6.3.2 Økonomiske gevinster for private og virksomheder Lav en liste over de økonomiske gevinster for private og virksomheder fordelt på gevinstejer for projektet. Du finder oversigten over økonomiske gevinster for private og virksomheder i business casen, tabel 1.21. Detailbeskrivelse af gevinster findes i produktbilag B: Gevinstdetaljer. 3.7 Teknisk løsning I dette afsnit skal forventninger til projektets tekniske løsning beskrives. Indsæt diagram eller tegning til illustration af den forventede løsning, data og integrationer. Det vil være oplagt at inddrage de fem principper for gode statslige it-projekter samt berøre nedenstående emner i forbindelse beskrivelses af projektets tekniske løsning: Teknologiens modenhed hvor velafprøvet er den ønskede teknologi i forhold til teknologiens anvendelsesområde? Genanvendelse af komponenter kan der med fordel genanvendes egne eller andre institutioners komponenter? Standardsystem er der foretaget afdækning af, om markedet kan levere et standardsystem ift. det ønskede anvendelsesområde Systemmoduler hvor stor er den tekniske kompleksitet i projektet mht. antallet af moduler i løsningen? Integrationer Hvor stor er den tekniske kompleksitet mht. antallet af integrationer til andre systemer? Konvertering og migrering - Hvor stor er den tekniske kompleksitet mht. konvertering og migrering? Sikkerhed Er der taget stilling til sikkerheden i forbindelse med udvikling og drift? Alle diagrammer skal udarbejdes ud fra BPMN notationen. I forbindelse med udarbejdelse af den overordnede arkitektur for den tekniske løsning anbefales det at orientere sig i vejledninger, specifikationer og skabeloner fra OIO EA. OIO EA er en dansk fællesoffentligt standard for processer og dokumentation af it-arkitekturen i relation til digitaliseringsprojekter. Følgende overvejelser bør indgå og beskrives ifbm. den tekniske løsning: Beskrivelse af hvilke applikationer der bruger hvilke forretningsobjekter / data (svarer til OIOEA: C2.2 Applikation-Information map) Overblik over hvilke applikationer der understøtter hvilke forretningsprocesser / handlinger (svarer til OIOEA: C2.4 Applikation-Proces map) Beskrivelse af integrationer mellem de centrale applikationer / komponenter (services), herunder særligt integrationer til andre interne og eksterne løsninger (svarer til OIOEA: C2.7 Applikation-Integrations views) Du kan læse mere om OIOEA anbefalinger vedr. applikationsarkitektur her. Det kan også være relevant at gennemføre en kvalitetssikring af arkitekturen ud fra OIOEA tjeklisten. Du kan læse mere om tjeklisten her. 3.8 Leverancer 3.8.1 Hovedleverancer I dette afsnit skal projektets hovedleverancer beskrives. Leverancerne kan være organisatoriske, tekniske, processuelle og er alle konkrete produkter, som projektet har leveret ved afslutning af projektet. Udover leverancerne i sig selv, er det interessant hvem der leverer dem (projektet selv eller fx andre institutioner), deres indbyrdes afhængigheder, deres kritikalitet for projektet mv. Tabellen er en hjælp til at få listet leverancerne, så der skabes overblik. Såfremt et ganttdiagram eller andet visuelt vil kunne levere de samme oplysninger, må dette gerne indsættes. Nedenfor er givet et eksempel på, hvordan tabellen kan udfyldes. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [8]
Projektets mål Beskrivelse Succeskriterier Tekniske leverancer Systemanskaffelse Miljøer Test Dokumentation Procedurer for vedligehold, drift og forvaltning Organisatoriske leverancer Skitse over den fremtidige organisation/arbejdsdeling mellem it-afdelingen og forretningen. Plan for uddannelse af nøglemedarbejdere Processuelle leverancer Projektinitieringsdokument med tilhørende underbilag Udbudsmateriale med tilhørende kravspecifikation Kontrakt (anskaffelsen) To virtuelle miljøer til brug ved fremtidig opgradering og test, samt et produktionsmiljø i samme setup. Hvert miljø samt produktion kan efter behov etableres med flere instanser. Der gennemføres en række test af løsningen, herunder Proof of Concept (POC), der bl.a. består af testene: Installationsprøve Funktionstest Performancetest IT sikkerhedstest Overtagelsesprøve Projektet leverer dokumentation for design, installation og drift af komponenterne. Godkendes ved overtagelsesprøve. Projektet leverer procedurer og vejledninger for anvendelse af systemet i drift, vedligehold og udvikling. Skitse over den fremtidige organisation for drift og forvaltning i IT i forhold til forretningen. Herunder udarbejdes oversigt over kompetencer, der bør være til stede i organisationen. Oversigten udarbejdes på grundlag af leverandørens anbefalinger. Projektet leverer en plan for uddannelse af nøglemedarbejdere i IT drift og forretning. Udarbejdes i henhold til Ministeriets projektmodel samt den fællesstatslige itprojektmodel. Udbuddet gennemføres som et SKI miniudbud. Udbudsmaterialet udarbejdes med udgangspunkt i SKI 02.06. rammeaftale. Kontrakten indgås på grundlag af gennemført SKI mini-udbud og udarbejdes i samarbejde med juridisk afdeling. Gennemførelsesfasen dd.mm.201x - dd.mm.201x Gennemførelsesfasen dd.mm.201x - dd.mm.201x dd.mm.201x dd.mm.201x dd.mm.201x dd.mm.201x dd.mm.201x Gennemførelsesfasen dd.mm.201x - dd.mm.201x Gennemførelsesfasen/realiseringsfasen dd.mm.201x - dd.mm.201x Gennemførelsesfasen dd.mm.201x - dd.mm.201x Gennemførelsesfasen dd.mm.201x - dd.mm.201x Løbende i hele projektperioden Anskaffelsesfasen dd.mm.201x - dd.mm.201x Anskaffelsesfasen dd.mm.201x - dd.mm.201x 3.8.2 Kriterier for overdragelse af leverancer fra projekt til forretning Her opstilles konkrete kriterier, som projektet skal overholde, før leverancerne kan overtages af forretningen, og den primære del af gevinstrealiseringen påbegyndes. Der påføres i ske- Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [9]
maet ansvarlige modtagere samt ansvarlig for overdragelsesprocessen. Der kan være tale om kvalitative eller kvantitative krav, fx at en række tests er bestået, eller at krav til teknisk idriftsættelse er indfriet. 3.9 Organisering I dette afsnit skal der redegøres for den projektorganisering, som opsættes rundt om projektet. En projektorganisation er karakteriseret ved, at den er et supplement til den klassiske organisation, dvs. basisorganisationen, der tager sig af de mere rutineprægede opgaver i virksomheden. Projektorganiseringen eksisterer således parallelt med linjeledelsen i myndigheden. Projektorganisationen oprettes i forbindelse med projektet - en bestemt opgave - og nedlægges, når opgaven er afsluttet. Det kan fx være ved udvikling af et nyt produkt, planlægning af et nyt it-system, mv. Ved etablering af en projektorganisation tilføres virksomheden fleksibilitet og evnen til hurtig, informeret handling, ved netop at være organiseret og etableret med et stærkt og entydigt fokus (projektets succesfulde udførelse) for øje. Basiselementerne i projektorganisationen består af en styregruppe og en projektgruppe. Styregruppen tager sig af de overordnede ledelsesmæssige opgaver i forbindelse med projektet og rekrutterer sine medarbejder fra den øverste del af basisorganisationen. Projektgruppen står for den udførende del af projektet og rekrutterer sine medarbejdere fra basisorganisationens øvrige medarbejderstab. Sammensætningen af projektorganisationen baseres på at basiselementerne og basis roller besættes. Det skal her bemærkes, at en rolle ikke nødvendigvis er lig en person. En person kan bestride flere roller i et projekt. Det anbefales, at orientere sig i og følge organiseringen i vejledning om den fællesstatslige it-projektmodel og i vejledning til sammensætning af projektorganisationen (beskrivelse af roller og ansvar). 3.9.1 Projektorganisation Her skal selve projektorganisationen illustreres. Det gøres typisk ved hjælp af et organigram. Eksempel: Ledelsesniveau Styregruppe Styringsniveau Projektleder Udførende niveau Projektgruppe It specialist Forretningsspecialist... Leverandør team Teknisk projektleder Udvikler 1... 3.9.2 Styregruppe Beskriv sammensætningen af styregruppen, herunder formand/projektejer, seniorbruger(e) og seniorleverandør(er). Såfremt de tre standardroller i tabellen ikke udfyldes i styregruppen skrives begrundelse herfor i afsnittet. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [10]
3.9.3 Projektleder og projektgruppe Her listes projektlederens navn, certificeringer og kompetencer i relation til projektet. CV kan vedlægges. List ligeledes kort projektdeltagerne. Angiv for alle roller / deltagere ressourcebookningen til projektet. 3.9.4 Øvrige roller og bemanding Angiv eventuelle andre roller eller grupper i projektet (f.eks. arbejdsgruppe, referencegruppe, følgegruppe mv.). Rollerne kan evt. vælges ud fra vejledningen sammensætning af projektorganisationen. 3.9.5 Driftsansvarlige Opgør de ansvarlige ift. den efterfølgende drift af projektet. Som minimum angives ansvarlig til overtagelse fra forretningen systemejer, og medmindre at systemet driftes eksternt angives også teknisk ansvarlig fra driften platformsejer. Overvej også om procesejere skal listes. For yderligere information om disse roller se vejledningen sammensætning af projektorganisationen. 3.10 Tilrettelæggelse og tidsplan 3.10.1 Strategier for projektets tilrettelæggelse Beskriv hvor relevant for projektet følgende områder: Udbudsstrategi - beskriv den overordnede udbudsstrategi og kontraktstrategi i projektet, tilgangen til det, og hvordan den sikres udmøntet. Se evt. værktøjet udbudsstrategi. Udviklingsstrategi - beskriv den overordnede udviklingsstrategi og hvilket udviklingsmetodeværktøj der anvendes i projektet. Beskriv hvordan projektet sikres udmøntet, anvendes der fx vandfaldmodel, agile udviklingsmetoder, etc. Implementeringsstrategi og overdragelse til forretningen - beskriv den overordnede udrulnings- og implementeringsstrategi i projektet, og hvordan den sikres udmøntet. Herunder, hvilke organisatoriske forandringer løsningen forudsætter, hvordan disse sikres gennemført og hvordan der følges op på implementeringen. Strategi for overdragelse af system - den overordnede strategi for overdragelse til drift (selve it-systemet og driftskontrakten) og hvordan den sikres udmøntet. Henvis evt. til særskilte dokumenter for yderligere detaljer. 3.10.2 Tidsplan Kort beskrivelse af de overvejelser der har været gjort i forbindelse med udarbejdelsen af tidsplanen. Er der forhold i tidsplanen, der gør, at nogle milepæle er faste, er idriftsættelse af løsningen bestemt af andre faktorer fx lovgivning, er der elementer, der tidligst kan påbegyndes på et udefra styret tidspunkt, eller faktorer der på anden vis er uden for projektets beslutningskompetence og som har afgørende indflydelse på tidsplanen. Overvej opdelingen i faser samt underopdeling af hovedfaser ledelsesfaser. Såfremt en hovedfase løber over 3-6 måneder eller oppebærer væsentlige udgifter, bør det overvejes at opdele i ledelsesfaser. Begrund opdeling i hovedfaser og ledelsesfaser i projektet. Hovedfasen gennemførsel vil oftest med fordel kunne opdeles i flere ledelsesfaser. Selve tidsplanen kan beskrives i den i skabelonen udarbejdede tabel, i et Gantt skema eller gennem anden grafisk illustration af tidsforløbet, hvor projektfaserne samt realisering gennemløbes. 3.11 Afhængigheder Opsummer kort projektets væsentligste interne og eksterne afhængigheder fx til andre itsystemer, processer, projekter mv. Afhængigheder kan også være i forhold til forvaltningsgrundlag, fx juridiske og forvaltningsmæssige afhængigheder til fx arkivloven eller persondataloven. Anfør også her hvis projektet er et projekt i et program, og overvej om PID en skal udvides med et separat afsnit, der i flere detaljer beskriver programmet. Hvis projektet er en del af Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [11]
et program, der møder betingelserne fra IT-projektrådet for risikovurdering af programmer gøres ligeledes opmærksom herpå og henvises til separate programdokumenter. 3.12 Kvalitet Alle interessenter i et it-projekt har krav og forventninger til resultatet. De har forventninger om, at specifikke behov opfyldes, og de har forventninger til, at projektets produkter har en bestemt kvalitet. Derfor er det en god idé at planlægge og følge op på, om disse krav og forventninger opfyldes hele vejen igennem projektforløbet. Der er forskellige former for kvalitet, som skal adresseres i et projekt: Produktkvalitet Proceskvalitet Graden af behovsopfyldelse Produktkvalitet omhandler projektets resultat, fx om et system lever op til kravene i kravspecifikationen, både funktionelle og ikke-funktionelle krav og ikke er fejlbehæftet. Proceskvalitet handler om, hvorvidt de metoder og værktøjer, som anvendes i projektet, har den rette kvalitet og bidrager til projektets formål. Graden af behovsopfyldelse omfatter opfyldelse af interessenternes behov i relation til projektet dvs. om de oplever, at de produkter, de får stillet til rådighed, faktisk også lever op til deres behov. Der bør naturligvis være sammenfald mellem produktkvalitet og graden af behovsopfyldelse, men det er ikke altid tilfældet. Graden af behovsopfyldelse afhænger også af den måde, produktet er blevet implementeret og idriftsat på. Fx om it-supporterne kan vejlede i brug af et system efter ibrugtagning eller om brugernes arbejdsprocesser er effektive i samspil med et nyt system. Formålet med kvalitetsafsnittet er at fastlægge processer for: Kvalitetsplanlægning hvad er vores kvalitetskrav, hvad vil vi tjekke og hvornår? Kvalitetskontrol - måling, registrering og vurdering af kvaliteten. Kvalitetssikring - følges kvalitetsplaner og udføres kontroller. At beskrive kvalitetskrav, processer og kvalitetssikring kan være en omfangsrig opgave. Overvej om afsnittet skal udskilles i en separat kvalitetsplan, der vedlægges PID en som produktbilag. 3.12.1 Kvalitetsplanlægning Her beskrives hvad der skal kontrolleres i projektet, kvalitetsaktiviteterne til gennemførsel af denne kontrol og en plan for hvornår kontrollen skal finde sted. Kvalitetskrav er ofte dokumenteret i form af en kravspecifikation med funktionelle og ikke-funktionelle krav og krav til it-standarder, hvis der er tale om en systemimplementering, eller i form af krav til itprocesser, fx testplaner, driftsplaner eller planer for konfiguration af it-miljøer. 3.12.2 Kvalitetskontrol Her beskrives processer for, hvordan man i projektet vil måle, registrere og vurdere kvaliteten. Typisk beskrives hvilke standarder, skabeloner, kvalitetsmetode og metrikker, der følges. Mange organisationer har dette defineret for organisationen som hele, hvorved der kan henvises til generelle standarder og skabeloner. 3.12.3 Kvalitetssikring Beskriv hvordan man i projektet sikrer, at kvalitetsplanlægning følges og kontroller udføres altså tjek af, om kvalitetskontrol udføres. Beskriv, hvilket ansvar styregruppen har for kvalitetssikring og beskriv, hvilke eksterne organer, som projektet vil blive kvalitetssikret af. Eksterne organer kan f.eks. være Statens IT-projektråd eller ekstern revision. 3.13 Risici Risikostyring er beskrevet i detaljer i vejledningen om risikostyring, som anbefales læst forud for fastlægningen af risikostyringen i projektet. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [12]
Risici er en mulig hændelse eller række af hændelser, der - hvis den/de opstår, vil have indvirkning på opfyldelse af målene i programmet eller i projektet. En hændelse kan være en trussel, som kan have en negativ indvirkning på programmets eller på projektets mål, eller en mulighed, som har en gunstig indvirkning på programmets eller projektets mål. En risiko angives som en kombination af sandsynligheden for at hændelsen indtræder, og omfanget af dens indvirkning på målet (konsekvens). Til at styre risici anvendes risikostyring, som er en ramme for forvaltning af risici på tværs af alle dele af en organisation. Den indeholder alle de aktiviteter, der kræves for at identificere og kontrollere eksponeringen for enhver form for risiko, positiv eller negativ, som kan have en indvirkning på opnåelsen af organisationens forretningsmæssige mål. Til at understøtte risikostyringen er der udarbejdet et værktøj risikoregisteret. Risikoregisteret findes som produktbilag til PID skabelonen, produktbilag C. I dette afsnit i PID en beskrives de overvejelser der er gjort omkring projektets risikoprofil og den risikostyring der vil blive anvendt i projektet herunder hvordan og hvor ofte der følges op på risici også for de risici der ligger efter projektet er idriftsat. Tag stilling til hvor risikovillig man ønsker at være i projektet. Inddrag så vidt muligt primære interessenter i risikoanalysen. 3.14 Interessenter En central del af god projektledelse er styring af projektets interessenter. Interessenter er personer eller grupper i et projekts omverden og defineres ved, at de har mulighed for at påvirke og/eller påvirkes af projektets udførelse. Den korrekte identifikation og håndtering af interessenter kan derfor være kritisk for projektets succes. PID ens afsnit om interessenter redegør for de væsentligste interessenter til projektet, deres relation til projektet, samt om der skal iværksættes særlige tiltag for at håndtere disse interessenter. I forhold til identifikation og håndtering af interessenter findes inspiration til den bagvedliggende analyse i værktøjet interessenthåndtering. Afsnittet om interessenter i PID en kan, især for større projekter, blive omfangsrigt når der skal redegøres for alle væsentlige interessenter. Det kan derfor overvejes at udskille afsnittet i en separat interessentanalyse. Interessentanalysen kan vedlægges PID en som produktbilag. 3.15 Kommunikation Kommunikation og dialog er et væsentlige redskaber til håndtering af interessenter i itprojekter. Er der udarbejdet en overordnet strategi for kommunikationsindsatsen bør afsnittet være en konkretisering af strategien, det kunne fx styrelsens overordnede kommunikationsstrategi. Kommunikationsindsatsen i projektet sikrer ideelt set at: alle projektdeltagerne har en fælles opfattelse af projektets art, scope og planlagte gevinster der er en generel opmærksomhed om resultater og de planlagte gevinster de direkte interessenter er løbende informeret om projektets fremdrift dvs. både før, under og efter implementeringen af selve løsningen projektets nøglebudskaber bliver formidlet projektet går i dialog, inddrager de direkte interessenter og opmuntrer dem til at komme med feedback der er tilslutning fra interessenter med direkte indflydelse projektet signalerer, at det har en vilje til at imødekomme sponsorens forventninger Afsnittet om kommunikation i PID en kan, især for større projekter, blive omfangsrigt når der skal redegøres for alle budskaber og kommunikationsindsatser. Det kan derfor overvejes at udskille afsnittet i en separat kommunikationsplan. Kommunikationsplanen kan vedlægges PID en som produktbilag Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [13]
3.15.1 Hovedbudskaber Redegør for de væsentligste budskaber i projektet. Korriger skemaet hvis der er andre områder med central interesse for projektet. 3.15.2 Formidling af budskaber til interessenter/målgrupper I dette afsnit konkretiseres kommunikationen på budskaber i forhold til de i forrige afsnit identificerede interessenter. Det er vigtigt, at der for hver indsats tilknyttes milepæle og ansvarlig for udførelsen samt at der tænkes tiltag til opfølgning på kommunikationsindsatsen. 3.16 Tolerancer Projekttolerancer angiver projektlederens råderum i forhold til styregruppen. Tolerancer kan typisk defineres i forhold til tid for gennemførelse af projektet, i forhold til budget for projektet samt i forhold til scope for projektet. Anvendelse af tolerancer giver projektlederen mulighed for hurtigt at kunne agere i forhold til pludseligt opståede udfordringer i projektet eller dets omverden. Især i forhold til projekter, der køres efter agil udviklingsmetode er definitionen af tolerancer central. Overskrides tolerancerne eller forventes de overskredet skal afvigelserne eller ændringerne forelægges og godkendes af styregruppen i form af en afvigelsesanmodning. Defineres der ikke tolerancer for projektet skal alle afvigelser og ændringer, uanset størrelse og omfang, forelægges styregruppen. 3.17 Rapporteringskrav Her listes de forskellige rapporteringskrav, som projektet skal opfylde. Det kan fx være interne krav i forhold til styregruppe, i forhold til ledelsesrapportering eller lignende. Også eksterne krav, som eksempelvis statusrapportering til Statens IT-projektråd opgøres. 3.18 Revisionshistorik Opgør i tabellen, når PID dokumentet ændres. 3.19 Bilag Findes der produktbilag udover de listede produktbilag A, B og C opgøres en liste her. Det kan eksempelvis være valgt at udskille kvalitetsovervejelser i en kvalitetsplan. Kvalitetsplanen skal således listes her som bilag og vedlægges PID. 3.20 Produktbilag A: Gevinstdiagram Et gevinstdiagram illustrerer grafisk sammenhængene mellem projektets formål, gevinster, resultater og de tiltag leverancer og den organisatoriske implementering heraf, der skal til for at opnå gevinsterne. Ud over at give dette overblik over projektets interne afhængigheder for at opnå de ønskede gevinster, kan gevinstdiagrammet kan også bruges som input til forudsætningsdiagrammet til business casen forudsætningsdiagrammet kan betragtes som udgiftssiden af gevinstdiagrammets sammenhænge. Udarbejdelse af et gevinstdiagram kan være en kompleks øvelse især første gang. Et godt udgangspunkt er i projektet samt med styregruppe og væsentlige interessenter at blive enige projektets formål, hvis dette ikke allerede er helt klare i projektgrundlaget. Projektets formål beskriver, hvad projektet skal levere på højeste niveau inden for rammerne af myndighedens strategiske mål. Herefter identificeres gevinster både dem, der gavner projektet og dem, der måske opstår utilsigtet og som kan have en negativ effekt på projektets nytte. I projektgrundlaget er allerede identificeret nogle gevinster. Gevinster findes ved at spørge hvorfor iværksætter vi dette projekt? Hvad får vi ud af det?. Det kan i gevinstdiagrammet være nyttigt at illustrere, om der er relationer mellem gevinster dette kan gøres ved at placere dem nær hinanden / Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [14]
samle dem i grupper. Ligeledes kan en gevinst føre til en anden. Dette skal også fremgå af gevinstdiagrammet. De identificerede gevinster skal herefter knyttes til projektets resultater hvilket defineret resultat fører til hvilke gevinster. Dette bidrager også til en prioritering af projektets resultater de endelige resultater, der leder til de gevinster der enten politisk prioriteres højest eller fx økonomisk bidrager mest til myndigheden, bør have fokus i projektet. Det næste skridt i processen er at identificere den forandringsevne og den organisatoriske implementering af denne, som det er nødvendigt at projektet bibringer myndigheden for, at de ønskede resultater kan opnås. Forandringsevner er ændringer i de nuværende arbejdsmetoder, der skal gennemføres i de forretningsområder, der er berørt af projektet. De kan indeholde, proces- og adfærdsændringer samt ændringer til operationelle procedurer. For eksempel vil en ny klar it-sikkerhedspolitik til støtte for myndigheden kun levere de ønskede gevinster, hvis personalet ændrer deres vaner. Endelig skal forandringsevnen kobles til projektets leverancer. Med dette sidste trin viser diagrammet en klar sammenhæng mellem de konkrete leverancer, som projektet skal levere, i forhold til de ønskede gevinster og formålet for projektet. Det skal bemærkes, at diagrammet ikke kan oplyse, hvornår tingene sker i tiden, dvs. sekvens. Det er simpelthen en fremstilling af, hvordan tingene er forbundet til hinanden. Når gevinstdiagrammet er færdigt, indsættes dette i nærværende afsnit med oversigt over sammenhænge mellem leverancer, resultater og projektets gevinster. Gevinster kan, som tidligere nævnt, være positive og negative, og begge skal medtages i diagrammet. Organisatorisk forankring Leverancer Forandringsevne Resultater Gevinster Formål 3.21 Produktbilag B: Gevinstdetaljer Udarbejdelse af tabeller med gevinstdetaljer for hver enkelt gevinst i projektet er nøglen til en god realisering af gevinster. Gevinstdetaljer specificerer ejeren og den ansvarlige for opfølgningen og sikringen af gevinsten, og hjælper projektleder til at styre og overvåge leveringen af gevinster. Gevinster opdeles i to typer effektiviseringsgevinster og kvalitetsløftgevinster. Effektiviseringsgevinster er økonomiske gevinster, der kan have en direkte effekt på en myndigheds budget, hvis de høstes. Ved effektiviseringsgevinster forstås således alene økonomiske gevinster, som kan indbudgetteres og henføres til en specifik, offentlig konto. Gevinsterne kan, når de høstes, enten blive i den pågældende myndighed og give mulighed for, at myndigheden kan løfte andre opgaver, eller tages ud af den enkelte myndighed og bruges til tværgående prioriteringer. Det er et spørgsmål om gevinstrealiseringsstrategien og planlægningen af høsten af de pågældende gevinster. Effektiviseringsgevinster opgøres alene på gevinstid samt på gevinstejer. Kvalitetsløftsgevinster er gevinster, der enten forbedrer ikke-økonomiske parametre, såsom tilfredshed, eller som trods, at de er økonomiske, ikke har en direkte effekt på en myndigheds budget, såsom økonomiske gevinster for erhvervslivet eller borgere. For kvalitetsløftsgevinster skal angives om der er tale om primære eller sekundære gevinster da den økonomiske vinding for myndigheden som ved effektiviseringsgevinster ikke kan bruges til at prioritere fokus for gevinsthøsten. Kvalitetsløftgevinster opgøres både på gevinstid, navn og gevinstejer. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [15]
For alle typer gevinster gælder, at gevinstdetaljer består af to tabeller, der skal udfyldes for hver gevinst. Tabellerne specificerer den enkelte gevinst samt de fremtidige målinger, der skal sikre at gevinsten opnås. Målingerne opdeles i fire typer: - Før-måling: Dette er baseline for gevinsten og den måling, der udgør basis i førsituationen i business casen for opgørelse af bruttogevinsten. Målingen laves ved udarbejdelse af business casen i analysefasen. - Opdateret før-måling: Et projekt kan være undervejs i op til flere år. For at sikre et direkte sammenligneligt grundlag på effekten af implementering af et it-system på fx en given arbejdsproces, foretages der en opdateret før-måling umiddelbart før systemet idriftsættes. Denne måling bruges til opgørelse af nettogevinsten. - Midtvejsmåling(er): Foretages undervejs i realiseringsfasen. Der kan foretages flere målinger. Formålet er at følge gevinstrealiseringen undervejs i realiseringsfasen for at sikre, at der er sandsynlighed for at den samlede forventede gevinst realiseres. Afviger målingerne bør der foretages korrigerende handlinger hvis muligt, eller justeres i forventningen til gevinstrealiseringen i realiseringsfasen. - Slutmåling: Foretages ved slutdato for høst og opgør den samlede gevinstrealisering for pågældende gevinst. Udgangspunktet for udfyldelsen er PID en afsnit 6, der laves på basis af effektiviseringsgevinster i business casens tabel 1.12, ikke-økonomiske kvalitetsløftsgevinster opgjort i business casens tabel 1.6 samt kvalitetsløftsgevinster relateret til økonomiske fordele for private og virksomheder, opgjort i business casens tabel 1.21. Nedenstående er givet et eksempel på udfyldelse af gevinstdetaljer for en effektiviseringsgevinst. Eksempel: Stamdata [Gevinst 3] Gevinstejer: Anders Andersen (AA), Økonomichef Forventet 0-scenarie: 110 mio. kr. Økonomiområdet (ØKO) Startdato høst: 1.1.2014 Forventet 1-scenarie: 90 mio. kr. Slutdato høst: 31.12.2018 Forventet gevinst: + 20 mio. kr. Væsentligste interessenter: Væsentligste risici: Evt. selvstændige aktiviteter planlagt i realiseringsfasen Direktionen (direktør YX): XY har en stærk interesse i gevinsten fordi XY har mulighed for at påvirke gevinststørrelsen og gevinsthøsten gennem Markedstingsafdelingen (Kurt, Preben og Bente): Marketing er centrale for at høste gevinsten da Risiko1, risiko5, risiko11. Bemærk især at risiko 11 er kritisk ift. at høste gevinsten. Indtræffer denne hændelse skal der iværksættes følgende foranstaltninger for at kunne høste gevinsten: Følgende aktiviteter i realiseringsfasen relaterer sig til høst af gevinst 3: - sikre nedsættelse af arbejdsgruppe mellem ZQ myndighed og XY styrelse - sikre supportorganisation efterfølgende til systemet -. Følgende milepæle defineres: Milepæl 1: XX, dato 1.1.2015 Milepæl 2:. Det er nødvendigt, at der til realisering af gevinsten etableres en midlertidig supportorganisation med 2 ÅV til øget understøttelse af implementeringen. Der er givet tilsagn om ressourcer fra QW afdelingsleder. ZY er ansvarlig for at iværksætte og implementere organisationen fra 1.1.14 til 1.1.15. Målinger [gevinstid] Målemetode Dato for måling Ansvarlig Måleresultat 1-scenarie Afvigelse Før-måling Besparelse i antal ÅV 1.1.2013 AA 100 mio. kr. 90 mio. kr. 10 mio. kr. Opdateret førmåling 20.12.2013 AA Besparelse i antal ÅV Besparelse i antal ÅV 6.6.2014 AA 6.12.2014 Midtvejsmåling 6.6.2015 6.6.2016 6.6.2017 6.6.2018 Slutmåling Besparelse i antal ÅV 6.12.2018 AA Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [16]
3.22 Produktbilag C: Risikoregister Produktbilag C er risikoregisteret for projektet, der er indlejret i PID dokumentet som en Excel fil. Dobbeltklikkes på ikonet åbnes filen i Excel og er klar til indtastning. Efterfølgende skema gennemgår alle de kolonner i risikoregisteret, som der skal indtastes i. Der henvises ydermere til vejledning om risikostyring. Proces Felt Beskrivelse Stamdata Risiko-id Programbølge-id (for programmer) (tryk på + over kolonne F) Projekt-id (for programmer) (tryk på + over kolonne F) Programniveau Berørte projekter (for programmer) (tryk på + over kolonne F) Dato Projektets eller programmets stamdata til brug for intern styring. Det er væsentligt, at den nuværende fase holdes opdateret for projekter, og tilsvarende opdatering af den nuværende fase og programbølge i programmer. Fortløbende nummerering af risici af hensyn til identifikation. Angiv hvilken bølge i programmet risikoen befinder sig i. Angiv hvilket projekt risikoen befinder sig i. Angiv om risiko ligger på programniveau, dvs. er tværgående over flere projekter. Vælg mellem ja/nej. Angiv hvilke andre projekter der berøres, dvs. påvirkes, af risikoen. Dato for registrering eller opdatering af risiko. Forfatter Risikoårsag Angiv initialer på forfatter til tilføjelsen/opdateringen af risikoen. Kort og præcis beskrivelse af årsagen til den pågældende risiko, dvs. den begivenhed eller situation, som er kilden til risikoen. Risikobeskrivelse (identificering) Risikohændelse Risikoeffekt Risikotype Seneste status for risiko (kun relevant ved opdateringer af risici) (tryk på + over kolonne P) Sandsynlighed Højeste konsekvensscore Kort og præcis beskrivelse af den pågældende risiko, som hændelsen. Kort og præcis beskrivelse af den pågældende risikos effekt. Vælg fra listen hvilken risikogruppe risikoen tilhører: Forretningsmæssige forhold Projektets / programmets tilrettelæggelse Markedsafklaring og teknisk løsning Interessenter Slutbrugere og slutprodukt Vælg fra listen et tal fra 1-5 sandsynligheden for at risikoen indtræffer: 1. 0-20 % 2. 20-40 % 3. 40-60 % 4. 60-80 % 5. 80-100 % Vælg fra listen en værdi fra 1-5 for de negative Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [17]
konsekvenser hvis risikoen indtræffer: 1. - Ubetydelige konsekvenser 2. - Mindre konsekvenser 3. - Betydelige konsekvenser 4. - Store konsekvenser 5. - Meget store konsekvenser Såfremt konsekvensen vil være positiv for projektet/programmet, vælg en værdi mellem -1 og 5: -1 - Ubetydelige, positive konsekvenser -2 - Mindre, positive konsekvenser -3 - Betydelige, positive konsekvenser -4 - Store, positive konsekvenser -5 - Meget store, positive konsekvenser Nuværende status for risiko (vurdering) Risikoværdi Beskrivelse af tiltag Status for hændelse Sandsynlighed Konsekvenser for økonomi, tid, kvalitet og gevinster Højeste konsekvensscore Risikoværdi Udregnes automatisk som sandsynlighed x konsekvens. Beskriv meget kort tiltag til håndtering af risiko før seneste opdatering. Vælg status for hændelse. Er der stadig en risiko for at hændelsen indtræffer (risiko), er den ikke længere mulig (indtraf ikke), eller er den indtruffet (indtraf)?: - Risiko - Indtraf ikke - Indtraf Vælg fra listen et tal fra 1-5 sandsynligheden for at risikoen indtræffer: 1. 0-20 % 2. 20-40 % 3. 40-60 % 4. 60-80 % 5. 80-100 % Vælg fra listen en værdi fra 1-5 for de negative konsekvenser hvis risikoen indtræffer: 1. - Ubetydelige konsekvenser 2. - Mindre konsekvenser 3. - Betydelige konsekvenser 4. - Store konsekvenser 5. - Meget store konsekvenser Såfremt konsekvensen vil være positiv for projektet/programmet, vælg en værdi mellem -1 og 5: -1 - Ubetydelige, positive konsekvenser -2 - Mindre, positive konsekvenser -3 - Betydelige, positive konsekvenser -4 - Store, positive konsekvenser -5 - Meget store, positive konsekvenser Udregnes automatisk som den højeste konsekvensscore. Udregnes automatisk som sandsynlighed x konsekvens. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [18]