Hva skal til for å lykkes med ITprosjekter

Transkript

1 Hva skal til for å lykkes med ITprosjekter i offentlig sektor? Econas nettverk for offentlig ansatte /osloakershus /econaoffentligansatte /

2 Magne Jørgensen Simula Research Laboratory University of Oslo Scienta

3 Hva vil det si å lykkes? Suksess er kontekstavhengig, men ofte en prioritert kombinasjon av: Oppnådd nytte (gevinster, måloppnåelse, ROI) Prosjekteffektivitet Funksjonalitet Kostnadskontroll Tidskontroll Tekniske produktegenskaper (kvalitet, utvidbar, bærekraftig)

4 Undersøkelse 2004 Undersøkelse 2014

5 Hvor god er offentlige sektor til å levere nyttige IT-løsninger? Av alle offentlige IT-prosjekter som startes så er det 5-10% som stoppes før de blir fullført. Av offentlige IT-prosjekter som fullfører er det: Ca. 35% som oppfattes å levere svært bra eller bra mhp nytte. Ca. 60% som oppfattes å levere akseptabelt mhp nytte Ca. 5% som oppfattes å levere vesentlig mindre nytte enn planlagt. Rundt halvparten av alle offentlige (og private) ITprosjekter får store problemer på enten kundenytte, kostnadskontroll, tidskontroll, kvalitet eller effektivitet

6 Hvordan bli (enda) bedre?

7 Del store prosjekter opp i mindre

8 Store prosjekter gir høyere risiko for fiasko, (men de store som fullfører gjør det like bra) < 10 mill mill > 100 mill Nytte 31% 47% 35% Kvalitet 24% 28% 25% Budsjett 24% 47% 47% Tid 29% 35% 35% Effektivitet 24% 12% 24% Ingen klar sammenheng mellom budsjett-størrelse og andel prosjekter som er suksessfulle av de som fullfører. MEN, de store (> 100 mill) er sterkt overrepresentert i gruppen av fiaskoprosjekter, dvs prosjekter som aldri blir fullført eller som leverer så å si ingen nytte! (2-3 ganger hyppighet). Tidobling av størrelsen ser ut til å doble risikoen for fiasko. God støtte for å dele opp store satsninger i mindre prosjekter.

9 Unngå fastpriskontrakter

10 Unngå fastprisprosjekter! (stort sett ) Fastpris Per time Smidig Risikodeling Nytte 0% 59% 29% 22% Kvalitet 22% 24% 43% 22% Budsjett 33% 31% 71% 22% Tid 11% 29% 43% 44% Effektivitet 0% 19% 29% 33% Andel 18% 37% 14% 41% Hvorfor gjør IT-prosjekter med fastpris det så dårlig?

11 Dybdeundersøkelse av 35 offentlige IT-prosjekter Fastpris ga oftere oppførsel og kundestyring etter kravspesifikasjon (kontrakt), og mindre etter nytte. Mekanismer: Vinnerens forbannelse, opportunistisk oppførsel ved fare for tap + fokus på spesifikasjon i stedet for nytte ( fastprisoppførsel ), adverse selection Unngå fastprisoppførsel, velg kontrakter basert på per time betaling, smidig kontrakter eller målpris uten tak

12 Fastpris gir dessuten mer administrasjon Ahonen, Jarmo J., et al. "Reported project management effort, project size, and contract type." Journal of Systems and Software 109 (2015): Fixed price Per hour

13 Vær smidig på en riktig måte

14 Smidig utvikling med hyppige leveranser til kunde og fleksibilitet i innhold gjør det bra NB: Dersom et prosjekt var smidig men IKKE hadde fleksible leveranser, eller IKKE hadde hyppig leveranse til kunde, gikk det dårligere enn i ikke-smidige prosjekter.

15 Endringshåndtering og suksessrate I hvilken grad ble behov, krav eller løsninger endret underveis i prosjektet som et resultat av eksterne endringer eller læring innad i prosjektet? I stor grad Nytte 67% (suksessrate) 21% Kvalitet 53% 13% Budsjett 47% 27% Tid 33% 25% Effektivitet 33% 10% I liten grad/fraværende Endringer bør sees på som muligheter, planlegges for (smidig) og ikke anses som trussel (ref. scope creep -holdning).

16 Vær en kompetent og involvert kunde

17 Vanskelig å lykkes uten en kompetent og involvert kunde (tre undersøkelser) Undersøkelse 1: Dybdeundersøkelse Alle de mislykkede prosjektene hadde en kunde uten særlig grad av egen IT-kompetanse og/eller en kunde som i liten grad hadde involvert seg i prosjektet. Høy kompetanse og involvering var i seg selv ingen god indikator på prosjektsuksess!? Undersøkelse 2: Spørreundersøkelse Dersom kunden var tett involvert i å: 1) Prioritere krav og ta viktige avgjørelser underveis og 2) Fokusere på nyttestyring underveis i prosjektet, lyktes 66% av prosjektene svært godt. Der ingen av disse var tilstede i vesentlig grad, lyktes kun 14% av prosjektene svært godt. Undersøkelse 3: Data mining av offshoringsprosjekter Lav suksessrate på tidligere prosjekter hos kunde og leverandør (indikator på lavere kompetanse) like sterke indikatorer på prosjektfiasko. Kundes kompetanse like viktig som leverandørens!?

18 VEKTLEGG NYTTESTYRING

19 Noen nyttestyring-praksiser er mer viktige enn andre

20 Oppsummert

21 Evidensbaserte tiltak for å lykkes 1. Oppdeling av større satsninger i mindre prosjekter/leveranser. 2. Hyppige leveranser til produksjon (i det minste til grundig evaluering og feedback). 3. Gjennomgående nyttestyring, fra konseptanalyse, gjennom prosjektet og hos mottager av leveransene. Særlig viktig: Plan for og underveis nyttestyring. 4. Bedre, utprøvingsbaserte, evalueringer og valg av leverandører, f eks trialsourcing. 5. Kontraktstyper som gir riktige insitamenter for leverandør. Unngå fastpris og målpris med øvre tak. 6. Omfattende medvirkning og god kompetanse fra kunde-siden underveis i prosjektet. Gjelder særlig på underveis prioriteringer og nyttestyring. 7. Utviklingsprosesser som planlegger for og ser endringer i krav og målsetninger som muligheter for økt nytte av IKT-leveransene. 8. Vektlegging av risiko og usikkerhetsanalyser for å skape risikobevissthet hos involverte aktører, god risikostyring og sikre at ambisjonsnivå ikke legges for høyt

22 EKSTRA

23 Mye av de samme faktorene i 1967 som i Hvorfor klarer vi ikke å lære av tidligere feil? Hva betyr faktorene? Og er det de riktige faktorene? To typiske undersøkelser om årsaker til at IT prosjekter mislykkes Gotterer 1967 Oxford-McKinsey 2012 Lack of support from top management Lack of competent software professionals Changing technology Changing user requirements Insufficient project management Unclear objectives Lack of business focus Shifting requirements Technical complexity Unaligned team Lack of skill Unrealistic schedule

24 Noen IT-kunder lykkes oftere enn andre IT-Offshoring (undersøkelse av småprosjekter): Den halvparten av kundene som hadde lykkes best med tidligere prosjekter, hadde ca. 50% lavere risiko for å feile i neste prosjekt. Den halvparten av leverandørene som hadde lykkes best med tidligere prosjekter, hadde også ca. 50% lavere risiko for å feile i neste prosjekt. Kundeegenskaper like viktige som leverandøregenskaper? Stor ulikhet mellom hvor ofte kunder fra ulike land/kulturer feiler (data fra samme offshoring-undersøkelse) Leverandør i Ukraina: Prosjekter med indisk kunde feilet mer enn dobbelt så ofte som prosjekter med norsk kunde (30% vs 13%) Leverandør i India: Prosjekter med indisk kunde feilet ca. 25% oftere som prosjekter med norsk kunde (37% vs 29%) til tross for samme nasjonale kultur. India-India kombinasjonen var den 122. verste av 127 kundeleverandørkombinasjoner (mellom land med mer enn 100 prosjekter). Verste var kunde fra Malaysia og leverandør fra India.

25 Hvorfor går det så mye dårligere med fastprisprosjektene?

26 ERFARINGER FRA EDAG-PROSJEKTET OG ETABLERINGEN AV A-ORDNINGEN Torstein Hoem november

27 Agenda A-ordningen EDAG-prosjektet Oppsummert 2

28 A-ordningen 3

29 Verdikjeden i a-ordningen

30 Konseptforståelse for samordningen A-opplysningsloven og tilhørende særlover A-meldingen Avlønning, ansettelse fastsettelse, kontroll statistikkproduksjon Lønnsystem, Altinn, mottakssystem, fagsystem Lover og forskrifter Semantikk Prosesser Teknisk Denne typen samordning krever topplederforankring 5

31 A-opplysningsloven Opplysningsplikten 3: Ligningsloven 5-2 Skattebetalingslove n 5-11 Svalbardskatteloven 5-2 (5) Folketrygdloven 24-2, 25-1 (2) og Statistikkloven 2-2

32 Fra 5 skjemaer til en melding Terminoppgave forskuddstrekk og arbeidsgiveravgift Melding til Aa-registeret Lønns- og trekkoppgave (årlig) Oppgave til lønnsstatistikk Årsoppgave for arbeidsgiveravgift 7

33 EDAG prosjektet 8

34 Modningsprosessen Grunnlaget blir lagt i tidlig fase Konseptforståelse Lær av andre det er alltid noen som gjort lignende før Harmonisering regelverket, slik at det er mulig å bygge en løsning som gir gevinster

35 EDAG-prosjektet ( ) Tverretatlig; Skatt, NAV, SSB og Brreg (Altinn) 150 prosjektdeltakere/619 millioner i styringsramme Produkt: innføring av a-ordningen med nytt regelverk, ny systemløsning, nytt forvaltningsapparat Målgruppe: 35 lønns- og personalsystemleverandører / arbeidsgivere 10

36 Målsetninger Samfunnsmål Målet for a-ordningen er å samkjøre myndighetenes krav til å gi opplysninger om inntektsmottakere, ansettelses- og lønnsforhold med mer, slik at de opplysningspliktige kan følge opp disse kravene så enkelt som mulig. Dette skal gi betydelige effektiviseringsgevinster for arbeidsgiverne, legge grunnlaget for en mer effektiv forvaltning og på sikt større forvaltningsreformer. Effektmål 1 A-ordningen skal gjøre det mindre ressurskrevende å gi pliktige opplysninger til myndighetene om inntektsmottakere, deres ansettelses- og inntektsforhold med mer Effektmål 2 A-ordningen skal bidra til økt effektivitet og bedre oppgaveløsning i de tre etatene. Effektmål 3 A-ordningen skal legge grunnlag for bedre tjenester fra det offentlige overfor inntektsmottakere og opplysningspliktige

37 Prosjektet Tilnærming Organisering og samarbeid Løsning Innføring Juridisk 12

38 Organisering og samarbeid Ekstern kvalitetssikring EDAG Styringsgruppe (BRREG, DIFI, NAV, SKD, SSB) EDAG fagråd EDAG Hovedprosjekt Ass. HPL Controller MAG Regelverk Løsning Innføring Forvaltning NAV Mottak SKD Mottak SSB Mottak MAG Utvikling MAG Test MAG Miljø

39 = Leveranseansvar = Rapportering Organisering og samarbeid Ekstern kvalitetssikring FIN Kontaktforum FIN, ASD, NFD, KMD ASD FIN NFD Etatsledermøtet Skattedirektøren SKD Prosjekteier Ekstern kvalitetssikring EDAG Styringsgruppe (BRREG, DIFI, NAV, SKD, SSB) EDAG fagråd EDAG Hovedprosjekt NAV Styringsgrp SKD Styringsgrp SSB Styringsgrp Brreg MAG Systemutvikling Regelverks utvikling Innføring Forvaltning NAV Mottak SKD Mottak SSB Mottak

40 Organisering og samarbeid Etatene Ett felles, eksternt mål: Forenkle for næringslivet En enkel finansieringsmodell Topplederforankring og eierskap i etatene - førsteprioritet Tett dialog med departementene Faste uformelle møter på alle nivåer 15

41 Organisering og samarbeid Samfunnet Fagråd med interesseorganisasjonene (NHO, IKT Norge, NKK, Regnskap Norge, ledere fra SKD, NAV, SSB, BBREG) Løpende dialog og møter med fagfolk fra lønnssystemleverandørene om løsningsutforming Faste orienteringsmøter med samtlige lønnssystem 16

42 Samarbeid i prosjektet Størst mulig grad av samlokalisering Tett operativt samarbeid mellom hovedprosjekt og mottaksprosjekt og mellom hovedprosjekt og MAG Tverrfaglighet juridisk/løsning/utvikling 17

43 Løsning Systemutviklingen og styring av brukerkrav Overordnet funksjonelt bilde, detaljer underveis Solid konseptforståelse hos «alle» Krav med høyest nytte utvikles først Revidering av nytte og gjenstående scope Nyttevurdering av kanaler Høy fokus på time-to-market Fra produksjonssetting 4 ggr/år til 2 ggr/uke 18

44 Innføring Tett samarbeid med prosjektets interessenter Endringsnettverket mot arbeids-givere Markedskunnskap Tett samarbeid med systemleverandører Interesseorgani-sasjoner invitert inn tidlig i prosessen 19

45 Styrt og faseinndelt innføring HØST 2013 VÅR 2014 HØST 2014 VÅR 2015 Skape interesse og bevisstgjøre Skape forståelse og handling Utdypende informasjon og støtte Hjelp og støtte Holde oppdatert «Forhold deg rolig» «Gjør deg klar» «Vær klar!» «Rapporter!» Besvar: Besvar: Besvar: Besvar: Hva er a-ordningen? Når kommer det? Hva må jeg gjøre av forberedelser og når? Hvordan tilpasser jeg meg? Spørsmål om rapportering

46 Prøvedrift i 2014 den virkelige testen Samtlige lønns- og personalsystemleverandører deltok 200 arbeidsgivere med spesialoppfølging arbeidsgivere deltok totalt Kontinuerlig analyse av datakvalitet og systemtilrettelegging basert på funn 21

47 Risikostyring og beslutningspunkter - Selvevaluering, kvalitetssikring, forankring - 22

48 Oppsummert 23

49 Oppsummert Modning av konsept Forstå helheten ordningen skal inngå i Kjenn djevelen i detaljene Snakk med de der ute som kjenner virkeligheten Organisering og samarbeid Topplederforankring. Fasiliter uformelle arenaer. Vær tett på virkeligheten 24

50 Oppsummert Regelverk Regelverksutvikling regelverksutvikling regelverksutvikling Begynn tidlig. Fortsett. Tverrfaglig samarbeid Løsning Bygg den enklest tenkelige løsningen som fungerer for normaltilfellene. Gjør den god. Bygg resten. Innføring Test løsningen på virkeligheten 25

51 26

52 Videreutvikling og bruk 27

53 Gjenbruk i samfunnet Effektiv rapportering til det offentlige Datakvalitet Bedre tjenester fra det offentlige Økt effektivitet og bedre oppgaveløsning i etatene 28

54 Resultater i

55 Grunnlag for oppdatering av Aa-registeret Grunnlag ved beregning av ytelser Sykepenger Foreldrepenger Uføretrygd Pleiepenger Dagpenger Kontrollformål

56 Tidlig tilgang til inntekt og trekkinformasjon Fokus tidlig i verdikjeden, tidligkontroller for å få korrekte data med en gang Grunnlag for Skattekort Selvangivelse Skatteoppgjør Arbeidsgiveravgift Forskuddstrekk Kontrollformål

57 Grunnlag for Lønnsstatistikk Sysselsettingsstatistikk Sykefraværsstatistikk Statistikkene gir grunnlag for Lønnsoppgjør Konjunkturovervåkning Forskning Politiske beslutninger

58 Opplysningspliktige fordelt på kanal - mai 2016 (%) A02 system A04 forenklet A05 forenklet A01 Altinn portal Papir unike opplysningspliktige har sendt inn for 2015 per

59 Inntektsmottakere per kanal - mai 2016 A02 system (98,91 %) A04 forenklet (0,07 %) A05 forenklet (0,01 %) A01 Altinn portal (1,00 %) Papir (0,01 %) 34

60 Leveranser på papir A101 levert på papir

61 Innrapportering volumer på frist 2015/