Om forskning på IT-prosjekter

Dette handler om kunsten å lære av erfaring og er en kommentar til Magne Jørgensens foredrag på Software 2015 kalt “Hva skal til for å lykkes i IT-prosjekter?
 Hvor mye og hvordan kan man lære av andres suksesser og fiaskoer?”
 

Akkurat disse spørsmålene har opptatt meg nærmest på heltid siden tidlig 90-tall når jeg jobbet i Siemens Telecom på Linderud i Oslo. Jeg var da så heldig å få være med på ulike forskningsprosjekter, alle med variasjoner over disse spørsmålene som hovedtema. Jeg kan nevne SISU, SPIQ, SPIKE, PROFIT og Evisoft som ble kjørt på rekke og rad i en 20-års periode fra tidlig 90-tall, med finansiering av Norsk Forskningsråd og med forskere fra Sintef, NTNU, UiO og etter hvert Simula. Magne var selv med i noen av disse, husker jeg. Vi (i Siemens) var også med i PERFECT-prosjektet, et EU-finansiert ESPRIT-prosjekt over 3 år, der vi som industripartner hadde støtte fra konsulenter (Q-Labs i Sverige) og forskere fra Sintef, NTNU, Fraunhofer, Universitetet i Kaiserslautern og Universitetet i Grenoble. Våre utviktingsprosesser og vår evne til å lære av erfaring fikk da virkelig kjørt seg. Resultatet fra prosjektet ble kalt PERFECT Improvement Approach (PIA) og var basert på Quality Improvement Paradigm (QIP) og Goal Question Metrics (GQM). Alt lå til rette for at dette skulle bli virkelig bra. God finansiering, flere industripartnere og ikke minst anerkjente forskere som professor Dieter Rombach fra Fraunhofer på laget. Vi støtte oss også tungt på Professor Vic Basili ved Universitetet i Maryland som utviklet GQM og QIP. Og forskning gjort ved NASA av Frank MacGarry. Til tross for alt dette ble resultatet en stor flopp! Hvorfor virker ikke denne solide, vitenskapelig baserte prosessforbedringsmodellen? Hvorfor klarer vi ikke å lære av erfaring på denne måten? Jeg stilte meg dette spørsmålet om og om igjen på slutten av 90-tallet og utover i dette årtusenet og kunne bare konkludere med en ting: Prosjektene var for langvarige og store! Jeg tror det er tre helt fundamentale problemer med dette:

1. Det blir kjørt få prosjekter innenfor en kontekst, så vi får svært få datapunkter å sammenligne.

2. Store prosjekter er svært krevende å analysere, siden det fort vil være alt for mange variable faktorer – som ikke er uavhengige

3. Store prosjekter vil bruke mye kalendertid hvilket lett fører til at det neste prosjektet må forholde seg til en annerledes virkelighet og ha andre rammebetingelser – prosjektene blir ikke sammenlignbare.

Om 3: en metode som fungerte godt i ett prosjekt vil ikke nødvendigvis fungere godt i det neste for her vil sannsynligvis en rekke faktorer (som for eksempel personell) være forskjellige. Jeg husker godt dette fenomenet ble belyst i den smått kjetterske artikkelen The Importance of NOT Learning from Experience som Magne skrev sammen med Dag Sjøberg i år 2000. Bare overskriften fikk brikker til å falle på plass hos meg (jeg kan legge til at jeg ikke er enig i alt som står i artikkelen, men det spiller ingen rolle her). Jeg husker fra PERFECT-prosjektet at vi i Siemens ble trukket fram som et empirisk eksempel på at PIA fungerte. Vi kjørte da tre ganske like prosjekter rett etter hverandre. Alle tre var ganske korte med varighet på 6-7 måneder og prosjekt nummer 3 var særdeles vellykket. Vi som jobbet med prosessforbedring innkasserte gjerne denne seieren da, men med en litt flau smak i munnen. Realitetene var jo at disse tre prosjektene hadde vært nesten like! Og de hadde omtrent samme bemanning. Vi hadde systematisk samlet data og forbedret prosessene våre, men vi må ikke glemme at den erfaringen som satt i hodene på de som hadde vært med på alle tre prosjektene kanskje talte like mye. Eller kanskje mer? Etter dette forandret Siemens strategi (nye tider, ny teknologi osv) og vi oppdaget da at all erfaringslæring, innsamlede data og definerte prosessmodeller var fullstendig ubrukelige. Det ville rett og slett vært skadelig å benytte seg av dette i de neste prosjektene…

I foredraget problematiserer Magne Jørgensen rundt vår evne til å analysere og trekke slutninger. Hvor stor kausalitet har egentlig problemet vi analyserer? Hvor uhildet er våre konklusjoner? Er vi i stand til å være objektive, eller vil vi søke etter å få det svaret vi trodde på forhånd – eller det vi ønsker oss? Kan vi forvente å lære noe særlig når det opprettes “havarikommisjon” i forb med et stort, feilslått prosjekt? Dette er fornøyelig lesning og det er alltid godt å få bekreftet det vi allerede vet av en professor og av forskning. Men dette foredraget rommer egentlig ikke noe nytt. Dessverre.

Løsningen på læringsproblemet

Magne Jørgensen presenterer HVA KAN VI GJØRE FOR Å BLI BEDRE TIL Å LÆRE AV ERFARING? og kommer med en del gode, men ganske selvfølgelige tips. Men han nevner ikke noe om muligheten til å stykke opp problemet i små, sammenlignbare enheter som i for eksempel Scrum. Jeg “arvet” Masterkurset “Produkt- og Prosessforbedring” på IFI av Magne Jørgensen på tidlig 2000-tall, og jeg hadde kurset i 5 år. Jeg bakte tidlig inn det å kjøre mange små, fremfor få store prosjekter i kurset, men rundt år 2004 fikk jeg en slags oppvåkning da jeg forstod rekkevidden av Scrum og andre smidige metoder. Scrum er jo en prosessforbedringsprosess! Scrum er skreddersydd for å lære av erfaring! Men for at det skal fungere godt, må noen brikker være på plass: Teamet må ha på plass kontinuerlig integrasjon, og faktisk fullføre et produktinkrement i hver iterasjon. Og teamet må ansvarliggjøres slik at de selv kan iverksette tiltak når de lærer av erfaring. Erfaringer kan kun trekkes på bakgrunn av sluttresultatet.

Læringsmulighet

Jeg blir altså stadig forundret over at forskere og konsulenter overser denne fantastiske muligheten til å optimalisere læringen. I figuren kan vi tenke oss at det samme 2-års prosjektet med de samme målsetningene kjøres på tre ulike måter. Først et “big-bang-prosjekt” som altså får én læringsmulighet, der vi kjører en prosjektevaluering (som alle gode prosjektledere gjør). Deretter det samme prosjektet med 3 delleveranser og 3 evalueringer. Her vil vi høyst sannsynlig ha ganske like rammebetingelser og kanskje vi er så heldige å ha de samme menneskene i prosjektet (mye tyder på at menneskeaspektet er det aller mest avgjørende). Det er lett å se at vi her får langt bedre betingelser for å forbedre oss underveis og å kunne trekke noen konklusjoner. I smidig vil betingelsene for læring være dramatisk forbedret. Her ser vi at hver iterasjon (I) (tar typisk 2-3 uker) resulterer i et produktinkrement som analyseres og vi får en direkte læringseffekt. Ett aspekt her er at de involverte får rask feedback gjør at læringen kan bli langt mer effektiv. Vi har det vi gjorde friskt i minne og kommer lett i en svært effektiv læringsmodus. Inkrementene er også svært like hverandre, hvilket gjør at vi nå kan eksperimentere med metoder og verktøy. Og vi får øvd oss. Skal vi virkelig bli gode i noe, må vi øve! En viktig betingelse for at smidig skal fungere godt er også at teamet som gjør jobben ikke arbeider mot en stor avslutningsmilepæl. I slike tilfeller vil investeringer i bedre metoder og verktøy kunne virke litt fånyttes, siden prosjektet blir oppløst ved avslutningen. En bedre løsning er å satse på mer permanente team som jobber mot klare målsetninger, men som da får lov til å forbli intakte og kan selv høste fruktene av egen prosessforbedring.

Scrum er laget for å øke kausaliteten dramatisk. Gjennom å dele opp arbeidet i inkrementer, tiden i løpende tids-bokser (iterasjoner) og organisasjonen i små, tverrfaglige team får vi en helt annen gjennomsiktighet. Årsak-virkning-sammenhengene kommer til syne på en helt annen måte.

Jeg trodde det var opplest og vedtatt at store prosjekter er for komplekse til å kunne trekke bastante konklusjoner om hva som gikk galt. Til det er det alt for mange avhengige faktorer som spiller inn; Verden er ikke lineær, den er tvert om dynamisk og kompleks. Jeg støtter meg til Cynefin-modellen til Dave Snowden når jeg diskuterer kausalitet i lys av kompleksitet. Jeg har skrevet en liten innføring her. Han deler inn problemer i 4 domener: Opplagte, Kompliserte, Komplekse og Kaotiske. Det Snowden interessant nok sier om Scrum er at inne i terasjonen er vi sannsynligvis i det kompliserte domenet, hvilket innebærer at vi kan finne årsak-virkning-sammenhenger. I et mer langsiktig perspektiv er vi i det Komplekse området, hvor vi kun i ettertid kan analysere resultatet og finne ut om vi er på rett vei.

Det var mange foredrag direkte og indirekte om smidig på Software2015. Synes nå det er på høy tid at også forskerne ser med større interesse på dette fenomenet, særlig når det er snakk om å lære av erfaring. Det er mulig jeg er for utålmodig, men forskerkverna kverner svært langsomt…

PS: Som deltager på Software2015 fikk jeg en dropbox-link til alle foredragene. Jeg er usikker på om jeg uten videre kan dele foredraget til Magne Jørgensen på denne bloggen.

Du kan se presentasjonen til Magne Jørgensen her

 

Posted on February 20, 2015 at 4:54 pm by gamsjo · Permalink
In: Forskning, kompleksitet, Scrum · Tagged with: , , , ,

4 Responses

Subscribe to comments via RSS

  1. Written by Magne Jørgensen
    on 23/02/2015 at 7:50 am
    Reply · Permalink

    Hei!

    Bra innlegg og mye innsikt fra ulike faser i prosessforbedringens historie!

    Du kan dele presentasjonen min til alle på bloggen, men kanskje ikke dropboxen til DnD.

    Ser at jeg godt kunne godt ha gjort mer poeng ut av læringsprosessen som ligger i inkrementell utvikling.

    Presenterte noen resultater fra den gode effekten av hyppig leveranse til kunde. (Scrum i seg selv var forøvrig ingen faktor for å lykkes i IT-prosjektene i undersøkelsen vår, kun når den førte til hyppige leveranser til kunde). Ut over det så var det mest vektlegging av andre læringsting i presentasjonen. Det betyr ikke at vi er uenige på viktigheten av tidlig og hyppig feedback/læring.

    Vi (Hovedstadsnettverket for IT-ledelse og styring) starter om ikke lenge et 3-årig prosjekt der vi skal forsøke å lære fra tidligere erfaringer. Håper på gode diskusjoner og innspill rundt dette. Vi kan trenge all den kritikk og hyppige tilbakemeldinger vi kan få forå unngå å komme opp med kun resultater som er selvfølgelige.

    mvh
    Magne Jørgensen
    (som skal forsøke å presentere færre selvfølgeligheter i fremtiden :-))

    • Written by gamsjo
      on 23/02/2015 at 8:52 am
      Reply · Permalink

      Takk Magne!

      Ja, jeg har vært veldig forundret over at forskerne ikke delte min entusiasme rundt korte iterasjoner og mer direkte erfaringslæring. Etter mitt skjønn representerte de smidige metodene en revolusjon som ville snu opp ned på all prosessforbedring. Når vi kom til Evisoft (2006-2010 var det ikke?), når spseiselt Scrum virkelig hadde vist hva denne arbeidsformen rommet, trodde jeg virkelig på en dreining i fokus fra forskningen. Men jeg oppfattet ingen entusiasme, selv om det ble en viss dreining i retning av smidig. Selv hadde jeg da vært hos Finn.no og sett med egne øyne hvilket potensiale for systematisk prosessforbedring som lå her!

      Jeg synes fremdeles det er viktig og riktig at du og andre forskere påpeker “selvfølgeligheter” så lenge dette bidrar til å utfordre gjeldende praksis. Dere har en helt annen tyngde og det har verdi om forskningsresultater bekrefter “det vi allerede visste”:) Endring vil alltid ta tid og vi må innse at vi må gjenta oss selv en del ganger før ting skjer i praksis.

      Difi kunne for eksempel spilt en stor rolle her – det er vanskelig å forstå at de ikke på det sterkeste advarer mot å kjøre store IT-prosjekter med store leveranser – i 2015 hvor vi har så mye empiri som viser at jo strørre prosjekt desto større risiko og mindre læring…

      Blir gjerne med på diskusjoner i dette nettverket, Magne!

  2. Written by Dag Sjøberg
    on 10/03/2015 at 10:23 am
    Reply · Permalink

    Hei Geir og Magne,

    Mye fornuftig det som sies her. Siden du Geir nevner kurset på Ifi, UiO, “Masterkurset “Produkt- og Prosessforbedring”, vil jeg bare opplyse om at kurset lever i beste velgående med omtrent 50 studenter i semesteret, men det er nå kraftig re-vitalisert og heter “Prosessforbedring og smidige metoder i systemutvikling”. Dette har også en versjon som undervises på erfaringsmaster-programmet for folk i arbeidslivet. Videre vektlegges Smidig og Lean også i begynnerkurset i systemutvikling med 350 studenter.

    Hilsen Dag Sjøberg

    • Written by gamsjo
      on 10/03/2015 at 11:35 am
      Reply · Permalink

      Det var jeg ikke klar over, Dag. Så bra! Det er en mengde forskjellige aspekter som stimulerer til prosessforbedring i smidig og lean, ikke sant! Rask feedback er jo opplagt, men også ansvarliggjøring og eierskap er viktig.
      Jeg kan ikke dy meg – har en annen diskusjon gående med Magne – her må vi utfordre “prosjektet”. Folk har en klar mental modell av et “prosjekt”: Noe tidsbegrenset og midlertidig som måles for seg. Det jeg observerer er at de som tenker for mye i disse baner lett mister interessen for forbedring. Hvem sine prosesser er det vi da forbedrer egentlig? Og på samme måten blir fokuset på produktet og på effekten av arbeidet tonet ned.
      I smidig/lean er jo “sustainable development” som styrende prinsipp…

Subscribe to comments via RSS

Leave a Reply