Den Digitale Taskforces
Projektmodel
Version 3.0 december 2007
Forord fra elektronisk version af projektmodellen til papirversion
Som en del af projektet om ledelse og kompetenceudvikling har Taskforcen i samarbejde med Videnskabsministeriet, Danske Regioner, KL og Finansministeriet udviklet en projektmodel. Taskforcen anbefaler brug af projektmodel i offentlige digitaliseringsprojekter for at understøtte god styring og indfrielse af mål.
Taskforcens projektmodel er målrettet ledere og projektledere i den offentlige sektor, der styrer eller har ansvar for digitaliseringsprojekter. Modellen kan understøtte, at ledere, projektledere og -medarbejdere får et fælles sprog om projekter. Derudover er det ambitionen, at modellen giver et overskueligt værktøj til bedre planlægning, dokumentation og styring af især digitaliseringsprojekter.
Modellen er ikke et forkromet værktøj, der indeholder alle enkeltdetaljer i et projekt. Ambitionen er at tilbyde en light-model, der indeholder helt grundlæggende elementer ud fra devisen, at det gør betydelig forskel at bruge en enkel model frem for slet ingen. Omvendt vil projektmodellen i sin nuværende form kunne være et for omfattende redskab at benytte i sin fulde udstrækning, når det drejer sig om mindre projekter. I de tilfælde anbefales det, at man nøjes med at benytte redskaberne vedrørende projektplan, business case og risikovurdering, og så i øvrigt plukker de elementer fra modellen, som det vurderes, at det vil være hensigtsmæssigt at arbejde med.
Projektmodellen har sin styrke ved at give mange forskellige indgange til den samme information. F.eks. kan den erfarne projektleder gå direkte til de redskaber og skabeloner vedkommende har brug for.
Dette er tredje version af projektmodellen. Modellen er bl.a. blevet opdateret i lyset af, at Taskforcen har udviklet en ny business case model, som det er nyttigt at anvende i projektarbejde af både større og mindre karakter. Projektmodellen vil løbende videreudvikles i takt med, at der indhøstes erfaringer med brugen af den. Du er derfor meget velkommen til at kontakte Taskforcen med kommentarer, spørgsmål, kritik mv. Projektmodellen er til fri afbenyttelse for offentlige myndigheder i Danmark.
God læselyst
Med venlig hilsen
Den Digitale Taskforce
Forord fra elektronisk version af projektmodellen til papirversion
Overblik - projektmodellen struktur og opbygning
Filosofien ved den faseinddelte projektmodel
Grafisk oversigt - Projektmodellens faser og elementer
Styregruppen: projektorganisering og ledelsesbeslutninger
Projektinitieringsdokument (PID)
Dokumenter/redskaber til fase 1: Idebeskrivelsen
Øvrige redskaber til brug til fase 1: idebeskrivelsesfasen
Produktnedbrydning og produktflowdiagram
Fase 2: Analyse- og planlægningsfasen
Dokumenter/redskaber til fase 2: Analyse- og planlægningsfasen
Fase 3: Udviklings- og implementeringsfasen
Dokumenter og redskaber til Fase 3: Udviklings- og implementeringsfasen
Business case - den løbende opdatering
Øvrige redskaber til brug til fase 3: Udviklings- og implementeringsfasen
Diverse metoder til at sikre en brugerorienteret løsning
Fase 4: Afslutning og evaluering- og effektopfølgningsfasen
Dokumenter og redskaber til Fase 4: Afslutning, evaluering og effektopfølgning
Opdatering og evaluering af projektets business case
Bilag til projektmodellen: Flere redskaber
Kick-off seminar: Indførelse af projektmodel
It-arkitektur og teknologi - nogle generelle betragtninger
Overblik - projektmodellen struktur og opbygning
Projektmodellen er opbygget over 4 hovedfaser. Faserne hjælper til at skabe overblik over de forskellige opgaver, der er i projektets levetid i forhold til de forskellige aktører og interessenter. Modellen bidrager til at skabe beslutningsgrundlaget for de ledelsesbeslutninger for projektet, der typisk ligger ved faseovergangene. Inden for hver fase er der undersider og indbyrdes link mellem siderne.
Projektmodellen består i udgangspunktet af følgende faser:
Faserne indeholder:
· beskrivelse af fasernes overordnede formål og resultatmål
· anbefalinger til processen/fremgangsmåde/metode (hvilke redskaber skal bruges/hvilke dokumenter skal produceres)
· anbefaling til ledelsesmæssige beslutninger
Til hver fase er beskrevet, hvilke elementer der skal udarbejdes i den pågældende fase
For eksempelvis skal der udarbejdes en risikoanalyse i idebeskrivelsesfasen.
Til risikoanalysen er der tilknyttet:
· beskrivelse af analysens formål og resultatmål
· anbefalinger til processen/fremgangsmåde/metode
· en oversigt over relevante projektredskaber/værktøj/skabelon
· samt et eksempel på anvendt værktøj
De fleste redskaber skal benyttes i flere faser. Som ofte er der dog tale om en opdatering af de tidligere indhentede oplysninger. For at lette læsningen er der indsat 3 typer af piktogrammer.
Piktogrammerne står for:
·
Formål
·
Redskaber og vejledninger
·
Eksempler på brug af redskaber
og vejledninger
Filosofien ved den faseinddelte projektmodel
Den overordnede filosofi ved den faseinddelte projektmodel er, at hver faseovergang udgør et beslutningspunkt, hvor styregruppen for projektet skal have forelagt de seneste resultater for herefter at træffe beslutning om, i hvilken retning projektet skal fortsætte. Desuden skal der ved afslutningen af en fase foreligge en detaljeret plan for aktiviteterne i den efterfølgende fase. Denne faseplan med angivelse af leverancer skal godkendes af styregruppen. Faseplanlægningen bidrager dermed til forventningsafstemningen i projektet samt den løbende kvalitetssikring. I faseplanen sker en opdatering af de centrale dokumenter i projektet som f.eks. business casen, interessentanalysen og risikovurderingen ved hver faseovergang.
Kort om faserne
I denne fase beskrives ideen mhp. udarbejdelse af et beslutningsgrundlag - et projektinitieringsdokument - for etablering af projektet, hvor de overordnede mål og rammer, som projektet skal arbejde indenfor opstilles. På baggrund af projektinitieringsdokumentet træffer styregruppen beslutning om, projektet skal igangsættes eller ej. Det er en god idé at involvere styregruppen og andre ressourcepersoner i udarbejdelsen af beslutningsgrundlaget. Det kvalificerer indholdet og sikrer ejerskab til projektideen allerede på et tidligt tidspunkt.
Analyse- og planlægningsfasen
I denne fase fastlægges projektets mål og de rammer, som projektet skal arbejde indenfor endeligt. Samtidig fastlægges de arbejdsprocesser og indsatsområder, der skal arbejdes med i det videre projektforløb. I fasen opstilles der mulige løsninger, der kan indfri projektmålet. Målet er at skabe et grundlag for styregruppens beslutning om projektets udformning. Når styregruppen har godkendt projektets endelige udformning, kan planlægningen af projektet færdiggøres, så der fremkommer en detaljeret projektplan. Samtidig skal projektets centrale dokumenter færdiggøres, herunder det projektinitieringsdokument, som blev udarbejdet i idébeskrivelsesfasen. Fasen vil evt. skulle følges af en specifikationsfase, hvori de nærmere krav til it-løsningen specificeres, hvilket danner grundlag for udarbejdelsen af en kravspecifikation.
Udviklings- og implementeringsfasen
I denne fase skal der arbejdes med selve projektet. Fasen er en produktionsfase, hvor målet er konkret at realisere projektets mål og formål, herunder producere de produkter, der er aftalt med styregruppen. Det er dermed også i denne fase, der gennemføres et udbud på baggrund af kravsspecifikationen udarbejdet i analyse- og planlægningsfasen (eller evt. i en særskilt specifikationsfase). Afhængigt at projektets omfang og kompleksitet kan fasen evt. deles op i flere delfaser.
Afslutnings- og evalueringsfasen
Når projektets mål er realiseret, skal der ske en afslutning og en evaluering af projektet. Afslutningen markerer, at projektets formål nu er opnået, og at projektorganiseringen derfor skal opløses. Samtidig skal der i denne fase, træffes endelig beslutning om projektets overgang til drift, ligesom det skal sikres at der følges op på om digitaliseringens langsigtede milepæle bliver nået. De langsigtede milepæle er defineret i business case modellen.
Evalueringen af projektet består dels af en vurdering af projektets resultater, dels af en vurdering af selve projektet, herunder organisering, fremdrift mv. Det sidste skal lede til, at projektets erfaringer kan bruges også i andre sammenhænge. Det foreslås, at der i denne fase gennemføres en evaluering af projektet samt en evaluering af projektets business case. Det kan i visse projekter være oplagt, at evalueringen foretages på et tidspunkt, hvor projektet har været implementeret i noget tid, da dette vil skabe et reelt grundlag for at kunne måle, om de ønskede gevinster faktisk er opnået.
Grafisk oversigt - Projektmodellens faser og elementer
Styregruppen: projektorganisering og ledelsesbeslutninger
Styregruppen har det overordnede ansvar for projektet.
Sammensætning
Styregruppen
består af en formand, der ejer potentialevurderingen/business casen, samt
mindst to andre personer, der repræsenter hhv. slutbrugerne og
leverandøren(ene) og løsningen.
Brugerrepræsentanten er en repræsentant for de, der skal benytte den endelige løsning eller de produkter, som projektet leverer.
Leverandørrepræsentanten er en repræsentant for de, der skal levere indholdet til projektet. Her kan der fx være tale om den it-afdeling, som skal implementere projektet eller den chef, der har ansvaret for den eksterne leverance.
Styregruppen er ikke en demokratisk forening. Det er styregruppeformanden, der bestemmer!
Skal
træffe beslutninger
Undervejs i
projektet er det styregruppen, der træffer en række valg på
baggrund af informationer (hovedsagligt) stillet til rådighed af
projektlederen.
Styregruppen skal fx:
· tage stilling til hvor stor en afvigelse i forhold til den aftalte tidsplan/ de afsatte ressourcer, der skal accepteres, inden der tages stilling til korrigerende handlinger
· godkende afslutningen af en fase eller projektet
· godkende planlægningen af den næste fase
· tage stilling til, om projektet på baggrund af den seneste opdaterede business case og risikovurdering skal fortsætte eller nedlægges
Det er desuden styregruppens ansvar, at projektlederen bliver informeret om begivenheder uden for projektet, der kan have indflydelse på projektet.
Når projektet er afsluttet og projektlederen afleverer en plan for, hvordan projektet skal evalueres efter endt implementering, er det styregruppeformanden, der har ansvaret for, at evalueringen bliver gennemført, og om eventuelle korrigerende handlinger føres ud i livet.
Fase 1: Idebeskrivelsesfasen
I denne fase beskrives projektideen, og der udarbejdes et projektinitieringsdokument (PID), der udgør beslutningsgrundlaget for igangsættelse af projektet.
Formål
Formålet med idébeskrivelsesfasen er, at der udarbejdes et projektinitieringsdokument (PID), der udgør kontrakten mellem projektorganisationen og styregruppen. Det er projektets nøgledokument. På baggrund af projektinitieringsdokumentet (PID) træffer styregruppen beslutning om, hvorvidt projektet skal igangsættes eller ej.
Resultatmål - Der er udarbejdet et projektinitieringsdokument til styregruppen - Styregruppen træffer på baggrund af projektinitieringsdokumentet en beslutning, om projektet skal igangsættes eller ej.
Fremgangsmåde
Projektinitieringsdokumentet (PID) består af følgende dokumenter som er beskrevet i de kommende afsnit:
- Formål
og mål
- Overordnet
projektplan
- Projektorganisering
- Potentialevurdering/business
case
- It-arkitektur
og teknologi
- Interessentanalyse
- Risikostyring
Redskaber m.m. til udarbejdelsen af dokumenter a – g findes på de følgende sider.
Nogle af ovenstående dokumenter vil på nuværende tidspunkt have karakter af mere overordnede skitser. Det kan således være vanskeligt allerede tidligt i projektets livscyklus meget nøje at specificere f.eks. metode, it-arkitektur, interessenter, risici mv. Det er dog vigtigt, at formål og mål for projektet samt business casen allerede tidligt i forløbet gennemarbejdes. Disse er centrale elementer i grundlaget for beslutningen om igangsættelse af projektet og giver samtidig et godt grundlag for den senere planlægning af projektet.
I denne fase er det en god ide at vurdere sin myndigheds modenhed for at sikre gode arbejdsgange og processer undervejs i projektet. Videnskabsministeriet har i samarbejde med en række kerneaktører[1] udviklet publikationen ”Modenhed i it-baserede forretningsmodeller” (2006), som er et værktøj til måling af modenhed. Find publikationen på: oio.dk/styring/modenhed
Det er en god idé at involvere projektejer og andre ressourcepersoner i beskrivelsen af ideen og udarbejdelsen af projektinitieringsdokumentet (PID). Det kvalificerer indholdet og sikrer ejerskab til projektet allerede på et tidligt tidspunkt.
Projektinitieringsdokument (PID)
Formål med projektinitieringsdokumentet (PID)
Formålet med projektinitieringsdokumentet er at skabe et beslutningsgrundlag og en forventningsafstemning vedr. projektet, herunder at skabe et grundlag, som vitale beslutninger i projektforløbet kan holdes op imod. Projektinitieringsdokumentet fungerer således som et overordnet styringsværktøj for projektet og er informationsgrundlag og referenceramme for projektets interessenter.
Resultatmål
Der er udarbejdet en klar og operationel beskrivelse af projektet, dets formål og mål samt de overordnede rammer for projektet, på baggrund af hvilket styregruppen kan tage stilling til projektets igangsættelse.
Målgruppe for projektinitieringsdokumentet
Projektinitieringsdokumentets (PID) målgruppe er typisk styregruppen og projektsekretariatet/arbejdsgruppe samt en evt. referencegruppe eller følgegruppe.
Hent redskaber på modernisering.dk/projektmodel
· Skabelon for projektinitieringsdokument (PID)
· ”Modenhed i it-baserede forretningsmodeller”
Dokumenter/redskaber til fase 1: Idebeskrivelsen
Formål og mål (målhierarki)
Når et projekt skal igangsættes er det afgørende, at projektets formål og mål er klart beskrevet, idet dette vil være de centrale pejlemærker for projektet igennem hele dets levetid. Det er samtidig vigtigt, at projektets formål og mål er kendt af alle, der er involveret i projektet, herunder styregruppe, projektmedarbejdere, leverandører mv.
Formål
Formålet med målformulering og afgræsning af projektet er at etablere en entydig, afgrænset og operationel målsætning for projektet, der tydeliggør, hvad der skal leveres i projektet, hvornår og hvorfor. Fastsættelse af formål og kortsigtede som langsigtede mål skaber fundamentet for den nødvendige efterfølgende milepæls-, aktivitets-, ressource- og tidsplanlægning.
Resultatmål
· Projektets formål er beskrevet
· Projektets resultatmål og delmål er beskrevet
· Projektets succeskriterier er beskrevet
· Der er skabt en tydelig sammenhæng mellem formål, resultatmål, delmål og succeskriterier
Projektets afgrænsning
Afgrænsningen af projektet beskrives - i samarbejde med opdragsgiver - med hensyn til:
· Problemstillinger, der skal løses
· Områder, der skal fokuseres på
· Ydelser, som ønskes forbedret
· Processer, der skal arbejdes med
· Interessenter, der skal tilfredsstilles
Hvis der er igangsat andre projekter, som vil kunne få indflydelse på projektet eller omvendt, så må dette afklares, og der må om nødvendigt tages initiativ til at sikre en koordinering mellem projekterne.
Projektets formål, resultatmål og succeskriterier
De tre måltyper hænger tæt sammen, idet de afspejler forskellige niveauer af mål. De tre måltyper udtrykker dermed et projekts målhierarki.
Kort sagt så udtrykker:
Formålet: Hvorfor projektet etableres
Resultatmålene: Hvilke leverancer projektet realiserer
Succeskriterierne: Konkrete målbare effekter i form af ”Key Performance Indicators” (KPI)
Projektets formål findes ved at svare på spørgsmålet: “Hvorfor vil vi gennemføre projektet?” Formålet kan herefter beskrives ved at besvare spørgsmålet på formen: “For at ......”
Projektets resultatmål er en beskrivelse af de ønskede leverancer (resultater) fra projektarbejdet. Resultatmålene er nødvendige at opnå for at realisere projektets formål og beskriver, hvilke indsatser der skal bidrage til formålsopfyldelsen.
Gode resultatmål er karakteriseret ved at være SMARTe: Specifikke, Målbare, Accepterede, Realistiske (men ambitiøse og udfordrende) og Tidsfastsatte.
Det vil ofte være nødvendigt at nedbryde resultatmålene i en række delmål og dermed gøre målene mere konkrete og målbare.
Projektets resultatmål findes ved at spørge: “Hvordan vil vi realisere projektets formål?”/ ”Hvad skal projektet levere for at opnå formålet?” Besvar spørgsmålet på følgende form: “Ved at have (leveret) .....” Det er vigtigt, at man besvarer spørgsmålet på en måde, der beskriver resultatet og ikke indsatsen.
Projektets succeskriterier i form af KPI’er findes ved at spørge: “Hvordan kan vi måle, at projektets effekt opnås?” Besvar spørgsmålet - som med projektmål - på formen: “Ved at have (gennemført) .....” Business case modellen (se s. 15) omfatter en metode til at definere de centrale KPI’er.
Et helt kort eksempel på ovenstående kunne se sådan ud: Det er et formål at opnå en mere effektiv dokumenthåndtering. Et resultatmål kunne være at opnå tidsbesparelser ved at scanne dokumenter ind, og de konkrete effekter i succeskriterierne kunne være, at der er opnået en tidsbesparelse ved dokumenthåndteringen på xx minutter, og at al fysisk post er scannet ind.
Resultatmål og delmål
Projektets resultatmål skal formuleres så operationelt som muligt. Det vil sige, at det senere skal kunne måles, om målene nås. Et operationelt mål er udtrykt med nogle egenskaber, der kan måles og er udtrykt ved et antal af en bestemt måleenhed som f.eks. procent, kr., minutter.
Er de overordnede mål ikke operationelle, skal de nedbrydes i delmål, indtil de er operationelle. Delmålene skal formuleres, så de tilsammen bidrager til opfyldelse af de overordnede mål.
Ved nedbrydning af målene fremkommer delmål, som kan opfyldes med it-systemløsninger, personale-, opgave- eller organisationsudvikling eller en kombination heraf. Når man nedbryder mål, skal man sikre sig, at delmålene tilsammen opfylder hovedmålet.
I ovenstående eksempel er delmålet "Effektiv opgaveløsning" ikke operationelt og må nedbrydes yderligere. De øvrige mål er derimod operationelle, idet der for disse kan fastlægges egenskaber, som kan måles. I beskrivelsen af målene skal egenskaber, måleenhed og niveau fremgå.
Eksempelvis kunne beskrivelsen af målet "Opnå minimumskontrolniveau" være formuleret således: "Kontrollen skal have et niveau, så EU's mindstekrav er opfyldt. EU's mindstekrav er kontrol af mindst 2% i hver varesektor og en samlet kontrolindsats på tværs af alle varesektorer på minimum 5%."
De opstillede mål er udgangspunkt for formulering af funktionelle-, kvalitative- og ressourcemæssige krav til arbejdsproces- og it-løsning. F.eks. kunne et funktionelt krav om en automatisk risikoanalyse i it-systemet bidrage til opfyldelse af målet "Opnå minimumskontrolniveau".
Overordnet Projektplan
Allerede ved formuleringen af projektgrundlaget er det vigtigt at have en overordnet projektplan, der angiver projektets tidsramme og de vigtigste milepæle i projektet. Det vil dog næppe være muligt allerede i idébeskrivelsesfasen at gennemføre en meget detaljeret projektplanlægning. Den nedenstående beskrivelse af projektplanen skal derfor ikke følges til punkt og prikke på nuværende tidspunkt, men alene give en introduktion til arbejdet med projektplaner i projektet samt tjene som inspirationen for arbejdet med den overordnede tidsplan.
Formål
Projektplanen bidrager til at skabe overblik over sammenhænge mellem ressourcer, aktiviteter og tid. Detaljeringsniveauet vil afhænge af det konkrete projekts behov. Dermed skabes forskellige typer af overblik over projektet, der kan fungere som udgangspunkt for forventningsafstemning, kommunikation, opfølgning og justering af projektet.
Resultatmål - Der er etableret en projektplan, der viser sammenhænge mellem indsatsområder, aktiviteter og evt. ressourcer, ansvarlige, udførelsesstatus og prioriteringer - Planen muliggør sortering af relevante data, der giver overblik i forhold til den konkrete anvendelsessituation - Planen vedligeholdes løbende, så den giver overblik over projektets aktuelle status
Fremgangsmåde
Informationerne i projektplanen kan med fordel indsamles i forlængelse af formuleringen af indsatsområder (se målhierarki), milepæle og ressourceestimering. I projektplanen beskrives:
· Projektets strategi
· Projektets milepæle (leverancer - se næste afsnit) og hvornår disse foreligger
· Projektets overordnede faser og aktiviteter
· Projektets ressourcer og rammer
· Skitse til projektorganisationen
· Planen opdateres løbende
Som minimum ved hvert faseskift, hvor den kommende fase detaljeres/justeres. Planen indgår i første udgave i projektets prospekt, der udover planen beskriver baggrund, problemstilling, mål, behov samt et begrundet projektforslag mv. Planer for faser, hvor it-systemet realiseres, bør udarbejdes med deltagelse af leverandøren. Der kan i løbet af et projekts levetid blive rejst nye krav til projektet, blive stillet forslag om ændringer eller opstå ny viden o.l., som projektgruppen skal forholde sig til. Det kan derfor anbefales, at der oprettes en emnelog, hvori nye arbejdsopgaver noteres, således at projektgruppen får et redskab til en systematisk håndtering heraf.
Hent redskaber på modernisering.dk/projektmodel
· Skabelon for projektplan
· Skabelon til emnelog
Hent eksempel på modernisering.dk/projektmodel
· Eksempel på udfyldt emnelog
Projektorganisering
Projekter kan være organiseret på forskellig vis, men typisk er der som minimum udpeget en projektleder, projektgruppe og styregruppe. Ydermere kan der være tilknyttet referencegrupper og en eller flere projektejere. Udover at fastlægge selve bemandingen er det vigtigt at afklare forventningerne til, hvordan man arbejder sammen, og hvordan roller og ansvar fordeles. Dette gælder også i relation til styregruppen og evt. referencegrupper. Denne projektmodel opererer med faser, og det er typisk ved faseovergangene, at styregruppen involveres i beslutninger - med mindre projektet har f.eks. afvigelser ud over den aftalte tolerance (fx tid, kvalitet, økonomi eller lignende)
Formål
Formålet med projektorganisering er at sikre en hensigtsmæssig arbejdsdeling og placering af ansvars- og ledelsesopgaven i et projekt.
Resultatmål
· Ansvaret for ledelsesopgaven i projektet er klarlagt
· Der er klare forventninger til roller og ansvar for projektleder, projektgruppe og styregruppe og det konkrete samarbejde mellem dem
· Der er etableret et beslutningsorgan, der vurderer projektet regelmæssigt
Fremgangsmåde
Når en projektorganisation skal defineres, er der forskellige forhold og anbefalinger, som kan følges. Generelt skal der sikres klare forventninger og eventuelt kommissorier omkring:
· hvem der træffer, hvilke beslutninger i projektet
· hvem der arbejder i projektet
· hvem der giver sparring og støtte til projektet
Bemandingen af et projekt
Bemandingen skal ske ud fra afvejede hensyn til kompetencer og viden samt ledige ressourcer. Det nytter f.eks. ikke at etablere en arbejdsgruppe bestående af lutter meget travle mennesker som ikke reelt har tid til at yde et bidrag i projektet. Husk at organiseringen af projektet er et vigtigt signal til resten af organisationen om, hvor betydningsfuldt projektet er for ledelsen. Jo stærkere projektet er forankret i topledelsen, jo stærkere signal om projektets betydning for hele organisationen.
Overordnet er det:
· Styregruppens ansvar at levere ressourcer, beslutninger og mandat til projektet
· Projektlederens ansvar at styre og planlægge projektet, herunder at tilvejebringe beslutningsgrundlag og dokumentation til styregruppen
· Projektgruppens ansvar at levere det faglige arbejde
Hent redskaber på modernisering.dk/projektmodel
· Beskrivelse af roller og ansvarsområder i projektorganisationen
Potentialevurdering – business case
Når de første tanker om projektet er fostret, er det nødvendigt at påbegynde analysen af konsekvenser og effekter af projektet. Der skal foretages en analyse af, hvad de økonomiske og kvalitative effekter af projektet vil være. Er der en økonomisk gevinst, vil der typisk være mere, der peger i retning af, at projektet bør sættes i gang. Et projekt kan også være levedygtigt, hvis formålet er at høste kvalitative gevinster. Det kan fx være fornuftigt at gennemføre et projekt, hvis det er muligt at realisere større retssikkerhed, en bedre serviceoplevelse eller hvis projektet er et strategisk vigtigt projekt. Det kan også være en væsentlig kvalitativ gevinst, at der er eksterne parter, der får en økonomisk fordel af projektet.
Formål
Formålet med at lave en business case i idéfasen er, at skabe overblik over de økonomiske og kvalitative konsekvenser af projekter samt at give ledelsen/styregruppen de relevante informationer til at træffe beslutninger om projektets lønsomhed.
Resultatmål
· Der er udarbejdet en business case, der rummer vigtig ledelsesinformation
· Ledelsen/styregruppen træffer på baggrund heraf beslutning, om projektet skal gennemføres i den foreslåede form eller om projektet skal reorganiseres eller helt afvises.
Business case model og andre værktøjer til at understøtte business case-arbejdet
Som et led i digitaliseringsstrategien ”Strategi for
Digital Forvaltning 2007 –
Business case modellen fokuserer på de forretningsmæssige aspekter af et projekt – især målrettet udvikling af en it-løsning. Business case modellen er bygget op omkring fire hovedafsnit:
- Første afsnit (”Løsningbeskrivelse”) giver et overordnet grundlag for at vurdere investeringens omfang og karakter.
- Andet afsnit (”Forretningsmæssige konsekvenser”) giver et klart billede af investeringens økonomiske konsekvenser, hvilke investeringer der skal foretages, hvilke risici projektet indeholder, og hvilke økonomiske eller servicemæssige gevinster projektet forventes at resultere i.
- Tredje afsnit (”Implementering og opfølgning”) beskriver konkret, hvordan projektet i praksis gennemføres samt, hvordan og hvornår, der følges op på de kortsigtede og langsigtede effektmål. Det er her, at succeskriterier i form af ”Key Performance Indicators” (KPI) skal defineres.
- Fjerde afsnit (”Ejerskab”) giver et klart billede af, hvem der har hvilket ansvar – herunder ansvaret for opfølgningen på de langsigtede forretningsmål.
Det bør tage omkring en effektiv arbejdsuge at udarbejde en business case for et middelstort projekt (5-10 mio. kr.). Mere komplekse projekter vil selvsagt tage længere tid. Udfyldelsen vil typisk kræve, at man løbende er i dialog med relevante interessenter.
Med hensyn til business casens omkostningsside har Den Digitale Taskforce tidligere lanceret et værktøj til IT-omkostningsopgørelse. Dette værktøj kan benyttes til at understøtte opgørelsen af omkostningssiden i den samlede business cases.
Hvad
angår definition af projektleverance- og/eller forretningsmæssige
milepæle og effektmål i business casen kan IT- og Telestyrelsens
”Effektmåling af offentlige it-projekter” (2007) bidrage til
inspiration.
TILBAGE TIL OVERSIGTEN
Proces
Hvis der er flere projekter i spil, kan brugen af business case modellen og de øvrige værktøjer være medhjælpende til at beslutte, i hvilken rækkefølge projekterne skal iværksættes. En systematisk opgørelse af de kvalitative gevinster og økonomiske fordele og omkostninger ved et digitaliseringsprojekter er en central del af det at skabe et kvalificeret beslutningsgrundlag for et projekt.
Baggrund for værktøjerne til potentiale og effektmåling
Visionen for digital forvaltning i Danmark er, at den offentlige sektor skal levere en bedre, mere sammenhængende og effektiv service til borgere og virksomheder. Rigtig gennemført digitalisering skal muliggøre både bedre service og kvalitet og samtidig frigøre ressourcer så opgaver kan løses mere enkelt og effektivt. Således er et af initiativerne digitaliseringsstrategien for 2007-2010, at mindst 75 pct. af de offentlige digitaliseringsprojekter frigør ressourcer, og mindst 25 pct. gør det i høj grad.
Danske og internationale undersøgelser viser, at der er forholdsvis få offentlige institutioner, der arbejder systematisk med at opstille mål – herunder effektmål - for deres investeringer.[2] Mange offentlige digitaliseringsprojekter iværksættes, uden der forinden og løbende foretages en systematisk opfølgning af forventningerne til såvel projektets fordele som dets ulemper. Systematisk opfølgning på et projekts omkostninger og de økonomiske og kvalitative gevinster er en del af at drive et projekt professionelt og herunder skabe et kvalificeret beslutningsgrundlag for projektet.
Formålet med business case modellen og de understøttende værktøjer til potentialevurderingen er at understøtte denne type opgørelser i den offentlige sektor. En business case bør udarbejdes før et projekt besluttes. Men business casen er et dynamisk dokument, der løbende skal opdateres og bruges som effektmålingsværktøj igennem hele forløbet af et digitaliseringsprojekt. Ved hver faseovergang skal der foreligge en opdateret business case, der giver styregruppen mulighed for at vurdere, om gevinster og omkostninger stadig står mål med hinanden. Beregninger af potentialer og omkostninger justeres i takt med, at der i projektforløbet opnås en mere præcis viden om besparelsesmuligheder og omkostninger forbundet med projektet.
Hent redskaber på modernisering.dk/projektmodel
· Den generelle business case model
· Business case vejledning
· Omkostningsmodel inkl. regneark og estimering af it-omkostninger - vejledning
· ”Effektmåling af offentlige it-projekter”
Hent eksempler på modernisering.dk/projektmodel
· Se fiktivt eksempel på at bruge business case modellen
· Læs om estimering af IT-omkostninger ved indførelse af FESD i Den Sociale Sikringsstyrelse
It-arkitektur og teknologi
Allerede i forbindelse med udarbejdelsen af projektinitieringsdokumentet vil der være behov for overordnede overvejelser omkring it-arkitektur og teknologi i projektet. Det kan eksempelvis være overvejelser om, hvorvidt der er behov for nye it-løsninger, eller der skal ske tilpasninger af eksisterende løsninger, og videre hvis det vurderes, at der er behov for nye it-løsninger, om disse kan bestå af standardløsninger, eller der er behov for løsninger, der er udviklet specielt mhp. de forretningsmæssige krav i projektet. Disse informationer skal også indgå på et overordnet niveau i business casen.
Formål
Formålet med overvejelserne om it-arkitektur og teknologi i denne fase er at klarlægge, hvilke ønsker og behov der er til de it-løsninger, som er del af projektet.
Resultatmål
· Det er klarlagt, hvilke overordnede behov it-løsningen skal opfylde
· Det er klarlagt, hvilken betydning evt. eksisterende it-strategi og it-arkitekturarbejde vil have for projektet
Beslutningen om at igangsætte et projekt kan træffes på baggrund af en række forskellige ønsker og behov. Dette kan f.eks. være:
· Lovmæssige ændringer, der kræver nye løsninger
· Politiske ønsker om bedre og/eller mere effektiv service
· It-strategi og it-arkitekturarbejde kan pege på et behov for et givet projekt
Baggrunden for at iværksætte et it-projekt vil dermed kunne have stor betydning for de valg, der skal træffes vedr. it-arkitektur og teknologi.
I idéfasen er det vigtigt at få klarlagt, om projektideen stiller krav, som kræver en udbygning af it-infrastrukturen - eller man f.eks. i stedet skal vælge outsourcing.
I denne fase er der derfor behov for at skabe et overordnet overblik over eksisterende infrastruktur (kan hentes fra det overordnede arkitekturoverblik – hvis et sådant findes)
It-arkitekturarbejdet henter desuden input fra:
· Interessentanalysen
· Arbejdsopgaver og ansvarsområder
Samtidig kan it-arkitekturarbejdet udføre/medvirke til dokumentation af disse, herunder give input til beskrivelsen af projektets definition og omfang. På baggrund af projektgrundlaget udarbejdes en overordnet skitsering af krav og ønsker vedr. it-arkitektur og teknologi. Den overordnede skitsering kan bruges i business casen, hvor it-løsning og it-arkitekturen ligeledes skal præsenteres på et overordnet niveau i kapitel 1 - ”Løsningsbeskrivelse”.
Leverancer i fasen:
· Overordnet overblik over eksisterende it-arkitektur og infrastruktur
· Første pejling på ønsker og behov vedr. fremtidig it-arkitektur og teknologi
Interessentanalyse
Ofte vil mange personer og organisationer have en eller anden interesse i et projekt. De kan være positive eller negative overfor projektet, og de kan have større eller mindre indflydelse på projektets forløb og efterfølgende implementering. Det er derfor vigtigt i et projekt at fastslå de vigtigste interessenter og pege på strategier til håndteringen af disse. Bemærk at kortlægning af interessenter også skal indgå i business casen.
Formål
· At skabe et overblik over projektets interessenter samt at
· At sikre en målrettet og differentieret håndtering af projektets interessenter, herunder at skabe strategisk vigtige relationer mellem projektet og interessenterne. Interessentanalysen skal således identificere de kritiske interessenter, for efterfølgende at kunne beslutte, hvilke tiltag der skal iværksættes for at håndtere dem. Eksempelvis skal der skelnes mellem, hvem der skal orienteres, informeres, høres eller involveres i projektet. Dette kan ske dels gennem projektets organisering og dels gennem kommunikationsstrategien.
Resultatmål
· Projektets interessenter er identificeret
· Der er sket en positionering af interessenterne i forhold til væsentlighed for projektet
· Der er opstillet konkrete aktiviteter til håndtering af vigtige interessenter. Strategierne kan f.eks. omhandle, hvordan projektet bruger den viden, som interessenterne har, hvordan projektet skaffer accept og opbakning fra interessenter, samt hvordan projektet minimerer modstanden i en efterfølgende implementeringsfase i projektet. Eksempler på interessenter kan være projektets målgruppe, projektejer, opdragsgivere, slutbrugere, borgere, beslutningstagere, politikere, myndigheder, leverandører med flere. Interessentanalysen bør tages frem med jævne mellemrum i projektgruppen, da projektet og dets kontekst kan ændre sig med tiden. F.eks. kan et regeringsskifte påvirke en politisk dagsorden i en projektgruppe, ligesom ny lovgivning kan medføre, at projektet ændrer karakter.
Fremgangsmåde: Interessentanalyse - fire trin
Det er vigtigt at involvere ressourcepersoner, der har et indgående kendskab til projektets område og omgivelser. Det er derfor naturligt at vælge en idégenereringsmetode, der lægger op til at udnytte alle projektmedlemmernes forskellige perspektiver, hvor også projektejer og styregruppe kan involveres. Den brede involvering er med til at sikre 1) at de vigtigste interessenter bliver identificeret 2) at der etableres engagement i projektgruppen. Interessentanalysen gennemføres i nedenstående fire trin vha. papkortmetoden:
Trin 1: Brainstorm - identifikation af interessenter
På dette trin skal projektgruppen komme med idéer til, hvem der bliver berørt i projektforløbet, og hvem der bliver berørt af resultatet. Hvert projektmedlem noterer alle tænkelige interessenter ned på papkort (5-10 min.), der efterfølgende vilkårligt sættes op på væggen. Interessenterne kan opdeles i henholdsvis for projektet og imod projektet og markeres ved eksempelvis at anvende blå kort for de interessenter, der er for, og røde kort for dem, der er imod.
Interessenter, der er for projektet, kan eksempelvis være dem der får et stort udbytte uden at skulle yde så meget og tilsvarende kan de interessenter, der er imod være dem, der skal yde meget uden at få så stort et udbytte. Papkortene fastsættes på væggen med ”tyggegummi” så de efterfølgende kan flyttes rundt.
Trin 2: Sortering af interessenter efter indflydelse
Interessenterne sorteres i kategorier ud fra, hvor stor indflydelse de har på projektet, og hvor nødvendig deres medvirken er for, at projektet bliver gennemført.
· Det kan være afgørende at bruge mange kræfter på de interessenter, som har stor indflydelse på, om projektet når sine mål i praksis (interessenter, som kan blokere for projektets gennemførelse).
· Der kan også være interessenter med stor indflydelse, men hvor medvirken ikke i særlig høj grad er nødvendig. Det kan være ledere eller opinionsdannere, som ikke umiddelbart er synlige, men som det på et tidspunkt kan være afgørende at have med (kan f.eks. kontrollere ressourcer eller påvirke personer).
· De interessenter, som ikke har stor indflydelse, men som i høj grad påvirkes af projektet (ofte slutbrugere), kan være vigtige at inddrage tidligt i projektet, så de kan indstille sig på forandringerne - og således øge muligheden for, at de helhjertet vil påtage sig ansvar for forandringen.
Gruppens medlemmer skal på dette trin flytte på kortene og placere interessenterne i et koordinatsystem i forhold til indflydelse og medvirken (5-10 min.).
Trin 3: Udvælgelse af væsentligste interessenter, prioriteringsskema og interessentskema Det er ikke muligt at fokusere på samtlige interessenter i projekter. Derfor udvælges de væsentligste interessenter. Måden, hvorpå disse udvælges, er ved at prioritere dem kvadrant for kvadrant, med undtagelse af interessenterne i nederste venstre kvadrant, der ikke betragtes som vigtige.
Trin 4: Opsamling og konklusioner
· Som sidste trin i interessentanalysen vurderes det samlede billede på baggrund af følgende spørgsmål:
· Hvad betyder interessentanalysen for det samlede projekt og for projektledelsen?
· Giver analysen anledning til at justere formål, mål og resultatveje i projektet?
· Hvordan skal beslutningsprocessen indrettes?
· Hvordan skal projektet organiseres?
· Hvem skal involveres og hvornår og hvordan?
· Hvilke aktiviteter til interessenthåndtering skal lægges ind i kommunikationsstrategien?
Hent eksempel på modernisering.dk/projektmodel
· Eksempel på en interessentanalyse fra projektet "Kampagne for digitale selvbetjeningsløsninger”
Risikostyring
It-projekter er forbundet med risiko. Nogle risici har institutionerne selv indflydelse på. Andre risici er det ikke muligt at påvirke. It-projekter kræver ofte ændringer i ansattes kompetencer og i den måde den offentlige sektor organiserer sig på. Desuden sker der på it-området en hurtig teknologisk udvikling. Der er ikke kun risici forbundet med gennemførelse af it-projekter. Der vil også være risici ved, at den offentlige sektor ikke anvender den ny teknologis muligheder. Det kunne betyde, at den offentlige sektor ikke i fremtiden vil være i stand til at opfylde de krav, som stilles af borgere og erhvervsliv.
Det er ikke et mål i sig selv at undgå risiko, men derimod at sikre, at der er en fornuftig balance mellem omkostninger, fordele samt den tilhørende risiko. Igangsættelse af et it-projekt bør først ske efter, at der er gennemført en risikovurdering, der omfatter de væsentligste elementer, der kan have betydning for projektets gennemførelse, vurdere sandsynligheden for, at de indtræffer samt opstille planer for, hvordan man kan håndtere risici. Risici kan påvirke business casen – derfor indgår en overordnet risikovurdering også i Taskforcens business case model.
Formål
Formålet med en risikovurdering er at sætte fokus på de resultater, som især er sårbare over for påvirkninger. Risikovurderingen skal samtidig rumme en vurdering af konsekvensen, såfremt en given risiko indtræffer samt justere og planlægge, hvad der kan gøres for at undgå, reducere eller fjerne en bestemt risiko.
Resultatmål
· De væsentligste risici og argumenterne herfor er dokumenteret
· Der er for hver risiko opstillet forslag til aktiviteter mhp. at undgå, reducere eller fjerne en bestemt risiko
· Der foretages løbende konkrete justeringer af projektet mhp. at forebygge eller reducere konsekvenser
Risici kan knyttes til:
· Organisatoriske forhold
· Politiske forandringer
· Teknisk løsning
· Leverandører
· Interessenter
· Samarbejde
· Målopfyldelse
· Projektjustering
Risikovurdering og styring som løbende værktøj
En risikovurdering bør gennemføres første gang i projektets idébeskrivelsesfase, hvor formål og mål formuleres. Det er på dette tidspunkt, man skal finde ud af, hvilke risici der skal tages højde for, og hvilken strategi der skal udvikles for at mindske konsekvenserne af disse.
Typen af risici og den vægt de enkelte risici skal tillægges, vil således variere alt afhængig af det konkrete projekt. På baggrund af den specifikke situation er det dermed ikke kun en opgave om at kunne identificere risici for det enkelte projekt, men også at kunne vurdere, hvilken vægt de enkelte risici skal tillægges. Risikovurderingens værdi er hovedsagelig tilknyttet den information, der erhverves ved at anvende det som et løbende styringsværktøj. I den løbende risikovurdering bør der tages højde for alle overstående risici.
Fremgangsmetode: Risikostyring - fem trin
Fastlæg retningslinier for, hvordan risikostyring anvendes som et konstruktivt værktøj i projektforløbet. Der bør være etableret en fast procedure for, hvorledes den projektansvarlige inddrager og orienterer de ansvarlige ledere løbende, fx i et overskueligt rød-gul-grøn-skema.
Risikostyring omfatter:
· Identifikation af risici
· Analyse og kvantificering
· Opfølgning og handling
Trin 1: Brainstorm og identificering af risici Analysen starter med at projektgruppen kommer med idéer til, hvilke genkendelige risici projektgruppen vurderer, kan opstå eller allerede eksisterer. Hvert projektgruppemedlem noterer alle tænkelige risici (5-10 min.), der efterfølgende noteres i et skema, jf. skabelonen nedenfor.
Trin 2: Risikoanalyse - Vurdering af sandsynlighed og konsekvens Vurderingen af hver enkelt identificeret risiko foregår i to dimensioner: 1) Hvor stor er sandsynligheden for, at denne risiko opstår? 2) Hvad er konsekvensen, hvis denne risiko bliver en realitet? Gruppens medlemmer overvejer placeringen af de enkelte risici i forhold til sandsynlighed og konsekvens (5-10 min.). Beregning af risikoværdi: De risici, projektgruppen har identificeret opstilles i et skema, jf. skabelonen nedenfor. For hver risiko vurderes (på en skala fra 1-10) sandsynligheden for, at de vil opstå og konsekvensen, hvis det sker. Disse vurderinger anvendes til at beregne risikoværdien, for hver enkelt risiko, ud fra formlen: S x K = R (Sandsynlighed x Konsekvens = Risikoværdi). Risici, der er meget sandsynlige og indebærer store konsekvenser har dermed en høj risikoværdi. Værdierne ganges således med hinanden, og resultatet angiver værdien for risikoen.
Trin 3: Planlægning - forebyggende handleplan Det er ikke muligt at fokusere på samtlige risici i projekter. Derfor skal projektgruppen og styregruppen primært forholde sig til den eller de risici, der har særlig høj risikoværdi. For disse risici, bør der udarbejdes en plan for håndtering af hændelserne, hvis nu de skulle blive en realitet. En sådan plan skal ikke nødvendigvis være detaljeret, men bør indeholde en angivelse af hvilke omstændigheder, der skal aktivere planen (advarselstegn), og hvad der skal ske, hvis hændelserne opstår. Hertil kan skabelonen nedenfor anvendes.
Trin 4: Konsekvenser af risikovurderingen Det skal afslutningsvis vurderes, om risikoanalysen giver anledning til at justere på projektets
· business case
· resultatmål
· resultatveje
· milepæle
· organisation
Trin 5: Etablering af en fast procedure for, hvorledes den projektansvarlige løbende inddrager og orienterer de ansvarlige ledere For statslige it-projekter er der pligt til at foretage risikovurdering af it-projekter, der skal forelægges for Finansudvalget, jf. Budgetvejledningen. It-projekter skal forelægges for Finansudvalget, hvis de samlede budgetterede udgifter til anskaffelse og udvikling udgør 50 mio. kr. eller derover. Forelæggelsen af risikovurderingen for Finansudvalget er en status for det forarbejde, der sker i forbindelse med igangsættelse af et it-projekt. Der skal bl.a. gøres rede for de tiltag, som iværksættes for at mindske risici, jf. Finansministeriets vejledning om risikovurdering ved forelæggelse af it-projekter, som kan findes på:
http://www.oav.dk/graphics/OAV/Dokumenter/Vejledninger/Bevillingsomraade/vejl_risikovurdering_it.pdf
Hent redskaber modernisering.dk/projektmodel
· Hent skabelon til risikostyring
· Tjekliste til vejledning i risikostyring
· ”Vejledning om risikovurdering ved forelæggelse af it-projekter for Finansudvalget”
Øvrige redskaber til brug til fase 1: idebeskrivelsesfasen
Milepælsplanlægning
Milepælsplanlægning er en metode, der hjælper til at nedbryde projektets resultatmål og delmål i håndtérbare indsatsområder og opgaver/aktiviteter. Hermed skabes også forudsætningerne for at fordele ressourcer og ansvarsområder i projektet. Selve milepælene giver et overblik over vigtige fikspunkter i projektperioden, som kan bruges til at gøre status og styre efter. Endelig kan milepælene også bruges som væsentlige pejlemærker for kommunikation med f.eks. styregruppen. Milepælene er således elementer i en tidsplan. Det egentlige udgangspunkt for kommunikationen med styregruppen bør dog være faseovergangene. I forlængelse af milepælsplanen kan en egentlig projektplan udarbejdes.
Formål
Formålet med milepælsplanlægningen er at identificere og skabe klarhed i projektgruppen om, hvilke skridt (milepæle) der fører til realiseringen af projektets resultatmål samt at skabe ejerskab til projektet i hele projektgruppen. Ud over at arbejde med projektleverancemilepæle vil det også være relevant at definere langsigtede forretningsmilepæle.
Resultatmål
· Der er udledt indsatsområderne ift. resultatmålene
· Der er udledt resultatveje og et antal milepæle identificeret
· En milepælplan, der angiver projektets fremgangsmåde og danner grundlag for udarbejdelse af en ressourceestimering og en eventuel handleplan, er udarbejdet og dokumenteret
Hvad er en milepæl - og hvor mange skal man have?
En milepæl formuleres i projektregi som: "En tilstand og de betingelser, der skal være knyttet til denne tilstand, før en milepæl er indfriet". Det kan f.eks. være: "Rapporten er udarbejdet og godkendt af styregruppen den 4. oktober". En milepæl kan således knyttes til styregruppemøder, men behøver ikke at gøre det. Man kan også benytte interne milepæle i projektgruppen, som markerer vigtige begivenheder i projektarbejdet. Det kan f.eks. være: "Der er foretaget 1. systemtest" eller "Evalueringsrapport er afleveret til trykkeriet" eller lignende. Altså milepæle, som ikke involverer en styregruppes kvalitetssikring eller beslutning.
Milepælene markerer særlige afgørende delmål i projektforløbet, som også kan kommunikeres til projektets interessenter. Som tommelfingerregel kan 6-8 store milepæle skabe et godt overblik over et projekt, men det afhænger også af fasernes længde.
Fremgangsmetode
Milepælsplanlægning - tre trin
En god milepælsplan tager udgangspunkt i projektets resultatmål, jf. målhierarkiet, og består af følgende trin:
1. Fastsættelse af indsatsområder
2. Identificering af milepæle i faserne
3. Overordnet tidsplanlægning (deadlines) og ansvarsfordeling
Trin 1: Definér indsatsområder Den første opgave er at sortere projektets resultatmål i nogle overskuelige grupper (indsatsområder).Projektets indsatsområder betegner naturlige grupperinger af opgaver, som kan planlægges mere eller mindre uafhængigt af hinanden. Kriterierne for gruppering kan være geografiske, fysiske, eller - som oftest - relatere sig direkte til resultatmålene.
Trin 2: Udled milepæle Inden for hvert indsatsområde spoles så at sige baglæns ift. at definere de skridt/handlinger, der fører til opfyldelse af resultatet. Når disse aktiviteter er fastlagt, udvælges konkrete milepæle. Det skal være afgørende tidspunkter i projektets liv, hvor der f.eks. træffes væsentlige beslutninger. Ofte er det ikke muligt at forudse alle konkrete aktiviteter i projektet. Det betyder dog ikke, at man ikke kan lægge en milepælsplan, da resultatmålet er kendt. Det er f.eks. ikke muligt at vide, hvilke retningslinjer der skal udarbejdes i et lovformuleringsprojekt. Denne afklaring opnås først, når analysen er gennemført, men det er muligt at kortlægge den proces, projektgruppen skal gennemløbe for, at retningslinjerne er udarbejdet (som f.eks. analyse, udkast til beslutninger, høring om beslutninger osv.).
Trin 3: Overordnet tidsplanlægning (deadlines) og ansvarsfordeling Når milepælene er defineret for de forskellige indsatsområder, er det muligt at trække nogle tidsmæssige grænser for, hvornår de forskellige milepæle skal være indfriet. Det er også muligt at angive, hvem der har ansvaret for, at en milepæl indfries. Man skal være opmærksom på, at der kan være indbyrdes afhængighed mellem nogle milepæle på tværs af indsatsområderne. Ved at gruppen i fællesskab laver tidsplanslægningen, skabes der ansvar, og alle bliver bevidste om deres rolle i projektgruppen. Det bliver også muligt at skabe overblik over hele projektet, i forhold til om der er nogle perioder med flere deadlines end andre og i forhold til, om der derfor bør omprioriteres. I Taskforcens business case models vejledning kan du finde en fremgangsmåde til at definere og følgekonkret op på både kortsigtede og langsigtede milepæle.
Emnelog
Undervejs i et projekt vil der vil blive fremsat ønsker om ændringer af de aftalte produkter, rejst spørgsmål eller udtrykt bekymringer, som projektet må forholde sig til. Dette kalder man projektemner, og det anbefales, at disse noteres i en emnelog mhp. at skabe et overblik over projektemnerne og hvordan de skal håndteres. Emneloggen er dermed et centralt værktøj i et projekts ændringsstyring.
Formål
Formålet med en emnelog er, at projektlederen og projektmedarbejderne har et centralt placeret kommunikationsværktøj, der sikrer, at der systematisk bliver fulgt op på uforudsete opgaver undervejs i projektet. Emneloggen fungerer således som en opsummering af alle projektemner, analyse af dem og deres status.
Resultatmål
At der bliver etableret et dokument, der løbende bliver opdateret gennem hele processen af både projektlederen og projektmedarbejderne, og som bidrager til en systematisk håndtering af uforudsete arbejdsopgaver.
Baggrund
Det er ikke alle udfordringer og informationer, der kan forudsiges ved indledningen til et projekt. Der vil løbende dukke ønsker og informationer op, der betyder, at der vil være uforudsete opgaver skal løses og valg, der skal træffes. Det derfor være en god idé at etablere en emnelog, hvori projektemner i form af krav om ændringer, spørgsmål, nye informationer mv. noteres. Det kan være i form af nye risici, eller i form af nye muligheder for at få mere ud af projektet end først forventet. På baggrund af en beskrivelse af projektemnet træffer projektlederen beslutning om, hvordan det skal håndteres.
Fremgangsmåde
I emneloggen tildeles alle projektemner et unikt nummer, projektemnets type dokumenteres (f.eks. ændringsønske, spørgsmål eller bekymring) og projektemnet beskrives. Der noteres desuden en dato, samt hvem der har noteret opgaven. Kategorierne, der vælges til at beskrive opgaverne, kan justeres fra projekt til projekt. Det er herefter projektlederens opgave at sørge for at der bliver fulgt op på opgaven (skal den løses hvornår skal den være løst, og hvem skal løse den?). Undervejs skal de involverede projektdeltagere løbende notere status for opgaven (oprettet, igangværende, afvist eller afsluttet), således at alle projektets deltagere kan følge udviklingen i opgaveløsningen.
Hent redskab på modernisering.dk/projektmodel
· Skabelon til emnelog
Hent eksempel på modernisering.dk/projektmodel
· Eksempel på udfyldt emnelog
Produktnedbrydning og produktflowdiagram
- Nedbrydning af mål og leverancer til konkrete arbejdsopgaver
Når
målene er nedbrudt og gjort operative, skal der ses på hvilke
opgaver, der skal laves, for at målene kan nås.
Det kan virke uoverskueligt at overskue hvilke opgaver, der ligger i at
indføre fx et ESDH-system.
Derfor er det en god ide at nedbryde opgaven i mindre stykker, således at
arbejdsopgaverne bliver gjort mere overskuelige og håndfaste. Dette
kaldes for produktnedbrydningsanalyse.
Efter at have nedbrudt opgaverne i mindre arbejdsopgaver kan disse sættes i rækkefølge efter hvornår, de skal udføres i forhold til hinanden, for at opgaven kan løses. Flere rækker af opgaver kan naturligvis udføres sideløbende. Har man endvidere sat tid på, hvor lang tid de enkelte opgaver tager at udfærdige, kan man ved at lægge disse i forlængelse efter hinanden beregne, hvor lang tid opgaven tager at løse. Dette kaldes for produktflowdiagram.
· At få sat præcise ord og handlinger på hvilke opgaver, der skal løses
· At skabe et overblik over, i hvilken rækkefølge opgaverne skal løses
· At få udfærdiget samt estimere en tidsplan for, hvor lang tid opgaven vil tage at færdiggøre
· Produktnedbrydningsanalyse
· Identifikation af hvilke underopgaver, der skal løses, for at hovedopgaven bliver løst
· Tidsfastsættelse af opgavens produktionstid
Fremgangsmåde
Produktnedbrydningsdiagram
Den overordnede opgave identificeres. Opgaven brydes ned i mindre opgaver, der
igen nedbrydes, indtil opgaverne er af så simpel karakter, at de
umiddelbart er til at forstå og til at gå til. Til de enkelte
opgaver laves en liste over hvilke ressourcer, der skal til for at få
løst opgaverne, samt hvor lang tid det vil tage at løse
opgaverne.
Produktflowdiagram
Med
produktflowdiagrammet sættes opgaverne sættes op i
rækkefølge efter hvilke opgaver, der kan laves først, uden
at skulle vente på andre opgaver bliver løst. Dermed opnår
man en identifikation af den kritiske vej for opgaveløsningen.
Se eksempel på produktnedbrydningsdiagram
og produktflowdiagram på de næste sider
Projektnedbrydningsdiagram
|
|
Projektflowdiagram
Fase 2: Analyse- og planlægningsfasen
Fasen tager udgangspunkt i det projektinitieringsdokument, som styregruppen har godkendt i idébeskrivelsesfasen. På baggrund heraf indledes nu en analyse- og planlægningsfase, hvor der opstilles løsninger, der kan indfri projektmålet. Målet er at skabe grundlaget for styregruppens endelige beslutning om projektets udformning. Når styregruppen har taget stilling til projektets endelige udformning, kan planlægningen af projektet færdiggøres, så der fremkommer en detaljeret projektplan. Afhængigt af projektets størrelse og kompleksitet kan der være brug for at opdele analyse- og planlægningsfasen i flere faser. F.eks. kan det i nogle projekter være en fordel at indføre en egentlig specifikationsfase (se nedenfor).
Formål
Formålet med analyse- og planlægningsfase er, at der udarbejdes konkrete forslag til indfrielse af projektmålet, som styregruppen kan tage stilling til og som dermed kan danne grundlag for den endelige beslutning om projektets mål og rammer. Fasen skal desuden bidrage til, at forventningerne til projektet afstemmes gennem godkendelse af en klar og præcis projektplan.
Resultatmål
· Der er gennemført relevante analyser mhp. opstilling af mulige løsningsforslag, som styregruppen kan tage stilling til
· Der er udarbejdet en detaljeret projektplan. Dokumenterne fra idébeskrivelsesfasen, som udgjorde grundlaget for projektinitieringsdokumentet opdateres. Samtidig udarbejdes der dokumenter vedr. modenhed og kompetencer samt en kommunikationsplan.
De centrale dokumenter i denne fase er dermed:
· Projektplan
· Business case
· It-arkitektur og teknologi
· Modenhed og kompetencer
· Interessentanalyse
· Kommunikationsplan
· Risikostyring
· Projektstatus
Afhængigt at projektets størrelse og kompleksitet kan der være behov for at følge op på analyseaktiviteterne ved at igangsætte en egentlig specifikationsfase, hvori det nærmere specificeres, hvad it-delen af projektet konkret skal rumme, og hvilke krav der skal opstilles i forbindelse med udformningen af en kravspecifikation.
Fremgangsmåde
Indledningsvis foretages der i analyse- og planlægningsfasen en kortlægning og analyse af de nuværende it-strukturer og arbejdsprocesser samt relevante organisatoriske forhold. På baggrund heraf opstilles mulige løsningsforslag, der vil indfri projektmålene. Disse forslag forelægges for styregruppen, der beslutter sig for den endelige model for projektet. Sideløbende gøres der overordnede overvejelser om de projektplaner, der vil være tilknyttet hvert enkelt løsningsforslag, således at der er skabt et godt grundlag for udformningen af den endelige og detaljerede projektplan.
Det skal i denne fase således specificeres, hvilke nøgleprodukter projektet skal levere, hvornår og hvordan disse bliver leveret, hvad det må koste, kvalitetskrav til produkterne samt hvilke risici der foreligger. Afslutningsvis skal der desuden udarbejdes en plan for, hvordan den efterfølgende fase i projektet skal forløbe mhp. at opnå styregruppens godkendelse heraf.
Når styregruppen har truffet beslutning om den endelige projektmodel, kan projektplanen færdiggøres. Det vil være en god idé at involvere projektgruppen i udarbejdelsen af projektplanen. Det kvalificerer indholdet og gøder jorden for engagement og ejerskab i gruppen.
Kort om Specifikationsfase
Som nævnt tidligere er digitaliseringsprojekter kendetegnet ved at være projekter, der tager afsæt i indførelse af digital teknologi, der understøtter forretningsprocesser. Der vil derfor som opfølgning på analyse- og planlægningsfasen - hvor der blev valgt den løsning, der skal lede til opfyldelse af projektets mål - kunne være behov fore en egentlig specifikationsfase. Hvor meget denne del vil fylde i et digitaliseringsprojekt, vil være meget afhængig af projektets udformning, herunder om der er tale om et projekt, hvor der skal ske nyudvikling af it-løsninger eller der skal ske mindre tilpasninger af eksisterende løsninger. Under alle omstændigheder er det vigtigt at have gjort sig klart, hvilke krav der stilles til it-løsningerne.
Formål Formålet med en specifikationsfase er nærmere at specificere, hvad it-delen af projektet konkret skal rumme og hvilke krav, der skal opstilles i forbindelse med udformningen af en kravspecifikation.
Resultatmål
· Der er skabt klarhed over krav og forventninger til it-delen af projektet, hvilket danner baggrund for en evt. kravsspecikation.
Fremgangsmåde I sagens natur vil det især være it-arkitektur og teknologi, der skal arbejdes mest intensivt med i denne fase. Specifikationsfasen vil dog også kunne få betydning for de øvrige projektdokumenter som f.eks. business casen, modenhed og kompetencer samt risikostyringen og dermed på den samlede projektplan og projektets status. Elementerne i fasen er derfor de følgende:
· Projektplan
· Business case
· It-arkitektur og teknologi
· Kravspecifikation
· Modenhed og kompetencer
· Kommunikationsplan
· Risikostyring
· Projektstatus
Dokumenter/redskaber til fase 2: Analyse- og planlægningsfasen
Projektplan
Når styregruppen har truffet endelig beslutning om den løsning, som projektet skal føre ud i livet mhp. at opnå de fastsatte projektmål, kan der udarbejdes en detaljeret projektplan for projektet.
Formål
Projektplanen skal skabe overblik over sammenhænge mellem ressourcer, aktiviteter og tid. Således vil projektplanen bidrage til at aftale og fastholde forventninger til projektets forløb samt at samle al nødvendig information for at kunne styre og kontrollere et projekt.
Resultatmål
· Der er etableret en projektplan, der viser sammenhænge mellem indsatsområder, aktiviteter og evt. ressourcer, ansvarlige, udførelsesstatus og prioriteringer
· Planen muliggør sortering af relevante data, der giver overblik i forhold til den konkrete anvendelsessituation
· Planen vedligeholdes, så den giver overblik over projektets aktuelle status
Fremgangsmåde
Informationerne i projektplanen kan med fordel indsamles i forlængelse af fastlæggelsen af delmål, milepæle og ressourceestimering. I projektplanen beskrives:
· Projektets strategi
· Projektets milepæle og hvornår disse foreligger
· Projektets overordnede faser og aktiviteter
· Projektets ressourcer og rammer
· Skitse til projektorganisationen
· Planen opdateres løbende
Som minimum ved hvert faseskift, hvor den kommende fase detaljeres/justeres. Detaljeringsniveauet vil afhænge af det konkrete projekts behov for at kunne sortere relevante projektdata. Der kan således skabes forskellige typer af overblik over projekter, der kan fungere som udgangspunkt for forventningsafstemning, kommunikation, opfølgning og justering af projektet. Projektplanen er den naturlige fortsættelse af den opgavenedbrydning, der er sket i milepælsplanlægningen. Planer for faser, hvor it-systemet realiseres, udarbejdes med deltagelse af leverandøren.
Hent redskab på modernisering.dk/projektmodel
- Skabelon til en projektplan
Business case
I analysefasen foretages en ny/mere dybdegående beregning af business casen. Der afsættes ressourcer til at indhente detailoplysninger og beregninger, og de seneste oplysninger opdateres, og hvis der er kommet nye forudsætninger til, skal disse indarbejdes.
Formål
Formålet med beregningen af business casen i analysefasen er at give styregruppen det bedst mulige beslutningsgrundlag i forhold til at træffe beslutning, om projektet skal fortsætte samt at give styregruppen et værktøj til at kunne prioritere mellem flere projekter
Resultatmål
· Der er udarbejdet en business case, der rummer vigtig styregruppeinformation på baggrund af de nyeste opdateringer af projektet
· Styregruppen tager ved udgangen af analysefasen stilling til, om projektet skal fortsætte i sin nuværende form eller om det skal ændres. Evt. kan nye oplysninger være af så negativ karakter, at ledelsen bør beslutte at lukke projektet ned, så der ikke ”smides gode penge efter dårlige” projekter.
Baggrund
Der skal generelt i arbejdet med digitale projekter løbende holdes øje med, om forudsætningerne ændrer sig. Det er vigtigt, at der løbende laves opdateringer af business casen således, at der hele tiden holdes styr på, om det kan betale sig at fortsætte med projektet – en beslutning, der må tages stilling til ved overgangen til næste fase. Styregruppen får på denne måde undervejs i forløbet mulighed for at stoppe projektet eller omforme det, hvis det viser sig, at de nye forudsætninger ændrer på business casen.
Med hensyn til business casens omkostningsside har Den Digitale Taskforce tidligere lanceret et værktøj til IT-omkostningsopgørelse. Dette værktøj kan benyttes til at understøtte opgørelsen af omkostningssiden i den samlede business case.
Hent redskaber på modernisering.dk/projektmodel
· Den generelle business case model
· Business case vejledning
· Omkostningsmodel inkl. regneark og ”Estimering af IT-omkostninger” – vejledning
Hent eksempler på modernisering.dk/projektmodel
· ”Estimering af IT-omkostninger ved indførelse af FESD i Den Sociale Sikringsstyrelse”
· Fiktivt eksempel på at bruge business case modellen
It-arkitektur og teknologi
I det følgende præsenteres en beskrivelse af det forløb og de overvejelser, der hører til en analyse af projektets it-arkitektur og teknologi i analyse og planlægningsfasen:
Formål
· At sikre at It-løsningen understøtter organisationens visioner og strategi
· At teknologien understøtter forvaltningen bedst muligt
· At It-løsningen kan kommunikere åbent, fleksibelt og sikkert med andre It-systemer.
Resultatmål
· Indhent organisationens vision og strategi fra det overordnede arkitekturarbejde, eller dokumenter den
· Udarbejd en detaljeret beskrivelse af den eksisterende infrastruktur på områder som projektidéen har afhængigheder til - udbygning af arbejdet i idefasen – som kom fra det overordnede arkitekturoverblik
· Skab overblik over løsningsområdet forretningsbegreber og processer.
· Lav et System Kontekst Diagram – til kommunikation og “salg” til interessenter og projektorganisationer
· Fastlæg funktionelle krav og ikke-funktionelle krav også kaldet kvalitetsparametre
· Bliv bekendt med nuværende it-standarder fastlagt i det overordnede arkitekturarbejde eller dokumenter nuværende It-standarder
Brug begrebsmodel
Hvis organisationen har en overordnet begrebsmodel – så udpeg de begreber som anvendes i løsningen eller dokumenter de nævnte begreber
· Indhent dokumentation over de processer som løsningen skal understøtte – fra forretningen eller fra tidligere arkitekturarbejde
· Beskriv forretningsområdet i et overordnet procesdiagram med tilhørende dokumentation. Identificér potentielle subsystemer og definer funktionelle sikkerhedskrav. Dette gøres på basis af begrebsmodel og procesbeskrivelse eller use case model. Der beskrives hvilke handlinger de identificerede roller/aktører skal kunne udføre på begrebsmodellens forskellige typer af information i et såkaldt CRUD-diagram (CRUD står for Create, Read, Update og Delete = Opret, Læs, Opdater og Slet)
· Opdater Business Case – og vurder om projektet stadig er levedygtigt
Brug use case model
1. Lav liste over brugere, eksisterende systemer og kendte funktionelle krav, herunder hændelsesliste fra procesanalyser.
2. Uddrag aktører og use cases fra pkt. 1; Opbyg use-case model
3. Skab overblik over genbrugelige arkitekturprodukter (fx. Referencemodeller, mønstrer og evt. ”pakkeløsninger”, som kan være løsningskandidater
4. Map de use cases, der er dokumenteret under pkt. 2 med use cases fra genbrugelige arkitekturprodukter og evt. ”pakkeløsninger”, og fastslå, hvor stor en del af løsningen, der vil kunne baseres på genbrug/allerede eksisterende løsninger
5. Fastlæg hvilke use cases, som vedrører funktionalitet, der ikke er dækket af de genbrugelige løsninger. Kategoriser eventuelt disse i forhold til løsningsmønstre.
6. Fastlæg ikke-funktionelle krav, der også kaldes kvalitetsparametre for løsningen
7. Valider kravene med brugere og beslutningstagere ved gennemgang af use cases og evt. papirprototype.
Leverancer/Genbrug
Mere detaljeret beskrivelse af eksisterende infrastruktur på områder som projekt-ideen er afhængig af:
· Organisationens Vision og strategi
· Begrebsmodel og overordnet proces
· System Kontekst Diagram
· Use Case Model med funktionelle krav
· Dokumentation af it-standarder
· Dokument med ikke-funktionelle krav (kvalitetsparametre for løsningen)
Kravspecifikation
Udarbejd kravspecifikation:
· Brug generelle arkitekturkriterier for vurdering af løsninger (hvis dette dokument findes) til evt. at foretage yderligere afgrænsninger i forhold til løsningens udfaldsrum
· Arkitekturmæssigt indhold: Stort set alle arkitekturleverancer fra denne og de foregående faser
· Skal indeholde klare, testbarre krav, og krav til svarene der gør at de nemt kan sammenlignes
Leverancer:
Dokument med arkitekturmæssige beslutninger
Diagram med arkitekturmæssigt overblik på subsystemniveau
Diagram med arkitekturmæssigt overblik på logisk system niveau
Evt. Komponentmodel
Kravspecifikation (inkl. Driftsbetingelser (SLA krav))
Yderligere vejledning
· Læs mere om it-arkitektur på oio.dk/arkitektur.
· Læs om den fællesoffentlige referencemodel (FORM) og den fællesoffentlige integrationsmodel på Taskforcens hjemmeside modernisering.dk/integrationsmodel og modernisering.dk/form
Interessentanalyse
I løbet af et projekt vil en eller flere interessenter ofte skifte betydning for projektet, og samspillet med de enkelte interessenter vil kunne ændre sig i løbet af projektet. Det er derfor vigtigt hele tiden at have for øje, hvilken rolle de enkelte interessenter har i løbet af projektet. Det er også vigtigt løbende at vurdere interessenterne, da dette kan påvirke business casen.
Formål
De identificerede interessenters interesser, og måden hvorpå de skal håndteres, skal justeres efter hvilken fase, projektet befinder sig i. På denne måde vedligeholdes overblikket over projektets interessenter, således at der fortsat sikres en målrettet og differentieret håndtering af projektets interessenter, herunder at der bibeholdes de strategisk vigtige relationer mellem projektet og interessenterne.
Resultatmål
· Projektets interessentanalyse er opdateret
· Interessenterne er positioneret i forhold til væsentlighed for projektet i forhold til analysefasen
· Der er opstillet konkrete aktiviteter til håndtering af fasens vigtige interessenter. Interessentanalysen bør justeres løbende - også mellem faseovergangene - da projektet og dets kontekst kan ændre sig med tiden.
Hent eksempel på modernisering.dk/projektmodel
· Eksempel på en interessentanalyse fra projektet "Kampagne for digitale selvbetjeningsløsninger"
Kommunikationsplan
Formål
Formålet med en kommunikationsstrategi er at skabe klarhed over, hvad der skal kommunikeres, med hvem, hvordan, hvornår - og med hvilken effekt. Kommunikationsstrategien skal understøtte projektets gennemførelse, bidrage til at sikre ejerskab og samtidig sikre, at projektets resultater formidles til de involverede interessenter. Projektets kommunikationsstrategi skal sikre, at overvejelser om kommunikation tidligt tænkes med i de samlede overvejelser om tilrettelæggelsen af et projekt.
Resultatmål
· Formål, budskaber, målgrupper og medier er identificeret
· Der er sket en konkret udmøntning af kommunikationsaktiviteter
· Der sker løbende en evaluering og effektmåling af kommunikationen
Fremgangsmåde
En velfungerende kommunikationsstrategi kan med fordel tage afsæt i en analyse af projektets interessenter. Interessentanalysen kan give et værdifuld input i forhold til afklaring af en række centrale spørgsmål, når kommunikationsstrategien udarbejdes. I en kommunikationsstrategi bør indgå afklaring af:
· formål
· budskab(er)
· målgruppe(r)
· medie(r)
· timing
· alliancemuligheder
· succeskriterier
Formål, budskaber og målgrupper
Hvad ønskes opnået gennem kommunikationsaktiviteterne? Hvad er det - eller de centrale budskaber - der skal kommunikeres i relation til projektet? Hvem skal budskaberne kommunikeres til? Er der tale om ren information (envejs) - eller skal en eller flere af målgrupperne inddrages mere aktivt i projektets kommunikation? Det er en vigtig pointe, at formål, budskaber og målgrupper skal være afklaret, inden der tages hul på overvejelserne om medievalg. En flot opsat artikel i Politiken kan være værdiløs, hvis målgruppen for budskabet typisk ikke orienterer sig i københavnske morgenaviser.
Som hovedregel bør der i en kommunikationsstrategi indgå overvejelser om såvel intern som ekstern kommunikation. Ofte fokuseres der i kommunikationsstrategier for ensidigt på den eksterne kommunikation - fx pressen eller medlemskommunerne - mens det overses, at kollegerne kan være potentielt stærke ambassadører for projektet.
Medier
Hvordan nås målgrupperne bedst? Et nyhedsbrev kan sjældent stå alene, men kan ofte med fordel suppleres med andre medier. Det er vigtigt at være opmærksom på hele paletten af medier:
· dialog-/debatmøder
· kursusvirksomhed
· interne trykte medier (fx nyhedsbreve, pjecer mv.)
· eksterne medier (fx dagblade, fagblade, elektroniske medier)
· hjemmesider og intranet
Timing
Hvornår skal hvilke initiativer sættes i værk? Timing er essentiel, når man ønsker sit budskab sat på dagsordenen hos en målgruppe. En måde at arbejde med timing på er at undersøge, om der er andre ydre begivenheder, der kan medvirke til at øge opmærksomheden på dit budskab eller som vil kunne overskygge det.
Alliancemuligheder Hvem kan forventes at bakke op bag strategiens budskaber - og hvem kan omvendt forventes at modarbejde dem? Kan der gøres noget for at styrke mulige alliancer eller for at svække modstand - fx ved inddragelse?
Succeskriterier Hvordan godtgøres det, at strategien har virket efter hensigten? Succeskriterier er især vigtige for at kunne evaluere på strategien: Hvad var effekten af kommunikationsarbejdet? Hvad virkede godt? Hvad kan gøres bedre næste gang?
Hent redskaber på modernisering.dk/projektmodel
· Skabelon for kommunikationsstrategien
Risikostyring
I takt med at projektet bevæger sig fra den ene fase til den næste, vil det vise sig, om de risikomomenter, som blev identificeret i idebeskrivelsesfasen, er kommet til udtryk, eller om det er lykkedes at styre uden om dem. Samtidig vil der ofte dukke nye oplysninger op, som stiller spørgsmål ved, om projektet kan gennemføres med det ønskede resultat. Der skal derfor i hele projektets levetid findes en fornuftig balance mellem omkostninger og fordele samt den tilhørende risiko. Overgangen til næste fase af et it-projekt bør først ske efter, at der er gennemført en ny risikovurdering, der omfatter de seneste oplysninger, der kan have betydning for projektets resultater.
Formål
Formålet med en opdatering af risikovurderingen er at sikre, at der stadig er en fornuftig balance mellem risici, omkostninger og fordele. Risikovurderingen skal stadig rumme en vurdering af konsekvensen, såfremt en given risiko indtræffer samt en plan for, hvad der kan gøres for at undgå, reducere eller fjerne en bestemt risiko.
Resultatmål
· Der er udarbejdet en beskrivelse af de væsentligste risici i fasen
· Der er opstillet forslag til at undgå, reducere eller fjerne en bestemt risiko for hver aktivitet
· Der foretages løbende konkrete justeringer af projektet for at forebygge eller reducere konsekvenser af de opstillede risici.
· De væsentligste risici og argumenterne herfor skal dokumenteres løbende, fx i business casen.
Hent redskaber på modernisering.dk/projektmodel
· Skabelon til risikostyring
· Tjekliste til vejledning i risikostyring
· ”Vejledning om risikovurdering ved forelæggelse af it-projekter for Finansudvalget”
· Taskforcens Business case model: Afsnit om risikovurdering
Hent eksempel på modernisering.dk/projektmodel
· Eksempel på risikovurdering fra eDag2-projektet
Projektstatus
Det er igennem et projekts levetid vigtigt løbende at følge op på projektstatus, så der kan foretages korrigerende handlinger, såfremt projektet afviger fra projektplanen. Der skal derfor udarbejdes en projektstatus for projektet med passende mellemrum.
Formål
Formålet med projektstatus er at give styregruppen en opsummering af fasens status med de mellemrum, der er aftalt mellem projektlederen og styregruppen. Styregruppen bruger projektstatus til at overvåge fase- og projektfremdrift. Projektlederen bruger den også til at advisere styregruppen om evt. problemer eller områder, hvor styregruppen kunne hjælpe. Der er flere forskellige metoder til at afrapportere projektstatus, som kan anvendes, og som hver især kan være gode.
Nedenfor skitseres de elementer, som en statusrapport som minimum bør indeholde. Hovedprincippet er, at på baggrund af de udførte leverancer og de identificerede risici i projektet skal gøres redes for fremdriften i projektet, herunder de væsentligste trusler mod projekter og hvad der planlægges gjort for at imødegå disse.
Indhold i statusrapport
· Dato
· Den omfattende periode
· Budgetstatus
· Status for tidsplan
· Produkter, der er færdiggjort i løbet af perioden
· Aktuelle eller potentielle problemer og risikoopdatering
· Produkter, der skal færdiggøres i løbet af den efterfølgende periode
· Status for evt. projektemner, jf. emneloggen
· Eventuelle ændringers effekt på budget og tidsplan
Fase 3: Udviklings- og implementeringsfasen
Når projektplanlægningen er gennemført og analyse- og planlægningsfasen dermed er afsluttet, går projektet over i udviklings- og implementeringsfasen, hvor projektets mål og formål skal realiseres. Denne fase er således den fase, hvor der arbejdes med selve projektet. Fasen kan deles op i flere delfaser. Ved afslutningen af fasen skal projektetplanen, business casen samt risikovurderingen som minimum opdateres.
Formål
Formålet med udviklings- og implementeringsfasen, er at realisere projektets mål og formål, herunder producere de produkter, der er aftalt med styregruppen.
Resultatmål
· Projektets konkrete mål bliver realiseret
· Evt. justeringer af produktionen er sket med accept fra styregruppen I udviklings- og implementeringsfaen skal der være fokus på proces og resultater.
Elementerne i denne fase er:
· Projektplan
· Business case
· Udbud og implementering
· Interessentanalyse
· Kommunikationsplan
· Risikostyring
· Projektstatus
Justering af planerne
Projektplanen skal løbende opdateres gennem projektets løbetid, så det sikres, at projektet holder sig inden for de aftalte rammer, og at der kan gribes ind, hvis projektet nærmer sig de tolerancer, der er aftalt for projektet. Opdateringen af projektplanen bidrager til at skabe overblik over sammenhænge mellem ressourcer, aktiviteter og tid. Overblikket skal fungere som udgangspunkt for forventningsafstemning, kommunikation, opfølgning og justering af projektet. Projektet skal opdateres ved hver faseovergang, hvis udviklings- og implementeringsfasen er opdel i flere delfaser.
Risici
I takt med, at projektet skifter fase vil det vise sig, om de risikomomenter, som blev identificeret i analyse- og planlægningsfasen, faktisk er blevet til realiteter, eller om det er lykkedes at styre uden om dem. Samtidig vil der ofte dukke nye oplysninger op, som stiller spørgsmål ved, om projektet kan gennemføres med det ønskede resultat. Der skal derfor i hele projektets levetid findes en fornuftig balance mellem omkostninger og fordele samt den tilhørende risiko. Formålet med opdateringen af risikovurderingen ved hver faseovergang, er at sikre, at denne balance opretholdes. Risikovurderingen skal stadig rumme en vurdering af konsekvensen, såfremt en given risiko indtræffer samt en plan for, hvad der kan gøres for at undgå, reducere eller fjerne en bestemt risiko.
Business casen
Business casen skal opdateres tilsvarende de øvrige projektelementer. I denne fase skal business casen tjene som en pejling på, om der opstår et misforhold mellem de forventede gevinster og omkostninger. Sker der radikale ændringer i dette forhold, skal styregruppen straks involveres.
Styring af projektgruppen
Projektlederen skal være opmærksom på gruppens engagement og prioritering af arbejdsopgaver. Nedprioriterer projektdeltagerne projektet, bør dette tages op enten med projektdeltageren selv, dennes chef eller projektgruppen som helhed. Et "sundhedstjek" af projektgruppen kan med fordel foretages med jævne mellemrum, og kan f.eks. tage udgangspunkt i profiltest eller gruppens egen forventninger til hinanden, som bør have været opstillet ved et opstartsseminar. Projektlederen skal desuden være opmærksom på gruppens kompetencer i forhold til at løse diverse arbejdsopgaver.
Projektlederen skal være opmærksom på:
· Hvilke arbejdsopgaver, der skal løses
· Hvilke kompetencer er nødvendige for at løse arbejdsopgaverne
· Om der skal igangsætte læringsaktiviteter, for at opnå nødvendige kompetencer i projektgruppen
· Om der bør inddrages nye personer/kompetenceprofiler i projektet
Interessenterne
I løbet af et projekt vil en eller flere interessenter ofte skifte betydning for projektet, og samspillet med de enkelte interessenter vil kunne ændre sig i løbet af projektet. Det er derfor vigtigt hele tiden at have for øje, hvilken rolle de enkelte interessenter har i løbet af projektet. De identificerede interessenters interesser, og måde hvorpå de skal håndteres, skal justeres efter hvilken fase, projektet befinder sig i. På denne måde fastholdes overblikket over projektets interessenter, således at der fortsat sikres en målrettet og differentieret håndtering af projektets interessenter, herunder at de strategisk vigtige relationer mellem projektets og dets interessenter bibeholdes.
Fokusering på projektejer og styregruppen
For at opretholde ledelsesbevågenhed på projektet bør der være en løbende kommunikation omkring projektets status. Har projektet lange tidsmæssige faser, bør der indlægges projektleverancemilepæle i projektet, hvor projektlederen giver en løbende status til styregruppen. Er projektet derimod opbrudt i mange faser, hvor tidshorisonten mellem faserne er begrænset, vil der automatisk forekomme løbende fasestatusrapporter ved hver faseovergang. Statusrapporten bør i øvrigt udarbejdes i forhold til det projektinitieringsdokument, som ledelsen/styregruppen har godkendt.
Dokumenter og redskaber til Fase 3: Udviklings- og implementeringsfasen
Projektplan
Projektplanen skal løbende opdateres igennem projektets løbetid, så det sikres, at projektet holder sig inden for de aftalte rammer, samt at der kan gribes ind, hvis projektet nærmer sig de ydre tolerancer, der er aftalt for projektet. Det er derfor nødvendigt med et tæt samspil mellem projektplan og projektstatus i projektets levetid.
Formål
Den løbende opdatering af projektplanen bidrager til at fastholde overblik over sammenhænge mellem ressourcer, aktiviteter og tid. Overblikket skal fungere som udgangspunkt for forventningsafstemning, kommunikation, opfølgning og justering af projektet.
Resultatmål
· Der foreligger en opdateret projektplan, der viser sammenhængene mellem indsatsområder, aktiviteter og evt. ressourcer, ansvarlige, udførelsesstatus og prioriteringer i udviklings- og implementeringsfasen
· Den opdaterede plan giver fortsat mulighed for sortering af relevante data, der giver overblik i forhold til den konkrete anvendelsessituation
· Planen vedligeholdes løbende, så den giver overblik over projektets aktuelle status. Projektplanen bidrager til at skabe overblik over sammenhænge mellem ressourcer, aktiviteter og tid. Detaljeringsniveauet vil afhænge af det konkrete projekts behov for at kunne sortere relevante projektdata. Dermed skabes forskellige typer af overblik over projektet, der kan fungere som udgangspunkt for forventningsafstemning, kommunikation, opfølgning og justering af projektet. Projektplanen er den naturlige fortsættelse af den opgavenedbrydning, der er sket i milepælsplanlægningen.
Business case - den løbende opdatering
Som tidligere nævnt bør der arbejdes med en business case igennem hele forløbet af et digitaliseringsprojekt. Beregninger af potentialer og omkostninger justeres i takt med, at der i projektforløbet opnås en mere præcis viden om besparelsesmuligheder og omkostninger forbundet med projektet. Specielt skal der foreligge en opdateret business case ved hver faseovergang.
Formål
At give styregruppen en melding om, at projektet fortsat indeholder de gevinstmuligheder, som tidligere blev estimeret
Fremgangsmåde
Nye forudsætninger og informationer, der er kommet til med betydning for den beregning af business casen, som tidligere er foretaget, skal indarbejdes. Der kan f.eks. være tale om, at it-udstyr, der forventes indkøbt, er dyrere end beregnet. Opdateringen af business casen fører til at styregruppen skal træffes beslutning, om projektet skal overgå til næste projektfase. Den grundlæggende beregningsmetode for business casen er uændret, og det er stadig de samme redskaber som tidligere, der kan benyttes.
Hent redskaber på modernisering.dk/projektmodel
· Den generelle business case model
· Business case vejledning
· Omkostningsmodel inkl. regneark og Estimering af it-omkostninger - vejledning
· ”Effektmåling af offentlige it-projekter”
Hent eksempler på modernisering.dk/projektmodel
· Business case eksempel
Udbud og implementering
It-anskaffelse er en tids- og ressourcekrævende opgave, men er et vigtigt element i digitaliseringen af den offentlige sektor. Økonomistyrelsen har derfor i samarbejde med Den Digital Taskforce udarbejdet en vejledning i udbud og indkøb af it-systemer.
Formål
Formålet
med vejledningen er at rådgive om og inspirere til, hvordan statslige
institutioner kan tilrettelægge arbejdet med at anskaffe et it-system.
Vejledningen giver et overblik over processen, masser af gode råd og
indeholder desuden links til relevante kilder, hvor der kan læses mere.
Kulturministeriets departement, Odense Kommune, Cap Gemini samt Statens og Kommunernes
Indkøbsservice A/S har bidraget med gode råd og erfaringer til
vejledningen. På IT- og Telestyrelsens hjemmeside kan du finde
standardkontrakter for både kortvarige (K01) og længerevarende
it-projekter (K02):
http://www.itst.dk/it-styring/standardkontrakter
Som en del af at udarbejde en standardkontrakt vil en vurdering af leverandørens modenhed indgå. Se publikationen ”Modenhed i it-baserede forretningsprojekter” på oio.dk/styring/modenhed
På Konkurrencestyrelsens hjemmeside www.ks.dk/udbud findes desuden relevant information om gennemførelse af EU-udbud mhp. indgåelse af offentlige kontrakter, herunder it-kontrakter. Her findes blandt andet link til udbudsdirektivet samt til standardformularer til offentliggørelse af EU-udbud, eksempelvis udbudsbekendtgørelsen.
KL og Erhvervs- og Byggestyrelsen har ligeledes sammen udviklet Udbudsportalen www.udbudsportalen.dk, der tilbyder offentlige udbydere og private leverandører vejledning i, viden om og værktøjer til gennemførelse af udbud. Portalen indeholder blandt andet en trin-for-trin-udbudsguide.
Hent redskaber på modernisering.dk/projektmodel
· Vejledning i udbud og indkøb af it-systemer
Hent yderligere redskaber
·
Standardkontrakter for
kortvarige (K01) og længerevarende it-projekter (K02):
http://www.itst.dk/it-styring/standardkontrakter
· Værktøjer til gennemførelse af udbud: www.udbudsportalen.dk
· Værktøjer til gennemførelse af EU-udbud: www.ks.dk/udbud
Interessentanalyse
I løbet af et projekt vil en eller flere interessenter ofte skifte betydning for projektet, og samspillet med de enkelte interessenter vil kunne ændre sig i løbet af projektet. Det er derfor vigtigt hele tiden at have for øje, hvilken rolle de enkelte interessenter har i løbet af projektet.
Formål
De identificerede interessenters interesser og måden hvorpå de skal håndteres, skal justeres i forhold til hvilken fase projektet befinder sig i. På denne måde vedligeholdes overblikket over projektets interessenter, således at der fortsat sikres en målrettet og differentieret håndtering af projektets interessenter, herunder at der bibeholdes de strategisk vigtige relationer mellem projektet og interessenterne.
Resultatmål
· Projektets interessentanalyse er opdateret
· Interessenterne er positioneret i forhold til væsentlighed for projektet i forhold til analysefasen
· Der er opstillet konkrete aktiviteter til håndtering af fasens vigtige interessenter
Interessentanalysen bør justeres løbende - også mellem faseovergangene - da projektet og dets kontekst kan ændre sig med tiden. I udviklings- og implementeringsfasen er det ofte brugerne, der skal være fokus på. I denne fase skal der ofte testes. Dvs. at nye arbejdsgange ofte kommer i spil, hvilket kan give anledning til en del opmærksomhed blandt brugerne. Enten i form af, at testpersoner oplever en væsentlig lettelse i deres dagligdag, og der derved vil komme pres fra mange sider om at få indført de nye arbejdsgange så hurtigt som muligt, eller fordi der spredes rygter om en række besværligheder, som det er vigtigt at forholde sig til.
Kommunikationsplan
Formål
Formålet med at opdatere kommunikationsstrategien er at sikre, at der kommunikeres på den mest hensigtsmæssige måde i udviklings- og implementeringsfasen. Der kan løbende indtræffe begivenheder, der tilsiger, at kommunikationsplanen skal justeres.
Resultatmål
· Der er sket en opdatering af formål, budskaber, målgrupper og medier
· Der foretages de nødvendige justeringer af den konkrete udmøntning af kommunikationsaktiviteter
· Der sker en løbende evaluering og måling af effekt af kommunikation
Fremgangsmåde
Opdateringen af kommunikationsstrategien kan med fordel tage afsæt i en analyse af projektets interessenter. Den opdaterede interessentanalyse vil kunne give input i forhold til afklaring af en række centrale spørgsmål, når kommunikationsstrategien skal opdateres.
Kommunikationsstrategien skal opdateres indenfor:
· budskab(er)
· målgruppe(r)
· medie(r)
· timing
· alliancemuligheder
Formål, budskaber og målgrupper De centrale spørgsmål er, om de centrale budskaber har ændret sig, og om der er sket ændring af målgruppen? Det vil i den forbindelse stadig være vigtigt at skelne mellem intern og ekstern kommunikation.
Medier Det skal undersøges, om den hidtidige anvendelse af de valgte medier har haft den ønskede effekt, eller der måske er behov for at skifte til andre medier.
Timing Den opstillede plan for timing af kommunikationsaktiviteterne skal revurderes, så det sikres, at den er i overensstemmelse med projektets faktiske fremskridt.
Alliancemuligheder Det skal fortsat overvejes, hvem der kan forventes at bakke op om strategiens budskaber - og hvem der omvendt kan forventes at modarbejde dem, og om der kan gøres noget for at styrke mulige alliancer eller for at svække modstand - fx ved inddragelse?
Hent redskaber på modernisering.dk/projektmodel
· skabelon for kommunikationsstrategi
Risikostyring
I takt med at projektet skifter fase vil det vise sig, om de risikomomenter, som blev identificeret i idebeskrivelsesfasen, er kommet til udtryk, eller om det er lykkes at styre uden om dem. Samtidig vil der ofte dukke nye oplysninger op, som stiller spørgsmål ved, om projektet kan gennemføres med det ønskede resultat. Der skal derfor i hele projektets levetid findes en fornuftig balance mellem omkostninger og fordele samt den tilhørende risiko. Overgangen til næste fase af et it-projekt bør først ske efter, at der er gennemført en ny risikovurdering, der omfatter de seneste oplysninger, der kan have betydning for projektets resultater.
Formål
Formålet med en opdatering af risikovurderingen er sikre, at der stadig er en fornuftig balance mellem risiko, omkostninger og fordele. Risikovurderingen skal stadig rumme en vurdering af konsekvensen, såfremt en given risiko indtræffer samt en plan for, hvad der kan gøres for at undgå, reducere eller fjerne en bestemt risiko.
Resultatmål
· Der er udarbejdet en beskrivelse af de væsentligste risici i fasen
· Der er opstillet forslag til at undgå, reducere eller fjerne en bestemt risiko for hver aktivitet
Der foretages løbende konkrete justeringer af projektet for at forebygge eller reducere konsekvenser af de opstillede risici. De væsentligste risici og argumenterne herfor er dokumenteret.
Hent redskaber på modernisering.dk/projektmodel
· Skabelon til risikostyring
· Tjekliste til vejledning i risikostyring
· ”Vejledning om risikovurdering ved forelæggelse af it-projekter for Finansudvalget”
Projektstatus
Det er igennem et projekts levetid vigtigt løbende at følge op på projektstatus, så der kan foretages korrigerende handlinger, såfremt projektet afviger fra projektplanen. Der skal derfor udarbejdes en projektstatus for projektet med passende mellemrum.
Formål
Formålet med projektstatus er at give styregruppen en opsummering af fasens status med de mellemrum, der er aftalt mellem projektlederen og styregruppen. Styregruppen bruger projektetstatus til at overvåge fase- og projektfremdrift. Projektlederen bruger den også til at advisere styregruppen om evt. problemer eller områder, hvor styregruppen kunne hjælpe. Der er flere forskellige metoder til at afrapportere projektstatus, som kan anvendes, og som hver især kan være gode.
Nedenfor skitseres de elementer, som en statusrapport som minimum bør indeholde. Hovedprincippet er, at på baggrund af de udførte leverancer og de identificerede risici i projektet skal gøres redes for fremdriften i projektet, herunder de væsentligste trusler mod projekter og hvad der planlægges gjort for at imødegå disse.
Indhold i statusrapport
· Dato
· Den omfattende periode
· Budgetstatus
· Status for tidsplan
· Produkter, der er færdiggjort i løbet af perioden
· Aktuelle eller potentielle problemer og risikoopdatering
· Produkter, der skal færdiggøres i løbet af den efterfølgende periode
· Status for evt. projektemner, jf. emneloggen
· Eventuelle ændringers effekt på budget og tidsplan
Øvrige redskaber til brug til fase 3: Udviklings- og implementeringsfasen
Diverse metoder til at sikre en brugerorienteret løsning
Borgeren/brugeren i centrum
Ideer til hvordan den offentlige service forbedres bør i videst mulige omfang tage afsæt i konkrete undersøgelser, der har fokus på at identificere, hvad brugeren af X service har behov for.
Der findes
mange brugercentriske metoder, der alle har sine fordele og ulemper.
Nedenfor er de mest klassiske metoder beskrevet. Taskforcen anbefaler i
øvrigt den tværministerielle udviklingsenhed mind-lab.dk
for at få inspiration til at gennemføre
brugercentriske udviklingsprojekter. Det er ofte også relevant, at
bruge disse metoder allerede i ideudviklingsfasen.
Dybdegående
interview (enkelte, åbne semi-strukturerede interviews)
Det centrale ved den kvalitative metode er forsøget på at
opnå en indgående forståelse for det problemkompleks, man
undersøger. Metoden har den fordel, at man kan gå mere i dybden
for eksempel i form af grundige ikke-styrede interview med enkelte udvalgte brugere.
Til gengæld må man af ressourcemæssige årsager ofte
begrænse undersøgelsen til få brugere, hvorved
generalisering til brugerne under ét vanskeliggøres.
Fokusgrupper
interview
En mindre kreds af
borgere samles med det formål at spørge om deres holdning til et
bestemt produkt, ydelse eller andet. Ved at samle en gruppe brugere i et rum,
bliver der god mulighed for at diskutere ønsker og behov, gode og
dårlige sider ved et produkt osv.
Ulempen ved metoden er, at det tager tid, koster penge i nogen udstrækning,
og det er relativt få personer, man drager konklusioner ud fra.
Personas
En personas er en
fiktiv modelborger, der er lavet på baggrund af kvantitativ og kvalitativ
data. Modsat virkelige mennesker, der kun kan siges at repræsentere
sig selv, er en persona sammensat sådan, at den repræsenterer mange
mennesker ad gangen. Derfor er personas stærke som databærere i
udviklingsarbejde og til at forankre service og tilbud, der er målrettet
både grupper og enkeltpersoner. Personas er dermed en måde, hvorpå
man kan operationalisere og inddrage sin viden om brugeren i både analyse
og udviklingsarbejde. Dermed øges chancen for at ramme målgruppens
behov.
Processen for arbejdet med personas indeholder udvikling af personas på baggrund af beslutninger om målgruppefokus og dataindsamling, workshops med fokus på brugsscenarier og konkrete brugertests. Med udviklingen af borger.dk er der konstrueret 12 personas med henblik på at målrette den digitale kommunikation. Personaerne er omfattet af en såkaldt ”Creative Commons” licens, sådan at de frit kan anvendes til at udvikle digital borgerservice andre steder.
Hent redskab
· På borger.dk/personas findes borger.dk’s 12 personas, samt ”gode råd og gør det selv”-guides til de forskellige faser i arbejdet med personas
Forumteater
og kollegial refleksion
Forumteater og
kollegial refleksion er nye metoder til at afdække problemstillinger og
dilemmaer i samspillet mellem for eksempelvis forvaltning og brugere/borgere.
Forumteater fungerer ved, at man f. eks sætter borgere og sagsbehandlere
sammen. Skuespillere dramatiserer borgernes oplevelser af mødet med
"systemet", det vil sige sagsbehandlingen og brugerinddragelsen.
Undervejs har deltagerne mulighed for at rette på skuespillerne, så
scenerne kan spilles om, indtil deltagerne mener, at scenen nu afspejler det
virkelige hændelsesforløb og de dilemmaer, de står i.
På den måde faciliteres dialogen mellem deltagerne af skuespillerne
og konsulenterne. Fordelen er desuden, at problemstillingen angribes i en
interaktiv proces, der afmonterer fastlåste roller og forståelser.
Café
Dialoger
Café Dialog
er en metode til dynamisk videndeling og idéudvikling i grupper, hvor et
stort antal deltagere medvirker på lige fod. En kreds af borgere kan
f.eks. dele forventninger, ønsker og udvikle nye idéer sammen,
som grundlag for udvikling af for eksempel nye elektroniske
selvbetjeningsløsninger. Med udgangspunkt i en café-lignende
opstilling med borde, menuer, lys og duge etableres et uformelt rum, designet med
det ene formål at stimulere deltagerne til videndeling, udvikling og
fælles læring. Ulempen ved metoden er, at det tager tid og det er
relativt få personer, man drager konklusioner ud fra.
Appreciative
Inquiry
Appreciative
Inquiry (AI), som betyder værdsættende udforskning, er en teori og
metode til udvikling af organisationer, afdelinger eller dele heraf. Borgere i
en AI proces tager afsæt i og lærer af det, der fungerer. Dette
giver værdifuld viden og energi til at udvikle videre og lægge
strategier og handlinger for de nye udfordringer. Både sagsbehandleren og
borgeren kunne for eksempelvis med fordel deltage sammen i processen. Ulempen
ved metoden er, at det tager tid og det er relativt få personer, man
drager konklusioner ud fra.
Observationer
Ved at studere
allerede eksisterende adfærd kan der udledes en række konklusioner
om adfærden blandt brugerne. Dette kan ske bl.a. ved at se på
hjemmeside statistik, opgøre hvorfor borgere møder op på
kommunen, studere sagsgangen for de ansatte osv.
På denne måde vil det blive muligt at udlede, hvordan det vil
være mest hensigtsmæssigt at tilbyde offentlig borgerservice og
derved kunne tilrette sagsgennemgangen herefter. Metoden kan være
være tidskrævende. Til gengæld vil man i langt højere grad
end ved de øvrige typer af undersøgelser kunne udrede brugernes
reale behov, og ikke bare det udtalte behov.
Tænke-højt
test
En simpel og billig
måde at foretage en test af f.eks. brugervenligheden af en hjemmeside
på, er at tage et lille antal borgere ind til en
”tænke-højt-test”.
En
”tænke-højt-test” går ud på, at
sætte testpersonen foran skærmen og lade personen tale om de ting,
personen oplever ved brug en hjemmesiden.
Der kan vælges enten at lade personen selv se sig om på
hjemmesiden, eller man kan vælge at stille en række opgaver og
så se på og lytte til, hvordan testpersonen løser opgaverne.
På denne måde vil en række uhensigtsmæssigheder kunne
afdækkes.
Metoden er en meget simpel og billig metode. Metoden er ikke oplagt at benytte
i alle situationer, og metoden vil ikke kunne fange alle fejl og mangler, men
der er stor sandsynlighed for, at de største uhensigtsmæssigheder
vil kunne afdækkes.
Kvantitative metoder
Spørgeskema/
kvantitative analyser:
En større gruppe mennesker spørges om et emne samtidig. De
får alle de samme spørgsmål, som derved nemt kan
efterbehandles.
Metoden sikrer at et bredt udsnit af målgruppen får mulighed for at
kommentere på emnet. En sådan undersøgelse kan foretages
relativt hurtigt. Ulemperne er, at det koster en del, og det er ikke muligt at
udbygge spørgsmålene, hvis man får nogle interessante eller
mærkelige besvarelser. Desuden er der større sandsynlighed for, at
spørgsmålene forstås forskelligt.
Undersøgelser
At se på
erfaringer fra andre steder er en hurtig og simpel metode til at få
beskrevet borgernes/brugernes ønsker eller behov. Det kræver, at
der er andre der har udført sådanne undersøgelser, samt at
de til en hvis grad er nogen, man kan sammenligne sig selv med.
Fase 4: Afslutning og evaluerings- og effektopfølgningsfasen
Et af kendetegnene ved et projekt er, at det er tidsbegrænset – det har en begyndelse og en slutning. Formålet med denne fase er at afslutte og evaluere projektet – men samtidig også sikre at de langsigtede effekter måles. Afslutning og evaluering retter sig mod projektets resultater, herunder en evaluering af business casens projektleverancemilepæle for projektet. Da evalueringsaktiviteterne samtidig skal bidrage til, at projektets erfaringer bruges i andre sammenhænge, skal projektets resultater mere generelt afrapporteres og formidles. Afslutning og evaluering retter sig samtidig også mod selve projektgruppen og aktiviteterne her, hvor der følges op på processer, aktiviteter og målopnåelse.
Formål
Sikring af, at formål eller mål beskrevet i projektinitieringsdokumentet er blevet opnået. I denne projektfase er det formålet at afslutte projektet og anvende erfaringerne og de opnåede resultater i projektet.
Resultatmål
· Det sikres, at formålet som beskrevet i projektinitieringsdokumentet (PID) er blevet opnået
· Det sikres, at business casens projektleverancemilepæle er blevet opnået
· Det sikres, at alle forventede produkter er blevet afleveret og godkendt af kunden/bestiller
· Det sikres, at alle godkendelseskriterierne er blevet opfyldet og der er indhentet bekræftelse af dette
· Det sikres, at erfaringer gjort i forbindelse med projektet opsamles og dokumenteres
· Det sikres, at projektet økonomisk, regnskabsmæssigt og personaleadministrativt er afsluttet
· Det sikres, at business casens kapitel 3 ”Implementeringsstrategi” bliver opdateret med fokus på, hvem der er ansvarlig for, at de langsigtede forretningsmæssige milepæle - og tilknyttede Key Performance Indicators (KPI’er) - nås
· Det sikres, at driftsopgaver er placeret
· Der sikres en sikker og ordentlig arkivering af projektets dokumenter
· Der produceres en afslutningsrapport
Fremgangsmåde
Evalueringen af projektet tager udgangspunkt i projektinitieringsdokumentet
Hvad skal evalueres? - resultat og proces
· Et projekts resultater skal altid evalueres. Det centrale spørgsmål er, om vi har opnået de ønskede resultater og business casens projektleverancemilepæle ift. de forventninger og opstillede mål, der var ved projekts igangsættelse.
· Evalueringen af hvorfor projektet har nået (eller ikke nået!) resultaterne sker derimod i en evaluering af processen, herunder såvel ydre som indre omstændigheder i projektet.
Hvad skal der evalueres og til hvem?
· Overvej hvem der skal inddrages. Det kan være projektejer, styregruppe, projektleder, projektgruppen og projektets interessenter
· Overvej hvem evalueringen skal formidles til
Evalueringsmetoder
Metoderne ift. resultat- og procesevaluering kan f.eks. være at:
· Gennemføre en spørgeskemaundersøgelse hos projektets interessenter
· Afholde interviews/ fokusinterviews med interessenter
· Beskrive projektets historik - tilblivelsen og projektfaserne, herunder identificere afgørende begivenheder i projektperioden
· Bruge gule lapper til at identificere læringspunkter i projektet - f.eks. hvad skulle vi have gjort mere af? Hvad skulle vi have gjort mindre af?
· Bruge gule lapper til at reflektere over personlig læring - f.eks. gennem succeshistorier
Input til evaluering af projektet
· Projektinitieringsdokument
· Evaluering af business casens projektleverancemilepæle
Hent redskaber på modernisering.dk/projektmodel
· Business case vejledning kapitel 3
Eksempler på modernisering.dk/projektmodel
· Se eksempel på opstilling og fremgangsmåde for en konkret opfølgning på langsigtede forretningsmål i business case eksemplet
Dokumenter og redskaber til Fase 4: Afslutning, evaluering og effektopfølgning
Opdatering og evaluering af projektets business case
Foruden en opgørelse af såvel de økonomiske gevinstmuligheder som de egentlige/ direkte projektomkostninger, bygger udarbejdelsen af en business case på det hovedprincip, at der foretages en analyse af, om de gevinster, der blev beregnet i den oprindelige business case, er blevet realiseret.
Formål
Formålet med at lave en evaluering af business casen er at skabe et overblik over, om de forventede gevinster er indhøstet og dermed et grundlag for at kunne afslutte projektet. Evalueringen skal således bidrage til at sikre, at alle gevinster er realiseret og samtidig forklare, hvis noget ikke er endt som forudset. Evalueringen skal desuden producere information til at kunne fortælle om projektets resultater. Evalueringen skal kobles med en opdatering af business casens forretningsmilepæle med fokus på, hvorvidt tidspunktet for målingen(erne) af KPI’er for forretningsmilepælene er hensigtsmæssige. Dette er også for at sikre, at ansvaret for effektmålingen er placeret hos den relevante part.
Resultatmål
· Der er foretaget en undersøgelse af gevinsterne, som er formuleret i business casen
· Det er sikret, at der følges op på de langsigtede forretningsmilepæle
Laves der ikke en opfølgning, er der ingen sikkerhed for, at de langsigtede økonomiske såvel som de kvalitative gevinster bliver høstet. Der er heller ikke overblik over, i hvor høj grad projektet ud fra en økonomisk synsvinkel har været et rentabelt projekt på kort eller på lang sigt. Det er således vigtigt, at der i løbet af projektet arbejdes aktivt med forudsætningerne for business casen.
Fremgangsmåde
Med afsæt i business casens kapitel 3 foretages der en undersøgelse af, hvorvidt projektleverancemilepælene er opnået. Med afsæt i samme del af business casen gennemgås forretningsmilepælene med fokus på tidspunkt for måling af de opstillede KPI’er og med fokus på, hvem der har ansvar for at foretage effektmålingen.
Baggrund
Det er ledelsens ansvar at gå forrest og sikre, at projektet bliver ført helt igennem mht. business casen og de generelle mål for projektet. Ledelsen skal derfor stå fast på, at projektet først er afsluttet, når der er foretaget en evaluering, der som minimum indeholder en analyse af, om de helt overordnede projektleverancemål er nået og om de opstillede effekter er nået på kort sigt, og at det er sikret, at der følges op på om investeringens langsigtede effektmål nås. Det kan fx betyde, at der foretages en undersøgelse af, om de estimater, der blev gjort for tidsbesparelser i f.eks. sagsgennemgangen, kom til at holde stik. Hvis estimaterne har vist sig ikke at holde stik, så skal der analyseres på, om det er fordi, projektet ikke er fuldt funktionelt, eller det er fordi, man ved udarbejdelsen af business casen havde været for optimistisk.
Ledelsen skal bevare fokus på projektet, indtil projektet er lukket ned. Fjernes fokus inden nedlukningen, viser al erfaring, at en del af rationaliseringsgevinsterne vil gå tabt. Det er ledelsens ansvar at sikre, at projektet bliver lukket ordentligt ned. Til nedlukningen hører, at de enkelte projektmedarbejdere tilbageføres helt til deres oprindelige opgaver, at projektets resultater synliggøres overfor resten af organisationen og ikke mindst, at der tages stilling til, hvornår de langsigtede effektmål fra business casen måles, og hvem der er ansvarlig for at foretage målingen.
Hent redskaber
på modernisering.dk/projektmodel
· Den generelle business case model
· Business case vejledningen
Bilag til projektmodellen: Flere redskaber
Kick-off seminar: Indførelse af projektmodel
At indføre projektledelse og styring efter nogle særlige principper og redskaber kræver nye kompetencer, som projektledere og deltagere skal lære at bruge i praksis. Det tager tid at få en fælles forståelse af, hvad f. eks en risikoanalyse er, hvordan den kan hjælpe med at styre et projekt og hvordan den skal udarbejdes. Den fælles forståelse og accept kommer ikke af at læse en pdf-udgave af projektmodellen, den kommer af fælles dialog om indholdet af projektmodellen samt ved at arbejde med redskaberne og metoderne i praksis.
I samarbejde
med Kriminalforsorgen afholdte Taskforcen et 1-dags seminar. Der var to
mål med dagen. Dels at kickstarte processen med indførelse af
projektmodellen i Kriminalforsorgen, dels at udarbejde et inspirationsprogram
for implementering af projektmodellen blandt offentlige myndigheder.
Nedenfor er implementeringsprogrammet for, hvordan man kan komme i gang med at
arbejde med projektmodellen, vist.
Formål
Der tages udgangspunkt i en gruppe medarbejdere, bestående af projektledere og projektdeltagere samt evt. styregruppemedlemmer, der skal indføre en projektmodel i deres daglige arbejde.
Formålet
er:
Hel eller delvis indførelse af Taskforcens projektmodel. Målet er,
at gruppen bliver mere effektiv gennem anvendelse af fælles sprog,
terminologi, ensartet metode, samt målrettet styring af tid og
omkostninger.
Resultatmål
Resultatmål for seminaret er:
· At deltagerne på sigt samme får et fælles sprog og referenceramme internt i gruppen.
· At projekterne får ensartet dokumentation omkring grundlag, organisering, risikostyring, business case, kvalitetssikring mv.
·
At deltagerne på
sigt får et fælles overblik over de ledelsesbeslutninger, der
typisk ligger ved faseovergangene.
At deltagerne efterfølgende vil bruge projektmodellens redskaber og
metoder i det aftalte omfang
Fremgangmåde
Datofastlæggelse:
Ledelsen for udviklingsafdelingen, projektenheden, ledelsen for IT-enheden
eller lign. fastlægger i god tid en dato for afholdelse af et kick-off
seminar.
Formøde:
På et formøde til kick-off seminariet diskuterer ledelsen for
udviklingsafdelingen mv. hovedlinierne for indførelsen af
projektmodellen. Det er vigtigt at få afklaret:
· Hvorfor ønskes der en fælles tilgang til projektledelse?
· Hvad fungerer nu, og hvad skal der ændres på, hvad nyt skal læres?
· Hvordan ønsker vi at styre digitaliseringsprojekter efter seminariet
· Hvilke kompetencer skal læres og hvordan?
· Hvad er ambitionen med kick-off seminaret?
· Har vi topledelsens opbakning til at indføre og arbejde efter principperne i en projektmodel?
· Hvor meget selvstudie forventes deltagerne på seminaret at skulle foretage inden afholdelsen?
Invitation:
Sørg for at alle relevante medarbejdere inviteres med –
også de, der først senere vil være deltagere i et projekt.
Omvendt må der kun deltage medarbejdere, der skal arbejde med en
projektmodel. Formålet med at tage alle med er, at alle potentiale
deltagere kommer til at kende projektmodellens terminologi, metoder og
redskaber. En fælles indlæring og forståelse af værdien
af projektmodellen skal bidrage til at skabe et fælles grundlag og
engagement.
Afholdelse
Udgangspunktet for kick-off seminaret er et 1-dages seminar. Det kan anbefales
at deltagerne læser pdf-udgaven af projektmodellen. På seminariet
gennemgås den nødvendige teori og gruppen bliver kastet ud i at
løse opgaver i plenum og i mindre grupper.
Huskeliste:
· Det skal synliggøres, at det er ledelsens ønske, at der skal arbejdes efter en projektmodel.
· Det er en god ide er at inddele deltagerne i grupper, som i forvejen arbejder sammen om et projekt. Benyt projekter til øvelserne, som deltagerne allerede arbejder med – det øger relevansen og dermed engagementet fra deltagerne
·
Sørg for, at det
er klart for deltagerne:
- Hvad, der er målet med seminaret
- Hvad, der kan ændres
- Hvad, der allerede er fastlagt.
· Deltagerne skal på forhånd vide, at de i fremtiden kommer til at arbejde efter projektmodellen
· Husk at afsætte god til implementeringen af modellen. Det tager tid at få skabt en fælles forståelse af hvad f. eks en risikoanalyse er, og hvordan den udarbejdes. Modellen har også mange delelementer. Det kan derfor virke uoverskueligt, hvis hele modellen introduceres på samme dag.
Forslag til emner på seminariet:
· Hvorfor fokus på styring af digitaliseringsprojekter?
· Hvorfor implementeres en fælles tilgang til projektledelse?
· Hvad kan projektmodellen?
· Hvordan er modellen opbygget?
· Hvad forstår vi ved risikoanalyse, interessentanalyse, business casen mv.?
· Hvordan bruges redskaberne?
· Hvilke redskaber er relevante for os?
· Hvordan ønsker vi at styre projekter efter seminariet?
· Hvad fungerer nu, og hvad skal der ændres på? Hvad nyt skal læres?
· Hvad er vores kompetencebehov for at benytte en projektmodel?
Forslag til seminarets form
Skab et afvekslende program, hvor der benyttes:
· Oplæg
· Plenumdebatter
· Øvelser i grupperum
· Øvelser i plenum
· Forskellige former for fremlæggelse af øvelsesresultater
Hent eksempler på modernisering.dk/projektmodel
· Se tidsplan og dagsorden for kick-off seminaret i Kriminalforsorgen
· Se øvelser til seminarets workshop
· Se Taskforcens slides til brug ved seminaret
Ledelse af digitaliseringsprojekter i den offentlige sektor: gode råd når modellen skal implementeres
Det er velkendt, at succesfuld implementering af forandringsprojekter ikke blot kræver god projektstyring, men også betydelig ledelsesopmærksomhed.
Men hvad kendetegner god ledelse af digitaliseringsprojekter, og hvilke forhold skal ledelsen være opmærksom på? Med det formål at udbrede erfaringer fra frontløbere inden for digital forvaltning, har en arbejdsgruppe bestående af Finansministeriet, Personalestyrelsen, VTU, KL, Danske Regioner og Den Digitale Taskforce fået udarbejdet en rapport om emnet.
Rapporten er udarbejdet af rådgivningsfirmaet Managers’ Hotline A/S og baserer sig på en omfattende undersøgelse af, hvordan ni institutioner, der har markeret sig inden for digital forvaltning, blandt myndigheder og forvaltninger i stat, amter og kommuner leder de digitale udviklingsindsatser. Over 100 ledere på mange niveauer af disse institutioner har deltaget i undersøgelsen.
Hvad anbefaler rapporten?
Undersøgelsen identificerer tre forhold, som i særlig grad er udtryk for god digital ledelse. Disse forhold, er dem, der blandt de deltagende institutioner tillægges størst betydning blandt de i alt 10 anbefalinger og 5 advarsler, som undersøgelsen afdækker:
Topledelsen skal formidle en klar vision for digitaliseringen Topledelsen skal gøre visionen tydelig for alle internt som eksternt gennem en vedholdende formidling i mange forskellige sammenhænge. Vedholdenhed, argumentationen og indsigt i forholdene giver topledelsens formidling af visionen gennemslagskraft og troværdighed.
Digitaliseringsprojekter skal være forretningsmæssigt velbegrundede Forretningsmæssigt velbegrundet digitalisering betyder i offentlig sammenhæng, at det tilfører reelle og efterspurgte fremskridt, dvs. en mere effektiv ressourceudnyttelse og en mere kvalificeret opgaveløsning.
Den daglige ledelse skal holde fokus og retning på digitaliseringsprojekterne
De daglige ledere har et vigtigt ansvar for den praktiske gennemførelse og skal sikre, at de løsninger, der gennemføres, medfører klare fremskridt. Samtidigt skal ledere for støttefunktioner sørge for, at specialisternes bidrag sker tæt på den daglige drift og i overensstemmelse med dens behov.
Digital ledelse
Digital ledelse bidrager med én blandt en lang række synsvinkler på den samlede ledelsesopgave – synsvinkler der trænger sig på i takt med, at der identificeres områder af ledelse og organisation, der er underbelyst i digitaliseringssammenhænge. Digital ledelse betragtes i rapporten som den ledelsesform, hvor ledelsen:
· skaber nye måder at løse opgaver på gennem anvendelse af informationsteknologi
· bruger it til at opbygge nye samarbejds- og kommunikationsformer internt og eksternt
· gennemfører nødvendige organisatoriske forandringer, der er drevet af teknologiudviklingen
· styrer implementering af systemer, metoder og opgaver effektivt og opmærksomt
· bidrager til udviklingen af enkeltpersoner og kollegiale miljøer, som kan styrke grobunden for den fortsatte digitalisering af det offentliges service til borgere og virksomheder.
It-arkitektur og teknologi - nogle generelle betragtninger
De overvejelser, der specifikt knytter an til arbejdet i de enkelte faser, vil være beskrevet under den relevante fase.
Formål
Projektets it-arkitektur skal tage udgangspunkt i det løbende arkitekturarbejde, der er indeholdt i organisationens visioner og strategi. Formålet med at lave en god it-arkitektur er at stille it-teknologisk udstyr til rådighed, der understøtter de administrative forretningsgange på en så hensigtsmæssig måde som muligt. It-arkitekturen skal i videst muligt omfang konstrueres således, at den nemt kan kommunikere med andre offentlige systemer.
Resultatmål
· Der skal dokumenteres væsentlige arkitekturmæssige beslutninger i et samlet dokument – herunder hvorledes de overordnede arkitekturprincipper udmøntes i forhold til den givne løsning.
· Der foreligger en beskrivelse af de administrative arbejdsgange, som it-arkitekturen skal understøtte
· Der foreligger en beskrivelse af den fremtidige informationsarkitektur
· Der skal laves et løsningsdesign, der er på tilstrækkeligt logisk niveau, til at opgaven kan udbydes
Fremgangsmåde
Grundkonceptet for godt it-arkitektur arbejde er, at det er principstyret. Det betyder, at først analyseres forretningskravene, og på baggrund heraf opstilles et sæt konceptuelle arkitekturprincipper, som benyttes ved organiseringen og de tekniske valg. Arkitekturarbejdet skal sikre sammenhængen mellem kravene og principperne, således at forretningskravene vil være opfyldt af en løsning, der efterlever principperne, og de gældende principper altid er begrundet med forretningsmæssige krav. Arkitekturprincipperne opstilles i et hierarki med flere niveauer. Det øverste niveau omfatter fælles, overordnede principper, som blandt andet afspejler behovet for sammenhæng på tværs af den offentlige sektor. Det næste niveau omfatter principper, som typisk har til formål at optimere it-løsningerne inden for en enkelt sektor eller et indsatsområde. På det laveste niveau finder vi principper, som er rettet mod et konkret system eller en portefølje af systemer i en enkelt organisation.
Hent mere information
· Om it-arkitektur se oio.dk/arkitektur
· Om den fællesoffentlige integrationsmodel se modernisering.dk/integrationsmodel
· Om den fællesoffentlige referencemodel (FORM) se modernisering.dk/form