PID - Projekt Initierings Dokument

Projektnavn:	Forklaringer og eksempler til de enkelte afsnit i skabelonen til projektinitieringsdokument

Projektejer:

Projektleder:

Version:	5.3	Versionering skal opdateres løbende. Start med ver 0.x inden fremlæggelse i styregruppen

Dato:	02-01-2023

Del af program:	JA/NEJ [Skriv programnavn]

Udbud	JA/NEJ

Dokumenthistorik: Slet arbejdshistorikken når 1.0 publiceres

Version	Dat0	Ændret af	Ændring (hvad er ændret)	Godkendt af
5.2	28-04-22	Nanna Garner	Rettelser efter input fra PL i AU IT indhentet på workshop 22-02-22
5.3	02-01-2024	Nanna Garner	Skabelon til ledelsessammenfatningen tilføjet i starten af dokumentet.

Indholdsfortegnelse:

1	Ledelsessammenfatning	4

2	Projektet	4

2.1	Baggrund	4

2.2	Vision	4

2.3	Arkitektur	4

2.4	Formål	4

2.5	Mål	5

2.6	Afgrænsning af projektet	5

3	Leverancer	5

3.1	Projektets hovedleverancer	6

3.2	Projektets leverancer	6

3.3	Metodeafvigelser	7

4	Effekter og gevinster	7

5	Tidsplan	7

5.1	Forventet start- og slutdato	7

5.2	Implementeringsstrategi	7

5.3	Milepæle	7

6	Afhængigheder	8

6.1.1	Grænseflader til andre projekter	8

6.1.2	Andre afhængigheder	8

7	Organisering	8

7.1	Roller og ansvar	9

8	Omkostningsbudget og personaleressourcer	10

8.1	Omkostningsbudget	10

8.2	Projektfinansiering	10

8.3	Ressource estimater	10

9	Business case	11

9.1	Investeringsvurdering	11

10	Interessenter	11

10.1	Interessentanalyse	11

10.2	Brugerinddragelse	11

10.3	Intern kommunikationsplan	12

11	Risici	13

12	Andet	13

12.1	Ændringshåndtering	13

12.2	Problemhåndtering	14

12.3	Beslutningslog	14

12.4	Projektdokumentation	15

13	Bilag	15

Brug evt. Tjekliste til projektlederen, faneblad Rammer, som hjælp ved udfyldelse af PID.

Ledelsessammenfatning

Vision:
Formål:
Mål:
Faser/Milepæle
Hovedleverancer:
Risici:

Er inputtet til projektets elevatortale. Denne del skal alle styregruppemedlemmer kunne udenad

Projektet

Lav evt. en ordliste her med forkortelser som anvendes i dokumentet.

Baggrund

Udfyldes i samarbejde med projektejer.

Beskriv den nuværende tilstand og eventuelt hvorfor den ser ud som den gør?

Hvilke problemer opleves i dag? Det store brede billede.

Vision

Hvorhen på lang sigt: Den tilstand vi ønsker at befinde os i engang i fremtiden.

Er indenfor synsvidde men udenfor rækkevidde. Dv.s det er ikke det her projekt som opfylder visionen, men det yder et bidrag til den og understøtter den.

Ikke alle projekter har en vision som pejlemærke. Nogle projekter arbejder udelukkende ud fra deres konkrete formål.

Arkitektur

Projektet udarbejder en arkitekturstrategi som beskriver hvilke arkitekturleverancer, der er relevante for dette projekt. Arkitekturstrategien godkendes af projektchefen og PL sikrer at den reviewes i arkitektregi.

Hvis projektet kun har ganske få leverancer kan de beskrives i denne PID. Ellers bør det ligge i bilaget ”Arkitekturstrategi” der findes som obligatorisk skabelon.

Formål

Få hjælp ved projektejer og styregruppe til at udfylde dette punkt.

Hvad er projektet sat i verden for at producere?

Formuler det kort og præcist.

Konkret eksempel fra testprojektet:

Projektets formål er, at implementere løsninger, som adresserer:

Skalering af testmiljøer (ny infrastruktur) til efterlevelse af leverandørkontrakter og AU-projekter, der forudsætter brug af flere integrerede testmiljøer.

Sikring af, at det kommende 773-SIS projekts krav til testinfrastruktur er etableret og klar.

Implementering af tiltag, som øger testmodenheden og den organisatoriske forankring i AU.

Mål

Involver projektejer og styregruppe i tilblivelsen af dette punkt.

Hvorhen på den korte bane?

Det vi helt konkret gerne vil nå i dette projekt.

Hvilke mål skal vi stille op for projektet? Hvilken tilstand ønsker vi at befinde os i når projektet er afsluttet? Eksempler:

Antallet af supportsager vedrørende brugergrænsefladen er faldet med 75 procent

Alle medarbejdere….

De studerende på … kan…

Konkret eksempel fra testprojektet:

Målene for dette projekt er:

AU har et dedikeret TMO, der bistår i testrådgiving, allokering af relevante testmiljøer, inklusiv nye data.

Alle AU-projekter benytter de obligatoriske testartefakter, der vedligeholdes og styres af TMO.

Alle AU-projekter følger TMO’s anvisninger og retningslinjer for bestilling af testmiljøer og -data.

TMO har den nødvendige viden til at skabe synergi og løfte kvaliteten af testarbejdet.

Booking-funktionen til bestilling af miljøer, benyttes af alle AU-projekter og forvaltninger.

AU kan stille relevante testmiljøer til rådighed for leverandører.

Alle krav til 773-SIS projektets testinfrastruktur er etableret.

Afgrænsning af projektet

Hvad omfatter projektet ikke.

Leverancer

Prince 2 beskriver produkter som værende det der fastlægger projektets omfang.

Der er dels slutprodukter som er det projektet er sat i verden for at skabe og dels produkter, som er alt det som skal til for at skabe slutprodukterne og styre projektet.

I PID beskrives det som hovedleverancer og leverancer.

Det er vigtigt at både hovedleverancer og leverancer beskrives på et niveau, der kan danne grundlag for forventningsafstemning om projektets omfang.

Projektets hovedleverancer

Hovedleverancerne definerer projektets overordnede omfang. Svarer til Prince2´s slutprodukter.

Hovedleverancerne danner grundlag for planlægning og styring af projektet.

Dette afsnit kan slås sammen med det efterfølgende for at visualisere hovedleverancernes sammenhæng med leverancerne. Det skal dog fremgå tydeligt hvad hovedleverancerne er da disse er genstand for ændringsstyring i PFU.

Projektets leverancer

Der er to typer af leverancer i projektet:

Minimumsleverancer – Alt det som skal til uanset projektets art, men som kan tilpasses i forhold til det enkelte projekt. Disse fremgår af projektmodellen og skal ikke beskrives her medmindre det bidrager særligt til forventningsafstemningen.

Projektspecifikke leverancer - De væsentligste produkter projektet skal indeholde for at kunne levere hovedleverancerne. Prince 2 kalder dem specialistprodukter eller output. Altså noget som leveres ud af projektet undervejs.

Projektleverancerne vil være genstand for ændringsstyring i forhold til styregruppen, men ikke nødvendigvis i forhold til PFU.

Leverancerne kan beskrives i et af nedenstående skemaer, som punktopstilling eller på anden vis.

Leverance	Beskrivelse
Leverance 1
Leverance 2

Alternativt (grå linier er hovedleverancer, hvide linier er delleverancer, farverne kan fjernes eller bruges)

ID	Leverance	For- analyse	FG3	EG3
1	Teknisk implementering af Office 365
Tildeling af rettigheder ved udrulning af Office 365	x
Beskrive hvad eksterne og studerende tilbydes i forhold til samarbejde med ansatte	x	x
2	Flytning af Exchange
Integrationer	x	x

Metodeafvigelser

Hvilke af projektmodellens minimumsleverancer gennemføres IKKE og hvorfor?

Er der planlagt andre afvigelser fra projektmodellen, eksempelvis i forhold til håndtering af gates, flytning af minimumsleverancer til andre faser eller andet?

Det er ok at beskrive hvad man laver af minimumsleverancer i stedet for at skrive hvad man IKKE laver.

Effekter og gevinster

Udfyldes i gevinstkortet og lægges i bilag.

Gengiv gevinsterne fra gevinstkortet her, således at de bliver retningsanvisende og en ramme for projektets styring.

Udarbejdes der en businesscase for projektet kan dette afsnit udelades.

Tidsplan

Forventet start- og slutdato

Angiv forventet start- og slutdato for projektet.

Den dynamiske projektplan og milepælsplan lægges i bilag. Datoer vedligeholdes i bilag.

Implementeringsstrategi

Er der gjort overvejelser om Pilotimplementering, big bang, trinsvis udruldning eller andet, som kan have indflydelse på projektets forløb og tidsplan?

For nogle projekter vil implementeringsstrategi afhænge af tekniske muligheder og samarbejde med leverandør, som først fastlægges senere i projektet.

Milepæle

Milepæle er noget væsentligt projektet skal have opnået. Noget som kan fortælle hvorvidt projektet har fremdrift og kommer i mål til tiden.

Milepæle kan både være tidspunkter/tilstande hvor der skal råbes Hurra når de nåes, og tidspunkter/tilstande hvor der skal råbes Hjælp, hvis de ikke nås til fastsat tid.

Projektets kritiske vej skal være repræsenteret ved 1 eller flere milepæle.

I PID beskrives de væsentligste milepæle for projektet. Kan der ikke sættes dato på endnu, vil det ske i den efterfølgende planlægning.

Milepælsdefinition: Består af en eller flere leverancer, og beskriver en tilstand på et givet tidspunkt. Tilstanden opnås typisk med en betingelse, f.eks. en godkendelse, beslutning eller kvalitetskriterie.

Viser afhængigheder til:

Andre projekter
årshjul
travle perioder som milepælen skal ligge inden
kontraktforhold, der skal opfyldes
gates
Beslutninger udenfor projektorganiseringen eksempelvis UNILED, LEA
…

Nedenfor beskrives milepælene i projektet. Disse vil projektet løbende rapportere på.

Milepælsplan	Dato/uge/måned

Afhængigheder

Grænseflader til andre projekter

Er der afhængigheder til andre projekter, leverancer eller interessenter?

Andre afhængigheder

Er der forudsætninger, personer, beslutninger eller leverancer udefra som projektet er afhængig af?

Eksempler kan være:

Årshjul
Frozen Zones
Servicevinduer
Tekniske afhængigheder f.eks opgraderinger
Regnskabsår, kalenderår eller studieår i forbindelse med datamigrering
…

Skaber projektet ændringer, der kan resultere i at andre projekter, eksisterende processer, systemer eller strukturer skal ændre noget?

Afhænger skal typisk være afspejlet i kommunikationsplanen, interesentanalysen, milepælene og/eller risikologgen.

Organisering

Her beskrives den overordnede projektorganisering. Hvem deltager i projektet og hvilket ansvar har de?

Beskriv strukturen. Tegn gerne diagram. Sørg for at det er projektets organisering der beskrives og ikke oversigt over hvor projektdeltagerne er ansat.

Den detaljerede projektorganisation lægges i bilag.

Projektorganisationen skal tage udgangspunkt i interessenterne.

Projektorganisationen skal kunne dække de beskrevne leverancer.

Overvej:

Styregruppe

Projektejer.

Projektdeltagere.

Tovholdere.

Referencegrupper.

Ad hoc deltagere.

Arkitektur, it-sikkerhed, UX, support, drift, dokumentation, udvikling, change management.

Beslutninger der skal træffes i projektets levetid.

Andre.

Angiv om muligt, hvem, der er nøglepersoner.

Sørg for at styregruppen ikke er for stor, og at den er beslutningsdygtig.

Roller og ansvar

Rolle	Ansvar
Styregruppe Tilføj navne	Skal sikre at projektet har et klart defineret formål og mål og et veldefineret omfang Er ”værd at gennemføre” har en realistisk tidsplan samt de fornødne ressourcer problemer løses rettidigt projektet har de rigtige rammer til, at projektlederen kan opnå den rigtige fremdrift i projektets beslutninger.
Projektejer Tilføj navn	Fagligt ansvar for at projektet leverer det ønskede produkt. Budgetansvar.
Projektleder Tilføj navn	Styring af leverancer og proces. Leverandørstyring Testmanagement
Forretnings Projektleder Tilføj Navn	Ansvarlig for implementeringen og forandringsledelsen i organisationen.
Arkitekt Tilføj navn	Finop Azure

Tilføj roller i det omfang der er behov for det.

Omkostningsbudget og personaleressourcer

Omkostningsbudget

Hvor mange penge må projektet bruge i kr og ører. IKKE i årsværk.

Beskriv de estimerede omkostninger for projektet. Omkostningsbudgettet er kroner der på forhånd er tildelt projektet og som skal posteres på et budget undervejs i projektet. Disse skal projektlederen eller projektejeren kunne redegøre for overfor styregruppen.

Detaljeret omkostningsbudget til opfølgning lægges i bilag.

Projektfinansiering

HVEM betaler for projektet og den efterfølgende systemforvaltning?

Projektfinansiering indeholder BÅDE omkostninger i projektets levetid OG systemforvaltning på det niveau, der aftales i den første version af systemforvaltningsaftalen.

Alle direkte omkostninger i projektet skal være finansierede, både de som allerede er kendte og de som måtte dukke op undervejs. Det bør også være aftalt, hvorledes de konteres.

Derudover skal der være en aftale om finansiering af systemforvaltning efter projektets afslutning med angivelse af hvornår eventuelle omkostninger overgår til forvaltningen.

Projektefinansiering beskrives i bilag og vedligeholdes løbende, således at omkostninger, der kommer til undervejs, altid er finansierede, INDEN de afholdes.

For hardware og udstyr der overstiger beløbsgrænsen for aktiver (Spørg i AU IT sekretariatet for den aktuelle beløbsramme) skal afskrivningen finansieres. (Typisk over 3 år, men spørg.)Det skal være aftalt om det er projektet, der bærer afskrivningerne, eller alternativt hvilken afdeling/team der skal have dem. Afskrivninger som fortsætter efter projektets levetid skal altid konteres hos en afdeling/team.

Ressource estimater

Beskriv projektets estimat for personaleressourcer opdelt på hovedområder og VD områder.

Medtag også estimat for ressourcer til at modtage projektets leverancer i modtagerorganisationen.

Detaljerede estimater opdelt på måneder og leverancer lægges i bilag efter foranalysen.

Hvis der er forskel på de estimater projektet kommer frem til i løbet af PID-udarbejdelsen, og de estimater der var gældende i den korte projektbeskrivelse, skal der udarbejdes en ændringsanmodning til porteføljestyringen.

Business case

Beskriv OM projektet vil arbejde med business casen. For nogle projekter er der behov for detaljerede analyser, for andre projekter er oversigten over effekter/gevinster sammenholdt med omkostningerne tiltrækkeligt.

Selve businesscasen kan med fordel ligge i bilag, da den vil være dynamisk i projektets levetid.

Brug eventuelt Business-case skabelonen på projektmodellens hjemmeside.

Investeringsvurdering

Opsummer de første hovedkonklusioner om projektets business case. Kan det betale sig og hvad er risikoen for at det senere viser sig at det kan det ikke?

Interessenter

Interessentanalysen er grundlaget for indefra-ud tænkningen, brugerinddragelsen, projektorganiseringen, kommunikationsplanen og forandringsledelsen i projektet. Alle projekter bør derfor gennemføre en interessentanalyse.

Interessentanalyse

Hvem bliver påvirket af projektet eller projektets hovedleverancer?

Interessentanalysen kan med fordel lægges i bilag, hvor adgangen til den også kan gøres fortrolig og hvor bilaget kan blive ”et levende dokument” som vil blive opdateret og ajourført undervejs i projektets levetid.

Brug evt. interessent –skabelonen på projektmodellens hjemmeside.

Brugerinddragelse

Hvilke forandringer vil projektet medføre hos de der berøres af projektets leverancer?

Hvad skal projektet være opmærksom på for at kunne understøtte forandringerne?

Hvilke leverancer skal projektet medtage for at understøtte den forandringsproces, der skal til? Eksempelvis uddannelse eller informationsmøder.

Hvilken strategi for brugerinddragelse vil projektet benytte? Hvordan vil projektet involvere brugerne i forbindelse med f.eks. kravspecifikation, test og uddannelse?

Er brugerinvolvering tænkt ind i f.eks. projektorganisationen, teststrategien eller implementeringsstrategien?

Intern kommunikationsplan

Beskriv kommunikationsplanen internt i projektet, d.v.s i forhold til styregruppe, projektdeltagere, referencergrupper m.v.

Medtag rapporteringskrav som særskilte kommunikationsprodukter.

Kommunikationsplan - intern
Produkt (hvad)	Målgruppe (hvem)	Mediet (hvordan)	Hvornår	Ansvarlig
Projektstatus	Projektgruppen	Statusmøder, Daily stand up, kopi af statusrapporten Mailinfo	Mail efter hvert styregruppemøde Efter statusrapportering	Projektleder
Statusrapportering	Projektejer, Styregruppen, PFU, Særlige interessenter, referencegruppen	Worddokument som journaliseres	Hver d. 5 i måneden	Projektleder
Styregruppemøder	Styregruppen	Dagsorden i wordskabelon
Info om projektet	Scrumteamet	Projektleder eller scum master?
Styregruppereferater	Styregruppen	Wordskabelon. Journaliseres	senest 3 hverdage efter mødet	Projektleder

Statusrapporteringen skal være kommunikeret til projektejer inden fremsendelse til PFU. Ved røde statusmarkeringer skal styregruppeformanden være orienteret af projektejer senest dagen før fremsendelse.

Risici

Afsnittet skal beskrive risici forbundet med projektets successfulde gennemførelse. IT-sikkerheds risikovurdering samt produktrisikoanalysen er begge leverancer i løbet af projektet, som beskræftiger sig med systemets risici. De beskrives ikke i PIDén.

Beskriv projektets 3-5 væsentligste risici i PIDén og udarbejd et bilag der efterfølgende vedligeholdes dynamisk i projektets forløb.

En risiko er en hændelse der måske, måske ikke indtræffer og som i givet fald vil have (negativ) indflydelse på projektets mål og effekter eller rammerne for projektets gennemførelse (som fx tid og økonomi).

En hændelse man ved, vil indtræffe er ikke en risiko, men en udfordring, som skal håndteres og løses i projektet.

Vurder om der er nogle af ricisiene som kan medføre betydelige omkostninger hvis de indtræffer.

Beskriv mitigering af risiciene, d.v.s imødegåelse af både sandsynlighed og konsekvens så man mindsker risikoen for at det sker og man forsøger at mindske konsekvensen hvis det sker alligevel.

Beskriv også mitigeringen selvom det allerede er indarbejdet i projektet, eksempelvis gennem organisering eller specifikke leverancer.

Brug evt. risikoskabelonen på projektmodellens hjemmeside.

Andet

Ændringshåndtering

Beskriv hvorledes projektet vil håndtere ændringer i projektets rammer. Hvilke ændringer kan projektlederen beslutte, hvilke skal i styregruppen, og hvilke skal i andre fora. Hvad skal informeres omkring ændringer til hvem, og hvad er kommandovejen?

Ændringer der påvirker projektets rammer skal godkendes af PFU, hvis det handler om arkitektur, scope, eller tidsplan.

Overvej specifikt hvordan ændringsprocessen skal være i tilfælde af at det er den økonomiske ramme som er under pres, hvis der er brug for at projektdeltagerne tager merarbejde/overarbejde/arbejde udenfor normal arbejdstid, hvis der bliver brug for eskalering udenom linjeledelseshierarkier, hvis der er udfordringer i forhold til ressourcer hos et enkelt styregruppemedlem m.m.

Forslag til tekst, der kan modificeres til det aktuelle projekt:

Projektleder kan, i samråd med projektdeltagerne, identificere og beslutte tekniske og designmæssige ændringer, som ikke har indflydelse på de leverancer, der skal leveres ud af projektet.

Projektleder kan selv identificere og beslutte ændringer til tidsplanen, der ikke har indflydelse på milepælene eller slutdatoen.

Projektejer skal involveres som beslutningstager for ændringer, der har indflydelse på de leverancer, der leveres ud af projektet f.eks. i form af indhold, økonomi eller tid. Projektejer skal også involveres i forhold til ændringer til de milepæle, der er rapporteret til styregruppen.

Hvis projektejer ikke har beslutningskompetence til at afklare en ændringshenvendelse, skal styregruppen involveres for afklaring. Styregruppen skal altid involveres i forhold til politiske konsekvenser.

Styregruppen skal orienteres om alle ændringer, der har indflydelse på de rapporterede milepæle, samt de leverancer der leveres ud af projektet.

Hvis styregruppen ikke har beslutningskompetance eskaleres til LEA.

Problemhåndtering

Beskriv hvorledes projektet håndterer opdukkende problemer. Hvordan logges de, hvem informeres, hvem skal inddrages i hvilken type af problemer? Hvad er rapporteringskravet og til hvem?

Eksempeltekst:

Projektleder er ansvarlig for at sikre håndtering af problemer, der opstår i projektet.

Eskaleringsvejen er typisk: Projektleder->Projektejer->Styregruppe->Styregruppeformand

Ved ressourceeproblemer eskaleres til det styregruppemedlem, som repræsenterer det område, hvor ressourceproblemet er. Eskalationen sker gennem projektejer.

Ved problemer omkring projektøkonomi eskaleres til styregruppen.

Alle problemer, der fremlægges til styregruppen skal være beskrevet i et beslutningsoplæg med minimum 2 alternativer. Skabelonen til sagsfremstillinger benyttes.

Sørg for at følgende spm er besvaret i ovenstående beskrivelse:

Hvis projektet ikke kan overholde deadline eller budget, vil …….

Hvis der er ønske om, at scope reduceres eller udvides, skal følgende involveres, før styregruppen træffer beslutning……

Hvis styregruppen skal træffe beslutninger vedrørende at overholde tidsplan, overskride budget eller reducere scope, skal der udarbejdes følgende beslutningsgrundlag……

Hvis det viser sig, at gevinster ikke kan blive så store som estimeret, ………

Hvis det ikke er muligt at nå til enighed i styregruppen, …….

Beslutningslog

Hvordan håndteres beslutninger i projektet? Hvilke beslutninger kan projeklederen træffe, hvilke skal i styregruppen eller andre fora, hvad kan projektejer og/eller systemejer beslutte?

Hvor registreres projektets beslutninger og hvem kan se beslutningsloggen? Er der forskel på beslutninger der træffes af styregruppen, projektejer og projektgruppen i forhold til logning og synlighed?

Eksempeltekst:

Projektlederen vedligeholder en beslutningslog, som ligger i projektets Confluence space. Styregruppen kan få en udskrift på styregruppemøder, eller på anfordring.

Styregruppen kan få adgang til Confluence, hvis det ønskes.

Projektdokumentation

Hvor ligger projektdokumentation og de dokumenter der udarbejdes i projektets levetid? Hvem har adgang til dokumenterne? Er der særlig fortrolighed omkring styregruppemateriale og hvordan håndteres denne fortrolighed?

Har projektet en hjemmeside på beslutningsmodellens hjemmeside og hvordan vedligeholdes den? Er der nogen som skal godkende det som lægges på hjemmesiden?

Når projektet er afsluttes, hvem har så ansvaret for at arkivere relevant projektdokumentation i Workzone og nedlukke projektarkivet og eventuel hjemmeside?

Eksempeltekst, der kan tilpasses efter behov:

Projektet dokumenteres på Confluence: Indsæt link.

Alle brugere af Confluence har adgang til at læse. Projektejer har ansvar for at vurdere hvilken dokumentation, der potentielt kan være behov for fortrolighed om, og i disse tilfælde bede om at adgangen begrænses. Projektet har ingen hjemmeside i TYPO3.

Det er projektlederens ansvar at sikre lukning af projektets Confluence space og JIRA projekt ved projektafslutning samt at relevant projektdokumentation er blevet journaliseret.

Bilag

Slet eller tilføj bilag, således at bilagslisten viser bilagene til det konkrete projekt

Projektplan

Milepælsplan med datoer

Interessentanalyse

Omkostningsbudget og personaleressourcer

Organisationsdiagram

Ekstern kommunikationsplan

Risikovurdering

Business case

Arkitekturstrategi