Vejledning til projektinitieringsdokumentet (PID)

Vejledning til projektinitieringsdokumentet (PID) Marts 2016

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 SCOPE OG AFGRÆNSNINGER... 5 3.4 MÅL OG SUCCESKRITERIER... 5 3.5 ØKONOMISKE HOVEDTAL OG FINANSIERING... 6 3.6 GEVINSTER... 6 3.7 TEKNISK LØSNING... 7 3.8 LEVERANCER... 8 3.9 ORGANISERING... 8 3.10 TILRETTELÆGGELSE OG TIDSPLAN... 10 3.11 KVALITET... 10 3.12 RISICI... 11 3.13 INFORMATIONSSIKKERHED... 12 3.14 INTERESSENTER... 14 3.15 KOMMUNIKATION... 15 3.16 TOLERANCER... 15 3.17 RAPPORTERINGSKRAV... 16 3.18 REVISIONSHISTORIK... 16 3.19 BILAG... 16 3.20 PRODUKTBILAG A: GEVINSTDIAGRAM... 16 3.21 PRODUKTBILAG B: GEVINSTDETALJER... 16 3.22 PRODUKTBILAG C: RISIKOREGISTER... 19

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 It-projektrådet. 1.2.2 Formålet med at udarbejde en PID PID en har to primære formål: 1. Den skal sikre, at projektet har et stabilt grundlag, før styregruppen forpligter sig til projektet, herunder afholdelse af væsentlige udgifter. 2. Den 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 beslutninger i forhold til de godkendte rammer. 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 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 It-projektrådet. Du kan læse mere om den fællesstatslige it-projektmodel i vejledning om den fællesstatslige itprojektmodel. It-projektmodellen opdateres årligt 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 overordnet projektmodel, beregnet for anvendelse på alle statslige it-projekter. Modellen omfatter: 1. En model for faseopdeling af projektforløbet 2. Principper for overgang fra en fase til næste fase 3. Et antal ledelsesprodukter og skabeloner hertil (også kaldet produkter) 4. 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å Digitaliseringsstyrelsens hjemmeside. 2.1 Anvendelse af PID en i projektforløb It-projektmodellen er en fasemodel, der støtter styringen af projektet hen imod projektets samlede leverancer. 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 (PLD) Projektafslutningsrapport Gevinstrealiseringsrapport Business case It-projektmodellen indeholder fem hovedfaser: 1. Idéfase: Ideen kvalificeres og udmøntes i et projektgrundlag. 2. Analysefase: Projektet defineres og beskrives i PID en med tilhørende business case og evt. risikotjekliste til It-projektrådet. 3. Anskaffelsesfase: Specificering af krav og behov samt gennemførelse af anskaffelsesproces typisk via udbud. 4. Gennemførelsesfase: Kontrakter underskrives, og projektets leverancer realiseres. Fasen løber frem til systemet er idriftsat og implementeret organisatorisk. 5. 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å Digitaliseringsstyrelsens hjemmeside, er udarbejdet på basis af best practice i staten samt principper fra PRINCE2. PID en består af 19 hovedafsnit hertil 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 afsnit i PID en, blot skal der i forhold til en risikovurdering hos It-projektrådet indføjes en begrundelser under afsnittet ud fra følg eller forklar princippet. 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 som værende effektivisering, kvalitetsløft eller lov. 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. Der skal udarbejdes procesdiagrammer over nuværende arbejdsprocesser, der påvirkes af løsningen. Anvend gerne BPMN notation (http://www.bpmn.org/). 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 og bidrag til strategiske mål 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. Det skal beskrives, hvordan projektets gennemførelse understøtter myndighedens strategiske mål, mission og vision. 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 Den fremtidige situation efter indførelse af løsningen Beskriv situationen efter løsningen er implementeret. Brug procesdiagrammer til at vise de fremtidige arbejdsgange. Beskrivelsen udgør baggrunden for 1-scenariet i business casen. Det er også i dette afsnit, at slutproduktet skal beskrives hvad vil projektet reelt resultere i, set fra slutbrugernes perspektiv. Brug gerne mock-ups, wire frames eller lignende. Endelig skal afsnittet også indeholde en kort beskrivelse af slutbrugerne. 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.4 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.5 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 Scope og afgrænsninger Under dette afsnit beskrives projektets scope overordnet hvad er in scope, og hvad er out of scope. Der er især fokus på afgræsninger til projektet, der ellers naturligt kunne opfattes som del af projektet. For hver begrænsning 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 projektets output, dvs. de leverancer som projektet skal levere. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [5]

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 Pr. XX dato (efter idriftsættelse og nedluk af gammelt system), skal driftsudgifter max være 70 pct. af XX år niveau. Optimering af arbejdsgange Arbejdsprocesser i Dokumentationskontoret effektiviseres som følge af det nye system. Arbejdsproces XX kan udføres på 10 minutter efter uddannelse af brugere og idriftsættelse af nyt system. Dokumentkontores kan varetage eksisterende arbejdsopgaver med XX ÅV mindre end nuværende niveau ½ år efter idriftsættelse. Moderne infrastruktur Levering af en standard platform for ESDH, der understøtter senere digitaliserings- og effektiviseringstiltag Ved idriftsættelse skal 70 pct. af alle integrationer bygge på XY standard. Der skal være etableret 2 standard integrationer til systemet pr. XX dato, som følge af andre projekter, der bygger videre på platformen. 3.5 Økonomiske hovedtal og finansiering I dette afsnit indsættes nøgletal fra ledelsesresumeet i business casen. Såfremt statens business case-model version 3.0 eller derover benyttes, kan blot henvises til ledelsesresumeet i business case-modellen. 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 nettonutidsværdien 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. Effektiviseringsprojekter evalueres efter, at der skal 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 skal kommenteres tekstuelt i dette afsnit i PID. Endelig beskrives i afsnittet hvordan projektet anvises finansiering 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. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [6]

Gevinster til projektet er kvantificerbare og der kan opsættes målepunkter for realisering og høst. Findes der 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 som gevinster. Typiske spørgsmål, der bør besvares af en strategi for gevinstrealisering kan være: 1. Er der risici, som kan forhindre gevinstrealiseringen og hvis ja, hvordan kan denne risiko reduceres? 2. Hvilke interessenter har betydning for realiseringen, og hvordan klæder vi dem bedst muligt på til det? 3. Hvordan høstes produktivitetsgevinsterne (anvendes de eksempelvis til en forøgelse af antallet af behandlede sager, større kvalitet i sagsbehandling, allokering af ressourcer til andre typer af opgaver, tilføjelse af nye opgaver etc. )? 4. Hvad er overvejelserne om de samfundsøkonomiske gevinster? Hvordan kan vi bedst muligt understøtte at de høstes hos borgere og virksomheder? F.eks. informationskampagner etc. 5. Hvilke aktiviteter skal vi sikre os gennemføres i realiseringsfasen (hvor projektet er lukket, dvs. gevinstejeren eller seniorbrugeren skal tage ansvar for disse)? 6. 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? 7. Etc. 3.6.2 Effektiviseringsgevinster Effektiviseringsgevinster forstås bredt som de økonomiske gevinster, der er med til at bidrage til en positiv nettonutidsværdi og en positiv intern rente. Der opereres med tre typer af effektiviseringsgevinster. Budgetmæssige og produktivitetsgevinster kan henføres direkte til en statslig konto. Budgetmæssige gevinster medfører tillige en direkte påvirkning af myndighedens budget, dvs. de er cashable i den forstand, at de er budgetreducerende. Samfundsøkonomiske gevinster er gevinster, som bidrager positivt til projektets nettonutidsværdi, men som ikke kan henføres til en offentlig konto. Det kan f.eks. være gevinster for private og virksomheder. 3.6.3 Ikke-økonomiske gevinster Ikke-økonomiske gevinster refererer til gevinster, som er kvalitative i natur, fx større brugertilfredshed med et givet system. Ikke-økonomiske gevinster kaldes også kvalitetsløftsgevinster. Afsnittet skal indeholde en liste over de ikke-økonomiske gevinster fordelt på gevinstejer for projektet. Detailbeskrivelse af gevinster findes i produktbilag B: Gevinstdetaljer. 3.7 Teknisk løsning 3.7.1 Markedsundersøgelse Statslige it-projekter bør orientere sig i markedet før nyudvikling igangsættes samt for at sikre så godt indblik som muligt i eksisterende standardløsninger. I dette afsnit indsættes kort oversigt over, hvilke systemer, leverandører m.v. der er undersøgt, samt hvilke kriterier, der er lagt til grund for valget af løsning. I afsnittes skrives også, hvis der er lavet erfaringsudveksling med nationale eller internationale aktører, der har samme behov som myndigheden. 3.7.2 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: 1. Teknologiens modenhed hvor velafprøvet er den ønskede teknologi i forhold til teknologiens anvendelsesområde? 2. Genanvendelse af komponenter kan der med fordel genanvendes egne eller andre institutioners komponenter? 3. Standardsystem er der foretaget afdækning af, om markedet kan levere et standardsystem ift. det ønskede anvendelsesområde 4. Systemmoduler hvor stor er den tekniske kompleksitet i projektet mht. antallet af moduler i løsningen? 5. Integrationer Hvor stor er den tekniske kompleksitet mht. antallet af integrationer til andre systemer? Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [7]

6. Konvertering og migrering - Hvor stor er den tekniske kompleksitet mht. konvertering og migrering? 7. 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: 1. Beskrivelse af hvilke applikationer, der bruger hvilke forretningsobjekter / data (svarer til OIOEA: C2.2 Applikation-Information map) 2. Overblik over hvilke applikationer der understøtter hvilke forretningsprocesser / handlinger (svarer til OIOEA: C2.4 Applikation-Proces map) 3. 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.7.3 Integrationer Her listes og beskrives de forventede integrationer, herunder kompleksitet og anvendelse af standarder til integration. 3.7.4 Test Det er obligatorisk i henhold til den fællesstatslige it-projektmodel at udføre tests af projektets løsning i gennemførelsesfasen. I PID ens afsnit 7.1 redegøres for den teststrategi, der skal, sikre, at projektets løsning vil leve op til de målsætninger, der er formuleret. Afsnittet bør tillige også adressere brugerinddragelsen (hvis relevant) i forhold til tests. På hjemmesiden for Ministeriernes projektkontor findes værktøj om tests, der kan give inspiration til tilrettelæggelsen. 3.8 Leverancer 3.8.1 Leverancer og afhængigheder I dette afsnit skal projektets hovedleverancer beskrives samt hvilke afhængigheder, der allerede nu identificeres ift. de enkelte leverancer både interne og eksterne. 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. 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. Projekt- Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [8]

gruppen 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. 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. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [9]

3.10 Tilrettelæggelse og tidsplan I dette afsnit beskrives relevante strategier, som minimum de strategier, der er udpindet med egen overskrift. Findes der yderligere strategier, der er relevante for projektet tilføjes yderligere underafsnit. 3.10.1 Udbudsstrategi Beskriv den overordnede udbudsstrategi og kontraktstrategi i projektet, tilgangen til det, og hvordan den sikres udmøntet. Se evt. værktøjet udbudsstrategi. 3.10.2 Udviklingsstrategi Beskriv den overordnede udviklingsstrategi, herunder om der anvendes vandfaldmodel, agile udviklingsmetoder, etc. samt hvordan udviklingsstrategien er forankret i organisation og tilgængelige kompetencer. 3.10.3 Implementeringsstrategi og forandringsledelse Beskriv kort implementeringsstrategien for hvordan systemet udrulles og sættes i drift, strategi for go-live samt strategien for forandringsledelsen. Der kan tages udgangspunkt i Bilag A: Gevinstdiagram. Angiv særskilt, hvornår strategier forventes konkretiseret til egentlige (detail)-planer for implementering, go-live og eventuelle andre forandringstiltag. 3.10.4 Kriterier for overdragelse af leverancer fra projekt til forretning Her opstilles konkrete kriterier, som projektet skal overholde, før leverancerne kan overtages af forretning og drift. Der påføres i skemaet 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.10.5 Tidsplan Kort beskrivelse af de overvejelser der har været gjort i forbindelse med udarbejdelsen af tidsplan, milepælsplan og kritisk vej. Er der forhold, 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 og 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ørelse 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. Skemaet i afsnittet skal udfyldes, og der skal udarbejdes en milepælsplan med angivelse af kritisk vej som enten kan indsættes i afsnittet eller vedlægges som bilag. 3.11 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. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [10]

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.11.1 Kvalitetsplanlægning Her beskrives, hvad der skal kontrolleres i projektet, kvalitetsaktiviteterne til gennemførelse 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.11.2 Kvalitetskontrol Her beskrives, 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.11.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 It-projektrådet eller ekstern revision. 3.12 Risici Risikostyring er beskrevet i detaljer i vejledningen om risikostyring, som anbefales læst forud for fastlægningen af risikostyringen i projektet. 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 hvem, hvordan og hvor ofte der følges op på risici. Tag stilling til hvor risikovillig man ønsker at være i projektet. Inddrag så vidt muligt primære interessenter i risikoanalysen. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [11]

3.13 Informationssikkerhed Alle it-projekter, som anvender it-projektmodellen, skal udover en risikovurdering af projektet også lave vurderinger af informationsaktivet og it-løsningen. Informationsaktivet er den information (data), som skal behandles af it-løsningen, og som skal sikres. Til dette er der to produkter, PIA og sikkerhedsmæssig risikovurdering, hvoraf det ene, PIA, kan udelades, såfremt it-løsningen ikke skal behandle personoplysninger. Personoplysninger forstås ved enhver information om et fysisk individ, som er identificeret eller er identificerbar. Produkterne skal udarbejdes i analysefasen for at sikre det bedst mulige udgangspunkt for løsningen. Processen for arbejdet med informationssikkerhed i statens it-projektmodel ser sådan ud: Skal it-løsningen behandle personoplysninger? Hvis JA, der skal laves PIA og sikkerhedsmæssig risikovurdering Hvis NEJ, der skal laves sikkerhedsmæssig risikovurdering PIA Sikkerhedsmæssig risikovurdering Sikkerhedsmæssig risikovurdering Efterfølgende forklares begreberne PIA og sikkerhedsmæssig risikovurdering kort, og der henvises samtidigt til relevante vejledninger med detaljeret information om disse. PIA og sikkerhedsmæssig risikovurdering En PIA, Privacy Impact Assessment, som den kaldes af de fleste, handler om, at der skal foretages en vurdering af de risici, set fra et individs synspunkt, der kan være ved, at en aktør behandler individets personoplysninger. Digitaliseringsstyrelsen har udgivet en vejledning i vurdering af offentlige it-projekters potentielle konsekvenser for privatlivet, som omfatter samme betragtninger, og som også tænker konsekvenserne ind for den dataansvarlige. Vejledningen kan sammen med værktøjet til konsekvensvurdering af privatlivskonsekvens, hentes via nedenstående henvisning. http://www.digst.dk/arkitektur-ogstandarder/videnscenter-for-implementering-af-iso27001/konsekvensvurdering-forprivatlivet.aspx En sikkerhedsmæssig risikovurdering er en risikovurdering, som tager udgangspunkt i de informationssikkerhedsmæssige risici ved it-løsningen og ikke selve it-projektet. En sikkerhedsmæssig risikovurdering skal også tage stilling til cybertrusler, som er trusler, der kan påvirke it-løsningens sikkerhed fra Internettet. Arbejdet med en sikkerhedsmæssig risikovurdering behandles i afsnittet om sikkerhedsmæssig risikovurdering. PIA og privatlivsfremmende teknologier Privacy Impact Assessment eller privatlivsrelateret konsekvensvurdering skal udarbejdes, såfremt it-løsningen skal behandle personoplysninger. Når der er foretaget en konsekvens- Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [12]

vurdering, vil resultatet afgøre i hvilket omfang, der er behov for foranstaltninger til at reducere risici for indgriben i datasubjekternes privatliv. Følgende teknologier kan overvejes: Anonymisering Pseudonymisering Virtuelle identiteter Partiel identifikation Kryptering Ovennævnte teknologier samt arbejdet med privatlivsrelateret konsekvensvurdering beskrives nærmere i vejledningen i vurdering af offentlige it-projekters potentielle konsekvenser for privatlivet. Vejledningen kan findes her: http://www.digst.dk/arkitektur-ogstandarder/styring-af-informationssikkerhed-efter-iso-27001/konsekvensvurdering-forprivatlivet Resultatet af konsekvensvurdering for datasubjektet, dvs. den person, som data vedrører, skal indarbejdes i føromtalte sikkerhedsmæssige risikovurdering. Denne forklares i det følgende afsnit. Sikkerhedsmæssig risikovurdering Udover de risici, der vedrører de projektmæssige hændelser, skal der også udarbejdes en liste over risici, som relaterer sig til sikkerheden i og omkring it-løsningen. Disse overvejelser udgør den sikkerhedsmæssige risikovurdering, som er obligatorisk for alle it-projekter, der skal igennem It-projektrådet. Processen for udarbejdelse af den sikkerhedsmæssige risikovurdering ser ofte således ud: Klassifikation af informationsaktivet Konsekvens-vurdering af brud på informationssikkerhed en Trusselsvurdering/ sårbarhedsvurdering Risikohåndtering Første skridt i processen med at udarbejde en sikkerhedsmæssig risikovurdering er at finde ud af, hvilken type information, der forventes at blive lagret og behandlet i it-løsningen. Klassifikation af informationsaktivet skal ske i henhold til sikkerhedscirkulæret som henvises til her: https://www.retsinformation.dk/forms/r0710.aspx?id=166206 Udover den information, som klassificeres i henhold til sikkerhedscirkulæret skal information som personoplysninger betragtes som klassificeret. Når it-løsningen skal indsamle og/eller behandle personoplysninger skal persondataloven overholdes. Persondataloven kan findes her: https://www.retsinformation.dk/forms/r0710.aspx?id=828 Konsekvensvurdering af it-løsningen Formålet med at konsekvensvurdere er at finde ud af, hvor meget sikkerhed, der skal tænkes ind i it-løsningen. Kort fortalt handler en konsekvensvurdering om at afdække konsekvensen ved, at der sker brud på informationssikkerheden i it-løsningen. Altså, hvad sker der, hvis nogen får uautoriseret adgang til it-løsningen og får adgang til at udlæse informationer (fortrolighed), får adgang til at ændre eller slette informationer (integritet), og slutteligt skaden, hvis it-løsningen ikke er tilgængelig for dets autoriserede brugere f.eks. pga. nedbrud (tilgængelighed). Et obligatorisk element i arbejdet med risikovurderingen består i at vurdere om en it-løsning hænger sammen med andre it-løsninger, f.eks. som aftager- eller kildesystem. Disse forhold kan påvirke konsekvensvurderingen, og skal indarbejdes og afspejles det i videre arbejde med it-løsningen. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [13]

Der henvises til gældende vejledning i it-risikostyring og vurdering, hvori der findes yderligere forklaring på opgørelse af konsekvensniveauer. http://www.digst.dk/arkitektur-ogstandarder/videnscenter-for-implementering-af-iso27001/vejledninger-omsikkerhedsarbejdet/risikovurdering.aspx Identifikation af risici Resultatet af konsekvensvurderingen vil udstikke retning i forhold til gennemførelse af risikovurderingen. Således vil det være mest hensigtsmæssigt at vurdere risici, som kan relateres til de påvirkninger, som har størst konsekvens for systemet. Det forventes efterfølgende, at de identificerede risici, hvor konsekvensen er tilstrækkelig stor til, at den ikke kan accepteres, herefter mitigeres på en balanceret måde. Det er ofte fordelagtigt at tænke sikkerheden i designet af løsningen, hvilket kan medvirke til, at det efterfølgende arbejde med sikkerhed både er billigere og giver mere reel sikkerhed. I vejledningen i it-risikostyring og vurdering beskrives det nærmere, hvordan den efterfølgende håndtering af de identificerede risici kan imødegås. Risikohåndtering I det fortsatte arbejde med informationssikkerhed skal alle efterfølgende faser efter analysefasen, understøtte mitigeringen af de risici, som er identificeret i analysefasen i forbindelse med PIA og sikkerhedsmæssig risikovurdering. Eksempelvis skal et krav til brugerstyring, adgangskontrol, krypteret af kodeord, pseudonymisering og virtuelle brugeridentiteter stilles i kravspecifikationen. Dvs. i anskaffelsesfasen. Gennemførelsesfasen af it-projektet skal indeholde testscenarier, hvor de sikkerhedsmæssige risici og krav til ovennævnte efterprøves. Alt efter om it-projektet afvikles som et agilt forløb eller traditionelt vandfaldsbaseret, skal testene placeres mest hensigtsmæssigt i forhold til leverandørens leverancer. Dette betyder, at it-løsningens samlede accepttest skal omfatte de sikkerhedsmæssige elementer. Ide Analyse Anskaffelse Gennemførelse Realisering Analysefasens sikkerhedsmæssige resultater skal indarbejdes i de efterfølgende faser så det sikres, at sikkerheden bliver implementeret, testet og afleveres professionelt til driftsorganisationen, klar til at indgå i det almindelige ISO 27001 sikkerhedsarbejde i organisationen. For både PIA og den sikkerhedsmæssige risikovurdering gælder, at risici identificeret hermed skal indgå i risikoregisteret. 3.13.1 Sikkerhedsmæssig risikovurdering I dette afsnit gengives væsentligste konklusioner fra den sikkerhedsmæssige risikovurdering, herunder væsentligste udfordringer, mitigerende handlinger samt hvordan sikkerhedsmæssige risici procesmæssigt håndteres. Sikkerhedsmæssige risici skal være indeholdt i risikoregister for projektet. 3.13.2 Konsekvensvurdering for privatlivet Såfremt løsningen behandler personoplysninger fremhæves væsentligste konklusioner af PIA analyse, mitigerende handlinger samt beskrivelse af evt. samarbejde med Datatilsynet i denne forbindelse. Risici relateret til konsekvenser for privatlivet skal være indeholdt i risikoregisteret. 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 Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [14]

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 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. Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [15]

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 It-projektrådet 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, mål og de tiltag leverancer og den organisatoriske implementering heraf, der skal til for at opnå gevinsterne. 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 om fortolkningen af projektets formål, hvis dette ikke allerede er helt klart 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 / samle dem i grupper. Ligeledes kan en gevinst føre til en anden. Dette skal også fremgå af gevinstdiagrammet. Herefter gås trinvist tilbage i gevinstkæden ned til de leverancer, der på konkret plan skal bidrage til at opnå de ønskede gevinster. Der er mere hjælp at hente til udarbejdelse af gevinstdiagram i vejledningen hertil, der kan hentes på Digitaliseringsstyrelsens hjemmeside. Nedenfor er gengivet et eksempel på et udfyldt gevinstdiagram. Testet ESDHsystem Procesbeskrivelser Kurser Organisatorisk forankring 95 pct. behandler klager rigtigt Alle brugere uddannet Flere tilfredse kunder Kortere sagsbehandlingstid Færre bortkomne akter Effektivisering Leverancer Mål 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 fire typer. Budgetmæssige, produktivitetsmæssige, samfundsøkonomiske og ikke-økonomiske gevinster (kvalitetsløftgevinster). For de tre første gælder, at de optræder i business casen og er gjort målbare i monetære enheder. Ikke-økonomiske gevinster er Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [16]

målbare, men vil ofte være i andre enheder f.eks. en tilfredshedsskala, anvendelsesskala, etc. Budgetmæssige og produktivitetsgevinster kan indbudgetteres og henføres til en specifik, offentlig konto. Gevinsterne kan, når de høstes, enten være cashable dvs. det er muligt at skære dem væk fra budgettet og anvende dem på andre tværgående prioriteringer. Disse angives som budgetmæssige. Alternativt kan gevinsterne forblive i den enkelte myndighed og f.eks. anvendes til at gøre kvaliteten bedre, øge sagsbehandlingen eller give rum til nye opgaver. Disse gevinster betegnes produktivitetsgevinster. Det er et spørgsmål om gevinstrealiseringsstrategien og planlægningen af høsten af de pågældende gevinster. Samfundsøkonomiske gevinster er gevinster som ikke har en direkte effekt på en myndigheds budget, men derimod er økonomiske gevinster for erhvervslivet eller borgere. Ikkeøkonomiske gevinster er gevinster, der forbedrer ikke-økonomiske parametre, såsom tilfredshed, eller øget anvendelsesgrad af en bestemt ydelse. 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ør-situationen 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. 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.2017 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 6.12.2014 AA Midtvejsmåling 6.6.2015 6.6.2016 6.6.2017 Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen [17]