Kompleksitet er relativt

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.

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.

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.