Agil Projektledelse

Agil Projektledelse 

- en bedre vej? 

Opgavebesvarelse til afsluttende opgave på 

Diplomuddannelsen i Projektledelse, Ingeniørhøjskolen i København 

Efteråret 2007 

”Hvis du altid gør hvad du altid har gjort, 

vil du altid få hvad du altid har fået” 

Opgaven er afleveret den 14. december 2007 

udarbejdet af 

Gunnar Enggård Feder Michael Agerkvist Petersen 

K5674 K1117 

Vejleder Merete Hartvig Petersen 

Opgaven må anvendes i undervisningen

Agil Projektledelse - en bedre vej? 

Resume 

a-dpl-final-2007-12-14.doc 

INGENIØR 

HØJSKOLEN 

KØBENHAVN 

”Agil Projektledelse - en bedre vej?” er en opgavebesvarelse til den afsluttende 

opgave på Diplomuddannelsen i Projektledelse, Ingeniørhøjskolen i København, 

efteråret 2007. 

Opgavebesvarelsen stiller spørgsmålstegn ved den traditionelle 

projektledelsestilgang, der har sin oprindelse i Frederick Taylor's Scientific 

Management tanker, og som har præget både ledelses- og projektledelsestilgangen 

op igennem det 20-århundrede. 

Vi diskuterer om den traditionelle succes definition (overholdelse af aftalte krav, 

tidsramme og pris) stadig kan stå distancen i relation til udvikling af videnstunge 

produkter i dynamiske og komplekse omgivelser. Når mange projekter i dag med 

traditionel projektledelsestilgang har svært ved at opfylde disse succeskrav, synes 

det meningsløst når virksomheds- og projektledelsen blot fortsætter ad denne vej, i 

en forventning om at det nok går bedre næste gang. 

Med udgangspunkt i det agile værdisæt peger opgavebesvarelsen på, at der findes 

en anden vej til succes. Den nye vej udspringer i et øget behov for innovation, 

hvilket fordrer at projektlederen i højere grad skal kunne veksle mellem 

management og leadership. 

Opgavebesvarelsen peger på, hvilke kompetencer og adfærd der fordres hos 

morgendagens projektledere. Med henvisning til forskellige moderne ledelsesteorier 

argumenteres for, at de identificerede kompetencer er særligt stimulerende for 

udviklingen af en læringskultur og dermed også en god platform for innovation. 

14. december 2007 

Gunnar Enggård Feder 

Michael Agerkvist Petersen 

Billedet på forsiden er ”Tilbage til naturen”, Storm P, 1945 

Side i


Indholdsfortegnelse 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

1 INDLEDNING – KONTEKST OG UDFORDRING ........................................1 

1.1 FORMÅL – ET NYT PARADIGME FOR PROJEKTLEDELSE?.................................................................. 2 

1.2 PROBLEMFORMULERING.................................................................................................................. 3 

1.3 AFGRÆNSNING – HVAD FOKUSERER OPGAVEBESVARELSEN PÅ?.................................................... 3 

1.4 METODEVALG – HVORDAN ER OPGAVEN GREBET AN? ................................................................... 3 

1.5 OPGAVENS STRUKTUR..................................................................................................................... 5 

2 BAGGRUNDSANALYSE ..........................................................................6 

2.1 PROJEKTETS ÆNDREDE KONTEKST .................................................................................................. 6 

2.1.1 Hvad er konsekvenserne ved globaliseringen? ...................................................................... 7 

2.1.2 Projektledelse i historisk perspektiv....................................................................................... 7 

2.2 KOBLING MELLEM PROJEKTTYPE OG UDVIKLINGSMODEL............................................................. 12 

2.2.1 Rutineprojektet...................................................................................................................... 13 

2.2.2 Problemdefinitionsprojektet ................................................................................................. 13 

2.2.3 Passer en given udviklingsmodel til alle projekttyper? ....................................................... 14 

2.3 PROJEKTSUCCES - HVAD ER DET..? ................................................................................................ 16 

2.4 OPSUMMERING AF PROBLEMATIKKERNE....................................................................................... 18 

3 VEJEN TIL ALTERNATIV PROJEKTLEDELSE..........................................20 

3.1 DE AGILE VÆRDIER - EN FORTOLKNING......................................................................................... 20 

3.1.1 Individuals and interaction over processes and tools.......................................................... 21 

3.1.2 Customer collaboration over contract negotiation.............................................................. 22 

3.1.3 Working Software over comprehensive documentation....................................................... 22 

3.1.4 Responding to change over following a plan....................................................................... 23 

3.1.5 Opsummering........................................................................................................................ 23 

3.2 ITERATIV UDVIKLINGSMODEL....................................................................................................... 24 

3.2.1 Timeboxed iterativ udvikling ................................................................................................ 24 

3.2.2 Et paradigmeskifte ................................................................................................................ 26 

3.2.3 Planlægning vandfald- versus iterativ udviklingsmodel...................................................... 27 

3.2.4 Styring - hurtig respons på ændringer ................................................................................. 31 

3.3 PROJEKTORGANISATION ................................................................................................................ 35 

3.3.1 Organisk organisation .......................................................................................................... 36 

3.3.2 Gensidig tilpasning som koordineringsmekanisme.............................................................. 38 

3.4 SELV-ORGANISERENDE PROJEKT TEAMS ....................................................................................... 39 

3.4.1 Hvad er handlekraft?............................................................................................................ 40 

3.4.2 Handlekraft forudsætter motivation ..................................................................................... 41 

3.5 VIDENDELING I FLERFAGLIGE TEAMS............................................................................................ 44 

Side ii



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

3.5.1 Deling af tavs viden i flerfaglige teams................................................................................ 46 

3.6 PROJEKTLEDERENS KOMPETENCER............................................................................................... 51 

3.6.1 Lineær versus cirkulær logik som kompetence .................................................................... 51 

3.6.2 Balancen mellem operationel- og kontekstuel usikkerhed................................................... 53 

3.6.3 Balancen mellem at inkludere og ekskludere kunden .......................................................... 54 

3.6.4 Projektlederen i meta-position ............................................................................................. 55 

4 KONKLUSION - HVAD HAR VI LÆRT? ..................................................59 

5 PERSPEKTIVERING – NÆSTE SKRIDT .................................................62 

6 REFERENCER – HVOR VED VI DET FRA? ..............................................63 

7 DEFINITIONER & FORKORTELSER – HVAD BETYDER DET? ..................66 

APPENDIX 1 UDVIKLINGSMODELLER.....................................................70 

APPENDIX 2 ITERATIV UDVIKLING .......................................................74 

APPENDIX 3 AGIL VERSUS ITERATIV UDVIKLINGSMODEL .....................80 

APPENDIX 4 PROJEKT USIKKERHED ......................................................82 

APPENDIX 5 PROJEKTTYPER..................................................................84 

APPENDIX 6 PROJEKTSUCCES ...............................................................88 

APPENDIX 7 HVAD ER VIDEN? ...............................................................91 

APPENDIX 8 AGIL LITTERATUR .............................................................94 

Side iii


1 Indledning – kontekst og udfordring 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Forestil dig, at du, som chauffør dagligt bringer varer fra A til B. Varen er velkendt, 

du har et transportmiddel du ved kan fragte varen, samt en grundig 

kørselsvejledning til en kendt kunde. Pludselig en dag lyder beskeden: du skal 

aflevere en vare til en bestemt tid. Du kan imidlertid ikke få præcis information om 

hvad det er for en vare, hvordan du fragter den, hvor den skal afleveres, eller 

hvem modtager er. Det lyder som en umulig opgave, men lignende betingelser kan 

meget vel blive dagligdagen for fremtidens projektleder. 

I opgavebesvarelsen gør vi op med den projektledelsestilgang, der i dag anvendes i 

forbindelse med produktudvikling i de fleste danske virksomheder. Denne 

projektledelsestilgang, som vi kalder den traditionelle, er funderet på principperne i 

Frederick Taylor's Scientific Management [Bakka & Fivelsdal]. Vi argumenterer for, 

at der findes alternative former for projektledelse, der bedre matcher de 

udfordringer projekterne står overfor i dag. Dette kræver grundlæggende 

forandringer, og vi finder støtte til forandringerne i eksisterende teorier. 

Vi har begge gennem en årrække deltaget i forskellige virksomheders 

produktudviklingsprojekter. Projekterne har varieret i størrelse fra få personer op til 

100+ og med en gennemløbsperiode fra et halvt år og op til flere år. 

Gennem disse projekter har vi erfaret, at kompleksiteten for sammenlignelige 

produkter er steget mærkbart. Eksempelvis er det svært at genkende dagens 

mobiltelefon i den telefon vi kendte for 30 år siden. Skønt mobiltelefonen og 

telefonen har oprindelse i det samme behov - nemlig at bringe mennesker sammen 

- viser designet, mangfoldigheden af features og brugergrænsefladens kompleksitet 

i dagens mobiltelefon, at den har undergået en innovativ revolution over de sidste 

30 år. Efter vores opfattelse er dette en tendens snarere end et enkeltstående 

tilfælde. 

Hvor projekterne tidligere kun indeholdt opgaver med karakter af rutineproblem og 

problemløsning, indeholder de i dag flere opgaver med karakter af problemløsning 

og ofte opgaver med karakter af problemdefinition. Både projektledere og kunder i 

dagens produktudviklingsprojekter, har ofte svært ved at overskue det kommende 

produkt og dets muligheder. Dette skifte har medført, at der stilles højere krav til 

fleksibilitet omkring ledelsen af projektet, samt omkring projektdeltagernes evner 

til at indgå i mange forskellige sammenhænge. 

side 1 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

På trods af at projekterne opfylder de traditionelle mål for projektsucces - 

overholdelse af budget, tidsplan og kvalitet – oplever vi, at de udviklede produkter 

ofte ikke opfylder ledelsens og kundernes forventninger. Ikke desto mindre bliver 

dette ofte mødt med ledelseskrav om endnu mere management i projekterne - 

kravspecifikation, planlægning, opfølgning og kontrol - i stedet for at stille kritiske 

spørgsmål til hvorvidt præmisserne, for de rammer projektet virker indenfor, stadig 

er opfyldt. 

Globaliseringen betyder, at projektet, der tidligere skulle fungere i lokale relativt 

stabile omgivelser, nu også bliver nødt til at forholde sig til forandringer på 

fjernmarkeder. Globalisering skaber derfor mere dynamiske omgivelser for 

projektet, der svarer igen med innovativ tilgang i produktudviklingen [Carlson & 

Wilmot]. Innovation medfører ofte anvendelse af ny teknologi, og dette bringer 

projektet ind i mere komplekse omgivelser. Konsekvensen for sådanne projekter er, 

at projektdeltagerne skal turde bevæge sig ind i områder med større operationel 

usikkerhed såvel som kontekstuel usikkerhed. 

I dette perspektiv vil vi gerne diskutere hvilke konsekvenser ovenstående har for 

de kompetencer, der efterspørges hos projektlederen. Endvidere vil vi gerne 

vurdere, hvordan projektlederen gennem håndtering af risici balancerer mellem at 

være fleksibel overfor ændringer i omgivelserne og samtidig blive færdig med 

produktet til tiden. 

Projektledere kan i denne opgavebesvarelse få viden om de trends der pt. rører sig, 

og få indtryk af i hvilken retning projektledelse bevæger sig og hvilke konsekvenser 

det har for de kompetencer, der efterspørges hos projektledere i de kommende år. 

Endvidere henvender opgaven sig også til de beslutningstagere, der kan og vil 

initiere forandringer. 

1.1 Formål – Et nyt paradigme for projektledelse? 

Agil er fællesbetegnelse for produktudviklingsmetodikker, hvor vægten ligger på at 

levere værdi til kunden gennem iterativ udvikling. Agil er ikke i sig selv en metodik, 

men er funderet ved et værdisæt, se [Agile Manifesto]. Der findes en omfattende 

agil litteratur, se Appendix 8, der beskriver et alternativ til den traditionelle 

projektledelsestilgang. Litteraturen udspringer sjældent fra universitets- eller 

forskningsmiljøer og er ikke koblet til noget moderne videnskabsteoretisk arbejde, 

og mangler således formelt støtte. Vi har ikke kendskab til nogen større 

side 2 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

undersøgelser af den eksisterende agile empiri. Det er derfor vanskeligt at redegøre 

for, hvorvidt det agile alternativ i højere grad end den traditionelle 

projektledelsestilgang fører til succes. 

Vores intention med denne opgavebesvarelse er derfor, at skabe refleksion omkring 

den traditionelle projektledelses tilgang og forståelse for, hvilke forandringer en agil 

projektledelsestilgang fordrer hos projektlederen. 

1.2 Problemformulering 

Det er vores opfattelse, at produktudvikling i dynamiske og komplekse omgivelser 

fordrer et paradigmeskifte omkring projektledelse. I dette perspektiv vil vi diskutere 

følgende spørgsmål: 

"Hvordan kan de agile værdier hjælpe projektlederen til at skabe og 

levere nyværdi til kunden på markedspladsen?" 

Med udgangspunkt i ovenstående spørgsmål, vil vi diskutere: 

Hvilken betydning har de agile værdier for: 

• projektets processer 

• projektets struktur? 

• de kompetencer, der efterspørges hos projektlederen? 

1.3 Afgrænsning – Hvad fokuserer opgavebesvarelsen på? 

Vi tager afsæt i projektlederrollen og som sådan betragter vi det nødvendige 

paradigmeskifte indenfor projektledelse, set gennem projektlederens optik. Vores 

fokus er på produktudvikling i mindre projekter og projektteams (< 10 personer), 

der opererer i dynamiske og komplekse omgivelser. Det vil sige, vi udelader 

overvejelser om samarbejdet mellem flere teams det være sig på virksomhedsplan, 

nationalt som internationalt. 

Agile Manifesto [Agile Manifesto] er et værdisæt for software udvikling - men vi 

bruger det på produktudvikling generelt. Vi tager ikke stilling til, hvordan de 

enkelte agile værdier er opstået. Ikke fordi det er uvæsentligt, men for at afgrænse 

opgaven. 

1.4 Metodevalg – Hvordan er opgaven grebet an? 

Udgangspunktet for opgavebesvarelsen er en vurdering af projektets kontekst i et 

side 3 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

historisk perspektiv. Dette leder frem til en forståelse af projektets kontekst i dag, 

og vi bruger denne indsigt til at formulere en vision for morgendagens succesfulde 

produktudviklingsprojekter. 

Spørgsmålet er, om denne vision giver anledning til, at der efterspørges andre og 

nye kompetencer hos projektlederen. 

Det agile værdisæt giver nogle anvisninger på, hvad der er vigtigt i 

projektledelsessammenhæng. Herefter søger vi gennem fortolkning at klarlægge 

hvordan de agile værdier kan forstås. Formålet med dette er at få inspiration til, 

hvordan disse værdier kan implementeres i praksis, samt vurdere om vi kan skabe 

en vision for en anden projektledelsestilgang. 

Vi vælger at se på, hvordan vi kan implementere de agile værdier gennem 

forandringer i struktur og proces. I de moderne videnskabsteoretiske arbejder (fx 

fra [Gitte Haslebo] og [Poula Helth] samt i supplerende litteratur, primært 

[Christensen & Kreiner]) søger vi belæg for, at de foreslåede forandringer bringer 

os nærmere den formulerede vision. 

Når der anvendes modeller eller teorier fra litteraturen, angiver vi en reference til 

kilden. 

I appendiks har vi placeret en del materiale, der uddyber nogle af begreberne fra 

både traditionel- og agil projektledelse. Personer med kendskab til projektledelse 

behøver ikke at læse appendiks for at forstå opgaven. Andre begreber, som 

skønnes vigtige for forståelse af opgaven, er defineret i afsnit 7. 

I opgaven anvendes følgende tekstdifferentiering: 

• Referencer til litteratur er angivet i [], som fx: [Gitte Haslebo] og alle 

referencer er listet i afsnit 6. 

• Begreber, ord og forkortelser, der er listet i afsnit 7, er i kursiv første 

gang de optræder i teksten. 

• Vigtige pointer er anbragt i en grå boks som denne. 

side 4 af 94


1.5 Opgavens Struktur 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Vi har valgt at strukturere opgavebesvarelsen i følgende overordnede afsnit: 

Baggrundsanalyse: Her belyser vi den kontekst som nutidens 

produktudviklingsprojekter befinder sig i. Endvidere beskrives skiftet i 

projektledelsestilgangen i et historisk perspektiv. 

Vejen til bedre projektledelse: I dette afsnit argumenterer vi for, at det agile 

værdisæt vil være et udmærket udgangspunkt for en alternativ projektledelses 

tilgang. 

Konklusion: Her kommer vi med en opsummering og en konklusion på opgavens 

vigtigste punkter. 

Perspektivering: Her beskrives andre vinkler i forhold til agil projektledelse, som 

vi ikke har med i opgaven, men som det ville være relevant at arbejde videre med. 

Referencer: Her lister vi, de referencer der er anvendt i forbindelse med opgaven. 

Definitioner & forkortelser: Her definerer vi, de begreber som vi finder vigtige, 

at have en fælles forståelse med læseren omkring. 

Appendiks: Indeholder supplerende information. 

side 5 af 94


2 Baggrundsanalyse 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Dette afsnit giver en uddybende beskrivelse af problemformuleringen. 

Afsnittet belyser den kontekst det moderne udviklingsprojekt i dag befinder 

sig i, samt diskuterer globaliseringens indflydelse på den måde virksomheder 

gennemfører projekter på i dag. Endvidere ser vi på, hvordan man kan 

karakterisere det skifte i ledelsestilgang, der har fundet sted fra starten af det 

20’ende århundrede og frem til i dag. 

Der redegøres for vores forståelse af en række begreber (globalisering, teknologi, 

dynamiske og komplekse omgivelser, eksponentiel økonomi, det rigtige produkt, 

succes), der spiller en central rolle, når man skal forstå den forandring, vi ser 

omkring tilgangen til projektledelse. 

2.1 Projektets ændrede kontekst 

Konteksten for projekter har ændret sig gennem de sidste dekader. Den 

teknologiske udvikling har drevet globaliseringen og medført ændrede krav til 

projektledelse af produktudvikling. 

Den kontekst, projekterne i dag befinder sig i, er stærkt påvirket af den 

globalisering, der har fundet sted gennem de sidste 40 år. Globaliseringen (det vil 

sige, den stadig stigende teknologiske, kulturelle og økonomiske udveksling mellem 

de forskellige verdensdele) drives på mange måder af den teknologiske udvikling 

(fx større og billigere fly og skibe, Internettets hastige udbredelse) samt af den 

politik, der udspilles på den internationale scene (fx GATT-aftalen og WTO- 

organisationen). Den gør transport og kommunikation over store afstande 

nemmere og gør dermed handel på tværs af verdensdele stadig mere økonomisk 

attraktiv. Man kan sige, at verden bliver mere flad, idet konkurrencefordele og - 

ulemper i stigende grad udlignes. 

Men globaliseringen har også en anden konsekvens. Viden spredes i dag langt 

hurtigere end tidligere og kombineres til nye ideer, der igen sammensættes som 

byggeklodser og skaber innovation i et stadigt stigende tempo. Den "tidslige 

distance" mellem nye ideer er omvendt proportional med den stigende 

globalisering. Jorden er ikke kun flad - dens udstrækning er kun på størrelse med 

en dot (som i ”dot-com”) ...! Dette fører til hvad [Carlson & Wilmot] betegner som 

side 6 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

den eksponentielle økonomi, og som er afgørende for hvilke virksomheder, der 

eksisterer om 3-5 år. 

2.1.1 Hvad er konsekvenserne ved globaliseringen? 

Globaliseringen udfordrer virksomhedernes evne til at udvikle nye 

konkurrencedygtige produkter hurtigt. 

Globaliseringen har som konsekvens, at konkurrencen mellem virksomheder er 

stærkt voksende. Det betyder bl.a., at virksomhedernes overlevelsesevne er koblet 

til deres evne til hurtigt at udvikle nye produkter og features, der skal erstatte 

tidligere produkter. Det vil sige, der hele tiden skal skabes nye ideer, der resulterer 

i nye konkurrencedygtige produkter, men der er også en udfordring i at gøre dem 

tilgængelige på markedspladsen, på det rigtige tidspunkt. Dette er ganske 

afgørende for en virksomheds overlevelsesevne. Moore's lov siger, at en computers 

ydeevne fordobles for hver 18-24 måned [Carlson & Wilmot]. Hvis en virksomhed i 

computer branchen ikke kan generere ideer til nye produkter, der matcher denne 

udvikling i ydeevne, vil den være udkonkurreret i løbet af ganske få år. Denne 

tendens forstærkes i takt med at økonomien drives stadig mere af videnstunge 

produkter, og dette skyldes ikke mindst Internettets eksponentielle vækst. Så 

succesen bestemmes i høj grad af evnen til at udvikle nye produkter hurtigt og 

derigennem skabe ny kundeværdi. I dette spændingsfelt spiller tidsfaktoren en 

vigtig rolle. 

2.1.2 Projektledelse i historisk perspektiv 

Ledelse, herunder projektledelse, har ændret sig, fra administrativ kontrol over 

effektiv rationalisering og faglig ledelse til professionel ledelse, som følge af 

ændret projektkontekst. 

Selvom vi kender til store projekter fra gammel tid, såsom Ægyptens pyramider, 

Romernes akvædukter osv. så er projektledelse som selvstændig disciplin ikke 

særlig gammel. Projektledelse har sine rødder i de klassiske ingeniørfag, som at 

bygge broer og skibe. 

side 7 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Projektledelsestilgangen har gennem de sidste 100 år fulgt de ændringer, der har 

været indenfor generel ledelse i samme periode. Ledelsestilgangen for de seneste 

100 år kan opdeles i 4 perioder [Poula Helth]: 

• Administrativ kontrol 

• Effektiv rationalisering 

• Faglig planlægning 

• Professionel ledelse 

I de efterfølgende afsnit relateres disse 4 perioder til projektledelse 

2.1.2.1 Administrativ kontrol 

I perioden 1900-1930 blev ledelse betragtet som administrativ kontrol, hvor 

embedsmænd bedrev ledelse som regelorienterede kontrollanter. Administrationen 

fik i denne periode mange flere opgaver og blev udvidet med nye typer af 

specialister [Bakka & Fivelsdal]. 

Fra midten af 1900 tallet og frem var der fokus på, at kunne producere mere af det 

samme til stadig lavere enhedsomkostninger. I starten af det 20 århundrede var 

mange virksomheder relativt store og industrialiseret, som rutinemæssigt 

producerede forskellige produkter. 

I denne periode arbejdede Frederick Taylor med Scientific 

Management [Bakka & Fivelsdal], bogen udkom i 1911. En af 

Taylors konklusioner var at arbejde kan analyseres i tids- og 

bevægelsesstudier og neddeles til elementardele og derved 

forøge produktiviteten. Hovedpunkterne i Taylors teori er: 

• Definer de nødvendige kvalifikationer 

• Vælg arbejdskraft med passende evner for de enkelte jobs 

• Standardiser metoder til udførelse af de enkelte jobs 

• Uddan medarbejdere til standard opgaver 

• Planlæg arbejdet og fjern forhindringer 

• Beløn og straf medarbejdere for at få dem til at gøre tingene rigtigt. 

Taylor's teori har uden tvivl været effektivitetsfremmede da den kom frem og i 

årene derefter. Før Taylor fik man arbejdsstyrken til at arbejde hårdere eller 

længere, når effektiviteten skulle forøges. Det skal bemærkes, at Taylor kun 

forholdte sig til arbejde af repeterbar karakter. 

side 8 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Denne neddeling af arbejde i forudsigelige dele samt planlægning af specialisering 

er samme princip som anvendes i den traditionelle projektledelses tilgang i dag, 

Første gang projektledelse optrådte som disciplin, var i starten af det 20’ende 

århundrede. Henry Gantt’s var under påvirkning af Frederick Taylor’s ideer, og 

beskrev en række værktøjer til projektledelse, hvor Gantt diagram er det mest 

kendte. 

I starten af det 20. århundrede var et produkts livscyklus, altså den periode det 

sælges i, mange dekader [Carlson & Wilmot]. Et godt eksempel fra den tid er 

telefonen, som stort set var uforandret på markedet i flere dekader, indtil 

fremkomsten af automatiske centraler krævede nye telefoner. 

Fra 1900-1930 var mange produkter også specialiseret i de forskellige lande - 

endog i de forskellige byer. Fx kunne det elektriske net have forskellige spændinger 

i de forskellige byer. En sådan specialisering udgør selvsagt en barriere, for at 

virksomhederne kan skabe et stort marked. 

2.1.2.2 Effektiv rationalisering 

Fra 30’erne til 60’erne blev et produkts livscyklus reduceret. Fx gik der 10 år fra det 

første sort-hvide fjernsyn (1939) til det første farvefjernsyn (1951). Interessant 

nok gik der yderligere mere end 15 år, inden Danmarks Radio sendte fjernsyn i 

farver (1967). 

I denne periode begyndte verden at interessere sig for at få standardiseret 

produkter på tværs af landegrænserne. Dette skete bl.a. ved oprettelsen af 

International Organization for Standardization (ISO) i 1947. 

Efter 2. verdenskrig startede et antal store og komplekse projekter, bl.a. indenfor 

våbensystem området. Disse projekter havde et meget stort antal aktiviteter og 

mange indbyrdes afhængigheder, hvilket stillede større krav til ledelsen af 

projekterne. Disse krav afstedkom nogle af de projektledelsesværktøjer vi kender i 

dag (PERT diagrammer, Critical Path Method etc.), der alle gav projektlederen 

bedre mulighed for styring. Ideerne fra Taylor, Gantt og andre hjalp projektledelse 

på vej mod en selvstændig disciplin. 

Det er også i denne periode, at ”ledelse” dukker op for første gang. Ledelse var 

rettet mod rationel arbejdsledelse. Det vil sige, ledelse skulle ske gennem effektiv 

side 9 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

rationalisering og optimering af sagsgange og ved at indgyde ”den rette produktive 

ånd”. Genstanden for rationalisering var processen ud fra et teknisk-økonomisk 

rationale. 

I 1930'erne udviklede Max Weber sin bureaukratiske teori, 

baseret på Scientific Management ideerne. Weber fokuserede 

på at dele organisationer i hierarkier med stærke funktionelle 

linier, der blev ledet gennem autoritet og styring. Han forslog 

at organisationer beskrev detaljerede procedurer for alle 

rutineopgaver [Bakka & Fivelsdal]. 

Weber’s ideer har stadig betydning for den måde projekter 

traditionelt organiseres på. Projektet opdeles typisk efter 

fagdiscipliner, hvor de enkelte fagdiscipliner koordineres gennem dokumenter og 

beskrevne procedurer. 

2.1.2.3 Faglig planlægning 

Indtil starten af 1960’erne er det typiske projekt baseret på ad hoc projektmodeller, 

se Appendix 1. 

De projektledelsesværktøjer, der i 50’erne var udviklet til brug i meget komplekse 

projekter, blev efterhånden spredt til andre typer projekter, også projekter med 

væsentlig mindre kompleksitet. Denne ændring afstedkom en række forandringer i 

tilgangen til projektledelse. Blandt andet blev der udpeget en projektleder til at 

styre projektet. Han skulle endvidere sammensætte projektet og sikre 

kommunikationen på tværs af de forskellige afdelinger. 

I 1969 dannes Project Management Institute (PMI) med det formål at få defineret 

projektledelse som en professionel disciplin med formaliseret værktøjer og 

metoder. Dette skulle bl.a. sikre en ensartet tilgang, som kunne anvendes indenfor 

alle typer projekter, fra brobygning til produktudvikling. 

PMI’s tilgang repræsenterer den traditionelle projektledelses tilgang. Den er den 

dag i dag den traditionelle projektledelsestilgang, og på mange områder funderet i 

side 10 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Taylor, Gantt og Weber’s tanker fra starten af det 20’ende århundrede. 

I perioden fra 1960 til 1980 var der ledelsesfokus på faglig planlægning, 

effektivisering, total rationalisering af struktur, teknik, opgaver og personer. 

Planlæggerne satte ikke kun sagen eller processen i centrum, men også selve 

problemet [Poula Helth side 21]. Denne tilgang, mener vi, blev drevet af en 

overvægt af rutineopgaver i udviklingsprojekterne, se Appendix 5. 

Organisationsidealet var hierarkiet med funktionelle søjler, der var funderet i 

basisorganisationen og var tilpasset repeterbare processer. 

Kontakten til kunder skete fx gennem marketing og ikke direkte fra projektteamet. 

Der var fokus på at skabe struktur i organisationen, men også omkring 

projektopgaver, og målet var at tilvejebringe stabilitet, forudsigelighed og 

ensartethed [Christensen & Kreiner side 20]. 

2.1.2.4 Professionel ledelse 

Perioden fra 1980 var også perioden, hvor globaliseringen starter. Globaliseringen 

tog for alvor fart op gennem 90’erne. Fra 1980 og til nu har nogle produkttyper 

oplevet en dramatisk reduktion i levetid. Mobiltelefonen er et godt eksempel på en 

produkttype, hvor det går så hurtigt, at det er billigere at stoppe et projekt, der er 

6 måneder forsinket og så starte et nyt projekt op, end at gøre projektet færdigt. 

Virksomheder som Nokia lancerer 10+ nye modeller om året. Perioden har også 

været præget af øget harmonisering af standarder i den vestlige verden. Således 

kan en GSM type mobiltelefon sælges i hele Europa og ikke kun i Norden, som 

tilfældet fx er med den tidligere nordiske mobiletelefon standard NMT. 

I denne periode har ledelse været fokuseret 

omkring begreber som professionel og strategisk 

ledelse [Poula Helth side 22]. Lederen har i højere 

grad skulle formulere visioner og værdier samt 

udforme handleplaner for at nå målene. 

Organisationen har ændret sig mere i retning af 

netværk, og produktionsoutput er blevet mere 

kundetilpasset. Fokus er flyttet fra den stabile til 

den fleksible projektorganisation, og grundlaget for 

projektets styrke er skiftet fra, at kunne skabe stabilitet til at kunne håndtere 

forandring. Vi mener, denne ændring er sket, for at tilgodese de særlige behov, 

side 11 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

globaliseringen har medført, og at dette skifte indikerer, at andelen af 

problemdefinerende projekter er voksende, se Appendix 5. 

Men hvad er det for behov globaliseringen har ført med sig? På hvilken måde 

påvirkes projektteamet og dets måde at arbejde på? Før vi kan svare på dette, må 

vi først vurdere, om der er en sammenhæng mellem forskellige projekttyper og den 

kontekst de befinder sig i. 

Det er interessant, at den traditionelle projektledelsestilgang der anvendes i 

produktudvikling i dag, har sine rødder i en helt anden tid. Det var en tid, hvor 

produkters livscyklus blev målt i dekader, og hvor markedet for masseproducerede 

produkter var det foretrukne domæne. Det var en tid, hvor forandring var uønsket 

af hensyn til effektiviteten. 

2.2 Kobling mellem projekttype og udviklingsmodel 

Projekttypen kan karakteriseres ved projektets stillingtagen til operationel og 

kontekstuel usikkerhed. 

Projektet bør vælge udviklingsmodel ud fra projekttypen. 

Figur 1 viser forskellige projekttyper med relation til usikkerhed. Projekttyperne 

defineres i de underliggende afsnit. 

Høj 

Lav 

Lav 

kaos 

problemdefinition 

problemløsning 

kontekstuel 

usikkerhed 

rutine 

Fuldstændig 

orden 

Figur 1 Projekttyper og deres relation til henholdsvis operationel og kontekstuel 

usikkerhed [egen tilvirkning]. 

side 12 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

I en idealiseret tilstand med fuldstændig orden er alle opgaver veldefineret og 

forudsigelige. Gennem traditionel risikohåndtering kan enhver operationel 

usikkerhed da elimineres. I Figur 1 svarer dette til, at den kontekstuelle usikkerhed 

er høj, idet de fast definerede opgaver og detailplanlægningen fordrer, at 

ændringer i den omgivende verden ikke får direkte indflydelse på opgaveløsningen, 

og altså ignoreres. Omkostningen er, at der ikke sker nogen som helst læring fra 

omgivelserne. 

I den anden ende af skalaen findes en idealiseret tilstand af kaos. Her stiller 

projektet sig helt åben overfor enhver form for ændring, der kan afstedkomme ny 

læring, skabe nye muligheder for opgaveløsning eller ideer. Den kontekstuelle 

usikkerhed er nu lav, fordi enhver ændring skal evalueres. Prisen er fuldstændig 

uforudsigelighed om hvilke opgaver, der skal løses i morgen og hvordan de skal 

løses. Idet der ikke kan etableres faste mål, kan der heller ikke etableres nogen 

planlægning. Objekterne for den traditionelle risikohåndtering er meget flygtige, 

hvorfor den operationelle usikkerhed bliver høj. 

Dilemmaet i Figur 1 er, at projektet ikke kan eliminere den operationelle usikkerhed 

uden at fornægte eller negligere den kontekstuelle usikkerhed og vice versa 

[Christensen & Kreiner, side 44]. Dette indikeres ved den røde kurve. 

2.2.1 Rutineprojektet 

Rutineprojektet kan typisk nedbrydes i velafgrænsede delopgaver, der er målbare, 

både hvad angår tidsforbrug og kvalitet. Ekstremet kan symboliseres ved et system 

i fuldstændig orden, hvor alle opgaver er forudsigelige, velkendte og kan 

planlægges og styres, se Figur 1. Traditionelt anvendes vandfaldsmodellen som 

udviklingsmodel for rutineprojektet, se Appendix 1. 

Konsekvensen er, at projektet fastlåses i en indre verdens logik. Der er fuldt fokus 

på at løse opgaven og levere produktet. I denne tilstand ignoreres eventuelle 

ændringer i omgivelserne, svarende til maksimal kontekstuel usikkerhed. 

2.2.2 Problemdefinitionsprojektet 

Problemdefinitionsprojektet ligger i den anden ende af skalaen, og kan ikke drives 

af konkrete, veldefinerede mål, på grund af den manglende opgavedefinition. 

Ekstremet er kaos, se Figur 1. I denne tilstand er definition af faste mål ikke mulig, 

fordi projektet hele tiden forholder sig til nye input. Hvis projektet efterstræber at 

side 13 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

reducere den kontekstuelle usikkerhed, betyder det i den yderste konsekvens, at 

projektet aldrig bliver færdigt. 

I næste afsnit vurderer vi, om det giver mening, at anvende vandfaldsmodellen i 

både det rutineprægede og det problemdefinerende projekt. 

2.2.3 Passer en given udviklingsmodel til alle projekttyper? 

Andelen af problemløsende og problemdefinerende opgaver er langt større i 

produktudviklingsprojekter end i fx bygge- og anlægsprojekter. 

Vandfaldsmodellen egner sig bedst til projekter, hvor der er et overvejende 

antal af rutineprægede opgaver. 

Vi oplever i dag, at produktudviklingsprojekter i udstrakt grad anvender 

udviklingsmodeller, der minder om vandfaldsmodellens sekventielle forløb. 

Samtidig ser vi også, at mange af disse projekter ikke kan levere færdige produkter 

til tiden, eller at produkterne ikke opfylder kundens forventninger på 

afleveringstidspunktet. Spørgsmålet er derfor: er der en sammenhæng mellem 

projekttypen, den udviklingsmodel der anvendes, og projektets evne til at opfylde 

kundens forventninger? 

Et af formålene med en udviklingsmodel, er at sikre effektivitet i arbejdet og skabe 

forudsigelighed af hensyn til planlægningen. 

Vandfaldsmodellens håndterer effektivitetsproblematikken ved så vidt muligt at 

nedbryde projektopgaven til enkle delopgaver, samt separere de mere kreative 

opgaver fra de mere rutineprægede. 

Denne tilgang reducerer projektets følsomhed overfor knaphed på højt kompetente 

personer, og minimerer projektomkostningen, ved at udskille og samle de 

rutineprægede opgaver, der kan udføres af en mindre kompetent og dermed 

billigere arbejdskraft. Denne tilgang styrker også muligheden for detaljeret 

planlægning, især i implementationsfasen, idet den indeholder rutineprægede 

opgaver, der er relativt forudsigelige. 

Dette kan være en meget fornuftig strategi, hvis projektet fortrinsvis indeholder 

rutineprægede opgaver. De kreative opgaver er ikke karakteriseret ved samme 

forudsigelighed. 

side 14 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Fordelingen af opgavetyper synes imidlertid ikke at være ens for rutine- og 

problemdefinitionsprojektet. 

Et projekt som Storebæltsbroen blev gennemført i perioden 1988-1998. Østbroen 

blev anlagt i perioden 1991-1998 med 3 års forudgående forundersøgelser og 

projektering. Anlægsarbejdet ligger i implementationsfasen, og må med rimelighed 

kunne antages at vægte betydeligt mere end analyse og design, set i lyset af at det 

varede 8 år og involverede tusinder af bygningsarbejdere. Det er vores opfattelse, 

at dette kan generaliseres, og at bygge- og anlægsprojekter derfor typisk ligger i 

kategorien rutineprojekter. 

For softwareudvikling er implementationen skrivning af selve kildeteksten samt test 

af denne. Med denne definition udgør implementationsfasen ca. 15 % af hele 

softwareprojektet [McConnel]. Softwareudviklingsværktøjer tilbyder i dag 

kodegenereringsfaciliteter, hvilket også peger i retning af, at implementationsdelen 

i softwarebaserede projekter er faldende. Den relativt lille andel af rutineopgaver 

betyder, at softwareudvikling må karakteriseres som problemløsning eller 

problemdefinerende. 

Opgavefordelingen mellem rutine- og problemdefinerende projekter er illustreret i 

Figur 2. 

Figur 2 Implementationsfasens vægt i forskellige projekttyper 

Det er vores erfaring, at fordelingen af opgavetyper i produktudviklingsprojekter er 

sammenlignelig med softwareudviklingsprojekter. 

På denne baggrund kan det synes svært at forstå, at mange projekter indenfor 

side 15 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

produktudvikling ukritisk vedbliver med at anvende vandsfaldsmodellen til 

produktudvikling. 

Hvis produktudviklingsprojekter vælger at anvende alternative udviklingsmodeller, 

må der også stilles spørgsmål til, om det er muligt at fastholde et objektivt billede 

af, hvad der ligger i begrebet projektsucces. Dette er emnet for det næste afsnit. 

2.3 Projektsucces - hvad er det..? 

Traditionelt vurderes projektsucces i forhold til de operationelle parametre - 

planlagt overholdelse af tidslige rammer, af funktionelle og kvalitative 

rammer (features) samt af økonomiske rammer. 

Det bør overvejes, om kontekstuelle parametre også skal indgå i vurderingen 

- fx graden af værdiskabelsen hos kunden, samt om levering skete i det 

markedsmæssige rette tidsvindue. 

Hvis der laves væsentlige ændringer i projektets rammer, som fx skift af 

udviklingsmodel, må vi spørge, om det giver anledning til at revurdere og evt. 

ændre de parametre, projektets succes vurderes efter. 

For at vurdere effekten af eventuelle ændringer må vi forholde os til, hvad der 

menes med projektsucces. Vi sætter den traditionelle definition på projektsucces i 

relation til ændringer i projektets kontekst, for at vurdere om dette giver anledning 

til nye overvejelser. 

Det er projektlederens overordnede ansvar, at projektet opnår succes. Det vi 

interesserer os for er, hvad det vil sige, at projektet opfattes som en succes, og 

hvilke fordringer dette stiller til projektlederen. 

Traditionelt anskues projektsucces ud fra planlagte og operationelle kriterier: 

levering af aftalt funktionalitet, til aftalt tid og indenfor aftalt budget. 

Formålet med projektsucces evalueringen er at gøre status, og fastsætte værdien 

af den forandring projektet har tilvejebragt - står det opnåede resultat mål med 

indsatsen? For at svare på dette spørgsmål er det nødvendigt med et kriterium. I 

det traditionelle projekt er kriteriet det oprindeligt formulerede resultatmål. Så 

længe de opnåede resultater stemmer overens med de målsatte er alt godt, og her 

spiller tidsplanlægningen en betydelig rolle. Projektplanen betragtes som det kort, 

side 16 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

der fører projektet til succes. Derfor sker enhver bedømmelse af projektet ved at 

vurdere om projektets status er i overensstemmelse med planen. 

Denne retrospektive tilgang kan synes meget belejlig, idet resultatet direkte kan 

sammenlignes med succesparametrene, som de oprindeligt blev defineret ved 

projektets start. Dette er efter vores mening en lineær tilgang – hvor 

projektteamets orientering og retning fastsættes gennem målsætninger, og 

begivenheder og handlinger ordnes i kronologisk rækkefølge, og betragtes gennem 

en årsag-virkningsoptik. 

Projektlederens strategi til at opnå succes i denne kontekst er reduktion af 

operationel usikkerhed, se Appendix 4. Efter vores mening er dette et udtryk for en 

1.ordens-ledelseslogik, hvor projektopgave og projektteam, i det ekstreme tilfælde, 

opfattes som et lukket system, en indre verden, der kan håndteres adskilt og uden 

hensyntagen til den ydre verden. 

Men hvis projektets omgivelser ændrer sig, vil den oprindelige plan måske ikke 

længere være værdiskabende som retningsgiver. I dette tilfælde skal projektet 

hellere måles på dets evne til at levere værdi til kunden, end på evnen til blindt at 

følge en forældet plan. 

Undersøgelser tyder på, at traditionelt gennemførte projekter ikke altid fører til 

produkter, der matcher kundens behov og forventninger ved afleveringen. Standish 

Group hævder således, at IT-projekter gennemført efter vandfaldsmodellen leverer 

mange (45 %) features, der aldrig udnyttes [Standish01]. 

Det kan måske synes selvmodsigende, at kundens behov ikke er opfyldt, samtidig 

med at alle formelle kontraktaftaler og kravspecifikationer i øvrigt er opfyldt. Men 

dette kan ske, hvis projektet fastfryser planlægningsgrundlaget under hele 

projektforløbet, uden at tage hensyn til at projektets kontekst ændres igennem 

projektforløbet. Standish Group's observation understreger behovet for, at projekt 

og kunde løbende vurderer, om de leverede features er værdiskabende for kunden. 

Denne vurdering er vigtig, ikke kun i forhold til om projektet leverer værdiskabende 

features. Men også fordi den kan bruges styringsmæssigt, idet fleksibilitet omkring 

til- og/eller fravalg af features er bestemmende for, om den endelige leverance 

rammer det helt rigtige tidsvindue på markedet. Denne tidslighed er 

kontekstafhængig og har intet at gøre med de planlagte tidslige rammer, projektet 

ofte evalueres efter. 

side 17 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Det vil sige, opfattelsen af succes skal i nogle sammenhænge løsrives fra en "indre 

verden" betragtning og åbnes overfor ændringer i projektets ydre verden med en 

løbende evaluering af ændringernes betydning for projektet. Det er stadig de 3 

parametre (feature, tid og pris) der evalueres i forhold til, men disse bliver nu 

variable størrelser, i særdeleshed featureparameteren, mens tidskrav og pris ofte er 

fastlåste. Projektlederens strategi til at opnå succes, i relation til den ydre verden, 

er reduktion af kontekstuel usikkerhed, se Appendix 4. 

Den kontekst, projektet befinder sig i, har altså betydning for, hvordan 

projektlederen sikrer projektsucces. I dynamiske omgivelser skal projektlederen 

ikke kun forholde sig til, hvordan opgaven bedst løses (operationel usikkerhed), 

men også løbende vurdere om opgavedefinitionen fører til "det rigtige produkt" 

(kontekstuel usikkerhed). Vægtningen mellem reduktion af operationel og 

kontekstuel usikkerhed afhænger af den aktuelle projekttype: rutine, 

problemløsning eller problemdefinition, se Appendix 5. 

2.4 Opsummering af problematikkerne 

Den foregående diskussion har argumenteret for, at globaliseringen fordrer en 

anden tilgang til projektledelse end den traditionelle, hvis virksomhederne i den 

eksponentielle økonomi skal gøre sig håb om at overleve på lang sigt. Samtidig 

spiller tidsfaktoren en vigtig rolle - det er i voksende grad afgørende, at nye 

produkter introduceres på markedspladsen på det rigtige tidspunkt. 

Hvis vi skal formulere dette som en vision for projektledelse af morgendagens 

projekter, må det blive at: 

Vision for projektledelse 

Projektlederen skal støtte dannelse af relationer og der igennem facilitere: 

• skabelsen af ny viden 

• ibrugtagning af nye teknologier 

• en positiv adfærdsændring 

for projektgruppe og kunden. Dette skal sikre at projektet udvikler det rigtige 

produkt - i rette tid. 

Her igennem styrkes udviklingsmiljøet, der er en bærende forudsætning for 

succes i fremtidens projekter. 

side 18 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Fokus skal flyttes væk fra det individorienterede, og skal i langt højere grad vendes 

mod det relationsskabende. Relationer skal dyrkes og plejes, dels i projektteamet, 

men også i forhold til omgivelserne (kunderne). Det er igennem disse relationer ny 

viden og nye teknologier skal manifestere sig, og i sidste ende sikre virksomhedens 

overlevelse. Visionen peger på, at projektlederen skal fremme og øge den virkning 

relationerne har på skabelse af ny viden. Han skal understøtte den 

adfærdsændring, der er nødvendig for, at den ny viden slår igennem som læring, 

og derved bidrager til, at projektet leverer det rigtige produkt. 

side 19 af 94


3 Vejen til alternativ projektledelse 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Vejen til alternativ projektledelse baseres på de agile værdier. Implementering 

af et organisk, selvorganiserende og flerfagligt projektteam, kombineret med 

en iterativ udviklingsmodel understøtter disse værdier. 

Vær opmærksom på, at disse ændringer stiller nye krav til projektlederens 

kompetencer. 

Mod slutningen af 1990erne var der en stigende erkendelse af, at den traditionelle 

projektledelsestilgang ikke var tilstrækkelig til at skabe de ønskede resultater. 

Erkendelsen bredte sig primært indenfor softwareudviklingskredse, og var mere 

fremherskende på græsrodsniveau end på ledelsesniveau. 

Adskillige forskellige metoder voksede frem som resultat af denne erkendelse. 

Fælles for dem alle var et mere tæt samspil mellem projektteam og kunde, fokus 

på direkte kommunikation, hyppige leveringer af produkt med gradvist mere og 

mere værdiskabende funktionalitet. De bærende elementer i denne nye 

projektledelsestilgang blev i 2001 formuleret som et sæt værdier, kaldet Agile 

Manifesto, se [Agile Manifesto]. 

Med udgangspunkt i de agile værdier vil vi diskutere, mulige strukturelle og 

processuelle forbedringer. Vi vurderer om dette skifte i projektledelsestilgang 

fordrer nye krav til projektlederens kompetencer. 

3.1 De agile værdier - en fortolkning 

De agile værdier fokuserer på individer og samspillet med kunde i højere grad 

end den traditionelle projektledelsestilgang gør. Vi vurderer, at dette ændrede 

fokus er med til at skabe mere succesfuld produktudvikling. 

I dette perspektiv fortolker vi, hvilke strukturelle og processuelle ændringer, 

der kan understøtte disse værdier. 

Den fortolkning, vi anvender, tillader vi at gælde for produktudvikling, og ikke kun 

softwareudvikling. Dermed peger vi på ændringsmuligheder, der kan være 

relevante i det flerfaglige miljø, software, elektronik og mekanik. 

Der er 4 overordnede værdier i det agile manifest, se Figur 3. Det agile manifest er 

struktureret i en venstre side og en højre side, hvor udsagnet på venstresiden 

side 20 af 94


prioriteres højere end udsagnet på højreside. 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

The Manifesto for Agile Software Development 

We are uncovering better ways of developing software by doing it and 

helping others to do it. 

Through this work we have come to value: 

Individuals and interactions over processes and tools 

Working (usable) software over comprehensive documentation 

Customer collaboration over contract negotiation 

Responding to change over following a plan 

That is, while there is value in the items on the right, we value the items 

on the left more. 

Figur 3 Agile værdier [Agile Manifesto] 

Det agile manifest er af og til blevet misbrugt som argumentation for, at særlige 

opgavetyper, fx dokumentation og planlægning, ikke længere er nødvendige i 

projektet. Dette er forkert! Det er derimod vigtigt hele tiden at vurdere, hvor det er 

mest værdiskabende at placere projektets fokus. Fx kan det være vigtigere at 

forholde sig til en ændring i projektets omgivelser end at følge en plan. 

Som det fremgår af ovenstående er agil tilgang mere et spørgsmål om holdninger 

end om proces og mere et spørgsmål om relationer end metoder. 

I de følgende afsnit fortolkes de enkelte agile værdier. 

3.1.1 Individuals and interaction over processes and tools 

Fokus skal rettes mod individet og samspillet mellem individer, og bør ikke 

side 21 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

overskygges af processer og værktøjer. Det er individer, der udvikler produktet, og 

processerne er vejledende og supporterende. Værktøjer er med til at øge 

effektiviteten. Vi tolker det således, at hvis ikke projektdeltagerne har de rette 

kompetencer, så hjælper processer og værktøjer ikke. Processer og værktøjer er 

nyttige, men det er projektdeltagerne som individer og gruppe der er vigtigst. Vi 

mener derfor, at der skal fokuseres på, hvordan individernes arbejdsbetingelser 

optimeres, så de får de bedste betingelser for at være effektive og produktive. 

Dette skal sættes i relation til de strukturelle rammer, men også relateres til 

projektlederens rolle i forhold til projektteamet. 

3.1.2 Customer collaboration over contract negotiation 

Fortolkningen er her, at kunden er den vigtigste blandt projektets interessenter - 

uden kunde, ingen forretning. Kunden er i denne kontekst den person, der bruger 

slutproduktet til at generere forretningsværdi, for konsumvarer er det slutbrugeren. 

Kunden er den af interessenterne, der definerer værdi, andre interessenter 

definerer begrænsninger. For interne projekter er der typisk ikke en kontrakt i 

traditionel forstand, her er det fx en kravspecifikation som udgør kontrakten 

mellem kunde og projekt. Denne definerer de krav, som kunden vurderer giver 

værdi. Imidlertid kan en kontrakt ikke erstatte det værdifulde bidrag, et godt, tæt 

samarbejde og en god kommunikation mellem projekt og kunde giver. Projektet 

skal derfor vælge at betragte relationen til kunden som et partnerskab, snarere end 

en kontraktaftale, i bestræbelsen på at levere et produkt, der opfylder kundens 

forventninger bedst muligt. Dette har både strukturelle og kompetencemæssige 

konsekvenser for projektet. Men kontrakten er stadig vigtig for at initiere kunde- 

projekt relationen. 

3.1.3 Working Software over comprehensive documentation 

De fleste er bekendte med ordsproget "Et billede siger mere end 1000 ord". Vi 

mener, projektet nøje skal overveje, hvilken kommunikationsform, der er bedst 

egnet i forhold til kunden. Det drejer sig ikke kun om stade og fremdrifts 

information, men også om teknologiske produktforhold, der er vigtige for kundens 

vurdering af produktværdien. Endelig skal projektet erkende at kommunikationen 

til kunden skal være tovejs, og at kommunikationen sikrer projektet fleksibilitet, 

læring og udviklingshastighed. 

”Working Software over comprehensive documentation” tolkes ofte som at der ikke 

side 22 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

skal produceres dokumentation. Dokumenter har deres berettigelse, i det de støtter 

kommunikation, koordinering, for alle repeterbare opgaver og for videndeling. 

Desuden er dokumentation ofte krævet af diverse myndigheder. Det er dog vigtigt 

at forstå, at dokumentation ikke kan erstatte samspil mellem projektdeltagerne 

eller i forholdet til kunden. Dokumentationen skal opfattes som et biprodukt af 

samspillet, hvilket er i overensstemmelse med Stacey's opfattelse af viden [Jensen, 

Mønsted & Olsen]. 

I vores kontekst kan ”Working software” erstattes med ”usable products”, altså 

produkter der giver værdi til kunden. 

3.1.4 Responding to change over following a plan 

Hvis der sker ændringer i projektets omgivelser, der har betydning for kundens 

vurdering af det udviklede produkts værdi, skal dette give anledning til en 

øjeblikkelig revurdering af projektets situation. Da der er en risiko for at ændringer 

i omgivelserne kun registreres af den ene part, er det vigtigt med hyppig og 

kvalitativ god kommunikation med kunden. Formålet er, at sikre det bedste 

beslutningsgrundlag for projektets videre forløb. Det er afgørende at kunden 

deltager i denne beslutning. 

Alle projekter har større eller mindre grad af usikkerhed, se Appendix 4. Derfor skal 

det enkelte projekt finde en balance mellem planlægning og håndtering af 

ændringer. Kravet om denne balance gør også, at hverken venstre eller højre side 

af ”Responding to change over following a plan” er rigtig, men at det afhænger af 

projekttypen. Projektet skal balancere mellem: 

• Explorativ versus plandrevet 

• Problemdefinerende versus rutine 

• Adaption versus forudseenhed 

3.1.5 Opsummering 

I de efterfølgende afsnit vil vi argumentere for, at vores fortolkning af de agile 

værdier kan understøttes ved at: 

• danne organiske, selvorganiserende projektteams, der sammensættes af 

flerfaglige kompetencer 

• anvende den iterative udviklingsmodel, som styrende for udviklingsprocessen 

De efterfølgende afsnit diskuterer den iterative udviklingsmodel og 

side 23 af 94


selvorganiserende teams. 

3.2 Iterativ Udviklingsmodel 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Den iterative udviklingsmodel introducerer et paradigmeskifte i forhold til den 

traditionelle udviklingsmodel. 

Den iterative udviklingsmodel understøtter: 

• projektets fleksibilitet i forhold til ændringer i omgivelserne. 

• hyppig og kvantitativ kommunikation med kunden 

• kontinuert procesforbedring gennem hele projektforløbet 

Formålet med dette afsnit er at argumentere for, at en iterativ udviklingsmodel, i 

forhold til en traditionel udviklingsmodel, fører til: 

• større kundeværdi gennem bedre 

- prioritering af features 

- risikostyring 

• større fleksibilitet (styring af ændringer til produktet) 

Og dermed at iterativ udvikling er et godt bud på en alternativ vej til projektledelse. 

I det efterfølgende afsnit forklares princippet i timeboxed iterativ udvikling. Dette er 

en forudsætning for diskussionen om planlægning og styring, hvor vi diskuterer den 

iterative udviklingsmodel i forhold til vandfaldsmodellen. Der er en mere uddybende 

forklaring i Appendix 1 og Appendix 2. 

3.2.1 Timeboxed iterativ udvikling 

Iterative udviklingsmodeller er karakteriseret ved at kravet om faseopdeling 

frafaldes, og faserne erstattes af en overordnet proces, der består af et antal 

sekventielle iterationer, se Figur 4. 

De tidligere faseknyttede aktiviteter som: analyse, design, implementation osv. 

genfindes i hver iteration. Hver iteration er således et selvstændigt mini-projekt, og 

målet for hver iteration er en produktrelease, der ikke bare er en prototype eller 

lignende, men en delmængde af det færdige produkt. Det vil sige med en kvalitet, 

der kan frigives til og accepteres af brugeren. Der leveres altså mere og mere 

funktionalitet for hver iteration. Hver iteration er typisk af 2 – 8 ugers længde. 

side 24 af 94



Figur 4: Fra vandfald til iterationer [egen tilvirkning] 

INGENIØR 

HØJSKOLEN 

KØBENHAVN 

En undersøgelse af mere end 35.000 IT projekter viser at der er en helt klar 

sammenhæng mellem projektsucces i traditionel forstand og hvor længe projektet 

varer [Standish01]. Jo længere projektet varer jo mindre er sandsynligheden for at 

det bliver en succes, dette forhold indikerer at det er fornuftigt at dele et projekt op 

i et antal iterationer. 

Slutdatoen for en iteration besluttes ved iterationens start og ændres under ingen 

omstændigheder undervejs. Dette princip kaldes timebox. Hvis der opstår 

problemer med at blive færdig til tiden, så bortskæres/udskydes funktionalitet i 

stedet for at ændre på afleveringsdatoen eller på allokerede personer. 

Enhver iteration afsluttes med at projektet laver en produktrelease til kunden. 

Dette giver kunden mulighed for at evaluere produktet samt levere værdifuld 

feedback tilbage til projektet. Projektteamet får også mulighed for at reflektere 

over produktet og arbejdsprocessen. 

Den iterative model skaber således mulighed for løbende planlægning, der er 

værdiskabende for projektet, fordi der hele tiden er fokus på, at forbedre 

arbejdsprocessen og bringe produktet i overensstemmelse med kundens 

side 25 af 94


forventninger. 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Se Appendix 1 og Appendix 2 for mere information om iterative udviklingsmodeller. 

3.2.2 Et paradigmeskifte 

Forsøg ikke at specificere alle krav tidligt i forløbet. Hold i stedet tidspunkt for 

aflevering fast, og tilvælg løbende de features, der leverer størst kundeværdi. 

Der er tradition for, at anskue et projekts frihedsgrader ud fra en styringstrekant. 

Der indgår 3 basale frihedsgrader i styringstrekanten: 

• Pris - timeforbrug, udgifter/indtægter 

• Tid – den tid der afsættes til udviklingsarbejdet 

• Features - Hvor meget og hvor godt, målt efter relevante kvalitetsparametre, 

arbejde der lægges i projektet 

Målet er til enhver tid at skabe en hensigtsmæssig balancetilstand mellem de 3 

frihedsgrader, hvilket i praksis opnås ved at fjerne 1, 2 eller alle 3 frihedsgrader. 

For at muliggøre fleksibilitet i projektet, skal der dog mindst være én frihedsgrad, 

projektet kan justere på. 

Udvikling baseret på vandfaldsmodellen foreskriver, at alle kravene skal specificeres 

i de tidlige faser. Dette svarer til, at fastfryse feature parameteren og kun tillade 

styring på pris og tid. Når alle kravene til funktionaliteten kendes, er det muligt at 

estimere tidsforbrug og omkostninger. Dette er naturligvis ideelt - forudsat kravene 

ikke forandrer sig. For projekter med problemdefinerende opgaver er dette ikke 

tilfældet. Sådanne projekter vil opleve store problemer med at opfylde 

forventningerne til projektets tidsforbrug og budget, baseret på tidlige estimater, 

simpelthen fordi den nødvendige forudsigelighed ikke er til stede. 

Det er netop spørgsmålet om, hvorvidt det overhovedet er ønskeligt at fastfryse 

kravene, i projekter som indeholder problemdefinerende opgaver, der giver afsæt 

til en alternativ fortolkning af styringstrekanten. Figur 5 viser hvorledes 

styringstrekanten vendes på hovedet. Den traditionelle tilgang starter med at 

fastfryse de features, der skal med og derefter estimere tid og pris. Den iterative 

tilgang fastfryser pris og tid (iterationslængde) og bestemmer ud fra dette hvor 

mange features, der kan komme med i iterationen. 

side 26 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Figur 5 Paradigmeskifte - fra vandfald til iterativ udvikling [egen tilvirkning] 

I sådanne projekter er det vanskeligt at vide på forhånd, præcist hvor projektet vil 

ende. At forvalte sådan et projekts dynamiske virkelighed som om den er statisk og 

forudsigelig, er urealistisk, risikabelt og i de fleste tilfælde uproduktivt. Det er 

derimod nødvendigt - og ønskeligt, at projektet kan håndtere frekvente og hyppige 

ændringer af kravene, for der igennem aktivt at sikre risiko eliminering og høj 

værdiskabelse. Ydermere kan en antagelse om, at kundens behov og ønsker ikke 

ændrer sig gennem et sådant projektforløb, synes som en fundamental fejl i 

vandfaldsmodellen. 

Det er disse overvejelser, der ligger til grund for at ændre fokus i 

problemdefinerende projekter - væk fra en vandfaldsmodel. I den iterative 

udviklingsmodel vendes planlægningsstrategien på hovedet, ved at låse 

afleveringstidspunktet og projektbudgettet fast, og i stedet indføre en mere 

fleksibel planlægning omkring udvikling af features. 

3.2.3 Planlægning vandfald- versus iterativ udviklingsmodel 

Hold afleveringstidspunktet fast og styr på funktionalitet. 

Spørg kunden hvilken features, der forventes at give mest værdi og tilvælg 

dem som foretrukne kandidater i næste iteration. Vurder dernæst risici, og 

vælg blandt features kandidaterne dem med størst risiko først. 

Planlægning vil sige at etablere og vedligeholde en plan for aktiviteter og deres 

indbyrdes afhængigheder, der definerer et projekt. Planlægning kan være lineær, 

som ved vandfaldsmodellen, det vil sige den er afsluttet, før udførelsen begynder. 

Den iterative model anvender løbende planlægning. Det vil sige at planlægningen 

side 27 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

fortsætter under hele udførelsen bl.a. på grundlag af regelmæssig feedback fra 

kunden. 

Det vandfaldsbaserede projekt sigter mod at være forudseende og proaktiv i sin 

planlægning - "plan the work". Dette kan give god mening i projekter, der 

behandler rutineproblem- eller problemløsningsopgaver. I vandfaldsperspektivet er 

dette nødvendigt, dels for at sikre allokering af de rette ressourcer på det rette 

tidspunkt i de forskellige faser, og dermed skabe en effektiv ressourceudnyttelse, 

men også for at muliggøre en proaktiv adfærd i forhold til potentielle risici. 

Det er netop karakteristisk ved de problemdefinerende projekter, at det ikke giver 

mening at foretage detaljeret planlægning af alle faser ved projektets start. Dette 

er i bedste fald spild af ressourcer, vel vidende at det informationsgrundlag, man 

optimerer på, er ufuldstændigt eller direkte forkert. Se Figur 6, hvor det fremgår at 

ændringer i omgivelserne medfører, at den kontekstuelle usikkerhed forøges over 

tid. 

Figur 6: Den kontekstuelle usikkerhed over projektforløbet set fra projektstart 

[Christensen & Kreiner, side 43]. 

Det er imidlertid klart, at intet projekt kan undvige kravet og forventningen om, at 

der foreligger en plan for projektet. Om ikke for andet så for at sandsynliggøre 

overfor omgivelserne (interessenterne), at projektet er velovervejet. Det drejer sig 

derfor ikke om, hvorvidt der skal laves tidsplanlægning eller ej, men om hvilket 

side 28 af 94


indhold og sigte projektplanlægningen skal gives. 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

I erkendelse af opgavernes uforudsigelighed udføres den detaljerede planlægning i 

det iterative projekt kun for den aktuelle iteration og ikke for hele projektforløbet. 

Planlægningen af den enkelte iteration indeholder altså stillingtagen til, hvad der 

detaljeret skal laves på kort sigt - men ikke på langt sigt. Her spiller kunden en 

vigtig rolle, fordi projektet vil lave det, der giver mest værdi til kunden på det givne 

tidspunkt - og ikke i forhold til en måske forældet plan. Som tidligere nævnt er det, 

at overholde leveringstid første prioritet – så projektet skal styre på, hvilke features 

der skal med i iterationen. Men hvordan vælges disse? Ved at spørge kunden forud 

for hver iteration! 

Der er undersøgelser, der viser at over 60 % af funktionaliteten i et nyt produkt 

sjældent eller aldrig bliver brugt, se Appendix 6. Dette forhold strider mod 

forventningen om, at der er en lineær sammenhæng mellem mængden af leveret 

funktionalitet og kundetilfredshed. Dette forhold er anskueliggjort i Figur 7. 

Figur 7 Aktuel opfattelse af kundetilfredshed [egen tilvirkning] 

Den iterative planlægning består derfor i at tilvælge de features først, der efter 

kundens vurdering giver mest værdi. 

Men er dette ikke også hvad der sker i vandfaldsmodellens planlægning? Nej - i 

side 29 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

vandfaldsmodellen definition ligger implicit en forudsætning om, at kundens 

forventninger og krav ikke ændres gennem projektforløbet, svarende til der ikke 

sker nogen læring, hverken hos kunden eller i projektet! Og dette er jo i modstrid 

med forudsætningen om, at projektet befinder sig i komplekse og dynamiske 

omgivelser. 

Den anden vigtige parameter der indgår i planlægningen er risici. I traditionel 

risikostyring fokuseres på de største risici først. Iterativ udvikling benytter samme 

tilgang omkring operationelle risici. Sammenfattende vil det sige, at projektet altid 

giver første prioritet til de features, kunden vurderer som mest værdiskabende. 

Dernæst vurderes risiko for disse features, og dem med størst risiko tilvælges først. 

Denne strategi er skitseret i Figur 8. 

Figur 8: Strategi for prioritering af features i den iterative udviklingsmodel [Cohn, 

side 85]. 

Man kan sige, at kunden prioriterer, hvad der skal laves, projektet estimerer, hvor 

lang tid det vil tage, og dermed hvad der kan nås i en iteration, idet tid har prioritet 

over funktionalitet. Dette sker ud fra devisen: Hellere de 80 % vigtigste dele af 

funktionalitet klar på afleveringstidspunktet end 100 % af al funktionalitet som kun 

er 80 % færdig. 

side 30 af 94


3.2.4 Styring - hurtig respons på ændringer 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Levér regelmæssige releases til kunden og evaluér efter hver release 

feedback fra kunden. 

Styring foregår i 2 niveauer: 

• Styr overordnet efter minimering af risici og optimering af kundeværdi. 

• Fasthold afleveringstidspunkt. Styr på features - dvs. fjern features, hvis 

Det er værd at bemærke, at et projekts overordnet mål ikke kun bør være at 

udvikle et produkt. Projektet skal være ansvarligt for at udvikle et produkt som 

kunden kan lide, et produkt der tilfredsstiller kundens behov eller ønsker. Med 

andre ord er det projektets overordnet mål at udvikle et produkt, der skaber værdi 

for kunden - et produkt som er ”det rigtige produkt”. 

Udvikling af det rigtige produkt sker ved at tilføre projektet fleksibilitet. Eftersom 

fleksibilitet forudsætter styring, vil det være naturligt at se kritisk på projektets 

styringsmekanisme. 

Styring, i traditionel forstand, er at sikre, at projektet følger planen. Det vil sige at 

monitorere projektets fremdrift (fx med Performance Measurement, se [Mikkelsen 

& Riis side 430]), og om nødvendigt planlægge og udføre korrigerende handlinger 

for at komme på planen igen. Passende aktioner ved styring kan være en ny 

planlægning. 

de betyder forsinkelse, og adder nye features, hvis projektet kommer 

foran plan. 

I den iterative model styres der først og fremmest efter risiko og kundeværdi. 

Styringsmålet er, at levere maksimal værdi til kunden samtidig med at høj-risici 

faktorer elimineres, så tidligt som muligt, se Appendix 1, Figur 22. Dette er ikke 

væsensforskelligt fra, hvad man gør i projekter baseret på vandsfaldsmodellen, 

men midlerne adskiller sig i nogen grad, og evnen til at respondere hurtigt er 

meget forskellig. 

I det vandfaldsbaserede projekt elimineres risici ved at være forudseende og tidligt 

planlægge proaktiv adfærd. Midlet til at sikre maksimal kundeværdi, er ved at 

definere alle krav tidligt i projektets faser. Disse aktiviteter danner grundlaget for 

planlægningen, der efterfølgende styres efter - "work the plan". Forandringer er 

grundlæggende uønskede, men behandles typisk af et Change Control Board, der 

side 31 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

vurderer konsekvenserne af ændringerne inden ændringerne godkendes. 

Denne mekanisme kan imidlertid være ufleksibel og langsommelig og derfor uegnet 

til projekter i dynamiske omgivelser og med mange opgaver, hvor der må forventes 

mange ændringer. Den er ufleksibel fordi behandling af ændringer, der reelt har 

betydning, ofte kræver en tilbagevending til tidligere projektfaser, med de 

konsekvenser det nu engang har omkring genforhandling af krav og 

kontraktforhold, re-allokering af ressourcer osv. Det siger sig selv, at ændringer i 

for eksempel testfasen vil gennemgå en langsommelig proces, inden de når ud til 

kunden i form af et færdigt produkt. Og netop derfor gør kunden meget for at sikre 

sig, at det bliver lavet rigtigt første gang, hvilket ofte betyder en forstærket indsats 

i definitionsfasen - og sådan kører den onde cirkel. 

Netop omkring styring leverer den iterative udviklingsmodel nogle gode svar: - tag 

små skridt ad gangen! Acceptér at der kræves fornyet planlægning efter hvert 

skridt. Figur 9 illustrerer styringen i den iterative udviklingsmodel. Den blå streg 

viser projektets aktuelle forløb mod målet i iterationer, den røde streg viser, 

hvordan kundens forventninger, ændrer sig gennem tid. Forskellen mellem den 

røde og den blå streg indikerer forskellen mellem hvad projektet har leveret og 

kundens ønske på et givet tidspunkt. Det skal bemærkes, at Figur 9 er af 

pædagogisk karakter - fx er det ikke givet, at kundens forventninger er en 

kontinuert funktion af tiden. 

Figur 9 Styring i iterativ udviklingsmodel [egen tilvirkning] 

Styring i den iterative udviklingsmodel adskiller sig fra styring i vandfaldsmodellen, 

side 32 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

hvor forandring grundlæggende er uønsket. I vandfaldsmodellen sker styring 

gennem planlægning af korrigerende handling, og har til formål at bringe projektet 

tilbage på den oprindelige plan. Figur 10 illustrerer styringen i vandfaldsprojektet, 

den røde streg viser den planlagte vej til målet, og den blå streg hvordan projektet 

nogle gange kommer på afveje, for så at blive trukket på sporet igen med en 

korrigerende handling. 

Figur 10 Styring i vandfaldsmodellen [egen tilvirkning] 

I den iterative udviklingsmodel betyder regelmæssig opgaveprioritering sammen 

med kunden, sammenholdt med konstruktiv, regelmæssig feedback, at projektet 

kun løber en begrænset risiko for at komme på afveje (arbejdet i 1 iteration). Dette 

står i skarp kontrast til det vandfaldsbaserede projekt, der risikerer at have fjernet 

sig langt fra kundernes oprindelige ønsker, når projektet er færdigt. I 

vandfaldsmodellen forsøger projektet tidligt at fjerne alle usikkerheder omkring, 

hvad der skal laves, og hvordan det skal laves. Operationelle risici søges reduceret 

ved at undgå problemdefinerende opgaver, samt ved at sikre flere 

rutineproblemopgaver end problemløsningsopgaver i projektet. Det iterative projekt 

forholder sig derimod kun til de helt aktuelle høj-risici og udskyder håndtering af 

andre mulige risici, indtil mere information er til rådighed - "Make what the 

customer wants!", se Figur 11. 

side 33 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Figur 11: Forskellig håndtering af usikkerheder på HVAD og HVORDAN i 

henholdsvis vandfalds- og iterativtprojekt [Cohn]. 

Som det fremgår af Figur 11 reducerer vandfaldstilgangen løbende usikkerheden 

om HVORDAN produktet skal laves, mens al usikkerhed om HVAD, der skal laves 

forsøges elimineret ved projektstart. Analyse handler om at definere, hvad der skal 

laves og design handler om, hvordan det skal laves. At fjerne al usikkerhed på både 

HVORDAN og HVAD ved projektopstart er umuligt. Den iterative tilgang forsøger 

ikke at eliminere usikkerheden om HVAD der skal laves ved projektopstart. Til 

gengæld vil projektet løbende og på baggrund af kunde feedback definere, hvad 

der skal laves. Samtidig vil projektet også lære mere om hvordan produktet skal 

laves. Denne linie er ikke tegnet lineær, netop for at indikere det vigtige i først at 

udvikle de features, som bedst giver os mulighed for at få ”Working software” ud til 

kunden. Dermed reduceres risikoen omkring det at lave det rigtige produkt. 

En konsekvens af den iterative udviklingsmodel er, at projektteamet, gennem hele 

projektforløbet, skal være mere bredt sammensat kompetencemæssigt. Dette er en 

nødvendighed, for at projektet kan release brugbar funktionalitet i hver iteration. 

Men det betyder også, at projektteamet hele tiden besidder de kompetencer, der 

kræves for at reagere på de aktuelle ændringer (kundeønsker eller problemer), og 

dermed er i stand til at agere hurtigt. En anden fordel er, at det er muligt at 

allokere mange ressourcer samtidig på projektet og dermed skabe hurtig fremdrift. 

En ulempe er dog, at det kan blive sværere at starte mange projekter op i parallel, 

fordi det er svært at frigøre ressourcer fra projektet, før det er helt færdigt. 

Der er en risiko for at kundens direkte indflydelse på release indhold for de enkelte 

iterationer release indhold kan medføre en kaotisk målstyring, idet hyppige 

side 34 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

kursændringer kan medføre projektet aldrig bliver færdigt. Der er derfor behov for, 

at projektet balancerer mellem åbenhed overfor ændringer i omgivelserne og målet 

om at blive færdig til tiden. For projektlederen betyder dette i praksis en 

kontinuerlig vekslen mellem kontekstuel og operationel risikostyring. 

Vi har tidligere nævnt, at der er sket et skifte i retning af, at projekterne i dag 

indeholder flere opgaver af problemdefinerende karakter end tidligere. Baseret på 

diskussionen ovenfor betyder dette, at projektlederen i højere grad har behov for at 

kunne reducere den kontekstuelle usikkerhed, der knytter sig til projektopgaverne, 

og samtidig kunne acceptere en høj operationel usikkerhed. Noget kan tyde på, at 

håndteringen af kontekstuel og operationel usikkerhed fordrer vidt forskellige 

projektledelsestilgange. 

Med fokus på en løbende målstyring mod levering af ”det rigtige produkt”, bliver 

læring et helt centralt element, der får afgørende betydning for projektets succes. I 

det vandfaldsbaserede projekt kan styring gennem korrigerende handling ses som 

single loop læring, idet der ikke stilles spørgsmål ved det oprindeligt formulerede 

mål, og den oprindelige plan fastholdes som målstyrende [Jacobsen & Thorsvik, side 

340]. Med den iterative udviklingsmodel er hensigten, at bevæge sig fra single loop 

læring til double- og triple loop læring, idet der ved hver iteration stilles spørgsmål 

til, om målet stadig er det samme som ved sidste iteration [Jacobsen & Thorsvik, side 

340]. Dette sker gennem spørgsmål til HVAD der skal laves og HVORDAN. 

3.3 Projektorganisation 

De dynamiske omgivelser og den komplekse teknologi, projekter oplever i dag, 

håndteres bedst med en organiske struktur, der støttes af en decentraliseret 

magt deling og gensidig tilpasning som koordineringsmekanisme. 

I afsnit 2 har vi tidligere argumenteret for, at produktudviklingsprojekterne er 

skiftet i retning mod udvikling af mere højteknologiske og videnstunge produkter, 

der kræver højteknologisk kompetence. Deri ligger at nye produkter i stigende grad 

er mere komplicerede at udvikle og med begrænset mulighed for genbrug. Ifølge 

definition fra [Mintzberg], betyder dette, at denne type projekter befinder sig i 

dynamiske og komplekse omgivelser. 

I følge [Jacobsen & Thorsvik, side 205] skal en organisation løbende forsøge, at 

side 35 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

ændre sin struktur så den matcher de opgaver den skal løse. De opgaver, der skal 

løses i projektets kontekst, er direkte koblet til kunden, eller til ny teknologi. 

Projektorganisationen skal derfor tilpasse sin struktur til at håndtere læring fra 

kunden samt ny teknologiudnyttelse. I denne sammenhæng er spørgsmålet derfor, 

- hvilken struktur er den optimale? [Mintzberg] angiver sammenhængen mellem 

struktur og Komplekse/Enkle samt Stabile/Dynamiske omgivelser som vist i Tabel 1. 

Omgivelser 

Stabile Dynamiske 

Professionel Organisation: 

Bureaukratisk 

organisation 

Vertikal og horisontal 

decentraliseret 

Standardisering af 

viden og færdigheder 

Maskinbureaukrati: 

Centraliseret 

bureaukratisk 

organisation. 

Med begrænset 

horisontal 

decentralisering 

Standardisering af 

arbejdsopgave og 

resultater 

Ad Hoc Krati: 

Organisk organisation 

Decentraliseret 

organisation 

Gensidig tilpasning 

Organisation: 

Organisk organisation 

Vertikal og horisontal 

centraliseret 

Direkte tilsyn 

Tabel 1 Organisationstype relateret til organisationens omgivelser [Mintzberg] 

Af Tabel 1 fremgår det, at når projektet befinder sig i dynamiske og komplekse 

omgivelser, er den mest optimale strukturtilpasning karakteriseret ved en organisk 

organisation. Samtidig er den decentraliserede organisation med gensidig tilpasning 

som koordineringsmekanisme, den bedst egnede til at håndtere (= vurdere, 

beslutte og implementere) komplekse teknologier. 

3.3.1 Organisk organisation 

Organisér projektet med en organisk struktur. Sammensæt et team med 

flerfaglige kompetencer så de matcher opgaven. De nødvendige kompetencer 

for at løse opgaven skal samles både i tid og rum. Derved skabes en effektiv, 

fleksibel og hurtig projektorganisation. 

En organisk organisation er, i modsætning til den bureaukratiske, fleksibel og åben 

side 36 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

overfor input fra omgivelserne. Den organiske organisation har minimum af hierarki 

og specialisering af funktioner. For at en organisation er ægte organisk, kræves 

det, at alle er på samme niveau, uden egentlige jobbeskrivelser, og med en flad 

netværkslignende kommunikation, med interaktion på tværs af formelle grænser, 

se Figur 12. Al planlægning og kontrol foregår decentralt, og endvidere er der ingen 

pre-definerede rigide processer. Den organiske organisation er et fleksibelt netværk 

af ikke-specialiserede individer. 

Figur 12 Eksempler på traditionel bureaukratisk og organisk organisationsform i 

hub [egen tilvirkning]. 

Der er selvfølgelig et kontinuum mellem den bureaukratiske og den organiske 

organisation. Den mest egnede struktur ligger et eller andet sted imellem de to. 

Det vi kan sige er, at udviklingen af mere dynamiske og komplekse omgivelser 

peger i retning af, at der i fremtiden bliver behov for at projektteamet organiserer 

sig i mere organisk retning. 

En bureaukratisk organisationsstruktur har, ifølge Mintzberg, vanskeligere ved at 

tilpasse sig til de ændringer, der finder sted i omgivelserne [Jacobsen & Thorsvik, 

side 106]. Dette mener vi, kan henføres til bureaukratiet krav om klare 

ansvarsforhold, forudsigelighed og standardisering i bestræbelsen på at skabe 

effektivitet. Dette kan risikere at ske på bekostning af refleksion, læring og 

motivation, i dét det kan blive et mål i sig selv blot at følge reglerne. Der er en 

betydelig risiko for at projektet ikke får udnyttet den kompetence og viden, 

projektdeltagerne har, og som kunne være relevant for opgaveløsningen. I den 

bureaukratiske organisationsstruktur kan opgaverelevant kompetence og viden 

side 37 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

også findes hos personer, der ikke er en del af projektteamet. Dette kan fx være 

produktejer, marketing eller salg, hvor organisationsstrukturen introducerer en 

barriere i forhold til, at projektteamet kan få adgang til deres viden og kompetence. 

En sådan organisation kan derfor få problemer med hastighed og effektivitet i 

dynamiske omgivelser. Hvis organisationen kun langsomt kan tilpasse sig 

ændringer i omgivelserne, kan resultatet derfor blive, at projektorganisationen 

bliver overvejende fastlåst og ufleksibel. Derved kan projektet have svært ved, at 

udvikle de rigtige produkter på det rigtige tidspunkt. 

En organisk og flerfaglig projektorganisation kan derimod bedre reagere og agere 

fleksibelt på ændringer i omgivelserne. Når magten, og dermed indflydelsen på 

opgaveløsningen, placeres hos det fagligt kompetente projektteam, øger det 

muligheden for handlekraft og dermed understøttes beslutningsevnen. Når de 

nødvendige kompetencer er samlet i projektteamet, og de selv har den direkte 

kundekontakt, bliver kommunikationsvejene kortere, og kommunikationen dermed 

mere effektiv. Den decentraliserede magt og den effektive kommunikation er begge 

med til at understøtte projektets fleksibilitet i forhold til omgivelserne. 

3.3.2 Gensidig tilpasning som koordineringsmekanisme 

Gensidig tilpasning er en effektiv koordineringsmekanisme for mindre teams 



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

følge op på deres ideer, og selv definerer deres arbejdsmetoder og opgaver. I 

denne situation kan gensidig tilpasning være en effektiv koordineringsmekanisme. 

Organisationsteorien [Jacobsen & Thorsvik, side 80] siger, at gensidig tilpasning 

som koordineringsmekanisme kun kan anvendes i meget overskuelige situationer. 

Det vil sige for projektteams med fx 10+ personer er det tvivlsomt at alle kan følge 

med i, hvad de andre gør. Der er derfor behov for en løbende vurdering af, hvor 

gensidig tilpasning vil have størst effekt, og eventuelt understøtte effekten ved en 

passende fysisk placering af projektdeltagerne. Der har været en del debat om, 

hvor mange personer man kan sætte sammen og stadig opnå effektivitet. Åbne 

kontormiljøer er meget almindelig i nye byggerier i dag, men effekten af dem har 

været blandet. Højt støjniveau og forstyrrelser kan være et problem, og indikerer at 

det er vigtigt, at diskutere fordele og ulemper med projektdeltagerne. 

Når gensidig tilpasning virker, er det en effektiv form for koordinering, idet de 

enkelte personer automatisk tilpasser deres adfærd til den adfærd, der udvises af 

dem de er afhængige af. I den iterative tilgang er der tilstræbt overskuelige 

situationer ved at nedbryde projektopgaverne i mindre og dermed mere 

overskuelige delopgaver. Derved kan gensidig tilpasning udnyttes til at opnå hurtig 

og uformel koordinering. De enkelte teammedlemmer arbejder sammen, og 

koordinerer deres handlinger for at udføre opgaverne bedste muligt. 

3.4 Selv-organiserende projekt teams 

Det primære mål for det selv-organiserede team er, at opnå handlekraft og 

beslutningsevne og derigennem skabe manøvredygtighed i forhold til HVAD der 

skal laves og HVORDAN det laves. 

Globaliseringen har betydet, at information som ressource er mængdemæssigt 

eksploderet. Digitaliseringen har muliggjort, at information er blevet uafhængig af 

tid og sted. Samtidig oplever vi en til stadighed stigende forandringstakt i 

samfundet og verden, og dette medfører at antallet af beslutninger, der skal tages 

vokser, og tiden til at tage den enkelte beslutning formindskes. Det betyder alt 

andet lige, at der kræves flere beslutningstagere, hvis beslutningskadencen skal 

opretholdes og beslutninger kvalificeres på baggrund af information og viden. 

Det er i denne kontekst vi ser det selv-organiserede team som en mulig vej til at 

opnå mere handlekraft og beslutningsevne, og dermed skabe et mere 

side 39 af 94


manøvredygtigt projektteam. 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

En projektorganisation kan agere hurtigt og fleksibelt, når magten er 

decentraliseret [Jacobsen & Thorsvik, side 87]. Dette opnår vi i det agile projekt, 

ved at danne organiske, selvorganiserende teams sammensat af personer, hvis 

kompetencer dækker de relevante faglige områder. 

Dette medfører samtidig, at der er mulighed for at beslutningerne træffes af de 

mest kompetente personer inden for et givet område. Derved øges effektiviteten og 

kvaliteten af de trufne beslutninger. Ifølge [Jacobsen & Thorsvik, side 259] 

fremmer selvorganiserende teams innovation og nytænkning. 

3.4.1 Hvad er handlekraft? 

Handlekraftig adfærd understøttes, hvis en beslutning og de afledte 

konsekvenser er synlige for beslutningstageren. 

Fleksibilitet og manøvredygtighed fordrer bl.a. handlekraft og beslutningsevne. Men 

kan vi styrke dette gennem strukturelle ændringer? 

Bag ønsket om det selvorganiserende team ligger en tro på, at dette i 

produktudviklingsregi vil føre til den bedste løsning. Rationalet er, at hvis 

projektdeltagerne oplever sammenhæng i udviklingsopgaven, sådan at opgaven er 

begribelig, håndterbar og meningsfuld, vil de træffe de beslutninger og vælge de 

løsninger, der leverer den største værdi til kunden. Udover en god kontakt til 

kunden fordrer dette naturligvis, at projektdeltageren selv har kontrol over og 

indflydelse på kritiske og afgørende faktorer omkring projektteamets opgaver. 

Hvis projektteamet har en direkte kommunikation med kunden, mærker de også 

direkte konsekvenserne af deres beslutninger. Læringsteori hævder eftertrykkeligt, 

at det der former menneskelig adfærd, er deres forventninger til, hvilke 

konsekvenser, der er forbundet med adfærden [Jacobsen & Thorsvik side 335]. 

Det er svært at se, at det er muligt at agere handlekraftigt uden at være motiveret. 

Motivationen bliver dermed en helt central størrelse i relation til projektets succes, - 

altså projektets mulighed for at producere ”det rigtige produkt”. 

side 40 af 94


3.4.2 Handlekraft forudsætter motivation 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Motivation knytter sig til oplevelse af meningsfuldhed i jobbet, det at have 

indflydelse på, hvordan opgaven løses og dermed følelse af ejerskab og ansvar 

for resultat, samt adgang til information om resultatet af eget arbejde. 

Med udgangspunkt i motivationsteorien vil vi argumentere for, at det 

selvorganiserende team i højere grad understøtter motivationsdannelsen end den 

traditionelle projektorganisation. 

De underliggende afsnit tager hver især udgangspunkt i de kritiske psykologiske 

tilstande som Hackman & Oldham’s motivationsmodel fremhæver som afgørende 

for opnåelse af gode resultater [Jacobsen & Thorsvik, side 254]. Den følgende 

diskussion anskuer det flerfaglige team i forhold til en traditionel 

projektorganisation. 

3.4.2.1 Meningsfuldhed i jobbet 

Hackman & Oldham påpeger vigtigheden i, at arbejdsopgaverne stiller varierede 

krav til evner og færdigheder. Den gunstige motivation opnås, når personen har 

viden og færdigheder, der er relevante for de aktuelle arbejdsopgaver. Hackman & 

Oldham nævner 3 særlige kendetegn ved oplevelsen af meningsfuldhed i jobbet: 

• Variation i viden: Kravet til variation opfyldes ved den måde samarbejdet i 

flerfaglige teams sker på, se afsnit 3.5. Det enkelte teammedlem får i teamet 

mulighed for at bevare og udbygge sin faglige kompetence, ved at overskride 

faggrænser og kombinere den eksisterende viden med den ny viden, som 

indsigt i andre fag giver. Endvidere er der større spillerum med hensyn til at 

fordele arbejdsopgaverne. Den direkte kontakt med kunden synliggør 

forventninger og værdier langt bedre, og er med til at bibringe en bedre 

forståelse af opgavens betydning. Ikke mindst får teamet en langt stærkere 

oplevelse af, hvordan produktet bliver brugt – og om det bliver brugt! Ifølge 

teorien styrker dette motivationen, enten direkte positivt eller som 

energiskabende retningsgiver. Derved opnås bedre muligheder for at forfølge 

det, der giver kunden mest værdi. 

• Identifikation med opgaven: Identifikation med opgaven styrkes ved, at 

teamet involverer alle fagdisciplinerne og arbejder med en vertikal 

side 41 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

udviklingsstrategi. Dermed har teamet ansvaret for at udvikle en hel feature. 

Og ikke kun en usynlig delmængde af det samlede produkt. Den personlige 

indstilling til arbejdet kan give vidt forskellig grader af identifikation med 

arbejdet. Dette illustreres med den gamle historie om de 3 stenhuggere, se 

Figur 13. 

Figur 13 Historien om de 3 stenhuggere [www.poppendieck.com] 

Den direkte kontakt og tilbagemelding fra kunden er også med til at sikre 

helhedsopfattelsen, og skabe overblik. 

• Opgavens betydning: Her tænkes på oplevelsen af, at opgaven har 

betydning for omgivelserne, fx kunden. Dette sikres især ved, at teamet selv 

har den direkte kontakt til kunden. Derigennem opnås den direkte 

tilbagemelding om, hvad der giver kunden værdi, og hvad der bør prioriteres. 

Den høje grad af selvstyring kræver høj kompetence, idet det kræver faglig indsigt 

og overblik at træffe de rigtige valg. Det rejser spørgsmål om, hvorvidt fx 

nyuddannede vil kunne fungere optimalt i selvorganiserende teams, og i givet fald, 

hvordan de integreres. Mangel på kompetence kan have direkte uønskede effekter, 

som fx destruktive konflikter, fordi der kan herske tvivl om, hvorledes den nye 

viden tilvejebringes og kombineres. Et mere fatalt resultat kan være at opgaverne 

ikke bliver løst. 

side 42 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Omprioritering ud fra værdi-vurdering kan også skabe konflikt i forhold til de 

projektdeltagere, der skal fra- eller tilvælge nye opgaver. 

3.4.2.2 Ansvar for resultat 

Ifølge Hackman & Oldham [Jacobsen & Thorsvik] er oplevelsen af ansvar for 

resultatet også vigtig for motivationen. Igen spiller valget af selvorganiserende 

teams en vigtig rolle. Den selvorganiserende samarbejdsform betyder, at 

metodevalg med videre er løst defineret. Det enkelte team har stor frihed til selv at 

definere opgaverne. Løsningerne vælges og tilpasses ud fra de givne teknologiske 

muligheder og kundens ønsker. Det kræver, at teamets adfærd er styret af 

initiativer og nygerrighed. Teamets opgave med selv at vælge metoder og 

teknologi, opsøge den nødvendige viden, samt etablere tæt kontakt til kunden og 

have ansvar for kundesupport, styrker oplevelsen af ansvar for resultatet. Når 

projektdeltagerne selv tager ansvaret for valg af løsning, mister de samtidig 

"retten" til at kritisere beslutningerne. Det kan forklare, hvorfor nogle ikke er så 

ivrige efter indgå i selvorganiserende teams. 

3.4.2.3 kendskabet til resultatet af eget arbejde 

Den sidste faktor, der ifølge Hackman & Oldham [Jacobsen & Thorsvik] er vigtig for 

motivationen, er kendskab til resultaterne af ens eget udførte arbejde. Den ny 

organisations svar på det, er at de flerfaglige team selv danner grænseflade til de 

omgivelser, der kan levere nødvendig information eller give feedback. Teamet 

agerer direkte med kunden, hvilket giver kontant og hurtig oplevelse af, hvordan 

produkt resultatet fungerer. Endvidere arbejder teamet med en vertikal 

udviklingsstrategi, og det bidrager til helhedsopfattelsen og overblikket. 

side 43 af 94


3.5 Videndeling i flerfaglige teams 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Undgå faglige siloer – etablér team med flere faglige kompetencer og opnå 

bedre deling af eksisterende viden og skabelsen af ny viden. 

Facilitér etablering af relationer i teamet, og skab der igennem bedre deling af 

tavs viden og få et mere effektivt og produktivt team. 

Skab mere effektiv kommunikation ved at udnytte de korte 

kommunikationsveje, der karakteriserer de flerfaglige teams. 

Den måde projektopgaver opdeles på følger organisationens struktur. I det 

traditionelle projekt, organiseret efter funktionelle søjler, har dette som 

konsekvens, at personer i samme projektteam ofte er placeret fysisk adskilt. 

Dokumentationen opfylder her et koordineringsbehov på tværs af funktionssøjlerne, 

se Tabel 2. 

Dokumentation har også til opgave, at reducere virksomhedens følsomhed overfor 

personaleudskiftninger. Dette kan henføres til Taylor's tanker om effektivisering 

[Bakka & Fivelsdal]. Ifølge Taylor skulle alle opgaver nedbrydes til enkle opgaver, der 

var veldefinerede og som kunne dokumenteres. Derved opnåede virksomheden stor 

fleksibilitet i forhold til oplæring af nye medarbejdere. 

Denne tankegang kendes også i dag fra fx kvalitetsstyringssystemer (QMS), der er 

den klassiske mekanisme til at dele "Best Practice". QMS administrations 

procedurerne kan imidlertid opleves som en barriere i dynamiske domæner, 

karakteriseret ved hurtige og frekvente gennemløb af SEKI-modellen [Jensen, 

Mønsted & Olsen, side 38]. Her vil QMS kunne opleves som et "langsomt" medie, 

og ikke blive brugt til deling af information, simpelthen fordi informationen hurtigt 

forældes. Et andet karakteristisk forhold ved informationen i QMS er, at den 

sædvanligvis er på kodet form som fx proces- og procedurebeskrivelser, skabeloner 

og checklister. Det er ikke al information, der egner sig til denne form for 

kodificering. Som en konsekvens heraf er en del viden forbeholdt de få, fordi den 

ligger som uformel projektdokumentation, og dermed ikke er kollektivt tilgængelig. 

Sloan og Læringsteorien påpeger, at der eksisterer en konflikt mellem på den ene 

side procedurer og regler, der har til formål at harmonisere og stabilisere adfærden, 

og på den anden side læringsbehovet, der fordrer ny adfærd. Af hensyn til 

effektiviteten bør opmærksomheden være koncentreret om at sikre, at regler 

side 44 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

anvendes og procedurer følges. Men dette betyder, at der fokuseres mere på at 

gøre tingene rigtigt, frem for at ændre adfærd og gøre de rigtige ting. Formalismen 

leder således systematisk opmærksomheden væk fra påvirkninger, der kunne have 

tilført organisationen den nødvendige nye læring, der skulle til for at ændre adfærd 

[Jacobsen & Thorsvik, Sloan side 71, Læringsteorien side 349]. 

Tabel 2 viser koblingen mellem videnstyper og forskellige strategier til at dele den 

viden projektet har, samt forslag til strategier for, hvordan projektet kan skabe ny 

viden. 

Vi ved 

Vi ved ikke 

at Vi ved 

Explicit 

viden 

Strategi: 

Dokumentation 

Tavs viden 

Skjult viden 

Strategi: 

Videndeling 

at Vi ved ikke 

Oplyst 

uvidenhed 

Strategi: 

Risikostyring 

Uvidenhed 

Strategi: 

Udforskning 

Tabel 2 Videnmatrix tilpasset fra [Jensen, Mønsted & Olsen, side 32] 

Der er forskellige grunde til, at vi gerne vil gøre op med den traditionelle måde at 

dele viden på. Undersøgelser har vist, at op mod 90 % af den samlede generelle 

viden er repræsenteret som tavs viden, se Tabel 2. Dette taler for, at der skal 

fokuseres på at dele den tavse viden [Holdt Christensen, side 105]. Mere detaljeret 

diskussion om viden og vidensformer findes i Appendix 7. 

En anden væsentlig grund er, at den hastighed, hvormed der sker ændringer i 

projektets omgivelser, er stærkt voksende som følge af globaliseringen, og deraf 

opstår et voksende behov for, at projektteamet kan præstere en hurtig fleksibel 

adfærd. 

En tredje grund er, at dokumentation kan hæmme effektiviteten i projektteamet. 

Når projektopgaverne er delt imellem personer, der sidder adskilt i forskellige 

side 45 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

funktionelle søjler, kan dokumentationen manifestere sig som en kontrakt mellem 

de forskellige grupper. Ved uenighed skaber dette ofte diskussioner om, hvem der 

har ansvaret for fejlen, i stedet for at løse problemet. 

3.5.1 Deling af tavs viden i flerfaglige teams 

De efterfølgende afsnit er struktureret efter nogle af de faktorer, Davenport og 

Prusak's påpeger virker som barrierer for videnoverførelse [Jensen, Mønsted & 

Olsen, side 50]. Vi argumenterer for, at flerfaglige teams skaber mulighed for at 

nedbryde disse barrierer. 

3.5.1.1 Mangel på tillid 

Mangel på tillid mellem mennesker er en af de største barrierer for videndeling. 

Skab derfor gode vilkår for at tillidsfulde relationer kan udvikles mellem 

projektdeltagerne. 

Hvis projektdeltagerne kan skabe tillid til hinanden, har de et stærkere grundlag for 

at udforske og udfordre hinandens viden og "ikke-viden" områder gennem 

samarbejde [Darsø]. Tilliden til, at den anden part ønsker at forstå, imødekomme 

og hjælpe en, giver dem modet til i højere grad at erkende egen fejl og eksponere 

manglende indsigt og viden. Tillidskabende aktiviteter vil derfor forøge muligheden 

for at dele tavs viden. 

Hvis vi skal forholde os til, hvilke aktiviteter, der kan være fremmende for 

tillidsskabelsen, må vi fortolke begrebet tillid: 

Tillid opleves når man: 

• kan være sikker i sin forventning til hinandens opførsel og intentioner 

• udviser hjælpsomhed overfor hinanden og værdsætter andres bidrag til 

teamet 

• føler tryghed nok til at turde være åben omkring fejl, svagheder og 

frygt, såvel omkring kompetencer, styrker og præstationer 

De strukturelle ændringer, vi tidligere har diskuteret, danner rammerne for at tillid 

kan udvikles, men dette er ikke nok i sig selv. Fortolkningen af tillid som begreb 

peger på, at tillid er koblet til kulturen i projektteamet. Her spiller projektlederen en 

side 46 af 94


vigtig rolle for at sikre dannelse af tillid mellem projektdeltagerne. 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Den mest værdiskabende videnstype er medarbejderens tavse viden [Petersen & 

Østergaard]. Tavs viden hænger sammen med praksis læring. Projektlederen kan 

udvikle og kollektivisere denne videnstype ved at støtte indførelsen af forskellige 

tillidskabende aktiviteter. Et eksempel på en sådan aktivitet er parvis 

opgaveløsning, der er karakteriseret ved det direkte personlige møde. Ifølge 

Davenport og Prusak [Jensen, Mønsted & Olsen, side 50] skaber det direkte 

personlige møde netop kontakt og tillid mellem deltagerne. 

I og med op mod 90 % af den generelle viden er tavs viden, må der fordres andre 

rammer, end fx dokumenter, til at vurdere og inkorporere ny viden og erfaring. 

Stacey peger på, at viden knytter sig til relationer mellem mennesker [Jensen, 

Mønsted & Olsen, side 68]. For at opnå videndeling skal der dannes gode relationer 

mellem projektdeltagerne og på tværs af faglige grænser. Gode relationer fordrer, 

at der eksisterer tillid mellem parterne. Tillidsskabelsen kan styrkes, ved at placere 

projektdeltagerne fysisk sammen. Derved øges sandsynligheden for, at de lærer 

hinanden godt at kende - i rette tid. 

Den ene side af problematikken er altså, at de faktiske instrumentelle rammer ikke 

må modvirke muligheden for at opbygge tillid. Den anden side er, at team 

medlemmerne skal være villige til at opbygge tillid og indgå i tillidsdannende 

relationer. Den personlige indstilling er altså en væsentlig parameter, når der skal 

etableres samarbejde, og her spiller projektlederen en rolle omkring udviklingen af 

de rette kulturværdier. 

3.5.1.2 Forskellig kultur, begrebsverden og referenceramme 

Undgå videnskliker - sammensæt flerfaglige kompetencer i samme team. Det 

skaber bedre betingelser for at sprede den eksisterende viden samt at skabe ny 

viden. 

Det der ofte binder mennesker sammen på arbejdspladsen, er de fælles værdier og 

de holdninger, der karakteriserer virksomhedens succesgrundlag. Organisationen er 

med til at fastlægge den begrebsverden og det fagsprog, projektteamet benytter 

sig af. Når projektteamet deler viden, er kulturen, begrebsverdenen og 

referencerammerne med til at fastholde dem, så de ofte deler viden med de samme 

personer. Når de søger viden, afgrænser de sig således ofte til dem, der fysisk eller 

side 47 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

fagligt sidder nærmest. Dermed dannes der videnskliker, det vil sige, det er den 

samme gruppe af personer, der i en eller grad deler den viden de altid har delt. Ved 

at sammensætte flerfaglige kompetencer i projektteamet, modvirkes dannelsen af 

videnskliker [Holdt Christensen, side 20]. 

Flerfaglige projektteams vil også kunne øge muligheden for at generere ny viden. 

De forskellige faglige kompetencer i projektteamet er ikke belastet af de andre fags 

professionalisme, og kan netop derfor tillade sig at stille de ”dumme spørgsmål”. 

Muligheden for dannelse af nye relationer kombineret med modet til at stille de 

”dumme spørgsmål” er vigtig for skabelse af ny viden [Darsø]. Det bør dog noteres, 

at for mange spørgsmål til eksisterende beslutninger kan trække momentum ud af 

projektet. 

Personer, der er ansvarlige for udvikling af en given feature, bør placeres i samme 

rum. Herved øges chancen for at uenighed i relation til udvikling af produktet bliver 

synligt og adresseret i gruppen. 

3.5.1.3 Mangel på tid og lejlighed til at mødes 

Skab tid og lejlighed til at de forskellige projektkompetencer kan mødes. Placer 

dem i samme rum og understøt derigennem det uformelle møde - det er 

gavnligt for videndelingsprocessen. 

Når behovet for viden er mest akut gør vi os mindst umage for at finde den. Det er 

et paradoks som også Lotte Darsø peger på [Darsø] citat: "den virkelige 

effektivisering består i at give medarbejderne mere tid til relationsdannelse, fordi 

videndeling netop udebliver, når medarbejderen presses til kun at passe sit eget". 

Mangel på tid og lejlighed er altså en væsentlig strukturel forhindring for at dele 

den tavse viden. Der skal tid til den kollegiale oplæring, samt tid til at dele viden. 

Projektorganisationens bidrag til videndeling består i at skabe de strukturelle 

rammer. I det agile projekt opnår vi dette, ved at placere de forskellige faglige 

kompetencer i samme rum. En effektiv måde at få del i andres viden er gennem 

samværet med andre. Lejlighed til at mødes understøttes også ved, fx at opstille 

whiteboards i teamets fællesområde. 

side 48 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Figur 14 Båndbredde ved forskellige typer kommunikation tilpasset og oversat til 

dansk fra [Cockburn] 

Figur 14 indikerer, at whiteboard er en af de vigtigste kommunikationsformer, når 

der er behov for stor effektivitet. 

Med brug af hyppige releases til kunden, understøttes også lejligheden til at møde 

kunden. Dette sker gennem det The Agile Manifesto betegner som "working 

software" og som vi kalder "brugbart produkt" i Figur 14. Hyppige leverancer styrker 

i betydelig grad kundens mulighed for at forholde sig til produktets funktionalitet og 

værdi. Det, at kunden får et fungerende produkt i hænderne, forbedrer muligheden 

for at give effektiv feedback til projektteamet - helt i tråd med ordsproget: Jeg 

hører - Jeg glemmer. Jeg ser - Jeg husker. Jeg gør - Jeg forstår (kinesisk ordsprog 

- Kungfutse). 

De strukturelle rammer kan dog ikke alene sikre videndeling. Projektlederen skal 

skabe legitimitet og accept af det sociale samvær, som en vej til at kollektivisere 

medarbejdernes viden. Han kan også understøtte videndeling på anden måde, fx 

ved at facilitere udviklingen af den ønskede kommunikationsform, påvirke mødestil, 

fejre succeser osv. 

side 49 af 94


3.5.1.4 Status og belønning går til ejere af viden 

Understøt dannelse af sociale bytteforholdsrelationer – det styrker 

videndelingsprocessen. 

Understøt gensidig anerkendelse i projektteamet – det styrker 

videndelingsprocessen. 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Ifølge den klassiske kommunikationsmodel er videndeling en strøm af viden, der 

flyder fra en afsender til en modtager [Jacobsen & Thorsvik, side 271]. Modtageren 

er derved den part, der opnår flest fordele. Der vil derfor kun finde en frivillig 

kommunikations udveksling sted mellem de 2 parter, hvis der etableres et 

bytteforhold mellem dem. Den der afgiver viden skal altså på passende vis 

kompenseres af modtageren. [Holdt Christensen] har imidlertid en interessant 

pointe i denne sammenhæng. Han har bemærket, at medarbejderne i danske 

virksomheder deler viden, også selv om de ikke modtager nogen økonomisk 

kompensation. I stedet etableres, det han betegner, et socialt bytteforhold. I dette 

perspektiv udspringer videndelingsproblemet ikke af uvilje hos medarbejderne, men 

snarere af manglende mulighed for at dele viden. Man deler viden, bl.a. for at vide 

sig sikker på selv at kunne opnå hjælp, når det kræves. 

Anerkendelse er væsentlig i den videndelende organisation. Videndeling skal være 

en del af projektkulturen. At kunne acceptere og belønne kreative fejl og 

samarbejde er vigtigt, og projektdeltagerne skal vide, de ikke taber status ved ikke 

at vide alt, [Jensen, Mønsted & Olsen, Davenport og Prusak side 50]. 

Ved at lade et flerfagligt team udvikle en hel feature, bliver ansvaret for opgaven 

placeret et sted - nemlig i teamet. Dermed kommer teamet i fællesskab til at eje al 

den nødvendige viden - men også ansvaret, og kan derfor også kun som team 

høste belønningen. For at høste belønningen skal teamet altså også dele viden. 

side 50 af 94


3.6 Projektlederens Kompetencer 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Projektlederen for det problemdefinerende projekt skal både mestre 

management og leadership kompetencer. 

Det fordrer en særlig kompetence hos projektlederen at kunne veksle mellem 

management og leadership tilgangen - og med den rette timing. 

Management knytter sig til reduktion af operationel usikkerhed. 

Leadership knytter sig til reduktion af kontekstuel usikkerhed. 

I dette afsnit vil vi vurdere, hvilke kompetencer der fordres hos projektlederen for 

det problemdefinerende projekt, set i relation til de traditionelle 

projektledelseskompetencer. De traditionelle projektledelseskompetencer 

identificeres i forhold til de projekttyper, de bringes i anvendelse overfor. De 

opgaver de forskellige projekttyper giver anledning til kræver anderledes 

procesledelseskompetencer og værktøjer af projektlederne end de almindeligvis 

kendte projektlederkompetencer. Det fordrer fx en særlig evne hos projektlederen 

til at balancere mellem reduktion af operationel- og kontekstuel usikkerhed. 

Afslutningsvis stiller vi spørgsmål til om management kompetencer er tilstrækkelige 

i projektledelse. 

3.6.1 Lineær versus cirkulær logik som kompetence 

Projektlederens kompetencer i rutineprojektet er primært knyttet an til en 

1.ordens-ledelseslogik, baseret på en lineær forståelsesform. 

Projektlederens kompetencer i det problemdefinerende projekt er primært 

knyttet an til en 2.ordens-ledelseslogik, baseret på en cirkulær forståelsesform. 

I dette afsnit vil vi vurdere, hvilke projektleder kompetencer, der knytter sig til 

polariseringerne indenfor de projekttyper, vi har defineret, nemlig rutine- og 

problemdefinitionsprojektet. 

Med udgangspunkt i definitionen af rutineprojektet, mener vi at projektledelsen 

praktiseres ved traditionel funktionel ledelse [Bakka & Fivelsdal, side 24]. Dette 

fordrer blandt andet kompetencer i de værktøjer, der bringes i anvendelse omkring 

planlægning, styring og opfølgning [Melander, side 156 "formelle 

planlægningsværktøjer og styringsog opfølgningsværktøjer"]. Denne tilgang 

side 51 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

forudsætter, at projektopgaven er veldefineret, og betyder at projektet kan styres 

gennem faste målsætninger. Løsning af opgaven fastlægges typisk med procedurer 

og processer, der dikterer den ønskede adfærd. 

I denne optik ligger der i rutineprojektet et primært fokus på projektteamets 

funktion og effektivitet – det vil sige et fokus på projektets "indre verden" [Gitte 

Haslebo]. Enhver ændring i rutineprojektet er således baseret på en lineær logik. Fx 

er rettelser af fejl i software baseret på en årsag-virkning logik og ansvar-skyld 

logik. Denne logik har til formål at udpege hvor ændringen skal ske samt hvor 

ansvaret skal placeres. Dette mener vi er en 1.ordens-ledelseslogik, baseret på en 

lineær forståelsesform, som er fokuseret på at "gøre tingene rigtigt". 

I det problemdefinerende projekt stilles der ofte spørgsmålstegn ved opgave 

definitionen - hvad er kundens behov, og hvilken teknologi indfrier bedst disse 

behov? Her kan projektet ikke nøjes med at fokusere på projektteamets funktion og 

effektivitet - den indre verden, men må også rette fokus mod omgivelserne - den 

ydre verden. I rutineprojektet, hvor fokus er på projektteamets indre verden, kan 

projektlederen, føre projektet til succes ved en normativ adfærd, der er baseret på 

fastlagte processer og procedurer. Problemdefinerende opgaver kan derimod ikke 

rummes i sådanne strukturelle former, og her må projektlederen tage ansvar for at 

projektteamet selv får defineret og besluttet den adfærd, der sikrer projektet 

succes under delt hensyntagen til såvel projektteamets indre som ydre verdens 

behov og præmisser. Efter vores mening fordrer dette andre kompetencer end i 

rutine projektet, se fx [Melander, side 156 "Eksterne integrationsværktøjer"] og 

Figur 15. Selvom eksterne integrationsværktøjer som fx dannelse af styregruppe, 

brugerinvolvering, kundemøder, status- og fremskridtsrapporter tilpasset 

interessenternes behov kræver lineære kompetencer, er det at stille 

spørgsmålstegn ved projektopgavens præmisser og reflektere over 

projektdeltagernes adfærd, såvel internt som eksternt, efter vores mening et 

udtryk for en bevægelse i retning af 2.ordens-ledelse, og er karakteriserende for 

cirkulær logik [Gitte Haslebo]. 

side 52 af 94


3.6.2 Balancen mellem operationel- og kontekstuel usikkerhed 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Værktøjer til reduktion af operationel risiko knytter sig til en 1.ordens- 

ledelseslogik det vil sige management tilgang. 

Værktøjer til reduktion af kontekstuel risiko knytter sig til en 2.ordens- 

ledelseslogik det vil sige leadership tilgang. 

I Figur 1 har vi illustreret at produkt udviklingsprojektet lever i et spændingsfelt 

mellem to typer usikkerhed, operationel og kontekstuel usikkerhed. I det 

problemdefinerende projekt kan man, efter vores mening, ikke opnå succes ved 

kun at håndtere den ene type usikkerhed. Dette skyldes, at projektet skal sikre 

overensstemmelse med kundens forventninger og behov, og derfor skal 

projektlederen hele tiden balancere mellem de to typer af usikkerhed. På den ene 

side skal han søge at reducere kontekstuel usikkerhed ved at åbne op for nye 

fortolkninger omkring definition af projektopgaven, og hvordan den bedst løses, og 

på den anden side samtidig sikre projektet bliver færdigt til tiden ved at reducere 

operationel usikkerhed. De projektlederkompetencer, der bruges til reduktion af 

operationel usikkerhed, knytter sig efter vores mening til projektlederen som 

manager. Det vil sige de traditionelle formelle planlægnings- styringsog 

opfølgningsværktøjer. Reduktion af kontekstuelle risici stiller derimod anderledes 

kompetencekrav til projektlederen. Her spiller de eksterne og interne 

integrationsværktøjer en større rolle. Eksempler på disse værktøjer kan ses i 

[Melander, side 156]. Grundlæggende drejer det sig for projektlederen om, at sikre 

at projektteamet fungerer som en samlet integreret gruppe, men især også om at 

skabe sammenhæng i forhold til omgivelserne fx kunden. I det problemdefinerende 

domæne sker dette ved at projektlederen agerer som facilitator i højere grad end 

som manager. Dette indikerer, at projektlederen skal trække på kompetencer fra 

helt andre områder fx gruppepsykologi, adfærdspsykologi. Det er her 

projektlederen skal fokusere på at skabe motivation og kreativitet, bl.a. gennem 

kommunikation og effektiv videndeling projektteamet og kunde imellem, med det 

formål at opbygge ny viden og derigennem stimulere læring. Evnen til at lykkes på 

dette område er meget vigtig for om projektteamet kan agere innovativt. 

side 53 af 94


3.6.3 Balancen mellem at inkludere og ekskludere kunden 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Projektlederen skal løbende kunne vurdere og træffe beslutning om, hvorvidt 

kunden skal inkluderes eller ekskluderes i forhold til projektteamet. 

Kompetencer der understøtter kommunikation og videndeling er centrale. 

I det dynamiske domæne, hvor det er vanskeligt at specificere en objektiv 

opgavedefinition, der kan fortolkes ens uafhængigt af iagttageren, er det ikke 

muligt at fastlægge den optimale adfærd gennem procedurer og processer. I denne 

situation er det vores erfaring, at produktudviklingen forløber bedst når det lykkes 

at integrere kunden i projektteamet. Den rolle kunden skal spille er, at deltage 

løbende i projektets prioriteringer og beslutninger. En forudsætning for at dette kan 

lykkes er, at kunden føler sig velkommen og integreret i projektet. Tanken er ikke 

at kunden rent fysisk skal sidde sammen med projektteamet i gennem hele 

projektforløbet. Dette vil formodentlig være spild af både kundens og 

projektteamets tid. Det væsentlige er, at der er en god kommunikation og en god 

videndeling mellem projektteam og kunde. Dette vil understøtte projektteamets 

læring og forståelse af de behov produktet skal opfylde. Samtidig vil kunden lære 

om de teknologiske muligheder, der kan vælges i mellem. Dette vil hjælpe til den 

rigtige prioritering og beslutning om projekts retning og mål. 

Hvis der er klarhed om, hvad der skal laves, og hvordan det skal laves, kan det 

omvendt være mere hensigtsmæssigt ikke at inddrage kunden i en periode, og lade 

projektteamet arbejde koncentreret med at implementere løsningen. Efterfølgende 

må resultatet så stå sin prøve i forhold til kundens forventninger, og projektteamet 

må evaluere sin adfærd, orientering og retning. 

Det er således en vigtig projektleder kompetence, at han kan ramme den rigtige 

timing med hensyn til at inkludere - men også ekskludere kunden. Endvidere 

fordrer det særlige kompetencer omkring etablering af den rette kommunikation og 

videndeling, der skal sikre både projektteam og kunde den nødvendige læring. 

Derfor er det nødvendigt at projektlederen kan træde tilbage i metaposition og 

vurdere den optimale strategi. Figur 15 tager udgangspunkt i Figur 1, men tilføjer 

reference til, hvordan værktøjstyper knytter sig til projektkontekst ifølge 

[Melander]. 

side 54 af 94


Høj 

Lav 

Lav 


Eksterne og interne 

integrationsvæktøjer 

(kundeinvolvering, netværk, etc.) 

Meta-position 

kontekstuel 

usikkerhed 

INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Formelle planlægnings- styringsog 

opfølgningsværktøjer 

(Målsætning, planlægning, 

formelle statusrapporter etc.) 

Figur 15 Projektlederen i meta-position 

Høj 

Projektlederen skal således gennem meta-position kunne veksle mellem: 

• at bringe lineær og cirkulær logik i spil afhængig af projekt kontekst 

• at differentiere mellem strategier til reduktion af kontekstuel eller operationel 

usikkerhed 

• at inkludere eller ekskludere kunden 

Dette mener vi, er et eksempel på den 2.ordens-ledelses kompetence en 

projektleder skal mestre. 

3.6.4 Projektlederen i meta-position 

Projektlederens evne til at træde i meta-position, og der igennem vekselvirke 

mellem management og leadership - med den rette timing - er en helt 

afgørende forudsætning for at kunne føre det problemdefinerende projekt til 

succes. 

I dette afsnit vil vi vurdere sammenhængen mellem management og leadership på 

den ene side og projekttype på den anden. Endvidere vil vi vurdere, hvor vi ser 

anvendelse af management og leadership som ledelsestilgang i forhold til 

projekttyperne. 

side 55 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Med de karakteristika vi tidligere har tegnet for rutineprojektet, ser vi en 

sammenhæng mellem den ledelsesform management er udtryk for, og de 

ledelsesbehov der er i rutineprojektet. I rutineprojektet er det muligt for 

projektlederen at planlægge opgaven, og derefter ansætte personer med de rette 

kvalifikationer til at føre planen ud i livet og derigennem løse opgaven. 

Forudsætningen er dog at ændringer fra omgivelserne kan ignoreres. 

Vi er skeptiske overfor om dette også er muligt i det problemdefinerende projekt. 

På grund af den manglende struktur - projektlederen ved jo ikke hvad der skal 

laves og hvordan det skal laves - bliver han nødt til at opgive sin position som 

overordnet autoritet og indtage en mere sideordnet rolle i forhold til 

projektdeltagerne. Projektdeltagerne er jo oftest dem, der er tættest på den 

praktiske del af opgaven, og vi mener derfor også, de er bedre rustet til at finde de 

rette løsninger end projektlederen er. Men dette fordrer frivillighed, nysgerrighed, 

vilje og evne til at udforske og udfordre nye verdener eller følge nye veje, alt 

sammen eksempler på adfærd hos projektdeltagerne, der ikke kan beordres. 

På den anden side må en forudsætning for at projektlederen kan indtræde i en 

mere sideordnet rolle være, at magtrelationen mellem ham og de øvrige 

projektdeltagere ikke står i vejen for etablering af en sådan relation. Fx har 

projektlederen ofte indflydelse på ledelsesvurderinger, der danner basis for 

lønforhandlinger, bonus udbetalinger osv., og de kan hæmme projektdeltagerens 

ønske om at indgå i sideordnede relationer med projektlederen, af frygt for at 

svække deres stilling. 

Det interessante er, hvordan projektlederen løser opgaven, at få den optimale 

adfærd frem hos projektdeltagerne. Projektdeltagernes relationer skabes ikke af 

deres subjektive tanker, følelser og intentioner, men af den kommunikation der 

foregår mellem dem [Gitte Haslebo]. Dette åbner for mange forskellige muligheder 

for at skabe et velfungerende projektteam, hvor det at stille de rigtige spørgsmål er 

mere i fokus end det at give de rigtige svar. Dette finder vi ligger helt i tråd med 

leadership tilgangen. Når der ikke kan opstilles klare mål og retning af 

projektlederen, må han i stedet appellere til, at projektdeltagerne afsøger deres 

egne erfaringsgestalter og på basis af disse danner en fælles retningsgivende vision 

[Gitte Haslebo, side 52]. Derigennem kan der skabes fælles energi, engagement, 

ansvarlighed, orientering og retning, idet projektets vision forenes med 

projektdeltagernes egne ønsker. 

side 56 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Hvor management tilgangen søger at eliminere de operationelle risici, erkender 

leadership tilgangen nødvendigheden i at acceptere høj operationel usikkerhed for 

derigennem at kunne minimere den kontekstuelle usikkerhed. I leadership 

tilgangen opfattes det som naturligt, at der sker ændringer i den ydre verden. Disse 

ændringer ses som potentielle muligheder for at opnå læring, og dette kan i sidste 

ende føre til en bedre løsning og et mere konkurrencedygtigt produkt. Leadership 

tilgangen fordrer at projektteamet er komfortabel med risiko og ikke er bange for 

at bryde regler og procedurer i bestræbelsen på at gøre "de rigtige ting". Dette er 

dog ikke uden problemer, idet projektet har brug for legitimitet og accept fra 

basisorganisationen. Mangel på regelrethed, mener vi derfor, kan føre til konflikter i 

forhold til basisorganisationen. Fx er mange virksomheders kvalitetssystem baseret 

på en lineær tilgang, idet det dikterer, hvordan projekter gennem repeterbare 

processer og procedurer skal gennemføres. 

Udfordringen, ved at anvende leadership tilgangen i det problemdefinerende 

projekt, er at blive færdige til tiden. For at tilgodese det mener vi, det kan være 

formålstjenligt at kombinere management og leadership med henblik på at 

gennemføre projektet mere effektivt. Fx anvendes dette princip i den iterative 

udviklingsmetode, se Appendix 2, ved brug af timeboxed iterationer. 

Projektlederens leadership kompetence går på at etablere de rammer, der skaber 

åbenhed i projektteamet overfor ændringer i projektets omgivelser, mens 

management kompetencen går på den traditionelle planlægnings- og styringsdel i 

de enkelte iterationer. 

En stærk leadership dominans vil i en eller anden udstrækning ødelægge orden og 

effektivitet. Ligesom en stærk management dominans kan tænkes at tage modet 

fra de risikovillige og innovative. Derfor kan de to tilgange ikke eksistere på samme 

tid. Hvis leadership og management skal kombineres, kan det tyde på, at det skal 

ske med en tidslig forskydning. Vi har selv erfaret, at det er vanskeligt, at arbejde 

med fx koncepter den ene dag og forholde sig rationelt og effektivt til en 

arbejdsproces den næste dag. Det at veksle mellem management og leadership 

tilgang, kræver efter vor opfattelse i særlig grad evne til 2.ordens-ledelse. 

Kunsten for projektlederen er derfor at han skal kunne vekselvirke mellem 

management og leadership tilgangen. Det problemdefinerende projekt bliver aldrig 

færdig under rendyrket leadership ledelse, men opnår heller aldrig den læring der 

fører til det rigtige produkt ved en rendyrket management tilgang. En særlig 

kompetence er derfor, at han skal kunne træde tilbage i meta-position og indtage 

side 57 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

en observerende rolle, hvor der reflekteres over, hvilke strategier, der er optimale i 

den givne situation, se Figur 15. Det at kunne træde tilbage og observere, reflektere 

og beslutte strategi opfatter vi som en særlig kompetence, projektlederen skal 

beherske for at opnå succes med det problemdefinerende projekt [Stelter, Kolb's 

læringscyklus side 164]. 

Mange af de management opgaver, der traditionelt varetages af projektlederen 

overtages i det problemdefinerende projekt af projektdeltagerne selv. Dog 

faciliterer projektlederen gennemførelsen af disse opgaver. Dette gælder fx 

definition, planlægning og opfølgning på de enkelte opgaver i den iterative 

udviklingsmodel. Projektdeltagerne tager endvidere ansvar ved selv at tilvælge 

opgaver, ud fra egen vurdering af hvilke opgaver de anser sig som mest 

kompetente til at løse. Dette fordrer at projektlederen kan/vil give slip på ansvaret, 

og at projektdeltagerne kan/vil tage ansvaret. Heri ligger igen en indikation om, at 

projektlederen skal opgive sin rolle som instruktør og vejleder og bevæge sig mere 

i retning af at være facilitator for dannelse af de rette relationer - både internt i 

projektteamet såvel som eksternt i forhold til omgivelserne. 

Ved valg af ledelsestilgang skal projektlederen bl.a. forholde sig til, at: 

• Management og leadership ikke er et spørgsmål om enten/eller men om 

både/og. 

• Management og leadership kan ikke koeksistere, og fordrer derfor både evne 

til at træde i meta-position samt at kunne vekselvirke mellem begge 

ledelsesformer. Dermed er timing en vigtig faktor. 

• Leadership knytter sig til reduktion af kontekstuel usikkerhed bl.a. ved brug af 

cirkulær logik. Leadership fordrer at projektlederen kan ligestille sig med 

projektdeltagerne. 

• Management knytter sig til reduktion af operationel usikkerhed bl.a. ved brug 

af lineær logik. 

side 58 af 94


4 Konklusion - Hvad har vi lært? 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

For agile projekter er management og leadership ikke et spørgsmål om enten/eller 

men om både/og. Kravet til, hvornår projektet er færdig, er stadig gældende. Her 

spiller management en vigtig rolle. På den anden side er kravet om, at levere den 

rigtige funktionalitet på afleveringstidspunktet også vigtigt. Dette skaber behov for, 

at projektet løbende er åbent overfor omgivelserne. I denne dynamik spiller 

leadership tilgangen en vigtig rolle. 

Leadership knytter sig til reduktion af kontekstuel usikkerhed bl.a. ved brug af 

cirkulær logik. Management knytter sig til reduktion af operationel usikkerhed bl.a. 

ved brug af lineær logik. Det nye er, at projektlederen også skal beherske 

kompetencer, der anvender cirkulær logik, samtidig med han stadig skal beherske 

de traditionelle projektlederkompetencer, der anvender lineær logik. Det er 

projektets kontekst, der er bestemmende for, hvilken logik der bør anvendes. 

Cirkulær logik er knyttet til projektlederens rolle som facilitator overfor 

projektteamet. Dette gælder i særlig grad i forholdet til projektteamets 

kompetencer fx omkring fleksibilitet overfor forandringer, selvstændighed og 

ansvar. 

Hovedkonklusion: 

Produktudviklingsprojekter er i stigende grad problemdefinerende, og 

befinder sig i dynamiske og komplekse omgivelser. I dette domæne er 

projektledelse, baseret på de agile værdier, bedre rustet end traditionel 

projektledelse, til at levere ny værdi til kunden på markedspladsen, i rette 

tid. 

Dynamiske og komplekse omgivelser kræver mere end blot traditionelle 

projektlederkompetencer. Projektlederen skal også mestre: 

• leadership tilgang, herunder anvendelse af cirkulær logik 

• balancegang mellem reduktion af operationelle og kontekstuelle 

risici 

• at kunne veksle mellem: 

o management og leadership tilgang 

o at inkludere eller ekskludere kunden i projektet 

side 59 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Management og leadership kan ikke koeksistere, og fordrer derfor evne hos 

projektlederen til at kunne træde i meta-position og overveje samt vælge en 

passende ledelsesstrategi. 

Pointer omkring projektets processer: 

Vores anbefaling er, at anvende en iterativ udviklingsmodel, baseret på en 

timeboxed iterativ proces. 

Med den iterative udviklingsmodel opnår projektet: 

Med en passende kort iterationslængde opnår projektteamet løbende fleksibilitet 

overfor ændringer i omgivelserne. Dette skaber god mulighed for håndtering af 

såvel operationelle som kontekstuelle risici. 

Hyppig og kvantitativ kommunikation, mellem projektteam og kunde, skaber 

mulighed for god overensstemmelse mellem kundens forventninger og det færdige 

produkt på afleveringstidspunktet. Den regelmæssige feedback fra kunden styrker 

muligheden for at prioritere arbejdet relativt til det, der giver kunden mest værdi. 

Projektteamets refleksion efter hver iteration, skaber mulighed for en kontinuert 

procesforbedring. Dermed er der til stadighed fokus på at fremme effektiviteten i 

projektet. 

• fleksibilitet i forhold til ændringer i projektets omgivelser 

• hyppig og kvantitativ kommunikation mellem projektteam og kunde 

• mulighed for kontinuert procesforbedring gennem hele projektforløbet 

Pointer omkring projektets struktur: 

Vores anbefaling er, at: 

• etablere en projektorganisation med en organisk struktur 

• etablere en selvorganiserende projektteams 

• etablere projektteams, sammensat af flerfaglige kompetencer 

• placere teammedlemmerne i samme rum 

En organisk struktur skaber mulighed for en effektiv, fleksibel og hurtig 

projektorganisation. Manøvredygtighed og fleksibilitet støttes med etablering af 

selvorganiserende teams. Sammensætning af projektdeltagere i flerfaglige teams 

side 60 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

skaber mulighed for bedre deling af tavs viden og skabelse af ny viden. Det styrker 

de personlige relationer at placere teammedlemmerne i samme rum. Derved 

understøttes også det direkte møde, og der etableres korte kommunikationsveje, 

der muliggør gensidig tilpasning. 

Den mest grundlæggende forudsætning for at lykkes med implementation af ”en 

bedre vej” til projektledelse, er at få forankret beslutningen hos ledelsen. Ledelsen 

skal overbevises om, at det er en bedre vej. 

Det er vigtigt at projektet allierer sig med forandringsagenter, der brænder for den 

ny sag. 

Anbefalinger til implementation af ”en bedre vej” til 

projektledelse: 

• forankre beslutningen om iterativ udvikling som strategi, på 

ledelsesplan 

• få engagerede personer involveret i projektteamet 

• gennemfør indledende uddannelsesforløb omkring iterative metoder, 

både for projektdeltagere og projektledere 

• etabler samarbejde med personer, der har erfaring i at facilitere 

anvendelsen af iterative metoder 

• få de fysiske rammer på plads – fjern forhindringerne 

• tag små skridt og søg de kortsigtede gevinster 

• vær forberedt på at skulle afvige fra ovenstående, for at kunne 

tilpasse implementationen til konteksten 

Enhver læring starter med ny viden – sørg derfor for at kick-starte processen 

gennem uddannelse. Mange af erkendelserne kommer først gennem handling, så 

derfor er det vigtigt, at projektteamet bliver faciliteret af en person, der har prøvet 

den iterative proces før. 

Fjern forhindringerne - Etabler gode fysiske rammer fx whiteboards, rigelig med 

plads til at projektteamet kan udfolde deres aktiviteter. 

side 61 af 94


5 Perspektivering – Næste skridt 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Efter at have fulgt en række kurser på Diplomuddannelsen i Projektledelse er det 

påfaldende, hvordan de forskellige teoriområder, indenfor: kommunikation, 

teambuilding, coaching, organisationsteori, motivation og videndeling, understøtter 

de agile værdier. Bidragene fra disse forskellige teoriområder gør det dog også klart 

for os, at det vil fordre forandringsledelse på en række områder, hvis man skal 

opnå det fulde udbytte ved at skifte fra traditionel projektledelse til agil 

projektledelse. 

Nogle interessante spørgsmål, der kan arbejdes videre med, i forbindelse med 

undersøgelse og indførelse af den iterative udviklingsmodel, er: 

Videre undersøgelse af den iterative versus den vandfaldsbaserede 

udviklingsmodel: 

• Opleves produkterne som værende bedre, færre fejl?, mere brugervenlige 

produkter? 

• Er den iterative udviklingsmodel altid at foretrække? 

Forandringsledelses problematikker: 

• Eksisterer der en konflikt imellem udviklingsprojektets behov for fleksibilitet 

og udviklingsarbejdets bindinger til kvalitetsstyringssystemet? 

• Favoriserer agile projekter særlige persontyper? 

• Hvorledes kan projekter være agile og samtidig eksistere med de 

institutionelle bindinger? 

• Hvordan indføres agil udvikling i praksis? 

• Hvis agile projekter er så gode, hvordan kan det så være at ledelsen 

generelt stadig holder fast i den traditionelle projektledelsestilgang? 

• Hvordan ser fremtidens virksomhed ud? – den er måske struktureret 

udelukkende af organiske projektteams? 

Projektlederens kompetencer: 

• Kan man gennem sammenligning af fx 15 år gamle og nutidige jobannoncer 

konstatere den tendens i projektleder kompetencer, vi har argumenteret 

for? 

• En anden mulighed kunne være at interviewe en række virksomheder, for at 

undersøge, om de har konstateret et skifte i de projektleder kompetencer, 

der efterspørges. 

side 62 af 94


6 Referencer – Hvor ved vi det fra? 

Reference navn Beskrivelse 

Agile Manifesto Manifesto for Agile Software Development 

Findes på: http://agilemanifesto.org/ 

(14. december 2007) 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Arne Vestergaard Erhvervspsykologi i praksis - metoder til fælles bevægelse 

Arne Vestergaard 

Psykologisk Forlag, 2. udgave 2003 

ISBN: 87-7706-374-0 

Bakka & Fivelsdal Organisationsteoriens klassikere 

Redigeret og kommenteret af Jørgen Frode Bakka & Egil Fivelsdal 

Handelshøjskolens Forlag, 1. udgave, 1. oplæg, 2002 

ISBN 87-629-0202-4 

Carlson & Wilmot Innovation - The Five Disciplines for creating What Customers 

Want 

Curtis R Carlson & William W. Wilmot 

Crown Business, 2006 

ISBN: 0-307-33669-7 

Christensen & Kreiner Projektledelse i løst koblede systemer - ledelse og læring i en 

ufuldkommen verden. 

Jurist- og Økonomforbundets Forlag, 1. udgave, 10. oplag 2002 

ISBN 87-574-5930-4 

Cockburn Agile Software Development 

Alistair Cockburn 

Addison-Wesley Professional, 2001 

ISBN: 0201699699 

Cohn Agile Estimating and Planning 

Mike Cohn 

Pearson Education, 2006 

ISBN: 0-13-147941-5 

Darsø Findes der en formel for innovation? 

Lotte Darsø 

Børsen Ledelseshåndbøger, Innovations- og forandringsledelse, 

februar 2003 

Gitte Haslebo Relationer i organisationer – En verden til forskel 

Gitte Haslebo 

Psykologisk Forlag A/S, 2006 

ISBN 87 7706 351 1 

Guba The Paradigm Dialog. 

SAGE, London 1990. 

IEEE IEEE Standard Glossary of Software Engineering Terminology 

IEEE Std 610.12-1990 (R2002) 

Holdt Christensen Vidensdeling - perspektiver, problemer og praksis 

Peter Holdt Christensen 

Handelshøjskolens Forlag, 1. oplag 2004 

ISBN 87-629-0218-0 

Jacobsen & Thorsvik Hvordan organisationer fungerer – Indførelse I organisation og 

ledelse 

side 63 af 94



Jensen, Mønsted & 

Olsen 


Dag Ingvar Jacobsen 

Jan Thorsvik 

Hans Reitzels Forlag, 2. oplag 2004 

ISBN: 97-412-2475-2 

INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Viden, Ledelse og kommunikation 

Sisse, Siggaard Jensen, Mette Mønsted og Sanne Fejfer Olsen 

Samfundslitteratur 2004 

ISBN 87-593-1069-3 

John P. Kotter I spidsen for forandringer. 

Peter Asschenfeldts Nye Forlag 

ISBN 87-7880-709-3 

Larman Agile & Iterative Development - A managers guide 

Craig Larman 

Addison-Wesley, 2004 

ISBN 0-13-111155-8 

McConnel Software Project Survival Guide 

Steve C McConnell 

Microsoft Press; 1 edition, 1997 

ISBN: 978-1572316218 

Melander Projektstyringens problemer og værktøjer - Fra kaos til resultat 

Redigeret af Preben Melander 

Jurist- og Økonomforbundets Forlag, 2. udgave, 1993 

ISBN 87-574-5805-7 

Mikkelsen & Riis Grundbog i Projektledelse 

H. Mikkelsen og J. O. Riis 

Prodevo ApS, 7. udgave 2003 

ISBN 87-89477-21 

Mintzberg Structure in Fives: Designing Effective Organizations (side 121- 

150) 

Henry Mintzberg 

Prentice Hall, 1. edition 

ISBN: 87-89477-21 

Noter fra ITPR Noter i forbindelse med forelæsninger i faget IT projektledelse 

Allan Bo 

Foråret 2006-05-17 

Udleveret i forbindelse med undervisning 

Nørretranders Mærk verden - En beretning om bevidsthed 

Tor Nørretranders 

Gyldendal 2. udgave 1993 

ISBN: 87-0015128-9 

Petersen & 

Østergaard 

Videnkollektivisering som videnstrategi 

Nicoline Jacoby Petersen og Sille Østergaard 

Findes på: http://www.leadingcapacity.dk 

Royce Managing the Development of Large Software Systems: concepts 

and techniques 

Winston Royce 

Proceeding, IEEE Westcon, august 1970 

Findes på: 

http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf 

(14. december 2007) 

side 64 af 94



Poula Helth Lederskabelse - det personlige lederskab 

Poula Helth (red.) 

Samfundlitteratur, 1. udgave 2006 

ISBN: 87-593-1233-5 

Standish01 Extreme Chaos, 2001 

Jim Johnson, et al. 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Findes på: 

http://www.standishgroup.com/sample_research/PDFpages/extre 

me_chaos.pdf (12. december 2006) 

Stelter Coaching læring og udvikling 

Reinhard Stelter 

Dansk Psykologisk Forlag, 1ste udgave, 7. oplag, 2005 

ISBN 87 7706-323-6 

side 65 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

7 Definitioner & forkortelser – Hvad betyder 

det? 

Definition navn Beskrivelse 

2. ordens-ledelse En iagttagelse af det, der ligger bag logikken i både den indre 

organisation og i den ydre verden hos kunder og 

samarbejdspartnere samt i relationer mellem de 2 verdener. 

Lederen kan også herfra iagttage først ordens-ledelse og de 

logikker, der skaber handlinger i denne. Anden ordens-ledelse 

kræver en refleksiv kompetence samt evne til at analysere det 

iagttagede og det tænkte i forhold til forskellige logikker. Anden 

ordens-ledelse er en forudsætning for at kunne analysere og 

forstå de stadigt mere komplekse og skiftende kontekster hvor 

ledelse praktiseres [Poula Helth side 185]. 

Det rigtige produkt Det produkt, der med passende teknologi bedst matcher kundens 

forventninger på afleveringstidspunktet. 

Det vil sige i forhold til den vandfaldsbaserede tilgang skiftes der 

paradigme fra ”at lave tingene rigtigt” (plan the work - work the 

plan) til at ”lave de rigtige ting”. 

Dynamiske omgivelser Omgivelserne betegnes som dynamiske, hvis det er svært at 

forudse fremtidige (kunde-) krav til produktet [Mintzberg]. 

Eksponentiel økonomi [Carlson & Wilmot] Udbredelsen af de nye vidensbaserede 

produkter og services fx Internet, computer, 

kommunikationsteknologi, bioteknologi, forbruger elektronik etc. 

der oplever en hurtig og eksponentielt voksende værdiudvikling. 

Fx fordobles Internet backbone kapaciteten hvert år. 

Feature Det er en ønsket service for et system, som kan kræve en 

sekvens af input for at opnå det ønskede resultat. For eksempel 

er SMS på en mobiltelefon en feature. 

Software feature: 

(1) (IEEE Std 829-1983 [5]) A distinguishing characteristic of a 

software item (for example, performance, portability, or 

functionality). 

(2) (IEEE Std 1008-1987 [10]) A software characteristic specified 

or implied by requirements documentation (for example, 

functionality, performance, attributes, or design constraints). 

funktionel ledelse En ledelsesstil, der fokuserer på at holde styr på tid og 

omkostninger, kontrol, reparation og vedligeholdelse samt 

arbejdsdisciplin [Bakka & Fivelsdal]. Efter vores mening 

sammenfaldende med management begrebet 

1.ordens-ledelse En iagttagelse af de handlinger og den adfærd man umiddelbart 

kan se og sanse. Det er fænomeners umiddelbare fremtræden og 

den forklaringskraft, den ikke reflekterende opfattelse vil efterlade 

hos lederen. Er nødvendig i forhold til den adfærd og handlekraft, 

som frembringes i handlingens domæne [Poula Helth side 188]. 

Globalisering Den stadig stigende kulturelle og økonomiske udveksling mellem 

de forskellige verdensdele. 

Indre verden Internt i projektet; dvs. projektleder og – deltagere, se også 

[Poula Helth] side 42 figur 2.2. 

Den indre verden består af projektdeltagerne, deres indbyrdes 

side 66 af 94




INGENIØR 

HØJSKOLEN 

KØBENHAVN 

handlinger og kommunikation og den struktur de organiserer sig i 

for at løse opgaven. 

Inkrementel Tilføjelse af features / funktionalitet i små skridt 

Med inkrementel udvikling menes, at produktet udvikles i 

inkrementer, hvor der gradvist tilføjes features / funktionalitet per 

iteration. Den anbefalede længde for en iteration er fra 1 til 6 

uger [Larman]. 

Iteration Gentagelse af en udviklingssekvens for eksempel analyse � 

design � implementation � test � release 

Iterativ 

udviklingsmodel 

Udviklingsmodel der bygger på iterationer og inkrementel 

udvikling. 

Se også: Appendix 1 

Kompetence I følge [Arne Vestergaard] resultater: grad af succes (person x 

opgave x kontekst). Tilføres der værdi og leveres varen? (ja/nej). 

Kompetencer knyttes til situationer og relationer. Kompetencer 

opstår når viden / kvalifikationer bringes i anvendelse - det 

forudsætter altså handling. [Arne Vestergaard] 

Med kompetencer mener vi også anvendelse af metoder, 

værktøjer etc. 

Komplekse omgivelser Omgivelserne betegnes komplekse, hvis det involverer ny 

teknologi, der er tidskrævende at forstå og/eller kræver 

ændringer af produktplatformen [Mintzberg]. 

Kontekst Projektets kontekst er ikke kun de konkrete projektdeltagere, 

deres indbyrdes relationer og den struktur de indgår i, men også 

de handlinger og den kommunikation der foregår i den omgivende 

organisation, det omgivende samfund, institutioner, hos 

konkurrenter og kunder og som interferer med projektet på den 

ene eller anden måde. 

Kontekstuel 

usikkerhed 

Forskellen mellem den viden og de præmisser, projekter på den 

ene side designes og planlægges på, og som de på den anden 

side senere evalueres på [Christensen & Kreiner]. 

Kontekstuel risiko: Er knyttet til usikkerheden om ”HVAD” vi 

skal lave for at få udviklet det rigtige produkt (og kunden bliver 

tilfreds). 

Et andet ord for kontekstuel risiko er ekstern risiko. 

Kunde Den person, eller gruppe af personer, der anvender produktet til 

at skabe forretningsværdi eller, i tilfælde af detailprodukt, den 

person som bruger produktet. Kunder definerer værdi de øvrige 

interessenter definerer begrænsninger 

Kundeværdi Forskellen mellem den pris produktet sælges til (~ de 

brugerfeatures produktet tilbyder) og den omkostning der er 

knyttet til fremstilling af produktet. 

Kundeværdi kan øges på 2 måder - enten ved at sænke 

kostprisen eller ved at øge antallet af brugerfeatures eller 

forbedre dem. 

Leadership Handler om ledelse af de processuelle kvalifikationer og 

vedkommende evne til at kunne skabe sammenhængskraft i 

organisationen gennem involvering og udvikling. [Poula Helth, 

side 138]. 

Leadership er en ledelsestilgang, der: 

side 67 af 94




INGENIØR 

HØJSKOLEN 

KØBENHAVN 

� Er visionsdrevet – det vil sige der defineres en vision og 

en strategi for dennes realisation 

� Kommunikerer vision og strategi ud til medarbejdere og 

relevante interessenter på en sådan måde, at der skabes 

commitment til at nå fremtidige mål. 

� Inspirerer og motiverer medarbejderne til at håndtere de 

� udfordringer, der er forbundet med at arbejde frem mod 

visionen. 

Lidt populært kan man sige at: "lederen stiller de rigtige 

spørgsmål" 

[John P. Kotter] Dansk oversættelse af Leadership = Lederskab 

Management Er lederens evne til at sikre mål og retning, strategi, fokusering, 

kompetenceudvikling og ansættelse af folk med de rette 

kvalifikationer. [Poula Helth, side 138] 

Management er en ledelsestilgang der forsøger at skabe 

forudsigelighed og orden i organisationen ved: 

� Fastlæggelse af operationelle mål som følger en detaljeret 

plan, til hvilken der allokeres de nødvendige ressourcer. 

� Ansætte medarbejdere i overensstemmelse med mål og 

plan, og etablere organisationsstrukturer, der 

understøtter, de opgaver der skal løses. 

� At overvåge processen og korrigeres løbende 

Lidt populært kan man sige at: "Lederen kender de rigtige svar" 

Operationel 

usikkerhed 

[John P. Kotter] Dansk oversættelse af Management = Ledelse 

Forskellen, mellem på den ene side, den informationsmængde 

som er nødvendig for at udføre opgaven, og på den anden side, 

den informationsmængde, som på et givent tidspunkt er til 

rådighed for opgave udførelsen [Christensen & Kreiner, side 38]. 

Operationel risiko: er typisk relateret til hvordan vi sikrer at 

produktet bliver færdigt, herunder teknologiske risici som igen er 

knyttet til usikkerheden om ”HVORDAN” produktet skal laves. 

Et andet ord for operationel risiko er intern risiko. 

Problemdefinition Opgavetype, hvor det ikke umiddelbart er muligt at identificere 

selve opgaven/problemet [Noter fra ITPR] 

Problemløsning Opgavetype, hvor der er ingen eller ringe erfaring med [Noter fra 

ITPR] 

Projektsucces Traditionel definition: overholdt budget, tidsplan samt 

tilstrækkelig kvalitet. 

Risiko Fare. Mulighed for at noget uheldigt eller uønsket vil ske, der 

forhindre at projektet kan blive færdigt til tiden eller at produktet 

ikke opfylder kundens forventninger. 

Begrebet risiko kan deles i kontekstuelle og operationelle risici. 

Risikohåndtering, 

traditionel 

Risikohåndtering som beskrevet i [Mikkelsen & Riis, side 174]. 

Traditionel risikohåndtering relaterer til begrebet operationel 

risiko. 

Rutineproblem Opgavetype, der er løst før, måske endda mange gange [Noter 

fra ITPR] 

side 68 af 94



Selvorganiserende 

projektteam 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Er det team, der har retten til at planlægge og iværksætte enhver 

ændring, der forbedre teamets proces eller resultat. 

Alle teammedlemmerne har ansvar for at iværksatte ændringer, 

har den ønskede effekt. 

Timeboxed Timeboxed vil sige, at en iteration har en fast længde i periode. I 

styringstrekant regi betyder det, at der reguleres på features / 

funktionalitet for at fastholde terminsdatoen. Hvis det under en 

iteration ser ud til at sluttidspunktet ikke kan overholdes, så 

fjernes der opgaver fra iterationen i stedet for at acceptere en 

forsinkelse. 

Traditionel 

projektledelsestilgang 

Udviklingsmodel Se Appendix 1 

Den projektledelsestradition, der udspringer af Taylor's teori 

Scientefic Management om effektivisering af arbejdsprocesser. I 

opgavebesvarelsen bruges dette begreb om projekter gennemført 

efter vandfaldsmodel, se også: Appendix 1 

Vandfaldsmodel Et forløb hvor det tilstræbes at et produkt ideelt set udvikles med 

kun et gennemløb af følgende faser: Specifikation, design, 

implementation, test, og frigivelse. [IEEE]. Se også: Appendix 1 

Vertikal 

udviklingsstrategi 

Den strategi at et enkelt team i samme iteration implementerer 

brugergrænseflade, datakommunikationen, databasen, 

hardwaregrænseflade for en enkelt feature. 

Den modsatte strategi er at anvende horisontal implementation, 

hvor forskellige teams har ansvaret for forskellige ”lag” i 

produktet, så som: Brugergrænseflade, Datakommunikationen, 

Databasen osv. 

Ydre verden Projektets omgivelser, se også [Poula Helth] side 42, figur 2.2. 

Den ydre verden består primært af handlinger og kommunikation 

i samfundet, hos institutioner, kunder og konkurrenter samt 

teknologisk udvikling. 

Paradigmeskifte Paradigme: "....a basic set of beliefs that guides action, whether 

of the everyday garden variety or action taken in connection with 

a disciplined inquiry". [Guba] 

side 69 af 94


Appendix 1 Udviklingsmodeller 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Dette afsnit beskriver de vigtigste karakteristika for forskellige udviklingsmodeller, 

samt sammenligner vandfaldsmodellen med den iterative udviklingsmodel. 

Sammenligningen tager udgangspunkt i udviklingsmodeller for software, men 

grundideerne kan uden videre overføres til for eksempel udvikling af produkter 

En softwareudviklingsmodel, Software Development Process, er defineret af [IEEE] 

som: 

The process by which user needs are translated into a software product. The 

process involves translating user needs into software requirements, 

transforming the software requirements into design, implementing the 

design in code, testing the code, and sometimes, installing and checking out 

the software for operational use. 

Der findes forskellige udviklingsmodeller, de kan alle kategoriseres, efter forskellige 

principper, en måde er at opdele i 3 grundlæggende modeller; Ad hoc udvikling, 

vandfaldsmodeller og iterative modeller, se Figur 16. Disse grundlæggende 

modeller beskrives i de efterfølgende underafsnit. 

Grundlæggende 

udviklingsmodeller 

Ad-Hoc udvikling Vandfaldsmodeller Iterativemodeller 

Figur 16: Tre grundlæggende udviklingsmodeller, Oversat til dansk efter Darryl 

Green and Ann DiCaterino, (1998) "A Survey of System Development Process 

Ad Hoc udvikling 

Models" 

Er karakteriseret ved, at der ikke anvendes en eksplicit udviklingsmodel, således at 

opgaver løses kaotisk/tilfældig. Hvis der er planer, er de upræcise og usikre. Det 

færdige produkt er præget af uklarhed om funktionaliteten og stor inkonsistens i 

kvaliteten. Produktivitet og kvalitet afhænger af enkelt personer, derfor er det ikke 

et godt udgangspunkt for forbedring af produktivitet og kvalitet 

side 70 af 94


Vandfalds modeller 

Vandfaldsmodel er ifølge [IEEE] defineret som: 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

A model of the software development process in which the constituent 

activities, typically a concept phase, requirements phase, design phase, 

implementation phase, test phase, and installation and checkout phase, are 

performed in that order, possibly with overlap but with little or no iteration. 

Contrast with: incremental development 

Vi forholder os til vandfaldsmodellen i dens ekstreme udgave uden tilbageløb 

Vandfaldsmodellen er karakteriseres ved at alle krav skal defineres og fastfryses i 

en kravspecifikation, og ændringer i princippet er uønsket. Kravspecifikationen 

danner grundlag for tidsplanen, design osv. Med en komplet og korrekt 

kravspecifikation kan omfanget af udviklingsopgaven estimeres. Estimaterne 

anvendes til at lave en detaljeret plan for resten af projektet. I designfasen 

beskrives arkitekturen og detaljeret design for det kommende system, som herefter 

fastfryses. Herefter udvikles og implementeres systemet på en gang i henhold til 

planen og kravspecifikationen. Hver fase i projektet danner således et fast 

fundament for næste fase, se Figur 17. Dette fundament forsøges at holdes så 

stabilt som muligt, idet resultaterne for hver fase fastfryses. 

Systemkrav 

Software 

krav 

Analyse 

Program 

Design 

Program 

Konstruktion 

Figur 17: Vandfaldsmodel [Royce] 

Testing 

Operation 

Et projekt der følger vandfaldsmodellen fokuserer på at minimere både 

operationelle og kontekstuelle risici, ved tidligt i projekt forløbet at definere og 

fastfryse krav. I det vandfaldsbaserede projekt sker styring typisk ved regulering 

side 71 af 94


på parametrene udviklingsomkostninger og udviklingstid. 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Hvis et vandfaldsbaseret projekt i en given fase ønsker ændringer til krav, der er 

defineret i en tidligere fase sker dette via Change Control Board. Dette er i praksis 

et tilbageløb i modellen for den del der er omfattet af ændringen. 

Iterative modeller 

Iterative udviklingsmodeller anvender typisk en inkrementel tilgang, det vil sige at 

en delmængde af det samlede system vokser inkrementelt med nye features 

iteration for iteration. Inkrementel udvikling er ifølge [IEEE] defineret som: 

Incremental development. A software development technique in which 

requirements definition, design, implementation, and testing occur in an 

overlapping, iterative (rather than sequential) manner, resulting in 

incremental completion of the overall software product. Contrast with: 

waterfall model. 

Konceptet med at lade et system vokse via iterationer kaldes også Iterativ og 

Inkrementel udvikling, men i praksis anvendes begrebet iterativ udvikling. 

Tidligere anvendtes begrebet ”Inkrementel udvikling” til at beskrive en kombination 

af fastlåste kravspecifikationer inden design, efterfulgt af iterativ udvikling af 

features, men der er ikke nogen fælles enighed om anvendelse af begrebet 

[Larman]. Vi betragter iterativ udvikling, som udvikling uden tidligt fastlåste 

kravspecifikationer, hvor definitionen af kravene også er en del af iterationerne og 

hvor der efter hver iteration er mulighed for at se en delmængde af produktet som 

virker. 

Iterative udviklingsmodeller er karakteriseret ved at kravet om faseopdeling 

frafaldes, og faserne erstattes af en overordnet proces, der består af et antal 

sekventielle iterationer, se Figur 18, hvor faserne fra [Royce] af hensyn til 

overskuelighed er reduceret til: Analyse, Design Implementation og Test. 

side 72 af 94



Figur 18: Fra vandfald til iterationer [egen tilvirkning] 

INGENIØR 

HØJSKOLEN 

KØBENHAVN 

De tidligere faseknyttede aktiviteter som: analyse, design, implementation osv. 

genfindes i hver iteration. Hver iteration er således et selvstændigt mini-projekt, og 

målet for hver iteration er en iterations release, der ikke bare er en prototype eller 

lignende, men en delmængde af det færdige produkt. Det vil sige med en kvalitet, 

der kan frigives til og accepteres af brugeren. Der leveres altså mere og mere 

funktionalitet for hver iteration. 

Se Appendix 2 for mere information om iterativ udvikling. 

side 73 af 94


Appendix 2 Iterativ udvikling 

Hvad er iterativ udvikling? 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Iterative udviklingsmodeller anvender typisk en inkrementel tilgang, det vil sige at 

en delmængde af det samlede system vokser inkrementelt med nye features (det 

vil sige, ønskede service for produktet) iteration for iteration. Dette i modsætning til 

vandfalds udviklingsmodeller hvor alt planlægges ved projektopstart og projektet 

gennemføres med et enkelt gennemløb af modellen. 

Vi betragter iterativ udvikling, som udvikling uden tidligt fastlåste 

kravspecifikationer, hvor definitionen af kravene også er en del af iterationerne og 

hvor der efter hver iteration er mulighed for at se en delmængde af produktet som 

virker 

Hvor udvikling efter vandfaldsmodellen er fase-drevet og indenfor fasen 

aktivitetsdrevet, er udvikling efter den iterative model drevet af operationelle risici 

og kundeværdi i iterationer, hvor de fleste aktiviteter er repræsenteret, se Figur 19. 

Aktiviteter 

Analyse 

Design 

Implementation 

Test 

En iteration er et mini-projekt, der inkluderer 

arbejde inden for de fleste aktiviteter og 

som ender i en stabil release 

Iterationer 

Figur 19: Aktiviteter i iterationer, inspireret fra [Larman] 

Bemærk at selvom 

en iteration 

inkluderer næsten 

alle aktiviter, så 

skifter den relative 

del gennem tid 

De overordnede features defineres ved projektstart og fordeles på et antal 

iterationer. I den enkelte iteration arbejdes der videre med de features, der er 

placeret i iterationen. Indholdet af de enkelte iterationer vælges ud fra: 

• Interessenternes/kundernes prioritering af features ved hjælp af blandt andet 

brugerfokusgrupper 

• ønsket om at reducere eller eliminere de højeste risikofaktorer, det vil sige at 

minimere projektets usikkerhed ved hjælp af risikostyring 

side 74 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

• Input fra den læring der er sket ved sidste iteration – det vil sige, projektets 

læring som følge af arbejdet med produktet, læring fra omgivelser (kunder 

teknologi, konkurrenter osv.) 

De enkelte features implementeres ofte vertikalt, men kan også implementeres 

horisontal, hvis det giver bedre mening. For eksempel i forbindelse med definition 

af en brugergrænseflade er det ofte en fordel at kunne vise store dele af 

brugergrænsefladen uden at skulle have databasen implementeret, især hvis denne 

implementation skønnes som et rutineproblem. 

Slutdatoen for en iteration, timebox, besluttes ved iterationen start og ændres 

under ingen omstændigheder undervejs. Hvis der opstår problemer med at blive 

færdig til tiden, så bortskæres/udskydes funktionalitet i stedet for at flytte datoen. 

Generel mikromodel for iterativ udvikling 

Læreprocessen sker via timeboxed iterativ og inkrementel udvikling, hvor projektet 

veksler mellem overordnet styring, kontrol og prioritering, af operationelle mål og 

læring fra omgivelser, relateret til produktvisionen, de overordnede features osv. 

Figur 20 illustrerer en generel mikromodel for iterativudvikling 

Figur 20: Generel iterativ udviklingsmodel [egen tilvirkning] 

Makromodel for iterativ udvikling 

Hvor traditionelle projektmodeller, som fx vandfaldsmodellen, anvender en klar 

lineær tilgang, mener vi at iterativ udvikling må betragtes som en cirkulær tilgang. 

side 75 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Denne cirkulære tilgang er illustreret som en makromodel for iterativ udvikling i 

Figur 21 

Figur 21 Makromodel for iterativudvikling [egen tilvirkning] 

Ved opstarten på et iterativt projekt defineres det ønskede projekt ud fra en række 

parametre, først og fremmest kundeønsker, men også ud fra hvad konkurrenterne 

kan byde på, det teknologiske stade og så videre. Projektet deles, under 

udviklingsforløbet op i et antal releases til kunden. Kunden kan derved løbende 

evaluere og acceptere delmængder af produktet. Det interessante er at det ikke 

kun er kunden der bliver informeret ved en sådan release. Konkurrenterne får også, 

på et tidspunkt, informationer om produktet. Dette kan fx ske via de patenter 

projektet udfærdiger. Desuden vil patenter også ofte medføre en ændring af den 

tilgængelige teknologi. Det frigivne produkt kan ligeledes påvirke de institutioner, 

som har indflydelse på produkttypen. I nogle forretningsområder er der mange 

institutionelle krav til fx hvad et produkt skal kunne, men sådanne institutioner 

bliver også påvirket af ny teknologi og nye produkter. Ved de efterfølgende 

iterationer påvirkes produktdefinitionen af input fra kunder, konkurrenter, teknologi 

osv. Det vil sige, at fremtidige input til produktdefinitionen umuligt kan forudses og 

som følge deraf ikke planlægges. 

Projektrisici kan ændre sig som funktion af tiden, og alt andet lige ændrer den 

side 76 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

iterative udviklingsmodel derfor ikke på den overordnede risikohåndtering i forhold 

til vandfaldsmodellen. Ideelt set vil et projekt, der følger en iterativ 

udviklingsmodel, opleve at prioritering af kundeværdi og operationelle risici i de 

enkelte iterationer vil medføre at kundeværdien stiger meget i starten, og at de 

operationelle risici vil falde meget i starten. Antallet af implementerede features vil 

stige gennem projektforløbet, men vil ikke nødvendigvis følge stigningen i 

kundeværdien, se Figur 22. Det bør bemærkes at kurverne i Figur 22 i praksis vil se 

anderledes ud, for eksempel fordi kundernes læring vil medføre, at kundeværdien 

på et givet tidspunkt vurderes lavere end ved forrige iteration. Ligeså kan læring 

medføre, at allerede implementerede features ikke er interessante mere, og derfor 

vil antallet af features falde. 

Figur 22: Operationelle risici og kundeværdi som funktion af tiden [egen 

tilvirkning] 

En iterativ tilgang kan i princippet reducere den økonomiske risiko ved et 

udviklingsprojekt. Da der releases et funktionsdygtigt produkt efter en iteration, er 

der mulighed for at vælge at markedsføre produktet hurtigere. Hurtigere release 

giver mulighed for at tjene penge hurtigere end tilfældet er med en 

vandfaldstilgang hvor alle features først skal implementeres inden produktet 

frigives, se Figur 23. 

side 77 af 94


100 

0 

[mio DKK] 


Omkostninger 

Værdi af produkt - iterativ 

Værdi af produkt - vandfald 

INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Start Iteration Iteration Iteration Slut 

1 

2 

3 

Figur 23 Minimering af økonomisk risiko [egen tilvirkning] 

Vandfald versus Iterative modeller 

Tabel 3 sammenligner vandfald med den iterative model på en række karakteristika 

Karakteristika Vandfald Iterativ 

Primære mål Forudsigelighed, Stabilitet høj 

sikkerhed 

tid 

Fleksibilitet, ændringsparathed 

Størrelse Små og korte projekter Små til store projekter med middel 

til lang gennemløbstid 

Omgivelser Stabile, lav ændringsrate. Projekt 

og organisations fokuseret 

Kundeforhold ”As-needed customer interactions”, 

fokus på kontrakt overholdelse 

Planlægning og 

styring 

Der styres efter krav 

Dokumenteret planer, kvantitativ 

styring 

• Planlæg “alt” hvad der forventes 

at ske i projektet - “Plan the 

work” 

• Sikre at det, der sker, er planlagt 

– “Work the plan” 

o Directive management 

o Control, control, control 

• Anvend Change Control til 

håndtering af ændringer 

o Change Control Board 

o Defect Management 

Dynamiske med høj ændringsrate. 

Projektfokuseret 

Dedikeret ”onsite customer”, fokus 

på prioriteret features 

Der styres efter en vision 

Internaliseret planer, kvalitativ 

styring 

• Planlæg hvad der forventes at 

ske i nærmeste fremtid 

• Styr ved hjælp af tilpasning i 

forhold til feedback 

• Brug Agile metoder til håndtering 

af ændringer: 

o Kontinuert feedback 

o Iterative & incremental 

udvikling 

o Prioriteret fetatures 

(operationelle risici og 

kundeværdidrevet) 

Kommunikation Eksplicit dokumenteret viden Tavs interpersonel viden 

side 78 af 94


Karakteristika Vandfald Iterativ 

Krav Formaliseret projekt, kapacitet, 

interface, kvalitet. Overskuelig 

ændring af krav 

Udviklere I det de fleste opgaver er defineret 

på forhånd og der er SOP’er for det 

meste stilles der ikke krav op top 

kompetencer 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Prioriteret uformelle ”stories” og 

test cases 

Uoverskuelige ændringer til krav 

Store krav til kompetencer og 

kvalifikationer. Og måske lidt mere 

ekstrovert natur 

Kultur Styring via SOP’er Selvorganiserende grupper med 

stor frihedsgrad 

Metafor ”Dicke Bertha” – Er utrolig effektiv 

til mål der ikke bevæger sig, tager 

lang tid at indstille. 

”Stinger Missile” – Kan følge 

bevægelige mål er let og hurtig at 

affyre. 

Tabel 3: Sammenligning mellem vandfald og iterativ udvikling – egen tilvirkning 

med udgangspunkt i [Noter fra ITPR] 

side 79 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Appendix 3 Agil versus Iterativ udviklingsmodel 

Det agile manifest, [Agile Manifesto] giver nogle værdier, der skal indgå for at et 

projekt er agilt. Der er således ikke angivet nogen specifik udviklingsmodel eller 

andre metoder, værktøjer osv. 

Hjørnestenen i alle agile metoder er en iterativ udviklingsmodel med timeboxed 

iterationer, hvor specifikationer og planer udvikles og tilpasses igennem projektets 

løbetid. Men det betyder ikke, at alle iterative udviklingsmodeller er agile. Det 

afhænger af i hvor høj grad det agile manifest efterleves. Af Figur 24 fremgår det, at 

der ligeledes findes nogle metoder som er på grænsen til at være agile, som for 

eksempel Rational Unified Process, hvor især implementationen af denne model 

afgør, om den er agil eller ej. I sin oprindelige udgave opfylder Rational Unified 

Process ikke det agile manifest, blandt andet fordi krav relativt hurtigt i 

projektforløbet bliver mere eller mindre fastlåst. 

Figur 24: Iterative udviklingsmodeller versus agile metoder, oversat til dansk fra 

[Larman] 

En iterativ udviklingsmodel skal som udgangspunkt bestå af mere end et 

gennemløb, men kan bestå af mere eller mindre ceremoni. Ceremoni er et udtryk 

for, hvor formel metoden er, og udtrykkes ved et antal dokumenter, review, 

defineret proces osv., se Figur 25, hvor nogle forskellige udviklingsmetoder er 

placeret i forhold til hinanden. 

side 80 af 94


Lidt 

XP 

Scrum 


Iterationer 

Mange (korte, 5 dage) 

Een 

INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Rational Unified Proces 

Ceremoni 

(Formel tilgang) 

Meget 

Vandfald (med eet gennemløb) 

Figur 25: Kategorisering af udviklingsmetoder, modificeret og oversat til dansk fra 

[Larman] 

side 81 af 94


Appendix 4 Projekt usikkerhed 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Risikostyring handler om at forebygge og afbøde hændelser, der kan påvirke 

muligheden for at nå succesmålene. I projektledelse opereres med begreberne den 

operationelle og den kontekstuelle usikkerhed. 

Operationel risiko 

Den operationelle usikkerhed er den operationelle usikkerhed i projektet. Den er et 

udtryk for den usikkerhed, der kan være omkring opnåelse af projektmålet. Den 

operationelle usikkerhed = Den informationsmængde der er nødvendig for at udføre 

opgaven – minus: Den informationsmængde som på et givet tidspunkt er til 

rådighed for opgaveudførelsen [Christensen & Kreiner], se venstre side af Figur 26. 

Operationel usikkerhed er typisk relateret til, hvordan vi sikrer at produktet bliver 

færdigt, herunder teknologiske risici som igen er knyttet til usikkerheden om 

”HVORDAN” vi skal lave produktet. Den operationelle usikkerhed kan nedbringes 

ved at etablere operationelle mål og gennemføre en systematisk, realistisk 

planlægning baseret på disse mål og dernæst at følge planen. En detaljeret 

projektplan sikrer, at man ved at følge den trin for trin kan indfri det mål, der blev 

opstillet i starten af projektet. Operationel usikkerhed håndteres således med en 

lineær strategi. 

Kontekstuel risiko 

Den kontekstuelle usikkerhed er den eksterne usikkerhed og opstår, når kravene til 

projektmålet ændrer sig, fordi krav og muligheder i omgivelserne ændres. 

Kontekstuel usikkerhed = den viden og de præmisser projektet designes og 

planlægges på – minus: Det vidensgrundlag, de præmisser og læringsmuligheder 

som projektet evalueres på [Christensen & Kreiner], se højre side af Figur 26. 

Læring, omverdenens udvikling og så videre ændrer forudsætningerne for ethvert 

projekt; men for nogle projekttyper i langt højere grad end for andre. 

Kontekstuel usikkerhed knytter sig især til at lave ”det rigtige produkt”. Det knytter 

sig til usikkerheden om ”HVAD” vi skal lave for at få det rigtige produkt og dermed 

skabe kundetilfredshed. 

side 82 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Figur 26 Operationel og kontekstuel usikkerhed [Christensen & Kreiner] 

Der findes ingen midler til at eliminere den kontekstuelle usikkerhed med, dels fordi 

det der skaber den ligger uden for projektets rækkevidde og autoritet, og dels fordi 

den kun kan erkendes retrospektivt. Idet vi ikke kan eliminere den kontekstuelle 

usikkerhed, er det næstbedste at gøre sig åben overfor den, og håndtere den bedst 

muligt, fx ved at projektet, gentagne gange i projektforløbet, fremviser 

mellemstadier af produktet til kunderne. Kunderne får derved mulighed for at 

påvirke resten af projektet, samtidig med at projektet også påvirker kunden, idet 

kunden ser nye muligheder. Dette er en cirkulær tilgang hvor produktforståelsen og 

de handlinger, der er nødvendige for at lave det rigtige produkt bliver knyttet 

sammen med den kontekst projektet og kunden befinder sig i. Ydermere er det at 

projektet kommer ud og viser sit produkt kan påvirke omgivelserne, det vil sige, 

danner skole for særlige løsninger, der siden hen kan påvirke projektet gennem 

3die part (den globale landsby tankegang) se også Appendix 1. Dette er ikke en 

særlig elegant løsning eller rationel tilgang, men vinder dog formodentlig over en 

strategi, der fornægter eller negligerer ændringer i omgivelserne. 

side 83 af 94


Appendix 5 Projekttyper 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Projektopgaver kan grupperes i 3 opgavetyper: rutineopgaver, problemløsnings- 

opgaver og problemdefinitionsopgaver. I Tabel 4 er de 3 opgavetyper vist med nogle 

typiske karakteristika. Hvad opgaven er, hvordan den løses, om vi er sikre på hvad 

resultatet skal bruges til og hvor stor den operationelle usikkerhed er. 

Tabel 4 Karakteristik af opgavetyper, egen tilvirkning med inspiration fra 

[Mikkelsen & Riis] 

I den videre diskussion definerer vi 3 projekt arketyper: rutineprojektet, 

problemløsningsprojektet og problemdefinitionsprojektet. Projekt arketypen 

afhænger af projektets opgavesammensætning, se Figur 27. 

Figur 27 Opgavesammensætning i forskellige projekttyper [egen tilvirkning] 

side 84 af 94


Rutineprojektet 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Indeholder en klar overvægt af rutine prægede opgaver og kun få problemløsnings- 

og ingen problemdefinitionsopgaver. En metafor for denne projekttype er 

masseproduktion. Projektopgaven kan typisk nedbrydes i velafgrænsede 

delopgaver, der er målbare, både hvad angår anvendt arbejdstid og opnået 

kvalitet. Produktfrembringelsen er regel- og procedureorienteret, og ønsket er at 

standardisere og optimere arbejdsprocessen, så der undgås spild og opnås 

forudsigelighed og ensartethed. Det ligger implicit i definitionen af en rutineopgave, 

at den generelle usikkerhed er lav. Den operationelle usikkerhed er elimineret 

gennem stram planlægning. I rutineprojektet er det en acceptabel strategi at 

negligere den kontekstuelle usikkerhed - i det mindste indtil markedet efterspørger 

nye produkttyper, eller der opstår pres på omkostning og kvalitet fra konkurrerende 

produkter. Et eksempel på masseproduktion er bygning af typehuse, hvor alt er 

prøvet mange gange før og planlagt i detaljer. 

Figur 28 Bygning af typehus, et eksempel på et rutineprojekt 

Rutine projektet indplaceres med lav operationel risiko og høj kontekstuel risiko. 

Problemløsningsprojektet 

Er karakteriseret ved at opgaven er veldefineret, mens det er mindre klart, hvordan 

resultatet skal opnås. Projektet består af både rutine- og problemløsende opgaver. 

Metaforen er udviklingsprojektet. Denne projekttype indeholder typisk en ligelig 

blanding af rutine- og problemløsningsopgaver. Utzon's operahus kan ses som et 

kendt eksempel på denne type opgave. Det var rimeligt veldefineret, hvad der 

skulle laves i projektet, men hvordan tagkonstruktionen skulle udføres i praksis var 

ikke kendt. 

side 85 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

De oprindelige succesmål omkring omkostning og leveringstid blev defineret tilbage 

i 1957. Det oprindelige budget var på $7 millioner men endte på $102 millioner 

Ligeledes var den oprindelige leveringsdag planlagt til at være 26. Januar, 1963, 

men projektet blev ikke afsluttet før 1973 [Wikipedia]. Utzon's operahus er et 

eksempel på et projekt der havde store problemer med at håndtere den 

operationelle usikkerhed. Skønt byggeriet i sin samtid var en økonomisk skandale, 

er der nok ikke tvivl om, at eftertiden vil evaluere operahuset som en succes, med 

vital betydning for Sydney. 

Figur 29 Operahuset i Sydney, et eksempel på et problemløsningsprojekt 

De styringsrelaterede kompetencer, der var tilstrækkelige i rutineprojektet synes 

ikke at slå til her - der skal altså noget andet til, men hvad? Da Utzon ikke vidste, 

hvordan opgaven med tagkonstruktionen skulle løses, har han ikke kunnet 

eliminere den operationelle risiko ved opgaveplanlægning alene. På den ene side 

har det været nødvendigt med helhedssyn for at finde den rette 

tagkonstruktionsløsning, hvilket fordrer at projektet er åbent for inspiration fra 

omgivelserne. Denne åbenhed kræver at projektlederen tør operere med stor 

usikkerhed. På den anden side har det også været nødvendig med 

risikoplanlægning på de kendte områder, hvilket fordrer årsag-virkning analyse 

kompetencer hos projektlederen. 

Problemdefinitionsprojektet 

Projektet er karakteriseret ved at opgaven ikke er veldefineret, ligesom det heller 

ikke er klart, hvordan den skal løses. Metaforen for denne projekttype er forskning. 

Projektet indeholder problemløsnings- såvel som rutineopgaver, men også et antal 

problemdefinitionsopgaver. 

side 86 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

I projekter, der indeholder problemdefinerende opgaver, er det vanskeligt at vide 

på forhånd, præcist hvor projektet vil ende. At forvalte sådan et projekts 

dynamiske virkelighed som om den er statisk og forudsigelig, er urealistisk, 

risikabelt og i de fleste tilfælde uproduktivt. Det er derimod nødvendigt - og 

ønskeligt, at projektet kan håndtere frekvente og hyppige ændringer af kravene, 

for der igennem aktivt at sikre risiko eliminering og høj værdiskabelse. Ydermere 

kan en antagelse om, at kundens ønsker ikke ændrer sig gennem et sådant 

projektforløb, synes som en fundamental fejl i vandfaldsmodellen. 

Det er disse overvejelser, der ligger til grund for vores påstand om at det i de 

problemdefinerende projekter er nødvendigt at ændre fokus væk fra de traditionelle 

projektledelses tilgang, hvor alle kravene fastfryses tidligt i projektet, og i retning 

af en iterativ udviklingsstrategi, hvor det er tid og budget, der fastfryses. 

På grund af den manglende opgavedefinition kan projektet ikke drives af konkrete, 

veldefinerede mål. I stedet er det en vision, der driver projektet frem. Et eksempel 

er Apollo-projektet. Målet var at sætte en mand på månen inden for et årti, men 

det kan diskutere om det ikke snarere var en vision end et mål. Det er et spørgsmål 

om teknologien, der skulle bringe en mand til Månen, overhovedet fandtes på det 

tidspunkt projektet blev besluttet. Apollo-projektet havde et stort indhold af 

forskning - fx er integrerede kredsløb, teflon osv. et spin-off, som findes overalt i 

nutidens produkter. 

Figur 30 Apollo-programmet et eksempel på et problemdefinitionsprojekt 

side 87 af 94


Appendix 6 Projektsucces 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Standish Group er en amerikansk virksomhed, der har specialiseret sig i store 

undersøgelser, der indsamler information om ”real-life IT failures and 

environments”. Resultaterne udgives i en årlig Standish Group rapport, der giver et 

øjebliksbillede af, hvor gode virksomhederne er til at gennemføre IT-projekter. 

Standish Group startede i 1994 og har undersøgt mere end 35 000 IT projekter. 

Standish Group kategoriserer projekter efter følgende: 

• Succes: Projektet er færdigt til tiden, til prisen og med de fleste features 

• Udfordret: Projektet er færdigt for sent, for dyrt og/eller med færre features 

• Fejlslagne: Projektet er aflyst eller ikke brugt 

Der er lavet sammenlignelige målinger for 1994 og 2000, se Tabel 5 

Årstal 1994 2000 

Succes 16 % 28 % 

Udfordret 53 % 49 % 

Fejlslagne 31 % 23 % 

Tabel 5 Succesrate for projekter i 1994 og 2000 [Standish01] 

Ovenstående information kan ikke umiddelbart overføres til danske forhold. Men 

det indikerer at IT projekter, generelt set, forholdsvis sjældent opfattes som en 

succes. Samtidig må det konstateres at succesraten er blevet bedre fra 1994 med 

16 % succesfyldte projekter til 2000 med 28 % succesfyldte projekter. Standish 

Group kommer ikke med nogen direkte forklaring på denne forbedring. 

side 88 af 94


Aktuel brug af de implementerede krav 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Standish Group undersøgte, i et stort studie af IT-projekter, hvor meget brug der, i 

princippet, er af implementerede features defineret i tidlige kravspecifikationer. 

Konklusionen, se Figur 31, var at 45 % af de implementerede features aldrig blev 

brugt. 

Figur 31: Den aktuelle brug af implementeret features oversat til dansk fra 

[Standish01] 

Det bør dog bemærkes, at det ikke er præciseret, hvilke type projekter det drejer 

sig om, andet end at de var udviklet efter vandfaldsmodellen, og at de er fra 

samme base af projekter som indikeret i [Standish01]. Derfor kan resultaterne ikke 

bruges som andet end en retningsgiver, og en stærkere argumentation kan kun 

opnås ved adgang til de data, undersøgelsen bygger på. 

Recepten for projekt succes: The CHAOS Ten 

Hvad skaber succesfulde projekter? Tabel 6 viser de 10 vigtigste succesfaktorer, 

the CHAOS Ten, identificeret i 2001 af Standish Group. Hver faktor er vægtet i 

forhold til faktorens indflydelse på et projekts succes, jo højere tal, jo vigtigere for 

side 89 af 94


projektets succes. 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

I Tabel 6 har vi, hvor det giver mening, relateret de enkelte succesfaktorer til 

leadership tilgangen. 

Succesfaktor Relation til leadership tilgangen % 

Ledelsens opbakning Ikke specifik for leadership tilgangen. Men det 

kan hævdes at en leadership tilgang måske 

kan forøge ledelsens opbakning, idet 

leadership også handler om at involvere 

interessenter. 

Bruger involvering 

Dette er en af hjørnestenene i at reducere 

kontekstuel usikkerhed. Og løbende åbenhed 

overfor brugere/kunder kræver en leadership 

tilgang 

Erfaren projektleder 

Efter vores mening også en forudsætning for 

leadership tilgangen. 

Klare forretningsmål Ikke specifik for leadership tilgangen. 12 

Begræns omfang (begræns 

antallet af features i 

projektet) 

Ikke specifik for leadership tilgangen. 10 

Standard software 

infrastruktur 


Robuste basale krav Der kan være lighedspunkter med 

visionsbegrebet som retningsgiver i leadership 

tilgangen. 

6 

Formel projektledelses 

metodik 


Pålidelige estimater Ikke specifik for leadership tilgangen. 5 

Andre faktorer (kompetente 

projektdeltagere, og 

ordentlig planlægning) 


Tabel 6: De 10 Succesfaktorer i følge Standish Group ("The Chaos Ten"), oversat til 

dansk fra [Standish01], tilføjet vores kommentarer omkring leadership tilgang. 

Det skal bemærkes at nogle af de ovenstående succesfaktorer, som fx pålidelige 

estimater, måske mere er en management tilgang. Men det indikerer at når det 

gælder succes i projekter ikke er et spørgsmål om enten en management tilgang 

eller en leadership tilgang. 

18 

16 

14 

side 90 af 94


Appendix 7 Hvad er viden? 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Videndannelse forudsætter kognitiv aktivitet. Med udgangspunkt i Boisot’s 

videnmodel [Jensen, Mønsted & Olsen] og videnformer fra [Petersen & Østergaard] 

kan videndannelse vises som vist på Figur 32. Viden starter som data, der skal 

passere de perceptuelle og konceptuelle filtre. Disse filtre lader kun bestemte data 

"passere", idet en person modtager data svarende til millioner af bits i sekundet, 

men bevidstheden kan kun håndtere en promille af denne datamængde 

[Nørretranders, side 165]. Data, der passerer filtrene bliver til information, som 

derefter bliver bearbejdet og integreret som viden. 

”Fly SK70 afgår 

fra gate 27” 

Perception 

(filter) 

”Jeg skal være ved 

gaten om 5 minutter” 

Figur 32 Model for videndannelse [egen tilvirkning] 

Kognitiv 

aktivitet 

”Jeg skal gå 

mod gaten nu” 

Viden som produkt knytter sig til erhvervsøkonomiske betragtninger (rationalistisk 

og artefaktbaseret vidensyn), der fokuserer på produktet eller resultatet. Her bliver 

viden noget konkret der eksisterer i sig selv. Viden kan kodificeres, opbevares og 

lagres (ekspliticeres). Videnledelse drejer sig fx om at få viden, som produkt 

(dokumentation), lagret i virksomheden, frem for at viden forbliver i hovederne på 

de enkelte videnmedarbejdere. QMS (procedurer og standarder), databaser har alle 

det formål at lagre viden, så den kan blive anvendt af andre. Dette vidensyn 

fokuserer på genbrug, nytte og øget effektivitet. 

side 91 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Viden som proces (social-psykologisk procesorienteret vidensyn) involverer læring 

og problemløsning, idet det handler om at bruge eksisterende viden til at skabe ny 

viden. Viden er subjektiv, værdi- og erfaringsbaseret og skabes ved social 

interaktion mellem individer (Stacey/Tsoukas). Det er her der tales om viden på 

forskellige former, fra "tavs viden" [Polanyi i Jensen, Mønsted & Olsen, side 56] til 

hvilken rolle den spiller, og hvordan tavs viden kan transformeres til eksplicit viden 

[Nonaka & Takeuchi i Jensen, Mønsted & Olsen, side 42]. Viden som proces 

inkluderer også muligheden for refleksion over de antagelser, der ligger til grund 

for denne viden, hvilket kan resultere i ændring af disse gennem "double-loop 

learning" [Argyris i Jacobsen & Thorsvik side 340]. Videndeling handler om at skabe 

rammerne for dialog og samspil mellem individer. 

Endelig inddrages visdom, erfaring og intuition, når viden bliver til handling i 

praksis. Viden som handling i praksis kobler den enkeltes videnkompetencer med 

den konkrete situation og kontekst [Stacey i Jensen, Mønsted & Olsen side 62]. 

Kompetence forstås her som evnen til at mobilisere viden i samspil med andre på 

rette tid og rette sted. Der sondres mellem at have viden eller at være vidende, og 

at være i stand til at vide, hvordan og hvornår denne viden bedst kan anvendes. 

[Petersen & Østergaard] deler viden op i 4 videnformer: Handle-, Refleksiv-, fælles- 

og offentligviden. Handleviden er tavs viden, fælles viden er både tavs og eksplicit 

viden hvor refleksiv og offentlig viden er eksplicit viden I videnmodellen [Petersen 

& Østergaard] skelnes der desuden mellem subjektiveret viden, dvs. viden der kun 

eksisterer i det enkelte individ, og objektiveret viden er viden der kan eksistere 

uafhængigt af det enkelte individ. 

Den enkelte person kan have gemt viden i hovedet som både eksplicit og tavs 

viden. Noget af personens eksplicitte viden kan også være i bøger, rapporter, 

dokumenter som så tilgås via meta-viden. Desuden må noget af den viden en 

person har, kan være skjult, dvs. der er ikke sat ord på så den er eksplicit. Denne 

opdeling er søgt illustreret i Figur 33. Forholdet mellem videnformerne er fortegnet, 

ifølge Nonaka udgør tavs og skjult viden 90 % af den samlede viden. 

side 92 af 94



INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Figur 33 Opdeling af personlig viden [egen tilvirkning] 

side 93 af 94


Appendix 8 Agil litteratur 


INGENIØR 

HØJSKOLEN 

KØBENHAVN 

Siden fremkomsten af det agile manifest i 2001 er der kommet rigtig meget 

litteratur om emnet. Fælles for litteraturen er at de, med meget få undtagelser, alle 

er på engelsk. En søgning på internetboghandlen saxo.com finder ingen danske 

bøger hvor ”agil” indgår, men 100+ bøger på engelsk. En søgning på google, 11. 

december 2007 efter ”agile” giver 19.500.000 på hele nettet, 1.940.000 hits på 

engelsk og 26.100 på dansk. 

Figur 34 Et lille uddrag af bøger om agil udvikling 

I denne opgave har vi anvendt en del bøger om agil udvikling, men det er bare en 

brøkdel af udbuddet, de bøger vi har anvendt fremgår af afsnit 6. 

side 94 af 94

Agil Projektledelse

Create successful ePaper yourself

Delete template?

Save as template?