FRA IDÉ TIL PRIORITERET PROJEKT FOR HENVENDELSER DER KAN INVOLVERE AU IT

Transkript

1 FRA IDÉ TIL PRIORITERET PROJEKT FOR HENVENDELSER DER KAN INVOLVERE AU IT

2 AU IT PORTEFØLJEINDGANG FOR PROJEKTER

3 Proces for dialog om forventninger til systemanvendelsen Godkendt Systemejere Porteføljeenheden i AU IT AU IT teams PFU LEA Skabelon Skabelon udsendes Indsamling af behov fra fakulteterne Forventninger til systemanvendelsen næste kalenderår Forventninger til næste kalenderår indsendes Arrangerer bilaterale møder med systemejere og vicedirektører Arrangerer bilaterale møder med administrationschefer og it supportchefer Scoring af projekterne Udarbejdelse af projektliste opdelt i SKAL, VIL og ØNSKER Scoring pr projekt Sammenfatning af scoringer og kommentarer Overblik over projektscoringer Forår Efterår Dialog på systemejerforum om systemforvaltning og LEAs projektliste Orientering om prioritering via linjeledelsen Mail Koordinering af behov med fakulteterne Ændringer til forventninger indsendes Sikrer estimering på systemforvaltning og projekter Oplæg til systemforvaltning Send oplæg til systemejerforum og administrations chefer Mail vedrørende ændringer til systemforventninger udsendes Ændringer i forventninger til systemanvendelsen Q3 og Q4 Overordnet projektprioritering Sammenfatning og bearbejdning Tilretning af beslutningsoplæg Sammenfatning og bearbejdning Estimering og kompetencer Estimeringer pr system og projekt Ressourceallokering projekt og systemforvaltning Ressourceallokering projekt og systemforvaltning Overblik og beslutningsoplæg for projekt og systemforvaltning Prioriteringer og ressourcekonflikter i forhold til midler Tilrettet overblik og beslutningsoplæg Godkendt aftale om prioriteringer og ressourcefordeling ml. projekter og systemforvaltning Overblik og beslutningsoplæg Prioriteringer og ressourcekonflikter i forhold til midler Godkendt aftale om prioriteringer og ressourcefordeling ml. projekter og systemforvaltning Beslutning om hvilke projekter, der skal på prioriteringslisten Oplæg til prioritering næste kalenderår Godkendelse af prioritering og porteføljeplan Afstem med UNILED Oplæg til prioritering Q3 og Q4 Godkendelse af prioritering og porteføljeplan Orientering om prioritering via linjeledelsen Orientering om prioritering i UNILED

4 Prioritering af projekter med AU IT involvering Årshjul Godkendt SEP OKT NOV DEC JAN FEB MAR APR MAJ JUN JUL AUG Forventninger til systemanvendelsen næste kalenderår Bilaterale møder mellem VD områderne og AU IT samt Administrations centrene og AU IT Overordnet projektprioritering LEA Beslutte prioriteringslisten Scoring pr projekt Oplæg til prioritering næste kalenderår LEA Godkendelse af prioritering LEA Afstem prioritering med UNILED Enhedsadministrationen Input til næste budgetår vedrørende projekter Ændringer i forventninger til systemanvendelsen Q3 og Q4 Bilaterale dialog med AU IT Oplæg til prioritering Q3 og Q4 LEA Godkendelse af prioritering LEA Afstem prioritering med UNILED Projektlisten til systemejerforum Aftale om projektmidler for næste budgetår AU ITs projektportefølje LEA Godkendelse af større ændringer for resterende kalenderår LEA Godkendelse af større ændringer for indeværende kalenderår PFU ændringer PFU ændringer PFU ændringer PFU ændringer PFU ændringer PFU ændringer PFU ændringer Løbende porteføljestyring i AU IT Afvis/Løses i forvaltningsorganisationen Løbende porteføljestyring i AU IT Afvis/Løses i forvaltningsorganisationen

5 Styringsprincipper For projekter der involverer AU IT Opdateret

6 Projektrammer Prioriterede projekter, der besættes med en eller flere projektledere* (uanset organisatorisk tilhørsforhold), skal: 1) Følge den fælles projektmodel. 2) Arbejde med ændringshåndtering i hele projektets livscyklus. Er det ikke beskrevet i de godkendte projektrammer, er det en ændring. 3) Have en styregruppe. AU IT chefgruppen skal være repræsenteret i styregruppen. Styregruppen kan være PFU i AU IT eksempelvis for infrastrukturkritiske projekter eller projekter med begrænset udbredelse. 4) Udpege én overordnet ansvarlig projektleder i de projekter, der har mere end en. 5) Rapportere månedligt til PFU i fælles statusrapportskabelon. 6) Tildeles ressourcer fra alle deltagende organisatoriske enheder, således at projektet kan gennemføres indenfor de godkendte projektrammer. Kan medføre at interne projekter i de enkelte områder må vige pladsen for prioriterede projekter igangsat af andre områder. Nogle projekter har ikke projektleder og er dermed ikke underlagt projektrammerne. Nogle projekter har flere projektledere, eksempelvis en i AU IT og en i projektejerens organisation og en hos en ekstern leverandør. Opdateret

7 Princip for ressourceallokering Rækkefølge for tildeling af ressourcer i AU IT Systemforvaltning Aftalte leverancer og minimumsdrift Prioriterede projekter i prioriteringsrækkefølge Rækkefølge for tildeling af ressourcer Systemforvaltning backlog Uprioriterede projekter Buffer Projekter Forvaltning Opdateret Udmøntning af ressourceallokeringen

8 Prioriteringsprincipper for projekter Projektprioritering sker af den samlede portefølje. Godkendelse af enkeltstående indstillinger i LEA, UNILED eller andre governanceorganer er IKKE ensbetydende med at projektet prioriteres. Projekterne opdeles i 3 kategorier: SKAL, VIL, ØNSKER. Projektprioritering foretages kun for SKAL og VIL projekter, mens ØNSKER -projekter gennemføres hvis AU IT har mulighed for det gennem uprioriterede projekter. Overordnet projektprioritering i LEA sker ud fra en scoringsmodel baseret på 5 ligestillede parametre: Kobling til strategi eller udviklingsmål Effektiviseringspotentiale Projektets parathed Efterspørgsel fra brugerorganisationen Konsekvens ved ikke at gennemføre projektet Overordnet projektprioritering i LEA sker uden hensyn til Ressourcetilgængelighed, leveranceafhængigheder og deadlines. Detailprioritering udarbejdes af PFU ud fra den overordnede prioritering med tilføjelse af betragtninger omkring: Ressourcetilgængelighed kompetencer og nøgleressourcer. Projektafhængighed i leverancer. Deadlines Detailprioriteringerne fastlægges ud fra et princip om ikke at allokere alle ressourcer 12 måneder frem, men sikre en buffer/udisponeret tid, som giver et råderum i løbet af prioriteringsperioden. Opdateret

9 Beslutningskompetence Få en oversigt over beslutningskompetence i rollerne i forbindelse med projekter. 1. LEA (ledelseskredsen i Enhedsadministrationen) Beslutter den endelige ressourcefordeling mellem projekter og systemforvaltning i AU IT på baggrund af oplæg fra PFU (Porteføljeudvalget). Beslutter prioriterede projekter og den indbyrdes prioritering imellem dem på baggrund af oplæg fra PFU. Beslutter prioritering i forbindelse med større ændringer i projektporteføljen. Eskalerer til Universitetsledelsen. 2. PFU - Porteføljeudvalget Definerer hvornår en henvendelse er et projekt henholdsvis forvaltning. Godkender fravalg af projektmodel-leverancer i faserne. Kan afvise målarkitektur og løsningsdesign. Beslutter ressourceallokering af AU IT ressourcer til projekterne, herunder tildeling af projektleder. Beslutter oplæg til prioritering i LEA ud fra prioriteringsprincipperne. Prioriterer løbende henvendelser, indstillinger, igangværende projekter og projektpipeline inden for den af LEA godkendte ressourcefordeling. Eskalerer til LEA ved større ændringer til projektporteføljen. Agerer på projekters sundhedstilstand og hjælper nødlidende projekter eventuelt via ledelsesstrengen. 3. Projektets styregruppe Godkender projektets rammer i form af PID (projektinitieringsdokument). Beslutter projektindhold inden for projektets rammer. Indstiller til PFU om fortsat prioritering ved større ændringer eller udvidelser i projektomfang. Godkender faseovergange og projektafslutning. Godkender leverancer og står ind for det faglige behov. Ejer effektmålene, forandringsledelsen og budgettet. Eskalerer til LEA via ledelsesstrengen ved uenighed med PFU om prioriteringer. 4. Projektleder Afgør hvorvidt leverancer og ændringer kan realiseres inden for projektets rammer. Definerer projektets sundhedstilstand til PFU via statusrapportering.

10 Definerer hvilke projektmodel-leverancer, der skal medtages i projektets gennemførelse. Fravalg godkendes af PFU. Eskalerer til styregruppen og/eller PFU ved ændringer eller udvidelser, som har indflydelse på AU IT's leverancer.

11 Godkendt Scoringsmodel for projektprioritering Brugen af en scoringsmodel i forbindelse med prioritering af projekter giver en konsistent, kvantificerbar metode, der kan skabe synlighed og overblik over hvilke projekter, der prioriteres og hvorfor. Scoringsmodellen indgår i beslutningsmodellen for projekter, der involverer AU IT og benyttes 1 gang årligt i forbindelse med prioriteringen af projekter for kommende kalenderår. Det er den enkelte projektejer, der sikrer kategorisering og scoring af projekterne. Til hver kategorisering og hver scoring skal knyttes en kommentar om hvorfor netop den værdi er valgt. Det er LEA, der træffer beslutning om prioriteringsrækkefølge af projekterne med udgangspunkt i scoringerne. LEA skal på møde udfordre den kategorisering og scoring projektejerne har meldt ind, ud fra et helhedshensyn og overblik. LEA skal på mødet udarbejde en konkret liste over projekter, der skal arbejdes videre med i prioriteringsrunden. Listen skal være i prioriteret rækkefølge. Det er AU IT, der på baggrund af LEAs prioriteringsrækkefølge, fremlægger oplæg til kalendermæssig prioritering og rækkefølge ud fra ressourcetilgængelighed, afhængigheder mellem projektleverancer og eventuelle deadlines. Det er LEA der træffer den endelige beslutning om prioriteringen af projekter ud fra AU ITs oplæg. Scoringsmodellens principper: 1) Projekterne opdeles i 3 kategorier: SKAL VIL ØNSKER 2) Projekterne i SKAL og VIL scores ud fra 5 parametre: Kobling til strategi eller udviklingsmål Effektiviseringspotentiale Projektets parathed Efterspørgsel fra brugerorganisationen Konsekvens ved ikke at gennemføre projektet 3) Hver parameter scores i forhold til en skala fra 0-5 4) Alle 5 parametre tæller ligeligt i opgørelsen af projektets samlede score

12 Godkendt Definitioner: Begreb Beskrivelse SKAL-projekter Projekter, der ikke kan afvises begrundet i: Lovgivning Myndighedskrav Sikker drift Politiske hensyn VIL-projekter Need-to-have. Projekter, der er stærke argumenter for at gennemføre ØNSKER projekter Nice-To-have. Projekter, det ville være godt at få gennemført på et tidspunkt, når der er ressourcer til det. Parametre: Nedenstående beskrivelser skal ses som en guide til scoring af projekterne. Det er IKKE en facitliste, og der VIL være gråzoner. Parameter Kobling til strategi og ledelsesprioriteringer Effektiviseringspotentiale Beskrivelse Strategi skal læses som AUs strategi og tilhørende delstrategier, herunder målene i udviklingskontrakten. Ledelsesprioriteringer forudsættes underbygget af strategi, således at en beslutning i UNILED, LEA, fakultetsledelse m.v. vil kunne scores på nedenstående parametre. 0. Ingen kobling mellem projektet og AUs strategi og underliggende delstrategier 1. Understøtter strategiens forudsætninger 2. Understøtter indirekte et eller flere strategimål eller udviklingsmål 3. Understøtter direkte et enkelt strategimål eller udviklingsmål 4. Bidrager målbart til opfyldelsen af et enkelt strategimål eller udviklingsmål 5. Bidrager målbart til opfyldelsen af flere strategimål eller udviklingsmål Der scores i forhold til konkret effektiviseringspotentiale. Dvs. der scores i forhold til, hvor stort det realiserbare effektiviseringspotentiale er. 0. Projektet skaber ikke målbare effektiviseringer, der kan høstes i forbindelse med gevinstrealisering. 1. Der skabes gevinster, som ikke kan måles på en måde der muliggør at konkrete effektiviseringspotentialer kan høstes, eksempelvis større oplevet kvalitet. 2. Der skabes effektiviseringer, som danner grundlag for andre effekter, eksempelvis mulighed for fremadrettet at ensarte processer. 3. Der skabes målbare effektiviseringer, der frigiver ressourcer til serviceforbedringer på andre områder, eksempelvis hurtigere løsning af brugerhenvendelser. 4. Der kan gennemføres direkte besparelser i budgettet.

13 Godkendt Projektets parathed Efterspørgsel fra brugerorganisationen Konsekvens ved ikke at gennemføre projektet 5. Der kan gennemføres anseelige direkte besparelser i budgettet. Beskriver hvor klart projektet er til at starte op. Findes der en projektbeskrivelse, en PID, et råt ressourceestimat, en overordnet arkitekturbeskrivelse etc. Er modtagerorganisationen parat til at afsætte de nødvendige ressourcer og er finansieringen under og efter projektet på plads? 0. Projektet er kun beskrevet i en overskrift. 1. Der findes en kort projektbeskrivelse. 2. Der findes en kort projektbeskrivelse og en grov vurdering af ressourcebehovet. 3. Der findes en kort projektbeskrivelse med leverancer, grov vurdering af ressourcebehov og økonomi i træskolængder. 4. Der er udarbejdet en arkitekturbeskrivelse og en PID, som belyser finansiering i projektet såvel som i den efterfølgende forvaltningsorganisation. 5. Projektet er velbeskrevet, finansieringen på plads, organisationen klar til at indgå i projektet og forvaltningsrollerne bemandet. Hvor stor en brugerorganisation er det, som efterspørger leverancerne? 0. Brugerorganisationen har ikke efterspurgt leverancerne. I værste fald, kan der være modstand mod forandringen. 1. Projektet efterspørges alene af projektejer/systemejer/processejer. 2. Projektet efterspørges af et eller flere ledelsesorganer. 3. Lille efterspørgsel fra VIP og/eller studerende. 4. Projektet efterspørges af mange, men vil kun give en mindre oplevet forbedring for brugergruppen. 5. Stor efterspørgsel fra VIP og/eller studerende med stor oplevet forbedring for brugergruppen. Hvis projektet ikke prioriteres i den kommende periode, eller hvis det helt lukkes ned, hvilke negative konsekvenser, vil det så kunne få for AU? 0. Der er ikke direkte konsekvenser ved ikke at gennemføre ændringen. Status quo bibeholdes. 1. Mindre ekstraomkostninger, eksempelvis nye manuelle arbejdsgange. 2. Utilfredse brugere. 3. Direkte negativ påvirkning på strategimål eller udviklingsmål, eksempelvis tabt anseelse blandt udenlandske studerende. 4. Mistet indtjeningsmulighed eller større direkte omkostninger, eksempelvis fra bøder for manglende lovmedholdelighed. 5. Risiko for datatab eller systemnedbrud på driftskritiske områder.

14 Godkendt De scorede projekter samles i et excel-overblik: Parametre Kobling til Efterspørgsel fra Konsekvens ved Projekter strategi eller udviklingsmål Effektiviseringspotentiale Projektets parathed brugerorganisationen ikke at gennemføre projektet Samlet score Samlet argumentation for scoren pr projekt Lovkrav, der ikke kan opfyldes Projekt uden it-udvikling SKAL projekter Basal IT-infrastruktur der skal Projekt være på plads. - Sikker drift VIL projekter Projekt UNILED har besluttet initiativer, der skal støtte op om rekruttering af 9 udenlandske studerende Projekt Projektet er allerede godt i gang på forretningssiden men 9 mangler it-ressourcer Kort beskrivelse af de enkelte projekter vil kunne findes i separat bilag med oversigt over alle projekter.