DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL 1.5

DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL 1.5 1

HVORFOR HAVE EN FÆLLESSTATSLIG IT- PROJEKTMODEL? Den giver et fælles referencegrundlag for alle, der arbejder med projekter Så får vi endelig dokumenteret Det giver ensartethed Det er ikke modellen, men brugen af den, der kan løfte kvaliteten Det er noget, bureaukrater har fundet på Det er også spild af tid og papir Den sikrer sammenlignelighed mellem projekter Den indeholder mange års bedste praksis 1.5 2

VEJEN TIL UDDANNELSE I IT-PROJEKTMODELLEN Analyse af erfaringer fra ni statslige itprojekter Rapport om prof. af arbejdet med itprojekter i staten Fællesstatslig itprojektmodel Dilemmaer og udfordringer i projektledelse Undervisning - Kravene - Bedste praksis - Tips og tricks Analysen konkluderede, at de væsentligste problemområder i statens it-projekthåndtering er: Manglende projektmodenhed: Projektværktøjer, processer og ressourcer samt erfaring fra tilsvarende projekter. Der gennemføres meget risikofyldte projekter: De statslige it-projekter er særdeles risikofyldte og gennemføres ofte uden, at der tages de nødvendige forholdsregler for at håndtere risici. Knaster i samarbejdsrelationerne. 3 1.5 3

VEJEN TIL UDDANNELSE I IT-PROJEKTMODELLEN Analyse af erfaringer fra ni statslige itprojekter Rapport om prof. af arbejdet med itprojekter i staten Fællesstatslig itprojektmodel Dilemmaer og udfordringer i projektledelse Undervisning - Kravene - Bedste praksis - Tips og tricks Formålet med projektmodellen er: dels at give projekterne et kompetencemæssigt løft ved at stille bedste praksisværktøjer til rådighed for projekterne dels at skabe grundlag for læring på tværs af projekterne. Det er en værktøjskasse bestående af en fasemodel med tilhørende produkter, skabeloner og vejledninger. Men disse kan ikke stå alene 4 1.5 4

VEJEN TIL UDDANNELSE I IT-PROJEKTMODELLEN Analyse af erfaringer fra ni statslige itprojekter Rapport om prof. af arbejdet med itprojekter i staten Fællesstatslig itprojektmodel Dilemmaer og udfordringer i projektledelse Undervisning - Kravene - Bedste praksis - Tips og tricks Det er erfaring, bedste praksis og tips og tricks, som kan skabe den virkelige nytte af en projektmodel. Vi har derfor indsamlet dilemmaer og udfordringer samt bedste praksis og har indarbejdet disse i undervisningen i it-projektmodellen tillige med tips og tricks. Dette er kun begyndelsen. 5 1.5 5

DET OMFATTER IT-PROJEKTMODELLEN En faseopdeling af projektforløbet Et begrænset antal obligatoriske produkter En række valgfrie men anbefalede produkter Beskrivelser af roller og ansvar i projekter 1.5 6

KORT OM IT-PROJEKTMODELLEN Ved gennemførelse af it-projekter skal den fællesstatslige it-projektmodel følges. En fælles model for hele staten skal bidrage til bedre og mere ensartet planlægning, styring og gennemførsel af it-projekter i staten. Udarbejdet i samarbejde med en statslig arbejdsgruppe og med udgangspunkt i bedste praksis i staten og PRINCE2. Udvikles og vedligeholdes af Ministeriernes Projektkontor i Økonomistyrelsen. Faseopdeling skal anvendes af alle statslige it-projekter. Obligatoriske produkter skal udarbejdes af projekter over 10 mio. kr. 1.5 7

I FORHOLD TIL PRINCE2 Projektmodellen anvender overvejende PRINCE2 begreberne, da disse er udbredt i staten (de fleste steder dog PRINCE light ). Følgende standardbegreber fra PRINCE2 anvendes: Produkter: Projektoplæg, Projektinitieringsdokument, Faseplan og Faseafslutningsrapporter (kombineret i én rapport), Projektafslutningsrapport. Roller: Alle PRINCE2-roller, f.eks. Projektleder, Styregruppe, Seniorbruger, Seniorleverandør. Følgende begreber afviger fra PRINCE2: Fasebetegnelserne (start af projekt idefase, initiering af projekt analysefase). Roller: En lang række specifikke it-roller er defineret som tillæg til PRINCE2-rollerne. 1.5 8

ALLE IT-PROJEKTER OPDELES I 5 HOVEDFASER Formål Idé kvalificeres og beskrives i et projektoplæg. Grundlaget for projektet analyseres og defineres i projektinitieringsdokument (PID). Behov og krav til itsystem beskrives og anskaffelse gennemføres. Kontrakt underskrives og design, udvikling test, idriftsættelse og implementering gennemføres. Gevinster realiseres i henhold til business case og gevinstrealiseringsplan. Output Godkendt projektoplæg Godkendt PID Kontrakt klar til underskrift Godkendt projektafslutningsrapport Godkendt gevinstrealiseringsrapport Projektejer udpeget Projektleder udpeget 1.5 9

OBLIGATORISKE LEDELSESPRODUKTER FOR IT-PROJEKTER 10 MIO. KR. Faseovergangsrapport Projektinitieringsdokument* Faseovergangsrapport Faseovergangsrapport Afvigelsesanmodning Faseovergangsrapport Afvigelsesanmodning Projektafslutningsrapport Gevinstrealiseringsrapport Business case* Kvalitetsplan Afvigelsesanmodning Gevinstrealiseringsplan* Risikoanalyse* Afvigelsesanmodning Risikoscore til IT-projektrådet Et ledelsesprodukt i it-projektmodellen understøtter styring og beslutninger i projektforløbet. Produkter markeret med * opdateres som minimum ved hver faseovergang. 1.5 10

ANBEFALEDE LEDELSESPRODUKTER Projektoplæg Produktbaseret planlægning Produktbeskrivelse Arbejdspakker Interessentanalyse Kommunikationsplan Projektroller Udbudsstrategi 1.5 11

STATENS IT-PROJEKTRÅD RÅDETS OPGAVER 2.5 12

KORT OM IDÉFASEN Idéfasen Formål med fasen At kvalificere en idé til et it-projekt og udmønte den i et projektoplæg, som beskriver, hvordan projektet kan yderligere kvalificeres i en analysefase samt hvilke ressourcer/tid der vil medgå til denne kvalificering. Typiske aktiviteter Kriterier ved faseovergang Godkendt Faseovergangsrapport (faseplan delen) Sponsor udpeget Foranalyse af ideens bæredygtighed mht. gevinster Foretage overslag over mulige samlede omkostninger Udarbejde plan for analysefasen Skrive projektoplæg Obligatoriske produkter Faseovergangsrapport (faseplan delen) Anbefalede produkter Projektoplæg 1.5 13

KORT OM ANALYSEFASEN Formål med fasen Typiske aktiviteter Analysefasen At analysere grundlaget for projektet og definere projektet i form af et projektinitieringsdokument (PID) Detailanalyse af projektets omfang, krav til ressourcer, omkostninger, mulige gevinster, tidsplan, risiko, kvalitet etc. Udarbejdelse af PID Udarbejde plan for Anskaffelsesfasen Identificere projektleder Markedsanalyse Teknologianalyse- og vurdering Kriterier vedfaseovergang: Obligatoriske produkter: Anbefalede produkter: Obligatoriske produkter godkendt Projektleder udpeget Projektinitieringsdokument (PID) Kvalitetsplan Business case Risikoanalyse Faseovergangsrapport Gevinstrealiseringsplan Afvigelsesanmodning Risikoscore til It-projektrådet Produktbaseret planlægning Produktbeskrivelse Arbejdspakker Interessentanalyse Kommunikationsplan Projektroller 1.5 14

RISIKOSCOREN 1.6 15

FORMÅL OG KONTEKST Formål Risikoscoren indgår i Statens IT-projektråds risikovurdering af statslige it-projekter. -> høj risiko medfører forelæggelse. Redskab til at skabe opmærksomhed omkring væsentlige risikofaktorer for it-projekter og som en tjekliste til det enkelte projekt. Risikoscoren erstatter ikke it-projektets eget arbejde med risikostyring. Kontekst Den skal senest udfyldes ved udgangen af projektets analysefase (sammen med PID og business case). Udarbejdes af den med størst indsigt i projektet evt. et team. Den skal godkendes af ansvarligt direktionsmedlem i den projektejende institution. 1.6 16

RISIKOSCORE SKEMAETS OPBYGNING Kommentarer Emne Risikoparameter og definition Vurdering Forklaring http://www.oes.dk/offentlig-udvikling/ministeriernes-projektkontor/projektmodellen/download 1.6 17

DE FIRE KRITISKE TIL RISIKOSCOREN 1. Er det ikke blot endnu en papirtiger hvad vil den tilføre af værdi? Den er baseret på seriøse undersøgelser af, hvad der giver høj risiko i et projekt, så hvorfor ikke tage tyren ved hornene i starten af projektet og forholde sig til det? 2. Hvem vil nogensinde bruge den? Den skal bruges ift. IT-projektrådet men brug den også aktivt i dit eget projekt. 3. Vil projekterne flage høj risiko eller blot camouflere den? Modellen er baseret på udstrakt grad af facts i håbet om, at den ikke kan udfyldes som elastik i metermål. 4. Er risikoscoren statisk? Tanken er, at den opdateres i takt med høstede erfaringer. 1.6 18

PRODUKTINITIERINGSDOKUMENT 1.11 22

FORMÅL PID skal sikre, at projektet har et stabilt beslutnings- og ledelsesgrundlag, før styregruppen forpligter sig til projektet, herunder afholdelse af væsentlige udgifter. PID skal fungere som et grunddokument (baseline) i forhold til hvilket, styregruppen og projektlederen kan vurdere fremdrift, emner angående afvigelsesstyring og løbende spørgsmål om fortsættelse af projektet. PID skal også give styregruppen et grundlag til at vurdere, om det overordnede formål med projektet dækkes af projektets leverancer og fremgangsmåde. 1.11 23

KONTEKST PID er grundstenen hoveddokumentet - og udarbejdes i analysefasen. Indgår i pakken til IT-projektrådet (sammen med risikoscore og business case). Revideres løbende i hele projektforløbet. Projektinitieringsdokumentet er et paraplydokument, hvorfra der refereres til underdokumenter. Projektinitieringsdokumentet skal som minimum suppleres med følgende dokumenter: Business case, Risikoanalyse, Kvalitetsplan og Gevinstrealiseringsplan. Styregruppen skal godkende projektinitieringsdokumentet. Skal endvidere kunne bruges af projektmedarbejderne og centrale interessenter som fælles referencegrundlag. 1.11 24

Valgfri Obligatorisk I FORHOLD TIL PRINCE2 PRINCE2 PID template Alle elementer er med, men struktureret lidt anderledes Forretningsmæssig begrund else og formål Mål og succes kriterier Økonomiske hovedtal Leverancer Fremgangs måde Risici Kvalitetsstyring Tolerancer Afgræn sninger og afhængig heder Organisering Interessent håndtering Kommunikation De 5 principper Allokering fordelt på roller 1.11 25

Valgfri Obligatorisk HVOR SIGER ERFARINGEN, AT DET GÅR GALT? Forret- Vi høstede nings- mæssig ikke Mål og gevinsternesucces begrun delse kriterier og formål Kvali- Tolerancer for tets- styring Det blev dyrt Vi blev Økonomiske Leve- forsinkede hovedtarancer Fremgangs måde Risici Vi havde ikke de rigtige Allokering på fordelt Modtageorganisationen holdet på roller var ikke klar Driften var ikke forberedt AfgrænVi fik ikke det Interessent sninge rigtige Organi r og afhængi -sering håndtering gheder Leverandøren kunne ikke Kom-levere De 5 muni- kation cipper prin- Vores interessenter tog ikke ejerskab 1.11 26

INTRODUKTION BUSINESS CASE & GEVINSTREALISERINGSPLAN 2.2 27

DEN FÆLLESSTATSLIGE BUSINESS CASE 2.2 28

FORMÅL OG KONTEKST Business case er en teknik til at opbygge troværdighed omkring en forretningside. Den kan hjælpe til at træffe forretningsmæssige beslutninger. Business casen har til formål at beregne og visualisere fordele og risici i forhold til omkostningerne af en beslutning. En business case er mere end en økonomimodel - en god business case indebærer, at beviser/fakta/skøn og rationelle argumenter præsenteres på en tilgængelig måde, hvormed dens konklusioner bliver gennemskuelige. Centrale elementer i opbygningen af en business case omfatter dataindsamling, estimering, identifikation af markedet og risikoberegninger. 2.2 29

HVORFOR BEDRE BUSINESS CASES PÅ IT-PROJEKTER? Det vurderes, at staten årligt investerer ca. 3,2 mia. kr. i it-projekter. It-projekter er komplekse og påvirker såvel faglige som organisatoriske forhold. It-projekter er blevet en af de primære drivere inden for moderniseringen af den offentlige sektor. Der er derfor behov for et oplyst beslutningsgrundlag, hvilket indebærer en øget kvalitet af de økonomiske estimater for både udgifter og gevinster. 2.2 30

FORMÅL OG KONTEKST 1. Business case, risikoscore og projektinitieringsdokument indsendes til IT-projektrådet. 2. Opdateres ved hver faseovergang eller ved afvigelser. 2.2 31

DEN GODE OG DEN MINDRE GODE BUSINESS CASE Den gode business case Typisk selvstændigt udfærdiget i samarbejde med projektejer Som minimum gøre ingenting vs. gøre noget Opstiller et handlingsrationale Opstiller nettopotentiale Sikrer sammenhæng ml. business case og gevinstrealisering Opstiller følsomhedsanalyse og kvalificerer risikoelementer Faglig dokument Den mindre gode business case Typisk politisk dokument/forhandlingsdokument Viser kun et alternativ Oplister bruttopotentiale Ser bort fra gevinstrealisering (f.eks. implementering) Viser ikke følsomhedsanalyse og underspiller risikoelementer uden kvalificering 2.2 32

LAD OS SE NÆRMERE PÅ DEN NYE MODEL.. Word-skabelon Regneark 2.2 33

HVAD ER NYT I DEN NYE BC-MODEL? 1. Gevinster Obligatorisk at beskrive projektet og nulløsningen Der skelnes mellem økonomiske gevinster, der har en direkte effekt på en institutions budget, og de effekter, der generelt forbedrer mulighederne for erhvervslivet, borgerne, etc. Ikke-økonomiske gevinster opgøres detaljeret og kvantificeres 2. Forudsætninger BC opbygges via forudsætninger Der angives et spænd rundt om forudsætninger, hvilket beskriver projektets udfaldsmuligheder mere nuanceret 2.2 34

HVAD ER NYT I DEN NYE BC-MODEL? 3. Beslutningsgrundlag Projekter skal angive, hvad projektets primære formål er Nettonutidsværdi og intern rente Diskonteringsfaktor [5 %] Word-skabelonen skal opdateres for hver faseovergang Business casen fokuserer på konsekvensberegninger 4. Styring og opfølgning Gevinster og udgifter skal henføres til specifikke gevinst- og omkostningsbærere Faste og udgiftskategorier koblet til den statslige kontoplan Alle tal i business case-skabelonen er udgiftsbaserede Fast praksis for anvendelse af buffere Udgifter og gevinster tælles med, så længe der afskrives 2.2 35

GEVINSTREALISERINGSPLANEN 2.3 36

NYT PARADIGME Det traditionelle projektledelsesdogme: Projektet skal leveres til tid, pris og kvalitet Burde det ikke afløses af: Har vi fået en it-løsning, som giver en tilfredsstillende understøttelse af forretningen i daglig drift? Var det indsatsen værd og kom den på det rigtige tidspunkt? Goddag og velkommen til gevinstrealiseringsplanen! 2.3 37

FORMÅL OG KONTEKST Gevinstrealiseringsplanen Obligatorisk ledelsesprodukt i projektmodellen. Skal være med til at sikre, at projektets formål indfries. Planen udarbejdes på baggrund af BC og PID. Planen skal rumme beskrivelse af de konkrete aktiviteter og den organisering af arbejdet, der er nødvendig, for at gevinsterne kan hentes hjem. Kontekst 1. version af gevinstrealiseringsplanen udarbejdes i analysefasen sammen med PID. Gevinstrealiseringsplanen opdateres ved hver faseovergang. Planen udbygges i forbindelse med projektafslutningen ved overgang til realiseringsfasen og godkendes af styregruppen. 2.3 38

PLAN FOR GEVINSTREALISERING Økonomiske og kvalitative gevinster - Hvilket beløb er indregnet i business casen? - Hvilke konkrete kvalitative gevinster? Målbare gevinster - Hvad er gevinstmålingen baseret på? Årsværk der kan spares Antal servere der kan lukkes Reduktion i antallet af fejl Metode - Hvordan har vi tænkt os at måle, om gevinsten er realiseret? Foretages en baseline-måling? Meget konkret angivelse af, hvordan optællingen /konstateringen kan foretages 2.3 39

PLAN FOR GEVINSTREALISERING Dato for måling - Hvornår måler vi på realiseringen? Gøres dette løbende, ved go live eller et år efter go live? - Jo senere, desto større risiko for, at realiseringen ikke entydigt kan henføres til projektet Ansvarlig for måling - Hvem har ansvaret for gevinstens realisering og dermed for målingen? 2.3 40

KUNSTEN AT OPSTILLE MÅLBARE RESULATER Beslutningstagerne har forskellige forestillinger om løsningens resultater Tag derfor ikke til takke med overordnede mål - "Højere effektivitet" - "Bedre videndeling" - "Større medarbejdertilfredshed" Skab konsensus om konkrete og målbare resultater - "Afdelingen bliver i stand til at håndtere 15% flere sager" - "Hver medarbejder skal spare 10 min. om dagen ved bedre opslagsmuligheder" - "5% mindre sygefravær" Du køber ikke en it-løsning for det, den kan. Du køber den for det, du forestiller dig, at den kan gøre for dig. 2.3 41

ANSKAFFELSESFASEN 2.7 42

KORT OM ANSKAFFELSESFASEN Anskaffelsesfasen Formål med fasen At få specificeret de ydelser, der skal i udbud/anskaffes fra eksterne leverandører, evt. sende disse i udbud, vælge leverandør samt forberede og indstille til kontraktunderskrift Typiske aktiviteter Udarbejde overordnet strategi for anskaffelse, implementering og idriftsættelse Udarbejde plan for testforløb Specificere behov og krav samt processer for det, der skal anskaffes Specificere plan for teknisk og organisatorisk implementering samt test- og prøveforløb Udarbejde udbudsmateriale Offentliggøre udbud og eventuelt gennemføre prækvalifikation af leverandører Sammenligne tilbud Eventuelt gennemføre kontraktforhandlinger Indstille til kontraktunderskrift Kriterier ved faseovergang: Obligatoriske produkter godkendt Kontrakt klar til underskrift Obligatoriske produkter: Opdateret PID Opdateret Business case Opdateret Risikoanalyse Faseovergangsrapport Afvigelsesanmodning Valgfri men anbefalede produkter: Udbudsstrategi Ændringsanmodning Kvalitetsplan 2.7 43

OPDELING AF ANSKAFFELSESFASEN For it-projekter på 60 mio. kr. og derover gælder, at anskaffelsesfasen skal opdeles i en specificeringsfase og en udbudsfase som illustreret nedenfor. Opdelingen er valgfri for it-projekter under 60 mio. kr. Specificeringsfasen: Krav og behov specificeres til en ekstern leverandør og et eller flere udbud forberedes. Udbudsfasen: Leverandører afgiver tilbud på leverancer iht. specifikationerne. Fasen afsluttes med en indstilling til kontraktunderskrivelse. 2.7 44

GENNEMFØRSELSFASEN 2.12 47

KORT OM GENNEMFØRSELSFASEN Gennemførselsfasen Formål med fasen At få designet, udviklet, opsat, testet, implementeret og overdraget til drift, således at organisationen er klar til at realisere de specificerede gevinster (denne fase vil typisk være underopdelt i ledelsesfaser med tilhørende produkter) Typiske aktiviteter Detaildesign af løsning Udvikling og test Pilotforløb Uddannelse og implementering Forberede overdragelse til drift Fastlægge videre arbejde med gevinstrealisering Kriterier ved faseovergang Obligatoriske produkter godkendt Obligatoriske produkter Opdateret PiD Opdateret Business case Faseovergangsrapport Afvigelsesanmodning (hvis relevant) Projektafslutningsrapport Anbefalede produkter Ændringsanmodning Kommunikationsplan Interessentanalyse Produktbeskrivelse Arbejdspakker 2.12 48

KORT OM GENNEMFØRSELSFASEN Formål med fasen Gennemførselsfasen At få designet, udviklet, opsat, testet, implementeret og overdraget til drift, således at organisationen er klar til at realisere de specificerede gevinster (denne fase vil typisk være underopdelt i ledelsesfaser med tilhørende produkter) Typiske aktiviteter Detaildesign af løsning Afvigelsesrapportering Udvikling og test Pilotforløb Risikohåndtering Uddannelse og implementering Afvigelsesanmodning Forberede overdragelse til drift Fastlægge videre arbejde med gevinstrealisering Kriterier ved faseovergang Obligatoriske produkter godkendt Vi vil i denne fase fokusere på: Konstruktivt samarbejde mellem kunde Obligatoriske produkter og leverandør Opdateret PiD Opdateret Business case Faseovergangsrapport Afvigelsesanmodning (hvis relevant) Projektafslutningsrapport Anbefalede produkter Ændringsanmodning Kommunikationsplan Interessentanalyse Produktbeskrivelse Arbejdspakker 2.12 49

RISIKOANALYSE OG -STYRING 2.13 53

FORMÅL OG KONTEKST En risikoanalyse kan defineres som en systematisk måde at identificere og behandle risikofaktorer og usikkerhed på, som led i en helhedsbetragtning. Formålet med at lave en risikoanalyse er at identificere og styre de risici, der er, for at projektet ikke kan realisere sine mål, eller for at organisationen ikke indfrier de forventede gevinster. Risikoanalysen er et obligatorisk ledelsesprodukt i den fællesstatslige itprojektmodel. Skabelonen er obligatorisk at anvende for it-projekter over 10 mio. kr. 2.13 54

Valgfri Obligatorisk PRODUKTETS OPBYGNING Word skabelon + Excel skabelon Indhold /Beskri -velse Risikotype og tidspunkt (fase) Sandsyn -lighed, konsekvens og værdi inden tiltag Reduce -rende tiltag + værdi efter Konsekvenser økonomi, tid kvalitet Beredskabsplan Ansvarlig og status 2.13 55

RISIKOSTYRING Risikostyring er bearbejdning og håndtering af de risici, der identificeres og specificeres i risikoanalysen. Risikostyring sker gennem hele projektet og baseres på den løbende risikoanalyse. 2.13 56

2.13 57

HVORDAN LAVER VI EN RISIKOANALYSE? Identificer risici forbundet med projektet Vurder med baggrund i konsekvens og sandsynlighed om der er tale om høj/middel/lav risiko Beskriv hvordan væsentlige risici skal håndteres (hvordan kan konsekvens eller sandsynlighed minimeres), og dermed indarbejdes i projektets planlægning i øvrigt 2.13 58

RISIKOANALYSE SANDSYNLIGHED OG KONSEKVENS Risikoanalyse Risiko Sandsynlighed Konsekvent Vurdering Handling (Forebygge / Plan B) leverandørs evne til at levere 3 3 9 grænseflader til andre projekter 3 2 6 manglende erfaring i projektgruppen 1 3 3 0 0 0 0 2.13 59

RISIKOANALYSE EKSEMPLER PÅ RISIKOFAKTORER 1. Underleverandørers evne til at levere 2. Behov for store organisatoriske ændringer efterfølgende 3. Manglende erfaring med løsning af den type opgave 4. Behov for inddragelse af store dele af organisationen i projektarbejdet 5. Mange grænseflader til andre projekter 6. Kritiske, ufravigelige milepæle 2.13 60

REAKTIONER PÅ RISIKO 1. Fjerne Gør tingene på en anden måde, så risikoen elimineres 2. Reducere Kontrollere og følge op, så risikoen reduceres 3. Acceptere Vi lever med risikoen 4. Beredskabsplan Vi planlægger og organiserer 5. Konsekvens Vi kender og kommunikerer mulige konsekvenser 2.13 61

PROJEKTAFSLUTNINGSRAPPORTEN 3.2 66

FORMÅL OG KONTEKST Formål: At give styregruppen et beslutningsgrundlag for afslutning af projektet og dermed en afvikling af projektorganisationen. At give input til samlet læring i forbindelse med iværksættelse af fremtidige projekter. Modtagere: Styregruppen er den primære modtager af projektafslutningsrapporten, mens enheder i forretningen, der arbejder med udbredelse af læring, kan inddrage projektets erfaringer i deres arbejde. Projektafslutningsrapporten sendes til Statens ITprojektråd til orientering. Med godkendelse af projektafslutningsrapporten nedlægges projektet og projektleverancerne overdrages til forretningen. 3.2 67

BEDSTE PRAKSIS 1. Projektafslutningsrapporten skal godkendes samtidig med gevinstrealiseringsplanen og faseovergangsrapporten 2. I projektafslutningsrapporten fremgår det hvilke produkter og eventuelt udestående opgaver, der afleveres fra projektet til forretningen Vær ærlig omkring udeståender og overlever altid disse med en plan for færdiggørelse. Overlever på et møde til forretningen, således at der finder formel overlevering sted. 3. Fremlæg rapporten på et afsluttende styregruppemøde. 4. Gevinstrealiseringsplanen bør udarbejdes i tæt tilknytning til udarbejdelse af projektafslutningsrapporten. 3.2 68

EFTER PROJEKTAFSLUTNING Hvornår er projektet slut-slut? Kontrakten er opfyldt Gevinsterne er realiseret (eller glemt) Kunden er tilfreds Tiden er gået Pengene er brugt op Leverandøren er taget hjem Hvor længe skal du blive hængende som projektleder? Hvad kan du, som gevinstejeren ikke kan? Vær opmærksom på dine præferencer Mange projektledere vil hellere starte op end binde sløjfe 3.2 69

GEVINSTREALISERINGSRAPPORTEN 3.4 70

KORT OM REALISERINGSFASEN Realiseringsfasen Formål med fasen At gennemføre realiseringen af projektets gevinster i henhold til oprindelig business case Typiske aktiviteter Ibrugtagen af projektets leverancer Genvistopfølgning Løbende forankring og forbedring Kriterier ved faseovergang Obligatoriske produkter godkendt Obligatoriske produkter Opdateret Business case Afvigelsesanmodning (hvis relevant) Gevinstrealiseringsrapport Anbefalede produkter 3.4 71

TO TILGANGE TIL AT HØSTE GEVINSTERNE 1. At kæmpe aktivt for at komme i mål eller 2. Håbe på at gevinsten kommer af sig selv Der er postet millioner af kroner i digitalisering. Mange følger forbavsende lidt op på effekten af investeringerne. 3.5 72

FORMÅL OG KONTEKST Formål: Opgørelse af de realiserede gevinster Status på arbejdet med gevinstrealisering, jf. gevinstrealiseringsplanen Evt. justering af den oprindelige plan for arbejdet Kontekst: Udarbejdes i realiseringsfasen Forretningens ledelse er modtager og godkender rapporten Fremsendes til Statens IT-projektråd til orientering 1 år efter idriftsættelse af løsningen 3.5 73

EFFEKTMÅLING Vi måler for at: retfærdiggøre investeringen finde ud af, hvor vi skal sætte ind Selve målingen påvirker resultatet: selve planen om at måle giver bedre brug 3.5 74

KONKLUSION VEDR. INDFRIELSE AF GEVINSTER OG MÅL Ref. id fra Business Case Økonomiske gevinster Forventet måleresultat Måleresultat Tidspunkt for måling Ansvarlig for måling Det samme udfyldes for kvalitative gevinster. For begge skemaer skal afvigelser forklares. 3.5 75 75

DET ER SVÆRT AT HØSTE GEVINSTERNE! Nemmest at realisere Bedre datakvalitet Overholde lovkrav og interne krav til fx dokumentation og sikkerhed Ændret arbejdsdeling Større fleksibilitet i forhold til tilrettelæggelsen af arbejdet arbejde uafhængig af tid og sted Sparede driftsomkostninger Sværere at realisere Effektivisering af arbejdsgange (ofte kvalitet frem for effektivitet) Understøtte beslutningsgange Styring og ledelsesinformation Bredere videndeling Konsekvent og ensartet anvendelse (pisk og gulerod) 3.5 76

TYPISKE UDFORDRINGER Svært at fastholde interessen for realiseringen af gevinster i forretningen Nye projekter starter Som tiden går, bliver det mere mudret at følge, om realisering af gevinster (eller mangel på samme) skyldes projektet eller udefrakommende faktorer Særligt hvis det ikke ser ud til, at gevinsterne realiseres, vil tiden gå med bortforklaringer Erfaringen viser, at kun hvis organisationen budgetmæssigt på topledelsesniveau holdes op på gevinstrealisering, er der et stærkt nok incitament til at sikre, at det sker. 3.5 77

TYPISKE UDFORDRINGER Mellemlederne er ofte dem, der ender i en klemt situation De bliver skåret i budgetter eller afkræves bedre/højere målopfyldelse. Hvis de ikke har været aktivt involveret i projektet, kender de ofte ikke nok til business casen til at kunne se sammenhæng mellem projekt og gevinstrealisering. Brugerne vil ofte begrunde manglende gevinster med alt det der blev skåret væk i projektet. Ofte har de ret, f.eks. skæres rapportering desværre ofte ud af (eller ned i) scope for at nå projektet til tiden 3.5 78

PROCESOVERBLIK IT-PROJEKTRÅD OG FiU: PROCES OG LEVERANCER 1.12 79

FORMÅL OG KONTEKST Ønske om bedre styring af statslige it-projekter Nye forelæggelsesregler for it-projekter (BV2011) Statens IT-projektråd skal risikovurdere alle større it-projekter ( 10 mio. kr.) Forelæggelse for FiU mhp. tilslutning til igangsættelse af it-projekt ( 60 mio. kr.) 2 forelæggelsesgrænser og dermed forskellige processer og leverancer for it-projekterne 10 mio. < 60 mio. kr. 60 mio. kr. Forelæggelsesregler omhandler tilslutning til igangsættelse af it-projekt under forudsætning af bevillingsmæssig hjemmel i øvrigt. Altid forelæggelse for FiU, hvis projektet kræver merbevilling, dvs. ikke kan afholdes inden for egen ramme. 1.12 80

FLOWDIAGRAM FOR IT-PROJEKTER 10 MIO. KR. Flowdiagram for statslige it-projekter 10 mio. Kr. FIU Aktstykke forelægges inden udbud m.h.p. tilslutning - Projekter 60.mio. kr. Orientering om gennemført udbud - Projekter 60.mio. kr. Orientering om projektafslutning og overgang til drift - Projekter 60.mio. kr. Orientering om realiserede gevinster - Projekter 60.mio. kr. It-projektrådet Sekretariat for It-projektråd Projekt/ forretningen Behandling af projekt: Anbefaling om risikohåndtering eller anbefaling om eksternt review (v. høj risiko) Riskoscore, PID og BC modtages og risikovurdering udarbejdes Ledelsesprodukter udarbejdes (BC, PID, Risikoscore m.fl) Høj risiko Risikovurdering modtages Risikohåndtering revideres? Review gennemføres? Ved review Plan for håndtering af review anbefalinger udarbejdes Halvårlige status modtages Halvårlige status udarbejdes Halvårlige status modtages Halvårlige status udarbejdes Halvårlige status modtages Halvårlige status udarbejdes Projektafslutningsrapport og gevinstrealiserings -plan modtages til orientering Projektafslutningsrapport og gevinstrealiserings plan udarbejdes Gevinstrealiseringsrapport modtages til orientering (1 år efter projektafslutning) Gevinstrealiseringsrapport udarbejdes Analysefase Specificering Udbud Gennemførelse Realisering 1.12 81

PROCES OG LEVERANCER DEL 1 1.12 82

RISIKOVURDERING AF ALLE IT-PROJEKTER 10 MIO. KR. Flowdiagram for statslige it-projekter 10 mio. Kr. Den projektejende institution indsender følgende til IT-projektrådets sekretariat: Risikoscore FIU for u Pro Business case (ledelsesresumé, hoveddokument samt regneark) Projektinitieringsdokument (PID), herunder gevinstrealiseringsplan, risikoanalyse og kvalitetsplan 10 arbejdsdages sagsbehandlingstid til risikovurdering herefter svar fra sekretariat om vurderingen af projektets risiko som normal/høj inkl. samlet begrundelse. Ved normal risiko fortsætter projektet. Ved høj risiko får projektet anbefalinger om risikohåndtering fra Rådet, som også kan anbefale et eksternt review. Efter review udarbejdes handlingsplan for håndtering af review-anbefalinger. It-projektrådet Sekretariat for It-projektråd Projekt/ forretningen Behandling af projekt: Anbefaling om risikohåndtering eller anbefaling om eksternt review (v. høj risiko) Riskoscore, PID og BC modtages og risikovurdering udarbejdes Ledelsesprodukter udarbejdes (BC, PID, Risikoscore m.fl) Høj risiko Risikovurdering modtages Risikohåndtering revideres? Review gennemføres? Analysefase Ved review Plan for håndtering af review anbefalinger udarbejdes u S 1.12 83

OM RISIKOVURDERING AF ALLE IT-PROJEKTER 10 MIO. KR. Formål Risikovurdering skal sikre, at projektejerne får håndteret og minimeret afgørende risici, før de indgår kontrakter og anskaffer systemer. Risikovurderingen kan også være en hjælpende hånd til projektlederen mulighed for at fremhæve og løfte kendte udfordringer/risici. Timing Risikovurdering skal senest ske ved afslutning af projektets analysefase og inden anskaffelsesfasen. Ansvar Det er de enkelte ministeriers ansvar at indmelde projekterne. Ansvarligt direktionsmedlem er afsender projektleder vil ofte være den udførende. 1.12 84

VIGTIG AT VIDE FOR IT-PROJEKTER 60 MIO. KR. Altid vurderet som et højrisikoprojekt. Aktstykker for it-projekter 60 mio. kr. skal forelægges FiU efter IT-projektrådet, men inden udbud offentliggøres. IT-projektråds risikovurdering tages med i betragtning i FiU s behandling af aktstykker. Forventning om mere gennemarbejdede aktstykker og bedre estimater. Aktstykkeskabelon for it-projekter 60 mio. kr., dvs. fast format for aktstykker til FiU. Tidlig kontakt til Finansministeriet anbefales, idet BC indgår i ITprojektrådets risikovurdering af itprojekterne. Flowdiagram for statslige it-projekter 10 mio. Kr. FIU It-projektrådet Sekretariat for It-projektråd Projekt/ forretningen Behandling af projekt: Anbefaling om risikohåndtering eller anbefaling om eksternt review (v. høj risiko) Riskoscore, PID og BC modtages og risikovurdering udarbejdes Ledelsesprodukter udarbejdes (BC, PID, Risikoscore m.fl) Høj risiko Risikovurdering modtages Risikohåndtering revideres? Review gennemføres? Analysefase Ved review Plan for håndtering af review anbefalinger udarbejdes Aktstykke forelægges inden udbud m.h.p. tilslutning - Projekter 60.mio. kr. Halvårlige status modtages Halvårlige status udarbejdes Specificering Halvårlige status modtages Halvårlige status udarbejde Udbud 1.12 85

PROCES OG LEVERANCER DEL 2 1.12 86

PROCES OG LEVERANCER IFT. FiU ( 60 mio. kr.) Flowdiagram for statslige it-projekter 10 mio. Kr. Forelæggelse for FiU, inden udbud offentliggøres. Tidsplan for orienteringer fastlægges. Orientering om resultatet af det gennemførte udbud. Væsentlige ændringer undervejs Høj i risiko gennemførselsfasen forelægges Riskoscore, PID og BC modtages og risikovurdering Finansudvalget. udarbejdes Budgetoverskridelser 10% og Risikovurdering 6 mio. Ledelsesprodukter modtages kr., større funktionalitetsændringer, m.m. udarbejdes (BC, Risikohåndtering Orientering om overgangen til drift. FIU It-projektrådet Sekretariat for It-projektråd Projekt/ forretningen Behandling af projekt: Anbefaling om risikohåndtering eller anbefaling om eksternt review (v. høj risiko) PID, Risikoscore m.fl) revideres? Review gennemføres? Ved review Plan for håndtering af review anbefalinger udarbejdes Aktstykke forelægges inden udbud m.h.p. tilslutning - Projekter 60.mio. kr. Halvårlige status modtages Halvårlige status udarbejdes Halvårlige status modtages Halvårlige status udarbejdes Orientering om gennemført udbud - Projekter 60.mio. kr. Halvårlige status modtages Halvårlige status udarbejdes Orientering om projektafslutning og overgang til drift - Projekter 60.mio. kr. Projektafslutningsrapport og gevinstrealiserings -plan modtages til orientering Projektafslutningsrapport og gevinstrealiserings plan udarbejdes Orientering om realiserede gevinster - Projekter 60.mio. kr. Gevinstrealiseringsrapport modtages til orientering (1 år efter projektafslutning) Gevinstrealiseringsrapport udarbejdes Orientering om projektets effekter ca. 1 år efter overgangen til drift. Analysefase Specificering Udbud Gennemførelse Realisering 1.12 87

PROCES OG LEVERANCER IFT. IT-PROKJEKTRÅD (IT-PROJEKTER 10 MIO. KR.) Status Statusrapportering hvert halve år (2. og 4. kvartal) (forelægges ØU) Afslutning m for statslige it-projekter 10 mio. Kr. Projektafslutningsrapport og gevinstrealiseringsplan sendes til orientering Gevinstrealiseringsrapport sendes til orientering 1 år efter overgang til drift Aktstykke forelægges inden udbud m.h.p. tilslutning - Projekter 60.mio. kr. Orientering om gennemført udbud - Projekter 60.mio. kr. Orientering om projektafslutning og overgang til drift - Projekter 60.mio. kr. Orientering om realiserede gevinster - Projekter 60.mio. kr. ndling af projekt: nbefaling om sikohåndtering r anbefaling om rnt review (v. høj risiko) Høj risiko skoscore, PID BC modtages risikovurdering udarbejdes Halvårlige status modtages Halvårlige status modtages Halvårlige status modtages Projektafslutningsrapport og gevinstrealiserings -plan modtages til orientering Gevinstrealiseringsrapport modtages til orientering (1 år efter projektafslutning) Ved review elsesprodukter arbejdes (BC,, Risikoscore m.fl) Risikovurdering modtages Risikohåndtering revideres? Review gennemføres? Plan for håndtering af review anbefalinger udarbejdes Halvårlige status udarbejdes Halvårlige status udarbejdes Halvårlige status udarbejdes Projektafslutningsrapport og gevinstrealiserings plan udarbejdes Gevinstrealiseringsrapport udarbejdes Analysefase Specificering Udbud Gennemførelse Realisering 1.12 88

ALT KAN FINDES På www.ministeriernesprojektkontor.dk 1.5 90