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

Derfor bør du ta deg tid til en ordentlig prosjektavslutning

Bygget er ferdig bygget, brukerne har flyttet inn og driften er i gang, prosjektorganisasjonen er delvis oppløst og mange er allerede engasjert i nye prosjekter. Hvordan skal man egentlig avslutte et prosjekt på riktig måte, før man som prosjektleder kan slippe taket? En fallgruve i prosjekter er at prosjektet aldri blir formelt avsluttet, men «dør» hen. Prosjektleder er i gang med nye utfordringer, og avslutningsaktivitetene ble aldri egentlig gjennomført. I slike tilfeller risikerer man å miste viktig og verdifull innsikt. Her får du et overblikk over hvordan du bør gå frem i avslutningsprosessen, samt noen tips til hvordan du gjennomfører på en måte som gir godt utbytte i form av forståelse for prosjektets resultater som kan hjelpe dere å gjøre det enda bedre i fremtiden.  

3 hovedmomenter ved Systematisk ferdigstillelse

Hva er viktig å tenke på når man skal innføre Systematisk ferdigstillelse om en del av prosjekteringen? For å få mest ut av prosessen og innholdet, er det tre overordnede elementer som må være til stede; ledelse, innholdskompetanse og systematikk. I dette innlegget skal vi se nærmere på disse tre elementene, og hvilke hovedmomenter innenfor disse du bør få med deg for å oppnå best mulig resultat.

Hva er Systematisk ferdigstillelse?

Tekniske anlegg utgjør en stadig større del av totalleveransen i nybygg, noe som medfører mer komplekse prosjekter med flere grensesnitt og komponenter enn tidligere. Mange byggeprosjekter preges også ofte av at tekniske systemer og prosjekterte funksjoner ikke fungerer som de skal når bygget skal tas i bruk. Oppretting av dette kan ta tid og medfører gjerne merkost for prosjekteier. Så hvordan kan man i prosjektet sikre at alt fungerer best mulig ved overtakelse? Dette innlegget er det første i en serie om Systematisk ferdigstillelse. Her introduserer vi deg for metoden, og hvordan den kan benyttes for å unngå feil og mangler, ved å fokusere på sluttfase allerede fra tidligfase og utover.