Ledelse av IT-prosjekter Et spørsmål om å håndtere usikkerhet og risiko 22. Mars 2016 Bo Hjort Christensen Sivilingeniør/Bedriftsøkonom Høyskolelektor; Handelshøyskolen BI Institutt for ledelse og organisasjon Bedriftsrådgiver BHC A/S bo.h.christensen@bi.no 1
Prosjektkategorier Sosiale plattformer Skytjenester Digital samhandling DIGITALISERINGSPROSJEKTER In Memory Analyse Mobilitet Robotisering 2
Utfordringens fundament 3
Utskifting av ERP anno 2017 Forskningsarbeid utført ved Cracow University of Economics, Poland av PhD Piotr Soja, 2006 Success factors for ERP implementation: Utskifting av ERP-systemer er per definisjon en risikoaktivitet. Dette må reflekteres både i kontrakter, budsjetter, planer og prosjektets styringsmodell The factors that have the greatest influence on implementation are: System reliability Team involvement Team composition Work Time Schedule Co-operation with supplier Top Management Support 4
Det handler om kompetanse Professor Linda Lai på BI 1: Ledere må ha nødvendig innsikt eksisterende og fremvoksende teknologiske plattformer og verktøy 6: Ledere må ha evne til å bruke digitale teknologi som en integrert del av lederskapet 5
Rapport: Kartlegging av hindre for digitale forretningsprosesser (KPMG-2014) Oppsummering av funn knyttet til hindre for digitalisering på overordnet nivå «Myke hindre» 4,4 4,1 4,0 3,7 3,6 3,5 3,4 2,7 Manglende standardisering Kompetansehindre Organisatoriske hindre Kulturhindre Juridiske/ Regulatoriske hindre Økonomiske hindre Teknologiske hindre Andre hindre 6
Hvordan lykkes vi ERP-implementeringen? Kost Årsaker til kostoverskridelser: 1. Utvidelse av scope (24%) 2. Uventede tekniske eller organisasjonelle problemer (21%) 3. Underestimert bemanning (19%) 4. Nye krav 5. Urealistisk budsjett 6. Økt kost pga tidsoverskridelser (8%) Årsaker til tidsoverskridelser: 1. Data/Masterdata problemer (15%) 2. Utvidelse av scope (14%) 3. Uventede organisasjonelle problemer (12%) 4. Uventede tekniske problemer (12%) 5. Urealistisk plan (11%) 6. Prioritetskonflikter (10%) Tid 7
7 virkemidler for å håndtere usikkerhet og risiko 1. Benytte en dialogbasert anskaffelsesmodell 2. Skarpere evaluering av leveranseteamet forut for kontraktsinngåelse 3. Bryte opp kontrakten i delleveranser som f.eks. reflekterer release-utviklingen 4. Etablere rollen som prosjektkontroller 5. Etablere en metode for oppfølging og presentasjon av ressursinnsatsen i prosjektet (ETC-EAC) 6. Benytte en smidig utviklings/innføringsmodell 7. Redusere omfanget av sanksjoner i kontrakten fordi det kan virke kontraproduktivt mht å nå kvalitetsmål. 8
Disse vanskelig ERP-prosjektene Styringsgruppen Prosjekteier (Leder i styringsgruppe) Prosjektsekretær Prosjektcontroller Kvalitetsrevisor Leverandørens deltaker Prosjektleder Leverandørens prosjektleder Løsningsarkitekt Løsningsarkitekt Samarbeid - kommunikasjon Samarbeid - kommunikasjon Samarbeid - kommunikasjon Samarbeid - kommunikasjon Samarbeid - kommunikasjon Delprosjektgruppe: Delprosjektgruppe: Delprosjektgruppe: Samarbeid - kommunikasjon Prosesser/rutiner Styringsmodell Kodeplaner/grunndata Organisasjon Kompetanse Motivasjon Teknisk infrastruktur Konvertering Integrasjoner Konsulenter: Konfigurering Konsulenter: Opplæring Konsulenter: Installasjon ERP-prosjekter er en særegen type prosjekt som i økende grad preges av et svært tett samarbeid i alle faser av prosjektets gjennomføring f.eks. som følge av en smidig (agil tilnærming) Det må være den profesjonelle leverandørens ansvar å veilede kundene i hvordan denne type prosjekter organiseres og styres. 9
Djevelen ligger i detaljene Det er min klare oppfatning at en av grunnene til at ERP-prosjektene feiler er vår manglende evne til å ha stålkontroll på detaljene. Poenget er at rollen som prosjektleder må støttes av rollen som prosjekt-controller. Dokumentstyring (Bruk f.eks. Projectplace) Saksstyring (Bruk verktøy av typen FogBugz eller JIRA for loggføring) Issues (avvik-feil) Dokumenter Endringsordre Kontraktstyring (Bruk prosjektoppfølgingsmalen Excel) Sakene på styringsgruppens bord Risikoer Risikostyring (Bruk referatmalen Word) 10 Timer mot WBS Fremdriftsstyring/tid Ressursstyring/WBS (Bruk prosjektoppfølgingsmalen Excel)
Nøkkelen er begrepet «Realisme» Vi er naturlig optimistiske,- det er bra men kan også før oss inn i helt urealistiske prosjektbeskrivelser: Planrealisme Budsjettrealisme Ambisjonsrealisme Realisme mht. usikkerhet og risiko Nobelprisvinneren mener vi har en tendens til å fortrenge dårlige erfaringer fra tilsvarende prosjekter Vi må etablere et såkalt «Outside View» der vi bringer inn erfaringstall fra sammenlignbare prosjekter. Realisme mht. fristilling av egne ressurser 11
Prosjektoppfølging WBS Ressursoppfølging «One-Pager» Ressursmodell (alle tall representerer timer) Referanse til kontrakt Planlagt timer (Kontrakt) Planlagt timer (Kontrakt) Planlagt timer (Kontrakt) EO01 etter A&D fasen Planlagt timer (Revidert kontrakt) Akkumulerte timer (Forrige periode) Påløpte timer (Denne periode) Akku-mulerte timer (ATD) Ferdigstillelsesgrad (I dag) Forventet gjen- stående (ETC) Arbeidspakker Fastpris/ Tak T&M Målpris EO01 Ny Målpris Analyse og Design 150 150 0 150 100 % 0 150 0 Teknisk installasjon 17 17 15 5 20 100 % 0 20 3 Konfigurering og parametersetting 12 10 22 5 5 10 50 % 20 30 8 Innlegging av grunndata 25 25 0 25 25 60 % 20 45 20 Opplæring av superbrukere 16 10 26 0 0 0 26 26 0 Tilpasse grunnlagsregister 29 29 0 0 0 29 29 0 Tilrettelegge rapporter og formularer 19 19 0 0 0 19 19 0 Bistå kundens akseptansetest 8 10 18 0 0 0 20 20 2 Opplæring av sluttbrukere 144 144 0 0 0 144 144 0 Prosjektledelse 120 120 0 0 0 120 120 0 Lage brukerdokumentasjon 170 170 0 0 0 170 170 0 Bistand under oppstart 100 100 0 0 0 100 100 0 Total - DEL 1 = Opprinnelig kontrakt og Revidert kontrakt 150 0 660 690 170 35 205 668 873 33 Endringsordre 1 (Etter Analyse og Design) 30 Endringsordre 2 100 100 100 0 Endringsordre 3 0 0 Endringsordre 4 0 0 Endringsordre n 0 0 Total - DEL 2 = Endringsordre etter kontraktsinngåelse 0 0 0 30 100 0 0 0 100 100 0 Sum per kontrakskategori inkludert EO 150 0 660 0 790 170 35 205 0 768 973 33 SUM forventet forbrukt ved prosjektets slutt (EAC) 800 805 840 835 840 843 845 950 947 948 949 973 SUM forventet overskridelse/underskridelse -10-5 0-5 0 3 5 10 7 8 9 33 SUM avtalt inkludert endringsordre 810 810 840 840 840 840 840 940 940 940 940 940 SUM endringsordre 0 0 30 30 30 30 30 130 130 130 130 130 SUM avtalt opprinnelig kontrakt 810 810 810 810 810 810 810 810 810 810 810 810 Dato rapportert: 01.03.2016 01.042016 01.05.2016 01.06.2016 01.07.2016 01.08.2016 01.09.2016 01.10.2015 01.11.2015 01.12.2015 01.01.2016 03.02.2016 1000 950 900 850 800 750 PROSJEKTETS UTVIKLING OVER TID Serie1 Serie3 Serie5 Forventet forbruk (EAC) Avvik 700 1 2 3 4 5 6 7 8 9 10 11 12 12
Saken i et nøtteskall Vi kjøper både «kodekraft» og «hodekraft». Det vil si programvare(-tjenester) og intellektuelle tjenester. Leveranse- og forvaltningsteamets kvalitet er den faktoren som i størst grad påvirker løsningskvalitet og TCO. Rammer Styringsevne Endringsledelse Masterdatakvalitet Ressurstilgjengelighet Kundens bidrag Løsningsforståelse Samarbeidsevne Ressursinnsats og kvalitet Økosystem Investeringsnivå Markedsposisjon Netto kundetilgang Bransjerelevent ERPsystemet Partnerrelasjon Partnerens Leveransetea m Ansiennitet Sertifiseringer Bransjeforståelse Kommunikasjonsevne Ressurstilgjengelighet Systemnivå Eierskapskost Ressursinnsats og kvalitet 13 Prosjektkost Forvaltningskost
Konklusjon Leverandør xxxxx Evalueringsregler Evalueringsregler Evalueringsregler Evalueringsregler Evalueringsregler Dato: Score 1 = ingen grader Score 1 = mindre enn 5 år Score 1 = mindre enn 5 Score 1 = meget liten Score 1 = ingen sertifiseringer Versjon: Score 2 = Bachelor Score 2 = mellom 5 og 10 år Score 2 = Mellom 5 og 10 Score 2 = Middels Score 2 = Mangler enkelte s Forfatter Score 3 = Master Score 3 = Mer enn 10 år Score 3 = Mer enn 10 Score 3 = Meget lang Score 3 = Har alle relevante s EVALUERING AV LEVERANSETEAM Navn Rolle i prosjektet Formalkompetanse (Bachelor/Master) Antall års erfaring systemet Antall relevante caser han/hun har deltatt i Relevant bransjeerfaring Sertifiseringer på ERPløsning, metode eller prosjektledelse Ola Nordmann Løsningsarkitekt 3 1 2 3 2 11 Nils Nilsen Prosjektleder 2 3 3 2 2 12 Kari Konsulent logistikk 3 2 3 3 3 14 Hans Konsulent økonomi 2 3 1 2 3 11 Petter Konsulent innkjøp 2 3 1 2 3 11 Gjermund Konsulent teknisk infrastruktur 1 2 1 3 2 9 Øystein Konsulent rapportering/bi 2 3 3 1 2 11 0 0 0 0 Samlet score for teamet 79 Gjennomsnittsscore for teamets deltakere Denne formelen må justeres avhengig av antall deltake i teamet 11,3 Samlet Score
Prosessen i et helhetsperspektiv Prosjektorganisering Strategi- & modningsfasen Prosjektidé Beslutning om å vurdere kjøp Valgfasen Implementeringsfasen Beslutning om kjøp (A&D) Beslutning om realisering Beslutning om å ta i bruk Anvendelsesfasen Beslutning om å videreføre dagens løsning Beslutning om å videreføre dagens løsning Beslutning om å hoppe ut av kontrakten Implementering av nye Komponenter innenfor valgt system Utskifting av erp-systemet Prosessen består totalt av fire faser. Modningsfasen er en uformell tilnærming til et krevende prosjekt som består av valgfasen og implementeringsfasen. I forbindelse at systemet settes i drift overleveres bransjeløsningen fra prosjektet til linjen. Da er vi inne i anvendelsesfasen som varer så lenge løsningen er i bruk. Det er ikke uvanlig at prosjektet opprettholdes et godt stykke inn i anvendelsesfasen. 15
Sakens kjerne: Presentasjon av våre behov Visjon hvor skal vi Mål hva vil vi oppnå Prosessforbedring Prosess Styrker Regler Forbedringsmål Svakheter Regler Forbedringsmål Det står og faller på vår evne til å beskrive bedriftens kompleksitet,- dvs. dens prosesser, forretningsregler og styringsprinsipper. Forbedringsmål 16
Implementeringsfasen SSA-T Prosjektering Analyse & Design (forprosjekt) Bygge og Pilotere (hovedprosjekt) Utrulling Kontraktrevisjon Kontraktrevisjon Det blir stadig klarere for meg at i større bedrifter bør implementeringsfasen brytes opp i 3 prosjekter sine leveransepakker, kontrakter, organisering og ressursallokering Prosjektering Analyse & Design Bygge og Pilotere Utrulling SSA-O SSA-T SSA-B BHC 17
Alternative kontraktsmodeller Analyse & Design Bygge og Pilotere Utrulling Forvaltning SSA-O SSA-T SSA-B SSA-V SSA-T SSA-V SSA-O SSA-T SSA-V 18
Noen viktige begreper Dialogbasert tilbudsprosess Med utgangspunkt i en RFI/RFP har partene en tett dialog der både kundens tilbudsinnbydelse og leverandørens tilbudsdokument oppdateres stegvis frem mot et punkt der dokumentene låses og valget tas. Kontraktstyrt tilbudsprosess Leverandørens tilbud gis i kontrakts form, der kunden i sin tilbudsinnbydelse har instruert leverandøren i hvordan den valgte kontraktsmalen skal anvendes (IKT Norge, SSA-T, PS 2000 eller andre) Progressivt kontraktsregime Partene er ved kontraktsinngåelse enige om at kontrakten, basert på noen tydelige regler, skal revideres etter avsluttet Analyse & Designfase. BHC 19
Dialogbasert anskaffelse variant 1 Lev. 1 System A Løsningsarkitektur Bemanning Referanser Metode Kalkyle v. 1.0 Besvarelse v.1.0 Iterasjon 1 Rette åpenbare feil og mangler i besvarelsen Lev. 1 System A Oppdatert Besvarelse v.2.0 Iterasjon 2 Hard allokering av ressurser Mer detaljert kalkyle Mer detaljert løsningsbeskrivelse Mer detaljert prosjektbeskrivelse Mer detaljert plan Lev. 2 System A Besvarelse v.1.0 Lev. 2 System A Oppdatert Besvarelse v.2.0 Lev. 2 System A Revidert Besvarelse v.3.0 Lev. 2 System A SSA-O Lev. 3 System B Lev. 4 System C Besvarelse v.1.0 Besvarelse v.1.0 Lev. 3 System B Lev. 4 System C Oppdatert Besvarelse v.2.0 Oppdatert Besvarelse v.2.0 Lev. 3 System B Revidert Besvarelse v.3.0 Lev. 3 System B RFI+ v.1.0 Rammer for anskaffelsen Overordnede krav Mål og ambisjoner Virksomhetsarkitektur Kalkylemodell Konstruktiv og klargjørende tilbakemelding til leverandørene RFI+ v.2.0 Kontraktsforhandling Sonderinger i markedet Behovskartlegging Presentasjoner Dialog Referansebesøk Presentasjoner Dialog Evaluering Mer detaljert kalkylemodell Mer detaljerte krav Justerte målbilder Use-case Work-Shops Use-Case Dialog Evaluering 20
Variantene Vannfallsmetode Agil metode Malbasert metode I en agil, scrum-basert metode defineres produktkøen som en sum arbeidspakker av typen: Configuration items Modification items Integration items Document items Migration items Oppgavene ordnes i sprinter som fører frem til en Release. Kunden er dypt involvert i hver sprint både når det gjelder analyse, design og testing. Det er ikke uvanlig å tenke seg et prosjekt som kombinerer metodene. 21