Smidig overgang fra prosjekt til forvaltning

Transkript

1 Smidig overgang fra prosjekt til forvaltning SBN BRUKERKONFERANSE, STAVANGER, 22. OKT JAN-OLAV ARNEGÅRD

2 Konflikt mellom prosjekt og forvaltning Tidspunkt for oppstart: Både prosjekteier og leverandør trykker på for å bli ferdig. Brukere vil ha mest mulig gjennomtestet system. Ressurskonflikt: Prosjektet trenger IT ressurser og forretningsressurser for å ferdigs>lle ak>viteter, mens forvaltning må få >d >l å lære opp supportorganisasjon. Kvalitetskonflikt: Prosjektet har fokus på kontraktsmessige kvalitetskrav, og innfører manuelle ru>ner (workarounds) for å kompensere for feil i løsning og funksjonalitet som ikke er på plass. Forvaltningsorganisasjon og brukerne vil ha en mest mulig stabil løsning og funksjonalitet som beskrevet i kravspesifikasjonen.

3 Hva er vellykket go live? q Løsning dekker krav og forretningsbehov q Brukere er klare >l å ta i bruk løsning q Få feil i løsning q Rask feilhåndtering q God implementeringsstrategi q God IT Governance

4 Smidig overgang til forvaltning krever fokus på Kontrakt: Gir kontrakten den nødvendige fleksibiliteten ved oppstart? Metode: Metode er nymg og vik>g, men må kombineres med sunn fornun og erfaring. Organisering i prosjekt: Hvordan kan prosjektet hjelpe forvaltning best mulig både før og eper oppstart? Organisering i forvaltning: Hvor bør forvaltning organiseres for å understøpe rask feilremng? Organisering i selskapet: Ansvar og myndighet knypet >l eierskap av data og endringer i løsning. Endringsledelse og forankring: Hvordan forberede organisasjonen?

5 Scope og kvalitetskrav Kontrakt Klassisk Scope avtales i kontrakt, og endres ikke i design eller implementeringsfasen. Kravene er gjerne detaljerte. Kriterier for ant feil ved oppstart følges i henhold >l kontrakt Smidig Scope vurdere løpende i prosjekt og det vurderes hva man trenger fra dag 1 i produksjon Det gjøres en vurdering av hvor kri>ske feil man kan leve med fra dag 1 og evt. workarounds

6 Brukeropplæring Metode Kontrakt Klassisk Opplæringsmateriell lages fra bunn, og er gjerne inndelt eper funksjonsområder. All opplæring er ferdig >l løsningen tas i bruk Smidig Bruk testscenarier som en del av opplæringsmateriellet. Opplæring så tep opp>l go live som mulig, og evt noe eper go live. Superbrukere spiller en veldig vik>g rolle i overgangen fra prosjekt >l forvaltning, og spesielt vik>g at disse får god trening.

7 Håndtering av feil i forvaltning Kontrakt Organi- sering Klassisk En forvaltningsavtale forutseper gjerne at man tar i bruk hele forvaltningsapparatet fra første dag. Fullstendige prosesser for feilhåndtering fra første dag i produksjon Det legges opp >l egen opplæring av forvaltningsorg. som belaster prosjektressurser Smidig Ta høyde for at prosjekt- organisasjon må bistå. En trinnvis innføring av ekstern forvaltning kan være best. Forenklet prosess for feilhåndtering en periode eper oppstart 2. og 3. linje support kan lære ved å delta i tes\asen i prosjektet. Men: Vik>g at ansvar roller og ansvar for feilhåndtering er tydelige og kommunisert godt >l prosjektet, forvaltningsorganisasjon og brukere.

8 Lessons learned Det er lep å sepe opp en plan og følge en metode. I virkelig verden må man noen ganger være lip mer pragma>sk å finne smidige løsninger som fungerer. q Forbered organisasjonen godt, både ledere og brukere. q Roller og >lgangsstyring er krevende, og må testes god go live. q Trekk inn >lstrekkelig antall dyk>ge forretningsressurser i prosjektet. q Etablering av IT governance er krevende og tar lang >d q Unngå en situasjon i forvaltning der ulike leverandører peker på hverandre når feil skal håndteres q Bruk av offshore support krever gjerne lengre innkjørings>d enn nearshore support og lokale ressurser q Unngå flere ulike systemer for feilhåndtering, det gir mye ekstra administrasjon q Legg et realis>sk løp for feilremng og releaser