Magma topp logo Til forsiden Econa

Einar Elvenes er førsteamanuensis ved Institutt for industriell økonomi og teknologiledelse ved NTNU. Hans fagfelt er organisasjonsteori og prosjektledelse. Elvenes er utdannet siv. ing. fra NTH og senere dr.ing. ved NTH.

Kompleksitet i prosjekter - forslag til tiltak basert på systemteori

Dagens prosjekter oppleves som komplekse. Det er behov for å utvikle en bedre forståelse av hvorfor kompleksitet oppstår, samt hvordan den kan håndteres. Denne artikkelen tar utgangspunkt i systemteoriens grunnleggende byggeklosser; elementer, relasjoner, egenskaper og systemgrense. Disse elementene anvendes for å utvikle en mer omfattende definisjon av kompleksitet samt fremme eksempler på anbefalinger for hvordan kompleksiteten kan reduseres til et håndterbart nivå. Videre anbefales bruken av alternative teoretiske perspektiver for å skape et mer mangfoldig og nyansert syn på kompleksitet.

Innledning

Enhver teori innebærer en avgrensning, forenkling og til dels forvrengning av virkeligheten1, gjerne knyttet til bestemte fagfelt. Naturen, og dermed problemet, kjenner ikke teori og fag. Inndelingen ble skapt av mennesker ut fra hva som var hensiktsmessig der og da, uten kunnskap om det problemet vi skal løse her og nå. Bruker vi teorien som grunnlag for å utvikle en løsning, så er løsningen tilpasset teoriens oppfatning av virkeligheten.

«Triangulerings-hypotesten» ble etablert som en motvekt mot dette. Skal man anvende teori for å finne fram til praktiske løsninger, bør man anvende to eller flere ulike teorier. Disse teoriene bør bygge på så forskjellige antakelser og forutsetninger at de ikke er logisk konsistente i forhold til hverandre. For eksempel bør en tilrettelegging av en fusjon mellom to selskaper i det minste ta hensyn til teknisk-økonomiske problemstillinger og politiske problemstillinger vedrørende involverte interessenter.

Aksepterer vi denne hypotesen, aksepterer vi samtidig at ingen teori, metode eller aktør har monopol på sannhet, enten det er snakk om problemstilling, faglig tilnærming, prosess eller fortolkning av resultat. Først når vi kombinerer ulike teoretiske og praktiske tilnærminger, får vi et grunnlag som er mangfoldig nok til å fange opp de vesentligste sider ved problemstilling og kontekst. Dette er spesielt relevant for komplekse og dynamiske problemstillinger som prosjekter.

Mange forfattere har opp gjennom tidene forsøkt å gruppere teorier og metodologier etter grunnleggende oppfatninger, antakelser og/eller forutsetninger. Blant de mer kjente måtene å klassifisere teorier på er:

  • Metaforer (Morgan 86)
  • Paradigmer (Kuhn 70)
  • Perspektiver (Bolman et al. 84)
  • Sosiologiske paradigmer (Burrell et al. 79)
  • Ways of Thinking (Mitroff et al. 93)

Systemer og systemtekning2 lanseres av flere om en egen gruppe av teorier og metodologier. Denne artikkelen tar utgangspunkt i generell systemteori og anvender den til å forstå, forklare, forutsi og handle i forhold til kompleksitet i prosjekter. Formålet er ikke å lansere tanker og konsepter som skal erstatte leserens egne, men skape grobunn for ettertanke rundt og videreutvikling av det man allerede tenker og gjør innen dette området.

Systemets byggeklosser

Den generelle systemteorien bygger på tanken om at ting henger i hop og påvirker hverandre. Til sammen danner de en helhet. Systemet vil ha egenskaper som er unike for helheten, det vil si at helhetens egenskaper ikke er det samme som summen av egenskapene for delene (Checkland 81). For eksempel kan vi ikke konstruere en levende hund ut fra kunnskapen om grunnstoffene en hund består av. Dette står i skarp kontrast til den tradisjonelle analytiske tilnærmingen hvor vi nettopp skaffer oss en forståelse av helheten gjennom å analysere delene (reduksjonisme og atomisme).

Et system kan modelleres ut fra et begrenset antall byggesteiner:

  • elementer (objekter, deler, prosesser, konsepter, påstander osv.)
  • relasjoner (sammenkoplinger og transaksjoner mellom objekter)
  • egenskaper (attributter knyttet til objekter og relasjoner)
  • systemgrense (en skillelinje mellom det som inngår i et system og det som utgjør systemets omgivelser) 

I denne artikkelen anvendes disse byggesteinene til å diskutere kompleksitet i prosjekter, samt hvordan denne kan håndteres.

Kompleksitet

Kompleksitet er et mangfoldig konsept som kan studeres fra mange ulike utgangspunkt, for eksempel fysiske, konseptuelle, emosjonelle og kulturelle. Det kan være så som så med samsvaret mellom teoretisk beregnet kompleksitet, opplevd kompleksitet og evnen til å mestre denne kompleksiteten. Denne artikkelen retter søkelyset på hvordan kompleksitet kan forstås som et rasjonelt og målbart fenomen.

Den enkleste definisjonen av kompleksitet sier at den er en funksjon av antall elementer og relasjoner i et system. Skal man redusere kompleksiteten, må man enten redusere antall objekter, antall relasjoner eller begge deler. La oss se på hva dette innebærer for kompleksiteten i et prosjekt.

Elementer og kompleksitet

Elementene utgjør, som nevnt tidligere, systemets bestanddeler eller objekter. Det kan være fysiske objekter, symbolske objekter, informasjonselementer, funksjoner, prosesser og så videre. For at de skal være en del av et system, må de ha en kopling til ett eller flere andre elementer i systemet.

Anbefaling 1: Hvis et element ikke har logiske eller påviselige relasjoner med andre elementer i systemet, er det ikke en del av systemet og kan derfor fjernes.

Når elementer står i et avhengighetsforhold til hverandre, kan de betraktes som ledd i en eller flere prosesser. En prosess omformer noe til noe annet (Schoderbek et al. 90). Det betyr at de resultatene som produseres av ett element, fungerer som input eller rammebetingelser for ett eller flere andre elementer.

Anbefaling 2: I et system skal elementets output (resultater) bidra til best mulig resultat for prosessen som helhet. Hvis ikke, vil nødvendige justeringer og tilpasninger (nye objekter og relasjoner) gi en dramatisk økning av kompleksiteten.

Kompleksiteten avgjøres ikke av det absolutte antall elementer, men av antall forskjelligartede elementer. I en tidlig fase av prosjektet er det lett både å kreve og tilby unike elementer som har lite eller ingen positiv innvirkning på sluttresultatet.

Anbefaling 3. Kompleksitet reduseres gjennom standardisering. Unike elementer og løsninger brukes kun der disse har en påviselig positiv effekt på sluttresultatet som overgår ulempene knyttet til ekstra utvikling og koordinering for systemet som helhet.

Relasjoner og kompleksitet

Relasjoner er bindinger som skaper koplinger mellom elementene i et system. Vi kan skille mellom tre hovedtyper relasjoner:

  • Symbiotiske, det vil si relasjoner som er absolutt nødvendige for at systemet skal fungere.
  • Synergetiske, det vil si relasjoner som bidrar til å øke systemets prestasjonsevne.
  • Redundante, det vil si relasjoner som dupliserer en eller flere andre relasjoner (Schoderbek et al. 90).

De symbiotiske relasjonene er kritiske for systemet. Systemet fungerer ikke hvis kun en av dem svikter eller mangler. Det hjelper ikke hvor gode elektriske hjelpemidler du har hvis strømforsyningen mangler, svikter eller er av feil type.

Anbefaling 4: Bruk tilstrekkelig tid og ressurser til å identifisere og definere samtlige av systemets symbiotiske relasjoner, tekniske så vel som administrative. Sørg for at prosjektets deltakere forstår disse relasjonene samt får tilgang til nødvendige virkemidler for å ivareta dem.

Ulike personer og aktører kan ha forskjellige oppfatninger av hva som er symbiotiske relasjoner. Dette gjelder spesielt for aktører som ikke legger et systemperspektiv til grunn.

Anbefaling 5: Symbiotiske relasjoner skal begrunnes ut fra en systemanalyse. Relasjoner som feilaktig bedømmes som symbiotiske, øker prosjektets kompleksitet da de må ivaretas teknisk så vel som administrativt.

Symbiotiske relasjoner kan være enveis eller gjensidige (uni- eller bipolare). Enveisrelasjoner (også kalt parasittiske) medfører at ett element er avhengig av et annet, men ikke omvendt. Gjensidige relasjoner medfører at elementene er avhengige av hverandre. For eksempel vil en kontrakt etablere en gjensidig relasjon mellom kunde og leverandør. Begge blir avhengige av hverandre, og handlinger som skader den ene, vil som regel også skade den andre.

Anbefaling 6: Vær forsiktig med å anta at en symbiotisk relasjon er ensidig. Er antakelsen feil, undervurderer man mulige konsekvenser av egne handlinger. Dette gjelder spesielt i forholdet mellom interessenter hvor tiltak kan utløse til dels meget uønskede mottiltak.

Synergi, som egentlig betyr kombinert handling, oppstår når to eller flere elementer samvirker på en slik måte at de skaper et bedre resultat enn summen av individuelle bidrag. Katalysatorer i kjemiske prosesser er et godt eksempel i så måte.

Synergi er et sårbart fenomen som er avhengig av de riktige rammebetingelsene og få eksterne forstyrrelser. Dette gjelder også for sosiale systemer som for eksempel prosjektteamet. En ny prosedyre eller utskiftingen av ett medlem kan være nok til at de synergiske relasjonene bryter sammen og prestasjonsnivået synker dramatisk. Slike sammenbrudd skader relasjonene mellom elementene og øker kompleksiteten inntil nye eller endrede relasjoner er etablert.

Anbefaling 7: Så lenge synergiske prosesser er i samsvar med prosjektets mål og rammebetingelser, bør de beskyttes mot eksterne forstyrrelser og inngrep. Selv velmente inngrep kan ødelegge synergiske relasjoner og øke kompleksiteten.

Under prosjektets planlegging forsøker man som regel å redusere antall redundante relasjoner til et minimum. De medfører økt kompleksitet og økte kostnader. Forskjeller i relasjonenes oppbygning, tilknytning og virkemåte kan skape økt usikkerhet, for eksempel ved at flere personer opptrer som kundens representant overfor prosjektet. De kan også skape en falsk følelse av sikkerhet og kvalitet. Et eksempel i så måte er at seks personer kontrollerer kvaliteten på en tegning produsert av en annen person. Alle har mer enn nok å gjøre og antar at de andre gjør jobben. Denne pulveriseringen medfører at ingen kontrollerer tegningen, eller at de foretar en overflatisk kontroll.

Redundans kan rettferdiggjøres ut fra sikkerhets- og pålitelighetsargumenter. Hvis den ene relasjonen svikter, kan den andre overta. Dette gjelder like mye for administrative som tekniske delsystemer. NASA fikk svi for dette da viktig sikkerhetsrelatert informasjon om Challenger-fergen ble blokkert fordi kanalen ikke ønsket å viderebringe denne informasjonen. I dette tilfellet ville redundante relasjoner bidratt til å forebygge ulykken.

Anbefaling 8: Analyser prosjektets relasjoner for å avdekke overlapping eller duplisering. Fjern de som ikke kan rettferdiggjøres ut fra et viktighets-, sikkerhets- eller pålitelighetsargument.

Ekte redundans forutsetter at samme objekt, for eksempel informasjonselement, formidles gjennom kanaler med ulike egenskaper og virkemåter. Uekte redundans tillater at man dupliserer to kanaler med samme egenskaper og virkemåte. Uekte redundans gir en falsk trygghetsfølelse da det som fikk den første relasjonen til å svikte, også kan få den redundante til å bryte sammen.

Det er lett å anta at man har ekte redundans fordi man har separate relasjoner, men ting eller hendelser i situasjon eller omgivelser kan øke sårbarheten. For eksempel sviktet det hydrauliske styringssystemet i et DC-10 fly, og flyet krasjlandet (systemet skaper en relasjon mellom piloten og kontrollflater på flyet som høyde- og sideror, flaps, slats, luftbremser og så videre). Dette skulle ikke skje siden flyet var utstyrt med tre fullstendig separate hydrauliske systemer. Problemet var at de hydrauliske rørene som gikk til haleroret, lå tett ved siden av hverandre. Da noen av turbinbladene i motor tre (DC-10 har tre motorer hvorav nummer tre sitter i haleseksjonen) løsnet, var kraften så stor at ett av bladene skar gjennom pansringen rundt motoren og kuttet hydraulikkrørene til samtlige styringssystemer.

Anbefaling 9: Hvis redundans er nødvendig, velg om mulig ekte redundans. Sjekk nøye at det ikke foreligger forhold som kan oppheve redundansen, selv når dette bidrar til å øke kompleksiteten.

Det kan eksistere mange relasjoner mellom to elementer i et system. For eksempel kan to mennesker i et prosjekt være knyttet sammen gjennom faglige, administrative, vennskapelige og andre relasjoner. For prosjektet som helhet, kan summen av relasjoner nærme seg det uendelige. Ifølge systemteorien er styringen av relasjoner vel så viktig som styringen av elementene (Narayanan et al. 93). Derfor er det et sterkt ønske om å fjerne unødvendige relasjoner.

Anbefaling 11: Vurder nøye i hvilken grad en formell relasjon er nødvendig eller ikke. For eksempel hvem må informeres om hva, hvem skal kontrollere hvem, hva og når, hvem skal fatte beslutninger om hva, hvem skal koordineres i forhold til hvem og hva og så videre.

Prosjekter defineres gjerne som unike. De skal produsere løsninger som ikke er produsert før, og de skal gjøre det gjennom arbeidsprosesser som skiller seg fra dem som anvendes i basisorganisasjonen. Imidlertid er det fullt ut mulig å skape så vel nye løsninger som nye prosesser gjennom å kombinere kjente elementer på nye måter.

Anbefaling 12: Det er ingen naturlov som sier at unike løsninger krever unike elementer og relasjoner. Det er fullt mulig å standardisere betydelige deler av prosjektets relasjoner, både internt og eksternt. En slik standardisering bidrar til å redusere kompleksiteten, forhåpentligvis til et håndterbart nivå.

Relasjonenes antall, form og innhold avhenger av elementenes antall, form og innhold. Det finnes mange prinsipper og framgangsmåter for å definere systemets elementer. Det samme gjelder for nedbrytingen av et prosjekt i delprosjekter og aktiviteter. Hvordan dette gjøres, vil ha en betydelig innvirkning på relasjonene innad i prosjektet og mellom prosjektet og dets omgivelser.

Anbefaling 13: Vurder ulike prinsipper for oppdeling av prosjektet. Velg, om mulig, det prinsippet som reduserer antall nødvendige relasjoner mellom elementene. Ikke bland prinsipper på samme nivå i nedbrytingen da dette senere skaper store koordineringsmessige utfordringer.

Når to eller flere elementer står i et gjensidig avhengighetsforhold til hverandre, oppstår det automatisk et koordineringsbehov mellom dem. Jo mer komplekse disse avhengighetene er, jo mer kompleks blir koordineringen. Ifølge dekoplingsprinsippet skal disse elementene ligge under samme administrative enhet (Stinchcombe et al. 85). Skal elementene administreres av forskjellige administrative enheter, bør de være tilnærmet uavhengige av hverandre (dekoplet).

Anbefaling 14: Sjekk i hvilken grad elementer er rimelig uavhengige av hverandre før de fordeles på ulike administrative enheter, eksempevisl settes bort til underleverandører. Redefiner, om nødvendig, elementene slik at de tilfredsstiller kravet om dekopling. Hvis dette kravet ikke kan tilfredsstilles, bør elementene administreres under samme enhet, eventuelt må det etableres et egnet apparat for koordinering mellom dem.

Diskusjonen ovenfor tok utgangspunkt i den enkleste definisjonen av kompleksitet, nemlig at den er en funksjon av antall elementer og relasjoner i et system. Det viste seg rimelig fort at den ikke var tilstrekkelig. Det var sider ved kompleksiteten som ikke lot seg fange opp og beskrive av en slik enkel modell. Hva er for eksempel mest komplekst, et mekanisk urverk eller en samtale mellom to personer? Ifølge den tradisjonelle definisjonen burde urverket være mest komplekst da det består av hundrevis av deler som alle er relatert til hverandre. Når man så forsøkte å modellere de to systemene og forutsi deres resultat, kom man fram til det motsatte resultatet. Et urverk kan i prinsippet modellere gjennom ei fjær, et svinghjul og en regulator, og denne modellen kan meget presist forutsi urverkets atferd år fram i tid. En samtale, derimot, var det umulig å modellere slik at man kunne forutsi eksakt hvilken retning den ville ta, og hva som ville bli konklusjonen. Dertil var det altfor mange variable (frihetsgrader) som man ikke hadde kontroll over, deriblant menneskets frie vilje og kreativitet.

Man trengte en mer omfattende definisjon av kompleksitet. Etter hvert innså man at det var umulig å finne fram til et generelt måleinstrument som eksakt kunne måle kompleksitet. Imidlertid kunne man identifisere hvilke elementer som skaper kompleksitet og forsøke å påvirke dem i ønsket retning.

Hvis man legger et systemteoretisk perspektiv til grunn, vil systemets byggesteiner også være de faktorene som skaper kompleksitet. Ut fra en slik betraktning kan kompleksitet defineres som følgende funksjon:

K = f (elementer, relasjoner, egenskaper, systemgrense, organisering)

 

Kompleksitet og egenskaper

Både elementer og relasjoner har egenskaper. En egenskap uttrykker noe som er kjent, observert eller introdusert i elementet eller relasjonen. En maskin kan for eksempel ha egenskaper som typenummer, kapasitet, spenning, toleranser og forventet livslengde.

Vi kan skille mellom ulike egenskaper (Schoderbek et al. 90):

  • Definerende, det vil si egenskapene som beskriver systemets identitet og natur. Mangler en eller flere av disse egenskapene, så blir ikke systemet gjenkjent eller akseptert. Taxiene i selskapet Yellow Cabs i New York gjenkjennes ut fra en egenskap, nemlig at de alle har samme farge. Taxier i Norge må gjenkjennes ut fra andre egenskaper.
  • Ledsagende, det vil si egenskaper som ikke er nødvendige for å gjenkjenne systemet, men som kan medføre ekstra nytte eller funksjonalitet. Det er ikke noe krav om at en taxi skal ha luftkondisjonering, men denne egenskapen kan øke velværet for så vel sjåfør som passasjer.

De definerende egenskapene må ivaretas skal løsningen oppfattes som en løsning. Men hva er de definerende egenskapene, og hvem skal i så fall definere dem? Ulike aktører kan ha forskjellige oppfatninger av hva som er definerende egenskaper, og det kan være sterke egeninteresser knyttet til det å få inn eller fjerne bestemte definerende egenskaper. Hvilke egenskaper kjennetegner for eksempel en ekte bunad? De fleste vil vel tenke på slike ting som lokal historisk forankring, stoff, snitt, broderier og så videre. For noen år siden oppstod det en disputt som gikk på om bunader sydd i utlandet kunne klassifiseres som ekte bunader. Sterke norske interessenter ønsket å innføre en ny egenskap, nemlig at den også måtte være sydd i Norge, selv i de tilfeller hvor arbeidet ellers oppfylte alle eksisterende krav og standarder.

Anbefaling 15: Gå i dialog med prosjektets mest sentrale interessenter for å avdekke og skape enighet om hva som skal være prosessens og resultatets definerende egenskaper. Dette gjelder også de egenskapene som ellers oppfattes som selvsagte. Det finnes en rekke systemorienterte metodologier man kan anvende, for eksempel SATS, Interactive Planning og Soft Systems Methodology (Jackson 03).

Definerende egenskaper må ha et klart og konkret innhold. Slagordpregede formuleringer som «Godt Norsk» eller «Topp kvalitet» er uegnede så lenge de ikke fylles med et konkret og allment forstått innhold.

Anbefaling 16: Definerende egenskaper må være konkrete, ha et felles forstått meningsinnhold og dokumenteres. Ellers åpnes det for ulike fortolkninger, noe som kan gi en betydelig økning i kompleksiteten for prosjektet, for eksempel ved at det skal tilfredsstille to ulike fortolkninger.

Anbefaling 17: Skill klart mellom definerende og ledsagende egenskaper. Definerende egenskaper må ivaretas mens ledsagende er et forhandlingsspørsmål. Husk imidlertid at jo flere ledsagende egenskaper som aksepteres, jo mer komplekst blir prosjektets gjennomføring og resultat.

Anbefaling 18: Vær bevisst på hvilke ledsagende egenskaper du er villig til å tilby i en salgssituasjon og hvilke konsekvenser de vil få for gjennomføringen av prosjektet. Slike tilbud skaper forventninger hos kunden, selv når vedkommende egentlig er tilfreds med å få ivaretatt de definerende egenskapene.

Oppfatningen av hva som er definerende og ledsagende egenskaper, endres over tid. Da man lanserte et nytt taxiselskap i Norge, var en av de definerende egenskapene at alle deres taxier skulle være gule. Dette kravet gjelder ikke lenger. Hvilke egenskaper må et distrikt ha for at det skal oppleves som attraktivt for bedrifter og personer som ønsker å etablere seg? I løpet av få år har tilgang til bredbånd blitt en slik egenskap.

Anbefaling 19: Etabler et apparat som kan identifisere og definere endringer blant interessentene med hensyn til definerende og ledsagende egenskaper. Endringer skal formelt sanksjoneres før de får konsekvenser for prosjektets gjennomføring og resultat. Endringer som kommer inn «bakveien», gir som regel en høyere kompleksitet for prosjektet enn endringer som formelt vurderes og godkjennes.

Enkelte egenskaper blir definerende, ikke fordi de er teknisk eller økonomisk nødvendige, men fordi de er politisk eller symbolsks viktige. Man kan ikke bygge gasskraftverk i Norge fordi de har egenskapen forurensende, men det er ok å bygge det samme kraftverket i Danmark eller Tyskland for så å importere kraften. Det er etisk forkastelig å forske på stamceller, men det er greit å motta en behandling basert på stamceller.

Anbefaling 20: Vær oppmerksom på politiske, symbolske og moralske vurderinger av et prosjekts egenskaper. De kan få store konsekvenser for prosjektets kompleksitet, ikke minst hvis de påvirker de definerende egenskapene. På den annen side kan en fornuftig tilpasning til disse åpne opp for nye muligheter og fjerne en rekke hindringer for prosjektets gjennomføring.

En stadig tilbakevendende årsak til problemer i prosjekter er at objekter og relasjoner har ulike eller inkompatible egenskaper. Prøv bare å sende et hastedokument via e-post til noen som leser e-posten en gang i måneden, bruker en annen tekstbehandler enn deg og har installert et SPAM-filter som mener at e-postadressen din ligner mistenkelig på adressen til en kjent spammer. Uforenlige egenskaper kan også medføre katastrofale konsekvenser. For eksempel bommet NASA regelrett på Mars da deler av sondens navigasjonsprogram var skrevet i det metriske system (SI-systemet), mens andre deler var skrevet i Imperial (yards i stedet for meter). Ingen hadde definert hvilken standard som skulle følges, fordi ingen trodde dette skulle bli noe problem.

I andre tilfeller bør elementer og relasjoner ha uforenlige egenskaper. Eksemplet her er kollisjonen mellom to passasjerfly hvor den ene piloten oppfattet nei som ja (begrepene «negative» og «affirmative» er fonetisk så like at de i en stresset og støyfylt situasjon kan misforstås). Man har senere endret på begrepene, men gammel vane og standarder hindret bruken av «no» og «yes» som er så fonetisk forskjellige at de vanskelig kan sammenblandes.

Anbefaling 21: Det er ikke nok at egenskapene er logisk konsistente innen et element eller en relasjon. De må også være logisk konsistente på tvers av disse hvis systemet som helhet, skal fungere som forutsatt. Det innebærer at man både må definere når egenskapene skal være forenlige, og når de skal være uforenlige.

Kompleksitet og systemgrense

Et system forutsetter en avgrensning i forhold til omgivelsene. Vi trenger å definere hva som er en del av systemet, og hva som er en del av omgivelsene. Denne grensen må defineres, og spørsmålet er hvor den skal gå. Noen definisjoner vektlegger at omgivelsene består av elementer og relasjoner med liten eller ingen tilknytning til systemets elementer og relasjoner, mens andre vektlegger at omgivelsene består av elementer og relasjoner som systemet ikke har noen direkte styring over.

Ta et prosjekt. Skal kunde og leverandører oppfattes som en del av prosjektet, eller som en del av omgivelsene, eventuelt når går de fra å være en del av omgivelsene til å bli en del av prosjektet? Her kan det være mange ulike oppfatninger. Økonomifunksjonene kan oppfatte seg som atskilte, mens produktutviklerne, som arbeider i et integrert team, oppfatter seg som en del av det samme systemet.

Anbefaling 22: Prosjektet må definere en systemgrense overfor omgivelsene. Dette er ikke en fysisk grense, men en grense som definerer prosjektets rolle og identitet. Mangelfull eller uklar definering øker prosjektets kompleksitet.

Systemgrensens plassering påvirker tilnærming til problemstilling og løsning. Anta at du skal lede et prosjekt som skal studere årsakene til hjerteinfarkt. Hvordan avgrenser du prosjektet? Skal du studere hjertemuskelen, skal du inkludere det kardiovaskulære systemet, skal du ta med andre kroppslige prosesser som påvirker hjertet, som åndedrett og fordøyelse, skal du ta hensyn til forhold utenfor kroppen som kan ha innflytelse, blant annet livsstil, skal du betrakte individet som et element i et sosialt system, eller hva? Avhengig av hvor du setter systemgrensen, vil ulike elementer og relasjoner påvirke hjertemuskelen, og du vil sannsynligvis finne fram til forskjellige forklaringer på hjerteinfarkt, samt hvordan det kan forebygges.

Anbefaling 23: Det finnes ingen «riktig» definisjon av systemgrense som er riktig for alle oppgaver og situasjoner. Grensen plasseres ut fra hva som er hensiktsmessig i forhold til oppgave og rammebetingelser.

Plasseringen av systemgrensen vil få store konsekvenser for prosjektets kompleksitet. For vide systemgrenser bringer inn unødvendig kompleksitet mens for trange grenser går ut over kvaliteten på prosess og resultat. Spesielt i tidlige faser er det lett å definere for vide grenser.

Anbefaling 24: Prøv å definere hva systemet og løsningen ikke skal inneholde, ikke skal gjøre og ikke skal ta hensyn til.

Prosjekter er åpne systemer med relasjoner til omgivelsene. Gjennom disse relasjonene flyter informasjon, ressurser, påvirkninger og så videre. På den annen side verken kan eller bør prosjektet være et fullstendig åpent system. Ikke bare bryter dette mot definisjonen av et system, men prosjektet trenger også til en viss grad å beskytte sine interne prosesser mot eksterne påvirkninger.

Anbefaling 25: Definer og dokumenter, sammen med interessentene, hvilke relasjoner som skal krysse systemgrensen samt hva som skal flyte gjennom disse relasjonene. Dette kan spare deg for mye unødvendig kompleksitet i en senere fase.

Prosjektet kan ikke styre sine omgivelser. Det betyr imidlertid ikke at prosjektet vilje- og betingelsesløst tilpasser seg alle mulig endringssignaler fra omgivelsene. Prosjektet vil forsøke å beskytte seg mot uønskede eller irrelevante endringssignaler, eventuelt yte motstand mot slike signaler.

Anbefaling 26: Prosjektet bør etablere, i samråd med sine interessenter, organer og prosedyrer for håndtering av eksterne og interne endringssignaler. Disse skal sikre en entydig håndtering av slike signaler som også aksepteres av interessentene.

Prosjektet, som et målsøkende system, vil forsøke å påvirke omgivelsene slik at de legger forholdene til rette for prosjektets gjennomføring og overføring av resultatet. Kompleksiteten reduseres hvis prosjektet lykkes med dette.

Anbefaling 28: Prosjektet bør sette av tid og kapasitet til aktiv påvirkning av omgivelsene. I det minste må prosjektleder være i stand til å fungere som brobygger (boundary spanner) mellom prosjektet og dets omgivelser.

Kompleksitet og organisering

Organisering innebærer at det skapes ekstra eller fjernes relasjoner mellom elementene i et system slik at det dannes et mønster av samvariasjon mellom delene. Organiseringen skjer på mange plan, både teknisk, administrativt og mellommenneskelig.

La oss vende tilbake til eksemplet med klokken. Gjennom den tekniske løsningen organiseres relasjonene mellom delene. Klokken kalles et tett koplet system fordi delene er fratatt mulighetene til individuell atferd. Beveger en del seg, så må de andre reagere som foreskrevet, ellers slutter klokken å fungere.

Anbefaling 29: Hvis man ønsker å redusere kompleksiteten til et system, organiserer man tette koplinger mellom elementene.

Legg merke til at mange teknikker innen teknisk og administrativ planlegging forsøker å redusere systemets frihetsgrader så langt som mulig, det vil si skape tett koplede systemer. For eksempel vil klassisk optimalisering fjerne buffere og andre muligheter til at elementene kan opptre annerledes enn planlagt. I sin ytterste konsekvens vil tidsmessig optimalisering av et nettverk medføre at alle eller flesteparten av aktivitetene ligger på kritisk sti. Hvorfor driver vi ikke optimaliseringen like langt i praksis? Planer vil alltid være beheftet med antakelser, feil og mangler. Tett koplede systemer er svært sårbare overfor feil og endringer. Ta eksemplet med klokken. Det er nok at det brekker en tann på ett tannhjul, og klokken stopper. Den har ikke innebygd redundans, den har ikke muligheten for å legge om de interne prosessene og så videre.

Anbefaling 30: Vær oppmerksom på at tett koplede systemer er sårbare for feil og endringer. Inntreffer slike avvik fra det forventede, øker kompleksiteten for systemet som helhet. Er man riktig uheldig, kan tiltakene som skulle redusere kompleksiteten, gi den motsatte effekt.

Hvis man forventer endringer i systemet, blir robusthet en viktig designparameter. Robusthet går ikke bare på systemets evne til å motstå behovet for endringer, men også på å begrense de uheldige konsekvensene av endringer. Et organisatorisk tiltak i så måte er modularisering av systemer og standardisering av grensesnitt. La oss anta at du skal bygge en ny enebolig. Du setter bort grunnarbeider, grunnmur og installasjoner i kjeller til en entreprenør, mens selve huset med nødvendige installasjoner skal leveres av en annen entreprenør. For å redusere kompleksiteten i prosjektet, og dermed også behovet for løpende koordinering, velger du å betrakte kjeller og hus som to moduler. Du standardiserer grensesnittene mellom de to ved å definere kontaktflatene mellom hus og grunnmur, samt hvor tekniske installasjoner skal føres fra den ene til den andre. Så lenge man holder seg til dette standardiserte grensesnittet mellom modulene, kan man gjøre endringer i den ene uten at det får konsekvenser for den andre. Dette reduserer prosjektets kompleksitet og reduserer koordineringsbehovet.

Anbefaling 31: Vurder i hvilken grad modularisering kan redusere prosjektets kompleksitet. Hvis dette er mulig, hvordan kan man modifisere elementer og relasjoner slik at modulariseringen blir mest mulig effektiv?

Avsluttende kommentarer

Hensikten med denne artikkelen var å demonstrere hvordan grunnleggende systemteori kan anvendes til å definere kompleksitet, identifisere forhold som skaper kompleksitet, og danne grunnlag for forslag til tiltak. Denne diskusjonen kan gjøres langt mer grundig og omfattende enn her, men formkravene til en artikkel begrenser omfanget.

Det er fullt ut mulig å gjennomføre tilsvarende diskusjoner ut fra andre teoretiske perspektiver som strukturelt, sosialt, politisk eller kulturelt (Bolman et al. 84). En slik diskusjon vil skape andre oppfatninger av hva kompleksitet er, hvordan kompleksitet oppstår og hvordan kompleksitet kan håndteres. Leseren oppfordres også til å gjøre dette ut fra egen fag- og erfaringsbakgrunn og sammenligne anbefalingene med dem som er fremmet i denne artikkelen. Dette kan gi, og forhåpentligvis gir, leseren et mer mangfoldig bilde av kompleksitet som fenomen.

Noter

Litteratur

  • Bolman, L.G. og Deal, T.E. 1984. Modern Approaches toUnderstanding and Managing Organizations. San : Jossey-Bass Publishers
  • Burrell, G. og Morgan, G. 1979. Sociological Paradigms andOrganizational Analysis. London: Heinemann
  • Checkland, P. 1981. Systems Thinking, Systems . Chichester: John Wiley & Sons, Ltd.
  • Jackson, M.C. 2003. Systems Thinking: Creative Holism for . Chichester: John Wiley & Sons, .
  • Kuhn T. 1970. The Structure of Scientific , 2ed. Chicago: University of Chicago Press
  • Mitroff, I.I. og Linstone, H.A. 1993. The Unbounded . New York: Oxford University Press
  • Morgan, G. 1986. Images of Organization. California, Hills: Sage Publications
  • Narayanan, V.K. og Nath, R. 1993. Organization Theory: A Approach. Homewood, Illinois: Richard D.Irwin Inc.
  • Schoderbek, Schoderbek, Kefalas 1990. Management Systems - Considerations. Homewood, Illinois: Richard . Irwin Inc.
  • Stinchcombe, A.L. og Heimer, C.A. 1985. Organizational Theoryand Project Management; Administering Uncertainty in NorwegianOffshore Oil. Oslo: Universitetsforlaget

© Econas Informasjonsservice AS, Rosenkrantz' gate 22 Postboks 1869 Vika N-0124 OSLO
E-post: post@econa.no.  Telefon: 22 82 80 00.  Org. nr 937 747 187. ISSN 1500-0788.

RSS