Fælles beslutningsmodel – tidligere kaldet governance for projekter.

Præsentationer af emnet: "Fælles beslutningsmodel – tidligere kaldet governance for projekter."— Præsentationens transcript:

1 fælles beslutningsmodel - for projekter der kan involvere AU IT Vedtaget af LEA
Fælles beslutningsmodel – tidligere kaldet governance for projekter. Det er vigtigt at pointere, at den fælles beslutningsmodel kun relaterer til projekter, der kan involvere AU IT.

2 Målet Den fælles beslutningsmodel er sat i værk for at:
Gøre det rigtige Gøre det rigtigt Skabe større synlighed og transparens 1) Prioritering af knappe ressourcer – brug de begrænsede ressourcer på de rigtige ting 2) Gennemfør det vi har besluttet os for at prioritere effektivt, så vi når de fastsatte mål og følger op på, at det sker Styrke planlægningen i projekterne mhp. endnu større succesrate i levering indenfor aftalt tid og kvalitet. 3) Skabe større synlighed og transparens i projektporteføljen og prioriteringen af dem. Ved at arbejde mere med struktur og fælles processer vil det give noget tilbage igen.

3 Hvad? Overblik Prioritering Gennemførelse
Bemærk: Der er en ny tegning på vej fra grafikeren. Den fælles beslutningsmodel handler om: 1) hvordan man får overblik over alle ønskerne til AU IT. - Alle de gode ideer/ønsker skal indsamles og eksistensregistreres. Det gør AU IT. De henvendelser der skal løses som projekter skal identificeres og der skal skabes overblik over dem. Overblikket skal gøre os i stand til bedre at planlægge vores projekter 2) hvordan man får prioriteret imellem dem. Henvendelserne skal bearbejdes/modnes, således at der kan udarbejdes et oplæg til hvilke, der skal prioriteres. LEA tager stilling til prioriteringsoplægget og sikrer, at beslutningen er afstemt med universitetsledelsen. 3) hvordan man samarbejder om at løse projekterne. Organisationen samarbejder på tværs om at løse projektet. Det er alt sammen noget som skal gøres i fællesskab.

4 Hvorfor? Bemærk – Der er en ny tegning på vej fra grafikeren.
Ikke nødvendigt at kende i detaljen, men illustration af kompleksiteten. Sliden illustrerer begrundelsen for, at der er behov for en fælles beslutningsmodel. AU IT modtager hvert år talrige ønsker til projekter fra hele universitetet; langt flere ønsker, end AU IT har mulighed for at indfri. De kommer fra alle dele af universitetet. Der er brug for en helhedsbetragtning. Beslutningsmodellen giver mulighed for mere synlighed omkring hvorfor det nogle gange er svært at ”komme igennem med noget”. Beslutningsmodellen giver også mere transparens i hvilke projekter der er prioriteret og hvorfor. Ønskerne kan: udspringe af ledelsesbeslutninger f.eks. på fakulteterne eller i universitetsledelsen. komme fra allerede igangværende projekter, f.eks. hvis projektet ser en god bussiness case i at udvide projektet eller igangsætte et delprojekt. komme fra den daglige systemforvaltning, hvor f.eks. lovkrav kan spille ind. komme via direkte henvendelse fra en medarbejder eller studerende på AU til en person i AU IT eller IT-supporten. Uanset hvor henvendelsen kommer fra, opsamles den i AU IT og registreres, så der prioriteres på tværs af helheden. Det som med fordel kan løses i forvaltningsorganisationen, kanaliseres derhen og fjernes fra projektporteføljen. Det som gennem dialog viser sig ikke at skulle løses alligevel, eksempelvis fordi der allerede findes en løsning et andet sted i organisationen, lukkes som afvist/løses ikke alligevel.

5 Hvordan? Beslutningsmodellen består af følgende 6 beskrivelser:
Fra ide til prioriteret projekt for henvendelser der kan involvere AU IT Porteføljeindgange i AU IT Forventninger til systemanvendelsen Prioritering af projekter med IT - Årshjul Beslutningsprincipper Beslutningskompetence i rollerne omkring projekt og porteføljestyring Hvordan får man så overblik, prioritering og fælles fodslag i samarbejdet? Det skal de 6 beskrivelser samt en fælles projektmodel med tilhørende værktøjskasse og skabeloner hjælpe til. De to første beskrivelser er gennemgået. De 4 næste kan man klikke på enkeltvis, eller sige noget om overordnet hver især, og dermed springe detaljen over. Projektmodellen beskrives på næste slide.

6 Hvordan? Den fælles beslutnings- model inkluderer desuden en fælles projektmodel. Samt en værktøjskasse med fælles skabeloner og tjeklister. Den fælles projektmodel er en AU IT projektmodel, der beskriver minimumsleverancer og giver gode råd til opmærksomhedspunkter i fasen. Modellen SKAL benyttes på prioriterede projekter, der har en projektleder. Modellen MÅ bruges af alle. Værktøjskassen består af fælles skabeloner, der SKAL benyttes samt en tjekliste, der SKAL tages i anvendelse. Tjeklisten er under udarbejdelse og mangler indhold for i gang-fasen. Den vedligeholdes og udbygges af AU IT. Hvis man klikker på billedet af projektmodellen, kommer man til den detaljerede beskrivelse af leverancerne. Denne kan springes over, hvis man i stedet henviser til beslutningsmodellens hjemmeside. Man kan få hjælp til at komme i gang.

7 Hvem? Fælles beslutningsmodel Fælles IT projektmodel
Modellen gælder for alle projekter, der kan involvere AU IT - også før et projekt får brug for AU IT’s ressourcer. Fælles IT projektmodel Modellen skal benyttes for alle prioriterede projekter, der har en projektleder, uanset projektlederens organisatoriske tilhørsforhold. Det er vigtigt, at man indsender henvendelser til AU IT så tidligt som muligt. Jo mere komplet overblikket over ønskerne er, desto bedre beslutningsgrundlag vil LEA have når der prioriteres for den kommende periode. Det vil bidrage til færre omprioriteringer undervejs. Model, værktøjer og skabeloner må gerne bruges af alle, men der er ikke et krav, når der ikke er en projektleder, eller hvis projektet ikke er blandt de prioriterede projekter. IT-projektmodel betyder at det er når projekterne involverer AU IT

8 Hvilke projekter i Praksis?
ALLE skal: ændringshåndtering statusrapportering Oversigten viser de prioriterede projekter, der har en projektleder, og som derfor skal følge den fælles projektmodel. Nogle projekter er dog så langt i et forløb, at det ikke vil være hensigtsmæssigt at ændre projektet til at benytte den fælles projektmodel. Disse projekter vil ikke mærke nogle ændringer i forhold til, hvorledes de arbejder i dag. Nogle projekter kan med fordel køre en tilpasset model. For disse projekter vil det sammen med projektlederen aftales, hvordan og hvilke elementer, det giver mening at inddrage. De resterende projekter skal som udgangspunkt benytte fuld ny projektmodel. Det vil blive diskuteret og aftalt med hver enkelt projektleder, hvad det så betyder for projektet. Den røde pil henleder opmærksomheden på, at ALLE nye projekter skal benytte den fælles projektmodel. Uanset hvor lidt/meget projekt-modellen i øvrigt følges, SKAL ALLE projekter aflevere statusrapportering d. 5 i hver måned OG skal indsende ændringsanmodninger – Uddybes næste slide.

9 Hvad betyder det for projekterne?
Projekterne SKAL: følge den fælles projektmodel. Projektinitieringsdokumentet (PID) er projektets ramme og SKAL udarbejdes. Minimumsleverancerne SKAL gennemføres. Porteføljeudvalget i AU IT (PFU) kan godkende afvigelser. PFU skal se alle PID med henblik på metodemæssig godkendelse. PFU skal godkende arkitekturleverancer i projektet. arbejde med ændringshåndtering i hele projektets livscyklus. Hvis det ikke er beskrevet i de godkendte projektrammer, er det en ændring. have en styregruppe. AU IT ledergruppen skal være repræsenteret i styregruppen. udpege én overordnet ansvarlig projektleder i de projekter, der har mere end en. statusrapportere månedligt til PFU Projekterne SKAL benytte den fælles skabelon og SKAL aflevere den 5 i hver måned. tildeles ressourcer fra alle deltagende organisatoriske enheder, således at projektet kan gennemføres inden for de godkendte projektrammer. Kun hvis der er en projektleder, (uanset projektlederens organisatoriske tilhørsforhold. OG det er et prioriteret projekt. 2) Større projektudvidelser besluttet i styregruppen er ikke automatisk prioriteret. Alle ændringer, som påvirker projektrammen eller arkitekturen, SKAL indstilles til PFU med henblik på godkendelse i forhold til porteføljen. PFU godkender ikke forretningsbeslutninger, men de projekt og porteføljemæssige konsekvenser af dem. PFU vurderer om ændringen skal eskaleres særskilt til LEA, eller indgå i næste prioriteringsrunde. 3) Prioriterede projekter, der har en projektleder skal også have en styregruppe. For nogle projekter, kan PFU i AU IT være styregruppe. 4) Nogle projekter kan have en projektleder hos leverandøren, hos den enhed, der ejer projektet, hos AU IT og hos de enheder der modtager projektets produkter. Det er derfor vigtigt at sikre at der er én som har det overordnede ansvar og beslutningskompetence. Den interne arbejdsdeling mellem projektlederne aftales fra projekt til projekt. 5) Den månedlige statusrapportering til PFU kan i nogle tilfælde falde sammen med andre statusrapporteringer i projektet. Det ændrer ikke på hverken dato eller skabelon for den, der afleveres til PFU. I praksis sendes statusrapporten til Nanna Garner i porteføljeenheden. 6) Tildeling af ressourcer skal ske i prioriteringsrækkefølge. Tildeling kan betyde, at interne projekter i de enkelte enheder må vige pladsen for prioriterede projekter, som er igangsat af andre enheder.

10 Vi tager den fælles beslutningsmodel i brug NU!
Hvornår? Vi tager den fælles beslutningsmodel i brug NU!

11 Hjælp og spørgsmål? Besøg medarbejdere.au.dk/beslutningsmodel for mere information. Alle projektledere bliver kontaktet med henblik på en gennemgang af projektmodellen og en snak om, hvordan den kan bruges sammen med deres projekt. Der gennemføres styregruppekursus i efteråret 2016 for: LEA LEA udpeger funktionschefer og andre relevante deltagere funktionscheferne udpeger projektledere Har du spørgsmål, kan du kontakte Nanna Garner fra Porteføljeenheden i AU IT Det vil kun være de projektledere, der skal arbejde efter fuld eller tilpasset projektmodel, der bliver kontaktet. Hvis de gerne vil i gang hurtigere end de kontaktes, er de velkomne til at tage fat i Nanna Garner fra Porteføljeenheden i AU IT.

12 Bilag Find de dokumenter, der er en del af den fælles beslutningsmodel, men som ikke er præsenteret. Dokumenterne kan gennemgås enkeltvis via link på slide 4 og 5 eller efterfølgende, når præsentationen er gennemgået. Hvis man klikker på bilaget sendes man tilbage til slide 4/5 i præsentationen.

13 Forventninger til systemanvendelsen
Efterår: Struktureret indsamling af ønsker og forventninger både for systemforvaltning og projekter. prioriterer ressourcefordeling mellem projekter og systemforvaltning. lister hvilke projekter, der prioriteres. lister hvilken prioriteringsrækkefølge projekterne skal have. Forår: Fokus på ændringer og nye ønsker. Revideret oplæg til prioritering for Q3 og Q4 samme år. Skal IKKE læses, men vise kompleksiteten. Ud over alle de ønsker der kommer ind, når de gode ideer opstår, er der også en mere struktureret indsamling af behovene for systemforvaltning. Indsamlingen sker gennem systemejerforum samt Administrationschefer og it-supportchefer. Indsamlingen foretages to gange om året – efterår for næste kalenderår og forår/sommer for ændringer til Q3 og Q4 samme år. Formålet med den strukturerede indsamling er: Dels at få fat i projektønskerne så tidligt som muligt. Dels at få fastlagt niveauet for systemforvaltning for det kommende kalenderår. Dels at sikre muligheden for genovervejelser, omprioriteringer, ændringer halvvejs i kalenderåret. Denne ”runde 2” er ikke så omfattende og ressourcekrævende som den første, hvor der kigges 1 år frem. På baggrund af indmeldingerne og bilaterale møder udarbejder PFU et oplæg til LEA. Næste slide viser kalenderdimensionen af disse indsamlinger.

14 Årshjul Årshjulet kombinerer den strukturerede indsamling af ønsker med den operationelle dagligdag, hvor der løbende kommer ønsker og ændringer ind. Den grønne ”database” er den samme var tegnet på ”Porteføljeindgangen” hvor alle henvendelser eksistensregistreres og løbende holdes opdaterede. I september starter indsamlingen af forventninger til systemanvendelsen I januar godkender LEA en samlet prioriteringsramme for systemforvaltning og projekter. December og januar ”fastfryses” for ændringer til denne ramme. I maj starter indsamlingen af ændringer til porteføljen eller prioriteringsønskerne. I august godkender LEA en ny prioriteringsramme for Q3 og Q4. Juni-august ”fastfryses” for ændringer til denne ramme. I perioderne mellem prioriteringsrunden, behandler PFU (Porteføljeudvalget i AU IT) de henvendelser og ændringsanmodninger der kommer ind. Nogle ændringer og henvendelser kan løses i forvaltningsorganisationen og skal tages ud af projektporteføljen. Nogle henvendelser vil gennem dialog vise sig ikke at skulle løses alligevel, eksempelvis fordi der allerede findes en løsning et andet sted i organisationen. Disse lukkes som afvist/løses ikke alligevel. Nogle henvendelser har brug for at blive ”modnet”/bearbejdet mere i detaljen, før der kan tages stilling til hvor meget der kræves for at løse dem, og om de kan løses gennem forvaltning eller skal ind som projekt. 5) Hvis ændringen /henvendelsen medfører en større ændring af porteføljen, og den ikke kan afvente næste prioriteringsrunde, vil PFU eskalere til LEA for godkendelse. – Det er PFU som vurderer hvornår LEA inddrages. På denne måde administrerer og synliggør PFU konsekvenserne af ændringsønskerne og henvendelserne på porteføljen.

15 Prioriteringsprincipper for projekter
Projektprioritering sker af den samlede portefølje prioriteringsprincipper for projekter: - Ressourcetilgængelighed - Effekt. - Konsekvens ved ikke at gennemføre projektet. - Projektafhængighed i projektleverancer. Der planlægges med en BUFFER Hvordan foretages udvælgelsen af projekterne så? Det er vigtigt at bemærke, at der prioriteres ud fra en samlet portefølje på tværs af universitetet. Det betyder, at de forskellige ledelsesfora, governanceorganer m.v. kan godkende at en indstilling er relevant og fornuftig at gennemføre, men ikke HVORNÅR den prioriteres. Projektprioritering sker ud fra fire grundlæggende prioriteringsprincipper som skal sikre, at projekterne gennemføres i en fornuftig rækkefølge Prioriteringerne fastlægges ud fra et princip om ikke at allokere alle ressourcer 12 måneder frem, men sikre en buffer, som giver et råderum i løbet af prioriteringsperioden. Når LEA har besluttet prioriteringsrammen for forvaltning og projekter, samt prioriteret mellem projekterne, sker tildelingen af ressourcer i AU IT ud fra princippet på tegningen: Der allokeres til systemforvaltning. Dels specifikke leverancer som er aftalt, dels til en minimumsdrift af systemet. Dernæst tildeles projekterne ressourcer i den rækkefølge de er prioriteret. Hvis der efterfølgende er ledig kapacitet benyttes den til forvaltning og uprioriterede projekter.

16 Beslutningskompetence i rollerne i forbindelse med porteføljestyring
Overblik, prioritering og samarbejde omkring projekterne hviler på den beskrivelse af beslutningskompetence som er gengivet ovenfor. Det kan være en god ide at give 5 min til at læse og reflektere over indholdet. Det er vigtigt at fremhæve: Det er LEA der beslutter prioriteringerne. PFU har påtaget sig en sekretariatsbetjening af LEA i forbindelse med porteføljestyringen. PFU har en metodemæssig styringsfunktion. Styregrupperne skal sikre at ændringer som berører projektrammen eller arkitekturen, godkendes af PFU. Projektlederen skal sige til, hvis projektet bevæger sig ud over rammerne (beskrevet i PID) og udarbejde en ændringsanmodning til styregruppen.

17 Bilag: Projektmodellen I
Projektmodellen består af to slides og nogle bilag. Denne slide viser en visualisering af faserne og hvordan man kan bevæge sig imellem dem. Der er minimum 4 gates, men projekterne kan lægge så mange beslutningspunkter ind undervejs, der er behov for. Viser også de obligatoriske dokumenter, der har en fælles skabelon – PID, statusrapport, ændringsanmodning, systemforvaltningsaftale, kort projektbeskrivelse Effektrealiseringen ligger udenfor projektet, men grundlaget skabes i projektet. Man kan få hjælp fra AU IT når man skal i gang med at bruge modellen.

18 Projektmodellen er en forholdsvis fleksibel model, hvor man kan tilrettelægge faserne så de passer bedst muligt på projektet. Eksempelvis kan man i i gang-fasen vælge en vandfaldsmodel eller en scrum-model. Man kan definere de underfaser og beslutningspunkter der er behov for, eksemplificeret med de ”gule firkanter”. Samme princip gælder foranalysen. Det som ligger fast er de overordnede gates. Et eksempel kunne være at kontrakten med leverandøren som ikke underskrives før projektets fortsatte eksistens er godkendt af styregruppen i en gate2 hvor revideret businesscase foreligger.

19 Projektmodellen Projektmodellen består af to slides.
Minimumsleverancer Projektmodellen består af to slides. - Denne slide beskriver for hver fase hvad formålet er, hvilke leverancer der skal gennemføres samt kommer med nogle opmærksomhedspunkter, der kan være gode at overveje i forbindelse med ledelsen af projektet. - Leverancerne skal betragtes som MINIMUMSLEVERANCER for fasen. Hvis der er nogle af de generelle leverancer beskrevet på oversigten, projektet ikke planlægger at gennemføre i den beskrevne fase, skal PFU godkende fravalget/flytningen af leverancen. Man kan få hjælp fra AU IT når man skal i gang med at bruge modellen.

20 Eksempel på det værktøj, der hedder tjeklister til projektlederen.
Stort excel-ark med faneblad for hver fase, hver gate, og særlig vigtige områder, som her ”TEST”. Hver af de 3 grønne linjer kan foldes ud. Der er i alt 109 linjer i testtjeklisten. Skal hjælpe til at man kommer godt omkring i planlægningen. Opdateres løbende, når verden forandrer sig eller vi bliver klogere.

21