dette er en personlig kopi af bogen sendt til dig med...

Dette er en personlig kopi af bogen sendt til dig med venlig hilsen fra Novateam og IT People Denmark. Videresend venligst ikke dette dokument, men henvis i stedet til IP People Denmark eller køb bogen her:

https://www.saxo.com/dk/ledelse-af-komplekse-projekter_mogens-frank-mikkelsen_hardback_9788799968206

Novateam tilbyder workshop for projektlederer/chefer mv inden for emnet. Se videre om dette bagerst i dokumentet.

Ledelse af komplekse projekter med agilitet og et fast greb

Del 1

Mogens Frank Mikkelsen



Kolofon

© Mogens Frank Mikkelsen, Novateam, 2017

1. udgave, 2. oplag

Alle rettigheder forbeholdes. Mekanisk, elektronisk eller anden gengivelse af eller kopiering fra denne bog eller dele heraf er ifølge gældende danske lov om ophavsret ikke tilladt uden forfatterens skriftlige samtykke.

Illustrationer: Yogi

Forsidefoto: Dzokowski

Tryk: LaserTryk.dk

ISBN 978-87-999682-0-6

Gammelmosevej 70 2800 Kongens Lyngby 2628 8448 www.novateam.dk

Tak

En forfatter er ikke bedre end dem, der har hjulpet med ord og inspiration gennem tiden.

Først en tak til min tidligere chef Claus Havemann Andersen for at give tid, inspiration og særlig opmuntring til at skrive – selv om de første forsøg endte i papirkurven. Det er først nu, bogen har fundet en form, der egner sig til offentliggørelse.

Dernæst 1000 tak til - i alfabetisk orden - Kim André, Henri Brorson, Dorte Havshøj, Peter Høeg, Asbjørn Enemark, René Figgé, Rasmus Ludvigsen, Gert Plenge, Anne Mette Skovsen for at gennemlæse udkast og skærpe pointerne. Jeg sætter stor pris på netop jeres kommentarer, fordi de repræsenterer mange års erfaring med at drive projekter i den til tider barske virkelighed, som projektledelse foregår i.

Også en stor tak til de mange, der anonymt (og ofte uvidende) har deltaget ved at bidrage med hjerne, hjerte og krop til mine mange små uvidenskabelige eksperimenter, hvor jeg har afprøvet dele af bogens centrale model. Testen var spørgsmålet: Giver dette mening, og har det relevans for din projektledelse? Når svaret var klart ja fra tilstrækkelig mange, er det kommet med i bogen som valideret pointe.

En særlig tak til Karsten Kock, der har leveret meget tankegods igennem tiden, og særligt grundlaget for rammesætningsmodellen skal tilskrives Karsten. Sluttelig en tak til Yogi for hans illustra-tionerne, der er et muntert og opløftende bidrag til bogen.


mailto:[email protected]

Indhold

Tak ................................................................................................. 5

Forord ............................................................................................. 8

Introduktion til bogen .................................................................. 10

Overblik over bogens indhold ...................................................... 14

En mulig definition på projektkompleksitet ............................. 14

Kompliceret er ikke komplekst ................................................ 17

To centrale parametre, der skaber projektkompleksitet ........... 22

Projektkompleksitetsdefinition................................................. 22

Det sikre domæne: Klarhed og konsensus ................................... 32

Plandrevet projektledelse ......................................................... 34

Projektplanlægning i plandrevet projektledelse ....................... 40

Begrænsning af det sikre domæne ........................................... 45

Opsamling: Det sikre domæne ................................................. 54

Det uvisse domæne – konsensus, men usikkerhed! ..................... 55

Projektmodeller fra IT-branchen .............................................. 64

Det uvisse domæne handler mest om læring ............................ 80

Opsamling: Det uvisse domæne ............................................... 82

Det divergente domæne – klarhed, men uenighed! ..................... 83

Politiske vilkår.......................................................................... 90

Politisk analyse af projektet ..................................................... 93

Gode råd til den politiske projektledelse .................................. 99

De andre ser verden anderledes end dig ................................. 113

Opsamling: Det divergente domæne ...................................... 122

Det kaotiske domæne – uenighed og uvished ............................ 123

Hvad er kaos og kaotisk? ....................................................... 126

Det uundværlige rammesætningsværktøj ............................... 129

Ledelsesopgaven i rammesætningsmodellen ......................... 140

Samspil med projektværktøjskassen ...................................... 147

Opsamling: Det kaotiske domæne .......................................... 153

Afslutning af bogen .................................................................... 154

Entreprenant projektledelse .................................................... 154

Resume af bogen .................................................................... 157

Appendiks .................................................................................. 160

Projektledelsesstandarder og kompleksitet ............................ 161

Historisk udvikling af projektkompleksitetsdefinitionen ....... 164

Andre modeller for projektkompleksitet ................................ 169

Generelle modeller af kompleksitet ....................................... 171

Referenceliste ............................................................................. 175

Side 8 Ledelse af komplekse projekter

Forord

Forord af konsulent Finn Svenning, HD, PMP med over 30 års

projekterfaring, indehaver af Danmarks største blog om

projektledelse, anmelder af litteratur om projektledelse, tidl.

præsident for PMI i Danmark og medlem af redaktionen på

DPL’s medlemsblad.

--

Kan man overhovedet skrive en bog om at styre noget ustyrligt

uden at bryde forudsætningen om netop ustyrligheden?

Det kunne være den første tanke, man gør sig, når man bladrer i Mogens Mikkelsens nye bog Ledelse af komplekse projekter. Men det er i sandhed lykkedes, fordi bogen, til forskel fra de fleste

andre bøger, starter med at afklare den virkelighed, som projekt-

lederen befinder sig i, og først derefter peger på mulighederne at

lede projektet. Med ordene vished contra uvished og sikkerhed

contra usikkerhed optegner bogen fire kombinationer, som

karakteriserer ethvert tænkeligt projekt. Først når projektlederen

indser, hvilken kombination han/hun er havnet i, er det relevant at

tale om værktøjsbrug til at styre med.

Ved nærmere eftertanke må man jo indse, at ingen projekter helt

kan styres. Vi kan forsøge, og slipper afsted med det, mere eller

mindre succesfuldt, men helt styr på projekter får vi aldrig.

Årsagen er, at der ikke eksisterer en teori for projekter, som der

gør for tyngdekraft eller magnetisme. Det, vi kalder metoder og

værktøjer i projekter, er derfor i virkeligheden kun principper,

som har vist sig nyttige i arbejdet med projekter.

- med agilitet og et godt greb Side 9

I takt med at projekterne bliver mere komplekse i vores stadig

mere komplekse virkelighed, bliver principperne så meget desto

vigtigere at koncentrere sig om, og det er lige dér, Mogens

Mikkelsen med denne velskrevne bog tilføjer en værdifuld brik til

vores litteratur om projektledelse. En brik, som fortjener at stå

forrest i litteratursamlingen, fordi den beskæftiger sig med at

afklare projekternes situation snarere end deres eventuelle løsning.

En brik, som måske vil vise sig at være den allervigtigste i

styringen af de ustyrlige og komplekse projekter i fremtiden.

Bogen kan på mange måder opleves som en god vejleder, som er i

stand til at skabe en forenkling og indsigt, der giver afklaring og

fornyet energi til projektlederskabet! En klar anbefaling fra mig!

Finn Svenning, november 2016.

Overblik


Kapitel 1

Introduktion til bogen

Den stigende kompleksitet i vores projekter tvinger os til at genopfinde projektledelse – eller i det mindste opdage, hvor den traditionelle projektledelse ikke helt slår til. Kompleksiteten stiger eksponentielt i vores samfund – blandt andet som følge af den store integration af alting, forandringshastigheden generelt og den stigende forventning hos interessenterne om, at deres interesser bliver hørt og varetaget. Der er ikke længere så mange, der finder sig i lugten i bageriet, som der tidligere var.

Projekter behøver ikke at være store for at være komplekse. Der er overraskende mange små projekter, der har stor kompleksitet. Dette skyldes blandt andet, at det i disse projekter forventes, at projektlederen også håndterer implementering og forandrings-ledelse samt nogle gange også benefitrealiseringen – ledelses-opgaver, som tidligere normalt lå i forretningen/organisationen.

Gennem mange år har jeg arbejdet med spørgsmålet: Hvad er egentlig projektkompleksitet – og hvordan håndterer man det bedst muligt? Det viser sig, at der er flere svar, end én bog kan rumme. Forhåbentlig kan du bruge de svar, som denne bog præsenterer.

Måske du også har lyst til at deltage i den fortsatte diskussion af emnet. Det er allerede nu helt sikkert, at denne bog får en efter-følger. Da emnet projektkompleksitet er komplekst, er en trilogi også en mulighed. Dette er helt i tråd med en central måde at håndtere kompleksitet på: Brug iterative processer.

Kapitel 2


Herefter springer vi til det mindst lige så vigtige emne: læserne. Bogen er mest skrevet til projektledere, men projekt-ejerne og andre beslutningstagere og centrale interessenter kan med fordel læse med – Om ikke andet, så for at deltage i en berigende snak med projektlederen om projektet, og hvordan det kan ledes sikkert.

Enhver forfatter har en forestilling om, hvem der får udbytte af bogen. Jeg er ingen undtagelse, og de antagelser, jeg gør mig om den ideelle læser til Ledelse af komplekse projekter, er følgende: Du kender til projektlederens basale værktøjskasse. Du har med stor sandsynlighed gennemført flere projekter og har konstateret, at værktøjskassen har sine begrænsninger. Du har sikkert flere gange oplevet, at et projekt var ude af teamets kontrol – ja, du har måske også oplevet kaotiske perioder.

Du har formodentligt grebet Ledelse af komplekse projekter, fordi du ønsker at få inspiration til bedre at kunne navigere i den kom-pleksitet, der findes i og omkring såvel små som store projekter. Med andre ord er dit ønske at få en model for, hvordan projekt-ledelsen kan reagere på projektkompleksitet. Bogen kan forhåbentlig give inspiration til, hvordan du kommer til at sidde mere sikkert på et projekt, der både stejler og sparker bagud. Forsiden har allerede givet et bud: Det handler om agilitet og et fast greb i ”dyret”, du sidder på. Hvordan dette konkret forstås, bliver udfoldet i bogen.

Herefter et par ord om min baggrund for at skive en bog som denne. De første 15 år efter min grunduddannelse som civilingeniør fra Danmarks Tekniske Universitet (DTU) har jeg arbejdet som projektleder, projektejer, siddet i styregrupper i både små og store virksomheder samt i forskellige brancher. Mine

Overblik


projekter har ofte omhandlet IT den den ene eller andet måde. Nærværende bogs indhold udspringer af egne erfaringer fra de mange år som aktiv projektleder, men indholdet bygger måske endnu mere på de mange andre tusind projektledere, som jeg har undervist og coachet igennem de seneste 10 år. Man kan sige, at de seneste 10 år har gjort det meget klart for mig, hvad jeg lærte i løbet af de første 15 år. På en måde har det sluttet ringen for mig, idet jeg nu har lejlighed til at hjælpe andre med at blive bedre projektledere.

På en måde, har jeg taget tilløb til denne bog gennem flere artikler udgivet via forenignen Dansk Projektledelses tidskrift ”Projektledelse”: Disse er:

• Situationsafstemte projektlederroller. Projektledelse 2015 - 1 • Kompleksitet – kan du blive i sadlen, hvis projektet stejler?

Projektledelse 2015 - 2 • Det u-undværlige rammesætningsværktøj. Projektledelse

2015 - 4 • Når kunden giver politisk modspil. Projektledelse 2016 - 3

Du kan finde tidskrifterne på www.issuu.com

I foreningen Dansk Projektledelse har jeg også haft fornøjelsen af at præsentere temaet på Symposiet Projektledelse i 2015 og 2016 samt på halvdagsseminarer, hvor temaet er blevet gentaget.

De forskellige aspekter af modellen, der er grundlaget for denne bog, er blevet afprøvet sammen med projektledere i forskellige sammenhænge, blandt andet ved at tage pointerne med i min undervisning for at se, hvordan projektledere med forskellige grader af erfaring reagerer. Denne semi-videnskabelige tilgang har været en yderst interessant og givende proces – særligt for mig.

Kapitel 2


Anbefalet supplerende litteratur

Ledelse af komplekse projekter dækker langt fra alt, man kunne ønske sig at vide om ledelse af projekter – særligt de komplekse. For at kompensere lidt for dette peges her på en række andre bøger, der støtter godt op om budskabet i denne bog.

• Power i projekter og porteføljer. J.R. Olsson, N. Ahrengot og M.L. Attrup. Djøf Forlag 2015. Bogen er netop udkommet i 3. udgave og er en klassiker som introduktion til emnet projekt-ledelse og beskriver i en let fordøjelig stil projektlederens opgaver og ansvar.

• Creativity Inc. Ed Catmull. Random House Inc. 2014. En bog, der ikke handler om projektledelse som sådan, men om udviklingen af det projektmiljø, der har gjort Pixar Animation Studio i stand til succesfuldt at håndtere og lede komplekse projekter på stribe.

• Images of projects. Mark Winter og Tony Szcwpanek. Gower 2009. Bogen udmærker sig ved at give syv helt forskellige perspektiver på et projekt. Selv om bogen ikke omtaler kompleksitet direkte, er den et rigtig godt bidrag til forståelse af projektkompleksitet.

• Leading Complex Projects. Kaye Remington. Routeledge 2011. En inspirerende bog om kommunikation, tænkning og politisk lederskab i komplekse projekter.

• Managing Complex Projects. K.B. Hass. Management Concepts 2009. En udmærket bog om graduering af projekter i stigende kompleksitet og forslag til ledelsens modsvar herpå.

Overblik


Kapitel 2

Overblik over bogens indhold

Flere af de første forsøg på at skrive Ledelse af komplekse projekter begyndte med optegning af de mange forskellige definitioner af kompleksitet, hvor der særligt blev gransket i de videnskabelige artikler fra diverse Project Management journals. Ingen af disse forsøg blev dog særligt vellykkede. Stoffet blev hurtigt tungt og alt for akademisk. En væsentlig grund er, at der findes et utal af forskellige måder at definere projektkompleksitet på. Disse er skubbet til et appendiks placeret bagerst i bogen.

I stedet for starter bogen med slutningen på de mange overvejelser og giver et bud på, hvad projektkompleksitet er: Det er alt det, som falder uden for projektlederens traditionelle værktøjskasse. Da dette er lidt for metaforisk til at arbejde med, kommer her et mere seriøst bud:

En mulig definition på projektkompleksitet Et projekt kan være simpelt eller kompliceret, og dog analyserbart på forhånd. Derimod er et komplekst projekt uforudsigeligt som følge af projektets usikkerhed og interessenternes uenighed. Høj score i begge faktorer kan give projektet kaotiske træk.

Gradbøjning versus opdeling i parametre

Det fremsatte forslag til definitionen af projektkompleksitet består egentligt af to definitioner samlet i én. Det indeholder både en gradbøjning (simpel, kompliceret, kompleks og kaotisk) og opdeling i parametre (graden af uforudsigelighed opdelt på usikkerhed og uenighed). Der er derfor grund til at se nærmere på hver af disse to måder at definere noget på.

Kapitel 2


Definering med gradbøjningen kan illustreres med en analogi: Antag, at vi skal definere begrebet ”størrelse”. En gradbøjning af begrebet størrelse kunne være i følgende fire grader: S, M, L og XL. Det er fire grader, der er som trappetrin. Med andre ord er de klart adskilte fra hinanden. De er diskontinuerte, vil nogle sige. Denne måde at definere på kan kaldes en klassifikation og er velegnet, hvis der er unikke forhold, der kun gælder for hver enkelt af klasserne.

En anden måde at definere ”størrelse” på kunne være ved hjælp af parametre. Disse kunne passende være: højde, bredde og længde. Hver af disse tre parametre er kontinuerte, og der er derfor ingen veldefineret overgang fra ”lille” til ”stor”, når vi bruger parametre til at definere begrebet størrelse.

Så kunne diskussionen begynde: Hvilken type definition, der er den ”rigtige”? Gradbøjningen eller parameterdefinition – eller en kombination, som denne bog bruger. Denne diskussion ville gøre det hele meget akademisk. Som nævnt kan man hoppe til bogens appendiks, hvis man gerne vil se de seneste 25 års bud på, hvor-dan projektkompleksitet kan defineres.

Til vores formål har vi mest brug for at forholde os til, hvad vi gør, hvis projektkompleksiteten er ”stor”, og derfor er gradbøj-ningen den primære.

Gradbøjning af projektkompleksitet

Lad os begynde med en model, der bygger på gradbøjningen af kompleksitet i simpel, kompliceret og komplekst samt kaotisk. Figuren er baseret på Leading Complex Projects af Kaye Remington, herunder er den udsat for Yogis streg. Remington er tydeligvis inspireret af David John Snowdens Cynefin Frame-work, som vi møder i appendikset sidst i bogen. Det er egentlig

Overblik


misvisende at tegne en linje, som Remington gør. Det ville være mere korrekt med en trappe, fordi der kan forekomme spring på skalaen imellem de fire situationer, simpel, kompliceret, kompleks og kaos.

Man kan også springe et ”trin” over: Et projekt behøver ikke at være kompliceret for at blive komplekst. Omvendt bliver et kompliceret projekt ikke komplekst, blot fordi det er meget kompliceret.

Men bort set fra det, så er ovenstående et godt bud på, hvordan projektledelsen bør tilrettelægges. Ud fra, hvor på skalaen projektet er, kan vi svare på spørgsmålet: Skal projekt-ledelsen være administrativ, nærmest regelbaseret, eller er der brug for en mere analyserende ekspertbaseret tilgang, måske der kræves et eksperimenterende projekt setup, eller skal vi reagere hurtigt på en umiddelbar krise?

Men hvad er den egentlige forskel på kompliceret og komplekst? Remington besvarer ikke spørgsmålet i sin ellers udmærkede bog, men forskellen er vigtig, og derfor dykker vi ned i dette emne i næste afsnit.

Kapitel 2


Kompliceret er ikke komplekst Hvis noget består af mange forskellige sammenhængende dele - og det stadig er muligt at skille det ad og samle det igen - så kan man sige, at det er kompliceret. Et projekt kan være kompliceret, fordi det er svært at overskue alle enkeltdelene, men det er dog muligt at analysere det komplicerede til bunds og forudsige, hvordan delene vil interagere. Det forholder sig anderledes, når enkeltdelene gensidigt påvirker hinanden, for så bliver det komplekst.

Figuren herunder illustrerer grafisk forskellen på kompliceret og komplekst. Det er dog sjældent, at projekter kun er det ene eller det andet, så figuren skal ses som to arketyper af projekter.

Hvis man skal fra problemet A til løsningen B, så kan det komplicerede projekt kræve mange elementer – steps – der følger efter hinanden i en bestemt rækkefølge. Problem og løsning er stabile. Men hvis problemet ændrer sig, når vi har løsningen, så A og B afhænger indbyrdes af hinanden, så er det komplekst. Det betyder blandt andet, at man ikke kan planlægge vejen fra A til B i et komplekst projekt, på samme måde som man kan, hvis projektet ”kun” er kompliceret.

Overblik


Det betyder også, at selv om et projekt er meget kompliceret, så bliver det ikke komplekst, og omvendt er noget, der er lidt komplekst heller ikke nødvendigvis kompliceret.

Forskellen har stor praktisk betydning for ledelse af projektet. Det komplicerede er dybest set variationer over noget kendt, som man kan analysere og planlægge til bunds. Det komplekse indeholder så meget nyt, at det bliver uforudsigeligt.

Hvor meget planlægning er mulig – og værdifuld?

Sondringen imellem det komplicerede og det komplekse giver svaret på spørgsmålet: I hvilken grad giver det mening at plan-lægge projektet detaljeret på forhånd?

Hvis det er et komplekst projekt, så er detaljeret planlægning ikke løsningen. Omvendt er det værd at bemærke, at selv om man har et kompliceret tilfælde, og man principielt kunne planlægge alt i de mindste detaljer, så er det ikke altid godt at gøre dette. Nogle gange kan en plan, der er for kompliceret, skabe en kompleks situation, fordi ingen længere har overblikket.

Anlægsarbejde er et eksempel på et projekt, der er kompliceret, men næppe komplekst. Maskiner, materialer og mandskab samt afskærmning og trafik gør, at der er ufatteligt meget at holde styr på. Det er dog stadig forudsigeligt og muligt at planlægge – også selv om der er mange risici, der kan udfordre planen. Det hele er ganske lineært – metaforisk set. Der er tale om en lige vej fra problem til løsning, og det er muligt at lave risikoanalyser, der udtømmer udfaldsrummet for begivenhederne. I figuren er dette bestemt som et lineært og entydigt forløb mellem A og B.

Til sammenligning er mange IT-projekter ikke lineære, men derimod cirkulære. Problem og løsning påvirker hinanden. Det

Kapitel 2


komplekse opstår, når der ikke er en lineær sammenhæng mellem problem og løsning. Som eksempel kan brugerønskerne nemt ændre sig, når de oplever løsningen på deres oprindelige behovs-formulering.

Sagt med et glimt i øjet er den hurtigste måde at få en bruger til at ombestemme sig følgende: Lever dét, som brugeren oprindelig bad om.

Mange opdager først, hvad de ikke vil have, når de får, hvad de troede, de havde brug for.

Hvis problemstillingen er kompleks, kan den først rigtig forstås, når løsningen er blevet fundet. Løsningen til det komplekse kræver derfor ofte mange iterationer, hvor man prøver sig frem – nogle gange i blinde. Den komplicerede problemstilling kan derimod analyseres til buds, og en lineær løsning kan beskrives, inden man går i gang. Man man godt efterratonalisere, hvorfor det gik som det gik, men man kan ikke forudsige det.

Et kompliceret projekt

Projekterne med udbygning af motorvejene uden for København er komplicerede, men ikke komplekse. Der er ufatteligt mange ting at planlægge og holde øje med, når trafikken skal afvikles samtidig med, at nye baner etableres, og gamle broer og indfaldsveje ændres. Det er kompliceret, fordi så mange forskellige aktiviteter

Overblik


skal passe sammen og udføres i den rigtige sekvens, samtidig med at uheld undgås, og bilkøer minimeres.

Motorvejsrenoveringsprojektet er som nævnt kompliceret, men der kan godt være elementer i projektet, som er komplekse, ja endda kaotiske, eksempelvis hvis en bro falder sammen. Et meget usandsynligt scenarie, men det var hvad der skete i 2014 ved udvidelsen af Helsingørmotorvejen.

Et komplekst projekt

Store events vil meget ofte have meget kom-plekse projektkarakterer. Her er der mange ting, som interagerer simul-tant. Det kan også blive kaotisk, når det kun er tilfældigheder, der hersker. Afholdelse af karneval i København er et komplekst projekt. Eller rettere: Det var det i begyndelsen. Nu, hvor det er blevet afholdt mere end 30 gange, har der udviklet sig til en stabil organisation, der kører som smurt – også selv om vejret er en uforudsigelig størrelse.

Deltagerantallet var en af kompleksitetsfaktorerne, særligt i begyndelsen. Antallet afhang af pressedækning, og omvendt var pressens opmærksomhed afhængig af deltagerantallet. Blandt andre elementer var uforudsigeligt politi og politikere – blot for at nævne andre ting, der var umulige at planlægge ordentligt ved de første afholdelser. Omvendt vil ikke alt være komplekst, idet mange aspekter kan analyseres og planlægges på forhånd, som f.eks. afspæringer og deraf ændringer af trafikale forhold.

Kapitel 2


Ved senere afholdelser begyndte der at være forudsigelige mønstre, der gør, at afholdelse af karneval i dag stort set ”kun” er kompliceret og ikke så komplekst, som det var i begyndelsen.

Forventninger skaber kompleksitet

Det er ikke kun projekterne i sig selv, men også omverdenens forventningerne til projekterne, der kan skabe kompleksitet. Mange projekter er i sig selv ”kun” komplicerede, men bliver komplekse, fordi projektet også får ansvar for implementering, forandringsledelse og benefitrealisering. Som eksempel kan indkøb af en maskine blot være kompliceret. Det er det, hvis der er faste forudsigelige krav, og man kan analysere, hvilke tilbud der bedst lever op til dem. Men hvis man får ansvaret for realisering af business casen for maskinkøbet, bliver det komplekst, fordi dette griber ind i organisationens brug af maskinen efterfølgende. Her kommer projektlederen på udebane, fordi der er mange andre spillere på banen, som ikke altid spiller godt sammen med projektet, hvilket vi kommer tilbage til i senere kapitler.

Projektkompleksitet er skabt af mennesker – og skal løses af mennesker! Problemer kan være komplekse, men løsninger bør være simple. Mennesker egner sig ikke til at bruge komplekse løsninger. Vores hjerner fungerer med ved enkelthed.

Hvis problemet kræver en kompliceret løsning, så har man sandsynligvis ikke nået målet endnu. Nogle gange er det først, når man er kommet helt i mål, at man opdager, at det, der fremstod som vanskeligt, i virkeligheden var ganske enkelt. Eller formuleret kortere således:

Simplicity = Complexity explained

Overblik


To centrale parametre, der skaber projektkompleksitet Projektkompleksitet kan forenklet beskrives ved to parametre: usikkerhed og uenighed. På hver af de parametre kan man ligge højt eller lavt, og hermed dannes et 2 x 2 vindue, som man kan bruge til at navigere med.

Inspirationen til at benytte disse to parametre er kommet fra Ralph Stacey, der har foreslået en model kaldet Agreement-Certainty-Matrix (Stacey, 1996). Hvis man gerne vil studere kilderne, kan Stacey ikke anbefales – Pånær hvis bogen er med på pensumlisten på et fag, som man skal til eksamen i. Brenda Zimmerman har med bogen ”Edgware” skrevet en letforståelig fortolkning af Staceys arbejde. (Zimmerman, 1998). Modellen stiller to spørgsmål:

• Er vi tæt på eller langt fra enighed? • Er vi tæt på eller langt fra sikkerhed?

Dette giver fire grundformer, der bør være styrende for vores valg af beslutningsproces.

I appendikset bag i bogen bliver der vist, hvordan de to parametre – usikkerhed og uenighed – i Staceys kompleksitetsmatrix kan forstås i forhold til de mange andre mulige parametre, som projektkompleksitet kunne udtrykkes med.

Projektkompleksitetsdefinition Remingstons kompleksitetskala fra tidligere og Staceys kompleksitetsmatrix for ledelsesbeslutninger har været en vigtig inspirationkilde for vores definition. Definitionen er gentaget her, så man ikke behøver at bladre tilbage til begyndelsen af kapitlet.

Kapitel 2


Et projekt kan være simpelt eller kompliceret, og dog analyserbart på forhånd. Derimod er et komplekst projekt uforudsigeligt som følge af projektets usikkerhed og interessenternes uenighed. Høj score i begge faktorer kan give projektet kaotiske træk.

Denne definition fører frem til et 2 x 2 vindue over tilstande, som et projekt kan være i kompleksitetsmæssigt. Et landskab med fire domæner, der er udspændt af uenighed og usikkerhed som vist i figuren. Det kaldes et vindue, for at minde os om, at det er noget, vi ser ud gennem, for at blive kloge på kompleksitetslandskabet.

Den centrale pointe er, at projektledelsen skal tilrettelægges forskelligt afhængig af, hvilke af de fire kvadranter projektet befinder sig i – eller mere præcist: spreder sig over – for et projekt vil typisk bestå af delemner fra flere domæner.

Overblik


Hen gennem bogen refereres ofte blot til domænenumre 1, 2, 3 og 4, andre gange til deres navne, som er det sikre, det uvisse, det divergente og det kaotiske domæne.

1. Det sikre domæne, der er kendetegnet ved rimelig klarhed og enighed, er den klassiske projektledelse. Man forudsætter klare mål og metoder, der er enighed omkring. I dette domæne er projektet enten simpelt eller kompliceret, fordi det kan analyseres til bunds og planlægges i detaljer. Hvad skal leveres, hvor hurtigt kan vi gøre det – og til hvilken pris?

2. Det uvisse domæne, hvor der er en høj grad af usikkerhed. Projektet er indholds komplekst, forstået på den måde, at indholdet først er endeligt klart, når projektet er færdigt. Hvad er dét, som vi ikke ved endnu, og hvordan finder vi ud af det? Hvordan etableres læringsfeedback i projektet?

3. Det divergente domæne, hvor der er en høj grad af uenighed. Projektet er interessent komplekst. Der er brug for projektledelse med politisk forståelse. Hvilke interesser og magtforhold er projektet udsat for, og hvordan håndterer vi disse?

4. Det kaotiske domæne, hvor der både er høj grad af usikkerhed og uenighed, hvilket giver en meget stor uforudsigelighed og bringer os til kanten af kaos. Hvordan håndterer vi det?

Klarhed versus uvished

I princippet er al fremtid uvis, fordi vi ikke kan forudse den med absolut sikkerhed. I praksis har mange projekter dog en rimelig klar fremtid, fordi den kan analyseres og forudsiges med en rimelig høj grad af sikkerhed. I andre projekter indgår så mange usikre antagelser og elementer, at projektets fremtid er uvis.

Kapitel 2


Begrebet ”usikkerhed” er meget bredt og kan have den medbetydning, at noget kunne være analyseret, men ikke er blevet det, eller kun er blevet undersøgt overfladisk. Dette vil blot være et udtryk for sløsethed. Dét, der henvises til med begrebet uvished, er mere beslægtet med emergens, som betyder, at noget opstår. Emergens er et begreb, der vinder stigende popularitet ved beskrivelse af en uvis fremtid.

Den Danske Ordbog kan tilbyde følgende definition af begrebet emergens: Dannelse eller opståen af nye egenskaber i et sammen-sat system, som ikke kan forklares ud fra de enkelte deles egen-skaber.

Lad os for enkelthedens skyld sammenligne to projekter fra privatlivet. De kan være af samme økonomiske størrelse: Køkkenudskiftning og verdensrundrejsen. I førstnævnte vil man for alt i verden have klarhed og undgå usikkerheden. I sidstnævnte er usikkerheden et naturligt element af projektet, ja nogle vil måske ligefrem sige, at selve rejsens formål er at opleve emergens. Det nye, der bryder frem, mens vi er undervejs. Ordet planlægning vil i de to eksempler have to meget forskellige betydninger. I køkken-tilfældet handler planlægning om at specificere, hvordan det skal se ud i sidste ende og måske laves en kontrakt med den udførende leverandør. I verdensrundrejsen er planlægning i stedet at lave rammerne for en god oplevelse, som vi først vælger indholdet af undervejs.

Pointen med emergens her er at tydeliggøre, at ordet uvist bruges om noget, der ikke kan undersøges fyldestgørende på forhånd. Vi bliver nødt til at skabe det først, og så se på det skabte bagefter. Som bekendt er bagklogskabens lys klarest, hvilket gælder i både positiv og negativ forstand.

Overblik


Konsensus versus divergens

På den anden akse har vi nærmest det modsatte problem. Begrebet ”uenighed” er på en måde for snævert til det, vi forsøger at udtrykke opad den lodrette akse i figuren.

Den Danske Ordbog har følgende definition af divergens: Meningsforskelle, uenighed eller noget, der afviger eller fjerner sig fra hinanden.

Til sammenligning er definitionen af konsensus: Generel enighed i en bestemt gruppe, fx om hvordan man skal forholde sig i en sag.

Divergens handler ikke ”bare” om uenighed som i konflikt eller diskussioner, det handler også om, at man grundlæggende ser forskelligt på situationer og ikke mindst er ved at gå i hver sin retning – måske fordi man har forskellige visioner.

Divergens dækker også over den sproglige forskellighed, tvetydigheder, der vanskeliggør vores kommunikation i almindelighed og projektets målformuleringer i særdeleshed.

I moderne ledelseslitteratur skiver man ofte om ”diversiteten”, hvilket er et udtryk for mangfoldighed og forskelligartethed (ifølge Den Danske Ordbog). Dette giver grundlag for den divergens, vi kan opleve i projekterne.

Divergens handler både om de mange forskellige perspektiver på projektet, men også forskellige syn på, hvor komplekst projektet egentlig er – med andre ord spørgsmålet om: Hvilket projekt setup og projektledelse er der brug for her?

Kapitel 2


Et forenklet billede

Al kommunikation – herunder den skriftlige i en bog som denne – er en vanskelig balance mellem fremmedgørende præcision på den ene side og mere tilgængelige tilnærmelser på den anden. Med risiko for at havne i den sidstnævnte grøft har vi valgt at illustrere bogens grundmodel som vist herunder.

Det er vanskeligt at vide, hvilket domæne projektet befinder sig i. Måske kan det heller ikke fastlægges objektivt – og slet ikke i begyndelsen. Det centrale spørgsmål er: Hvor hurtigt kan vi finde ud af, hvad vi har med at gøre – og hvordan lærer vi at håndtere dette projekt? Hvis vi opdager det for sent, kan vi blive smidt af, hvis projektet stejler eller sparker bagud.

Overblik


Hvem er du – når du vurderer projektets placering?

Dette spørgsmål er ikke ment som et eksistentielt spørgsmål, men i stedet en afdækning af de briller, som du ser på projektet med. Dine briller påvirker, hvor du har en tilbøjelighed til at placere projektet i matrixen.

Er du projektejer eller projektleder? Det er ofte en forskel på, hvordan disse to roller ser projektet. Førstnævnte er tilbøjelig til at se klarhed og konsensus – måske som en ønsketænkning. Sidstnævnte er måske mere opmærksom på usikkerhed og uenighed – nok fordi projektlederen skal håndtere disse konkret.

Din erfaring vil også påvirke dit perspektiv. En meget erfaren projektleder ser måske projektet som kompliceret, mens en mindre erfaren vil opfatte det som komplekst – måske endda kaotisk. En uerfaren kan omvendt måske overse uenigheder og potentielle konflikter, som mere erfarne vil kunne se.

Forskellige personlighedstyper kan også have indflydelse på ens subjektive placeringen af projektet i projektkompleksitetsvinduet. En MBTI-type J vil nok være mere tilbøjelig til at vælge det sikre domæne, mens en type P vil vælge en af de andre tre.

Projektets forandringer over tid

Projekter er sjældent placeret i ét domæne fra start til slut, og delene i det enkelte projekt kan være spredt ud over alle fire domæner med en ulige fordeling. Et projekt kan betragtes som et kalejdoskop af issues, der opstår, afklares og forsvinder.

Kapitel 2


I figuren er dette illustreret med A, B og C, der udtrykker et projekt, der ændrer sin placering i de fire domæner hen gennem projektets livscyklus – fra ide til færdiggørelse. Men et projekt kan på et givet tidspunkt være spredt ud over vinduet, således at noget af projektet er i det ene domæne, mens andre dele er i et eller flere af de andre. Billede burde måske ikke være en ”ø” men mere en øgruppe.

På spørgsmålet: Hvilke dele af et projekt er komplekse?

Kan det enkle svar være: Det er som sagt de dele af projektet, som falder uden for projektlederens værktøjskasse – Alt det andet er blot kompliceret, eller måske endda simpelt.

Overblik


Meningen med forsidens tagline: Agilitet og et fast greb

Som forsiden lægger op til, skal komplekse projekter ledes med agilitet og et fast greb. Agiliteten handler om at håndtere uvished og emergens. Det faste greb skal håndtere divergensen.

Der er én særlig udfordring, som kan kræve et særlig godt greb: Hvis centrale magtfulde interessenter tror, at projektet er i domæne 1, og man som projektleder er overbevist om, at dette ikke er tilfældet. Med andre ord: Magtfulde interessenter lider af ”fejlagtig-første-domæne-tænkning”. Denne situation forekommer ofte, men indses tit for sent, blandt andet fordi man kan være blændet af sin autoritetstro. Selv om kejseren ikke har tøj på, så er han jo stadig kejseren. Omvendt kunne man jo selv se forkert, og det er ikke godt at pege fingre af nøgenhed, hvis kejseren rent faktisk har tøj på. Dette er som sagt en særlig vanskelig divergens, der gør det svært at lede projektet, som det burde ledes.

Størstedelen af litteraturen om projektledelse tager udgangspunkt i det sikre domæne, hvor der er klarhed og konsensus. Men en meget stor del af projektledernes virkelighed foregår i de tre andre domæner, hvor der er forskellige kombinationer af uvished og divergens.

Bogen forklarer de fire felter, forskellen på dem og overgangen imellem dem. Til hvert af de fire domæner hører anbefalet adfærd til projektledelsen. Det er med vilje, at der her ikke står ’projekt-lederen’, for det er projektets samlede ledelse, der skal agere hensigtsmæssigt for at opnå succes med projektet.

Bogens overordnede pointe er, at man skal tilpasse projektledelsen til det domæne, som projektet befinder sig i. Nogle gange handler det alene om at opdage, at man er røget ud af

Kapitel 2


det sikre domæne, og så arbejde på at komme tilbage. Det er trods alt, når der er klarhed og konsensus, at tingene foregår bedst. Nogle gange kan den kun opnås for den næste korte periode af projektet, men så må man starte med dét.

Gennem bogen vil vi dog forholde os til et domæne ad gangen – Der er grænser for, hvor komplekst, man kan skrive en bog.

Der er tre afgørende spørgsmål, man løbende må stille sig selv:

1. Hvor er vi? Dette spørgsmål kan stilles både på projekt- og aktivitet-niveauet. Er der usikkerhed og/eller uenighed, eller hersker der konsensus og klarhed om, hvad vi skal?

2. Hvor enige er vi om, hvor vi er? Hvor forskelligt ser projektets centrale aktører på situationen, og kan projektet gennemføres med denne grad af divergens?

3. Hvad gør vi? Hvordan skal projektledelsen (prøve at) tilrettelægge projektet i denne situation med disse issues?

Der står ”prøve” under punkt 2 for at minde os om, at selv om vi selv kan se lyset – og vi synes at vide, hvad der burde gøres – så kan andre se anderledes på det. Og endnu værre, de kunne have ret, men vi er altid nødt til at handle ud fra hvad vi selv tror mest på. Hvis vi ikke gør dét, så løber tiden fra os – og når tiden er gået, kan intet længere gøres.

Men lad os så komme i gang med at se nærmere på hver af de fire domæner, som projektkompleksitetsvinduet spænder over.

Det sikre domæne


Kapitel 3

Det sikre domæne: Klarhed og konsensus

Hun var godt forberedt og stod nu foran styregruppen. Præsentationen var baseret på grundig forventningsafstemning med centrale interessenter, og tidsplanen var lavet sammen med det lille team, som hun havde samlet til lejligheden. Men styre-gruppen ville, som så ofte set, have det hele bedre, billigere og hurtigere.

Mødet udviklede sig til et langvarigt tovtrækkeri frem og tilbage om, hvad der kunne lade sig gøre inden for det budget og den tidsramme, som styregruppemedlemmerne insisterede på. De pressede, og hun forsvarede sig. De udfordrede tallene, og hun forklarede teamets estimater. Men det gik, som det ofte går, når der er flere mod én, og på et tidspunkt gav hun op. Med et lille suk satte hun sig og noterede, hvad styregruppen gerne ville have leveret inden for deres ønskede budget og deadline. Hun læste sine noter højt, så alle var enige om, at dette var rammen for projektet. Styregruppens medlemmer nikkede – tilfredse med, at hun tog deres anbefalinger til efterretning. Derefter sagde hun følgende: ”Hvis dette er rammen, så mangler vi blot at finde en projektleder, der kan tage projektet.”. Der blev først stille. ”Jamen,” sagde alle i styregruppen nærmest i kor. ”Du er jo projektlederen.”. Hun så på dem, ”Desværre,” svarede hun og tilføjede: ”Jeg laver ikke ’mission impossible’. Jeg har besluttet, at alle mine projekter skal bygge på et realistisk udgangspunkt.”

Der blev nogen forvirring i den lille styregruppe. Efter at være kommet sig over overraskelsen spurgte et af medlemmerne i styregruppen: ”Jamen, hvad kan du så foreslå?”

Kapitel 3


Projektlederen havde lidt svært ved at skjule et lille smil, da hun begyndte at fremlægge teamets oprindelige forslag til indhold, budget og tidsplan. Styregruppen sagde senere, at de aldrig havde oplevet noget lignende, og det var egentlig for ringe! Det er trods alt bedre at blive lidt skuffet i starten – frem for at blive meget skuffet i slutningen!

Domæne nummer et i kompleksitetsvinduet kaldes ”Det sikre domæne”, fordi det er kendetegnet ved, at der både er enighed om projektet og også en stor vished om, hvad der skal laves, hvor hurtigt det kan laves, og hvad det kommer til at koste. Eller, for at være mere præcis: Der kan komme klarhed og konsensus, hvis man gør en indsats for det – og nogle gange sætter sin rolle på spil. Det kommer ikke af sig selv!

Det sikre domæne


Projektleder og team skal bruge tid til forventningsafstemning af mål og planlægning af midler. Uden denne indsats kan ”Det sikre domæne” snildt blive en usikker fornøjelse for både projektleder og projektejer.

Men, hvorfor egentlig gennemgå ”Det sikre domæne”? Hvis læseren af denne bog har projektledererfaring, er det så ikke overflødigt?

Jo, måske. Omvendt er det godt at være enige om, hvordan vi ser på den traditionelle projektledelse, for så er det nemmere at kommunikere om, hvad der mangler, når vi bevæger os ud i de andre domæner i projektkompleksitetsvinduet.

Plandrevet projektledelse Alle de klassiske værktøjer kommer til deres ret, når der er konsensus og sikkerhed omkring projektet. De fleste bøger om projektledelse, projektstyring og projektværktøjer tager udgangspunkt i dette område.

Den plandrevne tilgang til projektledelse er udgangspunktet og historisk set den eneste fremgangsmåde for det, vi kender som fagområdet ”Project Management”. Fagområdet har udviklet sig stødt og roligt op gennem 1900-tallet. Det er først efter årtusindskiftet, at det meget anderledes ”Agile Project Manage-ment” har bidt sig fast. Mere om dette under det uvisse domæne i næste kapitel. Dette kapitel handler om kernen i god projekt-ledelse i traditionel forstand.

Kapitel 3


Projekttrekanten

Projekttrekantens tre hjørner består af indhold, ressourcer og deadline. Hovedpointen er, at disse tre skal være i balance. Selv om man kan ønske sig noget, der er billigere, bedre og hurtigere, så kan man ikke få alle tre ting. Man må nøjes med to! Eller sagt på en anden måde: Hvis det skal være billigt og gå hurtigt, bliver det sjældent godt. Hvis det skal være hurtigt og godt, bliver det næppe billigt, og hvis det skal være godt og billigt, bliver det sikket ikke hurtigt.

Uden at fortabe sig helt i historiebøgerne kan man sige, at projekt-trekanten er en vårunge på kun et par og tyve år. Naturligvis har de tre begreber tidligere været omtalt i litteraturen før det, men

Det sikre domæne


ikke så enkelt artikuleret som i projekttrekanten, der nævnes i en videnskabelig artikel første gang 1993.

Man skulle tro, at en så central model er lige så gammel som projektledelsesfaget, der nu er mere end 50 år gammelt. Eller måske dobbelt så gammelt, hvis vi skulle gå helt tilbage til Henry Gantt, der i begyndelsen af det 20. århundrede begyndte at bruge diagrammer med aktiviteter på en tidslinje – de senere kendte Gantt Charts, hvilket de kaldes, selv om de faktisk var ”opfundet” 100 år før, Gantts begyndte at bruge dem til sine tidsplaner.

Inden begrebet ”Iron triangle” blev populært i projektlederkredse, blev det i sin tid brugt om de tre aktører: Kongressen, Pentagon og våbenleverandørerne i USA. Så her har militæret endnu engang inspireret projektledelsesfaget.

For at gøre billedet fuldstændigt kan det nævnes, at projekttre-kanten har en variant, der kaldes projektdiamanten. Diamanten har fire hjørner: Tid, Ressourcer, Scope og Kvalitet. Projekttrekantens ene hjørne, indhold, er således blot opdelt i de to sidstnævnte parametre i diamanten, og ellers er det helt det samme.

Desuden kan det nævnes, at PMI (Project Management Institute) i stedet for en trekant benytter en sekstakket stjernet, der medtager parametrene: Scope, Quality, Cost, Ressources, Time, Risk. Stjernen er mere korrekt og præcis, men også sværere at huske. Til vores formål er projekttrekanten alt rigeligt.

Hvilken rolle projekttrekanten spiller i den plandrevne projektledelse, kommer vi ind på i det følgende.

Kapitel 3


Ja-hatten

Projektledere er som udgangspunkt optimistiske folk, der kan genkende en udfordring, når de ser en, og de takker med glæde ja til at få ansvaret for den. Når nye projektledere skal lære faget, kommer de ofte med ja-hatten på.

Inden man for alvor forstår projekttrekantens budskab, har man en tendens til at have ja-hatten trukket godt ned over øjne og ører. Men hvis man siger ”Yes Boss” til alt, bliver det hurtigt umuligt at holde sine aftaler. Og ikke nok med det: Man bringer også bossen i vanskeligheder ved ikke at sige fra, hvis bukserne ikke kan holde.

Det tager ofte noget tid, inden nye projektledere opdager, at de bliver nødt til at sige ”nej”, indtil der foreligger realistiske vilkår i form af en projekttrekant, der er i balance.

Situationen er egentlig grotesk i al sin enkelthed, hvilket tydeligt ses med en sammenligning:

Lad os sige, at du er bilejer og konstaterer, at der er noget galt med bilen. Derfor kører du hen til værkstedet. Her siger du: ”Min bil skal fixes til i morgen, og det må koste 1.000 kroner.” En projektleder ville måske blot sige ”Yes Boss”, men værkføreren siger noget mere passende: ”Jeg tager et kig på den og ringer til dig senere.” Når værkføreren ringer, er det for at give dig

Det sikre domæne


valgmuligheder. ”Du kan få bilen i morgen, hvis vi blot reparerer den med gaffatape. En bedre løsning er at renovere motoren, men det koster og kræver mere tid. Eller du kan komme ind forbi salgsafdelingen og se på en ny bil.”

I tillæg til historien hører også det forhold, at hvis reparationen af bilen reelt er uklar, så er det dét, der er meldingen fra værkføre-ren. Han ved jo godt, hvordan han undgår vrede kunder. Det eneste værkføreren lover er at arbejde loyalt på en løsning og holde dig underrettet om dine optioner, som arbejdet skrider frem.

Hvis flere projektledere tog bestik af denne fremgangsmåde, ville mange projekter være bedre stillet. Men særligt vidensmedarbej-dere har en forestilling om, at man kan nå det dobbelte på den halve tid – uden at reducere kvaliteten. Måske, fordi arbejdet foregår mere inde i hovedet frem for ude i virkeligheden? Projekter, der egentlig ikke i sig selv er komplekse, bliver det, fordi mange glemmer, at alting tager tid og kræver ressourcer. Hvis der ikke er aftalt tilstrækkelig tid og ressourcer, bliver projektet komplekst at udføre. Hvis der mangler tid, kommer alting under pres, og uforudsigeligheden øges. Hvis der mangler ressourcer, kommer man i modvind hos dem, man ”stjæler” ressourcerne fra.

Projekttrekanten er altid til forhandling, og må gerne genoptages, hvis man har lavet en regnefejl eller fejlestimat. Når man ikke har forhandlet sig til nok ressourcer, i forhold til de aftalte leverancer, har man faktisk svigtet sit team. Et andet sted, der også kan være afsat alt for få mandetimer til, er selve projektledelsen, hvor et godt nøgletal er, at man afsætter 1 time til at udføre projektledelse per 5 mandetimer til at lave projektets leverancer.

Kapitel 3


20 % timeoverhead til projektledelse

Selv om der er konsensus og klarhed, skal der bruges tid på projektledelse. En god tommelfingerregel er at lægge 20 % oven i den tid, dit team estimerer, at det skal bruge på de ting, projektet skal lave. Hvis man skal lede projektet, så sikrer man, at organisationen får værdi for de penge, der investeres i projektet.

”20 %? Det får jeg aldrig!”

Dén reaktion hører jeg ofte. Jo mere uerfarne projektledere er, jo sikrere er de ofte på, at de aldrig får 20 % overhead til at lave et projekt i. Dette kan skyldes, at det er de mere erfare projektledere, der er i stand til at italesætte værdien af deres projektledelse – og derfor også nemmere kan argumentere for, at der med investeringen skal følge en god sum til projektledelse. Nogle gange er det kun 10-20 %, men det er også ok. Så har man blot mere travlt!

Lad os se på baggrunden for dette nøgletal. 20 % overhead betyder, at der er en fuldtids projektleder, når teamet har 5 fuldtids team-medlemmer. Vi kan sammenligne det med linjeledelse. Mange linjeledere begynder at ømme sig, når de nærmer sig 10 vidensmedarbejdere. Ved over 10 medarbejdere begynder linjelederne ofte at opdele deres afdeling i teams med egen teamleder. Et fornuftigt princip. Medarbejdere i en afdeling ved ofte, hvad de skal lave. Deres Key Performens Indikatorer, KPI’er, er veldefinerede, og måske findes der medarbejder-håndbøger med procedurer og procesbeskrivelser. Sådan er det ikke for et teammedlem i projektet. Et projekt er per definition noget nyt og anderledes. Derfor skal man bruge mere tid på at afklare forventninger, roller, samarbejder m.m. Med andre ord: En

Det sikre domæne


projektleder har mere at se til per medarbejder end en afdelings-leder.

Hvad de 20 % timeoverhead konkret skal bruges til, det kommer vi til i senere afsnit. Først lidt mere om planlægning.

Projektplanlægning i plandrevet projektledelse Projektet begynder med en god idé eller et problem, der skal løses. Gennem den første fase bliver idéen eller problemet omformuleret til et formål. Nogle gange er projektlederen med i den initiale fase, andre gange ikke. Det er mindre afgørende. Et projekt kan komme i gang på flere måder, men når på et tidspunkt en sådan udvikling, der gør, at selve planlægningsfasen kan gå i gang. Afhængigt af projektmodenheden kan det være en styret proces, der involverer udfyldelse af bestemte dokumenter, registrering i projektporteføljen, oprettelse i økonomisystemet og andre formelle aktiviteter.

Projektets målformulering

Målformuleringen for projektet er det første, der skal på plads. Projektets målformulering er vigtig, uanset hvilket domæne projektet befinder sig i. Vilkårene er forskellige i hvert af domænerne, så derfor vil vi dvæle ved denne del af projektlederens værktøj.

Det er vigtigt, at projektets mål bliver opdelt i formålet og leverancen. Nogle gange anvendes andre ord, men det betyder mindre. Leverancen kan også blive kaldt projektmål, output, produkter eller andet. Det centrale er, at det kan leveres. Nogle siger det på den måde, at hvis det ikke kan være i en trillebør, så er det ikke en leverance. Det kan kræve en kæmpe trillebør, men

Kapitel 3


pointen er fin nok. Leverancen er det konkrete, som projektet efterlader sig, når den midlertidige organisering er færdig.

En leverance kan kun muliggøre, at formålet indfries.

”Muliggøre” er understreget, fordi det er væsentligt at bemærke, at der kun står ”muliggøre” – ikke garantere!

Overlægen skrev i journalen: ”Operationen lykkedes, men patienten døde”.

Det sikre domæne


Joken handler om overdreven faglighed, men joken har også en pointe. Formålet med operationen er naturligvis, at patienten overlever og efterfølgende har en høj livskvalitet. Men overlevelse kan lægen selvsagt ikke garantere. Til gengæld kan lægen tilbyde en leverance, en operation, som udføres efter alle kunstens regler – eller best practice, som det også hedder i projektverdenen. Efter ”leverancen” overtager patienten selv ansvaret for indfrielsen af formålet. På samme måde overtager projektejeren/styregruppen ansvaret for indfrielsen af formålet, efter at projektet har leveret det aftalte.

For at blive i det sikre domæne er det vigtig, at projektlederen kun tager ansvar for leverancen, ikke for formålet. Leverancen kan kontrolleres af projektlederen, men det kan formålet ikke. Sådan er det, blandt andet fordi formålet ofte først bliver realiseret længe efter, at leverancen er leveret, og projektet er lukket. Hvis projektet får ansvar for dele af eller hele formålet, bevæger det sig ud af det sikre domæne, idet usikkerheden – og måske også uenigheder – så tager til. Mere herom senere, når vi ser på overgangen fra domæne 1 til domæne 2 og 3.

Andre værktøjer fra den klassiske projektlederværktøjskasse

Det følgende er skrevet med det abstraktionsniveau, at den erfare projektleder bliver mindet om enkeltdelene i planlægning, og den mindre erfarne får overblik over, hvad der er at lære. Til sidstnævnte gruppe kan bogen ”Power i projekter og porteføljer” være en god introduktion, som nævnt i denne bogs indledning.

Kapitel 3


Interessentanalyse

Når projektets målformulering er på plads, er næste trin i plan-lægningen at lave interessentanalyse. Her påbegyndes også en kommunikationsplan. Den klassiske litteratur om kommuni-kationsplaner har ofte den antagelse, at hvis bare vi kommunikerer grundigt nok, så forsvinder interessemodsætningerne, med andre ord: Så bliver vi i det sikre domæne 1. Denne antagelse bygger på den rationelle tankegang om, hvordan organisationer virker, der som bekendt ikke holder hele vejen igennem.

En veludført interessentanalyse kan afsløre, at uenighederne er så store, at projektet faktisk ikke er i domæne 1, men derimod i det divergente domæne 3. Mere om dette, når domæne 3 belyses.

Tids- og aktivitetsplan

Lige siden Gantts første diagrammer har tids- og aktivitetsplanen været omdrejningspunktet for god projektledelse. Man kan med sindsro kalde den klassiske projektledelse for plandrevet. Man laver en plan og realiserer den.

Der er skrevet et væld af bøger om, hvordan man opstiller projekt-planer, så her nøjes vi med at henvise til dem. Udkommet af planlægningsfasen er i al sin enkelthed en projekttrekant, med visualiering af hvordan de tre hjørner hænger sammen.

Meget kort fortalt består processen i, at man tager beskrivelsen af leverancerne, finder et lille planlægningsteam og går i gang. Al erfaring viser, at det i denne fase er bedre at arbejde ”på væggen” end i MS projekt eller tilsvarende projektplanlægningsværktøjer.

Først laves en nedbrydning af leverancerne. Denne nedbrydning kan fx vise sig i en opdeling i svømmebaner, hvor man definerer milepæle og laver nedbrydningen i aktiviteter (eller i produkter,

Det sikre domæne


hvis man bruger PRINCE2). Man kunne også, som PMI (Project Management Institute) foreslår, lave en WBS-nedbrydning (Work Breakdown Structure) af leverancerne direkte. Der er som sådan ingen rigtig eller forkert metode at bruge.

Slutpunktet er, at leverancen er nedbrudt i en række arbejdspak-ker, og denne nedbrydning består af en veldefineret struktur, der skal sikre, at summen af enkeltdelene bliver lig den ønskede helhed.

Så er tiden inde til at opstille en kvalitetsplan: Hvordan vil du sikre, at arbejdspakkerne er gode nok? Og hvordan sikres, at leverancerne lever op til specifikationerne? Hvem skal godkende leverancerne, og er der defineret accepttest og kvalitetskriterier?

Herefter kan vi estimere varigheder og ressourceforbrug. Vi kan allokere ressourcer på arbejdspakkerne og identificere den kritiske vej, der definerer, hvornår vi kan være færdige med leverancerne. Hermed har vi været hele trekanten rundt: Vi er startet med ind-holdet, har estimeret ressourceforbruget, og til sidst har vi fastlagt en realistisk deadline.

Planen er indtil videre kun at betragte som en teenager, dvs. en der forventer, at alt går godt. For at gøre planen helt voksen skal vi lave en risikoanalyse og finde passende handlinger til at imødegå de risici, som ikke kan accepteres. Til slut har vi en risikobalan-ceret tids- og aktivitetsplan.

Det tog kun 5 minutter at skrive, men kan let tage et planlægningsteam 5 dage at udføre i et mellemstort projekt, hvis det skal gøres ordentligt.

Kapitel 3


Nu er planen lavet. Nu skal den realiseres. Det vil uundværligt være sådan, at der gennem realiseringsperioden kommer ønsker, nye idéer eller indtræffer uheld eller uhensigtsmæssigheder. For at undgå det såkaldte ”scope creep” etableres en ændringsanmod-ningsprocedure. Den bidrager til at holde projektet i domæne 1.

Begrænsning af det sikre domæne Det er afgørende at vide, hvornår projektet ryger ud af domæne 1, for når det sker, kan vi ikke længere bruge den plandrevne model som grundlæggende struktur. Det er vigtigt at bemærke, at planer også er vigtige i de tre andre domæner, men planerne er ikke drivkraften i dem. Desuden er planerne mere overordnet.

Det sikre domæne


Hvornår er usikkerhederne i og omkring projektet så store, at vi må opgive at planlægge projektet i sin helhed? Det er ikke let at opstille enkle regler for det. Men det er afgørende at have en fornemmelse af, når man designer projektet.

Der er flere af værktøjerne fra projektlederens værktøjskasse, der har til opgave at holde projektet i domæne 1.

Lidt forenklet kan man sige, at estimeringsmetoder, tolerancer, slack i tidsplanen, ændringsanmodningsprocedure og risikoplaner er værktøjer, der prøver at begrænse projektets usikkerhed. Eller anderledes formuleret har disse værktøjer til formål at flytte grænsen for, hvor det sikre domæne slutter, og det uvisse domæne begynder.

Kapitel 3


Værktøjerne i projektlederes værktøjskasse prøver således at stække gyldighedsfeltet for projekttrekanten. Figuren illustrerer, hvordan gyldighedsområdet forsøges strakt ind i domæne 2 og 3.

Interessentanalysen, kommunikationsplanen og projektorganise-ringen med referencegrupper, høringsgrupper med videre er projektværktøjer, der forsøger at holde projektet fra uenighed, med andre ord flytte grænsen for, hvornår det sikre domæne går over i det divergente domæne.

Det sikre domæne er kun et udtryk for en kendt fremtid. Det betyder ikke, at projektlederen slipper for at arbejde. Der skal laves forventningsafstemning og de mange planlægnings-dokumenter som nævnt, og desuden skal der laves diverse ledelses- og styringsdokumenter, som efterfølgende løbende skal opdateres.

Det kræver mange projektledertimer at fastholde projektet i det sikre domæne. Derfor er de omtalte 20% overheadtimer til projektledelse vigtig. Hvis du ikke får tiden til at lede et kompliceret projekt, så bliver det let komplekst – eller måske kaotisk.

Men selv med masser af tid til projektledelse og -styring er der grænser for, hvor langt man kan strække det plandrevne domæne til at håndtere usikkerhed og uenighed.

Ansvar for forretningsmæssige mål

Som vi var inde på i forrige afsnit, er projektet på vej ud af det sikre domæne, hvis man som projektleder også får ansvaret for realisering af formålet. Formålet er de forretningsmæssige mål, dem vi også kalder succeskriterier, resultatmål eller outcome –

Det sikre domæne


begreber, der alle udtrykker realisering af organisationens benefit ved projektet.

For fuldstændighedens skyld kan det nævnes, at visse projekt-ledelsesbøger argumenterer for, at projektlederen også har ansvar for resultatmål. Disse bøger har således blot overskredet grænsen for det plandrevne.

Den klassiske rollefordeling er således: Projektlederen tager sig af leverancen, styregruppen tager ansvaret for realisering af succeskriterierne og indfrielsen af formålet. Naturligvis bør projektlederen interessere sig meget for formålet, for det er med til at skærpe forståelsen af leverancen, men det er stadig styregruppens ansvar, at succeskriterierne bliver realiseret. Det forholder sig sådan af den simple grund, at succeskriterierne tidsmæssigt ligger efter, at leverancen er afleveret, og projektet afsluttet.

Sat på spidsen er situationen denne: Organisationen laver en midlertidig organisation, et projekt, der låner personer til at frembringe en leverance. Denne leverance skal implementeres i organisationen. Denne implementering volder typisk problemer. Problemer, der bliver forværret af, at modtagerne i organisationen ofte er nogle andre personer, end dem der har sat projektet i gang.

Projektlederen kan have fuld kontrol over leverancen og den midlertidige organisation. Kontrollen over den midlertidige organisation kræver, at projektlederen har klare allokeringsaftaler, at der ikke er tvivl om, hvornår og hvor meget man er

Kapitel 3


teamdeltager. Den øverste pil i figuren. Det at fremstille leverancen kan godt være kompliceret, men dog inden for kontrol, hvis usikkerheden er lav. Men når leverancen skal sættes i spil i organisationen, så kommer projektlederen til at spille på udebane. Den nederste pil i figuren herunder

Derfor kan man som projektleder kun påtage sig ansvar for at frembringe en leverance, men resten af processen er man ikke herre over. Implementering, forandringshåndtering og i særdeleshed benefitrealisering kræver, at man har magt over organisationen.

En sådan magt har projektet ikke, og derfor stiger usikkerheden – og sikkert også uenigheden – hvis projektet skal stå for mere end

Det sikre domæne


at levere en leverance. Det er naturligvis helt i orden, at en projektleder får både ansvar for implementering og forandringsprocessen, men det flytter projektet fra domæne 1 til domæne 2, 3 eller måske 4. Ansvar for forandringer flytter projektlederen på udebane, hvilket sætter projektet i en kompleks situation.

Særligt i mindre projekter ser man mange gange, at en person både er projektleder og samtidig har en lederrolle i forretningen. I denne situation er forventningerne ofte, at personen både gennemfører projektet og efterfølgende realiserer benefit. Det er ofte meget svært at få disse to roller til at forenes.

Projekter som mini-programmer

Komplekse projekter kan ses som et mellemtrin mellem almindelige projekter på den ene side og programmer på den anden (Hass, 2009). Når man giver en projektleder ansvar, der ligger ud over leverancen, er det en glidende overgang til at gøre personen til programleder. Komplekse projekter kan være mini-programmer.

Hvis vi taler om programmer, i stedet for projekter, så er rollefordelingen lidt anderledes. Den programansvarlige har ansvaret for alt fra leverancen til benefitrealisering, og har derfor ansvaret for organisationens udvikling. Ansvaret for leverancen er ofte uddelegeret til en projektleder. Processen fra leverance til benefitrealisering kan beskrives i disse overgange (MSP, 2009):

1. Leveranceaflevering 2. Kompetenceudvikling 3. Forandringshåndtering 4. Benefitrealisering

Kapitel 3


Hvis alle i organisationen var enige om, at det var netop disse benefit, der var de højest prioriterede, så ville det være let at realisere dem. Sådan er det bare ikke. Der er masser af divergens at håndtere, når man har et programansvar. Jo længere frem i programmets processer (de ovenforstående punkter 1-4), man får ansvaret som projektleder, jo mere får rollen karakter af programledelse. Samtidig kommer man som tidligere nævnt på udebane i organisationen. Udebane forstået på den måde, at det er linjelederne – ikke projektlederne – der bestemmer og prioriterer. Projektet er jo per definition en midlertidig organisation, som projektlederen får ansvar for og ledelsesretten over.

Tidshorisonten

Både en kort tidsfrist og lang tidsfrist kan være et problem. Vi ser på den korte tidsfrist først.

Et kompliceret projekt kan ændre sig til at blive komplekst, hvis projektet udsættes for et hårdt tidspres. Hvis projektet er kompliceret, og der er tid nok, så er det ”kun” kompliceret, fordi man har tid til at finde ud af tingene, at analysere problemstillingerne til bunds og forudsige projektets forløb i store træk. Når man ikke har tid til at forberede og undersøge forud, vil der uvægerligt opstå fejl. Hvor fejlene kommer, og hvor store de er, er naturligvis helt uforudsigeligt – og selv om man kunne forudsige det, så ville man ikke have tid til at gøre det!

Hvis tidshorisonten ligger langt ude i fremtiden, opstår et andet problem: begivenheder, der ændrer forudsætningerne for projektet. Der kan ved et langvarigt projekt let være så megen uvished, at det ikke giver mening at tale om en projekttrekant, der dækker hele projektet.

Det sikre domæne


Det giver ofte mening at tale om en ”eventhorisont”, altså en begivenhed i fremtiden, hvor man ikke har viden om, hvad der sker efterfølgende. En projekttrekant giver kun mening, hvis afslutningen ligger før en sådan eventhorisont.

Én og kun én projekttrekant

Hvis man ikke kan blive enige, så er der ingen projekttrekant. Eller rettere sagt: Så er der ikke EN projekttrekant. Der er flere. Der er måske den, teamet selv tror på, og så er der en, som kunden gerne vil have. Muligvis er der en tredje, som ledelsen prøver at få opbakning til. Ofte handler det om ønskerne til sammenhængen imellem indhold og ressourcer. Vil man have god kvalitet billigst muligt – eller vil man have god tid til at lave kvaliteten. To helt naturligt modsatrettede interesser, der viser hver sin ønsketrekant. Men også hastigheden, hvormed tingene skal - eller kan - udføres, kan være genstand for uenighed. Leverandøren vil helst have god tid, mens kunden ofte helst ville have haft leverancen i går. Hvis man ikke kan opnå enighed, kan man ikke have én projekttrekant.

Der kan godt være trekanter, der lapper over hinanden. For eksempel kan en leverandørs trekant indgå i kundens lidt større trekant, der måske har samme deadline. Men så giver det også mening at tale om de forskellige projekter – leverandørens underprojekt og kundens eget projekt.

Ud over de nævnte uenigheder om projekttrekanten kan der også være andre forstyrrende forhold, fx angående hvem der afleverer mandskabet, hvilke standarder skal benyttes, og hvem godkender resultatet og så videre.

Kapitel 3


Hvis der er uenighed, er der grundlag for konflikt, og når den optræder, er vi ude af domæne 1, og kommet ind i domæne 3, hvor vi har divergens.

Det behøver ikke at være åbenlyse uoverensstemmelser. Ofte er de langt mere subtile. Det kan være i situationen, hvor projektlederen har lavet aftaler om ressourceforbrug med styregruppen lige efter bogen. Desværre har styregruppen ikke magt, som den har agt, og derfor frigiver andre aktører i organisationen ikke ressourcerne. Dette er også divergens, og projektlederen må kæmpe for at få de ressourcer, som projektet allerede har fået ”tildelt”.

Eller en endnu mere drilsk situation, hvor styregruppen har sikret sig hos porteføljestyringen, at projektet kan blive prioriteret, og ressourcerne er til rådighed, så alt burde være i orden. Indtil det viser sig i praksis, at porteføljestyringens datagrundlag ikke er i orden, fordi andre projekter ikke har indrapporteret korrekt, så vores stakkels projektledere endnu engang må kæmpe for ressourcerne.

Det sikre domæne


Opsamling: Det sikre domæne Det sikre domæne med konsensus og klarhed er dér, hvor den klassiske projektledelse kommer fra. Det er her, hvor det er muligt på forhånd at specificere en leverance, estimere hvor mange ressourcer, der kræves for at frembringe denne leverance, og hvor man kan opstille en tidsplan, der fastlægger deadline. Med andre ord, at projekttrekanten på forhånd kan specificeres for hele projektet og efterfølgende realiseres.

Projektet ryger ud af det sikre domæne, hvis der er meget usikkerhed og/eller stor uenighed. Hvis vi ikke kan slippe af med uenigheden gennem brug af projektledelsesværktøjer som en kommunikationsplan eller en projektorganisering af interesserne, så bliver vi nødt til at agere politisk og forhandle os igennem projektet. Hvis vi ikke kan begrænse usikkerheden gennem bedre estimering, slack i planen og risikoplanlægning, bliver vi nødt til at anvende iterationer og agile tilgange i projektets gennemførelse.

I kapitlet har vi nævnt en række af de årsager, der kan være til, at projektet ryger ud af domæne 1 og ind i domæne 2, 3 eller 4. Det indlysende er enten høj grad af divergens eller stor uvished om mål eller metode. Derudover er der peget på faktorer som for eksempel:

• Ansvar for forretningsmæssige mål • Ikke timer nok til projektledelse • Projekter som mini-programmer • For lang eller for kort tidshorisont • Uenighed om projekttrekanten

Kapitel 4


Kapitel 4

Det uvisse domæne – konsensus, men usikkerhed!

Diskussionen i direktionslokalet var lettere ophidset. – Hvordan pokker kan det være, at tallene ikke holder, når nu projektlederen selv har lavet dem? Jeg kunne forstå det, hvis det var noget, vi havde dikteret, men det er deres egne tal. Se nu denne reviderede businesscase. Både forventet benefit og cost-siden er ændret. Hvordan skulle man kunne køre en rentabel virksomhed, når de ændrer på tallene på den måde? – Jo, men hvis vi skal være fair, sagde projektlederen ikke noget om, at det var et meget komplekst projekt? – Jo, det kan godt være, men når man kan få en rumraket til at ramme månen, så burde vores projektafdeling da også kunne ramme tallene i en businesscase. Det er jo ikke raketvidenskab, vores produkter består af. – Jamen, er en raketprojektion ikke blot et udtryk for fysiske love, så er det jo bare kompliceret – ikke komplekst! – Ha! Kompliceret eller komplekst, det lyder i mine ører som en dårlig undskyldning. Det samme kan man sige om deres bemærkninger om, at projektet er blevet klogere. Sikke noget pjat! Dengang jeg var ung, lavede vi businesscases og sørgede derefter for at holde den. Ikke al denne moderne sniksnak om feedback, bristede antagelser og emergens. – Jamen, var verden ikke også mere forudsigelig, dengang du var ung? – Sig mig lige en gang … Hvem holder du egentlig med? Mig eller sådan en uforudsigelig projektleder? – Hmmm, tja, jeg ved ikke rigtig, om jeg tør svare på det spørgsmål.

Det uvisse domæne


Domæne 2 kalder vi det uvisse domæne, og det er her, man kan forvente det uventede. Fremtiden byder på emergens, men vi ved ikke, hvad det består af, hvor meget det er, og hvornår det kommer.

Formålet med dette kapitel er ikke at præsentere de agile metoder som sådan. Der findes allerede bøger, der beskriver metoderne udmærket. Derimod vil vi se på, hvordan man generelt kan håndtere uvished og usikkerhed i projekter. Som bogens forside lader antyde, kan kompleksitet blandt andet håndteres med agilitet. Det er i dette lys, at vi trækker udvalgte aspekter af de agile projektmetoder frem.

Kapitel 4


I domæne 2 har vi konsensus og uvished, jævnfør vores projekt-kompleksitetsmatrix. Med andre ord er vi enige om projektet og dets formål, men uforudsigeligheden forhindrer os i at lave en holdbar plan, fordi vi er usikre på, hvilke indhold og fremgangsmåde der vil kunne realisere formålet.

Der kan med andre ord være usikkerhed om, hvad leverancen bør være for at muliggøre formålet. Hvis vi kender leverancen, kan usikkerheden bestå i, hvordan den skal laves, og dermed hvor lang tid den tager og koster at frembringe. Kort og godt: Det er ikke muligt at opstille en projekttrekant for hele projektet.

Hvis launch-tidspunktet er usikkert, bliver benefit også usikkert. Som nævnt er kost-siden heller ikke sikker, derfor bliver cost/-benefit i businesscasen en meget tvivlsom affære. Hvad gør man så som beslutningstager?

Jo mindre projektet ligner noget, vi har prøvet før, jo større er usikkerheden ofte. Og for at gøre ondt værre kan der være stor usikkerhed på usikkerheden. Der forventes emergens, men vi ved ikke, hvornår og hvor meget, der kommer.

Det er én ting at bevæge sig på tynd is, men det er straks noget andet, hvis man ikke ved, om man er på tynd is – eller hvor tynd den egentlig er! Hvis man ved, at isen er tynd, indretter man sin fremfærd efter det. Hvis isen derimod ikke er tynd, vil samme fremfærd virke helt tåbelig. Det samme vil det gøre, hvis man har en fremfærd, som om isen var tyk og sikker, men at det viser sig, at isen alligevel ikke kan holde.

Metaforen er givet for at vise, at usikkerhed er en tricky størrelse. Hertil kommer, at der blandt interessenter og beslutningstagere kan være stor uenighed om usikkerheden.

Det uvisse domæne


Planlægningsdilemma

Projektlederens klassiske beslutningsdilemma: I starten træffes de afgørende beslutninger, og med tiden bliver der færre friheds-grader for beslutninger. Viden oparbejdes gennem projektet som læring, der kan gøre beslutningerne bedre. I den klassiske projekt-model er vi i den situation, at vi træffer vores afgørende beslut-ninger, når vi har mindst viden. Når vi har opnået nødvendig viden, så har vi ingen beslutningsrum tilbage.

I sikre domæne, hvor indholdet er kendt fra staten, er lærings-kurven flad, og derfor er problemet af overskuelig størrelse. Men i det uvisse domæne, hvor der er meget uvished – og dermed en stejl læringskurve – er dilemmaet ikke til at komme uden om.

Kapitel 4


Løsningen på dilemmaet er: Udskyd de afgørende beslutninger, til projektet har mere viden. Dette kræver, at projektet kører efter en agile projektmodel. Det betyder ikke fravær af planer, men derimod at de kun rækker et spring (eller timebox) ad gangen.

Med metaforen ovenfor kan man sige det således: Hvis du ikzke ved, hvor tyk isen er, så lad være med at planlægge, hvordan du vil komme over søen, indtil du har denne viden. Lav en test, udfør et eksperiment, lav en prototype, opdel lasten i små portioner eller noget helt andet. Dette er, hvad man er nødt til, hvis projektet befinder sig i det usikre domæne.

Ud over en iterativ tilgang til vandring på isen er det vigtigt, at folk ikke bliver nervøse. Skab ro og tryghed gennem arbejde med visionen og en kultur, hvor det er tilladt at fejle. Med andre ord, det skal være helt ok, at man ryger gennem isen, når bare vi lærer noget af begivenheden.

Agilitet versus agile projekter

Der er mange positive fordomme om den agile fremgangsmåde til ledelse af projekter. Mange af dem er desværre ønsketænkning, som metoderne ikke kan indfri. Der er brug for en sondring imellem, hvornår vi taler agilt, som et udtryk for at være fleksibel og omstillingsparat, og hvornår vi mener agile projekter i henhold til de metoder, som er kommet til de senere år.

Agilitet leder tankerne hen på høj fleksibilitet og mulighed for øjeblikkelig ændring af retning og hastighed. En agil organisation er adaptiv og forandringsparat – hele tiden. Sådan er agile projekter ikke!

Det uvisse domæne


Som eksempel på ovenstående er metoden Scrum utrolig fleksibel, hvad leverancen angår, for den kan ændre sig meget fra sprint til sprint. Omvendt er Scrum utrolig dogmatisk med sine grundregler og meget rigid med sine roller, ceremonier og artefakter. For at kunne være fleksibel med indholdet er de agile projekter ufleksible med struktur og rammer.

Hvis et plandrevet projekt er som en kæp, der kan bøjes lidt, så er de agile projekter som en kæde, der kan bøjes meget, men hvert led er ubøjeligt i sig selv.

Skal vi have et plandrevet eller agilt projekt?

Domæne 1 forudsætter, at vi kender bestemmelsesstedet. Dette svarer til forudsætningen bag det spørgsmål, som Filurkatten driller Alice med i Alice i Eventyrland af Lewis Carroll.

One day Alice came to a fork in the road and saw a Cheshire cat in a tree. “Which road do I take?” she asked. “Where do you want to go?” was his response. “I don’t know” Alice answersed. “Then,” said the cat, “it doesn’t matter”.

Kapitel 4


Mødet imellem Filurkatten og Alice i den agile version af historien kunne i stedet lyde sådan:

– ”Hvilken vej skal jeg tage?” spurgte Alice Filurkatten, der sad i træet. – ”Det kommer an på, hvor du vil hen”, svarede Filurkatten. – ”Det ved jeg ikke”, svarede Alice. Filurkatten skulle lige til at svare: ”så er det lige meget, hvilken vej du går”, men tog sig i det, og sagde i stedet: ”Så må du tage den agile vej”. Alice stoppede op, for sådan var den klassiske udgave jo ikke. Men hun ville jo gerne videre, så hun spurgte: ”Hvilken vej er så det?” Filurkatten forklarede: ”Først vælger du den retning, der virker mest værdifuld. Stop op med jævne mellemrum, evaluér turen og vurder, hvordan du kan komme videre dérfra. Vælg så den retning, der nu virker mest værdifuld”. ”Jamen, hvordan ved jeg så, hvilken vej der er mest værdifuld?” spurte Alice for at forstå det hele ”Se ikke ned på vejen, men kig op på visionen, så ved du det ”, svarer katten muntert. ”Hmmm”, sagde Alice eftertænksomt, ”Men hvordan ved jeg så, hvornår jeg er fremme?” ”Det er nemt nok” sagde katten. ”Du er færdig, når du vurderer, at vejen ikke længere er værdifuld at gå videre af, og det er, når du ikke skaber merværdi, der berettiger yderligere vandring”. Og med disse ord var katten væk.

Det uvisse domæne


Tilbage i den virkelige verden kan vi sige, at projektets formål forbliver, som det er – uanset om vi bruger den agile eller den plandrevne metode. Det, der er forskelligt, er, hvordan leverancen kommer til verden – og i særdeleshed, hvornår leverancen bliver fastlagt.

Som beskrevet i forrige kapitel bliver leverancen ved den plandrevne metode fastlagt i begyndelsen. Herefter er det kun godkendte ændringsanmodninger, der kan ændre på leverancen.

Med den agile fremgangsmåde bliver leverancen specificeret/fastlagt løbende hen igennem projektet, hvilket betyder, at vi faktisk ikke kender det samlede indhold, før projektet er afsluttet.

I begge typer projekter kan leverancen kun muliggøre, at formålet indfries. Dette ændres ikke, uanset hvornår leveranceindholdet fastlægges. Med andre ord kan man sige, at et projekt i domæne 1 kan være leverance-styret, mens et projekt i domæne 2 bliver nødt til at være mere formåls-styret.

Men er der enighed om formålet? Ikke nødvendigvis, men hvis der er flere konkurrerende formål, så er vi i det divergente domæne. Her i det uvisse domæne forudsætter vi, at der er konsensus om projekts formål, men uvished om, hvordan det indfries.

Kilder til uvished/usikkerhed

Uvished/usikkerhed kommer i mange former og farver, men for klarhedens skyld kan her nævnes en række eksempler:

• Der er lavet en kravspecifikation, men afspejler den virkelig, hvad kunden egentlig har brug for? Hvor godt har

Kapitel 4


analytikerne forstået brugernes behov? Hvor godt kender brugerne behovet selv?

• Vi har ikke prøvet denne fremgangsmåde før. Hvor gode er vores estimater, og har vores aktivitetsnedbrydning det hele med?

• Det er en stram tidsplan, og der er mange risici. Kan vi bevare overblikket over udviklingen, samtidig med at vi har travlt?

• Vi regner med, at vi kan bruge teknologi X og Y, men fungerer disse to teknologier sammen?

• Er konkurrenterne på vej med noget, der spolerer vores markedsplaner, så denne produktudvikling mister sin relevans?

• Hvordan vil brugerne reagere på den nye teknologi og de medfølgende ændringer af forretningsgangen? Kommer der stor forandringsmodstand?

• Bringer dette projekt os ind på et nyt og ukendt forretningsområde?

Som du måske allerede har luret ved at læse denne liste, så afhænger projektkompleksiteten også meget af, hvad projektet har ansvar for. Har projektet alene ansvaret for en konkret fysisk leverance, eller er der også ansvar for områder som implemen-tering, brugernes anvendelse, salget og den forretningsmæssige succes?

Der er en stigende tendens til at give projekterne ansvar for både forandring og benefit-realisering. Denne tendens øger projekt-kompleksiteten markant. Tendensen er mest udbredt i mindre projekter.

Det uvisse domæne


Projektmodeller fra IT-branchen En af de brancher, der har ændret projektformen meget i de seneste årtier, er IT-branchen. Baggrunden for ændringen har blandt andet været meget store, dyre projekter, som er kørt i hegnet. Særlig kendt er offentlige projekter, fx projekter som Amanda, Polsag og senest Skats store skandalesag. Førstnævnte løb 200 % over budgettet og kostede 650 millioner kroner. Polsag havde til sammenligning ”kun” overløb på næsten 100 % og kostede 425 millioner kroner. Til gengæld nåede projektet slet ikke at komme i drift. Skats nye IT-system, EFI, endte med at koste 1,2 milliarder kroner, men endte med at blive skrottet for ganske nylig. Alle nævnte projekter var forsinkede i flere år.

PRINCE2 udspringer blandt andet af behovet for styring af store IT-projekter. Det samme kan man sige om Scrum, selv om de to metoder er meget forskellige i deres væsen.

En forenkling af disse to måder at håndtere kompleksitet er, at PRINCE2 forsøger at give kontrollen til topledelsen, mens Scrum giver den til udviklerne i projektteamet. Ja-ja, jeg ved det, dette er en voldsom forenkling, og der er brug for en nuancering. Pointen er, at PRINCE2 er en stage-/gate-model, hvor magten er placeret ved de centrale beslutningsgates. Scrum derimod giver autonomi til udviklingsteam.

En anden grov forenkling, man kan lave, er, at et sprint i Scrum-modellen principielt svarer til en stage i PRINCE2, selv om førstnævnte kun er 4-8 uger, mens sidstnævnte kan være flere måneder. Så selv om de to metoder er helt forskellige, er der ligheder i deres måde at inddele tiden i stykker med konstante vilkår.

Kapitel 4


En fællesnævner for både Scrum og PRINCE2 er, at man prøver at komme væk fra den klassiske vandfaldsmodel – men hver på sin måde.

Vandfaldsmodellen er en fasemodel, der udtrykker, at tilbageløb ikke er muligt. Modellen har to grundforudsætninger. Den ene er, at vi til at begynde med har fuld viden om behovet, således at man kan opstille en klar og tydelig kravspecifikation. Den anden er, at verden ikke forandrer sig, mens projektet er i gang, så behovet er stabilt. Vandfaldsmodellen er oplagt at bruge i det sikre domæne, men kompleksitet i form af uvished udfordrer vandfaldsmodellen kraftigt.

PRINCE2 prøver at skabe et kontrolleret miljø (heraf metodens navn: PRrojects IN Controlled Enviroment), hvor man etablerer processer og roller, der skal forhindre, at projekterne løber løbsk som følge af stigende uvished. Princippet er godt, men PRINCE2 ses desværre ofte i en overbureaukratisk implementering.

Scrum prøver modsat at få succes i et ukontrolleret miljø ved at etablere enkle regler for samarbejde, der kun består af tre roller, fire ceremonier og fem artefakter, som en måde at håndtere uvished.

Lidt filosofisk kan man sige, at PRINCE2 prøver at håndtere kompleksiteten udefra, mens Scrum prøver at leve med komplek-siteten ved at fungere inde i den.

PRINCE2 og stage-/gate-modellen

Stage-/gate-modellen er ikke en opfindelse, der kommer fra PRINCE2. Princippet er adapteret fra Coopers produktudviklings-

Det uvisse domæne


model, der anvendes meget i pharma-branchen. På grund af produktkompleksiteten designede Cooper innovationsprocessen som en ”forsøg-og-smid-væk-hvis-det-ikke-virker-proces”. Formålet med ”gates” er at stoppe de ufrugtbare forsøg i forskellige faser fra idé til marked. Forenklet sagt har PRINCE2 generaliseret Coopers produktudviklingsmodel til en projekt-ledelsesmodel.

En anden væsentlig sidebemærkning om stage-/gate-modellen handler om, hvad der er i den enkelte ”stage”. Illustrationen viser et stage-forløb med ide-stage, en planlægningsstage, gennem-førelsesstage og en afslutningsstage. Hver stage er afsluttet med en gate. En state-gate model på den måde er ikke ret meget mere fleksibel end vandfaldmodellen. Det er kun i det sikre domæne, at man vil kunne bruge en sådan version af stage-/gate-modellen.

Desværre ser man ofte en stage-/gate-model med denne form. Årsagen må nok tilskrives centrale beslutningstageres ønske-tænkning om, at verden altid er forudsigelig. Det er den som bekendt kun, hvis vi befinder os i det sikre domæne.

En mere agile udlægning af stage-/gate-modellen kan laves ved ikke at have en planlægning, derefter følgende ”blot” skal realiseres, men derimod have stages der er et afsluttet hele, som muliggør at man ved næste gate kan dreje projektet i nye veje.

Kapitel 4


Dette er på skematisk form se ud som skitseret i illusationen herunder, hvor indholdet af hver stage i denne udlægning udfyldt af Demings Wheel (Plan-Do-Check-Act). Med andre ord er den enkelte stage meget agile, mens man opretholder, at der er klare gates, som projektet skal igennem. Hvis Deming havde været i live, da PRINCE2 blev lanceret i 1996, ville han sikkert have foreslået det samme.

Scrum-modellen

En af de store fordele ved Scrum-modellen er, at den er forholdsvis let at forstå. Det er væsentligt at bemærke, at Scrum ikke er en projektledelsesmodel, men Scrum udmærker sig ved at være en meget simpel arbejdsmodel, der egner sig til mange projekter – ikke kun inden for IT.

Der bruges et par sider på at forklare hovedprincippet i Scrum, for lettere at vise, hvordan den kan hjælpe til håndtering af komplekse projekter.

Den ultra korte forklaring af Scrum er, at der findes tre roller, fire ceremonier og fem artefakter (der findes andre udlægninger af antallene, men det er uvæsentligt her).

Det uvisse domæne


De tre eneste roller, der findes i Scrum, er produktejer, Scrum-master og teamdeltager. Noget særligt ved Scrum er, at produkt-ejeren dagligt skal være tilgængelig for teamet. Det er enkelt og slagkraftigt. Når der kun er tre roller, er der heller ikke så meget at tage fejl af, men fleksibiliteten i organiseringen er lig nul.

Scrums fire ceremonier (som blot er et fancy ord for møder) er sprint-planlægning, daglige tavlemøder, sprint-review og sprint-retrospektiv. For forståelsen af Scrum er det væsentligt at forstå, at et sprint er et velplanlagt forløb, der bygger på estimater af de items, der udtages fra backlogen til fremstilling i det kommende sprint. Sprint har en længde på 4-8 uger. De daglige tavlemøder er vigtige for at holde kadencen højt gennem sprintet. Efter sprintet fremvises de færdige produkter til interessenterne, så man har mulighed for at bruge deres feedback i prioriteringen af kommende sprint. Sprint-retrospektiv er teamets egen feedback og evalueringsmøde, hvor man arbejder med forbedring af arbejdsformen under næste sprint. Både review og retrospektiv er således med til at sikre en høj læringskurve i projektet.

Kapitel 4


Der er stor principiel lighed med et sprint i Scrum og en omgang med Plan-Do-Check-Act i Demings Wheel.

Scrums artefakter er ”Product backlog”, ”Backlog item”, ”Sprint Backlog”, ”Sprint burndown chart” og ”Increment”. I vores anvendelse er artefakterne ikke så væsentlige for pointerne om, hvorfor scrum er så velegnet til håndtering af kompleksitet i form af uvished.

Scrum er ikke en projektledelsesmodel. I Scrum er der tre – og kun tre – roller. Der er ingen projektleder i Scrum. Det, vi normalt forstår som en projektleder, kan enten være i form af rollen som produktejer eller som Scrum-master. Produktejerrollen skal være en beslutningstager fra forretningen. Scrum-masteren skal være en ”servant leader”, det vil sige langt mere praktisk orienteret og servicerende, end vi sædvanligvis opfatter projektlederen.

Det kan forekomme at være lidt abstrakt at adskille produkt-ledelsesmodeller fra udviklingsmodeller, men det er en vigtig adskillelse, der tydeliggør, hvilke opgaver projektledelsen har - i modsætning til, hvilke opgaver teamet har.

Set i en historisk ramme kan man sige, at Coopers produkt-udviklingsmodel var for udviklingen af PRINCE2 projekt-ledelsesmodel, hvad Scrums IT-udviklings-model var for udviklingen af den agile projektledelsesmodel.

Scrum som værktøj til håndtering af uvished

Scrum kan håndtere projektet med en meget stor uvished. Backlog’en, der som nævnt er en ønskeliste – ikke en kravsliste – bliver hele tiden opdateret, så det mest værdifulde står øverst, klart til at blive taget med i det næste sprint. Beslutningstageren kan derfor ombestemme sig af hjertets lyst, uden at dette vælter

Det uvisse domæne


projektet. Den eneste begrænsning i Scrum er, at når emnerne er udtaget til sprintet, så laves det aftalte som aftalt.

I princippet kan projektet skifte til en helt ny retning, for hvert sprint. Dette vil man dog næppe se i praksis, for der vil være en overordnet vision med projektet, men Scrum sætter ingen grænser for ændringer.

Hvis man I et plandrevet projekt skulle forsøge at være lige så fleksibel, ville man hurtigt drukne i ændringsanmodninger. I Scrum er ændringer så at sige bygget ind i selve modellens grundstruktur. Ændringer i sprintets indhold er ikke tilladt, men de kommer ”gratis” med ved omprioritering af backloggen.

Til gengæld er Scrum-modellen ufleksibel på andre punkter. Der er kun 3 roller og 4 ceremonier, og Scrum holder meget fast på denne form. Man kan sige, at Scrum er firkantet med rammerne for at kunne være super fleksibel med indholdet.

Det agile læringsaspekt

Review er meget centralt for både Scrum og alle de andre agile metoder. Produktejeren inviterer udvalgte interessenter til at se og afprøve del-leverancen fra sprintet. Reviewet har stor betydning for retningen, projektet kører. Reviewmøderne er nøglen til et godt alignment mellem projekt og organisation.

Til sammenligning kan man notere sig, at et vandfalds-projekt også har et ”review-møde”. Det ligger til slut, hvor det er for sent at gøre noget ved det, man opdager på mødet.

Review bliver en kreativ kobling mellem projekt og aftager, hvor aftagerne bliver bedre i stand til at formulere egne behov, og

Kapitel 4


projektet bliver i stand til at forstå dem. Dette er en central del af håntering af uvisheden, der handler om leverancens indhold og anvendelse.

Den agile læringskurve bygger på dels den omtalte review, hvor man lærer, hvad organisationen i virkeligheden har brug for. Læringen består i, at man få lov til at afprøve delleverancerne, hvilket altid bringer nye indsigter med sig.

Desuden har Scrum og visse andre agile metoder også en indad-skuende review, kaldet retrospective, hvor teamet efter hvert sprint laver refleksioner og optimerer deres egne arbejdsmetoder.

Review og retrospektion gør Scrum til en meget adaptiv metode og skaber dermed en agilitet, som projekter med høj uvished har brug for.

Man kan notere sig, at Scrum lader hele interessent-håndteringen i hænderne på produkt-ejeren. Hvis denne person ikke læser organisationen korrekt, kommer der ikke værdi af projektet. I forhold til projektkompleksitetsvinduet, så forudsætter Scrum konsensus for at kunne håndtere en høj grad af uvished.

Agile projektledelse

Der er en bølge på vej ind over os. Nogle mener, det bliver en tsunami, men det er vist kun de ”agile evangelister”, der for alvor tror på, at det bliver så voldsomt. Men en bølge kommer der helt sikkert. Der er tre certificeringer i denne bølge:

• PRINCE2-agile. I sommeren 2015 har Axelos lavet en agile version af PRINCE2.

• PMP-ACP. For nogle år siden præsenterede PMI deres Agile Certified Practitioner.

Det uvisse domæne


• AgilePM. Den ældste er Agile Project Management (APMG International), som er en videreudvikling af tidligere adaptive projektmodeller.

Fælles for disse tre projektledelsesmodeller er, at de sætter de agile værktøjer som Lean, Scrum, Kanban, Sprint eller Timebox ind i en projektledelsesramme.

Vi må nok over de kommende år forvente at se et slagsmål om, hvem der er den ”mest rigtige” agile projektledelsesmodel.

Et af de steder, hvor Agile projektledelsesmodeller lægger meget til Scrum, er på antallet af roller, og hvordan interessenterne håndteres. Agile PM vil derfor være langt bedre end Scrum til at håndtere uenighed. I sin rendyrkede form forudsætter Scrum, at der ikke findes uenighed.

Lean start up

Scrum er udviklet med stor inspiration fra Lean-tænkning, men det er ikke kun IT-verdenen, der har taget inspirationen til sig. Også inden for iværksætteri er der kommet en Lean-bevægelse. Figuren herunder er baseret på tankegangen i Lean start up (Ries, 2011). Den cirkulære bevægelse Build-Measure-Learn bygger på Deming wheel Plan-Do-Check-Act, som er blevet omtalt tidligere i kapitlet.

Kapitel 4


Cirklens proces forløber forlæns, men processen planlægges baglæns. Dette skal forstås således, at det centrale er, at projektet har grundlæggende antagelser, som vi ikke kender gyldigheden af.

Antagelserne har brug for at blive be- eller afkræftet, så vi kan afgøre, om vi skal ændre retning eller fortsætte. I modellen kaldes dette pivot/perservere.

Be-/afkræftning af vores antagelser er lig med læring. For at dette kan ske, skal antagelserne formuleres som spørgsmål, der kan omsættes til målinger. Ud fra disse bygges målesystemer, der udtrykker, hvad vi ønsker at lære i projektet. For at målingen kan se, skal vi have bygget noget, der kan eksperimenteres med.

Den grundlæggende pointe i lean start up er, at man bygger et ”Minimal Viable Product”, kaldet en MVP. Altså en service, produkt eller andet, der lige netop er tilstrækkelig til, at nogle vil købe/bruge/afprøve det, så vi kan genere målinger, der skaber læring.

Ud over at hente inspiration til sit projekt-setup i domæne 2 fra Lean Startup kan man også lade sig inspirere af metoder som Prototyping, Design Thinking og de mange andre iterative metoder, der byder sig til.

Den måske vigtigste ting fra Lean start-up metode til håndtering af kompleksitet er den systematiske afprøvning af projektets antagelser. Det er en svær men vigtig opgave, at identificere sine antagelser, omsætte dem til spørgsmål og finde en sikker måde at få dem besvaret.

Det uvisse domæne


Oprigtig feedback fra en braintrust

Det måske stærkeste element ved de agile metoders håndtering af kompleksitet er at få interessenterne, brugerne, kunderne og andre til meget tidligt i processen at reagere på en foreløbig leverance, i form af en prototype, del-leverance, MVP, increment, eller hvad det nu passende kan hedde i den model, man anvender.

Bogen Creativity Inc, som er omtalt i indledningen, beskriver, hvordan Pixar har brugt meget tid på at opbygge en braintrust med firmaets mest erfarne folk, der lige fra start samles med jævne mellemrum for at give kritik af prototypen på filmen, der løbende forfines gennem omskrivning og redesign samt tilførelse af yderligere detalje-rigdom og finesse, indtil filmen har sin endelige form og historie.

Det afgørende for Pixar er, at braintrusten ikke har beføjelser over filmen. De kan påpege problemer og hvad, der ikke virker, de kan også komme med ideer og stille forslag, men det er projektet selv, der skal finde løsningerne og dermed sikre, at filmen viser fremdrift ved næste fremvisning.

Pixar har gennem årene opbygget en kultur med oprigtig og direkte feedback. Intet undlades, og alt er velkommen, fordi kulturen understøtter, at fejl er ok, og blot en del af rejsen. Det er, når man undlader at lede efter sine fejl, at problemerne opstår. Hvis man desuden lider af den tvangstanke, at man slet ikke fejler, så er katastrofen nær.

En braintrust, der ikke bestemmer, men i stedet inspirerer projektet til at udvikle sig trin for trin, kan givetvis lægge noget godt til den måde, mange projekter ellers kører.

Kapitel 4


Det sikre versus det uvisse domæne

En måde at beskrive forskellen mellem det sikre og det uvisse domæne er, at forløbet i førstnævnte er lineært, mens sidstnævnte er cirkulært. En måde at beskrive forskellen på er, at vandfalds-modellen er indholdsstyret, mens den agile er rammestyret.

I det sikre domæne er det muligt tidligt i projektet at forudsige – inden for en vis margin – trekantens sammensætning af indhold, ressourcer og deadline. I det uvisse domæne er det ikke muligt at forudsige det for hele projektet, men kun for det næste korte trin, hvor trinet kan være et sprint, en timebox eller en stage, alt afhængigt af om projektmodellen Scrum, AgilePM eller PRINCE2 benyttes.

En måde at sammenligne grundmodellerne på er at sætte dem på en skala, der udtrykker, om der er fokus på styring af indhold eller ramme. Når man styrer ud fra indhold, vil man ofte starte med en kravspecifikation. Omvendt, når man laver rammestyring, starter man med beskrivelsen af en samarbejdsform, der kan lade indholdet udvikle sig over tiden.

Med indholdsstyring lægger man vægt på kontrol, men den rammestyrede forudsætter en højere grad af tillid. Det er muligvis også derfor, at man ser topledelsen have modstand på at lade projekterne kører agilt. Der virker for utrygt ikke at kende indholdet af leverancen på forhånd.

Det uvisse domæne


Et spørgsmål, der ofte dukker op omkring det agile i forhold til det plandrevne setup: Bliver førstnævnte ikke dyrere, fordi kursen zig-zag’er mere, end hvis indholdet var fastlagt fra starten?

Spørgsmålet bygger på den ide, at det er muligt at fastlægge indholdet, så det giver måske ikke mening. Selv hvis det gjorde, har zig-zag-kursen en overraskende effekt: Det agile projekt ender nogle gange med ikke at bruge hele budgettet eller den periode, man har planlagt ud fra. Måske det lyder mærkeligt, men det er en direkte konsekvens af Paretos 80/20-regel, der siger, at 80 % af værdien bliver leveret af 20 % af indholdet. Når man gennemfører projektet iterativt og leverer indhold løbende, vil der komme et tidspunkt, hvor det resterende indhold ikke har så megen værdi.

Hvordan kan det hænge sammen, tænker nogen måske. Hvis det er med i kravspecifikationen, så har det vel værdi? Ja, det bygger på en forestilling om værdi. Ofte ser man, når brugerne er gået i gang med at anvende noget, at deres opfattelse af, hvad der er ”nice to have” og ”need to have”, ændres. Projektet er blevet klogere, kan man sige. Med den plandrevne tilgang kan den nye viden sjældent komme i spil, mens den bliver en naturlig del af den iterative tilgang.

Kapitel 4


Holder trekanten?

Projekttrekanten holder jo alligevel ikke, hører man tit, nogle sige. Men det gør den jo altid! Tiden går, og der kommer et eller andet indhold, som har kostet noget at fremstille. Så tid, indhold og ressourcer kan altid gøres op (hvis man altså har data). Der er en klar sammenhæng mellem de tre hjørner i trekanten. Når projektet er overstået, så er der gået noget tid, der er brugt en vis mængde ressourcer, og der er frembragt noget indhold – brugbart eller ej. Så projekttrekanten passer altid – men det kan være svært at forudsige, hvordan den tager sig ud på forhånd.

Spørgsmålet er blot, om vi kan forudsige, hvordan trekanten ser ud, når projektet er slut. Hvis det er let af forudsige, så er vi i det sikre domæne, hvis det er svært, er vi i det uvisse domæne.

Nogle mennesker er tungt forankret i den tænkning, der knytter sig til det sikre domæne, at de nærmest fornægter uforudsige-lighed. Deres mantra lyder: ”Naturligvis kan vi vide det på forhånd! Vi skal bare analysere det grundigt nok.” Men sådan er virkeligheden desværre ikke altid. Der er ting, som er for komplekse til at analysere på forhånd. Når det er overstået, kan vi se tilbage og give forklaringer på, hvorfor det gik, som det gjorde. Men det er ikke det samme, som at vi ville kunne forudse forløbet med den viden, vi havde på det tidspunkt.

Projekttrekanten er blevet udskældt. Mange taler om ”beyond the iron triangle”, når de taler om den moderne projektledelse. Nogle taler, som om agil projektledelse er et modstykke til projekt-trekanten. Dette giver kun mening, hvis man stirrer sig blind på en bestemt brug af trekanten. Projekttrekanten lever i bedste velgående i de agile metoder, men blot på en lidt anderledes måde. I stedet for at være en trekant, der defineres i begyndelsen

Det uvisse domæne


af projekter, er der mange successive trekanter. Hvert sprint har en benhård projekttrekant. De opgaver, der er udtaget fra ”back loggen”, er nøje afstemt med, hvad teamet har mulighed for at nå med de ressourcer, de har inden for sprintets deadline.

Det næste spørgsmål er: Hvilken usikkerhed vil vi acceptere? Vil vi have muligheder for at omprioritere hen ad vejen, når vi hen gennem projeketet er blevet klogere?

Sådan kan projekttrekanten se ud med den plandrevne tilgang, hvor krav-specifikationen er det vigtigste. Tid og ressourcer bliver

Kapitel 4


sekundære og dermed dem, der ”rammes” af projektets uvished og usikkerhed.

Projekttrekanten i den plandrevne versus den agile projektmodel

Forskellen handler metaforisk om, hvordan trekanten vender. Enten er indholdssiden (kravspecifikationen) vigtigst, ellers er tid/ressource vigtigst.

Hvis tid/ressource er vigtigst, bliver det til en rammestyring af indholdet. Når usikkerheden stiger, bliver man nødt til at gå væk fra indholdsstyring og hen mod rammestyring.

Det uvisse domæne


Man kan sige, at Scrum i særdeleshed og de agile modeller i almindelighed er meget rammestyrende. Dette skal ses i modsætning til den plandrevne projektmodel, der er meget indholdstyret, fx udtrykt ved en kravspecifikation.

Indtil nu har modellerne koncentreret sig mest om projektets leverance, og hvordan vi håndterer usikkerheden i forbindelse med denne. Nogle gange kaldes den agile tilgang også for den værdi-drevne i modsætning til den plandrevne.

I det agile setup er det indholdet, der er den mest usikre faktor, idet budgettet og tiden kan gøres til de begrænsende faktorer. Projekttrekanten vender derfor modsat af den plandrevne version, hvor udgangspunktet var, at ”papkassen var lukket”, fordi leverancen var fast.

Sat på spidsen, kan man sige, at det eneste, det agile koncept lover helt sikkert, er at bruge de aftalte ressourcer inden for deadline. Indholdet gives der ingen faste løfter om – og deraf kommer agiliteten.

Denne udlægning er god at sige højt til beslutningstagere, så man sikrer, at de faktisk gerne vil have et agilt projekt – på godt og ondt.

Det uvisse domæne handler mest om læring Det handler om læring. Når projektet starter, aner vi ikke, hvor det ender. I det sikre domæne kan vi se hele vejen hen til målet. Det uvisse domæne er kendetegnet ved, at den sidste del af projektet ligger i mørke. Og visse gange falder mørket tidligt på projektets tidslinje. Selv om visionen måske lyser lidt op, er stien mørk.

Kapitel 4


Først må vi lære en masse. Hvad er der i virkeligheden brug for? Hvordan kan det laves? Hvordan reagerer organisationen på projektet? Hvad sker der rundt om projektet, mens vi er i gang med leverancerne? Og ikke mindst: Hvilke fejlantagelser har vi lige nu?

Hvis den første plan, vi laver, alligevel ikke holder, fordi vores antagelser er usikre, så handler det om at lade planen fejle hurtigst muligt, så vi opdager, hvor vi tog fejl, så vi kan rette vores fejltagelser og prøve på ny.

I Scrum sker læringen ved gradvist at bygge systemet og lave reviews på produktet, der udvikler sig og laver retrospektiv på processen. I Lean start up sker læring gennem søsætning af MVP’er, der skaber viden og dermed former vores læring.

PRINCE2 har også indbygget en mulighed for høj læringskurve. Men det kræver, at man vil gentænke projektet ved hver gate. Der er mulighed for, at projektet kan være en fleksibel kæde af stages og ikke en massiv jernstang, som man ofte ser stage/gate modellen implementeret. Her er kodeordet: businesscase-opdatering. Skal det være en justering eller et helt nyt dokument, der er baseret på, hvad vi har lært af projektet indtil nu?

Når projektet har ”tilladelse” til at blive klogere, så bliver opdatering af businsesscasen en acceptabel ting. Sjovt nok møder man ofte protester mod dette i form af sætninger som ”I burde jo have vidst … ”. Det er dog mest en kritik, der kommer fra personer, der hellere ikke til at begynde med acceptere primissen om at der var stor uvished.

Det uvisse domæne


Opsamling: Det uvisse domæne Når projektets usikkerhed er over et vist niveau, går man fra det sikre til det uvisse domæne. Projektet ændrer karakter fra at være kompliceret til at være komplekst. Projektets delemner kan være fordelt over begge disse to domæner (ligesom over de andre domæner, hvilket vi kommer til senere).

Uvisheden kan handle om såvel leveranceusikkerhed, uklare metoder eller ukendte udefrakommende events. Der bør ikke være uvished om projektets formål i dette domæne, hvis der er, er projektet måske i det divergente domæne.

I det uvisse domæne må projektledelsen finde et passende projekt-setup, der kan håndtere uvisheden. I praksis vil det ofte være projektlederen, der kommer med et forslag til projektejeren om, hvordan dette kan gøres. Ud fra kapitlet kan der peges på fire anbefalinger til, hvad man bør fokusere på.

• Kommuniker uvisheden. Skab en udbredt forståelse af de uvisse elementer i projektet, og dermed kompleksiteten, der skal håndteres.

• Systematisk iteration. Muliggør agilitet ved at opdele tiden i intervaller, som kan hedde sprint, timebox eller stages, hvor der evalueres, og fremtiden genovervejes.

• Feedback fra omverden. Etabler regelmæssig ude-fra-ind vurdering af projektets delresultater, f.eks. i form af reviewmøder med interessenter, der kan ændre projektets retning.

• Fokus på læring. Fremelsk en læringskultur med villighed til at drøfte og afprøve egne antagelser, og hvor fejltagelser er helt ok, når de fører til læring.

Kapitel 5


Kapitel 5

Det divergente domæne – klarhed, men uenighed!

Ferien var tiltrængt. Efter at have sovet et par dage sad han og tænkte tilbage på projektet. Hvordan kunne det gå så skævt? Det var jo bare et flytteprojekt. Det burde ikke være vanskeligt at flytte et domicil med 500 medarbejdere. Det var bestemt heller ikke det indtryk, han have fået, da direktøren havde bedt ham stå for flytteprojektet. Måske skulle han have været mere kritisk og mindre smigret over, at direktøren gav ham en opgave med ordene: ”Det klarer sådan en som dig helt sikkert nemt.”

Det er én ting at sætte nedpakning i system, styre flyttemænd og arrangere indflytning, men det er noget helt andet at slås med særinteresserne om lokalefordeling, kontorlandskaber kontra enmandskontorer, fordeling af vinduer og prominente beliggenheder. Når man ændrer noget, og folk opdager, at deres gamle privilegier ikke er rettigheder, så opstår konflikterne nemt. Når man derudover er i en forhandlingssituation, hvor alt, man giver, skal tages fra andre, så bliver mulighederne for acceptable kompromiser små. Når det desuden ikke er muligt at bringe alle interessenter sammen, så de selv kan finde løsningerne, men tiden i stedet for går med at løbe fra den ene bilaterale forhandling til den næste, så mister man hurtigt overblikket. Projektet var virkelig en lang proces af uenigheder. I bagklogskabens klare lys kunne han godt se, hvordan de forskellige centrale personer havde meget forskellige interesser, som hver for sig var tydelige nok, men blot konfliktede med hinanden.

Det er svært at sætte en finger på, præcist hvornår hovedet på sømmet kom. Muligvis skete det gradvist, men der opstod en idé

Det divergente domæne


om, at den forestående organisationsændring skulle finde sted samtidig med flytningen. Nogle syntes vist nok, at det lød vældig rationelt. Han havde ikke lige været opmærksom nok til at se denne kobling opstå – så han fik ikke sagt nej i tide. Pludselig lå den nye organisationsplan som grundlag for det nye domicils lokalefordelingen og var dermed blevet en del af projektet. Set i bakspejlet er det nemt at se, hvordan frustrationen over den nye organisation blev ført over på flytteprojektet. Det er nemmere at kritisere de konkrete lokaleforhold frem for de diffuse problemer imellem afdelingerne. Den nye lokalefordeling, som han havde stået for, fik skylden for, at organisationen var dysfunktionel i månedsvis. Alt dette, blot fordi han ikke fik styret projektet uden om konflikterne.

Han skulle jo bare sørge for flyttemænd, elektrikere og indretningsarkitekter. Hvordan pokker kunne han så pludselig befinde sig midt i en magtkamp om enmandskontorer, vindues-pladser og kontorlandskaber? Hvordan skulle han have undgået, at divergensen splittede flytteprojektet? Han havde jo ikke magt til at sætte rammerne eller styre dagsordenen, eller havde han?

Meget ville været gået anderledes, hvis han havde sagt nej flere gange, krævet bedre vilkår for projektet – og frem for alt sagt fra overfor en organisationsændring i samme periode.

Kapitel 5


I det divergente domæne er der klarhed om tingenes sammen-hæng, men aktørerne er uenige.

Det helt simple tilfælde er således: Vi ved, hvad der sker, hvis vi vælger A. Vi ved også, hvad der sker, hvis vi vælger B. Vi kan bare ikke blive enige om, hvorvidt vi skal vælge A eller B. Med andre ord, der er klarhed, men uenighed.

Hvis det i situationen desuden er uklart, hvem, der kan/må/skal bestemme, hvis vi er uenige, så er der lang vej frem til en løsning. Jo mere tværorganisatorisk projektet er, jo større bliver dette problem ofte.

Uenigheden kan både være en åbenlys konflikt, eller det kan være en diffus, skjult og uklar eller blot uopdaget forskel. I begge tilfælde kalder vi det divergens, som er et udtryk for noget, der fjerner sig fra hinanden.



Mennesker mødes, og divergens opstår. Sådan kan vi smukt omskrive talemåden om sød musik. I projektsammenhænge kan divergens optræde mange steder, fx i teamet, over for styre-gruppen, i forhold til leverandører, kunder, brugere, myndigheder. Nogle gange bliver divergens til konflikter, andre gange eksisterer det som ulmende uenigheder over lang tid, og heldigvis opnås der nogle gange konsensus, så man kan komme tilbage til det sikre domæne.

Vi vil helst opretholde billedet af et projekt som en rationel proces, der er styret af en leder, som har en plan for forløbet, der vil samle de forskellige bidrag til en helhed. Nærmest som en dirigent gør for sit orkester til publikums store fornøjelse.

Den største ineffektivitet af alle

”Politisk” bliver af mange projektledere opfattet som et skældsord. Måske med rette, fordi det besværliggør den rationelle projektledelse. Men hvis man er i en situation med konfliktende holdninger, og dermed en stor grad af uenighed, så er man nødt til at forholde sig til situationen med de politiske briller på. Vender

Kapitel 5


man det blinde øje til, fordi man ikke vil se det, så bliver det ofte værre.

Senere i kapitlet kommer vi til at se på, at det divergente domæne måske slet ikke er så irrationelt, som vi gør det til. Det er i stedet et spørgsmål om, at andre bruger rationaler, der er anderledes end dine egne – og at de derfor ser irrationelle ud i dine øjne. I deres øjne er de fuldt ud rationelle, og de kender jo også deres egne intentioner. De ved, hvad rationalet i virkeligheden er – også selv om du og andre ikke kan gennemskue det og derfor tror, at de handler irrationelt.

At mennesker vil noget forskelligt, giver helt sikkert anledning til ineffektivitet. Men ineffektiviteten bliver overgået af en endnu større potentiel ineffektivitet, der består i, at projektet kører videre, selv om divergensen er blevet stor.

Peter Drucker har sagt, at den største ineffektivitet er en perfekt udførelse af noget, der ikke skulle være gjort.

Det er denne ineffektivitet, man risikerer, hvis man lader projektet køre videre trods stor uenighed og divergens. I særlige tilfælde kan det være nødvendigt at køre projektet videre trods modstand. Der kan være gode grunde til at køre videre, og så må man jo fortsætte til den bitre ende. Og den bliver helt sikkert bitter, når den stærke overvinder modstanden ved hjælp af sin styrke.

Men i langt de fleste tilfælde må man stoppe projektet og arbejde med diversiteten, indtil projektet kan få en ny kurs, hvor der er enighed nok til, at formålet efterfølgende kan realiseres.

Isoleret set kan leverancen ofte laves, hvis blot projektet får penge og ressourcer nok – men formålet kan sjældent indfries, hvis



divergensen er høj. Det er derfor ikke en sag for projektlederen alene, men for projektledelsen som helhed. Det er ofte projekt-lederen, der skal tage udfordringen op og foreslå projektet stoppet, indtil der foreligger bedre vilkår.

Er dit projekt ramt af uenighed?

Hvis du er usikker på, om der er divergens i dit projekt, så brug denne lille test: Spørg de centrale interessenter om, hvilken prioriteringsrækkefølge, de synes, der bør være for projekt-trekantens hjørner. Hvad vægter de højest: deadline, ressourcer eller indhold? Hvad vægtes næsthøjest og herefter? Er dine centrale interessenter enige, eller er der uenighed? Og hvad med de lidt mindre, men centrale interessenter – hvad synes de?

Kapitel 5


En anden lille test: Har projektet fået lovning på ressourcer, som alligevel ikke er tilgængelige? Hvis ja, så foreligger der sikkert divergens, for de manglende ressourcer er sikkert et udtryk for, at nogen synes, at noget andet var vigtigere end projektet. Det kan være, at styregruppen ikke var enige med linjelederne om, hvor mange ressourcer der skulle gives, og hvorfra de skulle komme. Det kan også være porteføljegruppen, der nok har en fin oversigt over ressourcer, men ikke magt nok til at tildele disse til projekterne. En tredje årsag kan være, at de pågældende medarbejdere blot havde helt andre mål, hensyn og interesser at varetage og derfor prioriterede projektet lavere. Hvorom alting er, så skal der findes en løsning på problemet, og løsningen indebærer ofte forhandlinger parterne imellem.

En konflikt, der rammer de fleste projekter

Konflikt er et andet ord, vi normalt heller ikke bryder os så meget om. Men konflikt og konfliktløsning er en naturlig del af virkeligheden. En grundlæggende konflikt, som flere projekter bliver ramt af, er interessemodsætningen imellem leverandør og kunde – eller imellem modtager og betaler. Der behøver ikke at være en ekstern kunde, for at konflikten kan opstå. Konflikten kan udtrykkes med projekttrekanten. Kunden ønsker at betale mindst muligt for leverancen og vil gerne have leverancen hurtigt. Leverandøren ønsker at blive betalt bedst muligt og vil gerne have god tid til arbejdet. Der er modstridende interesser til både indhold, ressourcer og deadline i trekanten. I første omgang er det en salgsproces: Leverandør og kunde skal blive enige om en og samme trekant for projektet. Når projektet er solgt eller aftalt, er det en tilbagevendende kilde til konflikt at holde trekanten i balance. Hver gang der sker noget uforudset, er spørgsmålet:



Hvem skal nu betale? Eller: Skal en forsinkelse koste noget? Eller: Giver ændringen af indhold anledning til en merbetaling?

PRINCE2, som vi har talt en del om i forrige kapitel, har følgende forslag til kontrol af interessekonflikten: Der skal være en repræsentant for både leverandør og kunde i styregruppen. Så kan projektlederen få et afklaret og entydigt mandat. I teorien et godt forslag, men i praksis løser det ikke alle problemer. Interessekonflikterne kan være for komplekse til at blive løst på et månedligt møde, hvor parterne er repræsenteret.

Politiske vilkår Politik kaldes ofte „det muliges kunst“. Og kan man ikke sige det samme om de fleste projekter? Politik handler om interesse-modsætninger. Alt dette skaber divergens i projektmiljøet. Hvor meget divergens skal der til, for at vi kipper fra konsensus til uenighed? Det er svært at give en klar beskrivelse af, og der er helt sikkert også gråzoner. Man har derfor en politisk situation omkring projektet, når noget af det følgende gør sig gældende i ikke uvæsentlig grad:

• Organisationen har færre ressourcer end behovet i forhold til de projekter, vi vil gennemføre.

• Der hersker uenighed om, hvilke projekter der skal køre. • Enkelte personer har større indflydelse, end de formelt er

blevet tildelt. • Der er uenighed om prioritering af det ene eller det andet. • Der er magtkampe imellem grupper eller individer. • Der er forskel på den officielle projektportefølje og

realisternes verden.

Kapitel 5


• Det et svært at få en entydig prioritering af, hvilke projekter der er de vigtigste.

• Der er løbende kamp mellem projekterne og driften om ressourcer og nøglepersoner.

• Der bliver sat mere i gang, end organisationen kan overkomme at gennemføre.

• Der er zombieprojekter, der ikke rigtig vil dø, selv om de ikke har prioritet.

• Der er ikke den fornødne tillid til projektledelsen.

Med disse eksempler er det tydeligt, hvor politiske de fleste projektmiljøer i virkeligheden er. Alene det forhold, at projektet er en midlertidig organisation, der skal låne (og nogle gange stjæle) ressourcer fra den permanente organisation, giver anledning til interessemodsætninger og magtkampe – eller måske ligefrem ignorering og manglende opbakning til projektet. I det politiske perspektiv er et projekt noget, der opleves som én lang forhand-ling med skiftende parter. Politik handler om håndtering af uenighed. Der er i realiteten langt mere politik i organisationen, end vi egentlig bryder os om.

En gang imellem hører man en projektleder sige: ”Der er ikke politiske forhold i mit projekt. Problemet er alene manglende interesse fra topledelsen.” Uden at tage stilling til, om projektet skulle have haft opbakning, kan vi konstatere, at det ikke er lykkedes projektledelsen at få, hvad de mente, de havde brug for, fordi topledelsen valgte at prioritere deres opmærksomhed anderledes. Denne uenighed om prioritet bygger på interesse-modsætningerne og er dermed et udtryk for politiske forhold.



Politik er ikke noget, vi rigtigt taler om i projektlederkredse, og alligevel anerkender alle, at projektfiasko ofte udspringer af manglende opbakning fra topledelsen. Det er jo ikke sådan, at man mangler deres konkrete input (mange vil sikkert også helst være foruden, fordi den ikke bygger på detaljeret viden). Derimod mangler man dem til at bane vejen og få andre interessenter til at makke ret og gøre, som projektet har brug for. Med andre ord: Man mangler topledelsens magt.

Hvad er der at være uenige om ved projekter?

Mange projekter ville være nemmere, hvis vi var mere enige. Og sikkert også mere kedelige, vil nogle tilføje. Udover at være uenige, så ser vi også forskelligt på uenighed. Nogle ser uenighed som et minefelt af ødelæggende konflikter. Andre ser uenighed som potentialet for en berigende proces. Hvis du hører til den første gruppe, vil politiske projekter nok ikke være din kop te. Heldigvis kan man lære at tilegne sig det andet synspunkt.

De to nævnte opfattelser af uenighed er nok yderpunkterne på en linje, hvor de fleste af os nok ligger et eller andet sted midt imellem. Men uanset udgangspunkt kan vi nok alle blive bedre til at opdage og håndtere de politiske udfordringer i og omkring vores projekter.

Der kan være uenighed om mange aspekter af et projekt:

• Skal projektet overhovedet gennemføres? • Er det den rigtige retning og den bedste timing? • Har projektet flere, konkurrende formål? • Hvad skal udkommet af projektet være? • Hvad må det koste, og hvor lang tid må det tage? • Hvorfor skal vores afdeling levere ressourcerne?

Kapitel 5


• Hvad skal med, og hvad kan udelades? • Skal det helst være billigt, godt eller hurtigt? • Er det vigtigere end andre projekter? • Skal projektet eller driften have fortrin? • Er projektet bemandet rigtigt? • Er projektet forankret rigtigt i organisationen? • Hvem skal sidde i styregruppen? • Hvor store risici er det værd at tage? • Hvorfor gennemfører vi det? • Hvilke gevinster er de vigtige?

Der er et hav af potentielle uenigheder, og de er centreret om eksemplerne på uenighed inden for selve projektet. Hvis projektet forandrer vilkårene for andre, hvilket det ofte gøre i større eller mindre udstrækning, så kan der komme en stribe andre uenigheder som for eksempel:

• Er det nye virkelig bedre end det eksisterende? • Er det nu en forandring til det bedre eller ej? • Skulle vi ikke hellere gøre noget andet? • Skal projektet bestemme noget i linjen? • Skal vi prioritere implementering over daglige opgaver? • Hvem er ansvarlig, hvis forandringen udebliver? • Skal det være nu eller senere?

Politisk analyse af projektet Projektlederens værktøjskasse har et centralt værktøj: interessent-analysen. Interessentanalysen har en række specifikke formål:

- Input til organisering af projektet



- Input til risikoanalyse særligt vedrørende konflikter - Kommunikationsplan

Selv om interessentanalyse ofte har en kolonne til konflikter imellem interessenterne, er analysen kun en skygge af det politiske billede. En politisk analyse rækker noget videre.

En politisk analyse kan minde om en interessentanalyse, men der indgår langt flere parametre og overvejelser om interessenternes adfærd i forhold til projektet og projektets resultater. En politisk analyse kan vise, at planen ikke kan lade sig gøre. Det afføder naturligvis irritation hos en resultatorienteret person, som projekt-lederen ofte er, at konstatere dette. Men det er dog bedre at opdage umuligheden igennem analyse forud, end ved efter-følgende hele tiden at banke hovedet imod muren.

Hvis det handlede om Folketinget, kunne analysen reduceres til at tælle til 90 mandater. Det politiske liv i en organisation er mindre målbart, og den politiske analyse handler om at finde ud af, om vi kan få de andre til at gøre dét, som vi ønsker. Med andre ord: Har vi magt og indflydelse til at få dem til at makke ret? Magt er et ord, vi heller ikke så gerne anvender, men det er nødvendigt, at vi forholder os til, hvem der har magt til at gennemføre – eller forhindre – det, som projektet har brug for.

For hver aktør kan man begynde med deres rationelle perspektiv på projektet. Hvad kan interessenten opnå eller undgå? Det er her værd at huske på, at der er dobbelt så meget styrke i ”loss-aversion” (hvad man kan undgå) som i ”gain-seeking” (hvad man kan opnå) (Kahneman, 2011). Med andre ord: Dét, interessenten kan undgå, tæller dobbelt i forhold til, hvad denne kan opnå.

Kapitel 5


Dette betyder, at når man overvejer sine interessenter, er det vigtigt at vide, hvad de kan opnå ved projektet – men dobbelt så vigtigt at vide, hvad de kan undgå eller risikere at miste ved projektet.

Den politiske analyse handler om at forudsige, hvordan de forskellige interessenter vil agere i forhold til projektet. For at gøre det simpelt kan vi opstille tre forskellige handlemåder, de kunne have:

• Samarbejde • Nedprioritere • Modarbejde

Samarbejde består i, at man indgår i arbejdet, prøver at løse de problemer og issues, der opstår, og er aktiv i forhandlinger, hvis sådanne er påkrævet for at komme videre.

Nedprioritere betyder, at interessenten anerkender, at projektet er positivt, men at man blot har en anden prioritering, så man ikke ønsker at bruge sin egen tid og ressourcer på at samarbejde med projektet, for man har andre ting, som man synes er vigtigere. Ligegyldighed kunne også bruges som betegnelse for dette.

Modarbejde er ikke nødvendigvis for modstandens skyld, men kan være, fordi man synes, at ressourcerne kunne bruges til noget bedre, fordi projektet har dårlig timing, eller noget helt tredje. Med andre ord: Man har nogle andre mål, end projektet har, og projektet står i vejen for disse mål, så derfor ”modarbejder” man projektet.

Dette giver en 3 x 3 tabel, som kunne udfyldes for hver af de væsentlige interessenter (personer eller grupper). Tabellen



udtrykker, hvilke motiver de enkelte interessenter kan have for at agere fremmende, ligeglade eller hindrende på projektet. Det kan være et stort arbejde at kortlægge de centrale interessenter på denne måde, men hvis nok er på spil, er det forberedelserne værd. For at få input kan man tale med interessenterne om projektet for at høre, hvor de står, og hvad de tænker om projektets mål og planer.

Skemaet kan naturligvis bruges direkte til indsætning, men det er ikke tanken, at det skal bruges bogstaveligt. Den politiske analyse handler mere om at sætte sig i de andres sted end at udfylde skemaer.

Handleform Opnå Undgå Risikere Samarbejde (fremme projektet)

Nedprioritering (ligeglad med projektet)

Modarbejdning (hindre projektet)

Hvem lider, hvis projektet ikke lykkes?

Når du har gjort, hvad du kunne for at motivere personerne med et velformuleret ”hvorfor”, er det fint at tænke over følgende spørgsmål for yderligere at kende den politiske situation:

• Hvis projektet bliver forsinket, hvem går det så ud over? • Hvis projektet ikke lykkes godt, hvem bliver så belastet? • Hvis projektet bliver en fiasko, hvem skader det så?

Kapitel 5


Alle spørgsmålene kan formentlig besvares med ”projektlederen”. Sandsynligvis også sponsorerne. Men hvem har ellers noget på spil?

Hvis du skylder banken 100 tusinde, har du et problem, men hvis du derimod skylder banken 100 millioner, har banken et problem.

Jo mere de har at miste, jo bedre samarbejdspartnere kan de blive – hvis de da har indset, hvad de potentielt kunne miste ved ikke at samarbejde. Nogle gange skal du selv sætte ord på, hvilke ”millioner banken har på spil”, som de taber, hvis de ikke hjælper dit projekt frem til succes. Det kræver ofte, at man tænker lidt dybere over situationens mulige implikationer.

Projektlederen til møde hos coachen

PROJEKTLEDER: Det projekt kan bare ikke lade sig gøre med de interessenter! COACH: Hvis projektet ikke kan lade sig gøre, så skal det jo afsluttes. PROJEKTLEDER: Det var ikke dét, jeg mente. Det er bare meget svært at gennemføre. COACH: OK. Så det er altså muligt? PROJEKTLEDER: Nej. Jeg vil nærmere sige, at projektet kun har en meget lille sandsynlighed for succes. COACH: Ved din sponsor godt, at der bruges penge på noget, der sandsynligvis er spildt? PROJEKTLEDER: Øh, nej! Altså, hvor er du pisse irriterende at snakke med.



COACH: Ha, ha. Ja, måske. Og måske prøver jeg blot at hjælpe dig med at være mere konsekvent. Har du tænkt på det? PROJEKTLEDER: Hvad mener du? COACH: Hvis det er meget lidt sandsynligt, at dit projekt lykkes med de interessenter, der er, så bør du måske overveje at gøre følgende: Lav en analyse, der viser, at projektet er praktisk taget umuligt i den aktuelle politiske situation. Fremlæg analysen for din sponsor. Så kan der ske én af to ting. Enten takker han dig for, at du tog initiativ til at få stoppet det fortsatte spild af penge på et projekt, der ikke er muligt. Eller også begynder han at lede efter, hvordan omstændighederne for dit projekt kan ændres, så det bliver muligt. I begge tilfælde er du bedre stillet, end hvis du fortsætter med de nuværende vilkår, som er imod alle odds. PROJEKTLEDER: Det kan der være noget om. Men hvad sker der, hvis jeg bare kører videre? COACH: Tja, det er svært at sige. Projektet kan blive et zombieprojekt, der blot suger ressourcer, men aldrig bliver til noget. Eller det kan køre helt i hegnet og miskreditere både dig og din projektejer. Det kan også være, at projektet er en lottokupon med en stor gevinst. Du kender sandsynligheden for dette bedre end jeg. Uanset hvad: Hvis du bare kører videre, er det dit ansvar – ikke sponsorens, for han ved jo ikke, hvad du ved. PROJEKTLEDER: Hmmm. Okay. Jeg laver analysen og tager snakken med min sponsor. COACH: Fint. Så snakker vi videre, når du har gjort det. Det giver ikke mening at planlægge, før du har haft mødet med din sponsor.

Kapitel 5


Gode råd til den politiske projektledelse Politik handler om relationer og kommunikation. Man kan tale om et politisk håndværk, når man mestrer at samle interesserne i en fælles løsning, der har så tilstrækkelig magt bag sig til at blive realiseret. Det er et håndværk, man kan være nødt til at bruge i visse projekter.

I det følgende kommer en række gode råd til politisk projekt-ledelse. En så kort liste er naturligvis ikke udtømmende. Omvendt er en kort liste lettere at overskue, og den kan derfor inspirere til handling. Måske gør du allerede nogle af de ting nævnt her. Så er du allerede godt på vej!

1. Hold øje med spillet. 2. Undgå at blive en del af spillet. 3. Vær klar til at gå ind i forhandlinger. 4. Vær klar til at gå fra forhandlinger. 5. Dyrk magtfulde relationer. 6. Afhold politiske møder.



Ovenstående lyder sikkert ikke som noget, der kendetegner en projektleder, men det er en del af pointen. Mange projektledere afholder sig fra ovenstående, selv om de burde gå ind i det, når projektet er i domæne 3. I det følgende runder vi de seks råd et ad gangen.

1. Hold øje med spillet

Anerkend, når der er gået politik i den. Hvis man fortsætter, som om der fortsat er konsensus, bliver det for alvor vanskeligt at komme i mål med projektet. Det gode råd er derfor at åbne øjnene og se på interessemodsætningerne, som de virkelig er – ikke som man helst vil have dem.

Vær opmærksom på skjulte dagsordener, og hold øje med skjulte konflikter og magtkampe, der ofte foregår bag lukkede døre. Lær at spille spillet, læs de andre og hold styr på deres interesser og tilbøjeligheder. Hvis du ikke kan se, hvem af de andre, der er den svage part, så er det måske dig selv.

Der findes nok ikke en rigtig indstilling til politiske forhold for projekterne, og der er to grøfter, man kan falde i. Hvis man tror, der ingen politiske aspekter er, er man naiv og bliver let overrumplet, når det rammer projektet. Hvis man ser politiske forhold alle steder, bliver man let betragtet som intrigant.

Dagsordenen er nøglen til processen. Det gælder både den dagsorden, der styrer det enkelte møde, men også den uformelle dagsorden for, hvad der diskuteres i organisationen. Det giver stor indflydelse at kunne sætte dagsordenen – eller i det mindste at kunne påvirke den.

Kapitel 5


Anledninger er en vigtig del af den politiske proces. Politik er jo ikke en logisk styret proces, hvor målene er klare, og midlerne følger de bedste mål. Meget bliver afgjort ved mere eller mindre tilfældige anledninger til at træffe beslutninger. Den årlige budgetrunde er et godt eksempel på en anledning. Det samme gælder de store og små kriser i projektets omgivelser.

I sidste ende bør man huske på, at interessenterne ikke nødvendig-vis skal juble eller kunne lide dig. Når blot de accepterer, hvad der foregår, er det fint nok. Den, der kan opnå interessenternes accept, kan udrette meget.

Mennesker mødes for at informationsudveksle og skabe mening i tingene. Hvis du altid har næsen i sporet, løber efter det næste mål, opnår du naturligvis mange resultater. Men effektivitet har en pris. Du mangler at høre de tilfældige informationer, som har en afgørende indflydelse på dit projekt. Emergens ligger uden for det snævre målfokus.

Politisk arbejde tager tid. Meget tid. Men som de vises ord lyder, så er det bedre at svede i fredstid end at bløde i krig.

2. Undgå at blive en del af spillet

Hvilke interessenter tjener du? Politik er den uformelle måde – mere end den formelle – at få tingene til at ske. Der kan være både konstruktiv og destruktiv politik. Politisk styring opfattes ofte som modsætningen til den rationelle, hierarkiske styring. Politisk projektledelse er en balancegang. Den rette mængde kan være afgørende for succes med projektet.

Hvis din idé er i politisk modvind, kan du vælge imellem tre ting:



• Få selv den magt, idéen kræver, fx et klart mandat fra toppen.

• Find nogen, der har magt nok, og sælg din idé til dem, så den bliver deres.

• Drop idéen for nu, og brug din energi på andre kampe, som du kan vinde.

Sæt dig selv i scene som en apolitisk frispiller med et højere formål. Hold dig fri af særinteresser. Tænk gerne følgende om dig selv: Jeg har kun vores aktionærer på sinde, eller hvis man er offentligt ansat: Jeg tænker mest på borgerne, eller hvis man er mere frelst: Jeg er blot demokratiets ydmyge tjener. Naturligvis skal man også forholde sig til sin linjeleder, projektsponsor, styregruppe og sine kunder, men en for stærk identifikation med deres interesser vil give modstand hos de andre interessenter.

En politisk analyse: Er projektet muligt på nuværende vilkår? Som projektleder lærer man at lave en interessentanalyse og opstille en kommunikationsplan. Men man lærer ikke at stille spørgsmålet: Kan projektet gennemføres med denne interessentsammensætning og på disse vilkår?

3. Vær klar til at gå ind i forhandlinger

Politisk studehandel er et nedsættende begreb, for der er for så vidt ikke noget galt i at handle med interesser. Hvad er det modsatte? At man på basis af sine argumenter overbeviser modparten om, at denne bør opgive sine interesser, uden at der gives noget til gengæld? Dette kræver, at modparten som udgangspunkt har taget fejl, og blot skal gøres opmærksom på

Kapitel 5


dette. Eller at man har så gode retoriske evner, at modstanderen overgiver sig, også selv om denne faktisk har ret.

Hvis man kalder den politiske studehandel en win-win-situation, så er det straks mere attraktivt – selv om det dybest set handler om det samme!

Man undersøger hinandens interesser for at finde en udveksling, der samlet set stiller begge parter bedre, end de var før handlen.

Hvis man som sælger ikke får et nej, så sælger man ikke, man tager kun imod ordre. Hvis man som projektleder ikke forhandler, så leder man ikke, man administrerer kun.

Du kan næppe finde den endegyldige formel på succes, men formlen på fiasko er velkendt: At prøve at tilfredsstille alle.

4. Vær klar til at gå bort fra forhandlinger

Det modsatte gælder også: Lær at sige nej til de aktuelle vilkår. Naturligvis kan man ikke sige nej hele tiden, og man skal have sine begrundelser i orden, når man gør det. Men hvis du aldrig siger nej, får du næppe andre vilkår, end dem du allerede har. Hvis du bare fortsætter projektet, tror de andre jo ikke, at det er nødvendigt at ændre noget. Men at sige nej kræver, at man først indser, at det er muligt at sige fra, sige nej eller sætte projektet på pause, indtil vilkårene muliggør en gennemførelse. Hvornår skal projektet sættes på hold? Indtil parterne er enige?

Som projektleder er dit måske stærkeste politiske våben: At anbefale projektet lukket, hvis ikke vilkårene for gennemførelse bliver væsentligt forbedret. Det giver sig selv, at et sådan våben ikke kan bruges særligt tit, og det kan kun bruges med en solid



argumentation. Men bortset fra det, så er det et meget effektivt greb.

En lidt mildere udgave er at fingere en lille krise for at sætte scenen, skabe opmærksomhed eller få noget til at ske. I den anden ende af skalaen findes et godt råd om ikke at prøve noget som helst, fordi det alligevel ikke nytter noget. Så hellere bruge energi på andre kampe, der er mulige at vinde.

For en person, der gerne vil skabe resultater og komme i mål, kan det være et ret irriterende råd at få, men udfaldet af den politiske analyse kan vise, at det ikke er muligt at forfølge visse mål lige nu, og at det bedre kan svare sig at gemme kræfterne til senere eller til andre kampe, der er mulige at vinde.

Der er sagt og skrevet så meget om indflydelse og gennemslags-kraft, at man kommer til at tro, at alt kan lade sig gøre. Det kan det bare ikke.

Mange projekter er stødt på grund, fordi succeskriterierne ikke passede med de andres KPI’er (Key Performence Indikatorer). Det er sjældent, at vi kender de andre KPI’er, men mon ikke de vil fortælle dem, hvis du spørger i en god mening?

Hvis projektet ikke understøtter interessenternes resultatmål eller KPI’er, så er der meget lang vej til projektsucces!

Du behøver ikke at tage ovenstående som en absolut sandhed eller helt opgive projektet på dette grundlag, men det er værd at over-veje at sende budskabet til de centrale interessenter, der har magt til at ændre på de pågældendes resultatmål/KPI’er.

Kapitel 5


5. Dyrk magtfulde relationer

Det lyder kynisk, men når der er politiske forhold, bliver man nødt til at gøre følgende som projektleder: Identificér, hvem der er de magtfulde personer (og grupperinger) og etabler gode relationer til disse – af hensyn til dit projekt, naturligvis. Det starter med at skabe kontakten, og derefter få noget kvalitetstid sammen. Her må man være kreativ.

Hvis man ikke har den formelle magt eller en overbevisende business case, må man bygge sin magtbase på relationer. Det er vigtigt, at man ikke lader sig begrænse af organisatoriske linjer, men i stedet vælger at være en frispiller, der kommer rundt og snakker med mange interessenter og skaber relationer, der styrker projektet.

Relationerne opbygges ikke for relationernes skyld, men for at give projektet magt og indflydelse. Indflydelsen går begge veje. Den ene er projektets indflydelse på omgivelserne igennem den magtkoalition, det er lykkedes at samle omkring projektets formål. Den anden er den indflydelse, som projektet giver interessenterne på projektets løsning. Relationer kan både være personbårne som i personlige relationer, eller de kan eksistere igennem deltagelse i strukturer som fx høringsgrupper, udvalg, paneler og fokus-grupper.

Hvem taler en politiker med? Svaret er: Alle! Formålet med kom-munikationen er at få informationer, høre andres holdninger, gøre sin indflydelse gældende og naturligvis fiske stemmer. Det er kun det sidste punkt, der ikke er relevant for projektledelse. Vi har tidligere talt om 20% til projektledelse, men det er muligvis ikke nok, hvis der er behov for politisk projektledelse for at opnå resultaterne.



Mange projektledere begrænser desværre sig selv med følgende tanke: Jeg har ikke lov til at snakke på tværs – og slet ikke opad i organisationen! Det er en regel, man selv har fundet på, og som sjældent er begrundet i den virkelige verden. Det er naturligvis ikke alt, man må dele med alle. Desuden skal man respektere styregruppens beslutningsret. Men herudover bør man være fri og huske på, at man er ”CEO for en midlertidig organisation”.

Det er vigtigt ikke at forveksle organisatoriske grænser med kommunikationsgrænser. Hvis man trods dette alligevel gerne vil have en formel tilladelse til at kommunikere frit på tværs af organisatoriske grænser, så kan man bruge dette trick: Skriv ind i kommunikationsplanen, hvem du regner med uformelt at holde kontakt med, og send planen til styregruppen, så den kan blive godkendt.

Få tilladelse til relationsskabelse

Mange projektledere synes, at de kun må række ud til andre, nedad og skråt ud til siden set i forhold til deres organisatoriske placering. Nogle synes, det er ok at vandre frit på eget hierarkiske niveau i organisationen. Kun få synes, det er ok at tage kontakt opad.

Lad os udfordre det med et tankeeksperiment: Antag, at du – fx igennem en sportsklub – har en relation til en højt placeret person, som nu er en central interessent i dit nye projekt. Vil det ikke være nærliggende at få denne interessents syn på dit projekt med på vejen? I langt de fleste tilfælde er svaret ja. Det er helt ok at bruge de mennesker, der tilfældigvis indgår i vores personlige netværk, når bare vi ikke misbruger det. Antag nu den samme situation – blot uden den tilfældige relation fra sportsklubben. Vil det nu

Kapitel 5


være nærliggende at spørge interessenten om dennes syn på dit projekt? Meget ofte vil svaret være nej. Men hvorfor egentlig det?

Hvis interessentens synspunkt er relevant, så er det relevant, uanset om du har en tilfældig relation til personen eller ej. Det kunne jo også være, at projektet netop var anledningen til at opbygge en relation – så behøver man ikke sportsklubben.

Ovenstående tankeeksperiment er med for at vise, hvordan vores forlegenhed (eller hvad det nu er) kan stå i vejen for at opsøge informationer, som vores projekt kan have fordele af at få. Her må vi nok arbejde på at træde ud over vores egen emotionelle komfortzone til gavn for projektet. På en måde er det helt forståeligt, at vi frygter det. Vi har alle prøvet – eller kender nogen, der er kommet til – ”at gå bag ryggen på bossen”, hvilket fik alvorlige konsekvenser – også selv om intentionerne var uselviske.

Organisationsdiagrammets linje bliver nogle gange en barriere for kommunikation, et mentalt fængsel, som det ikke bør være.

En måde at løse problemet på er at lave en kommunikationsplan, hvor en række centrale interessenter er nævnt, og hvor informationskanalen er skabelse af uformel kontakt til dem.

Det tager lang tid at netværke – husk at booke tid i din kalender!

6. Afhold politiske møder om projektet

Den sjette anbefaling er: Hold politiske møder – Men kald dem endelig noget andet end dét. De fleste projektledere er vant til at holde møder om indholdssiden. Det er jo det, der driver arbejdet



fremad mod den aftalte leverance. Men møder er ikke kun arbejdsmøder.

Med politiske møder menes i denne sammenhæng møder, der ikke handler om indholdet som sådan, men om at skabe enighed. Nuvel, nogle gange må man justere indhold for at opnå enighed, men fokus på møderne ligger på at skabe enighed – og indholdet er kun sekundært.

Politiske møder handler ikke om at lave rævekager, men derimod om at samle folk, så deres enighed eller mangel på samme kan blive tydelig for alle. På mødet skal man være særlig opmærksom på konsensus-sproget, der består af tvetydigheder, der blot skjuler uenighed.

Hvis du opdager uenighed, så gå i gang med planlægning af en proces, der kan skabe mere enighed. Timing er også vigtig. Det er ikke sikkert, at konfrontationen af uenighederne skal tages med det samme.

Skab enighed om uenigheden

Hvis der er bred enighed om, at projektet er ramt af stor uenighed, så er det lettere for projektledere, end hvis uenigheden er skjult.

Hvis der er enighed om, at der er uenighed, er der forståelse for, at projektet skal have tid og ressourcer til afholdelse af møder, work-shops eller seminarer for at drøfte synspunkter og imødekomme de forskellige interesser. Interesseorganisationer, foreninger, politiske partier, NGO’er og tilsvarende organisationer er vant til sådanne projekter. Men det er samme vilkår, der møder strategi-ske projekter, hvor man ønsker et bredt fundament for

Kapitel 5


beslutningen eller implementeringsprojekter, hvor der er mange forskellige hensyn og interesser at imødekomme.

Projektlederens rolle bliver facilitator eller mediator (forskellen på disse to funktioner er primært, om der allerede er opstået en konflikt, som skal medieres, eller om det er beslutningsprocessen, der skal faciliteres).

I det følgende ser vi på to slags møder. Det første kan vi kalde ”mødet med de to stærke og meget uenige”. Det andet kan vi kalde ”mødet med interessenter med forskellige interesser”. Det er to meget forskellige møder, som vi her ser på en ad gangen.

Mødet med de to stærke og meget uenige

I komplekse projekter er det meget almindeligt, at man har enkelte centrale stærke interessenter, der ikke vil det samme. Det kan godt være, at alle vil være indstillet på, at projektet skal gennemføres, og derfor er alle meget positive. De er bare ikke enige om, hvad der skal ske, og hvordan det skal gøres. Desværre taler de ikke sammen, og derfor kommer man som projektleder til at løbe spidsrod imellem dem – uden anerkendelse af, at man er sat på en umulig opgave.

På grund af disse interessenters styrke er der som regel kun én mulighed: Få dem samlet, så de ved selvsyn kan opleve, hvor uenige de er. Det kan være svært at få et sådant møde indpasset i projektets tidsplan, for denne slags interessenter har ofte en stram kalender.

Det kan være fristende at køre projektet videre i henhold til planen og håbe på det bedste. Hvis du vælger denne løsning, er det måske her, man med rette kan tale om naivitet. I stedet er det projektets



tidsplan, der skal ændres, så den kan tage højde for den politiske realitet.

Når du så har de få stærke interessenter samlet i et rum, står du med den næste store risiko: Det er meget sandsynligt, at de taler i så generelle vendinger, at det ligner enighed. Det er eksempelvis meget nemt at blive enige om, at ”kunden skal i centrum”, og at dette skal ske ”snarest muligt”. Dette er desværre så tvetydigt, at du ikke står bedre.

Mødet med interessenter med forskellige interesser

Hvis flere interessenter er uenige, er der brug for at arbejde med tvungen accept. Der er situationer, hvor der er anvendt for bred en debat. Målet er at gøre en gruppe mennesker mere enige, end de var før. Hvis det kun er en håndfuld, det drejer sig om, kan man samle dem til et møde, hvor personerne har tid og mulighed for at tale en konsensus frem. Hvis det derimod er 25 personer, der er tale om, skal der en anden struktur til.

Her er en mulig fremgangsmåde, som kan få 25 personer til at drøfte et kompliceret emne på en eftermiddag:

Kapitel 5


Det er vigtigt for processen, at formålet er gjort helt tydeligt for deltagerne. Er det for at give dem mulighed for vidensdeling om emnet? Er det for at indsamle input til forståelse af behovet? Er det for at skabe konsensus? Er det for at komme med kreative løsninger på komplekse problemer?

Arrangér fem borde hver med fem deltagere. Hold et oplæg om emnet, der lægger op til en drøftelse af fem spørgsmål. Det er vigtigt, at de fem spørgsmål er konkrete hver for sig, men tilsammen omfatter det komplekse emne.

En person ved bordet bliver referent på hvert af spørgsmålene, så alle får til opgave at samle de fire andres holdning. Der kan for eksempel være fem minutter til drøftelse af hvert spørgsmål. Projektlederen markerer tiden, for eksempel med en fælles klokke.

Når første runde er gennemført, er der en pause, hvor man placerer sig ved et nyt bord. På denne måde bærer man holdninger fra første bord videre til det nye bord. Det er lidt af en kabale, der i sig selv er kompleks, hvis man lader det være op til deltagerne selv at få det til at gå op. Det anbefales, at der laves en køreplan,



så alle kan se, hvor de skal gå hen, afhængigt af hvilket bord-/referat de havde. Men selv med en køreplan kan der opstå kaos, men det går.

På det nye bord skal deltagerne vælge at blive referent på et andet spørgsmål end det, de havde tidligere – i den udstrækning det er muligt. Herefter kører runde to som runde et. Der er kun den forskel, at man på det nye bord begynder drøftelsen af hvert spørgsmål med referatet fra forrige runde. Runde tre er herefter en kopi af runde to, blot med nye borde og nye spørgsmål for den enkelte at være referent på.

Ved runde tre begynder engagementet i drøftelserne at tage af, og man kan overveje at stoppe her. Hvis man kører fire eller fem runder, begynder der desuden at være deltagere, som skal til at være referent på et tidligere emne.

Et sådant debatforløb kan gennemføres på 3-4 timer, afhængigt af antal runder, drøftelsestid per spørgsmål og pausetid indimellem. Den samlede investering er derfor omkring 100 mandetimer. Udbyttet i form af en højere grad af konsensus om emnet er ofte stort – og helt sikkert effektivt i forhold til tidsforbruget.

En måde at afrunde debatprocessen er at bede deltagere fortsætte drøftelserne på uformelt plan. Hvis man har brug for, at der bliver arbejdet videre på en formaliseret måde med drøftelserne, kan man tilføje hæfter til referentens arbejde. Man tager 25 hæfter og skriver et af spørgsmålene på forsiden, så hvert spørgsmål står på 5 hæfter. Referenterne skal skrive deres noter i hæftet. For hver ny runde gives hæftet videre til den næste referent ved det nye bord. Efterfølgende kan man samle og konsolidere noterne til hvert spørgsmål.

Kapitel 5


Det er vigtigt, at det er tydeligt for deltagerne, hvad næste skridt er. Om de bliver inddraget igen, og hvis de gør, er det vigtigt for dem at vide hvordan og hvornår. Hvis deltagerne ikke inddrages igen, er det vigtigt, at deltagerne ved, hvordan resultaterne fra dagen vil indgå i det kommende forløb i projektet. Man skal huske på, at debatmøder som disse har en forventningsdannende effekt. Derfor skal den efterfølgende forventningsafstemning være planlagt.

Denne proces er blot en blandt flere mulige. Det er ikke sikkert, at præcis denne form passer til den politiske proces, du står overfor. Men nu har du i hvert fald fået inspiration til, hvordan man på kort tid effektivt kan håndtere en drøftelse blandt mange mennesker.

De andre ser verden anderledes end dig Nogle opdager tidligt – andre først senere i livet – at alle mennesker ser verden helt forskelligt.

Af denne grund er mennesker det mest komplekse element i ethvert projekt. Ting, teknik og IT kan være kompliceret, men der skal mennesker til at gøre det komplekst.

Måske er det den rationelle tilgang, der er dybt forankret i vores moderne kultur, som kan gøre os blinde over for det faktum, at den enes kort over virkeligheden er meget forskelligt fra den andens kort.

Man kan eksempelvis opdage forskelligheden, hvis man får lejlighed til at sammenligne to menneskers opfattelse af et møde, som de begge lige har været til. Hvad blev der sagt og diskuteret, og hvad blev der besluttet? Ja, for ikke at nævne, hvad var



egentlig formålet med mødet? Ofte er svarene så forskellige, at man må spørge: Var det overhovedet det samme møde, som de to personer var til?

Hvis man selv var den ene af de to mødedeltagere, ville man måske komme til at tænke, at den anden havde skumle hensigter med at fordreje mødets indhold på dén måde. I virkeligheden har begge lige fordrejede opfattelser, men opfattelserne er blot drejet i hver sin retning. Et møde er blot et eksempel på de grundlæg-gende forskellige opfattelser, der kommer til udryk i alle menneskelige forhold, herunder også de projekter, vi laver.

Mennesker har forskellige opfattelser af verden, forskellige idéer om, hvad der er rigtigt og forkert, forskellige værdier og over-bevisninger. Det er derfor ikke overraskende, at vi har meget forskellige mål og derfor nemt bliver uenige.

Hver interessent kan være fuldstændig rationel set ud fra sine egne mål. Da målene hos interessenterne er forskellige, kan helheden komme til at fremstå irrationel eller tvetydig. Tvetydighed er et af parametrene i projektkompleksitet, som det fremgik tidligere. Tvetydigheden har især grobund, hvis kulturen er baseret på konsensus, hvilket den typisk er i den skandinaviske model. Konsensuskultur skaber tvetydige mål, fordi der i denne kultur er færre, som siger nej.

Hvis du var dén person, som du opfatter som en modstander, hvordan ville du så tænke om dit projekt?

Inden vi farer ud med bål og brand for at komme af med vores såkaldte politiske modstandere, kan vi stille et par afklarende spørgsmål til os selv:

Kapitel 5


• Vil du investere i noget, hvor du ikke kan forvente et klart afkast inden for en overskuelig fremtid?

• Vil du afgive ressourcer til andre, hvis du selv har brug for dem til vigtige formål?

• Vil du anbefale et projekt, som du ikke tror kan lykkes? • Vil du godkende et projekt, som kan gennemføres på en

bedre måde? • Vil du lade et mindre betydningsfuldt projekt komme

foran et med større betydning? • Vil du bruge virksomhedens frie midler på noget, du

opfatter som gambling? • Vil du gå i gang med aktiviteter, der ikke tjener et klart

formål for din afdeling, dit team eller dig selv? • Vil du engagere dig i noget, du ikke rigtigt forstår eller kan

se meningen med?

Du har formodentlig sagt nej til hovedparten af disse spørgsmål. Det vil de fleste fornuftige personer gøre. Herefter kan vi vende den rundt og se på, når vi er irriterede over projektets såkaldte modstandere. Vi glemmer ofte, at de som regel er ganske fornuftige personer, der blot har svaret ”nej” til et eller flere af ovenstående spørgsmål.

Hvis man laver et system med rationelle (eller i det mindste fornuftige) beslutningstagere og giver dem forskellig information og baggrundsviden, vil systemet fremstå som irrationelt.

Politik er ofte blot konfliktende perspektiver og prioriteringer. Hvis alle havde samme opfattelse af virkeligheden, det samme mentale landkort over verden, så var der formentlig ingen meningsforskelle.



Endnu en gang kan dette klassiske billede med elefanten og de fem blinde mænd komme til gavn for forståelsen.

Ingen ser projektet, som det er. Du ser derimod, hvad det betyder for dig. Du ser projektet gennem en linse, som er formet af din jobfunktion. Dette vilkår gælder for alle.

I forhandling og konflikter er det en afgørende fordel at kunne se verden gennem de andres briller. Du behøver ikke give dem ret eller give afkald på dine egne interesser, men du er bedre stillet.

Kapitel 5


Visdom er at forstå en indstilling, der ikke kunne være ens egen. Piet Hein

Husk også det gamle mundheld: Før du kritiserer nogen, bør du gå en mil i personens sko.

Der er også den fordel, at når kritikken kommer, er du så langt væk, at personen ikke kan høre dig. Desuden er personen sikkert også travlt optaget af at lede efter sine sko.

Og lad os ikke glemme, at det værste ved en konflikt er, at modparten muligvis har ret.

Simpel datafangst – spørgeteknik

Det er ikke nødvendigvis særligt vanskeligt at afdække, hvad interessenterne tænker inderst inde. Ofte skal man bare spørge dem: ”Hej, jeg er i gang med [projektnavn], og det er vigtigt at høre, hvad du tænker om dette projekt” (Hvorfor det er vigtigt, kommer du sjældent til at uddybe, for alle synes, at deres tanker om alt muligt er vigtigt).

• Hvorfor synes du, dette projekt er vigtigt? • Hvilke faldgruber ser du, at projektet har? • Hvilke fordele kan du se, projektet har for dig/jer? • Hvilke ulemper forventer du, det giver dig/jer?

Husk at holde ørerne åbne, og sæt god tid af i din kalender. Væn dig til at stille et spørgsmål, og hold så din mund lukket!

En lille udfordring: Hvordan ved du egentlig, at det er dine politiske modstandere, der tager fejl? Det kunne jo være dig/jer.

Hvad ville du gøre, hvis det nu var dig, der tog fejl? Hvis nu det viste sig, at den meget aktive modstand eller den passive



ignorering af projektet skyldtes, at de andre havde ret. Måske er det jer, der holder liv i et zombieprojekt? Eller skubber organisationen ud over kanten?

Hvis det giver et lille gib i dig, er det måske meget godt at lave følgende øvelse: Tag et stykke papir, og lav to kolonner med følgende overskrifter. Den venstre er sikkert nem at udfylde, men hvad med den højre?

Projektet / projektledelsen har mest ret, fordi:

Modstanderne af projektet har mest ret, fordi:

Hvis der ikke står en særligt intelligent og indsigtsfuld under overskriften i højre kolonne, så er du enten i en organisation af tåber, eller også har du ikke gjort dit arbejde med datafangst godt nok.

Zombieprojekter kan være et resultat af uenighed. Man kan ikke blive enige om at give projektet de nødvendige ressourcer til at blive færdig – omvendt kan man heller ikke blive enige om at lade projektet dø. Resultatet bliver en række levende døde projekter, der vandrer omkring i organisationen og stjæler ressourcer, der kunne bruges til noget mere produktivt. Nogle gange er zombie-projekterne kun holdt i live af en enkelt vedholdende person. Holder du zombieprojekter i gang?

Kapitel 5


Tvetydige mål gør det vanskelige endnu sværere

I projekter ser man desværre alt for ofte, at uenigheden om, hvad vi skal, fører til tvetydige målformuleringer. Dette er særligt slemt i konsensuskulturer, hvor man prøver at tale sig frem til en enighed om alting. På den korte bane er det smart med tvetydige mål, for så er der ingen, som vil slagte projektet, før det er kommet i gang. Men det giver også projektledelsen en skjult konflikt, som senere skal håndteres. Skjulte konflikter har en slem tendens til at åbenbare sig på det mindst belejlige tidspunkt.

Andre gange ved vi godt, at målformuleringen er tvetydig, men man kommer til at vende det blinde øje til, fordi ”the show must go on”. Projektet skal jo gennemføres, og hvis vi tager konflikten op, stopper det jo projektet. Dette er vist en almen menneskelig reaktion: Den er i hvert fald ofte set. Vi kan være så fokuserede på oplevelsen af og behovet for kontrol, at vi vender det blinde øje til politiske forhold, men spørgsmålet er blot, hvordan det går med projektet, hvis vi ikke adresserer konflikten?

I divergente domæner opstår der også let paradokser. En ofte set kombination er denne: Nogle vil have A, andre vil have B, men ingen vil have C. For at undgå konflikter vælger vi C. Måske et udslag af et samfund, hvor en vigtig kulturbærer er, at vi alle er lige. Det havde nok været bedre, hvis vi kunne arbejde løsningsorienteret med uenigheden. Det kræver, at nogen kan og vil tage fat om situationen, selv om der er risiko for, at vi ikke altid alle sammen får lige meget hele tiden.

Tvetydige begreber skaber komplekse projekter

Begrebet ”implementering” er et eksempel på et flertydigt ord, som vi ofte bruger og tror, de andre ved, hvad vi mener.



Mange er tilbøjelige til at tænke, at det jo er klart nok, men hvad betyder implementering egentlig? Hvornår er noget implementeret? En IT-udvikler synes måske, at implementeringen betyder, at systemets database snurrer, og programmet kan afvikles, men en IT-supporter mener nok, at det først er implementeret, når alle arbejdsstationer er testet. En HR-konsulent kan mene, at implementering også bør omfatte undervisning af brugerne, så de er i stand til at bruge systemet. En afdelingsleder mener sikkert, at implementering må omfatte forandringshåndtering, så brugerne rent faktisk er kommet i gang med regelmæssig brug af systemet. Alle har ret ud fra deres perspektiv på et IT-system.

Begrebet implementering er meget flertydigt, ligesom så mange andre af de begreber, vi bruger til daglig med den selvfølgelighed, at andre tænker præcist det samme som os … hvilket de sjældent gør.

Kapitel 5


Begrebet ”implementering” er blot et blandt mange tvetydige ord, der skaber divergens. Andre eksempler er: agilitet, topstyring, kundecentrering, commitment og opbakning.

Det er svært at kommunikere, når folk forstår noget forskelligt ved de ord, de siger. Nobelprismodtageren George Bernard Shaw sagde det ret præcist: “Det største problem med kommunikation er illusionen om, at den har fundet sted.”

Det er sjældent nok at kommunikere, ofte bør vi gentage os selv på flere måder, og kontrollere, at kommunikationen har haft den ønskede effekt. Og vi bør gentage og kontrollere dette langt oftere, end det forekommer os naturligt. Hmmm, måske jeg også lige skulle sige dette en gang til blot på en anden måde …



Opsamling: Det divergente domæne Uenigheden i et projekt består i, at interessenterne går i forskellige retninger. Der kan både være enighed inden for og uden for projektets afgrænsning. Uenigheden kan både være som en åbenlys konflikt, og den kan være skjult og ubemærket. Nogle gange kan den skjule sig i tvetydige målformuleringer, hvilket særlig ses i en ”konsensuskultur”.

For at håndtere denne divergens bliver man nødt til at bedrive politisk projektledelse – selv om ordet måske har en uheldig klang.

Kapitlet peger på seks anbefalinger, som man kan overveje, hvis projektet befinder sig helt eller delvist i det divergente domæne.

1. Hold øje med spillet. 2. Undgå at blive en del af spillet. 3. Vær klar til at gå ind i forhandlinger. 4. Vær klar til at gå fra forhandlinger. 5. Dyrk magtfulde relationer. 6. Afhold politiske møder.

Det måske mest afgørende er at sætte sig for, og afsætte tid til, at forstå de andre, og hvordan deres verdensbillede hænger sammen. Måske er der mere logik i modstandernes synspunkt, end man som udgangspunkt antog.

Frem for alt er det vigtigt at blive dygtig til kommunikation. Ikke kun for at undgå konflikter og blive bedre til at samarbejde, men også for at opdage de mange steder, hvor vi taler fundamentalt forbi hinanden. Som det er fremhævet i kapitlet, så er der mange mulige forståelser af ordet implementering.

Kapitel 6


Kapitel 6

Det kaotiske domæne – uenighed og uvished

Det store IT-projekt kører fint. Kunderne var glade for systemet, og stadig flere kom til. En morgen kom direktøren forbi, roste projektet, og sagde, at systemet var blevet solgt til en stor IT-koncern. Med et slag var projektet ændret fra kompliceret til kompleks, ja til tider nærmest kaotisk, skulle det vise sig.

Når man som projekt bliver købt ud af sin hjemstavn og placeret ind i en helt ny organisation, så er der pludselig mange nye ting at forholde sig til. Flytning til andre lokaler, en ny infrastruktur, systemerne skulle migreres til andre servere og meget andet. Nye chefer og andre kollegaer. Det var uklart, hvem der skulle eller måtte beslutte hvad, og der var desuden et hav af anderledes regler, procedurer og forretningsgange at forholde os til.

Det blev en svær tid. De klynkede og klagede. De brokkede sig højlydt, men intet syntes at hjælpe. Som hos mange andre grupper under pres udviklede de paranoia over for omgivelserne, og var hele tiden var på vagt overfor ”dem”, og hvad ”de” nu kunne finde på. Der udviklede sig en udpræget ”dem/os-tænkning”, som var tydeligt i sproget. Skal de nu komme her og blande sig i vores planer, og skal vi nu til at bruge deres produkter og metoder?

Mange møder blev brugt til at drøfte problemerne, der var kommet i kølvandet på at blive opkøbt. Det siges, at en god målestok for kaos er, hvis den producerede værdi er nul, selvom alle knokler løs. Med denne målestok havde de ret meget kaos i projektet. Alt i alt følte de sig mere solgt, end købt

Det kaotiske domæne


Da skete det heldigvis, at en tilfældig bemærkning medførte en åbenbaring. Efter overførslen var der kommet nye personer ind i gruppen, og det er som bekendt fra de nye, at man skal høre sandheden. På et af de sædvanlige møder, hvor alle de uløselige problemer var på bordet - igen - spurgte den ene af de nye forsigtigt: ”Nu tilkommer det jo ikke mig at spørge sådan, men tror I, at handlen kan gå tilbage, at købet kan gøres om?”

Med ét slog det projektlederen, at de havde taget fejl!

De troede, at alt det, de ikke brød sig om, var problemer, der skulle løses. Det var det ikke! Det var blot nye vilkår, som de skulle lære at leve med.

Ud over, at de havde taget fejl af vilkår og problemer, så havde de også bevæget sig fra noget kompliceret til en kompleks situation uden at bemærke det. Det var først, da nogen pegede det ud for dem, at de indså, at man ikke kan eksekvere gamle planer i nye ukendte vilkår. Set i bagklogskabens iskolde lys lyder det næsten naivt, men det er måske meget menneskeligt at være så optaget af at håndtere det komplicerede, at man ikke opdager, at det i mellemtiden er blevet komplekst. Hvis man ikke tager hånd om det komplekse, bliver alt nemt kaotisk.

Kapitel 6


Med både uvished og divergens er vi havnet i det kaotiske domæne. Ikke alene ser vi noget ukendt i horisonten, men vi er også uenige om, hvordan vi skal fortolke det, vi ser, og hvad vi bør gøre ved det.

Sagt med andre ord: Nogle vil til A, andre vil til B, men ikke nok med det: Ingen ved faktisk med sikkerhed, hvordan man kommer til A eller B. Forvirringen i det kaotiske domæne kan nå endnu større højder end dem, der er i det uvisse og divergente domæne tilsammen.

Billedligt talt er vi i en situation, hvor isen er usikker, men vi er uenige om, hvorvidt det nu også passer. Nogle mener, at isen er tynd, mens andre mener, at isen er tyk nok og derfor insisterer på,



at projektet gennemføres med raske skridt hen over isen – uden tøven eller tidskrævende sikkerhedsforanstaltninger.

Hvad er kaos og kaotisk? En målestok for kaos kan være, at den producerede værdi nærmer sig nul, selvom alle knokler løs, fordi der er travlt. En anden kan være, at folk er meget uenige, og ingen har overblik eller ide om, hvordan vi kommer videre herfra. Nogle mener, at kaos er et nødvendigt element i nytænkning, mens andre ser det som en mørk og destruktiv kraft. Der er mange meninger om sagen.

Der er også en gradbøjning at tage stilling til. Kaos og kaotisk er ikke det samme. Ordene bruges i denne bog således, at kaotisk henviser til en situation, der kan gå over, mens kaos er en mere permanent tilstand. Som Remingtons skala (vist i bogens indledning) antyder, så er der ingen vej tilbage fra kaos. Hvis kaos indtræder, må man lukke projektet og eventuelt starte et nyt.

Når situationen er kaotisk, er vi på kanten af kaos, og man må gøre noget for ikke at ryge ned i afgrunden af kaos. Når projektet står på kanten, bliver man nødt til at droppe aktuelle planer, og i stedet gå tilbage til en kort tidshorisont og arbejde med det basale for at genvinde kontrollen.

I projektkompleksitetsvinduet er det, når der både er meget divergens og stor uvished, at situation er kaotisk.

Der kan være individuelle forskelle på, om man opfatter situationen kaotisk. Hvad der er kaotisk for den ene, er det måske ikke for den anden. Tilsvarende kan en tilskuer opfatte et møde som kaotisk, mens deltagerne oplever det som en kontrolleret proces – det omvendte er også muligt.

Kapitel 6


I det følgende bruges følgende definition: Situationen er kaotisk, når der mangler en fælles ramme for dét, der aktuelt foregår.

Dette kapitel vil handle om denne ramme, og hvordan projektlederen kan skabe og vedligeholde den i og omkring projektet.

Ingen værktøjer i kassen

Hvis man leder i projektlederens sædvanligvis værdifulde værktøjskasse, så finder man ikke rigtigt noget til at håndtere situationen med. Derfor må vi hente inspiration andre steder. Harald Enderud har skrevet bogen Beslutninger i organisationer, der er blevet lidt af en klassiker. Enderud peger på tre typer beslutningsmodeller:

• Den rationelle • Den politiske • Den anarkistiske model

I vores terminologi tilhører den rationelle beslutningsmodel det sikre domæne (og til dels også i det uvisse domæne, hvis man betragter en iterativ proces som en rationel beslutningsmodel). Den politiske model hører til i det divergente domæne, og den anarkistiske model er i det kaotiske domæne. Den af Enderuds anarkistiske modeller, som især byder sig til, er Garbage Can-modellen. Den bruger vi som indledning til det følgende.

Garbage Can-modellen beskriver organisationen (i vores sammenhæng projektorganisationen) som en beslutningsarena, hvor der kommer anledninger strømmende igennem. Anledningerne kan være alt lige fra møder til kriser og budgetlægning. Anledningerne er som en skraldespand, hvor



aktørerne forsøger at kombinere problemer og løsninger. Når problemløsningen er i spanden, handler det om at få den ud til eksekvering, inden andre tager den op igen. Nogle gange lykkes det, andre gange kommer spanden tom ud af arenaen.

Det er en meget enkel, men også slagkraftig metafor med spande, aktører, problemer og løsninger. Når man tager disse briller på, og betragter de processer, der foregår på møder, bliver spillet meget tydeligt. En anledning er den udløsende faktor. Uden anledningen ville problem og løsning ikke kunne bringes sammen.

Modellen har en politisk vinkel, idet aktørerne har forskellig magt over spandene og i forhold til hinanden. Det er også forskelligt, hvem der har mulighed for at deltage ved hvilke anledninger. Med andre ord: Der er meget divergens omkring spandene, alle aktørerne vil noget forskelligt.

Modellen afspejler også den uforudsigelige side, idet der er emergens i forhold til, hvilke spande der ankommer. Desuden er det uforudsigeligt, hvordan problemer og løsninger fungerer sammen, og det ved vi faktisk først, når den efterfølgende eksekvering er overstået, og effekten kendes.

Metaforen er super som deskriptiv model, det vil sige, at den er god til at beskrive virkeligheden, men desværre er den ikke så god til at give normative anbefalinger ud fra. Derfor suppleres Garbage Can-modellen i det følgende med et meget enkelt praktisk orienteret værktøj, der kan bruges, når man oplever kaotiske forhold, og hvor det er anledningerne, der styrer projektet – og ikke omvendt.

Modellen vi herefter ser på, handler om at sætte en fælles ramme for det, der foregår, således at vi får styr på det kaotiske.

Kapitel 6


Det uundværlige rammesætningsværktøj Lad os starte med det helt fundamentale: Det modsatte af kaos er kontrol. Uanset, hvor meget kaos du oplever, vil der altid være noget, som du har kontrol over.

Lad os begynde med dét startsted, ”cirkle” det ind og kalde det kontrolcirklen.

Begrebet kontrolcirkel er hentet fra Steve Covey (ham med bogen Syv gode vaner hos højeffektive mennesker). Covey taler også om en indflydelsescirkel, der ligger uden for kontrolcirklen. Med de to cirkler er verden inddelt i tre zoner: Dét, vi har kontrol over, og dét, vi har indflydelse på, samt dét, der er helt uden for vores indflydelse. Indflydelsescirklen er herunder tegnet som en firkant, fordi det derved passer med ordet Rammesætning. Mere herom senere.

Den enkelte person har kontrol over, hvad man siger og gør, samt hvad man bruger sin tid og sine penge til.

For et team vil dét, man har kontrol over, være de tildelte ressourcer i form af arbejdstimer og økonomi.

Hvad er et problem … egentlig?

Det næste, vi skal have på plads, er begrebet ”problem”. Vi kan også kalde det en ”udfordring”, for problem og udfordring er i



virkeligheden to sider af samme mønt, men sidstnævnte lyder blot mere positivt. I andre sammenhænge er begrebet ”issue” mere passende at bruge.

Lad os lige stoppe op et øjeblik og reflektere over essensen i et problem – eller mere præcist: Hvad er det gode ved et problem?

Det gode ved et problem er, at det kan løses!

Hvis noget ikke kan løses, så er det ikke et problem, men et vilkår. Et vilkår er noget, man må leve med – i modsætning til et problem, hvor man per definition kan finde en løsning.

Man har indflydelse på sine problemer, og derfor hører de til inden for firkanten. Omvendt er problemer placeret uden for cirklen af den simple grund, at problemer, man har kontrol over, normalt kaldes opgaver. Derfor er et problem, som vi har kontrol over, ikke længere et problem, men en opgave.

Som opsamling er der tre niveauer: vilkår, problemer og opgaver. Opgaverne er noget, vi har kontrol over, mens problemer er noget, vi har indflydelse på.

Ovenstående indsigt kendes også i et citat: Giv mig styrke til at kæmpe med det, der kan ændres. Giv mig sindsro til at acceptere, hvad der ikke kan ændres. Og giv mig visdom til at kende forskel.

Det vides ikke med sikkerhed, om citatet skal tilskrives Frans af Assisi (1182-1226), men inspirationen er god alligevel, og vi kan tegne en ramme som vist i figuren. En ramme, der adskiller problemer fra vilkår, fordi det er to helt forskellige ting, man har brug for at kende forskel. Opgaverne er placeret i kontrolcirklen.

Kapitel 6


I dag – snart 800 år efter, at Frans af Assisi (muligvis) skrev de vise ord – er der ikke så meget, mennesker ikke KAN ændre. Når man ser nærmere efter, kan stort set alt ændres – enten af individer eller af flere samlet folk. Derimod bliver spørgsmålet, om vi VIL ændre det.

Med en verden fuld af projekter må det konstateres, at vi kan, hvad vi vil, hvis blot vi kan finde finansieringen dertil. Derfor er rammen lig en social konstruktion, der består af vores mere eller mindre ubevidste beslutninger, vaner, kultur, aftaler og/eller forventninger. Man kan også sige, at rammen er politisk fastlagt.



Her er der nogen, som reagerer med spørgsmålet: Skal jeg udfordre projektets rammer – Er det virkelig min rolle som projektleder? Svaret er: Ja, nogle gange – men vælg dine kampe med omhu!

Det er også her man må tage stilling til om man vil udøve ledelse af projekter – eller projektledelse. Det er ikke et spørgsmål om leg med ord, for bag det valgte ligger en forskel i attitude. Som projektleder er man mere leder i projektet en leder af projektet.

Rammesætning til håndtering af det kaotiske

Rammen kan både ses som projektets scope, som afgrænsningen på et møde eller på den situation, som vi aktuelt betragter. Hverken scopet, mødeindholdet eller situationsafgræsning er naturbestemt, men er derimod resultatet af en mere eller mindre bevidst beslutning, truffet af dig og dem, du er sammen med.

På kanten af kaos er deltagerne i vildrede, der mangler enighed, og ingen er rigtig klar på, hvor dette fører os hen. Det er derfor, vi klassificerer situationen til at være i det kaotiske domæne. Tankerne er uklare, og diskussionerne vælter frem og tilbage. Det, der er brug for, er en grundlæggende sikker struktur, der gør, at vi kan håndtere emnerne, efterhånden som vi tænker på dem og bringer dem op i diskussionen.

Det moderne menneske med alle vores (nærmest uudtømmelige) ressourcer kan derfor stille følgende spørgsmål til alt, hvad det møder på sin vej:

Prioriterer vi dette emne, som et problem, vi vil prøve at løse, eller skal vi acceptere dette som et vilkår?

Kapitel 6


Der er to facetter af dette spørgsmål, både divergens og uvished. Det er derfor, rammesætningsmodellen er meget brugbar i dette domæne, hvor vi er på kanten af kaos.

Rammesætningsmodellen håndterer divergens to steder. For det første den manglende enighed om, hvorvidt noget er et problem eller et vilkår. For det andet kan der være uenighed om, hvilke opgave vi skal tage på os.

Uvisheden handler om, at vi ikke med sikkerhed kan vide, at den opgave, vi vælger, rent faktisk løser det problem, som vi er enige om at løse.

Håndtering af divergens og uvished omkring rammesætningen er emnet i det følgende.

Dynamikken i rammesætningsmodellen

Dynamikken i modellen er, at når der er en anledning, kan en aktør tage et problem op. Anledningerne i et projekt består oftest af arbejdsmøder, styregruppemøder, kundemøder eller andre møder imellem interessenter.

Modellen har to afgørende spørgsmål til håndtering af det problem, der er taget op:

1. Er dette et problem, der skal løses – eller skal det betragtes som et vilkår for projektet?

2. Hvis problemet skal løses, hvilken opgave kan og vil vi tage på os, som måske løser dette problem?

Hvis vi ikke vil tage en opgave på os, så bliver problemet parkeret sammen med vores andre vilkår – uden for rammen.



Lad os se nærmere på de to ovennævnte spørgsmål hver for sig.

1. Er problemet blot et vilkår?

Det første spørgsmål, vi bør stille er: Er dette et ægte problem? Kan vi løse det med de ressourcer, vi har til rådighed? Hvis svaret er ”nej”, så havner det uden for rammen. Problemet er med andre ord om-defineret til at være et vilkår, noget, der ikke kunne løses.

Det samme gælder, hvis vi faktisk godt kunne, men ikke vil løse problemet, måske fordi vi sparer vores kræfter til andre ting. Så er det også uden for rammen. Her kan man tale om, at problemet er parkeret som et vilkår for nærværende. Senere kan vi overveje at problematisere det igen, hvis vi har fået tid, lyst og overskud til at se nærmere på, hvordan problemet nu kan løses.

Kapitel 6


Der kan være tale om korttidsparkering, langtidsparkering eller en permanent placering med sætningen: Når vores projekt ikke kan, så er der måske andre, der tager sig af det – og hvis ikke, så var det nok lige meget!

Parkeringspladsen er et fint middel til at opnå accept af, at det ikke er et problem, vi skal se på nu. Accepten kan blive understøttet med, at punktet skrives ned – eller op på tavlen. Om der så er tale om korttids- eller langtidsparkering, kan man tage stilling til senere.

2. Hvad er problemets opgave?

Hvis vi vælger at løse problemet i vores aktuelle projekt, så handler det om at finde ud af, hvilke opgaver i problemstillingen vi vælger at udføre. Dette er i alt sin enkelthed grundstrukturen i problemløsning. Når opgaven er defineret, kan der eventuelt være noget tilbage af problemstillingen, der ryger ud som et nyt vilkår. Det nye vilkår kan så få samme tur, hvis nogen tager det nye vilkår op som et problem, de gerne vil løse.

Når opgaven er udført, ved vi, om løsningen løste problemet, eller om der er brug for yderligere iterationer med nye opgaver, vi påtager os.

Mental energibesparelse

Rammesætningsmodellen er i al sin enkelthed en meget praktisk model. Gevinsten ved at bruge den konsekvent er, at vi ikke spilder tid og tanker på det, vi vælger skal være vores vilkår. Derimod kan vi bruge al energi på at fokusere på at løse det, vi sætter os for at gøre noget ved.



Hvis et emne er uden for vores indflydelse, er det helt klart et vilkår. Vi kan konstatere, at vilkåret findes, men vi bør holde op med at diskutere det, for det fører ingen vegne hen. Hvis emnet derimod er inden for vores indflydelse, så skal vi træffe en beslutning. Vil vi prioritere at løse problemet, eller vil vi behandle det som et vilkår – og leve med, at det ikke bliver løst (ikke af os i hvert fald)? Det er her, rammesætningsværktøjet bliver et vigtigt værktøj for projektlederen.

Indflydelsescirklen ændres med deltagerne. Hvad der er et vilkår på et teammøde, kan gøres til et løsbart problem, hvis CEO tilfældigvis deltager på mødet. Facilitering handler i høj grad om at aligne deltagerne til den samme forståelse af, hvad der er problemer og vilkår for denne kreds på dette møde. Alignment indebærer, at nogen skal acceptere, at emner, der kunne have været problemer, bliver gjort til vilkår – og vice versa. Vilkår kan være permanente eller midlertidige, så emnet bare er parkeret til senere.

Man skal hele tiden holde sig for øje, at mængden af opgaver skal passe med den tid, der er til rådighed. Hvis det er en person, er begrænsningen 24 timer i døgnet (hvoraf nogle af timerne går med at spise og sove). Hvis det er et team, er der flere timer til rådighed per dag, men der er også stadig begrænsninger. Hvis vi ikke har tid nok, så er det et nyt problem, der skal findes en løsning på i form af en opgave, der skal udføres, og opgaven til dette problem hedder typisk prioritering.

Den praktiske proces

Om du har tegnet denne model på en tavle, på væggen med tape, på et papir, eller om du blot har den i dit hoved som et mindset, er

Kapitel 6


underordnet. Det afgørende er træning i at bruge den. Træningen består i at mestre modellen kommunikativt.

Oprydningen af kaos består i at notere alle problemer, udfordringer, issues, risici og diverse uafklarede forhold ned på en Post-it-seddel eller tilsvarende, der let kan flyttes rundt. Sammen med teamets eller mødets deltagere går oprydningen nu i gang. Hvad kan vi leve med som vilkår? Det flytter uden for rammen. Til alle sedler inden for rammen stiller vi spørgsmålet: Hvilken opgave kan vi tage på os? Det bliver til en to-do-seddel under opgaver.

Den resterende del af problemstillingen, som vi ikke tager på os her, bliver for nærværende placeret uden for rammen. På et senere tidspunkt kan denne rest-problemstilling genopstå som et nyt og aktuelt problem – men den tid den udfordring. Et komplekst problem vil ofte dukke op flere gange – af den simple grund, at det er for komplekst til, at vi helt kan gennemskue, hvilke opgave der vil være tilstrækkelige til at fjerne problemet. Det er en cirkulær struktur – en iterativ proces – ligesom det, vi så på under den agile projektledelse. Den er velegnet til håndtering af usikkerhed.

Hvis der kommer flere opgaver ud af oprydningen, end vi kan overskue eller har ressourcer til at håndtere, må vi i gang med prioriteringen. Denne prioritering vil medføre, at opgavens bagvedliggende problemstilling skal accepteres som et vilkår. Ved at være meget konsekvent her, får man en ægte prioritering, hvor man faktisk oplever en accept af, at ikke-prioriterede opgaver ikke bliver løst. Det er langt bedre end den velkendte pseudo-prioritering i A, B og C, hvor man forventer, at det hele alligevel finder sin løsning.



Ved brug af modellen kommer man hurtigt til en situation, hvor nogen siger: ”Jamen, hvordan accepterer man, at et problem skal placeres som et vilkår, når man virkelig føler, at det bør løses?” Det er her, at lederskabet skal stå sin prøve, for det kræver stor emotionel intelligens at hjælpe andre til at acceptere noget som et vilkår, hvis de i virkeligheden hellere vil løse det. Det handler i sin enkelthed om, at der ikke er enighed om, hvilke ting der er et problem, som skal løses, og hvilke ting, vi skal acceptere som vilkår.

Alignment

Det er ikke muligt for et team at arbejde sammen, hvis nogen synes, noget er et vilkår, mens andre synes, det er et problem. Førstnævnte vil tale om emnet som noget, vi skal lære at leve med, mens andre prøver at finde en løsning på problemet. De er først et team, når de er på samme side af linjen. Ellers har man reelt to teams.

Kapitel 6


I bund og grund er rammens placering en beslutning. En beslutning om, hvad vi vælger at bruge vores mentale energi på. Rammen er under indflydelse af, hvor meget tid vi har, hvad vi tror er muligt, den herskende kultur, personlige præferencer og meget andet. Vi har brug for at tydeliggøre rammen – både over for os selv og hinanden. Jo mere vi er enige om rammen, jo stærkere står vi som gruppe. Hvis vi ikke kan blive enige om rammen, kan vi heller ikke blive enige om meget andet.

I megen ledelseslitteratur står der, at lederskab handler om at skabe alignment, men hvordan man egentlig gør det, fortaber sig desværre i det uvisse. Men med ovenstående rammesætningsmodel har du nu fået en meget enkel og konkret opskrift på at skabe alignment.

Problemet har en ejermand, som har emotioner

Hvis problemet ikke har en ejer, så er det ikke et problem. Hvis nogen synes, noget er et problem, så er det, fordi de føler noget, når de tænker på det. Hvis de var ligeglade, så ville det være et vilkår. Ejerforholdet til et problem er med andre ord etableret med emotioner. Man er engageret i problemstillingen med sine følelser. Man kan føle for at ændre noget, opnå noget eller undgå noget. Hvis en person ikke føler noget for en ”sag”, så er emnet blot et vilkår for denne person. Hvis ingen føler noget for et givent emne, så er dette emne blot et vilkår for alle.

Med andre ord kan noget kun beskrives som et problem, hvis nogen har emotioner knyttet til det. Hvis emotionerne er positive, kalder vi det dog ikke et problem, men derimod en udfordring.



Det er svært at give følelsesmæssigt slip på noget, man egentlig synes er et problem, der skal løses. Det er ægte lederskab, hvis man får folk til at slippe emner, de ellers er følelsesmæssigt knyttet til. Det er det, der ligger i at opnå accept.

Omvendt kan det også være svært at skabe begejstring for at gøre noget ved det, som de fleste har accepteret som et vilkår. Det er ægte lederskab, hvis man kan inspirere nogen til at se udfordringen i noget, der ellers blev opfattet som ligegyldige vilkår.

Hvis man med sit lederskab er i stand til at få folk til at skifte fra problem eller udfordring til vilkår eller omvendt, så er man i stand til at navigere igennem meget komplekse farvande for projektet.

Ledelsesopgaven i rammesætningsmodellen Alignment opstår, når vi er enige om, hvad der er problemer, og hvad der er vilkår i den aktuelle situation for projektet. Det vil sige, at vi er enige om rammen i modellen. Ordet ”vi” bør omfatte alle projektets væsentligste interessenter. Vi taler nemt forbi hinanden, når den ene taler om, hvordan ”vi kan løse noget”, mens den anden taler om, hvordan ”vi kan leve med det”. Det er en klassisk konfliktsituation.

Det næste niveau af alignment opstår, når vi også bliver enige om, hvilke opgaver vi tager på os. Det vil sige, når vi når til enighed om, hvad der kommer ind i cirklen. Det er projektlederens ansvar at sikre enighed om, hvilke af de mange mulige problemer, der skal være de aktuelle udfordringer, som projektet skal arbejde med. Rammen ændrer sig, afhængigt af hvilke problemer der

Kapitel 6


kommer til, finder en løsning eller forsvinder af sig selv. Jo mere komplekst projektet er, jo mere dynamisk vil rammen være.

Rammesætningsmodellen kan bruges til flere ting. En mulighed er som nævnt at hænge den på væggen i projektrummet og bruge Post-it-sedler til visualisering af drøftelserne af diverse emner. Men modellen stikker dybere end blot problemløsning. Den udtrykker også det politiske landskab. Som vi tidligere så, handler politisk ledelse om at sætte dagsordenen. Hvad er på dagsordenen, og hvad er udenfor? Dette er rammesætningen blot med andre ord.

For at gøre det helt konkret har vi herunder eksempler på sætninger, der kan bruges til at dirigere mødedeltagernes mindset. Når et problem tages op af en eller flere deltagere på mødet, bør projektlederen indledningsvis spørge: ”Er dette et problem eller blot et vilkår?” Hvis det er helt uden for vores indflydelse, er det et vilkår, men hvis det er indenfor, skal vi beslutte os for, om vi vil bruge tid på problemet.

Som nævnt tidligere er et problem kun et problem, hvis nogen føler noget for emnet. Omvendt kan et emne kun accepteres som et vilkår, når vi holder op med at være følelsesmæssigt knyttet til det. Projektlederen kan være nødt til at behandle disse emotioner for at skabe accept.

At skabe accept af, hvad der er et vilkår i forhold til problemer, kræver ledelse. Her bør man overveje forskellige lederstile i forhold til emnet, deltagerne og situationen i øvrigt. Ledelsen kan være rettet mod hele gruppen eller enkelte deltagere, der skal rette ind.



Projektets vilkår stammer overordnet fra styregruppen. Det kan være effektivt, hvis man får teamet alignet inden for disse vilkår. Her er nogle konkrete sætningseksempler til inspiration:

Den autoritære kunne vælge sætninger som disse: ”Stop, vi har ikke tid til at drøfte dette nu”, ”Jeg har et klart mandat fra styregruppen” eller ”Det er nødvendigt at acceptere, at dette bliver parkeret til senere.” Det kan godt være, at man kan køre mødet igennem, men folk vil sjældent ændre følelserne for emnet.

En mere demokratisk stil kunne være at stille spørgsmål som: ”Jeg vil gerne have jeres input til, hvordan projektet kan leve med disse vilkår?”, ”Er der enighed om at nedprioritere dette emne til et senere møde eller måske et senere projekt?” eller ”Jeg anerkender problemet, men vil gerne parkere det til senere. Er det okay?” Den demokratiske tilgang kræver længere tid, men kan være nødvendig for at få en bæredygtig parkering af problemet som et vilkår.

Eller det kunne være den coachende lederstil, som man valgte med en sætning som denne: ”Hvad skal der til for at leve med dette som et vilkår – i stedet for at prøve at løse det?”. Den coachende stil egner sig ikke så godt til møder, men mere til samtaler med én teamdeltager ad gangen.

Som nævnt i tidligere kapitel er perfekt udførelse af noget, der ikke skulle være gjort, den højeste grad af ineffektivitet. Derfor er det bedste, du nogle gange kan gøre, at udfordre de vilkår, som projektet har fået. Det kræver meget visdom at kende forskel på de to. Rammesætningsværktøjet kan bidrage til at tydeliggøre, hvilke vilkår projektet som udgangspunkt har, så vi i

Kapitel 6


fællesskab kan tage stilling til, hvilke vilkår vi bør beslutte os for at acceptere.

Innovation er den modsatte proces

Mange siger, at innovation sker bedst i kaos. Hvis man vil beskrive innovation i rammesætningsmodellen, så handler det om at gøre et vilkår til et problem. Man skal tænke ud af boksen for at se problemet i noget, andre tager for givet. Innovation er i bund og grund, at man tager noget, andre opfatter som et vilkår, og gør det til et problem, som man derefter finder en løsning på. Det er denne proces, der forandrer verden.

Oprydning i det kaotiske

Oprydningen vil i praksis foregå på møder, workshops og andre fora, der bliver afholdt for at dele information, drøfte problemer, udvikle idéer og beslutte handlinger. Disse sociale begivenheder lægger ofte beslag på en stor andel af projektets ressourcer, og derfor er det afgørende, at projektlederen forstår at facilitere møderne effektivt. Vi kender alle møder, hvor drøftelserne kører rundt og rundt uden rigtig at komme nogen vegne. Hvert nyt bidrag synes at være relevant, men bidrager kun til at gøre drøftelserne mere kaotiske. Emnet synes at vokse sig større og større, lige indtil tiden er gået, og man ender med konklusionen om, at vi må tage emnet op igen på et senere møde.

Som projektleder bør man være meget bevidst om, hvilken proces man prøver at lede. Uanset hvem eller hvad, der er årsagen til de kaotiske tilstande, så skal projektlederskabet træde i karakter for at rydde op og genskabe orden. Det følgende handler om en visuel model, der kan hjælpe med dette.



Figuren viser de tre principielle oprydningsprocesser, som findes i rammesætningsværktøjet:

1. Er man i gang med at opnå accept af, at et ”problem” placeres som et vilkår (eventuelt med en tidsbegrænsning)?

2. Eller er man ved at løse et problem ved at identificere en opgave i problemet, som vi kan og vil påtage os?

3. Eller prøver man at tvangsproblematisere et vilkår, altså at skabe en innovativ proces, hvor vi finder løsningen på noget, andre havde accepteret som et vilkår?

Nogle gange handler oprydningen om, at man skal skabe accept af vilkår opad. Det kan f.eks. være begrænsningerne i, hvad man kan udrette med det team, man har fået. Det er bestemt ikke nogen nem opgave at få styregruppen til at acceptere, at noget, de anså som et problem, ikke kunne løses, men i stedet var et vilkår.

Ved nærmere undersøgelse viser det sig ofte, at det ikke er emnet som sådan, der vokser, men derimod problemet, som ikke er blevet afgrænset. Ethvert emne kan drøftes i det uendelige, hvilket det ofte bliver, hvis projektlederen ikke sætter rammen.

Kapitel 6


Naturligvis er verden mere kompliceret og kompleks, men vi har brug for de simplificeringer, som dette værktøj giver, for at agere i vores projekter.

Simplicity = Complexity explained

Nogle gange handler lederskabet om at skabe simplicitet – Ikke fordi den er korrekt, men fordi den er nødvendig for handling i teamet.

En forkert forenkling af det kaotiske kan være bedre end en korrekt, men overkompliceret løsning. Særlig er forenkling godt, hvis man er meget villig til at opdage sine fejl, stå ved fejlene – og vælge en ny forenkling at handle på derefter. Ingen løsning er perfekt, men det er lettere at rette fejlen ved den enkle, frem for den komplicerede løsning.

Kaos eller vilkår?

At der er kaotiske tilstande, kan vi ikke gøre noget ved. Det er et vilkår – indtil det er gået over. Det eneste, vi kan gøre, er at håndtere problemer og issues, som det blev beskrevet tidligere.

Med andre ord: Du kan ikke forhindre kaos, men vælge hvilke elementer af kaos, du tager inden for rammen som problem-stillinger, du prøver at løse (alene eller sammen med projektet).

Mange opfatter kaos som noget dynamisk, noget, der er i konstant bevægelse. Alle projekter vil have elementer af kaos. For de fleste projekter er det kun på delområder eller i korte perioder, at kaos optræder. Nogle projekter oplever kaos som en del af døds-kampen, inden projektet lukker eller overgår til at være et zombieprojekt. Andre projekter har fungeret med kaos som en naturlig del i kortere eller længere perioder.



Det klassiske skrækscenarie: En topledelse træffer en beslutning om et IT-system, der skal rationalisere arbejdet. Et plandrevet projekt defineres. Ledelsen ser på projektets deadline og igangsætter fyringsrunder for at høste gevinsten af effektivise-ringen. Hvis man er uenig i denne strategi, kan man let blive den første, der fyres. Så der er en stor, skjult uenighed. Efterhånden som det plandrevne projekt gennemføres, viser usikkerheder sig, og leverancen bliver forsinket. Kompetenceudviklingen sker nu, samtidig med at de fyrede forlader jobbet, så alle, der skulle lave noget i det gamle system, enten er forsvundet eller på kursus i det nye system. Forandringsprocessen har ikke medtaget dette usikkerhedsmoment og kører processen det sidste stykke – helt ned i grøften. Mange deltagere på kuldsejlede IT-projekter, offentlige eller private, kan sikkert genkende billedet. Samme grundlæggende problemstilling findes i mange andre brancher og projekttyper.

Den korte genfortælling er, at man antager, at der er enighed og sikkerhed, så man kan køre et plandrevet projekt. Men i virkeligheden er der både uenighed og usikkerhed, så derfor skal man gøre noget helt andet. Når post mortem skrives, er det ”naturligvis” projektets skyld … sagt med en bittersød bemærkning! Dette kan måske ikke undre, for det er ofte de samme beslutningstagere, der bestiller en post mortem-rapport, som også bestiller det plandrevne projekt.

Der er ofte en omvendt sammenhæng imellem selvsikkerhed og forståelse af problemet. Jo mindre du forstår problemet, jo nemmere tror du, at problemet kan løses. Eller som Bertrand Russell har udtrykt det: Det, der er galt med verden, er, at de dumme er så skråsikre på alting – og de kloge er så fulde

Kapitel 6


af tvivl. Overført til projektverdenen betyder dette, at jo mindre beslutningstageren forstår projektet-problemet, jo nemmere er det at træffe katastrofale beslutninger.

Samspil med projektværktøjskassen Rammesætningsværktøjet spiller fint sammen med mange andre metoder fra projektværktøjskassen.

Problemerne inden for rammen kan behandles med alle de sædvanlige problemløsningsteknikker som for eksempel fiskebensanalyse, Root Cause, brainstorm eller 5 x Why med det mål at finde frem til den opgave, teamet kan påtage sig.

Problemet kan med fordel opdeles i en ”Problem Breakdown Structure” (tilsvarende en WBS, blot med en nedbrydning af et problem). Et problemhierarki forholder sig til WBS, som problem forholder sig til løsning. Man kan både tale om ”scope” af en løsning, men også om scope af et problem. Når problemet nedbrydes i delproblemer, er det også nemmere at identificere, hvilke af disse der er vilkår eller kan parkeres.

Der er en vigtig balance mellem problemanalyse og løsnings-mindset. Faktisk kommer vi ofte til at hænge fast ved at analysere problemet for længe – i stedet for blot at prøve en løsning, der ligner en mulighed. Det er vigtigt at kunne sige: Fint, lad os prøve dét i en periode og så evaluere, hvorefter løsningen kasseres, bevares eller forbedres.

Opgaverne inden for kontrolcirklen kan detaljeres yderligere med angivelse af ansvarlig tovholder, aktionslister, tidsplaner, RACI-matrix eller med SMART-kriterier for resultatet. Projektets



aktiviteter, for eksempel defineret som WBS, findes inde i kontrolcirklen, mens projektets formål findes uden for denne cirkel.

Planlægning er egentlig let nok, hvis blot man får tiden til det, og fremtiden lader sig forudsige, når vilkårene er stabile. Det er muligt, at problemerne, vi skal løse, er komplicerede, og at udførelsen af opgaverne er indviklet, fordi der er mange komponenter og grænseflader. Men når blot det lader sig analysere, kan vi også lave planer – selv om de bliver komplicerede. Når man skal planlægge, findes der mange strukturmetoder i værktøjskassen at vælge imellem.

Essensen i planlægning er, at vi har et kendt og veldefineret problem, som vi finder en løsning på. Planen bliver herefter en opskrift på, hvordan vi kommer fra problem til løsning. Hvis projektet er kompliceret, er der mange opgaver, som skal løses i en bestemt sekvens, hvilket ofte gør planlægningen kompliceret og medfører endnu mere komplicerede planer. I den klassiske planlægning, hvor vi opstiller tids- og aktivitetsplaner, har vi forudbestemt, hvilke opgaver vi påtager os i projektet. Planen kan være enkel eller kompliceret, som der er behov for.

Et komplekst projekt vil have et problem, der ændrer sig igennem projektets løbetid. Nogle delproblemer vil falde bort, mens ukendte problemer vil komme til i en mængde, der ikke kan forudsiges eller overskues på forhånd. Hvis projektet er komplekst, giver planlægning derfor ikke lige så meget mening, og i stedet for bør projektlederen vedligeholde rammesætningen, så der konstant tages stilling til, hvilke problemer der arbejdes med. Efterfølgende lader projektlederen de aktuelle problemer styre, hvilke opgaver der bliver udført.

Kapitel 6


Rammesætningsmodellen og projektmålsætning

Problemer og udfordringer ligger inden for rammen, men uden for cirklen. Hvis vi ser på projektniveauet, er problemer og udfordringer lig med formålet. Et formål er en beskrivelse af et problem, der skal løses, eller en udfordring, der skal lykkes.

Cirklen, altså det, som projektet har kontrol over, kan beskrives som projekttrekanten. I det plandrevne projekt beskriver cirklen trekanten for hele projektet. I det agile projekt er cirklen lig med det næste sprint (eller timebox).

Projekttrekanten handler om at få kontrol gennem en definition af indhold, estimering af ressourcebehov og fastlæggelse af deadline. Projekttrekanten er derfor et afgørende værktøj i kontrolcirklen.



Hvis vi fra kanten af kaos får kontrol over situationen, ser billedet måske sådan ud. Inden for kontrolcirklen hersker projekttrekan-ten. Hvis vi kan komme tilbage til det sikre domæne, er det, fordi hele projektperioden er kommet ind i kontrolcirklen. Hvis vi er i det uvisse domæne, er det ”kun” et sprint ad gangen, der er i kontrolcirklen.

Reduktion af divergens

Hvis uenigheden er høj, er det første punkt, man må få afklaret: Er dette en diskussion af, om det er et problem eller et vilkår? Det nytter egentlig ikke at drøfte andet, indtil vi er enige om dette punkt.

Nogle gange handler diskussionen om, hvad der skal betales, for at problemet bliver løst. Det kan være imellem en kunde og en leverandør. Hvis leverandøren kan få ekstra betaling, er denne normalt opsat på, at det er et problem for kunden, som bør løses. Hvis leverandøren derimod er kontraktligt bundet, så der ikke kommer en ekstra betaling, mener leverandøren meget ofte, at problemet blot er et vilkår, som kunden skal lære at leve med.

Som sagt: Vi skal først opnå enighed om, hvorvidt det er et problem eller et vilkår, for løsningen vil afhænge meget af, hvem der ejer problemet – hvis der overhovedet er et problem.

Når der er opnået enighed, kan vi gå videre til, hvad det så er for en løsning, vi kan blive enige om? Hvilken opgave skal vi tage på os? Nogle gange kan uenighed om opgaven give et tilbageløb i diskussionen til en genoptagelse af uenigheden om, om det overhovedet er et problem.

Kapitel 6


Hvis vi så er enige om, hvilken opgave vi tager på os, så er vi faktisk kommet fra domæne 4 til domæne 1., hvor det er projekttrekanten, der er i spil og udtrykker den opgaveudførelse, vi er enige om. Det vil sige, hvad opgaven består af, hvad vi regner med, at den koster, og hvornår vi forventer, den er færdig.

Det kan også være, at drøftelserne ender med, at der er enighed om, at det er et problem, der skal løses – men der er usikkerhed om, hvad løsningen er. Så er vi faktisk i domæne 2. Enighed og usikkerhed. Her er det emergens, der hersker, og vi må i gang med eksperimenterne.

Projektlederens business case dilemma

Nogle gange – men heldigvis ikke altid – står man som projektleder i et særligt dilemma i projektets tidligere faser, hvor man skal skaffe den første accept fra sponsor, direktion, eller hvem der nu skal godkende projektet ud fra den fremlagte business case.



Hvis projektet i projektlederens øjne har en uvished, der gør det komplekst, men projektejer/styregruppe synes, at det ”blot” er kompliceret, skal projektlederen vælge sine ord med stor omtanke.

Hvis man siger, at projektet er komplekst, så får projektet sikkert ”kniven”, fordi projektejer ikke ønsker en usikker, uforudsigelig og utilregnelig business case. Der skal i hvert fald være en kæmpe potentiel benefit i den sidste ende.

Hvis projektlederen omvendt lader, som om projektet ”kun” er kompliceret, fordi det nu engang er dét, projektejeren gerne vil høre, så ender det med noget, der har karakter af russisk roulette. Måske går det godt – men risikoen er stor, og konsekvensen er fatal.

En undersøgelse har i øvrigt vist, at 1 ud af 6 IT-projekter for den britiske regering fejlede med mere end 100% overløb på både tid og budget. Så metaforen med russisk roulette er ikke helt skæv.

I forhold til projektkompleksitetsvinduet kan man sige det sådan: Projektlederen oplever, at der er uvished i projektet, men projektejeren er ikke enig. Derfor er der både uvished og divergens. Projektet er derfor i det kaotiske domæne.

Her skal projektlederen træffe et afgørende valg. Skal enigheden om uvisheden gøres til et problem eller et vilkår?

Kapitel 6


Opsamling: Det kaotiske domæne Det er kaotisk, når situation er tæt på kaos. Det kaotiske består både af divergens og uvished. Når vi oplever det, må planerne vige for den umiddelbare genetablering af rammerne om vores samarbejde.

Kaotisk blev defineret som mangel på en fælles ramme om dét, der aktuelt foregår, og kapitlet præsenterede en rammesætnings-model.

Essensen i rammesætningen er at opnå enighed om, hvad vi betragter som vilkår og problemer. Dernæst handler det om at blive enige om, hvilke opgaver projektet skal påtage sig. Ved valget af opgave må man ofte affinde sig med, at det kan være uvist, om opgaven løser problemet. Derfor kan det være nødven-digt at arbejde iterativt.

Med andre ord, rammesætningsmodellen virker til at løse både uvisheden og diversiteten, der er den dobbelte kompleksitet, der kaldes kaotisk.

Rammesætningsmodellen har en firkantet ramme og en kontrol-cirkel inden i. Begge dele har nær sammenhæng til projekt-ledelsens værktøjskasse, som forklaret i kapitlet.

Afslutning


Afslutning af bogen

Vi har indtil nu set på projektledelse i fire forskellige situationer, eller domæner, som de er kaldt.

Først det sikre domæne med klarhed og konsensus, som passer fint til den klassiske plandrevne projektledelsesstil, hvor man planlægger og siden gennemfører planen frem til en leverance ved projektets afslutning.

Dernæst så vi på det uvisse domæne, hvor den agile projektledelse spreder planlægningen hen over hele projektet, og løbende laver delleverancer, så læringen kan indarbejdes i projektet.

Det tredje var det divergente domæne, hvor der er brug for politisk projektledelse, hvor man fokuserer på at afdække uenigheder og potentielle konflikter samt arbejder for, at disse ikke står i vejen for projektet.

Det fjerde og sidste domæne er på kanten af kaos, hvor projekt-lederne bliver kaospiloter, der skal skabe kontrol over, hvad der kan kontrolleres – uanset, hvor lidt dette måtte være – ved at sortere skrapt i vilkår, problemer og opgaver, man kan tage på sig.

Der er også en femte, som vi først nu berører. På billedet af projektledelsesmatrixen kan det være hajen i midten, som indtil nu har svømmet ubemærket rundt midt i billedet.

Entreprenant projektledelse I takt med at flere og flere forventer, at projektet også tager forretningsmæssigt ansvar – og gennem dette også ansvar for forandringen i forretningen/organisationen – så kommer

Afslutning


projektlederne til at være i en situation, hvor de mere og mere ligner en entreprenør, der tager et forretningsmæssigt ansvar.

Den entreprenante projektleder har mere fokus på den store trekant uden om projekttrekanten, illustreret på denne måde. Den entreprenante projektleder har fokus på formål og succeskriterier og tager selv en risiko for at skabe en forretningsmulighed.

Hvis man har ansvar for realisering af benefit, har man mere status som programleder end projektleder. Normalt bruges

Afslutning


programmer om store initiativer, der omfatter mange projektet og varer i flere år. Dette er i hvert fald udlægningen i MSP (Managing Succesful Programmes). Processen er, at projekter leverer output, mens programmet skaber kompetenceudviklingen og sikrer forandringsprocessen samt realiserer den endelige benefit.

Hvis man skulle indtegne den entreprenante projektledelse i vores projektkompleksitetsmatrix, så ville det blive en tredje dimension. Entrepreneurskabet er måske indfanget meget fint af Richard Brandson-citatet: Screw it – let’s do it!

Hvad med hajen, hvorfor er den med? Ja, kunne det måske være den entreprenante projektledelse, der ligger der og lurer i midten af projektkompleksitetsvinduet, midt mellem de fire andre former?

Dette spørgsmål vil anden del af denne bog komme til at besvare. Titlen på næste bog bliver formodentligt: Ledelse af komplekse projekter – med benefit-drevet projektledelse.

Afslutning


Resume af bogen Bogen giver gode råd til ledelse af komplekse projekter og definerer projektkompleksitet på følgende måde:

Et projekt kan være simpelt eller kompliceret, og dog analyserbart på forhånd. Derimod er et komplekst projekt uforudsigeligt som følge af projektets usikkerhed og interessenternes uenighed. Høj score i begge faktorer kan give projektet kaotiske træk.

Denne definition giver anledning til en opdeling i 2 x 2 vindue med fire domæner som vist herunder, der kaldes projekt-kompleksitetsvinduet.

Projekter bevæger sig fra start til slut rundt i det landskab, der udspænder sig imellem usikkerhed og uenighed.

Afslutning


De fleste projekter har delområder i forskellige domæner, så det giver mest mening at tale om projektets spredning på domænerne i matrixen frem for kun en placering.

Projektledelsen må finde en passende reaktion på, hvor projektet aktuelt befinder sig i matrixen.

Overordnet er hovedanbefalingerne til hvert af de fire domæner:

1. Det sikre domæne med konsensus og klarhed: Fokuser på leverancen. Lav en plan og realisér den.

2. Det uvisse domæne med høj usikkerhed. Skab iterative processer og læringsfeedbackloops.

3. Det divergente domæne med høj uenighed: Lav en politisk analyse og skab magtrelationerne.

4. Det kaotiske domæne, hvor der både er høj uklarhed og usikkerhed: Få kontrol med kaos gennem accept af rammesætningen.

Og så er der som sagt den femte, entrepreneurship, den benefit-drevne projektledelse, der må være en cliffhanger til næste bog.

SLUT

Afslutning


Tak, fordi du brugte tid på denne bog. Jeg håber, du har sat lige så meget pris på at læse bogen, som jeg har værdsat at skrive den.

Måske har den sat gang i tanker, spørgsmål og refleksioner. Hvis du har lyst til at dele disse med mig, så er du mere end velkommen til at skrive til mig på adressen: [email protected]

Invitationen gælder også hvis du har lyst til at deltage i forkning på området. I de næste par år, forventer jeg at komme til at lave en række systematiske undersøgelse af emnet ledelse af komplekse projekter – og du må gerne være med.


Appendiks

Som nævnt i indledningen har vi skubbet en mænge relevant stof, som muligvis ikke interesserer alle, til dette appendiks.

I kapitlet ser vi både på, hvordan projektledelsesstandarderne forholder sig til begrebet projektkompleksitet. Der kommer også en historisk gennemgang af definitionsudviklingen over de sidste tyve år.

Man skal dog ikke forvente, at kapitlet her kommer med et facit. Historien viser nemlig, at det er vanskeligt at opnå konsensus om, hvad projektkompleksitet egentlig er. Ja, man kan sige, at definitionen af projektkompleksitet i sig selv er kompleks.

Den historiske gennemgang indeholder også en argumentation for, hvorfor denne bogs definition er valgt, samt hvilke andre relevante definitioner, der også kunne benyttes.

Vi ser også på det generelle kompleksitetsbegreb afslutningsvist, blandt andet for at præsentere to af de modeller, denne bog har gjort brug af til at opbygge projektkompleksitetsvinduet.

Lige en advarsel: Dette appendiks har et meget anderledes indhold end bogen, og derfor er stilen også meget anderledes –lidt kedeligt, har nogen sagt.

På grund af appendiksets karakter, er det valgt at benytte kildernes originale illustrationer, således at Yogi muntre steg stopper her.

Kompleksitet kan defineres på flere måder

I bogens indledning blev der præsenteret to forskellige måder at definere begrebet på. Dels en gradbøjning, dels en parameterbeskrivelse. Hvis disse skulle bruges til at definere begrebet ”størrelse”, så ville gradbøjningen pege på, at der findes fire forskellige klasser: S, M, L og XL. Parameterdefinition af størrelser vil for eksempel optræde i de tre parametre højde, bredde og længde. I det følgende ser vi både på klassifikationsdefinitioner og parameterdefinitioner.

Der findes generelle kompleksitetsforståelser, som henvender sig til ledelse generelt. Desuden findes der specifikke forståelser, der adresserer projektkompleksitet. Der er både en naturlig forskel og et naturligt overlap imellem de generelle og de specifikke modeller.

Projektledelsesstandarder og kompleksitet

PMBOK

PMI (Project Management Institut) udgiver en standard for projektledelse, der kaldes PMBOK (Project Management Body of Knowledge). Der er en 600 siders manual, som man bliver eksamineret i for ifølge PMI at kunne kalde sig PMP, dvs. Project Management Practitioner. PMI forholder sig ikke ret meget til kompleksitet. Det er nævnt lidt hist og pist i PMBOK.

PRINCE2

PRINCE er en forkortelse af: PRojects IN Controlled Environments. Manualen er er på 450 sider, så det er også en

omfangsrig sag. PRINCE2 forholder sig ikke direkte til projektkompleksitet, men formålet med at skabe et kontrolleret miljø kan ses som en reaktion på kompleksitet.

Forskellen på PRINCE2 og PMBOK er, at PRINCE2 fokuserer på roller og processer, mens PMBOK fokuserer på projektlederens kompetencer. PRINCE2 har stort set ingen værktøjer til projektlederen, mens PMBOK er fyldt med værktøjer til planlægning, kontrol og opfølgning på projekterne.

Hverken i PRINCE2 eller PMBOK finder man særskilt omtale af projektkompleksitet. Dette emne er ikke centralt for hverken PMBOK eller PRINCE2. Det er derfor ikke overraskende, at Per Svejvik fra Århus Universitet har konkluderet, at projektkompleksitet tvinger os til at gentænke projektledelse (Svejvik, 2015).

MSP

MSP er en forkortelse af Managing Successful Programmes, og er lavet af samme organisation, som leverer PRINCE2. MSP er ikke som sådan en projektledelsesstandard, idet den handler om ledelse af programmer. Den er værd at nævne her, fordi komplekse projekter kan opfattes som mini-programmer (Hass, 2009). MSP skaber et framework for håndtering af benefitrealisering, blandt andet ved at formulere roller og ansvar for forandringsagenter og forretningsansvarlige. Men heller ikke denne metode forholder sig til projektkompleksitet.

IPMA

Dette er den eneste projektledelsesstandard, der forholder sig til projektkompleksitet. Som projektledelsesstandard betragtet er IPMA (International Project Management Association) en

fleksibel størrelse. Der findes en international standard ICB (International Competence Baseline), og så kan hvert medlemsland have sin egen standard NCB (National Competence Baseline). Den danske NCB udmærker sig ved at lade kompleksitet indtage en central rolle. Alle, der er blevet certificeret efter denne standard, har prøvet at score deres egne projekter i forhold til en kompleksitetsskala.

Til forskel fra de danske NCB’er har den internationale ICB en anden kompleksitetsskala, og denne benyttes kun til certificeringerne på niveau B og A. Den internationale kompleksitetsskala afviger på visse punkter fra den danske, så endnu en gang må vi konstatere, at projektkompleksitet er en kompliceret sag at gøre rede for.

NCB’s 12 parametre for projektledelseskompleksitet

• Projektets omgivelser ► Projektets betydning ► Politiske vilkår for projektet ► Antal interessenter og andre afhængigheder ► Forandringer hos kunden / i virksomheden

• Projektets opgave og forløb ► Funktionalitet af projektets resultater ► Løsningstyper / anvendt teknologi ► Antal af delprojekter ► Angrebsmåde og tidsramme for gennemførelsen

• Projektets ressourcer og organisation ► Samlede projektressourcer ► Projektdeltagernes kompetencer ► Projektorganisationens struktur ► Deltagernes geografiske placering

IPMA’s kompleksitetsvurdering bruges indledningsvist til at ”måle” projektets kompleksitet på en skala, der består af 12 parametre. Hver parameter scores med værdien 1-4. Man tager et gennemsnit af disse 12 og får hermed en samlet score for projektet. Scoren af projektledelseskompleksiteten skal bruges til at afgøre, hvor ”tung” projektlederen skal være, med andre ord om det skal være en med IPMA-certificeringen D, C, B eller måske A, der skal lede projektet.

Tankegangen om, at man kan analysere projektets kompleksitet i begyndelsen af projektet, er måske lidt for optimistisk. I praksis skal man nok med jævne mellemrum lave analysen. Ganske som man vil gentage interessentanalyse eller risiko-analysen jævnligt hen gennem projektet.

Historisk udvikling af projektkompleksitetsdefinitionen Dette afsnit tager os med til begyndelsen af projektkompleksiteten, der opstod som et forskningsfelt tilbage i 1995. For at undgå tvivl ved oversættelse er nøglebegreberne bevaret på engelsk.

Der er udvalgt en række papers fra internationale journals, som der refereres til af mange, og derfor har en høj status i forskerkredse.

Når man ser på forskningsfeltet, er den ældste paper, der refereres til, fra 1995 (Baccarini, 1995). David Baccarini definerer projektkompleksitet som ”Variation and interrelations”. Der er både en organisatorisk og en teknisk side. Måske man kan bruge udtrykkene mangfoldighed og grænseflader såvel teknisk som organisatorisk til at beskrive den tidlige forståelse af

projektkompleksitet. Der bliver i senere videnskabelige papers refereret til denne forståelse som den ”strukturelle kompleksitet”.

I forhold til bogens projektkompleksitetsvindue ligger Baccarini i det sikre domæne, idet han antager, at såvel de tekniske som de organisatoriske variationer og relationer kan analyseres på forhånd.

En anden forsker, Terry Williams, argumenterer i 1999 for, at projektkompleksitet består af såvel den strukturelle kompleksitet som usikkerhed i mål og metoder. Hans nøglebegreber er Structural Complexity, Uncertainty: uncertainty in goals; uncertainty in methods (Williams, 1999). Hermed står Williams i kontrast til dem, der mener, at projektkompleksitet og usikkerhed er to uafhængige variabler. Williams bruger begreber som “weakness of goals” og “newness of technology” til at beskrive sin forståelse af usikkerhed som en del af projektkompleksitet.

I forhold til projektkompleksitetsvinduet medtager Williams dermed både det sikre og det uvisse domæne.

Weidong Xia går en anden vej og forslår, at projektkompleksitet defineres med en 2 x 2-matrix, der består af opdelingen (Xia, 2004):

• Organizational vs. Technological • Structural vs. Dynamic

Xia bruger denne matrix til at inkludere forhold omkring forandring som en del af projektkompleksiteten. Man kan sige, at Xia laver en ”dobbelt op” på Baccarinis definition ved både at have en strukturel og en dynamisk side af sagen.

Det bør bemærkes, at Xias forståelse af ”dynamisk” indbefatter ”change” – både den udefrakommende og den, man selv laver internt. Dermed er forandringsbegrebet nu en del af kompleksitetsforståelsen. Forandring er ellers noget, som både PMI og PRINCE2 udelader af projektlederens ansvar. Xias definition af projektkompleksitet bevæger sig uden for, hvad der traditionelt betragtes som projektlederens ansvar.

Xia har en anden fremstilling end Williams, men det er stadig placeret i, hvad denne bog kalder det sikre og det uvisse domæne.

Nogle år senere kommer Jerry Mulenburg med et forslag til 6 parametre til projektkompleksitet: Details, Ambiguity, Uncertainty, Unpredictability, Dynamics, Social Structure (Mulenburg, 2008). Denne definition er på en måde en forlængelse af Xias udvidelse med den dynamiske side af sagen. Samtiden medtages også i Williams vinkel på sagen: At projekt-kompleksitet indeholder usikkerhed, ja, endda uforudsigelighed. Som noget nyt har Mulenburg også tvetydighed med som et parameter, hvilket peger på, at kompleksitet opstår, fordi det menneskelige sprog har mange lag med uspecifikke referencer.

Som omtalt i et tidligere kapitel er tvetydighed en mulig årsag til – og en taktisk sløring af – ødelæggende uenighed i projektet. Ambiguity både skaber og slører uenighed i og omkring projektet.

Mulenburgs 6 parametre kan ses som en underopdeling i de to hovedparametre, der er brugt i nærværende bog: usikkerhed og uenighed. Dermed har Mulenburg både placeret sig i det sikre, det uvisse og det divergente domæne med sin definition.

Harvey Mayer foreslår et stort hierarki af spørgsmål. Ifølge Mayer bør man stille i alt 120 spørgsmål for at få hånd om

projektkompleksiteten. Disse spørgsmål adresserer fem hovedområder: Mission, Organization, Delivery, Stakeholders and Team (Mayer et al, 2008). Disse 120 spørgsmål vedrører næsten alt, hvad man kan komme i tanke om med relation til projekter. Frit oversat siger Mayer, at ”projektkompleksitet består af alt med relation til projekter”.

I 2010 laver Joana Geraldi et opsamlende studie på de videnskabelige papers indtil da. Hun argumenterer for, at der peges på fire dimensioner: Structural. Uncertainty. Dynamic. Pace. Socio-political (Garaldi 2010). Structural er et udtryk for projektstørrelse og indre afhængigheder (meget a la Baccarinis oprindelige forslag til definition). Uncertainty omfatter nøgleord som novelty, experience, availability of information, og også begrebet ambiguity. Dynamic er en bred forståelse af forandringer og ændringer. Pace er inkluderet, selv om det ikke virker, som om der helt er belæg for dette ud fra de papers, hun citerer, så det er vist mest hendes eget tillæg til sagen. Socio-politisk dækker over nøglebegreberne: importance, support to, fit/convergence and transparency.

Geralidis fremstilling af forskningens definition af projektkompleksitet til dato viser, at det strækker sig ud over både det sikre, det uvisse og det divergente domæne.

Christian Brockman har et forslag til, hvordan projektkompleksitet kan forstås gennem disse fem dimensioner: Task, Social, Cultural, Cognitive Operative (Brockmann, 2012). Nu har vi både kultur og tænkning med i definitionen. Det er der helt sikker et godt belæg for, men dermed bliver definitionen også mere floffy at arbejde med. Man kan sige, at Brockman bliver talsmand for, at projektkompleksitet bliver et spørgsmål om

perspektiv, altså at det, vi ser, er et udtryk for vores kultur og mentale filtre.

Med denne definition bevæger vi os i retning af nødvendigheden af rammesætning, som vi fremhævede under det kaotiske domæne.

Mohsin Qureshi laver, ligesom Geraldi, et tværgående studie og ender med følgende seks nøglebegreber: Non-linearity, Context Dependence, Uniqueness, Uncertainty, Trust, Capability (Qureshi, 2014). Det må i sandhed siges, at projektkompleksiteten her er meget anderledes end den, Baccarini definerede 20 år tidligere. Nu er forståelsen af projektkompleksitet, at den er ikke-lineær, kontekstafhængig, unik og usikker, tillidsafhængig og ikke mindst afhængig af egne færdigheder. Med sidstnævnte er objektiviteten opgivet, idet det betyder, at det er så komplekst, som vores evner gør det til. Man kan sige, at nøglebegreb 1, 5 og 6 passer med uenighed i vores model. Nøglebegreb 2, 3 og 4 passer med usikkerhed. Det virker, som om Qureshi helt har forlagt den strukturelle kompleksitet som en parameter.

Det samme år foreslår Ivana Dunovic en definition, der er noget mere enkel og måske lidt Old School-agtig med disse tre dimensioner: Structural (Number of Elements and Dependencies), Uncertainty (of Objectives and Methods), Constraints (of Environment, Resources and Objectives) (Dunovic, 2014). Det interessante ved Dunovics fremstilling er, at han definerer tre lag af projektkompleksiteten, der bygger ovenpå hinanden. Formuleret med en enkelt sætning siger han: Structural complexity compounded by uncertainty increased by constraints. Sagt med andre ord bliver den underliggende, strukturelle

kompleksitet forstærket af usikkerhed og øget med begrænsninger (fra centrale interessenter).

Den sidste definition, som vi har valgt at medtage i denne bog, er fra Alexei Botchkarev, der peger på, at projektkompleksitet omfatter følgende tre områder: Product (solution/business challenges), Project (knowledge and skills gaps) and External Environment (stakeholder nonalignment, user incongruity) (Botchkarev, 2015). Med denne definition kan projektkompleksitet stort set ikke blive mere omfangsrigt. Det, Botchkarev lægger til de øvrige forslag, er i særdeleshed forretningsvinklen, som jo tidligere har ligget uden for projektets ansvarsområde. Så med denne definition lægges der op til en helt anderledes forståelse af, hvad en projektleder er og har af ansvarsområder.

Som opsamling på den historiske udvikling kan man sige, at definitionen af projektkompleksitet over de sidste 20 år har bevæget sig fra noget forholdsvist simpelt til en meget vidtforgrenet og indviklet definition, der har tendens til at forsøge medtagelse af alle tænkelige forhold (Mikkelsen, 2016).

Andre modeller for projektkompleksitet I det foregående har vi set på definitioner, der benyttes, når man ser på ”projektkompleksitet” som det centrale begreb, som har fået en række forskellige nøgleord som underparametre.

Der findes også modeller, hvor projektkompleksiteten er et underpunkt i en større model. En af disse er usikkerhed-kompleksitetsmatrix, der er en 2 x 2 matrix tilsvarende den, bogen

bruger, men, som det fremgår, blot med en anden parameterkombination.

En anden model, hvor kompleksiteten er en parameter i modellen, er NTCP-diamanten (Novelty, Technology, Complexity and Pace), som beskrives i næste afsnit.

NTCP-diamanten

Illustrationen herunder er kopieret fra “Why projects fail? How contingency theory can provide new insights” (Sauser, 2009).

Brian Sauser anvender følgende tredelingen af kompleksitet:

• Assembly: Subsystem, performing a single function (e.g., CD player; cordless phone).

• System: Collection of subsystems, multiple functions (e.g., spacecraft; cars).

• Array: Widely dispersed collection of systems with a common mission (e.g., New York transit system; air traffic control).

Som det fremgår af NTCP-diamanten, er de fire parametre Novelty, Technology og Pace samt Complexity på samme niveau. Definitionerne af projektkompleksitet i forrige afsnit havde de tre førstnævnte som underdimensioner til kompleksiteten. Konklusionen må være, at der er rigtig mange mulige parametre og konstellationer, disse kan indgå i.

Generelle modeller af kompleksitet Når vi ikke kun ser på ”projekt-kompleksitet”, men på kompleksitet mere generelt, findes der et hav af andre modeller i den brede managementlitteratur. I det følgende nævnes tre, hvoraf de to første har været inddraget i nærværende modeludvikling.

Uncertainty – disagreement matrix

Kompleksitet er lige så meget en udfordring for ledere i almindelighed, som det er en udfordring for projektledere. De første modeller, vi kigger på, henvender sig til den første gruppe: lederne.

Organisationsteoretikeren Ralph Stacey har foreslået en Certainty Agreement Matrix (Stacey, 1996) til forståelse af kompleksitet. Mellem kaos og orden ligger ”The Zone of Complexity” med Staceys ord. Kompleksitet eksisterer imellem orden og kaos (frit efter Stacey). Hertil kan man lægge, at graden af kompleksitet er placeringen mellem orden og kaos.

Modellen er senere blevet viderebearbejdet i forskellige retninger. Særligt har Brenda Zimmerman sat begreberne: Simple, Complicated, Complex og Anarcy ind som gradbøjning.

De to parametre fra Staceys matrix er brugt direkte til nærværende bogs definition af projektkompleksitet.

Figuren er fra bogen Edgeware (Zimmerman, 1998).

Cynefin Framework

En anden model, kaldet Cynefin Framework, stammer fra David Snowden. Cynefin kan oversættes med landskab eller hjemsted. Modellen har 4 (5) domæner. Det femte domæne ligger i midten og handler om de situationer, som endnu er uafklarede (Disorder). Den ene side kaldes af Snowden for ”Order”, fordi det kan analyseres – hvilket man ikke kan med den modsatte side, kaldet ”Unorder”.

Figuren er kopieret fra en artikel i Harvard Business Review (Snowdon, 2007)

Simpel er ifølge Snowden et særtilfælde af det komplicerede. Fælles for de to er, at situationen kan analyseres til bunds. Ved det komplekse er det ikke muligt at forudsige, hvad der kommer til at ske, og derfor må man prøve sige frem.

Snowdens gradbøjning er brugt som en del af denne bogs definition, idet ”det indlysende” kun er medtaget som et underforstået punkt på det komplicerede. Det komplekse er blevet opdelt i to typer: Interessentkompleksitet og indholdskompleksitet.

VUCA-modellen

Mange flere modeller kunne hentes ind for at vise variationen, men lad os blot tage en ekstra som afslutning: VUCA-modellen, som måske mere er et begreb end en egentlig model. Begrebet VUCA, som er en forkortelse for Volatility, Uncertainty, Complexity og Ambiguity er introduceret af den amerikanske hær (Honey, 2010). Modellen er forholdsvis udbredt, og derfor er det rimeligt at nævne den her. Der bliver ofte sagt sætninger som ”We live i en VUCA-world”. Man kan hertil lidt kækt svare: ”Ja … og?”

Der er dog siden kommet et ”VUCA-modsvar”, der består i at arbejde med disse fire begreber, der tilsammen giver samme forkortelse: Vision, Understanding, Clarity og Agility. Dette giver måske god mening som en rettesnor for det lederskab, komplekse projekter har brug for.

Referenceliste

1. Baccarini, David. "The concept of project complexity—a review." International Journal of Project Management 14.4 (1996): 201-204.

2. Botchkarev, Alexei, and Patrick Finnigan. "Complexity in the Context of Systems Approach to Project Management." (2014).

3. Brockmann, Christian, and Kalle Kähkönen. "Evaluating Construction Project Complexity." CIB JOINT INTERNATIONAL SMPOSIUM, Rotterdam (2012): 716-727.

4. Budzier, Alexander, and Bent Flyvbjerg. "Overspend? Late? Failure? What the data say about IT project risk in the public sector." Commonwealth Governance Handbook 13 (2012): 145-157.

5. Catmull, Ed. Creativity, Inc.: Overcoming the unseen forces that stand in the way of true inspiration. Random House, 2014.

6. Collins, Jim, and Morten T. Hansen. Great by Choice: Uncertainty, Chaos and Luck-Why some thrive despite them all. Random House, 2011.

7. Damasiotis, Vyron, Panos Fitsilis, and James F. O'Kane. "Measuring communication complexity in projects." the Proceedings of the Management of International Business and Economic Systems (MIBES-ESDO) 2012 International Conference, School of Management and Economics, TEI of Larissa, Greece. 2012.

8. Dunović, Ivana Burcar, Mladen Radujković, and Kristina Ana Škreb. "Towards a New Model of Complexity–The Case of Large Infrastructure Projects." Procedia-Social and Behavioral Sciences 119 (2014): 730-738.

9. Enderud, Harald. Beslutninger i organisationer - i adfærdsteoretisk perspektiv. Fremad, 1976.

10. Geraldi, Joana, Harvey Maylor, and Terry Williams. "Now, let's make it really complex (complicated) A systematic review of the complexities of projects." International Journal of Operations & Production Management 31.9 (2011): 966-990.

11. Gregory, Robert W., and Everlin Piccinini. "The Nature Of Complexity In IS Projects And Programmes." Nature 7 (2013): 1-2013.

12. Gul, Saleem, and Shahnawaz Khan. "Revisiting Project Complexity: Towards a Comprehensive Model of Project Complexity." 2nd International Conference on Construction and Project Management. Singapore, IACSIT Press. IPEDR. Vol. 15. 2011.

13. Hass, Kathleen B. Managing complex projects: A new model. Management Concepts Inc., 2009.

14. Horney, Nick, Bill Pasmore, and Tom O'Shea. "Leadership agility: A business imperative for a VUCA world." Human Resource Planning 33.4 (2010): 34.

15. Kahneman, Daniel. Thinking, fast and slow. Macmillan, 2011. 16. Kotter, John P. What leaders really do. Harvard Business School

Publishing Corporation, 2001. 17. Van Marrewijk, Alfons, et al. "Managing public–private

megaprojects: Paradoxes, complexity, and project design." International Journal of Project Management 26.6 (2008): 591-600.

18. Maylor, Harvey, Richard Vidgen, and Stephen Carver. "Managerial

complexity in project‐based operations: A grounded model and its implications for practice." Project Management Journal 39.S1 (2008): S15-S26

19. Mikkelsen, Mogens Frank, Novateam. "How to cope with complexity? - A review of project complexity literature using the Cynefin framework as theoretical lens.". The 39th Information Systems Research Conference in Scandinavia, 2016

20. MSP. Office of Government Commerce (OGC). Managing successful programmes. The Stationery Office, 2007.

21. Mulenburg, Dr. Jerry, PMP. What Does Complexity Have to Do With It? NASA Project Management Challange, Florida. 2008. http://www.slideshare.net/NASAPMC/geraldmulenburg

22. PMBOK. "Project Management Body of Knowledge (PMBOK® GUIDE)." Project Management Institute. 2001.

23. PRINCE2. Office of Government Commerce (OGC). Managing successful projects with PRINCE2. The Stationery Office, 2009.

24. Sauser, Brian J., Richard R. Reilly, and Aaron J. Shenhar. "Why projects fail? How contingency theory can provide new insights–A comparative analysis of NASA’s Mars Climate Orbiter loss." International Journal of Project Management 27.7 (2009): 665-679.

25. Qureshi, Sheheryar Mohsin, and ChangWook Kang. "Analysing the organizational factors of project complexity using structural equation

modelling." International Journal of Project Management 33.1 (2015): 165-176.

26. Remington, Kaye, and Julien Pollack. Tools for complex projects. Gower Publishing, Ltd., 2007.

27. Remington, Kaye. Leading complex projects. Gower Publishing, Ltd., 2011.

28. Ries, Eric. The lean startup: How today's entrepreneurs use continuous innovation to create radically successful businesses. Crown Books, 2011.

29. Schwaber, Ken, and Jeff Sutherland. "Scrum. The Official Guide." 2010

30. Snowden, David J., and Mary E. Boone. "A leader's framework for decision making."Harvard business review 85.11 (2007): 68.

31. Stacey, Ralph. Strategic management and organisational dynamics, Pitman Publishing, 1996.

32. Svejvig, Per, and Peter Andersen. "Rethinking project management: A structured literature review with a critical look at the brave new world."International Journal of Project Management 33.2 (2015): 278-290.

33. Vidal, Ludovic-Alexandre, Franck Marle, and Jean-Claude Bocquet. "Using a Delphi process and the Analytic Hierarchy Process (AHP) to evaluate the complexity of projects." Expert systems with applications 38.5 (2011)

34. Williams, Terry M. "The need for new paradigms for complex projects." International journal of project management 17.5 (1999): 269-273.

35. Xia, Weidong, and Gwanhoo Lee. "Grasping the complexity of IS development projects." (2004)

36. Zimmerman, B., C. Lindberg, and P. Plsek. "Edgeware: Insights from complexity ideas for health care leaders." Irving, TX: VHA (1998).

dette er en personlig kopi af bogen sendt til dig med...

Documents