Søk
Søk

Komplekst prosjekt, hva nå?

Vi har testet ut et samtaleverktøy for å snakke om kompleksitetene i prosjekter, og erfaringene så langt er så gode at vi vil dele det med alle. I tillegg til Linda og Lena, har Camilla Wadseth og Kristin Wulff vært med i utarbeidelsen av samtaleverktøyet og denne bloggen.

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). 

Cynefin med forklaring

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”.  

Effektivt vs omstendelig

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

Dette er bra, men jeg synes det blir for enkelt. Det er noe som mangler. Det er andre ting enn produktkompleksitet som påvirker hverdagen og som øker kompleksiteten og som igjen påvirker de valg vi må ta for å komme i mål

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. 

   

  Område  Forklaring  Nivå 1 - 4 
Produkt-kompleksitet  Sikkerhetskrav  Komplekse sikkerhetskrav; godkjenning av ekstern part, styrt av regulativa autoriteter, GDPR (anonymisering av data), osv.  Lavt – Høyt 
Antall komponenter/ integrasjoner  Antall komponenter/integrasjoner innfører tekniske avhengigheter som må håndteres, og der det også kan være vanskelig å få avklart om man får det man trenger, til riktig tid.  Få – mange 
Teknologi  Bleeding edge eller kjent og stabil teknologi. Ukjent teknologi kan være: ny teknologi, ny for konsulenten, ukjent kodebase. Ukjent teknologi gir økt sannsynlighet for endringer underveis, og behov for kompetanseheving i prosjektet.  Kjent – Ukjent 
Domene  Ukjent domene kan gi begrepsforvirring, det skaper behov for å sette seg inn i og det finnes en mulighet for at det finnes løsninger som kunne ha vært brukt, men som ikke er kjent pga manglende domenekunnskap.  Kjent – Ukjent 
Markedsdynamikk  Markedsdynamikk peker på hvor stabilt eller ustabilt markedet er. I et etablert og stabilt marked jobber man på en helt annen måte enn i et uetablert og nytt marked.   Kjent – Ukjent 
Brukermakt  I hvilken grad er det vi lager noe som brukeren må bruke vs. om de kan velge å la være og bruke. 1.Intern løsning  2.Intern løsning som erstatter eksisterende løsning 3.Eksternt monopol (for eksempel nettbank) 4.Ekstern konkurranse  Lav – Høy 
Prosjekt-kompleksitet  Hyppighet av endring  Skjer det endringer i prosjektet hyppig eller holder seg scope, teamsammensetning og fokus stabilt?  Få – Mange 
Antall parallelle «småprosjekt»  1 Ett prosjekt 2 To-tre prosjekt 3 Prosjekt i ulike faser 4 Prosjektene har forskjellig kompleksitet og arbeidsmåte  Ett – mange og komplekst 
Teamet  Stort team gir mer koordinering, det er flere som ikke vet alt som skjer.Men det kan også handle om: språk, om man har jobbet sammen før, kultur, forskjellige firma, stabilt vs ustabilt, konflikter.  Lite – Stort 
Fysiske rom  1 Samlokalisering med oppdragsgiver (forretning)  2 Samlokalisering av team uten oppdragsgiver 3 Distribuert team, noe samlokalisering 4 Distribuert team, alle sitter forskjellige steder  Samlokalisert – ulike lokasjoner 
Interessenter  Hvem er interessenten(e)? Er det en type interessenter, eller er det flere typer interessenter? Hvis mange, har alle like mye påvirkningskraft? Har noen av de mer “bestemmenderett”? Har de veldig forskjellige interesser?  Få – Mange 
Avhengigheter utenfor teamet  Ingen eller opptil mange avhengigheter til andre utenfor teamet  Få- Mange 
Tidspress  1 Normal fart 2 Konkurranse 3 Fastsatt sluttdato ("olympisk dato") 4 Krisehåndtering  Lav – Høy 

 

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.   

 Prosjekt- og produktkompleksitet

Målet med å ta frem disse områdene og modellen er ikke å fjerne kompleksitetenmen 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."

Det er veldig viktig at du ikke begynner å late som dette er den ene, sanne, modellen over prosjektkompleksitet. Og det tror vi at du risikerer hvis du lager modellen finere/mer grundig. Dette er en oversikt over det vi tror er noe av det vanligste, men for at den skal være nyttig for deg må du vurdere om det er andre elementer som bidrar til kompleksitet hos deg hver gang du starter et prosjekt. 

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 

 Prosjektkompleksitet

Litt om forfatterene

Linda Falk

Linda Falk

Jeg er prosjektleder/teamleder/team coach. Jeg synes at det er helt rått når vi får ting til å skje i fellesskap; når teamet samarbeider og finner gode løsninger sammen, når vi trives med og har tillit til hverandre i det daglige, når det er høyt og det er lavt men vi alltid står støtt sammen. Dette jobber jeg med å få til, hver dag.
Lena-Romundstad

Lena Romundstad

Jeg jobber både som prosjektleder og testleder. Jeg er glad i å rydde - få til en viss orden slik at det blir enklere for alle å bidra i prosjektet, og slik at vi lager løsninger med høy kvalitet.
comments powered by Disqus