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.


Vurderer du å bruke smidige metoder i ditt team eller virksomhet, eller er du  bare nysgjerrig på smidig og ønsker å lære mer? Les mer om kurset introduksjon  til smidig.


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 å få en introduksjon til smidig


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

6 grunner til kostnadsoverskridelser (og hvordan unngå dem)

Kostnadsoverskridelser er dessverre et vanlig problem i både store og mindre prosjekter. Ofte hører vi om store statlige byggeprosjekter med million- og milliardsprekker. Årsakene til disse er selvfølgelig forskjellige og sammensatte, men noen gjengangere finner vi. Gjennom 40 års erfaring med komplekse prosjekter på tvers av bransjer, har Metier lært å kjenne igjen de vanligste fallgruvene som fører til kostnadsoverskridelser, og de mest sentrale suksessfaktorene for et vellykket resultat. I dette innlegget gir vi deg en oversikt over de 6 vanligste grunnene til budsjettoverskridelser. Vi har også hentet frem blogginnlegg fra arkivet som kan hjelpe deg med å unngå å havne i fella i prosjektprosessen. Her kan du lese videre om suksessfaktorer, ting verdt å ta hensyn til, samt eksempler fra prosjekter som har lykkes.

Et vellykket prosjekt - først når det er en vellykket ibruktakelse

Hva er et vellykket prosjekt? Som prosjektledere og -eiere er det naturlig å trekke frem prosjekttrekanten for å vurdere om vi har levert på tid, innenfor kost og med den kvalitet som er beskrevet. Er svaret ja på alle disse tre, kan det være fristene til å si at prosjektet er vellykket. Men da glemmer vi noe. For kvalitet er også knyttet til de funksjonelle forutsetningene for å kunne levere på de effektene som virksomheten skal levere etter å ha investert i et nytt bygg. Et vellykket prosjekt må kort og godt resultere i et produkt – et bygg eller annet – som blir brukt, som gir en god nytteverdi for brukerne, og som ikke minst svarer ut behovet det var ment å svare ut. Et vellykket prosjekt betyr derfor også en vellykket ibruktakelse.

Hvorfor bruke klarspråk i prosjekter?

Har du opplevd misforståelser i prosjekter knyttet til uklar kommunikasjon? I prosjektfaget er nettopp god kommunikasjon en viktig suksessfaktor. Det å skrive (og snakke) på en måte som alle involverte i prosjektet forstår, er viktig. Da unngår vi misforståelser, ekstra runder med oppklaring, og i verste fall feil i prosjektene. I dette innlegget viser vi deg hvordan du kan oppnå god og effektiv kommunikasjon i dine prosjekter ved hjelp av prinsipper for klarspråk.