PORTEFØLJESTYRING OG PROJEKTMODEL

PORTEFØLJESTYRING OG PROJEKTMODEL Indholdsfortegnelse Porteføljestyring og Projektmodel... 2 Programmer, projekter og opgaver... 4 Projekttyper... 6 Prioritering... 8 Overblik over faserne... 11 Porteføljeindgang... 12 På vej... 14 Gate 0... 16 Foranalyse... 18 Gate 1... 20 Indmeldingsprocessen... 22 Rapportering... 24 Review af projekter... 25 Værktøjer... 26 Detaljerede procesbeskrivelser og guidelines... 26 Regneark til fælles porteføljestyring og koordinering... 26 Skabeloner... 26 Ressourceestimeringsmetoder... 26 Ordforklaringer... 27 FALK... 27 Lokalt... 27 Version 1.1 af 14.03.2013 Side 1 af 27

Porteføljestyring og Projektmodel Porteføljestyring handler om at gennemføre de rigtige projekter, mens projektmodel handler om at gennemføre projekterne rigtigt. Ved at arbejde med porteføljestyring og projektmodel i forening opnås en styrkelse af gennemførelsen og en bedre balance, der sikrer professionel løsning af kerneopgaver på AU. Målene for porteføljestyring på AU er: Skabe bedre beslutningsgrundlag for prioritering, der styrker en omkostningseffektiv gennemførelse af projekter og skaber sammenhæng i ressourcefordelingen både lokalt og centralt. Skabe større synlighed om påvirkning af projekter på organisationen. Medvirke til at projekterne gennemføres effektivt, forberedt, at roller og beslutningskompetence er klare, og at de rigtige ressourcer disponeres på rette tidspunkt. Målet for fælles projektmodel på AU er: Fælles processer og metoder, der understøtter effektiv og professionel gennemførelse af projekter. o o o Med udgangspunkt i brugernes behov og ønsker Roller og beslutningskompetencer er klare De rigtige ressourcer disponeres på rette tidspunkt AU s projektmodel er beskrevet på 2 niveauer. Det øverste niveau afspejler projekternes livscyklus, og det er her koblingen mellem model og porteføljestyring sker. Det andet niveau i projektmodellen beskriver projektets faser hen gennem livscyklussen. Det er det enkelte projekts styringsredskab og den del af modellen projektlederens værktøjer hægtes op på. Version 1.1 af 14-03-2013 Side 2 af 27

Projektmodel og Porteføljestyring Gennemføre projekterne rigtigt Gennemføre de rigtige projekter Fælles centrale begreber, skabeloner Klare beslutningsprocesser Etablere portefølje organisering Klare projektmål, milepæle, faser Prioritere projekt portefølje Afstemme ressourcer til projekter Tydelig brugerinvolvering Forbedre porteføljen Projektafhængigheder Ressourceallokering Lede porteføljen 18-03-2013 Projekt og porteføljestyringsmodel Projekt Portefølje Prioritering Porteføljeindgang På vej Gate 0 Foranalyse Gate 1 I gang Gate 2 Indkøring Afslut Effektevaluering Indstilling version 1 version 2 Kvalificering Analyse Planlægning Udarbejdelse Implementering Afslutning Drift og support Version 1.1 af 14-03-2013 Side 3 af 27

Programmer, projekter og opgaver Definitionen af et projekt er: En midlertidig organisation, der er oprettet med det formål at levere et eller flere unikke forretningsprodukter i henhold til et beskrevet behov på et aftalt tidspunkt. Projekter har en eller flere hovedleverancer, der udtrykker projektets samlede resultat til projektejer. Projekter har effekt, der udtrykker hvilken værdi, projektet skaber for brugerorganisationen. Et projekt slutter, når det har nået sine mål, og projektorganisationen opløses. Herefter overgår projektets leverancer til en drifts- og vedligeholdelsesfase eller et nyt projekt med nye mål kan startes på basis af leverancerne. Definitionen af et program er: En samling af projekter, der deler en fælles vision og hvor effekten af projektprogrammet kun kan realiseres via de samlede hovedleverancer fra projekterne i programmet. Et program er en form for samlings-projekt, hvor de enkelte dele er projekter. Definitionen af en opgave er: Opgaver adskiller sig fra et projekt ved at operere indenfor kendte rammer. Enten en kendt proces for løsning (Eksempelvis planlægning og gennemførelse af en konference eller en ad hoc brugerhenvendelse), eller et kendt og tilbagevendende tidspunkt (Eksempelvis årlige lønforhandlinger). Ved at skelne mellem projekter og programmer fås et projektmæssigt styringsredskab ind over de større og mere komplekse projekter. Samtidig mindsker det kompleksiteten i porteføljestyringen, der kan koncentrere indsatsen om programmerne vel vidende at der allerede er fokus på afhængigheder og ressourcer mellem projekterne internt i programmet. Ved at skelne mellem opgaver og projekter opnår organisationen en veldefineret beslutningsstruktur forog prioritering af de mange aktiviteter der skal gennemføres internt i afdelingerne såvel som på tværs i AU. Version 1.1 af 14-03-2013 Side 4 af 27

Allerede i porteføljeindgangen tages der stilling til om den opgave, der kommer ind er et projekt eller en opgave. Efterfølgende kan det være i løbet af kvalificeringen af indstillingen, at det defineres hvorvidt der er tale om et projekt, eller om der er behov for at organisere projektet i et decideret program. I nogle tilfælde vil det først være i forbindelse med en analyse af projektet, at programmet identificeres og defineres. Version 1.1 af 14-03-2013 Side 5 af 27

Projekttyper Projekttypebegrebet benyttes til at gruppere projekter i kasser der kan arbejdes med efterfølgende. Grupperingerne afspejler beslutningsstrukturer, samarbejdsflader og projektkompleksitet. Hos AU bruges projekttyperne til at definere minimumskrav til projekterne hen igennem projektprocessen. Det være sig krav til beslutning og prioriteringsprocessen, eller krav til udarbejdelse af dokumentation. Projekttypen kan bestemmes allerede i porteføljeindgangen og skal som minimum være på plads ved GATE0 godkendelsen af projektet. Projekttypen fastsættes af lokalt beslutningsorgan. Projekttypen bruges i denne fase til at definere hvilke projekter, der skal udarbejde en version 1 og til at fastlægge beslutnings og prioriteringsniveau for projektet. Version 1.1 af 14-03-2013 Side 6 af 27

Version 1.1 af 14-03-2013 Side 7 af 27

Prioritering Prioritering må ikke forveksles med godkendelse af projektet. Prioritering kigger udelukkende på projekter, det allerede er besluttet skal gennemføres og som er godkendt i alle de for projektet relevante fora. Prioritering sætter herefter fokus på hvornår timingen er rigtig for projektet i forhold til alle de øvrige projekter, der også er godkendt til at skulle gennemføres. Prioriteringen har også som en del af sin værktøjskasse mulighed for at sætte projekter på pause, eller helt lukke projekter, der ikke kan ses en prioriteringsmæssig fremtid for indenfor en overskuelig horisont. Prioriteringen kommer dermed til at anvise en rækkefølge af projekterne, enten enkeltvis eller i grupperinger. Projektporteføljen på AU er meget omfattende. De mange initiativer påvirker brugerorganisationen når de gennemføres, men også hvis de ikke gennemføres hurtigt nok, der hvor behovet er størst. Samtidig trækker mange af projekterne på de samme nøglepersoner for at kunne gennemføres og i disse tilfælde skal der træffes et valg om hvilket projekt, der skal prioriteres først. Endelig er der også for mange af projekterne en afhængighed mellem de leverancer, der skal leveres fra projekterne. Prioriteringen skal sikre, at projekterne gennemføres i en fornuftig rækkefølge set i forhold til afhængigheder. Prioritering foretages løbende på hele porteføljen ud fra hvor projekterne er. Den tværgående porteføljestyring koncentrerer sig om de projekter, der har den bredeste involvering af brugerorganisationen (Projekttype A1 og A2). Disse projekter prioriteres af Universitetsledelsen. Sideløbende med denne prioritering vil FællesAdministrationens LederKreds-FALK sikre koordinering og prioritering af de projekter, der ikke når helt så bredt ud i brugerorganisationen, men som involverer flere vicedirektørområder, der skal finde ressourcer til projektet (Projekttype A3). Den sidste del af prioriteringerne foregår i de lokale beslutningsorganer, hvor alle de projekter, der ikke har tværorganisatorisk karakter prioriteres (Projekttype B1 og B2), og hvor den del af A-projekterne, der ikke er prioriteret af FALK eller Universitetsledelsen placeres i den nære sammenhæng. Version 1.1 af 14-03-2013 Side 8 af 27

Hvordan prioriteres administrative projekter Universitetsledelsen Universitetsdirektøren og FALK Lokalt A1 Projekter der, involverer alle hovedområder A1 A2 A2 Projekter, der involverer et helt hovedområder eller flere hovedområder på AU. A3 A3 Projekter der involverer flere VDområder og evt. et eller få institutter. B1 B2 B1 B2 Projekter der involverer flere afdelinger/teams internt i egen enhed Projekter der kun involverer én afdeling/et team i egen enhed Hvad betyder prioritering? Prioritering i Universitetsledelsen: For projekter af typen A1 og A2, der prioriteres af Universitetsledelsen gælder: Hovedområderne og administrationen afsætter de nødvendige ressourcer til gennemførelsen af projekterne før de afsætter ressourcer til andre projekter. Projekterne planlægger de konkrete tidspunkter for involvering med de enkelte hovedområder. Hovedområderne og administrationen accepterer de projektudskydelser, der evt. kan komme på de ikke prioriterede projekter. Universitetsledelsen følger den overordnede fremdrift af de prioriterede projekter. Version 1.1 af 14-03-2013 Side 9 af 27

Hvad betyder prioritering - Fortsat For øvrige projekter gælder: Hvis dele af et hovedområde involveres, skal det være aftalt med dekan eller institutleder For projekter af typen A3, der prioriteres af FALK gælder: Administrationen afsætter de nødvendige ressourcer til de prioriterede projekter, dog under hensyntagen til at projekter prioriteret af UNILED skal bemandes først. For projekter af typen B1 og B2, der prioriteres af lokalt beslutningsorgan gælder: Et VD-område kan fortsætte eller igangsætte projekter, hvis ressourcerne kan holdes inden for eget VD-område og under hensyntagen til, at projekter prioriteret af UNILED og FALK bemandes først. For alle projekter gælder: Hovedområder og VD-områder kan aftale at fortsætte eller igangsætte projekter, der ikke er prioriteret, under hensyntagen til, at projekter, der er prioriteret af Universitetsledelsen eller FALK bemandes først. Version 1.0 af 04.02.2013 Side 10 af 27

Overblik over faserne G A T E 0 G A T E 1 G A T E 2 A F S L U T Version 1.1 af 14-03-2013 Side 11 af 27

Indstilling version 1 version 2 Prioritering Porteføljeindgang På vej Gate 0 Foranalyse Gate 1 I gang Gate 2 Indkøring Afslut Effektevaluering Porteføljeindgang Et projekt bliver til på baggrund af et behov i organisationen. Disse behov skal samles op og undersøges. Organisationen skal have en indgang til at komme af med deres gode ideer, ønsker og akutte behov. Det første der sker i projektmodellen kalder vi derfor for porteføljeindgangen. Det er her behovene samles, vurderes og viderebehandles alt efter om der er tale om projekter eller opgaver. Kun projekterne går videre i modellen. Porteføljeindgangen generer et dokument: Første version af en indstilling. For at sikre at opgaver der har karakter af projekter, kommer til at indgå i porteføljen og den samlede prioritering. Og for at sikre at alle behov opsamles og bearbejdes uanset hvor i organisationen de kommer fra. Behov kan komme mange steder fra, eksempelvis myndigheder, medarbejdere, systemejere, være udsprunget fra andre projekter eller være et led i en større forandringsproces. Disse behov omsættes via porteføljeindgangen til projektideer som beskrives i en skabelon for projektindstillinger. Projektbehovene opsamles lokalt i de enkelte vicedirektørområder/hovedområder. Alle projekter skal have en lokal forankring i enten et VD-område eller et hovedområde. Ansvaret for at der defineres et ejerskab til projektet, ligger i det område, hvor behovet kommer ind første gang. Hvert område skal definere og beskrive deres proces for porteføljeindgang og sikre at brugerorganisationen og medarbejderne er bekendt med processen. Version 1.1 af 14-03-2013 Side 12 af 27

Projekt Første trin i projektmodellen er porteføljeindgangen Porteføljeindgang Indstilling Lokal proces RETNINGSLINJER FOR INDSTILLINGEN: Alle opgaver af projektkarakter beskrives i en indstilling. Både interne ideer og henvendelser fra brugerorganisationen. Indstillingen skal detaljeres til et niveau, der giver beslutningsgrundlag for om projektet skal videreføres, lukkes, eller sættes på pause. Alle VD-områder og hovedområder benytter den samme skabelon for indstillinger. Processen i grove træk Behov opstår Opgave Enheden vurderer om der er tale om et projekt eller en opgave Videregives til drift eller supportorganisationen i relevant område Medarbejdere sikrer udfyldelsen af første version af en indstilling Beslutningsorgan vurderer om projektet skal videreføres på baggrund af den første beskrivelse Projekt afvist/lukket Indstilling klar til kvalificering Version 1.1 af 14-03-2013 Side 13 af 27

Indstilling version 1 version 2 Prioritering Porteføljeindgang På vej Gate 0 Foranalyse Gate 1 I gang Gate 2 Indkøring Afslut Effektevaluering På vej På vej er der hvor henvendelsen, den gode ide, bliver kvalificeret yderligere og der tages stilling til om projektet er et der skal arbejdes videre med, om det skal lukkes/afvises eller om det skal sættes på pause til senere revurdering. Indstillingen er grundlaget for den videre beskrivelse af behovet. På vej- fasen vil generere to dokumenter, alt efter projekttypen. En færdig indstilling og en version 1. Indstillingen detaljeres, for derigennem at finde ud af hvad det kommende projekt skal indeholde og hvornår det ideelt set tænkes gennemført. For nogle projekter kan det forholdsvis nemt beskrives, for andre projekter er det nødvendigt at starte en foranalyse før man kan komme det nærmere. Det er en af de ting kvalificeringen skal klarlægge. På vej fasen hænger tæt sammen med porteføljeindgangen i det enkelte VD-område/hovedområde, og beskrives i sammenhæng. Fælles for alle områder vil dog være behovet for nogle procedurer, der sikrer at: 1) Projekttype defineres og ejerskab i organisationen fastsættes. 2) Projektet godkendes på relevant niveau. Inden projektet kommer alt for langt i sin beskrivelse, skal det f.eks. vurderes om det er en ide, der skal godkendes af Universitetsledelsen, FALK, Dekaner, udvalg eller andre organer. En sådan godkendelse skal så indarbejdes i processen. 3) Projektet indmeldes til porteføljestyring hvis det er et A- projekt. 4) Der tages stilling til om projektet skal gennemløbe en foranalyse. 5) Indstilling og detaljeres til et tilstrækkeligt niveau. 6) Fasen afsluttes med en Gate0 godkendelse af projektet. Version 1.0 af 04.02.2013 Side 14 af 27

På vej fasen Processen i grove træk: Hvad Behov kvalificeres og beskrives i en indstilling og i en Leverancer Projektejer udpeget. Projektleder udpeget Forretnings- og it-arkitekter udpeget. Projektet indmeldt til porteføljestyring. Godkendt Indstilling. Godkendt version 1. G A T E 0 Indstilling klar til kvalificering Medarbejder(e) detaljerer behovbeskrivelsen i indstillingen Tjekliste Tidsplan for foranalyse eller Tidsplan for projekt. Er projektets mål, leverancer og effekter beskrevet? Hvordan understøtter ideen organisationens strategi? Er der fokus på effekterne og ikke blot på teknologien? Beslutningsorgan i enheden tager stilling til projektet, herunder projekttype, indmelding til porteføljestyring og hvor indstillingen skal godkendes. Hvem skal involveres for at kvalificere indstillingen? Skal processer ændres? Hvad vil de største risikofaktorer være og hvordan kan vi minimere dem i en eventuel analysefase? version1 udarbejdes for A1 og A2 projekter. Enten på analysefasen eller på hele projektet Hvilke nøgleressourcer er der behov for i næste fase? Er projektet godkendt i alle de rigtige fora? Er der en plan for næste fase? Lokal porteføljestyring tager en Gate0 beslutning om projektet Lokal proces Version 1.1 af 14-03-2013 Side 15 af 27

Indstilling version 1 version 2 Prioritering Porteføljeindgang På vej Gate 0 Foranalyse Gate 1 I gang Gate 2 Indkøring Afslut Effektevaluering Gate 0 Gate 0 er det lokale beslutningspunkt, der afgør om projektet skal fortsætte, sættes på pause eller måske helt lukkes ned igen. Processen for denne Gate0 godkendelse, og de prioriteringskriterier, der ligger til grund for beslutningen vil variere fra område til område. Samtidig kan der være forskel på, hvorledes man ønsker at arbejde med de forskellige projekttyper. Fælles for alle er, at projekter som er klassificeret som A-projekter kun kan godkendes i Gate0, hvis de har et beskrivelsesniveau, der kan danne grundlag for prioritering hos FALK og universitetsledelsen. Gate0 skal sikre at det er de rigtige projekter der startes op indenfor det enkelte område. Dvs. at projekterne understøtter områdets strategier eller handlingsplaner, har den rigtige timing etc. Gate0 skal også sikre, at de store tværorganisatoriske projekter identificeres og beskrives på et tidligt tidspunkt, således at samarbejde, brugerinddragelse og prioritering kan komme i fokus fra projektets start. Gate0 godkendelsen sker lokalt i de respektive VD-områder/hovedområder. Der er tre udfald af Gate0 beslutningen. 1) Luk projektet 2) Sæt projektet på pause 3) Godkend projektet Projektet godkendes enten til at gennemføre en foranalyse, eller til at gå direkte i gang og starte op på planlægning og udarbejdelse af projektet. Beslutningen handler om hvorvidt projektet skal gennemføres eller ej (eventuelt i form af en foranalyse først), og om timing er rigtig. Det er IKKE en prioritering af projektet. Version 1.1 af 14-03-2013 Side 16 af 27

GATE0 godkendelsen er kvalitetssikringen af, at det er de rigtige projekter, der startes op. Ide 2 Ide 1 Ide 3 Godkendte projekter MINIMUMSKRAV for dokumentation af projekterne inden de fortsætter til næste fase Projekttype Minimumskrav A1 og A2 Indstilling: o Godkendt af kommende projektejer o Godkendt af universitetsledelsen og/eller andre organer, hvis der er behov for dette. udarbejdet indeholdende: o Udpeget projektejer. o Mål, hovedleverancer og effekt o Projektorganisering som minimum for næste fase. o Plan for hvorledes projektet/foranalysen skal gennemføres. Milepælsplan for hovedleverancer og leverancer Planen skal indeholde identificerede arkitekturovervejelser, der afklares i en foranalyse. o Identifikation af projektafhængigheder og nøglepersoner. o Slutdato for projektet eller foranalysen. A3 Indstilling: o Godkendt af kommende projektejer. o Godkendt af FALK og/eller andre organer, hvis der er behov for dette. o Ressourceestimering for de VD-områder, der skal deltage. o Slutdato for projektet eller foranalysen. B1, B2 Ingen minimumskrav Version 1.1 af 14-03-2013 Side 17 af 27

Indstilling version 1 version 2 Prioritering Porteføljeindgang På vej Gate 0 Foranalyse Gate 1 I gang Gate 2 Indkøring Afslut Effektevaluering Foranalyse Ikke alle projekter skal gennem et foranalyseforløb, men mange af de bredt funderede A-projekter vil have et behov for at blive yderligere afklarede, inden det endelige projekt kan beskrives. Når projekter startes op er det med henblik på at ændre en eksisterende situation til fordel for en ny (og bedre) tilstand. For at kunne planlægge den bedste måde at komme derhen kan det være nødvendigt at få belyst hvor man er og hvilke muligheder der er for rejsen. Foranalysefasen bruges således til at få undersøgt forhold omkring projektet, der er med til at definere det endelige projekts rammer og løsninger. Foranalysen skal ikke bruges til at gennemføre egentlige projektaktiviteter eller leverancer. Det er heller ikke i foranalysen man foretager leverancenedbrydning, ressourceallokering og øvrige projektplanlægningsaktiviteter som vedrører projektets hovedleverancer. Det er typisk i løbet af en foranalyse at grundlæggende arkitekturbeslutninger træffes. Det er også i foranalysen at kravspecifikationer og udbudsproces gennemføres, således at man, når leverandørvalg er foretaget og kontrakten er underskrevet, kan planlægge resten af projektet. Foranalysen genererer et dokument: version 2. Foranalysen har til formål at frembringe det beslutningsgrundlag, der skal til for at kunne forme det endelige projekt. Rammerne for foranalysen er beskrevet i version 1 for projektet. Version 1.0 af 04.02.2013 Side 18 af 27

Foranalysen kan igangsættes når projektet er godkendt i GATE0. Er der ikke allerede udpeget en projektleder skal dette gøres i forbindelse med opstarten af foranalysen.foranalysens forløb vil variere fra projekt til projekt, alt efter hvilke emner der er i fokus, og hvad projektet indeholder. Fælles for foranalyserne vil være at der skal være planlagt projektaktiviteter der sikrer at: Arkitekturaktiviteter bemandes. Foranalysen detailplanlægges og ressourcesikres. Systemer risikovurderes i samarbejde mellem systemejer og it-sikkerhed. Forretningsbeslutninger identificeres og træffes på rette niveau og i rette organer i organisationen. version2, der beskriver resten af projektet, udarbejdes. G A T E 1 Hvad Grundlaget for projektet analyseres og rammerne fastlægges. Løsninger, der påvirker projektets rammer, designes. Forretningsbeslutninger, der påvirker projektets rammer, skal træffes. Udbud gennemføres. Leverancer Systemejer udpeget. Vedr. it: Arkitekturleverancer for: Processer (AS IS og TO BE) Systemlandskab Projektafhængigheder Begreber Relevante forretningsbeslutninger Strategi for udfasning af gamle systemer, herunder data og afhængigheder Kravspecifikation. Underskrevet udbudskontrakt Tidsplan for projektet. Godkendt version 2. Retningslinjer for ressourceaftaler mellem samarbejdende parter Ressourcesikringen foretages af det område, der ejer projektet. Ressourcesikringen skal respektere beslutninger om prioritering foretaget af Universitetsledelsen og FALK. Foranalysen planlægges i henhold til de opnåede ressourceaftaler. Tjekliste Er foranalysen detailplanlagt? Er organiseringen for foranalysen på plads? Er ressourcesikringen for foranalysen tilstrækkelig? Hvordan kan forretningsbeslutningerne gennemføres kalendermæssigt? Er udbudsforretningens aktiviteter på plads? Er implementeringsstrategien for projektet fastlagt? Er brugerorganisationen tilstrækkeligt involveret i analysen? Er projektet godkendt i alle de rigtige fora? Er der en plan for projektet? Version 1.1 af 14-03-2013 Side 19 af 27

Indstilling version 1 version 2 Prioritering Porteføljeindgang På vej Gate 0 Foranalyse Gate 1 I gang Gate 2 Indkøring Afslut Effektevaluering Gate 1 Gate 1 er det lokale beslutningspunkt, der afgør om projektet skal fortsætte, sættes på pause eller måske helt lukkes ned igen baseret på oplysninger der er kommet frem i løbet af foranalysen. Det betyder at gate1 bliver en kvalitetssikring af, at projektet er beskrevet på et tilstrækkeligt niveau og at analyserne har været bredt nok omkring. Processen for denne Gate1 godkendelse, og de prioriteringskriterier, der ligger til grund for beslutningen vil variere fra område til område. Samtidig kan der være forskel på, hvorledes man ønsker at arbejde med de forskellige projekttyper. Fælles for alle er, at projekter som er klassificeret som A-projekter kun kan godkendes i Gate1, hvis de har et beskrivelsesniveau, der kan danne grundlag for prioritering hos FALK og universitetsledelsen. Gate 1 skal sikre at de projekter, der igangsættes har det rigtige indhold i forhold til de behov der skal opfyldes og de effekter man ønsker at opnå. Samtidig skal gate1 godkendelsen sikre at projektet stadig er relevant for AU, at timingen er rigtig og at projektets (nye) mål og visioner er godkendt i alle de rigtige fora. Gate1 godkendelsen sker lokalt i de respektive VD-områder/hovedområder. Ved gate1 godkendelsen vil projektet som regel præsentere resultaterne af foranalysen og forklare hvorledes disse resultater er indarbejdet i projektbeskrivelsen i version 2. Der er tre udfald af Gate1 beslutningen: 1) Luk projektet 2) Sæt projektet på pause 3) Godkend projektet Version 1.0 af 04.02.2013 Side 20 af 27

Godkendes projektet kan det sættes i gang. Hvornår projektet rent fysisk startes op, afhænger af projektets prioritering i forhold til øvrige projekter, og timingen i øvrigt. Gate1 beslutningen handler om hvorvidt projektet skal gennemføres eller ej. Det er IKKE en prioritering af projektet. MINIMUMSKRAV for dokumentation af projekterne inden de fortsætter til næste fase Projekttype Minimumskrav A1 og A2 version 2 udarbejdet indeholdende: o Udpeget projektleder. o Udpeget systemejer o Mål, hovedleverancer og effekt o Projektorganisering o Plan for hvorledes projektet skal gennemføres. o Håndtering af projektafhængigheder og nøglepersoner. o Slutdato for projektet. A3 Ingen minimumskrav B1, B2 Ingen minimumskrav Version 1.1 af 14-03-2013 Side 21 af 27

Prioritering Porteføljeindgang På vej Gate 0 Foranalyse Gate 1 I gang Gate 2 Indkøring Afslut Effektevaluering Indstilling version 1 version 2 Indmeldingsprocessen FALK og Universitetsledelsen får alle A-projekter fra hvert Vicedirektørområde, samt alle administrative A- projekter fra hvert hovedområde uanset hvor i livscyklussen projekterne befinder sig. Det er så i første omgang FALKs og dernæst Universitetsledelsens opgave at sammensætte den konkrete portefølje for den næste periode. A1 og A2 -projekterne skal meldes ind til porteføljestyringen allerede når de er besluttet lokalt ud fra en indstilling, således at FALK og Universitetsledelsen kan tage stilling til, om det er projekter, der skal prioriteres og fremskyndes i forhold til nogle af de andre projekter, i porteføljen. Det er ledelsens opgave at definere den rette porteføljesammensætning på tværs af organisatoriske forhold og ud fra en helhedsbetragtning om hvad der er vigtigst for AU. Projekterne skal derfor prioriteres på tværs af livscyklus ud fra dels et ressourceperspektiv, dels et behovsperspektiv og dels et leveranceafhængighedsperspektiv. Det kan kun gøres, hvis ledelsen får et overblik over relevante projekter, og tilstrækkeligt beslutningsgrundlag til at kunne prioritere imellem dem. Vicedirektørområder og hovedområder indmelder deres administrative A-projekter til FALK i en fælles skabelon. Dette gøres via porteføljekoordinatorerne. Projekterne indmeldes fra det område hvor det administrative projektejerskab ligger og KUN derfra. Indmeldelsen skal medtage alle ressourceestimeringer og overvejelser, også for ressourceforbrug, der ligger i andre områder. Version 1.0 af 04.02.2013 Side 22 af 27

Projekterne registreres i forhold til hvor de er i livscyklussen. Har projekter passeret GATE1, vil nye oplysninger om projektet ikke føre til at projektet sættes tilbage til livscyklus foranalyse. Projekter vil i øvrigt have mange analyser som en del af leverancegennemførelsen i livscyklus i gang, f.eks. i forbindelse med løsningsdesign. Projekter, der har en faseopdelt implementering skal have en GATE2 godkendelse inden det går videre til indkøring. Projekt kan aftale med sin gatekeeper om efterfølgende indkøringsfaser skal godkendes, eller gategodkendelsen gælder for den alle. En arbejdsgruppe omkring porteføljestyringen samler indmeldingerne og sikrer at alle får et samlet masterark med overblik på tværs af alle områder. FALK arbejder derefter ud fra masterarket for at beskrive et beslutningsoplæg til Universitetsledelsen for den kommende periodes porteføljeprioritering. Beslutningsoplægget indstilles til Universitetsledelsen kvartalsvis, men FALK følger udviklingen i porteføljen løbene, for derigennem at kunne reagere på forandringer og igangsætte aktiviteter til at skabe det kvartalsvise beslutningsgrundlag. Version 1.1 af 14-03-2013 Side 23 af 27

Rapportering I løbet af projektets livscyklus, skal der statusrapporteres til forskellige ledelsesorganer, projektorganer og beslutningsorganer. Omfanget, frekvensen og måden der rapporteres på, afhænger dels af projekttypen dels af hvor projektet er blevet prioriteret. En del af porteføljestyringen er at lede porteføljen. Det betyder blandt andet at der skal følges op på de prioriterede projekter, og der skal foretages korrigerende handlinger i tilfælde af afvigelser eller opdukkende problemstillinger af porteføljemæssig karakter. Porteføljekoordinatorerne indsender på opfordring fra arbejdsgruppen omkring porteføljestyring en status på de af deres projekter, der er prioriteret af Universitetsledelsen. Det vil typisk ikke være alle de prioriterede projekter, der skal rapporteres på, så arbejdsgruppen omkring porteføljestyring på AU vil inden hver statusmelding skrive ud til porteføljekoordinatorerne og udstikke retningslinjerne for næste periodes statusmeldinger. Version 1.1 af 14-03-2013 Side 24 af 27

Review af projekter Review er et af projektlederens værktøjer til at kvalitetssikre sit projekt. Projektlederen kan bruge reviews både til hjælp med overblik over manglende/supplerende leverancer, men også til at sætte fokus på modtagerorganisationens parathed til at tage leverancerne i brug. Samtidig er reviews et værktøj i forbindelse med porteføljestyring, idet en gennemgang af projektet kan belyse om projektet er på rette kurs, og får de ressourcer det har behov for. Reviews kan i tide sætte fokus på områder, der skal have særlig opmærksomhed. Reviews skal gennemføres af projektkyndige personer med relation til AU. Reviews kan gennemføres i hele projektets livscyklus, men vil oftest blive brugt i forbindelse med overgangen til indkøring for at sikre at projektet og modtagerne er klar til at tage leverancerne i brug. Version 1.1 af 14-03-2013 Side 25 af 27

Værktøjer Detaljerede procesbeskrivelser og guidelines Er endnu ikke udarbejdet. Regneark til fælles porteføljestyring og koordinering Projekterne vedligeholdes lokalt. Et regneark til formålet er stillet til rådighed for alle vicedirektørområder og hovedområder. Det er obligatorisk at vedligeholde alle A-projekter i regnearket, mens registrering af B-projekter er et tilbud som kan benyttes i de enkelte enheder, for at give et samlet overblik over projektporteføljen. Alle områdearkene samles i ét masterark, der gøres tilgængeligt for porteføljekoordinatorerne i de enkelte områder. Porteføljekoordinatorerne aftaler videre distribution lokalt. Skabeloner Der er udarbejdet to fælles skabeloner som skal benyttes af alle områder. 1) Projektindstilling Oprettes i porteføljeindgangen. Kvalificeres og detaljeres i På vej - fasen. Godkendes i Gate0 Benyttes til den initielle godkendelse af projektet Benyttes i forbindelse med prioritering af projektet 2) Projekt Initierings Dokument Udarbejdes i en version 1 i På vej - fasen Godkendes i Gate0 Udarbejdes i en version 2 i forbindelse med en eventuel foranalyse. Godkendes i Gate1 Ressourceestimeringsmetoder Ikke defineret endnu. Version 1.1 af 14-03-2013 Side 26 af 27