TJEKLISTE TIL IT-PROJEKTER OG PROGRAMMER VERSION 1.0

Transkript

1 TJEKLISTE TIL IT-PROJEKTER OG PROGRAMMER VERSION 1.0 Denne tjekliste er udarbejdet på baggrund af de erfaringer IT-projektrådet har fra arbejdet med risikovurderinger. Tjeklisten skal ikke ses som en endelig liste, men som en samling af punkter der ofte er relevante at medtage i store it-projekter og programmer og kan bidrage til projekternes succes.

2 Læsevejledning Denne tjekliste er opdelt ud fra de fem vurderingsemner, som IT-projektrådet gennemgår ved risikovurderinger af it-projekter og programmer. De fem vurderingsemner er; Forretningsmæssige forhold, Governance, Projektets tilrettelæggelse, Markedsafdækning og teknisk løsning samt Slutbruger og slutprodukt. Indholdet i tjeklisten er baseret på IT-projektrådets erfaringer med, hvilke risici der ofte ses i de digitaliseringsprojekter, der risikovurderes. De forskellige emner og underkategorier skal ikke ses som adskilte, men som et forsøg på at opdele de komplekse dele der alle supplerer hinanden i et itprojekt eller program. Tjeklisten kan anvendes som en måde at sikre, at projektet kommer godt rundt om de emner, der erfaringsmæssigt er vigtige for projektet at få afklaret. Tjeklisten kan anvendes på forskellige tidspunkter i projektet, men ved afslutningen af analysefasen, bør projektet kunne besvare mange af punkterne i tjeklisten og have forholdt sig til centrale områder som: Business casen og gevinstpotentialer Organisering og projektmodel Implementeringsovervejelser og tilrettelæggelse Kendskab til markedet Teknologiske overvejelser og potentielle tekniske løsninger Slutprodukt ved overgang til drift og når løsningen tages i brug. Side 1 af 12

3 Indhold Forretningsmæssige forhold... 3 Formål og scope... 3 Gevinster og succeskriterier... 4 Business case... 4 Procesafdækning... 4 Governance... 5 Projekt-/programstyring... 5 Interessenthåndtering... 5 Koordinering og afhængigheder... 6 Styregruppe... 6 Leverandørstyring... 6 Projektets tilrettelæggelse... 7 Projekt- og ledelsesdokumenter... 7 Tidsplan... 7 Risikostyring... 8 Ressourcer og kompetencer... 8 Implementeringsstrategi... 8 Erfaringsudveksling... 8 Markedsafdækning og teknisk løsning... 9 Markedsafdækning... 9 Teknisk løsning... 9 Tekniske krav Mobility Slutbruger og slutprodukt Test Slutprodukt Slutbruger Side 2 af 12

4 Forretningsmæssige forhold Forretningsmæssige forhold dækker over projektets succeskriterier, formål, business casen og procesafdækningen og er det område, hvor IT-projektrådet identificerer flest risici og giver flest anbefalinger. Fokus på projektets forretningsmæssige formål og succeskriterier giver projektet et solidt fundament til at planlægge leverancer og til at tydeliggøre og kommunikere projektet overfor omverdenen. I forbindelse med projekternes business case anbefaler IT-projektrådet ofte, at projekterne løbende opdaterer business casen og at denne anvendes aktivt i styringen af projektet. Ligeledes anbefales mange projekter at nedskrive forudsætningerne for beregningerne i business casen. I forbindelse med procesafdækning ser IT-projektrådet ofte at der mangler klarlægning af nuværende og fremtidige processer, hvilket kan resultere i, at man anskaffer en løsning som ikke er optimal, eller at organisationen ikke er parat til at anvende løsningen. Formål og scope Er den overordnede strategi 1 for projektet/programmet kendt og passer den med den overordnede strategi for forvaltningen? Er der en klar beskrivelse af projektets/programmets formål og den forretningsmæssige begrundelse 2 for projektet/programmet? Er der sammenhæng mellem formål, scope og løsningen/slutproduktet? Er valgene for scopet af projektet/programmet begrundet (fx hvilke forretningsområder berøres og hvilke berøres ikke af projektet?). Er projektets leverancer beskrevet og prioriteret? Er det kortlagt og tydeligt beskrevet, hvilke forandringer projektet medfører? 1 Overordnet set kan en strategi betegnes som fastsættelsen af virksomhedens langsigtede mål. Alt det virksomheden ønsker at blive, og de mål virksomheden ønsker at nå. Det er forskellige fra forvaltning til forvaltning om der arbejdes med strategier, visioner eller politikker og om de udarbejdes på forvaltnings-, enheds- eller afdelingsniveau. 2 Den forretningsmæssige begrundelse for projektet tydeliggør projektets værdi for forretningen, og hvordan projektets gennemførelse understøtter myndighedens strategiske mål, politikker og/eller vision. Side 3 af 12

5 Gevinster og succeskriterier Er projektets/programmets succeskriterier tydelige (succeskriterier bør være konkrete, realiserbare, målbare og relateret til formålsbeskrivelsen)? Er der udarbejdet en gevinstrealiseringsplan (bør minimum indeholde; gevinster, gevinstejere, relaterede handlinger og succeskriterier)? Er gevinsterne nedbrudt og kvantificeret i tilstrækkelig grad (fx kan gevinsterne nedbrydes på enkeltstående aktiviteter og leverancer)? Er det tydeligt beskrevet, hvor og hvornår gevinsterne hentes? Er der indlagt plan for løbende at følge op på, hvorvidt gevinsterne og succeskriterierne er indfriet/opnået? Business case Er projektets/programmets finansieringsgrundlag beskrevet? Er budgettet og regnskabet gennemsigtigt med fremadrettede indtægter og udgifter, samt forudsætningerne herfor? Er udgifterne nedbrudt til håndgribelige aktiviteter og leverancer? Er der afsat tilstrækkelige midler til implementerings- og forandringsfasen samt drift? Er der aftale med styregruppe om aktiv anvendelse af business casen samt løbende opdatering heraf? Procesafdækning Er ændringerne mellem nuværende og fremtidige arbejdsgange klarlagt (fx ved hjælp af as-is og to-be beskrivelser)? Er der sikret mandat til at vedtage/indføre nye processer/arbejdsgange (særligt vigtigt ved processer som vedrører flere afdelinger/forvaltninger)? Er håndtering og organisering af nye arbejdsgange beskrevet? Side 4 af 12

6 Governance Governance indebærer den overordnede styring og organisering i og af projektet/programmet. Det drejer sig om rolle- og ansvarsfordeling både i projektgruppen og i styregruppen. Ligeledes indebærer det interessenthåndteringen og herunder også koordinering og afhængigheder til andre projekter og forretningsmæssige forhold. Når det drejer sig om projektorganiseringen, ses det ofte, at udviklingsprojekter eller store implementeringsopgaver blandes sammen med den daglige driftsstyring. En sådan organisering kan virke hensigtsmæssig, da de driftsansvarlige ofte besidder den største viden om dagligdagen, men det kan også øge risikoen for, at projektet eller implementeringen nedprioriteres i forhold til driftsopgaver, hvormed projektets gevinster kan blive svære at indfri. Leverandørstyringen er også en del af governance. Projektet bør her kigge på, om leverandørstyringen er forankret på så højt et niveau, at beslutningsgangen ikke bliver for lang, da det kan være med til at forsinke projektet/programmet. Hvis der arbejdes agilt og eller udvikles i samarbejde med leverandøren, bliver evnen til hurtig beslutningstagen endnu vigtigere. Projekt-/programstyring Er der en tydelig defineret projekt-/programstyring (ved programmer er det vigtigt med klare snitflader mellem programstyregruppe og projektstyregrupper, herunder hvilken styregruppe der har mandat til hvad)? Er der en projektorganisation med tilknyttede og dedikerede ressourcer? Er roller og ansvar i projektorganisationen defineret (også i forhold til snitflader mellem den projektejede forvaltning og eventuelle eksterne samarbejdspartnere)? Interessenthåndtering Er interessentanalysen gennemarbejdet (er projektejer, projektgruppe mv. inddraget i udarbejdelsen af analysen), og indeholder den en plan for håndtering af interessenter? Er der tydelige kommandoveje og eventuelle kanalstrategier til de definerede målgrupper? Side 5 af 12

7 Er der udarbejdet en kommunikationsplan med beskrivelse af kommunikationsform til både interne og eksterne interessenter? Koordinering og afhængigheder Er afhængigheder og snitflader til andre projekter eller programmer (intern og ekstern) afdækket? Koordineres der med projekter og opgaver, der har indflydelse på projektet/programmet? Styregruppe Er styregruppen forankret på det rette niveau i organisationen (ved store og/eller strategiske investeringer evt. i direktionen)? Er styregruppen sammensat af de rette personer og roller? Er roller og ansvar tydeligt defineret i styregruppen (fx ved at udfylde en styregruppeaftale) og udfylder medlemmerne rollerne? Er opdelingen mellem projektstyregruppe og programstyregruppe beskrevet, særligt i forhold til hvem der har hvilket beslutningsmandat? Er der fastsat hyppighed for faste styregruppemøder og eventuelt rammer for afholdelse af ekstraordinære styregruppemøder? Leverandørstyring Er der udarbejdet et setup for leverandørstyring (ved flerleverandørstrategi, er det vigtigt at være særlig opmærksom på ansvarsfordelingen)? Er leverandørstyringen og relationen forankret på det rette niveau i projekt-/programorganisationen? Er der klare og målbare krav til leverandør(erne)? Er der foretaget en afvejning af fordele og ulemper i forbindelse med ansvarsoverdragelse af vigtige opgaver til leverandør(er)? Er roller og ansvar afstemt med leverandør(erne)? Side 6 af 12

8 Projektets tilrettelæggelse Projektets tilrettelæggelse dækker over de gængse projektledelsesopgaver. Det vedrører selve projektdokumentationen, aktivitetsplanlægningen, estimering og tidsplan. Ligeledes dækker det over identificering og sikring af de rette kompetencer og ressourcer samt vidensdeling og erfaringsudveksling, internt som eksternt. Alle disse forhold anbefales at afspejle den valgte projektmetode (fx om der arbejdes ud fra en vandfaldsmodel eller om der arbejdes agilt). Implementeringsstrategien og forandringsledelsen er også en del af projektets tilrettelæggelse. Erfaringsmæssigt kræver store forandringer, at man helt fra start af projektet påbegynder forandringsledelsen og overvejer den rette implementeringsstrategi, hvis man vil sikre de bedste chancer for en succesfuld implementering. Projekt- og ledelsesdokumenter Er der aftale med projektejer og styregruppe om, hvilke projekt- og styringsdokumenter der arbejdes med i projektet/programmet og at disse holdes opdateret? (Fx: business case, økonomistyring, projektinitieringsdokument, slutproduktbeskrivelse, risikolog, styregruppeaftale osv.) Er der afstemt tolerancer i forhold til tid, økonomi og scope for projektlederen? Er der behov for separate styrings- og projektplaner for delprojekter i et program? Tidsplan Er der indsamlet nok data til at udarbejde en realistisk tidsplan (fx ved inddragelse af it-arkitekt, udbudsjurister, mobility teamet, slutbrugere, testmanager osv.)? Er tidsplanen nedbrudt på aktivitets- og leveranceniveau? Er der områder, hvor det ikke er muligt at nedbryde tidsplanen og hvor der anvendes skøn, og medfører det særlige risici? Er der indarbejdet buffere i perioder, hvor der erfaringsmæssig fremkommer forsinkelser (fx ved beslutningsfaser, integrationer, test, osv.)? Side 7 af 12

9 Hvad er tolerancerne i tidsplanen og holdes tidsplanen opdateret? Er projektets/programmets kritisk vej identificeret? Risikostyring Er der udarbejdet en risikostyringsstrategi samt løbende opfølgningen med styregruppe/projektejer på risikooversigten? Er risikovilligheden afstemt med styregruppe? Er der udarbejdet mitigeringsplan for alle risici? Ressourcer og kompetencer Er de kritiske kompetencer og ressourcer til projektgennemførsel identificeret (fx it-arkitekter, fagpersoner, it-sikkerhed osv.)? Er de nødvendige ressourcer og kompetencer til rådighed (forventningsafstem vedr. ressourcetræk- og behov med de forskellige enheder)? Er juridisk rådgivning inddraget tidligt i forløbet (særlig vigtigt ved udbud)? Implementeringsstrategi Er implementeringsstrategien indarbejdet fra start af projektet/programmet (kan udfoldes og nedbrydes løbende)? Er behovet for forandringsledelse klarlagt og drøftet i styregruppen/andre relevante fora? Er lokale forandringsagenter inddraget aktivt og tidligt i forløbet? Bakker ledelsen op om forandringsindsatsen og er de rigtige ledelsesniveauer inddraget? Er der afsat tid til evalueringer efter hver delimplementering? Er der defineret succeskriterier for implementeringen? Erfaringsudveksling Er det undersøgt om andre afdelinger i KK har gennemført lign. projekter/udbud som man kan drage erfaringerne fra? Er der hentet erfaringer fra øvrige kommuner og/eller virksomheder som har relevant viden? Side 8 af 12

10 Markedsafdækning og teknisk løsning Markedsafdækning og teknisk løsning relaterer sig til projektets/programmets løsning. Det vedrører kravene til løsningen, funktionelle såvel som nonfunktionelle, samt overvejelser vedrørende teknologivalg og mobile løsninger. Alt efter omfanget af løsningen er der flere overvejelser, som er vigtige at forholde sig til. I relation til markedsafdækningen, viser erfaringerne, at mange går i gang med dette, før de egentlig har taget stilling til, hvad deres behov er. En tidlig markedsafdækning kan være velegnet, når det handler om at hente inspiration fra andre, men er sjældent den bedste måde at få afdækket konkrete spørgsmål i forbindelse med den løsning, som udbydes. Man kan her overveje en fremgangsmåde med flere runder i markedsafdækningen. Flere og flere projekter i Københavns Kommune gør sig gode erfaringer med at offentliggøre udbudsmateriale i en ikke endelig version, så markedet får lov at kvalificere materialet, før man går i udbud. Markedsafdækning Er der udarbejdet et konkret formål med markedsafdækningen, herunder hvilke spørgsmål man ønsker afklaret? Er det undersøgt hvorvidt eksisterende systemer/løsninger i KK kan anvendes? Er der tænkt på implementering af demoversioner fra leverandørerne? Er der gjort overvejelser om at offentliggøre udbudsmateriale i v. 0.8 (der kan hentes erfaringer fra KOMBIT i denne forbindelse)? Er der hentet erfaringer/referencer fra kunder af eksisterende løsninger? Teknisk løsning Er der foretaget en behovsafdækning, der tydeliggør behovet for den tekniske løsning? Er løsningens sammenhæng og relationer til andre systemer beskrevet (fx i form af et samlet målbillede for arkitekturen)? Er der overvejelser om at lave særskilte pilotprojekter (gerne så tidligt som muligt)? Side 9 af 12

11 Kan løsningen implementeres i faser? Er opgaver relateret til konfigurering, integrationer, datakonvertering etc. tydeligt beskrevet? Er man særlig opmærksom på it-sikkerhed og persondataforordningen? Tekniske krav Er både funktionelle og non-funktionelle krav klarlagt? Er der gjort overvejelser i forbindelse med krav til bl.a.: Driftsmiljø, nyt hardware, internetforbindelse, integrationsbeskrivelser, datatyper, dataudveksling, oppetider, support, fall back plan, responstider, konfigurering? Er Kravbankens krav anvendt, hvor det giver mening? Er de tekniske krav realistiske i forhold til de løsninger som findes på markedet? Mobility Har forvaltningen en devicestrategi, hvis ja, er der så taget udgangspunkt i denne? Er der taget stilling til behovet for en mobil løsning? Er Mobility teamet i Koncern IT inddraget for rådgivning og videndeling? Side 10 af 12

12 Slutbruger og slutprodukt Slutbruger og slutprodukt vedrører inddragelse af slutbrugeren samt beskrivelsen af slutproduktet. Det indbefatter også test af løsningen. Projekterne/programmerne mangler ofte at afsætte tid og ressourcer til testforløb, hvormed risikoen for at gå i drift med en løsning der indeholder fejl er større, end hvis der løbende testes på slutproduktet. Vedrørende fokus på slutbrugeren, er det vigtigt i en offentlig kontekst at have for øje, at der kan være to eller flere grupper af slutbrugere, som fx borgere og sagsbehandlere. Disse to grupper af slutbrugere kræver forskellige tilgange, hvorfor det bliver endnu vigtigere at definere, hvordan de forskellige kategorier af slutbrugere inddrages. Test Er der udarbejdet en teststrategi og testplan(er), herunder inddragelse af testmanager? Er der afsat tid i tidsplanen samt ressourcer til testforløb? Er der planlagt pilottest og/eller gjort overvejelser om test i lukket miljø forud for implementering? Er det overvejet om der skal foretages brugervenlighedstest som en del af tilbudsevalueringen eller acceptkriterier? Er der beskrevet klare end-to-end godkendelseskriterier for test? Slutprodukt Er slutproduktet tydelig beskrevet? Er acceptkriterier for slutproduktet defineret? Er der forståelse for løsningens kritikalitet for forretningens arbejde? Er der sammenhæng mellem det definerede forretningsbehov og slutproduktet? Slutbruger Er slutbrugeren inddraget løbende i processen? Er de forskellige grupper af slutbrugere defineret? Er slutbrugernes serviceoplevelser medtaget i opfølgningen på projektet/programmet? Side 11 af 12

13 SPØRGSMÅL TIL TJEKLISTEN? Du er altid velkommen til at kontakte IT-projektrådets sekretariat. Mail: Telefon: / Side 12 af 12