Metodevalg: Et spørsmål om riktig verktøy til formålet

Prosjektgjennomføring Metoder og modeller

6 min. lesning

Om vi skal gjennomføre et tiltak agilt eller som fossefall, er et spørsmål om å velge riktig metode til riktig formål, og å anerkejenne at et tiltak, enten det er agilt eller tradisjonelt, kan - og bør - inneholde elementer av begge.

Det handler om å bruke riktig verktøy til jobben. For vi bruker vel ikke Word til å regne ut ting, gjør vi vel?

Jeg sa i et tidligere innlegg om smidige kontra tradisjonelle tilnærminger, at det i den agile diskusjonen ofte blir en drøfting om enten-eller, mens jeg mener det burde handle om både-og. For å fremheve et poeng rundt sunn fornuft, sa Halvard Kilde en gang i et foredrag om eierstyring av investeringer, at «Word brukes til å skrive og Excel brukes til å kalkulere». Dette synes jeg er ganske passende å ta frem nå.

Det tidligere innlegget jeg snakker om endte opp i (etter min mening veldig gode) diskusjoner, blant annet på digi.no, rundt spørsmålet om behovet for styring knyttet til smidig gjennomføring av tiltak.

Utfordringen med slike ordvekslinger er at det av og til kan være vanskelig å ikke bli opphengt i våre egne persepsjoner om hvordan ting er – eller bør være. Jeg pleier å si til mine studenter at vi som mennesker er forutinntatte av natur. Vi er etter min mening ute av stand til å være fullstendig objektive, nettopp fordi vi er mennesker med erfaringer, meninger og følelser – og ja, persepsjoner og preferanser.

Ikke la deg styre av det som føles komfortabelt 

Våre persepsjoner og preferanser gjør også at vi ofte velger det vi kjenner godt eller foretrekker når vi står overfor valg av tilnærming. Eksempelvis møtte jeg nå nylig på et prosjekt hvor det var så tydelig hva som skulle leveres, hvorfor, og hvordan, men hvor prosjektledelsen og teamet likevel var overbevist om at prosjektet måtte kjøres agilt. Hvorfor må det det? Er det fordi teamet mener at det fremdeles er rom for kontinuerlig tolkning og avklaring? Eller er det fordi de ganske enkelt foretrekker å jobbe agilt fremfor å «bare levere det som er avklart»?

Kanskje nettopp på grunn av disse persepsjonene og preferansene, er det vi mennesker trenger litt «kart og kompass» når vi skal finne veien i en jungel av muligheter, og når vi skal velge riktig verktøy for jobben vi står overfor. Akkurat som da vi lærte oss å bruke Word og Excel til deres respektive formål, mener jeg vi kan ha nytte av et kart som gir oss en pekepinn. På den måten får vi ikke bare en pekepinn på hva som er mulig å gjøre, men på hva som er fornuftig å gjøre.


Ønsker du forståelse for når smidig metodikk kan være riktig fremgangsmåte?  Meld deg på kurs om smidighet i prosjekter.


Stikk fingeren i jorda: Hvordan gå frem på en fornuftig måte

Jeg deltok nylig på et kurs i design thinking. Her ble jeg påminnet om hvor viktig det er å «jorde» oss når vi står overfor en problemstilling, for å prøve og unngå å falle i persepsjonens og preferansens felle, og heller belyse problemet og spørsmålet med fornuft, logikk og felles forståelse.

Hva er det vi egentlig prøver å finne svar på? Hvordan bør vi mest fornuftig gå frem for å løse problemet? I det samme kurset ble jeg også påminnet om en figur som jeg har tatt meg friheten til å «spisse» enda litt mer, nettopp for å prøve å gjøre den enda tydeligere.

Figur - tilnærming til problemløsing

I figuren ser vi at der hvor vi står overfor en kjent løsning på et kjent problem, er det naturlig å benytte en «tradisjonell» tilnærming (eller fossefall om du vil). Likeledes sier den at der vi står overfor et kjent problem med en ukjent løsning er det mest naturlig å innta en mer utforskende tilnærming, altså agil.

Men nå står vi ikke bare overfor spørsmålet om agil eller ikke lenger. Vi står også overfor spørsmål om hvorfor tiltaket eller investeringen bør organiseres som prosjekt (hvis i det hele tatt), og om prosjektet i så fall bør ha en fossefalls- eller smidig tilnærming. Vi står overfor spørsmål om hvorvidt utvikling bør produkt-orienteres, og om vi har tilstrekkelig med fokus på innovasjon i vår tilnærming. I tillegg dukker det opp spørsmål om hvordan vi skal organiseres oss; i teams, squads, tribes osv.

Figuren over gir oss svar på noen – ikke helt ubetydelige – spørsmål. Som at vi bør kjøre fossefall når vi kjenner både problem og løsning og at vi bør kjøre agilt når problemet er kjent, men løsning er ukjent. Den gir oss også en pekepinn på at produktorientert, kapasitetsstyrt utvikling kan være hensiktsmessig i en «forbedringsportefølje» hvor man har en løsning (eksempelvis IT systemene i en bedrift), som kontinuerlig bør videreutvikles for å tilpasses organisasjonens og brukernes endrede behov. Sist, men ikke minst, sier den at hypotesedrevet design (ekte explorative om du vil) passer aller best der hvor vi skal utforske både problemet og løsningen.

Ikke enten-eller, men både-og

At figuren sier «gå for en tradisjonell tilnærming» betyr selvsagt ikke at du alltid skal gjøre det, ei heller at akkurat det valget trenger å være gjeldende for hele prosjektet. Eksempelvis er det ofte i tidligfase av prosjekter mest hensiktsmessig å innta en utforskende tilnærming, selv om prosjektets gjennomføringsfase kanskje naturlig bør gjøres som fossefall.

Likeledes kan du ha prosjekter hvor noen deler av gjennomføringen bør gjøres som fossefall, mens andre bør gjøres mer smidig. Det er, som jeg sa i den nevnte diskusjonen, ikke et spørsmål om fugl eller fisk, men heller som Ole Brumm (faktisk aldri) sa: ja takk, begge deler (faktasjekk: Ole Brumm sa aldri egentlig det, det fremkommer kun i den norske oversettelsen av Torbjørn Egner).

Figuren gir oss ikke alle svarene, men den gir oss en pekepinn på hvor vi bør rette blikket. Den gir oss i så måte også et kompass vi kan navigere etter i vår søken etter løsning og tilnærming, eller svar på spørsmålet om hvilket verktøy vi bruker til hvilket formål.


Vil du lære mer om når det kan være nyttig å ha en smidig tilnærming? 

Krav om hurtige endringer og løpende justeringer skaper behov for en arbeidsflyt hvor man jobber iterativt og realiserer verdi gjennom hele eller deler av prosjektet. Derfor går mange over til å bruke smidige metoder i prosjekter. Men når skal man gjøre det, og hvordan går man frem?

På vårt kurs om Smidighet i prosjekter vil du få en grunnleggende innsikt i nettopp dette. 

Meld deg på kurs om smidighet i prosjekter


Morten Duesund har en doktorgrad innen prosjektfaget, og tung erfaring innen prosjekt-, program- og porteføljeledelse. Den tidligere lederen i Project Management Institute (PMI) i Norge er også vant til å stå på scenen, og deler gladelig av sin kunnskap med kunder, kolleger og medarbeidere.


Likte du dette blogginnlegget? Da tror vi at disse også passer for deg

Hvordan sikrer TOMRA vekst med nytt HR-system?

TOMRA er et norsk, bærekraftig eventyr som i dag opererer i hele 80 markeder verden over. Vekstambisjonene er fremdeles sterke, og nå innføres det et nytt HR-system globalt i selskapet for å understøtte disse ambisjonene. Dette vil være et stort bidrag til TOMRAs satsning på Talent Management og gi høyere effektivitet når det kommer til IT-operasjoner knyttet til HR-oppgaver. Metier OEC er en samarbeidspartner i prosjektet, og bidrar med kompetanse innenfor digitalisering, endrings- og prosjektledelse, samt smidige metoder. I dette blogginnlegget byr vi på noen av prosjektets største fordeler og suksessfaktorer, og prosjektleder Per Inge Krossen forteller om hva han har lært på veien mot implementering i ca. 40 land.

11 blogginnlegg om prosjektledelse fra start til slutt

Prosjektledelse gir rom for nye karrieremuligheter og personlig utvikling. Samtidig er det et stort fagfelt, og en prosjektleder har ofte mange tråder å holde i. Vi har samlet noen av de mest aktuelle blogginnleggene for temaet, som vi tenker kan være til nytte for deg som er enten ny eller erfaren prosjektleder.

Hva gjør jeg når prosjektet ikke ligner på noe jeg har gjort før?

Et prosjekt er per definisjon unikt. Noen prosjekter skiller seg likevel vesentlig mer fra det virksomheten er vant til, og dette kaller vi et Stranger-prosjekt. Et slikt prosjekt er verken kompatibelt med kompetansen eller rammeverket i virksomheten, og det kan være vanskelig å vite hva du egentlig står overfor. Når du utbryter «hjelp, jeg har et Stranger-prosjekt» har prosjektet kanskje kommet så langt at det kan få følgefeil helt til slutten. Vi gir deg våre erfaringer fra Stranger-prosjekter, så det skal være lettere å oppdage at du har et, unngå fellene og kunne innrette deg slik at du klarer å hente ut de planlagte gevinstene.