Gevinstrealisering i programmer Er det slutbrugerne der gør forskellen? 25. Oktober 2018

Transkript

1 Gevinstrealisering i programmer Er det slutbrugerne der gør forskellen? 25. Oktober

2 Program 8:00 8:30 Ankomst og morgenmad 8:30 9:00 Hvordan står det til? årets undersøgelse vedr. programledelse og gevinstrealisering Kaare Pedersen og Anette Zobbe, Peak Consulting Group 9:00-10:00 Hvad gik galt i 5 store offentlige it-projekter og hvad kan man gøre ved det? Eksemplificeret ved Sundhedsplatformen. v. Søren Lauesen, professor, ITU. 10:45 11:45 Samtalesalon paradokser, årsager, dilemmaer hvordan kommer vi videre? v. Jens Laugesen, Anette Zobbe og Pernille Thorup, moderator Kaare Pedersen 11:45 12:00 Afslutning og en sandwich 2

3 Know How Hvordan står det til? årets undersøgelse vedr. programledelse og gevinstrealisering Kaare Pedersen og Anette Zobbe

4 Vi er blevet lidt trætte af Gevinstsurvey og det er I vist også 4

5 Allerede i spørgsmålet ligger en antagelse

6 Lad os se på nogle af tallene

7 Percent Hvilke områder fungerer BEDST i Jeres programmer? (sæt 3 krydser) ,2 39,4 33,3 48,5 60,6 30,3 24,2 30,3 15,2

8 Percent Hvilke områder fungerer DÅRLIGST i Jeres programmer? (sæt 3 krydser) ,5 39,4 36,4 39,4 45, ,2 18,2 21,2 18,2 0

9 Percent Hvilke områder mener du, er de VIGTIGSTE at få til at fungere i et program? (sæt 3 krydser) ,5 12,1 42,4 24,2 54,5 63,6 30,3 15,2 9,1

10 Andel af gevinsterne Hvor stor en andel af gevinsterne realiseres? % 5% % 14% % 22% % 27% % 24% 0-20 % 9% 0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% Pct besvarelser

11 Hvem har ansvaret for at gevinsterne realiseres? Vi følger ikke op men har en plan om at gøre det 38,50% 40,20% Vi udpeger gevinstejere, der sikrer at der måles og følges op 26,50% 34,60% 0% 5% 10% 15% 20% 25% 30% 35% 40% 45%

12 Hvordan bliver gevinstansvaret praktiseret? I praksis betyder det, at der ikke sker så meget når projektet er lukket 19% Der bliver arbejdet seriøst med at gennemføre forandringerne og realisere gevinsterne 27% Ansvaret er ikke tydeligt beskrevet, så det er meget forskelligt, hvad den enkelte ansvarlige gør 54%

13 Hvordan sikrer I at forandringerne gennemføres? Planlægger F I samarbejde med forretningen 33,30% 46,20% Forlænger projektet ind I realiseringsfasen 12,80% 22,20% Forandringsteam, der støtter forretningen 7,40% 10,30% Forandringer dækker andet end udd 14,80% 4,30% 0% 10% 20% 30% 40% 50% Andel besvarelser

14 Er disse forandringer en del af projektets budget? Nej, aldrig 7,40% 10,30% Nej, ikke så ofte 45,30% 55,60% Ved ikke 11,10% 8,50% Ja, ofte 22,20% 31,60% Ja, altid 3,70% 4,30% 0,00% 10,00% 20,00% 30,00% 40,00% 50,00% 60,00%

15 Blinde pletter I en rationel verden, bliver tallene et paradoks, med enkelte lyspunkter Fordi vi ser, det vi spørger om, men ikke ser på den måde vi ser på!

16 Udfordre vores mentale modeller Den mekaniske, kausale model Programmet Forandringerne Gevinsterne 16

17 Kompleksitet og mennesker A B Vi lever midt i et af verdens mest dynamiske, men også mest komplekse samfund. Blandt de vigtigste livsfærdigheder nu er simpelt hen at tåle kompleksiteten og at forstå sig selv og andre Skårderud,

18 Udfordre vores mentale modeller Komplekse forandringer mellem mennesker Programmet Gevinsterne 18

19 Udfordre vores mentale modeller Komplekse forandringer mellem mennesker hele tiden Programmet Gevinsterne 19

20 Udfordre vores mentale modeller Komplekse forandringer mellem mennesker hele tiden i en meget større og vigtigere verden end programmet Programmet Gevinsterne Forretningen eller driftsorganisationen Bestående af mennesker der er rationelle og irrationelle 20

21 Know How Samtalesalon paradokser, årsager og dilemmaer Jens Laugesen, Anette Zobbe og Pernille Thorup - moderator Kaare Pedersen

22 Ambition: Modet til at starte nye samtaler om at skabe forandringer. Der findes mange svar: I litteraturen, i brugerinddragelse, i metoderne, i ledelsen, mv. Vores samtaler: Et forsøg på at bringe andre perspektiver ind. Tilgangen er både-og (ikke enten-eller).

23 Grundlæggende antagelse: Tre antagelser drøftes i samtalesalon: Freeze-unfreeze Kommunikation Styring Organisationer bruger programmer og projekter med det formål at skabe gevinster for deres organization, ved at implementere de leverancer og forandringer, der er en forudsætning.

24 Antagelsen om Unfreeze-Freeze

25 Antagelsen om Kommunikation Lederen Besked Interessenter

26 Antagelsen om Styring

27 Program 8:00 8:30 Ankomst og morgenmad 8:30 9:00 Hvordan står det til? årets undersøgelse vedr. programledelse og gevinstrealisering Kaare Pedersen og Anette Zobbe, Peak Consulting Group 9:00-10:00 Hvad gik galt i 5 store offentlige it-projekter og hvad kan man gøre ved det? Eksemplificeret ved Sundhedsplatformen. v. Søren Lauesen, professor, ITU. 10:45 11:45 Samtalesalon paradokser, årsager, dilemmaer hvordan kommer vi videre? v. Jens Laugesen, Anette Zobbe og Pernille Thorup, moderator Kaare Pedersen 11:45 12:00 Afslutning og en sandwich 27

28 Hvorfor elektronisk tinglysning startede som en katastrofe Hvordan kunne det være undgået? Hvorfor deres sagsbehandlingssystem blev lukket Søren Lauesen IT-University of Copenhagen Hvorfor rejsekortet blev 4 år forsinket Søren Lauesen IT-Universitetet i København slauesen@itu.dk Hvordan forbedring nedsatte produktiviteten (i begyndelsen?) Flere? Havarikommission 19 behandlinger 36 slags årsager 20 skader i 5 projekter 19 behandlinger og antal årsager de forhindrer 7 Problem-orienterede krav Se mere: Lauesen: 6 Pilot test Damage and damage 5 Tidlige prototyper og test causes in large IT 4 Juster plan ved overraskelser government projects 4 POC (Proof of concept) 3 Studer hvad der er og planlæg fremtiden 3 Scope management + function points 3 Overvåg resterende arbejde 2 Idriftsæt i flere omgange 2 Ekspertinddragelse 2 Lille arbejdsgruppe med beføjelser 1 Opfølgende undersøgelse 1 Undersøg teknologien grundigt 1 Tredje-part kan integrere 1 Planlæg lukningen tidligt 1 Kreative jurister 1 Overvåg forretningsaspekterne 1 Risikostyring efter bogen 1 Giv ledelsen IT-kompetencer 4 Årsager uden kendt behandling 51 Total Nogle årsager har to behandlinger 21 Gældsinddrivelse (Skat, EFI) Hvordan man spildte 600 M DKK på software og udskød gæld for M DKK i årevis 11

29 Hvordan forbedring nedsatte produktiviteten (i begyndelsen?) 29

30 Sundhedsplatformen (EPIC) Udviklet Observerede skader Tid: 3 år for de første 2 hospitaler. +15 hospitaler i Ingen skade. Pris: SW M DKK. Ingen skade. Uddannelse og tilpasning M DKK. Driftsomkostninger 200 M DKK/år. Forretning: Vil spare 600 M DKK/år efter to år. For tidligt at vurdere (marts 2018). Gl. system: Brugte 1-2 timer pr. dag med mange log-ind. Er sparet. Men andre problemer røver mere tid end besparelsen. Nogle steder ansættes flere + gratis overarbejde. Brugervenlighed: Mange frustrationer, men noget er blevet bedre. Status: Ellers succes. Hvorfor? Analysefase 900 sider krav: The system shall sider use cases A1 Sætter sig ikke godt nok ind i brugernes behov, fx alle specialer. A2 Skriver ikke krav der dækker kundens behov. Ingen skade - systemet kan alt. A7 Vil have det hele straks: "Pilot test" med klinikere. Alle specialer. Store ændringer af lægens job, fx ingen journaldiktat, bestil selv lab test, afregn... A8 Planlagde ikke de nye arbejdsgange godt nok. A10 Overraskende regel-jungle: afregning med myndigheder, systemintegration. Anskaffelse B4 Forkerte kriterier til leverandørvalg kvalitetspoint i stedet for gevinst 30

31 Design af løsning C1 Konfigurerede skærmbilleder for flere specialer, men testede ikke brugervenligheden. Programmering D2 System-integration - ups! Brug af FMK (Fælles medicinkort) var ufravigeligt, men langsomt og sinkede lægerne. Skulle også integrere med 20 andre systemer. EPIC gav en fast pris, men blev overrasket. Test E1 Satte i drift med utilstrækkelig test, fx af integrationer, specialudviklede dele, brugervenlighed. Idriftsættelse F1 Satte i drift med utilstrækkelig support. F2 Kontrollerede ikke om systemet blev brugt som forventet. F3 Fejlvurdering af brugerhastighed. Hvorfor ikke opdaget ved 3-ugers prøven? Ledelse G1 Klare forretningsmål, men overvåges ikke. Kunne fx have ændret beslutninger om diktat til journal. G2 Idriftsatte til tiden under pres -> utilfredshed og lav produktivitet. G6 Fyrede en del lægesekretærer for tidligt. G9 Store arbejdsgrupper skulle blive enige og designe specialløsninger. 31

32 36 forskellige årsager i 5 projekter: Grønt: Også i Analysefase Bonnerup 2001 A1 Sætter sig ikke ind i brugernes behov. Skaber ikke win-win A2 Skriver ikke krav der dækker kundens behov A3 Beskriver løsningen i detaljer. Ingen spillerum til leverandøren A4 Kræver ind og tror det er gratis A5 Teknologier oversælges, fx SOA, web-baseret, workflow maskine A6 Flerleverandør-strategi - så er vi leverandøruafhængige!? A7 Vil have det hele på engang, fx hele landet, eller alle slags gæld A8 Planlægger ikke de nye arbejdsprocesser A9 Tvivl om der findes en løsning, er der fx det nødvendige data? kan man opnå akceptable svartider? etc. A10 Overraskende regel-jungle Anskaffelse B1 Leverandør for optimistisk - den der lyver vinder B2 Kunden vurderer ikke løsningen, beder evt. leverandøren gøre det B3 Glemmer eller ignorerer vigtige omkostninger B4 Forkerte kriterier til leverandørvalg 32

33 Design af løsningen C1 Sikrer ikke brugervenlighed, selv når man ved hvordan det gøres C2 Designer skærmbillederne for sent C3 Akcepterer leverandørens løsningsbeskrivelse uden at forstå den C4 Kan ikke se hvor langt leverandøren er C5 Vil have det på sin egen måde uden at se på leverandørens måde Programmering D1 Leverandøren akcepterer en dyr kravfortolkning selvom det er urimeligt D2 Overraskelser ved system-integration Test E1 Idriftsætter systemet med utilstrækkelig test Deployment F1 Idriftsætter systemet med utilstrækkelig support og uddannelse F2 Tjekker ikke om systemet bruges som forventet F3 Fejlvurderer brugernes hastighed 33

34 Ledelse G1 Ingen forretningsmæssige mål eller glemmer dem undervejs G2 Justerer ikke planen ved overraskelser, men tror resten kan speedes op G3 Projektet vokser uden at nogen opdager det G4 Ser ikke faren i øjnene, men bagatelliserer risikoen G5 Pengene slipper op og parterne skændes i stedet for at samarbejde G6 Høster gevinsten førend den er der, fx fyrer for tidligt G7 Manglende ledelse eller ekspertinddragelse G8 Overdreven ledelse eller ekspertinddragelse G9 For store styregrupper eller arbejdsgrupper G10 Overdreven brugerinddragelse G11 Tror at loven forbyder fx at tale med leverandører eller lave pilotdrift 34

35 Årsagsprofiler Hvornår skete det? 10 Analysefase 4 Anskaffelse 5 Design 2 Programmering 1 Test 3 Idriftsættelse 11 Ledelse 36 I alt Hvem gjorde det? 32 Kunden 15 Konsulenten 10 Leverandøren 5 Regeringen 62 I alt I mange tilfælde skyldtes det to parter Årsager pr. projekt 17 etinglysning 12 Rejsekortet 17 Politiets sagssystem 16 Skat EFI, gældsinddrivelse 15 Patientjournal EPIC 77 I alt Hver årsag observeres i ca. to projekter Hvilken slags fejl? 17 Ignorerede kendt løsning 22 Løsning ikke udbredt 3 Fejlinformeret 4 Løsning ukendt 46 I alt Nogle årsager var af to slags 35

36 Flere? Havarikommission 20 behandlinger 36 slags årsager 20 skader i 5 projekter 20 behandlinger og antal årsager de forhindrer 8 Problem-orienterede krav (SL-07) 5 Pilot test eller deployment test 5 Tidlige prototyper og usability test 5 Scope management + function points 4 Juster plan ved overraskelser 4 Tidlig POC (Proof of concept) 3 Studer hvad der er og planlæg fremtiden 3 Overvåg resterende arbejde 3 Idriftsæt i flere omgange Rød: Bruges sjældent 2 Ekspertinddragelse 2 Lille arbejdsgruppe med beføjelser 1 Opfølgende undersøgelse 1 Undersøg teknologien grundigt, second opinion 1 Central database + fleksibel SOA (Odata) 1 Trediepart kan integrere + nedlukningskrav 1 Overvåg forretningsaspekterne 1 Risikostyring efter bogen 1 Konstruktive jurister 1 Giv ledelsen IT-indsigt 1 Omkostningstjekliste 3 Behandling ukendt 53 Total Nogle årsager kræver to behandlinger 36

37 Kravskabelon SL-07 Bestilt af VTU-ministeriet som led i K-02 (i 2007) Udfordring: Gør alle slags krav problemorienterede

38 38. Kravskabelon SL-07 v5 (med EPJ-eksempel) A. Vision, kontekst, vejledning... B. Overordnede behov 20% genbrug i B1. Flow andre områder B2. Forretningsmæssige mål B3. Tidligt bevis (POC) B4-B6. Min-krav og tildelingskriterier C. Task systemet skal støtte C1. Indskriv patient 1% genbrug C10. Klinisk session... D. Data systemet skal anvende D1. Diagnoser 1% genbrug D2. Diagnosetyper... E. Andre funktionelle krav E1. Systemgenerede hændelser E2. Udskrifter og rapporter E3. Komplekse beregninger og regler E4. Udbygning af systemet 30% genbrug F. Integration med eksterne systemer G. Teknisk it-arkitektur G1. Brug af eksisterende HW og SW G2. Nyt hardware og software... H. Sikkerhed 50% genbrug H1. Login og adgangsret for brugere H2. Sikkerhedsadministration H3. Sikring mod tab af data H4. Sikring mod utilsigtet brugeradfærd H5-H6. GDPR og sikring mod trusler I. Brugervenlighed og design 80% I1. Indlæring og effektivitet i daglig brug I2. Tilgængelighed og Look-and-Feel J. Andre krav og leverancer J1. Andre standarder der skal følges J2. Uddannelse J3. Dokumentation 80% genbrug J4. Datakonvertering J5-J7. Installation, Test, Udfasning K. Kundens leverancer L. Drift, support og vedligehold L1. Svartider L2. Tilgængelighed (driftseffektivitet) L3. Datalagring 90% genbrug L4. Support L5. Vedligehold

39 39. C10. Udfør klinisk session En klinisk session kan omfatte diagnose, planlægning, udførelse, vurdering, mv. Som regel udføres der lidt af det hele, men det kan også ske at der fx kun udføres planlægning. Start: Kontakt med patienten eller konference om patienten. Slut: Når der ikke skal gøres mere med patienten lige nu. Hyppighed: Totalt: Ca pr. døgn. Pr. bruger: Op til 20 pr. døgn. Vanskeligt: Katastrofe med mange tilskadekomne. (Beskriv det hellere som et selvstændigt task. Se vejledningshæftet). Brugere: Subtask og varianter: Eksempel på løsning: Kode: 1. Identificér patient. Systemet kan læse et elektronisk armbånd, fx til bevidstløse patienter. 2. Vurdér patientens tilstand. Se åbne diagnoser og tilhørende indikationer. Se notater. Se resultater fra ydelser der tidligere er rekvireret og sammenhold dem med operationelle mål. Det data der skal overskues omfatter D1 2p. Problem: I dag skal klinikerne logge ind og ud af flere systemer for at se alt relevant data. 3. Giv ydelser der kan gives med det samme, fx blodtryk og SAT. 4. Følg op på planlagte ydelser og resultater. Kontrollér om tidsfrister er udløbet. 5. Justér diagnoser (ret, tilføj, slet, prioritér). Afstem med vejledninger. Skriv notater. 5p. Problem: Besværligt at få adgang til vejledninger. 6. Planlæg og bestil nye ydelser. Afstem med ledige tidspunkter hos alle parter - også patienten. (Se de lange subtask C11, C12 om medicinordinering, booking ). Systemet viser en oversigt på ét skærmbillede, fx med en Gantt-agtig tidsdimension. Brugeren kan vælge detaljer fra oversigtsbilledet. Systemet gør det let at registrere resultatet straks. Oversigten viser bestilte ydelser og deres tilstand, fx udløbne frister. Systemet kan vise vejledninger og checklister ud fra en valgt diagnose. For bookinger viser systemet ledige tider for alle parter. Leverandør skriver sin løsning med rødt her

40 40. B1. Flow Systemet skal kun støtte én slags flow: Behandling af en patient. Nedenstående er det generelle, logiske flow for en behandling. Mange af trinene kan udelades (fx trin 2 og 8) eller kan gentages flere gange under behandlingen (fx trin 3 til 9). Det logiske flow udføres i fysiske arbejdsopgaver (task), hvor en medarbejder en kort periode arbejder med patienten uden væsentlige afbrydelser. Kolonne 2 viser de relaterede task og subtask for hvert trin. Detaljerne fremgår af kapitel C. Trin i patientbehandling 1. Indskriv patienten enten via egen læge, ved henvendelse fra patienten selv eller akut (fx trafikuheld med bevidstløs patient). Task og subtask C1, C2 2. Indkald patienten og aftal tid. C Patienten ankommer til afdelingen. Undersøg hvad patienten fejler, herunder foretag diverse test på stedet eller via laboratorier. Stil diagnoser. 4. Planlæg behandling, herunder ordinér medicin, book tider, bestil implantater, etc. 5. Overfør evt. patienten til en anden afdeling, fx hvis der er flere diagnoser. C3 C10-1, 2, 3 C12 C10-6, C11, C13 6. Udfør behandling. C10-3, C14 7. Vurder resultatet. Udfør evt. yderligere test og udfør supplerende behandling. 8. Aftal kontrolbesøg. C10-6? 9. Patienten ankommer til kontrolbesøg. Udfør diverse test og evt. supplerende behandling. Aftal evt. næste kontrolbesøg og evt. behandling. 10. Aftal evt. hjemmepleje.? 11. Udskriv patienten og orienter relevante parter, fx egen læge eller sociale myndigheder. Patienten kan også være død. 12. Afregn tilskud eller egenbetaling. C8 C10 C10 C6, C7

41 41. Y-Fonden: C20. Vurder ansøgninger inden bestyrelsesmødet Dette task beskriver hvad et bestyrelsesmedlem gør inden bestyrelsesmødet. Start: Når der kommer en opfordring fra sagsbehandler eller et bestyrelsesmedlem til at se på ansøgninger eller når der er tid til at se på ansøgninger. Slut: Når alle er vurderet eller der ikke er mere tid lige nu. Hyppighed: Dagligt op til en uddelingsrunde. Brugere: Bestyrelsesmedlemmer. De fire bestyrelsesmedlemmer og sagsbehandleren har... Subtask og varianter: Tilbudt løsning: Kode: 1. Se på ansøgninger du skal vurdere, dvs. dem du ikke har vurderet og som er til dig som fagmedlem eller som er til hele bestyrelsen. 2. Se evt. på ansøgers historik, dvs. hvilke andre ansøgninger han har været inddraget i og bevilgede beløb. 3. Se på andre bestyrelsesmedlemmers vurdering og om den er vurderet som publiceringsegnet. 4. Se på de akkumulerede, bevilgede beløb for hvert uddelingsområde, på det samlede ansøgte beløb og på rådighedsbeløbet (se D1). 5. Noter din egen konklusion, kommentarer og evt. ændret beløb. Andre bestyrelsesmedlemmer vil kunne se dem. 6. Noter evt. dine private kommentarer, som andre ikke skal se. 7. Hvis du har vurderet ansøgninger som fagmedlem: Advisér andre bestyrelsesmedlemmer om at de skal se på disse ansøgninger. Systemet viser en liste af ansøgninger med status, beløb, mv. Se løsningsnoten nedenfor. Bruger kan sortere og filtrere på data. Kan ses på den enkelte ansøgning såfremt det er muligt at matche på enten cpr nr eller adresse. Synligt i listen. Feltet publiceringsegnet er ikke vist ovenfor men vil kunne vises i listen. Synligt fra listen. Øverst vises runden herunder det beløb som er afsat i runden. Anføres direkte i listen. Anføres direkte i listen. Ved at ændre status fra ikke set til enten set, godkendt eller afvist vil sagen automatisk blive synlig for...

42 42. Y-Fonden Løsningsnote Bestyrelsesmedlemmer tilgår systemet via en web-browser. Dette vil fungere fra en traditionel PC såvel som fra en ipad via VPN. Løsningen er skitseret herunder og fremvist for Y-Fonden. Dette billede er centralt for hele sagsbehandlingen i systemet og anvendes løbende af både sagsbehandler og bestyrelsesmedlemmer. Det er muligt at filtrere på de enkelte kolonner, herunder trafiklysene for det enkelte bestyrelsesmedlem. Dermed er det enkelt løbende at se om der er sket nye ting. Bestyrelsesmedlemmerne kan direkte fra dette billede ændre status og skrive offentlig såvel som privat kommentar for den enkelte sag, og via linket hurtigt gå til sagen for at se detaljer. Afhængigt af den specifikke opsætning vil det også være muligt at få adgang til fx ansøgningsdokumentet direkte fra denne liste.

43 43. SL-07 baggrund 1998: Aktionsforskning med hospital og tre leverandører. 2001: Tasks & Support: Proceedings of AWRE : Task descriptions as functional requirements. IEEE Software. 2005: VTU ministeriet skrev en standardkontrakt for IT-systemer, K02. Søren skrev standardkrav der skulle være bilag til kontrakten. 2007: Kontrakten klar som K-02. Krav+vejledning klar som SL-07 (eller SL-007?) 2009: IBM Rational vil bruge SL-07. Konklusion: Alt for meget skal ændres i deres Rational-system og -uddannelser (og SL-07 var ikke en trussel). 2011: Task descriptions versus use cases. Requirements Engineering Journal. 2015: SL-07 er blevet brugt med succes i 100+ virkelige projekter. For og imod 1. Meget hurtigere end den traditionelle metode (5-10 gange). 2. Meget kortere end traditionelle krav (50 sider vs ) 3. Egnet til både Agilt og standardsystemer. Venstre side meget stabile krav. 4. Ser let ud, men uden vejledning bliver det gamle krav i ny ramme. 5. Jurister og konsulenter tøver - tør de?

44 44. Kontrakt og SL-07 Hvilken kontrakt passer til SL-07? Servicemål både i kontrakt og SL-07? Hvad er bedst? Udviklingsmodel i kontrakt? Hvorfor? Leverandøren har erfaringen og ved bedst. Eksperiment: Gør kontrakten problem-orienteret. Flyt mest muligt til SL-07. Resultat 1. Kontrakt bliver 8 sider + 4 bilag (PLS er 32 sider + 16 bilag, K03 59 sider + 16 bilag). 2. Krav bliver 3½ side længere. Nye kravafsnit: K. Anskaffelsesprocessen K1. Anskaffelsesplan K2. Projektledelse K3. Problemstyring (issue management) K4. Kundens leverancer

45 45. Kilde: Samlet liste PLS, K02, K03 og SL Hvad skal leveres: Målsætning, krav, løsning, rettigheder. 28 emner 2. Hvordan og hvem: Metode, organisation, kundens leverancer. 24 emner 3. Hvornår og hvor: Tidsplan. 3 emner 4. Pris: Optioner, drift, ændring. 3 emner 5. Hvis ikke... : Ændringer, hæve, tvister 17 emner I alt 75 emner Gruppe Emne SL-07 PLS K02 K03 1 Baggrund og vision A Definitioner Overordnet løsning og A3 bilag 3b alternativer 1 Optioner A3 bilag Løsningsbekrivelse. A3+ud for 3.1.2, bilag bilag 3 (SL- Bilag 3 hvert krav 07 princip) 1 Flow B1 1 Forretningsmæssige mål B2 2 bilag 3a.i 1 Funktionelle krav C, D, E, F bilag bilag 3 bilag 3a.ii 1 Eksisterende og nyt HW og G1, G2 bilag bilag 2, 3 4 bilag 2 SW 1 Driftsansvar G bilag 7 Bilag 12 1 Systemets sikkerhed H 1 Brugervenlighed I 1 Standarder der skal følges J1 1 Uddannelse J Dokumentation J bilag bilag 4 1 Datakonvertering J4 3.6+bilag Installation J5 1 Udfasning J7 bilag 13 1 Svartider L1 3.4, bilag bilag 6 16, 17+bilag 11 1 Tilgængelighed L2 3.4, bilag bilag 6 16, 17+bilag 11 (driftseffektivitet) 1 Datalagring L3 1 Support L bilag 5 15+bilag Vedligehold L bilag bilag 5 15+bilag 10+12

46 46. En overraskelse man forebygger 22 dødsårsager Årsag A1: Sætter sig ikke ind i brugernes behov. Skaber ikke win-win (B1, B2) Årsag A2: Skriver ikke krav der dækker kundens behov (B1, B2, C, D, mv.) Årsag A3: Beskriver løsningen i detaljer. Ingen spillerum til leverandøren (C, D, mv.) Årsag A4: Kræver ind og tror det er gratis (C, D, mv.) Årsag A7: Vil have det hele på engang, fx hele landet, eller alle slags gæld (K1) Årsag A8: Planlægger ikke de nye arbejdsprocesser (B1, C) Årsag B1: Leverandør for optimistisk - den der lyver vinder (B3) Årsag B2: Kunden vurderer ikke løsningen, beder evt. leverandøren gøre det (B3, B4, B5, B6) Årsag B4: Forkerte kriterier til leverandørvalg (B4, B5, B6) Årsag C1: Sikrer ikke brugervenlighed, selv når man ved hvordan det gøres (I1, K1) Årsag C2: Designer skærmbillederne for sent (I1, K1) Årsag C3: Accepterer leverandørens løsningsbeskrivelse uden at forstå den (K2) Årsag C4: Kan ikke se hvor langt leverandøren er (K2, K3) Årsag C5: Vil have det på sin egen måde uden at se på leverandørens måde (C, D, mv.) Årsag D2: Overraskelser ved system-integration (B3) Årsag E1: Idriftsætter systemet med utilstrækkelig test (K3) Årsag F2: Tjekker ikke om systemet bruges som forventet (K1-17) Årsag G1: Ingen forretningsmæssige mål eller glemmer dem undervejs (B2, K2-8) Årsag G2: Justerer ikke planen ved overraskelser, men tror resten kan speedes op (K2) Årsag G3: Projektet vokser uden at nogen opdager det (K2) Årsag G4: Ser ikke faren i øjnene, men bagatelliserer risikoen (K2-9) Årsag G5: Pengene slipper op og parterne skændes i stedet for at samarbejde (K2) Hvis man altså følger kravene