vejledning til den fællesstatslige programmodel€¦translate this page2015/12/20 · microsoft...

Den fællesstatslige programmodel Vejledning til den fællesstatslige programmodel Side 1

Vejledning til den fællesstatslige programmodel

December 2015

Den fællesstatslige programmodel er med Budgetvejledning 2016 frivillig at bruge for statslige myndigheder.

Opdelingen i frivillige og obligatoriske faser, ledelsesprodukter, governance-fora og roller, er derfor kun relevant, hvis programmet ønsker at blive risi-kovurderet hos It-projektrådet som samlet program.

Indhold

1. LÆSEVEJLEDNING ........................................................................ 4

2. ANVENDELSE AF PROGRAMMODELLEN ............................................. 7

3. PROGRAMMODELLENS BEGREBER .................................................. 9

4. DEN FÆLLESSTATSLIGE PROGRAMMODEL ...................................... 10

5. PROGRAMMODELLENS FASER ...................................................... 20

6. PROGRAMLEDELSESPRODUKTER .................................................. 33

7. SAMMENHÆNG TIL DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL .......... 40

8. YDERLIGERE VEJLEDNING OG STØTTE ........................................... 43

9. BILAG ....................................................................................... 44

Den fællesstatslige programmodel version 1.3

Vejledning til den fællesstatslige programmodel Side 4

1. Læsevejledning Vejledningen beskriver den fællesstatslige programmodel. Den henvender sig til alle, der er i gang med eller står over for at igangsætte statslige programmer.

Hvem henvender vejledningen sig til?

Vejledningen henvender sig til ministerier eller myndigheder, der ønsker at gennemfø-re programmer enten inden for eget område, i et samspil med andre ministerområder og/eller i et samspil med kommuner og regioner.

Hvad er rammerne og formålet med vejledningen?

Den fællesstatslige programmodel er jf. Budgetvejledning 2016 frivillig at anvende for statslige myndigheder. Et program kan, såfremt det indeholder en væsentlig andel af it og har et programbudget over 60 mio. kr., vælge at blive risikovurderet hos It-projektrådet som program. I dette tilfælde skal modellens obligatoriske faser og ledel-sesprodukter følges.

Nærværende vejledning sætter rammerne for den fællesstatslige programmodel, her-under:

− Beskrive obligatoriske faser og gates samt obligatoriske ledelsesprodukter (for programmer, der forelægges It-projektrådet til risikovurdering)

− Give anbefalinger til øvrige ledelsesprodukter − Definere god praksis for programledelse og programstyring

Vejledningen tager udgangspunkt i god praksis fra HM Government modellen ”Mana-ging Successful Programmes1” (herefter refereret til som MSP) samt Ministeriernes projektkontors erfaringer med vejledning af programmer og vejledning til den fælles-statslige it-projektmodel.

Hvad er baggrunden og forudsætningerne for vejledningen?

Der er en stigende tendens til at organisere projekter i programmer i statslige institu-tioner. Dette er en ny faglig udfordring for størstedelen af de statslige institutioner. Dette mærkes særligt i It-projektrådet, som nu præsenteres for projekter som en del af større programmer.

Derfor er der udarbejdet en fællesstatslig programmodel, og denne vejledning intro-ducerer modellen og dens elementer.

Det er en forudsætning for læsning og forståelse af vejledningen til den fællesstatslige programmodel, at læseren har et godt kendskab til programbegrebet. Endvidere tager vejledningen udgangspunkt i, at læseren står over for at skulle igangsætte et program og ønsker eller skal anvende den fællesstatslige programmodel.

1 HM Government, The Cabinet Office: Managing Successful Programmes, 2011 edition



For uddybende introduktion til programmer og programledelse og guide for valg af program, ift. projekt og portefølje, henvises til vejledningen ”Introduktion til pro-grammer”.

Hvad indeholder vejledningen?

Vejledningen omfatter:

− Beskrivelse af forandringsforløbet (transformational flow) og dets faser − Overblik over obligatoriske og valgfrie programledelsesprodukter – hvor skel-

nen mellem obligatoriske og valgfrie produkter kun gør sig gældende, såfremt programmet skal risikovurderes hos It-projektrådet

− Introduktion til programgovernance og programprincipper − Information om, hvor ministerierne kan finde yderligere vejledning og støtte

Hvilken sammenhæng indgår dokumentet i?

Vejledningen til programmodellen er central for at sikre en god overordnet forståelse for, hvad der kræves for at gennemføre et program.

Vejledningen kan dog ikke stå alene, og derfor anbefales det også at orientere sig i følgende dokumenter:

− Introduktion til programmer – definition af centrale begreber samt guidelines for valg af program frem for projekt

− Vejledning om god programledelse i staten – principper og temaer − Vejledning om programgovernance – som beskriver obligatoriske (i det tilfæl-

de, programmet skal risikovurderes hos It-projektrådet) og valgfri fora samt disses roller og ansvar

− Vejledning til rollebeskrivelser i programmodellen – som beskriver alle centrale roller i programmer

− Startpakke til programledelsen – som giver programledelsen et overblik over opgaverne i identifikationsfasen (den første fase i programmodellen) og et for-slag til en operationel gennemførelse af disse

− Skabeloner og vejledninger til brug af skabeloner for obligatoriske produkter

Derudover er der udarbejdet ”Ledelsesintroduktion til programmodellen”, som giver en kort introduktion til programmodellens indhold.

Forslag til læsning af vejledningen

Vejledningen til programmodellen giver anledning til mange overvejelser, man bør gøre sig i forbindelse med etablering og eksekvering af et program. Afhængigt af læ-serens rolle i et program samt forudgående viden om programmer og programstyring, vil der være forskellige behov for fordybelse i vejledningens kapitler. Derfor er neden-for angivet et forslag til, hvordan læsningen kan gribes an.

God læselyst.



Hvis du…..

Kap

. 2

Anv

ende

lse

af p

ro-

gram

mod

elle

n K

ap.

3 P

rogr

amm

odel

lens

be

greb

er

Kap

. 4

Den

fæ

lless

tats

lige

prog

ram

mod

el

Kap

. 5

Pro

gram

mod

elle

ns

fase

r K

ap.

6 P

rogr

amle

dels

es-

prod

ukte

r K

ap.

7 S

amm

enhæ

ng t

. it-

proj

ektm

odel

len

Kap

. 8

Yde

rlig

ere

vejle

d-ni

ng o

g st

øtte

Kommentarer

Er en del af programbe-styrelsen

Læs produktet ”Ledelsesintro-duktion til programmodellen” i stedet for. Kan dog anvende nærværende vejledning til op-slag.

Er Program-ejer eller del af program-styregruppe

X

X

Få kendskab til rammen og fa-serne, som styregruppen lø-bende skal lede og styre efter

Er programle-der og kender til MSP X

X X X X

Kun afsnittet om obligatoriske krav i kap 2 er nødvendigt at læse. Brug kapitel 5 og 6 til opslag, når relevant

Er programle-der med be-grænset pro-gramerfaring

X X X X X X X

Læs 2,3,4,7 og 8. Brug kapitel 7 og 8 til opslag, når relevant. Læs derudover de særskilte vejledninger til ledelsesproduk-terne.

Er program-medarbejder X X Lær begreberne og få et over-

blik over modellen

Er projektle-der i et pro-gram

X X X Få et overblik over program-modellen og læs om særlige krav til projekter i et program

Er nysgerrig på, hvad pro-grammer og programmo-dellen er

X

Læs først ”Introduktion til pro-grammer” (separat vejledning) og derefter kapitel 4



2. Anvendelse af programmo-dellen

I dette kapitel gøres rede for kravene til anvendelse af den fællestatslige programmo-del samt overvejelser i forbindelse med beslutning om at gennemføre programmer.

Det er op til myndighederne at beslutte, om en forandring skal eksekveres som et program eller som selvstændige projekter. Der er en række fordele ved at vælge pro-gram frem for projekter, men det stiller store krav til ledelsen og styringen.

Valget af hhv. program og projekt afføder forskellige styringsmæssige krav. Disse krav er samlet i hhv. den fællesstatslige programmodel og den fællesstatslige it-projektmodel. Hvis myndigheden vælger at gennemføre forandringer som et program, er programmet omfattet af nedenstående krav om anvendelse af programmodellen og risikovurdering i It-projektrådet.

2.1 Krav til anvendelse af programmodellen I medfør af Finansministeriets Budgetvejledning 2016 kan programmer risikovurderes i It-projektrådet. Såfremt et program vælger at blive risikovurderet hos It-projektrådet skal den fællesstatslige programmodel skal anvendes, såfremt et pro-grams udgifter overstiger 60 mio. kr., og it udgør en væsentlig del af programmet.

Opgørelse af programmets udgifter ift. grænsen på de 60 mio. kr. er den samme som for den fællesstatslige it-projektmodel (i øvrigt henvises til Budgetvejledning 2016).

I overensstemmelse med den eksisterende praksis for projekter, foretager It-projektrådet vurderingen af graden af it i programmet i det konkrete tilfælde sammen med den enkelte myndighed og beslutter på denne baggrund, om programmet er om-fattet af reglerne for risikovurdering i rådet.

Programmer skal overholde følgende obliga-toriske krav, såfremt det skal risikovurderes hos It-projektrådet:

− Programmet skal følge opdelingen af forandringsforløbet i de 4 hovedfaser og supplering af fasen ”Ledelse af programbølger” med to yderligere fa-ser

− Programmet skal udarbejde obligato-riske programledelsesprodukter og anvende obligatoriske skabeloner – det konkrete indhold fastlægges i dia-log med Ministeriernes projektkontor

− Programmet skal etablere obligatori-ske governancefora (Se vejledning om programgovernance)

For programmer med…

− udgifter over 60 mio. kr., hvor it udgør en væsentlig del af pro-grammet

…er det obligatorisk, hvis man ønsker at blive risikovurderet hos It-projektrådet, at:

− Følge faseopdelingen − Udarbejde obligatoriske ledelses-

produkter − Etablere obligatoriske governan-

cefora − Gennemgå risikovurdering i Sta-

tens It-projektråd − Indsende statusrapportering − Gennemgå yderligere risikovur-

dering og/eller objektivt review, såfremt Statens It-projektråd finder det nødvendigt



− Programmet skal gennemgå risikovurdering i It-projektrådet og indsende en række obligatoriske programdokumenter samt udvalgte projektdokumenter, der fastlægges i dialog med Ministeriernes projektkontor

− Programmet skal halvårligt indsende statusrapporter til It-projektrådet − På baggrund af statusrapporteringen kan It-projektrådet beslutte at gennemfø-

re en fornyet risikovurdering og/eller anbefale, at programmet gennemfører et eksternt programreview.

2.2 Programmer og programledelse Det kan være en god ide at samle og eksekvere projekter i et program, hvis:

− Organisationen (-erne) står foran en større strategisk forandring og denne for-andring kræver eksekvering af en række projekter

− Projekterne har indbyrdes stærke afhængigheder − Den samlede gevinstrealisering ved eksekvering af projekterne er større end

eksekveringen af projekterne hver for sig, fordi der opnås synergi eller fordi det undgås, at man tæller de samme gevinster med i flere projekter (dobbelt-counting).

Programledelse skal sikre såvel ledelse som styring af programmet. Erfaringen viser, at uden en stærk og velfungerende programledelse, er sandsynligheden for succes med et program meget ringe. Programledelse handler om at mestre en lang række discipliner. Programledelsen skal kunne:

− Skabe en overbevisende vision for den forandring, programmet skal realisere – og evne at kommunikere denne til alle relevante interessenter

− Uddelegere beslutninger og ledel-seskraft gennem ledelse og motiva-tion af andre

− Sikre sammenhængende planlæg-ning, koordination, eksekvering og fremdrift af de projekter, der indgår i bølgerne - under hensyntagen til den daglige drift

− Engagere og agere med autoritet i ledelsesstilen for at kunne sikre al-lokering af de rigtige ressourcer til programmet og influere og engagere inte-ressenter

− Balancere programmets prioriteringer ift. den løbende drift i organisationen − Fokusere på realiseringen af forretningsgevinster − Identificere og imødegå væsentlige risici for realiseringen af gevinster

Den fællesstatslige programmodel indeholder elementer, som understøtter programle-delsen i alle ovenstående discipliner.

Programledelse

− Skabe og kommunikere vi-sion

− Uddelegere ledelseskraft − Sikre koordination & frem-

drift − Udvise engagement & au-

toritet − Balancere prioritering − Fokusere på gevinster − Imødegå risici



3. Programmodellens begreber I dette kapitel defineres programbegrebet og en række centrale begreber i den fælles-statslige programmodel introduceres.

Program: Et program er en midlertidig fleksibel organisationsstruktur, der er oprettet for at koordinere, styre og overvåge gennemførelsen af en gruppe gensidigt afhængi-ge projekter og aktiviteter for at levere en samlet business case i form af resultater og gevinster, der understøtter samme vision.

For at kunne forstå den fællesstatslige programmodel er det væsentligt at kende til en række centrale begreber.

Centrale begreber i den fællesstatslige programmodel

Begreb Forklaring

Vision

Visionen skal udtrykke den ønskede og realiserbare fremtid, som bliver resultatet af at gennemføre programmet.

Fremtidsmodel En fremtidsmodel operationaliserer visionen og viser målet med programmet i form af nye processer, ny organisering, nye teknologier, ny information og ny kultur. Ikke alle af disse elementer vil nødvendigvis være ændret. Fremtidsmo-dellen indeholder både beskrivelse af før- og efterbilledet, så det er enkelt at se forskellen og dermed den forandring som myndigheden skal gennemføre.

Forandringsevne Forandringsevnen er effekten af projekternes leverancer. Forandringsevnen kan beskrives som summen af projektle-verancer herunder gennemførte organisatoriske foran-dringsinitiativer, der tilsammen kan skabe de forventede resultater.

Bølger En bølge er defineret som en mængde af projekter, som tilsammen leverer forandring af en organisation. Dvs. at en organisation realiserer gevinster som en del af hver bølge (der kan dog være undtagelser fra dette, idet en indledende bølge kan anvendes til at afklare analytiske usikkerheder).

Governance Samling af funktioner, roller, ansvar, processer og procedu-rer, der tilsammen definerer, hvordan et program er organi-seret, ledet og styret.

Gevinstrealisering (i.f.t. foran-dringsevne)

En målbar forbedring af den måde, en organisation drives på, som resultat af programmet. Gevinstrealiseringen kan finde sted, når forandringsevnen er opnået. Planlægning og opfølgning på gevinstrealisering er en del af programmodel-len og dermed en del af programmets ansvar.



4. Den fællesstatslige program-model

Nedenfor præsenteres den fællesstatslige programmodel, herunder krav til faser, le-delsesprodukter, programtemaer og principper

4.1 Den samlede programmodel Den fællesstatslige programmodel (Figur 1) består af 4 niveauer:

1. En fasemodel, som har fire overordnede programfaser herunder ”ledelse af pro-grambølger” som er den fase, hvor de enkelte projekter gennemføres i en eller flere programbølger. Hver programbølge har til formål at levere en forandring, dvs. at brin-ge organisationen op på et mere attraktivt niveau end før gennemførelsen af bølgen og derigennem realisere gevinster.

Til eksempel kan et program være opdelt i tre programbølger: Bølge 1 består af tre projekter, som flytter to fusionerede styrelser sammen til en ny lokation og giver alle it-adgang; Bølge 2 består af to projekter, som opgraderer ESDH-systemet og sikrer organisatorisk implementering. Bølge 3 (afsluttende bølge) består af to projekter, som etablerer en selvbetjeningsløsning til borgerne samtidigt med, at styrelsens processer redesignes.

2. En række obligatoriske og valgfrie ledelsesprodukter, som understøtter fasemodel-len. 3. Ni programtemaer, som er gennemgående for alle faser i programmet, og som der-for ligger som en overbygning til fasemodellen. 4. Syv grundlæggende principper for god programledelse, som sætter rammerne for programledelse. I de underliggende afsnit gennemgås fasemodellen, ledelsesprodukterne og program-temaerne.

Figur 1 Den fællesstatslige programmodel

Hertil kommer It-projektrådets risikovurdering, som baserer sig på risikotjeklisten samt flere af de obligatoriske ledelsesprodukter for såvel programmet som projektet.



4.2 Fasemodellen for programmer De obligatoriske programfaser er følgende:

− Identificering af program: Programejer, –styregruppe og –leder udpeges. Herefter de-fineres programmet og forventede fordele, omkostninger, tidsramme og risiko identifice-res. Dokumentationen samles i program-grundlaget. Programmets præciseringsfase forberedes i en detaljeret plan for fasen.

− Præcisering af program: Detaljeret definition af programmets vision og fremtidsmodel samt planlægning af programmets ledelse, styring og eksekve-ring, herunder realisering af programmet i et antal bølger. Business casen og gevinstrealiseringsplanen udarbejdes, og programmet risikovurderes eventuelt i It-projektrådet. Dokumentationen samles i programpræciseringsdokumentet (PDD), og den første bølge forberedes.

− Ledelse af programbølger: Programmet eksekveres, og det sikres, at leve-rancerne er i overensstemmelse med den strategiske retning og møder succes-kriterierne. I denne fase (som løber frem til alle programbølger er gennemført) startes, eksekveres og lukkes programbølgerne med de underliggende projek-ter. I forbindelse med opstarten af hver programbølge skal der ske en detalje-ret planlægning af den enkelte programbølge. Efter hver bølge evalueres pro-cessen og resultatet, og læringen opsamles og anvendes i forberedelsen af næ-ste bølge.

− Levering af forandringsevne: Koordinering og styring af hvert projekts leve-rancer ift. bølgeplanen.

− Realisering af gevinster: Planlægning og gennemførelse af transition til drift. Styring af gevinsterne fra identificeringen til succesfuld realisering. Gentages ved hver bølge i programmet. Programmet kan principielt set ikke afsluttes, før alle gevinster er realiseret.

− Lukning af program: Vil sikre at programmets resultater formelt anerkendes, og at programmet afsluttes. Her lukkes og reviewes det samlede program efter endt gevinstrealisering.



4.3 Formål og resultat af hver fase Nedenfor kan ses en oversigt over formål og resultat af hver fase i den fællesstatslige programmodel.

Se kapitel 4 for en detaljeret gennemgang af hver af faserne i programmodellen.

4.4 Bemanding af roller ift. programmets faser Nedenfor vises en oversigt over, hvilke roller der hhv. skal og bør/kan bemandes i hver fase. Rollerne er nærmere beskrevet i vejledning til programgovernance og i rol-lebeskrivelsesdokumentet.



4.5 Programledelsesprodukter Programmodellen omfatter en række obligatoriske og valgfrie ledelsesprodukter.

Udvalgte obligatoriske ledelsesprodukter skal medsendes til It-projektrådet ved risiko-vurdering – og det er obligatorisk at anvende de etablerede skabeloner.

De valgfrie ledelsesprodukter anbefales anvendt – men såvel anvendelse som skabe-loner er frivillige.

Alle obligatoriske ledelsesprodukter skal godkendes af programstyregruppen. Alle obli-gatoriske ledelsesprodukter beskrives nedenfor mht. formål og kort om indholdet. En mere detaljeret beskrivelse af produkterne (kan anvendes til opslag) findes i kapitel 6. Desuden findes der en skabelon og en vejledning til en lang række af ledelsesprodukterne.

1. Programgrundlag Formål: Beskriver programmets mål og formål og benyttes til at vurdere, om programmet er realistisk, og om mål-sætningen er realistisk. Programgrund-laget udbygges i præciseringsfasen til programpræciseringsdokument (PPD). Indhold: Programgrundlaget er det før-ste ledelsesprodukt, som beskriver de samlede rammer for programmet inkl. første overslag på gevinster og omkost-ninger, en foreløbig visionsbeskrivelse

Obligatoriske ledelsesprodukter

− Programgrundlag − Programpræciseringsdokument − Vision − Fremtidsmodel − Gevinstdiagram med profiler − Business case − Risikoregister − Projektkatalog − Programplan − Bølgeplan − Programstrategier − Implementeringsstrategi − Udbudsstrategi − Gevinstrealiseringsplan − Gevinstrealiseringsrapport − Programevalueringsrapport



og en vurdering af, hvilke bølger og hvilke projekter, der skal til for at realisere visionen.

2. Programpræciseringsdokument (PPD)

Formål: At give ledelsen et mere præcist billede af programmet i forhold til det programgrundlag, som ledelsen brugte i fasen identificering af program til at vurdere, om programmet er ønskeligt og opnåeligt. Programpræciseringsdo-kumentet fungerer som kontrakten mellem programstyregruppen og program-lederen. Indhold: PPD’en er en udbygning af programgrundlaget men er mere præcist. PPD’en er paraplydokument for en lang række af de øvrige ledelsesprodukter, ligesom PID’en er det for et projekt. PPD’en omfatter således elementer fra vi-sionen, fremtidsmodellen, programplan, gevinstdiagram, business case, pro-jektkatalog og risikoregister.

3. Vision Formål: At kommunikere programmets overordnede formål.

Indhold: Visionen udtrykker i en kort sætning programmets målbille-de/målsætning. Visionen skal være så attraktiv og fleksibel, at den kan benyt-tes til at kommunikere med alle interessenter gennem hele programmets leve-tid.

4. Fremtidsmodel Formål: En fremtidsmodel operationaliserer visionen og viser målet med pro-grammet i form af nye processer, ny organisering, nye teknologier, ny informa-tion og ny kultur. Ikke alle elementer vil nødvendigvis være ændret. Indhold: Fremtidsmodellen indeholder både beskrivelse af før- og efterbilledet, både hvad angår processer, organisering, teknologi, information og kultur, så det er enkelt at se, hvad det er for en forandring, der skal gennemføres.

5. Gevinstdiagram med gevinstprofiler Formål: At illustrere (på en overskuelig facon) sammenhængen fra program-mets leverancer til de realiserede gevinster og disses effekt (gevinstdiagram) samt sikre detaljeret forståelse af hver af gevinsterne i business casen (ge-vinstprofiler).

Indhold: Gevinstdiagrammet er en tegning af årsag-virkningssammenhænge og viser leverancerne, den forandringsevne de skaber, de gevinster der dermed kan opnås og de effekter, gevinstrealiseringen samlet set vil have på organisa-tionen og dens omgivelser. Gevinstprofiler indeholder en detaljeret beskrivelse af gevinsten, dens ejer(e), bl.a. link til programmål, gevinstkategori, leveran-cer og forretningsmæssige ændringer, som er nødvendige for at realisere ge-vinsten, risici og afhængigheder.

6. Business Case Formål: Business casen benyttes til fortløbende validering af programmets be-rettigelse. Indhold: Business casen udarbejdes for det samlede program og indeholder al-le udviklingsudgifter på projekt og programniveau samt alle driftsmæssige ge-vinster, som det samlede program realiserer. Udgifter summeres på baggrund af opgørelse af udgifter for hvert projekt og udgifter for programniveauet. Ge-vinster opgøres kun på programniveau som forskellen mellem driftsudgifter i



den nuværende situation og driftsudgifter efter gennemførelse af programmet. Endvidere kobles risici og risikoniveau til de enkelte udgifter.

7. Risikoregister program Formål: Risikoregisteret har til formål at identificere, dokumentere og aktivt styre de risici, der påvirker eller potentielt kan påvirke programmet. Indhold: Indeholder beskrivelse af hver risiko, sandsynlighed og konsekvens samt oplæg til afbødende handlinger.

8. Projektkatalog Formål: At skabe oversigt over de projekter, der er nødvendige for at kunne opfylde og levere fremtidsmodellen.

Indhold: Projektkataloget indeholder overordnede beskrivelser af projekterne og afhængighederne mellem disse samt viser opdelingen i de forskellige pro-grambølger.

9. Programplan

Formål: Formålet med programplanen er (ligesom med projektplanen i et pro-jekt) at skabe en sammenhængende plan, der kan anvendes til at skabe over-blik over, hvornår hvilke aktiviteter skal igangsættes, hvilke afhængigheder der findes i programmet/projekterne samt ressourcetrækket.

Programplanen er det styringsmæssige grundlag for, at programmet løbende kan styre og følge op på programmets fremdrift i forhold til de planlagte pro-gram- og projektleverancer. Samtidig skal programplanen sikre, at program-met kan følge op på risici, hændelser og kvalitet samt interne projektaf-hængigheder i programmet.

Indhold: Programplanen viser et overblik over programmets samlede leveran-cer fordelt på de enkelte programbølger samt sammenhængen (afhængighe-der) mellem projektleverancer og den kritiske vej (hvornår hvilke leverancer, resultater og gevinster skal være leveret, for at der ikke opstår kritiske forsin-kelser).

Programplanen samler alle væsentlige oplysninger om programmets samlede plangrundlag. Det gælder projektplaner for programmets projekter, program-mets kvalitetsplan, risikoplan, kommunikationsplan, mobiliseringsplan og im-plementeringsplan.

10. Bølgeplan Formål: Ved indgangen til hver ny bølge skal der foreligge en detaljeret plan for bølgen. Planen kan ses som en ”slags PID” for bølgen, hvis væsentligste formål er at dokumentere en sammenhængende plan for gennemførelse af bøl-gen.

Indhold: Det væsentligste indhold er en samlet tids-, aktivitets- og ressource-plan for bølgen. Derudover beskrives også, hvilke gevinster, der skal være rea-liseret, for at bølgen kan afsluttes succesfuldt. Planen vil i praksis typisk bestå af flere forskellige produkter som fx en aktivitets og tidsplan i Microsoft Project, en leveranceliste i Excel og en gevinstbeskrivelse.



11. Programstrategier

Formål: At sætte rammerne for styring og ledelse i programmet. Indhold: Beskrivelse af strategier for håndtering af udbud, implementering, in-teressenthåndtering, kvalitet, gevinster, risici og afhængigheder. Strategierne sætter rammerne ved bl.a. at beskrive processer samt roller og ansvar for hvert element i strategien.

12.Implementeringsstrategi Formål: Formålet med implementeringsstrategien er at sikre, at programmet har taget stilling til, hvordan forandringsledelse og transitionen fra program til drift håndteres i programmet og dets projekter samt i organisationen som hel-hed. Indhold: Implementeringsstrategien er et ledelses- og styringsdokument, der indeholder overvejelser og begrundelser for valg af den overordnede måde im-plementering gribes an på. Det handler om forandringsledelse og transition fra program til drift.

13. Udbudsstrategi Formål: Formålet med udbudsstrategien er at sikre, at programmet har taget stilling til, hvordan programmet mest optimalt tilrettelægger de udbud, der skal gennemføres i programmet med henblik på at optimere programmets business case og tidsplan. Indhold: Udbudsstrategien er et ledelses- og styringsdokument, der omfatter en lang række beslutninger om valg af tilgang til at gennemføre udbud, herun-der begrundelser og eventuelle understøttende analyser.

14. Gevinstrealiseringsplan Formål: Formålet med gevinstrealiseringsplanen er at udarbejde en plan for, hvornår og hvordan gevinsterne i business casen realiseres.

Indhold: Beskriver og konkretiserer hver af gevinsterne i business casen for programmet og angiver, hvornår og hvor gevinsterne realiseres, hvem der rea-liserer dem, og hvordan realiseringen skal måles. Planen udarbejdes i fasen præcisering af program og detaljeres ved igangsætning til hver bølge, således at det er tydeligt, hvilke gevinster der realiseres som følge af bølgen.

15. Gevinstrealiseringsrapport Formål: At følge op på og dokumentere de høstede gevinster for en bølge i programmet.

Indhold: Rapporten indeholder basismåling, løbende målinger og afsluttende måling af gevinstrealiseringen. Rapporten kan også anvendes til samlet afrap-portering af gevinstrealisering for det samlede program.

16. Programevalueringsrapport Formål: Programevalueringsrapporten anvendes til at opsamle erfaringer og læring fra det samlede program. Denne læring videregives til nye programmer og kan give input til vurdering af organisationens generelle governance setup.

Indhold: Rapporten indeholder erfaring og læring fra det gennemførte program, både i form af opfølgning på business casen og realiserede gevinster samt op-følgning på anvendte processer, værktøjer og governancestrukturer i pro-grammet.



I forhold til informationssikkerhed, er der krav om, at alle it-projekter skal lave vurde-ringer af informationssikkerheden, af informationsaktivet og it-løsningen i analysefa-sen. Informationsaktivet er den information (data), som skal behandles af it-løsningen, og som skal sikres. Vurderingerne laves via to produkter, en konsekvens-vurdering af privatlivet (PIA) og en sikkerhedsmæssig risikovurdering, hvoraf den ene, PIA, kan udelades såfremt it-løsningen ikke skal behandle personoplysninger. Resulta-terne dokumenteres i PID og risikoregister.

Spænder eventuelle informationssikkerhedsmæssige udfordringer over flere projekter og dermed potentielt påvirker programniveauet, skal programmet lave en samlet vur-dering, der dokumenteres i PPB og risikoregister.

I tillæg til informationssikkerhed kommer, at for at udvikle en it-løsning, som under-støtter de forvaltningsretlige krav og kravene i anden relevant lovgivning, er det afgø-rende, at man fra starten skaber sig et meget præcist overblik over de regler og pro-cesser, som et digitalt sagsbehandlingssystem skal understøtte. Det skal være klart, hvilke formelle og materielle regler, der gælder for forvaltningen ift. den pågældende løsning. Det er således et krav, at it-projekter / programmer sikrer, at systemet ud-formes, så forvaltningsretslige krav og krav i anden relevant lovgivning overholdes.

I forhold til formelle krav til sagsbehandlingen vil det eksempelvis skulle indtænkes, at reglerne om partshøring og begrundelse kan efterleves. I forhold til de materielle krav til afgørelsen vil der eksempelvis kunne være tale om, at regelgrundlaget kræ-ver, at der udøves et skøn i den enkelte sag. Hvis det er tilfældes, skal processerne indrettes sådan, at det kan efterleves.

Man skal endvidere være opmærksom på, om digitalisering af et område kræver ny lovgivning. Der kan i den forbindelse eksempelvis peges på, at det kræver ny lovgiv-ning at gøre det obligatorisk for ansøgere at kommunikere digitalt med myndigheden på et område og derved udelukke andre former for kommunikation.

Der henvises endvidere til Notat om forvaltningsretlige krav udarbejdet af Justitsmini-steriet (http://www.digst.dk/~/media/Files/Digitaliseringsstrategien/Notat-om-forvaltningsretlige-krav-til-det-offentliges-itlsninger.pdf) for en uddybning af de for-valtningsretslige krav og kravene i anden relevant lovgivning.

Skabeloner og vejledninger til en lang række af ovennævnte ledelsesprodukter kan findes på Ministeriernes projektkontors hjemmeside.

4.6 De ni programtemaer Studier af en række gennemførte programmer i England (såvel succesfulde som ikke-succesfulde prorammer) har vist, at ni temaer er afgørende for at opnå succes med et program. Det er derfor essentielt, at programledelsen i hele programmets levetid har fokus på disse 9 temaer og arbejder med disse i den daglige ledelse og styring af pro-grammet.

Nedenfor gennemgås temaerne kort.

Programorganisering Etablering af en klar organisation med effektiv governance er hjørnestenen i et suc-cesfuldt program. Den skal derfor løbende monitoreres og tilpasses programmets ak-tuelle situation. Fx kan der være behov for skift i organisering og i kompetencer mel-lem udvikling og implementering i en programbølge.



Vision Visionen er et billede på en bedre fremtid. En god og kommunikerbar vision er en for-udsætning for interessentopbakningen til programmet. Programmet skal løbende sikre kommunikation af visionen til interessenterne, for at sikre opbakning til og forankring af programmet i organisationen.

Lederskab og engagement af interessenter En forudsætning for et succesfuldt program er engagement og aktiv deltagelse fra interessenterne. Interessenterne skal opfatte gevinster som attraktive for at pro-grammet opnår succes. Dette kommer ikke af sig selv, men kræver en løbende ledel-sesmæssig indsats med information og dialog om programmets formål og resultater.

Ledelse af gevinstrealisering Ledelse af gevinstrealisering er hjertet af programledelse. Det er vigtigt at identificere såvel gevinster som ulemper oplevet af interessenterne og aktivt forfølge gevinstreali-seringen.

Design og leverance af fremtidsmodel Det er fremtidsmodellen, som operationaliserer visionen og gør det muligt at modelle-re gevinsterne og designe projektkataloget, som skal virkeliggøre visionen. Selv om fremtidsmodellen etableres tidligt i programmet i præciseringsfasen, er det nødvendigt løbende at vurdere, om den fortsat er holdbar og eventuelt justere den i takt med op-nåede resultater som følge af gennemførelse af bølger.

Planlægning og kontrol Planlægning og kontrol af det samlede program er en særlig ledelses- og styringsdi-sciplin, som kræver fokus og ressourcer i hele programmets levetid. Det indebærer bl.a. processer og procedurer ift. løbende planlægning og styring af fremdriften i pro-grammet for at sikre proaktiv håndtering af mulige afvigelser.

Business case Business casen er det fundament, hvorpå ledelsen ultimativt baserer sin beslutning om at fortsætte eller stoppe programmet. Eftersom programmet er en levende størrel-se, er business casen ikke statisk, men kræver løbende genbesøg og justering ift. ge-vinster, udgifter og risici.

Risiko- og emnehåndtering Succesfulde programmer er i stand til løbende at håndtere og tolerere usikkerhed kompleksitet og uklarhed. Dette gøres gennem risikohåndtering og emnehåndtering og indebærer bl.a. etablering af strategi og proces for det løbende arbejde med risiko-håndtering i programmet for at sikre proaktiv identifikation og håndtering af væsentli-ge risici.

Kvalitetsplanlægning og –sikring Kvalitetsplan og –sikring skal igennem hele programmet tilsikre, at programmet er på rette spor ift. opnåelse af målene i visionen. Kvalitet skal styres såvel i forhold til leve-rancer som processer og procedurer. Derfor skal der lægges planer for kvalitetsstyring og kvalitetssikring, og der skal følges op på kvaliteten af leverancerne fra hvert af pro-jekterne og følges op på kvaliteten af de processer, der udføres i programmet.

4.7 Grundlæggende ledelsesprincipper Syv ledelsesprincipper er retningsgivende for programledelsens arbejde, hvilket bety-der, at hver ledelsesrepræsentant (hvad enten der er tale om programejer, program-leder, forandringsejer eller medlem af programstyregruppen) bør arbejde ud fra disse og løbende evaluere egen indsats og ledelse ift. at efterleve dem.



− Sikre overensstemmelse med strategier − Lede forandringer − Kommunikere fremtidens fordele − Lede proaktiv gevinstrealisering − Tjekke programorganiseringens værdi − Sikre organisatoriske forandringer − Skabe læring i organisationen

Programprincipperne kan anvendes individuelt af ledelsesrepræsentanterne til at vur-dere egen indsats, men kan fx også tages op i styregruppen som en drøftelse af, om arbejdet har det rette fokus. I ”vejledning til god programledelse i staten – principper og temaer” findes en detalje-ret gennemgang af, hvad der kendetegner principper for succesrige og fejlslagne pro-grammer samt en beskrivelse af opgaver og ansvar for alle programtemaer opdelt på roller og faser.


5. Programmodellens faser Nærværende kapitel er tænkt som et opslagsværk til brug for programmets ledelse og deltagere. Hver programfase beskrives på en til to sider med et overbliksbillede og en kort liste over væsentligste aktiviteter. Aktiviteterne er kun forslag og er således ikke obligatoriske. Herudover findes i ”Startpakke til programledelsen” en uddybning af aktiviteterne for identifikationsfasen

5.1 Fire sekventielle hovedfaser Programmodellens fire hovedfaser (identificering af program, præcisering af program, ledelse af programbølger og Lukning af program) er sekventielle og en fase afsluttes, før den næste kan begynde.

Der kan være to eller flere programbølger, hvorfor ledelse af programbølger typisk er den længste fase i et program og kan spænde over flere år. Mellem hver programbøl-ge gennemføres et review af resultater og proces for at opnå læring, som indarbejdes i planerne for den næste bølge.

5.2 Tre tæt forbundne ledelsesprocesser Anderledes forholder det sig med levering af forandringsevne og realisering af gevin-ster. Aktiviteterne her gennemføres iterativt og parallelt med ledelse af programbøl-ger. Den tætte sammenhæng mellem de tre ledelsesprocesser er i illustrationen vist

med pile, der går begge veje:

I hver programbølge sikrer en række projekter levering af for-andringsevnen og transitionen til drift, og den efterfølgende opfølgning planlægges og ekse-kveres for at sikre realisering af gevinster.

Alle disse aktiviteter detailplan-lægges, koordineres og styres i ledelse af programbølger.

Dermed kan de tre ledelsesprocesser ikke udføres uafhængigt af hinanden, og beskri-velserne af disse bør derfor læses i sammenhæng.



5.3 Identificering af program

Uddybning af aktiviteter Hoved- aktiviteter

Beskrivelse

Ansvar for udførelse

Afklaring af og evt. an-skaffelse af program-mets finansiering i pro-grambestyrelsen

For at Identifikationsfasen kan starte, skal programbesty-relsen være udpeget. Programbestyrelsen består af top-ledere, som har strategisk ansvar og som skal beslutte investeringen i programmet. Programbestyrelsen skal sikre, at den nødvendige finansiering af programmet er til stede. Som minimum skal bestyrelsen sikre finansie-ring af den næste fase (præcisering af program).

Program- bestyrelse

Godkendelse af pro-gramkommissorium

Programbestyrelsen skal godkende programkommissoriet og overlevere dette til programejeren. Kommissoriet skitserer retning, begrænsninger, prioriteringer og øn-skede resultater for programmet.

Program- bestyrelse

Udpege programstyre-gruppe – afhold første møde

Programbestyrelsen skal formelt udpege programejeren, som er den person, der har den største aktie i program-mets succes – ofte er vedkommende dog den første person, som identificeres. Programejeren er formand for programstyregruppen og udpeger styregruppens med-lemmer. Første styregruppemøde forberedes og afholdes.

Program- bestyrelse/ Programejer

Udarbejdelse af Vision Visionen for programmet skal udarbejdes. Visionen skal formuleres kort og skal samtidigt have appel til alle nøg-leinteressenter. Visionen skal kommunikere den fremtidi-ge tilstand, som organisationen opnår ved at gennemføre programmet. Se endvidere skabelon og vejledning til vision

Program- leder

Forbered og udarbejd Et programgrundlag er kerneleverancen i denne fase og Forandrings-




Beskrivelse


Programgrundlag udarbejdes typisk af et lille forretningsteam i samarbejde med forandringsejeren. Grundlaget skal sandsynliggøre, om programmet er ønskeligt og realistisk og indeholder skitser til vision, fremtidsmodel, business case, risici etc. Det er ønskeligt, at programlederen allerede er udpeget på dette tidspunkt, så han/hun kan lede udarbejdelsen af programgrundlaget. Se endvidere skabelon og vejledning for Programgrund-lag

ejer og/eller programleder

Afklar anmeldelse til It-projektrådet

Tidsplanen for indmelding til Statens It-projektråd skal afklares og fastlægges. Dette afhænger bl.a. af tidspla-nen for udarbejdelse af materiale i fasen ”præcisering af program”.

Programleder

Evt. – Afklar videre akti-viteter i hvert projekt (hvis evolutionsprogram)

Hvis programmet er opstået af en række eksisterende projekter, som samles til et program (evolutionspro-gram), skal der tages stilling til, om alle projekter skal fortsætte uændret, eller om et eller flere projekter bør stoppes eller omdefineres.

Programleder (eller pro-gramejer, hvis leder ikke er ud-peget)

Udarbejdelse af plan for præciseringsfasen

Denne aktivitet omhandler planlægning af næste fase ”præcisering af program” og udstikker rammerne og aktiviteterne i den kommende fase inkl. ressourceestima-ter og tidsplan. Senest her skal programlederen være udpeget, således at han/hun kan varetage denne aktivi-tet.

Programleder

Uafhængig gennemgang og beslutning om at fortsætte

Programgrundlaget og plan for præciseringsfasen kan underkastes en uafhængig gennemgang forud for indstil-ling til godkendelse i programbestyrelsen.

Programejer og program-bestyrelse

Aktiviteter i identifikationsfasen er mere detaljeret beskrevet i dokumentet ”Startpak-ke til programledelsen”, som kan findes på Ministeriernes projektkontors hjemmeside. Startpakken indeholder endvidere et forslag til tidsplan for alle aktiviteterne i fasen.



5.4 Præcisering af program


Beskrivelse


Mobilisering af pro-gramteam inkl. afkla-ring af infrastruktur

Rammerne for programarbejdet skal etableres. Det gælder såvel kontorplads som it og øvrige supportværk-tøjer. Da et program betyder udarbejdelse af en meget stor mængde dokumentation, bør konfigurationssty-ringsregler og –værktøj også etableres her. Endelig skal programteamet mobiliseres, der skal afholdes kick off og fasens opgaver skal fordeles iht. tidsplanen.

Program- leder

Analyse af interessenter En grundig interessentanalyse er essentiel for et pro-gram – både for at sikre, at alle interessenter inddrages og kommer til at føle ejerskab og for at skabe overblik over, hvilke interessenter der er nøglepersoner i hvilke dele af programmet, således af kommunikationsindsat-sen kan rettes mod dem og koordineres på tværs af projekter.

Program- leder og -team

Udarbejdelse af frem-tidsmodel

Der skal udarbejdes en fremtidsmodel, som beskriver, hvordan visionen realiseres i form af nye processer, ny organisering, nye teknologier, ny information og ny kultur. Da der ofte er mange mulige veje til realisering af visionen, modelleres fremtidsmodellen parallelt med etablering af gevinstdiagram og business case. Se endvidere skabelon og vejledning til fremtidsmodel

Program- leder

Udarbejdelse af pro-gramplan

Programplanen angiver programmets samlede leveran-ce-, aktivitets-, ressource- og tidsplan. Planen aggrege-rer alle væsentlig oplysninger om programmets samlede plangrundlag (projektplaner for programmets projekter,

Programleder




Beskrivelse


programmets kvalitetsplan, risikoplan, kommunikations-plan, mobiliseringsplan og implementeringsplan).

Udarbejdelse af gevinst-diagram med gevinst-profiler

Et gevinstdiagram skal etableres. Det viser år-sag/virkningssammenhængene mellem leverancer, forandringsevne, gevinster og effekter. På baggrund af denne udarbejdes en gevinstprofil for hver gevinst, som mere detaljeret definerer gevinsten og målingen af denne. Det er forandringsejeren (eller –ejerne), som har ansvaret for udarbejdelsen af diagram og profiler. Se endvidere skabelon og vejledning til gevinstdiagram

Forandrings-ejer

Udarbejdelse af projekt-katalog

På baggrund af vision og fremtidsmodel kan projektka-taloget udarbejdes. Projektkataloget består af de pro-jekter, der skal til for at skabe fremtidsmodellen og beskriver kort indhold, leverancer, afhængigheder til andre projekter, forventede udgifter og hvilke gevinster, projektet medvirker til at realisere. Hvis der er mange projekter, vil kataloget med fordel kunne suppleres med en Exceloversigt frem for kun at have informationen i et Worddokument. Se endvidere skabelon og vejledning til projektkataloget

Program- leder

Udarbejdelse af Business case

Der skal udarbejdes en business case for programmet. Vær opmærksom på, at det er programniveauet som ejer alle gevinster og ikke de enkelte underliggende projekter. Udgifterne derimod opgøres per projekt og konsolideres til programniveauet + tillægges udgifter til programniveauet (programkontor, programledelse mv.). Se endvidere særskilt vejledning til udarbejdelse af Business case inkl. skabelon i Excel

Program- leder

Udarbejdelse af gevinst-realiseringsplan

Efter udarbejdelse af business case, skal forandringseje-ren udarbejde en overordnet gevinstrealiseringsplan, der beskriver, hvornår gevinster i business casen reali-seres, hvem der har ansvar for realisering, og hvordan realisering måles. Planen detaljeres ved indgangen til hver bølge (hver bølge realiserer en delmængde af ge-vinsterne) og bruges til løbende opfølgning på gevinst-realisering igennem resten af programmet.

Forandringsejer

Udarbejdelse af pro-gram-præciseringsdokument

Programpræciseringsdokumentet (PPD) udarbejdes på baggrund af programgrundlaget. PPDen er et paraply-dokument for programmet og er derfor helt grundlæg-gende for programmet, ligesom PIDen er det for et projekt. Programmet opsummeres i PPDen, som henvi-ser til de respektive ledelsesprodukter for flere detaljer. Se skabelon og vejledning til programpræciseringsdo-kument

Program- leder

Beskrivelse af program-strategier

Et program skal sætte rammerne for alle de projekter, der skal udføres som en del af programmet. En del af disse rammer defineres i denne fase i form af program-strategier. Programstrategier skal beskrive program-mets strategiske overvejelser om ledelse og styring af gevinstrealisering, interessenter, ressourcer, risici og emner, kvalitet, opfølgning- og kontrol, afhængigheder og dokumentkonfiguration. Strategierne beskriver pro-cesser og principper, som programmet arbejder efter samt roller og ansvar ift. disse – således slipper projek-terne for hver især at skulle definere disse processer og principper og håndteringen af fx risici og gevinster ens-artes dermed på tværs af projekter. Se skabelon og vejledning til programstrategier

Program- leder

Beskrivelse af imple-menteringsstrategi

Strategien skal fx sætte rammer for ledelsens rolle og indsats ift. at skabe forandringer, ligesom strategien

Programleder i samarbejde




Beskrivelse


skal rammesætte omfanget af inddragelse af organisati-onen undervejs i programforløbet for at forberede orga-nisationen på implementering af fx nye arbejdsproces-ser, nye roller, nye kompetencer mv. Samtidig skal der tages stilling til krav til de fælles rammer i programmet (på tværs af projekterne) i for-hold til forberedelse af transitionen fra program til drift herunder den egentlige udrulning og ibrugtagning af både organisatoriske og tekniske leverancer fra projek-terne. Se skabelon til implementeringsstrategi

med foran-dringsejer

Beskrivelse af udbuds-strategi

Udbudsstrategien skal sætte de overordnede rammer for programmets udbud, så udbud gennemføres både tids-, omkostnings- og ressourceeffektivt og med størst muligt udbytte, fx bedre indkøbspriser, bedre leverandø-rer og mere indhold. Strategien sikrer, at programmets udbud tilrettelægges med afsæt i Total Cost of Owner-ship (TCO) – dvs. at man også sikrer, at business casen for udbuddet er hensigtsmæssig, når man ser på de samlede omkostninger i det anskaffedes levetid. Endelig skal strategien forholde sig til snittet mellem udbudsrelaterede opgaver i hhv. program og projekter herunder, hvordan aktiviteter koordineres på tværs af projekter. Udbudsstrategien svarer på 5 overordnede spørgsmål:

1. Hvad skal programmet anskaffe igennem ud-budsforretninger?

2. Hvordan kan/bør programmet samle anskaffel-serne (for at opnå bedst mulig TCO business case) og hvad skal udbudsformen være?

3. Hvilke målsætninger og principper skal pro-grammet leve op til i forbindelse med gennem-førelse af udbud?

4. Hvordan skal programmet gennemføre udbuds-forretningen (-erne)

5. Hvad estimeres de samlede anskaffelsesom-kostninger til?

Se skabelon til udbudsstrategi

Programleder

Risikovurdering i It-projektrådet

De krævede ledelsesprodukter kan nu indsendes til Statens It-projektråd til risikovurdering. Se vejledning til risikovurdering af programmer i It-projektrådet

Programejer

Detailplanlægning af første programbølge

Første programbølge skal detailplanlægges. Denne plan er en tids-, aktivitets- og ressourceplan, fx i Microsoft Project eller lign. Værktøj. Se skabelon og vejledning til bølgeplan

Program- leder

Design programorgani-sationen og udarbejd mobiliseringsplan for første bølge

Den endelige programorganisation skal designes for programmet og for de enkelte bølger og en mobilise-ringsplan udarbejdes for den første bølge. Dette kan være en omfattende opgave, hvis programmet er kom-plekst, idet allokering af de rette ressourcer skal koordi-neres med allokering af fysiske rammer og program-teamets ressourcer, ift. at kunne tage imod ressourcer-ne og initiere projekter og opgaver.

Program- leder og pro-gramkontor

Godkende obl. ledelses-produkter og opnå ac-cept til at fortsætte

PPDen skal godkendes i programstyregruppen sammen med de underliggende ledelsesprodukter (vision, frem-tidsmodel, business case etc.).

Program- styregruppe



5.5 Ledelse af programbølger

Uddybning af aktiviteter Hovedakti-viteter

Beskrivelse


Detaljering af bølgeplan

Bølgeplanen skal detaljeres mht. aktiviteter, tid og ressourcer. Fasen ledelse af programbølger er den paraply, der løbende sikrer koordi-nation og sammenhæng på tværs af alle projekter. Planen er derfor nødt til at være detaljeret nok, til at den afspejler kritisk vej og af-hængigheder mellem projekter – samtidigt med at overblikket beva-res. Planen vil ofte være udarbejdet i et værktøj a la Microsoft Pro-ject. [Skabelon og vejledning forventes etableret i efteråret 2013]

Program- leder

Mobilisering af projekter og projektteams

I starten af hver bølge, skal bølgens projekter og projektteams mobi-liseres. Ressourcer med de rette kompetencer skal identificeres og allokeres til projekter (eller sources eksternt), og alle projekter skal gennemgå kick off, hvor betydning for den samlede programrealise-ring tydeliggøres og rammerne (og tolerancerne) for projekterne kommunikeres.

Program- leder

Programsty-ring og pro-gramledelse

Dette dækker over dag til dag ledelsen som programleder. Dette indebærer opgaver på flere niveauer: 1. Politisk programledelse ift. håndtering af minister, departement og omgivelser, 2. Strategisk programledelse ift. løbende at skabe overblik og analysere, om pro-grammet samlet set er på rette spor, 3. Operationel programledelse ift. at guide om og sikre efterlevelse af programgovernance samt coaching og opfølgning på projekter og håndtering af undtagelser og eskalationer.

Program- leder

Løbende sikre sammenhæng mellem Frem-tidsmodel og

Det er programlederens ansvar i samarbejde med programejer lø-bende at bevare overblikket over programmet og sikre, at der er sammenhæng mellem den fremtidsmodel, som programmet arbejder hen imod og den forretningsstrategi, som er gældende. Strategier

Program- leder



Uddybning af aktiviteter Hovedakti-viteter

Beskrivelse


forretnings-strategi

kan ændre sig i den årrække, som et program typisk strækker sig over, og det er nødvendigt løbende at sikre overensstemmelse med strategi, så programmet forbliver relevant (eller lukkes, hvis det ikke er tilfældet).

Indkøb og ressourcesty-ring

Indkøb af såvel kompetencer som software/hardware og løbende ressourcestyring bør foretages på programniveau. I store program-mer kan programledelsen have en juridisk enhed tilknyttet, som håndterer programmets udbud, kontrakt- og leverandørstyring. Res-sourcestyring omhandler bl.a. håndtering af tilgang og afgang af ressourcer samt løbende disponering og omdisponering af ressourcer ift. behov på program- og projektniveau.

Program- leder

Opfølgning og kontrol samt rapportering og kommuni-kation

Et velfungerende opfølgningsregime er afgørende for at kunne beva-re overblikket over et program. Der er ofte mange projekter og akti-viteter, som skal monitoreres og koordineres og mange interessen-ter, som har behov for fremdrifts- og resultatrapportering. Indsam-ling og kommunikation af denne information er væsentlig – men skal hele tiden balanceres, så den ikke tager fokus fra at sikre fremdrift, leverancer og arbejdet med gevinstrealisering.

Program- leder

Transition til stabil drift

Transitionen af de enkelte projekter og bølger planlægges og gen-nemføres i ”realisering af gevinster”, men i ledelse af programbølger overvåger programledelsen, om transitionen lykkes og arbejder for og følger op på, at stabil drift opnås, og at gamle arbejdsmetoder afskaffes.

Forandrings-ejer

Foretag re-views

Et program er så stort og ofte komplekst, at det er nødvendigt lø-bende at stoppe og sikre review af, at programmet fortsat er på rette spor. Review kan foretages både på projektniveau (er leverancerne tilfredsstillende), bølgeniveau (opnås den ønskede forandring og gevinstrealisering) og på programniveau (er fremtidsmodellen fortsat strategisk relevant og ser programmet som helhed ud til at kunne realisere den). Igangsætning, koordinering og styring af disse re-views er en løbende opgave for programledelsen. Det anbefales, at lade personer, som er eksterne ift. programmet (fx en intern audit-funktion), gennemføre reviews for at sikre et neutralt review.

Program- leder

Lukning af bølge samt forberedelse af næste bøl-ge

Hver bølge afsluttes med et review og en evaluering. Denne foreta-ges inden næste bølge igangsættes, så læring og erfaring kan indar-bejdes i planen for den kommende bølge. Detailplanlægning af næste bølge udarbejdes og forelægges til godkendelse i programstyregrup-pen.

Program- leder



5.6 Levering af forandringsevne

Uddybning af aktiviteter Hoved- aktivite-ter

Beskrivelse


Opstart af projekter

Programledelsen skal sikre en projektstart, som sikrer, at projektledelse (projektejer og projektleder) kender den samlede projektportefølje, for-står mål og fremtidsmodel og kan se, hvilken værdi eget projekt tilfører, får overblik over afhængighederne til andre projekter og forstår, hvordan projektets leverancer skal anvendes. Endelig skal opstarten også sikre, at projektledelsen kender rammerne for programgovernance, herunder tolerancer samt krav og rammer fra programstrategierne.

Program- ledelse

Eksekve-ring af projekter iht. mål

Projektledelsen eksekverer projekterne i henhold til de mål og rammer, programmet har udstukket. Se kapitel 7 for krav til ledelsesprodukter for projekter i et program

Projekt- ledelse

Ledelse og kontrol af leverancer

Programledelsen har ansvar for løbende ledelse af programmets projekter ift.: Review af projektet fremdrift og leverancer, opfølgning på tid, udgif-ter, ressourcer og scope, håndtering af eskalationer og undtagelser, le-delse af afhængigheder og integrationer mellem projekter, sikre overens-stemmelse med fremtidsmodel og kvalitetssikring.

Program- ledelse

Løbende opfølgning på mulig-hed for gevinstrea-lisering

Forandringsejeren er ansvarlig for løbende at følge op på, om leverancer-ne fra et specifikt projekt ser ud til at ville give den forventede foran-dringsevne og dermed sandsynliggøre gevinstrealiseringen. Selv om ge-vinster ikke kvantificeres på projektniveau, skal projektets PID alligevel beskrive, hvilke gevinster projektets leverancer skal være med til at reali-sere – og forandringsejeren skal følge op på, om det fortsat ser ud til at være realistisk. Dette sker på mange forskellige måder, bl.a. ved at give

Forandrings-ejer



Uddybning af aktiviteter Hoved- aktivite-ter

Beskrivelse


input til kravspecifikationer og procesdesign, ved allokering af forret-ningskompetence til projekterne og ved deltagelse i review og vurdering af skalerbarhed af projektleverancer (vurdering af skalerbarhed fra enkelt test til fuld driftsimplementering).

Lukning af projekter

Et projekt skal lukkes formelt ved at programledelsen godkender, at projektet møder acceptkriterierne fra projektets PID. Evt. kan et formelt review af projektet gennemføres.

Program- ledelse

5.7 Realisering af gevinster

Uddybning af aktiviteter

Hovedaktivite-ter

Beskrivelse


Planlægge og gen-nemføre gevinst-rapporteringsmålin-ger

Den overordnede gevinstrealiseringsplan, som er udarbejdet i præciseringsfasen, skal detaljeres og afgrænses for den aktuelle bølge. Planen skal præcist definere, hvilke gevinster bølgen reali-serer, hvem der har ansvaret for realiseringen og hvad planen er for løbende måling og rapportering af gevinstrealiseringen. Endvi-dere skal baseline målinger sikres (helst allerede i præciseringsfa-sen). Forandringsejeren skal derefter i løbet af bølgen (og efter afslutning) følge realiseringen gennem målinger og rapportering af gevinstrealiseringen. Dette dokumenteres i gevinstrealiserings-rapporten. [Skabeloner og vejledninger forventes etableret i efteråret 2013]

Forandrings-ejer

Planlægge transitio- Transitionsplanen er afgørende for succesfuld overgang fra gam- Forandrings-



Uddybning af aktiviteter Hovedaktivite-ter

Beskrivelse


nen/forandringen fra gammel til ny driftsmodel

mel forretningsmodel til ny. Den bør derfor være detaljeret og er ofte ganske omfattende. Planen skal forholde sig til alt fra over-gang til nye processer og arbejdsgange, nedlukning af gamle systemer og ibrugtagning af nye, implementering af kulturelle og holdningsmæssige ændringer hos personale og driftsledelse til planlægning af support fra fx it og HR i transitionsfasen og etable-ring af back-up planer for, hvordan tilbagerulning sikres, ifald der opstår uoverstigelige problemer i løbet af transitionen. Planen bør derfor udarbejdes i tæt samarbejde mellem forandringsejer og programleder og med løbende inddragelse af de projektledere, som bidrager med leverancer.

ejer og pro-gramleder

Godkende igang-sættelse af transiti-on

Når alle leverancer er meldt klar fra projekterne i bølgen og tran-sitionsplanen er udarbejdet, skal forandringsejeren vurdere, om organisationen er klar til transitionen. Dette indebærer godken-delse af, at leverancerne kan skabe den nødvendige forandring og en vurdering af, om organisationen er klar til transition. Foran-dringsejeren fortager vurderingen, men det er programejeren, der træffer den ultimative beslutning (typisk som del af et program-styregruppemøde).

Forandrings-ejer og pro-gramejer

Lede forandringen og overvåge ge-vinstrealiseringen

Forandringsejer leder nu transitionen og følger løbende op på, at nye forretningsgange og måder tages i brug og de gamle forlades. Dette tager tid og kræver konstant overvågning og involvering fra ledelsens side. Udviklingen i gevinstrealiseringen overvåges og dokumenteres i gevinstrealiseringsrapporten. Ofte vil fuld gevinst-realisering kræve tid og kan ikke nødvendigvis opnås inden for bølgens tidsplan, men realiseringen skal sandsynliggøres, før bølgen kan lukkes.

Forandrings-ejer

Løbende kommuni-kation ift. interes-senter

Kommunikation er en aktivitet, der bør fylde meget i denne fase. Før transitionen igangsættes, skal alle relevante interessenter informeres om planerne. Mange programmer indebærer ændring af arbejdsgange og/eller organisatoriske strukturer, hvilket skaber usikkerhed hos de, der berøres af forandringen. Løbende kommu-nikation skaber klarhed over, hvad der skal ske, hvad der er op-nået og mindsker dermed usikkerheden og er med til at holde motivationen for forandringen oppe – også hos de interessenter, som ikke har været direkte involveret i programmet. Det er for-andringsejer, der har ansvaret for denne aktivitet – men ofte er vedkommende understøttet af en kommunikationsfunktion i pro-grammet eller i driftsorganisationen. Det kan også være relevant at inddrage personer med ansvar for ekstern kommunikation for at kunne håndtere pressen.

Forandrings-ejer

Lede og monitorere post-forandringen til den nye driftsmodel

Denne aktivitet indebærer håndtering af udfordringer og proble-mer oplevet i den nye driftssituation. Disse kan løses inden afslut-ningen af bølgen eller overføres som opgaver til driftsorganisatio-nen eller til et eller flere kommende projekter. Som en del af post-forandringen skal gamle processer og arbejdsgange endeligt nedlægges og gamle systemer tages ud af drift.

Forandrings-ejer



5.8 Lukning af program


Beskrivelse


Forbered lukning af program

Som en del af forberedelsen til lukningen af programmet skal programlederen sikre følgende: De ønskede effekter er opnået og ser ud til at være holdbare også efter lukning, business casen er tilfredsstillende opfyldt (men ikke nødvendigvis 100 pct. indfriet), sidste bølge er gennemført og der er ikke udestående risici eller emner, som ikke er accepteret af driftsorganisationen.

Program- ledelse

Sikring af support til den nye driftsorga-nisation

Mens programmet kører, har programledelsen fokus på at sikre den nødvendige support til driftsorganisationen (jf. aktivitet under realisering af gevinster). Når programmet står foran lukning, skal eventuelt videre behov for support adresseres og sikres, fx i form af proceshjælp eller løbende uddannelse i nye it-systemer. Even-tuel ændring i supportstruktur skal kommunikeres til rette inte-ressenter.

Program- ledelse

Evaluer program og opsamling på reali-sering af den sam-lede business case

Det samlede program skal gennemgå et formelt review iht. krave-ne for lukning af program (Se under ”Forbered lukning af pro-gram”). Den endelige review vil tage udgangspunkt i de allerede gennemførte reviews ved afslutning af hver programbølge og konsolidere resultaterne ift. opnåelse af fremtidsmodel og realise-ring af business case. Reviewet dokumenteres i en programevalu-eringsrapport. Da et program ofte lukker, inden programmet har realiseret ge-vinsterne 100%, kan det nogle gange være hensigtsmæssigt at planlægge med gennemførelse af endnu et review et godt stykke tid efter programmets lukning.

Forandrings-ejer

Opløs programorga-nisation

I forbindelse med opløsning af programorganisationen skal pro-gramressourcerne afallokeres og allokeres til et nyt projekt eller program eller flyttes tilbage til deres driftsorganisation. Dette

Program- leder




Beskrivelse


kræver aktiv planlægning, eftersom de ressourcer, der er tilknyt-tet programmet, kan have været en del af programmet i flere år og dermed have mistet tilknytningen til driftsorganisationen. Eventuelle vedvarende forpligtelser ift. leverandør- og kontraktop-følgning skal overdrages til driftsorganisationen.

Formel lukning af program

Programmet lukkes formelt af programejeren – dette gøres på et afsluttende programstyregruppemøde.

Programejer



6. Programledelsesprodukter Nærværende kapitel er tænkt som et opslagsværk til brug for programmets ledelse og programsekretariat samt andre, som forventes at bidrage til udarbejdelse af ledelses-produkter. Det giver et overblik over produkterne og deres sammenhæng og viser, om skabelon og vejledning findes.

6.1 Programledelsesprodukter ift. programmodellens faser Der skal udarbejdes en række produkter i løbet af et programs levetid for at sikre den optimale programstyring og -ledelse. Den overvejende del af disse produkter udarbej-des i præciseringsfasen som basis for at tage beslutning om igangsættelse af leveran-cedelen af programmet. Nedenfor vises, hvilke produkter der udarbejdes i hvilke faser.



6.2 Sammenhæng mellem produkter Nedenfor vises en oversigt over de centrale programledelsesprodukter, som har stær-ke indbyrdes afhængigheder. Pilene angiver, at et ledelsesprodukt anvendes som ud-gangspunkt eller input til et eller flere andre ledelsesprodukter.

Endvidere vises sammenhængen til de vigtigste ledelsesprodukter på projektniveau.

Pilene kommer dermed også til at angive en anbefalet rækkefølge for udarbejdelsen af produkter.

Først udarbejdes programgrundlag og vision. De giver begge input til fremtidsmodel-len og gevinstdiagrammet, som udarbejdes parallelt, og som skitserer, hvad der skal til for at opnå visionen. Når fremtidsmodellen og gevinstdiagrammet er udarbejdet, kan business casen udarbejdes og herefter gevinstrealiseringsplanen - en plan, som senere udbygges for hver bølge, der gennemføres. I praksis vil fremtidsmodel, ge-vinstdiagram og overordnede skitser til business case udarbejdes i flere iterationer, til visionen er opfyldt på en måde, som giver en tilfredsstillende business case.

Fremtidsmodellen giver input til projektkataloget, som herefter kan udarbejdes. På baggrund af projektkataloget kan programplanen, som er tidsplanen for væsentlige aktiviteter for det samlede program og alle projekter, udarbejdes. I praksis vil arbej-det med programplanen kunne betyde tilbageløb til projektkataloget, idet behov for nye eller ændrede projekter kan identificeres i takt med planens udarbejdelse.

Programpræciseringsdokumentet (PPD) kan påbegyndes på baggrund af program-grundlag, vision og fremtidsmodel. Det er et paraplydokument, som opdateres med risici, gevinster, business case tal etc., efterhånden som disse produkter udarbejdes, dvs. der er mange tilbageløb til PPD’en fra de øvrige produkter.

Så tidligt som muligt i præciseringsfasen påbegyndes programstrategier, udbudsstra-tegi og implementeringsstrategi, som tilsammen sætter de overordnede rammer for, hvordan programmet, herunder dets projekter skal styres og ledes.



Programmets risici kan beskrives i risikoregisteret – og sammen med gevinstdia-grammet giver risici input til business casen, hvor risici kobles til de enkelte gevinster.

Når de grundlæggende ledelsesprodukter for programniveauet er udarbejdet, kan le-delsesprodukter på bølgeniveau udarbejdes. Programplanen bruges som afsæt for ud-arbejdelsen af bølgeplan, og projektdefinitionen i projektkataloget giver input til PID’er for hvert projekt.

Den overordnede gevinstrealiseringsplan for programmet giver input til den detaljere-de gevinstrealiseringsplan, der udarbejdes for en bølge, og planen danner senere grundlag for udarbejdelse af gevinstrealiseringsrapporten.

Gevinstrealiseringsrapport og projektafslutningsrapport giver input til den bølgere-view-rapport, som udarbejdes ved udgangen af hver programbølge – og det samlede antal bølgereviewrapporter danner baggrund for udarbejdelse af programevaluerings-rapporten, hvor status på realisering af den samlede business case opgøres.


6.3 Obligatoriske ledelsesprodukter Ledelses-produkt

Formål og indhold

Udar-bejdes i

Udar-bejdes af

Forven-tet sidean-tal

Sammenhæng til andre produkter

Skabelon/ vejledning

Program-grundlag

Formål: Beskriver programmets mål og formål og benyttes til at vur-dere, om programmet er realistisk, og om målsætningen er realistisk. Er rammen for gennemførelse af præciseringsfasen. Indhold: Programgrundlaget er det første ledelsesprodukt, som be-skriver de samlede rammer for programmet inkl. første overslag på gevinster og omkostninger, en foreløbig visionsbeskrivelse og en vur-dering af, hvilke bølger og hvilke projekter, der skal til for at realisere visionen.

Identifice-ring af program

Foran-dringsejer og/eller programle-der

7-10 Basis for alle produk-ter, som udarbejdes i fasen præcisering af program – særligt PPD og fremtidsmodel

Skabelon og vejledning findes

Vision Formål: At kommunikere programmets overordnede formål. Indhold: Visionen udtrykker i en kort sætning programmets målbille-de/målsætning. Visionen bruges i kommunikation af programmets overordnede formål. Visionen skal være så attraktiv og fleksibel, at den kan benyttes til kommunikation med alle interessenter og gennem hele programmets levetid.

Identifice-ring af program

Programle-der

2-5 Giver input til frem-tidsmodel og PPD


Fremtids-model

Formål: En fremtidsmodel operationaliserer visionen og viser målet med programmet i form af nye processer, ny organisering, nye tekno-logier, ny information og ny kultur. Ikke alle elementer vil nødvendig-vis være ændret. Indhold: Fremtidsmodellen indeholder både beskrivelse af før- og efterbilledet, både hvad angår processer, organisering, teknologi, information og kultur, så det er enkelt at se, hvad det er for en foran-dring, der skal gennemføres.

Udkast: Identifice-ring af program Endelig: præcise-ring af program

Programle-der

15-25 Skaber den røde tråd tilbage til vision og videre frem til gevinst-diagram, business case, projektkatalog og bølgeplaner, som alle defineres op imod fremtidsmodellen. Fremtidsmodel, ge-vinstdiagram og busi-ness case udvikles i et iterativt forløb.


Gevinstdia-gram og gevinstpro-filer

Formål: At illustrere (på en overskuelig facon) sammenhængen fra programmets leverancer til de realiserede gevinster og disses effekt (gevinstdiagram) samt sikre detaljeret forståelse af hver af gevinster-ne i business casen (gevinstprofiler) Indhold: Gevinstdiagrammet er en tegning af årsag-virkningssammenhænge og viser leverancerne, den forandringsevne

Præcise-ring af program

Foran-dringsejer

2-5 (dia-gram) 1-2 per gevinst

Udarbejdes på bag-grund af vision og fremtidsmodel – og danner grundlag for udarbejdelse af busi-ness case og gevinst-realiseringsplan. Frem-




de skaber, de gevinster der dermed kan opnås og de effekter, gevinst-realiseringen samlet set vil have på organisationen og dens omgivel-ser. Gevinstprofiler indeholder en detaljeret beskrivelse af gevinsten, dens ejer(e), bl.a. link til programmål, gevinstkategori, leverancer og forretningsmæssige ændringer, som er nødvendige for at realisere gevinsten, risici og afhængigheder.

tidsmodel, gevinstdia-gram og business case udvikles i et iterativt forløb.

Business case

Formål: Businesscasen benyttes til fortløbende validering af pro-grammets berettigelse. Indhold: Business casen udarbejdes for det samlede program og indeholder alle udgifter på projekt og programniveau samt alle gevin-ster, som det samlede program realiserer. Udgifter summeres på baggrund af opgørelse af udgifter for hvert projekt og udgifter for programniveauet. Gevinster opgøres kun på programniveau. Endvide-re kobles risici og risikoniveau til de enkelte udgifter og gevinster.


Programle-der

10-15 Udarbejdes iterativt parallelt med gevinst-diagram og Fremtids-model. Får input fra risikoregister til vurde-ring af usikkerheder for såvel gevinster som udgifter


Program-præcise-ringsdoku-ment (PPD)

Formål: Dette er programmets mest afgørende ledelsesprodukt og har til formål at konsolidere og opsummere rammerne for og indholdet af programmet. Indhold: PPD er baseret på programgrundlaget (samme skabelon), men er uddybet og mere præcist. PPDen er paraplydokument for en lang række af de øvrige ledelsesprodukter, ligesom PID’en er det for et projekt. PPDen omfatter således elementer fra visionen, fremtids-modellen, bølgeplan, gevinstdiagram, business case, projektkatalog og risikoregister.


Programle-der

20-30 Grundlæggende ledel-sesprodukt for pro-grammet sammen med vision og fremtidsmo-del. Skitseres tidligt på baggrund af vision og programgrundlag – men opdateres efter-hånden, som underlig-gende ledelsesproduk-ter færdiggøres


Risikoregi-ster pro-gram

Formål: Risikoregisteret har til formål at understøtte identifikation, dokumentation og aktiv styring af de risici, der påvirker eller potentielt kan påvirke programmet. Indhold: Indeholder beskrivelse af hver risiko, sandsynlighed og konsekvens samt oplæg til afbødende handlinger.


Programle-der

8-10 Udarbejdes parallelt med PPD og giver input til business casen og gevinstrealiseringspla-ner


Projektkata-log

Formål: At skabe oversigt over de projekter, der er nødvendige for at kunne opfylde og levere fremtidsmodellen. Indhold: Projektkataloget indeholder overordnede beskrivelser af projekterne og afhængighederne mellem disse samt viser opdelingen i de forskellige programbølger.


Programle-der

2-3 sider per projekt

Udarbejdes på bag-grund af fremtidsmodel og anvendes som grundlag for etablering af bølgeplaner og de-taljeret planlægning af de enkelte projekter


Program-plan

Formål: Formålet med programplanen er (ligesom med projektplanen i et projekt) at skabe en sammenhængende plan, der kan anvendes til at skabe overblik over, hvornår hvilke aktiviteter skal igangsættes og dermed afhængigheder på tværs af og ressourcetrækket i program-


Programle-der

10-15 sider Udarbejdes på bag-grund af arbejdet med fremtidsmodellen og programpræciserings-




met/projekterne.

Programplanen er det styringsmæssige grundlag for at programmet løbende kan styre og følge op på programmets fremdrift i forhold til de planlagte program- og projektleverancer. Samtidig skal programplanen sikre, at programmet kan følge op på risici, hændelser og kvalitet samt interne projektafhængigheder i programmet.

Indhold: Programplanen viser et overblik over programmets samlede leverancer fordelt på de enkelte programbølger samt sammenhængen (afhængigheder) mellem projektleverancer og den kritiske vej for hvornår hvilke leverancer, resultater og gevinster skal være leve-ret/opnået for at der ikke opstår kritiske forsinkelser.

Programplanen er samtidig udgangspunktet for en detaljeret planlæg-ning af projektleverancer, resultater og gevinster samt styring af af-hængigheder for hver enkelt programbølge.

dokumentet. Programplanen detalje-res i en detaljeret bølgeplan, som udar-bejdes som plangrund-lag forud for hver pro-grambølge i fasen ledelse af programbøl-ger.

Bølgeplan Formål: Ved indgangen til hver ny bølge skal der foreligge en detalje-ret plan for denne. Den kan ses som en ”slags PPD” for bølgen, hvis væsentligste formål er at dokumentere en sammenhængende plan for gennemførelse af bølgen. Men også rammer for bølgen i form af fx organisering beskrives her, idet disse kan afvige fra de grundlæggen-de rammer, der er defineret på programniveau. Indhold: Det væsentligste indhold er en samlet tids-, aktivitets- og ressourceplan for bølgen. Derudover beskrives også, hvilke gevinster, der skal være realiseret, for at bølgen kan afsluttes succesfuldt og rammer for eksekvering af bølgen (fx organisering). Planen vil i prak-sis typisk bestå af flere forskellige produkter som fx en aktivitets og tidsplan i Microsoft Project, en leveranceliste i Excel og en gevinstbe-skrivelse.

Ledelse af program-bølger og derefter i starten af hver ny bølge

Programle-der

8-10 per bølge

Udarbejdes på bag-grund af programpla-nen Anvendes som baseline for bølgereviewrapport


Program-strategier

Formål: At sætte rammerne for styring og ledelse i programmet. Indhold: Beskrivelse af strategier for håndtering af gevinster, interes-senter, ressourcer, risici og emner, kvalitet, opfølgning og kontrol, afhængigheder og dokumentkonfiguration. Strategierne sætter ram-merne ved bl.a. at beskrive processer samt roller og ansvar for hvert element i strategien.


Programle-der

36-54 Dokumentet er ram-mesættende for flere andre ledelsesproduk-ter, fx programplan, gevinstrealiseringsplan, projektkatalog og risi-koregister samt øvrige anbefalede plandoku-menter.


Udbudsstra-tegi

Formål: Formålet med udbudsstrategien er at sikre, at programmet har taget stilling til, hvordan programmet mest optimalt tilrettelægger

Præcise-ring af

Programle-der

15-20 Dokumentet sætter rammerne for planlæg-

Skabelon og vejledning



de udbud, der skal gennemføres i programmet med henblik på at optimere programmets business case. Indhold: Udbudsstrategien er et ledelses- og styringsdokument, der omfatter en lang række beslutninger om valg af tilgang til at gennem-føre udbud, herunder begrundelser og eventuelle understøttende ana-lyser.

program

ning af programmets indkøb fordel over programmets projek-ter, som fremgår af programplan og pro-jektkatalog.

findes

Implemen-teringsstra-tegi

Formål: Formålet med implementeringsstrategien er at sikre, at pro-grammet har taget stilling til, hvordan forandringsledelse og transitio-nen fra program til drift håndteres i programmet og dets projekter samt i organisationen som helhed. Indhold: Implementeringsstrategien er et ledelses- og styringsdoku-ment, der indeholder overvejelser og begrundelser for valg af den overordnede måde implementering gribes an på. Det handler om for-andringsledelse og transition fra program til drift.


Programle-der og for-andringsejer

10-15 Dokumentet er ram-mesættende for flere andre ledelsesproduk-ter, fx programplan, gevinstrealiseringsplan, projektkatalog og risi-koregister samt øvrige anbefalede plandoku-menter.


Gevinstrea-liserings-plan

Formål: Formålet med gevinstrealiseringsplanen er at udarbejde en plan for, hvornår og hvordan gevinsterne i business casen realiseres. Indhold: Beskriver og konkretiserer hver af gevinsterne i business casen for programmet og angiver, hvornår og hvor gevinsterne reali-seres, hvem der realiserer dem, og hvordan realiseringen skal måles. Planen udarbejdes i fasen præcisering af program og detaljeres ved igangsætning til hver bølge, således at det er tydeligt, hvilke gevinster der realiseres som følge af bølgen.

Præcise-ring af program og før opstart af hver bølge

Foran-dringsejer

10-20 5-7 per bølge

Etableres på baggrund af business case, ge-vinstprofiler og bølge-plan og danner bag-grund for udarbejdelse af gevinstrealiserings-rapport


Gevinstrea-liserings-rapport

Formål: At følge op på og dokumentere de høstede gevinster for en bølge i programmet. Indhold: Rapporten er en udbygning af den eksisterende gevinstreali-seringsrapport fra it-projektmodellen og indeholder basismåling, lø-bende målinger og afsluttende måling af gevinstrealiseringen. Denne kan også anvendes til samlet afrapportering af gevinstrealisering for det samlede program.

Ved afslut-ning af hver bølge og ved afslutning af program

Foran-dringsejer

5-10 per bølge 10-20 ved afslutning af program

Udarbejdes med ud-gangspunkt i gevinst-realiseringsplan og giver input til bølgere-viewrapport og Pro-gramevalueringsrap-port


Program-evaluerings-rapport

Formål: Programevalueringsrapporten anvendes til at opsamle erfa-ringer og læring fra det samlede program. Denne læring videregives til nye programmer og kan give input til vurdering af organisationens generelle governance setup. Indhold: Rapporten indeholder erfaring og læring fra det gennemfør-te program, både i form af opfølgning på business casen og realisere-de gevinster samt opfølgning på anvendte processer, værktøjer og governancestrukturer i programmet.

Lukning af program

Programle-der

5-10 Udarbejdes på bag-grund af alle øvrige produkter, særligt vision, fremtidsmodel og business case. Input fås fra gevinstrealise-ringsrapporter og bøl-gereviewrapporter



7. Sammenhæng til den fælles-statslige it-projektmodel

Dette kapitel beskriver kort, hvordan den fællesstatslige programmodel og den fælles-statslige it-projektmodel hænger sammen.

7.1 De to modeller og sammenhængen mellem dem De to modeller eksisterer parallelt, og den ene overflødiggør ikke den anden. Alle pro-jekter i et program skal således som udgangspunkt følge den fællesstatslige it-projektmodel – dog er der visse ledelsesprodukter, som udarbejdes på programni-veau, og som derfor ikke skal defineres for et projekt.

Programmodellens bølger består hver af et eller flere projekter. Hvert projekt ledes i henhold til faserne i den fællesstatslige it-projektmodel.

7.2 Ledelsesprodukter for it-projekter i et program Projekter i et program skal udarbejde færre ledelsesprodukter end projekter, der står alene.

For projekter, som indgår i et program, skal kun PID og projektafslutningsrapport udarbejdes. De øvrige produkter – projektgrundlag, business case og gevinstrealise-ringsrapport - skal ikke udarbejdes og er derfor i overbliksfiguren angivet med stiplet kant.



Da programmet indgår i et program, er det heller ikke alle dele af PID’en, som det er relevant at udfylde. I tabellen nedenfor er angivet, hvilke dele af PID’en, der ikke skal udfyldes af et projekt, eller som kun delvist skal udfyldes:

PID kapitel Kommentar til udfyldelse

Kapitel 5 – Økonomiske hovedtal og finansiering

Kun input til business casens udgiftsside skal angives.

Kapitel 6 – Gevinster Ingen af tabellerne skal udfyldes, men projektet skal be-skrive, hvilke af programmets gevinster der understøttes med leverancer fra projektet. Som følge heraf skal Pro-duktbilag A og B ikke udarbejdes.

Kapitel 10 – Tilrettelæg-gelse og tidsplan

10.1 om strategier skal sandsynligvis ikke udfyldes, da disse i de fleste tilfælde defineres på programniveau. Dette aftales konkret med programlederen.

Kapitel 12 – Kvalitet Kvalitetsstrategi skal sandsynligvis ikke beskrives her, da denne i de fleste tilfælde defineres på programniveau. Dette aftales konkret med programlederen.

Kapitel 13 – Risici

Rammen for risikostyringsaktiviteter vil sandsynligvis væ-re beskrevet på programniveau. Dette aftales konkret med programlederen.

Kapitel 15 – Kommunika-tion

Kommunikationsaktiviteter (15.2) koordineres oftest på programniveau for at hindre, at flere af programmets pro-jekter kommunikerer ukoordineret til samme interessen-ter. Det er dog sandsynligt, at der vil være enkelte pro-jektspecifikke kommunikationsaktiviteter. Dette aftales konkret med programlederen.

Projektgrundlaget forventes at blive defineret af programledelsen ud fra projektka-taloget.

Business case udarbejdes for programmet som helhed, og alle gevinster defineres på programniveau. I den fællesstatslige business case angives udgifterne for hvert pro-jekt dog separat som input til et aggregeret udgiftsoverblik.

Gevinstrealiseringsrapporten udarbejdes derfor heller ikke for et projekt. Denne rapport udarbejdes ved afslutning af hver bølge i programmet. Projektafslutningsrap-



porten bør således fokusere på evaluering af, om leverancerne er leveret i henhold til plan og kvalitet.

7.3 Informationssikkerhed for it-projekter i et program Der er krav om, at alle it-projekter skal lave vurderinger informationssikkerheden af informationsaktivet og it-løsningen i analysefasen. Informationsaktivet er den informa-tion (data), som skal behandles af it-løsningen, og som skal sikres. Vurderingerne laves via to produkter, en konsekvensvurdering af privatlivet (PIA) og en sikkerheds-mæssig risikovurdering, hvoraf det ene, PIA, kan udelades såfremt it-løsningen ikke skal behandle personoplysninger. Spænder de informationssikkerhedsmæssige udfor-dringer på tværs af projekter, skal programmet lave en samlet vurdering. Der henvi-ses til vejledning for PID for projekter for yderligere beskrivelse og hjælp til PIA og sikkerhedsmæssig risikovurdering.

7.4 Værktøjer for it-projekter i et program Nedenstående figurer illustrerer anbefalede værktøjer for it-projekter ift. it-projektmodellen. Værktøjer kan bruges i flere af projektets faser, og skal derfor i figu-ren ses som generiske værktøjer, der ikke er tilknyttet en specifik fase.

Det er obligatorisk for et projekt at rapportere afvigelser til programledelsen, og her kan værktøjet afvigelsesanmodning anvendes, såfremt dette besluttes på pro-gramniveau.

Udbudsstrategi og interessenthåndtering kan i det konkrete program være be-sluttet på programniveau. Hvis dette er tilfældet, skal et projekt ikke udarbejde disse men i stedet følge programstrategier og udbudsstrategi på programniveau. Dette afta-les konkret med programlederen.



8. Yderligere vejledning og støt-te

Dokument Type Kort beskrivelse

Vejledning til god programledelse i staten – principper og temaer

Vejledning Omfatter 9 programtemaer og 7 programledel-sesprincipper. Principperne kan bruges som tjekli-ste for programledelsen, og temaerne er ledel-sesmæssige områder, som alle er nødvendige for at sikre programmets succes, og som ledelsen derfor kontinuerligt bør fokusere på.

Vejledning til P3M3-modenhedsanaly-se

Vejledning Analyse til at vurdere modenheden i en organisa-tion, før man begynder aktiviteter omkring porte-føljer, programmer og projekter.

Ledelsesintroduk-tion til program-modellen

Quickguide Beskriver på overbliksniveau programmodellen for ledelsen. Denne kan læses uafhængigt af alle an-dre produkter.

Startpakke til pro-gramlederen

Vejledning Tidsplan

Vejledning til programledelsen ift. planlægning af de første 3 måneder af et program. Vejledningen giver forslag til aktiviteter den først uge, måned og kvartal i fasen Identifikation af program. Vej-ledningen indeholder et konkret forslag til en tids-plan i Microsoft Project.

Vejledning om programgovernan-ce

Vejledning Introduktion til programgovernance og vejledning om obligatoriske og anbefalede governancefora for programmer. Endvidere introduktion til alle centrale programroller.

Rollebeskrivelser Vejledning Liste over alle programroller med angivelse af ansvarsområder og typiske opgaver.

Introduktion til programmer

Begrebsbe-skrivelse

Definition af programmer og programledelse ift. projekter og porteføljer. Beskriver også baggrun-den for udarbejdelse af den fællesstatslige pro-grammodel.



9. Bilag 9.1 Principper for udviklingen af programmodellen

Programmodellen er udviklet på baggrund af eksisterende bedste praksis i staten samt principper fra programmodellen MSP.

Udarbejdelsen har fulgt den fællesstatslige it-projektmodel, herunder faseopdelin-gen. Projektet har været ejet af Digitaliseringsstyrelsen med en styregruppe og en projektgruppe fra MPK. Nedenfor er angivet væsentlige aktiviteter og leverancer i hver fase.

Følgende myndigheder har bidraget til leverancer og review gennem interview og deltagelse i referencegruppe: Banedanmark, Forsvaret, Moderniseringsstyrelsen, Digitaliseringsstyrelsen, Erhvervsstyrelsen, SKAT. Derudover er Danske Bank in-terviewet i Idefasen.

9.2 Ansvar for modellen Den fællesstatslige programmodel ejes af Ministeriernes Projektkontor i Digitalise-ringsstyrelsen.

Ministeriernes Projektkontor (MPK) er ansvarlige for udarbejdelse, vedligeholdelse og opsamling på erfaringer med anvendelse af modellen.

Statens It-projektråd ejer risikovurderingsprocessen, hvori elementer fra pro-grammodellen vil indgå som dokumentation. Statens It-projektråd vil på baggrund af risikovurderingsprocessen give programmerne anbefalinger til risikominimeren-de tiltag og give feedback på de indsendte ledelsesprodukter.

MPK har nedsat en følgegruppe, som de er i løbende dialog med, mht. opsamling af ændringsforslag og erfaringer med anvendelse af modeller, metoder og værktø-jer.

9.3 MSP og god praksis Der er taget udgangspunkt i bedste praksis og de grundlæggende principper fra ”Ma-naging Successful Programmes” udviklet af HM Government i England. Denne findes pt. kun i engelsk udgave (se figur nedenfor).



Terminologien er som en del af programprojektet blevet oversat til dansk ud fra en række sproglige og formidlingsmæssige hensyn

Al terminologi er reviewet af programprojektets referencegruppe

Den gode praksis omfatter dog meget mere end praksis fra HM Government. Også erfaringer fra en lang række danske programmer er opsamlet og indarbejdet i model-len, som er forsøgt gjort endnu mere operationel end tilfældet er med MSP bogen. Dette bl.a. gennem:

− Konkret vejledning til design af governance i et program − Startpakke med beskrivelse af konkrete aktiviteter i identifikationsfasen af pro-

grammet −

9.4 Afvigelser fra MSP På nogle få områder er det valgt at afvige fra MSPs anbefalinger. Afvigelserne og be-grundelse herfor er listet nedenfor:

MSP Fællesstatslig pro-grammodel

Begrundelse

Forandringsteam refererer til forandringsejer, som refererer til programejer

Forandringsteam kan referere til program-ledelse, hvis ikke for-andringsejere og pro-gramejere er erfarne inden for programle-delse

Manglende erfaring med pro-grammer gør forandringsledel-sen sårbar, hvorfor det kan give god mening at lægge denne som et spor under programle-deren frem for at holde ansva-ret uden for selve programlede-rens område.

Alle ledelsesprodukter er obligatoriske

Kun udvalgte ledel-ses-produkter er obli-

Dette er gjort ud fra et ønske om at starte med et overskue-



MSP Fællesstatslig pro-grammodel

Begrundelse

gatoriske – og visse produkter kombinerer to MSP produkter

ligt sæt af produkter, indtil pro-grammodenheden er steget. Hvis MSP anvendes råt, kan modellen virke meget uover-skuelig.

8 strategier for program-governance

Der er i staten behov for at sætte fokus på styring af af-hængigheder i en strategi:

− Hvordan styres og af-rapporteres afhængig-heder mellem projekter-ne i programmet?

Implementeringsstrategi − Hvordan arbejder pro-

grammet med foran-dringsledelse og imple-mentering, er der fx krav om pilottest før storskalaudrulning?

Udbudsstrategi − Hvordan tilrettelægges

og afvikles udbud i pro-grammet?

vejledning til den fællesstatslige programmodel€¦translate this page2015/12/20 · microsoft...

Documents