Fælles beslutningsmodel (governance)

Formål: Sikre at henvendelser bliver håndteret, og at der skabes transparens i prioritering og gennemførelse af digitaliseringsprojekter på AU

 

Hvorfor porteføljestyring

•Porteføljestyringen skal håndtere:

•Efterspørgsel hos AU IT, der er større end ressourcerne rækker til

•Efterspørgsel fra forskellige aktører, der har fælles ”budget” hos AU IT

•Flaskehalse og ressourcer, der efterspørges flere steder samtidig

•Afhængigheder mellem leverancer i forskellige projekter/produkter

•Afhængigheder i den fælles underliggende arkitektur

•Derfor er prioritering, planlægning og koordination nødvendig

•Prioritering, der fokuserer på værdiskabelsen for AU og som synliggøres

•Planlægning, der sikrer at rækkefølgen er lagt i forhold til ressourcer og arkitektur

•Koordination, der går på tværs af projekter og produkter

Projektmodellen som forudsætning for porteføljestyring

•Skal kunne anskueliggøre fremdrift i projekter på en standardiseret måde

•Faser – hvor langt er hvert projekt nået

•Statusrapportering – samme sprog og struktur

•Farvekoder for sundhedstilstand på flere parametre

•Skal sikre ændringsstyring med fokus på konsekvensvurdering for porteføljen

•Scope, tidsplan, ressourcer, gevinster

•Den enes positive BC er den andens forsinkelse => helhedssyn er nødvendigt!

•Skal gennem minimumsleverancer og gategodkendelser, sikre beslutninger og kvaliteter, som AU sætter fokus på

Porteføljeindgange

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:

  1. udspringe af ledelsesbeslutninger f.eks. på fakulteterne eller i universitetsledelsen.
  2. komme fra allerede igangværende projekter, f.eks. hvis projektet ser en god bussiness case i at udvide projektet eller igangsætte et delprojekt.
  3. komme fra den daglige systemforvaltning, hvor f.eks. lovkrav kan spille ind.
  4. 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 eller som mindre udviklingsopgave, 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.

Forventninger til systemanvendelsen

Ud over alle de ønsker der kommer ind, når de gode ideer opstår, er der også en mere struktureret dialog om behovene for projekter og systemforvaltning. Dialogen sker på bilaterale møder mellem AU IT og Systemcheferne samt Administrationschefer og IT-supportchefer. De bilaterale møder afholdes en gang om året – i september for næste kalenderårs forvaltningsbehov samt revision af projektporteføljen for hvert område. Grundlaget for dialogen er AU IT`s masterplan, overblik over projekternes belastning i forretningen samt diverse projektoversigter, timeregistreringsoverblik m.m.

Formålet med den strukturerede dialog er:

  • Dels at få revideret projektporteføljen.
    • Er der noget som er blevet uaktuelt?
    • Noget som er gået fra ”Ønsker” til SKAL p.g.a eksempelvis myndighedskrav eller leverandørkrav. Andet?
    • Scoringer eller beskrivelser, der bør revideres?
  • Dels at få fastlagt niveauet for systemforvaltning for det kommende kalenderår.
    • Er der større opgraderinger eller udbud på vej?
    • Nye teknologiske muligheder, der bør kigges på?

På baggrund af det udsendte materiale og dialogen på de bilaterale møder udarbejder Porteføljechefen et overblik til PFU og LEA

(Ledelseskredsen i EnhedsAdministrationen)

Prioritering af projekter

Det er LEA (Ledelseskredsen i EnhedsAdministrationen), der træffer beslutning om hvilke projekter, der skal prioriteres og hvorledes prioriteringsrækkefølgen skal være. Det gør LEA bl.a. med udgangspunkt i scoringerne.

PFU (PorteFøljeUdvalget) behandler prioriterede projekter på månedligt møde, hvor også tages stilling til nye projekter, samt igangsætning  og prioritering af eksisterende projekter.”

PFU vedligeholder løbende en porteføljeplan, der afspejler projekternes prioritering og kalendermæssige placering.

Når LEA har prioriteret mellem projekterne, sker tildelingen af ressourcer i AU IT ud fra følgende principper:

  • Der allokeres til systemforvaltning. Dels minimumsdrift, dels specifikke leverancer som er aftalt, dels til mindre udviklingsopgaver, der kan gennemføres, der hvor porteføljeplanen giver mulighed for det.
  • Dernæst tildeles projekterne ressourcer i den rækkefølge de er prioriteret og ud fra nedenstående:
    • Korte koncentrerede forløb.
    • Medarbejderne allokeres til så få projekter samtidigt som muligt, helst kun 1.
    • Igangværende projekter færdiggøres inden nye sættes i gang.
  • Hvis der efterfølgende er ledig kapacitet benyttes den til forvaltning
  • Se en oversigt over prioriterede projekter

Beslutningskompetence

LEA - Ledelseskredsen i EnhedsAdministrationen

  • Beslutter hvilke projekter der skal prioriteres på baggrund af scoringsmodel og projektbeskrivelse udfyldt af projektejerne.
  • Beslutter den endelige ressourcetildeling til projekter på baggrund af oplæg fra PFU.
  • Beslutter den indbyrdes prioritering imellem projekterne på baggrund af oplæg fra PFU.
  • Beslutter prioriteringer i forbindelse med ændringer til projektportefølen.
  • Anviser budget for ufinansierede prioriteringer.
  • Eskalerer til UNILED

PFU - PorteFøljeUdvalg

  • Definerer hvornår en henvendelse er et projekt henholdvis forvaltning/mindre udviklingsopgave.
  • 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.
  • Udarbejder oplæg til prioritering i LEA med baggrund i de projekter LEA har sat på backloggen.
  • Agerer på projekters sundhedstilstand og hjælper nødlidende projekter eventuelt via ledelsesstrengen.
  • Godkender ændringsanmodninger der berører slutdato, ressourcer eller arkitektur.
  • Godkender projektafslutninger i forhold til minimumsleverancer og erfaringsopsamling.

Styregruppe

  • Godkender projektets rammer i form af PID.
  • Beslutter projektindhold indenfor projektets rammer.
  • Indstiller til PFU om fortsat prioritering ved større ændringer eller udvidelser i projektomfang.
  • Godkender faseovergange og forretningsmæssig projektafslutning.
  • Godkender leverancer og står inde for det faglige behov
  • Ejer effektmålene, forandringsledelsen og budgettet.
  • Eskalerer til LEA via ledelsesstrengen ved uenighed med PFU om ændringsanmodninger

Projektleder

  • Afgør hvorvidt leverancer og ændringer kan realiseres indenfor projektets rammer.
  • Definerer projektets sundhedstilstand til månedlig statusrapportering.
  • 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 ITs leverancer.

Scoringsmodel

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.

Alle projekter, der ønskes prioriteret:

Skal have en kort projektbeskrivelse i beslutningsmodellens skabelon.

Skal have en navngivet projektejer, der vil indgå i visiteringen af projektet.

Skal være kategoriseret som SKAL eller VIL projekt.

Skal have en udfyldt scoring med tilhørende argumenter som underbygges af beskrivelsen.

AU IT skal:

Visitere projektbeskrivelserne.

Diskuttere kategoriseringerne, scoringerne og argumenterne.

Projektejeren skal:

Tilvejebringe beskrivelse, kategorisering og scoring.

Sikre projekterne er opdaterede på projektportalen.

LEA (Ledelseskredsen i EnhedsAdministrationen) kan :

På projektprioriteringsmøde beslutte at ændre kategoriseringen af enkeltprojekter.

Projekterne scores ud fra 5 parametre:

1.       Kobling til strategi eller udviklingsmål

2.       Effektiviseringspotentiale

3.       Projektets parathed

4.       Efterspørgsel fra brugerorganisationen

5.       Konsekvens ved ikke at gennemføre projektet

Hver parameter scores i forhold til en foruddefineret skala

Alle 5 parametre tæller ligeligt i opgørelsen af projektets samlede score

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.