Komplekst prosjekt, hva nå?

Introduksjon og bakgrunn

Det var en tidlig mai-morgen og vi teamledere hadde fagmøte hos Kantega i Oslo. Linda kom hastende inn 5 minutter for sent på grunn av levering på skolen, og da var Kristin (Wulff) allerede godt i gang med å fortelle om Cynefin-rammeverket (uttales Kineevin – fra walisisk).

Det som er vanskeligst å huske i Cynefin er forskjellen på komplekst og komplisert. Komplekst handler om det som vi ikke kan se klare årsakssammenhenger på før eventuelt i etterkant. Team, marked og andre sammensetninger av folk med selvstendige viljer er komplekse. Det kompliserte handler om det som vi vet hvordan skal gjøres - eller vet at en ekspert kan løse. Her finner du mer forklaring av Cynefin:

Forutsigbare IT-prosjekt - finnes de?​

Linda hadde hørt om Cynefin før, men Kristin hadde en ny vri på dette. Dette er Kristin så god på! Hun hadde laget en modell som tydeliggjorde hvordan man skal redusere risiko hvis produktet som skal utvikles og vedlikeholdes er komplekst (uordnet), eller komplisert (ordnet) (se figuren under). Og fått gode innspill fra Jostein Emmerhoff i SpareBank 1, blant annet begrepet “Bygge - Håpe”.

Linda tenkte at “Hm, dette var interessant”. Det var god stemning og nikking og humring i salen, også fra Linda, men til tross for det begynte hun å gruble litt. Dette er så logisk og bra, men det blir for enkelt, tenkte hun. Men skal jeg si noe? Og hva er det jeg mener selv? Er det bare jeg som kanskje ikke forstår hva vi prøver å oppnå, kanskje det ble sagt noe i introduksjonen og jeg nå ødelegger alt hvis jeg sier noe. Men Linda vet at magefølelsen hennes ofte er god, og at det er bedre å spørre enn å la vær.

Så da kom det, litt tørt, fra Linda:

Kristin tenkte videre på det som hadde blitt sagt i møtet, og søkte etter mer informasjon i sitt forskningsmateriale. Vi fortsatte også diskusjonen i en gruppechat i perioden etter. Ferien kom, og etter sommeren så inviterte Kristin oss til en videre prat. Vi diskuterte hvilke faktorer vi mente var de som bidro aller mest til kompleksitet; vi begynte med en lang liste og endte til sist opp med de faktorene vi nå har i vår modell. Lena så raskt at vi kunne bruke et edderkoppnett for å enkelt visualisere hvor kompleksiteten er størst (eller minst).

Og sånn startet det.

Dette er nyttig fordi ...

Lena er opptatt av å teste ut om denne modellen vil fungere i forskjellige settinger, derfor var det naturlig å invitere til workshops. Her forteller hun fra workshopene:

Etter å ha gjennomført flere workshoper for å teste ut modellen, har vi erfart at deltagerne skjønner modellen veldig fort – og de har lyst til å ta den med tilbake til sin organisasjon eller sitt team og prøve den ut videre. Vi har fått tilbakemelding på at den gir et bra grunnlag for en samtale om kompleksitet. Modellen viser de områdene som øker kompleksiteten mest (slik vi ser det), og gir deg en pekepinn om hvilke områder ditt prosjekt eller din organisasjon bør finne tiltak for. Av og til kan tiltaket også være å ikke gjøre noe, men leve med høy kompleksitet på akkurat det området.

Modellen kan si noe om hva slags kommunikasjon du bør legge opp til ut fra hvor mye kompleksitet det er og på hvilke områder det er mest kompleksitet. Den kan også være en veileder til hvilken metodikk du bør bruke eller til å finne hvor det er størst potensial for innovasjon.

Utsagn som: “Denne tar jeg med meg hjem” og “jeg fant to tiltak” er morsomt å høre for oss som har jobbet fram modellen (se prosessbeskrivelse lenger ned). 

Et godt bevis på at workshop-deltagerne ser nytten er også at det ikke lå igjen ett eneste ark med utskrift av modellen da alle hadde gått etter forrige workshop. Vi tolker det som at alle hadde lyst til å prøve den ut i egen organisasjon. Og vi har allerede hørt fra noen av dere som har gjennomført utprøving i egen organisasjon.

Vi tror at modellen kan være nyttig både i starten av prosjekter og i forbindelse med retrospektiv for å snakke om hvordan kompleksitet blir håndtert og hvordan den endrer seg gjennom prosjektet.

Forklaring av modellen

Camilla er opptatt av å lage gode verktøy for å hjelpe folk til å kjøre bedre prosjekter. Derfor presenterer hun verktøyet: Modellen er bygget opp av 13 områder som vi mener påvirker kompleksiteten i et prosjekt. Noen av disse er knyttet til selve produktet som vi skal skape, resten til prosjektet eller teamet som skal levere.

Produktkompleksitet

For produktkompleksitet er områder som krav til sikkerhet, graden av integrasjoner og type teknologi avgjørende for prosjektets framdrift, men vi har også valgt å ta med de eksterne faktorene markedsdynamikk og grad av brukermakt. Dette fordi mange av løsningene vi lager er avhengig av mottakelsen i markedet. Vi må alltid kjenne til og ha kunnskap om det markedet løsningen skal ut i og på hvilken måte brukernes mottakelse har betydning. Jo større makt brukerne har, jo flere eksperimenter/iterasjoner må vi ta for å sjekke om vi er på riktig vei.

Se f.eks. historien om Spleis:
https://www.slideshare.net/yggdrasilkonferansen/spleis-fra-hypotesetesting-til-folkefinansering-bjrn-kjetil-hellestr-og-hans-magnus-inderberg 

Prosjektkompleksitet

Prosjektkompleksitet handler om rammene og forholdene i det teamet som skal jobbe med produktet. Størrelsen på teamet, hvor godt de kjenner hverandre og hvordan de samhandler. Men vi har også erfart at fysisk plassering er av stor betydning. Vi har gode erfaringer med distribuerte team, men ser også at dette er noe som øker kompleksiteten i gjennomføringen. Det er heller ikke uvanlig av noen av prosjektene våre har mange småprosjekter pågående samtidig. Dette kan være både nødvendig og effektivt, men påvirker også kompleksiteten til prosjektgjennomføringen.
Hyppigheten av endringer i prosjektets omfang, antall interessenter og hvor forskjellige interesser disse har og ikke minst avhengigheter utenfor teamet er også faktorer som vi har erfaring med at øker kompleksiteten - i tillegg til selvfølgelig det tidspresset som er gitt.

Hvert av områdene eller faktorene rangeres på en skala fra 1 til 4 ut fra graden av kompleksitet. Hvert punkt er beskrevet i tabellen under.

Eksempelvis ser vi at for område Teknologi vil en løsning som har mye ukjent teknologi rangeres på nivå 4, men om domenet er kjent for prosjektet vil denne kanskje ha nivå 1.

Ved å rangere alle områdene på denne måten inn i et edderkoppnett vil man få en figur som viser graden av kompleksitet. Jo større figuren blir jo større grad av kompleksitet vil du finne i prosjektet. Du ser også enkelt hvor denne kompleksiteten er størst og hvor den er lavere og på den måten kunne styre hvor man bør fokusere for å ta ned risiko i prosjektet.

Målet med å ta frem disse områdene og modellen er ikke å fjerne kompleksiteten, men snarere en hjelp til å anerkjenne at dette er med på å gjøre prosjektet komplekst og gi en oversikt over hvilke deler av prosjektet det er viktig å fokusere på, nettopp for å ta ned risiko. Se også bloggen om hvordan man jobber i det komplekse.​

Forutsetninger

I arbeidet med modellen så vi noen områder som vi mente var mer eller mindre avgjørende for å kunne gjennomføre et komplekst prosjekt. Vi valgte å sette disse områdene som forutsetninger. Dette handlet om modenhet hos de eller den vi samarbeider med, samt en etablert tillit til måten å jobbe på.

I tillegg satte vi også som forutsetning at teamet innehar den riktige kompetansen til å løse de utfordringene som er kjent ved starten av prosjektet. 

Tilbakemeldinger fra workshopene

I workshopene fikk vi tilbakemeldinger om at det blir mer visuelt når du plotter inn områdene i modellen, og at det gjør det lettere å snakke om.

Noen blir ivrige og vil forfine modellen med vektinger, prioriteringer osv. Til dem har vi sagt: “husk at dette er en oversikt over kompleksitet som vi har tenkt er vanlig i våre prosjekter, dette er ikke en fullstendig oversikt over hva som er komplekst i dine prosjekter – eller i framtidige prosjekter."

Etterhvert som vi får erfaring med bruk vil vi forhåpentligvis se noen mønster over hva som er vanligst i forskjellige typer prosjekter. Det tenker vi kan være veldig nyttig.

Vi fikk også en kommentar fra en klok kunde som sa at han ville nok plukke med i modellen bare de elementer som var komplekse i det aktuelle prosjektet – og dermed alltid få en ballong. Vi tror på at kompleksitet varierer i løpet av prosjektet og at vi derfor skal la de med lav “utgangskompleksitet” stå, men alternativet er å ha en liste og vurdere på ulike tidspunkt om noen av prosjektkompleksitetene har blitt mer eller mindre aktuelle nå.

Filer for nedlasting

Produkt- og prosjektkompleksitet - Modell for kartlegging​

Prosjektkompleksitet - bygg egen​

Den “komplette” listen fra forskningen finner du nederst.

Slik jobbet vi fram modellen

Kristin forsker på hvordan vi skal jobbe i det komplekse, og er glad i modeller som grunnlag for å øke forståelse og vokabular. Derfor forteller hun om hvordan vi jobbet fram modellen:

Trinn 0: prosjektkompleksitetsmodellen til Shenhar & Dvir (NTCP-diamond) ble bearbeidet til Kantega. Aksene: marked, teknologi, tidspress og brukermakt. De tre første er inspirert av S&D, mens brukermakt er inspirert av Teece (1986) sin påpekning av at software-produkter er lette å kopiere - derfor blir brukervennlighet ekstra viktig.

Som Linda beskrev i starten av denne artikkelen påpekte hun modig at det er mye mer enn produktkompleksitet som gjør et prosjekt komplekst. Derfor:

Trinn 1: 4 erfarne prosjektledere/ledere (bloggforfatterne) satte opp en liste over hva som gjør prosjekter komplekse, først hver for seg og så ble den slått sammen. Alt som fikk to eller flere “stemmer” for viktighet ble med videre.

Trinn 2: de samme 4 fikk i hjemmelekse å sjekke ut hva som stemte best for sitt prosjekt. Det viste seg at det aller meste av det vi hadde satt opp gjaldt.

Trinn 3: vi testet ut på Faggruppe Innovasjonsledelse med både eksterne og interne fagfolk og korrigerte.

Trinn 4: vi fant en litteratur-review-artikkel om prosjektkompleksitet og sjekket om a) alt vi hadde kommet fram til stod i forskningsoversikten, og b) at vi hadde dekket store deler av de områdene for prosjektkompleksitet som Vidal & Marle hadde kartlagt. (Se vedlegg).

Trinn 5: vi testet ut på intern fagdag og korrigerte.

Trinn 6: vi presenterte på fagsamling i forskningsprosjektet Autonome team (A-team) og de likte modellen.

Trinn 7: vi presenterte på Kantegadagen og de likte modellen. Vi fikk kommentar fra en av forskerne i A-team om at endring i forretningsmodell kanskje burde være med i modellen.

Trinn 8: denne bloggen

Trinn 9: presentasjon på fagforum for teamledere, både i Oslo og Trondheim.

Trinn 10: "ja, dette er vel og bra, men hvordan skal vi faktisk jobbe annerledes?" spør folk nå. Så da tar vi fatt på å trene på det. Ta kontakt med oss hvis du selv er en av dem som trener på å jobbe i det komplekse og kan dele med oss. Eller hvis du vil lære noe av oss. 

PS: mye klokt i Shenhar & Dvir sin bok, så den anbefaler vi at du både kjøper og leser.

Referanser

Teece, D. J. (1986). Profiting from technological innovation: Implications for integration, collaboration, licensing and public policy. Research policy, 15(6), 285-305.

Shenhar, A. J., & Dvir, D. (2007). Reinventing project management: the diamond approach to successful growth and innovation. Harvard Business Review Press. https://store.hbr.org/product/reinventing-project-management-the-diamond-approach-to-successful-growth-and-innovation/8002?sku=1261KB-KND-ENG​

Litteratur-review vi brukte for å sjekke om vi er innenfor: Ludovic-Alexandre Vidal, Franck Marle. Understanding project complexity: implications on project management. Kybernetes, Emerald, 2008, 10.1108/03684920810884928 . hal-01215364, https://hal.archives-ouvertes.fr/hal-01215364​