ITP Noter

Successkriterie: At få 02 med over 50% sandsynlighed inden for 1 uge

Tager udgangspunkt i eksamensopgaven fra 2015 på Absalon

General Shit og Tips 2

Metodeafsnit 3
Succeskriterier & Proces: 3
Valg af succeskriterier: 3
Eksempler på dårlige og gode succeskriterier (fra eksamensopgaven): 4
Proces & Plan for Måling af Succeskriterier: 5
Interessenter: 6
Identificering: 6
Analyse: 6
Mål: 6
Magt & Indflydelse: 7
Håndtering af Konflikter: 7
Risici: 7
Identificering: 7
Analyse: 8
Årsag: 8
Konsekvenser: 8
Sandsynlighed & Konsekvensniveau: 8
Handling for Forebygning og Formindskning af Konsekvenser: 9
Udviklingsmetoder: 10
Vandfald 10
SCRUM (Agile) 10
Modenhed: 11
General Shit og Tips
De 13 “Tjek”:

Gør opgaven overskuelig og systematisk, både for dig selv og for TA

Inkluder indholdsfortegnelse og del alle spørgsmål op i afsnit og underafsnit
Svar på alle spørgsmål inden for de 15 normalsider
Karakter bliver ikke givet på noget efter de 15 normalsider
Forside, indholdsfortegnelse og kildeliste tæller ikke med i normalsider, billeder og figurer gør
Vis bred forståelse af metoder og pensum
Tag udgangspunkt i både givne og selvvalgte kilder
Brug generelt tilgængelige kilder (bøger er bedst) - ikke betalte kilder
Punktform skal stadig være svaret i hele sætninger, ikke stikord
Skriv senest besøgt dato på webkilder - ting kan nå at ændre sig
Kildehåndtering:

Metodeafsnit
Er altid med i en eksamensopgave
Skriv det enten som indledning eller konklusion - eksemplet skriver indledning
Del op for hver underspørgsmål - eksemplet gør det også
Dokumenter rækkefølgen delspørgsmålene er svaret i - hvorfor og fordele/ulemper
Mest hvis man gør det på en anden måde end opgavens opdeling
Husk selvrefleksion af kildevalg og metodevalg:
- Hvad kan man gøre anderledes/bedre
- Hvilke udfordringer er der
- Hvordan er kilder fundet og behandlet (stolbarhed)
- Brug overstående punkter til kildehåndtering
- Argumenter for valg af metode og kilde
- Metoder behøver ikke være “korrekte” - argumentation for valget er vigtigere
Metoder til hver del: (Fra eksamensopgaven)
Succeskriterier - MOV, SMART
Interessenter - ingen specifik metode, diskuter håndtering af interessenter (samlet flere i en)
Risici - Hvilken skala der er brugt for at måle sandsynlighed/konsekvensniveau (1-10,
lav/middel/høj)

Succeskriterier & Proces:

Valg af succeskriterier:
Man kan tage udgangspunkt i målene for at finde kriterier
Brug MOV (Measurable Organizational Value) til at finde mål
Målene skal refereres til fra kilderne
Eksamensopgaven tager udgangspunkt i mål fundet med MOV
Brug SMART til at finde succeskriterier:
- Specifikke
- Målbare (procenttal)
- Accepterede (af alle)
- Realistiske
- Tidssatte (inden for x antal måneder eller år)

Der skal være forretningsmæssigt udbytte

Kriteriet skal kunne måles både før og efter produktet

Eksempler på dårlige og gode succeskriterier (fra eksamensopgaven):

Dårlige:

1. og 2. har ikke forretningsmæssigt udbytte (fælles standard el. overførsel af medicindata giver
ikke noget udbytte), derfor er de dårlige kriterier.
Fix: Ændrer kriterierne til at give forretningsmæssigt udbytte.

3. har ingen målbare værdier (værdien før kriteriet er ikke kendt, det er heller ikke angivet i %,
så derfor kan det ikke måles) eller tidsgrænse sat, derfor er det et dårligt kriterie.
Fix: Angiv en tidsgrænse og ændrer sekunder til %-værdier for at gøre det målbart (i stedet for
max. 5 sekunder, så max. 40% hurtigere end før).

Gode:
Alle tre kriterier har målbare værdier, tidssatte grænser, og vigtigst: de giver forretningsmæssigt
udbytte (hhv. fejlmedicinering, tid på admin. arbejde og øget arbejdskvalitet).

Andet eksempel fra Rigsrevisionen:

Dårligt kritierie: Løsningen skal udarbejdes af et brugerpanel med et helst 50% split af
brugergruppe 1 og brugergruppe 2.
Hvorfor er det dårligt?: Der er ikke noget forretningsmæssigt udbytte, der kan ikke angives en
tidsgrænse.
Godt kriterie udarbejdet fra det dårlige: Brugertilfredsheden af systemet skal forøges med
30% inden for 6 måneder fra idriftsættelsen.
Hvorfor er det godt?: Der er forretningsmæssigt udbytte (højere brugertilfredshed kan betyde
flere brugere af systemet) og der er en tidssat grænse på kriteriet.

Ens dårlige kriterier kan evt. bruges senere hen som løsninger til gode kriterier (f.eks. kan et
brugerpanel være med til at øge brugertilfredsheden ved at bearbejde en løsning sammen og
gøre begge parter så glade som mulige).

Proces & Plan for Måling af Succeskriterier:

Start med at argumenter for hvorfor det er godt at bruge SMART-kriterier (og MOV hvis man har
det)
Reflekter på hvilke typer af kriterier der er valgt og hvad de omhandler (forhold, økonomisk
besparelse, tidsbesparelse, brugerbehov, etc.)
Gennemgå hvordan man vil måle værdierne, både før og efter:
- Statistik
- Undersøgelser
- Stikprøver
- Spørgeskemaer
- etc.
Argumenter for valg af metoder til at måle værdierne
Evt. inkluder en tabel med før- og efter, og de brugte metoder (eksamensopgaven):

Bivirkning af dårlige kriterier - før-felterne er tomme. Undgå dette!

Interessenter:

Identificering:
De vigtigste interessenter at have med:
- Projektlederne
- Udviklerne/Leverandørerne
- Modtagerne af projektet
- Brugergrupperne (en eller flere, hvis der er)
- Sponsorater af projektet
- De ansatte (anderledes fra udviklere)

Behøver ikke argumentering for hvorfor interessenterne er valgt.

Analyse:
Når man skal gennemføre interessentanalysen, så opdel det i delspørgsmål hvor hver
interessent er dækket som et underafsnit:
Punkt 1:
- Interessent 1
- Interessent 2
- Osv osv.
Giver bedst overblik over opgaven.

Mål:
Skriv ikke at målet for en interessent er at levere/gennemføre projektet - det er deres opgave
Tænk på udbyttet og interessen for at få gennemført projektet - hvad vil interessenten gerne
have ud af at være involveret i projektet?

Dårligt eksempel:

Deres formål er ikke at indføre en løsning - det er deres arbejde. Deres formål ville hellere være
at få noget udbytte fra projektet.
Godt eksempel:

Formålene giver mening for interessenten (især det andet formål). Deres job er ikke dækket i
besvarelsen.

Magt & Indflydelse:

Argumenter for vurderinger af magt/sandsynlighed - lad være med bare at skrive “høj/lav magt”
Del magt og indflydelse op i separate afsnit (selvom eksamensopgaven ikke gør) - TA
Tabeller kan godt bruges til at illustrere magt og indflydelse, men argumentation er langt det
vigtigste

Håndtering af Konflikter:
Skriv om hvor meget hver interessent skal involveres, hvordan de skal involveres og hvor stor
en rolle deres involvering skal spille
Brug magt og indflydelse til at hjælpe her

Risici:

Identificering:
Tricky eksempel:

Som regel er forsinkelse af projektet ikke en risiko, men en konsekvens

I dette tilfælde er forsinkelsen pga. andre forudsatte projekter inden for sundhedssektoren,
derfor er det en risiko (da projekterne kan have betydning for FMK)

Generelle regler til at finde risici:

- Brug ikke risici som er grundet inkompetence
- Brug kilder til at finde relevante risici
- Risici uden for projektets rammer kan godt eksistere, men de skal være realistiske
(GDPR-ændringer f.eks.)
- Risici ud fra at man ikke kender alle projektets krav og rammer ved opstart kan godt
bruges (er ikke resultat af inkompetence)
- Risici ift. konflikter mellem interessenter (såsom brugergrupper) kan også gælde
I identificering, så skriv både risici og kort effekten af risici (eksempel fra afl. 3):

Begrund risici for at gøre det nemmere at overskue - hjælper med analysedelen

Analyse:
Svar enten en risici af gangen for alle delspørgsmål eller et delspørgsmål af gangen for alle
risici:
Risiko 1:
- Punkt 1
- Punkt 2
- Osv.

Punkt 1:
- Risiko 1
- Risiko 2
- Osv.

Eksamensopgaven bruger metode 2 - mere overskuelig.

Årsag:
Argumenter hvorfor risici er relevant
Kom med realistiske årsager
Risici kan godt have flere årsager
Referer evt. til kilder eller tidligere i opgaven

Konsekvenser:
Tænk over de negative effekter af risikoen
Konsekvenser behøver ikke kun at være tid- og økonomiomfattende
Eksempler på former af konsekvenser:
- Tid (forsinkelser)
- Økonomi (større budget end forventet)
- Omtale (brugere/andre parter kan give negativt pres)
- Mangel på implementering af funktioner

Sandsynlighed & Konsekvensniveau:

Det er godt at lave tabeller til at vise sandsynlighed/konsekvens
HUSK - Tabeller kan ikke stå alene - argumenter svarene uden for tabellen
Del sandsynlighed og konsekvensniveau op i separate afsnit (selvom eksamensopgaven ikke
gør) - TA
Eksempel fra eksamensopgaven:

Handling for Forebygning og Formindskning af Konsekvenser:

Tabeller kan igen bruges til at vise før-efter sammenligning
Husk igen at argumenter for handlinger
Dæk evt. Reduktion af sandsynlighed og konsekvens, samt omkostninger for de forebyggende
handlinger
Eksempel på tabel fra eksamensopgaven:
Udviklingsmetoder:
Nok ikke relevant, men godt at huske
To primære metoder - Vandfald & SCRUM (agile)

Vandfald
Sekventiel metode - hver fase bliver bearbejdet en ad gangen
Opdelt i fem faser:
- Analyse
- Design
- Programmering
- Testing
- Idriftsættelse & Vedligehold

Fordele:
Forløbet er tydeligt og kontrollerbart
Fremdrift og afslutning er sikret

Ulemper:
Fejl og mangler ift. nytteværdi fanges først senere i forløbet
Går lang tid før der skabes forretningsmæssig værdi
Sværere at tilpasse projektet indhold ift. ændringer i behov og eksterne ændringer

Bedst egnet til projekter med stabile krav og ændringer er ikke forventet undervejs
Foretrukket hvis projektgruppen mangler erfaring

SCRUM (Agile)
Iterativ metode - faserne bearbejdes flere gange under udvikling indtil tilfredshed er opnået
Krav og funktioner bliver udviklet delvist
Mere fokus på at udvikle et fungerende produkt frem for dokumentation

Fordele:
Resultater bliver hurtigt produceret selvom de er i mindre bidder
Det er nemmere at tilpasse sig potentielle ændringer og eksterne forhold
Fejl og mangler ift. nytteværdi fanges tidligere og kan bearbejdes under forløbet

Ulemper:
Forløbet og kravene er mindre tydelige fra start
Der er mindre sammenhæng i processen
Sværere at estimere projektets omfang og budget

Bedst egnet til projekter hvor man forventer ændringer eller hvor man ikke kender alle kravene
Modenhed:
Hvem giver en flying fuck

Ikke mig ;D