Du er her: AU  Medarbejdere  Medarbejderservice IT Projekter Fælles beslutningsmodel

Fælles beslutningsmodel (governance)

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.

Visiteringsprocessen

Uanset hvorledes henvendelsen kommer ind til AU IT, bliver den registreret i servicemanagementsystemet og brugeren får en kvittering for at henvendelsen er registreret.

Alle henvendelser bliver tilknyttet en tovholder fra visiteringsudvalget, der sikrer at der bliver kigget på henvendelsen.

Der kan være brug for at flere fra AU IT kommer ind over og bidrager til at undersøge og finde en løsning men tovholderen slipper ikke henvendelsen.

Når der er kommet en konklusion på hvad der skal ske med henvendelsen sikrer tovholderen at brugeren/ejeren af henvendelsen bliver orienteret.

Hvis henvendelsen resulterer i, at der skal oprettes et projekt, vil visiteringen sikre, at der er skrevet en kort projektbeskrivelse og at projektet er scoret.

Når projektet er oprettet i projektporteføljen indgår det i den agile prioriteringsproces på samme måde som de øvrige projekter i pipeline.

Se visiteringsprocessen

Forventninger til systemanvendelsen

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 Systemchefgruppen samt Administrationschefer og it-supportchefer.

Indsamlingen foretages en gang om året – i september for næste kalenderårs forvaltningsbehov samt revision af projektporteføljen for hvert område

Formålet med den strukturerede indsamling 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 indmeldingerne og bilaterale møder udarbejder PFU et overblik til LEA.

LEA beslutter niveauet for ressourcer til systemforvaltningen det kommende kalenderår.

LEA beslutter hvilke projekter i porteføljen, der skal prioriteres og hvilken indbyrdes prioritering de skal have. Både de projekter, der er i backlog og de projekter, der er i gang.

 

Prioritering af projekter

Det er LEA, 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.

LEA behandler prioriterede projekter på månedligt møde, hvor også tages stilling til nye projekter, samt igangsætning  og prioritering af eksisterende projekter.

AU IT fremlægger, på baggrund af LEAs prioriteringsrækkefølge, et oplæg til kalendermæssig prioritering og rækkefølge ud fra ressourcetilgængelighed, afhængigheder mellem projektleverancer og eventuelle deadlines. Dette afspejles i en porteføljeplan samt prioriteringsrækkefølge som godkendes af LEA månedligt og publiceres på beslutningsmodellens hjemmeside under ”Prioriterede projekter”.

Når LEA har besluttet prioriteringsrammen for forvaltning og projekter, samt 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.
  • Hvis der efterfølgende er ledig kapacitet benyttes den til forvaltning og uprioriterede projekter.

Beslutningskompetence

LEA

  • Beslutter hvilke projekter der skal prioriteres på baggrund af scoringsmodel og projektbeskrivelse udfyldt af projektejerne.
  • Beslutter den endelig ressourcefordeling mellem projekter og systemforvaltning i AU IT 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 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 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.


1429892 / i40