Vejledning til den fællesstatslige it

Vejledning til
den fællesstatslige itprojektmodel
Marts 2015
Indhold
1
INDLEDNING .......................................................................................... 3
2
FEM PRINCIPPER FOR IT-PROJEKTER I STATEN........................................... 6
3
DEN FÆLLESSTATSLIGE IT-PROJEKTMODEL ............................................... 8
4
FASER................................................................................................ 11
5
LEDELSESPRODUKTER ......................................................................... 15
6
VÆRKTØJER ....................................................................................... 18
7
ROLLER OG ANSVAR ............................................................................ 20
8
PROJEKTER MED BUDGET OVER HHV. 10 OG 60 MIO. KR. ........................... 23
1 Indledning
I dette afsnit beskrives, hvem vejledningen henvender sig til, hvilke emner vejledningen
behandler, samt hvad der defineres som et it-projekt.
1.1
Formål
Den fællesstatslige it-projektmodel skal bidrage til bedre og mere ensartet planlægning, styring og gennemførelse af statslige it-projekter. Modellen, der er udarbejdet med inspiration i
PRINCE2, er et værktøj møntet på de statslige it-projektledere til at understøtte daglige arbejde med it-projekter. Hertil skal modellen bidrage til at højne ledelsesinformations, samt
danne grundlag for risikovurdering hos It-projektrådet.
Vejledningen til den fællesstatslige it-projektmodel er rettet mod it-projektledere i staten,
som bør orientere og uddanne sig i modellen før it-projekter gennemføres. Anvendelse af
modellen er obligatorisk for alle statslige it-projekter.
1.1.1
Budgetvejledningen 2014
Den fællesstatslige it-projektmodel er obligatorisk at anvende i staten for alle it-projekter, jf.
budgetvejledningen 2014 pkt. 2.2.18. Budgetvejledning 2014 udgør således det juridiske
grundlag for den statslige anvendelse af modellen.
Budgetvejledning 2014 erstatter Budgetvejledning 2011 og reglerne i Budgetvejledning 2014
gælder fra og med finansåret 2014.
1.1.2
Rammer for gennemførelse af store it-projekter i staten
Vejledningen om den fællesstatslige it-projektmodel indgår i et større hele, der beskriver
rammerne for gennemførelse af store it-projekter i staten:
-
Budgetvejledningen (2014)
Vejledning om It-projektrådet
Vejledning om den fællesstatslige it-projektmodel (nærværende vejledning)
Vejledning om statens business case-model
Alle vejledninger findes i Finansministeriets Økonomisk Administrative Vejledning
www.oav.dk.
1.2 Læsevejledning
I dette afsnit i vejledningen om den fællesstatslige it-projektmodel defineres, hvad der menes med et it-projekt. De mere formelle sagsgange omkring modellen og opdatering af modellens bestanddele præsenteres også. I afsnit 2 gennemgås de overordnede fem principper
for it-projekter i staten. Afsnit 3 redegør for indholdet af den fællesstatslige it-projektmodel.
I afsnit 4 beskrives faserne i modellen i større detaljer. I afsnit 5 og 6 ses på produkter,
værktøjer og vejledninger til modellen, og i afsnit 7 præsenteres organisering og roller for et
it-projekt. I vejledningens sidste afsnit ses på kravene til projekter med budget over hhv. 10
og 60 mio. kr.. Disse typer projekter fremhæves, da alle it-projekter med projektbudget over
10. mio. kr. skal risikovurderes hos It-projektrådet.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[3]
1.3 Definition af et it-projekt
1.3.1
Hvornår er et projekt et projekt?
Et projekt kan opfattes som en opgave, der er afgrænset i tid, kvalitet og ressourcer. Det er
imidlertid ikke alle opgaver, der er projekter. For mange, mindre opgaver og aktiviteter vil
det være administrativt overhead at etablere en projektorganisation til at varetage udførelsen.
Projekt: En midlertidig organisation der etableres for at levere en eller flere leverancer iht. realisering af en business case.
Myndigheden skal have en klar projektdefinition. En definition sikrer, at der kun er større og
strategisk fokuserede projekter i myndighedens projektportefølje, og at der ikke anvendes
ressourcer på unødig administration.
Gode tommelfingerregler for definition af et projekt kan være:
•
•
•
Det opfylder definitionen af et projekt og har karakter af at være en enkeltstående strategisk opgave med et klart defineret start- og sluttidspunkt, et eksternt konsulentprojekt
eller en udviklingspræget opgave og
ressourceforbruget udgør minimum 1 ÅV timer eller,
det kræver finansiering af minimum 1,0 mio. kr. i øvrige driftsmidler.
1.3.2
Hvornår er et projekt et it-projekt?
Et projekt er et it-projekt, når projektet omfatter nyudvikling eller væsentlig tilpasning af itløsninger. Budgetvejledningen 2014 punkt 2.2.18 definerer it-projekter som følgende:
”[…] It-projekter er investeringsprojekter, der omfatter nyudvikling eller væsentlig tilpasning af
standard it-løsninger eller omfatter væsentlig tilpasning af allerede eksisterende it-løsninger.”
Budgetvejledningen 2014, pkt. 2.2.18.
It-projekter forekommer i stort set enhver organisation eller myndighed. Ofte er formålet
med it-projekter at rationalisere og effektivisere. Formålet kan dog også være eksempelvis
kvalitetsløft gennem et bedre ESDH-system, eller implementering af lov, eksempelvis EU-lov.
Eksempler på it-projekter kan således være implementering af et nyt økonomisystem, en
elektronisk patientjournal, et flådestyringssystem (logistik), et lagerstyringssystem, et journalsystem, udvikling af back-end komponenter som en datafordeler, osv.
1.4 Processer og formkrav
1.4.1
Kobling til statens business case-model
Den fællesstatslige it-projektmodel er tæt kobles til statens business case-model, idet business case-modellen er en integreret del af den fællesstatslige it-projektmodel.
Sammen med projektinitieringsdokumentet (PID’en) er business casen det centrale styringsprodukt i projektmodellen og skal udarbejdes i analysefasen. Det vil desuden være naturligt
at udarbejde et overordnet estimat for projektets business case i projektets idéfase, dvs. i
forbindelse med udarbejdelsen af projektgrundlaget. Se yderligere herom i afsnit 5.3, samt
vejledningen til statens business case-model.
1.4.2
Statens It-projektråd
Har et projekt budgetterede udgifter til anskaffelse og udvikling, herunder internt ressourceforbrug (fx lønudgifter), over 10 mio. kr., eller er der tale om et program, hvor de samlede
udgifter til it udgør 10 mio. kr. eller derover og it udgør et væsentligt element, skal alle produkter fra den fællesstatslige it-projektmodel, værktøjerne styregruppeaftale og risikotjekliste samt business casen sendes til It-projektrådet, som sekretariatsbetjenes af MinisterierDen fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[4]
nes projektkontor i Digitaliseringsstyrelsen. Dette skal ske som et led i en risikovurdering fra
It-projektrådet. Processen for risikovurderinger i It-projektrådet er beskrevet her.
Se mere om risikovurdering af it-projekter i vejledningens sidste afsnit. Programmer, og
hvad der definerer et væsentligt element af it i et program, er nærmere beskrevet i vejledningen til den fællesstatslige programmodel, som kan hentes på Digitaliseringsstyrelsens
hjemmeside.
1.4.3
It-aktstykker
Hvis projektet andrager 60 mio. kr. eller derover i budgetterede udgifter til anskaffelse og
udvikling, herunder internt ressourceforbrug, skal projektet forelægges Folketingets Finansudvalg. Til dette udarbejdes et it-aktstykke. Finansudvalget behandler forelæggelsen og herunder it-aktstykket med henblik på tilslutning til igangsættelse (jf. Budgetvejledningen 2014
punkt 2.2.18.3).
Udarbejdelsen af aktstykker i forbindelse med it-projekter skal følge Retningslinjer for udformning af it-aktstykker, der er optaget i ØAV og kan findes her.
Overstiger et projekt, der er undervejs i projektfasen, 60 mio. kr. eller udsættes projektet
for væsentlige ændringer, skal dette forelægges Finansudvalget ved et orienterende aktstykke. Såfremt der ikke er bevillingsmæssig hjemmel til at gennemføre projektet, skal der opnås hjemmel på bevillingslov eller ved tilslutning fra Finansudvalget, også selvom de samlede omkostninger til projektet er under 60 mio. kr.
Definition: Væsentlige ændringer
Ved væsentlige ændringer forstås ændringer i de samlede udgifter på 10 pct. eller derover,
eller mindst 6 mio. kr. Ligeledes er en forventet forsinkelse i forhold til den fastlagte tidsplan
på 3 måneder eller derover en væsentlig ændring. [Budgetvejledningen 2014, punkt 2.2.18.3]
1.4.4
Regnskabsmæssig behandling
It-projekter klassificeres regnskabsmæssigt som udviklingsprojekter under udførelse. Der
henvises til ØAV for nærmere regnskabsmæssige bestemmelser om udviklingsprojekter under udførelse og indregning af udgifter. Du kan se vejledningerne i ØAV på it-området her:
http://www.modst.dk/OEAV/Vejledninger/IT-omraadet.
1.5 Videreudvikling af modellen
Projektmodellen er udarbejdet med baggrund i praksis i staten samt principper fra PRINCE2.
It-projektmodellen er udarbejdet med henblik på at understøtte de fem principper for itprojekter i staten, som er beskrevet i rapporten fra 2010 ”Professionalisering af arbejdet
med it-projekter i staten” og videreudviklet af It-projektrådet. Du kan læse mere om principperne i afsnit 2. Videreudvikling af it-projektmodellen varetages af Ministeriernes projektkontor og godkendes af Digitaliseringsstyrelsen, Finansministeriet. Videreudvikling kan initieres
på baggrund af:
-
Anmodning fra myndighederne
Anmodning fra It-projektrådet
Behov identificeret af Ministeriernes projektkontor
Den fællesstatslige it-projektmodel opdateres årligt. Se yderligere om opdateringsprocessen
og prioritering af myndighedsønsker på Digitaliseringsstyrelsens hjemmeside. Opdatering og
videreudvikling af it-projektmodellen sker i dialog med It-projektrådet samt myndighedsfølgegruppen for Ministeriernes projektkontor.
1.6 Ansvar for modellen
It-projektmodellen udvikles og vedligeholdes af Ministeriernes projektkontor i Digitaliseringsstyrelsen, der ligeledes er ansvarlig myndighed for modellen.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[5]
2 Fem principper for itprojekter i staten
De fem principper for it-projekter er retningsgivende for, hvordan it-projekter skal gennemføres i staten. De skal være med til at reducere projekternes risikoprofil.
Formålet med principperne er at sikre, at staten ikke igangsætter unødigt, risikofyldte itprojekter. Projektet skal aktivt forholde sig til principperne gennem tilrettelæggelse og udførsel, og principperne skal afspejles i de valg, der redegøres for i projektmaterialet.
De fem statslige principper for it-projekter:
-
Staten skal være ambitiøs i forhold til digitalisering af den offentlige sektor, men skal kun
gå forrest i anvendelsen af umodne tekniske løsninger, såfremt der er særlige perspektiver
ved at foretage en sådan satsning.
-
Allerede indkøbte eller udviklede løsninger skal genbruges i videst mulige omfang.
-
Kun projekter med klart beskrevne omkostninger, gevinster og effekter bør gennemføres.
-
Projekter skal afgrænses ved at minimere omfang og kompleksitet med fokus på de forretningsmæssige mål.
-
Projekterne skal gennemføres med fælles metoder og kvalificerede ressourcer, således at
der i alle projekter er et passende modenhedsniveau.
2.1 Princip 1: Ambitiøs
Det første princip afspejler, at staten skal gå forrest i digitaliseringen af den offentlige sektor,
men at statslige myndigheder ikke skal udvikle nye it-systemer fra bunden, medmindre der
er tungtvejende grunde til det.
Nyudvikling af komplekse teknologiske løsninger er risikofyldt, og det skal derfor altid overvejes, om arbejdsgange kan tilpasses til standardløsninger frem for omvendt. Samtidig skal
der være klarhed om de risici en satsning på nyudvikling medfører, før projektet igangsættes.
Princippet fordrer, at det i projektmaterialet dokumenteres, hvor den foreslåede teknologi
har været anvendt tidligere, og hvad erfaringerne har været.
Andres erfaringer med den pågældende teknologi skal indsamles aktivt under planlægning af
projektet.
Teknologier og metoder, som ikke har været brugt hos førende offentlige eller private organisationer i Danmark eller i udlandet, bør som hovedregel ikke anvendes i staten. Der kan
være undtagelser, men princippet bør følges ved de allerfleste anskaffelser.
2.2 Princip 2: Genbrug
Det andet princip skal sikre, at statslige myndigheder aktivt undersøger mulighederne for at
genbruge løsninger. Det kan være løsninger, der allerede er udviklet i andre styrelser, eller
fælleskomponenter, som for eksempel den digitale signatur.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[6]
Hvis eksisterende løsninger ikke kan bruges direkte, skal det overvejes, om det bedre kan
betale sig at videreudvikle en allerede eksisterende funktionalitet fra en anden styrelse end
at foretage nyudvikling af en tilsvarende løsning fra bunden.
Det kan være svært at vide, hvilke funktioner der er udviklet i andre styrelser eller i udlandet, og om de kan genbruges. Derfor er det et led i planlægningen af it-projekter at kontakte
andre styrelser for at undersøge, om der findes it-systemer eller funktionalitet, der kan genbruges.
2.3 Princip 3: Business case
Det tredje princip skal sikre, at omkostninger, gevinster og effekter klart beskrives, og at
grundlaget for forventede gevinster og omkostninger er tydeligt. Det skal ske ud fra en fælles terminologi og med ensartede kategorier og retningslinjer.
Business casen skal løbende opdateres under projektforløbet, og det skal være klart, hvornår og
hvordan der følges op på de forventede gevinster.
Fælles retningslinjer er indarbejdet i statens business case-model, der understøtter alle typer
af projekter og programmer.
2.4 Princip 4: Afgræsning
Den fællesstatslige it-projektmodel vil gerne understøtte, at it-projekter påbegyndes med
stillingtagen til en realistisk afgrænsning af projektet. Herved forhindres, at nogle projekter
bliver omfangsrige og gaber over for mange og for store leverancer. Sådanne projekter er
svært styrbare, og ender i store overskridelser i forhold til de oprindelige estimater.
Afgrænsning af projekter handler om, at projektet fra starten minimeres i omfang og kompleksitet. En ikke helt triviel øvelse, som kræver beslutningskraft og evne til på et tidligt
tidspunkt at kunne holde fokus på de vigtigste forretningsmål.
2.5 Princip 5: Modenhed
Det femte princip skal sikre, at den nødvendige projektmodenhed er til stede i de enkelte itprojekter. Det er afgørende, at myndigheden tager aktivt ansvar herfor.
Projektet skal udføres og organiseres under hensyntagen til myndighedens projektmodenhed.
Princippet skal også bidrage til tværgående læring og videndeling.
Det forudsætter blandt andet, at der anvendes fælles metoder og værktøjer, som det er tilfældet med nærværende model for statslige it-projekter.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[7]
3 Den fællesstatslige itprojektmodel
I dette kapitel gives en overordnet introduktion til indholdet af den fællesstatslige itprojektmodel.
Den fællesstatslige it-projektmodel er en generel projektmodel, beregnet for anvendelse på
alle statslige it-projekter. Modellen omfatter overordnet set:
-
En model for faseopdeling af projektforløbet
Principper for overgang fra en fase til næste fase
Et antal ledelsesprodukter og skabeloner hertil (også kaldet produkter)
Beskrivelser af roller og ansvar
Endelig er der udarbejdet en række værktøjer og vejledninger til understøttelse af projektforløb og anvendelse af produkterne. Produkter, værktøjer og vejledninger er tilgængeligt på
Digitaliseringsstyrelsens hjemmeside.
3.1 Fasemodellen
It-projektmodellen indeholder en fasemodel hvor resultatet af hver fase er produkter, som
støtter styringen af projektet hen imod projektets samlede leverancer. Faseopdelingen består
af hovedfaser og ledelsesfaser og understøtter princip 4 om minimering af kompleksitet og
omfang.
Figur 1. Den fællesstatslige it-projektmodel.
It-projektmodellen indeholder fem hovedfaser:
-
Idéfase: Ideen kvalificeres og udmøntes i et projektgrundlag.
Analysefase: Projektet defineres og beskrives i PID’en med tilhørende business case og
evt. styregruppeaftale og risikotjekliste til It-projektrådet.
Anskaffelsesfase: Specificering af krav og behov samt gennemførelse af anskaffelsesproces – typisk via udbud.
Gennemførselsfase: Kontrakter underskrives, og projektets leverancer realiseres. Fasen løber frem til systemet er idriftsat og implementeret organisatorisk.
Realiseringsfase: Business casen realiseres, og gevinsterne hjemtages.
Den fællesstatslige it-projektmodel skal bidrage til bedre og mere ensartet planlægning, styring
og gennemførelse af statslige it-projekter.
Alle it-projekter opdeles i udgangspunktet i disse fem hovedfaser. Det anbefales at opdele
projektet i ledelsesfaser, hvis faserne strækker sig over lang tid, eller indeholder store, udgiftstunge aktiviteter. For det enkelte projekt skal styregruppen tage stilling til, om den konkrete tilpasning af modellen, herunder projektets faseinddeling, er hensigtsmæssig og giver
den nødvendige styring. Den endelige anvendelse af faser for det aktuelle projekt dokumenteres i PID’en.
Idéfasen og realiseringsfasen drives primært af forretningen, hvilket er vist i figuren ved den
mørkere farve af faserne. De mellemliggende faser drives af projektet – af projektlederen og
styregruppen. For at sikre beslutningspunkter og styregruppens stillingtagen til kritiske milepæle i projektet må hovedfaserne ikke overlappe hinanden. Såfremt der er tale om sekventiDen fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[8]
elle delprojekter, opgøres hovedfaserne som et gennemsnit ift. aktiviteterne og delprojekterne beskrives i større detailgrad i PID’en. Se mere om de enkelte faser i afsnit 4.
Den fællesstatslige it-projektmodel er en generisk ramme for statslige it-projekter. En af projektlederens fremmeste opgaver er derfor at tilpasse modellen til det aktuelle projekt, så brugen af
modellen er hensigtsmæssig og giver den nødvendige styring.
Inden igangsættelse af anskaffelsesfasen skal projektet, hvis projektbudgettet inkl. interne
lønomkostninger er over 10 mio. kr. forelægges for It-projektrådet. Se mere om risikovurdering hos It-projektrådet.
Alle it-projekter over 10 mio. kr. skal endvidere hvert halve år, indtil overgangen til drift,
statusrapportere på fremdrift til It-projektrådet. It-projektrådet udarbejder herefter en samlet oversigt over alle større statslige it-projekter. Oversigten offentliggøres på rådets hjemmeside. Når projekterne afsluttes sendes projektafslutningsrapport til rådet.
3.2 Ledelsesfaser
En ledelsesfase er en sammenhængende og styrbar delmængde af aktiviteter og leverancer
inden for en hovedfase. Den indledes og afsluttes med en styregruppebeslutning.
Enhver hovedfase i it-projektmodellen kan inddeles i flere faser, kaldet ledelsesfaser.
Formålet med en ledelsesfase er at sikre styringsgrundlaget og at opnå klare beslutningspunkter.
Et projekts ledelsesfaser fastlægges ved projektets start, og de må ikke gå på tværs af hovedfaserne i den fællesstatslige it-projektmodel. Der kan være forskellige årsager til, at
det giver mening at inddele én eller flere af modellens fem faser i flere ledelsesfaser, eksempelvis:
-
Et skift i projektets karakter: Fx mellem udvikling og test i gennemførelsesfasen.
Udstrækning i tid: En fase bør ikke have en udstrækning på mere end 3-6 måneder,
defineret som et antal sprint i en agil udviklingsmodel.
Organisatoriske: Implementering i forskellige dele af organisationen.
For projekter med et budget over 60 mio. kr. er det obligatorisk at inddele anskaffelsesfasen i to
ledelsesfaser, nemlig i en specificerings- og en udbudsfase.
Faseovergange mellem ledelsesfaser følger som nævnt ovenfor de generelle regler for faseovergange (se følgende afsnit).
3.3 Faseovergange
En faseovergang markerer et skift i projektets tilstand. Det gælder også for overgangen mellem to ledelsesfaser.
Figur 2. Faseovergange i den fællesstatslige it-projektmodel.
Det er styregruppens ansvar at godkende grundlaget for faseovergangen og beslutte, om
projektet er klar til at gå til næste fase. For at projektet kan fortsætte til næste fase skal PID
og business case foreligge i opdateret og godkendt tilstand. For overgangen mellem gennemførelsesfasen til realiseringsfasen, skal projektafslutningsrapporten foreligge på samme vis.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[9]
Udover de godkendte ledelsesprodukter skal projektlederen overfor styregruppen dokumentere aktiviteterne i den forgangne fase, præsentere en plan og leveranceoversigt for den
kommende fase, samt give et opdateret indblik i projektets samlede økonomi. Styringsværktøjet faseovergangsrapport kan anvendes. Værktøjet indeholder en plan for den kommende
fase og oversigt over resultaterne af den aktuelt afsluttede fase.
3.4 Ledelsesprodukter
Et ledelsesprodukt i it-projektmodellen understøtter styring og beslutninger i projektforløbet.
Der er knyttet en række ledelsesprodukter til it-projektmodellen, som produceres undervejs i
projektforløbet, se figuren nedenfor.
Figur 3. Den fællesstatslige it-projektmodel inkl. ledelsesprodukter.
I den fællesstatslige it-projektmodel findes to bærende ledelsesprodukter: PID og business
case. Disse to produkter indeholder den væsentligste information om projektet og bruges
igennem hele projektforløbet.
For projekter med budget over 10 mio. kr. skal ledelsesprodukterne PID og business case samt
værktøjerne styregruppeaftale, risikotjekliste og It-projektrådets cover anvendes ved risikovurdering hos It-projektrådet.
Der er krav om, at alle it-projekter skal lave vurderinger informationssikkerheden af informationsaktivet og it-løsningen i analysefasen. Informationsaktivet er den information (data),
som skal behandles af it-løsningen, og som skal sikres. Vurderingerne laves via to produkter,
en konsekvensvurdering af privatlivet (PIA) og en sikkerhedsmæssig risikovurdering, hvoraf
det ene, PIA, kan udelades, såfremt it-løsningen ikke skal behandle personoplysninger. Resultaterne af vurderingerne dokumenteres i PID og PID’en produktbilag C: Risikoregisteret.
Der er krav om, at projektet gennemfører relevante tests, herunder bruger- og brugervenlighedstests, i gennemførelsesfasen, og at planlægningen af dette dokumenteres i PID, og
gennemførelsen af tests dokumenteres i projektafslutningsrapporten. Udover ledelsesprodukterne anbefales det, at projektet gør brug af en række andre værktøjer undervejs i projektforløbet. Eksempelvis kan det give stor værdi at udarbejde en interessentanalyse eller en
kommunikationsplan. Disse vil generelt styrke planlægningen og styringen af projektet.
Ministeriernes projektkontor i Digitaliseringsstyrelsen udarbejder værktøjer, der understøtter
dette arbejde, og som kan hentes via Digitaliseringsstyrelsens hjemmeside. Ledelsesprodukter og værktøjer er yderligere beskrevet i afsnit 5 og 6.
3.5 Roller og ansvar
Ansvaret for ledelse og styring i de fem hovedfaser er forankret forskellige steder i organisationen. For at sikre, at ansvaret for beslutninger, ledelse og styring er forankret de rigtige
steder, indeholder it-projektmodellen et sæt standardroller og ansvarsbeskrivelse.
Projektleder og styregruppe kan tage udgangspunkt i standardrollerne ved design af projektorganisationen og bemanding af projektet, se yderligere i afsnit 7 samt på Digitaliseringsstyrelsens hjemmeside.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[10]
4 Faser
De fem hovedfaser i den fællesstatslige it-projektmodel præsenteres. For hver hovedfase
skitseres grundlaget for opstart af fasen, hvilke af de fem principper for statslige it-projekter,
der skal bringes i anvendelse under fasen, samt kriterier for overgang til næste fase. Endelig
listes ledelsesprodukter og relevante værktøjer og vejledninger.
4.1 Idéfasen
Idéfasen er den første fase i et projektforløb. Formålet med fasen er at undersøge, om ideen
er bæredygtig. Ledelsen (forretningen) tager stilling til, om der skal bruges ressourcer på at
gå videre til analysefasen og danne projektorganisationen. Ejerskabet for idefasen ligger hos
forretningen – det er her behovet, og efterfølgende ideen, til projektet opstår.
Figur 4. Idéfasen.
Idéfasen gennemføres, før projektet formelt er etableret. Den starter typisk på baggrund af
en forventning om enten at kunne effektivisere arbejdsgange, styrke kvaliteten af en service,
eller fordi der er stillet krav om implementering af ny lovgivning.
I idéfasen gennemføres en første analyse af, om ideen kan resultere i et bæredygtigt itprojekt. Det undersøges hvilke gevinster, der forventes, og der laves et overslag over projektets udgifter. Endelig redegøres for ressourcer ifbm. at analysere idéen nærmere i analysefasen. Dette er grundlaget for ledelsens beslutning om der skal overgås til analysefasen og
etableres et projekt.
Resultatet af idéfasen beskrives i et projektgrundlag. Det er en god idé også at arbejde med
business casen, især forudsætningsdiagrammet, der er en del af den. Diagrammet giver et
godt overblik over projektets samlede udgifter og over mulige gevinster.
Fasen afsluttes ved, at faseovergangsrapporten afleveres til projektejer / styregruppeformand til godkendelse.
4.2 Analysefasen
Formålet med analysefasen er at analysere indhold, omfang og ressourcer i it-projektet. På
denne baggrund beslutter styregruppen, om der skal fortsættes til anskaffelsesfasen. Ejerskabet for analysefasen ligger hos projektet.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[11]
Analysefasen bygger videre på projektgrundlaget og evt. udkast til business case, hvor der
her foretages en grundig og detaljeret analyse af projektets omfang, kravene til ressourcer,
udgifter, mulige gevinster, tidsplan, risici, kvalitet, etc.
Projekter med budget over 10 mio. kr. skal risikovurderes af It-projektrådet inden overgangen til anskaffelsesfasen.
Et væsentligt element i analysefasen er afdækning af informationssikkerheden. Alle itprojekter skal lave vurderinger af informationssikkerheden af informationsaktivet og itløsningen i analysefasen. Informationsaktivet er den information (data), som skal behandles
af it-løsningen, og som skal sikres. Vurderingerne laves ved hjælp af to produkter, en konsekvensvurdering af privatlivet (PIA) og en sikkerhedsmæssig risikovurdering, hvoraf det ene,
PIA, kan udelades, såfremt it-løsningen ikke skal behandle personoplysninger.
Personoplysninger forstås ved enhver information om et fysisk individ, som er identificeret
eller er identificerbar.
Resultaterne af vurderingerne dokumenteres i PID og PID’en produktbilag C: Risikoregisteret. Der henvises til vejledningen til PID’en for hjælp, vejledning og referencer i forhold til
gennemførelse af PIA og sikkerhedsmæssig risikovurdering.
PID’en sammenfatter alle analyser, udstikker projektets kurs og omfang og fungerer som
kontrakt mellem projektleder og styregruppe. Projektlederen udpeges senest i analysefasen,
og har ansvar for at tilpasse it-projektmodellen til projektet, for at tage initiativ til at få
sammensat projektorganisationen, for at gennemføre analyser og for at samle alle de bidrag,
der er nødvendige for at skabe styringsgrundlaget for et vellykket projekt. Det er et omfattende arbejde, som involverer mange mennesker med forskellig ekspertise fx forretning,
økonomi, arbejdsgange og it.
Figur 5. Analysefasen.
4.3 Anskaffelsesfasen
I denne fase beskrives behov og krav til det nye it-system og at gennemføre anskaffelsen
frem til det tidspunkt, hvor kontrakten er klar til underskrift. Ejerskabet for anskaffelsesfasen
ligger hos projektet.
Arbejdet omfatter forberedelse og gennemførelse af udbud. Under forberedelsen vælges
udbudsstrategi og behovene specificeres i kravspecifikationen. Under gennemførelsen af
udbuddet gøres udbudsmaterialet færdigt, udbuddet offentliggøres og indkomne tilbud vurderes, således at kontrakten med den valgte leverandør kan underskrives, så snart styregruppen godkender overgang til gennemførelsesfasen.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[12]
I anskaffelsesfasen er der mange kompetencer i spil: Fremtidige brugere, forretningen, som
skal realisere gevinsterne, it-arkitekter og jurister.
Hvis budgettet for it-projektet er større end 60 mio. kr. skal anskaffelsesfasen inddeles i to
ledelsesfaser, specificerings- og udbudsfasen. Herudover skal projektet forelægges Finansudvalget, efter det er behandlet af It-projektrådet, før offentliggørelsen af udbuddet.
Figur 6. Anskaffelsesfasen.
4.4 Gennemførelsesfasen
Det første skridt i denne fase er at underskrive kontrakten med leverandøren. Når kontrakten er underskrevet, starter samarbejdet med leverandøren om at designe, udvikle og teste
it-systemet. Den fællesstatslige it-projektmodel stiller krav om, at der gennemføres relevante tests i gennemførelsesfasen. Værktøjet test, kan anvendes som inspiration til planlægning
og udførelse af tests. Det er også i denne fase, at de første gevinster typisk kan høstes, da
fasen også indeholder implementering af it-systemet, uddannelse af brugerne, overdragelse
til drift og forretning og endelig afslutning af projektet. Ejerskabet for gennemførelsesfasen
ligger hos projektet.
Figur 7. Gennemførelsesfasen.
Gennemførelsesfasen omfatter idriftsættelsen af it-systemet, hvilket er defineret ved, at
endelig overtagelsesprøve fra leverandør bestås. Driftsudgifter i forbindelse med it-systemet
vil derfor også herefter skulle henføres til driften i business casen. Projektet kan imidlertid
stadig indeholde en række aktiviteter, fx udrulning af systemet til brugerne, brugeruddannelse og projektevaluering. Udgifter til disse aktiviteter henføres stadig til projektet.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[13]
Ofte tales der i projekter både om idriftsættelsen af et system og om projektafslutning –
uden at termerne er helt klare. Boksene definerer hhv. hvornår der er tale om idriftsættelse
af et system, og hvornår der er tale om projektafslutning. Projektafslutning markerer altid
overgangen mellem gennemførelsesfasen og realiseringsfasen. Idriftsættelsen af it-systemet
sker typisk i gennemførelsesfasen. Der kan derfor også sagtens påbegyndes realisering af
gevinster i gennemførelsesfasen.
Idriftsættelse af it-system:
-
Endelig overtagelsesprøve med leverandør bestået.
Sker i gennemførelsesfasen.
Systemudgifter konteres efter overtagelsesprøve på
driften.
Der eksisterer typisk stadig en projektorganisation og
projektaktiviteter som organisatorisk udrulning, uddannelse, evaluering og projektafslutning. Udgifter til
disse aktiviteter henføres til projektet.
Projektafslutning:
-
-
Alle projektaktiviteter er udført eller
overdraget.
Projektorganisation opløses, og der
kan herefter ikke konteres projektrelaterede udgifter.
Markerer overgangen mellem gennemførelsesfasen og realiseringsfasen.
Som sagt markerer overgangen fra gennemførelsesfasen til realiseringsfasen afslutningen på
projektet, hvortil også projektafslutningsrapporten udarbejdes. I realiseringsfasen vil der
derfor ikke være projektrelaterede udgifter.
Gennemførelsesfasen er den fase, der typisk varer længst tid og
kræver mest af projektlederen. Denne hovedfase kan derfor med
fordel opdeles i ledelsesfaser, uanset om der anvendes en vandfaldsmodel eller en agil udviklingsmodel. Når projektet er afsluttet, skal kunde-leverandørsamarbejdet evalueres, og resultaterne
indsendes sammen med projektafslutningsrapporten til Ministeriernes projektkontor i Digitaliseringsstyrelsen.
I gennemførelsesfasen
er det ofte en fordel at
udvide styregruppen
med en seniorleverandør.
4.5 Realiseringsfasen
I denne fase skal de gevinster, der er beskrevet i projektets business case, realiseres. Realiseringsfasen ejes af forretningen, ligesom idéfasen. Det er forretningens opgave at forankre
it-systemet i organisationen og høste gevinsterne.
Til at følge op på gevinstrealisering anvendes gevinstrealiseringsrapporten, der dokumenterer, om gevinstrealisering har fundet sted som planlagt. Har projektet et budget på over 10
mio. kr., skal gevinstrealiseringsrapporten indsendes til It-projektrådet et år efter projektafslutning. Forretningens ledelse godkender gevinstrealiseringsrapporten.
Figur 8. Realiseringsfasen.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[14]
5 Ledelsesprodukter
I dette afsnit gennemgås de fem ledelsesprodukter i den fællesstatslige it-projektmodel.
Den fællesstatslige it-projektmodel indeholder fem forskellige ledelsesprodukter, hvoraf PID
og business case kan sige at være de bærende produkter for projektudførslen. For disse to
produkter gælder, at dokumenterne skal opdateres ved hver faseovergang.
Formålet med produkterne er at understøtte især projektlederens arbejde undervejs i projektet, samt bidrag til at sikre, at projektet planlægges bedst muligt. Produkterne kan ses i nedenstående figur.
Figur 9. Den fællesstatslige it-projektmodel inkl. ledelsesprodukter.
Myndigheden kan frit tilføje afsnit eller udskille afsnit fra PID’en i selvstændige dokumenter,
såfremt dette er nødvendigt. Ligeledes kan det udelades at udfylde afsnit i PID’en, i stedet
skrives blot en kort begrundelse under det pågældende afsnit.
Ledelsesprodukterne bør, som den fællesstatslige it-projektmodel som helhed, tilpasses det
aktuelle projekt, så brugen er hensigtsmæssig og understøtter den nødvendige styring.
For projekter med budget over 10 mio. kr. er risikovurderingen hos It-projektrådet baseret
på indsendelse af ledelsesprodukterne PID og business case samt værktøjerne styregruppeaftale og risikotjekliste. Produkterne er beskrevet enkeltvis efterfølgende og der henvises i
øvrigt til produkternes særskilte vejledninger, der kan hentes på Digitaliseringsstyrelsens
hjemmeside.
5.1 Projektgrundlag
Projektgrundlaget skal sikre, at forretningen får et tilstrækkeligt grundlag at vurdere projektets berettigelse på inden analysefasen.
Dokumentet skitserer kort de overordnede rammer for det kommende projekt samt forventninger til projektets konsekvenser, udgifter, ressourceforbrug og gevinster.
Ansvaret for udarbejdelse af projektgrundlaget ligger hos projektejeren / styregruppeformand og udarbejdes i idéfasen. Projektgrundlaget godkendes af forretningen, typisk på direktionsniveau for store projekter. Godkendes projektgrundlaget erstattes dette af PID’en i
analysefasen.
5.2 Projektinitieringsdokument (PID)
PID'en samler de oplysninger og analyser, der er nødvendige for at starte og drive et projekt
på et forsvarligt grundlag. PID’en består af følgende hoveddele:
-
Forretningens formål med projektet: Hvorfor igangsættes projektet, hvad indeholder det,
hvordan vil det påvirke og bidrage til forretningen?
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[15]
-
Scope og afgræsning: Hvad omfatter projektet ikke?
Mål og succeskriterier: Hvilket mål skal nås med projektet, hvad er succeskriterier for at
opnå mål og dermed projektets succesfulde udførelse?
Økonomiske hovedtal og finansiering: Projektudgifter og kilde til finansiering
Gevinster: Hvad får forretningen ud af projektet? Opgjort på kvantitative, målbare gevinster
Teknisk løsning: Beskrivelse af den tekniske løsning, som skal udvikles og implementeres
Leverancer og afhængigheder: Liste og beskrivelse af projektets leverancer
Organisering: Projektorganisation og tildeling af roller/ansvar
Tilrettelæggelse og tidsplan: Hvornår udføres projektet, hvornår høstes gevinster?
Kvalitet: Hvilken kvalitet skal leverancer have og hvordan sikres dette?
Risici: Hvilken risikostrategi antager myndigheden i projektet?
Informationssikkerhed: Hvordan sikres it-løsningen? Er der gennemført sikkerhedsmæssig risikovurdering og evt. PIA?
Interessenter: Kort skitse over projektets væsentligste interessenter og deres håndtering.
Kommunikation: Strategi og budskaber i kommunikation i og fra projektet
Tolerancer: Hvilke tolerancer kan projektleder og styregruppe agere indenfor?
I tillæg til ovenstående indeholder PID’en tre produktbilag:
-
Bilag A: Gevinstdiagram – her udarbejdes en grafisk oversigt over gevinster i projektet,
samt hvordan disse forholder sig til formål, leverancer og resultater
Bilag B: Gevinstdetaljer - i dette bilag opgøres detaljeret for den enkelte gevinst omfanget af gevinsten, prioritering, type, interessenter samt målepunkter, mv.
Bilag C: Risikoregister – liste over risici i projektet, deres sandsynlighed, vurdering, konsekvens og effekt, samt forventede tiltag til håndtering
Indholdet i PID’en er i skabelonen tilrettelagt efter typiske projekter og skal tilpasses det
aktuelle projekt. Det er således muligt både at udelade at udfylde afsnit samt tilføje nye afsnit, hvis det er relevant for det pågældende projekt. Udelades det at udfylde afsnit begrundes dette kort under den pågældende overskrift.
PID'en udarbejdes i analysefasen på baggrund af projektgrundlaget og fungerer som en
baseline, som projektlederen og styregruppen kan bruge som baggrund for at vurdere fremdriften i projektet. På denne vis kan PID’en også opfattes som en kontrakt mellem styregruppen og projektlederen.
Projektlederen er ansvarlig for udarbejdelse af PID samt vedligeholdelse og opdatering. Som
minimum skal PID’en opdateres ved hver faseovergang.
5.3 Business case
Business casen udgør sammen med PID’en det centrale styringsgrundlag i den fællesstatslige
it-projektmodel.
En business case er en beregning af de samlede økonomiske konsekvenser af en potentiel
investering, såsom et projekt eller et program. Den bygger på en analyse og opgørelse af,
hvilken forandring man ønsker, og hvordan den opnås. Formålet med statens business casemodel er således at beregne konsekvenserne af den planlagte investering, som myndigheden
står overfor. Business casen er et meget vigtigt beslutningsgrundlag. Business casen opdateres ved hver faseovergang.
Projektlederen er ansvarlig for at samle information til business casen, evt. sammen med en
økonomimedarbejder. Business casen udarbejdes i analysefasen, men udkast til forudsætningsdiagram og regneark kan med fordel påbegyndes i idéfasen.
5.4 Projektafslutningsrapport
Projektafslutningsrapporten skal sikre, at der sker en rapportering af, hvordan projektet er
gennemført målt på økonomi og resultat, samt hvilken læring der er sket. Indholdet af projektafslutningsrapporten følger indholdet af PID’en med tillæg af et væsentligt afsnit om læring og videndeling forårsaget som følge af projektet. Rapporten skal give styregruppen et
grundlag for at beslutte, om projektet skal afsluttes.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[16]
Dokumentet er projektlederens rapport til styregruppen ved projektets afslutning om, hvordan projektet har klaret sig i forhold til senest godkendte PID. Projektets egen evaluering af
projektforløbet fremgår også af rapporten.
Projektlederen er ansvarlig for udarbejdelse af rapporten, og efter godkendelse opløses projektorganisationen og projektleverancerne overdrages til forretningen. For projekter med
budget over 10 mio. kr. skal projektafslutningsrapporten indsendes sammen med evaluering
af kunde-leverandør samarbejdet til It-projektrådet.
Projektafslutningsrapporten udarbejdes som den sidste aktivitet i projektet i slutningen af gennemførelsesfasen før endelig overgang til realiseringsfasen.
5.5 Gevinstrealiseringsrapport
Gevinstrealiseringsrapporten er det dokument, hvori seniorbrugeren dokumenterer, hvordan
det er gået med realisering af alle business casens gevinster (såvel økonomiske som ikkeøkonomiske). Gevinstrealiseringsrapporten består af en overordnet konklusion på høsten af
projektets gevinster, samt en detaljeret opfølgning på alle gevinster listet i projektets PID,
samt produktbilag A og B.
Rapporten viser, om gevinsterne er realiseret på niveau med eller bedre end specificeret i
PID’en– og hvis det ikke er tilfældet, skal afvigelsen forklares i rapporten.
Seniorbrugeren har ansvaret for udarbejdelse af gevinstrealiseringsrapporten, der som minimum anbefales udarbejdet et år efter projektets afslutning. Høster projektet gevinster
længere tid efter projektets afslutning bør gevinstrealiseringsrapporten opdateres løbende
efter aftalt frekvens.
Har projektet et budget på over 10 mio. kr. skal gevinstrealiseringsrapporten indsendes til
It-projektrådet et år efter projektets idriftsættelse.
Gevinstmålinger skal typisk fortsættes ud over det første år efter projektafslutning, da en del af
gevinsterne først realiseres senere.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[17]
6 Værktøjer
Til understøttelse af arbejdet med projekter under den fællesstatslige it-projektmodel er der
udarbejdet en række værktøjer. I nærværende afsnit gennemgås de fem mest centrale
værktøjer.
Under udarbejdelse af især de to primære ledelsesprodukter – PID og business case, vil projektlederen skulle indhente information fra organisationen og gennemføre et antal analyser.
Ministeriernes projektkontor udarbejder og vedligeholder en række værktøjer, som kan assistere projektlederen og projektorganisationen i dette arbejde.
Fem af disse værktøjer ses som centrale for den fællesstatslige it-projektmodel. To er styringsværktøjer, dels til styring af faseovergange, dels til styring af afvigelser. Hertil fremhæves værktøjet risikotjekliste, der bidrager til identifikation og belysning af risici, samt værktøjet styregruppeaftale. For projekter med budget over 10. mio. kr. skal disse to værktøjer
indsendes til It-projektrådet ved risikovurdering. Endelig er slutevalueringen af kundeleverandør samarbejdet en væsentlig komponent til arbejdet med at fremme samarbejde og
videndeling på tværs af staten. Evaluering af kunde-leverandør samarbejdet skal derfor for
projekter med budget over 10 mio. kr. indsendes til It-projektrådet i forbindelse med projektafslutning.
De nævnte værktøjer er gennemgået efterfølgende. For en komplet liste og download af
vejledninger og skabeloner for værktøjer henvises til Digitaliseringsstyrelsens hjemmeside.
6.1 Faseovergangsrapport
Faseovergangsrapporten bruges ved hver faseovergang – uanset om det er mellem de fem
faser i den fællesstatslige it-projektmodel eller mellem ledelsesfaser. Rapporten skal informere styregruppen om projektets status, så den kan beslutte, hvorvidt og hvordan projektet
skal fortsættes.
Faseovergangsrapporten er en status over den afsluttede fase samt et beslutningsoplæg med
plan for den kommende fase, og den angiver produkter, milepæle og risici. Endelig findes en
sektion, der beskriver projektets økonomi.
Faseovergangsrapporten skal indeholde tilstrækkelige oplysninger til, at styregruppen kan
træffe beslutning om, hvad der videre skal ske i projektet, og den udarbejdes af projektlederen.
6.2 Afvigelsesanmodning
Formålet med afvigelsesanmodningen er at sikre en ensartet styring af de situationer, hvor
afvigelser eller ændringer i projektet skal håndteres og kræver styregruppegodkendelse.
Anmodningen giver styregruppen det fornødne beslutningsgrundlag til at godkende eller afvise
afvigelser og ændringer i projektet, der påvirker tid, økonomi eller scope.
En afvigelsesanmodning indeholder beskrivelse af og begrundelse for, hvorfor der er opstået
en afvigelse (i scope, tid, ressourcer eller leverancekvalitet) i forhold til senest godkendte
PID og de tolerancer, der er tildelt projektlederen. Samtidig indeholder den en beskrivelse af
hvilke konsekvenser, afvigelsen har for projektet.
Afvigelsesanmodningen indeholder også projektlederens indstilling til, hvad styregruppen
anmodes om at godkende.
Projektlederen har ansvaret for udarbejdelse af afvigelsesanmodningen, herunder dens indhold og anbefalinger. Afvigelsesanmodninger bruges typisk i analyse-, anskaffelses- og gen-
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[18]
nemførelsesfasen, når det konstateres, at der er risiko for, at projektet bliver påvirket i et
omfang, der overstiger de tolerancer, der er tildelt projektlederen.
6.3 Risikotjekliste
Risikotjeklisten er et værktøj, udarbejdet på basis af erfaringerne fra risikovurderingerne i
regi af It-projektrådet. Formålet er at bidrage til identifikation af risici i myndighedens projekt.
Arbejdet med risikotjeklisten kan derved bidrage til at identificere og udfylde oplysninger om
risici i risikoregisteret – PID’ens produktbilag C. Risikotjeklisten bør udfyldes af dem med
størst indsigt i projektet, og der kan derfor sagtens være flere personer, der deltager i udfyldelsen af tjeklisten. Som udgangspunkt er det dog projektlederen, der har ansvaret for at
samle input til risikotjeklisten.
Såfremt projektet har et budget over 10 mio. kr., skal risikotjeklisten indsendes sammen
med PID og business case forud for risikovurdering hos It-projektrådet. Er dette tilfældet
skal listen, på samme vis som de øvrige produkter, kvalitetssikres og godkendes af projektejer på direktionsniveau.
6.4 Styregruppeaftale
Styregruppeaftalen udarbejdes når styregruppen nedsættes, typisk faciliteret af styregruppeformand og projektleder på kick-off mødet. Formålet med styregruppeaftalen er kort at definere gruppens mandat, beføjelser og ansvar – både som gruppe og individuelt ift. det pågældende projekt. Styregruppeaftalen underskrives af alle styregruppemedlemmer.
6.5 Slutevaluering
It-projektrådet har taget initiativ til evalueringen, da rådet ønsker at skabe større åbenhed
om statslige myndigheders såvel som it-leverandørers erfaringer med projektsamarbejdet i
statslige it-projekter. Oplysningerne fra skemaet vil blive offentliggjort på rådets hjemmeside.
Slutevalueringen er et skema til at samle op på erfaringerne fra de gennemførte it-projekter, så
kunde-leverandørsamarbejdet fremadrettet styrkes.
Både myndighed og leverandør skal udfylde skemaet. Har projektet et budget over 10 mio.
kr. skal det indsendes til It-projektrådet sammen med projektafslutningsrapporten.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[19]
7 Roller og ansvar
For at sikre et vellykket it-projekt er det vigtigt, at alle med tilknytning til et projekt ved,
hvem der har ansvar for hvilke opgaver og beslutninger i projektet. For at sikre, at ansvaret
for beslutninger, ledelse og styring er forankret de rigtige steder, indeholder itprojektmodellen et sæt standardroller og ansvarsbeskrivelse, gennemgået i dette afsnit.
En rolle er ikke per definition lig en konkret person. En rolle er en beskrivelse af de kompetencer, der skal til for at udfylde en bestemt funktion, det ansvar og de typiske opgaver, der
følger med. Én person kan godt varetage flere roller.
Den fællesstatslige it-projektmodel omfatter beskrivelser af de roller, der er mest relevante
for projekter i staten. Beskrivelsen af den enkelte rolle i den fællesstatslige it-projektmodel
er vejledende og bør tilpasses myndighedens organisation og projekt. Rollerne er i vid udstrækning afstemt med rolle- og ansvarsfordeling i projekter fra PRINCE2.
7.1 Projektorganisering i tre niveauer
Organisationsstrukturen i projekter kan konceptuelt inddeles i tre niveauer: Ledelsesniveauet, styringsniveauet og det udførende niveau. Dette er illustreret i figuren nedenfor.
Figur 9. Projektorganisering.
Uden for projektet er direktionen, m.fl. ansvarlig for at rekvirere projektet, udpege styregruppeformanden og fastlægge de tolerancer, styregruppen skal arbejde indenfor.
På ledelsesniveauet udstikkes rammerne for projektet. Det er på dette niveau ressourcer,
planer, overgang til næste fase og evt. afvigelser godkendes. På styringsniveauet ligger ansvaret for at levere de krævede produkter i overensstemmelse med projektets mål for tid,
budget, kvalitet, etc. Det udførende niveau har ansvaret for at levere de enkelte produkter i
en kvalitet, der svarer til det krævede og inden for rammerne af tidsplan og budget.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[20]
Det anbefales, at projektorganiseringen sker i tre niveauer, som angivet i figur 9. Roller og
ansvar på de tre niveauer er beskrevet efterfølgende.
7.2 Roller
Rolle
Udenfor projektet
Ledelse (linjeorganisation, fx direktion)
Ansvar
Fastlægger politikken og rammerne for projektet, herunder bl.a. organisationens risikovillighed, tolerancer og eskaleringsprocesser. Overordnet ansvarlig for alle projekter.
Ledelsesniveauet
Styregruppeformand
-
Seniorbruger
Seniorleverandør
-
Referencegruppe
Ændringsforum
-
Styringsniveauet
Projektleder
-
-
-
Primær beslutningstager i projektet
Sikrer nødvendige rammebetingelser for projektet (sammen med styregruppen) samt
sikrer fokus og retning for projektet
Udarbejder projektoplæg
Business case og herunder også gevinstrealisering
Kvalitetssikring ift. projektets forretningsinteresser (at projektet kan overholde tid og
økonomi samt levere et slutprodukt, der kan anvendes til at realisere gevinsterne)
Balancering af organisationens, brugerens og leverandørens krav
Sparring/mentoring af projektlederen
Definerer forventninger/krav til projektets slutprodukt, og dermed projektets omfang
Definerer og prioriterer godkendelseskriterier på projektniveau
Sikrer at kravene til projektets leverancer beskrives ordentligt (kvalitet)
Sikrer at kravene beskriver det rigtige – og at det, der bedes om, er både nødvendigt
og tilstrækkeligt til at realisere gevinsterne
Sikrer at de mulige gevinster identificeres og beskrives
Opretholder forretningsmæssig stabilitet ved overgang fra projekt til almindelig drift
Implementering og idriftsættelse, herunder ansvar for forandringsledelse
Bistår projektlederen med udarbejdelsen af en PID, særligt omkring gevinster
Sikrer nødvendige ændringer i forretningen, så gevinsterne realiseres
Dokumenterer at gevinsterne er opnået
Udarbejder gevinstrealiseringsrapport
Proaktiv orientering af den øvrige styregruppe og ledelse om forhold hos leverandøren (både for interne og eksterne leverandører), som kan påvirke projektet
Sikrer realisme i design og udvikling af projektets produkter
Sikrer at de nødvendige interne og eksterne leverandørressourcer (kompetencer)
stilles til rådighed
Træffer beslutninger om passende procedure til at sikre produkternes kvalitet
Sikrer at kvalitetsprocedurer anvendes korrekt, så produktet overholder kravene
Rådgiver om metoder til design, udvikling og godkendelse
Træffer beslutninger om problemer vedr. produkterne
Løser konflikter der vedrører leverandørkrav
Kvalitetssikrer projektet ift. leverandørens synsvinkel
Rådgiver projektet om nødvendige operationelle beslutninger på alle væsentlige
forretningsmæssige områder
Afvejer forretningens behov i forhold til løsningsmuligheder og øvrige projektbehov
Ser muligheder og udfordrer projektet mht. forretningsmæssige løsninger
Optræder loyalt over for beslutninger i projektet i forhold til eget bagland
Vurderer afvigelser til scope (ændringer)
Indstiller ændringsønsker til styregruppen
Opfølgning på udestående (ikke færdigbehandlede) anmodninger
Sikrer at projektet bliver planlagt, etableret, styret, gennemført, afsluttet og overleveret i henhold til gældende kvalitetssystem, den fællesstatslige it-projektmodel, itarkitektur og standarder samt øvrige krav fra offentlige myndigheder
Styrer projektet i hver fase indenfor de tolerancer, som styregruppen har fastsat
Styrer fremstillingen af produkter og tager ansvar for den overordnede fremdrift
Uddelegerer arbejde til projektdeltagerne og følger op
Udarbejder og opdaterer løbende de ledelsesprodukter, der skal anvendes til at lede
og styre projektet - PID og business case, herunder også kontakt og koordination med
økonomifunktion/projektcontrolller
Styrer projektets medarbejdere, interessenter og samarbejdspartnere frem mod
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[21]
-
leverance af de specificerede produkter til ønsket tid, økonomi og kvalitet – eller alternativt styrer afvigelser herfra
Etablererrollebeskrivelser og rolleallokerer projektdeltagerne samt styrer ressourcer
dagligt
Holder kontakt med eksterne leverandører
Sikrer effektiv risikostyring i projektet
Sikrer information og kommunikation fra projektet, herunder rapportering af status,
afvigelser, problemer og ændringsønsker
Sikrer planlægning af driftsteknisk og forretningsmæssig implementering
Administrerer projektet - ansvar for at projektet etablerer og følger op på projektarkiv
og journalisering af relevant dokumentation
Styrer projektdokumentation – herunder navngivningstandarder og versionering
Fælles standarder, metoder og processer – herunder implementering af eksterne krav
Indsamler data – faktiske og forventede
Opdaterer projektdokumentationen – herunder relevante logs, registre og planer
Bidrager med ekspertviden – inden for projektledelse eller andre discipliner
-
Udfører de aktiviteter, der bidrager til projektets leverancer
Projektsupport,
PMO, eller lign.
Det udførende niveau
Projektdeltagere
Udover ovenstående roller vil langt de fleste it-projekter på det styrende eller udførende
niveau have behov for at have tilknyttet en projektcontroller, forretningsspecialist, testspecialist, it-arkitekt og driftsrepræsentanter. Se yderligere beskrivelse af disse roller i vejledning
om sammensætning af projektorganisationen.
7.3 Fordeling af roller ift. faser
Nedenfor er fasemodellen vist med oplæg til, hvilke projektroller, der med fordel kan anvendes i de respektive faser.
Primære roller, som
skal bemandes
Projektejer /
styregruppeformand
Projektejer / styregruppe-formand
Seniorbruger /
gevinstejer
Seniorleverandør
Projektleder
Forretningsspecialist
Projektejer / styregruppeformand
Seniorbruger / gevinstejer
Seniorleverandør
Projektleder
Forretningsspecialist
Kontraktspecialist
Roller, som bør
bemandes
Projektleder
Projektcontroller
Forandringskonsulent
Arkitekt
Driftsrepræsentanter
Sikkerhedskonsulent
Testspecialist
Projektsupport
Arkitekt
Sikkerhedskonsulent
Driftsrepræsentanter
Ændringsmyndighed
Testspecialist
Forandringskonsulent
Roller, som med
fordel kan bemandes
Projektcontroller
Projektsupport
Projektejer/ styregruppeformand
Seniorbruger / gevinstejer
Seniorleverandør
Projektleder
Forretningsspecialist
Testspecialist
Forandringskonsulent
Arkitekt
Driftsrepræsentanter
Sikkerhedskonsulent
Kontraktspecialist
Ændringsforum
Seniorbruger /
gevinstejer
Forandringskonsulent
Projektcontroller
Projektsupport
Figur 10. Roller ift. den fællesstatslige it-projektmodels faser.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[22]
8 Projekter med budget
over hhv. 10 og 60 mio. kr.
Der stilles særlige krav til projekter med et budget over hhv. 10 mio. kr. og 60 mio. kr. om
brug af produkter, risikovurdering og rapportering. Dette afsnit opsummerer disse krav.
8.1 Projekter med budget over 10. mio. kr.
Har projektet et budget over 10 mio. kr. jf. budgetvejledning 2014, skal projektet:
-
Anvende skabelonerne for ledelsesprodukter til den fællesstatslige it-projektmodel.
Risikovurderes hos It-projektrådet.
Statusrapportere til It-projektrådet hvert halve år.
Rapportere om projektets afslutning.
Rapportere om gevinstrealisering.
8.1.1
Brug af ledelsesprodukter i den fællesstatslige it-projektmodel
For projekter med budget over 10 mio. kr. er det obligatorisk at anvende skabelonerne for
ledelsesprodukterne i den fællesstatslige it-projektmodel.
Alle skabeloner kan hentes på Digitaliseringsstyrelsens hjemmeside.
Projektet skal anvende følgende skabeloner:
-
Projektgrundlag
PID
Business case
Projektafslutningsrapport
Gevinstrealiseringsrapport
Det er altid muligt at kontakte Ministeriernes projektkontor for en introduktion til modellen
og/eller specifikke ledelsesprodukter.
8.1.2
Risikovurdering hos It-projektrådet
It-projektet skal risikovurderes af It-projektrådet inden overgangen til anskaffelsesfasen.
Projektet henvender sig selv til Ministeriernes projektkontor for at fastlægge en dato for risikovurderingen.
Forud for risikovurderingen skal projektet indsende ledelsesprodukterne PID og business
case, samt værktøjerne styregruppeaftale og risikotjekliste til Ministeriernes projektkontor i
Digitaliseringsstyrelsen, hvor det konkrete indhold i dokumenterne aftales i dialog med Ministeriernes projektkontor.
Ministeriernes projektkontor yder rådgivning om anvendelse af den fællesstatslige itprojektmodel, herunder statens business case-model i forbindelse med risikovurderingsforløb.
8.1.3
Rapportering om status hvert halve år til It-projektrådet
Efter et it-projekt er risikovurderet, skal projektet hvert halve år indsende oplysninger om
status for projektet til It-projektrådet. Oplysningerne skal være godkendt af myndighedens
departement. Statusoplysningerne bliver offentliggjort i en rapport på It-projektrådets
hjemmeside, hvis projektet er påbegyndt efter 1. januar 2011. Hvis det er påbegyndt før
2011, offentliggøres det på Digitaliseringsstyrelsens hjemmeside.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[23]
8.1.4
Rapportering om projektets afslutning til It-projektrådet
Når projektet er afsluttet, indsendes projektets direktionsgodkendte projektafslutningsrapport til It-projektrådet sammen med evalueringen af kunde-leverandørsamarbejdet.
8.1.5
Rapportering om gevinstrealisering til It-projektrådet
Et år efter afslutningen af projektet, indsender projektet direktionsgodkendt gevinstrealiseringsrapport til It-projektrådet.
8.2 Projekter med budget over 60 mio. kr.
Hvis it-projektet har et budget til anskaffelse og udvikling (inklusiv internt ressourceforbrug)
på mere end 60 mio. kr. skal det, ud over at følge samme krav som projekter med budget
over 10 mio. kr., forelægges for Finansudvalget.
Projektet skal forelægges Finansudvalget, efter det er blevet risikovurderet af Itprojektrådet, men før udbuddet offentliggøres. Projektet kan afholde udgifter til idéfasen,
analysefasen, kravspecifikation og forberedelse af udbud, før det forelægges Finansudvalget.
Som led i forelæggelsen præsenteres en plan for efterfølgende orienterende aktstykker til
Finansudvalget. Finansudvalget skal som minimum orienteres om:
-
Resultatet af det gennemførte udbud og projektstatus i øvrigt.
Den afsluttede implementering og status for projektet i forbindelse med overgang til
drift.
Drift og effekter ca. et år efter overgangen til drift.
Herudover skal Finansudvalget orienteres ved forsinkelser på mere end tre måneder, eller
hvis der er væsentlige ændringer i business case og risikoscore efter gennemførelsen af udbud og undervejs i gennemførelsesfasen. Se mere om kravene til forelæggelse i Budgetvejledningen, afsnit 2.2.18.3.
8.2.1
Retningslinjer for udfærdigelse af et it-aktstykke
”Retningslinjer for udfærdigelse af it-aktstykker” indeholder en gennemgang af de oplysninger, der typisk skal medtages i et aktstykke til Finansudvalget. Retningslinjerne er et supplement til Budgetvejledning 2014, hvori de generelle krav til aktstykker er fastlagt.
Budgetvejledningens bestemmelser om udformning af aktstykker er nærmere uddybet i relation til de særlige oversigter og oplysninger, der typisk skal medtages i et it-aktstykke. Det
drejer sig navnlig om aktstykkets b-stykke.
Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen
Vejledning om den fællesstatslige it-projektmodel, ver. 2.2
[24]