Hopp til hovedinnhold

Artikkel / 5 minutter /

Kompleksitet er relativt

«Prosjektet mitt er relativt komplekst» kan du si, og du kan synes litt synd på deg selv, - eller kanskje sier du det fordi du er litt stolt over å skulle hanskes med et komplekst prosjekt. Men hvor komplekst er det da, og hva krever det av deg som prosjektleder?

Illustrasjon av kompelsitet

Jeg har holdt tre kurs for prosjektledere i fellesadministrasjonen ved NTNU, med til sammen drøyt 90 deltakere. Kursene satte fokus på hva en prosjektleder må være oppmerksom på, for å kunne oppnå de effektene i virksomheten som prosjekteier har satt som mål. Disse effektene, eller gevinstene som de også gjerne kalles, vil komme til syne over tid etter at de ansatte i en periode har jobbet på en ny måte, - endret sin jobbadferd. Denne adferdsendringen er nettopp det prosjektet skal få til, gjennom sine leveranser til virksomheten. Leveransene kan være rutineforbedringer, ny IT-funksjonalitet som forenkler arbeidsprosesser, opplæring av ansatte i den nye måten å jobbe på, osv. Det er altså en årsak/virkning-kjede fra prosjektleveranse til adferdsendring og til gevinst, men denne kjeden kan være krevende å kontrollere, og det er først når tiden har gått at du ser klart hva som førte til hva.

Organisasjonen er ikke en forutsigbar maskin

Det kunne vært relativt enkelt å oppnå ønsket gevinst, hadde vi bare visst hvordan virksomheten og de ansatte vil komme til å respondere på prosjektets leveranser. Organisasjonen er imidlertid ikke en forutsigbar maskin. Det kan finnes interessenter med andre oppfatninger om hva som skal til for å oppnå ønsket gevinst. Det kan være ansatte som ikke er motivert for å endre sin måte å jobbe på, og det kan være at prosjektet ikke klarer å overskue virkningene av leveransene på tilgrensende virksomhetsområder eller på markedet.

Kompleksitet er noe prosjektledere må ha et forhold til. En del usikkerheter kan du forutse, eksempelvis om det vil være mulig å skaffe nok finansiering, om det er flere prosjekt samtidig som vil ha innvirkning på de samme ansatte, osv. Dette er forhold du kan undersøke og stille spørsmål om, fordi du vet hva du leter etter. Det er ikke alltid du får klare svar, men du kan ha slike usikkerhetsområder «på radaren» under gjennomføringen av prosjektet. Prosjekt med slike problemstillinger kaller vi her «bare» kompliserte.

Uforutsigbart hva dine tiltak fører til

Komplekst derimot er det når det er usikkerheter du ikke klarer å forutse og dermed etterspørre. Og om du klarer å forutse dem er det ikke sikkert noen kan gi deg svar som reduserer usikkerheten likevel. Hvordan angriper man slike? Du vet ikke hvilken virkning som kan oppstå som resultat av tiltak du skulle ønske å sette i verk. Du vet det først etter at du har prøvd. Angrepsmåten bør da være å prøve ut i så begrenset skala som mulig, for å få kunnskap om årsak-virkning før du iverksetter for fullt.

Å innføre nye digitale verktøy og nye arbeidsmåter i en virksomhet er i utgangspunktet komplekst (slik vi definerer det her, i tråd med Cynefin), nettopp fordi du ikke vet hvordan organisasjonen vil respondere. Da kan det være smart å prøve ut skrittvis, kanskje teste ut på en liten gruppe ansatte eller en avgrenset del av organisasjonen, kanskje lage en prototype som ikke koster all verden, kanskje innføre deler av ny løsning som ikke er virksomhetskritiske, osv.

Utprøving av verktøy for kartlegging av kompleksitet

Den første kursgruppen min fikk prøve ut et kompleksitetskartleggingsverktøy som vår Kristin Wulff har tatt frem som del av sitt nærings-phd-arbeid i samarbeid med flere kolleger (se bloggartikkel). Dette tar utgangspunkt i forskning på systemutviklingsprosjekter og hvor man arbeider i fortrinnsvis autonome team. Vi antok at de fleste kompleksitetsdriverne verktøyet kartlegger var nokså allmenngyldige, men tilbakemeldingene fra kursdeltakerne var at de måtte bruke mye innsats på å tolke driverne inn i sin kontekst som oftest er prosjekter for endring av folks arbeidshverdag.

Til neste kurs utarbeidet jeg en variant av verktøyet, fortsatt i stor grad forskningsbasert, men med kompleksitetsdrivere som var mer direkte rettet inn mot organisasjonsutviklings-arbeid. Tilbakemeldingene fra denne kursgruppen var i langt større grad at dette kunne være nyttig i den type prosjekt de vanligvis gjennomfører.

Kompleksitet er relativt

Denne erfaringen indikerer at «kompleksitet er relativt», også på den måten at det er hensiktsmessig å utarbeide tilpassede sjekklister av kompleksitetsdrivere avhengig av type prosjekt. Altså er det å vurdere kompleksitet også i seg selv en kompleks oppgave, og som vi må prøve ut ulike praksiser for.

Kursdeltakerne var delt inn i grupper som jobbet med et konkret eksempelprosjekt. De fikk et ark hvor de kunne plotte inn i en skala fra 1 til 4 for hver av faktorene. Bildet illustrerer hvordan en gruppe vurderte kompleksiteten i sitt prosjekt, og som vi ser kan det også være morsomt å vurdere kompleksitet.

Illustrasjon av kompleksitet i prosjekter

Vi drøftet på slutten av kurs 2 hva prosjektlederen kan bruke resultatene til. Noen mente at det gir noen viktige fokusområder for prosjektleder å holde øye med. Noen ville prøve tiltak for å redusere kompleksitet, noen ville skille ut deler av problemstillingen som egentlig «bare» er komplisert. Noen ville prøve ut muligheter for å avdekke årsakssammenhenger, knyttet til faktorene med høyest score, for om mulig å bevege prosjektet fra kompleks til komplisert. Noen ville gjøre øvelsen flere ganger i løpet av prosjektet for å se om de har greid å redusere kompleksitet. Noen fant det nyttig å ta med seg de sterkeste kompleksitetsfaktorene inn i risikoanalysen sin også, for å vurdere om disse kunne representere risiko og tilhørende konsekvens. Og noen fant ut at analyse-rekkefølgen av kompleksitetsdriverne kunne ha betydning for utfallet, eksempelvis at de ventet med å vurdere om prosjektet var stort eller lite til etter at de hadde vurdert de øvrige faktorene. Dette fordi gruppens oppfatning av denne faktoren var med å påvirke gruppens vurderinger av øvrige faktorer.

Samme illustrasjon av kompleksitet som i hovedbildet

Her er listen over kompleksitetsdrivere som ble brukt i andre kursgjennomføring. I tillegg til allerede nevnte faktorer om hvordan leveransene kan bli mottatt av organisasjonen, inneholder tabellen faktorer knyttet til prosjektet og rammebetingelser, prosjektteamets karakteristika, teknologi, osv.

Kompleksitetsdrivere i OU prosjekter
Prosjektets størrelseLite - stortProsjektets størrelse og nedslagsfelt i organisasjonen sammenlignet med "normale prosjekt" i organisasjonen. Angår investeringens størrelse, hvor mange enheter er involvert, hvor lang tid det tar, osv.
Regelverk og lovkravFå - mangeI hvor stor grad prosjektet må forholde seg til internt regelverk eller lovkrav. Eksempler: krav om å involvere arbeidstakerorganisasjoner, krav til informasjonssikekrhet/personvern, o.l.
Innvirkning på organisasjonenLiten - storI hvor stor grad prosjektets leveranser vil medføre omfattende omlegging i arbeidsprosess/verdiskaping; f.eks. endrer virksomhetsmodellen for aktuelle område; innovasjon som avløser/konkurrerer med eksisterende modell, påvirker forretningskritiske prosesser, osv.
BrukermaktLav - høyGrad av sjølråderett, eller kultur som er lite mottakelig for ledelse. Eksemplevis om brukere kan pålegges endring eller om det må være frivillig. Ytrer seg i antall omkamper og i endringsmotstand.
Uenige interessenterFå - mangeInteressentene representerer mange og sprikende krav/forventninger, eksempelvis hvis flere instanser deler på finansieringen.
TidspressLav - høyI hvor stor grad det er tidspress på prosjektgjennomføringen, for å måtte gjennomføre på kortere kalendertid enn prosjektplanen normalt skulle tilsi utfra tilgjengelige ressurser og krav til utførelse og resultater.
Avhengigheter utenfor teametFå - mangeAntall avhenggigheter utenfor prosjektteamets kontroll, eksempelvis at beslutninger blir tatt, at mottakere har gjort sin forberedende del for at innføring skal kunne skje, at det skal komme en sentral løsning, el.l.
ProblemområderFå - mangeAntall ulike problemområder prosjektet må håndtere. Det virker inn på antall selvstendige småprosjekt som hver gor seg er krevende og må håndteres samtidig, eller også antall oppgaver som har avhengigheter til hverandre.
Teamets spredning og størrelseLiten - storHvorvidt teamet er fysisk samlet eller spredt og/eller er stort og/eller har mange deltidsmedarbeidere.
Kompetansebredde i teametLiten - storI hvor stor grad teamet må håndtere mange fagområder, mange ulike arbeidsprosesser, organisasjonsenheter eller hierarkinivå.
Teknologi/leverandørKjent - ukjentI hvor stor grad prosjektet skal benytte uprøvd teknologi/ny systemleverandør
Dataflyt/integrasjonerFå - mangeI hvor stor grad løsningen er avhengig av dataflyt som innebærer integrasjoner mot mange andre tjenester/kildesystemer.
Endringer underveis i prosjektløpetFå - mangeHyppighet av endringer som prosjektet må håndtere underveis i arbeidet, eller sannsynlighet for at det vil bli mange endringer.