Sundheds- og Omsorgsforvaltningen MARTS Projekthåndbog. Om SUF s projektmodel

Transkript

1 MARTS 2016 Projekthåndbog Om SUF s projektmodel

2 PROJEKTHÅNDBOG 2 Indhold Indledning 4 Formål 4 Definition af et projekt 5 Processer og formkrav 5 Videreudvikling af projektmodellen 6 Fem principper for projekter i SUF 7 SUF s projektmodel 8 Fasemodellen 9 Ledelsesfaser 10 Faseovergange 10 Ledelsesdokumenter 11 Faser 12 Idéfasen 12 Analysefasen 13 Anskaffelsesfasen 14 Gennemførelsesfasen 16 Realiseringsfasen 17 Ledelsesdokumenter 18 Projektgrundlag 18 Projektinitieringsdokument (PID) 19 Business case 19 Status-/faseovergangsrapport 20 Projektafslutningsrapport 20 Afrapportering til Digitaliseringsmatrix 20 Værktøjer 21 Styringslog 21 Afvigelsesanmodning 21 Styregruppeaftale 22 Projektgovernance 24 Indledende forståelse 24 Projektgovernance 25

3 PROJEKTHÅNDBOG 3 Governacemodel 25 Projektfase 26 Ide 26 Analyse 26 Anskaffelse 26 Gennemførsel 26 Realisering 26 Projektorganisation 28 Projektorganisering i tre niveauer 28 Roller 30 Fordeling af roller i forhold til faser 33 Styregruppens arbejde 34 Styregruppens ansvar 34 Styregruppeledelse 35 Styregruppemøder 37 Projekter med budget på mere end 5 mio. kr. 39 Vurderingsgrundlaget 39 Journalisering i edoc 41

4 PROJEKTHÅNDBOG 4 Indledning I dette afsnit beskrives hvad formålet med SUF s projektmodel er, hvem håndbogen henvender sig til, og hvad der defineres som et projekt. I håndbogen er der referencer til Digitaliseringsmatrixen og Københavns kommunes Projektråd. Disse referencer er kun gældende for IT-projekter. Formål HVAD SUFS projektmodel skal sammen med denne projekthåndbog bidrage til bedre og mere ensartet samarbejde i SUF samt bedre planlægning, styring og gennemførelse af projekter. Projekthåndbogen er udarbejdet af Center for HR, Afdelingen for Digital Forandring og bygger på Den Fællesstatslige it-projektmodel med inspiration fra PRINCE2. HVEM Projekthåndbogen er rettet mod projektledere, der leder projekter i SUF. De skal orientere sig i projekthåndbogen og oplæres i projektmodellen, før SUF projekter gennemføres. Anvendelse af modellen er obligatorisk for alle SUF projekter. HVORDAN SUF s projektmodel og -håndbog skal benyttes til at understøtte det daglige arbejde med projekter. Håndbogen er en vejledning til SUF s projektmodel. Den skal ses i forhold til det enkelte projekts mål, vilkår og rammer. Det vil sige, at ikke alle projekter skal følge projektmodellen slavisk, men at projektleder i samarbejde med projektejer skal tage stilling til, i hvilket omfang den skal benyttes. Formålet med en fælles projektmodel i SUF er: Ensartethed i forhold til samarbejdet i forvaltningen Vi har vejledninger i alle vores dokumenter Vi standardiserer vores dokumenter Vi har en genkendelighed i alle vore projektdokumenter Sporbarhed og videndeling Vi journaliserer alle projektdokumenter i ESDH systemets standard En model der kan benyttes i samarbejdet på tværs af alle instanser og niveauer internt i KK og eksternt. Kan tilpasses andre forvaltningers og instansers projektmodeller Klare roller og ansvar

5 PROJEKTHÅNDBOG 5 Klarhed om egen rolle, ansvar og tilhørende mandat Projekt Et projekt er en midlertidig organisation, der etableres for at levere flere leverancer i forhold til et udviklingsønske eller realisering af en business case. Definition af et projekt Et projekt kan opfattes som en opgave, der er afgrænset i tid, kvalitet og ressourcer. Det er imidlertid ikke alle opgaver, der er projekter. For flere mindre opgaver og aktiviteter vil det være overflødigt at etablere en projektorganisation til at varetage udførelsen. En god tommelfingerregel for definition af et projekt er, at: Opgaven har karakter af at være en enkeltstående strategisk opgave med et klart defineret start- og sluttidspunkt Det er en udviklingspræget opgave Der arbejdes som regel på tværs af lokalområder, fagcentre, forvaltninger, regioner og andet Der arbejdes og koordineres på tværs af faglighed Typiske projekter i SUF kan være analyseprojekter, pilot- og afprøvningsprojekter samt projekter, der skal implementeres i driftsorganisationen. For it-projekter gælder derudover, at der kan være involveret ny teknologi, og at formålet ofte er at rationalisere og effektivisere. Formålet kan dog også være eksempelvis kvalitetsløft gennem et bedre ESDH-system, eller implementering af ny lovgivning. It-projekter i SUF skal altid opstartes i og følges af Digitaliseringsmatrixen som er det overordnede beslutningsorgan for digitale projekter i SUF. Se mere i afsnit 8, Governance. It-projekt It-projekter er investeringsprojekter, der omfatter ny teknologi, ny udvikling, væsentlig tilpasning af standard it-løsninger eller væsentlig tilpasning af allerede eksisterende it-løsninger. Eksempler på it-projekter i SUF kan være implementering af et nyt omsorgssystem, ny teknologi, der ønskes anvendt til hjælp i f.eks. hjemmeplejen, digital understøttelse af sundhedsydelser, en elektronisk borgerjournal, et logistiksystem, et journalsystem osv. Processer og formkrav Kobling til en business case Sammen med projektinitieringsdokumentet (PID en) er business casen det centrale styringsdokument i projektmodellen, og begge skal udarbejdes i analysefasen. Det vil desuden være naturligt at udarbejde et overordnet estimat for projektets business case i projektets idéfase dvs. i forbindelse med udarbejdelsen af projektgrundlaget. Se yderligere herom i afsnit 0, Business case samt vejledningen til SUFs business case på ØKF s intranetside. Københavns Kommunes It-projektråd Har et projekt budgetterede udgifter til anskaffelse og udvikling på over 5 mio. kr., og/eller er der tale om, at ny teknologi udgør et væsentligt element, skal PID og business case fra SUF s projektmodel sendes til KK It-projektrådet, som sekretariatsbetjenes af Koncern Service. Dette skal ske som et led i en risikovurdering fra It-projektrådet. Processen for risikovurderinger i It-projektrådet er beskrevet på It-projektrådets hjemmeside. Se mere om risikovurdering af it-projekter i afsnit 11.2, Vurderingsgrundlaget. Budgetproces og -udmøntning Langt de fleste projekter forudsætter selvstændige bevillinger. En bevilling kan godkendes via et budgetønske/effektiviseringsforslag i den årlige budgetaftale eller som en selvstændig indstilling om bevilling til Sundheds- og Omsorgsudvalget. Økonomisekretariatet råd-

6 PROJEKTHÅNDBOG 6 giver om processerne for budgetanmodninger til projekter og kan hjælpe med at kvalificere budgetforslag. I Københavns Kommune og hermed i Sundheds- og Omsorgsforvaltningen er der budgetudmøntning en gang årligt. Ved budgetudmøntning forstås, at budgettet på den enkelte bevilling fordeles til institutioner, enheder, kontorer etc., således at disse har et driftsbudget, og at reglerne vedrørende bevillinger og bevillingsbindinger overholdes. Midler Omplacering af budgetmidler kræver politisk godkendelse. Og anmodning om omplacering kræver derfor særlig procedure. Bevillingsomplaceringer Som følge af hensynet til den daglige drift og nye lovkrav opstår der til tider behov for at flytte budgetmidler fra en bevilling til en anden. Sådanne omplaceringer kræver politisk godkendelse i Sundheds- og Omsorgsudvalget samt Økonomiudvalget og Borgerrepræsentationen. Udarbejdelsen af anmodninger om sådanne omplaceringer følger derfor en særlig procedure. Der kan rettes henvendelse til Økonomisekretariatet vedrørende denne. Budgetudmøntningen udarbejdes i den periode, der ligger mellem vedtagelsen af kommunens samlede budget og begyndelsen af budgetåret. Budgetudmøntningen præsenteres for Sundheds- og Omsorgsudvalget inden budgetårets start. For yderligere information vedrørende budgetproces og særlige investeringspuljer, se Økonomiportalen. Budgetplanlægning og -opfølgning SUF s budgetplanlægning inkl. pris for personaleomkostninger, budgetopfølgningsproces, kvartalsopfølgning samt projektleders ansvar i projekternes økonomiopfølgning bliver i løbet af 2016 standardiseret. Beskrivelse heraf følger. I slutningen af hvert kvartal, skal projektlederen indrapportere status på forventet forbrug i projekterne til brug for aflæggelse af kvartalsregnskabet. Videreudvikling af projektmodellen Projektmodellen er udarbejdet af Center for HR, Afdeling for Digital Forandring med baggrund i SUF-praksis samt principper fra PRINCE2. Projektmodellen er udarbejdet med henblik på at understøtte de fem principper for projekter i SUF, som er beskrevet i næste afsnit, Fem principper for projekter i SUF. Videreudvikling af projektmodellen varetages af Center for HR, Afdeling for Digital Forandring og godkendes af ledergruppen under Digitaliseringschefen. SUF s projektmodel revideres årligt. Videreudvikling kan initieres på baggrund af: Anmodning fra ledergruppen under digitaliseringschefen Anmodning fra It-projektrådet Behov identificeret af projektledere, medarbejdere og ledere i SUF

7 PROJEKTHÅNDBOG 7 Fem principper for projekter i SUF De fem principper er retningsgivende for, hvordan projekter skal gennemføres i SUF. De skal være med til at reducere projekternes risikoprofil. Principperne er grundlæggende for, hvordan vi ønsker at arbejde med projekter i SUF, og projekterne skal aktivt forholde sig til principperne gennem hele projektforløbet. Principperne skal sikre, at SUF igangsætter de projekter, som giver værdi for borgere og medarbejdere samt SUF som helhed. De skal også sikre os et fundament for en bedre og hurtigere beslutningsstruktur, som styrkes ved, at vi arbejder ensartet og struktureret. Sidst men ikke mindst skal vi styrke projektfagligheden ved at tage ved lære af erfaringer og sørge for at dele viden. Figur 1: SUF s 5 principper for projekter

8 PROJEKTHÅNDBOG 8 SUF s projektmodel I dette afsnit gives en overordnet introduktion til indholdet af SUF s projektmodel. Styring SUF s it-projektmodel skal bidrage til bedre og mere ensartet planlægning, styring og gennemførelse af itprojekter i SUF. SUF s projektmodel er en generel projektmodel beregnet for anvendelse på alle SUF s projekter. Modellen omfatter overordnet set: En model for faseopdeling af projektforløbet Principper for hvordan projekter gennemføres i SUF Et antal ledelsesdokumenter og skabeloner hertil En værktøjskasse med beskrivelse af metoder til bl.a. risiko- og interessentanalyse m.v. Beskrivelser af roller og ansvar Endelig er der udarbejdet en række værktøjer og vejledninger til understøttelse af projektforløb og anvendelse af ledelsesdokumenterne. Ledelsesdokumenter, værktøjer og vejledninger er tilgængelige på intranettet - her. Figur 2: SUF s projektmodel

9 PROJEKTHÅNDBOG 9 Fasemodellen Projektmodellen indeholder en fasemodel, hvor resultatet af hver fase er produkter, som støtter styringen af projektet hen imod projektets samlede leverancer. Faseopdelingen består af hovedfaser og ledelsesfaser og understøtter princip 4 om minimering af kompleksitet og omfang. Figur 3: De 5 faser i SUF s projektmodel Model SUF s projektmodel er en generisk model for SUFs projekter. Projektmodellen indeholder fem hovedfaser: Idéfase: Ideen kvalificeres og udmøntes i et projektgrundlag Analysefase: Projektet defineres og beskrives i PID en med tilhørende business case og evt. styregruppeaftale og risikotjekliste til It-projektrådet Anskaffelsesfase: Specificering af krav og behov samt gennemførelse af anskaffelsesproces typisk via udbud Gennemførselsfase: Kontrakter underskrives, og projektets leverancer realiseres. Fasen løber frem til, systemet er idriftsat og implementeret organisatorisk Realiseringsfase: Business casen realiseres, og gevinsterne hjemtages Tilpas En af projektlederens fremmeste opgaver er at tilpasse projektmodellen til det aktuelle projekt, så brugen af den er hensigtsmæssig og giver den nødvendige styring. Alle projekter opdeles i udgangspunktet i disse fem hovedfaser. Det anbefales, at underopdele projektets hovedfaser i ledelsesfaser, hvis hovedfaserne strækker sig over lang tid (3-6 måneder), har stor kompleksitet eller indeholder store, udgiftstunge aktiviteter. Eksempelvis kan gennemførelsesfasen inddeles i flere mindre ledelsesfaser, der hver især kan have hver deres leverance(r), som skal godkendes af styregruppen. Det kan være udvikling og implementering af fase 1, udvikling og implementering af fase 2 og udvikling og implementering af fase 3. Figur 4: Eksempel på opdeling af de fem hovedfaser

10 PROJEKTHÅNDBOG 10 For det enkelte projekt skal styregruppen tage stilling til, om den konkrete tilpasning af modellen herunder projektets faseinddeling er hensigtsmæssig og giver den nødvendige styring. Den endelige anvendelse af faser for det aktuelle projekt dokumenteres i PID en. Idéfasen og realiseringsfasen drives primært af forretningen, hvilket vises ved den mørkere farve af faserne i figuren. De mellemliggende faser drives af projektet projektlederen og styregruppen. For at sikre beslutningspunkter og styregruppens stillingtagen til kritiske milepæle i projektet må hovedfaserne ikke overlappe hinanden. Se mere om de enkelte faser i afsnit 5, Faser. Hvis projektbudgettet inkl. interne lønomkostninger overstiger 5 mio. kr., og der er tale om et IT-projekt skal projektet forelægges for It-projektrådet, inden anskaffelsesfasen sættes i gang. Se mere om risikovurdering hos It-projektrådet og i afsnit 9, Projektorganisering. Overgang Styregruppen godkender grundlaget for faseovergangen, og beslutter om et projekt er klar til næste fase. Ledelsesfaser En ledelsesfase er en sammenhængende og styrbar delmængde af aktiviteter og leverancer inden for en hovedfase. Den indledes og afsluttes med en styregruppebeslutning. Formålet med en ledelsesfase er at sikre styringsgrundlaget og at opnå klare beslutningspunkter. Et projekts ledelsesfaser fastlægges ved projektets start, og de må ikke dække flere hovedfaser i SUF s projektmodel. Der kan være forskellige årsager til, at det giver mening at inddele én eller flere af modellens fem faser i flere ledelsesfaser. Eksempelvis: Et skift i projektets karakter f.eks. mellem udvikling og test i gennemførelsesfasen. Udstrækning i tid en fase bør ikke have en udstrækning på mere end 3-6 måneder, defineret som et antal sprint i en agil udviklingsmodel Organisatoriske implementering i forskellige dele af organisationen opdelt i faser Faseovergange mellem ledelsesfaser følger som nævnt ovenfor de generelle regler for faseovergange. Se mere herom i næste afsnit, Faseovergange. Faseovergange En faseovergang markerer et skift i projektets tilstand. Det gælder også for overgangen mellem to ledelsesfaser. Figur 5: Faseovergange i SUF s projektmodel Det er styregruppens ansvar at godkende grundlaget for faseovergangen og beslutte, om projektet er klar til at gå til næste fase. For at projektet kan fortsætte til næste fase, skal PID og business case foreligge i opdateret og godkendt tilstand. For overgangen mellem gennemførelsesfasen til realiseringsfasen, skal projektafslutningsrapporten foreligge på samme vis.

11 PROJEKTHÅNDBOG 11 Udover de godkendte ledelsesdokumenter skal projektlederen over for styregruppen dokumentere aktiviteterne i den forgangne fase, præsentere en plan og leveranceoversigt for den kommende fase samt give et opdateret indblik i projektets samlede økonomi. Styringsværktøjet status-/faseovergangsrapport kan anvendes. Værktøjet indeholder en plan for den kommende fase og en oversigt over resultaterne af den aktuelt afsluttede fase. PID & BC Ledelsesdokumenter Et ledelsesdokument i projektmodellen understøtter styring og beslutninger i projektforløbet. Der er knyttet en række ledelsesdokumenter til projektmodellen, som produceres undervejs i projektforløbet, se figuren nedenfor. Figur 6: SUF s projektmodel inkl. ledelsesdokumenter PID og Business Case er bærende ledelsesdokumenter, der er gennemgående i hele projektet. De opdateres løbende og i forbindelse med beslutning om faseafslutning og lignende. I SUF s projektmodel findes to bærende ledelsesdokumenter: Projektinitieringsdokument (PID) og business case. Disse to produkter indeholder den væsentligste information om projektet og bruges igennem hele projektforløbet. Udover de to bærende ledelsesdokumenter findes yderligere fire obligatoriske ledelsesdokumenter: Projektgrundlag, Status- /faseovergangsrapport, Projektafslutningsrapport og Gevinstrealiseringsplan. Det anbefales, at projektet gennemfører relevante tests herunder bruger- og brugervenlighedstests i gennemførelsesfasen, og at planlægningen af dette dokumenteres i PID. Gennemførelsen af tests dokumenteres i projektafslutningsrapporten. Udover ledelsesdokumenterne anbefales det, at projektet gør brug af en række andre værktøjer undervejs i projektforløbet. Eksempelvis kan det give stor værdi at udarbejde en interessentanalyse eller en kommunikationsplan. Disse vil generelt styrke planlægningen og styringen af projektet. Værktøjer, der understøtter dette arbejde, kan hentes her. Ledelsesdokumenter og værktøjer er yderligere beskrevet i afsnittet Værktøjer.

12 PROJEKTHÅNDBOG 12 Faser De fem hovedfaser i SUF s projektmodel præsenteres i dette afsnit. For hver hovedfase skitseres grundlaget for opstart af fasen, hvilke af de fem principper der skal bruges i fasen samt kriterierne for overgangen til næste fase. Endelig listes ledelsesdokumenter og relevante værktøjer og vejledninger. Faser Projektmodellen består af fem faser. Disse er idéfasen, analysefasen, anskaffelsesfasen, gennemførelsesfasen og realiseringsfasen, som igen kan nedbrydes yderligere. Idéfasen Idéfasen er den første fase i et projektforløb. Formålet med fasen er at undersøge, om ideen er bæredygtig. Digitaliseringsmatrixen tager stilling til, om der skal bruges ressourcer på at gå videre til analysefasen og danne projektorganisationen. Projektet oprettes i poverblik samt i edoc. Figur 7 - Idéfasen

13 PROJEKTHÅNDBOG 13 Analyse I analysefasen analyseres indhold, omfang og ressourcer. Projektlederen udpeges, og man afdækker it-sikkerhed. Idéfasen gennemføres, før projektet formelt er etableret. Den starter 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. I idéfasen gennemføres den første analyse af, om ideen kan resultere i et bæredygtigt projekt. Der laves et overslag over projektets udgifter. Og endelig redegøres der for ressourcer i forbindelse med at analysere idéen nærmere i analysefasen. Dette er ledelsens grundlag for at tage beslutning om, der skal overgås til analysefasen og etableres et projekt. Resultatet af idéfasen beskrives i et projektgrundlag. Det er en god idé også at arbejde med et udkast til den økonomiske business case, som giver et godt overblik over projektets samlede udgifter og mulige gevinster. Idéfasen afsluttes ved, at digitaliseringsmatrixen godkender projektgrundlaget og overgangen til analysefasen. Analysefasen Formålet med analysefasen er at analysere indhold, omfang og ressourcer i projektet. På denne baggrund beslutter styregruppen, om der skal fortsættes til anskaffelsesfasen. Ejerskabet for analysefasen ligger hos projektet. Analysefasen bygger videre på projektgrundlaget og evt. udkast til business case, hvor der her foretages en grundig og detaljeret analyse af projektets omfang, kravene til ressourcer, udgifter, mulige gevinster, tidsplan, risici, kvalitet, etc. Projektlederen udpeges senest i analysefasen og har ansvar for at tilpasse projektmodellen til projektet, at tage initiativ til at få sammensat projektorganisationen, at gennemføre analyser og samle alle de bidrag, der er nødvendige for at skabe styringsgrundlaget for et vellykket projekt herunder at igangsætte en gevinstrealiseringsproces. Det er et omfattende arbejde, som involverer mange mennesker med forskellig ekspertise f.eks. forretning, økonomi, arbejdsgange og it. Et andet væsentligt element i analysefasen er afdækning af it-sikkerheden. En itsikkerhedsvurdering laves på baggrund af oplysninger indtastet i FISKK. Resultaterne af alle analyserne samles i PID en, der udstikker projektets kurs og omfang og fungerer som kontrakt mellem projektleder og styregruppe.

14 PROJEKTHÅNDBOG 14 Figur 8: Analysefasen Analysefasen afsluttes ved, at status-/faseovergangsrapporten afleveres til styregruppen til godkendelse. Anskaffelsesfasen I denne fase beskrives behov og krav til det nye it-system, det ændrede it-system eller til den nye teknologi. Derudover gennemføres anskaffelsen frem til det tidspunkt, hvor kontrakten er klar til underskrift. Ejerskabet for anskaffelsesfasen ligger hos projektet. Arbejdet omfatter forberedelse og eventuel gennemførelse af udbud. Udbud Under forberedelsen vælges udbudsstrategi og behovene specificeres i kravspecifikationen. 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 godkender overgang til gennemførelsesfasen. For yderligere information vedrørende udbud, se ØKFs udbudsvejledning. I anskaffelsesfasen er der mange kompetencer i spil: Fremtidige brugere, forretningen, som skal realisere gevinsterne, it-arkitekter og jurister. Anskaffelsesfasen kan med fordel inddeles i to ledelsesfaser, kravspecificerings- og udbudsfasen.

15 PROJEKTHÅNDBOG 15 Figur 9: Anskaffelsesfasen Anskaffelsesfasen afsluttes ved, at status-/faseovergangsrapporten afleveres til godkendelse hos styregruppen.

16 PROJEKTHÅNDBOG 16 Gennemførelsesfasen Det første skridt i denne fase er at underskrive kontrakten med leverandøren. Når kontrakten er underskrevet, starter samarbejdet med leverandøren om at designe, udvikle og teste it-løsningen. Det anbefales, at der gennemføres relevante tests i gennemførelsesfasen. Værktøjet test, kan anvendes som inspiration til planlægning og udførelse af tests. Det er også i denne fase, at de første gevinster typisk kan høstes, da fasen også indeholder implementering af it-systemet, uddannelse af brugerne, overdragelse til drift og forretning og endelig afslutning af projektet. Ejerskabet for gennemførelsesfasen ligger hos projektet. Figur 10: Gennemførelsesfasen Projektet kan stadig indeholde en række aktiviteter f.eks. udrulning af systemet til brugerne, brugeruddannelse og projektevaluering. Udgifter til disse aktiviteter henføres stadig til projektet. Ofte tales der i projekter både om idriftsættelsen af et system og om projektafslutning uden at termerne er helt klare. Boksene definerer henholdsvis, hvornår der er tale om idriftsættelse af et system, og hvornår der er tale om projektafslutning. Projektafslutning markerer altid overgangen mellem gennemførelsesfasen og realiseringsfasen. Idriftsættelsen af it-systemet sker typisk i gennemførelsesfasen og er defineret ved, at den endelige overtagelsesprøve fra leverandøren bestås. Driftsudgifter i forbindelse med it-systemet vil herefter skulle henføres til driften i business casen. Der kan derfor også sagtens påbegyndes realisering af gevinster i gennemførelsesfasen. Som sagt markerer overgangen fra gennemførelsesfasen til realiseringsfasen afslutningen på projektet, hvor projektafslutningsrapporten også udarbejdes. I realiseringsfasen vil der derfor ikke være projektrelaterede udgifter.

17 PROJEKTHÅNDBOG 17 I drift Idriftsættelsen af et it-system kan ske efter, at den endelige overtagelsesprøve med leverandøren er bestået. Gennemførelsesfasen er den fase, der typisk varer længst tid og kræver mest af projektlederen. Denne hovedfase kan derfor med fordel opdeles i ledelsesfaser. Når projektet er afsluttet, skal kunde-leverandørsamarbejdet evalueres og resultaterne nedskrives i projektafslutningsrapporten. Gennemførelsesfasen afsluttes ved, at projektafslutningsrapporten afleveres til godkendelse hos styregruppen. Herefter frigives projektorganisationen inklusiv projektlederen og alle projektdeltagere, og den tilrettelagte driftsorganisation overtager herfra. Realiseringsfasen I denne fase skal de gevinster, der er beskrevet i projektets business case, realiseres. Som hovedregel er projektlederen ikke involveret i realiseringsfasen, som ejes af forretningen/driften. Det er forretningens/driftens opgave at forankre it-systemet i organisationen og høste gevinsterne. For at følge op på om gevinstrealisering har fundet sted som planlagt, afrapporteres gevinstrealiseringen til digitaliseringsmatrixen. Figur 11: Realiseringsfasen Afslut Projektafslutningen markerer overgangen mellem gennemførelsesfasen og realiseringsfasen. Afslutningen finder sted, når alle projektaktiviteter er udført eller overdraget, og projektorganisation opløses. Realiseringsfasen afsluttes ved, at gevinstrealiseringsrapporten afleveres til godkendelse hos Digitaliseringsmatrixen eller direktionen.

18 PROJEKTHÅNDBOG 18 Ledelsesdokumenter I dette afsnit gennemgås de seks obligatoriske ledelsesdokumenter i SUF s projektmodel. Vurdér Ledelsesdokumenterne bør, som SUFs projektmodel som helhed, tilpasses det aktuelle projekt, så brugen er hensigtsmæssig og understøtter den nødvendige styring. Tilpasningen skal dog begrundes. SUF s projektmodel indeholder seks obligatoriske ledelsesdokumenter, hvoraf projektinitieringsdokument (PID) og business case er de bærende dokumenter for projektudførslen. For disse to produkter gælder at dokumenterne skal opdateres ved hver faseovergang. Formålet med ledelsesdokumenterne er at understøtte især projektlederens arbejde undervejs i projektet samt bidrage til at sikre, at projektet planlægges bedst muligt. Ledelsesdokumenterne kan ses i nedenstående figur. Figur 12: SUF s projektmodel inkl. ledelsesdokumenter Projektlederen kan tilføje afsnit eller udskille afsnit fra projektinitieringsdokumentet (PID en) i selvstændige dokumenter, såfremt dette er nødvendigt. Ligeledes kan det udelades at udfylde afsnit i PID en i stedet skrives blot en kort begrundelse under det pågældende afsnit. Projektgrundlag Projektgrundlaget skal sikre, at forretningen får et tilstrækkeligt grundlag at vurdere projektets berettigelse på inden analysefasen. Dokumentet skitserer kort de overordnede rammer for det kommende projekt samt forventninger til projektets konsekvenser, udgifter, ressourceforbrug og gevinster. Ansvaret for, at projektgrundlaget bliver udarbejdet, ligger hos projektejer/styregruppeformand og udarbejdes i idéfasen. Projektgrundlaget godkendes af forretningen, typisk på direktionsniveau for store projekter. Godkendes projektgrundlaget, erstattes dette af PID en i analysefasen.

19 PROJEKTHÅNDBOG 19 Projektinitieringsdokument (PID) Under udarbejdelse af PID en, vil projektlederen skulle indhente information fra organisationen og gennemføre et antal analyser. PID'en samler de oplysninger og analyser, der er nødvendige for at starte og drive et projekt på et forsvarligt grundlag. PID en består af følgende hoveddele: BC Business casen er en beregning af den samlede effekt af den potentielle investering og udgør sammen med PID en det centrale styringsgrundlag i projektmodellen. Forretningens formål med projektet: Hvorfor igangsættes projektet, hvad indeholder det, hvordan vil det påvirke og bidrage til forretningen? Scope og afgræsning: Hvad omfatter projektet ikke? Mål og succeskriterier: Hvilket mål skal nås med projektet, hvad er succeskriterierne for at opnå målet og dermed projektets succesfulde udførelse? Økonomiske hovedtal og finansiering: Projektudgifter og kilde til finansiering Gevinster: Hvad får forretningen ud af projektet? Opgjort på kvantitative, målbare gevinster Teknisk løsning: Beskrivelse af den tekniske løsning som skal udvikles og implementeres Leverancer og afhængigheder: Liste og beskrive projektets leverancer Organisering: Projektorganisation og tildeling af roller/ansvar Tilrettelæggelse og tidsplan: Hvornår udføres projektet, hvornår høstes gevinster? Kvalitet: Hvilken kvalitet skal leverancer have, og hvordan sikres dette? Risici: Hvilken risikostrategi antager myndigheden i projektet? It-sikkerhed: Hvordan sikres it-løsningen? Der skal gennemføres en itsikkerhedsmæssig risikovurdering i FISKK? Interessenter: Kort skitse over projektets væsentligste interessenter og deres håndtering Kommunikation: Strategi og budskaber i kommunikation i og fra projektet Tolerancer: Hvilke tolerancer kan projektleder og styregruppe agere indenfor? Indholdet i PID en er i skabelonen tilrettelagt efter typiske projekter og skal tilpasses det aktuelle projekt. Det er således muligt både at undlade at udfylde visse afsnit og at tilføje nye afsnit, hvis det er relevant for det pågældende projekt. Undlades det at udfylde afsnit begrundes dette kort under den pågældende overskrift. PID'en udarbejdes i analysefasen på baggrund af projektgrundlaget og fungerer som en baseline, som projektlederen og styregruppen kan bruge som baggrund for at vurdere fremdriften i projektet. På den måde kan PID en også opfattes som en kontrakt mellem styregruppen og projektlederen. Projektlederen er ansvarlig for at udarbejde PID samt vedligeholde og opdatere den. Som minimum skal PID en opdateres ved hver faseovergang. Business case Business casen udgør sammen med PID en det centrale styringsgrundlag i SUF s projektmodel. Under udarbejdelsen vil projektlederen skulle indhente information og lave analyser i organisationen. En business case er en beregning af den samlede effekt af en potentiel investering. Den bygger på en analyse og opgørelse af, hvilken forandring man ønsker, og hvordan den opnås samt en økonomisk beregning. Formålet med SUF s business case er således at beregne konsekvenserne af den planlagte investering. Business casen er et meget vigtigt beslutningsgrundlag, og den opdateres ved hver faseovergang. Projektlederen er ansvarlig for at samle information til business casen evt. sammen med

20 PROJEKTHÅNDBOG 20 en økonomimedarbejder. Business casen udarbejdes i analysefasen, men et udkast kan med fordel påbegyndes i idéfasen. Business case-skabelonen skal hentes i edoc under standardtekster (A-Digitale projekter, std skabeloner mv). Det økonomiske bilag til business casen findes på digitaliseringsmatrixens intranetside. Status-/faseovergangsrapport Ved hvert styregruppemøde præsenteres styregruppen for en statusrapport, som giver et samlet billede af projektets status og fremdrift. Statusrapporten baserer sig på opdaterede styringsdokumenter (PID, business case etc.). Rapport Projektafslutningsrapporten udarbejdes som den sidste aktivitet i projektet i slutningen af gennemførelsesfasen før endelig overgang til realiseringsfasen. Der er således tale om et ledelseskoncentrat af centrale informationer om projektet, som skal ruste styregruppen til at træffe kvalificerede beslutninger om projektet. Statusrapporten anvendes også ved faseovergangen og suppleres her af planen for kommende fase. Denne udarbejdes af projektlederen og skal indeholde tilstrækkelige oplysninger til, at styregruppen kan træffe beslutning om, hvad der videre skal ske i projektet. Dokumentet er projektlederens rapport til styregruppen om, hvordan projektet har klaret sig i forhold til senest godkendte PID ved projektets afslutning. Projektets egen evaluering af projektforløbet fremgår også af rapporten. Efter godkendelse opløses projektorganisationen, og projektleverancerne overdrages til forretningen/driften. Projektafslutningsrapport Projektafslutningsrapporten skal sikre, at der sker en rapportering af, hvordan projektet er gennemført målt på økonomi og resultat, samt hvilken læring der er sket. Indholdet af projektafslutningsrapporten følger indholdet af PID en med tillæg af et væsentligt afsnit om læring og videndeling forårsaget som følge af projektet. Rapporten skal give styregruppen et grundlag for at beslutte, om projektet skal afsluttes. Dokumentet er projektlederens rapport til styregruppen ved projektets afslutning om, hvordan projektet har klaret sig i forhold til senest godkendte PID. Projektets egen evaluering af projektforløbet fremgår også af rapporten. Projektlederen er ansvarlig for udarbejdelse af rapporten, og efter godkendelse opløses projektorganisationen og projektleverancerne overdrages til forretningen/driften. Afrapportering til Digitaliseringsmatrix Gevinstejerne skal dokumentere, hvordan det er gået med realisering af alle business casens gevinster (såvel økonomiske som ikke-økonomiske). Afrapporteringen viser, om gevinsterne er realiseret på niveau med eller bedre end specificeret i PID en og hvis det ikke er tilfældet, skal afvigelsen forklares.

21 PROJEKTHÅNDBOG 21 Værktøjer Til understøttelse af arbejdet med projekter under SUF s projektmodel er der udarbejdet en række værktøjer. I dette afsnit gennemgås de fire mest centrale værktøjer. SUF s projektkontor udarbejder og vedligeholder en række værktøjer, som kan assistere projektlederen og projektorganisationen i deres arbejde. Fem af disse værktøjer ses som centrale for SUF s projektmodel: Styringslog til styring af projektets aktiviteter, beslutninger m.m. Afvigelsesanmodning til styring af afvigelser Risikolog der bidrager til identifikation og belysning af risici Styregruppeaftale Agenda/referat Afvigelse Afvigelsesanmodningen giver styregruppen det fornødne beslutningsgrundlag til at godkende eller afvise afvigelser og ændringer i projektet, der påvirker tid, økonomi eller scope. De nævnte værktøjer er gennemgået efterfølgende. En komplet liste af værktøjer findes her. Styringslog Med en Styringslog samles alle opgaver, beslutninger, udfordringer og emner til behandling i et og samme dokument. Det giver et godt overblik over, hvilke beslutninger der er taget i projektet, og hvem der har taget dem, samt hvilke opgaver og udfordringer der er, og hvem der har ansvaret for at følge op på dem. Sidst men ikke mindst kan projektlederen, eller en projektmedarbejder følge op på alle deadlines direkte i loggen. Man kan også vælge at skrive leverancer og milepæle ind i skemaet, for at gøre projektopfølgningen endnu lettere. Værktøjet Styringslog findes i værktøjskassen på projektsiden på intranettet. I sidste ende vil alle emnerne i loggen udgøre hele projektforløbet i kronologisk rækkefølge, og man kan derfra let udsøge de vigtige punkter, når man skal til at skrive projektevalueringen. Hvis loggen lægges, så alle har adgang til den, kan alle deltagere i projektet følge med i egne opgaver og deadlines. Dermed behøver projektlederen ikke lægge status ind for alle deltagere det kan de ansvarlige selv gøre. Man kan hurtigt fremsøge f.eks. beslutninger og andet, hvis der opstår tvister omkring, hvorvidt disse er foretaget eller ej. Afvigelsesanmodning Formålet med afvigelsesanmodningen er at sikre en ensartet styring af de situationer, hvor afvigelser eller ændringer i projektet skal håndteres og kræver styregruppegodkendelse. En afvigelsesanmodning indeholder beskrivelse af og begrundelse for, hvorfor der er opstået en afvigelse (i scope, tid, ressourcer eller leverancekvalitet) i forhold til senest godkendte PID og de tolerancer, der er tildelt projektlederen. Samtidig indeholder den en beskrivelse af hvilke konsekvenser, afvigelsen har for projektet.

22 PROJEKTHÅNDBOG 22 Afvigelsesanmodningen indeholder også projektlederens indstilling til, hvad styregruppen anmodes om at godkende. Projektlederen har ansvaret for udarbejdelse af afvigelsesanmodningen, herunder dens indhold og anbefalinger. Afvigelsesanmodninger bruges typisk i analyse-, anskaffelses- og gennemførelsesfasen, når det konstateres, at der er risiko for, at projektet bliver påvirket i et omfang, der overstiger de tolerancer, der er tildelt projektlederen. Risikolog Risikologgen er et værktøj, der skal benyttes til identifikation og vurdering af risici i projektet. Risikologgen bør udfyldes af dem med størst indsigt i projektet, og der kan derfor sagtens være flere personer, der deltager i udfyldelsen. Som udgangspunkt er det dog projektlederen, der har ansvaret for at samle input. Såfremt projektet har et budget på mere end 5 mio. kr., skal risikologgen indsendes sammen med PID og business case forud for risikovurdering hos It-projektrådet. Styregruppeaftale Styregruppeaftalen udarbejdes, når styregruppen nedsættes typisk faciliteret af styregruppeformand og projektleder på opstartsmødet med styregruppen se afsnit 10.4., Styregruppemøder. Formålet med styregruppeaftalen er kort at definere gruppens mandat, beføjelser og ansvar både som gruppe og individuelt i forhold til det pågældende projekt. Styregruppeaftalen underskrives af alle styregruppemedlemmer. Agenda/referat Nedenstående skabelon anvendes til agenda for styregruppemødet, og under eller efter mødet udfyldes den og udsendes som beslutningsreferat. Referatet fastholdes i edoc. I aftale for styregruppen kan være fastlagt terminer for udsendelse af agenda og referat, samt en passus om, at referatet betragtes som godkendt, hvis der ikke indenfor fem arbejdsdage fremsættes ændringer, tilføjelser eller korrektioner. I styregruppeaftalen vil typisk også være fastsat følgende omkring agenda og dagsorden: I dagsordenen angives om punktet er: Til orientering (O) Til drøftelse (D) Til beslutning (B) Den faste dagsorden til styregruppens møder indeholder følgende punkter: Godkendelse af dagsorden Godkendelse af referat Status for projektet (milepæle, risikostyring, fokusområder) Behandling af indstillinger fra projektledelsen Eventuelt herunder fastlæggelse af næste møde.

23 PROJEKTHÅNDBOG 23 Eksempel på udfyldt styregruppereferat:

24 PROJEKTHÅNDBOG 24 Projektgovernance Effektiv Governance sikrer, at organisationens projektportefølje er i overensstemmelse med organisationens målsætninger, at de enkelte projekters fremdrift og styring og i sidste ende projektporteføljen leveres effektivt og bæredygtigt. Beslut Governance er de beslutningsstrukturer og -processer, der samlet sikrer, at der træffes de rigtige og rettidige beslutninger i forhold til et givent projekt eller en portefølje af projekter. Indledende forståelse I denne projekthåndbog forstås governance som de beslutningsstrukturer og -processer, der samlet sikrer, at der træffes de rigtige og rettidige beslutninger i forhold til et givent projekt eller en portefølje af projekter. Det vil sige, at: Det er tydeligt, hvem der beslutter: Det betyder bl.a., at beslutningsfora har den rette sammensætning i forhold til beslutningsbehovene, og at samspillet mellem de forskellige beslutningsfora er entydigt Det er klart, hvad de beslutter: Dette indebærer tydelige beskrivelser af og forståelse for beføjelser, roller og ansvar i beslutningsfora, linjeledelse, projektejer og projektledere Det er defineret, på hvilket grundlag beslutningen træffes: Best practice i forhold til den rette brug af projektdokumenter, beslutningsoplæg mv. Der er klarhed om, hvornår beslutningen træffes: Rette timing i forhold til projektets fremdrift, projektmodel og projektets livscyklus For at projektgovernance skal være entydig, er det nødvendigt at have fokus på såvel struktur som proces. Desuden er det nødvendigt at have øje for projektets livscyklus. Figur 13: Governance og projektets livscyklus

25 PROJEKTHÅNDBOG 25 Struktur: Den ledelsesmæssige struktur skal være på plads og tydelig for alle deltagende parter. Der skal være tydelige kriterier for, hvilke interessenter og beslutningstagere styregruppen skal sammensættes af. Proces: Der skal være enighed om de basale processer for arbejdet, hvordan projekter og styregrupper etableres, hvornår digitaliseringsmatrixen skal inddrages, og hvilke beslutninger der er afgørende for projektets videre liv. Livscyklus: Der skal tages højde for projektets fremdrift og livscyklus bevidsthed om beslutningsstrukturer og processers forskellige karakteristika i de forskellige faser. Tre spor Governancemodellen er inddelt i tre spor: Porteføljegovernace, projektgovernace og systemgovenance. Projektgovernance I SUF Digital har vi valgt at beskrive governancemodellen ud fra en tredeling i følgende spor: Porteføljegovernance som er tragten, hvor porteføljen fastlægges og styres i forhold til strategierne. Porteføljegovernance forvaltes i SUF gennem digitaliseringsmatrixen. Projektgovernance som beskriver, hvad der sker fra, der træffes beslutning om at igangsætte et projekt, og indtil projektet overdrages til drift. Projektgovernance forvaltes via styregrupper, projektledere og projektgrupper. Systemgovernance som beskriver, hvordan systemer forvaltes efter idriftsættelsen. Processen for systemgovernance er under udarbejdelse. Figur 14 - Projektgovernance Begrebet projektgovernance beskriver de strukturer og processer, der sikrer, at der træffes beslutninger på rette niveau og muliggør en effektiv styring af projektet. Effektiv projektgovernance sikrer de enkelte projekters fremdrift og styring og i sidste ende at projektporteføljen leveres effektivt og bæredygtigt. I projekthåndbogen beskrives governancemodellen i forhold til projektgennemførsel. Governacemodel I figur 15 er governancemodellen mellem digitaliseringsmatrix, styregruppe og projektleder visualiseret. Som udgangspunkt igangsætter direktionen projekter og giver styregruppen mandat til at udføre projektet inden for fastsatte tolerancer. Hvis disse tolerancer overskrides bliver dette informeret via styregruppeformanden/projektlederen til digitaliseringsmatrixen.

26 PROJEKTHÅNDBOG 26 De forskellige led i styringskæden har ansvaret for og forpligtelsen til at melde afvigelser tilbage til næste led i kæden. Mandatet definerer det enkelte niveaus frihed til selvstændigt at træffe beslutning inden for en given ramme. Figur 15: Governancemodel I skemaet herunder visualiseres det, hvilke vigtige beslutninger og output der er vigtige i den enkelte fase. Derudover beskrives det, hvilke beslutningsfora der benyttes hvornår, hvilke styringsdokumenter der bruges og hvad formålet er. Modellen giver et overblik over hvornår kontakter foregår mellem digitaliseringsmatrix, styregruppe og projektleder i et projekt der holder sig indenfor de fastsatte tolerancer. Projektfase Ide Analyse Anskaffelse Gennemførsel Realisering Formål Ide kvalificeres og beskrives Udkast til business case Plan for næste fase Grundlaget for projektet analyseres og defineres i styrings- og beslutningsdokumenter Projektbeskrivelse Business case Styringslog Risikolog Behov og krav til den teknologiske løsning beskrives og mulige leverandører vurderes Produktet driftes og gevinster realiseres i henhold til business case og planen for gevinstrealisering Styringsdokumenter Projektgrundlag Fremdriftsrapport/status Kravspecifikation Udkast til kontrakt Plan for næste fase Opdateret PID Kontrakt underskrives og design, udvikling og test gennemføres. Idriftsættelse og implementering Underskrevet kontrakt Opdateret PID Projektafslutningsrapport Opdateret gevinstrealisering Plan for næste fase Plan for implementering og

27 PROJEKTHÅNDBOG 27 Plan for gevinstrealisering overdragelse til drift Fora Beslutninger og vigtige output Matrix, SUF Digital ledelse Overgang til næste fase Godkendt projektoplæg Godkendt projektopstart Projektejer udpeget Styregruppe Styregruppe Styregruppe Styregruppe Overgang til næste fase Styregruppen etableret og introduceret Projektleder udpeget Projektgruppe nedsat Overgang til næste fase Godkendte styrings- og projektdokumenter Kravsspecifikationen færdig og godkendt Kontrakt klar til underskrift Godkendt plan for implementering og overgang til drift Overgang til næste fase Produkt klar til drift Godkendt projektafslutningsrapport Overgang til drift Godkendt gevinstrealisering

28 PROJEKTHÅNDBOG 28 Projektorganisation For at sikre et vellykket projekt er det vigtigt, at alle med tilknytning til et projekt ved, hvem der har ansvar for hvilke opgaver og beslutninger i projektet. For at sikre at ansvaret for beslutninger, ledelse og styring er forankret de rigtige steder, indeholder projektmodellen et sæt standardroller og ansvarsbeskrivelse, som gennemgås i dette afsnit. Niveauer Projektorganisationen opdeles konceptuelt i tre niveauer: Ledelsesniveauet, styringsniveauet og det udførende niveau. En rolle er ikke per definition lig med en konkret person. En rolle er en beskrivelse af de kompetencer, der skal til for at udfylde en bestemt funktion samt det ansvar og de typiske opgaver, der følger med. Én person kan godt varetage flere roller. SUF s projektmodel omfatter beskrivelser af de roller, der er mest relevante for projekter i SUF. Beskrivelsen af den enkelte rolle i SUF s projektmodel er vejledende og bør tilpasses myndighedens organisation og projekt. Rollerne er i vid udstrækning afstemt med rolle- og ansvarsfordeling i projekter fra PRINCE2. Projektorganisering i tre niveauer For at sikre at ansvaret for beslutninger, ledelse og styring er forankret de rigtige steder, indeholder projektmodellen et sæt standardroller og tilhørende ansvarsbeskrivelse. Projektleder og styregruppe kan tage udgangspunkt i standardrollerne ved design af projektorganisationen og bemanding af projektet. Se yderligere i afsnit 8. Organisationsstrukturen i projekter kan konceptuelt inddeles i tre niveauer: Ledelsesniveauet, styringsniveauet og det udførende niveau. Dette er illustreres i figuren nedenfor. Figur 16: Projektorganisering

29 PROJEKTHÅNDBOG 29 Uden for projektet er direktionen, m.fl. ansvarlig for at rekvirere projektet, udpege styregruppeformanden og fastlægge de tolerancer, styregruppen skal arbejde inden for. På ledelsesniveauet udstikkes rammerne for projektet. Det er på dette niveau, at ressourcer, planer, overgang til næste fase og evt. afvigelser godkendes. På styringsniveauet ligger ansvaret for at levere de krævede ledelsesdokumenter i overensstemmelse med projektets mål for tid, budget, kvalitet, etc. Det udførende niveau har ansvaret for at levere de enkelte produkter i en kvalitet, der svarer til det krævede og inden for rammerne af tidsplan og budget. Det anbefales, at projektorganiseringen sker i tre niveauer, som angivet i figur 16. Roller og ansvar på de tre niveauer er beskrevet efterfølgende. Ud over de formelle beslutningsfora i projektøjemed har SUF flere andre faglige og politiske fora, der kan have behov for en orientering om et projekt, eller som skal godkende en eller flere leverancer i et projekt. Dette aftales med styregruppen undervejs i projektet. Her ses links til de mest relevante fora: Drifts- og Udviklingsforum (DUF) Kvalitetsorganisationen i SUF Myndighedsfaglig Kvalitetsgruppe Sundheds- og Omsorgsudvalget (SOU) Se også link til SUF s overordnede organisationsdiagram her. Nøgleaktører i projektet En projektorganisation består af en lang række parter, som har større eller mindre indflydelse på projekter og i større eller mindre grad bliver berørt af projektet. Der er grundlæggende tre interesserer, som varetager primære funktioner i projekterne: Figur 17: Nøgleaktører i projektet

30 PROJEKTHÅNDBOG 30 Ovenstående tre interesser bør alle være repræsenteret i en styregruppe, så det sikres, at der både er fokus på leverancer (leverandører), gevinster (brugerne) og de oprindelige forretningsmål. Styregruppers organisering kan løbende ændre sig som følge af ændrede behov og ændret scope for projektet. Roller Uden for projektet Rolle Ledelse (linjeorganisation, f.eks. direktionen) Ansvar Fastlægger politikken og rammerne for projektet herunder bl.a. organisationens risikovillighed, tolerancer og eskaleringsprocesser. Overordnet ansvarlig for alle projekter. Roller Der er grundlæggende tre interessenter, som varetager primære funktioner i projekterne: Styregruppeformand, seniorleverandør og seniorbruger. Ledelsesniveauet Rolle Ansvar Styregruppeformand Styregruppeformanden er projektejeren, dvs. den person i projektet der har det overordnede ansvar for økonomien i projektet og den beslutningsmæssige fremdrift. Sikrer nødvendige rammebetingelser for projektet (sammen med styregruppen) samt sikrer fokus og retning for projektet Udarbejder projektoplæg Business case og herunder også gevinstrealisering Kvalitetssikring ift. projektets forretningsinteresser (at projektet kan overholde tid og økonomi samt levere et slutprodukt, der kan anvendes til at realisere gevinsterne) Balancering af organisationens, brugerens og leverandørens krav Sparring med projektlederen Seniorbruger Seniorbrugeren repræsenterer brugernes interesser. Seniorbrugeren er ansvarlig for, at der bliver stillet de rigtige krav til projektets leverancer. Definerer forventninger/krav til projektets slutprodukt og dermed projektets omfang Definerer og prioriterer godkendelseskriterier på projektniveau Sikrer at kravene til projektets leverancer beskrives ordentligt (kvalitet) Sikrer at kravene beskriver det rigtige og at det, der bedes om, er både nødvendigt og tilstrækkeligt til at realisere gevinsterne Sikrer at de mulige gevinster identificeres og beskrives Opretholder forretningsmæssig stabilitet ved overgang fra projekt til almindelig drift Implementering og idriftsættelse herunder ansvar for forandringsledelse Bistår projektlederen med udarbejdelsen af en PID, særligt omkring gevinster Sikrer nødvendige ændringer i forretningen så gevinsterne

31 PROJEKTHÅNDBOG 31 Seniorleverandør realiseres Dokumenterer at gevinsterne er opnået Udarbejder gevinstrealiseringsrapportering Seniorleverandøren repræsenterer leverandørernes interesser i projektet. Rollen kan deles af flere personer, hvis projektet har flere leverandører f.eks. både den interne it-afdeling og en eller flere eksterne leverandører. Seniorleverandøren er ansvarlig for at overholde de forpligtelser, der kontraktuelt er pålagt denne. Dette vil typisk omfatte, at leverancer, kvalitet og tidsplan overholdes som aftalt samt, at brugernes krav kan tilgodeses/implementeres. Proaktiv orientering af den øvrige styregruppe og ledelse om forhold hos leverandøren (både for interne og eksterne leverandører), som kan påvirke projektet Sikrer realisme i design og udvikling af projektets produkter Sikrer at de nødvendige interne og eksterne leverandørressourcer (kompetencer) stilles til rådighed Træffer beslutninger om passende procedure til at sikre produkternes kvalitet Sikrer at kvalitetsprocedurer anvendes korrekt, så produktet overholder kravene Rådgiver om metoder til design, udvikling og godkendelse Træffer beslutninger om problemer vedr. produkterne Løser konflikter der vedrører leverandørkrav Kvalitetssikrer projektet ift. leverandørens synsvinkel Referencegruppe Der kan nedsættes en referencegruppe, hvis styregruppeformanden i samråd med projektlederen vurderer, at der er behov. Rådgiver projektet om nødvendige operationelle beslutninger på alle væsentlige forretningsmæssige områder Afvejer forretningens behov i forhold til løsningsmuligheder og øvrige projektbehov Ser muligheder og udfordrer projektet mht. forretningsmæssige løsninger Optræder loyalt over for beslutninger i projektet i forhold til eget bagland Styringsniveauet Projektejer Samlet ansvar for projektet og ejer af projektets business case. Godkender PID og større ændringer i projektet og agerer som ambassadør for projektet i organisationen. Gevinstejer Operationelt ansvar for implementering af forandringer og for at høste gevinster i en afgrænset del af organisationen. Gevinstejerne varetager implementeringen af programmets forandringsevne og leverancer i egen driftsorganisation/linje for at sikre de planlagte resultater af det samlede program. Projektleder Sikrer at projektet bliver planlagt, etableret, styret, gennemført, afsluttet og overleveret i henhold til gældende kvalitetssystem, SUF s projektmodel, it-arkitektur og standarder samt øvrige krav fra offentlige myndigheder Styrer projektet i hver fase inden for de tolerancer, som

32 PROJEKTHÅNDBOG 32 styregruppen har fastsat Styrer fremstillingen af produkter og tager ansvar for den overordnede fremdrift Uddelegerer arbejde til projektdeltagerne og følger op Udarbejder og opdaterer løbende de ledelsesdokumenter, der skal anvendes til at lede og styre projektet PID og business case Økonomistyring, budgetopfølgning og disponering af forbrug. Løbende kontakt og koordination med økonomifunktion/projektcontrolller Styrer projektets medarbejdere, interessenter og samarbejdspartnere frem mod leverance af de specificerede produkter til ønsket tid, økonomi og kvalitet eller styrer alternativt afvigelser herfra Etablerer rollebeskrivelser, rolleallokerer projektdeltagerne og styrer ressourcer dagligt Holder kontakt med eksterne leverandører Sikrer effektiv risikostyring i projektet Sikrer information og kommunikation fra projektet, herunder rapportering af status, afvigelser, problemer og ændringsønsker Sikrer planlægning af driftsteknisk og forretningsmæssig implementering Administrerer projektet har ansvar for at projektet etablerer og følger op på projektarkiv og journalisering af relevant dokumentation Projektkontor Projektkontoret er et tværgående hjælpefunktion, som kan anvendes efter behov af alle projekter. Det er også projektkontoret som fastsætter retningslinjer for god projektpraksis. Fastlægger og vedligeholder projekt- og styringsdokumentation herunder navngivningsstandarder og versionering Fastlægger og vedligeholder fælles standarder, metoder og processer Bidrager med ekspertviden inden for projektledelse eller andre discipliner Projektsupport Hjælpefunktion i form af specifikke ressourcer som tildeles projektet f.eks. i forhold til: Indsamling af data faktiske og forventede Opdatering af projektdokumentationen herunder relevante logs, registre og planer Det udførende niveau Roller Ansvar Projektdeltagere Udfører de aktiviteter, der bidrager til projektets leverancer Udover ovenstående roller vil langt de fleste projekter på det styrende eller udførende niveau have behov for at have tilknyttet en projektcontroller, forretningsspecialist, testspecialist, it-arkitekt og driftsrepræsentanter. Se yderligere beskrivelse af disse roller i vejledning om sammensætning af projektorganisationen.

33 PROJEKTHÅNDBOG 33 Fordeling af roller i forhold til faser Nedenfor er fasemodellen vist med oplæg til, hvilke projektroller der med fordel kan anvendes i de respektive faser. Ikke alle roller er beskrevet i afsnittet om roller og ansvar, da de ikke er særlig hyppigt anvendt i SUF Digital-projekter. Figur 18: Roller ift. SUF s projektmodels faser Primære roller, som skal bemandes Projektejer/styregr uppeformand Projektejer/ styregruppeformand Seniorbruger/ gevinstejer Seniorleverandør Projektleder Projektejer/ styregruppeformand Seniorbruger/ gevinstejer Seniorleverandør Projektleder Projektejer/ styregruppeformand Seniorbruger/ gevinstejer Seniorleverandør Projektleder Roller, som med fordel kan bemandes Testspecialist Projektsupport Roller, som bør bemandes Projektleder Forretningsspecialist Projektcontroller Forandringskonsulent Arkitekt Driftsrepræsentanter Sikkerhedskonsulent Forretningsspecialist Kontraktspecialist Arkitekt Sikkerhedskonsulent Driftsrepræsentanter Ændringsmyndighed Testspecialist Forandringskonsulent Projektcontroller Projektsupport Forretningsspecialist Testspecialist Forandringskonsulent Arkitekt Driftsrepræsentanter Sikkerhedskonsulent Kontraktspecialist Ændringsforum Projektcontroller Projektsupport Seniorbruger/ gevinstejer Forandringskonsulent Generelt gælder det, at når der etableres en projektorganisation, skal de deltagende aktører have repræsentation i styregruppen. Der behøver ikke nødvendigvis være en repræsentant fra alle deltagende parter, idet et styregruppemedlem kan have mandat til at repræsentere flere aktører. Kendetegnet for et styregruppemedlem er, at de har beslutningskompetence, og at de er tilgængelige for projektlederen.

34 PROJEKTHÅNDBOG 34 Styregruppens arbejde Styregruppen har det overordnede ansvar for projektets realisering. Styregruppen bør optræde som et samlet ledelsesorgan, der løbende overvåger projektets fremdrift og leverancer, og som med beslutninger og godkendelser fastholder projektets fokus på målet. Styregruppens ansvar Når et projekt igangsættes fastlægges rammerne for projektet i form af aftaler om: Ansvar Styregruppen har ansvar for at fastsætte rammer for mål og leverancer, ressourceforbrug og tidsplan. Mål og leverancer for projektet Hvad forventes det, at projektet skal levere? Det forventede ressourceforbrug Hvilke økonomiske ressourcer og medarbejderressourcer forventes projektet at få stillet til rådighed af styregruppen /organisationen? Tidsplanen Hvornår og med hvilke kadencer skal projektet gennemføres? Figur 19: Projekttrekanten Aftalerne nedfældes i projektets grundlæggende dokumenter, så som PID en, projektbeskrivelsen, business casen og styregruppeaftalen. Afvigelser måles således ud fra forventninger nedfældet i disse styringsdokumenter.

35 PROJEKTHÅNDBOG 35 Ændringer i omgivelserne for projekterne kan betyde, at aftalerne flytter sig, og at det f.eks. ikke længere er muligt at levere projektet inden for den forventede tidsramme eller med mindre funktionalitet/andre arbejdsgange end forventet. De tre parametre er tæt forbundne, dvs. at hvis vi stiller nye og højere krav til indholdet af et bestemt projekt, kan vi risikere, at projektet enten vil tage længere tid eller vil koste mere, hvis tidsrammen skal overholdes. I en omskiftelig organisation som SUF er det naturligt, at vilkårene for projekterne ændrer sig over tid f.eks. som følge af lovgivning, nye politikker, ændringer i leverandørsamarbejder etc. Det er således ikke nødvendigvis udtryk for dårlig projektledelse, men der kan være tale om, at vilkårene forudsætter, at vi revurderer vores projekter. Styregruppeledelse Det anbefales, at medlemmer i styregrupper følger de tre principper for god styregruppeledelse. De tre ledelsesprincipper er retningsgivende for styregruppens ledelsesindsats i forhold til at effektivisere styregruppens arbejde. Ejerskab Figur 20: Principper for god styregruppeledelse Styregruppen skal tage ejerskab for projektet ved aktivt at påtage sig ansvar og ledelsesrolle for projektet. Tag ejerskab Ledelsesprincippet tag ejerskab betyder, at styregruppen aktivt påtager sig ansvar og dermed ledelsesrolle for projektet. En forudsætning, for at et projekt bliver en succes, når sine mål og høster sine gevinster, er, at styregruppemedlemmerne erkender et medansvar. Styregruppen skal aktivt vejlede og rådgive projektleder, når der skal løses problemer. Det betyder ikke, at styregruppen skal deltage i den daglige styring af projektet. Det er alene projektlederens ansvar. Tag ejerskab betyder bl.a., at styregruppen skal: Prioritere og minimere mængden af opgaver fra styregruppemedlemmerne til projektlederen, således at denne kan fokusere på styring af projektet til succes Være forberedte og beslutningsorienterede på styregruppemøderne Være enige om mål, fokus, succeskriterier og gevinster for projektet Fjern barrierer For at understøtte at et projekt kan gennemføres så gnidningsfrit som muligt og uden forsinkelser, skal styregruppen aktivt handle i forhold til at fjerne barrierer. Barrierer kan være alt fra manglende projektfaciliteter til modstand til projektet. Det er styregruppens ansvar, at fjerne barrierer hurtigst muligt. Er det ikke muligt at fjerne en barriere, skal styregruppen acceptere, at det kan have konsekvenser for projektet. Det skal noteres i risikoanalysen, og potentiel effekt på business casen og gevinstrealiseringsplanen skal vurderes.

36 PROJEKTHÅNDBOG 36 Arbejdet med at håndtere barrierer kan omfatte, at: Model Styregruppens ansvarsmodel viser gruppens samlede ansvar for hver projektfase. Sikre mandat til at tage beslutninger i styregruppen Sikre afklaring af de forskellige interesser, der kan være mellem styregruppemedlemmerne specielt mellem leverandør- og brugerrepræsentanter Sikre de nødvendige faciliteter, projektet har brug for Beslut på stedet Det er vigtigt, at en styregruppe træffer beslutninger, når den mødes, og at projektet ikke ender i en venteposition, hvor beslutninger først skal træffes andet steds. Styregruppen skal bestræbe sig på at træffe beslutninger straks efter modtagelse af oplæg til beslutning fra projektlederen evt. via eller eventuelt møde afhængig af problemstillingen, såfremt det ikke kan vente til næste styregruppemøde. Styregruppen kan effektivisere processen ved at give klart mandat til projektejer og projektleder vedrørende beslutningskompetence, så fremdriften ikke i væsentlig grad afhænger af gentagne partshøringer for afgørelser, der omhandler forankring hos interessenter repræsenteret i styregruppen. Der er en række forudsætninger, som bør være på plads for at sikre, at styregruppen og dens medlemmer er beslutningsdygtige: Styregruppemedlemmerne skal tilsammen have de rette kompetencer og den nødvendige viden i forhold til projektets kompleksitet, leverancetyper, berørte forretningsområders ressortområde og forandringsledelse Der skal være en klart beskrevet beslutningsproces, der indbefatter, hvem der har ansvaret for at gennemføre de enkelte beslutninger, og hvordan der følges op på, om beslutningen giver det ønskede resultat Der skal etableres koordineringsmekanismer mellem styregruppemedlemmerne og deres bagland, som fungerer i dagligdagen, således at beslutninger kan træffes hurtigt og effektivt Hovedansvarsområder for styregruppen gennem projektets faser Styregruppen har ansvaret for projektets succes over for det overordnede ledelsesniveau (direktions-, portefølje - eller programledelsen) og er bemyndiget til at styre projektet inden for de rammer, den øvre ledelse har fastsat i projektoplægget. Ansvaret for styregruppen varierer alt efter hvilken fase, projektet befinder sig i. Styregruppens ansvarsmodel viser det samlede ansvar i styregruppen for hver fase, som projektet gennemgår. Formålet med modellen er i overbliksform at vise styregruppens væsentligste ansvarsområder på tværs af faserne. Som udgangspunkt etableres styregruppen i analysefasen, men det kan forekomme, at styregruppen allerede etableres i idéfasen. Modellen skal betragtes som rettesnor, og listerne med ansvarsområder må på ingen måde ses som udtømmende. Figur 21: Styregruppens ansvar i projektfaserne

37 PROJEKTHÅNDBOG 37 Etablere rammer for projektet Godkendelse af styringsmæssige produkter Konfliktløsning og sparring Godkende opdaterede styringsdokumenter Evt. vælge leverandør Afvigelseshåndtering Konfliktløsning og sparring Godkende opfyldelse af overdragelseskriterier Godkende opdaterede styringsdokumenter Afvigelseshåndtering Styregruppens ansvar overgår til gevinstejerne, som rapporterer til Digitaliseringsmatrixen, hvis der er afvigelser i planlagt gevinstrealisering Tidsstyring Økonomiog gevinststyring Kvalitetsog leverancestyring Ressourcestyring og organisering Interessentstyring Indsende gevinstrealiseringsrapport til Itprojektråd Risikostyring ift. gevinstrealiserings Risikostyring Sikre sammenhængende og troværdig tidsplan Godkend business case. Tjek plan for gevinstrealisering og sammenhængende leverancer Udfordre scope og løsningsdesign Sikre relevant organisering og bemanding Interessenthåndtering og kommunikation Sikre dækkende risikoanalyse Opfølgning på fremdrift ift. plan Løbende opfølgning på business case og earned value Godkende kravspecifikation, udbud og kontrakt Udvælgelseskriterier for leverandører Revurdere organisering og sikre fortsat bemanding Statusrapport Rammer for leverandørsamarbejde Aktiv opfølgning på risikoanalyse og fokus på reduktion af risici Opfølgning på fremdrift ift. plan Løbende opfølgning på business case og earned value Opfølgning på gevinstrealisering Sikre opfyldelse af forretningsmæssige behov Ændringshåndtering og prioritering Sikre organisering ift. leverandørorganisation Sikre ressourcer til drift og implementering Sikre godt leverandørsamarbejde Aktiv opfølgning på risikoanalyse og reduktion af risici Sikre måling af gevinster i henhold til plan Udarbejdelse af gevinstrealiseringsrapport Postkalkulation af business case Sikre forretningsvendte aktiviteter og leverancer som kan fremme realisering Evt. nedsætte gevinstrealiseringsorganisation Styregruppemøder Det er styregruppen, der beslutter, hvilke møder de ønsker at holde og hvor ofte. Disse formalia besluttes på et opstartsmøde for styregruppen. Der skal dog som minimum holdes møde ved alle faseovergange inklusiv ledelsesfaser. Styregruppeformanden har ansvaret for at indkalde til møderne. Ved faseovergang udarbejder og fremsender projektlederen en status- /faseovergangsrapport til styregruppen. Det er også projektlederens ansvar at fremsende eventuelle dokumenter som bilag til rapporten såsom risikolog, tidsplan og afvigelsesmodeller. Alle dokumenter er baseret på ajourførte versioner af de aftalte styringsdokumenter (f.eks. PID, business case mv.). Projektlederen vil typisk stå for gennemgangen af status-/faseovergangsrapporten, da han/hun besidder den detaljerede indsigt og forståelse for rapportens indhold.

38 PROJEKTHÅNDBOG 38 Det skal aftales, hvem der tager referat af mødet, og hvilken form referatet skal have f.eks. et beslutningsreferat. Kom godt fra start: Opstartsmøde for Styregruppen Ved start af analysefasen etableres styregruppen med deltagelse af seniorbrugere, seniorleverandør og andre som, styregruppeformanden mener, er nødvendige for, at styregruppen kan udøve sit ansvar i forbindelse med fastlæggelse af projektets grundlag. Styregruppen mødes og bliver enige om præmisserne for arbejdet i gruppen herunder roller og ansvar. Ved større projekter eller i tilfælde af etablering af en styregruppe bestående af mindre erfarne styregruppemedlemmer kan det være hensigtsmæssigt at lade opstartsmødet faciliteres af organisationens projektkontor eller tilsvarende. Løbende møder Der afholdes løbende styregruppemøder i projektforløbet, således at styregruppen kan understøtte faseovergangene og behovet for løbende beslutninger og rapporteringer i projektforløbet. Frekvensen kan svinge alt efter, hvor i projektfaserne man befinder sig i. Nogle styregrupper vælger at afholde faste forberedende styregruppemøder, hvor seniorleverandører ikke deltager. Behovet kan f.eks. opstå, hvis der er uenighed omkring fortolkningen af kontrakten, og kunden ønsker at diskutere sin position med de øvrige styregruppemedlemmer. Afslutningsmøde Hovedformålet med mødet er formelt at lukke projektet. Det kræver, at man på afslutningsmødet gennemgår og behandler følgende punkter: Sikrer at der ikke er udestående aktiviteter, leverancer og kontraktuelle forpligtelser i forhold til seniorleverandør eller seniorbruger Gennemfører evaluering af projektet Sikrer overdragelse til teknisk drift og vedligeholdelse Sikrer at seniorbrugeren tager ejerskab til at føre projektet ind i forretningsdrift og dokumenterer gevinstrealisering Da der er tale om formel lukning af projektet, er det vigtigt, at alle relevante interessenter er repræsenteret på mødet. Såfremt der er udeståender, og styregruppen trods dette vælger at lukke projektet, skal styregruppeformanden sammen med projektlederen sikre, at der udarbejdes en handlingsplan for håndtering af udeståender. Styregruppeformanden skal følge op på, at håndteringen af udeståender faktisk sker.

39 PROJEKTHÅNDBOG 39 Projekter med budget på mere end 5 mio. kr. Der stilles særlige krav til projekter med et budget på mere end 5 mio. kr. og projekter, der implementerer ny teknologi. Dette afsnit opsummerer disse krav. 5 mio. Projekter med et budget på mere end 5 mio. kr. skal risikovurderes af Itprojektrådet inden overgangen til anskaffelsesfasen. Inden risikovurderingen foretages, skal dokumenterne være godkendt i digitaliseringsmatrixen. Projekter med budget på over 5 mio. kroner eller ny teknologi Har projektet et budget på over 5 mio. kr., eller indeholder det ny teknologi, skal projektet risikovurderes i Københavns Kommunes It-projektråd. Forud for en eventuel risikovurdering tilbyder It-projektrådets sekretariat at vurdere, om det pågældende projekt opfylder kriterierne, der stilles til projekter, som skal risikovurderes. Det er derfor forvaltningens ansvar at tage kontakt til sekretariatet i god tid for at få en vurdering. Hvis det besluttes, at projektet skal risikovurderes fastlægges en dato for indsendelse af projektgrundlaget og igangsættelse af risikovurdering. Sekretariat kan hjælpe og vejlede i forhold til dokumentering af projektgrundlaget. Projektgrundlaget sendes elektronisk til It-projektrådets postkasse: ITprojektraad@ks.kk.dk på den aftalte dato senest kl. 12. Dokumenterne skal være godkendt af direktionen og digitaliseringsmatrixen samt af projektets styregruppe, før de sendes til It-projektrådet. Vurderingsgrundlaget For at skabe et godt vurderingsgrundlag bør forvaltningen sende følgende dokumenter om it-projektet til It-projektrådet: Business case (med tilhørende dokumenter/bilag) Projektinitieringsdokument (PID) herunder: - Risikoanalyse - Kvalitetsplan Såfremt man i forvaltningen gør brug af andre skabeloner/dokumenter, der kan erstatte ovenstående, kan disse sendes ind i stedet. For at der kan foretages en risikovurdering, er det dog vigtigt, at der er gennemsigtighed og struktur i dokumenterne, således at bagvedliggende økonomi og tidsplan er tilgængelig og forståelig. Løbende rapportering til It-projektrådet Forvaltningen skal løbende statusrapportere til It-projektrådets sekretariat. Statusrapporteringen sker via referater fra styregruppemøder samt via poverblik, hvor risikovurderede projekter statusopdateres i forhold til økonomi, tid og leverance. Forvaltningen skal tillige deklarere over for It-projektrådet, at projektet er afsluttet. Dette sker gennem den løbende statusrapportering. Der kan læses mere om It-projektrådet på deres hjemmeside.

40 PROJEKTHÅNDBOG 40 Opfølgning på gevinstrealisering i It-projektrådet Et år efter projektafslutning vil sekretariatet for It-projektrådet følge op på gevinstrealiseringen. Forvaltningen skal på det tidspunkt oplyse nøgletal om it-projektets gevinstrealisering til It-projektrådet.

41 PROJEKTHÅNDBOG 41 Journalisering i edoc For hvert projekt i SUF skal der oprettes et edoc projekt med minimum otte tilhørende sager. I dette afsnit kan du se strukturen i edoc. Figur 22: Standardstruktur i edoc for projekter Hvordan gør jeg? Først skal du oprette et projekt. Det gør du ved at trykke på knappen opret (symboliseret ved et plus). Herefter vælger du projekt. Nu skal du udfylde projektets titel og tilføje relevante projektdeltagere dette gøres under fanen yderligere sagsbehandlere. Navngivningen på projekter er CHR Relevant projektnavn Når du skal oprette et projekt til brug for projekter i SUF, er det vigtigt, at du husker at tilknytte den relevante proces til projektet. Processen sørger for, at du automatisk får oprettet de sager og dokumenter, du har brug for.

42 PROJEKTHÅNDBOG 42 Processen findes under Tilgængelige processer og hedder SUF Opret projekter, sager og dokumenter (se nedenstående billede). Tryk ok for at oprette projektet. Når projektet er oprettet, skal du sætte processen i gang. Dette gøres ved at stå på procesfanen i projektet (se nedenstående). Du sætter projektet i gang ved at trykke på de tre prikker for enden af teksten Start denne for at oprette sager og dokumenter. I menuen vælger du start funktion og herefter ja (se nedenstående).

43 PROJEKTHÅNDBOG 43 edoc vil nu automatisk oprette alle de sager og dokumenter, der ifølge projektmodellen skal oprettes. Disse oprettes med korrekte emneord og handlingsfacetter. edoc opretter følgende sager: CHR projekt Styringsdokumenter CHR projekt Analyser CHR projekt Anskaffelser CHR projekt Gennemførsel CHR projekt Gevinstrealisering CHR projekt Styregruppemøder CHR projekt Projektgruppemøder CHR projekt Arbejdssag Under disse sager opretter du relevante dokumenter. Ved oprettelsen af disse sager, vil du muligvis modtage otte mails i Outlook om, at du er blevet gjort ansvarlig for en ny sag. Disse mails kan du slette. Du får mailadviseringer, enten fordi en anden opretter sager i dit navn og/eller fordi, du har slået advisering til for administrative sager. Få overblik over projektet og sagerne Når sagerne og dokumenterne automatisk er oprettet, kan du gå i gang med at arbejde på dit projekt og lave de relevante filer. Hvis du vil have overblik over, hvilke sager og dokumenter der er oprettet, skal du i projektet gå ind på fanen Mere og vælge træstruktur. Når du har gjort dette, vil du få en oversigt over, hvilke sager og dokumenter der er i projektet. Du kan bruge den lille pil ud for projektikonet til at folde de forskellige niveauer ud.

44 PROJEKTHÅNDBOG 44 Hvordan opretter jeg endnu en sag til mit projekt? For at oprettet en ekstra sag på projektet, skal du gå over på fanen Sager i selve projektet. Her trykker du på knappen ny sag og opretter sagen som du normalt ville gøre. Når du opretter sagen under projektet, bliver den automatisk knyttet til dit projekt, og du kan se sagen sammen med de andre sager i træstrukturen. Hvordan opretter jeg en fil på dokumenterne i projektsagerne? Når du vil oprette en fil på de dokumenter, der er oprettet i dine projektsager, skal du stå på selve dokumentet. Dette kan du gøre ved at trykke på dokumentet i træstrukturen. Når du står på dokumentet, skal du: trykke på knappen opret ny fil ved hjælp af skabelon Vælg KK skabelon notat uden kolofon (word åbner) Vælg fanen edoc og tryk på Indsæt standardtekst Vælg biblioteket A digitale projekter, Std skabeloner mv. Vælg den wordskabelon som du skal bruge

45 PROJEKTHÅNDBOG 45 Hvordan sletter jeg en sag, jeg ikke skal bruge i mit projekt? Som udgangspunkt kan du ikke slette en sag i edoc. Men du kan fjerne sagens tilknytning til dit projekt. Herefter skal du huske at redigere og lukke sagen. For at fjerne en sag fra et projekt skal du ind og redigere i sagen. Via træstrukturen vælger du den sag, du vil fjerne. Når du står på sagen, skal du under funktioner vælge rediger egenskaber. Herefter åbner sagens egenskaber sig, og du kan redigere i egenskaberne: I titlen skal du skrive Annulleret sag I linjen Projekt skal du slette det projekt, der står på linjen Når en sag skal annulleres, skal du ændre dens emneord og handlingsfacet Emneordet ændres til: / Papirkurv Handlingsfacetten ændres til: G01 / Generelle sager Du skal trykke ok, og sagens egenskaber er ændret. Nu skal du lukke sagen. Gå ind under funktioner og vælg Arkivfunktioner og Sæt sagsstatus.