Guide til IT projekter i den fællesoffentlige projektmodel

DEN FÆLLESOFFENTLIGE PROJEKTMODEL Guide til IT projekter i den fællesoffentlige projektmodel Dato: 22.06.2015 Version: 1.0 1

Projektledelse af it-projekter Denne guide tager udgangspunkt i særlige forhold der gør sig gældende for arbejdet med it projekter i Selvstyret. Guiden skal ses som et supplement til (og forudsættes kendskab af) Den fællesoffentlige Projektmodel (FOP) som er beskrevet her. I nedenstående figur ses de aktiviteter der knytter sig til et projektforløb. De fremhævede punkter er særligt vigtige for it projekter. Ide Analyse Anskaffelse Gennemførelse Realisering Projektkommissorium Forundersøgelse Budgetplan Inddrag brugere Inddrag fagfolk Projektkommissorium Business Case v.1.0 Behovsafdækning baselinemåling Beskriv processer Inddrag brugere Inddrag it-drift Risikoanalyse Evt. risikostrategi Faseafslutningsrapport Business Case v.2.0 Udfærdig kravsspec. Inddrag it-drift Gennemfør testfase Inddrag it-jurist Gennemfør udbud Skriv kontrakt Faseafslutningsrapport Business Case v.3.0 baselinemåling Uddan brugere Planlægning af teknisk installation og fremtidig drift (fx patch updates) Support Forbered afslutning Overdrag produkter Projektafslutningsrapport Business Case v.4.0 Løbende uddannelse af brugere Bruger administration Support På mange måder udskiller et it projekt sig ikke fra andre projekter. Det handler også om mennesker og forandring. Der er dog en række øvelser der giver god mening at gennemføre for at sikre dig at dit it projekt kører på skinner. I følgende vil retningslinjerne for udbud, kontrakt, persondatasikkerhed og drift blive gennemgået. Personer (organisation) Processer (it) Produkt Er der indtænkt processer fra starten? Før man går i gang med at anskaffe sig et nyt it system, giver det god mening først at se på processerne og analysere hvilke forandringer i organisationen et nyt system vil medføre: Hvilke arbejdsområder bliver påvirket? Stiller processerne krav til systemet? Stiller systemet krav til processerne? Kan processerne effektiveres uden et nyt it system? 2

Det er en almindelig fejl, at antage at et it system i sig selv kan løse en given problemstilling/skabe en optimering, men ofte ligger den største del af gevinsten i at analysere strukturen, dvs. beskrive og dokumentere nuværende arbejdsprocesser (as is) og organiseringen heraf. Dette er en grundlæggende øvelse der ofte er forudsætningen for efterfølgende at kunne gennemføre en optimering af arbejdsgange (to be) og realisere de gevinster der er der tiltænkt med projektet. Lige så vigtigt er det at sikre, at de foreskrevne processer og den daglige praksis er det samme, og at medarbejderne ved hvordan processerne skal udføres. Er der indtænkt inddragelse af brugere fra starten? Generelt for it projekter bør brugerne inddrages i forbindelse med kravspecifikation og udviklingen af løsningen. Især i idé-, design- og testfaser er det vigtigt med brugerdialog til at definere konkrete behov og sikre brugervenlighed. Fx i forbindelse med funktionelle behov, use cases, brugervenlighedstest o.l. Det er vigtigt at undersøge de nuværende udfordringer på det område, som projektet skal lave om på. Ved at lytte til brugerne, kan man hurtigt finde ud af om problemerne skyldes det nuværende system (eller mangel på et), processerne eller manglende kompetencer hos medarbejderne. Valg af fremgangsmåde I mange it-projekter er det en betydelig udfordring at vælge fremgangsmåden: Skal der anskaffes en standardløsning og i givet fald hvilken? Skal der ske tilpasning eller udvikling af en standardløsning? Skal løsningen udvikles fra bunden? Hvilke teknologier skal der vælges? Skal opgaven outsources? Skal opgaven i udbud? Det er projektlederens ansvar at sikre at projektet får tilført den nødvendige viden. Her bør inddrages fagfolk enten fra organisationen eller udefra i det omfang som skønnes nødvendigt. Det er også projektlederens ansvar at sørge for at kortlægge om it arkitekturen i organisationen passer sammen med det system man vil anskaffe. Der kan i den forbindelse være uforudsete tekniske, eller sikkerhedsmæssige problemstillinger der kræver fagekspertise at kunne gennemskue. I støre komplekse projekter, eller projekter der er politisk følsomme, kan en ekstern kvalitetssikring (rådgivning) inddrages hvis behovet er der. Konsulenttimer er dyre, så foretag først en grundig vurdering af hvilken værdi det skal tilføre projektet, og om den ekstra budgetudgift kan forsvares. I Digitaliseringsstyrelsen råder man over specialister inden for drift, sikkerhed, jura og projektledelse, der kan være behjælpelig med sparing og generel kvalitetssikring af dit projekt. Forberedelser der bør gøres før nyt IT projekt igangsættes Opstil målepunkter for succes (se FOP guide) Er det nødvendigt at købe et nyt system? Findes der nogle systemer i organisationen allerede, der kan løse udfordringerne? 3

Overvej om dit nye system vil få konsekvenser for nuværende processer og systemer? 1. Vil andre systemer blive påvirket (uforudset dominoeffekt)? 2. Vil det medføre at processer påvirkes inden for andre forretningsområder i organisationen? Hvad med datakonvertering? Datakonvertering er ofte en stor økonomisk post i IT projekter. Er det tænkt ind i dit projektforløb, og er der budgetteret for disse omkostninger? Udbudsmateriale og kontrakt Når du vælger en udbudsstrategi giver det god mening at forholde sig til følgende tjekspørgsmål: Er der udarbejdet og godkendt et udbudsmateriale? Er der uddelegeret en ansvarshavende som procesansvarlig i forbindelse med udbudsprocessen og kontraktforhandlingen? Er juridisk (og gerne it-juridisk) kompetence bragt i spil i forbindelse med udarbejdelsen af udbudsmaterialet eller i review heraf? Har projektet indhentet viden om og erfaring fra lignende udbud - fra tidligere udbud i organisationen, fra andre organisationer og fra leverandører? Er leverandørmarkedet undersøgt, således at udbuddet passer til markedsvilkårene? Anbefalinger til god praksis: IT jura er en særlig disciplin, som ikke alle jurister kender til - inddrag i videst muligt omfang it-juridisk ekspertise. Digitaliseringsstyrelsen råder over en it jurist som kan gennemgå dine kontraktforhold. Lær af andres erfaringer - spørg i andre styrelser/departementer til erfaringer, hvis strategien indebærer en udbudsform, som egen organisation ikke har erfaring med. Indhent så meget leverandørviden som muligt - der er flere muligheder for at hente information fra leverandører end de fleste regner med. Der findes uvildige eksperter indenfor mange typer af systemer som f.eks. ERP, ESDH, CRM, som kan hjælpe med at lave en markedsanalyse og evt. med at vurdere tilbuddene. Tag udgangspunkt i en standardkontrakt. 1 Overvej hvilke rammer kontrakten sætter for arbejdsformen og overvej om det passer til projektet. F.eks. vil et agilt projekt stille nogle andre rammer til en kontrakt end et vandfaldsprojekt (metode). Overvej, hvilke kontraktmæssige forbehold fra leverandøren, som kan accepteres og hvilke som ikke kan. Forbered relevante bilag til kontrakten: Definitioner Hovedtidsplan Kundens it-miljø (it-infrastruktur beskrives) Løsningsbeskrivelse/kravsspecifikationer 1 Se evt. Statens og Kommunernes Indkøbs Service, som har lavet en lange række standardkontrakter på IT området http://www.ski.dk/ 4

Servicebeskrivelser Organisation og processer Servicemål Afprøvning Priser og betalingsplan Optioner Kundens ydelser Sikkerhed Ophørsassistance Afklaringsrapport Databehandleraftale (Selvstyrets instruktion til leverandørens it-sikkerhedsprocedure) Test af teknisk implementering Tjekspørgsmål: Er der gennemført tilfredsstillende stresstest af systemet i et omfang, som sandsynliggør en tilstrækkelig god driftsperformance? Er alle driftsmiljøer etableret og testet? Er alle integrationer til andre systemer testet tilstrækkeligt og med ønsket resultat? Er driftsprocedurer beskrevet og testet? Er der udarbejdet en plan for overdragelsestest? Er der udarbejdet plan for backup, restore og evt. roll-back? Anbefalinger til god praksis: Der bør være en fall back plan - hvad gøres, hvis funktionalitet ikke virker eller ikke kan anvendes? Det vil være god skik at vurdere, om enkelte dele kan pilles af uden at forstyrre helheden eller om det ved nye systemer er muligt alene at fjerne adgangen til funktioner frem for at rulle dem helt tilbage. Der skal aftales form på indberetninger af fejl/uhensigtsmæssigheder. I forhold til integration af løsning med eksisterende programpakker kontroller da, at alle installerede versioner er kompatible med løsningen. Implementeres der i forhold til slutbrugere, kontroller da løsningen på flere platforme (Windows, Mac, Linux, ios, Android) og i flere browsere og versioner. 5

ER DER STYR PÅ DRIFT? Det er vigtigt at lave et setup hvor løsningerne kan driftes, supporteres og vedligeholdes efterfølgende: Er krav til driftsmiljøet veldefineret (beskrives i udbudsmateriale og kontraktforhold)? Er driftsleverandøren inddraget? Er dokumentation til driftsløsningen på plads? F.eks. installations og driftsvejledninger. Er der taget stilling til hvem der skal supportere systemet? Er der taget stilling til hvem der skal håndtere brugeradministration? Er der lagt planer for vedligeholdelse (fejlrettelse, opdatering m.v.)? I forbindelse med kontraktskrivningen skulle en del af disse forhold allerede være gennemgået sammen med en it-jurist (i form af det indsendte bilagsmateriale). 6