RSD It-projektmodel Guide til it-projekter i Region Syddanmark

Transkript

1 Regional IT - PMO RSD It-projektmodel Guide til it-projekter i Region Syddanmark Projektplan Version April 2017

2 Indhold Guide til gennemførelse af it-projekter i Region Syddanmark... 2 Definitioner It-projekt: Fra idé til bevilling Overvejelser om iværksættelse af nyt it-projekt Definition af et projekt Godkendelse af projekt Processer Region Syddanmarks It-projektmodel It-projektmodellen Projekttrinnene Oversigt over projektstyringsdokumenter Organisering af projekter Projektorganiseringens principper Projektorganiseringens roller og deres ansvar Projektorganisering i praksis Overblik over beslutningspunkter It-beslutningsstruktur Rapportering af regionale projekter Formålet med statusrapportering Proces for rapportering Appendiks 1. Vejledning til skalering af projekter A1.1 Kompleksitet A1.2 Hvilke overvejelser bør foretages ved skalering af de enkelte typer af projekter A1.3 Projektstyringsdokumenter Appendiks 2. Fælles politik for test og kvalitetssikring A2.1 Formålet med test og kvalitetssikring A2.2 Test og kvalitetssikringsaktiviteter i It-projektmodellen A2.3 RSD testmodel og værktøjer Appendiks 3. Vejledning om informationssikkerhed i projekter A3.1 Baggrund A3.2 Informationssikkerhed i It-projektmodellen... 32

3 Guide til gennemførelse af it-projekter i Region Syddanmark Denne guide samler Region Syddanmarks It-projektmodel med de mest centrale processer, der er i forbindelse med et projekt. Den fælles projektmodel skal bidrage til en bedre og mere konsistent planlægning, styring, opfølgning og gennemførelse af it-projekter i Region Syddanmark. Modellen skal medvirke til at sikre en række formål og aktører i projektarbejdet. De vigtigste er: * Udvalg for Sundheds-it godkender regionale projekter direktionen for den enkelte enhed godkender lokale projekter RSD It-projektmodellen opdeler projektforløbet i fem projekttrin med underliggende faser og beslutningspunkter. Modellen beskriver desuden, hvilke processer og projektstyringsdokumenter, som indgår i et projektforløb fra start til slut. Anvendelse af modellen er obligatorisk for alle it-projekter i RSD, men tilpasses det enkelte projekts styringsbehov. Denne guide beskriver RSD It-projektmodellen og de centrale arbejdsgange ved it-projekter: Processen omkring bevilling af projekter og nogle af de centrale overvejelser, der ligger i den forbindelse Projektmodellens opdeling i projekttrin og overgangskriterierne for at komme fra det ene trin til det næste, projektstyringsdokumenter og brug af disse Organisering og styring af projekter med fordeling af roller og ansvar og sammenhængen mellem projektet, styregruppe og beslutningsorgan Procedurer for projektstatusrapportering Appendiks: o Vejledning til skalering af projekter o Politik for test og kvalitetssikring o Vejledning om informationssikkerhed i projekter Hvis du har brug for hjælp til projektmodellen og projektarbejdsformen, så kan PMO-teamet i Regional IT hjælpe. Side 2 af 36

4 Definitioner Centrale begreber i denne guide: Beslutningsorgan: Kompleksitetsscore: PMO: Portefølje: Direktion: Det beslutningsorgan, der træffer beslutning om oprettelse og lukning af projektet, samt bevilger ressourcer til et projekt. For regionale projekter er det Udvalg for Sundheds-it (USIT) og for lokale projekter er det direktionen for den enkelte enhed. Beregnet score for et projekts ledelseskompleksitet. I Region Syddanmark anvendes en scoringsmetode inspireret af skemaet Karakteristik af ledelseskompleksitet fra bogen Kompetencer i projektledelse (grundbog for IPMA-projektledercertificering). PMOteamet i Regional IT kan vejlede i scoring af projekter efter denne model. Kommer af det engelske Project/Portfolio Management Office. I Region Syddanmark er PMO-funktionen forankret i Regional IT, PMOteamet. Teamet udvikler, vedligeholder og vejleder i it-projektmodellen og de dertilhørende principper, processer, metoder og værktøjer for projektledelse, samt sikrer overblik over den regionale itprojektportefølje. PMO-teamet bidrager med reviews og sparring for kvalitetssikring af it-projekter og faciliterer netværks-aktiviteter for itprojektledere i RSD. Udover ovennævnte opgaver er PMO-teamet bl.a. også sekretariatsfunktion for Udvalg for Sundheds-it (USIT) og udarbejder/vedligeholder Region Syddanmarks Sundheds-it strategi. Den samlede mængde af it-projekter. Direktionen for den enkelte enhed (sygehus eller Regionshuset). Fungerer som beslutningsorgan for godkendelse af lokale it-projekter. Lokal direktion og sygehusledelse tænkes der her Udvalg for sundheds-it: Udvalg for sundheds-it (USIT) tager ledelsesmæssige beslutninger om de it-projekter og prioriteringer af it-systemer, der igangsættes i Region Syddanmark. I USIT er de 5 sygehusfællesskaber repræsenteret ved adm. direktør og it-direktør. Formanden for udvalget er den siddende regionsdirektør. RSD: Pejlemærker: Forkortelse for Region Syddanmark Regionerne har som en del af en fælles strategi for digitalisering af sundhedsvæsenet forpligtet sig til et antal sigtepunkter for deres indsats inden for sundheds-it. Hver region skal løbende indrapportere status til Regionernes Sundheds-it (RSI) på de projekter/aktiviteter, der er igangsat for at realisere pejlemærkerne. Side 3 af 36

5 1. It-projekt: Fra idé til bevilling Dette kapitel beskriver retningslinjerne for anvendelse af It-projektmodellen, hvornår skal den bruges og hvilke beslutningsorganer er med til at træffe beslutningerne. 1.1 Overvejelser om iværksættelse af nyt it-projekt Baggrunden for et nyt it-projekt kan være ny eller ændret lovgivning, strategiske beslutninger, nye teknologiske muligheder osv. PMO-teamet i Regional IT skal normalt inddrages i overvejelserne, ligesom det oftest også er en fordel at involvere Sundheds-økonomi 1. Projektmodellen anvendes, når større it-projekter i RSD skal igangsættes. Projektforslag, projektbeskrivelse og projektafslutningsrapport skal godkendes i de relevante beslutningsorganer Udvalg for Sundheds-it eller enhedens direktion. Ved mindre it-projekter skal anvendelse af modellen nedskaleres til det, der giver værdi. Se appendiks Definition af et projekt Der er tale om en enkeltstående, kompleks og tidsafgrænset (startdato og slutdato) opgave med et veldefineret mål, hvor der ofte skal arbejdes tværorganisatorisk Projektet er korrekt og realistisk afgrænset, så det er muligt at styre projektets leverancer Grundlaget for at realisere forretningsudbytte, gevinster og mål er til stede. 1.3 Godkendelse af projekt Udvalg for Sundheds-it prioriterer og beslutter sundheds-it indsatsen i regionen. Som beslutningsorgan beslutter udvalget dermed hvilke it-projekter, der skal iværksættes, og varetager porteføljeledelsen. Udvalget kan udmønte bevilling til projekter, hvis det ligger indenfor Sundheds-it rammen 2. Bevillinger herudover skal findes inden for de enkelte sygehuses og stabes økonomi og/eller bevilges politisk. Projekter vedrørende administrative it-systemer finansieres ikke af Sundheds-it rammen. Til udvalget skal der udarbejdes et dagsordenpunkt (sagsfremstilling)i henhold til processen herfor. Denne findes på intranettet, hvor også mødedatoer og tidsfrister for fremsendelse m.m. fremgår. Som et bilag til sagsfremstillingen vedlægges et projektforslag i henhold til it-projektmodellen. PMO-teamet i Regional IT er med til at kvalitetssikre indstillinger til Udvalg for Sundheds-it. I it-projekter, der involverer eksterne parter, fx tværsektorielle eller tværregionale samarbejdsprojekter, skal det vurderes, hvilke godkendelsesinstanser, der er relevante. Det skal også afstemmes, hvilken projektmodel, projektet skal følge, fx finder der en RSI-projektmodel for 1 Sundhedsøkonomi er en stabsfunktion i Regionshuset 2 Som en del af regionens årlige budget, er der afsat en økonomisk anlægsramme til investeringer i sundheds-it Side 4 af 36

6 tværregionale projekter. I projekter, hvor det ikke umiddelbart er givet, at der skal følges en anden projektmodel fra en ekstern part, opfordres der til, at RSD It-projektmodellen anvendes. 1.4 Processer Nedenstående er nogle af de kerneprocesser, som er vigtige at kende for projektlederen for at kunne agere. Alle it-projekter i RSD skal oprettes i Leverancesystemet 3, som danner grundlag for porteføljestyring og rapportering i RSD. Det er projektlederens værktøj til at lede projektet. Derudover fungerer det som styringsværktøj for relevante beslutningsfora f.eks. Udvalg for Sundheds-it. Inden et projekt kan overgå til drift, skal der være sket en serviceintroduktion 4 til den/de funktion(er), som skal varetage driften. Konkret kan det være til en drift- og supportafdeling eller en regional forvaltning. Skal projektet bruge ressourcer fra Regional IT, følges Regional IT s proces for rekvisition af ressourcer (Ressource Management), som findes beskrevet på intranettet. Eksempler på ressourcer/ydelser, som Regional IT tilbyder, er: it-arkitekt til udarbejdelse af arkitekturanalyse, specialister til etablering af driftsmiljø, testkonsulent til rådgivning omkring og koordinering af kvalitetssikring. Læs mere på intranettet under Projekter og ydelser i it-projekter. PMO-teamet i Regional IT kan hjælpe med at vejlede i It-projektmodellen, skalering af projektet og forklare værktøjerne, som kan findes på regionens intranet. Det anbefales, at man tager et opstartsmøde med PMO-teamet ved etableringen af et nyt projekt. 3 It-værktøj til understøttelse af It-projektmodel og porteføljestyring. 4 Der kan læses mere om Serviceintroduktion og processen omkring det på regionens intranet Side 5 af 36

7 2. Region Syddanmarks It-projektmodel 2.1 It-projektmodellen I dette kapitel gives en overordnet introduktion til RSD It-projektmodellen. It-projektmodellen er beregnet til anvendelse på alle it-baserede projekter i RSD. Det er imidlertid vigtigt at vurdere det enkelte projekts styringsbehov og tilpasse anvendelsen af modellen i forhold hertil. Se Appendiks 1 og evt. PRINCE2-manualen og afsnittet Tilpasning af PRINCE2 til projektmiljøet. Modellen omfatter overordnet set: En model for opdeling af projektforløbet i fem projekttrin med underliggende faser Principper for overgang fra ét projekttrin til det næste samt overgang fra én fase til den næste Et antal projektstyringsdokumenter og -værktøjer. Modellen er udarbejdet på grundlag af PRINCE2. Videreudvikling af It-projektmodellen varetages af PMO-teamet i Regional IT, og godkendes af Udvalg for Sundheds-it. Det er altid muligt at kontakte PMO-teamet for introduktion til It-projektmodellen eller rådgivning i brugen af modellen og det tilhørende sæt af projektstyringsdokumenter, -værktøjer og -processer. Projektstyringsdokumenter, værktøjer og vejledninger er tilgængelige på intranettet De fem projekttrin RSD It-projektmodellen opdeler projektforløbet i fem overordnede projekttrin med tilhørende beslutningspunkter. I hvert projekttrin udarbejdes projektstyringsdokumenter, som støtter styringen af projektet hen imod projektets samlede leverance. De fem projekttrin Idé: Ideen dokumenteres i form af et projektforslag, der omfatter et foreløbigt overslag, samt forslag til indhold og ressourcebehov for gennemførelse af analysetrinnet. Beslutningspunktet inden overgang til næste projekttrin kræver Udvalg for Sundhedsit s/direktionens 5 godkendelse af Projektforslaget. Analyse: Fokus i projekttrinnet er på, hvad projektet skal dække. Projektet defineres og beskrives i projektstyringsdokumentet Projektbeskrivelse med tilhørende business case. Beslutningspunktet er godkendelse af projektbeskrivelsen (Udvalg for Sundhedsit/direktion). 5 Udvalg for Sundheds-it godkender regionale projekter direktionen for den enkelte enhed godkender lokale projekter. Side 6 af 36

8 Anskaffelse: Fokus i projekttrinnet er på, hvordan behovene skal dækkes. Specificering af krav og behov samt gennemførelse af anskaffelsesprocessen som typisk er via udbud. Beslutningspunktet kan omfatte godkendelse af en revideret projektbeskrivelse. Projektinitieringsdokumentet (PID) udarbejdes også senest i denne trin og godkendes af styregruppen. Gennemførelse: Ved overgangen til gennemførelsestrinnet betegnes projektet som igangværende projekt. Kontrakter underskrives, og projektets leverancer realiseres. Projekttrinnet løber frem til, at alle leverancer er leveret og evt. udestående er overleveret. Beslutningspunktet inden overgang til realiseringstrinnet omfatter godkendelse af projektafslutningsrapport og evt. anbefaling af opfølgningsaktiviteter. Derudover opdateres PID og business case. Gevinstrealisering: Gevinstrealiseringsplanen overdrages til sygehuse/stabene i RSD. Forretningsudbytte og gevinster hjemtages i henhold til projektets gevinstrealiseringsplan. Alle it-projekter opdeles i udgangspunktet i disse fem projekttrin. Projekttrinnene Idé og Gevinstrealisering drives primært af sygehuse/stabene i RSD, hvilket er vist i figuren med den grønne farve på projekttrinnene. De mellemliggende projekttrin drives af projektet, dvs. af projektlederen og styregruppen. For at sikre beslutningspunkter og styregruppens stillingtagen til kritiske milepæle i projektet, må projekttrinnene ikke overlappe hinanden Opdeling i faser Hvis et projekttrin strækker sig over lang tid eller indeholder store, komplekse og/eller omkostningstunge aktiviteter, bør trinnet opdeles i flere underliggende faser. For det enkelte projekt skal projektstyregruppen tage stilling til, om der er foretaget en tilstrækkelig og hensigtsmæssig faseinddeling, der danner grundlaget for den nødvendige styring. Faseopdelingen i det enkelte projekt dokumenteres i PID en med tilhørende projektplan. Et projekts faser fastlægges ved projektets start. Faseopdelingen kan tage udgangspunkt i flere forhold eksempelvis: Et skift i projektets karakter: Fx mellem udvikling og test Udstrækning i tid: En fase bør ikke have en udstrækning på mere end 3-6 måneder Organisatoriske: Implementering i forskellige dele af organisationen Ledelsesmæssige: Ønske/krav om en tidsmæssig placering af en milepæl. Udover de godkendte projektstyringsdokumenter skal projektlederen overfor styregruppen dokumentere aktiviteterne i den forgangne fase i en faseafslutningsrapport, præsentere en faseplan og leveranceoversigt (indgår i PID og projektbeskrivelse) for den kommende fase, samt give et opdateret indblik i projektets samlede økonomi og herunder eventuelt opdatere projektets business case Beslutningspunkter og hovedmilepæle Et beslutningspunkt eller en hovedmilepæl markerer et skift i projektets tilstand. Beslutningspunktet markerer overgangen fra ét af de fem overordnede projekttrin til det næste trin og kræver Side 7 af 36

9 godkendelse i henhold til it-beslutningsstrukturen af Udvalg for Sundheds-it/direktion. I flere tilfælde kan styregruppen godkende beslutninger eller milepæle men scope, økonomi, projektovergange skal altid besluttes i Udvalg for Sundheds-it/direktion, med mindre andet er aftalt. I projektbeskrivelsen angives det, inden for hvilke rammer/tolerancer styregruppen kan agere inden for projekttrinnene. En hovedmilepæl markerer overgang fra et projekttrins underliggende fase til den næste fase. Milepælen godkendes af projektstyregruppen undtagelsesvist også af relevant beslutningsorgan f.eks. Udvalg for Sundheds-it, hvis der er tale om væsentlige ændringer af omkostninger, tidsplan eller indhold. Sammenhængen mellem beslutningspunkter, projekttrin, hovedmilepæle og faser samt ansvarsfordelingen i projektet er beskrevet i Kapitel Projekttrinnene For hvert projekttrin skitseres efterfølgende grundlaget for påbegyndelse af trinnet samt kriterier for overgang til næste projekttrin. BEMÆRK! Det er den fulde It-projektmodel, der beskrives her. For evt. skalering, se Appendiks Idé Projekttrinnet idé er det første af fem projekttrin i et projektforløb. Formålet er at undersøge, om ideen er bæredygtig. Ledelsen tager stilling til, om der skal bruges ressourcer på at gå videre til analysen og danne projektorganisationen. Ejerskabet for idétrinnet ligger hos sygehusene/stabene i RSD det er her behovet, og efterfølgende ideen, til projektet opstår. Kriterier for at starte projekttrinnet Ingen formelle kriterier Kriterier for at afslutte projekttrinnet Projektforslag Projektejer/styregruppeformand udpeget. Idétrinnet gennemføres således, før projektet formelt er etableret. Det påbegyndes typisk på baggrund af en forventning om enten at kunne effektivisere arbejdsgange, styrke kvaliteten af en service eller fordi der er stillet krav om implementering af ny lovgivning eller imødekommelse af pejlemærker. I idétrinnet gennemføres en første analyse af, om ideen kan resultere i et bæredygtigt it-projekt. Det undersøges, hvilket forretningsudbytte der forventes, og der laves et overslag over projektets Side 8 af 36

10 omkostninger. Endelig redegøres der for påkrævede ressourcer til at analysere idéen nærmere i det efterfølgende analysetrin. Resultatet beskrives i et projektforslag, som er ledelsens grundlag for at beslutte, om projektet kan gå videre til analysetrinnet. Det er vigtigt for et succesfuldt idétrin at få It-projektmodellen skaleret til det, der giver værdi for projektet. Obligatoriske projektstyringsdokumenter I idétrinnet er projektforslaget det eneste forventede projektstyringsdokument. Projektforslag: Projektforslaget skal sikre, at sygehusene/stabene i RSD får et tilstrækkeligt grundlag til at vurdere, om der skal anvendes ressourcer til en videre analyse af projektets berettigelse. Dokumentet skitserer kort de overordnede rammer for det kommende projekt samt forventninger til projektets konsekvenser, omkostninger, ressourceforbrug og forretningsudbytte. Ansvaret for udarbejdelse af projektforslaget ligger hos sygehusene/stabene og udarbejdes i idétrinnet Analyse Formålet med projekttrinnet Analyse er at fastlægge indhold og fordelagtigheder. På denne baggrund beslutter styregruppen og eventuelt Udvalg for Sundheds-it/direktion, om der skal fortsættes til anskaffelsestrinnet. Kriterier for at starte trinnet Projektforslag godkendt Projektleder udpeget Kriterier for at slutte trinnet Projektbeskrivelse godkendt Projektorganisation sammensat Analysetrinnet bygger videre på projektforslaget og evt. udkast til business case. Der foretages her en grundig og detaljeret analyse af projektets omfang, forretningsudbytte, leverancer, kravene til ressourcer, udgifter, tidsplan, risici, informationssikkerhed, kvalitet etc. Resultaterne af arbejdet samles i projektbeskrivelsen, der er det samlede grundlag for den forretningsmæssige vurdering af projektet. Udarbejdelse af PID påbegyndes også i dette trin. Projektlederen udpeges senest i starten af analysetrinnet. Projektlederen har i samarbejde med styregruppeformanden ansvar for at skalere RSD It-projektmodellen (så den passer til projektet), Side 9 af 36

11 for at etablere projektorganisationen, gennemføre analyser og samle alle de bidrag, der er nødvendige for at skabe styringsgrundlaget for et vellykket projekt. For at opnå et succesfuldt projekt er det vigtigt at få ledelsesmæssig opbakning til Ændringer i organisation, roller og opgavefordeling Ændringer i forretningsprocesser Ændringer i ressourceanvendelse Afgrænsninger og forudsætninger Risikovurdering (ud fra risikovurdering og -analyse) Obligatoriske projektstyringsdokumenter I Analysetrinnet skal der som minimum udarbejdes en projektbeskrivelse. Projektbeskrivelse: Projektbeskrivelsen er grundlaget for den endelige forretningsmæssige vurdering af projektet. Projektbeskrivelsen redegør for de samlede økonomiske og ikke-økonomiske konsekvenser af de potentielle omkostninger ved projektet. Projektbeskrivelsen skal godkendes i rette beslutningsorgan Udvalg for Sundheds-it/direktion. Projektbeskrivelsen er derfor et meget vigtigt beslutningsgrundlag. Det skal løbende kontrolleres, at projektets forudsætninger og vilkår, som angivet i projektbeskrivelsen, overholdes. Mulige projektstyringsdokumenter I analysetrinnet vil følgende projektstyringsdokumenter kunne tages i anvendelse: Business case: Regneark med beskrivelse af projektets nøgletal, herunder udgifter og gevinster. Emnelog: Emneloggen anvendes til at dokumentere og sikre opfølgning på emner i et projekt. Den kan omfatte observerede fejl og mangler, mulige problemer, temaer til drøftelse etc. Gevinstrealiseringsplan: Gevinstrealiseringsplanen er et styringsdokument, der sikrer, at det er klart beskrevet og besluttet, hvordan og hvornår der følges op på, om projektets gevinster realiseres i praksis. Interessentanalyse: Regneark med opgørelse af projektets væsentligste interessenter og deres eventuelle involvering i projektet. Interessentanalysen indeholder også et interessentkort til visuel fremstilling af interessenterne. Kommunikationsstrategi: Kommunikationsstrategien sikrer, at der foretages nogle systematiske og overordnede overvejelser om, hvordan det bedst muligt sikres, at kommunikationen i projektet understøtter intentionerne. Styringsdokumentet kommunikationsstrategi omfatter både en overordnet strategi for projektets kommunikation samt en mere detaljeret kommunikationsplan for de kommunikationsaktiviteter, der skal gennemføres. Side 10 af 36

12 Udarbejdelse af interessentanalyse og risikovurdering er forudsætninger for kommunikationsstrategien. PID: PID (projektinitieringsdokument) er opbygget med samme hovedindhold som projektbeskrivelsen. Formålet med PID er at foretage en yderligere detaljering af indholdet fra projektbeskrivelsen og tilføre yderligere elementer i form af f.eks. projektplan, så der bliver skabt et operationelt grundlag for at gennemføre projektet. I de afsnit i PID en, hvor der ikke er sket en yderligere detaljering i forhold til projektbeskrivelsen, kan der kopieres fra denne. PID en skal være godkendt inden projektet overgår til gennemførelsestrinnet. PID skal ikke anvendes af alle projekter på dette trin. PID en kan godkendes af styregruppen og/eller lokal ledelse på et sygehus/i en stab. Projektorganisation: En beskrivelse af, hvordan det konkrete projekt er organiseret og hvordan roller og ansvar i projektet er fordelt. Projektplan: Projektplanen er et centralt styringsdokument, der altid udarbejdes. Projektplanen omfatter produktbeskrivelser, tids- og aktivitetsplan, milepæle, ressourceforbrug mv. Risikovurdering og -log: Vejledning og regneark til analyse og registrering af risici og imødegående handlinger mv. Loggen indeholder også en opsummeret liste til anvendelse på eksempelvis styregruppemøder. Tjekliste vedr. informationssikkerhed: Dynamisk dokument, hvori det dokumenteres, hvordan aspekter ift. informationssikkerhed er håndteret i projektet i takt med, at projektet bevæger sig igennem de forskellige trin i Itprojektmodellen. Se også Appendiks 3. Vejledning om informationssikkerhed Anskaffelsestrinnet I dette trin fastlægges behov og krav til det nye it-system, og der gennemføres anskaffelse frem til det tidspunkt, hvor kontrakten er klar til underskrift. Projekter, der ikke medfører behov for et anskaffelsestrin, springer dette trin over. Kriterier for at starte trinnet Projektbeskrivelse Kriterier for at slutte trinnet Eventuelt opdateret projektbeskrivelse godkendt PID og business case godkendt Side 11 af 36

13 Kravspecifikation og evt. udbud Evt. kontrakt klar til underskrift Arbejdet omfatter forberedelse og gennemførelse af eventuelt udbud. Ved udbudsprojekter kan anskaffelsestrinnet med fordel inddeles i to faser, specificering og udbud. Under forberedelsen vælges udbudsstrategi og udbudsform, og behovene specificeres i en kravspecifikation. Under gennemførelsen af udbuddet gøres udbudsmaterialet færdigt, udbuddet offentliggøres og indkomne tilbud vurderes således, at kontrakten med den valgte leverandør kan underskrives så snart styregruppen og evt. relevante beslutningsorganer, f.eks. Udvalg for Sundheds-it, godkender overgang til gennemførelsestrinnet. Såfremt anskaffelsen indebærer en anlægsbevilling fra Regionsrådet, indhentes denne, inden gennemførelsestrinnet. Kontakt evt. PMO-teamet for spørgsmål til dette. Det er vigtigt for et succesfuldt anskaffelsestrin at få revideret projektbeskrivelsen/business casen og få bevilling hertil Gennemførelsestrinnet Det første skridt i dette trin er at underskrive kontrakten med leverandøren. Når kontrakten er underskrevet og evt. afklaringsfase er gennemført, starter samarbejdet med leverandøren. Kriterier for at starte trinnet Projektbeskrivelse endeligt godkendt PID og business case opdateret Evt. anlægsbevilling opnået. Kriterier for at slutte trinnet Projektafslutningsrapport PID og business case opdateret Serviceintroduktion Gennemførelsestrinnet er det trin, der typisk varer længst tid og kræver mest af projektlederen. Dette projekttrin kan derfor med fordel opdeles i faser. Efter et udviklingsforløb i gennemførelsestrinnet er leverandørens beståelse af endelig overtagelsesprøve en vigtig milepæl. Inden idriftsættelse er det også essentielt at verificere, at løsningen opfylder kravene til informationssikkerhed. Herefter kommer idriftsættelse med udrulning af systemet til brugerne, brugeruddannelse og projektevaluering. Væsentlige aktiviteter i den forbindelse er serviceintroduktion af løsningen og overdragelse til drift/forvaltning. Omkostninger til disse aktiviteter henføres stadig til projektet, men når overdragelsen er sket, afholdes videre omkostninger af driftsbudgetterne. Ofte kan der også påbegyndes realisering af gevinster i gennemførelsestrinnet i henhold til gevinstrealiseringsplanen. Side 12 af 36

14 Projektafslutningen omfatter: Der er udarbejdet en projektafslutningsrapport Alle projektaktiviteter er udført, alle leverancer er godkendt eller overdraget Projektorganisationen opløses Projektafslutning markerer altid overgangen mellem gennemførelsestrinnet og realiseringstrinnet. Det er vigtigt for et succesfuldt gennemførelsestrin at få etableret en god projektplan, hvor hovedmilepæle er nedbrudt i produktbeskrivelser, leverancer og arbejdspakker. Obligatoriske projektstyringsdokumenter I gennemførelsestrinnet introduceres følgende obligatoriske projektstyringsdokument. Projektafslutningsrapport: Projektafslutningsrapporten skal sikre, at der sker en rapportering af, hvordan projektet er gennemført målt på økonomi og projektleverancer. Rapporten skal også dokumentere, hvor godt projektet er blevet styret og hvilke observationer og erfaringer, der er gjort undervejs i projektforløbet, som har haft betydning for projektstyringen. Eventuelle opfølgningsaktiviteter på projektarbejdet anføres i rapporten. Rapporten udgør styregruppens grundlag for at beslutte, om projektet kan afsluttes. Styregruppen indstiller projektafslutningsrapporten til godkendelse i det tilknyttede ledelsesmæssige beslutningsorgan f.eks. Udvalg for Sundheds-it Gevinstrealisering I dette trin realiseres de gevinster, der er beskrevet i projektbeskrivelsen/pid og business case. Realiseringstrinnet ejes af sygehusene/stabene i RSD, ligesom idétrinnet. Det er sygehusene/stabene i RSDs opgave at forankre it-systemet i organisationen og høste gevinsterne. Kriterier for at starte trinnet Projektafslutningsrapport Opdateret gevinstrealiseringsplan Kriterier for at slutte trinnet Gevinstrealiseringsrapporten Side 13 af 36

15 Til at følge op på gevinstrealisering anvendes gevinstrealiseringsrapporten, der dokumenterer, om gevinstrealisering har fundet sted som planlagt. Gevinstmålinger skal typisk fortsættes ud over det første år efter projektafslutning, da en del af gevinsterne ofte først realiseres senere. I realiseringstrinnet vil der ikke være projektrelaterede udgifter, så derfor skal udgifter henføres til driften i projektbeskrivelsen. Det er vigtigt for et succesfuldt gevinstrealiseringstrin, at projektet får sikret ejerskab af en (opdateret) gevinstrealiseringsplan. Side 14 af 36

16 2.3 Oversigt over projektstyringsdokumenter 6 Projekttrin* Idé Analyse Anskaffelse Gennemførelse Gevinstrealisering Målgruppe** Projektstyringsdokument Afvigelsesrapport X S Arbejdspakke X X P Business case regneark X X X S Emnelog X X X S,P Erfaringslog X X X P Faseafslutningsrapport X S Faseplan X S Gevinstrealiseringsplan X X X X B,S Interessentanalyse X X X S Kommunikationsstrategi og -plan X X X S Produktbeskrivelse X X X S Produktnedbrydningsdiagram X X X S,P (PND) og Produktflowdiagram Projektafslutningsrapport X B,S Projektforslag X B,S Projektbeskrivelse X X B,S Projektinitieringsdokument (PID) (X) X X S Projektorganisation X X X B,S Projektplan X X X S Risikolog X X X S,P Slutproduktbeskrivelse X X X S Testdesign herunder test cases X X P Testplan (X) X X S Testrapport X S Teststrategi (X) X X S Ændringsønske X S Hjælpedokumenter Kompleksitetsskema for projekter X X X X P Risikovurdering (X) X X X P Statusrapport X X X S Standard styregruppeslides X X X S Tjekliste vedr. informationssikkerhed Tjekliste til vurdering af telemedicin * X angiver, på hvilket projekttrin dokumentet udarbejdes/anvendes. ** B = Beslutningsorgan, S = Styregruppe, P = Projekt (X) X X X S,P (X) (X) S De farvemarkerede dokumenter er obligatoriske og med undtagelse af projektafslutningsrapporten skal de senest foreligge godkendt, inden Gennemførelsestrinnet igangsættes. Disse dokumenter udgør tilsammen baseline for projektet. 6 Oversigten forholder sig til projektstyringsdokumenter i relation til den fulde It-projektmodel. For evt. skalering, se Appendiks 1. Side 15 af 36

17 Alle projektstyringsdokumenterne kan benyttes i projektet - men skalering/omfanget af projektet afgør, hvorvidt det er relevant, at alle dokumenter benyttes. PMO-teamet i Regional IT udarbejder projektstyringsdokumenterne og -værktøjerne, der understøtter dette arbejde. De kan hentes på regionens intranet under IT/Projekter og ydelser. Oversigten viser også, hvem der er målgruppe for de enkelte projektstyringsdokumenter. Det er vigtigt, at man holder dette for øje i udarbejdelsen, da det ikke kan forventes at et beslutningsorgan (eksempelvis Udvalg for Sundheds-it) vil kunne forholde sig til meget projektnære og tekniske problemstillinger, men vil forholde sig til de overordnede linjer i form af forretningsudbytte og sammenhæng til strategien. 3. Organisering af projekter Dette kapitel beskriver, hvordan it-projekter i Region Syddanmark skal organiseres, herunder de centrale roller i projektorganisationen og deres ansvar og opgaver. Dokumentet indgår som en del af den samlede projektmodel for regionens it-projekter. 3.1 Projektorganiseringens principper Projektmodellen indeholder en organisationsstruktur, der definerer roller og ansvar for hvert medlem af en projektorganisation. Det er af afgørende betydning, at projektorganisationen bemandes i forhold til projektets behov. Nedenstående gælder derfor for alle it-projekter. It-projektmodellen skal sikre, at projektets organisation er på plads fra projektets start, så roller og deres ansvar i ledelsen af projektet er aftalte og synlige. Projektledelsen består af styregruppen, projektlederen og eventuelle teamledere. Dette skal sikre en aktiv og effektiv involvering af beslutningstagere fra projektets start. Forslag til styregruppeformand og styregruppe forelægges for Udvalg for Sundheds-it/direktion som en del af projektforslaget for det enkelte it-projekt. Projektlederen udpeges af styregruppeformand eller systemejer. Beslutningsstrukturen/projektorganiseringen er således: Side 16 af 36

18 3.1.1 De tre projektinteresser Projektmodellen kræver repræsentation af tre centrale interesser, når der skal træffes væsentlige beslutninger i projektet: 1. En forretningsmæssig interesse til at sikre, at projektet leverer værdi til organisationen 2. En brugerinteresse til at sikre, at projektleverancer er konstrueret i overensstemmelse med de forretningsmæssige behov, og at de vil gøre det muligt for organisationen at realisere udbytter 3. En leverandørinteresse til at sikre, at de krævede projektleverancer kan realiseres 3.2 Projektorganiseringens roller og deres ansvar Styregruppen Styregruppen er ansvarlig for levering af det ønskede produkt eller resultat til Organisationen. Som hovedprincip gælder at styregruppen holdes så lille som muligt. Styregruppens opgave er at understøtte realiseringen af projektets mål ikke at være parlament for varetagelse af særinteresser. Styregruppen kan i nogle tilfælde have behov for at konsultere bredere interesser i projektet for at sikre sig korrekt information, opbakning eller andet. I så tilfælde kan det være en ide at etablere en referencegruppe enten ad hoc eller mere permanent. Styregruppen overvåger projektets fremdrift og træffer beslutninger på centrale steder og kontrollerer på den måde projektet. Side 17 af 36

19 Styregruppen fastsætter tolerancer for hver fase i projektet, sikrer prioritering af ændringsønsker og afvigelser fra specifikationer. Det er også styregruppen, der sikrer at projektet realiseres indenfor rammerne godkendt af beslutningsorganet, f.eks. Udvalg for Sundheds-IT. Styregruppen forestår afvigelsesstyring og sikrer, at projektet forbliver levedygtigt og overholder fastsatte begrænsninger. Dette sker også ved at sikre, at risici og emner bliver behandlet eller eskaleret. Det er styregruppens ansvar at godkende: Afvigelsesplaner (når tolerancer på faseniveau forventes overskredet) Business case Faseplaner Faser og deres produktbeskrivelser Færdige produkter Leverandørkontrakten (hvis kunde/leverandørforholdet er kommercielt) PID Projektbeskrivelse Projektafslutningsrapporten, inklusive sikring af overdragelse af udestående aktiviteter, herunder risici, emner og gevinstrealisering Ændringer. De tre projektinteresser beskrevet ovenfor er afspejlet i styregruppens tre roller Styregruppeformand. Styregruppeformanden udpeges af systemejer og præsenteres normalt i forbindelse med fremlæggelse af projektforslaget. Styregruppeformanden er projektejer og er ultimativt ansvarlig for projektet. Styregruppeformanden ejer således business casen og projektbeskrivelse/pid. Styregruppeformanden skal derfor både have bemyndigelse fra det relevante beslutningsorgan i RSD til at træffe beslutninger og faglig indsigt til at vurdere projektets status. Styregruppeformanden skal også sikre, at styregruppens øvrige medlemmer bidrager til projektet indenfor deres områder, ligesom styregruppeformanden sikrer udpegning af projektleder, samt at der er en tilstrækkelig kompetencesammensætning i projektgruppen. Seniorbruger Seniorbrugeren er ansvarlig for at sikre, at brugernes behov angives korrekt, og at løsningen opfylder disse behov inden for den aftalte kvalitet. Dermed er seniorbrugeren også ansvarlig for at projektet i sidste ende giver den lovede værdi til brugerne, via it-understøttelse, implementering og gevinstrealisering. Seniorbrugeren kan eventuelt i større og mere komplekse projekter vælge at danne en eller flere reference- eller brugergruppe(r), som kan konsulteres efter behov. Rollen kan fordeles på flere personer, hvis det er nødvendigt. Side 18 af 36

20 Seniorleverandør Seniorleverandøren er den overordnet ansvarlige i styregruppen for, at projektets it-leverancer bliver leveret via interne ressourcer eller via eksternt køb, dvs. ansvaret it-indkøb og itleverandørstyring. Seniorleverandøren er også ansvarlig for kvalitetssikringsprocessen i projektet samt den tekniske kvalitet. Seniorleverandøren leverer viden og erfaring fra de(t) vigtigste fagområde(r), der er engageret i fremstillingen af projektets leverancer. Seniorleverandøren repræsenterer leverandørinteresser inden for projektet og leverer leverandørressourcerne. Rollen kan fordeles på flere personer, hvis det er nødvendigt. Regional IT (ansvarlige for arkitektur og/eller drift) kan indgå som seniorleverandør, ligesom en ekstern leverandør kan indgå i styregruppen som seniorleverandør. Dette kan dog give anledning til, at styregruppemøderne styres på en sådan måde, at den eksterne seniorleverandør kun deltager i en del af dagsordenen Projektlederen Projektlederen repræsenterer sygehuse/stabene i RSD. Projektlederen udpeges af styregruppeformanden (systemejer, hvis der ikke er en udpeget styregruppeformand endnu) og sædvanligvis i forbindelse med fremlæggelsen af projektforslaget. Projektlederen udfærdiger projektets styringsdokumenter (sammen med projektorganisationen) og har ansvar for at opnå styregruppens godkendelse i henhold til It-projektmodellen. Derudover sikrer projektlederen, at projektet følger de rammer, som er aftalt i styringsdokumenterne, og eskalerer eventuelle behov for justeringer eller ændringer til styregruppen. Projektlederen skal også styre fremstillingen af de krævede produkter, tage ansvar for den overordnede fremdrift og anvendelse af ressourcer samt igangsætte korrigerende aktiviteter, når det påkræves. Projektlederen leder og motiverer projektorganisationen, sikrer at der aftales forventninger til projektdeltagernes indsats og har kontakt med eksterne leverandører og kundeansvarlige. Projektlederen har kontakt med virksomheds- eller programledelsen og sikrer afhængigheder til relaterede projekter, herunder at opgaver ikke udføres dobbelt. Derudover styrer projektlederen informationsflowet mellem styregruppen og projektdeltagerne. Projektlederen skal også orientere styregruppen om mulige afvigelser fra planer. Det er endvidere projektlederens ansvar, at: Etablere og kontrollere, at projektets procedurer for risiko-, emne-, ændrings-, konfigurations- og kommunikationsstyring følges Udstede arbejdspakker Udføre teamlederrollen (medmindre den er tildelt andre) Udføre projektsupportrollen (medmindre den er tildelt andre) Side 19 af 36

21 3.2.3 Teamledere Betegnelsen teamleder anvendes i denne sammenhæng om den rolle, som styrer leverancen af en delleverance. Teamledere vil ofte være ansatte hos leverandøren, men et projekt kan også indeholde delleverancer, hvor det er regionens egne medarbejdere, der skal levere et produkt Referencegruppe I it-projekter i RSD etableres der ofte en referencegruppe (jf. RSD It-projektmodellen er det dog ikke et krav, at en sådan referencegruppe etableres). En referencegruppe kan understøtte/supplere seniorbruger-rollen i styregruppen og kan konsulteres efter behov, fx ift.: Rådgivning omkring nødvendige operationelle beslutninger på væsentlige faglige/kliniske områder Vurdering af afdelingernes behov i forhold til løsningsmuligheder og øvrige projektbehov referencegruppen kan også bidrage til at identificere muligheder og udfordre projektet. Referencegruppen fungerer også som projektets ambassadører i organisationen og der må stilles forventning til, at de optræder loyalt over for beslutninger i projektet, når de agerer i eget bagland. Det er vigtigt, at referencegruppen har en bred (regional) forankring samt tilstrækkelig faglig/klinisk beslutningskompetence ift. til det relevante felt Øvrige projektroller De øvrige projektdeltagere bidrager med forskellige projektfærdigheder, forretningsmæssige færdigheder eller tekniske færdigheder. PMO-teamet i Regional IT kan rådgive omkring bemanding af det konkrete projekt. 3.3 Projektorganisering i praksis Den distribuerede organisering af sundheds-it området 7, hvor ansvar og systemejerskab for de enkelte applikationer er fordelt mellem sygehusene, medfører, at projekter ofte organiseres med et overordnet projekt på det systemejende sygehus og under-projekter på deltagende sygehuse. Under-projekter kan enten organiseres som rene projekter (med egen styring), som arbejdspakker i det overordnede projekt eller en kombination heraf. 7 Læs mere om dette på regionens intranet under Systemejerskab for sundheds it-systemer Side 20 af 36

22 Tegningen viser, hvordan et overordnet projekt enten organiseres med under-projekter (grøn), arbejdspakker (grå) eller en kombination. Tegningen tager udgangspunkt i et RSD-projekt (cirklen i midten). Øverst til venstre er vist en model med udelukkende arbejdspakker under projektet. Øverst til højre er der udelukkende anvendt underprojekter. Nederst er vist en kombination af arbejdspakker og underprojekter. PMO-teamet i Regional IT kan vejlede om, hvordan det enkelte projekt kan organiseres. Side 21 af 36

23 3.4. Overblik over beslutningspunkter It-beslutningsstruktur Sammenhængen mellem It-projektmodellen og projektets organisering i forhold til styregruppe og højere oppe i organisationen er illustreret i nedenstående model. I modellen kan man få et overblik over projekttrin, sammenhængen til forelæggelser for styregruppe mv. og overgangskriterierne. Modellen viser desuden, hvornår projektstyringsdokumenterne finder anvendelse. Modellen kan fås i en udgave (se intranettet), der er egnet til print i større størrelse. Blå firkanter repræsenterer obligatoriske forelæggelser for det relevante beslutningsorgan (evt. Udvalg for Sundheds-it) ved opstart og afslutning af projektet. Lyseblå firkanter er forelæggelser til beslutningsorganet, der kan foretages efter behov. Røde firkanter er forelæggelser for styregruppen. De er obligatoriske mellem hvert projekttrin. Hvis gennemførelsestrinnet er opdelt i faser, skal der også forelægges for styregruppen efter hver fase. Ide- og gevinstrealiseringstrinnene er farvet grønne, da de er forankrede i sygehusene/stabene, mens de øvrige trin varetages af projektorganisationen. Obligatoriske projektstyringsdokumenter er fremhævet med fed. Side 22 af 36

24 4. Rapportering af regionale projekter 4.1 Formålet med statusrapportering Formålet med projektstatusrapporteringen (PSR) er at holde Udvalg for Sundheds-it orienteret om udviklingen i den portefølje af it-projekter, de har porteføljeansvaret for. PSR bliver efterfølgende sendt til regionens direktion og offentliggjort på RSD s intranet. PSR er hermed den status, der synliggøres uden for projektets egne rammer for alle, der måtte have interesse for projektet. 4.2 Proces for rapportering Projektlederen har ansvaret for udarbejdelse af rapporten i Leverancesystemet. Det er vigtigt, at indholdet er afstemt med styregruppeformanden for projektet. Undgå tekniske udtryk, forkortelser og indforståethed, da mange modtagere ikke har indsigt i projektet. Der skal rapporteres ud fra den, af Udvalg for Sundheds-it, senest godkendte baseline for tid, scope og økonomi. Ved ændring af baseline skal den, efter godkendelse i styregruppen, godkendes i Udvalg for Sundheds-it. Dvs. et projekt i rød kan først rapporteres grøn efter godkendelse af ny baseline her (se definition af farvemarkering nedenfor). Farvemarkering Gul anvendes ved projekter med afvigelser, hvor det skønnes, at en skærpet indsats, projekt- og ledelsesmæssigt, kan holde projektet inden for de samlede rammer for projektet. Et projekt skal rapporteres gul ved afvigelser i godkendte milepæle. Rød anvendes ved projekter med afvigelser, der ikke kan holdes inden for de samlede rammer for projektet. Projektet vil herefter være i rød indtil Udvalg for Sundheds-it har godkendt nye rammer i form af opdateret projektbeskrivelse. Tidsfristen følger deadlines for indsendelse af materiale til Udvalg for Sundheds-it. Er projektet i rød, kan projektet blive kontaktet umiddelbart før mødet for at høre, om der er sket afgørende ændringer siden rapporteringen Kvalitetssikring PMO-teamet i Regional IT er tildelt rollen at kvalitetssikre og samle alle PSR, inden de udsendes. Ved kvalitetssikringen er der fokus på, om projektets status fremstår tydeligt og er i overensstemmelse med godkendt baseline og Sundheds-it s øvrige indsigt i projektet. Især hvis generel status er gul eller rød, vil kvalitetssikringen ske i dialog med projektlederen, der kan blive bedt om at komme med korrektioner. Side 23 af 36

25 4.2.2 Behandling i Udvalg for Sundheds-it På dagsorden for Udvalg for Sundheds-it er en gennemgang af projektstatus fra områderne Syddansk Sundhedsinnovation og Regional IT. Fokus er rettet mod projekter med status i gul eller rød. Normalt bliver direktøren for den projektansvarlige enhed bedt om at redegøre for, om projektet er på rette kurs. Derfor er det vigtigt, at direktøren er orienteret, hvis der er problemer i projektet. Når dagsordenen for Udvalg for Sundheds-it tillader det, er der en mere dybdegående gennemgang af alle projekter. I rapporteringen skal beskrivelse af afvigelser og korrigerende handling kun udfyldes for projekter i gul eller rød status. Her skal de til gengæld altid være udfyldt. Det er vigtigt ved beskrivelse af afvigelse, at det fremgår, hvilke konsekvenser afvigelsen har for projektets økonomi, scope eller tid, hvorimod årsagen er mindre interessant. Der er ligeledes fokus på, om projektet har forholdt sig til situationen og iværksat korrigerende handlinger, hvis der f.eks. er uopsættelige deadlines. Er redegørelsen for situationen ikke tilstrækkelig, vil Udvalg for Sundheds-it ofte bede projektet komme med en udvidet status på det kommende møde. Beslutninger og væsentlige kommentarer vil fremgå af referaterne fra møderne i Udvalg for Sundheds-it (kan tilgås via regionens intranet). Er projektet bedt komme med udvidet status på det kommende møde, vil det fremgå af dagsorden-teksten til det kommende møde. Side 24 af 36

26 Appendiks 1. Vejledning til skalering af projekter Denne vejledning er tænkt som en hjælp til at få den rette skalering af RSD It-projektmodellen i forhold til det enkelte projekt. Det er vigtigt at være opmærksom på, at ikke to projekter er ens, og derfor bør der altid foretages en individuel vurdering, hvor der tages stilling til, hvad der giver værdi og vil hjælpe til en sikker gennemførelse af det enkelte projekt. For at foretage den rette skalering er det vigtigt at gøre sig klart, hvad der er særlige karakteristika ved projektet. Dette kan gøres ud fra flere synsvinkler, hvor de væsentligste er type, kompleksitet og størrelse. Typer af projekter Typen fortæller noget om ensartetheden i projektets forløb og dermed hvilke trin og faser projektet skal gennemløbe. Der vil også være store sammenfald i typiske milepæle. Typen fortæller ikke noget om størrelse og kompleksitet. RSD har grundlæggende 3 typer af projekter: 1. Regionale udviklingsprojekter der leverer til flere enheder 2. Lokale projekter 3. Lokale implementeringsprojekter A1.1 Kompleksitet Der er mange elementer, der kan gøre et projekt komplekst, men der er ikke nogen direkte sammenhæng til størrelse og type. Kompleksiteten kan ligge i projektets omgivelser, dvs. hvilke vilkår er der for projektets gennemførelse. Kompleksiteten kan også ligge i selve opgaven og forløbet. PMO-teamet i Regional IT (i Regionshuset) har udarbejdet It-projektmodellen og anbefaler alle itprojekter at tage et opstartsmøde med PMO ved etablering af nyt projekt. Her drøftes det, hvordan projektmodellen med fordel kan tilpasses samt hvilke styringsdokumenter, der bør anvendes for det pågældende projekt. Anvend Kompleksitetsskema for projekter som værktøj til at score projektets kompleksitet allerede i Idétrinnet. En sådan scoring kan give et godt indblik i, hvor fokus skal ligge i projektet og hvilke kompetencer, projektet skal bemandes med. Den samlede score af kompleksitet for projektet er en væsentlig indikator for, hvor stor ledelsesindsats, der skal påregnes til at gennemføre projektet. Eksempelvis regner Dansk Projektledelse med, at et projekt med samlet kompleksitetsscore på 3 efter IPMA- Side 25 af 36

27 kategoriseringen 8, kræver erfaring som senior projektleder for at gennemføre, dvs. minimum 60 måneders projektledererfaring, hvoraf de 36 måneder skal være med komplekse projekter. A1.1.1 Hvilke trin skal mit projekt gennemløbe? For at besvare dette spørgsmål, er det vigtigt at gøre sig klart, hvilken type af projekt, der er tale om. Regionale udviklingsprojekter Hvor der anskaffes nye applikationer eller foretages væsentlig opdatering af eksisterende applikationer. Eksempler: Nye specialesystemer fx nyt øjensystem Karakteristika: Vil normalt ske gennem udbud, med mindre det er videreudvikling inden for eksisterende kontrakt Arbejdet med at afdække og afstemme de funktionelle krav er ofte omfattende Test og godkendelse af leverancer vil fylde meget i gennemførelsen Vil normalt have en række efterfølgende lokale implementeringsprojekter Lokale projekter Hvor der lokalt foretages mindre anskaffelser eller opgraderinger af løsninger. Eksempler: Løsning til forskningsprojekter Karakteristika: Vil normalt være mindre projekter begrænset til ét sygehus Projektet vil dække hele forløbet fra analyse til implementering Den ledelsesmæssige forankring sker i den lokale direktion Lokale implementeringsprojekter Hvor applikationer anskaffet via regionale udviklingsprojekter skal implementeres på den enkelte sygehusenhed. Eksempler: Lokal implementering af ESA eller EPJ system 9 Karakteristika: 8 Baseret på skemaet Karakteristik af ledelseskompleksitet som bl.a. anvendes ifm. projektledercertificeringen IPMA. Læs mere omkring IPMA på 9 ESA = Effektiv System Adgang, EPJ = Elektronisk Patient Journal Side 26 af 36

28 Der er ofte omfattende uddannelsesaktiviteter Der skal etableres lokal forankring under opstarten med fokus på support og opfølgning Leverandøren i projektet er det regionale udviklingsprojekt A1.2 Hvilke overvejelser bør foretages ved skalering af de enkelte typer af projekter A1.2.1 Regionale udviklingsprojekter Regionale udviklingsprojekter vil ofte være foranlediget af ønsket om at it-understøtte nye forretningsbehov, et specialeområde eller efterleve et pejlemærke fra Regionernes Sundheds-it (RSI). Forretningsbehovet vil ofte ikke fremstå særlig tydelig ved starten og vil normalt ikke være afstemt mellem de enkelte interessenter, desuden vil business case i form af økonomiske og ikke økonomiske gevinster normalt ikke være kendte eller i hvert fald omgærdet med stor usikkerhed. Nærmere afklaring af ovennævnte kan være omfattende, og derfor skal projektet inden opstarten udarbejde et projektforslag, der redegør for følgende: Beskrivelse af baggrund og forretningsbehov Omfang og forhold der skal afdækkes i analysen Hvilke leverancer skal der udarbejdes i analysen Hvilke ressourcer i form af mandetimer og økonomi vil det kræve at gennemføre analysen Tidsplan for gennemførelse af analysen Formålet med projektforslaget er at få ledelsens (USIT) prioritering af projektet og dermed tilsagn om ressourcerne til at gennemføre analysen. I analysetrinnet udarbejdes der altid en projektbeskrivelse, der er det ledelsesmæssige beslutningsgrundlag for projektet. Den skal danne grundlag for opbakning til projektet og den tilhørende økonomi, ressourcebehov, tidsplan og indhold, men også de afledte påvirkninger af organisation, fremadrettet ressourcebehov og processer. Ved mindre udviklingsprojekter (DKK 0,5 2 mio.) vil det ofte være tilstrækkelig at udarbejde en projektbeskrivelse og gå direkte til anskaffelsestrinnet. Det gælder, hvor projektet allerede er prioriteret i den samlede portefølje af Sundheds-it projekter, eller hvor der ikke er tvivl om, at projektet skal gennemføres. Det er en forudsætning at indhold og økonomi i projektet er rimeligt afklaret. Det analyse-behov, der fortsat måtte udestå i projektet, planlægges ind som en første fase i anskaffelsestrinnet. Er der tale om videreudvikling af en bestående applikation, der kun kan foretages af den oprindelige leverandører, vil der ikke være udbud, og dermed kan det overvejes at gå direkte fra analyse til gennemførelse, hvor kravspecifikationen udarbejdes i analysetrinnet. Side 27 af 36