Systemutvikling og prosjektstyring i staten Realisering av gevinster

Systemutvikling og prosjektstyring i staten Realisering av gevinster Temaer: IS og systemutvikling –ulike perspektiver og tenkemåter Systemutvikling og organisasjonsutvikling Prosjekt‐styring og gevinstrealisering Myndighet, ansvar og rollefordelingen Kvalitet og kvalitetsikring Litteratur Avison & Fitzgerald, kap. Kap. 1‐ 7, 10, 13, 15, 22‐ 24 Dahlbom & Mathiassen, kap. 1‐ 3, 9‐ 12 Veileder for prosjektstyring i staten : http: //www. prosjektveiviseren. no/ Flak (2012) Gevinst‐realisering og offentlige investeringar. Kap 1‐ 2, 7‐ 8 Jansen og Schartum (2008), kap. 5‐ 7. FINF- 4001, . Arild Jansen. AFIN 1

Store IKT‐prosjekter i staten: Samspill mellom teknologi, organisasjons og regelverksutvikling Politiske og rettslige endringer Organisatoriske og administrative endringer Teknologi/ IKT-utvikling Er ansvars‐ og arbeidsdelingen klar nok ? Er kunnskap og kompetanse på ulike nivåer tilstrekkelig? Og hva slags kompetanse er det behov for FINF- 4001. Arild Jansen. AFIN 2

Tradisjonell systemutviklingslivssyklus – Faser i systemutviklingsarbeidet: et teknologisk perspektiv Forstudie ‐ Foranalyse : Systemavgrensning og behovsanalyse Problem – og mulighetsanalyse ‐ avdekke problemer mm Se systemet utenfra og klarlegge behov og rammer : tekniske, organisatoriske, økonomiske, juridiske, sikkerhet Systemanalyse ‐> kravspesifikasjon Systemutforming : (design/konstruere) Realisering og implementasjon Bruk og drift , Videlikehold og videreutvikling Avvikling I hvilken grad er denne tenkemåten relevant for utvikling av ulike typer IS ? FINF- 4001 Arild Jansen. AFIN 6

Spiral‐» modellen» ‐ skjematisk skisse Fastlegge mål og rammer Analyse Vurdere alternativer, risikovurderinger Risikoanalyser Prototyping Vurdering Planlegge neste fase Krav utforming Utvikle neste produkt Agile systemutvikling (SCRUM etc. ) kan betraktes som varianter innenfor dette rammeverket, se http: //www. prosjektveiviseren. no/planleggingsfasen/smidig‐i‐planleggingsfasen 7

DIFI’s anbefalte rammeverk for IKT‐prosjekter http: //www. prosjektveiviseren. no/ Prosjektveiviseren hvor vi tilbyr et nettbasert veiledningsopplegg for gjennomføring av IKT‐prosjekter i offentlig sektor. Prosjektveiviseren skal bidra til bedre planlegging, gjennomføring og samordning av offentlige IKT‐prosjekter. Konsept Planlegge Gjennom‐ føre Avslutte Overleverer, evaluerer Realisere gevinster NB: PV er et ikke en modell for systemutvikling, men ramme verk for prosjekt-styring. Den kan også brukes ved smidig SU (SCRUM etc. ) FINF- H -12, . Arild Jansen. AFIN 8

Faser i SU-arbeidetendringer i organisasjonen (OU) (Prosjektveiviseren dekker ikke dette i særlig grad) Mens Prosjektveieviseren fokuserer på arbeidet i prosjektorg, gjelder organisasjonsutviklingen dvs. endringer i linjeorganisasjonen, som må skje parallelt med prosjektarbeidet Problemidentifisering &problemanalyse av nåværende organisering Beskrive (utforme) nødvendige organisatoriske endringer Fastsette mål og behov for endringsarbeid(styrt av politiske eller økonomiske hensyn) Nye rutiner, prosedyrer, ansvars‐ og beslutningsstrukturer etc. Beskrive opplæringsbehov Realisere og gjennomføre endringene Iverksette endringer I arbeidsformer, roller og ansvars mm Opplæring, motivasjon , . . FINF- 4001. Arild Jansen. AFIN 12

Viktige roller knyttet til store (IKT‐) prosjekter er knyttet til styring, ledelse og oppgavefordeling Prosjekteieren er «personen» (P‐styret) som blir utpekt som overordnet ansvarlig for at prosjektet når sine mål og leverer de forventede gevinster. Hvem som skal være prosjekteier, avhenger av prosjektet mål &fokus Prosjektlederen har myndighet og ansvar til å lede prosjektet og levere de produktene innenfor rammer som er definert av prosjektstyret. Scrumleder [simidige utviklingsprosjekter]: . Scrumleder er ansvarlig for tilrettelegging av teamets arbeid for å levere produkter i henhold til sprintplan Virksomhetsledelsen er den overordnede ledelsen som finansierer og tildeler prosjektoppdraget. [. . . ] Gevinstansvarlig : Er den rollen i linjeorganisasjonen som har ansvaret for at prosjektets gevinster blir realisert. [. . . ] Linjeorganisasjonen : Linjeorganisasjonen er basisorganisasjon hvor prosjektet har sitt mandat. Overtar prosjektets leveranser ved prosjektslutt. [. . . ] 13 FINF-4001 Arild Jansen. AFIN

Fra praksis til filosofi og tilbake til praksis FINF-4001 H -13, . Arild Jansen. AFIN 14

Systemer, perspektiver og tenkemåter Computer context, Systemtenkning (kap. 1‐ 3) Systemutvikling (kap. 4‐ 6) : Konstruksjon (spesifikasjonsstyrt), evolusjon (skrittvis, prøving og feiling), intervensjon (problem‐ og konflikt‐orientert, “Sammenbrudd” mm) Systemkvalitet (kap. 7‐ 9) Teknologi, data, informasjon og kunnskap Rasjonell versus romantisk tenkemåter “Dingser”, kultur & estetikk og makt & politikk Fra filosofi til praksis (kap. 12) Blant annet inspirert av Peter Checkland : Soft Systems Methodology (In System Thinking, Systems Practice) Den skandinavisk skole innen systemutvikling 15

Informasjonssystemet som skal tas i bruk: “Kalkulator”, informasjonsbehandler eller sosiale samhandling? To grunnleggende ulike perspektiver: Utgangspunktet er Descartes mekanistisk Utgangspunkt i organisk, dialektisk systemforståelse av virkeligheten’ Klar, eksakt og sann representasjon av ’Verden’ må forstås som helheter kan verden bare beskrives ved fortolkning Verden er stabil Virkeligheten er i stadig forandring ‐ Reduksjonisme, gjentagbarhet/ uforutsigbar‐ forkastbarhet Organisasjoner koordineres ved Verden oppfattes som en maskin ‐ f eks. uformell, direkte interaksjon mellom som byråkratier med formell medlemmene. arbeidsdeling og styring Datamaskinen som medium for menneskelig samhandling Den logiske, analytisk ’tenkende’ maskin (Babbage, Turing, von Newman) 16

Datamaskiner, informasjon og motsetning Datamaskinen : Informasjon Bygget på analytisk, matematisk‐logisk tenkemåte Forutsetter at både data (informasjon) og prosedyrer (algoritmer) kan representere gjennom en formalisert, entydig og presis form Forandring er forutsigbare (følger naturlover) Basert på arven fra rasjonalismen og tidlig naturvitenskap Motsetning Virkeligheten er opplevd, subjektiv og flertydig Hverken informasjon eller handlinger kan beskrives entydig og presist, men må forstås gjennom for‐ tolkninger og kunne representeres på flere måter Forandringer er uforutsigbare Basert arven fra romantikken Verdens (utvikling) er resultat motsetninger (konflikter) : Life is a struggle Hverken problemer eller løsninger kan identifiseres på forhånd, og endrer seg kontinuerlig Motsetninger/konflikter kan ikke løses, men må håndteres gjennom forhandlinger Inspirert av tenkningen hos 17 Hegel, Marx, Freud, . .

Noen ulike funksjoner /roller har IKT i organisasjoner og hvilke kvalitetskrav stiller vi ? IKT som (styrbart) verktøy til kontorstøtte, saksbehandling, mm IKT som hjelpemiddel for styring og kontroll IKT inngår som en forutsetning for tjenesteyting (IKT‐baserte produkter og tjenester) Maskin-metaphor : Kan utvikles og styres ved tradisjonelle metoder IKT utgjør en (informasjons) infrastruktur for Organisme-metaphor kommunikasjon og tilgang på offentlig informasjon Utfordrende både og utvikle IKT som basis for samhandling og samarbeid, både og å styre, krever andre tilinternt og ut mot publikum/næringsliv (Web 2. 0, . . ) IKT som støtte for demokratiske funksjoner nærminger Hvilke konsekvenser har dette for valg av SU‐strategi? 18

Ulike tilnærminger i utviklingsarbeidet Dahlbom og &Mathiassen , kap. 4‐ 6: Tre ulike tilnærmingsmåter for systemutvikling: Konstruksjon = Hard systemtenkning Antar verden er stabil og problemområdet veldefinert En rasjonell, analytisk topp‐down framgangs‐måte, Eks: Bassis programvare /infrastruktur‐løsninger Evolusjon = Myk systemtenkning Realistisk, helhetlig virkelighetsforståelse, usikkerhet , problemene eruklare Anvender eksperimentell strategi for systemløsning Bruker‐orientering, prosessorientering og læring Eks: Vanlige sluttbrukersystemer Intervensjon = dialektisk systemtenkning Problemet er ikke (klart) definert Utviklingsarbeidet kan ikke skilles fra løpende aktiviteter i organisasjonen Eks: Innføring av nye nettbaserte systemer, sosiale medier, 20

Myk systemutvikling som ’Evolusjon’ Tar utgangspunkt i : Realistisk og helhetlig problemforståelse Omgivelsene er dynamiske og uforutsigbare Flere mulige framgangsmåter Prototyping fram for fullstendige krav‐spesifikasjoner: Prøving og feiling - usikkerhet Bottom‐up‐tilnærming Brukerorientering ‐ brukerdeltagelse Vekt på prosessorientering og læring Men også Mindre vekt på planlegging og utforming Mer vekt på prosjektledelse ‐ samarbeid og koordinering Skrittvis utprøving og tilpasning av løsningen 22

Utviklingsarbeidet som ’Intervensjon’ Utgangspunkt Problemforståelsen springer ut fra situasjoner eller hendelser, både forventede og uforutsatte (f. eks. sykehus, flyplass) Problemområdet som datasystemet skal ’løse’ (understøtte) er uavklart Forståelse av ulike holdninger, roller og preferanser er viktige faktorer i utviklingsarbeidet Verden er full av motsigelser Brukerne er irrasjonelle, data er inkonsistente og organisasjoner er uforutsigbare Forberedt på at forandringer skjer løpende Forberedt å at systemer ikke [alltid] fungerer Tenk dere innføring av et (alt)omfattende system for arbeidsstøtte, registerings- og kalender mm i en virksomhet! 23

Pause: Refleksjon og diskusjon Hva har dere «lært» så langt i dag Hva savner dere (perspektiver, metoder, teknikker ) Er vanlige SU – rammeverk og metoder tilstrekkelige for større eforvaltningsprosjekter ? 24

Kvalitet og kvalitetssikring Teknisk, formell Kvalitet Opplevd kvalitet: (1) Et systems evne til å tilfredsstille de krav og forventninger og ønsker (2) Grad av systemets overensstemmelse med skriftlige spesifikasjoner (3) Forholdet mellom forventet og opplevd ytelse av et system subjektiv vurdering av den enkelte bruker eller aktør som er involvert Kvalitetssikring (engelsk Quality Assurance, QA) Arbeidet med planlegging, utforming, vedlikehold og kontroll som tar sikte på øke eller sikre kvaliteten av et produkt eller en prosess. 25

Hvorfor opplever at IKT‐systemer ikke fungerer i bruk? 3 nivåer av organisatorisk praksis 1. Formelle rutiner og prosedyrer 2. Oppfatningene blant de ansatte av hvordan arbeidet bør gjøres, dvs. tolkningen/forståelsen av rutiner og prosedyrer 3. Det faktiske adferden de har i arbeidet, den rotfestede praksis som utvikles over lang tid) For å endre organisatorisk praksis må alle 3 nivåene håndteres av systemene (ikke bare den formelle) Støtte for disse påstandene: Søderstrøm : Jævla drittsystem Mange systemer på nye områder – få standarder Taylorisme: Oppdeling &standardisering av arbeidsoppgaver (samlebåndsprinsipp) Elendig grensesnitt og dårlig interaksjon , mangel på opplæring Innkjøper (Økonomer/jurister) representere ikke bruker Byråkrati 2. 0 ……. 26

Ser leverandøren brukerne ? Typisk modell for innkjøp av nye systemer Leverandør Innkjøper (kunde) Ofte innkjøpsavdelingen! Bruker Det bør heller være slik : Innkjøper (kunde) LLeverandør Bruker 27

Ulike styringsnivåer i større [IKT‐] prosjekter (skjematisk ‐ i Systemutvikling (prosjekt) Programstyring Et system (prosjekt) Få aktører/roller: Prosjekteier. prosjektleder, «SCRUM-leder» , medlemmer Planlegging, utvikling og realisering Vil ofte primært ha et teknisk fokus, mindre på organisatoriske og rettslige aspekter Mandat og økonomiske rammer er gitt Flere systemer/ prosjekter Flere aktører: Programleder, Prosjekteier, [prosjektledere], . . Planlegging, utvikling realisering og implementering Samordne ulike delprosjekter Mer fokus på rettslige og org. spørsmål. , økonomistyring FINF-4001. Arild Jansen. AFIN Virksomhetsstyring Flere system En/flere eier‐ mange aktører Virksomhetsleder. Programleder, Prosjekteier Planlegging, [utvikling realisering, implementering] og gevinstrealisering Mest fokus på økonomi, prosjekt‐mandat, rettslige sp. og organisering 28

E‐Forvaltningsreformer i praksis. Hvilke gevinster får vi? Tema : Fra visjoner til mål, resultater og effekter – hva snakker vi om Hvilke mål skal vi oppnå og hvordan Hvordan skal vi kontrollere at målene er nådd FINF- 4001, Forelesning Arild Jansen. AFIN 29

Fra visjon til mål til resultater til effekter. Hvordan kommer vi dit? Tilsiktete Effekter = gevinster Visjoner Mål Resultater Utilsiktede effekter, både positive og negative Uønskede effekter (negative) Hvordan unngå at utilsiktede negative effekter og uønskede effekter reduserer/forhindrer ønskede gevinster? 30

Benefits Management Model (Ward og Daniel, 2006). Gevinstrealisering defineres som: ". . . prosessen med å organisere og lede slik at mulige gevinster fra bruk av informasjonssystemer / informasjonsteknologi faktisk realiseres. ". (J. Ward&Daniel, 2006) 31

Prinsipper (påstander) for gevinstrealisering Prinsipp 1: IT har ingen verdi i seg selv, ; men gevinster kan realiseres når IT brukes effektivt og lar virksomheter gjøre ting på nye måter. Prinsipp 2: Gevinster av IT‐investeringer er mer enn rasjonalisering. Prinsipp 3: Aktiv ledelse er nødvendig for å oppnå gevinster. Prinsipp 4: Det er den politiske og administrativ ledelses ansvar å realisere gevinster fra IT‐investeringer. Prinsipp 5: IT‐prosjekter er også organisasjonsutvikling. Prinsipp 6: Alle prosjekter gir resultater, men ikke alle resultater er gevinster 32

Samordnet opptak som en langvarig reformprosess Politiske og rettslige endringer Organisatoriske og administrative endringer Teknologi/ IKT-utvikling Prosjektene innebar betydelig organisatoriske endringer i arbeidsdeling mellom læresteder og SO‐sentralorg. Prosjektet var både styrt av og forutsatte endringer i lov og forskrift. Arild Jansen. AFIN 34

Samordna opptak ‐ fra kaos til automatisert opptak Bakgrunn og hovedidéer for Samordna opptak Rettslige utfordringer Ett søknadsskjema – en saksbehandling og ett tilbud Felles‐ samordnet sentral og desentralisert opptaksmodell Tilrettelegge for (nær) automatisert opptak Fleksibel modell som takler politiske reformer i utdanningssektoren Samordning av regelverket Tilrettelegge for automatiserte fortolkninger og beslutninger Tekniske hovedutfordringer Bygge ut en teknisk infrastruktur som understøtter samarbeid og fleksibilitet i saksbehandlertildeling Koding av opptaksregelverk ‐ delautomatisering av saksbehandling Koding og automatisert kontroll av elektroniske vitnemål fra vidg. skole FINF- 4001, . Arild Jansen. AFIN 35

Hovedmålene ved innføring av «NOM» i 1995 ble formulert i følgende hovedpunkter: Samordning og forenkling, men fortsatt desentralt opptaksansvar. Avgjørelsesmyndighet for opptak skulle fortsatt ligge på det enkelte lærested. Bedre tjenester ved å være oversiktlig og forutsigbart for søker, lærested og sentrale myndigheter. Forbedret kvalitativt opptak gjennom høy treffsikkerhet i opptaket, slik at flest mulig får tilbud på sitt primære studieønske så tidlig som mulig i opptaket. Effektiv ressursbruk gjennom forbedret samarbeid og eliminering av overflødig dobbeltarbeid (saksbehandling for hverandre). FINF- H -12, Forelesning 25. 9. 2012 Arild Jansen. AFIN 36

Utviklingen av SO gjennom samspill mellom rettslige, tekniske og organisatoriske faktorer Tilrettelegging av regelverk for automatisering, Felles U&H‐lov Harmonering av regelverket Legitimering av elektronisk vitemål og opptak Vedtak om nye skolereformer Elektronisk vitnemål Automatisert opptak Politiske og rettslige reformer Reorganisering av U&Hsektor : Etablering av SO‐prosjektet Enhetlig opptakssystem. Økt politisk styring og Teknologi myndighet Organisatoriske og administrative endringer Innføring av NOM‐struktur og samarbeidsmodell Etablering av felles opptakskontor Utvikling av felles teknisk og organisatorisk plattform FINF- H -12, Forelesning 25. 9. 2012 Arild Jansen. AFIN 38

Dynamikken i SO-prosjektet FINF- H -12, Forelesning 25. 9. 2012 Arild Jansen. AFIN 39

Suksess og fiasko i offentlige IKT‐prosjekter En oppsummering av forskningsbasert kunnskap og evidensbaserte tiltak (Prof. Magne Jørgensen, Simula research laboratory) Hva vil det si at et IKT‐‐‐prosjekt er en suksess? Prosjektsuksess handler om å levere avtalt funksjonalitet til avtalt pris og tidspunkt sett fra prosjektlederspektiv. Denne oppfatningen bør utvides med suksesskriterier fra oppdragsgiver og mottager av produktet. Suksesskriteriene i rapporten er: Levert nytte (kvalitet for brukerne og etaten) Teknisk kvalitet til produktet Kostnadskontroll i prosjektet Tidskontroll i prosjektet Effektivitet i prosjektarbeidet Et prosjekt kan være en suksess mhp en faktor, f eks at all planlagt nytte er oppnådd, men være mindre vellykket på andre faktorer, f eks store budsjettoverskridelser, lav effektiviteten 40 har, sprekk i tid, . .

Utfordringer og årsaker til «fiaskoer» (utdrag) Lav forståelse av kompleksiteten til systemet som skulle lages Liten evne til å stille kvalitetskrav, det vil si dårlig evne til å beskrive og evaluere ikke‐funksjonelle krav Problemer med kommunikasjon av krav mellom kunde og leverandør Manglende fokus på integrasjon og god system/portefølje‐arkitektur Manglende risiko‐ledelse og underestimering av risiko til prosjekter Manglende oppfølging/styring av prosjektene Manglende erfaring hos prosjektledelse, uklarhet i ansvarsforhold Manglende ledelsesfokus, (prosjekter ble sett på som et IKT‐prosjekt, ikke et omstillingsprosjekt med IKT‐utvikling som virkemiddel […. ] Liten evne/mulighet til å evaluere kompetanse til leverandører i anbudsprosess, som fører til valg av inkompetent leverandør 41

Kortfattet oppsummering En gjennomgang av forskningen gir at følgende forhold og tiltak synes å øke sannsynligheten for vellykkede IKT‐prosjekter Reduksjon i prosjekt størrelse , og dermed ambisjonsnivå per prosjekt, gjennom oppdeling av større satsninger i mindre prosjekter /leveranser Hyppige leveranser underveis i prosjektene Gjennomgående nyttestyring fra konseptanalyse, gjennom prosjektet og hos mottager av leveransene Bedre, utprøvingsbasert evalueringer og valg av leverandører Kontraktstyper som gir riktige insitamenter for leverandør. I særlig grad synes fastpris prosjekter i mange sammenhenger å være uegnet og føre til mindre grad av levert nytte i IKT prosjekter Omfattende medvirkning og god kompetanse fra kunde‐siden i prosjektet. Utviklingsprosesser som ser endringer i krav/mål som muligheter for økt nytte av IKT –leveransene, inkludert «smidige” utviklings‐prosesser Risiko og usikkerhetsanalyser for å skaper risiko‐bevissthet hos involverte aktører, god risikostyring og sikre at ambisjonsnivå ikke legges for høyt 42

Planlegging av store (IKT) prosjekter dreies seg i stor grad om styring, ledelse og ansvar Direktør Ida Børresen, tidligere UDI‐direktør på e. Forvaltningskonferanse 2011: Dersom jeg hadde problemer av økonomisk, lovgivningsmessig eller faglig karakter, kunne jeg ta dem opp med departementet, og få gode svar mer eller mindre på stående fot. Men når jeg ønsket støtte eller hjelp på IKT-området hadde jeg ingen å gå til. Fokus i departementet og kompetansen i departementet var på andre forhold, andre spørsmål FINF-4001 . Arild Jansen. AFIN 43

Noen erfaringer fra studie av prosjekt‐ og programstyring i praksis Resultatet av en undersøkelse i 2011‐ 2012 som analyserte 6 større, tverr‐etatlige (tverr‐sektorielle) prosjekter i forvaltningen : SL (skatte) og TVINN (Toll‐ og avg. ) under Finansdep. LØFT (Lånekassa) under Kunnskapsdep AUTOSYS (Veidir), under Samferdsels dep Effect (UDI) , under JD primært, men også DU og Aad Perform (Under gamle Fad Aad) Arild Jansen og Ivar Berg‐Jacobsen – Fra kontrollør til aktør: Behov for nye roller for fagdepartementene i styring av tverrgående IKT-prosjekter? Se: http: //complexserien. net/content/201201‐tre‐artikler‐om‐it‐styring‐i‐norsk‐forvaltning 44

Hovedbudskap fra rapporten Eierdepartementet generelt må ta en mer aktiv rolle i planlegging og gjennomføring av tverrgående IKT‐ prosjekter. Nødvendig med direkte involvering i på flere områder, både i den strategiske styringen (blant tilrettelegging av rammebetingelser som regelverk, finansieringsmodeller etc. ), og den operativ styringen. Eierdepartementet bør engasjere seg i alle fasene av prosjektet, også gjennomføring og implementering: Føle ansvar for at prosjektet ikke blir forsinket, ”rydde av veien” ulike typer hindringer, både rettslige, organisatoriske, ev. økonomiske mm. Øve påtrykk på andre departementer både vedr. finansiering, rettslige endringer, framdrift i prosjekter osv. I flere av prosjektene har eierdepartement vært seg bevisst denne rollen, men generelt er dette en svakhet