Agilitet i store projekter

Agilitet i store projekter - tag tyren ved hornene "What's needed is not at single software methodology, but a rich toolkit of process patterns and 'methodology components' (deliverables, techniques, process flows, and so forth) along with guidelines for how to plug them together to customize a methodology for any given project." (McCormick i Vanhanen, Jartti & Kähkönen, 2003, s. 2) Cand.it i IT, Kommunikation og Organisation Handelshøjskolen i Århus Speciale på 4. semester, afleveret 1. juni 2007 Henrik Jensen Kim Søvsø Pedersen Vejleder: Søren Erik Nielsen Afhandlingen eksklusiv bilag må gøres elektronisk tilgængelig

Forord Valget af agilitet i store projekter som specialeemne bygger på en fælles interesse for systemudvikling og projektledelsesdisciplinerne teamwork og kommunikation, som har en central plads i det agile paradigme. Med udgangspunkt i en opfattelse af agil udvikling som den ideelle udviklingsfilosofi har vi fået øjnene op for den spændende udfordring fra kompleksitet i det store projekt og det behov for plandrevenhed, kompleksiteten skaber. Interessen for at finde balancen mellem behovet for agilitet og behovet for planstyring og en fortsat interesse i at trække projekter i en agil retning, har hjulpet os med at bevare engagementet de seneste fire måneder. Tak til vores vejleder Søren Erik Nielsen. Hans praksisnære tilgang til projektledelsesfeltet har inspireret os til at afsøge grænselandet mellem den videnskabeligt orienterede og den praksisorienterede del af forskningsfeltet projektledelse. Ligeledes vil vi sige tak til Ole Jepsen fra goagile, for at have taget tid til at give kritik på vores indledende modelarbejde, samt for at lede os på sporet af Todd Littles projektprofileringsværktøj. Allerstørst tak skal dog lyde til vores søde kærester, Nina og Anne, som har måttet lægge øre til megen indforstået og uforståelig tale de seneste fire måneder. Specialerapporten er udarbejdet i perioden 18. januar til 1. juni 2007. i

Summary The background for the study in this thesis is a shared interest in the principles behind agile system development; informal communication, collocated developers, frequent releases and many more. Supported by influential methodologists such as Alistair Cockburn, Barry Boehm and Rich Turner as well as practically oriented project management experts such as Jutta Eckstein, we have come to realize the importance and relevance of agility in large, complex projects. This type of projects is sometimes necessary to fulfill the market expectations of tomorrow. Since these projects require both agile flexibility and plan-driven steering to reach their goals, guidelines are needed to tailor and stretch agile methods to work within this context. The need for freedom as well as control in these complicated projects has been coined by Todd Little in the bull project metaphor. The main purpose of this thesis is to create a framework for the guidelines needed for the bull projects. This framework will be a model for methodology design tailored to specific project profiles. In order to create this model the thesis gives a basis for a thorough understanding of the characteristics and challenges of a project organization in the traditional context, where the projects often take place. These preagility issues are believed to be of great importance to the tailoring of a project methodology that takes into account the current project needs as well as the organizational background. Secondly the thesis discusses ways to operationalize the project and the organizational characteristics into a meaningful and comparable project profile. Profiling the projects in the portfolio of an organization makes it possible to identify the most straightforward ones, which fall into the home ground of either agile or plan-driven standard methodologies. Profiling and comparing projects in the portfolio makes it easier to evaluate and share best practices across projects. It also simplifies planning and resource allocation by making the few but demanding bull projects stand out. The methodology for the bull project is designed by applying patterns concerning organizational and technical best practices having proved successful in similar projects. ii

Tailoring a methodology for a bull project is not for everybody. The target group for the resulting model, called the Bullfighter model, consists of competent project managers highly experienced with the human aspects of project management as well as traditional disciplines such as risk and stakeholder management. The primary method in creating the model has been a study of theory of methodology and project management in system development, focusing on the identification of aspects of the project and the project organization significant to the application of agile methodology components in the bull project. The focus on generally applicable patterns for any bull project has resulted in a minimum of empirical research. To test the model for operationality we have used a case test approach to reveal strengths and weaknesses in the model. For the purpose of verifying the scientific validity of the model as well as gaining the confidence of the intended audience, further testing by application to actual bull projects will be needed. The primary result of the thesis is the four-step Bullfighter model for methodology design coined in Figur 1 below. The Bullfighter Model 1 Pre-analysis 2 Project profiling Project initiation / Reevaluation 4 Methodology design 3 Risk analysis Figur 1 The Bullfighter model iii

Læsevejledning Denne læsevejledning vil præsentere specialerapportens struktur og sammenhængen mellem de enkelte dele med det formål at give læseren et overblik over rapportens indhold. Ligeledes præsenteres her specialets centrale produkt, Bullfighter-modellen, som er vist på Figur 2 herunder, samt relationen mellem specialet og modellens indhold. Modellens konkrete indhold og funktion præsenteres senere i specialerapporten, men modellen anvendes her til at give læseren et overblik over sammenhængen mellem modellens fire trin og specialerapportens indhold. Bullfighter-modellen 1 Foranalyse 2 Projektprofilering Projektstart / Revurdering 3 Risikoanalyse 4 Metodologisammensætning Figur 2 Bullfighter-modellen Specialerapportens indledning og problemanalyse præsenterer det generelle problemfelt og de specifikke problemstillinger der arbejdes med. Herefter præsenteres specialets videnskabsteoretiske og metodiske ståsted og det konkrete undersøgelsesdesign, som specialet er udarbejdet efter i afsnit 3 - Metodisk tilgang og afsnit 4 - Undersøgelsesdesign. iv

I afsnit 5 - Problembarnet: Det store projekt udfoldes problemområdet og afsnittet behandler den type udviklingsprojekter, som dette speciales fokus er rettet mod. De to efterfølgende afsnit, 6 - Præagilitet: Usikkerhed og forandring i udvikling og 7 - Præagilitet: Agil i en traditionel verden, behandler den paradigmatiske og organisationelle kontekst, hvori det store projekt befinder sig og anerkender behovet for at finde en afbalanceret tilgang til tilrettelæggelse af projektet. I forhold til modellen på Figur 2 behandler disse tre afsnit den første boks, som definerer projektets kontekst og modellens trin 1. Diskussionen om behovet for at tilrettelægge en metodologi for projektet udfoldes yderligere i afsnit 8 - Balancen: En metodologi per projekt, som omhandler modellen generelt og i afsnit 9 - Behov for operationalisering: Eksisterende modeller, hvor en række modeller og værktøjer til identificering af et projekts karakteristika og tilrettelæggelse af en sammensat metodologi for projektet diskuteres. Sidstnævnte afsnit behandler Bullfighter-modellens trin 2. I afsnit 10 - Fundamentet: Projektprofilering med Little-modellen uddybes en af de præsenterede modeller. Denne model udgør fundamentet i den sammensatte Bullfightermodel, som er produktet af dette speciale. I afsnit 11 - Profilering: Paradigmernes home grounds profileres de tidligere præsenterede paradigmer i modellen, med det formål at klarlægge paradigmernes væsentlige forskelle, styrker og svagheder. Disse afsnit omhandler Bullfighter-modellens trin 2, 3 og 4. Afsnit 12 - Operationalisering: Bullfighter-modellen præsenterer den samlede model for tilrettelæggelse af en metodologi for det store projekt. I afsnit 13 - Afprøvning: Amandaprojektet afprøves modellen på et virkeligt projekt og modellens styrker og svagheder identificeres. Som afslutning på denne specialerapport evalueres specialets fremgangsmåde og resultater i afsnit 14 - Diskussion og kritik. Dette munder ud i afsnit 15 - Konklusion, hvor v

resultaterne og besvarelsen af problemformuleringen præsenteres samt afsnit 16 - Perspektivering, hvor specialet og modellen anskues i et bredere perspektiv. Sidst i specialerapporten findes en litteraturliste, en referenceliste, Appendiks A, der indeholder en profil af en konkret metodologi og Appendiks B med eksempler på de metodologi-mønstre, der henvises til i specialerapporten. Bag i specialerapporten findes en CD-ROM med anvendt litteratur fra Internettet i PDF-format. Der vil i specialerapporten blive anvendt en række centrale begreber, som vi her vælger at præsentere for at tydeliggøre vores anvendelse af begreberne. Enkelte af begreberne fremgår allerede af ovenstående. Det drejer sig om begrebet metodologi, som her anvendes som betegnelse for en konkret udviklingsorganisations arbejdsmetode og - proces, der kan ligge mere eller mindre tæt op ad et systemudviklingsmæssigt rammeværk, som eksempelvis Extreme Programming eller Unified Process, men som også håndterer samarbejde og andre bløde aspekter. Vi læner os dermed op af den engelske betegnelse, methodology, for det, der på dansk oftest hedder metode (som eksempelvis i systemudviklingsmetode). Dette er valgt, da vi mener den engelske variant bedre rummer det aspekt, der handler om at tilpasse og sammensætte en systemudviklingsmetode - eller metodologi - til et en specifik situation; altså at begrebet er bredere favnende. Et andet centralt begreb er plandreven systemudvikling, der betegner den del af systemudviklingsverdenen, som tager afsæt i og lader projektet styre af kort- og langsigtet planlægning. Vi har valgt at anvende dette begreb i stedet for begrebet traditionel systemudvikling, da dette begreb ikke klart udtrykker de planlægningsmæssige karakteristika, som udgør et væsentligt element i denne tilgang til systemudvikling. God læsning. vi

Indholdsfortegnelse 1. INDLEDNING... 1 2. PROBLEMANALYSE... 5 2.1. PROBLEMFORMULERING... 7 2.2. UDDYBNING AF PROBLEMFORMULERING... 7 2.3. AFGRÆNSNING... 8 3. METODISK TILGANG...11 3.1. VIDENSKABSTEORETISKE OVERVEJELSER...11 3.2. METODE...14 3.3. OPSUMMERING...16 4. UNDERSØGELSESDESIGN...17 4.1. UNDERSØGELSESOBJEKTET...17 4.2. VALG AF UNDERSØGELSESMETODE...17 4.3. KVALITETSSIKRING...19 4.4. KRITIK AF UNDERSØGELSESDESIGN...19 4.5. OPSUMMERING...20 5. PROBLEMBARNET: DET STORE PROJEKT...21 6. PRÆAGILITET: USIKKERHED OG FORANDRING I UDVIKLING...23 6.1. PLANDREVEN SYSTEMUDVIKLING...24 6.2. AGIL SYSTEMUDVIKLING...28 6.3. SPÆNDINGSFELTET - ET SPØRGSMÅL OM KULTUR?...33 6.4. AGILT OG PLANDREVEN I FORENING - RAMMEUDVIKLINGSMODELLER...35 6.5. OPSUMMERING...38 7. PRÆAGILITET: AGIL I EN TRADITIONEL VERDEN...39 7.1. AGIL I EN TRADITIONEL ORGANISATION...39 7.2. AGIL I EN TRADITIONEL FORRETNINGSVERDEN...46 7.3. FRA TRADITIONEL TIL AGIL...52 7.4. OPSUMMERING...56 8. BALANCEN: EN METODOLOGI PER PROJEKT...57 8.1. COCKBURNS KOMPETENCENIVEAUER...57 8.2. OM METODOLOGI: EN DEFINITION...58 8.3. FORMÅLET MED EN METODOLOGI...62 8.4. REPRÆSENTATION AF METODOLOGIEN...63 8.5. METODOLOGI PER PROJEKT...64 8.6. OPSUMMERING: ADAPTION AF EN METODOLOGI...73 9. BEHOV FOR OPERATIONALISERING: EKSISTERENDE MODELLER...74 9.1. EKSISTERENDE MODELLER: VURDERINGSKRITERIER...75 9.2. OPSUMMERING...87 10. FUNDAMENTET: PROJEKTPROFILERING MED LITTLE-MODELLEN...89 10.1. EVALUERING: DIMENSIONERNE KOMPLEKSITET OG USIKKERHED...89 10.2. MODELLENS UNDERDIMENSIONER...90 10.3. INDPLACERING I HOUSTON-MATRICEN...94 10.4. HOUSTON-MATRICENS BIDRAG TIL HÅNDTERING AF BULLS...95 10.5. OPSUMMERING OG AFGRÆNSNING AF LITTLE-MODELLENS RELEVANS...95

11. PROFILERING: PARADIGMERNES HOME GROUNDS...97 11.1. DET PLANDREVNE PARADIGMES HOME GROUND...98 11.2. DET AGILE PARADIGMES HOME GROUND...105 11.3. HOUSTON WE HAVE A PROBLEM...111 11.4. OPSUMMERING...112 12. OPERATIONALISERING: BULLFIGHTER-MODELLEN...114 12.1. MÅLGRUPPE OG FORMÅL...115 12.2. TRIN 1: FORANALYSE: PROJEKTETS KARAKTER OG PRÆAGILITET...118 12.3. TRIN 2: PROJEKTPROFILERING: MED LITTLE-MODELLEN...121 12.4. TRIN 3: RISIKOANALYSE: EN RISIKOBASERET METODE...123 12.5. TRIN 4: METODOLOGISAMMENSÆTNING: VALG AF MØNSTRE...125 12.6. REVURDERING...127 12.7. KRITIK...128 12.8. OPSUMMERING...128 13. AFPRØVNING: AMANDA-PROJEKTET...130 13.1. PRÆSENTATION AF CASEN...131 13.2. GENNEMGANG AF MODELLEN...131 13.3. OPSUMMERING: EVALUERING AF MODELLEN OG CASETILGANGEN...145 14. DISKUSSION OG KRITIK...148 15. KONKLUSION...151 16. PERSPEKTIVERING...155 17. LITTERATURLISTE...157 18. REFERENCELISTE...162 APPENDIKS A: PROFILERING AF UDVIKLINGSMODEL: SCRUM...163 APPENDIKS B: MØNSTRE...169 BILAG 1: CD-ROM

1. Indledning I disse år oplever vi et kultursammenstød overalt i samfundet og især på arbejdspladserne. På den ene side står en kultur, der lægger vægt på stabilitet, bevarelse, forvaltning, reglementeret orden, tryghed, miljø, formelt demokrati, millimeterretfærdighed og bureaukrati. På den anden side står en kultur, der lægger vægt på fornyelse, synlighed, dynamik, udfordringer, situationsbestemt samarbejde og decentral styring. Vi har allerede set sammenstødet mange steder. (Munk-Madsen, 1996, s. 5f) Munk-Madsens betragtninger om de kulturelle forandringer i samfundet var yderst relevante, da han formulerede dem i 1996 og er det til stadighed i dag. Vi lever i en omskiftelig verden på mange måder ikke mindst i it-branchen, hvor nye teknologiske muligheder og enorme økonomiske potentialer skaber forandringer overalt. Virksomheder bliver mere og mere afhængige af it og investerer stadigt stigende beløb på nye systemer, der skal sikre konkurrencemæssige fordele. De store investeringer er nødvendige, for systemudvikling er en bekostelig affære. I 2004-udgaven af The Standish CHAOS Report 1 opgjorde The Standish Group, med baggrund i undersøgelser af op mod 40.000 it-projekter, det samlede beløb anvendt til udvikling af software i USA i 2004 til $255 mia. I samme rapport gøres status på succesraten for softwareprojekter. Ifølge The Standish Group fejlede 15 % af alle softwareprojekter i USA i 2004. Dertil kommer, at 51 % var problemfyldte som følge af overskridelse af tidsplaner eller budgetter eller grundet mangelfuldhed i forhold til de opstillede krav. Kun 34 % af alle softwareprojekter i USA i 2004 blev dermed karakteriseret som værende succesfulde. It-systemer udvikles for at tilføre organisationer værdi i form af forretningens overlevelse, øget effektivitet, potentielle konkurrencefordele, eller som følge af eksterne faktorer såsom ændringer i lovgivning, privatisering, fusioner m.m. (Cadle & Yeates 2004, s. 2). Når 66 % af alle softwareprojekter enten fejler eller er problemfyldte, er der 1 http://www.softwaremag.com/l.cfm?doc=newsletter/2004-01-15/standish - tilgået 03-05-2007 1

altså, ud over det økonomiske tab direkte forbundet med afviklingen af projekterne, et enormt tab afledt af forsinkede, forkerte, fejlfyldte eller på anden måde fejlslagne itsystemer. Der er således et stort økonomisk incitament til at øge andelen af succesfulde it-projekter. Men hvorfor fejler så mange it-udviklingsprojekter? Systemudvikling som faglig disciplin er efterhånden en mangeårig tradition, der er dybt forankret i kulturen i faget. Traditionel, plandreven systemudvikling har baggrund i en tanke om, at hvis blot man går grundigt nok til værks, så kan man forudsige alle krav til et system og på den måde sænke et projekts omkostninger ved at eliminere risikoen for, at der sker ændringer i kravene. Denne tilgang til systemudvikling har affødt serielle, strukturerede processer, som har haft til formål at forebygge eller forhindre ændringer i projektets forløb. Den plandrevne tilgang til systemudvikling tager derfor udgangspunkt i, at ændringer opstår som følge af fejl internt i udviklingsprocessen; at fejl opstår fordi man ikke er god nok til at identificere eller opstille krav, eller at man ikke er god nok til at styre udviklingsprocessen. Men hvad med de fejl, som opstår som følge af eksterne påvirkninger, såsom ændringer i kundens krav, i systemets omfang, i den kontekst hvori systemet skal anvendes, i forretningsbetingelserne eller i den anvendte teknologi? Disse påvirkninger er alle af ekstern karakter og altså noget, som er uden for udviklingsorganisationens indflydelse. Fordi man ikke kan eliminere og kun i ringe grad påvirke disse eksterne faktorer, er der kun én logisk strategi, man som udviklingsorganisation kan anlægge; i stedet for at forsøge at eliminere muligheden for ændringer skal man sænke de omkostninger, der er forbundet med at reagere på ændringerne (Cockburn, 2001; 2006). Der er ofte en sammenhæng mellem et systemudviklingsprojekts størrelse og graden af strukturering, styring og planer; jo større et projekt er, jo mere fokus er der på at følge en fastlagt proces og en fastlagt plan. Denne tilgang er dog problematisk i forhold til den omskiftelige verden, som de fleste store projekter lever i; en lineært struktureret og rigid proces vil sjældent være den bedste måde at håndtere forandringer på. Små projekter er derimod af en anden natur. Der er ofte et lille deltagerantal, som gør at deltagerne i højere grad kan kommunikere, videndele og interagere med hinanden og dermed hurtigere kan 2

reagere på forandringer. Hvor plandreven systemudvikling læner sig op af Munk- Madsens første kulturgruppe, som lægger vægt på stabilitet, forvaltning og reglementeret orden, er der i softwareindustrien i sidste halvdel af 1990erne opstået en modbevægelse der, som Munk-Madsen ligeledes beskriver tendensen, lægger vægt på dynamik, situationsbestemt samarbejde og decentral styring. Drivkraften i modbevægelsen er et opgør imod plandreven systemudviklings rigiditet, strukturering og høje grad af fokus på planer og processer gennem et øget fokus på slutproduktet, individer, samarbejde og forandringsparathed. Bevægelsen kalder tilgangen for agil systemudvikling. Ordbogen definerer begrebet således: a gil (lat. agilis, af agere handle, gøre) rask, bevægelig, adræt (Gyldendals Fremmedordbog, 2001) Den gren af systemudviklingsbranchen, der er skolet i den traditionelle verden, er ved at få øjnene op for de ræsonnementer, der ligger bag opblomstringen af den agile modbevægelse og de fordele, man opnår ved øget bevægelighed og adræthed og mindre afhængighed af planer og processer, for alle i branchen ønsker at opnå en højere succesrate for systemudviklingsprojekter. Men de, der er af den gamle skole, anvender netop ofte den strukturerede tilgang i store projekter, hvor styring og planlægning anses for nødvendig; der er mange deltagere, hvis aktiviteter skal planlægges og koordineres, der er stort behov for kommunikation i kraft af de mange deltagere, som endda kan være spredt over store fysiske afstande og det er et stort og måske missionskritisk system, der skal udvikles. Alligevel er der i branchen et stort ønske om at kunne håndtere forandringer bedre; at kunne skalere den agile tilgang op og anvende den i store projekter, på trods af de store risici, der er forbundet hermed. Dette udtrykkes i nedenstående citat: 3

Scaling of agile methods will continue to happen whether you like or not. [..] While several participants, especially Martin Fowler in his keynote address, argued that scaling of XP and agile projects was probably the last thing one would want to do, most delegates agreed it would happen anyhow. Because of the communal push for scaling, it was agreed that people would do it even when warned that it was the wrong thing to do. (Reifer, Maurer & Erdogmus, 2003, s. 4) På denne baggrund er der en bred erkendelse af, at der er behov for opstilling af retningslinjer for håndtering af de store udfordringer: All agreed that guidelines for scaling [agile methods] were needed. (Reifer, Maurer & Erdogmus, 2003, s. 2) Når den agile tilgang tager udgangspunkt i løs struktur og interaktion mellem individer og hele grundideen har sit udspring i små projekter med få, tætte deltagere, kan man så uden nærmere eftertanke anvende tilgangen i store projekter med mange deltagere? Hvilke kulturelle og organisatoriske udfordringer giver det? Hvad er et stort projekt overhovedet? Hvilke karakteristika kendetegner den agile tilgang til systemudvikling? Hvilke uoverensstemmelser er der mellem det store projekt og den agile tilgang og ikke mindst: Hvordan kan man bruge mønstre og principper fra den agile tilgang til at tilføre agilitet til store projekter? Den følgende problemanalyse vil uddybe udgangspunktet for specialets behandling af nogle af disse spørgsmål. 4

2. Problemanalyse Specialets problemstilling omkring anvendelse af agil systemudvikling i store projekter er inspireret af et konferenceresumé, hvor 35 professionelle fra systemudviklingsverdenen behandler problematikker og udfordringer ved agil systemudvikling (Reifer, Maurer & Erdogmus, 2003). I artiklen identificeres skalering af agile systemudviklingsmetoder til brug i store projekter som en væsentlig problemstilling i relation til moderne systemudvikling. Forfatterne nævner, at det i disse projekter vil være nødvendigt at blande agile og plandrevne metodeelementer. Det er det, fordi der er en stor interesse fra systemudviklingsindustrien for at kunne udnytte fordelene ved de agile udviklingsmodeller uden for den traditionelle agile andedam af projekter, der passer til de agile metoder. Dette gør problematikken yderst relevant at beskæftige sig med. Konferenceresuméet giver et konkret bud på, hvad der afgrænser denne mængde af projekter: A sweet-spot agile project is typically characterized by a small, self-organizing, collocated team of less than 20 developers and one or more on-site customers, together working on a variable-scope application with unstable or emergent requirements, and the predominance of an oral culture based on high-bandwidth face-to-face communication. (Reifer, Maurer & Erdogmus, 2003, s. 2) Mange projekter falder naturligt udenfor denne mængde af projekter, fordi de er underlagt andre vilkår. Det gælder store projekter i særlig grad, da de afviger fra de agile projekter på flertallet af områderne. I modsætning til det agile projekts få deltagere har det store projekt ofte mange projektdeltagere, og deltagerne kan være spredt over stor geografisk afstand. Der er ofte en mere formel og formelt ledet projektorganisation, og projektorganisationen har ofte en dokumentbaseret kommunikationskultur, i modsætning til de agile projekters fokus på interpersonel kommunikation. Der er ofte vanskelig eller ingen adgang til kundeorganisationen gennem hele udviklingsforløbet. 5

Den agile tilgang til systemudvikling skal, på baggrund af hele filosofien om løsrivning fra strukturer og bureaukrati, ikke ses som et sæt færdige metoder og standarder, der kan trækkes ned over ethvert projekt, som så bliver agilt. Det er netop nærmere en filosofi eller et tankesæt. Som følge heraf kan og skal de forskellige metoder og processer i det agile paradigme ses som en værktøjskasse, hvorfra man kan vælge og vrage delelementer og skræddersy netop den metodologi, som passer til et konkret projekt, som citatet herunder tydeliggør: "What's needed is not at single software methodology, but a rich toolkit of process patterns and 'methodology components' (deliverables, techniques, process flows, and so forth) along with guidelines for how to plug them together to customize a methodology for any given project." (McCormick i Vanhanen, Jartti & Kähkönen, 2003, s. 2) Agile metoder hjælper til at opfylde nogle ønskelige mål for udviklingsprojekter, blandt andet at man får det rigtige produkt leveret hurtigt, og at udviklingsorganisationen er i stand til at omstille sig til nye eller ændrede krav hurtigt. Der er derfor stor interesse blandt praktikere i det plandrevne systemudviklingsparadigme for at kunne udnytte fordelene, som de agile metoder tilbyder. Der er dog samtidig mangel på retningslinier og værktøjer, som kan hjælpe projektlederen med at navigere i den agile værktøjskasse og tilrettelægge store projekter med en agil tilgang. Med dette udgangspunkt vil vi undersøge det store projekts vilkår og kultur og den betydning, disse forudsætninger har for projektet, for derudfra at kunne opstille en model, der giver guidelines til sammensætning af en metodologi til projektet samt optimerer resourceanvendelsen i projektorganisationen. 6

2.1. Problemformulering Der er, afledt af problemanalysen, tale om tre centrale problemstillinger i dette speciale, hvorfor specialets problemformulering er: 1. Hvad karakteriserer det store projekt, organisationen og kulturen omkring projektet og de vilkår, projektet fungerer under? 2. Hvordan kan en projektleder ved hjælp af en operationel model vurdere sit kommende projekts kompleksitet og usikkerhed og derudfra sammensætte den mest agile metodologi, som passer til det konkrete projekt? 3. Hvordan kan modellen anvendes både til planlægning og evaluering af projekter i organisationens projektportefølje? 2.2. Uddybning af problemformulering De tre problemstillinger vil her blive uddybet kort med formålet at give en forståelse for vores tilgang til besvarelsen af de stillede spørgsmål. Det store projekt kan eksistere i en større eller mindre organisation og størrelsen på projektet kan derfor betragtes som relativ. I dette speciale antages dog en absolut betragtning, hvorfor det store projekt typisk vil finde sted i en relativt stor organisation. I forståelsen af det store projekt, organisationen og kulturen omkring projektet og dets vilkår er det derfor relevant at beskæftige sig med spændingsfeltet mellem det plandrevne paradigme, som ofte er organisationens udgangspunkt og det agile paradigme, hvis principper skal integreres. Forståelsen for betingelserne for agilitet i en traditionel verden er desuden en forudsætning for sammensætningen af en metodologi, der er tilpasset det konkrete projekt. Med betegnelsen projektleder forudsættes en person med en væsentlig erfaring med projektledelse i systemudviklingsprojekter og med tilpasning af arbejdsprocesser. Modellens operationalitet karakteriseres ved at den giver retningslinjer for, hvilke 7

metodologikomponenter, der er relevante i forhold til det konkrete projekt. Modellen er ikke tænkt som en metodologigenerator, men som en beslutningsstøttende model for den selvstændige projektleder. Formuleringen den mest agile metodologi indikerer, at agilitet i metodologien i sig selv er ønskeligt. En væsentlig pointe er dog, at metodologien kun skal skabe så meget agilitet, som projektets vilkår giver grundlag for. Modellens sekundære anvendelse, at bidrage til planlægning og evaluering af projekter i organisationens projektportefølje, er en udløber af den primære anvendelse, metodologisammensætning, og forudsætter derfor, at modellen er anvendt til dette eller til profilering af tidligere projekter i organisationen. Formålet er videndeling internt i projektteamet, videndeling på tværs af lignende projekter og prioritering af ressourcer til de mest opmærksomhedskrævende projekter. Prioriteringen af ressourcerne og optimering af videndelingen er en forudsætning for at kunne håndtere de store, komplekse og usikre projekter. Med dette brede udgangspunkt behøves en yderligere afgrænsning af specialets problemfelt. Denne afgrænsning vil blive foretaget i det kommende afsnit. 2.3. Afgrænsning I behandlingen af problemstillingerne, der er præsenteret i problemformuleringen, er der en mængde interessante indgangsvinkler til besvarelsen. Det er derfor nødvendigt at afgrænse specialets fokus for at kunne opnå en tilstrækkelig dybde. Afgrænsningerne begrundes nedenfor. Specialets fokus betyder, at vi beskæftiger os med både projektledelse og systemudvikling som problemfelt. Vi vil dog hele tiden bevare en projektledelsesvinkel, hvilket betyder, at vi ikke vil gå i dybden med tekniske aspekter eller konkrete udviklingsmodeller. Disse vil blive berørt i beskedent omfang, hvor de belyser de behandlede projektledelsesaspekter. 8

Indenfor projektledelsesfeltet er fokus de overordnede strategiske aspekter som valg af metodologi og projektorganisering og i mindre grad på taktiske aspekter som konkret planlægning og estimering. Vi identificerer interessenter i forhold til det agile projekt, men må afgrænse os fra dybdegående behandling af det komplekse emne interessenthåndtering, herunder kundesamarbejdet, selvom dette er utrolig centralt i forhold til at få samarbejde mellem et agilt projekt og dets interessenter til at fungere. Specialet har fokus på leverandørsiden af projektet. Samarbejdsfeltet med kunden beskrives, men altid med det primære formål at bidrage til leverandørorganisationens forståelse af projektet og til projektlederens mulighed for sammensætning af en passende metodologi. I metodologisammensætningen fokuserer vi på faktorer i initieringsfasen og i begyndelsen af projektet, vel vidende at metodologien ofte må justeres løbende for at passe til projektet. Ligeledes nedprioriteres på den måde de utallige situationer, hvor der blot er behov for et moderat retningsskift midt i et projekt. Modellen kan anvendes hertil, men det er ikke idealsituationen. I forhold til håndteringen af et ikke-agilt organisatorisk udgangspunkt og transitionen til en højere grad af agilitet i organisationen, er forandringsledelse som forskningsfelt utroligt relevant. Vi har ikke fundet, at vi kunne behandle dette komplekse emne forsvarligt og afgrænser os dermed fra emnet. I specialerapporten og dens gennemgang af det agile paradigmes principper understreges vigtigheden af people issues og de menneskelige aspekters betydning for succesfuld projektorganisering. Den operationelle model til metodologisammensætning vil let komme til at underspille betydningen af de menneskelige aspekter i metodologien. I arbejdet med modellen er fokus dog konkret, hvorfor vi må tage denne udfordring op, og 9

i stedet kompensere for dette i modellens tilgrundliggende diskussion og mønstrene i Appendiks B, som metodologien sammensættes af. Med denne baggrund vil vi i det kommende afsnit gøre rede for specialets metodiske tilgang og dermed baggrunden for de valg og fravalg, der er gjort rede for herover. 10

3. Metodisk tilgang I det følgende afsnit vil vi gøre rede for såvel vores videnskabsteoretiske udgangspunkt som vores metodiske overvejelser omkring besvarelse af problemformuleringen. I forlængelse heraf vil vores metode- og litteraturvalg blive kritiseret og deres konsekvenser for resultatet vil ligeledes blive diskuteret. 3.1. Videnskabsteoretiske overvejelser Projektledelse som forskningsfelt er i nogen grad præget af pragmatismen indenfor projektledelsesfaget i erhvervslivet. Det er et forskningsområde, der anerkender kompleksiteten i projektets kaotiske natur og afhængigheden af menneskelige faktorer, men som samtidig er meget interesseret i at håndtere denne kompleksitet på en måde, så praktikere kan vejledes til konkret handling. Der er naturligvis forskere, der beskæftiger sig med grundforskningsprægede emner indenfor eksempelvis projektkommunikation, der først over tid danner grundlag for den praksisorienterede forskning. Mange forskere har dog en baggrund som udøvende projektledere og har derfor fokus på applicérbarhed og anvendelighed i forskningen. Applicérbarheden afhænger af, at de fundne sammenhænge i forskningsarbejdet i et vist omfang gøres målbare og konkrete for praktikeren. Specialets videnskabsteoretiske anskuelse læner sig op af den praktisk orienterede del af forskningsmiljøet. Litteraturvalget, som kritiseres i afsnit 3.2.3, afspejler dette valg. 3.1.1. Forklaringsmodeller Det nævnte fokus på applicérbarhed stiller forskningsområdet projektledelse og dette speciale i en spænding mellem de forskellige samfundsvidenskabelige forklaringsmodeller, hvor formålsforklaringer lægger vægt på forståelse for individets og kollektivets handlinger, og årsagsforklaringer på den anden side forsøger at kortlægge stabile sammenhænge mellem faktorer i projektets domæne (Gilje, 2002). I dette speciales sammenhæng er formålsforklaringerne væsentlige for at forstå baggrunden for praktikeres ønske om brug af agile metoder i store projekter og for deres 11