Kompleksitet - kan du blive i sadlen, når projektet stejler?

Af Mogens Mikkelsen, ledelseskonsulent ved Mannaz

Artiklen sætter kompleksitet i kontekst og giver et par alternativer til den klassiske plandrevne projektledelse, for at skabe værdi i form at kompleksitetshåndtering.

Projekter udvikler sig sjældent til at blive mindre komplekse end først antaget. Samtidig kan kompleksiteten være svært at forudsige.

Så når man rammes af projektkompleksitet, bliver man muligvis overrasket. Hvis man opdager den rettidigt og får tæmmet den, har projektledelsen være særlig værdifuld. Det vil ofte være en usynligt værdi, fordi kompetent kompleksitetshåndtering viser sig ved, at projektet netop ikke stejler.

Det er ofte interessenternes skyld

Det er nødvendigt at få nøgleinteressenters anderkendelse af, at det er blevet et kompliceret projekt, for at få de nødvendige rammer til at lede det. Omvendt kan det være utroligt svært ved at få dem til at acceptere dette, særligt når det er deres egne uenigheder, skiftende forventninger, vage beslutninger og tvetydige formuleringer, der gør projektet komplekst.

Kan kompleksitet defineres?

Mange prøver at gøre projektkompleksitet målbar, men selve begrebet projektkompleksitet er tvetydig og forbundet med stor grad af uenighed – det samme som kompleksiteten er i sig selv. Nogle forfattere peger endda på, at kompleksitet er udefinerlig, men i stedet bedst kan genkendes, når man oplever den. Med andre ord, bør vi nok ikke forvente, at der kommer en entydig definition, der er alment accepteret.

Blandt de gode forsøg kan man fremtrække K-skalaen, der udtrykker projektets sværhedsgrad fra kontrol til kaos, eller fra det simple til det umulige. I figur 1 er også indtegnet et ledelsesmæssigt modsvar på projektets kompleksitet.  Figuren er baseret på ”Leading Complex Projects” (Remington, 2011).

Størrelsen er ikke afgørende

Projektet størrelse har kun lille indflydelse på hvor på skalaen projektet befinder sig. Dog vil komplicerede projekter ofte være store, mens komplekse projekter findes i alle størrelser. 

Det komplicerede opstår, når bliver svært at overskue hele løsningen. Komplicerede projekter kan opdeles i adskilte dele, hvilket komplekse projekter ikke altid kan. Det komplekse opstår, når der ikke længere er en lineær sammenhæng mellem problem og løsning. Endelig kaldes projektet kaotisk, når det er tilfældighederne, der hersker.

Ombygningen af motorvejene er et godt eksempel på projekter, der er komplicerede, men ikke komplekse. Maskiner, materialer og mandskab samt afskærmning, trafik og omkørsler, gør, at der er ufatteligt meget at holde styr på. Det er dog stadig forudsigeligt og muligt at planlægge i meget stor detaljer. Selv bilkørerne kan forudsige med rimelig præcision. Det hele er ganske lineært (metaforisk).  Det er en lige vej fra problem til løsning og det er desuden muligt at lave risikoanalyser, der udtømmer udfaldsrummet for begivenhederne.  I figur 2 er dette den entydige vej fra A til B til venstre.

Til sammenligning er mange IT projekter u-linære. Problem og løsning er ikke uafhængige af hinanden. Brugerønskerne ændrer sig ofte, når de oplever løsningen på deres oprindelige behovsformulering. Mange opdager først, hvad de ikke vil have, når de får, hvad de troede, de havde brug for. I figuren er dette vist nederst som en dynamisk sammenhæng mellem A og B.

Kompleksitetsteori

Ralph Stacy har formuleret en model for generel ledelsesmæssig kompleksitet: Agreement & Certainty Matrix (Complexity and Management, Stacy, 2000). Agreement er graden af enighed blandt berørte interessenter mens Certainty handler om sikkerheden på mål og udkommet af vores aktiviteter. Stacy taler i sin opdeling om generel ledelse, og når vi har med projekter at gøre bør man medtænke hvor kompliceret løsningen er, som en tredje parameter. På denne måder skaber vi også en god sammenhæng mellem teorierne fra hhv Reminton og Stacy. Man kan formulere sammenhængen således: Når løsningen bliver mere kompliceret tåler vi mindre usikkerhed og uenighed i projektet. Se figur 3.

Sikkerhed og enighed

Når der er høj grad af både sikkerhed og enighed kan vi opnå kontrol over projektet.

Problemet er stabilt gennem projektet, og projektledelsen kan derfor sættes ind på at styre de opgaver, som projektet har kastet af sig. Hvis løsningen er kompliceret bygger kontrollen på en høj grad af delegering, som jo er mulig idet projektet kan opdeles i relativt uafhængige delprojekter. I figur 4 er den klassiske plandrevne projektledelse indtegnet ved høj sikkerhed og enighed. Se figur 4.

I figur 4 er der også indtegnet tre mulige reaktioner på projektkompleksitet, som kan supplere – eller måske erstatte – den klassiske plandrevne projektledelse. Disse er den entreprenante, politiske samt agile projektledelse. Hver af dem gennemgås i det følgende.

Den agile projektledelse

Et af de afgørende elementer ved den agile projektledelse er opdelingen i delleverancer, der hver for sig er funktionelle og værdifulde i sig selv. Lidt forenklet kan man sige, at det agile koncept er at opdele projektet i en række sekventielle delprojekter, der hver har en færdig delleverance. Løbende hen gennem projektet vurderes hvilken delleverance, der nu er den mest værdifulde og hvordan den skal være. Denne sekventielle fremgangsmåde reducerer problemet med den dynamiske sammenhæng mellem problem og løsning.

Den agile projektledelse er god til håndtering af kompleksitet der udspringer af usikkerhed. Hvis der er sikkerhed om en kompliceret løsning – som f.eks. motorvejen – er den plandrevne at foretrække. Der kan være komplekse projekter, hvor design fasen løses bedst agilt mens konstruktionsfasen skal være plandrevet.

Den agile projektmodel kan også have svært ved håndtering af stor uenighed. Dette forklares nemmeste med terminologien fra Scrum, selv om Scrum ikke er en projektledelsesmodel som sådan.  Der er kun tre roller i Scrum; Produktejer, Scrum master og Teammedlem. Håndteringen af interessenternes behov ligger hos Produktejeren. Hvis der er meget uenighed kan produktejeren ikke levere hurtige beslutninger og entydige backlog-prioriteringer. Scrums simplificering af roller bliver til en hemsko, hvis man mødes af stor interessent diversifikation, d.v.s. kompleksitet i form af uenighed.  

På attitude niveau hører man desuden agile holdninger som ”Vi skal forhindre at organisationen forstyrrer”.  Ved stor uenighed, er det imidlertid nødvendigt at kunne kanalisere interesser i en langt mere vidt forgrenet og kompleks strukturer med interaktion end den agile metode lægger op til. Det er her den politiske projektledelse kommer ind i billedet.

Politisk projektledelse

”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 stor grad af uenighed, så er man nød til at forholde sig til situationen med de politiske briller på.

Politik handler om relationer og kommunikation. Man kan tale om et politisk håndværk, når man mestre at samle interesserne i en fælles løsning, der så tilstrækkelig magt bag sig, til at bliver realiseret. Det er et håndværk man som projektleder kan være nød til at bruge i visse projekter. Det er samtidig en balancegang; hvis du gør det for meget, kan du blive set som intrigant, og gør du det for lidt, opfattes du måske som naiv.

Hvem taler en politiker med? Alle! Formålet med kommunikationen er at få informationer, høre andres holdninger, gøre sin indflydelse gældende og naturligvis fiske stemmer. Det er kun det sidste punkt, som ikke er relevant for projektledelse. Men mange projektledere begrænser sig selv med følgende tanke: ”Jeg har ikke lov til at snakke på tværs og slet ikke opad i organisationen”. Det er et mental fængsel, der ofte er ubegrundet. Det er naturligvis ikke alt, man må dele med alle, og man skal respektere styregruppens beslutningsret. Men herud over bør man være fri, og huske på at man er ”CEO for en midlertidig organisation” – og ikke kun en ansat i et hierarki, der begrænser kontaktmulighederne. Hvis man alligevel vil have tilladelse, så kan man jo skrive det ind i kommunikationsplanen, som styregruppen så godkender.

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 gennem den magtkoalitionen, det er lykkes at samle omkring projektets formål. Den anden er den indflydelse, som projektet giver interesserene på projektets løsning. Relationer kan både være personbårne eller eksisterer gennem strukturer af høringsgrupper, udvalg, paneler, råd og fokusgrupper.

Vi kan konstruere et lille eksempel, for at illustrere behovet for Politisk projektledelse. En virksomhed søsætter projektet ”Kunden i centrum”. Der skal identificeres og løses en række problemer, som kunderne oplever ved at bruge vores service og produkter. Det er alle naturligvis med på. Problemerne opstår først senere. Hvem har egentlig ret til at fortolke kundens behov? Salgsfolkene ser helt anderledes på kundebehovet end R&D afdelingen gør. En fortolkning lavet et sted bliver ikke nødvendigvis accepteret et andet sted i virksomheden. Uenigheder og det politiske spil er i gang, og vi er slet ikke kommet til løsningerne endnu. Løsningerne vil ændre på eksisterende magtforhold og ressourcetildelinger, og derfor vil de skabe interessekonflikter.  Man sådanne projekter glider ud i sandet fordi man ikke tidligt nok har taget de rigtige briller på og set på de underliggende politiske realiteter og vilkår, som projektet skulle fungere på. 

Entreprenant projektledelse

Afslutningsvist kan peges på en tredje alternativ man kan lade sig inspirere af i din projektledelse: Entrepreneurship. For at få fat om begrebet kan vi se på forskellig bud på definitioner.

 “A person who sets up a business or businesses, taking on financial risks in the hope of profit”. (Oxford Dictionary)“Those who take initiative, accept risk of failure, and have an internal locus of control.”  (Albert Shapero) “Entrepreneurship is the pursuit of opportunity without regard to resources currently controlled.” (Howard Stevenson)

Med udgangspunkt i disse definitioner kan vi tydeliggøre forskellen mellem den klassiske projektledelse og entrepreneuren.

Project Manager

Entrepreneur

Afventer at få et projekt mandat.

Tager initiativ selv.

Styrer efter aflevering af leverancen, der er afstemt med interessenterne.

Styrer efter opnåelse af formålet ud fra en selvvalgt leverance

Laver risiko-analyse og afklare disse med styregruppen, der ejer projektets risici.

Tager selv ansvar for fiasko, og påtager sig selv risici for at skabe forretningen.

Skaffer ressourcer gennem aftaler med styregruppen. Søger kontrol over ressourcerne ved budgetter og forpligtende aftaler med ressource-ejere.

Går i gang uden de nødvendige ressourcer og forventer at tiltrække disse senere ved salgsarbejdet baseret på formålet.

Ser styregruppen som projektet beslutningstager og samarbejdet med styregruppen er essentiel for projektet.

Ser styregruppen som en investor, der skal holdes orienteret, måske mest som et nødvendig onde.

 
Et særkende ved den entreprenante projektledelse basere sit virke på tilgivelse frem for tilladelse. Man tager risici selv frem for at placere dem hos en styregruppe. Det er en risikabel stil, for hvis resultaterne udebliver, så udebliver tilgivelsen ofte også. Omvendt kan det være en nødvendig risiko at tage, hvis man vil skabe ekstraordinære resultater i en organisation med uklare beslutningsstrukturer eller svage beslutningstagere.

Det er ikke enten/eller med en passende kombination

Et projekt er sjældent kun én ting og skifter også ofte karakter hen gennem sin livscyklus.  I stedet for kun er bruge en stil, giver det mere værdi når projektledelsen kan være fleksibel og situationsafhængig. Ved komplekse projektet er det ofte vigtig at tænke at den samlede projektledelse skal være stærk – ikke at det skal være en stærk projektleder. Den samlede projektledelse kan deles af flere og fungere på flere niveauer i og omkring projektet. At blive i sadlen som projektleder, og kunne håndtere kompleksiteten, når den rammer, kræver mange refleksioner og afklarende diskussioner med andre der sidder i samme rolle.

Mogens F. Mikkelsen

Civilingeniør. Partner i Novateam.

Novateam.dk