Mathias Rangel Wulff Bachelorprojekt 2008 - Konceptuel Model For Den Offentlige Projektmodel

“Den Offentlige Projektmodel”
elektronisk vejledt med DOPE
Mathias Rangel Wulff
Kongens Lyngby 2007

IMM-B.Eng-2007-64
Technical University of Denmark
Informatics and Mathematical Modelling
Building 321, DK-2800 Kongens Lyngby, Denmark
Phone +45 45253351, Fax +45 45882673
reception@imm.dtu.dk
www.imm.dtu.dk
IMM-B.Eng: ISSN
Summary
In 2003 a project model was developed for information technology in the

Danish counties. Despite that there are only 33% using a project model in 2007.
On the base of a user investigation and a deep analysis of the specification
of the model, this paper declare focus areas, implementation guidelines and
conceptual model that for fill the expectations of the user and not the point
of view of the designer.
Resumé
I 2003 blev der udviklet en projektstyringsmodel rettet mod IT-udviklingsprojekter

inden for det offentlige. På trods af det, er der i 2007 kun 33% af kommunerne
i Danmark der bruger en projektstyringsmodel til håndtering af IT-projekter.
Med baggrund i en brugerundersøgelse og en dybdegående analyse af Den
Offentlige Projektmidel, fremsætter denne afhandling fokusområder, anbe-
falinger for implementering og konceptuel model for hvordan et digitalt
værktøj, der skal udbrede brugen af modellen, kan indfri brugernes forvent-
ninger, frem for designerens mening og mentale model af problemet.
Forord
At arbejde med med denne afhandling, til det punkt hvor den er idag, har
ført mig igennem adskillige faser og overvejelser, men jeg erkender, at ved
slutningen af denne afhandling, har jeg haft svært ved undertrykke lysten
til at gå dyberer og videre. Det er det mest seriøse og dybtegående stykke
arbejde jeg hidtil har lavet og det har opslugt, optaget og krævet min fulde
person og opmærksomhed.
Seks uger inden afslutningen af denne afhandling kom Den Offentlige Projekt-
model ud i en ny udgave. Efter en grundig sammenligning har jeg vurderet at
forskellen på 2. og 3. udgave af Den Offentlige Projektmodel i hovedtræk er:
1. Risikoanalysen er bedre specificeret.

2. Usecasemodellen er kommet i ny udgave og ligger nu til grund for, og
supplerer, langt flere elementer fra Den Offentlige Projektmodel
3. Kvalitetsplanen er fjernet
4. Tilføjet forumteater og kollegial refleksion
De strukturelle ændringer er altså holdt på et minimum, mens fokus på

visse aspekter har ændret sig. Denne rapport afspejler stadig fuldt ud Den
Offentlige Projektmodel, men man kan opleve at visse områder er nedprior-
iteret i forhold til hvad 3. udgave af Den Offentlige Projektmodel ligger op
til. Alle sidehenvisninger i denne rapport gælder for 3. udgave Den Offentlige
Projektmodel(2007).
iv
Uden illustrationer, forord, resume og appendix fylder afhandlingen ialt 42

”normale word sider”. .
Til sidst et lille citat der, for mig, representerer et mantra der er essensielt når
to så fremmede væsner som en designer og en bruger, fra to så vidt forskellige
verdner, nærmer sig hinanden for at skabe sammen...
”In interacting with the environment, with

others, and with the artifacts of technology,
people form internal, mental models of them-
selves and of the things with which they are
interacting. Only these models provide pre-
dictive and explanatory power for understand-
ing the interaction.”
- Donald A. Norman
København, januar 2008
Mathias Rangel Wulff

v
Indhold
Summary i
Resumé ii
Forord iii
1 Introduktion 1
1.1 Baggrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Formål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Afgrænsning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Den Offentlige Projektmodel 4
2.1 Spilmanual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Brugervenlighed
- ikke bare teori 9
INDHOLD vii
3.1 Hvad er brugervenlighed? . . . . . . . . . . . . . . . . . . . . 9
3.2 Human-Computer Interaction (HCI) . . . . . . . . . . . . . . 11
3.3 Mentale modeller . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Konceptuelle modeller . . . . . . . . . . . . . . . . . . . . . . 12
4 Brugerundersøgelse 15
4.1 Baggrund for brugerundersøgelsen . . . . . . . . . . . . . . . . 15
4.2 Materiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Metode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.4 Resultater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Opsummering af brugerundersøgelse . . . . . . . . . . . . . . . 22
5 Systematisk analyse 23
5.1 Identifikation af aktører . . . . . . . . . . . . . . . . . . . . . 23
5.2 Analyse af krav og behov . . . . . . . . . . . . . . . . . . . . . 26
6 Konklusion 63
6.1 Konceptuel model . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Anbefalinger for implementering . . . . . . . . . . . . . . . . . 64
6.3 Oplæg til prototypeudvikling . . . . . . . . . . . . . . . . . . . 66
A Visuel fremstilling af identificerede behov i A3 format 70

Kapitel 1
Introduktion
1.1 Baggrund
I 2001 blev Den Digitale Taskforce nedsat i forbindelse med etableringen

af Projekt Digital Forvaltning. Projekt Digital Forvaltning blev iværksat af
regeringen og de kommunale parter for at fremme udviklingen af digital forvalt-
ning [5]. For at bidrage til, at flere myndigheder skulle bruge en projektmodel
i forbindelse med planlægningen af ITudvikling udviklede Den Digitale Task-
force, i samarbejde med Danske Regioner og Kommunernes Landsforening, i
2003 en projektstyringsmodel kaldet ”Den Offentlige Projektmodel”[22] bereg-
net til, at ”. . . understøtte offentlige myndigheder i at styre, dokumentere og
implementere projekter og hjælpe til at sikre, at potentielle gevinster bliver
realiseret.”[24]. Specifikationen beskriver hvordan et IT-udviklingsforløb bør
forløbe, hvilke dokumenter der bør udfærdiges og hvordan styringen skal være.
Alt sammen for at sikre, at projektet realiseres bedst muligt eller stoppes
inden det bliver en fiasko. Ikke desto mindre er der, Ifølge Danmarks Statistik
2007, kun 33 % af alle offentlige myndigheder der anvender en projektmodel
til styring og gennemførelse af digitaliseringsprojekter [22].
Den Offentlige Projektmodel består af en 58 siders specifikation samt ca.

30 skabeloner og eksempler på udfyldte skabeloner for de i specifikationen
beskrevne værktøjer og dokumenter.
1.2 Formål 2
Linkfactory er et 6 år gammelt softwarehus i centrum af København. De

leverer webbasserede værktøjer til kundespecifikke problemløsninger baseret
på open source systemer. Det er kommet dem for øre, at det er svært at
følge Den Offentlige Projektmodel, fordi der er mange elementer og detaljer
at holde styr på og de ca. 90 siders instruktion kan være uoverskuelige. En
digital oversigt eller et værktøj til at holde styr på detaljer, rækkefølger,
kommunikation og andet virker som en indlysende idé, men det findes ikke
endnu.
For at gøre det nemmere at bruge Den Offentlige Projektmodel har Linkfactory
planer om at udvikle et system kaldet ”DOPE”(Den Offentlige Projektmodel
Elektronisk) der skal effektivisere håndteringen af IT-udviklingsprojekter efter
de retningslinjer der er angivet i Den Offentlige Projektmodel
1.2 Formål
For at kunne udvikle DOPE må præmisserne for domænet kendes. Det vil sige
hvilken adfærd brugerne har, samt deres krav til og behov for hjælp. Denne
afhandling har til formål at analysere og dokumentere fokusområder der gør
at DOPE bedst muligt kan understøtte og skabe fremdrift for arbejdet med
Den Offentlige Projektmodel. Det sker igennem
En brugerundersøgelse af domænet
Men en triangulering af en kvantitativ- og kvalitativ tilgang foretages
en eksplorativ brugerundersøgelse der søger at afdække hvordan Den
Offentlige Projektmodel bruges.
En systematisk analyse
Med udgangspunkt i en kritisk gennemgang af specifikationen for Den
Offentlige Projektmodel identificeres krav til og behov hos brugerne.
Konceptuel model, fokusområder og anbefalinger

Slutlig kædes brugerundersøgelsen og analysen sammen så der med
baggrund i domænet, og ikke designeren, kan fremsættes fokusområder,
anbefalinger for implementering og konceptuel model for hvordan at
DOPE kan give brugerne af Den Offentlige Projektmodel den bedst
mulige hjælp.
1.3 Afgrænsning 3
Denne afhandling vil ligge til grund for en prototypeudvikling af DOPE.
1.3 Afgrænsning
Denne afhandling har ikke til formål direkte at dokumentere hvorvidt udviklin-
gen af DOPE er en god eller dårligt idé set ud fra et økonomisk synspunkt.
Emnet vil blive berørt, men kun overfladisk.
Kapitel 2
Den Offentlige Projektmodel
Når man læser specifikationen for Den Offentlige Projektmodel, er et af de

største problemer, at man ikke kan danne sig et overblik over hvordan man rent
faktisk håndterer et IT-projekt efter retningslinjerne, før man har læst den
2-3 gange igennem. Jeg mener, at problemet bunder i, at specifikationen tager
udgangspunkt i hvad resultatet af processen skal være, desværre på bekostning
af, at selve processen mod resultatet, mildt sagt, ikke er så velbeskrevet som
man kunne håbe. Som eksempel kan nævnes, at den samlede beskrivelse af
en af rollerne, er fordelt i 46 sætninger spredt på 41 sider (se punkt 5.2.1.1
på side 27). For at give læseren af denne afhandling et billede af hvad Den
Offentlige Projektmodel indeholder, har jeg her udfærdiget en vejledning hvor
der er brugt en analogi til, at Den Offentlige Projektmodel er specifikationen
for et brætspil kaldet ”DOP”.
2.1 Spilmanual
Formålet med spillet ”DOP”er at realisere et IT-projekt fra ide til brugbart
system hvis, og kun hvis, ulemperne/omkostningerne ved realiseringen ikke
overstiger fordelene ved det færdige system.
Spillet foregår i runder. Centralt i spillet er overgangene imellem runderne

2.1 Spilmanual 5
hvor spillet enten skal :
• Afsluttes (jf. formålet med spillet)
• Fortsætte som det er
• Gå til næste fase
Spillet gennemgår fire faser:
• Idébeskrivelse
• Analyse og planlægning
• Udvikling og implementering
• Afslutning og evaluering
Til hver fase er der forskellige krav til en række opgaver, der skal være løst
førend fasen er gennemført. Kun når alle opgaver i en fase er løst, kan spillet
gå videre til næste fase. Spillet foregår ved, at der i hver runde skal udfærdiges
en del af fasens opgaver, imens det imellem hver runde skal verificeres om
opgaverne er lavet korrekt og fyldestgørende. Hver fase kan altså have vilkårligt
antal runder.
Spillet er slut når sidste fase er gennemført, og alle er dermed vindere.
Før spillet
Inden spillet går i gang får hver spiller tildelt en af følgende roller:
1. Styregruppeformand
2. Projektejer
3. Projektleder
4. Projektdeltager
5. Brugerrepræsentant
2.1 Spilmanual 6
6. Leverandørrepræsentant
Det er vigtigt, for spillets dynamik, at hver spiller kun får tildelt én rolle.
Alle roller skal være fordelt. Det betyder altså, at der som minimum skal
være 6 personer til at spille, men normalt vil der være flere deltagere, fx i
form af rollen som projektdeltager. Nogen af rollerne er sat på hold sammen.
Styregruppeformand, brugerrepræsentant og leverandørrepræsentant er på
holdet ”styregruppe”. Der kan kun være én styregruppeformand i en styre-
gruppe og der kan kun være én styregruppe per spil. Projektlederen kan, efter
ønske, dele projektdeltagerne op i hold kaldet ”projektgrupper”. Teoretisk
set kan samme projektdeltager godt vær med i flere hold af gangen, men det
anbefales, at han/hun kun er tilknyttet ét.
Rollen ”projektleder”og projektgruppe-holdene er kun i spil under runderne.

Derimod er rollerne i styregruppen (”styregruppeformand”, ”brugerrepræsen-
tant”og ”leverandørrepræsentant”) kun er i spil i overgangene imellem run-
derne. Rollen som projektejer er altid i spil.
’Spil start
Spillet starter ved, at der trækkes et ”idekort”fra bunken (eller en ide til et
IT-projekt opstår). Styregruppen sætter sig sammen og udfærdiger, ud fra
ideen, formål og ønsket resultat samt økonomisk og tidsmæssig ramme for
dette spil. Samtidig aftales det spillerne imennem hvor lang tid den første
runde skal tage. Første runde er nu i gang.
Her, specifikt i første runde, er det opgaven ”projektinitialiceringsdoku-

ment”(se de nøjagtige specifikationer i Den Offentlige Projektmodel) der
skal laves. Det er projektlederens ansvar, at opgaven bliver løst. Til at hjælpe
sig har han projektmedarbejderne. Projektlederen kan gruppere arbejderne
i hold (projektgrupper) og tildele dem ansvaret for en bestemt (del)opgave.
Projektmedarbejderne og projektlederen må, udover når der uddeles ansvar,
kun kommunikerer via det værktøj der hedder emneloggen. Formålet med
en emnelog er, at projektlederen og projektmedarbejderne har et centralt
placeret kommunikationsværktøj, der sikrer, at der systematisk bliver fulgt
op på uforudsete opgaver undervejs i projektet. Hvis en medarbejder opdager
en fejl, mangel eller uforudset problem, skal dette straks noteres i emneloggen,
så projektlederen kan nå at reagere inden runden er slut.
Når en runde er slut skal projektlederen kommunikerer resultatet af runden til

2.1 Spilmanual 7
styregruppen. Dette gøres ved at udfærdige dokumentet ”projektstatus”(se de

nøjagtige specifikationer i Den Offentlige Projektmodel). Projektstatus er den
eneste kommunikation projektlederen har med styregruppen. Det er derfor
vigtigt, at der derigennem bliver kommunikeret alt relevant om runden, om
de ønskede opgaver blev løst og problemer opstået undervejs (emneloggens
nye punkter). Men statusrapporten indeholder også et konkret forslag til
indholdet af næste runde. Indholdet af næste runde afhænger naturligvis af,
om alle rundens opgaver blev løst.
Styregruppen sætter sig derefter sammen (til et styregruppemøde) og kigger

på hvordan rundens opgaver er løst. Styregruppen skal verificere, at rundens
opgaver er udført korrekt. Hvis styregruppen finder, at løsningen på en opgave
ikke lever op til forventningerne (angivet i specifikationen for Den Offentlige
Projektmodel) forkastes den og må indgå i næste runde. Dernæst gennemgås
projektstatus med vægt på om ny viden eller problemer betyder, at hele spillet
ikke kan holde sig inden for de tidsmæssige eller økonomiske rammer. Hvis
ikke, skal der tages stilling til om spillet skal stoppes. Næste runde starter
med ved at projektlederen får resume af styregruppemødet sammen med OK
om at fortsætte.
Hele kusten med spillet ligger i at afpasse tiden for runderne med omfanget
af opgaver samtidig med at de overordnede tidsrammer, sat fra startender,
ikke overskrides.
På figur 2.1 på side 8 ses en humoristisk visualisering af processen.

2.1 Spilmanual 8
Humoristisk visualisering af spillet DOP

s lu d e
OK
n
t
R u
Arbejdsgruppe
Runde Projektleder Styregruppemøde

Ny fase
Emnelog
Styregruppe
Arbejdsgruppe
R u Projekt
n status
s ta d e
rt
Arbejdsgruppe
Projektleder
Figur 2.1: Humoristisk visualisering af spillet DOP (se punkt 2.1 på side 4).
Kapitel 3
Brugervenlighed
- ikke bare teori
Resultatet af denne afhandling skal lede mod et, for at sige det med jævne
ord, godt og effektivt værktøj til håndtering af Den Offentlige Projektmidel.
For at et værktøj kan beskrives som værende ”godt og effektivt”, må det være
konstrueret, så det lader dets brugere opnå deres mål på den bedst mulige
måde. Ikke nødvendigvis selve resultatet 1 , men den bedst mulige proces mod
målet. Hele problemet ligger, først og fremmest, i at finde frem til hvordan
man finder denne ”. . . den bedst mulige proces mod målet”. Hvordan får
brugeren en brugervenlig måde at arbejde på?
De følgende afsnit søger at beskrive den teoretisk baggrund for det fokus der,
i denne afhandling, er lagt på brugercentreret designudvikling.
3.1 Hvad er brugervenlighed?
Den internationale standart organisation ISO specificerer, i ISO9241, bruger-

venlighed som følgende:
1
Hvis resultatet ikke er godt, er det muligvis det forkerte værktøj der er brugt.
3.1 Hvad er brugervenlighed? 10
Usability
The effectiveness, efficiency and satisfaction with which specified users
achieve specified goals in a particular environment. (ISO 9241)
Effectiveness
Accuracy and completeness with which specified users can achieve
specified goals in a particular environment
Efficiency
The resources expended in relation to the accuracy and complete-
ness of the goals achieved
Satisfaction
The comfort and acceptability of the work system to its users and
other people affected by its use
Et forsigtigt bud på en dansk opsummering er, at brugervenlighed sættes

til at være den komfort hvormed en specifik bruger præcist og fuldkomment
gennemfører en ønsket aktivitet samt effektiviteten ved denne gennemførelse.
Denne specificering understøttes godt af Center for Information and Commu-
nication Technologies på Danmarks Tekniske universitet [16] der angiver, at
målene for brugervenlighed er
• Effektivitet
• Hastighed
• Sikkerhed
• Værdi
• Nemt at lære
• Nemt at bruge
Set som mål for en entydig og absolut specificering af begrebet ”bruger-

venlighed”, kan begge disse beskrivelser virke vage i deres brug af relative
begreber som ”effektivitet”, ”komfort”og ”nemt”. Hvad der er nemt for nogen,
er svært for andre. Hvad der er effektivt for nogen, er ulideligt langsomt for
andre. Hvordan kan dette være en specificering? At rejse dette spørgsmål
er netop meningen med formuleringerne; at understrege, at man ikke kan
tage udgangspunkt i hvad brugervenlighed er, førend man specificerer hvem
3.2 Human-Computer Interaction (HCI) 11
den er rettet mod. Specifikationerne er bevidst vage fordi brugervenlighed

er et relativt begreb der må sættes i forhold til en modtager hver gang den
konkretiseres.
3.2 Human-Computer Interaction (HCI)
Brugervenlighed er altså, i sin natur, en ganske udefinerbar størrelse. Til

at fastholde den, om end i et flygtigt greb, i forsøget på at måle og veje
dens egenskaber må der trækkes på en lang række ”klassiske”områder som fx
kognitiv psykologi 2 , computervidenskab, sociologi, antropologi, lingvistik og
organisationsteori. Området hedder ”Human-computer interaction”(HCI) og
beskæftiger sig med design, evaluering og implementering af computersystemer
med udgangspunkt i interaktionen mellem bruger og system. HCI søger,
overordnet set, at dokumentere videnskabeligt hvordan der bedst skabes
mulighed for forståelse af sammenhæng hos mennesker, så de efterfølgende kan
forudsige korrekt resultatet af en handling tilknyttet et system [2]. Begrebet
”Mentale modeller”er derved centralt i spørgsmålet om brugervenlighed,
fordi det beskriver hvordan det menneskelige sind strukturerer viden og
løsningsmodeller.
3.3 Mentale modeller
Mentale modeller skabes, med baggrund i menneskets interaktion med verden

[2], som en psykologisk repræsentation af virkelige, hypotetiske eller imaginære
situationer[12] for at konkretisere deres usynlige og ofte komplekse forbindelser
[20], [3]. Ofte som fortolkning af den visuelle struktur samt observation af
hvordan enheden reagerer. Deres eksistens blev foreslået i 1943 af den skotske
psykolog Kenneth Craik der skrev at; sindet danner ”small-scale models”af
virkeligheden som bruges til at forudsige handlinger, resonerer ud fra og
tildele forklaring på hændelsesforløb [2], [19]. Det var Donald A. Norman
der, i hans bog ”The Design of Everyday Things”fra 1988[15], for første gang
brugte udtrykket ”mentale modeller”i forbindelse med HCI [19]. Han brugte
udtrykket til at beskrive hvordan et system bliver designet og implementeret
2
Kognitiv psykologi er en gren inden for psykologien der beskæftiger sig med mentale
processer så som problemløsning, hukommelse og sprog
3.4 Konceptuelle modeller 12
på basis af designerens mentale model, men forstås og bruges på basis af
brugerens mentale model og hvilke problemer dette kan give. Dårligt design
er, når designeren materialiserer sin mentale model og prøver på at tvinge
brugeren til at have den samme.
Løsningen er brugercentreret designudvikling. Brugercentreret designudvikling

er, når man, som designer af et system, accepterer, at de reelle brugere
er de eneste virkelige eksperter på området og derfor baserer designet på
observationer af deres adfærd i stedet for antagelser, gisninger og ideer om,
hvad der er i brugerens interesse. Netop fordi forståelsen for brugerens mentale
model er så essentiel i forbindelse med brugervenligt design, skal man i en
udviklingsproces fokusere på forståelsen af denne. Brugervenlighed er ikke
bare teori, men virkelighed og man må, som designer, derfor ud i verden og
skabe kontakt med brugerne.
3.4 Konceptuelle modeller
Inden for HCI er der en lang række metoder til at tilegne sig viden om
brugernes mentale model, men den viden er intet værd hvis den ikke kan
formidles tilbage til brugeren og resulterer i brugervenlighed. Det er i brugerens
møde med et artefakt, at interaktionen mellem disse, formidler den løsning,
som designeren har skabt til et problem. Men løsninger på stadig mere
komplekse problemstillinger kræver stadig mere ekspertise. En ekspertise som
designeren har, men som, for brugeren, ikke er andet end støj på vejen mod at
få løst en opgave 3 . Man kan sammenholde det med at køre bil. Hvis man, for
at kunne køre, skulle forstå alle detaljer ved motoren, ville den ikke være særlig
brugbar. I stedet er det nok at have forståelse for interaktionen med gearstang,
pedaler og ret, og efterfølgende ikke bekymre os om detaljerne. Designeren
må derfor maskere sin løsning, eller måske rettere; formidle sin løsning, så
brugerens mentale model af artefaktet er rettet mod de elementer der er
3
Læs ”Brug en hammer for at få åbnet flasken”. Bemærk at, det ikke er ”for at åbne
flasken”, men ”for at få åbnet”. Den tilsyneladende subtile forskel ligger i om man tager
udgangspunkt i, at man har processen med at åbner flasken som mål, eller om man har et
problem (fx man er tørstig) og til opnåelsen af sluttilstanden (fx ikke tørstig mere) har
som gøremål at åbne flasken og derfor søger at bruger et værktøj der kan hjælpe. Det
er også derfor, der her er brugt et utraditionelt værktøj til opnåelsen af sluttilstanden.
Pointen er netop, at hvilket værktøj der bruges, og hvordan det sker, ikke er vigtigt, men at
opnåelsen af sluttilstanden er det centrale. Dertil kommer så, om brugerens mentale model
kan håndtere åbningen af en flaske med en hammer, men det er en helt anden diskussion. . .
centrale i forhold til løsningen på et problem. Den ”maskerede løsning”på

et problem der formidles via interaktionen mellem et artefakt og en bruger
kaldes den konceptuelle model .
En konceptuel model er i virkeligheden blot en yderst simplificeret repræsen-

tation af det virkelige system [17]. Det er den overordnede ide for hvordan
brugeren skal realisere sine mål. [11]. Som før beskrevet bliver den kon-
ceptuelle model, for et artefakt, det udgangspunkt, som brugerens mentale
model udvikles fra. Derfor er den essentiel i forhold til genkendelse i og
udviklingen af brugerens mentale model. En hjørnesten i dét, er genbrug af
eksisterende mentale modeller hos brugeren til at danne forståelse på nye
områder. [17] Målet med den konceptuelle model bliver dermed at bringe
brugernes kendskab om adfærd fra den virkelige verden ind i artefaktet, for
at gøre dem i stand til at have brugbare og korrekte forventninger til hvilke
opgaver de kan gennemføre, samt hvordan disse realiseres. [11]. Og netop dét
er brugervenligt.
Denne afhandling søger at komme med sagligt dokumenterede forudsætninger

for at DOPE ikke bliver en fiasko. Jeg håber med dette afsnit at ha beskrevet
vigtigheden af den brugercentrerede indgangsvinkel til problemet.
Se figur 3.1 på side 14 for en visualisering af hvordan denne afhandling

skematiserer strukturen for brugervenlighed i domænet for Den Offentlige
Projektmodel.
Ud over de kildehenvisninger der er angivet i dette afsnit, kan jeg kraftigt

anbefale en række andre kilder om same emne, der har været mig til stor
nytte: [6, 7, 8, 9, 14, 1, 18]
IT-udviklingsprojekt
Specifikation for
Den Offentlige Projektmodel
Krav
Fysisk dagligdag
Teknisk løsning
Behov
Bruger Produkt
Interaktion
Performance
Brugervenlighed
Effektivitet
Tilfredshed
Afkast
Figur 3.1: Visualisering af hvordan denne afhandling skema-

tiserer strukturen for brugervenlighed i domænet for Den
Offentlige Projektmodel
Kapitel 4
Brugerundersøgelse
4.1 Baggrund for brugerundersøgelsen
For at efterleve dogmerne for brugercentreret design, må jeg tage udgangspunkt
i, at jeg ikke har forudgående indsigt i domænet. For at afdække og nuancere
hvordan Den Offentligt Projektmodel bliver brugt i brugernes dagligdag, fore-
tager jeg i det følgende afsnit en eksplorativ brugerundersøgelse af de danske
kommuners brug af projektstyringsmodeller til udvikling af IT-projekter, med
fokus på Den Offentlige Projektmodel. Undersøgelsen sigter mod en helheds-
forståelse for årsagssammenhæng med hensyn til udfordringer i forbindelse
med brugen af modeller.
4.2 Materiale
De kommuner der deltager i undersøgelsen er udvalgt efter størst lønindkomst

for den IT-udviklingsansvarlige i kommunen 1 med det argument, at jeg
formoder en sammenhæng mellem indkomst og arbejdsbyrde, det vil sige
IT-relateret udvikling i kommunen og derved sandsynlighed for, at kommunen
1
Data for lønindkomst var tilgængelig førend undersøgelsen blev foretaget.
4.3 Metode 16
har værdifuld information til den kvalitative undersøgelse. De 45 kommuner

hvor den IT-ansvarlige tjener mest er blevet kontaktet i forbindelse med
undersøgelsen. Deraf har 18 kommuner indvilget i at deltage i undersøgelsen.
Det er godt og vel hver femte danske kommune. I undersøgelsen har følgende
kommuner medvirket: Allerød, Faxe, Frederiksberg, Frederikshavn, Frederiksværk-
Hundested, Guldborgsund, Hillerød, Ishøj, Kalundborg, Kolding, København,
Lyngby-Taarbæk, Mariager fjord, Middelfart, Odense, Ringsted, Roskilde,
Slagelse. De personer der har deltaget i undersøgelsen har alle en stilling-
betegnelse som enten afdelingsleder for IT, centralforvaltningsdirektør med
ledelse og ansvar for IT, chefkonsulent i Digital Forvaltning, digitaliseringschef,
ikt-chef, it-chef, it-koordinator, it-projektleder, direktør i Koncernservice eller
leder af IT-udvikling. For at resultaterne ikke skal være personhenførbare er
information om kilden til resultaterne fjernet.
4.3 Metode
Der er brugt metodologiske triangulering 2 af en kvantitativ- og kvalitativ

tilgang til domænet. Metodologisk triangulering henviser til, at man søger
at udvide undersøgelsesgrundlaget ved at kombinere flere metodiske tilgange
til emnet (også kaldet between-method triangulation). Hvor den kvantitative
undersøgelse fokuserer på det overordnede billede af kommunernes brug af
udviklingsmodeller, søger den kvalitative analyse at belyse de udfordringer de
enkelte testdeltagere har i forbindelse med IT-udviklingsprojekter, med fokus
på Den Offentlige Projektmodel. Min metodologiske triangulering er brugt
som ”single case”, det vil sige hvor de to metoder tager udgangspunkt i data-
indsamling fra de samme personer. Ud fra data og teoretisk baggrund munder
den kvalitativ undersøgelse ud i en række af påstande om det undersøgte
domæne. Et centralt spørgsmål er dermed, hvornår påstande er velbegrundede
nok til, at andre har grund til at tage det, de konkluderer alvorligt. Der søges,
så vidt muligt, at bibeholde nærhed til de konkrete data så langt som muligt,
så en ”rød tråd”skal overbevise om, at der ikke er tale om gætværk.
Den kvantitative undersøgelse afdækker fem spørgsmål

2
Triangulering er et udtryk hentet fra søfarten, når man vil bruge flere udgangspunkter
for at bestemme et objekts nøjagtige position. Det angiver, at der bruges en kombination
af metodologier til undersøgelse af et fænomen.
4.3 Metode 17
Udvikler kommunen IT
Om kommunen køber standart IT-løsninger, eller om de selv står for
udviklingen
Bruger kommunen en model

Om kommunen har en nedskrevet strukturel metode til at gennemføre
IT-udviklingsprojekter.
Bruger kommunen Den Offentlige Projektmodel

Om kommunen bruger hele, eller uddrag, af Den Offentlige Projektmodel
til at gennemføre IT-udviklingsprojekter.
Er kommunen opmærksom på Den Offentlige Projektmodel

Hvis kommunen ikke bruger Den Offentlige Projektmodel er det inter-
essant at vide om de har fravalgt den, eller om de ikke kender den
(Kommuner der bruger Den Offentlige Projektmodel anses her som
opmærksomme).
Er kommunen tilfreds med den nuværende situation

Om kommunen har et ønske om at ændre deres situation. Fx ved, at de
er i færd med at udvikle deres egen model, eller er utilfredse med, at de
slet ikke bruger nogen.
Til den kvalitative brugerundersøgelse er der brugt semi-struktureret (tele-

fon)interview med det formål at indhente meninger og beskrivelser fra de
interviewedes daglige arbejde med IT-udvikling. Der er sammensat en inter-
viewguide, efter tragtmetoden, der søger at belyse forskellige sider af arbejdet
med Den Offentlige Projektmodel. Spørgsmålene er fokuserede, men samtidig
åbne og indbyder derved til konversation. Interviewet er formet ved opfølgende
og uddybende spørgsmål til de svar, der kommer til interviewguiden. For
at verificere, at fortolkningen af den interviewedes svar er korrekt, er der
brugt fortolkende spørgsmål så som ”Vil det sige, at du altså mener at. . . ”.
Interviewguiden indeholder følgende spørgsmål:
• Udvikler I software i kommunen
• Bruger I en udviklingsmodel når I udvikler software
• Kender I Den Offentlige Projektmodel fra Den Digitale Taskforce?
• Hvilken model bruger I til, at håndtere jeres IT-udvikling? Hvordan

bruger i den?
4.4 Resultater 18
Tabel 4.1: Resultat af en undersøgelse angående de danske kommuners

brug af projektstyringsmodeller til udvikling af IT-projekter, med fokus på
brugen af Den Offentlige Projektmodel (DOP). Se forudsætninger for data
i sektion 4 på side 15.
18 Kommuner indgik i undersøgelsen

18% Andel af samlet antal kommuner i Danmark
Følgende angiver andel af de adspurgte
33% Udvikler ikke selv IT
56% Bruger en model
17% Bruger DOP
67% Er tilfredse med den situationen de står i nu
22% Bruger en model men er ikke tilfreds med den situation de står i
50% Er opmærksomme på DOP
17% Bruger anden model men er ikke opmærksom på DOP
11% Bruger ingen model men er ikke tilfredse med situationen
• Har I sammenlignet jeres model med Den Offentlige Projektmodel?
• Hvor mange arbejder med IT udvikling hos jer?
• Hvilken rolle har du normalt?
• Hvordan håndterer I kommunikationen/informations flow?
• Hvilke værktøjer bruger I?
• Føler I, at har de styreværktøjer i ønsker?
• Hvad er de største problemer med hensyn til gennemførslen af udviklingspro-

jekter?
Begge undersøgelsen er foretaget med et telefonheadset til kommunikation og

en computer til at notere svar på. En optagelse af samtalen med en senere
analyse af indholdet have givet det bedste resultat, men det blev fravalgt ud
fra et tidsmæssigt hensyn.
4.4 Resultater
Resultatet af den kvantitative undersøgelse vises på tabel 4.1 på side 18
4.4 Resultater 19
Den kvalitative undersøgelse viser, at et større udvalg af kommunerne har

valgt ikke at udvikle IT selv. De får deres IT-behov opfyldt igennem eksterne
leverandører. Fx udtaler én kommune at ”Vi har ingen egenudviklet software.
Det kan ikke betale sig i forhold til at købe standardiserede løsninger igennem
KMD eller andre leverandører.”. Af de adspurgte er der 8/18 der bruger
en model de selv har udviklet. Alle er baseret på projektstyringsmodellerne
prince2 eller prince2-light. De fleste dog hovedsageligt på hovedfaserne i
prince2 ligesom Den Offentlige Projektmodel. Der er en tendens til, at denne
gruppe, der bruger deres egen model, mener, at Den Offentlige Projektmodel
blot er en ”fordansknin”af prince2-light og at det derfor ikke er nødvendigt at
anse Den Offentlige Projektmodel som noget nyhedsskabene man bør forholde
sig til. Kun 1/18 kommune kører rent efter prince2 light.
Mange kommuner har for nylig haft deres projektstyringsmodeller til overve-
jelse, fordi kommunesammenlægningerne i 2006 betød, at der skulle vælges
én model blandt to mulige. Processen har dog generelt ikke været en grundig
analyse grundet alle de andre aspekter, der har været i forbindelse med
kommunesammenligningen.
Informationsflow og arbejdsmetoder består gennemgående af mange forskellige

systemer, der ikke er integreret op mod hinanden. Programmet ”Microsoft
project”indgår ofte i processen. Mange steder har de skabeloner til at starte
på forskellige dokumenter. For en del gælder det, at kommunikationen og
verifikationen som hovedregel sker per email eller via fælles mappe til filer.
Forskellige værktøjer er implementeret uafhængigt af hinanden som fx en
kommune hvor ”Tit har vi et excel dokument til emneloggen, wordfiler til
dokumenter og en delt kalender til projektstyring”
3/18 kommuner er i øjeblikket i gang med at revidere deres eksisterende

projektstyringsmodel eller udarbejde en ny. Alle disse giver udtryk for, at de
har tænkt sig at se eller har set på om Den Offentlige Projektmodel indeholder
elementer de kan bruge.
Flere af testdeltagerne gav udtryk for manglende generel IT-udviklings strategi

i kommunen hvorved den politiske del med at forklare nødvendigheden heraf
er en af de største udfordringer mod at gennemføre IT-projekter efter en
projektmodel. I et enkelt tilfælde blev det kommenteret med: ”I vores afdeling
må kæmpe for at få projektstyring brugt i kommunen.”
Brugen af Den Offentlige Projektmodel er meget varieret. Er der tale om

et mindre projekt bruges modellen som tjekliste, mens alle aspekter med
4.5 Diskussion 20
rollefordeling og dokumenter kommer i spil ved større projekter. Som det

udtrykkes i en kommune: ”Brugen er meget varieret. Er det et projekt til
5000 kr., så bruges den bare til lidt tjek af det vigtige. I øjeblikket har vi et
projekt i gang til 700.000. Der har vi alt igang.” Generelt plukkes der meget
adhock fra elementerne i Den Offentlige Projektmodel, men gennemgående
bliver den brugt meget som tjekliste for indholdet i forskellige dokumenter.
Som det udtrykkes fra en kommune: ”Vi bruger nogle af principperne fra
Den Offentlige Projektmodel men som regel meget adhock, hvor vi plukker de
relevante dele ud til hvert projekt.”. Der gives udtryk for, at skalerbarhed er
et af de vigtigste elementer netop fordi projekterne varierer meget i størrelse.
Uafhængigt af om Den Offentlige Projektmodel blev brugt eller ej, var der
flere deltagere der gav udtryk for, at dét at bibeholde en model kan være
svært hvis der sjældent udvikles større IT-projekter, fordi det er nødvendigt
at vedligeholde en procedure regelmæssigt. Som en kommune udtrykker det:
”Vi har prøvet at lave vores egen kogebog, skabe en procedure, men der er
ikke volumen nok til at bibeholde den.” og en anden kommune i samme tråd:
”Vi brugte en gang prince2, men det gled ud i sandet. Mange medarbejdere
var unge, men da de smuttede igen forsvandt deres viden.”
4.5 Diskussion
At brugen af Den Offentlige Projektmodel er meget varieret, er helt i tråd med

Den Offentlige Projektmodel. I specifikationen står nemlig at ”projektmodellen
[er]. . . et for omfattende redskab at benytte i sin fulde udstrækning, når
det drejer sig om mindre projekter.” 3 . Til mindre projekter bruges den
mere som tjekliste over dokumenternes indhold, end som udgangspunkt for
værktøjerne projektplan, business case og risikovurdering, som der ellers står
som anbefaling til mindre projekter 4 .
Antallet af undersøgte kommuner i den kvantitative undersøgelse gør det

vanskeligt at generalisere ud fra resultaterne. Testgruppen er heller ikke
repræsentativ, til fordel for den kvalitative undersøgelse, så det er sandsynligt,
at billedet er misvisende i forhold til den reelle situation i de danske kommuner.
Det ses fx i idet faktum, at Dansk Statistik beskriver, at det kun er 33% af
alle danske kommuner der bruger en model til IT-udvikling [22] mod 56% i
3
Se side 2 i specifikationen for Den Offentlige Projektmodel [25]
4
4.5 Diskussion 21
denne undersøgelse. Det vides dog ikke om de 33% er af alle kommuner, eller
kun de kommuner der udvikler IT. På trods af denne usikkerhed er det ikke
desto mindre stadig påfaldende, at der overhoved er en andel der ikke bruger
nogen model, men er utilfredse med situationen.
3/18 kommuner bruger Den Offentlige Projektmodel. Man kan være tilbøjelig
til at mene, at udbredelsen af Den Offentlige Projektmodel dermed ikke
haft succes til at slå igennem. Men ifølge Mette Margrethe, der sidder i Den
Digitale Taskforce som hovedansvarlig for Den Offentlige Projektmodel, så var
projektmodellen aldrig ment som et værktøj der skulle erstatte de eksisterende
projektmodeller i det offentlige. Modellen er skabt for, at det offentlige kan
have en standart at debattere og måle op imod [10]. Sagt med andre ord
skal succesen for Den Offentlige Projektmodel dermed ikke ses i forbindelse
med hvor mange kommuner der kører udelukkende efter den, men derimod i
antallet af kommuner der tager deres allerede eksisterende projektmodeller
op til debat og sammenligner den med Den Offentlige Projektmodel. Om
Den Offentlige Projektmodel dermed kan karrakteriseres som en succes med
baggrund i data i denne brugerundersøgelse ligger uden for rammerne af
denne afhandling at vurdere.
17% bruger en projektmodel men er ikke er opmærksom på Den Offentlige

Projektmodel. En mulig grund kan være at den viden der ligger oparbejdet
hos medarbejderne i de kommuner der igennem mange år meget IT-udvikling
og derfor idag har klart strukturerede metodikker for udvikligsprojekter. Fx
har Frederiksberg kommune nu 60 medarbejdere der er uddannet i, og har fået
licens på deres færdigheder til prince-2 ligth. En omskoling af medarbejderne
vil være en stor økonomisk byrde [4]. ”Blot fordi man ikke har haft en generel
offentlig projektmodel før i tiden, betyder det jo ikke, at de offentlige instanser
ikke har brugt projektmodeller i mange år” siger Flemming Engstrøm 5 ,
der er senior projektansvarlig i Frederiksberg kommune. Han har arbejdet
med projektudvikling inden for det offentlige i 20 år og har aldrig oplevet,
at der ikke var en model at gå ud fra. Eksemplet illustrerer godt hvorfor
Den Offentlige Projektmodel har svært ved at nå ind til dem der har stor
erfaring inden for IT-udvikling. De har allerede invisteret tid og penge i en
gennemarbejdet procedure for udviklingsprojekter.
På den anden side har Den Offentlige Projektmodel den svaghed, at de kom-
muner der kunne have gavn af mere struktur i deres IT-udvikling, ikke har
volumen nok til at bibeholde de nødvendige kompetencer. Uafhængigt af
5
Flemming Engstrøm har givet samtygge til at blive citeret
4.6 Opsummering af brugerundersøgelse 22
hvilken model der er tale om, er der en tendens til, at informationsflowet

nærmer sig en ustrukturel struktur. Det betyder, at der tit skal dygtighed og
disciplin til, for at kunne manøvrere korrekt. Det er derfor ikke underligt, at
dét at bibeholde en model uden så mange projekter kan være svært. Dygtighed
og disciplin kræver naturligvis øvelse. Det er muligvis også derfor projekt-
modeller nogen steder anses som besvær. Simpelthen fordi der startes fra
bunden af hver gang et projekt sættes i værk. Svært tilgængelige dokumenter
og procedurer kan i høj grad ”skabeloniseres”via et digitalt værktøj. Derfor
kan en ”svært”tilgængelige projektmodel gøres langt mere implementerbar
i en digitalt håndteret udgave. Dette er et nøgleargumentet for, at der i
denne sidste gruppe vil være et marked for et digitalt værktøj, der på en kon-
struktiv og brugervenlig måde guider og hjælper med at følge Den Offentlige
Projektmodel.
Der er en større andel af kommunerne i brugerundersøgelsen der har det

til fælles, at de, ligesom Den Offentlige Projektmodel, har baseret deres
egen projekt på prince2 eller prince2-light. Det er uden for rammerne af
denne afhandling, men er ikke desto mindre interessant, at gå ind og se
på, om der er nogen mening i at udvikle DOPE, så det er rettet mod at
være så interpolerbart og moduleret, at det kan bruges til håndtering af
andre projektstyringsmodeller der, via fælles baggrund i prince2-light, er ”i
familie”med Den Offentlige Projektmodel.
4.6 Opsummering af brugerundersøgelse
I de danske kommuner er der stor variation i hvordan IT-udviklingsprojekter

bliver gennemført, men de kan overordnet inddeles i tre segmenter.Første
segment har ikke behov for en projektstyringsmodel, fordi de ikke selv udvikler
IT. Andet segment har Ikke brug for Den Offentlige Projektmodel fordi
de selv, igennem mange år, har udviklet IT og derfor allerede har klart
strukturerede og gennemarbejdede procedurer for udviklingsprojekter. Tredje
segment har allerede værktøjer og skabeloner til rapportudfærdigelse, mens
kommunikationen og verifikationen bære præg af manglende struktur. Det
betyder, at disciplin og projektoverblik skal ligge hos den enkelte bruger.
Hvis disse ikke trænes jævnligt er der en tendens til, at projektstyring bliver
uønsket besværlig. Det er for dette segment at DOPE vil være et effektivt
værktøj.
Kapitel 5
Systematisk analyse
Den anden vigtige indgangsvinkel til data vedrørende domænet, ud over

brugerne, er selve specifikationen for Den Offentlige Projektmodel. Med
udgangspunkt i en kritisk gennemgang søger jeg at identificere krav til og
behov hos brugerne. I første omgang skal de relevante aktører findes, for siden
hen at indgå i en dybtgående analyse.
5.1 Identifikation af aktører
At identificerer aktørerne i Den Offentlige Projektmodel er centralt i forhold

til at nå ind til hvem der er vigtige at sætte fokus på. Aktører er de
nøglepersoner/enheder der optræder inden for et domæne, der også har
et initialiserende operationelt ansvar. Specifikationen for Den Offentlige Pro-
jektmodel er gennemgået, for at identificere alle de nøglepersoner/enheder
der figurerer. Følgende nøglepersoner/enheder er fundet:
1. Styregruppe
2. Leverandørrepræsentant
3. Brugerrepræsentant
5.1 Identifikation af aktører 24
4. Projektejer
5. Styregruppeformand
6. Projektgruppe
7. Projektdeltager
8. Projektleder
9. Referencegruppe
Herfra skal det klarlægges om der foreligger et initialiserende operationelt

ansvar.
Styregruppe som aktør

Styregruppen er aktør, fordi det er en enhed, der er ansvarlig for at
træffe forskellige valg med indflydelse på projektets videre færd.
Leverandørrepræsentant og brugerrepræsentant som aktører
Leverandørrepræsentanten og brugerrepræsentanten er, som medlem af
styregruppen, aktører, men har intet operationelt ansvar i sig selv. Deres
roller udfyldes derfor af aktøren ”styregruppe”, så hverken leverandør-
eller bruger- repræsentanten er i sig selv aktører.
Projektejer som aktør
En projektejer er aktør, fordi han har ansvaret for at overvåge projektets
fremdrift på det strategiske niveau hvilket blandt andet indbefatter at
sikre, at risici bliver opsporet og afbødet samt efterspørge risikovur-
deringer, kvalitetssikring og evalueringer
Styregruppeformand som aktør
Styregruppeformanden er ikke aktør. Med definitionen på en projek-
tejer: ”en person med samme forpligtigelser som styregruppeformand,
men som ikke indgår i styregruppeaktiviteterne”ses det at, ved at
”vende”argumentet bliver en styregruppeformand; ”en person med
samme forpligtigelser som en projektejer, men som indgår i styregrup-
peaktiviteterne (som formand)”. Det operationelle ansvar der ligger hos
styregruppeformanden er altså dækket ind med de to aktører projektejer
og styregruppe. Dette gælder selv om det er styregruppeformanden, der
har den endelige beslutningsret i styregruppen. Hans rolle er måske
ikke den samme som andre medlemmer af styregruppeaktøren, men det
operationelle ansvar er det samme.
5.1 Identifikation af aktører 25
Projektgruppe
En projektgruppe har ansvaret for at (kilde: [23])
• Levere specialistprodukter
• Holde evt. bagland/hjemmeorganisation orienteret om fremdrift,
resultater og beslutninger i projektet mellem styregruppemøderne
• Sikre koordinering med bagland/hjemmeorganisation
Og har derfor ikke noget initialiserende ansvar der berettiger til at være
aktør.
Projektdeltager
Projektdeltageren er aktør, fordi det er hans arbejder der ligger til
grund for ændringer i projektet. En hændelse kan, igennem forskellige
værktøjer, som fx emneloggen, kan have indflydelse på projektlederens
beslutninger eller blive et emne hos styregruppen der kan lukke projektet
på den baggrund.
Projektleder som aktør

Projektlederen er aktør, fordi han er den person der har ansvaret for at
styre og planlægge projektet, og derved også at fremskaffe beslutnings-
grundlag og dokumentation, der vil ligger til grund for styregruppens
beslutninger.
Referencegruppe som aktør

I beskrivelsen af referencegruppen står, at de ”. . . sædvanligvis ikke
[har] egentlige kompetencer eller operationelt ansvar i projektet . . . ”.
De har derfor intet initialiserende operationelt ansvar og er derfor ikke
aktør.
5.1.1 Opsummering af aktører
Ud af de 9 nøgle personer/enheder der figurerer i specifikationen for Den

Offentlige Projektmodel er følgende fire aktører identificeret:
• Projektleder
• Styregruppe
• Projektejer
5.2 Analyse af krav og behov 26
• Projektdeltager
Den videre analyse vil tage udgangspunkt i disse fire aktører.
5.2 Analyse af krav og behov
Specifikationen stiller krav til aktørene. Disse krav genererer et behov hos den
enkelte aktør, for at få den viden der er nødvendig for at leve op til disse krav.
En grundig analyse af specifikationen er derfor vigtig, fordi det er aktørernes
behov der i sidste ende ligger til grund for de krav der stilles til en konkret
implementering af DOPE.
krav i specifikationen −→ krav til aktør

krav til aktør −→ behov hos aktør
behov hos aktør −→ krav til DOPE
Se også figur 3.1 på side 14 for en visualisering af hvordan denne afhandling
skematiserer strukturen for brugervenlighed i domænet for Den Offentlige
Projektmodel. Et af de største problemer med Den Offentlige Projektmodel
er, at beskrivelsen af den enkelte aktør skal findes spredt igennem hele
specifikationen. Nogen gange på mere end 30 sider. Følgende afsnit søger
at identificere hvad de fire aktører har af behov, ved først at lokalisere alle
beskrivelser af aktørens rolle. Alle beskrivelserne nedbrydes derefter til at være
konkrete krav til aktøren. Kravene gennemgås for dubletter og organiseres så
man får et bedre overblik over hvilke krav der reelt er. Når kravene dermed
er isoleret, ses der på hvad aktøren har behov for, for at kunne opfylde
hvert enkelt krav. Det sidste skridt er essentielt. Men hvad skal der til for,
at mine identificerede behov er velbegrundet, til forskel fra rent gætværk
eller ønsketænkning? Forudsætningerne for at forstå behovene er, først og
fremmest, at forstå brugeren. Behovene er derfor udarbejdet med baggrund
i den brugerundersøgelse der er foretaget (se punkt 4 på side 15) men i
erkendelse af, at brugerne er de virkelige eksperter på domænet, er dette
sidste trin foretaget i samarbejde med flere kilder [26, 13, 21, 10]
(Afsnittet kan virke langtrukkent med sine lange lister af behov og krav
der analyseres. Det er ikke desto mindre essentielt for at dokumentere den
proces der ligger til grund for resultatet af denne afhandling. Jeg har derfor
valgt ikke at sætte det i appendix. Næste afsnit er på side 63 hvis en hurtig
gennemlæsning ønskes.)
5.2.1 Styregruppe
Styregruppen i Den Offentlige Projektmodel er den aktør, der har ansvaret

for at styre og planlægge projektet. For at nå frem til de behov som styregrup-
pen har, finder jeg først alle beskrivelserne af aktøren. Efterfølgende brydes
beskrivelserne ned til krav der sorteres og organiseres. Først derefter kan der
ses på hvilke behov styregruppen har.
5.2.1.1 Krav til styregruppe
Læser man dokumentet ”Beskrivelse af roller og ansvarsområder i projektorganisationen”[23]

får man beskrevet, at styregruppen roller er karakteriseret ved
[sgA1] ”Ansvarlig for den overordnede ledelse og styring af projekt”
[sgA2] ”Fastlægge projektets formål og mål”
[sgA3] ”Fastlægge overordnet økonomisk ramme og overordnet tidsramme”
[sgA4] ”Sikre, at de nødvendige ressourcer bliver tildelt projektet”
[sgA5] ”Udpege projektleder samt aftale dennes ansvarsområder og mål”
[sgA6] ”Træffe beslutninger om tilrettelæggelse og gennemførelse af projekt”
[sgA7] ”Sikre projektets kurs i samspil med projektlederen”
[sgA8] ”Godkende og sikre finansiering af ændringer”
[sgA9] ”Vurdere, hvilken information der skal forelægges direktionen”
[sgA10] ”Godkende projektgrundlag”
[sgA11] ”Godkende projektinitieringsdokument”
[sgA12] ”Godkende opfølgnings- og statusrapporteringer”

[sgA13] ”Godkende hver færdiggjort fase”
[sgA14] ”Godkende planer for den næste fase”
[sgA15] ”Godkende evaluering af projektet”
[sgA16] ”Sikre, at alle produkter er blevet leveret tilfredsstillende”
[sgA17] ”Tage stilling til, hvor stor en afvigelse i forhold til den aftalte tidsplan/
de afsatte ressourcer, der skal accepteres, inden der tages stilling til
korrigerende handlinger”
[sgA18] ”Tage stilling til, om projektet på baggrund af den seneste opdaterede
business case og risikovurdering skal fortsætte eller nedlægges”
[sgA19] ”Det er styregruppens ansvar, at projektlederen bliver informeret om

begivenheder uden for projektet, der kan have indflydelse på projektet.”
I specifikationen for Den Offentlige Projektmodel er styregruppens rolle

yderligere nævnt 24 gange fordelt fra side 6 til side 47:
[sgA20] ”Styregruppen for projektet skal have forelagt de seneste resultater

for herefter at træffe beslutning om, i hvilken retning projektet skal
fortsætte 1
[sgA21] ”Faseplan med angivelse af leverancer skal godkendes af styregruppen 2
[sgA22] ”På baggrund af projektinitieringsdokumentet træffer styregruppen

beslutning om, projektet skal igangsættes eller ej 3
[sgA23] ”Når styregruppen har godkendt projektets endelige udformning, kan

planlægningen af projektet færdiggøres 4
5
[sgA24] ”Styregruppen har det overordnede ansvar for projektet.
1
Se side 6 øverst i specifikationen for Den Offentlige Projektmodel [25]
2
3
4
5
[sgA25] ”Undervejs i projektet er det styregruppen, der træffer en række valg

på baggrund af informationer (hovedsagligt) stillet til rådighed af pro-
jektlederen. 6
[sgA26] ”Tage stilling til hvor stor en afvigelse i forhold til den aftalte tidsplan/
korrigerende handlinger 7
8
[sgA27] ”Godkende afslutningen af en fase eller projektet
9
[sgA28] ”Godkende planlægningen af den næste fase
[sgA29] ”Tage stilling til, om projektet på baggrund af den seneste opdaterede
business case og risikovurdering skal fortsætte eller nedlægges 10
[sgA30] ”Det er desuden styregruppens ansvar, at projektlederen bliver informeret

om begivenheder uden for projektet, der kan have indflydelse på pro-
jektet. 11
[sgA31] ”Efter endt implementering, er det styregruppeformanden, der har

ansvaret for, at evalueringen bliver gennemført 12
[sgA32] ”På baggrund af projektinitieringsdokumentet (PID) træffer styregrup-

pen beslutning om, hvorvidt projektet skal igangsættes eller ej. 13
[sgA33] ”Styregruppen træffer på baggrund af projektinitieringsdokumentet en

beslutning, om projektet skal igangsættes eller ej. 14
[sgA34] ”Det er styregruppens ansvar at levere ressourcer, beslutninger og

mandat til projektet” 15
[sgA35] ”Ledelsen/styregruppen træffer på baggrund heraf [Potentialevurdering –

business case] beslutning, om projektet skal gennemføres i den foreslåede
form eller om projektet skal reorganiseres eller helt afvises.” 16
6
7
8
9
10
11
Se side 8 nederst i specifikationen for Den Offentlige Projektmodel [25]
12
13
14
15
16
[sgA36] ”Ved hver faseovergang skal der foreligge en opdateret business case, der
giver styregruppen mulighed for at vurdere, om gevinster og omkost-
ninger stadig står mål med hinanden.” 17
[sgA37] ”styregruppen [skal] primært forholde sig til den eller de risici, der har
særlig høj risikoværdi.” 18
[sgA38] ”Når styregruppen har taget stilling til projektets endelige udformning,
kan planlægningen af projektet færdiggøres, så der fremkommer en
detaljeret projektplan” 19
[sgA39] ”[Det er] styregruppen, der beslutter sig for den endelige model for
projektet.” 20
[sgA40] ”Når styregruppen har truffet beslutning om den endelige projektmodel,

kan projektplanen færdiggøres.” 21
[sgA41] ”Når styregruppen har truffet endelig beslutning om den løsning, som
projektet skal føre ud i livet mhp. at opnå de fastsatte projektmål, kan
der udarbejdes en detaljeret projektplan for projektet.” 22
[sgA42] ”Styregruppen tager ved udgangen af analysefasen stilling til, om pro-

jektet skal fortsætte i sin nuværende form eller om det skal ændres.” 23
[sgA43] ”Styregruppen bruger projektstatus til at overvåge fase- og projektfrem-

drift.” 24
[sgA44] ”Styregruppen skal træffes beslutning, om projektet skal overgå til næste
projektfase” 25
[sgA45] ”Styregruppen bruger projektetstatus til at overvåge fase- og projekt-

fremdrift.” 26
17
18
19
20
21
22
23
24
25
26
For at opretholde sporbarhed har hver beskrivelse fået en unik identifikation

der starter med ”sg”efterfulgt af et bogstav for iterationen af analysen. Alle
krav kan derved spores til kilden. Beskrivelserne fra Den Offentlige Proejt-
model er af blandet karakter. Ved at bryde beskrivelserne ned til krav og
efterfølgende kategoriseret dem opnås et bedre overblik. Referencen til hvorfra
et krav oprinder, er angivet efter beskrivelsen af kravet.
[sgB1] Aftale projektlederns ansvarsområder [sgA5]
[sgB2] Aftale projektlederns mål [sgA5]
[sgB3] Ansvarlig for den overordnede ledelse af projekt [sgA1]
[sgB4] Ansvarlig for den overordnede styring af projekt [sgA1]
[sgB5] Ansvarlig for gennemførelse af projekt [sgA6]
[sgB6] Ansvarlig for, at evalueringen bliver gennemført [sgA31]
[sgB7] Beslutte den løsning, som projektet skal føre ud i livet mhp. at opnå de
fastsatte projektmål [sgA41]
[sgB8] Beslutte om den endelige projektmodel. [sgA40]
[sgB9] Beslutte om projektet skal gennemføres i den foreslåede form eller om

projektet skal reorganiseres eller helt afvises på baggrund af Potentiale-
vurdering – business case. [sgA35]
[sgB10] Beslutte om projektet skal igangsættes eller ej på baggrund af projek-

tinitieringsdokumentet [sgA22]


[sgB13] Beslutte om projektet skal overgå til næste projektfase [sgA44]
[sgB14] Beslutte om, i hvilken retning projektet skal fortsætte efter at have fået
forelagt de seneste resultater [sgA20]
[sgB15] Beslutter den endelige model for projektet. [sgA39]
[sgB16] Fastlægge overordnet overordnet tidsramme [sgA3]

[sgB17] Fastlægge overordnet økonomisk ramme [sgA3]
[sgB18] Fastlægge projektets formål [sgA2]
[sgB19] Fastlægge projektets mål [sgA2]
[sgB20] Forholde sig til risici, der har særlig høj risikoværdi. [sgA37]
[sgB21] Godkende afslutningen af en fase eller projektet [sgA27]
[sgB22] Godkende evaluering af projektet [sgA15]
[sgB23] Godkende faseplan med angivelse af leverancer [sgA21]
[sgB24] Godkende hver færdiggjort fase [sgA13]
[sgB25] Godkende og sikre finansiering af ændringer [sgA8]
[sgB26] Godkende opfølgnings- og statusrapporteringer [sgA12]
[sgB27] Godkende planer for den næste fase [sgA14]
[sgB28] Godkende planlægningen af den næste fase [sgA28]
[sgB29] Godkende projektets endelige udformning [sgA23]
[sgB30] Godkende projektgrundlag [sgA10]
[sgB31] Godkende projektinitieringsdokument [sgA11]
[sgB32] Informere projektlederen om begivenheder uden for projektet, der kan

have indflydelse på projektet. [sgA19]
[sgB33] informere projektlederen om begivenheder uden for projektet, der kan

have indflydelse på projektet. [sgA30]
[sgB34] Levere ressourcer, beslutninger og mandat til projektet [sgA34]
[sgB35] Overvåge fase- og projektfremdrift via projektetstatus [sgA45]
[sgB36] Overvåge fase- og projektfremdrift via projektstatus. [sgA43]
[sgB37] Sikre projektets kurs i samspil med projektlederen [sgA7]
[sgB38] Sikre, at alle produkter er blevet leveret tilfredsstillende [sgA16]
[sgB39] Sikre, at de nødvendige ressourcer bliver tildelt projektet [sgA4]

[sgB40] Tage stilling til hvor stor en afvigelse i forhold til den aftalte tidsplan/
de afsatte ressourcer, der skal accepteres [sgA26]
[sgB41] Tage stilling til korrigerende handlinger [sgA26]
[sgB42] Tage stilling til projektets endelige udformning. [sgA38]
[sgB43] Tage stilling til, hvor stor en afvigelse i forhold til den aftalte tidsplan/
korrigerende handlinger [sgA17]
[sgB44] Tage stilling til, om projektet skal fortsætte i sin nuværende form eller
om det skal ændres. [sgA42]
[sgB45] Tage stilling til, om projektet, på baggrund af den seneste opdaterede
business case og risikovurdering, skal fortsætte eller nedlægges [sgA18]
[sgB46] Træffer en række valg på baggrund af informationer (hovedsagligt) stillet

til rådighed af projektlederen. [sgA25]
[sgB47] Udpege projektleder [sgA5]
[sgB48] Vurdere om projektet skal fortsætte eller nedlægges på baggrund af den
seneste opdaterede business case og risikovurdering [sgA29]
[sgB49] Vurdere, hvilken information der skal forelægges direktionen [sgA9]
[sgB50] Vurdere, om gevinster og omkostninger stadig står mål med hinanden

med baggrund i en opdateret business case. [sgA36]
Listen gennemgås endnu en gang for at få fjernet alle krav der er duplikeret i
betydning.
[sgC1] Aftale projektlederns ansvarsområder [sgB1], [sgA5]
[sgC2] Aftale projektlederns mål [sgB2], [sgA5]
[sgC3] Ansvarlig for den overordnede ledelse af projekt [sgB3], [sgA1]
[sgC4] Ansvarlig for den overordnede styring af projekt [sgB4], [sgA1]
[sgC5] Ansvarlig for gennemførelse af projekt [sgB5], [sgA6]
[sgC6] Ansvarlig for, at evalueringen bliver gennemført [sgB6], [sgA31]

[sgC7] Beslutte om projektet skal fortsætte eller nedlægges på baggrund af den
seneste opdaterede business case og risikovurdering [sgB45], [sgB9], [sgB8],
[sgB14], [sgB48], [sgA29], [sgA20], [sgA40], [sgA35], [sgA18]
[sgC8] Beslutte om projektet skal igangsættes eller ej på baggrund af projek-

tinitieringsdokumentet [sgB10], [sgB11], [sgB12], [sgB44], [sgA42], [sgA33],
[sgA22], [sgA32]
[sgC9] Fastlægge overordnet overordnet tidsramme [sgB16], [sgA3]
[sgC10] Fastlægge overordnet økonomisk ramme [sgB17], [sgA3]
[sgC11] Fastlægge projektets formål [sgB18], [sgA2]
[sgC12] Fastlægge projektets mål [sgB19], [sgA2]
[sgC13] Forholde sig til risici, der har særlig høj risikoværdi. [sgB20], [sgA37]
[sgC14] Godkende afslutningen af en fase eller projektet [sgB21], [sgB13], [sgB24],

[sgA13], [sgA44], [sgA27]
[sgC15] Godkende evaluering af projektet [sgB22], [sgA15]
[sgC16] Godkende faseplan med angivelse af leverancer [sgB23], [sgA21]
[sgC17] Godkende og sikre finansiering af ændringer [sgB25], [sgA8]
[sgC18] Godkende opfølgnings- og statusrapporteringer [sgB26], [sgA12]
[sgC19] Godkende planer for den næste fase [sgB27], [sgB28], [sgA28], [sgA14]
[sgC20] Godkende projektets endelige udformning [sgB29], [sgA23]
[sgC21] Godkende projektgrundlag [sgB30], [sgA10]
[sgC22] Godkende projektinitieringsdokument [sgB31], [sgA11]
[sgC23] Informere projektlederen om begivenheder uden for projektet, der kan

have indflydelse på projektet. [sgB32], [sgB33], [sgA30], [sgA19]
[sgC24] Overvåge fase- og projektfremdrift via projektetstatus [sgB35], [sgB36],

[sgA43], [sgA45]
[sgC25] Sikre projektets kurs i samspil med projektlederen [sgB37], [sgA7]
[sgC26] Sikre, at alle produkter er blevet leveret tilfredsstillende [sgB38], [sgA16]

[sgC27] Sikre, at de nødvendige ressourcer bliver tildelt projektet [sgB39], [sgB34],

[sgA34], [sgA4]
[sgC28] Tage stilling til hvor stor en afvigelse i forhold til den aftalte tidsplan/
de afsatte ressourcer, der skal accepteres [sgB40], [sgB43], [sgA17], [sgA26]
[sgC29] Tage stilling til korrigerende handlinger ved afvigelser i forhold til den
aftalte tidsplan/ de afsatte ressourcer [sgB41], [sgA26]
[sgC30] Tage stilling til projektets endelige udformning. [sgB42], [sgB7], [sgB15],
[sgA39], [sgA41], [sgA38]
[sgC31] Træffer en række valg på baggrund af informationer (hovedsagligt) stillet

til rådighed af projektlederen. [sgB46], [sgA25]
[sgC32] Udpege projektleder [sgB47], [sgA5]
[sgC33] Vurdere, hvilken information der skal forelægges direktionen [sgB49],

[sgA9]
[sgC34] Vurdere, om gevinster og omkostninger stadig står mål med hinanden

med baggrund i en opdateret business case. [sgB50], [sgA36]
En UML notation af kravene i form af et usecase-diagram over aktøren

styregruppe kan ses på figur 5.1 på side 60
5.2.1.2 Behov hos styregruppe
Efter at kravene er isoleret, kan jeg identificere hvilke behov styregruppen har
for at kunne opfylde disse krav. I og med at jeg som udenforstående ikke kan
vide hvilke behov der er, er de udarbejdet med baggrund i brugerundersøgelsen
(se punkt 4 på side 15) samt i samarbejde med en række brugere [13], [21]
Nogen af kravene er af meget overordnet karakter. Disse krav opfyldes ved

at opfylde en række delkrav, der alle allerede er angivet og de vil derfor ikke
indgå i den videre analyse.
• Ansvarlig for den overordnede ledelse af projekt [sgC3], [sgB3], [sgA1]
• Ansvarlig for den overordnede styring af projekt [sgC4], [sgB4], [sgA1]

• Ansvarlig for gennemførelse af projekt [sgC5], [sgB5], [sgA6]
• Træffer en række valg på baggrund af informationer (hovedsagligt) stillet

til rådighed af projektlederen. [sgC31], [sgB46], [sgA25]
Nogen af kravene har i deres egen beskrivelse indikeret, at der i specifikationen

for Den Offentlige Projektmodel allerede er taget højde for hvilke behov der er
for at kunne opfylde kravet. Disse krav vil derfor ikke indgå i den videre analyse,
eftersom der allerede er taget højde for dem i Den Offentlige Projektmodel
• Beslutte om projektet skal fortsætte eller nedlægges på baggrund af den

seneste opdaterede business case og risikovurdering [sgC7], [sgB45], [sgB9],
[sgB8], [sgB14], [sgB48], [sgA29], [sgA20], [sgA40], [sgA35], [sgA18]
• Beslutte om projektet skal igangsættes eller ej på baggrund af pro-

jektinitieringsdokumentet [sgC8], [sgB10], [sgB11], [sgB12], [sgB44], [sgA42],
[sgA33], [sgA22], [sgA32]
• Vurdere, om gevinster og omkostninger stadig står mål med hinanden

med baggrund i en opdateret business case. [sgC34], [sgB50], [sgA36]
• Overvåge fase- og projektfremdrift via projektetstatus [sgC24], [sgB35],

[sgB36], [sgA43], [sgA45]
Nogen af kravene er helt baseret på menneskelige kvalifikationer og de er

derfor ikke centrale i forhold til digital hjælp. De vil derfor ikke indgå i den
videre analyse.
• Aftale projektlederns ansvarsområder [sgC1], [sgB1], [sgA5]
• Aftale projektlederns mål [sgC2], [sgB2], [sgA5]
• Ansvarlig for, at evalueringen bliver gennemført [sgC6], [sgB6], [sgA31]
• Informere projektlederen om begivenheder uden for projektet, der kan

have indflydelse på projektet. [sgC23], [sgB32], [sgB33], [sgA30], [sgA19]
• Vurdere, hvilken information der skal forelægges direktionen [sgC33],

[sgB49], [sgA9]
• Udpege projektleder [sgC32], [sgB47], [sgA5]

Nogen af kravene drejer sig om emner, der baserer sig på elementer uden for
det centrale arbejdsområde for Den Offentlige Projektmodel. De vil derfor
ikke indgå i den videre analyse.
• Fastlægge overordnet økonomisk ramme [sgC10], [sgB17], [sgA3]
• Fastlægge overordnet overordnet tidsramme [sgC9], [sgB16], [sgA3]
1. Tage stilling til hvor stor en afvigelse i forhold til den aftalte tidsplan/
de afsatte ressourcer, der skal accepteres [sgC28], [sgB40], [sgB43], [sgA17],
[sgA26]
Følgende krav handler alle om at godkende et, i Den Offentlige Projektmodel,

klart specificeret dokument.
• Godkende afslutningen af en fase eller projektet [sgC14], [sgB21], [sgB13],

[sgB24], [sgA13], [sgA44], [sgA27]
• Godkende evaluering af projektet [sgC15], [sgB22], [sgA15]
• Godkende faseplan med angivelse af leverancer [sgC16], [sgB23], [sgA21]
• Godkende opfølgnings- og statusrapporteringer [sgC18], [sgB26], [sgA12]
• Godkende planer for den næste fase [sgC19], [sgB27], [sgB28], [sgA28], [sgA14]
• Godkende projektets endelige udformning [sgC20], [sgB29], [sgA23]
• Godkende projektgrundlag [sgC21], [sgB30], [sgA10]
• Godkende projektinitieringsdokument [sgC22], [sgB31], [sgA11]
De genererer derfor det samme behov.
[sgD1] Verificere at specifikationen for et dokument er fulgt, hvilket vil sige,

at dokumentet er udfærdiget så det følger formålet og indfrier de resul-
tatmål der angives i specifikationen.
Kravet ”Fastlægge projektets formål [sgC11], [sgB18], [sgA2]”er en del af det, i

Den Offentlige Projektmodel, klart specificerede dokument ”Formål og mål”.
For at kunne opfylde kravet er der behov for at
[sgD2] Specifikationerne for dokumentet følges, hvilket vil sige, at det udfærdi-
ges så det følger formålet og indfrier de resultatmål der angives.
Kravet ”Fastlægge projektets mål [sgC12], [sgB19], [sgA2] ”hører ind under det,
i Den Offentlige Projektmodel, klart specificerede dokument ”Formål og mål”.
For at kunne opfylde kravet er der behov for at
[sgD3] Specifikationerne for dokumentet følges, hvilket vil sige, at det udfærdi-
Kravet ”Forholde sig til risici, der har særlig høj risikoværdi [sgC13], [sgB20],
[sgA37]”genererer et behov for at
[sgD4] Have en oversigt over riskostyringen af projektet
Kravet ”Godkende og sikre finansiering af ændringer [sgC17], [sgB25], [sgA8]”genererer

et behov for at
[sgD5] Have en oversigt over hvorfor ændringer er opstået.
Kravet ”Sikre projektets kurs i samspil med projektlederen [sgC25], [sgB37],

[sgA7]”genererer et behov for at
[sgD6] Kunne se en status hvor projektet er. Det vil sige, hvilke dele af projektet
er færdiggjort.
[sgD7] Se hvilke områder projektet bevæger sig ind på. Det vil sige hvilke
elementer der skal til at arbejdes med.
Kravet ”Sikre, at alle produkter er blevet leveret tilfredsstillende [sgC26],

[sgB38], [sgA16]”genererer et behov for at
[sgD8] En oversigt over hvilke produkter der er leveret
[sgD9] Kunne verificere beskrivelse af produkt med resultat af produkt
Kravet ”Sikre at de nødvendige ressourcer bliver tildelt projektet [sgC27],

[sgB39], [sgB34], [sgA34], [sgA4]”har ummidelbart at gøre med elementer uden
for Den Offentlige Projektmodel, men for at kunne se på om der skal flere
rescurcer til projektet er der behov for at se på om produkter bliver leveret
til tiden og der med
[sgD10] En oversigt over planlagte leverancer
[sgD11] Kunne spore hvad ændringer har haft af indflydelse på tidsplanen
Kravet ”Tage stilling til projektets endelige udformning. [sgC30], [sgB42], [sgB7],
[sgB15], [sgA39], [sgA41], [sgA38]”er baseret på hele baggrunden for de to første
faser i Den Offentlige Projektmodel. Det betyder, at der allerede er taget
højde for det og det vil ikke indgå i den videre analyse
Kravet ”Tage stilling til korrigerende handlinger ved afvigelser i forhold til
den aftalte tidsplan/ de afsatte ressourcer [sgC29], [sgB41], [sgA26]”ligger op til
et behov for at
[sgD12] Oversigt over planlagte produkter/emner der er færdiggjort
[sgD13] Kunne spore hvad ændringer har haft af indflydelse på tidsplanen
5.2.1.3 Opsummering af styregruppe
Nogen af behovene er de samme. Ved denne opsummering er flere behov

smeltet sammen
[sgE1] En oversigt over hvilke produkter der er leveret [sgD8], [sgD12], [sgD6]
[sgE2] En oversigt over planlagte leverancer [sgD10], [sgD7]
[sgE3] Have en oversigt over hvorfor ændringer er opstået [sgD5],

[sgE4] Have en oversigt over riskostyringen af projektet [sgD4]

[sgE5] Kunne spore hvad ændringer har haft af indflydelse på tidsplanen [sgD11],
[sgD13]
[sgE6] Kunne verificere beskrivelse af produkt med resultat af produkt [sgD9]

[sgE7] Specifikationerne for dokumentet følges, hvilket vil sige, at det udfærdi-
ges så det følger formålet og indfrier de resultatmål der angives. [sgD2],
[sgD3]
[sgE8] Verificere at specifikationen for et dokument er fulgt, hvilket vil sige,

at dokumentet er udfærdiget så det følger formålet og indfrier de resul-
tatmål der angives i specifikationen. [sgD1]
5.2.2 Projektejer
Aktøren projektejer i Den Offentlige Projektmodel har det overordnede ansvar

for projektet. For at nå frem til de behov som projektejeren har, finder jeg
først alle beskrivelserne af aktøren. Efterfølgende brydes beskrivelserne ned
til krav der sorteres og organiseres. Først derefter kan der ses på hvilke behov
projektejeren har.
5.2.2.1 Krav til projektejer

får man beskrevet følgende om projektejeren
[peA1] ”Den absolut ansvarlige for projekt ”

[peA2] ”Sikre, at projektet indfrier sine formål ”
[peA3] ”Sikre, at projektet leverer de aftalte produkter ”
[peA4] ”Sikre, at der er en sammenhængende og effektiv projektorganisation
og planlægning ”
[peA5] ”Overvåge projektets fremdrift på det strategiske niveau ”
[peA6] ”Sikre at risici bliver opsporet og afbødet så effektivt som muligt ”
[peA7] ”Efterspørge risikovurderinger, kvalitetssikring og evalueringer ”
[peA8] ”Orientere, inddrage og skabe opbakning fra den politiske ledelse ”
[peA9] ”Håndtere alvorlige problemer i projektet ”
[peA10] ”Sikre at de nødvendige ressourcer er til rådighed i projektet i samråd

med projektlederen ”
I specifikationen for Den Offentlige Projektmodel er Projektejerens rolle ikke

nævnt et eneste sted. Det kan overraske lidt, men tilbage i identifikationen af
aktørerne (se punkt 5.1 på side 23) ses det, at aktøren projektleder deler ansvar
med styregruppeformanden, bortset fra deltagelsen i styregruppemøderne.
I Den Offentlige Projektmodel er beskrivelser af styregruppeformanden der
ikke involverer styregruppen kun at finde ét sted:
[peA11] ”. . . det [er] styregruppeformanden, der har ansvaret for, at evalueringen

bliver gennemført, og om eventuelle korrigerende handlinger føres ud i
livet.” 27
For at opretholde sporbarhed har hver beskrivelse fået en unik identifikation

der starter med ”pe”efterfulgt af et bogstav for iteration af analysen. Alle
krav kan derved spores til kilden. Beskrivelserne brydes ned til konkrete krav
for at få alle krav adskilt. Referencen til hvorfra et krav oprinder, er angivet
efter beskrivelsen.
[peB1] Ansvarlig for at evalueringen bliver gennemført [peA11]
[peB2] Ansvarlig for om eventuelle korrigerende handlinger føres ud i livet

[peA11]
[peB3] Ansvarlig for projekt [peA1]
[peB4] Efterspørge evalueringer [peA7]
[peB5] Efterspørge kvalitetssikring [peA7]
[peB6] Efterspørge risikovurderinger [peA7]
[peB7] Håndtere alvorlige problemer i projektet [peA9]

27
[peB8] Inddrage Den politiske ledelse [peA8]
[peB9] Orientere den politiske ledelse [peA8]
[peB10] Overvåge projektets fremdrift på det strategiske niveau [peA5]
[peB11] Sikre at de nødvendige ressourcer er til rådighed i projektet i samråd

med projektlederen [peA10]
[peB12] Sikre at der er en sammenhængende og effektiv planlægning [peA4]
[peB13] Sikre at der er en sammenhængende og effektiv projektorganisation

[peA4]
[peB14] Sikre at projektet indfrier sine formål [peA2]
[peB15] Sikre at projektet leverer de aftalte produkter [peA3]
[peB16] Sikre at risici bliver opsporet og afbødet så effektivt som muligt [peA6]
[peB17] Skabe opbakning fra den politiske ledelse [peA8]
En UML notation af de identificerede krav i form af et usecase-diagram over

aktøren projektejer kan ses på figur 5.2 på side 61
5.2.2.2 Behov hos projektejer
Efter at kravene er isoleret, kan jeg identificere hvilke behov for information,
der går forud for at kunne opfylde disse krav. I og med at jeg som uden-
forstående ikke kan kende disse behov, er de udarbejdet i samarbejde med
en række brugere [13] \{KajVestergaard} samt med baggrund i brugerun-
dersøgelsen (se punkt 4 på side 15).
Nogen af kravene er helt baseret på menneskelige kvalifikationer og de er

derfor ikke centrale i forhold til digital hjælp. De vil derfor ikke indgå i den
videre analyse.
• Ansvarlig for projekt [peB3], [peA1]
• Orientere den politiske ledelse [peB9], [peA8]

• Håndtere alvorlige problemer i projektet [peB7], [peA9]
• Inddrage Den politiske ledelse [peB8], [peA8]
• Skabe opbakning fra den politiske ledelse [peB17], [peA8]
• Ansvarlig for at evalueringen bliver gennemført [peB1], [peA11]
En hel del af kravene drejer sig om elementer som er helt fundamentale i

Den Offentlige Projektmodel. Disse krav opfyldes simpelthen ved at følge
specifikationen. Der er dermed tale om løkke i definitionen. Følgende krav vil
ikke indgå i den videre analyse, fordi det er selve Den Offentlige Projektmodel
der ligger til grund for opfyldelsen af kravet.
• Sikre at projektet indfrier sine formål [peB14], [peA2]
• Sikre at projektet leverer de aftalte produkter [peB15], [peA3]
• Sikre at der er en sammenhængende og effektiv planlægning [peB12],

[peA4]
• Sikre at risici bliver opsporet og afbødet så effektivt som muligt [peB16],
[peA6]
• Overvåge projektets fremdrift på det strategiske niveau [peB10], [peA5]
• Ansvarlig for om eventuelle korrigerende handlinger føres ud i livet

[peB2], [peA11]
• Sikre at der er en sammenhængende og effektiv projektorganisation

[peB13], [peA4]
• Sikre at de nødvendige ressourcer er til rådighed i projektet i samråd

med projektlederen [peB11], [peA10]
Flere af kravene er i realiteten en påmindelse til andre om leve op til deres

rolle i Den Offentlige Projektmodel.
• Efterspørge evalueringer [peB4], [peA7]
• Efterspørge risikovurderinger [peB6], [peA7]

• Efterspørge kvalitetssikring [peB5], [peA7]
Kravene genererer et behov for at have
[peC1] En oversigt over hvornår hvad skal laves og en påmindelse hvis tids-
grænsen overskrides
5.2.2.3 Opsummering af projektejer
Der er kun identificeret ét behov der er egnet til digital hjælp
• En oversigt over hvornår hvad skal laves og en påmindelse hvis tids-

grænsen overskrides [peC1]
5.2.3 Projektmedarbejder
Aktøren projektmedarbejder kan ses som dem der udfører ”brødarbejdet”i

projektet og følger projektlederens ansvarsuddeling. For at nå frem til de behov
som aktøren har, finder jeg først alle beskrivelser og bryder dem efterfølgende
ned til krav der sorteres og organiseres. Først derefter kan der ses på hvilke
behov projektmedarbejderen har.
5.2.3.1 Krav til projektmedarbejder

er der ingen beskrivelse af en projektmedarbejder. I introduktionen til Den
Offentlige Projektmodel (se punkt 2 på side 4) ses det, at aktøren projek-
tmedarbejder indgår i arbejdsgruppe. Jeg tager derfor udgangspunkt i at
kravene til en projektmedarbejder er de samme som til en arbejdsgruppe. Så
beskrivelsen af rollen kommer til at inkludere følgende punkter:
[pmA1] ”Levere specialistprodukter”

[pmA2] ”Holde evt. bagland/hjemmeorganisation orienteret om fremdrift, resul-

tater og beslutninger i projektet mellem styregruppemøderne”
[pmA3] ”Sikre koordinering med bagland/hjemmeorganisation”
I specifikationen for Den Offentlige Projektmodel er det ikke angivet nogen

beskrivelse af hverken aktøren projektmedarbejder eller arbejdsgruppe
5.2.3.2 Behov hos projektmedarbejder
I og med at jeg som udenforstående ikke kan vide hvilke behov der er for
at kunne opfylde disse krav, er de udarbejdet med baggrund i brugerun-
dersøgelsen (se punkt 4 på side 15) samt i samarbejde med en domæneekspert
fra Den Digitale Taskforce [10].
Kravet ”sikre koordinering med bagland/hjemmeorganisation [pmA3]”er helt

baseret på menneskelige kvalifikationer og de er derfor ikke centrale i forhold
til digital hjælp. De vil derfor ikke indgå i den videre analyse.
I kravet ”levere specialistprodukter [pmA1]”indgår begrebet ”specialistproduk-

ter”. Begrebet er ikke nævnt andre steder en i beskrivelsen rollen hvor kravet
oprinder fra. Ved at kontakte en domæneekspert er jeg kommet frem til, at
begrebet dækker over de i specifikationen for Den Offentlige Projektmodel
klart specificerede dokumenter som aktøren af projektlederen har fået til
opgave at udfærdige. Det betyder, at der er et behov for at
[pmB1] Specifikationerne for dokumentet følges, hvilket vil sige, at det udfærdi-
Kravet ”Holde evt. bagland/hjemmeorganisation orienteret om fremdrift, resul-

tater og beslutninger i projektet mellem styregruppemøderne [pmA2]”generer
et behov for at have
[pmB2] En oversigt over hvilke produkter der er leveret

[pmB3] En oversigt over hvilke områder projektet bevæger sig ind på. Det vil
sige hvilke elementer der skal til at arbejdes med.
[pmB4] Resumé af sidste styregruppemøde.
5.2.3.3 Opsummering af projektmedarbejder
Det er ganske tydeligt, at Den Offentlige Projektmodel ”. . . bidrager til at

skabe beslutningsgrundlaget for . . . ledelsesbeslutninger for projektet. . . ”28
og ikke er henvendt mod projektmedarbejderne eftersom der stort set ikke er
nogen direkte krav til dem. Alligevel har Den Offentlige Projektmodel stor
indflydelse på deres arbejde, fordi den ligger grundlaget for et godt styret
projekt og derved giver basis for en bedre arbejdsdag. Opsummeret er behovet
hos aktøren projektmedarbejder følgende punkter:
[pmC1] Oversigt over hvilke områder projektet bevæger sig ind på [pmB3]
[pmC2] Oversigt over hvilke produkter der er leveret [pmB2]
[pmC3] Resumé af sidste styregruppemøde. [pmB4]
[pmC4] Specifikationerne for dokumentet følges, hvilket vil sige, at det udfærdi-
ges så det følger formålet og indfrier de resultatmål der angives. [pmB1]
5.2.4 Projektleder
Denne analyse søger at finde frem til hvilke behov projektlederen har, for
at kunne leve op til de krav der stilles til ham i specifikationerne for Den
Offentlige Projektmodel.
Aktøren projektlederen har ansvaret for at styre og planlægge projektet, og

derved også at fremskaffe beslutningsgrundlag og dokumentation der vil ligger
til grund for styregruppens beslutninger 29 . For at nå frem til de behov som
projektlederen har, finder jeg først alle beskrivelserne af aktøren. Efterfølgende
brydes beskrivelserne ned til krav der sorteres og organiseres. Først derefter
kan der ses på hvilke behov aktøren har.
28
29
5.2.4.1 Krav til projektleder

får man beskrevet, at projektlederen skal
[plA1] ”Planlægge og overvåge projektet, herunder løbende opfølgning på

projektets mål og milepæle”
[plA2] ”Styre risici”
[plA3] ”Påtage sig ansvaret for den overordnede fremdrift samt anvendelse af
ressourcer og om nødvendigt initiere korrigerende aktiviteter”
[plA4] ”Rapportere til styregruppen.” Det angives efterfølgende til at være
[plA4a] ”Udarbejde projektgrundlag, projektinitieringsdokument og pro-
jektets dokumentation”
[plA4b] ”Udarbejde projekt- og faseplaner”
[plA4c] ”Udarbejde budget samt budgetstyring”
[plA4d] ”Evaluering af projektet”
I specifikationen for Den Offentlige Projektmodel er projektlederens rolle

yderligere nævnt 9 gange:
[plA5] ”Når projektet er afsluttet skal projektlederen afleverer en plan for,

hvordan projektet skal evalueres efter endt implementering.” 30
[plA6] ”Det er projektlederens ansvar at styre og planlægge projektet, herunder
at tilvejebringe beslutningsgrundlag og dokumentation til styregruppen.”
31
[plA7] ”Projektlederen skal, via emneloggen, sikrer, at der systematisk bliver

fulgt op på uforudsete opgaver undervejs i projektet.” 32
[plA8] ”Projektlederen skal træffe beslutning om, hvordan nye projektemner,
så som nye risici, eller i form af nye muligheder for at få mere ud af
projektet end først antaget, skal håndteres.” 33
30
31
32
33
[plA9] ”Projektlederen skal udarbejde en projektstatus for projektet med

passende mellemrum så der kan foretages korrigerende handlinger,
såfremt projektet afviger fra projektplanen.” 34
[plA10] ”Projektlederen skal, via projektstatus, advisere styregruppen om eventuelle

problemer eller områder, hvor styregruppen kunne hjælpe.” 35
[plA11] ”Projektlederen skal styre projektgrupperne ved at være opmærksom

på gruppens engagement og prioritering af arbejdsopgaver.” 36
[plA12] ”Projektlederen skal være opmærksom på projektgruppens kompe-

tencer i forhold til at løse diverse arbejdsopgaver. Han skal derfor se på
følgende:” 37
(a) ”\begin{enumerate}[label={{[}plA12\alph*{]}},ref={{[plA12\alph*{]}}}]
(b) ”Hvilke arbejdsopgaver, der skal løses”
(c) ”Hvilke kompetencer er nødvendige for at løse arbejdsopgaverne”
38
(d) ”Om der skal igangsætte læringsaktiviteter, for at opnå nødvendige

kompetencer i projektgruppen” 39
(e) ”Om der bør inddrages nye personer/kompetenceprofiler i projek-
tet” 40
[plA13] ”Har projektet lange tidsmæssige faser, bør der indlægges projektlever-
ancemilepæle i projektet, hvor projektlederen giver en løbende status
til styregruppen.” 41
For at opretholde sporbarhed, har hver beskrivelse fået en unik identifikation

der starter med ”pl”efterfulgt af et bogstav for iterationen af analysen. Alle
krav kan derved spores til kilden. Beskrivelserne fra Den Offentlige Proejt-
model er af blandet karakter. Ved at bryde beskrivelserne ned til krav og
efterfølgende kategorisere dem opnås et bedre overblik. Referencen til hvorfra
et krav oprinder, er angivet efter beskrivelsen af kravet.
34
Se side 38 og 47 i specifikationen for Den Offentlige Projektmodel [25]
35
Se side 38 og 47 i specifikationen for Den Offentlige Projektmodel [25]
36
37
38
39
40
41
[plB1] Planlægge projektet [plA1]

[plB2] Ansvar for at planlægge projektet [plA6]
[plB3] Udarbejde projektets dokumentation [plA4a]
[plB3a] Udarbejde projektgrundlag [plA4a]
[plB3b] Udarbejde projektinitieringsdokument [plA4a]
[plB3c] Udarbejde projektplaner [plA4b]
[plB3d] Udarbejde faseplaner [plA4b]
[plB3e] Udarbejde budget [plA4c]
[plB3f] Udarbejde budgetstyring [plA4c]
[plB3g] Ansvarlig for Evaluering af projektet [plA4d]
[plB3g1] Udarbejde plan for hvordan projektet skal evalueres efter endt
implementering [plA5]
[plB4] Overvåge projektet [plA1]
[plB4a] Udarbejde en projektsstatus for projektet [plA9]
[plB4b] løbende opfølgning på projektets mål [plA1]
[plB4c] løbende opfølgning på projektets milepæle [plA1]
[plB4d] Via emneloggen sikre, at der systematisk bliver fulgt op på uforud-
sete opgaver undervejs i projektet. [plA7]
[plB4e] Påtage sig ansvaret for den overordnede anvendelse af ressourcer
[plA3]
[plB4f] Være opmærksom på projektgruppens engagement [plA11]
[plB4g] Være opmærksom på projektgruppens prioritering af arbejdsop-
gaver [plA11]
[plB4h] Være opmærksom på projektgruppens kompetencer i forhold til
deres arbejdsopgaver [plA12], [plA12]b, [plA12]c
[plB5] Ansvar for at styre projektet [plA6]
[plB5a] Styre risici [plA2]
[plB5b] Initiere korrigerende aktiviteter for anvendelse af ressourcer hvis
det er nødvendigt [plA3]
[plB5c] Beslutte hvordan nye projektemner, så som nye risici, eller i form
af nye muligheder for at få mere ud af projektet end først antaget,
skal håndteres [plA8]
[plB5d] Igangsætte læringsaktiviteter, for at opnå nødvendige kompetencer

i projektgrupperne [plA12]d
[plB5e] Vurdere om der bør inddrages nye personer, for at opnå nødvendige
kompetencer i projektgrupperne [plA12]e
[plB6] Overordnede fremdrift [plA3]
[plB6a] Giver løbende status til styregruppen [plA13]

[plB6b] Rapportere til styregruppen [plA4]
[plB6c] Dokumentation til styregruppen. [plA6]
[plB6d] Beslutningsgrundlag til styregruppen. [plA6]
[plB6e] Ansvarlig for, via projektstatus, at advisere styregruppen om
eventuelle problemer [plA10]
I 3. iteration gennemgår jeg listen for at se om der er punkter, der har samme
betydning som andre. Projektlederen vil altid kunne uddelegere opgaverne der
kræves af ham, så beskrivelser som ”ansvarlig for”og ”udarbejde”er fjernet
for at komme ind til essensen af kravet.
Så tilbage er der, at projektlederen skal stå for følgende
[plC1] Projektets dokumentation [plB6b], [plB6c], [plB6d], [plB3], [plB1], [plB2],

[plA6], [plA4a]
[plC1a] Projektgrundlag [plB3a], [plA4a]

[plC1b] Projektinitieringsdokument [plB3b], [plB3b] [plA4a]
[plC1c] Projektplaner [plB3c], [plA4b]
[plC1d] Faseplaner [plB3d], [plA4b]
[plC1e] Budget [plB3e], [plA4c]
[plC1f] Budgetstyring [plB3f], [plA4c]
[plC1g] Plan for evaluering af projektet [plB3g1], [plA4d], [plA5]
[plC2] Overvåge projektet [plB4], [plA1]
[plC2a] Projektsstatus for projektet [plB4a], [plA9]

[plC2b] Opfølgning på projektets mål [plB4b], [plA1]
[plC2c] Opfølgning på projektets milepæle [plB4c], [plA1]
[plC2d] Følge op på uforudsete opgaver angivet i emneloggen. [plB4d], [plA7]
[plC2e] Anvendelse af ressourcer [plB4e], [plA3]

[plC2f] Projektgruppens engagement [plB4f], [plA11]
[plC2g] Projektgruppens prioritering af arbejdsopgaver [plA11]
[plC2h] Projektgruppernes kompetencer i forhold til deres arbejdsopgaver
[plA12], [plA12]b, [plA12]c
[plC3] Ansvar for at styre projektet [plB5], [plA6]
[plC3a] Initiere korrigerende aktiviteter for anvendelse af ressourcer hvis

det er nødvendigt [plB5b], [plA3]
[plC3b] Beslutte hvordan nye projektemner, så som nye risici, eller i form
af nye muligheder for at få mere ud af projektet end først antaget,
skal håndteres [plB5c], [plA8]
[plC3c] Igangsætte læringsaktiviteter, for at opnå nødvendige kompetencer
i projektgrupperne [plB5d], [plA12]d
[plC3d] Vurdere om der bør inddrages nye personer, for at opnå nødvendige
kompetencer i projektgrupperne [plB5e], [plA12]e
[plC3e] Evaluering af projektet [plB3g] , [plA4d],
Følgende punkter er smeltet sammen:
• [plB1] (Planlægge projektet) er smeltet sammen med [plC1]
• [plB2] (Ansvar for at planlægge projektet) er smeltet sammen med [plC1]
• [plB5a] (Styre risici) er smeltet sammen med [plC3]
• [plB4a] (Ansvarlig for, via projektstatus, at advisere styregruppen om

eventuelle problemer) er smeltet sammen med [plC2a]
• [plB6d] (Beslutningsgrundlag til styregruppen) er smeltet sammen med

[plC1]
• [plB6a] (Giver løbende status til styregruppen) er smeltet sammen med

[plC2a]
• [plB6b] (Rapportere til styregruppen) er smeltet sammen med [plC2a]

• [plB6c] (Dokumentation til styregruppen) er smeltet sammen med [plC1]
En UML notation af de identificerede krav i form af et usecase-diagram over

aktøren projektleder kan ses på figur 5.3 på side 62
5.2.4.2 Behov hos projektleder
I specifikationen for Den Offentlige Projektmodel ses det at der, for at opfylde
de forskellige krav, er der flere delelementer involveret. Formålet med den
næste oversigt er at se på hvilke behov brugeren har for at kunne opfylde
disse krav I og med at jeg som udenforstående ikke kan kende disse behov er
de udarbejdet med baggrund i brugerundersøgelsen (se punkt 4 på side 15)
samt i samarbejde med flere domæneeksperter [10], [21]
Kravene [plC1], [plC2] og [plC3] bliver defineres ud fra sine underpunkter og er

derfor nu blot sat som overskrift i kursiv
Projektets dokumentation
Kravet ”Projektinitieringsdokument [plC1b], [plB3b], [plA4a]”opfyldes ved at

udfærdige en række dokumenter 42 :
43
• Formål og mål
44
• Overordnet projektplan
45
• Projektorganisering
46
• Potentialevurdering/business case
• It-arkitektur og teknologi [17]
47
• Interessentanalyse
48
• Risikostyring
42
43
44
45
46
47
48
[plD1] Alle disse dokumenter er klart specificeret i Den Offentlige Projektmodel.

For at kunne opfylde kravet må specifikationerne for alle dokumenterne
følges, hvilket vil sige at udfærdige dokumentet så det følger formålet
og indfrier de resultatmål der angives.
Kravet ”Projektgrundlag [plC1a], [plB3a], [plA4a]”indeholder begrebet ”Projekt-

grundlag”. nævnes to gange i specifikationen for Den Offentlige Projektmodel
• ”På baggrund af projektgrundlaget udarbejdes en overordnet skitsering

af krav og ønsker vedr. it-arkitektur og teknologi.”49
• ”Allerede ved formuleringen af projektgrundlaget er det vigtigt at have

en overordnet projektplan, der angiver projektets tidsramme og de
vigtigste milepæle i projektet”50
Punkterne er ikke informative når det gælder fakta om indholdet af begræbet

”projektgrundlag”. Det viser sig imidlertid, at ”projektgrundlag”dækker over
det der andetsteds benævnes som ”beslutningsgrundlag”. Det ses fx i sæt-
ningen ”. . . der udarbejdes et projektinitieringsdokument (PID), der udgør
beslutningsgrundlaget for igangsættelse af projektet.”51 . Derfor er det identisk
med kravet ”Projektinitieringsdokument [plC1b], [plB3b], [plA4a]”der allerede
er dokumenteret.
Kravet ”Projektplaner [plC1c] [plB3c], [plA4b]”opfyldes ved udfærdigelsen af et

klart specificeret dokument.
[plD2] For at kunne opfylde kravet må specifikationerne for dokumentet følges,
hvilket vil sige at udfærdige dokumentet så det følger formålet og indfrier
de resultatmål der angives 52 .
Krav ”Faseplaner [plC1d], [plB3d], [plA4b] ”er ikke klart specificeret i Den
Offentlige Projektmodel. Den nævnes kun ét sted: ”Desuden skal der ved
afslutningen af en fase foreligge en detaljeret plan for aktiviteterne i den
49
50
51
52
efterfølgende fase. Denne faseplan med angivelse af leverancer skal godk-

endes af styregruppen. Faseplanlægningen bidrager dermed til forventningsaf-
stemningen i projektet samt den løbende kvalitetssikring. I faseplanen sker en
opdatering af de centrale dokumenter i projektet som f.eks. business casen,
interessentanalysen og risikovurderingen ved hver faseovergang.” 53 og er altså
karakteriseret ved
• Detaljeret plan for aktiviteterne i den efterfølgende fase
• Angivelse af leverancer i næste fase
• skal godkendes af styregruppen
Hvorved man kan se det som et dokument. Men den karakteriseres også
som ”Faseplanlægningen”og ”I faseplanen sker en opdatering af de centrale
dokumenter i projektet som f.eks. business casen, interessentanalysen og
risikovurderingen”hvorved man kan se det som et begreb for en ”opsum-
mering”inden næste fase. Med baggrund i domæneeksperterne sætter jeg
faseplanen til at være a) en udvidet statusrapport med beskrivelse af alle
kommende leverancer og b) en opdatering af centrale dokumenter i projektet.
Da både statusrapport og andre centrale dokumenter er behandlet andetsteds
vil kravet ikke indgå i den videre analyse.
Kravet ”Budget [plC1e], [plB3e], [plA4c]”er ikke yderligerer nævnt i specifikatio-

nen for Den Offentlige Projektmodel. Af føre budget ses derfor som værende
uden for de centrale områder for Den Offentlige Projektmodel, og punktet
udgår derfor.
Kravet ”Budgetstyring [plC1f], [plB3f], [plA4c]”er ikke yderligerer nævnt i speci-

fikationen for Den Offentlige Projektmodel. På samme baggrund som for
[plC1e] ses kravet derfor som værende uden for de centrale områder for Den
Offentlige Projektmodel, og kravet vil derfor ikke indgå i den videre analyse.
Kravet ”Plan for evaluering af projektet [plC1g], [plC1g], [plB3g1], [plA4d],

[plA5]”er ikke specificeret i Den Offentlige Projektmodel kun beskrivelsen
af hvad dokumentet ”evaluering”skal indeholde. For at kunne udfærdige
planen er der derfor behov for at
53
[plD3] Se hvilke specifikationer der er angivet for, at dokumentet er fyldestgørende
[plD4] Verificere at specifikationen for dokumentet er fulgt, hvilket vil sige, at

dokumentet er udfærdiget så det følger formålet og indfrier de resul-
tatmål der angives i specifikationen.
Overvåge projektet
Krav [plC2a] ”Projektsstatus for projektet [plB4a], [plA9]”er et klart specificeret

dokument der skal indeholde 54
• Budgetstatus
– Emnet er udgået ligesom punktet [plC1f]
• Produkter, der er færdiggjort i løbet af perioden
[plD5] Der er behov for en oversigt over produkter/emner der er færdig-

gjort
• Status for tidsplan
[plD6] Der er behov for en tidsplan der viser status for alle tidsrelaterede
faktorer
• Aktuelle eller potentielle problemer og risikoopdatering
[plD7] Der er brug for et sted til at notere potentioelle problemer samt
risikostyring
• Produkter, der skal færdiggøres i løbet af den efterfølgende periode
[plD8] Der er brug for en oversigt over hvornår hvad skal laves
• Status for evt. projektemner, jf. emneloggen
[plD9] Der er brug for emneloggen som kommunikationsværktøj mellem

projektgrupper og projektleder
• Eventuelle ændringers effekt på budget og tidsplan

54
[plD10] Der er behov for at kunne spore hvad ændringer har haft af indfly-
delse på tidsplanen
For at kravet ”Opfølgning på projektets mål [plC2b], [plB4b], [plA1]”kan opfyldes
er der behov for
[plD9] En oversigt over projektets mål og hvorlangt de er.
For at kravet ”Opfølgning på projektets milepæle [plC2c], [plB4c], [plA1]”kan

opfyldes er der behov for
[plD10] En oversigt over projektets milepæle og hvorlangt de er.
For at kravet [plC2d] ”Følge op på uforudsete opgaver angivet i emneloggen

[plB4d], [plA7]”kan opfyldes er der behov for
[plD11] En velfungerende emnelog
For at kravet ”[plC2e] Anvendelse af ressourcer , [plB4e], [plA3]”kan opfyldes

må der være
[plD12] En oversigt over hvordan ressourcer bruges
Kravet ”Projektgruppens engagement [plC2f], [plB4f], [plA11]”er basseret på

menneskelige faktorer der ligger til grund for vurdering af situationen. Som
hjælp til denne vurdering vil det være der være behov for [21]
[plD13] En oversigt over hvor langt projektgrupperne er med deres arbejde
Kravet ”Projektgruppens prioritering af arbejdsopgaver [plC2g], [plA11]”er

basseret på menneskelige faktorer der ligger til grund for vurdering af situ-
ationen. Som hjælp til denne vurdering vil det være der være behov for
[plD14] En oversigt over projektgruppernes arbejdsfordeling i forhold til andre

opgaver
For at kunne opfylde kravet”Projektgruppernes kompetencer i forhold til

deres arbejdsopgaver [plC2h], [plA12], [plA12]b, [plA12]c”er der behov for
[plD15] En oversigt over projektgruppernes kompetencer

[plD16] En oversigt over de kompetencer der kræves for at udføre forskellige
arbejdsopgaver
Ansvar for at styre projektet
For at kunne opfylde kravet ”Initiere korrigerende aktiviteter for anvendelse

af ressourcer hvis det er nødvendigt [plC3a], [plB5b], [plA3]”er der behov for
[plD17] En oversigt over ressourcefordelingen på projekter
kravet ”Beslutte hvordan nye projektemner, så som nye risici, eller i form af
nye muligheder for at få mere ud af projektet end først antaget, skal håndteres
[plC3b], [plB5c], [plA8]”er af udpræget menneskelig karrakter. Det vurderes
derfor, at det ligger uden for rammerne af det kommenende system og kravet
bortkastes.
For at kunne opfylde kravet ”Igangsætte læringsaktiviteter, for at opnå

nødvendige kompetencer i projektgrupperne [plC3c], [plB5d], [plA12]d”er der
behov for

arbejdsopgaver
For at kunne opfylde kravet ”Vurdere om der bør inddrages nye personer, for
at opnå nødvendige kompetencer i projektgrupperne [plC3d], [plB5e], [plA12]e”er
der behov for

arbejdsopgaver
Kravet ”Evaluering af projektet [plC3e], [plB3g] , [plA4d]”opfyldes ved udfærdi-

gelsen af et klart specificeret dokument.
[plD22] For at kunne opfylde kravet må specifikationerne for dokumentet følges,
hvilket vil sige at udfærdige dokumentet så det følger formålet og indfrier
de resultatmål der angives 55 .
Flere af behovene går igen. Ved at fjerne dem og skære overflødig tekst fra fås
listen over de behov projektlederen har for at kunne opfylde kravene i Den
Offentlige Projektmodel:
[plE1] Specifikationerne for udfærdigelsen af et dokument skal følges, hvilket

vil sige at udfærdige dokumentet så det følger formålet og indfrier de
resultatmål der angives [plD1], [plD2], [plD22]
[plE2] Se hvilke specifikationer der er angivet for, at dokumentet er fyldestgørende

[plD3]
[plE3] Verificere at specifikationen for dokumentet er fulgt, hvilket vil sige, at

tatmål der angives i specifikationen [plD4]
[plE4] Oversigt over produkter/emner der er færdiggjort [plD5], [plD6]
[plE5] Status for mål og milepæle samt hvad der kommer i fremtiden [plD6],
[plD8], [plD9], [plD10]
[plE6] Værktøjet emnelog [plD7], [plD9], [plD10], [plD11]
[plE7] Værktøjet risikostyring [plD7]
[plE8] Spore hvad ændringer har haft af indflydelse på tidsplanen [plD10]
[plE9] Oversigt over projektgruppernes kompetencer [plD15], [plD18], [plD20]
[plE10] Oversigt over de kompetencer der kræves for at udføre forskellige arbe-
jdsopgaver [plD16], [plD19], [plD21]
[plE11] Oversigt over hvor langt projektgrupperne er med deres arbejde [plD6],
[plD13]
55
[plE12] Oversigt over hvordan ressourcer i projektet bruges [plD12], [plD17]

[plE13] Oversigt over projektgruppernes arbejdsfordeling i forhold til andre
opgaver [plD14]
5.2.4.3 Opsummering af projektleder
De tekniske beskrivelser i specifikationen for Den Offentlige Projektmodel af

projektlederens rolle er brudt ned til krav. Kravene er bearbejdet og resultatet
er de behov som projektlederen, i følge Specifikationen for Den Offentlige
Projektmodel, har for at udfylde sin rolle.
[plF1] Oversigt over de kompetencer der kræves for at udføre forskellige arbe-
jdsopgaver [plE10]
[plF2] Oversigt over hvor langt projektgrupperne er med deres arbejde [plE11]
[plF3] Oversigt over hvordan ressourcer i projektet bruges [plE12]
[plF4] Oversigt over produkter/emner der er færdiggjort [plE4]
[plF5] Oversigt over projektgruppernes arbejdsfordeling i forhold til andre
opgaver [plE13]
[plF6] Oversigt over projektgruppernes kompetencer [plE9]
[plF7] Se hvilke specifikationer der er angivet for, at dokumentet er fyldestgørende
[plE2]
[plF8] Specifikationerne for udfærdigelsen af et dokument skal følges, hvilket

vil sige at udfærdige dokumentet så det følger formålet og indfrier de
resultatmål der angives [plE1]
[plF9] Spore hvad ændringer har haft af indflydelse på tidsplanen [plE8]
[plF10] Status for mål og milepæle samt hvad der kommer i fremtiden [plE5]
[plF11] Verificere at specifikationen for dokumentet er fulgt, hvilket vil sige, at
tatmål der angives i specifikationen [plE3]
[plF12] Værktøjet emnelog [plE6]
[plF13] Værktøjet risikostyring [plE7]
Usecase diagram for aktøren ”styregruppe”

Udpege Ansvarlig for den Ansvarlig for den
projektleder [sgC32] Ansvarlig for overordnede ledelse af projekt overordnede styring af projekt
gennemførelse af projekt [sgC5] [sgC3] [sgC4]
Aftale projektlederns
Aftale ansvarsområder [sgC1]
projektlederns mål [sgC2] Fastlægge overordnet
overordnet tidsramme [sgC9]
Fastlægge Fastlægge overordnet

projektets formål [sgC11] økonomisk ramme [sgC10]
Fastlægge
projektets mål [sgC12]
Beslutte om projektet skal

igangsættes eller ej på baggrund af
projektinitieringsdokumentet [sgC8]
Godkende
projektgrundlag [sgC21]
Godkende projektets
endelige udformning
[sgC20]
Godkende projekt-
initieringsdokument [sgC22]
Tage stilling til

projektets endelige udformning.
[sgC30]
Overvåge fase- og
projektfremdrift via
projektetstatus [sgC24] Godkende opfølgnings- og
statusrapporteringer
[sgC18]
Godkende faseplan med

angivelse af leverancer
[sgC16]
Styregruppe
Godkende planer for
den næste fase [sgC19]
Godkende afslutningen af
en fase eller projektet
[sgC14]
Sikre, at alle produkter er Sikre projektets kurs i

blevet leveret samspil med projektlederen
tilfredsstillende [sgC26] [sgC25]
Sikre, at de nødvendige
ressourcer bliver tildelt Forholde sig til risici,
projektet [sgC27] der har særlig høj
risikoværdi. [sgC13] Tage stilling til korrigerende
handlinger ved afvigelser i forhold til den
aftalte tidsplan/ de afsatte
ressourcer [sgC29]
Godkende og sikre
finansiering af ændringer
[sgC17] Ansvarlig for, at
evalueringen bliver gennemført
[sgC6]
Vurdere, om gevinster og
omkostninger stadig står mål med hinanden med
Vurdere, hvilken baggrund i en opdateret business case.
information der skal forelægges Godkende evaluering [sgC34]
direktionen [sgC33] af projektet [sgC15]
Trækker en række valg på baggrund Informere projektlederen om

Beslutte om projektet skal fortsætte
af informationer (hovedsagligt) begivenheder uden for projektet, der kan
eller nedlægges på baggrund af den
stillet til rådighed af projektlederen. have ind ydelse på projektet.
seneste opdaterede business case og
[sgC31] [sgC23]
risikovurdering [sgC7]
Figur 5.1: Usecase diagram over aktøren ”styregruppe”. Elementerne er struktureret så
de afspejler afspejler hvornår i processen de er centrale. Se afsnit 5.2.1.1 på side 27 for
dokumentation
Usecase diagram for aktøren ”projektejer”

Ansvarlig for
projekt [peB3] Sikre at der er en Sikre at der er en
sammenhængende og ekkektiv sammenhængende og ekkektiv
planlægning [peB12] projektorganisation [peB13]
Efterspørge
Efterspørge risikovurderinger [peB6]
evalueringer [peB4]
Efterspørge
kvalitetssikring [peB5]
Overvåge projektets
fremdrift på det strategiske
niveau [peB10]
Ansvarlig for om eventuelle

korrigerende handlinger føres
ud i livet [peB2]
Sikre at projektet
Projektejer leverer de aftalte produkter
[peB15]
Sikre at projektet
indfrier sine formål
[peB14]
Håndtere alvorlige
problemer i projektet Sikre at risici bliver
[peB7] opsporet og afbødet så ekkektivt
som muligt [peB16]
Sikre at de nødvendige ressourcer

er til rådighed i projektet i
Inddrage Den samråd med projektlederen [peB11]
politiske ledelse [peB8]
Ansvarlig for at
evalueringen bliver gennemført
[peB1]
Skabe opbakning fra den
Orientere den politiske ledelse
politiske ledelse [peB9] [peB17]
Figur 5.2: Usecase diagram over aktøren projektejer. Se afsnit 5.2.2.1 på side 40 for doku-
mentation
Usecase diagram for aktøren ”projektleder”
Udfærdige de konkrete
dokumenter angivet i
[plC1a] - [plC1g]
Udfærdige projektets
dokumentation [plC1] Udfærdige
projektsstatus for projektet [plC2a]
Følge op åp
projektets mål [plC2b]
Følge op på
projektets milepæle [plC2c]
Følge op på uforudsete
opgaver angivet i emneloggen
[plC2d]
Overvåge projektet
[plC2]
Overvåge anvendelse
af ressourcer [plC2e]
Projektleder
Overvåge
projektgruppens engagement [plC2f]
overvåge projektgruppernes
kompetencer i forhold til deres
arbejdsopgaver [plC2h]
Overvåge projektgruppens Initiere korrigerende

prioritering af aktiviteter for anvendelse af ressourcer
arbejdsopgaver [plC2g] hvis det er nødvendigt [plC3a]
Beslutte hvordan nye

projektemner skal håndteres
[plC3b]
Styre projektet
[plC3]
Igangsætte læringsaktiviteter,
for at opnå nødvendige kompetencer
i projektgrupperne [plC3c]
Vurdere om der bør inddrages nye

Gennemføre evaluering personer, for at opnå nødvendige
af projektet [plC3e] kompetencer i projektgrupperne [plC3d]
Figur 5.3: Usecase diagram over aktøren projektleder. Se afsnit 5.2.4.1 på side 47 for dokumen-
tation
Kapitel 6
Konklusion
Igennem en brugerundersøgelse (se punkt 4.6 på side 22) i og en dybdegående

analyse (se punkt 5 på side 23) af domænet, har jeg forudsætningerne for
at udnævne fokusområder, udbringe anbefalinger for implementering og kon-
struere en konceptuel model for DOPE der indfrier brugerens forventninger,
frem for at være gæt og gisninger.
6.1 Konceptuel model
Den opmærksomme læser vil ha bemærket, at der allerede er gjort rede for en
konceptuel model. Den er beskrevet er i sektion 2.1 på side 4. Den offentlige
projektmodel beskrives som et brætspil er et sagligt bud på en konceptuel
model for DOPE. Meningen er, som beskrevet i den teoretiske baggrund (se
punkt 3 på side 9), at du, kære læser, derved drager nytte af din mentale
model for en et artefakt du kender (brætspil) til at forstå Den Offentlige
Projektmodel.
Jeg skal for en god ordens skyld understrege at den konceptuelle model er
udfærdiget på baggrund af domæneundersøgelserne (se sektion 4 på side 15
og sektion 5 på side 23), omend afsnittet er placeret som det første i denne
afhandling.
6.2 Anbefalinger for implementering 64
6.2 Anbefalinger for implementering
Den målgruppe der er identificeret for DOPE (se punkt 4.6 på side 22) har
to centrale tendenser:
• Kommunikationen internt og verifikationen af udførte opgaver bærer

præg af manglende struktur
• En del værktøjer og skabeloner eksisterer allerede.
For at have en mulighed for at ”komme ind i varmen”hos målgruppen vil det
være en klar fordel at drage nytte af de elementer der i forvejen er tilgængelige.
Det betyder at i stedet for at eksempelvis udvikle en integreret kalender, skal
udviklingen af DOPE fokuserer på at kunne håndtere og visuelt præsenterer
indkommende og udgående kalenderemner (fx via ICS filer) fra Microsoft
Projekt. En stringent lagdelt serviceorienteret arkitektur må derfor spille en
central rolle i DOPE eftersom det gør det muligt at skabe differentierede
interfaces og dermed interpolaritet til andre systemer. En implementering
baseret på et model-view-controle-pattern (MVC) vil kunne tilbyde dette.
6.2.1 Fokusområder
Den Offentlige Projektmodel har fire centrale aktører (se punkt 5.1.1 på
side 25) der igennem deres ansvar for initialiserende handlinger hver for sig
står for en central del af arbejdet et IT-udviklingsprojekt når det håndteres
efter specifikationen for Den Offentlige Projektmodel. På figur 6.1 på side
69 ses en visuel fremstilling af de 26 behov der er identificeret 5 hos de
fire aktører; projektejer (se punkt 5.2.2.3 på side 44), projektmedarbejder
(se punkt 5.2.3.3 på side 46), styregruppe (se punkt 5.2.1.3 på side 39) og
projektleder (se punkt 5.2.4.3 på side 59). Visualiseringen ligger vægt på at
illustrere indbyrdes relationer mellem forskellige behov. Farverne på figuren
repræsenterer de naturlige grupperinger der kommer som følge heraf.
Fortolket ud fra visualiseringen, kan grupperingerne karakteriseres som de
centrale områder som DOPE skal fokusere på at løse, for at kunne opfylde de
behov som brugerne har for information. Vægten ligger i at disse elementer
ikke er gætværk eller meninger fra en designer, men derimod oprinder fra
selve domænet.
6.2 Anbefalinger for implementering 65
Sporbarhed af ændringer via værktøjet emnelog

Værktøjet emnelog er helt klart specificeret i Den Offentlige Projekt-
model. Teknisk set er det er et simpelt værktøj med en række emner
der kan kommenteres på. Emneloggen er helt central i Den Offentlige
Projektmodel, så det vil være oplagt at kommunerne allerede har en
eksisterende emnelog. Designet skal derfor gennemtænkes så det bliver
helt lagdelt. En implementering baseret på et model-view-controle-
pattern (MVC) vil kunne tilbyde dette.
Værktøjet risikostyring
Værktøjet risikostyring er helt klart specificeret i Den Offentlige Pro-
jektmodel. Teknisk set er det et er simpelt værktøj, men brugernes
krav til DOPE om at kunne spille op mod andre systemer gør, at
designet skal være skarpt lagdelt. En implementering baseret på et
model-view-controle-pattern (MVC) vil kunne tilbyde dette.
Kompetencer og arbejdsbyrde
At kunne vurderer kompetencerne i en gruppe er centralt for at kunne
tildele korrekt disponerede opgaver. En mulighed løsning er, at alle der
deltager i projektet får registreret deres kompetencer. Samtidig noteres
hvilke fagområder udviklingsprojektet indebærer. De to kan så matches
op mod hinanden. Jeg har en sådan løsning mistænkt for at være svær
at håndterer. frem for person til person kontakt, fordi det vil være
omstendigt at registrere alle nuancerne af menneskelige kompetencer.
Emnet må stå til genstand for yderligere undersøgelser.
Tidsmæssigt overblik over kommende opgaver.

Der er to aspekter ved en oversigt over kommende opgaver. Først og
fremmest skal det give et overblik over hvordan arbejdsbyrden bliver
fremover. Dernæst skal man kunne se hvad den næste opgave er, som
man bør gå i gang med. En løsningsmodel over et Gantt diagram
anbefales.
Udfærdigelse af opgaver efter deres specifikation

At få vejledning, eller rettere, at have let adgang til en liste over hvad
et dokument skal indeholde, gør det langt nemmere at udfærdige det
korrekt. Den Offentlige Projektmodel indeholder klare specifikationer af
indholdet i alle de dokumenter der er krævet. Fælles for specifikationerne
er at de alle har tilknyttet beskrivelsen ”formål”der angiver hvorfor
dokumentet skal udfyldes samt en række ”resultatmål”der er specifikke
og konkrete krav til hvad dokumentet skal indeholde for at være udfyldt
korrekt. Disse oplysninger er allerede samlet systematisk i specifikationen
6.3 Oplæg til prototypeudvikling 66
for Den Offentlige Projektmodel, så et elektronisk ”opslagsværk”vil

ikke udgøre forbedringer. Men ved at have disse oplysninger tilknyttet
emnerne i den tidsmæssige oversigt, nævnt i sidste punkt, vil man få
den fordel, at specifikationen er til rådighed så snart man skal udfærdige
et dokument.
Verificere at opgaver er udfærdiget efter deres specifikation

At verificere et dokument betyder at bekræfte, at samtlige resultatmål
(som nævnt ovenfor) for dokumentet er opfyldt. Det kræver altså at
man adgang til produkt og liste over adgang samtidigt.
Feedback på udførte opgaver.

Feedback sker ved at den der har udført en opgave, får kommunikeret
resultatet af verificeringen.
Overblik over færdige opgaver

Såfremt verificeringen godkender en opgave må dette fremgå tydeligt.
Det anbefales at udnytte samme løsningsmodellen som fra punktet
”Tidsmæssigt overblik over kommende opgaver”
Hvilke fokusområder der skal prioriteres, er et spørgsmål der, naturligvis,

kræver, at de virkelige domæneeksperter bliver inddraget. På samme måde,
er (prototype)udviklingen af den visuelle fremstilling, der udgør interaktionen
mellem DOPE og brugeren, en iterativ proces hvor brugernes mentale modeller
må studeres nøje. Metoder som visuel perception og cardsort af emner der
skal prioriteres kan anbefales. Det er højest sandsynligt at disse metoder vil
identificere flere behov hos brugerne. Specielt omkring ansvarsfordeling og
konkrete krav til implementeringen af forskellige værktøjer, eftersom disse
emner ikke har været i fokus i denne afhandling.
6.3 Oplæg til prototypeudvikling
Næste skridt i processen mod udviklingen af DOPE vil være prototypeud-

vikling af DOPE. Resultatet af prototypeudviklingen på DOPE skal være
at konkretisere den konceptuelle model på en sådan måde, at brugernes
eksisterende mentale model af Den Offentlige Projektmodel effektivt kan
genbruges, samtidig med at nye brugere får nemmere ved at forstå modellen.
Med baggrund i min tekniske viden, sammenholdt med den information om

domænet for Den Offentlige Projektmodel jeg har fået, fremligge jeg i det
følgende et konkret oplæg til første skridt af prototypeudviklingen af DOPE.
De sidste fem punker af fokusområderne (kommende opgaver, udfærdigelse,

verificering, feedback og færdige emner) repræsenterer den livscyklus som alle
opgaver skal igennem. DOPE må fokusere på en struktur der samler trådende
og ligger op til at strukturen for behandling af opgaverne, igennem hele
cyklussen, er struktureret. Til dét anbefales udviklingen af en struktur kaldet
TODO. Hver opgave i projektet har en TODO tilknytet, der er målrettet
mod at være den samlede indgangsvinkel til opgaves cyklus. TODOs er
karakteriseret ved at have
En beskrivelse tilknyttet
Beskrivelsen er den tekst der er angivet som formål i Den Offentlige
Projektmodel. Det anbefales at den altid fremstår visuelt i forbindelse
med TODOs, for at brugeren ikke skal være i tvivl om hvad der
arbejdes med.
Indeholder et TOOL
Den ”aktive”del af en TODO hvor brugerne tilgår den viden / det
dokument / det værktøj som beskrivelsen omhandler. Et TOOL
kan være noget så simpelt som en uploadfunktion af wordfiler,
eller måske en avanceret visualisering i integration med større
bagvedliggende system. Det centrale er et TOOL er at stiller
information om opgavens resultat til rådighed for brugeren.
En række resultatmål tilknyttet.
Den række af krav der må være opfyldt førend TODO’ens opgave
er opfyldt. Meningen er, at forskellige brugere kan tilkendegive
om de mener at indholdet i TODO’ens TOOL lever op til hvert
enkelt resultatmål. Det vil kombinere at verificeringen af en opgave
er struktureret efter specifikationen for opgaven. Samtidig vil det
genererer konkret og målbar feedback på opgaven.
Andre TODOs
For at samle al information om én opgave må man have tilknyttet
information om de enkelte bestanddele. Sat på spidsen betyder
det at et helt udviklingsprojekt teoretisk set er én TODO der i en
træstruktur indeholder alle aspekter.
Det er vigtigt at sætte fokus på at skalerbarheden fra projekt til projekt er
essentiel for brugerne. En mulig indgangsvinkel til dette problem er først

og fremmest at dét at oprette, konfigurerer og tilknytte nye TODOs til et
udviklingsprojekt skal være yderst simpelt.
Med TODOs kan information og projektets status nemt gøres op, i og med
alle resultatmål sættes som forudsætning for at en opgave er løst. Samtidig
giver det mulighed for et godt informations flow. Brugerne kan notificeres når
en TODO opdateres og på den måde følge med i projektet. Alle notificeringer
kan samles centralt så der opnås et samlet overblik over projektets status, set
ud fra den enkelte bruger.
Måske mit oplæg minder om det online community facebook. Men det er helt
naturligt, for både facebook og udvikling af projekter drejer sig om at give
den enkelte bruger præcis den information der gør det muligt, på helt egne
præmisser, at overskue helheden.
Signaturforklaring
[sgE8] Verificere at Har behov: [plF11] Verificere at
specifikationen for et Er identisk med: specifikationen for
dokument er fulgt, Er relateret til: [plF7] Se hvilke
dokumentet er fulgt,
hvilket vil sige at specifikationer
hvilket vil sige at
dokumentet er der er angivet for
dokumentet er udfærdiget
udfærdiget så det følger at dokumentet er
så det følger formålet og
formålet og indfrier de fyldestgørende
[sgE6] Kunne indfrier de resultatmål der
resultatmål der angives verificere angives i specifikationen [plF1] Oversigt over
i specifikationen. beskrivelse af de kompetencer der
produkt med kræves for at udfører
resultat af forskellige
produkt arbejdsopgaver
[sgE4] Have
en oversigt [plF13]
over Værktøjet
riskostyringen risikostyring
af projektet
[plF6] Oversigt
over projekt-
[sgE5] Kunne
gruppernes
spore hvad
[plF12] kompetencer
ændringer har
Værktøjet Projektleder
haft af
emnelog
indydelse på
tidsplanen
[sgE3] Have [plF9] Spore [plF5] Oversigt over

[plF3] Oversigt
en oversigt hvad ændringer projektgruppernes
over hvordan
over hvorfor har haft af ind arbejdsfordeling i
ressourcer i
ændringer er ydelse på forhold til
projektet bruges
opstået tidsplanen andreopgaver
[sgE1] En [plF4] Oversigt
Visuel fremstilling af aktørenes behov og deres interne relationer

oversigt over over produkter/
hvilke produkter emner der er
der er leveret færdiggjort
[plF2] Oversigt [plF10] Status for

[pmC2] Oversigt
over hvor langt mål og milepæle
over hvilke
projektgrupper samt hvad der
produkter der er
ne er med kommer i
leveret
deres arbejde fremtiden
[pmC3] [sgE7]
Resumé af [plF8] Specifikationerne
Specifikationerne for
sidste for udfærdigelsen af et
dokumentet følges,
styregruppem dokument skal følges,
hvilket vil sige at det
øde hvilket vil sige at
udfærdiges så det
udfærdige dokumentet så
følger formålet og
det følger formålet og
indfrier de resultatmål
indfrier de resultatmål der
der angives.
angives
Projektmedarbejder
[pmC1] Oversigt
over hvilke
områder projektet [pmC4]
bevæger sig ind Specifikationerne for
[peC1] En oversigt dokumentet følges,
på
over hvornår hvad hvilket vil sige at det
skal laves og en udfærdigesså det
påmindelse hvis følger formålet og
tidsgrænsen indfrier de resultatmål
overskrides der angives.
[sgE2] En
oversigt over
planlagte
leverancer
Projektejer
Figur 6.1: Visuel fremstilling af de 26 behov der er identificeret 5 hos aktørerne (se punkt
5.1.1 på side 25) i Den Offentlige Projektmodel. Visualiseringen ligger vægt på at illustr-
erer de indbyrdes relationer mellem forskellige behov. Farverne repræsenterer de naturlige
grupperinger der kommer som følge heraf.
Appendix A
Visuel fremstilling af
identificerede behov i A3 format
Denne side skal ikke vises, men erstattes af en A3 udgave af figur 6.1 på side
69 hvor der ses en visuel fremstilling af de 26 behov der er identificeret 5 hos
de fire aktører; projektejer (se punkt 5.2.2.3 på side 44), projektmedarbejder
(se punkt 5.2.3.3 på side 46), styregruppe (se punkt 5.2.1.3 på side 39) og
projektleder (se punkt 5.2.4.3 på side 59). Visualiseringen ligger vægt på at
illustrerer indbyrdes relationer mellem forskellige behov. Farverne på figuren
repræsenterer de naturlige grupperinger der kommer som følge heraf.
Kildehenvisninger
[1]
[2] Mary Jo Davidson, Laura Dove og Julie Weltz. Mental Models and
Usability, 1999. Depaul University, Cognative Psychology 404. http:
//www.lauradove.info/reports/mental%20models.htm.
[3] Alan Dorin. More Human-Computer Interaction, 2007. http://www.csse.

monash.edu.au/~cema/courses/CSE5910/lectureFiles/lecture6b.htm.
[4] Flemming Engstrøm. Senior projektleder i Frederiksberg kommune.

[5] Finansministeriet. Organisationsdiagram for Finansministeriets
departement, Den Digitale Taskforce, 2006. http://www.fm.dk/1024/
visOrganisationsUnderside.asp?artikelID=5858.
[6] Marie-Claude Gaudel, Valérie Issarny, Cliff Jones, Hermann Kopetz, Eric
Marsden, Nick Moffat, Michael Paulitsch, David Powell, Brian Randell,
Alexander Romanovsky, Robert Stroud og François Taiani. Final Version
of DSoS Conceptual Model, Technical Report CS-TR-782. Rapport,
Institut für Technische Informatik, Technical University of Vienna, 2003.
http://www.cs.ncl.ac.uk/research/pubs/trs/papers/782.pdf.
[7] Phil Johnson-Laird og Ruth Byrne. Mental Models Website, a Gen-

tle Introduction, 2000. http://www.tcd.ie/Psychology/Ruth_Byrne/
mental_models/.
[8] P.N. Johnson-Laird, Vittorio Girotto og Paolo Legrenzi. Mental mod-

els: a gentle guide for outsiders, 1998. http://www.si.umich.edu/ICOS/
gentleintro.html.
KILDEHENVISNINGER 72
[9] Amir Khella. Knowledge and Mental Models in HCI, 2002. http://www.
cs.umd.edu/class/fall2002/cmsc838s/tichi/knowledge.html.
[10] Mette Margrethe. Hovedansvarlig for Den Offentlige Projektmodel i Den

Digitale Taskforce.
[11] Scott McDaniel. What’s Your Idea of a Mental Model?, 2003. http://
www.boxesandarrows.com/view/whats_your_idea_of_a_mental_model_.
[12] Pamela McGillivray. Mental Models and Human-Computer Interaction

LO17757, 1998. http://www.learning-org.com/98.04/0141.html.
[13] Svend Aage Møller. Leder af it-udvikling i Middelfart Kommune, 2007.
[14] Richard E. Nance og James D. Arthur. Software requirements engineering:

exploring the role in simulation model development. I S. Robinson,
S. Taylor, S. Brailsford og J.Garnett, redaktører, Proceedings of the
2006 OR Society Simulation Workshop, 2006. http://arthur.cs.vt.
edu/conceptual-modelling/Manuscripts/Nance-Arthur.pdf.
[15] Donald A. Norman. The Design of Everyday Things, 1988.
[16] Morten Proschowsky. Undervisningsmateriale for Interaktionsdesign 2007

(02811) på Center for Information and Communication Technologies at
Technical University of Denmark, 2007. mp@cict.dtu.dk.
[17] Professor Stewart Robinson. Issues in conceptual modelling for sim-

ulation: setting a research agenda, 2006. http://arthur.cs.vt.edu/
conceptual-modelling/Manuscripts/SW06_20%20Robinson.pdf.
[18] Martina Angela Sasse. Eliciting and Describing Users’ Models of Com-
puter Systems, 1997. http://www.cs.ucl.ac.uk/staff/a.sasse/thesis/
Frontpage.html.
[19] Mads Soegaard. Mental models, 2005. http://www.interaction-design.

org/encyclopedia/mental_models.html.
[20] Dana Spiegel. Human Computer Interaction, 1998. MIT http://alumni.

media.mit.edu/~spiegel/papers/HCI.pdf.
[21] Peter Svendsen. IT-projektleder i Ringsted Kommune.
[22] Den Digitale Taskforce. Baggrund for Den Offentlige Pro-

jektmodel. http://modernisering.dk/da/projekter/redskaber_og_
vejledninger/projektmodel/baggrund/.
KILDEHENVISNINGER 73
[23] Den Digitale Taskforce. Beskrivelse af roller og ansvarsområder i pro-

jektorganisationen for Den Offentlige Projektmodel. http://oldegov.dk.
upsilon.t3c.dk/uploads/media/Roller_og_ansvar_01.doc.
[24] Den Digitale Taskforce. Online specifikation af Den Offentlige

Projektmodel. http://oldegov.dk.upsilon.t3c.dk/redskaber_og_
vejledninger/projektmodel/index.html.
[25] Den Digitale Taskforce. Specifikatoin for Den Offentlige Projekt-

model, 2007. http://modernisering.dk/da/projekter/redskaber_og_
vejledninger/projektmodel/.
[26] Kaj Vestergaard. Den Digitale Taskforce.

Mathias Rangel Wulff Bachelorprojekt 2008 - Konceptuel Model For Den Offentlige Projektmodel

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mathias Rangel Wulff Bachelorprojekt 2008 - Konceptuel Model For Den Offentlige Projektmodel

Uploaded by

Copyright:

Available Formats

“Den Offentlige Projektmodel”

elektronisk vejledt med DOPE

Mathias Rangel Wulff

Kongens Lyngby 2007

In 2003 a project model was developed for information technology in the

I 2003 blev der udviklet en projektstyringsmodel rettet mod IT-udviklingsprojekter

1. Risikoanalysen er bedre specificeret.

De strukturelle ændringer er altså holdt på et minimum, mens fokus på

Uden illustrationer, forord, resume og appendix fylder afhandlingen ialt 42

”In interacting with the environment, with

København, januar 2008

Mathias Rangel Wulff

2 Den Offentlige Projektmodel 4

3.1 Hvad er brugervenlighed? . . . . . . . . . . . . . . . . . . . . 9

3.2 Human-Computer Interaction (HCI) . . . . . . . . . . . . . . 11

3.3 Mentale modeller . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Konceptuelle modeller . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Baggrund for brugerundersøgelsen . . . . . . . . . . . . . . . . 15

4.6 Opsummering af brugerundersøgelse . . . . . . . . . . . . . . . 22

5.1 Identifikation af aktører . . . . . . . . . . . . . . . . . . . . . 23

5.2 Analyse af krav og behov . . . . . . . . . . . . . . . . . . . . . 26

6.1 Konceptuel model . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.2 Anbefalinger for implementering . . . . . . . . . . . . . . . . . 64

6.3 Oplæg til prototypeudvikling . . . . . . . . . . . . . . . . . . . 66

A Visuel fremstilling af identificerede behov i A3 format 70

I 2001 blev Den Digitale Taskforce nedsat i forbindelse med etableringen

Den Offentlige Projektmodel består af en 58 siders specifikation samt ca.

Linkfactory er et 6 år gammelt softwarehus i centrum af København. De

Konceptuel model, fokusområder og anbefalinger

Denne afhandling vil ligge til grund for en prototypeudvikling af DOPE.

Den Offentlige Projektmodel

Når man læser specifikationen for Den Offentlige Projektmodel, er et af de

Spillet foregår i runder. Centralt i spillet er overgangene imellem runderne

hvor spillet enten skal :

• Afsluttes (jf. formålet med spillet)

• Fortsætte som det er

• Gå til næste fase

Spillet gennemgår fire faser:

Spillet er slut når sidste fase er gennemført, og alle er dermed vindere.

Rollen ”projektleder”og projektgruppe-holdene er kun i spil under runderne.

Her, specifikt i første runde, er det opgaven ”projektinitialiceringsdoku-

Når en runde er slut skal projektlederen kommunikerer resultatet af runden til

styregruppen. Dette gøres ved at udfærdige dokumentet ”projektstatus”(se de

Styregruppen sætter sig derefter sammen (til et styregruppemøde) og kigger

På figur 2.1 på side 8 ses en humoristisk visualisering af processen.

Humoristisk visualisering af spillet DOP

Runde Projektleder Styregruppemøde

3.1 Hvad er brugervenlighed?

Den internationale standart organisation ISO specificerer, i ISO9241, bruger-

Et forsigtigt bud på en dansk opsummering er, at brugervenlighed sættes

Set som mål for en entydig og absolut specificering af begrebet ”bruger-

den er rettet mod. Specifikationerne er bevidst vage fordi brugervenlighed

3.2 Human-Computer Interaction (HCI)

Brugervenlighed er altså, i sin natur, en ganske udefinerbar størrelse. Til

3.3 Mentale modeller

Mentale modeller skabes, med baggrund i menneskets interaktion med verden

Løsningen er brugercentreret designudvikling. Brugercentreret designudvikling

3.4 Konceptuelle modeller

centrale i forhold til løsningen på et problem. Den ”maskerede løsning”på

En konceptuel model er i virkeligheden blot en yderst simplificeret repræsen-

Denne afhandling søger at komme med sagligt dokumenterede forudsætninger

Se figur 3.1 på side 14 for en visualisering af hvordan denne afhandling

Ud over de kildehenvisninger der er angivet i dette afsnit, kan jeg kraftigt