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

“Den Offentlige Projektmodel”elektronisk vejledt med DOPE

Mathias Rangel Wulff

Kongens Lyngby 2007IMM-B.Eng-2007-64

Technical University of DenmarkInformatics and Mathematical ModellingBuilding 321, DK-2800 Kongens Lyngby, DenmarkPhone +45 45253351, Fax +45 [email protected]

IMM-B.Eng: ISSN

Summary

In 2003 a project model was developed for information technology in theDanish 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 specificationof the model, this paper declare focus areas, implementation guidelines andconceptual model that for fill the expectations of the user and not the pointof view of the designer.

Resume

I 2003 blev der udviklet en projektstyringsmodel rettet mod IT-udviklingsprojekterinden for det offentlige. Pa trods af det, er der i 2007 kun 33% af kommunernei Danmark der bruger en projektstyringsmodel til handtering af IT-projekter.Med baggrund i en brugerundersøgelse og en dybdegaende analyse af DenOffentlige Projektmidel, fremsætter denne afhandling fokusomrader, anbe-falinger for implementering og konceptuel model for hvordan et digitaltvæ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, harført mig igennem adskillige faser og overvejelser, men jeg erkender, at vedslutningen af denne afhandling, har jeg haft svært ved undertrykke lystentil at ga dyberer og videre. Det er det mest seriøse og dybtegaende stykkearbejde jeg hidtil har lavet og det har opslugt, optaget og krævet min fuldeperson 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 atforskellen 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, ogsupplerer, 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 pavisse aspekter har ændret sig. Denne rapport afspejler stadig fuldt ud DenOffentlige Projektmodel, men man kan opleve at visse omrader er nedprior-iteret i forhold til hvad 3. udgave af Den Offentlige Projektmodel ligger optil. Alle sidehenvisninger i denne rapport gælder for 3. udgave Den OffentligeProjektmodel(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 narto sa fremmede væsner som en designer og en bruger, fra to sa vidt forskelligeverdner, nærmer sig hinanden for at skabe sammen...

”In interacting with the environment, withothers, and with the artifacts of technology,people form internal, mental models of them-selves and of the things with which they areinteracting. 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 Formal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

K a p i t e l 1

Introduktion

1.1 Baggrund

I 2001 blev Den Digitale Taskforce nedsat i forbindelse med etableringenaf Projekt Digital Forvaltning. Projekt Digital Forvaltning blev iværksat afregeringen og de kommunale parter for at fremme udviklingen af digital forvalt-ning [5]. For at bidrage til, at flere myndigheder skulle bruge en projektmodeli forbindelse med planlægningen af ITudvikling udviklede Den Digitale Task-force, i samarbejde med Danske Regioner og Kommunernes Landsforening, i2003 en projektstyringsmodel kaldet ”Den Offentlige Projektmodel”[22] bereg-net til, at ”. . . understøtte offentlige myndigheder i at styre, dokumentere ogimplementere projekter og hjælpe til at sikre, at potentielle gevinster bliverrealiseret.”[24]. Specifikationen beskriver hvordan et IT-udviklingsforløb børforlø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 stoppesinden det bliver en fiasko. Ikke desto mindre er der, Ifølge Danmarks Statistik2007, kun 33 % af alle offentlige myndigheder der anvender en projektmodeltil styring og gennemførelse af digitaliseringsprojekter [22].

Den Offentlige Projektmodel bestar af en 58 siders specifikation samt ca.30 skabeloner og eksempler pa udfyldte skabeloner for de i specifikationenbeskrevne værktøjer og dokumenter.

1.2 Formal 2

Linkfactory er et 6 ar gammelt softwarehus i centrum af København. Deleverer webbasserede værktøjer til kundespecifikke problemløsninger baseretpa open source systemer. Det er kommet dem for øre, at det er svært atfølge Den Offentlige Projektmodel, fordi der er mange elementer og detaljerat holde styr pa og de ca. 90 siders instruktion kan være uoverskuelige. Endigital 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 ikkeendnu.

For at gøre det nemmere at bruge Den Offentlige Projektmodel har Linkfactoryplaner om at udvikle et system kaldet ”DOPE”(Den Offentlige ProjektmodelElektronisk) der skal effektivisere handteringen af IT-udviklingsprojekter efterde retningslinjer der er angivet i Den Offentlige Projektmodel

1.2 Formal

For at kunne udvikle DOPE ma præmisserne for domænet kendes. Det vil sigehvilken adfærd brugerne har, samt deres krav til og behov for hjælp. Denneafhandling har til formal at analysere og dokumentere fokusomrader der gørat DOPE bedst muligt kan understøtte og skabe fremdrift for arbejdet medDen Offentlige Projektmodel. Det sker igennem

En brugerundersøgelse af domænetMen en triangulering af en kvantitativ- og kvalitativ tilgang foretagesen eksplorativ brugerundersøgelse der søger at afdække hvordan DenOffentlige Projektmodel bruges.

En systematisk analyseMed udgangspunkt i en kritisk gennemgang af specifikationen for DenOffentlige Projektmodel identificeres krav til og behov hos brugerne.

Konceptuel model, fokusomrader og anbefalingerSlutlig kædes brugerundersøgelsen og analysen sammen sa der medbaggrund i domænet, og ikke designeren, kan fremsættes fokusomrader,anbefalinger for implementering og konceptuel model for hvordan atDOPE kan give brugerne af Den Offentlige Projektmodel den bedstmulige 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 formal direkte at dokumentere hvorvidt udviklin-gen af DOPE er en god eller darligt ide set ud fra et økonomisk synspunkt.Emnet vil blive berørt, men kun overfladisk.

K a p i t e l 2

Den Offentlige Projektmodel

Nar man læser specifikationen for Den Offentlige Projektmodel, er et af destørste problemer, at man ikke kan danne sig et overblik over hvordan man rentfaktisk handterer et IT-projekt efter retningslinjerne, før man har læst den2-3 gange igennem. Jeg mener, at problemet bunder i, at specifikationen tagerudgangspunkt i hvad resultatet af processen skal være, desværre pa bekostningaf, at selve processen mod resultatet, mildt sagt, ikke er sa velbeskrevet somman kunne habe. Som eksempel kan nævnes, at den samlede beskrivelse afen af rollerne, er fordelt i 46 sætninger spredt pa 41 sider (se punkt 5.2.1.1pa side 27). For at give læseren af denne afhandling et billede af hvad DenOffentlige Projektmodel indeholder, har jeg her udfærdiget en vejledning hvorder er brugt en analogi til, at Den Offentlige Projektmodel er specifikationenfor et brætspil kaldet ”DOP”.

2.1 Spilmanual

Formalet med spillet ”DOP”er at realisere et IT-projekt fra ide til brugbartsystem hvis, og kun hvis, ulemperne/omkostningerne ved realiseringen ikkeoverstiger fordelene ved det færdige system.

Spillet foregar i runder. Centralt i spillet er overgangene imellem runderne

2.1 Spilmanual 5

hvor spillet enten skal :

• Afsluttes (jf. formalet med spillet)

• Fortsætte som det er

• Ga til næste fase

Spillet gennemgar fire faser:

• Idebeskrivelse

• 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østførend fasen er gennemført. Kun nar alle opgaver i en fase er løst, kan spilletga videre til næste fase. Spillet foregar ved, at der i hver runde skal udfærdigesen del af fasens opgaver, imens det imellem hver runde skal verificeres omopgaverne er lavet korrekt og fyldestgørende. Hver fase kan altsa have vilkarligtantal runder.

Spillet er slut nar sidste fase er gennemført, og alle er dermed vindere.

Før spillet

Inden spillet gar i gang far 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 far tildelt en rolle.Alle roller skal være fordelt. Det betyder altsa, at der som minimum skalvære 6 personer til at spille, men normalt vil der være flere deltagere, fx iform af rollen som projektdeltager. Nogen af rollerne er sat pa hold sammen.Styregruppeformand, brugerrepræsentant og leverandørrepræsentant er paholdet ”styregruppe”. Der kan kun være en styregruppeformand i en styre-gruppe og der kan kun være en styregruppe per spil. Projektlederen kan, efterønske, dele projektdeltagerne op i hold kaldet ”projektgrupper”. Teoretiskset kan samme projektdeltager godt vær med i flere hold af gangen, men detanbefales, at han/hun kun er tilknyttet et.

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 etIT-projekt opstar). Styregruppen sætter sig sammen og udfærdiger, ud fraideen, formal og ønsket resultat samt økonomisk og tidsmæssig ramme fordette spil. Samtidig aftales det spillerne imennem hvor lang tid den førsterunde 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) derskal laves. Det er projektlederens ansvar, at opgaven bliver løst. Til at hjælpesig har han projektmedarbejderne. Projektlederen kan gruppere arbejdernei hold (projektgrupper) og tildele dem ansvaret for en bestemt (del)opgave.Projektmedarbejderne og projektlederen ma, udover nar der uddeles ansvar,kun kommunikerer via det værktøj der hedder emneloggen. Formalet meden emnelog er, at projektlederen og projektmedarbejderne har et centraltplaceret kommunikationsværktøj, der sikrer, at der systematisk bliver fulgtop pa uforudsete opgaver undervejs i projektet. Hvis en medarbejder opdageren fejl, mangel eller uforudset problem, skal dette straks noteres i emneloggen,sa projektlederen kan na at reagere inden runden er slut.

Nar 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 denøjagtige specifikationer i Den Offentlige Projektmodel). Projektstatus er deneneste kommunikation projektlederen har med styregruppen. Det er derforvigtigt, at der derigennem bliver kommunikeret alt relevant om runden, omde ønskede opgaver blev løst og problemer opstaet undervejs (emneloggensnye punkter). Men statusrapporten indeholder ogsa et konkret forslag tilindholdet 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 kiggerpa hvordan rundens opgaver er løst. Styregruppen skal verificere, at rundensopgaver er udført korrekt. Hvis styregruppen finder, at løsningen pa en opgaveikke lever op til forventningerne (angivet i specifikationen for Den OffentligeProjektmodel) forkastes den og ma indga i næste runde. Dernæst gennemgasprojektstatus med vægt pa om ny viden eller problemer betyder, at hele spilletikke kan holde sig inden for de tidsmæssige eller økonomiske rammer. Hvisikke, skal der tages stilling til om spillet skal stoppes. Næste runde startermed ved at projektlederen far resume af styregruppemødet sammen med OKom at fortsætte.

Hele kusten med spillet ligger i at afpasse tiden for runderne med omfangetaf 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 t a r t

R u n d e

Arbejdsgruppe

Arbejdsgruppe

Arbejdsgruppe

s l ut

R un de

Emnelog

Projektleder

Styregruppe

OK

Ny fase

Runde Styregruppemøde

Projekt status

Projektleder

Figur 2.1: Humoristisk visualisering af spillet DOP (se punkt 2.1 pa side 4).

K a p i t e l 3

Brugervenlighed- ikke bare teori

Resultatet af denne afhandling skal lede mod et, for at sige det med jævneord, godt og effektivt værktøj til handtering af Den Offentlige Projektmidel.For at et værktøj kan beskrives som værende ”godt og effektivt”, ma det værekonstrueret, sa det lader dets brugere opna deres mal pa den bedst muligemade. Ikke nødvendigvis selve resultatet 1, men den bedst mulige proces modmalet. Hele problemet ligger, først og fremmest, i at finde frem til hvordanman finder denne ”. . . den bedst mulige proces mod malet”. Hvordan farbrugeren en brugervenlig made 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:

1Hvis resultatet ikke er godt, er det muligvis det forkerte værktøj der er brugt.

3.1 Hvad er brugervenlighed? 10

UsabilityThe effectiveness, efficiency and satisfaction with which specified usersachieve specified goals in a particular environment. (ISO 9241)

EffectivenessAccuracy and completeness with which specified users can achievespecified goals in a particular environment

EfficiencyThe resources expended in relation to the accuracy and complete-ness of the goals achieved

SatisfactionThe comfort and acceptability of the work system to its users andother people affected by its use

Et forsigtigt bud pa en dansk opsummering er, at brugervenlighed sættestil at være den komfort hvormed en specifik bruger præcist og fuldkommentgennemfø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, atmalene for brugervenlighed er

• Effektivitet

• Hastighed

• Sikkerhed

• Værdi

• Nemt at lære

• Nemt at bruge

Set som mal for en entydig og absolut specificering af begrebet ”bruger-venlighed”, kan begge disse beskrivelser virke vage i deres brug af relativebegreber 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 forandre. Hvordan kan dette være en specificering? At rejse dette spørgsmaler netop meningen med formuleringerne; at understrege, at man ikke kantage 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 brugervenligheder et relativt begreb der ma sættes i forhold til en modtager hver gang denkonkretiseres.

3.2 Human-Computer Interaction (HCI)

Brugervenlighed er altsa, i sin natur, en ganske udefinerbar størrelse. Tilat fastholde den, om end i et flygtigt greb, i forsøget pa at male og vejedens egenskaber ma der trækkes pa en lang række ”klassiske”omrader som fxkognitiv psykologi 2, computervidenskab, sociologi, antropologi, lingvistik ogorganisationsteori. Omradet hedder ”Human-computer interaction”(HCI) ogbeskæftiger sig med design, evaluering og implementering af computersystemermed udgangspunkt i interaktionen mellem bruger og system. HCI søger,overordnet set, at dokumentere videnskabeligt hvordan der bedst skabesmulighed for forstaelse af sammenhæng hos mennesker, sa de efterfølgende kanforudsige korrekt resultatet af en handling tilknyttet et system [2]. Begrebet”Mentale modeller”er derved centralt i spørgsmalet om brugervenlighed,fordi det beskriver hvordan det menneskelige sind strukturerer viden oglø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æresituationer[12] for at konkretisere deres usynlige og ofte komplekse forbindelser[20], [3]. Ofte som fortolkning af den visuelle struktur samt observation afhvordan enheden reagerer. Deres eksistens blev foreslaet i 1943 af den skotskepsykolog Kenneth Craik der skrev at; sindet danner ”small-scale models”afvirkeligheden som bruges til at forudsige handlinger, resonerer ud fra ogtildele forklaring pa hændelsesforløb [2], [19]. Det var Donald A. Normander, i hans bog ”The Design of Everyday Things”fra 1988[15], for første gangbrugte udtrykket ”mentale modeller”i forbindelse med HCI [19]. Han brugteudtrykket til at beskrive hvordan et system bliver designet og implementeret

2Kognitiv psykologi er en gren inden for psykologien der beskæftiger sig med mentaleprocesser sa som problemløsning, hukommelse og sprog

3.4 Konceptuelle modeller 12

pa basis af designerens mentale model, men forstas og bruges pa basis afbrugerens mentale model og hvilke problemer dette kan give. Darligt designer, nar designeren materialiserer sin mentale model og prøver pa at tvingebrugeren til at have den samme.

Løsningen er brugercentreret designudvikling. Brugercentreret designudviklinger, nar man, som designer af et system, accepterer, at de reelle brugereer de eneste virkelige eksperter pa omradet og derfor baserer designet paobservationer af deres adfærd i stedet for antagelser, gisninger og ideer om,hvad der er i brugerens interesse. Netop fordi forstaelsen for brugerens mentalemodel er sa essentiel i forbindelse med brugervenligt design, skal man i enudviklingsproces fokusere pa forstaelsen af denne. Brugervenlighed er ikkebare teori, men virkelighed og man ma, som designer, derfor ud i verden ogskabe kontakt med brugerne.

3.4 Konceptuelle modeller

Inden for HCI er der en lang række metoder til at tilegne sig viden ombrugernes mentale model, men den viden er intet værd hvis den ikke kanformidles tilbage til brugeren og resulterer i brugervenlighed. Det er i brugerensmøde med et artefakt, at interaktionen mellem disse, formidler den løsning,som designeren har skabt til et problem. Men løsninger pa stadig merekomplekse problemstillinger kræver stadig mere ekspertise. En ekspertise somdesigneren har, men som, for brugeren, ikke er andet end støj pa vejen mod atfa løst en opgave 3. Man kan sammenholde det med at køre bil. Hvis man, forat kunne køre, skulle forsta alle detaljer ved motoren, ville den ikke være særligbrugbar. I stedet er det nok at have forstaelse for interaktionen med gearstang,pedaler og ret, og efterfølgende ikke bekymre os om detaljerne. Designerenma derfor maskere sin løsning, eller maske rettere; formidle sin løsning, sabrugerens mentale model af artefaktet er rettet mod de elementer der er

3Læs ”Brug en hammer for at fa abnet flasken”. Bemærk at, det ikke er ”for at abneflasken”, men ”for at fa abnet”. Den tilsyneladende subtile forskel ligger i om man tagerudgangspunkt i, at man har processen med at abner flasken som mal, eller om man har etproblem (fx man er tørstig) og til opnaelsen af sluttilstanden (fx ikke tørstig mere) harsom gøremal at abne flasken og derfor søger at bruger et værktøj der kan hjælpe. Deter ogsa derfor, der her er brugt et utraditionelt værktøj til opnaelsen af sluttilstanden.Pointen er netop, at hvilket værktøj der bruges, og hvordan det sker, ikke er vigtigt, men atopnaelsen af sluttilstanden er det centrale. Dertil kommer sa, om brugerens mentale modelkan handtere abningen 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”paet problem der formidles via interaktionen mellem et artefakt og en brugerkaldes 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 hvordanbrugeren skal realisere sine mal. [11]. Som før beskrevet bliver den kon-ceptuelle model, for et artefakt, det udgangspunkt, som brugerens mentalemodel udvikles fra. Derfor er den essentiel i forhold til genkendelse i ogudviklingen af brugerens mentale model. En hjørnesten i det, er genbrug afeksisterende mentale modeller hos brugeren til at danne forstaelse pa nyeomrader. [17] Malet med den konceptuelle model bliver dermed at bringebrugernes kendskab om adfærd fra den virkelige verden ind i artefaktet, forat gøre dem i stand til at have brugbare og korrekte forventninger til hvilkeopgaver de kan gennemføre, samt hvordan disse realiseres. [11]. Og netop deter brugervenligt.

Denne afhandling søger at komme med sagligt dokumenterede forudsætningerfor at DOPE ikke bliver en fiasko. Jeg haber med dette afsnit at ha beskrevetvigtigheden af den brugercentrerede indgangsvinkel til problemet.

Se figur 3.1 pa side 14 for en visualisering af hvordan denne afhandlingskematiserer strukturen for brugervenlighed i domænet for Den OffentligeProjektmodel.

Ud over de kildehenvisninger der er angivet i dette afsnit, kan jeg kraftigtanbefale en række andre kilder om same emne, der har været mig til stornytte: [6, 7, 8, 9, 14, 1, 18]


Produkt

Krav

Specifikation for Den Offentlige Projektmodel

Teknisk løsning

Interaktion

Fysisk dagligdag

BrugervenlighedTilfredshed

PerformanceEffektivitet

Afkast

Behov

IT-udviklingsprojekt

Bruger

Figur 3.1: Visualisering af hvordan denne afhandling skema-tiserer strukturen for brugervenlighed i domænet for DenOffentlige Projektmodel

K a p i t e l 4

Brugerundersøgelse

4.1 Baggrund for brugerundersøgelsen

For at efterleve dogmerne for brugercentreret design, ma jeg tage udgangspunkti, at jeg ikke har forudgaende indsigt i domænet. For at afdække og nuancerehvordan Den Offentligt Projektmodel bliver brugt i brugernes dagligdag, fore-tager jeg i det følgende afsnit en eksplorativ brugerundersøgelse af de danskekommuners brug af projektstyringsmodeller til udvikling af IT-projekter, medfokus pa Den Offentlige Projektmodel. Undersøgelsen sigter mod en helheds-forstaelse for arsagssammenhæng med hensyn til udfordringer i forbindelsemed brugen af modeller.

4.2 Materiale

De kommuner der deltager i undersøgelsen er udvalgt efter størst lønindkomstfor den IT-udviklingsansvarlige i kommunen 1 med det argument, at jegformoder en sammenhæng mellem indkomst og arbejdsbyrde, det vil sigeIT-relateret udvikling i kommunen og derved sandsynlighed for, at kommunen

1Data 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 kommunerhvor den IT-ansvarlige tjener mest er blevet kontaktet i forbindelse medundersø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ølgendekommuner 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 medledelse og ansvar for IT, chefkonsulent i Digital Forvaltning, digitaliseringschef,ikt-chef, it-chef, it-koordinator, it-projektleder, direktør i Koncernservice ellerleder af IT-udvikling. For at resultaterne ikke skal være personhenførbare erinformation om kilden til resultaterne fjernet.

4.3 Metode

Der er brugt metodologiske triangulering 2 af en kvantitativ- og kvalitativtilgang til domænet. Metodologisk triangulering henviser til, at man søgerat udvide undersøgelsesgrundlaget ved at kombinere flere metodiske tilgangetil emnet (ogsa kaldet between-method triangulation). Hvor den kvantitativeundersøgelse fokuserer pa det overordnede billede af kommunernes brug afudviklingsmodeller, søger den kvalitative analyse at belyse de udfordringer deenkelte testdeltagere har i forbindelse med IT-udviklingsprojekter, med fokuspa Den Offentlige Projektmodel. Min metodologiske triangulering er brugtsom ”single case”, det vil sige hvor de to metoder tager udgangspunkt i data-indsamling fra de samme personer. Ud fra data og teoretisk baggrund munderden kvalitativ undersøgelse ud i en række af pastande om det undersøgtedomæne. Et centralt spørgsmal er dermed, hvornar pastande er velbegrundedenok 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 trad”skal overbevise om, at der ikke er tale om gætværk.

Den kvantitative undersøgelse afdækker fem spørgsmal

2 Triangulering er et udtryk hentet fra søfarten, nar man vil bruge flere udgangspunkterfor at bestemme et objekts nøjagtige position. Det angiver, at der bruges en kombinationaf metodologier til undersøgelse af et fænomen.

4.3 Metode 17

Udvikler kommunen ITOm kommunen køber standart IT-løsninger, eller om de selv star forudviklingen

Bruger kommunen en modelOm kommunen har en nedskrevet strukturel metode til at gennemføreIT-udviklingsprojekter.

Bruger kommunen Den Offentlige ProjektmodelOm kommunen bruger hele, eller uddrag, af Den Offentlige Projektmodeltil at gennemføre IT-udviklingsprojekter.

Er kommunen opmærksom pa Den Offentlige ProjektmodelHvis 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 somopmærksomme).

Er kommunen tilfreds med den nuværende situationOm kommunen har et ønske om at ændre deres situation. Fx ved, at deer i færd med at udvikle deres egen model, eller er utilfredse med, at deslet ikke bruger nogen.

Til den kvalitative brugerundersøgelse er der brugt semi-struktureret (tele-fon)interview med det formal at indhente meninger og beskrivelser fra deinterviewedes daglige arbejde med IT-udvikling. Der er sammensat en inter-viewguide, efter tragtmetoden, der søger at belyse forskellige sider af arbejdetmed Den Offentlige Projektmodel. Spørgsmalene er fokuserede, men samtidigabne og indbyder derved til konversation. Interviewet er formet ved opfølgendeog uddybende spørgsmal til de svar, der kommer til interviewguiden. Forat verificere, at fortolkningen af den interviewedes svar er korrekt, er derbrugt fortolkende spørgsmal sa som ”Vil det sige, at du altsa mener at. . . ”.Interviewguiden indeholder følgende spørgsmal:

• Udvikler I software i kommunen

• Bruger I en udviklingsmodel nar I udvikler software

• Kender I Den Offentlige Projektmodel fra Den Digitale Taskforce?

• Hvilken model bruger I til, at handtere jeres IT-udvikling? Hvordanbruger i den?

4.4 Resultater 18

Tabel 4.1: Resultat af en undersøgelse angaende de danske kommunersbrug af projektstyringsmodeller til udvikling af IT-projekter, med fokus pabrugen af Den Offentlige Projektmodel (DOP). Se forudsætninger for datai sektion 4 pa side 15.

18 Kommuner indgik i undersøgelsen18% Andel af samlet antal kommuner i Danmark

Følgende angiver andel af de adspurgte

33% Udvikler ikke selv IT56% Bruger en model17% Bruger DOP67% Er tilfredse med den situationen de star i nu22% Bruger en model men er ikke tilfreds med den situation de star i50% Er opmærksomme pa DOP17% Bruger anden model men er ikke opmærksom pa DOP11% 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 handterer 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 ogen computer til at notere svar pa. En optagelse af samtalen med en senereanalyse af indholdet have givet det bedste resultat, men det blev fravalgt udfra 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 harvalgt ikke at udvikle IT selv. De far deres IT-behov opfyldt igennem eksterneleverandører. Fx udtaler en kommune at ”Vi har ingen egenudviklet software.Det kan ikke betale sig i forhold til at købe standardiserede løsninger igennemKMD eller andre leverandører.”. Af de adspurgte er der 8/18 der brugeren model de selv har udviklet. Alle er baseret pa projektstyringsmodellerneprince2 eller prince2-light. De fleste dog hovedsageligt pa hovedfaserne iprince2 ligesom Den Offentlige Projektmodel. Der er en tendens til, at dennegruppe, der bruger deres egen model, mener, at Den Offentlige Projektmodelblot er en ”fordansknin”af prince2-light og at det derfor ikke er nødvendigt atanse Den Offentlige Projektmodel som noget nyhedsskabene man bør forholdesig 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ælgesen model blandt to mulige. Processen har dog generelt ikke været en grundiganalyse grundet alle de andre aspekter, der har været i forbindelse medkommunesammenligningen.

Informationsflow og arbejdsmetoder bestar gennemgaende af mange forskelligesystemer, der ikke er integreret op mod hinanden. Programmet ”Microsoftproject”indgar ofte i processen. Mange steder har de skabeloner til at startepa forskellige dokumenter. For en del gælder det, at kommunikationen ogverifikationen som hovedregel sker per email eller via fælles mappe til filer.Forskellige værktøjer er implementeret uafhængigt af hinanden som fx enkommune hvor ”Tit har vi et excel dokument til emneloggen, wordfiler tildokumenter og en delt kalender til projektstyring”

3/18 kommuner er i øjeblikket i gang med at revidere deres eksisterendeprojektstyringsmodel eller udarbejde en ny. Alle disse giver udtryk for, at dehar tænkt sig at se eller har set pa om Den Offentlige Projektmodel indeholderelementer de kan bruge.

Flere af testdeltagerne gav udtryk for manglende generel IT-udviklings strategii kommunen hvorved den politiske del med at forklare nødvendigheden herafer en af de største udfordringer mod at gennemføre IT-projekter efter enprojektmodel. I et enkelt tilfælde blev det kommenteret med: ”I vores afdelingma kæmpe for at fa projektstyring brugt i kommunen.”

Brugen af Den Offentlige Projektmodel er meget varieret. Er der tale omet 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 detudtrykkes i en kommune: ”Brugen er meget varieret. Er det et projekt til5000 kr., sa bruges den bare til lidt tjek af det vigtige. I øjeblikket har vi etprojekt i gang til 700.000. Der har vi alt igang.” Generelt plukkes der megetadhock fra elementerne i Den Offentlige Projektmodel, men gennemgaendebliver den brugt meget som tjekliste for indholdet i forskellige dokumenter.Som det udtrykkes fra en kommune: ”Vi bruger nogle af principperne fraDen Offentlige Projektmodel men som regel meget adhock, hvor vi plukker derelevante dele ud til hvert projekt.”. Der gives udtryk for, at skalerbarhed eret af de vigtigste elementer netop fordi projekterne varierer meget i størrelse.

Uafhængigt af om Den Offentlige Projektmodel blev brugt eller ej, var derflere deltagere der gav udtryk for, at det at bibeholde en model kan væresvært hvis der sjældent udvikles større IT-projekter, fordi det er nødvendigtat vedligeholde en procedure regelmæssigt. Som en kommune udtrykker det:”Vi har prøvet at lave vores egen kogebog, skabe en procedure, men der erikke volumen nok til at bibeholde den.” og en anden kommune i samme trad:”Vi brugte en gang prince2, men det gled ud i sandet. Mange medarbejderevar unge, men da de smuttede igen forsvandt deres viden.”

4.5 Diskussion

At brugen af Den Offentlige Projektmodel er meget varieret, er helt i trad medDen Offentlige Projektmodel. I specifikationen star nemlig at ”projektmodellen[er]. . . et for omfattende redskab at benytte i sin fulde udstrækning, nardet drejer sig om mindre projekter.” 3. Til mindre projekter bruges denmere som tjekliste over dokumenternes indhold, end som udgangspunkt forværktøjerne projektplan, business case og risikovurdering, som der ellers starsom anbefaling til mindre projekter 4.

Antallet af undersøgte kommuner i den kvantitative undersøgelse gør detvanskeligt at generalisere ud fra resultaterne. Testgruppen er heller ikkerepræ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% afalle danske kommuner der bruger en model til IT-udvikling [22] mod 56% i

3Se side 2 i specifikationen for Den Offentlige Projektmodel [25]4Se side 2 i specifikationen for Den Offentlige Projektmodel [25]

4.5 Diskussion 21

denne undersøgelse. Det vides dog ikke om de 33% er af alle kommuner, ellerkun de kommuner der udvikler IT. Pa trods af denne usikkerhed er det ikkedesto mindre stadig pafaldende, at der overhoved er en andel der ikke brugernogen model, men er utilfredse med situationen.

3/18 kommuner bruger Den Offentlige Projektmodel. Man kan være tilbøjeligtil at mene, at udbredelsen af Den Offentlige Projektmodel dermed ikkehaft succes til at sla igennem. Men ifølge Mette Margrethe, der sidder i DenDigitale Taskforce som hovedansvarlig for Den Offentlige Projektmodel, sa varprojektmodellen aldrig ment som et værktøj der skulle erstatte de eksisterendeprojektmodeller i det offentlige. Modellen er skabt for, at det offentlige kanhave en standart at debattere og male op imod [10]. Sagt med andre ordskal succesen for Den Offentlige Projektmodel dermed ikke ses i forbindelsemed hvor mange kommuner der kører udelukkende efter den, men derimod iantallet af kommuner der tager deres allerede eksisterende projektmodellerop til debat og sammenligner den med Den Offentlige Projektmodel. OmDen Offentlige Projektmodel dermed kan karrakteriseres som en succes medbaggrund i data i denne brugerundersøgelse ligger uden for rammerne afdenne afhandling at vurdere.

17% bruger en projektmodel men er ikke er opmærksom pa Den OffentligeProjektmodel. En mulig grund kan være at den viden der ligger oparbejdethos medarbejderne i de kommuner der igennem mange ar meget IT-udviklingog derfor idag har klart strukturerede metodikker for udvikligsprojekter. Fxhar Frederiksberg kommune nu 60 medarbejdere der er uddannet i, og har faetlicens pa deres færdigheder til prince-2 ligth. En omskoling af medarbejdernevil være en stor økonomisk byrde [4]. ”Blot fordi man ikke har haft en genereloffentlig projektmodel før i tiden, betyder det jo ikke, at de offentlige instanserikke har brugt projektmodeller i mange ar” siger Flemming Engstrøm 5 ,der er senior projektansvarlig i Frederiksberg kommune. Han har arbejdetmed projektudvikling inden for det offentlige i 20 ar og har aldrig oplevet,at der ikke var en model at ga ud fra. Eksemplet illustrerer godt hvorforDen Offentlige Projektmodel har svært ved at na ind til dem der har storerfaring inden for IT-udvikling. De har allerede invisteret tid og penge i engennemarbejdet 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 harvolumen nok til at bibeholde de nødvendige kompetencer. Uafhængigt af

5Flemming 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 informationsflowetnærmer sig en ustrukturel struktur. Det betyder, at der tit skal dygtighed ogdisciplin til, for at kunne manøvrere korrekt. Det er derfor ikke underligt, atdet at bibeholde en model uden sa mange projekter kan være svært. Dygtighedog disciplin kræver naturligvis øvelse. Det er muligvis ogsa derfor projekt-modeller nogen steder anses som besvær. Simpelthen fordi der startes frabunden af hver gang et projekt sættes i værk. Svært tilgængelige dokumenterog procedurer kan i høj grad ”skabeloniseres”via et digitalt værktøj. Derforkan en ”svært”tilgængelige projektmodel gøres langt mere implementerbari en digitalt handteret udgave. Dette er et nøgleargumentet for, at der idenne sidste gruppe vil være et marked for et digitalt værktøj, der pa en kon-struktiv og brugervenlig made guider og hjælper med at følge Den OffentligeProjektmodel.

Der er en større andel af kommunerne i brugerundersøgelsen der har dettil fælles, at de, ligesom Den Offentlige Projektmodel, har baseret deresegen projekt pa prince2 eller prince2-light. Det er uden for rammerne afdenne afhandling, men er ikke desto mindre interessant, at ga ind og sepa, om der er nogen mening i at udvikle DOPE, sa det er rettet mod atvære sa interpolerbart og moduleret, at det kan bruges til handtering afandre projektstyringsmodeller der, via fælles baggrund i prince2-light, er ”ifamilie”med Den Offentlige Projektmodel.

4.6 Opsummering af brugerundersøgelse

I de danske kommuner er der stor variation i hvordan IT-udviklingsprojekterbliver gennemført, men de kan overordnet inddeles i tre segmenter.Førstesegment har ikke behov for en projektstyringsmodel, fordi de ikke selv udviklerIT. Andet segment har Ikke brug for Den Offentlige Projektmodel fordide selv, igennem mange ar, har udviklet IT og derfor allerede har klartstrukturerede og gennemarbejdede procedurer for udviklingsprojekter. Tredjesegment har allerede værktøjer og skabeloner til rapportudfærdigelse, menskommunikationen og verifikationen bære præg af manglende struktur. Detbetyder, at disciplin og projektoverblik skal ligge hos den enkelte bruger.Hvis disse ikke trænes jævnligt er der en tendens til, at projektstyring bliveruønsket besværlig. Det er for dette segment at DOPE vil være et effektivtværktøj.

K a p i t e l 5

Systematisk analyse

Den anden vigtige indgangsvinkel til data vedrørende domænet, ud overbrugerne, er selve specifikationen for Den Offentlige Projektmodel. Medudgangspunkt i en kritisk gennemgang søger jeg at identificere krav til ogbehov hos brugerne. I første omgang skal de relevante aktører findes, for sidenhen at indga i en dybtgaende analyse.

5.1 Identifikation af aktører

At identificerer aktørerne i Den Offentlige Projektmodel er centralt i forholdtil at na ind til hvem der er vigtige at sætte fokus pa. Aktører er denøglepersoner/enheder der optræder inden for et domæne, der ogsa haret initialiserende operationelt ansvar. Specifikationen for Den Offentlige Pro-jektmodel er gennemgaet, for at identificere alle de nøglepersoner/enhederder 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 operationeltansvar.

Styregruppe som aktørStyregruppen er aktør, fordi det er en enhed, der er ansvarlig for attræffe forskellige valg med indflydelse pa projektets videre færd.

Leverandørrepræsentant og brugerrepræsentant som aktørerLeverandørrepræsentanten og brugerrepræsentanten er, som medlem afstyregruppen, aktører, men har intet operationelt ansvar i sig selv. Deresroller udfyldes derfor af aktøren ”styregruppe”, sa hverken leverandør-eller bruger- repræsentanten er i sig selv aktører.

Projektejer som aktørEn projektejer er aktør, fordi han har ansvaret for at overvage projektetsfremdrift pa det strategiske niveau hvilket blandt andet indbefatter atsikre, at risici bliver opsporet og afbødet samt efterspørge risikovur-deringer, kvalitetssikring og evalueringer

Styregruppeformand som aktørStyregruppeformanden er ikke aktør. Med definitionen pa en projek-tejer: ”en person med samme forpligtigelser som styregruppeformand,men som ikke indgar i styregruppeaktiviteterne”ses det at, ved at”vende”argumentet bliver en styregruppeformand; ”en person medsamme forpligtigelser som en projektejer, men som indgar i styregrup-peaktiviteterne (som formand)”. Det operationelle ansvar der ligger hosstyregruppeformanden er altsa dækket ind med de to aktører projektejerog styregruppe. Dette gælder selv om det er styregruppeformanden, derhar den endelige beslutningsret i styregruppen. Hans rolle er maskeikke den samme som andre medlemmer af styregruppeaktøren, men detoperationelle ansvar er det samme.

5.1 Identifikation af aktører 25

ProjektgruppeEn 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æreaktør.

ProjektdeltagerProjektdeltageren er aktør, fordi det er hans arbejder der ligger tilgrund for ændringer i projektet. En hændelse kan, igennem forskelligeværktøjer, som fx emneloggen, kan have indflydelse pa projektlederensbeslutninger eller blive et emne hos styregruppen der kan lukke projektetpa den baggrund.

Projektleder som aktørProjektlederen er aktør, fordi han er den person der har ansvaret for atstyre og planlægge projektet, og derved ogsa at fremskaffe beslutnings-grundlag og dokumentation, der vil ligger til grund for styregruppensbeslutninger.

Referencegruppe som aktørI beskrivelsen af referencegruppen star, at de ”. . . sædvanligvis ikke[har] egentlige kompetencer eller operationelt ansvar i projektet . . . ”.De har derfor intet initialiserende operationelt ansvar og er derfor ikkeaktør.

5.1.1 Opsummering af aktører

Ud af de 9 nøgle personer/enheder der figurerer i specifikationen for DenOffentlige 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 denenkelte 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ørernesbehov der i sidste ende ligger til grund for de krav der stilles til en konkretimplementering af DOPE.

krav i specifikationen −→ krav til aktørkrav 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 afhandlingskematiserer strukturen for brugervenlighed i domænet for Den OffentligeProjektmodel. Et af de største problemer med Den Offentlige Projektmodeler, at beskrivelsen af den enkelte aktør skal findes spredt igennem helespecifikationen. Nogen gange pa mere end 30 sider. Følgende afsnit søgerat identificere hvad de fire aktører har af behov, ved først at lokalisere allebeskrivelser af aktørens rolle. Alle beskrivelserne nedbrydes derefter til at værekonkrete krav til aktøren. Kravene gennemgas for dubletter og organiseres saman far et bedre overblik over hvilke krav der reelt er. Nar kravene dermeder isoleret, ses der pa hvad aktøren har behov for, for at kunne opfyldehvert 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ærkeller ønsketænkning? Forudsætningerne for at forsta behovene er, først ogfremmest, at forsta brugeren. Behovene er derfor udarbejdet med baggrundi den brugerundersøgelse der er foretaget (se punkt 4 pa side 15) men ierkendelse af, at brugerne er de virkelige eksperter pa domænet, er dettesidste trin foretaget i samarbejde med flere kilder [26, 13, 21, 10]

(Afsnittet kan virke langtrukkent med sine lange lister af behov og kravder analyseres. Det er ikke desto mindre essentielt for at dokumentere den


proces der ligger til grund for resultatet af denne afhandling. Jeg har derforvalgt ikke at sætte det i appendix. Næste afsnit er pa side 63 hvis en hurtiggennemlæsning ønskes.)

5.2.1 Styregruppe

Styregruppen i Den Offentlige Projektmodel er den aktør, der har ansvaretfor 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 brydesbeskrivelserne ned til krav der sorteres og organiseres. Først derefter kan derses pa hvilke behov styregruppen har.

5.2.1.1 Krav til styregruppe

Læser man dokumentet ”Beskrivelse af roller og ansvarsomrader i projektorganisationen”[23]far man beskrevet, at styregruppen roller er karakteriseret ved

[sgA1] ”Ansvarlig for den overordnede ledelse og styring af projekt”

[sgA2] ”Fastlægge projektets formal og mal”

[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 ansvarsomrader og mal”

[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 tilkorrigerende handlinger”

[sgA18] ”Tage stilling til, om projektet pa baggrund af den seneste opdateredebusiness case og risikovurdering skal fortsætte eller nedlægges”

[sgA19] ”Det er styregruppens ansvar, at projektlederen bliver informeret ombegivenheder uden for projektet, der kan have indflydelse pa projektet.”

I specifikationen for Den Offentlige Projektmodel er styregruppens rolleyderligere nævnt 24 gange fordelt fra side 6 til side 47:

[sgA20] ”Styregruppen for projektet skal have forelagt de seneste resultaterfor herefter at træffe beslutning om, i hvilken retning projektet skalfortsætte 1

[sgA21] ”Faseplan med angivelse af leverancer skal godkendes af styregruppen 2

[sgA22] ”Pa baggrund af projektinitieringsdokumentet træffer styregruppenbeslutning om, projektet skal igangsættes eller ej 3

[sgA23] ”Nar styregruppen har godkendt projektets endelige udformning, kanplanlægningen af projektet færdiggøres 4

[sgA24] ”Styregruppen har det overordnede ansvar for projektet. 5

1Se side 6 øverst i specifikationen for Den Offentlige Projektmodel [25]2Se side 6 øverst i specifikationen for Den Offentlige Projektmodel [25]3Se side 6 i specifikationen for Den Offentlige Projektmodel [25]4Se side 6 i specifikationen for Den Offentlige Projektmodel [25]5Se side 8 øverst i specifikationen for Den Offentlige Projektmodel [25]


[sgA25] ”Undervejs i projektet er det styregruppen, der træffer en række valgpa baggrund af informationer (hovedsagligt) stillet til radighed af pro-jektlederen. 6

[sgA26] ”Tage stilling til hvor stor en afvigelse i forhold til den aftalte tidsplan/de afsatte ressourcer, der skal accepteres, inden der tages stilling tilkorrigerende handlinger 7

[sgA27] ”Godkende afslutningen af en fase eller projektet 8

[sgA28] ”Godkende planlægningen af den næste fase 9

[sgA29] ”Tage stilling til, om projektet pa baggrund af den seneste opdateredebusiness case og risikovurdering skal fortsætte eller nedlægges 10

[sgA30] ”Det er desuden styregruppens ansvar, at projektlederen bliver informeretom begivenheder uden for projektet, der kan have indflydelse pa pro-jektet. 11

[sgA31] ”Efter endt implementering, er det styregruppeformanden, der haransvaret 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 enbeslutning, om projektet skal igangsættes eller ej. 14

[sgA34] ”Det er styregruppens ansvar at levere ressourcer, beslutninger ogmandat til projektet” 15

[sgA35] ”Ledelsen/styregruppen træffer pa baggrund heraf [Potentialevurdering –business case] beslutning, om projektet skal gennemføres i den foreslaedeform eller om projektet skal reorganiseres eller helt afvises.” 16

6Se side 8 i specifikationen for Den Offentlige Projektmodel [25]7Se side 8 i specifikationen for Den Offentlige Projektmodel [25]8Se side 8 i specifikationen for Den Offentlige Projektmodel [25]9Se side 8 i specifikationen for Den Offentlige Projektmodel [25]

10Se side 8 i specifikationen for Den Offentlige Projektmodel [25]11Se side 8 nederst i specifikationen for Den Offentlige Projektmodel [25]12Se side 8 nederst i specifikationen for Den Offentlige Projektmodel [25]13Se side 9 øverst i specifikationen for Den Offentlige Projektmodel [25]14Se side 9 i specifikationen for Den Offentlige Projektmodel [25]15Se side 14 nederst i specifikationen for Den Offentlige Projektmodel [25]16Se side 15 i specifikationen for Den Offentlige Projektmodel [25]


[sgA36] ”Ved hver faseovergang skal der foreligge en opdateret business case, dergiver styregruppen mulighed for at vurdere, om gevinster og omkost-ninger stadig star mal med hinanden.” 17

[sgA37] ”styregruppen [skal] primært forholde sig til den eller de risici, der harsærlig høj risikoværdi.” 18

[sgA38] ”Nar styregruppen har taget stilling til projektets endelige udformning,kan planlægningen af projektet færdiggøres, sa der fremkommer endetaljeret projektplan” 19

[sgA39] ”[Det er] styregruppen, der beslutter sig for den endelige model forprojektet.” 20

[sgA40] ”Nar styregruppen har truffet beslutning om den endelige projektmodel,kan projektplanen færdiggøres.” 21

[sgA41] ”Nar styregruppen har truffet endelig beslutning om den løsning, somprojektet skal føre ud i livet mhp. at opna de fastsatte projektmal, kander 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 overvage fase- og projektfrem-drift.” 24

[sgA44] ”Styregruppen skal træffes beslutning, om projektet skal overga til næsteprojektfase” 25

[sgA45] ”Styregruppen bruger projektetstatus til at overvage fase- og projekt-fremdrift.” 26

17Se side 16 i specifikationen for Den Offentlige Projektmodel [25]18Se side 21 i specifikationen for Den Offentlige Projektmodel [25]19Se side 28 i specifikationen for Den Offentlige Projektmodel [25]20Se side 28 i specifikationen for Den Offentlige Projektmodel [25]21Se side 29 i specifikationen for Den Offentlige Projektmodel [25]22Se side 30 i specifikationen for Den Offentlige Projektmodel [25]23Se side 31 i specifikationen for Den Offentlige Projektmodel [25]24Se side 38 i specifikationen for Den Offentlige Projektmodel [25]25Se side 42 i specifikationen for Den Offentlige Projektmodel [25]26Se side 47 i specifikationen for Den Offentlige Projektmodel [25]


For at opretholde sporbarhed har hver beskrivelse faet en unik identifikationder starter med ”sg”efterfulgt af et bogstav for iterationen af analysen. Allekrav kan derved spores til kilden. Beskrivelserne fra Den Offentlige Proejt-model er af blandet karakter. Ved at bryde beskrivelserne ned til krav ogefterfølgende kategoriseret dem opnas et bedre overblik. Referencen til hvorfraet krav oprinder, er angivet efter beskrivelsen af kravet.

[sgB1] Aftale projektlederns ansvarsomrader [sgA5]

[sgB2] Aftale projektlederns mal [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 defastsatte projektmal [sgA41]

[sgB8] Beslutte om den endelige projektmodel. [sgA40]

[sgB9] Beslutte om projektet skal gennemføres i den foreslaede form eller omprojektet 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 faetforelagt 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 formal [sgA2]

[sgB19] Fastlægge projektets mal [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 kanhave indflydelse pa projektet. [sgA19]

[sgB33] informere projektlederen om begivenheder uden for projektet, der kanhave indflydelse pa projektet. [sgA30]

[sgB34] Levere ressourcer, beslutninger og mandat til projektet [sgA34]

[sgB35] Overvage fase- og projektfremdrift via projektetstatus [sgA45]

[sgB36] Overvage 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/de afsatte ressourcer, der skal accepteres, inden der tages stilling tilkorrigerende handlinger [sgA17]

[sgB44] Tage stilling til, om projektet skal fortsætte i sin nuværende form ellerom det skal ændres. [sgA42]

[sgB45] Tage stilling til, om projektet, pa baggrund af den seneste opdateredebusiness case og risikovurdering, skal fortsætte eller nedlægges [sgA18]

[sgB46] Træffer en række valg pa baggrund af informationer (hovedsagligt) stillettil radighed af projektlederen. [sgA25]

[sgB47] Udpege projektleder [sgA5]

[sgB48] Vurdere om projektet skal fortsætte eller nedlægges pa baggrund af denseneste opdaterede business case og risikovurdering [sgA29]

[sgB49] Vurdere, hvilken information der skal forelægges direktionen [sgA9]

[sgB50] Vurdere, om gevinster og omkostninger stadig star mal med hinandenmed baggrund i en opdateret business case. [sgA36]

Listen gennemgas endnu en gang for at fa fjernet alle krav der er duplikeret ibetydning.

[sgC1] Aftale projektlederns ansvarsomrader [sgB1], [sgA5]

[sgC2] Aftale projektlederns mal [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 denseneste 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 formal [sgB18], [sgA2]

[sgC12] Fastlægge projektets mal [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 kanhave indflydelse pa projektet. [sgB32], [sgB33], [sgA30], [sgA19]

[sgC24] Overvage 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 denaftalte 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) stillettil radighed 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 star mal med hinandenmed baggrund i en opdateret business case. [sgB50], [sgA36]

En UML notation af kravene i form af et usecase-diagram over aktørenstyregruppe 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 harfor at kunne opfylde disse krav. I og med at jeg som udenforstaende ikke kanvide 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 vedat opfylde en række delkrav, der alle allerede er angivet og de vil derfor ikkeindga 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) stillettil radighed af projektlederen. [sgC31], [sgB46], [sgA25]

Nogen af kravene har i deres egen beskrivelse indikeret, at der i specifikationenfor Den Offentlige Projektmodel allerede er taget højde for hvilke behov der erfor 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 denseneste 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 star mal med hinandenmed baggrund i en opdateret business case. [sgC34], [sgB50], [sgA36]

• Overvage fase- og projektfremdrift via projektetstatus [sgC24], [sgB35],[sgB36], [sgA43], [sgA45]

Nogen af kravene er helt baseret pa menneskelige kvalifikationer og de erderfor ikke centrale i forhold til digital hjælp. De vil derfor ikke indga i denvidere analyse.

• Aftale projektlederns ansvarsomrader [sgC1], [sgB1], [sgA5]

• Aftale projektlederns mal [sgC2], [sgB2], [sgA5]

• Ansvarlig for, at evalueringen bliver gennemført [sgC6], [sgB6], [sgA31]

• Informere projektlederen om begivenheder uden for projektet, der kanhave 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 fordet centrale arbejdsomrade for Den Offentlige Projektmodel. De vil derforikke 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 formalet og indfrier de resul-tatmal der angives i specifikationen.


Kravet ”Fastlægge projektets formal [sgC11], [sgB18], [sgA2]”er en del af det, iDen Offentlige Projektmodel, klart specificerede dokument ”Formal og mal”.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 formalet og indfrier de resultatmal der angives.

Kravet ”Fastlægge projektets mal [sgC12], [sgB19], [sgA2] ”hører ind under det,i Den Offentlige Projektmodel, klart specificerede dokument ”Formal og mal”.For at kunne opfylde kravet er der behov for at

[sgD3] Specifikationerne for dokumentet følges, hvilket vil sige, at det udfærdi-ges sa det følger formalet og indfrier de resultatmal der angives.

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]”generereret behov for at

[sgD5] Have en oversigt over hvorfor ændringer er opstaet.

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 projekteter færdiggjort.

[sgD7] Se hvilke omrader projektet bevæger sig ind pa. Det vil sige hvilkeelementer 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 udenfor Den Offentlige Projektmodel, men for at kunne se pa om der skal flererescurcer til projektet er der behov for at se pa om produkter bliver leverettil 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ørstefaser i Den Offentlige Projektmodel. Det betyder, at der allerede er tagethøjde for det og det vil ikke indga i den videre analyse

Kravet ”Tage stilling til korrigerende handlinger ved afvigelser i forhold tilden aftalte tidsplan/ de afsatte ressourcer [sgC29], [sgB41], [sgA26]”ligger op tilet 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 behovsmeltet 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 opstaet [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 formalet og indfrier de resultatmal 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 formalet og indfrier de resul-tatmal der angives i specifikationen. [sgD1]

5.2.2 Projektejer

Aktøren projektejer i Den Offentlige Projektmodel har det overordnede ansvarfor projektet. For at na frem til de behov som projektejeren har, finder jegførst alle beskrivelserne af aktøren. Efterfølgende brydes beskrivelserne nedtil krav der sorteres og organiseres. Først derefter kan der ses pa hvilke behovprojektejeren har.

5.2.2.1 Krav til projektejer

Læser man dokumentet ”Beskrivelse af roller og ansvarsomrader i projektorganisationen”[23]far man beskrevet følgende om projektejeren

[peA1] ”Den absolut ansvarlige for projekt ”

[peA2] ”Sikre, at projektet indfrier sine formal ”

[peA3] ”Sikre, at projektet leverer de aftalte produkter ”

[peA4] ”Sikre, at der er en sammenhængende og effektiv projektorganisationog planlægning ”

[peA5] ”Overvage 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] ”Handtere alvorlige problemer i projektet ”

[peA10] ”Sikre at de nødvendige ressourcer er til radighed i projektet i samradmed projektlederen ”

I specifikationen for Den Offentlige Projektmodel er Projektejerens rolle ikkenævnt et eneste sted. Det kan overraske lidt, men tilbage i identifikationen afaktørerne (se punkt 5.1 pa side 23) ses det, at aktøren projektleder deler ansvarmed styregruppeformanden, bortset fra deltagelsen i styregruppemøderne.I Den Offentlige Projektmodel er beskrivelser af styregruppeformanden derikke involverer styregruppen kun at finde et sted:

[peA11] ”. . . det [er] styregruppeformanden, der har ansvaret for, at evalueringenbliver gennemført, og om eventuelle korrigerende handlinger føres ud ilivet.” 27

For at opretholde sporbarhed har hver beskrivelse faet en unik identifikationder starter med ”pe”efterfulgt af et bogstav for iteration af analysen. Allekrav kan derved spores til kilden. Beskrivelserne brydes ned til konkrete kravfor at fa alle krav adskilt. Referencen til hvorfra et krav oprinder, er angivetefter 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] Handtere alvorlige problemer i projektet [peA9]

27Se side 8 nederst i specifikationen for Den Offentlige Projektmodel [25]


[peB8] Inddrage Den politiske ledelse [peA8]

[peB9] Orientere den politiske ledelse [peA8]

[peB10] Overvage projektets fremdrift pa det strategiske niveau [peA5]

[peB11] Sikre at de nødvendige ressourcer er til radighed i projektet i samradmed 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 formal [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 overaktø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 gar forud for at kunne opfylde disse krav. I og med at jeg som uden-forstaende ikke kan kende disse behov, er de udarbejdet i samarbejde meden 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 erderfor ikke centrale i forhold til digital hjælp. De vil derfor ikke indga i denvidere analyse.

• Ansvarlig for projekt [peB3], [peA1]

• Orientere den politiske ledelse [peB9], [peA8]


• Handtere 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 iDen Offentlige Projektmodel. Disse krav opfyldes simpelthen ved at følgespecifikationen. Der er dermed tale om løkke i definitionen. Følgende krav vilikke indga i den videre analyse, fordi det er selve Den Offentlige Projektmodelder ligger til grund for opfyldelsen af kravet.

• Sikre at projektet indfrier sine formal [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]

• Overvage 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 radighed i projektet i samradmed projektlederen [peB11], [peA10]

Flere af kravene er i realiteten en pamindelse til andre om leve op til deresrolle 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 hvornar hvad skal laves og en pamindelse hvis tids-grænsen overskrides

5.2.2.3 Opsummering af projektejer

Der er kun identificeret et behov der er egnet til digital hjælp

• En oversigt over hvornar hvad skal laves og en pamindelse hvis tids-grænsen overskrides [peC1]

5.2.3 Projektmedarbejder

Aktøren projektmedarbejder kan ses som dem der udfører ”brødarbejdet”iprojektet og følger projektlederens ansvarsuddeling. For at na frem til de behovsom aktøren har, finder jeg først alle beskrivelser og bryder dem efterfølgendened til krav der sorteres og organiseres. Først derefter kan der ses pa hvilkebehov projektmedarbejderen har.

5.2.3.1 Krav til projektmedarbejder

Læser man dokumentet ”Beskrivelse af roller og ansvarsomrader i projektorganisationen”[23]er der ingen beskrivelse af en projektmedarbejder. I introduktionen til DenOffentlige Projektmodel (se punkt 2 pa side 4) ses det, at aktøren projek-tmedarbejder indgar i arbejdsgruppe. Jeg tager derfor udgangspunkt i atkravene til en projektmedarbejder er de samme som til en arbejdsgruppe. Sabeskrivelsen 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 nogenbeskrivelse af hverken aktøren projektmedarbejder eller arbejdsgruppe

5.2.3.2 Behov hos projektmedarbejder

I og med at jeg som udenforstaende ikke kan vide hvilke behov der er forat 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æneekspertfra Den Digitale Taskforce [10].

Kravet ”sikre koordinering med bagland/hjemmeorganisation [pmA3]”er heltbaseret pa menneskelige kvalifikationer og de er derfor ikke centrale i forholdtil digital hjælp. De vil derfor ikke indga i den videre analyse.

I kravet ”levere specialistprodukter [pmA1]”indgar begrebet ”specialistproduk-ter”. Begrebet er ikke nævnt andre steder en i beskrivelsen rollen hvor kravetoprinder fra. Ved at kontakte en domæneekspert er jeg kommet frem til, atbegrebet dækker over de i specifikationen for Den Offentlige Projektmodelklart specificerede dokumenter som aktøren af projektlederen har faet tilopgave 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-ges sa det følger formalet og indfrier de resultatmal der angives.

Kravet ”Holde evt. bagland/hjemmeorganisation orienteret om fremdrift, resul-tater og beslutninger i projektet mellem styregruppemøderne [pmA2]”genereret behov for at have

[pmB2] En oversigt over hvilke produkter der er leveret

[pmB3] En oversigt over hvilke omrader projektet bevæger sig ind pa. Det vilsige 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 atskabe beslutningsgrundlaget for . . . ledelsesbeslutninger for projektet. . . ”28

og ikke er henvendt mod projektmedarbejderne eftersom der stort set ikke ernogen direkte krav til dem. Alligevel har Den Offentlige Projektmodel storindflydelse pa deres arbejde, fordi den ligger grundlaget for et godt styretprojekt og derved giver basis for en bedre arbejdsdag. Opsummeret er behovethos aktøren projektmedarbejder følgende punkter:

[pmC1] Oversigt over hvilke omrader 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 formalet og indfrier de resultatmal der angives. [pmB1]

5.2.4 Projektleder

Denne analyse søger at finde frem til hvilke behov projektlederen har, forat kunne leve op til de krav der stilles til ham i specifikationerne for DenOffentlige Projektmodel.

Aktøren projektlederen har ansvaret for at styre og planlægge projektet, ogderved ogsa at fremskaffe beslutningsgrundlag og dokumentation der vil liggertil grund for styregruppens beslutninger 29. For at na frem til de behov somprojektlederen har, finder jeg først alle beskrivelserne af aktøren. Efterfølgendebrydes beskrivelserne ned til krav der sorteres og organiseres. Først derefterkan der ses pa hvilke behov aktøren har.

28Se side 5 i specifikationen for Den Offentlige Projektmodel [25]29Se side 8 i specifikationen for Den Offentlige Projektmodel [25]


5.2.4.1 Krav til projektleder

Læser man dokumentet ”Beskrivelse af roller og ansvarsomrader i projektorganisationen”[23]far man beskrevet, at projektlederen skal

[plA1] ”Planlægge og overvage projektet, herunder løbende opfølgning paprojektets mal og milepæle”

[plA2] ”Styre risici”

[plA3] ”Patage sig ansvaret for den overordnede fremdrift samt anvendelse afressourcer 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 rolleyderligere nævnt 9 gange:

[plA5] ”Nar 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, herunderat tilvejebringe beslutningsgrundlag og dokumentation til styregruppen.”31

[plA7] ”Projektlederen skal, via emneloggen, sikrer, at der systematisk bliverfulgt 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 afprojektet end først antaget, skal handteres.” 33

30Se side 8 i specifikationen for Den Offentlige Projektmodel [25]31Se side 14 i specifikationen for Den Offentlige Projektmodel [25]32Se side 24 i specifikationen for Den Offentlige Projektmodel [25]33Se side 24 i specifikationen for Den Offentlige Projektmodel [25]


[plA9] ”Projektlederen skal udarbejde en projektstatus for projektet medpassende mellemrum sa der kan foretages korrigerende handlinger,safremt projektet afviger fra projektplanen.” 34

[plA10] ”Projektlederen skal, via projektstatus, advisere styregruppen om eventuelleproblemer eller omrader, hvor styregruppen kunne hjælpe.” 35

[plA11] ”Projektlederen skal styre projektgrupperne ved at være opmærksompa 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 pafø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ødvendigekompetencer 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 statustil styregruppen.” 41

For at opretholde sporbarhed, har hver beskrivelse faet en unik identifikationder starter med ”pl”efterfulgt af et bogstav for iterationen af analysen. Allekrav kan derved spores til kilden. Beskrivelserne fra Den Offentlige Proejt-model er af blandet karakter. Ved at bryde beskrivelserne ned til krav ogefterfølgende kategorisere dem opnas et bedre overblik. Referencen til hvorfraet krav oprinder, er angivet efter beskrivelsen af kravet.

34Se side 38 og 47 i specifikationen for Den Offentlige Projektmodel [25]35Se side 38 og 47 i specifikationen for Den Offentlige Projektmodel [25]36Se side 40 i specifikationen for Den Offentlige Projektmodel [25]37Se side 40 i specifikationen for Den Offentlige Projektmodel [25]38Se side 40 i specifikationen for Den Offentlige Projektmodel [25]39Se side 40 i specifikationen for Den Offentlige Projektmodel [25]40Se side 40 i specifikationen for Den Offentlige Projektmodel [25]41Se side 40 i specifikationen for Den Offentlige Projektmodel [25]


[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 endtimplementering [plA5]

[plB4] Overvage projektet [plA1]

[plB4a] Udarbejde en projektsstatus for projektet [plA9]

[plB4b] løbende opfølgning pa projektets mal [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] Patage 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 tilderes 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 hvisdet er nødvendigt [plA3]

[plB5c] Beslutte hvordan nye projektemner, sa som nye risici, eller i formaf nye muligheder for at fa mere ud af projektet end først antaget,skal handteres [plA8]


[plB5d] Igangsætte læringsaktiviteter, for at opna nødvendige kompetenceri projektgrupperne [plA12]d

[plB5e] Vurdere om der bør inddrages nye personer, for at opna nødvendigekompetencer 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 omeventuelle problemer [plA10]

I 3. iteration gennemgar jeg listen for at se om der er punkter, der har sammebetydning som andre. Projektlederen vil altid kunne uddelegere opgaverne derkræves af ham, sa beskrivelser som ”ansvarlig for”og ”udarbejde”er fjernetfor 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] Overvage projektet [plB4], [plA1]

[plC2a] Projektsstatus for projektet [plB4a], [plA9]

[plC2b] Opfølgning pa projektets mal [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 hvisdet er nødvendigt [plB5b], [plA3]

[plC3b] Beslutte hvordan nye projektemner, sa som nye risici, eller i formaf nye muligheder for at fa mere ud af projektet end først antaget,skal handteres [plB5c], [plA8]

[plC3c] Igangsætte læringsaktiviteter, for at opna nødvendige kompetenceri projektgrupperne [plB5d], [plA12]d

[plC3d] Vurdere om der bør inddrages nye personer, for at opna nødvendigekompetencer 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 omeventuelle 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 overaktø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 opfyldede forskellige krav, er der flere delelementer involveret. Formalet med dennæste oversigt er at se pa hvilke behov brugeren har for at kunne opfyldedisse krav I og med at jeg som udenforstaende ikke kan kende disse behov erde 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 erderfor nu blot sat som overskrift i kursiv

Projektets dokumentation

Kravet ”Projektinitieringsdokument [plC1b], [plB3b], [plA4a]”opfyldes ved atudfærdige en række dokumenter 42:

• Formal og mal 43

• Overordnet projektplan 44

• Projektorganisering 45

• Potentialevurdering/business case 46

• It-arkitektur og teknologi [17]

• Interessentanalyse 47

• Risikostyring 48

42Se side 9 i specifikationen for Den Offentlige Projektmodel [25]43Se side 11 i specifikationen for Den Offentlige Projektmodel [25]44Se side 13 i specifikationen for Den Offentlige Projektmodel [25]45Se side 14 i specifikationen for Den Offentlige Projektmodel [25]46Se side 15 i specifikationen for Den Offentlige Projektmodel [25]47Se side 18 i specifikationen for Den Offentlige Projektmodel [25]48Se side 20 i specifikationen for Den Offentlige Projektmodel [25]


[plD1] Alle disse dokumenter er klart specificeret i Den Offentlige Projektmodel.For at kunne opfylde kravet ma specifikationerne for alle dokumenternefølges, hvilket vil sige at udfærdige dokumentet sa det følger formaletog indfrier de resultatmal 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 skitseringaf krav og ønsker vedr. it-arkitektur og teknologi.”49

• ”Allerede ved formuleringen af projektgrundlaget er det vigtigt at haveen overordnet projektplan, der angiver projektets tidsramme og devigtigste milepæle i projektet”50

Punkterne er ikke informative nar det gælder fakta om indholdet af begræbet”projektgrundlag”. Det viser sig imidlertid, at ”projektgrundlag”dækker overdet der andetsteds benævnes som ”beslutningsgrundlag”. Det ses fx i sæt-ningen ”. . . der udarbejdes et projektinitieringsdokument (PID), der udgørbeslutningsgrundlaget for igangsættelse af projektet.”51. Derfor er det identiskmed kravet ”Projektinitieringsdokument [plC1b], [plB3b], [plA4a]”der alleredeer dokumenteret.

Kravet ”Projektplaner [plC1c] [plB3c], [plA4b]”opfyldes ved udfærdigelsen af etklart 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 formalet og indfrierde resultatmal der angives 52.

Krav ”Faseplaner [plC1d], [plB3d], [plA4b] ”er ikke klart specificeret i DenOffentlige Projektmodel. Den nævnes kun et sted: ”Desuden skal der vedafslutningen af en fase foreligge en detaljeret plan for aktiviteterne i den

49Se side 13 øverst i specifikationen for Den Offentlige Projektmodel [25]50Se side 13 i specifikationen for Den Offentlige Projektmodel [25]51Se side 9 øverst i specifikationen for Den Offentlige Projektmodel [25]52Se side 30 i specifikationen for Den Offentlige Projektmodel [25]


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 enopdatering af de centrale dokumenter i projektet som f.eks. business casen,interessentanalysen og risikovurderingen ved hver faseovergang.” 53 og er altsakarakteriseret 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 ogsasom ”Faseplanlægningen”og ”I faseplanen sker en opdatering af de centraledokumenter i projektet som f.eks. business casen, interessentanalysen ogrisikovurderingen”hvorved man kan se det som et begreb for en ”opsum-mering”inden næste fase. Med baggrund i domæneeksperterne sætter jegfaseplanen til at være a) en udvidet statusrapport med beskrivelse af allekommende leverancer og b) en opdatering af centrale dokumenter i projektet.Da bade statusrapport og andre centrale dokumenter er behandlet andetstedsvil 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ærendeuden for de centrale omrader for Den Offentlige Projektmodel, og punktetudgar 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 omrader for DenOffentlige 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 beskrivelsenaf hvad dokumentet ”evaluering”skal indeholde. For at kunne udfærdigeplanen er der derfor behov for at

53Se side 6 i specifikationen for Den Offentlige Projektmodel [25]


[plD3] Se hvilke specifikationer der er angivet for, at dokumentet er fyldestgørende

[plD4] Verificere at specifikationen for dokumentet er fulgt, hvilket vil sige, atdokumentet er udfærdiget sa det følger formalet og indfrier de resul-tatmal der angives i specifikationen.

Overvage projektet

Krav [plC2a] ”Projektsstatus for projektet [plB4a], [plA9]”er et klart specificeretdokument der skal indeholde 54

• Budgetstatus

– Emnet er udgaet 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 tidsrelateredefaktorer

• Aktuelle eller potentielle problemer og risikoopdatering

[plD7] Der er brug for et sted til at notere potentioelle problemer samtrisikostyring

• Produkter, der skal færdiggøres i løbet af den efterfølgende periode

[plD8] Der er brug for en oversigt over hvornar hvad skal laves

• Status for evt. projektemner, jf. emneloggen

[plD9] Der er brug for emneloggen som kommunikationsværktøj mellemprojektgrupper og projektleder

• Eventuelle ændringers effekt pa budget og tidsplan



[plD10] Der er behov for at kunne spore hvad ændringer har haft af indfly-delse pa tidsplanen

For at kravet ”Opfølgning pa projektets mal [plC2b], [plB4b], [plA1]”kan opfyldeser der behov for

[plD9] En oversigt over projektets mal og hvorlangt de er.

For at kravet ”Opfølgning pa projektets milepæle [plC2c], [plB4c], [plA1]”kanopfyldes 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 opfyldesma der være

[plD12] En oversigt over hvordan ressourcer bruges

Kravet ”Projektgruppens engagement [plC2f], [plB4f], [plA11]”er basseret pamenneskelige faktorer der ligger til grund for vurdering af situationen. Somhjæ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]”erbasseret 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 andreopgaver


For at kunne opfylde kravet”Projektgruppernes kompetencer i forhold tilderes 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 forskelligearbejdsopgaver

Ansvar for at styre projektet

For at kunne opfylde kravet ”Initiere korrigerende aktiviteter for anvendelseaf 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 afnye muligheder for at fa mere ud af projektet end først antaget, skal handteres[plC3b], [plB5c], [plA8]”er af udpræget menneskelig karrakter. Det vurderesderfor, at det ligger uden for rammerne af det kommenende system og kravetbortkastes.

For at kunne opfylde kravet ”Igangsætte læringsaktiviteter, for at opnanødvendige kompetencer i projektgrupperne [plC3c], [plB5d], [plA12]d”er derbehov for



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




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 formalet og indfrierde resultatmal der angives 55.

Flere af behovene gar igen. Ved at fjerne dem og skære overflødig tekst fra faslisten over de behov projektlederen har for at kunne opfylde kravene i DenOffentlige Projektmodel:

[plE1] Specifikationerne for udfærdigelsen af et dokument skal følges, hvilketvil sige at udfærdige dokumentet sa det følger formalet og indfrier deresultatmal 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, atdokumentet er udfærdiget sa det følger formalet og indfrier de resul-tatmal der angives i specifikationen [plD4]

[plE4] Oversigt over produkter/emner der er færdiggjort [plD5], [plD6]

[plE5] Status for mal 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]



[plE12] Oversigt over hvordan ressourcer i projektet bruges [plD12], [plD17]

[plE13] Oversigt over projektgruppernes arbejdsfordeling i forhold til andreopgaver [plD14]

5.2.4.3 Opsummering af projektleder

De tekniske beskrivelser i specifikationen for Den Offentlige Projektmodel afprojektlederens rolle er brudt ned til krav. Kravene er bearbejdet og resultateter de behov som projektlederen, i følge Specifikationen for Den OffentligeProjektmodel, 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 andreopgaver [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, hvilketvil sige at udfærdige dokumentet sa det følger formalet og indfrier deresultatmal der angives [plE1]

[plF9] Spore hvad ændringer har haft af indflydelse pa tidsplanen [plE8]

[plF10] Status for mal og milepæle samt hvad der kommer i fremtiden [plE5]

[plF11] Verificere at specifikationen for dokumentet er fulgt, hvilket vil sige, atdokumentet er udfærdiget sa det følger formalet og indfrier de resul-tatmal der angives i specifikationen [plE3]

[plF12] Værktøjet emnelog [plE6]

[plF13] Værktøjet risikostyring [plE7]


Styregruppe

Ansvarlig for denoverordnede styring af projekt

[sgC4]Ansvarlig for den

overordnede ledelse af projekt[sgC3]

Godkendeprojektgrundlag [sgC21]

Godkende opfølgnings- ogstatusrapporteringer

[sgC18]

Godkende afslutningen afen fase eller projektet

[sgC14]

Fastlæggeprojektets mål [sgC12]

Fastlæggeprojektets formål [sgC11]

Fastlægge overordnetøkonomisk ramme [sgC10]

Fastlægge overordnetoverordnet tidsramme [sgC9]

Godkende planer forden næste fase [sgC19]

Vurdere, om gevinster ogomkostninger stadig står mål med hinanden med

baggrund i en opdateret business case.[sgC34]Vurdere, hvilken

information der skal forelæggesdirektionen [sgC33]

Udpegeprojektleder [sgC32]

Trækker en række valg på baggrundaf informationer (hovedsagligt)

stillet til rådighed af projektlederen.[sgC31]

Tage stilling tilprojektets endelige udformning.

[sgC30]

Tage stilling til korrigerendehandlinger ved afvigelser i forhold til den

aftalte tidsplan/ de afsatteressourcer [sgC29]

Informere projektlederen ombegivenheder uden for projektet, der kan

have ind ydelse på projektet.[sgC23]

Usecase diagram for aktøren ”styregruppe”

Godkende projektetsendelige udformning

[sgC20]

Godkende og sikrefinansiering af ændringer

[sgC17]

Godkende evalueringaf projektet [sgC15]

Godkende faseplan medangivelse af leverancer

[sgC16]

Sikre, at de nødvendigeressourcer bliver tildelt

projektet [sgC27]

Sikre, at alle produkter erblevet leveret

tilfredsstillende [sgC26]

Sikre projektets kurs isamspil med projektlederen

[sgC25]

Overvåge fase- ogprojektfremdrift via

projektetstatus [sgC24]

Aftale projektledernsansvarsområder [sgC1]Aftale

projektlederns mål [sgC2]

Beslutte om projektet skaligangsættes eller ej på baggrund afprojektinitieringsdokumentet [sgC8]

Beslutte om projektet skal fortsætteeller nedlægges på baggrund af denseneste opdaterede business case og

risikovurdering [sgC7]

Ansvarlig forgennemførelse af projekt [sgC5]

Godkende projekt-initieringsdokument [sgC22]

Forholde sig til risici,der har særlig højrisikoværdi. [sgC13]

Ansvarlig for, atevalueringen bliver gennemført

[sgC6]

Figur 5.1: Usecase diagram over aktøren ”styregruppe”. Elementerne er struktureret sade afspejler afspejler hvornar i processen de er centrale. Se afsnit 5.2.1.1 pa side 27 fordokumentation


Projektejer

Ansvarlig for atevalueringen bliver gennemført

[peB1]Skabe opbakning fra den

politiske ledelse[peB17]

Sikre at risici bliveropsporet og afbødet så ekkektivt

som muligt [peB16]

Sikre at projektetleverer de aftalte produkter

[peB15]Sikre at projektetindfrier sine formål

[peB14]

Sikre at der er ensammenhængende og ekkektivprojektorganisation [peB13]

Sikre at der er ensammenhængende og ekkektiv

planlægning [peB12]

Sikre at de nødvendige ressourcerer til rådighed i projektet i

samråd med projektlederen [peB11]

Overvåge projektetsfremdrift på det strategiske

niveau [peB10]

Orientere denpolitiske ledelse [peB9]

Inddrage Denpolitiske ledelse [peB8]

Håndtere alvorligeproblemer i projektet

[peB7]

Efterspørgerisikovurderinger [peB6]

Efterspørgekvalitetssikring [peB5]

Efterspørgeevalueringer [peB4]

Ansvarlig forprojekt [peB3]

Ansvarlig for om eventuellekorrigerende handlinger føres

ud i livet [peB2]

Usecase diagram for aktøren ”projektejer”

Figur 5.2: Usecase diagram over aktøren projektejer. Se afsnit 5.2.2.1 pa side 40 for doku-mentation


Projektleder

Udfærdige projektetsdokumentation [plC1]

Overvåge projektet[plC2]

Styre projektet[plC3]

Udfærdige de konkretedokumenter angivet i [plC1a] - [plC1g]

Udfærdigeprojektsstatus for projektet [plC2a]

Følge op åpprojektets mål [plC2b]

Følge op påprojektets milepæle [plC2c]

Følge op på uforudseteopgaver angivet i emneloggen

[plC2d]

Overvåge anvendelseaf ressourcer [plC2e]

Overvågeprojektgruppens engagement [plC2f]

Overvåge projektgruppensprioritering af

arbejdsopgaver [plC2g]

overvåge projektgrupperneskompetencer i forhold til deres

arbejdsopgaver [plC2h]

Initiere korrigerendeaktiviteter for anvendelse af ressourcer

hvis det er nødvendigt [plC3a]

Beslutte hvordan nyeprojektemner skal håndteres

[plC3b]

Igangsætte læringsaktiviteter,for at opnå nødvendige kompetencer

i projektgrupperne [plC3c]Vurdere om der bør inddrages nyepersoner, for at opnå nødvendige

kompetencer i projektgrupperne [plC3d]Gennemføre evalueringaf projektet [plC3e]

Usecase diagram for aktøren ”projektleder”

Figur 5.3: Usecase diagram over aktøren projektleder. Se afsnit 5.2.4.1 pa side 47 for dokumen-tation

K a p i t e l 6

Konklusion

Igennem en brugerundersøgelse (se punkt 4.6 pa side 22) i og en dybdegaendeanalyse (se punkt 5 pa side 23) af domænet, har jeg forudsætningerne forat udnævne fokusomrader, 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 enkonceptuel model. Den er beskrevet er i sektion 2.1 pa side 4. Den offentligeprojektmodel beskrives som et brætspil er et sagligt bud pa en konceptuelmodel for DOPE. Meningen er, som beskrevet i den teoretiske baggrund (sepunkt 3 pa side 9), at du, kære læser, derved drager nytte af din mentalemodel for en et artefakt du kender (brætspil) til at forsta Den OffentligeProjektmodel.

Jeg skal for en god ordens skyld understrege at den konceptuelle model erudfærdiget pa baggrund af domæneundersøgelserne (se sektion 4 pa side 15og sektion 5 pa side 23), omend afsnittet er placeret som det første i denneafhandling.

6.2 Anbefalinger for implementering 64

6.2 Anbefalinger for implementering

Den malgruppe der er identificeret for DOPE (se punkt 4.6 pa side 22) harto centrale tendenser:

• Kommunikationen internt og verifikationen af udførte opgaver bærerpræ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 malgruppen vil detvæ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, skaludviklingen af DOPE fokuserer pa at kunne handtere og visuelt præsentererindkommende og udgaende kalenderemner (fx via ICS filer) fra MicrosoftProjekt. En stringent lagdelt serviceorienteret arkitektur ma derfor spille encentral rolle i DOPE eftersom det gør det muligt at skabe differentieredeinterfaces og dermed interpolaritet til andre systemer. En implementeringbaseret pa et model-view-controle-pattern (MVC) vil kunne tilbyde dette.

6.2.1 Fokusomrader

Den Offentlige Projektmodel har fire centrale aktører (se punkt 5.1.1 paside 25) der igennem deres ansvar for initialiserende handlinger hver for sigstar for en central del af arbejdet et IT-udviklingsprojekt nar det handteresefter specifikationen for Den Offentlige Projektmodel. Pa figur 6.1 pa side69 ses en visuel fremstilling af de 26 behov der er identificeret 5 hos defire 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) ogprojektleder (se punkt 5.2.4.3 pa side 59). Visualiseringen ligger vægt pa atillustrere indbyrdes relationer mellem forskellige behov. Farverne pa figurenrepræsenterer de naturlige grupperinger der kommer som følge heraf.Fortolket ud fra visualiseringen, kan grupperingerne karakteriseres som decentrale omrader som DOPE skal fokusere pa at løse, for at kunne opfylde debehov som brugerne har for information. Vægten ligger i at disse elementerikke er gætværk eller meninger fra en designer, men derimod oprinder fraselve domænet.

6.2 Anbefalinger for implementering 65

Sporbarhed af ændringer via værktøjet emnelogVæ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 emnerder kan kommenteres pa. Emneloggen er helt central i Den OffentligeProjektmodel, sa det vil være oplagt at kommunerne allerede har eneksisterende emnelog. Designet skal derfor gennemtænkes sa det bliverhelt lagdelt. En implementering baseret pa et model-view-controle-pattern (MVC) vil kunne tilbyde dette.

Værktøjet risikostyringVærktøjet risikostyring er helt klart specificeret i Den Offentlige Pro-jektmodel. Teknisk set er det et er simpelt værktøj, men brugerneskrav til DOPE om at kunne spille op mod andre systemer gør, atdesignet skal være skarpt lagdelt. En implementering baseret pa etmodel-view-controle-pattern (MVC) vil kunne tilbyde dette.

Kompetencer og arbejdsbyrdeAt kunne vurderer kompetencerne i en gruppe er centralt for at kunnetildele korrekt disponerede opgaver. En mulighed løsning er, at alle derdeltager i projektet far registreret deres kompetencer. Samtidig notereshvilke fagomrader udviklingsprojektet indebærer. De to kan sa matchesop mod hinanden. Jeg har en sadan løsning mistænkt for at være sværat handterer. frem for person til person kontakt, fordi det vil væreomstendigt 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 ogfremmest skal det give et overblik over hvordan arbejdsbyrden bliverfremover. Dernæst skal man kunne se hvad den næste opgave er, somman bør ga i gang med. En løsningsmodel over et Gantt diagramanbefales.

Udfærdigelse af opgaver efter deres specifikationAt fa vejledning, eller rettere, at have let adgang til en liste over hvadet dokument skal indeholde, gør det langt nemmere at udfærdige detkorrekt. Den Offentlige Projektmodel indeholder klare specifikationer afindholdet i alle de dokumenter der er krævet. Fælles for specifikationerneer at de alle har tilknyttet beskrivelsen ”formal”der angiver hvorfordokumentet skal udfyldes samt en række ”resultatmal”der er specifikkeog konkrete krav til hvad dokumentet skal indeholde for at være udfyldtkorrekt. Disse oplysninger er allerede samlet systematisk i specifikationen

6.3 Oplæg til prototypeudvikling 66

for Den Offentlige Projektmodel, sa et elektronisk ”opslagsværk”vilikke udgøre forbedringer. Men ved at have disse oplysninger tilknyttetemnerne i den tidsmæssige oversigt, nævnt i sidste punkt, vil man faden fordel, at specifikationen er til radighed sa snart man skal udfærdigeet dokument.

Verificere at opgaver er udfærdiget efter deres specifikationAt verificere et dokument betyder at bekræfte, at samtlige resultatmal(som nævnt ovenfor) for dokumentet er opfyldt. Det kræver altsa atman adgang til produkt og liste over adgang samtidigt.

Feedback pa udførte opgaver.Feedback sker ved at den der har udført en opgave, far kommunikeretresultatet af verificeringen.

Overblik over færdige opgaverSafremt 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 fokusomrader der skal prioriteres, er et spørgsmal der, naturligvis,kræver, at de virkelige domæneeksperter bliver inddraget. Pa samme made,er (prototype)udviklingen af den visuelle fremstilling, der udgør interaktionenmellem DOPE og brugeren, en iterativ proces hvor brugernes mentale modellerma studeres nøje. Metoder som visuel perception og cardsort af emner derskal prioriteres kan anbefales. Det er højest sandsynligt at disse metoder vilidentificere flere behov hos brugerne. Specielt omkring ansvarsfordeling ogkonkrete krav til implementeringen af forskellige værktøjer, eftersom disseemner 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æreat konkretisere den konceptuelle model pa en sadan made, at brugerneseksisterende mentale model af Den Offentlige Projektmodel effektivt kangenbruges, samtidig med at nye brugere far nemmere ved at forsta modellen.


Med baggrund i min tekniske viden, sammenholdt med den information omdomænet for Den Offentlige Projektmodel jeg har faet, fremligge jeg i detfølgende et konkret oplæg til første skridt af prototypeudviklingen af DOPE.

De sidste fem punker af fokusomraderne (kommende opgaver, udfærdigelse,verificering, feedback og færdige emner) repræsenterer den livscyklus som alleopgaver skal igennem. DOPE ma fokusere pa en struktur der samler tradendeog ligger op til at strukturen for behandling af opgaverne, igennem helecyklussen, er struktureret. Til det anbefales udviklingen af en struktur kaldetTODO. Hver opgave i projektet har en TODO tilknytet, der er malrettetmod at være den samlede indgangsvinkel til opgaves cyklus. TODOs erkarakteriseret ved at have

En beskrivelse tilknyttetBeskrivelsen er den tekst der er angivet som formal i Den OffentligeProjektmodel. Det anbefales at den altid fremstar visuelt i forbindelsemed TODOs, for at brugeren ikke skal være i tvivl om hvad derarbejdes med.

Indeholder et TOOLDen ”aktive”del af en TODO hvor brugerne tilgar den viden / detdokument / det værktøj som beskrivelsen omhandler. Et TOOLkan være noget sa simpelt som en uploadfunktion af wordfiler,eller maske en avanceret visualisering i integration med størrebagvedliggende system. Det centrale er et TOOL er at stillerinformation om opgavens resultat til radighed for brugeren.

En række resultatmal tilknyttet.Den række af krav der ma være opfyldt førend TODO’ens opgaveer opfyldt. Meningen er, at forskellige brugere kan tilkendegiveom de mener at indholdet i TODO’ens TOOL lever op til hvertenkelt resultatmal. Det vil kombinere at verificeringen af en opgaveer struktureret efter specifikationen for opgaven. Samtidig vil detgenererer konkret og malbar feedback pa opgaven.

Andre TODOsFor at samle al information om en opgave ma man have tilknyttetinformation om de enkelte bestanddele. Sat pa spidsen betyderdet at et helt udviklingsprojekt teoretisk set er en TODO der i entræ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ørstog fremmest at det at oprette, konfigurerer og tilknytte nye TODOs til etudviklingsprojekt skal være yderst simpelt.

Med TODOs kan information og projektets status nemt gøres op, i og medalle resultatmal sættes som forudsætning for at en opgave er løst. Samtidiggiver det mulighed for et godt informations flow. Brugerne kan notificeres naren TODO opdateres og pa den made følge med i projektet. Alle notificeringerkan samles centralt sa der opnas et samlet overblik over projektets status, setud fra den enkelte bruger.

Maske mit oplæg minder om det online community facebook. Men det er heltnaturligt, for bade facebook og udvikling af projekter drejer sig om at giveden enkelte bruger præcis den information der gør det muligt, pa helt egnepræmisser, at overskue helheden.


Projektejer

Projektmedarbejder

Projektleder

[peC1] En oversigt over hvornår hvad skal laves og en påmindelse hvis tidsgrænsen overskrides

[sgE1] En oversigt over

hvilke produkter der er leveret

[plF4] Oversigt over produkter/emner der er færdiggjort

[plF3] Oversigt over hvordan ressourcer i

projektet bruges

[plF2] Oversigt over hvor langt projektgrupperne er med

deres arbejde

[pmC2] Oversigt over hvilke

produkter der er leveret

[pmC1] Oversigt over hvilke

områder projektet bevæger sig ind

på

[plF1] Oversigt over de kompetencer der kræves for at udfører

forskellige arbejdsopgaver

[sgE6] Kunne verificere

beskrivelse af produkt med resultat af produkt

[sgE5] Kunne spore hvad

ændringer har haft af

indydelse på tidsplanen

[sgE4] Have en oversigt

over riskostyringen af projektet

[sgE3] Have en oversigt over hvorfor ændringer er

opstået

[sgE2] En oversigt over planlagte leverancer

[plF12] Værktøjet emnelog

[sgE8] Verificere at specifikationen for et dokument er fulgt, hvilket vil sige at dokumentet er

udfærdiget så det følger formålet og indfrier de resultatmål der angives

i specifikationen.

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

dokumentet er udfærdiget så det følger formålet og indfrier de resultatmål der angives i specifikationen

[plF10] Status for mål og milepæle samt hvad der kommer i fremtiden

[plF9] Spore hvad ændringer har haft af ind ydelse på tidsplanen

[plF8] Specifikationerne for udfærdigelsen af et dokument skal følges,

hvilket vil sige at udfærdige dokumentet så det følger formålet og

indfrier de resultatmål der angives

[pmC4] Specifikationerne for dokumentet følges, hvilket vil sige at det udfærdigesså det følger formålet og

indfrier de resultatmål der angives.

[sgE7] Specifikationerne for dokumentet følges, hvilket vil sige at det udfærdiges så det følger formålet og

indfrier de resultatmål der angives.

[plF7] Se hvilke specifikationer

der er angivet for at dokumentet er fyldestgørende

[pmC3] Resumé af

sidste styregruppem

øde

[plF6] Oversigt over projekt-gruppernes kompetencer

[plF5] Oversigt over projektgruppernes arbejdsfordeling i

forhold til andreopgaver

[plF13] Værktøjet risikostyring

Signaturforklaring Har behov: Er identisk med: Er relateret til:

Visuel fremstilling af aktørenes behov og deres interne relationer

Figur 6.1: Visuel fremstilling af de 26 behov der er identificeret 5 hos aktørerne (se punkt5.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 naturligegrupperinger der kommer som følge heraf.

A p p e n d i x A

Visuel fremstilling afidentificerede behov i A3 format

Denne side skal ikke vises, men erstattes af en A3 udgave af figur 6.1 pa side69 hvor der ses en visuel fremstilling af de 26 behov der er identificeret 5 hosde 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) ogprojektleder (se punkt 5.2.4.3 pa side 59). Visualiseringen ligger vægt pa atillustrerer indbyrdes relationer mellem forskellige behov. Farverne pa figurenrepræsenterer de naturlige grupperinger der kommer som følge heraf.

Kildehenvisninger

[1]

[2] Mary Jo Davidson, Laura Dove og Julie Weltz. Mental Models andUsability, 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 Finansministerietsdepartement, Den Digitale Taskforce, 2006. http://www.fm.dk/1024/

visOrganisationsUnderside.asp?artikelID=5858.

[6] Marie-Claude Gaudel, Valerie Issarny, Cliff Jones, Hermann Kopetz, EricMarsden, Nick Moffat, Michael Paulitsch, David Powell, Brian Randell,Alexander Romanovsky, Robert Stroud og Francois Taiani. Final Versionof DSoS Conceptual Model, Technical Report CS-TR-782. Rapport,Institut fur 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.

http://www.lauradove.info/reports/mental%20models.htm

http://www.lauradove.info/reports/mental%20models.htm

http://www.csse.monash.edu.au/~cema/courses/CSE5910/lectureFiles/lecture6b.htm

http://www.csse.monash.edu.au/~cema/courses/CSE5910/lectureFiles/lecture6b.htm

http://www.fm.dk/1024/visOrganisationsUnderside.asp?artikelID=5858

http://www.fm.dk/1024/visOrganisationsUnderside.asp?artikelID=5858

http://www.cs.ncl.ac.uk/research/pubs/trs/papers/782.pdf

http://www.tcd.ie/Psychology/Ruth_Byrne/mental_models/

http://www.tcd.ie/Psychology/Ruth_Byrne/mental_models/

http://www.si.umich.edu/ICOS/gentleintro.html

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 DenDigitale 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 InteractionLO17757, 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 the2006 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 atTechnical University of Denmark, 2007. [email protected].

[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/.

http://www.cs.umd.edu/class/fall2002/cmsc838s/tichi/knowledge.html

http://www.cs.umd.edu/class/fall2002/cmsc838s/tichi/knowledge.html

http://www.boxesandarrows.com/view/whats_your_idea_of_a_mental_model_

http://www.boxesandarrows.com/view/whats_your_idea_of_a_mental_model_

http://www.learning-org.com/98.04/0141.html

http://arthur.cs.vt.edu/conceptual-modelling/Manuscripts/Nance-Arthur.pdf

http://arthur.cs.vt.edu/conceptual-modelling/Manuscripts/Nance-Arthur.pdf

http://arthur.cs.vt.edu/conceptual-modelling/Manuscripts/SW06_20%20Robinson.pdf

http://arthur.cs.vt.edu/conceptual-modelling/Manuscripts/SW06_20%20Robinson.pdf

http://www.cs.ucl.ac.uk/staff/a.sasse/thesis/Frontpage.html

http://www.cs.ucl.ac.uk/staff/a.sasse/thesis/Frontpage.html

http://www.interaction-design.org/encyclopedia/mental_models.html

http://www.interaction-design.org/encyclopedia/mental_models.html

http://alumni.media.mit.edu/~spiegel/papers/HCI.pdf

http://alumni.media.mit.edu/~spiegel/papers/HCI.pdf

http://modernisering.dk/da/projekter/redskaber_og_vejledninger/projektmodel/baggrund/

http://modernisering.dk/da/projekter/redskaber_og_vejledninger/projektmodel/baggrund/

KILDEHENVISNINGER 73

[23] Den Digitale Taskforce. Beskrivelse af roller og ansvarsomrader 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 OffentligeProjektmodel. 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.

http://oldegov.dk.upsilon.t3c.dk/uploads/media/Roller_og_ansvar_01.doc

http://oldegov.dk.upsilon.t3c.dk/uploads/media/Roller_og_ansvar_01.doc

http://oldegov.dk.upsilon.t3c.dk/redskaber_og_vejledninger/projektmodel/index.html

http://oldegov.dk.upsilon.t3c.dk/redskaber_og_vejledninger/projektmodel/index.html

http://modernisering.dk/da/projekter/redskaber_og_vejledninger/projektmodel/

http://modernisering.dk/da/projekter/redskaber_og_vejledninger/projektmodel/

Documents

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