•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
•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
•Faser – hvor langt er hvert projekt nået
•Statusrapportering – samme sprog og struktur
•Farvekoder for sundhedstilstand på flere parametre
•Scope, tidsplan, ressourcer, gevinster
•Den enes positive BC er den andens forsinkelse => helhedssyn er nødvendigt!
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:
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.
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:
På baggrund af det udsendte materiale og dialogen på de bilaterale møder udarbejder Porteføljechefen et overblik til PFU og LEA
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:
LEA - Ledelseskredsen i EnhedsAdministrationen
PFU - PorteFøljeUdvalg
Styregruppe
Projektleder
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.