Embed Size (px)
Citation preview
11
Gevinstrealisering i programmer – Er det slutbrugerne der gør forskellen?
25. Oktober 2018
Program
2
8:00 – 8:30 Ankomst og morgenmad
8:30 – 9:00 Hvordan står det til? – årets undersøgelse vedr. programledelse og gevinstrealiseringKaare 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
Hvordan står det til? – årets undersøgelse vedr. programledelse og gevinstrealisering
Know How
Kaare Pedersen og Anette Zobbe
Vi er blevet lidt trætte af Gevinstsurvey– og det er I vist også
4
Allerede i spørgsmålet ligger en antagelse
Lad os se på nogle af tallene
18,2
39,4 33,348,5
60,6
30,3 24,2 30,315,2
0
10
20
30
40
50
60
70
Pe
rce
nt
Hvilke områder fungerer BEDST i Jeres programmer? (sæt 3 krydser)
Hvilke områder fungerer DÅRLIGST i Jeres programmer? (sæt 3 krydser)
51,5
18,2 18,2 21,2 18,2
39,4 36,4 39,445,5
0
10
20
30
40
50
60
Pe
rce
nt
Hvilke områder mener du, er de VIGTIGSTE at få til at fungere i et program? (sæt 3 krydser)
48,5
12,1
42,4
24,2
54,563,6
30,315,2 9,1
0
10
20
30
40
50
60
70
Per
cen
t
9%
24%
27%
22%
14%
5%
0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00%
0-20 %
21-40 %
41-50 %
51-60 %
61-80 %
81-100 %
Pct besvarelser
An
del
af
gevi
nst
ern
eHvor stor en andel af gevinsterne realiseres?
26,50%
40,20%
34,60%
38,50%
0% 5% 10% 15% 20% 25% 30% 35% 40% 45%
Vi udpeger gevinstejere, der sikrer at dermåles og følges op
Vi følger ikke op men har en plan om at gøredet
Hvem har ansvaret for at gevinsterne realiseres?
2018 2017
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%
I praksis betyder det, at der ikke sker
så meget når projektet er lukket
19%
Hvordan bliver gevinstansvaret praktiseret?
4,30%
10,30%
12,80%
46,20%
14,80%
7,40%
22,20%
33,30%
0% 10% 20% 30% 40% 50%
Forandringer dækker andet end udd
Forandringsteam, der støtterforretningen
Forlænger projektet ind Irealiseringsfasen
Planlægger F I samarbejde medforretningen
Andel besvarelser
Hvordan sikrer I at forandringerne gennemføres?
2018 2017
4,30%
31,60%
8,50%
45,30%
10,30%
3,70%
22,20%
11,10%
55,60%
7,40%
0,00% 10,00% 20,00% 30,00% 40,00% 50,00% 60,00%
Ja, altid
Ja, ofte
Ved ikke
Nej, ikke så ofte
Nej, aldrig
Er disse forandringer en del af projektets budget?
2018 2017
Fordi vi ser, det vi spørger om,
men ikke ser på den måde vi ser på…!
Blinde pletter
I en rationel verden,
bliver tallene et paradoks, med enkelte lyspunkter
16
Udfordre vores mentale modeller
Programmet Forandringerne Gevinsterne
Den mekaniske, kausale model
17
Kompleksitet og mennesker
“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, 2016
A B
18
Udfordre vores mentale modeller
Programmet Gevinsterne
Komplekse forandringer mellem mennesker
Programmet Gevinsterne
19
Udfordre vores mentale modeller
Komplekse forandringer mellem mennesker hele tiden
Forretningen eller driftsorganisationen
Bestående af mennesker – der er rationelle og irrationelle
Programmet Gevinsterne
20
Udfordre vores mentale modeller
Komplekse forandringer mellem mennesker hele tiden
i en meget større og vigtigere verden end programmet
Samtalesalon – paradokser, årsager og dilemmaer
Know How
Jens Laugesen, Anette Zobbe og Pernille Thorup - moderator Kaare Pedersen
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).
Grundlæggende antagelse:
Organisationer brugerprogrammer og projekter med det formål at skabe gevinsterfor deres organization, ved at implementere de leverancer og forandringer, der er enforudsætning.
Tre antagelser drøftes isamtalesalon:
Freeze-unfreeze
Kommunikation
Styring
Antagelsen om Unfreeze-Freeze
Antagelsen om Kommunikation
LederenInteres-senter
Besked
Antagelsen om Styring
Program
27
8:00 – 8:30 Ankomst og morgenmad
8:30 – 9:00 Hvordan står det til? – årets undersøgelse vedr. programledelse og gevinstrealiseringKaare 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
21
20 skader
i 5 projekter
36 slags årsager
Flere?
Havari-
kommission
19 behandlinger og antal årsager de forhindrer7 Problem-orienterede krav
6 Pilot test
5 Tidlige prototyper og test
4 Juster plan ved overraskelser
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 TotalNogle årsager har to behandlinger
19 behandlinger
Se mere: Lauesen:
Damage and damage
causes in large IT
government projects
2
Hvorfor
elektronisk
tinglysning startede
som en katastrofe
Hvordan kunne det
være undgået?
Søren Lauesen
IT-University of
Copenhagen
E-mail: [email protected]
www.itu.dk/people/slauesen
Hvorfor rejsekortet blev 4 år forsinket
Hvordan forbedring nedsatte
produktiviteten (i begyndelsen?)
Hvorfor deres sagsbehandlingssystem
blev lukket
Søren Lauesen
IT-Universitetet i København
www.itu.dk/people/slauesen
Gældsinddrivelse (Skat, EFI)
Hvordan man spildte 600 M DKK på software
og udskød gæld for 70.000 M DKK i årevis
11
Hvordan forbedring nedsatte
produktiviteten (i begyndelsen?)29
Sundhedsplatformen (EPIC) Udviklet 2013 - 2016
Hvorfor?Analysefase
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 8.000 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
Observerede skader
Tid: 3 år for de første 2 hospitaler. +15 hospitaler i 2017. Ingen skade.
Pris: SW 1.100 M DKK. Ingen skade.
Uddannelse og tilpasning 1.700 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.
900 sider - 1800 krav: The system shall . . .
400 sider use cases
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
Analysefase
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
36 forskellige årsager i 5 projekter:
32
Grønt: Også i
Bonnerup 2001
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
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
Årsagsprofiler
Hvornår skete det?
10 Analysefase
4 Anskaffelse
5 Design
2 Programmering
1 Test
3 Idriftsættelse
11 Ledelse
36 I alt
Å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
Hvem gjorde det?
32 Kunden
15 Konsulenten
10 Leverandøren
5 Regeringen
62 I alt
I mange tilfælde
skyldtes det to parter
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
20 skader
i 5 projekter
36 slags årsager
Flere?
Havari-
kommission
20 behandlinger
20 behandlinger og antal årsager de forhindrer8 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
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 TotalNogle årsager kræver to behandlinger
Rød: Bruges sjældent
Kravskabelon SL-07Bestilt af VTU-ministeriet som led i K-02 (i 2007)
Udfordring: Gør alle slags krav problemorienterede
38. Kravskabelon SL-07 v5 (med EPJ-eksempel)
A. Vision, kontekst, vejledning . . .
B. Overordnede behov
B1. Flow
B2. Forretningsmæssige mål
B3. Tidligt bevis (POC)
B4-B6. Min-krav og tildelingskriterier
C. Task systemet skal støtte
C1. Indskriv patient
C10. Klinisk session . . .
D. Data systemet skal anvende
D1. Diagnoser
D2. Diagnosetyper . . .
E. Andre funktionelle krav
E1. Systemgenerede hændelser
E2. Udskrifter og rapporter
E3. Komplekse beregninger og regler
E4. Udbygning af systemet
F. Integration med eksterne systemer
G. Teknisk it-arkitektur
G1. Brug af eksisterende HW og SW
G2. Nyt hardware og software . . .
H. Sikkerhed
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
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
J4. Datakonvertering
J5-J7. Installation, Test, Udfasning
K. Kundens leverancer
L. Drift, support og vedligehold
L1. Svartider
L2. Tilgængelighed (driftseffektivitet)
L3. Datalagring
L4. Support
L5. Vedligehold
20% genbrug i
andre områder
1% genbrug
1% genbrug
50% genbrug
80%
80% genbrug
90% genbrug
30% genbrug
39. C10. Udfør klinisk sessionEn 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. 15.000 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 …
Systemet viser en oversigt på ét skærmbillede, fx med en Gantt-agtig tidsdimension. Brugeren kan vælge detaljer fra oversigtsbilledet.
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.
Systemet gør det let at registrere resultatet straks.
4. Følg op på planlagte ydelser og resultater. Kontrollér om tidsfrister er udløbet.
Oversigten viser bestilte ydelser og deres tilstand, fx udløbne frister.
5. Justér diagnoser (ret, tilføj, slet, prioritér). Afstem med vejledninger. Skriv notater.
5p. Problem: Besværligt at få adgang til
vejledninger. Systemet kan vise vejledninger og checklister ud fra en valgt diagnose.
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 …).
For bookinger viser systemet ledige tider for alle parter.
6p. Problem: Man glemmer dele af bestillingen. Systemet kan booke standardpakker af ydelser.
6q. Problem: Fejl når data først noteres på papir,
senere tastes ind. Systemet gør det let at registrere alting straks.
7. Evt. afslutning af indskrivning. (Se task C6).
Leverandør
skriver sin løsning
med rødt her
40. B1. FlowSystemet 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 Task og subtask
1. Indskriv patienten enten via egen læge, ved henvendelse fra patienten selv eller akut (fx trafikuheld med bevidstløs patient).
C1, C2
2. Indkald patienten og aftal tid. C1-4
3. Patienten ankommer til afdelingen. Undersøg hvad patienten fejler, herunder foretag diverse test på stedet eller via laboratorier. Stil diagnoser.
C10-1, 2, 3
C12
4. Planlæg behandling, herunder ordinér medicin, book tider, bestil implantater, etc.
C10-6, C11, C13
5. Overfør evt. patienten til en anden afdeling, fx hvis der er flere diagnoser. C3
6. Udfør behandling. C10-3, C14
7. Vurder resultatet. Udfør evt. yderligere test og udfør supplerende behandling.
C10
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.
C10
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.
C6, C7
12. Afregn tilskud eller egenbetaling. C8
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.
Systemet viser en liste af ansøgninger med status, beløb, mv. Se løsningsnoten nedenfor. Bruger kan sortere og filtrere på data.
2. Se evt. på ansøgers historik, dvs. hvilke andre ansøgninger han har været inddraget i og bevilgede beløb.
Kan ses på den enkelte ansøgning såfremt det er muligt at matche på enten cpr nr eller email adresse.
3. Se på andre bestyrelsesmedlemmers vurdering og om den er vurderet som publiceringsegnet.
Synligt i listen. Feltet ”publiceringsegnet” er ikke vist ovenfor men vil kunne vises i listen.
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).
Synligt fra listen. Øverst vises runden herunder det beløb som er afsat i runden.
5. Noter din egen konklusion, kommentarer og evt. ændret beløb. Andre bestyrelsesmedlemmer vil kunne se dem.
Anføres direkte i listen.
6. Noter evt. dine private kommentarer, som andre ikke skal se.
Anføres direkte i listen.
7. Hvis du har vurderet ansøgninger som fagmedlem: Advisér andre bestyrelsesmedlem-mer om at de skal se på disse ansøgninger.
Ved at ændre status fra ”ikke set” til enten ”set”, ”godkendt” eller ”afvist” vil sagen automatisk blive synlig for . . .
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. SL-07 baggrund1998: Aktionsforskning med hospital og tre leverandører.
2001: Tasks & Support: Proceedings of AWRE 2001.
2003: 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. 500-16.000)
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. Kontrakt og SL-07Hvilken 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. Kilde: Samlet liste PLS, K02, K03 og SL-071. 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 A1 1 2
1 Definitioner 2 1
1 Overordnet løsning og alternativer
A3 bilag 3b
1 Optioner A3 bilag 3 14
1 Løsningsbekrivelse. A3+ud for hvert krav
3.1.2, bilag 3 3.1+bilag 3 (SL-07 princip)
Bilag 3
1 Flow B1
1 Forretningsmæssige mål B2 2 bilag 3a.i
1 Funktionelle krav C, D, E, F bilag 2 3.1 + bilag 3 bilag 3a.ii
1 Eksisterende og nyt HW og SW
G1, G2 bilag 6 + 7 bilag 2, 3 4 bilag 2
1 Driftsansvar G3 14.5+bilag 7 Bilag 12
1 Systemets sikkerhed H
1 Brugervenlighed I
1 Standarder der skal følges J1
1 Uddannelse J2 17.2 3.7
1 Dokumentation J3 3.2.3 3.5+bilag 4 3.5 + bilag 4
1 Datakonvertering J4 3.6+bilag 3 3.6
1 Installation J5
1 Udfasning J7 bilag 13
1 Svartider L1 3.4, bilag 12 13+bilag 6 16, 17+bilag 11
1 Tilgængelighed (driftseffektivitet)
L2 3.4, bilag 12 13 + bilag 6 16, 17+bilag 11
1 Datalagring L3
1 Support L4 11+14.4+bilag 5 15+bilag 10+12
1 Vedligehold L5 3.3 + bilag 10 11+14.4+bilag 5 15+bilag 10+12
1 Rettigheder F0-6, -8, -9. J7 13 23 31+bilag 16
1 Licensbetingelser bilag 7a bilag 15 Bilag 16
1 Overtagelse 9 10 13
1 Delleverance 7.3 mv. 3.2.2
1 Rådgivning 3.2.4
2 Vejledning til leverandøren A2
2 Proof of concept (POC) B3 5.1
2 Minimumskrav B4
2 Tildelingskriterier B5, B6
2 Udviklingsmetode 3.1, 5, bilag 10 3, 5, 6 + bilag 7
2 Analysefase 3.1.1, bilag 14 5.2
2 Kundens godkendelse 3.1.3
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
