Strategiske valg i styring av IT-programmer

Presentasjon om: "Strategiske valg i styring av IT-programmer"— Utskrift av presentasjonen:

1 Strategiske valg i styring av IT-programmer
Kjetil Strand, Promis AS Temadag om prosjektporteføljer

2 Fokus: IT-programmer i offentlig sektor
IT-program: En samling av flere større og mindre parallelle IT-prosjekter i samme organisasjon og for å oppnå en strategisk målsetning (eks: oppfylle økonomireglementet i staten) Erfaringer konsentrert om noen store IT-programmer i offentlig sektor Fokus på strategiske valg som går igjen i styringen av slike IT-programmer Temadag om prosjektporteføljer

3 Store IT-programmer i offentlig sektor
Aetat: SIAMO (ferdigstilt i årene ) Skattedirektoratet: SKARP (i gang) Forsvaret: GOLF (i gang) Lånekassen: LØFT (nettopp startet opp) RTV: Moderniseringsprogram, inkludert ny pensjonsreform (underveis) Temadag om prosjektporteføljer

4 Temadag om prosjektporteføljer
Noen felles parametre Store omstillingsprogrammer både med tanke på teknologiske løsninger og organisasjon IT-løsninger migreres fra stormaskinmiljø til relasjonsdatabaseplattformer Vesentlig innslag av saksbehandling, arbeidsflyt, regelanvendelse og dokumentarkiv Økonomiløsninger med reskontro, hovedbok og grensesnitt til bank (ut- og/eller inn-betalinger) Selvbetjeningsløsninger over internett Datavarehus med definerte og ad-hoc rapporter, ledelse- og informasjonssystemer Økonomiske rammer mellom 250 og 1000 MNMOK Temadag om prosjektporteføljer

5 Strategi for styring av IT-programmer
Langs hvilke akser (dimensjoner) er det vesentlig å treffe gode valg? I dette foredraget er det dette som oppfattes som hovedspørsmålet En god strategi for styring av et IT-program vil avhenge dels av Identifikasjon av de vesentlige dimensjonene Avveining av faktorene som spiller inn for beslutning i hver dimensjon Temadag om prosjektporteføljer

6 Temadag om prosjektporteføljer
Hva er dimensjonene? Make or buy? (strategi for anskaffelser og utkontraktering) Valg av styringsmodell (antall nivåer og grad av integrasjon) Systemlandskap eller monolittisk løsning? Standard eller skreddersøm? Migrering i faser eller big bang? Fastpris, målpris eller løpende timer? (strategi for kontraktsformer) Fossefall eller agilitet? (strategi for gjennomføringsmetodikk) Prinsipper for gevinstrealisering, omstilling, kost-nytte-analyser Prinsipper for kompetanseheving, opplæring, forvaltning Interessentanalyse og strategi for informasjon og kommunikasjon Prinsipper for kvalitetstyring (teststrategi, konfigurasjonsstyring…) Prinsipper for kostnadsstyring, risikohåndtering, endringshåndtering Temadag om prosjektporteføljer

7 Temadag om prosjektporteføljer
Make or buy? Dette er kanskje det vanskeligste strategiske valget – man ønsker å bruke og bygge opp kompetansen innomhus, men må samtidig se sine egne begrensninger klart i øynene Vil man ha en totalleverandør på IT-siden (GOLF) eller selv spille rollen som systemintegrator (SIAMO)? Valget henger naturlig sammen med dimensjonen systemlandskap – monolittisk løsning Et strategisk valg bør også skjele til driftssituasjonen – hvis organisasjonen tenker ASP, kan det være kostnadseffektivt å kontraktere ut systemutvikling, innføring og applikasjonsdrift under ett (i form av avtalte opsjoner) Rammeavtaler med huskonsulenter vs. separate kontrakter med systemleverandører: Ikke binde for mange internt! Markedssituasjonen kan spille inn for valg av strategi Temadag om prosjektporteføljer

8 Valg av styringsmodell
En programdirektør med et programkontor Helst ikke mer enn ett nivå over dette (egen styringsgruppe for hele programmet) Funksjonen ekstern kvalitetssikring: På hvilket nivå? Prosjektene i programmet: Speilet organisering kunde – leverandør, eller fullintegrerte team? Egne styringsgrupper for hvert prosjekt med representasjon fra prosjekteier, leveranseansvarlige og prosjektlederne? Et avklart forhold til linjen mht. ressurser og roller Et avklart forhold til de ansattes fagforeninger Egen problemstilling for statlige etater: Forholdet til departementet, rapportering og kvalitetssikringsfunksjoner Temadag om prosjektporteføljer

9 Systemlandskap eller monolittisk løsning?
To hovedalternativer: Alt løses i samme system; ERP eller ”standard” pensjonssystem Etablere et systemlandskap som spiller sammen for å løse de ulike oppgavene Ingen integrasjonsproblemer, sikrer bruk av konsistente data. Kompleks løsning både i utvikling, drift/forvaltning og fleksibilitet for endringer. Ytelse kan bli en utfordring. Sårbarhet Enklere oversikt over systemløsning og dataflyt. Bruk av standardløsninger der det finnes og minimere behov for skreddersøm. Enklere i utvikling og forvaltning, mindre sårbart. Krever konsistent datamodell og standardisering av grensesnitt. Temadag om prosjektporteføljer

10 Standard eller skreddersøm?
Ingen enkle svar på dette – anbefales å benytte prekvalifisering, tilbud og forhandlinger fullt ut for å avgjøre spørsmålet i det enkelte tilfellet Markedet kan vise seg å tilby kostnadseffektive systemløsninger som både er mer eller mindre modularisert enn det kunden hadde sett for seg (eks. integrert saksbehandlingsverktøy med arbeidsflyt, regelmotor og arkivløsning) En modularisert løsning med anskaffelse av standard komponenter er i utgangspunktet å foretrekke dersom alt annet holdes likt Man må uansett regne inn en betydelig kostnad til tilpasning av standard komponenter, samt systemintegrasjon Temadag om prosjektporteføljer

11 Temadag om prosjektporteføljer
Faser eller big bang? Dersom programmet omfatter overgang til ny systemplattform (eks. fra stormaskinn til relasjonsdatabase), bør det etableres en egen strategi for migrering Ad faser: Tryggere innføringsløp (sprer risikoen), alltid en fallback mulighet, bevisst bruk av læring underveis, men vanskeligere (og dyrere?) teknologisk (må sikre synkron kjøring av to miljøer i en overgangsperiode) Ad big bang: Stor risiko knyttet til ’D-dagen’ (oppstart), bratt læringskurve, får ikke gjenbrukt erfaringer underveis i programmet, men sparer kostnadene knyttet til parallell kjøring Temadag om prosjektporteføljer

12 Fastpris, målpris eller løpende timer?
Fast pris: Knyttet til avtalt omfang Løpende timer (regningsarbeid): Fakturerer løpende timer og andre kostnader Målpris: Justeres med incentiver og sanksjoner Temadag om prosjektporteføljer

13 Temadag om prosjektporteføljer
Fast pris prosjekter Bruksområder: Leveranser som kan spesifiseres veldig nøye Leveranse av standardiserte løsninger Fordeler og ulemper: Forutsigbar pris (men det kan løpe på endringer) Kan gi omfattende kontraktsadministrasjon Lite rom for erfaringsbaserte justeringer underveis Leverandøren vil snevre inn omfanget Leverandøren vil benytte billigst mulig ressurser Kunden vil få levert mest mulig innenfor fastprisen Temadag om prosjektporteføljer

14 Temadag om prosjektporteføljer
Løpende timer Bruksområder Leveranser som ikke kan spesifiseres detaljert Prosjekter med stor usikkerhet (eks. F&U) Konvertering, rapportutvikling Fordeler og ulemper Kan bli kostbart uten sterk kostnadsstyring Kan gjøre erfaringsbaserte justeringer underveis Lite kontraktsadministrasjon og endringshåndtering Leverandøren vil selge flest mulig timer Kunden vil gjennomføre godt nok med lavt ressursforbruk Temadag om prosjektporteføljer

15 Temadag om prosjektporteføljer
Målpris – en mellomvei Bruksområder Systemutvikling basert på relativt godt spesifisert behovsanalyse Godt nok grunnlag for realistiske estimater Erkjennelse av at krav og prioriteringer kan endre seg underveis Fordeler og ulemper Relativ forutsigbarhet mht. kostnader Klare leveranseavtaler mht. omfang og kalendertid Rom for erfaringsbaserte justeringer i iterasjoner Støtter integrert samarbeidsmodell Felles incentiver om å levere kvalitet til tid og kost Temadag om prosjektporteføljer

16 Parametre for å vurdere kontraktsform
Fordeling av risiko kunde - leverandør Kompleksitet i produkt og prosess Horisont (veldefinert omfang?) Avhengighetsforhold kunde/leverandør Partenes mulighet for å styre prosjektets rammebetingelser Temadag om prosjektporteføljer

17 Typiske prosjekter for ulike kontraktsformer
Standard programvare eller system med lite eller ingen brukerinteraksjon – eks tilpasning av nytt lønnssystem Programvare for å understøtte virksomhetens forretningsprosesser, kanskje i parallell med pågående organisasjonsutvikling i virksomheten Konvertering fra ett eller flere av kundens tidligere fagsystemer til nytt system Temadag om prosjektporteføljer

18 Fossefall eller agilitet?
Fossefall: Detaljert kravspesifikasjon – akseptanse blir knyttet opp mot denne Agilitet: Iterativ og inkrementell systemutvikling, sterk kundeinvolvering, signert akseptanse av funksjonelt innhold underveis Ad fossefall: Egner seg for prosjekter der det er stor forutsigbarhet mht. funksjonelle krav og måling av disse Ad agilitet: Egner seg i alle andre tilfelle Temadag om prosjektporteføljer

19 Prinsipper for gevinstrealisering
Man bør kvantifisere effektene av IT-programmet som basis for løpende kost-nytte-vurderinger gjennom programmet Det bør tas stilling til i hvilken grad gevinster kan tas ut underveis i programmet, blant annet ved å frigjøre ressurser i linjen til arbeid i programmet, eller frigjøring av midler til investeringer Omstilling kan bety mannskapsreduksjoner, og programmet må etablere retningslinjer for ressurshåndtering, omplasseringer, kompetansetiltak, utfasing og evt. sluttpakker Temadag om prosjektporteføljer

20 Prinsipper for opplæring og forvaltning
IT-programmer innebærer nye måter å arbeide på, nye roller og prosesser og nye krav til kompetanse Opplæring i forbindelse med innføring av nye IT-løsninger blir nesten alltid undervurdert Man bør vurdere om opplæring skal organiseres som et eget prosjekt i IT-programmet Man bør også vurdere om systeminnføring skal organiseres som et eget prosjekt. Her kan inngå konvertering, godkjenningsprøver, ytelsestesting, databasefunksjoner Forvaltning og systemeierskap er også ofte undervurdert. En godt planlagt overføring til linjen, for eksempel i form av et eget mottaksprosjekt, er vesentlig for at IT-programmet skal ha suksess Temadag om prosjektporteføljer

21 Informasjons- og kommunikasjonsstrategi
IT-programmet må etablere en egen strategi for informasjons- og kommunikasjonsarbeid Dette bør baseres på en grundig interessentanalyse: Hvem er det som har direkte eller indirekte interesser av programresultatene? Eksempel: Kundeorganisasjonen, prosjektdeltakerne, leverandørene, departementet, fagforeningene, brukerne av IT-løsningene, evt. klientene som bruken av løsningene er rettet mot Strategien bør videre bygge på en SWOT-analyse av interne og eksterne forhold: Styrker og svakheter, muligheter og trusler En hovedutfordring er forventningsstyring Målene for strategien bør være å skape engasjement om programmet internt, og mobilisere ambassadører for programmet Avklare hvem uttaler seg om hva, samt rapporteringsveier Temadag om prosjektporteføljer

22 Prinsipper for kvalitetssikring
IT-programmet må avklare funksjonen for ekstern kvalitetssikring, hvor denne er forankret og i forhold til hvilket nivå den skal fungere (eks. oppdrag fra eier av programmet, funksjon overfor styringsgruppen(e)) IT-programmet bør etablere en samlet test-strategi IT-programmet bør etablere felles prinsipper for konfigurasjonsstyring, bygging og leveranser (felles tool?) IT-programmet bør etablere felles standarder for dokumentasjon av kode, systemer, drift og bruk IT-programmet bør etablere felles kjøreregler for interne revisjoner, og arbeidsdelingen mellom leverandørenes kvalitetssikringsfunksjoner og kundens interne og eksterne kvalitetssikringsfunksjoner Temadag om prosjektporteføljer

23 Andre styrende prinsipper
Felles prinssipper for kostnadsstyring (anbefales basert på WBS, periodiserte budsjett, EVM og rapportert vha. S-kurver) Felles prinsipper for rapportering generelt og timebruk spesielt (krav til bruk av samme tool for timeføring?) Felles prinsipper for risikohåndtering (anbefales basert på risikomatrisen, ukentlig oppdatering og handlingsplaner ved risiki over <4,4>) Felles prinsipper for omfangsstyring og endringshåndtering (små og store endringer, regime for prioritering, definerte prosesser, roller og eskaleringsrutiner, mandater for hhv. prosjektledere, endringsråd og styringsgruppe) Vurdere eget prosjekt for utvikling og vedlikehold av kundens forretningsdata (’faste registre’, ’faglige kodeverk’) Vurdere eget prosjekt for anskaffelse av teknisk infrastruktur Temadag om prosjektporteføljer