Projektledelse for styregruppemedlemmer Workshop 1, onsdag den 19. februar 2014, Digitaliseringsstyrelsen Projektledelse for styregruppemedlemmer Typiske projektudfordringer - styregruppens roller, ansvar og kompetencer v/ Niels Terkelsen Kontakt: nielsterkelsen@gmail.com

Kursusprogram Derfor går det galt Når der går politik i projektet Styregruppens roller, ansvar og kompetencer Styregruppens tre hovedopgaver Introduktion til Grønlands fællesoffentlige projektmodel Centrale udfordringer i projektets hovedfaser Gode principper for it-projekter Derfor er business casen så vigtig 10.000 kilometers eftersyn af projektet

Digitalisering som drivkraft Tema 1 Mere og billigere internet Tema 2 Modernisering af grunddata Tema 3 Enkel, effektiv og sammenhængende offentlig sektor Tema 4 Digital uddannelse og kompetencer Tema 5 Sundhed for alle Tema 6 Innovation og investeringer

Præsentation Niels Terkelsen Enterprise arkitekt Uddannelses- og Forskningsministeriet Følgegruppen, Ministeriernes Projektkontor/Statens IT-projektråd Rådgivning i Grønland, Marokko, Kazakhstan Gæsteunderviser, IT-Universitetet Tidligere Arbejdsgruppen vedrørende fælles it-projektmodel i staten Programleder Chef for forretningsudvikling It-chef Strategi Forretning Information Applikation Teknologi 4

Derfor går det galt – 14 erfaringer fra Statens IT-projektråd i Danmark Mål og succeskriterier er ikke fastlagt Projektet vil for meget indenfor en for kort tidsplan: Født med overskridelse Ikke tydeligt nok hvilke leverancer der peger mod største gevinster Gevinstrealisering er ikke gennemtænkt og ejer ikke udpeget Risici er ikke værdisat i business case og der mangler forudsætninger og estimeringer Organisering af projekt og set-up til at styre projekt og sikre leverancer fra vigtige bidragsydere og fastlæggelse af ansvar hos væsentlige interessenter er ikke på plads Interessenter inddrages ikke tidligt nok og deres ansvar defineres ikke Ikke nok fokus på inddragelse af slutbrugere og deres incitamenter for anvendelse af løsningen (herunder hvilke krav der skal stilles om benyttelse for at opnå gevinster) Udbudsstrategi er mangelfuld og set-up for leverandørstyring ikke professionelt nok Implementeringsopgaven er undervurderet og driftsscenarier ikke gennemarbejdet Juridiske problemstillinger, ex. i forhold til datalovgivning, er ikke afklarede Der er ikke indhentet erfaringer fra andre myndigheder eller fra andre EU-lande Tekniske valg begrundes ikke altid med forretningsmæssige behov Kompleks it-arkitektur, mange integrationer og governance for data

Statens IT projektråd Mogens Pedersen Formand Kommitteret Finansministeriet  Birgit W. Nørgaard  Næstformand Bestyrelsesmedlem  Jesper Jarmbæk Tidl. direktør, Kort- og Matrikelstyrelsen Mads Tofte Rektor, IT-Universitetet Lars Mathiesen Direktør Nykredit Erik Andreasen Underdirektør, Danske Bank   Michael Moesgaard Koncern it-direktør, Dong Energy Lilian Mogensen Direktør ATP Ole Kjær Kommitteret, Skatteministeriet

Statens IT projektråd Risikovurdering Projektinitieringsdokument Ide Analyse Anskaffelse Gennemførelse Realisering Risikovurdering Projektinitieringsdokument Business case 7

Derfor går det galt … (1) ”Mål og succeskriterier er ikke fastlagt*” Efterlys S = SPECIFIKT M= MÅLBART A = ACCEPTERET R = REALISTISK T = TIDSFASTSAT

Derfor går det galt … (2+3) ”Projektet vil for meget indenfor en for kort tidsplan*: Født med overskridelse” ”Risici er ikke værdisat i business case og der mangler forudsætninger og estimeringer” Efterlys Produktnedbrydning, estimering, risikoregister, usikkerhed

Derfor går det galt … (4+5) ”Ikke tydeligt nok hvilke leverancer der peger mod største gevinster” ”Gevinstrealisering er ikke gennemtænkt og ejer ikke udpeget*” Efterlys Gevinstrealiseringsplan

Skab værdi Innovation People creating value through the implementation of new ideas Herman D’hooge, Intel Innovation Network

Derfor går det galt … (6+7) ​ Derfor går det galt … (6+7) ”Organisering til at styre projekt og sikre leverancer fra vigtige bidragsydere og fastlæggelse af ansvar hos væsentlige interessenter er ikke på plads” ”Interessenter inddrages ikke tidligt nok* og deres ansvar defineres ikke” Interessent Påvirkes interessenten? Har den indflydelse på projektet? Interessentens holdning til projektet Interessentens betydning for projektet   Efterlys Interessentanalyse (bekræftet)

Derfor går det galt … (8) ”Udbudsstrategi er mangelfuld* og setup for leverandørstyring ikke professionelt nok*” Efterlys Kompetencebehov, projektroller, profilbeskrivelser

Derfor går det galt … (9+10) ”Implementeringsopgaven er undervurderet og driftsscenarier ikke gennemarbejdet” ”Ikke nok fokus på inddragelse af slutbrugere og deres incitamenter for at bruge løsningen (herunder hvilke krav der skal stilles om brugen for at opnå gevinster)” Efterlys Procesanalyse, business case, forandringsledelse, implementeringsstrategi og -plan, interessentanalyse

Forandringsledelse

Derfor går det galt … (11+12) ”Juridiske problemstillinger, for eksempel i forhold til datalovgivning, er ikke afklarede” ”Der er ikke indhentet erfaringer fra andre myndigheder eller fra andre EU-lande” Efterlys Foranalyser, erfaringsindsamling, fællesoffentlig projekttjekliste

Derfor går det galt … (13+14) ”Tekniske valg begrundes ikke altid med forretningsmæssige behov” ”Kompleks it-arkitektur, mange integrationer og governance for data” Efterlys Arkitekt input, fællesoffentlig projekttjekliste, dogmeregler

Tre aspekter af styring Evaluate Direct Monitor ”EDM”, COBIT 5.0

Styregruppeformand( projektejer) Tre PRINCE2 hovedroller Styregruppeformand( projektejer) Seniorbruger Seniorleverandør

Styregruppeformand/ projektejer Projektejer er primær beslutningstager og mentor for projektlederen Styregruppeformand/ projektejer Seniorbruger Seniorleverandør Projektleder

Styregruppeformand Styregruppeformanden er ejer af projektet, og ejer dermed også Business Casen. Styregruppeformanden har det ultimative ansvar for projektet overfor organisationen. Styregruppeformandens primære fokus er på de forretningsmæssige interesser. Styregruppeformandens fokus er på, hvorvidt projektet er pengene værd, og hvorvidt de forventede gevinster kan realiseres.   Ansvarsområder: Primær beslutningstager Sikre rammebetingelser for projektet Ansvar for udarbejdelse af projektoplæg, business case og gevinstrealiseringsplan (i samarbejde med projektlederen) Kvalitetssikring i forhold til forretningsinteresserne Kommunikation i forhold til projektets interessenter Fungere som sparringspartner og mentor for projektlederen

Styregruppeformandens kompetencer Have myndighed til at træffe beslutninger, godkende planer og afvigelser på faseplaner Skal kunne tildele ressourcer Besidde lederevner Gennemslagskraft Løsningsorienteret Evne til at udfordre både brugere og leverandører konstruktivt

Styregruppeformandens kompetencer Have myndighed til at træffe beslutninger, godkende planer og afvigelser på faseplaner Skal kunne tildele ressourcer Besidde lederevner Gennemslagskraft Løsningsorienteret Evne til at udfordre både brugere og leverandører konstruktivt

Styregruppeformand/ projektejer Seniorbruger og brugerorganisation Styregruppeformand/ projektejer Referencegruppe Seniorbruger Seniorleverandør Brugerorganisation Projektleder Teamledere Projektdeltagere

Seniorbruger Seniorbrugeren repræsenterer brugernes krav og ønsker til slutproduktet. Seniorbrugeren er derfor ansvarlig for, at der bliver bestilt det rigtige produkt. Det er også seniorbrugerens ansvar at de mulige gevinster identificeres og realiseres. Seniorbrugeren har derfor en vigtig rolle at spille i forhold til gevinstrealiseringsplanen, også efter projektet er afsluttet , da nogle gevinster først vil kunne dokumenteres senere.   Ansvarsområder: Identificere og beskrive gevinster – gevinstrealiseringsplan Sikre brugerinddragelse og interne ressourcer Kvalitetssikre at løsningen dækker brugernes behov – kravspecificering og godkendelseskriterier Løse konflikter vedrørende forretningsmæssige problemstillinger Sikre implementering og idriftsættelse Dokumentere gevinster

Seniorbrugerens kompetencer Have myndighed til at træffe beslutninger, godkende planer og afvigelser på faseplaner Skal kunne tildele ressourcer Besidde lederevner Have overblik over forretningens behov Evne til at prioritere Forstå at skabe forandringer i forretningen

Styregruppeformand/ projektejer Leverance-organisation Seniorleverandøren og leveranceorganisation Styregruppeformand/ projektejer Referencegruppe Seniorbruger Seniorleverandør Leverance-organisation Brugerorganisation Projektleder Teamledere Projektdeltagere Teamledere

Seniorleverandør Seniorleverandøren har ansvaret for, at leverancer, kvalitet og tidsplan overholdes, samt at brugernes krav og ønsker kan implementeres. Seniorleverandøren kan både være intern og ekstern. Når den nye leverandør er valgt, skal en højtplaceret repræsentant for leverandøren indtræde i Styregruppen som seniorleverandør.   Ansvarsområder: Sikre at fremgangsmåde, planer og estimater for it-leverancer er realistiske At de nødvendige leverandørressourcer og kompetencer stilles til rådighed Sikre, at der etableres kvalitetssikringsprocedurer, samt at produkterne lever op til kvalitetskriterierne Rådgive om metoder Løse konflikter og problemer vedrørende it-mæssige problemstillinger Sikre, at standarder følges Vurdere konsekvenser og overvåge risici

Seniorleverandørens kompetencer Have myndighed til at træffe beslutninger, godkende planer og afvigelser på faseplaner Skal kunne tildele ressourcer Besidde lederevner Skal kunne omsætte brugerkrav til løsninger Forstå at formidle leverandørforhold (tekniske og andet) til den øvrige styregruppe

Styregruppeformand/ projektejer Leverance-organisation Projektlederen styrer leverancer fra brugerorganisation og leverandører Styregruppeformand/ projektejer Referencegruppe Seniorbruger Seniorleverandør Leverance-organisation Brugerorganisation Projektleder Konsulenter/ specialister Teamledere Projektdeltagere Teamledere

Projektleder Projektlederen er ansvarlig for den daglige styring i henhold til de rammer, som Styregruppen har udstukket. Projektlederens overordnede ansvar er at styre projektet sikkert frem mod leverance af de ønskede produkter til den aftalte tid, budget og kvalitet. Ansvarsområder: Al projektadministration i henhold til den fællesoffentlige it-projektmodel Styre projektet inden for tolerancerne Tage ansvar for den samlede fremdrift Opdatere ledelsesprodukter (business case) Styre medarbejdere og interessenter Projektorganisation og rollebeskrivelser Kontakten til ekstern leverandør Risiko- og ændringsstyring Planlægning af implementeringen af løsningen Projektadministration (logs osv.) Gevinstrealiseringsplan i samarbejde med Styregruppeformanden og Seniorbrugeren

Styregruppeformand/ projektejer Leverance-organisation Styregruppen skal sikre projektlederen arbejdsro Styregruppeformand/ projektejer Referencegruppe Seniorbruger Seniorleverandør Leverance-organisation Brugerorganisation Projektleder Konsulenter/ specialister Teamledere Projektdeltagere Teamledere

Styregruppens tre hovedopgaver Tag ejerskab Fjern barrierer Beslut på stedet God praksis for effektivt styregruppearbejde (se http://digitalimik.gl)

Tag ejerskab Vis vilje Formuler nødvendighed Prioriter

Fjern barrierer Sørg for tilstrækkelige kompetencer Håndter modstand og konflikter Skab enighed

Beslut på stedet Hav mandat Vær tilgængelig Styr baglandet

Kvalitetssikring Typiske leverancer, der skal kvalitetssikres: Projektdokumenter Procesdokumentation Udbudsmateriale og kontrakter It Typiske metoder: Test Audit Review Inspektion pilot Krav til personer, der udfører kvalitetssikringen: Relevant uddannelse og erfaring Krav til processen: Planlæg og dokumenter

Projektledelse for styregruppemedlemmer Workshop 2, fredag den 21. februar 2014, Digitaliseringsstyrelsen Projektledelse for styregruppemedlemmer Projektmodel og business case v/ Niels Terkelsen

Styregruppeformand/ projektejer Leverance-organisation Referencegruppe Seniorbruger Seniorleverandør Leverance-organisation Brugerorganisation Projektleder Konsulenter/ specialister Teamledere Projektdeltagere Teamledere

Styregruppeformand/ projektejer Ekstern seniorleverandør Referencegruppe Seniorbruger Ekstern seniorleverandør kompetence Brugerorganisation Projektleder Konsulenter/ specialister Teamledere Projektdeltagere Teamledere

Styregruppeformand/ projektejer Ekstern seniorleverandør kompetence Referencegruppe Seniorbruger Seniorleverandør Leverance-organisation Brugerorganisation Projektleder Konsulenter/ specialister Teamledere Projektdeltagere Teamledere

Introduktion til Grønlands fællesoffentlige projektmodel v/ Anders Hoffgaard, Digitaliseringsstyrelsen

Styringsmodel for projekter under digitaliseringsstrategien Naalakkersuisut Digitaliserings-styrelsen Departements-chefkreds Modernisering af grunddata Enkel, effektiv og sammenhængende offentlig sektor Digital uddannelse og kompetencer FOIS Mere og billigere internet Sundhed for alle Initiativ 1 Initiativ 2 Initiativ 3 Initiativ 4 Investeringer og Innovation

Styringsmodel for projekter under digitaliseringsstrategien Ide Analyse Anskaffelse Gennemførelse Realisering Projektkommissorium Reviewes af Digitaliseringsstyrelsen og godkendes af departmentschefkredsen Business case Reviewes af Digitaliseringsstyrelsen og godkendes af departmentschefkredsen Månedlige statusrapporter Reviewes af Digitaliseringsstyrelsen og godkendes af departmentschefkredsen Afslutningsrapport Reviewes af Digitaliseringsstyrelsen og godkendes af departmentschefkredsen Gevinstrealiserings-rapport Reviewes af Digitaliseringsstyrelsen og godkendes af departmentschefkredsen

Afsøg alle hjørner i idéfasen Ide Analyse Anskaffelse Gennemførelse Realisering Tal med andre med erfaring med området. Udvid netværket. Få idéer til foranalyser, proof of concepts og pilotprojekter Find verdens bedste projektleder I denne fase er projektorganisationen sjældent på plads

Business casen er hovedopgaven i analysefase Ide Analyse Anskaffelse Gennemførelse Realisering Afklar ved hjælp af analyser Mobilisér og motivér interessenter Skær projektet til Business case og analyser kræver stærke kompetencer

Procesanalyser overrasker altid Hvad du tror det er Hvad det virkelig er Hvad det kunne være

Dogmeregler fra ESDH projekt Løsningen vælges mellem standardløsninger, der har været afprøvet i sammenlignelige institutioner Løsningen skal tages i brug uden tilpasninger af standardfunktionaliteten, men alene ved konfiguration af standardsystemet Løsningen skal understøtte VTUs forpligtelser i forhold til gældende lovgivning, herunder offentligheds-, forvaltnings- og arkivloven Løsningen skal som minimum understøtte, at kernefunktioner og –processer knyttet til ministerbetjenings- og forelæggelsesprocesserne kan foregå fuldt digitalt på tværs af koncernen Medarbejderne skal sikres adgang til data fra tidligere ESDH- og journalsystemer Løsningen skal understøtte, at medarbejdernes dokumentregistrering, herunder af metadata og parter, automatiseres i størst mulig grad, med sikring af effektiv genfindingsfunktionalitet Løsningen skal gøre VTUs løbende ESDH-udgifter signifikant lavere Løsningen skal understøtte en optimering af medarbejdernes arbejdsprocesser, bl.a. gennem stabil drift og hurtige svartider Medarbejdernes tilfredshed med ESDH skal forbedres signifikant Identifikation af nye behov vil ikke medføre ændringer i systemet. Behovsafklaring fokuserer på specificering af de ovenfor nævnte kernefunktioner og processer Koncernen kan som udgangspunkt ikke forvente fuld understøttelse af andre processer, såfremt det kræver specialtilpasninger af den valgte standardløsning. Løsningen skal via snitflader kunne fungere som arkiv for disse processer. Men der skal ikke ske en egentlig integration af løsningen med fagsystemer som eksempelvis UBST’s Byggeweb, og FI’s tilskudsadministrationssystem. Løsningen skal understøtte de eksisterende FESD-standarder minimum i samme omfang som standardløsningerne på markedet allerede gør det i dag. Der skal alene foreligge en roadmap for leverandørens fremtidige understøttelse af de nye FESD-standarder (OIO Sag & Dokument). En eventuel fremtidig videreudvikling af løsningen skal ske i samarbejde med andre offentlige kunder

Anskaffelsesfase går i detaljen Analyse Anskaffelse Gennemførelse Realisering Kravspecifikation er en videnskab Detaljerede planer for teknisk og organisatorisk implementering, proof of concepts og test Anskaffelsesfasen kræver andre og mere specialiserede kompetencer end analysefasen

Realiteterne melder sig i gennemførelsesfasen Ide Analyse Anskaffelse Gennemførelse Realisering Stort ressourceforbrug på test (undgå ny tinglysningsskandale) Ofte brug for intensiv opfølgning og ændringsstyring Hvedebrødsdagene slutter Gennemførelsesfasen udfordrer leverandørstyrings-kompetencen

Her gik det galt i Tinglysningsprojektet Kunden holdt ikke øje med, hvad leverandøren lavede tidligt (ingenting) Brugervenlighed planlagt, men senere glemt Ubehjælpsomme krav til brugergrænsefladen Kundens konsulents SOA ambitioner Organisatorisk implementering optimistisk - uden konkrete målinger Pilot-drift sent i projektet var umulig - bevillingerne var skåret væk Umoden risikoanalyse Professor Søren Lauesen, ITU

Realiseringsfasen forandrer forretningen Ide Analyse Anskaffelse Gennemførelse Realisering Aldrig bigbang! Seniorbrugeren kommer til eksamen Behov for tæt opfølgning på processer og gevinster

Rapportering efter projekttrekanten (timer/penge) Ressourcer (Deadline) Kalendertid (Lav din overall vurdering - rød/gul/grøn) Overall (Hvad er leveret? er kvaliteten i orden?) Leverancer og Kvalitet (se http://digitalimik.gl)

Trafiklysrapport

Risikolog og emnelog

Fællesstatslige principper for it-projekter Staten skal være ambitiøs i forhold til digitalisering af den offentlige sektor, men skal kun gå forrest i anvendelsen af umodne tekniske løsninger, såfremt der er særlige perspektiver ved at foretage en sådan satsning Allerede indkøbte eller udviklede løsninger skal genbruges i videst mulige omfang Kun projekter med klart beskrevne omkostninger, gevinster og effekter bør gennemføres Projekterne skal opdeles i mindre og selvstændigt værdiskabende dele, som besluttes og gennemføres uafhængigt af hinanden Projekterne skal gennemføres med fælles metoder og kvalificerede ressourcer, således at der i alle projekter er et passende modenhedsniveau.

Business casen beskriver både forudsætninger og økonomi Projektgrundlag (strategier, analyser, planer) Økonomiberegning

Projektudgifter Personaleudgifter og lønninger Eksterne konsulenter og udviklingsomkostninger Udstyr (hardware og lignende) Licenser … andet

Gevinster og effekter Tre typer af projekter: Effektivisering Kvalitetsløft Implementering af EU-lovgivning Effektiviseringsgevinster er gevinster, der er henførbare til institutionens budget Kvalitetsløft er gevinster, som ikke er henførbare til institutionens budget. Kan eventuelt være henførbare til andres budget.

Beregning af gevinsten Gevinsten beregnes som forskellen mellem driftsomkostningerne ved nul-scenariet og projekt-scenariet Nul-scenarie - Projekt-scenarie = Gevinst

Realitetstjek af business casen Glem tro, håb og kærlighed for en stund Ville du investere dine egne penge i projektet? Business casen må kun indeholde gevinster, som er godkendt af gevinstejerne

Lav risikojustering og best-case/worst-case I business case-modellen vurderes usikkerheden på hvert estimat Der angives et best-case, worst-case og middel estimat – og hvert af dem tildeles en sandsynlighed Eksempel på de følgende to slides: Udviklingsomkostninger estimeres til 20 mio. kroner – med forskellige best- og worse-cases og forskellige sandsynligheder

Det bliver garanteret dyrere … (Fra Digitaliseringsstyrelsens ” Vejledning til statens business case-model v 1.3)

En vis risiko for, at det løber løbsk … (Fra Digitaliseringsstyrelsens ” Vejledning til statens business case-model v 1.3)

Beregn nutidsværdi Diskontorente på 5 procent: 100 kroner i år 5 er kun 78 kroner værd 100 kroner i år 8 er kun 68 kroner værd 100 kroner i år 10 er kun 61 kroner værd Hvad sker der, hvis projektet bliver forsinket?

Opsummering Konkretiser gevinster og udgifter Tag nul-projektet alvorligt Lav risikojustering og best-case/worst-case – og få et realistisk risikobudget Beregn nutidsværdien

10.000 kilometers eftersyn af projektet Den fællesoffentlige projektmodel omfatter en projekttjekliste, som for eksempel kan bruges ved en workshop med følgende personer: En eller flere erfarne enterprise arkitekt profiler Styregruppeformand Seniorbruger Seniorleverandør Projektleder Eventuelle andre hovedinteressenter

Enterprise arkitektur