3 konkrete råd for raskere omstilling

«Alle» snakker av gode grunner om fornying og omstilling for tiden. Men det er for det meste prat, lite konkret handling. Jeg er redd det kommer til å ta lengre tid enn det behøver å gjøre.

Artikkelen er publisert på digi.no

Omstilling er krevende av mange årsaker, men først og fremst fordi hierarkiene og styringssystemene er ganske fastlåste av natur. Og at gammel vane som kjent er vond å vende.

SameOldThinking

For å oppnå en grunnleggende omstilling raskt er det helt nødvendig å tydelig utfordre etablerte mønstre, og det kan oppnås gjennom å gjøre strukturelle endringer. Grunnleggende endringer vil nødvendigvis skape utrygghet blant de som allerede har en god posisjon i det etablerte. Man vil altså garantert møte motstand.

Jeg kjenner IT-bransjen godt og det kan tjene som et godt eksempel, siden alle organisasjoner gradvis har blitt helt avhengig av IT og en svært stor andel også av nyutvikling av programvarebaserte løsninger. Innovasjonen i offentlig sektor i dag er nesten utelukkende programvarebasert. Programvareutvikling er – enten vi liker det eller ikke – business as usual. Kjernevirksomhet.

To konkurrerende paradigmer for programvareutvikling

I 2001 ble Agile Manifesto publisert – et manifest som skulle utfordre de etablerte dogmene innen planlegging og styring av programvareutvikling. Det ble en formidabel suksess og vi ser i dag at de nye suksessrike programvareselkapene selskapene i verden (Google, Facebook, Amazon, Netflix, Spotify, eBay for å nevne noen) har adoptert denne tankegangen.

I de senere årene ser vi også stadig fler av ikke like opplagte IT-avhengige bransjene som bank/finans, telekom, energi, industri kommer etter. I norsk offentlig sektor har vi noen få eksempler på vellykkede forsøk med disse metodene.

Dette nye paradigmet – vi kaller dette smidig på norsk – er basert på mye av det samme tankegodset som vi finner i Lean og er designet for å oppnå hurtig læring, tilpasningsdyktighet og høy kvalitet og er eksplisitt kundedrevet. For å oppnå dette krever de smidige metodene at jobben deles opp i små delleveranser og gjøres i selvstyrte, tverrfaglige team med stor inflytelse på løsningsvalg. Smidige metoder vil skape en gjennomsiktighet som gjør det enklere og billigere å styre og reduserer risikoen betraktelig sammenlignet med tradisjonelle metoder.

Det skal ikke så mye til å se at de smidige metodene helt eksplisitt svarer på de utfordringene offentlig sektor står overfor i dag.

Det rådende, etablerte regimet fokuserer på grundig planlegging og analyse, på en rekke etterfølgende faser («vannfallsmodellen») på at ansvar er knyttet til roller (som lett blir til «siloer»), på hierarkiske strukturer og på prosjektstyring. Man kan få et godt bilde av dette ved å studere anskaffelser.no og prosjektveiviseren.no. Disse nettsidene representerer på en god måte de etablerte dogmene som Agile Manifesto utfordret i 2001. Fokuset på grundig, tidkrevende planlegging fører til at vi sløser med verdifull kalendertid og låser oss for tidlig. De som gjør jobben – designere, utviklere, testere osv – blir da effektivt fratatt muligheten for å skape et best mulig produkt siden endringer i forhold til plan og kontrakt alltid vil medføre merkostnader.

Hvordan skape endring?

Fornying krever endring. Endring er både smertefullt og tidkrevende. John Kotter satt fingeren på noe vesentlig: den viktigste faktoren er “a sense of urgency”.

Heldigvis har vi nå altså et 15 år gammelt velfungerende og smidig paradigme som svarer mye bedre på dagens utfordringer enn det etablerte. Det finnes gode rammeverk (som for eksempel Scrum) og metoder som ligger og venter på å bli tatt i bruk. Det finnes kurs og konsulenter som kan dette og det finnes mengder med litteratur. Men dette er såpass annerledes at en omlegging vil kreve modning over tid og mye hardt arbeid.

Det er Direktoratet for IKT – Difi – som sitter med nøkkelen her. De har en avgjørende rolle i arbeidet med å få skakkjørte IT-prosjekter på rett kjøl og å få fart på digitaliseringen av Norge.Men det går for sakte.

Difi har vært kjent med smidige metoder i lang tid, og de har i ulike sammenhenger uttalt at de er tilhengere av smidig, og at de er i gang med dette. Men dette er foreløpig bare prat. Det er fremdeles forrige århundrets paradigme som gjelder.

Dette bekrefter forestillingen (eller kanskje vi skal kalle det fordommene) vi har om at byråkratiet instinktivt vil motsette seg endring. Byråkratiske styringssystemer er skrudd sammen slik, med klare roller og formaliakrav og der standardisering og etterlevelse er det viktigste. Unntak og utfordringer er uønsket. Målstryring gir på toppen av dette lokalt fokus slik at helhetssynet og samhandlingen taper.

KMD er ansvarlig for moderniseringen og må stille krav til byråkratiet, og jeg mener bestemt de må være tydeligere for at direktoratet skal reagere. De må vise lederskap, i likhet med lederne i forvaltningen.

Her følger 3 konkrete råd til myndighetene:

Råd 1: Utvikle et alterantiv til prosjektveiviseren

Prosjektveiviserens utgangspunkt er som navnet tilsier at arbeidet skal skje gjennom en «anskaffelse» med «prosjekt» som styringsmekanisme. Disse mekanismene er er velegnet for ekstraordinære initiativer som krever sterkt fokus over tid. Fungerer fint for bygg og anlegg. Men det å utvikle programvare på denne måten har en rekke helt unødvendige ulemper. Det mest optimale er å definere IT-utvikling som «business as usual» og sørge for en viss grunnbemanning med utviklingskapasitet.

Denne kapasiteten kan da raskt svare på ønsker og behov i befolkning og forvaltning og operere på en mer effektiv og innovativ måte. Bruk konsulenter til å skalere opp og ned ved behov. Kunden sitter her med kontrollen over både gevinst og kostnader. (Her er et eksempel på potensialet Noen ekstra kodelinjer ga politiet den beste IT-løsningen.)

Så her trenger vi altså helt nytt veiledningsmateriell med tilhørende rådgivning og kurs. Men vi behøver ikke å starte helt fra scratch, både USA og Storbritannia har laget sine utmerkede veiledere som vi bør hente inspirasjon fra (GOV.UK Service Manual og US Digital Services Playbook) Så mitt klare råd her er å snarest skaffe kompetanse på området smidig systemutvikling (som Difi mangler i dag) og å sette i gang med dette arbeidet. Vi ligger minst 3 år bak USA og UK dette området.

Råd 2: Bytt rådgivere

Offentlig sektor er storkonsumenter av rådgivende konsulenter i digitaliseringsarbeidet. Ikke noe galt i seg selv dette, men skal man kunne håpe på endring vil man være nødt til å lytte til andre rådgivere. Rådgivere i posisjon har denne posisjonen fordi de er spesielt kompetente på det rådende regimet. De vil ha en langt svakere posisjon og kompetanse i det nye regimet, og vil naturlig nok ikke utfordre det bestående i særlig grad.

Vi opplever at «alle» er for smidig i dag, men det er veldig ulikt hva man legger i begrepet. De som har en solid posisjon i det bestående bruker begrepet svært overflatisk og svakt, med den naturlige konsekvens at endringsbehovet er lite.

De som har satt seg grundig inn i det, som virkelig ønsker smidig og som selv har vært igjennom noen smidige transformasjoner i privat sektor vet at dette er noe helt annet. Et ulikt tankesett med andre strukturer, styringsprinsipper og metoder.

Det blir altså ikke mye endring når rådgiverne selv tilhører etablissementet. Mennesker og selskaper er seg selv nærmest og de som er i posisjon vil naturlig unngå å utfordre denne posisjonen.

Råd 3: Ton flagg!

Det er ingen grunn til å tro at denne endringen vil bli enklere i offentlig enn i privat sektor. Jeg har fulgt en del organisasjoner i sine «smidige transformasjonsprogrammer» og la det være helt klart; det er mange som mislykkes. Men det er også klart at de som lykkes er tydelige på at vi behøver endring for å klare oss i framtiden!

KMD minister Jan Tore Sanner sier: Vi må skape en kultur for kontinuerlig fornyelse! Fint! Men hvordan da? Når?

Liam Maxwell, kalt «The CTO of UK» besøkte Digitaliseringskonferansen til Difi i 2013 og fortalte da på en svært overbevisende måte at de ikke kunne fortsette med de store vannfallsprosjektene lenger. (Video og presentasjon her) De gikk på den ene prosjektsmellen etter den andre, mens de store konsulenthusene tjente fett. Maxwell sa i klar tekst at dette var over og at de nå hadde gått over til en helt annen framgangsmåte basert på smidig.

Både Storbritannia og USA har sagt tydelig i fra at digitaliseringen skal skje gjennom smidige metoder. Prosjektstyring tones kraftig ned, rett og slett fordi prosjektstyring er feil medisin. Dette må også vi våge å utfordre! Jeg har til dags dato ikke oppfattet noen seriøs interesse fra offentlige instanser til å gjøre en gjennomgang av fordeler og ulemper med prosjektet som arbeidsform. Her er en god artikkel fra konsulentsekskapet Bekk om temaet.

Vi vil antageligvis se en dreining mot oppdeling i mindre prosjekter og delleveranser i tiden framover. Og helt sikkert flere Scrum-aktige utviklingsteam. Dette vil kunne gi en viss positiv effekt. Men det ikke nødvendig å nøye seg med dette! Vi kan oppnå mye mer gjennom å systematisk dyrke tverrfaglig teamarbeid, svært hyppige leveranser og kontinuerlig forbedring. Men da må det kraftigere lut til enn det vi ser i dag.

 

Posted on December 4, 2015 at 2:15 pm by gamsjo · Permalink · Leave a comment
In: Coaching, Endringsledelse, kompleksitet · Tagged with: , , ,

#NoEstimates – Nei til estimater!

Hashtagen #NoEstimates har hatt en imponerende aktivitet på twitter i drøye to år nå, med samme tema: Kan vi ta gode beslutninger uten å estimere? Det ville jo vært besnærende om det var mulig!

http://noestimatesbook.com/

http://noestimatesbook.com/

For alle som har vært ute en IT-vinterdag før vet at estimering har en del problematiske sider ved seg. Temaet er fremtredende på de fleste konferanser med fokus på smidig systemutvikling. Spørsmålet er når prosjektstyringsmiljøet fatter interesse for temaet.

Problematiske estimater

For det første er det svært vanskelig. Behovene og kravene vi skal tilfredsstille, er ulne. Dessuten har vi ikke gjort det før. Hvis det var gjort før, kunne vi bare levert det, ikke sant? Så for de aller fleste estimater må vi påregne en betydelig usikkerhet. Det hjelper heller ikke så mye å knytte estimert usikkerhet til estimatet, da også dette estimatet blir usikkert …

Det tar tid. Det går med andre ord an å spare verdifull tid – og dermed penger – ved å la være. Når vi skal vurdere en IT-satsning og estimere kostnadene og leveransetidspunktet, vil vi måtte forsøke å «tenke på alt», slik at vi ikke går på en smell og glemmer å ta med noe som for kunden er opplagt. Så vi blir nærmest tvunget til å gjøre en god del arbeid og bryte funksjonaliteten ned til et ganske detaljert nivå. Mye av dette arbeidet vil være unødvendig siden vi her vil fokusere på både viktig og uviktig funksjonalitet.

Det fører lett til at vi låser oss for tidlig. I prosessen med å estimere går vi altså ganske langt i å forsøke å forstå hele produktet vi skal lage. All den tiden vi har investert i å bryte ned på å estimere gjør at vi føler oss forpliktet til å også ta neste skritt og faktisk lage det, selv om det etter hvert skulle vise seg å ikke være så viktig. Vi pådrar oss med andre ord en stor økonomisk risiko.

Den blir misbrukt til å følge opp framdrift. Et estimat blir lett oppfattet som en forpliktelse, nærmest et løfte. Når en utvikler eller en leverandør støter på uventede ting (dette bør ikke være uventet innen IT-utvikling!) så havner vi på etterskudd i forhold til plan. Om prosjektledelesen eller andre følges opp mot en plan basert på estimater vi det være fristende å forsøke å jobbe fortere. Software kan lages fortere ved å kutte hjørner og altså ofre det gode håndtverket. Dette vil i sin tur kunne gi stor teknisk gjeld og dermed dårlig vedlikeholdsvennlighet.

Hva er alternativet?

Jeg vet ikke om det er fornuftig å ikke estimere i det hele tatt, men jeg vet at ved å dele opp problemet i små biter som blir levert etter hverandre får vi noen besnærende muligheter. Dette går i korte trekk ut på å bruke noen få iterasjoner på å skaffe empiri omkring hastigheten et team kan levere funksjoner i.

Hvis vi har et fast, tverrfaglig team som gjør jobben, kan vi ta beslutningen om å sette i gang utvikling uten å forplikte en stor leveranse langt inn i framtiden. Vi har en hypotese om at dette teamet vil kunne klare å levere verdifulle funksjoner som vil kunne tilfredsstille våre behov, og så investerer vi i et lite antall iterasjoner. Da vil vi kunne telle opp hvor mye funksjonalitet de leverer i en typisk iterasjon, hvilket vi så bruker til å ekstrapolere framover i tid.

Eksempel på ekstrapolering basert på erfaring. Illustrasjon: Sven Schnee

Her gjelder det altså å velge rammeverk som støtter raske iterasjoner og hyppige leveranser. Bruker vi Scrum, vil vi typisk avse fem prosent av kapasiteten til å grovestimere funksjonene som ligger foran oss. Man bruker gjerne relativ estimering og måler hastigheten i Story Points.

Med Kanban-metoden vil mange si at vi klarer oss med bare å telle opp ferdige elementer (gjerne User Stories) levert per tidsenhet. Uansett Scrum eller Kanban kan vi sannsynliggjøre omtrent når dette teamet har levert noe som vil ha betydelig verdi for oss. Faste team har også den besnærende effekten at kostnadene vil være ekstremt lett å kalkulere og ekstrapolere.

Hvordan ta beslutninger uten estimater?

Kunder vil naturligvis spørre «hva vil det koste» og «når kan vi få det» og de blir forståelig nok skuffet over at svaret er «vet ikke». Men selv om vi ikke vet så mye om det endelige produktet, kan vi allikevel gi kunde et godt beslutningsgrunnlag. Kunden vil kunne få bedre styring og kontroll på satsningen enn det som er vanlig i IT-prosjekter – etter at noen iterasjoner er gjennomført. Vi må altså ha erfaringer om fortiden for å kunne spå om framtiden. Vi skaffer oss empiri og baserer styringen på dette.

Etter at vi har fått empiri om hastigheten til teamet, vil vi kunne besvare spørsmål av typen:

Beslutningstakere har gjerne en klar mental modell hva det vil si å utvikle IT-systemer: Analyse, forprosjekt, estimering, planlegging, ny estimering, oppbemanning, gjennomføring, leveranse, nedbemanning. Man gjør dette nærmest av gammel vane, men det er ikke nødvendigvis den beste og mest effektive modellen. Og den medfører større økonomisk risiko enn nødvendig. Så snart man lærer seg å splitte problemet opp i små, prioriterte inkrementer får man også muligheten til å effektivt se fremover uten å basere seg på svært usikre estimater.

Sven Schnee snakket om #noestimates på Smidig 2015

 

Posted on November 15, 2015 at 4:39 pm by gamsjo · Permalink · Leave a comment
In: Endringsledelse, kompleksitet, Planlegging, produkteier, prosjektledelse, Risko · Tagged with: , ,

Tid er penger

TidErPenger

Vi har opparbeidet en aksept for de tre T-er: “Ting Tar Tid”. Men må det være sånn? Er det smart å akseptere at saker må legges i køer og dermed ta lang tid å behandle? Kan vi ikke i det minste få løst det mest prekære problemet kjapt, i stedet for å legge det i kø? Betimelige spørsmål som vi burde stille oss oftere.

Ventekostnader – Cost of Delay

I bygg- og anleggsbransjen er det opplagt at en leverandør vil ha krav på å få kompensert kostnader om de må vente med oppstart. De har tross alt reservert dyrt materiell og arbeidskraft for et gitt oppstartstidspunkt, så en forsinkelse blir da ren kostnad.

I IT-bransjen er det helt uvanlig å operere med ventekostnader, kanskje fordi disse kostnadene ikke er like oppe i dagen som i andre bransjer. Materiell har vi ikke på samme måten og arbeidskraften kan ofte brukes på andre oppgaver i påvente av oppstart. Men hva med brukerne som har sett fram tid en sårt tiltrengt forbedring? Hva med gevinstene som blir utsatt? Bør vi ikke kalkulere med disse?

I følge Don Reinertsen forfatter av The Principles of Product Development FLOW er de fleste i IT-bransjen blinde for denne effekten. Og dette til tross for at den økonomiske effekten er betydelig. Dessuten kan COD-kalkyler utgjøre et veldig nyttig instrument i produktplanleggingen.

If you only quantify one thing, quantify the Cost of Delay. Don Reinertsen

Boka fokuserer på de økonomiske effektene av produktutvikling og introduserer en stor mengde prinsipper for planlegging og styring. Ideen er å øke flyten på de delene av produktet som gir antatt størst gevinst og som det dermed blir mest kostbart å utsette. En svært smidig tankegang med andre ord.

Figuren er hentet fra en god beskrivelse av Cost of Delay fra Black Swan Farming. Som vi ser er COD rett og slett den akkumulerte gevinsten vi går glipp av ved å vente med implementasjonen. Vi forstår at vi ideelt sett bør sette i gang så fort vi har identifisert en gevinst som er mulig å realisere. Og så vet vi at det vil være en rekke potensielle gevinster som står i kø for å realiseres, men vi har en begrenset kapasitet. Så vi må prioritere – hva skal vi gjøre først? Hvorfor ikke da prioritere å gjøre det som har den høyeste COD dividert på kostnad? Her er en mer inngående beskrivelse av denne prioriteringsmekanismen.

Tradisjonell prosjektledelse har veldig svake konsepter for prioritering. I stedet blir det ofte slik at “alt skal med”. Vi planlegger for kompletthet. Vi forplikter oss til å levere et stort omfang, som vi jobber med i paralell. Konsekvensen blir da at gevinstene forsinkes voldsomt i forhold til potensialet. Hva koster dette?

Det er fristende å ta med COD i analysen av de store IT-skandalene vi har sett i offentlig sektor i den senere tid. Hvis vi ser på de planlagte gevinstene i Moderniseringsprosjektet til NAV – som ble stoppet – dreier dette seg ikke akkurat om småbeløp. Prosjektet har pågått i mange år – ble i realiteten startet rundt 2008 – og det er siden dette ikke gjort mye annet enn å analysere og planlegge. Ingen vesentlige gevinster realisert ennå. Totalgevinsten antydes til rundt 4 Mrd kroner “netto nåverdi mot nullalternativet” i KS1-rapporten. Det skal spares ca 2000 årsverk. Når da dette prosjektet i fjor ble stoppet, betyr det at det fremdeles “løper” en anselig COD!

Alle synes nå omsider å være med på at vi må dele opp disse mammutprosjektene i mindre biter. Det er på høy tid. Men da trenger vi helt andre metoder og ikke minst annen kompetanse i startfasen. COD bør innarbeides som en naturlig del av den samfunnsøkonomiske analysen. Som Arild Haraldsen er inne på i denne artikkelen er disse analysene en svært krevende øvelse med stor usikkerhet og mange fallgruber. Men det er ingen løsning å gjøre analysene “grundigere”. Øket tidsbruk vil jo bare øke COD. Igjen, det gjelder å balansere tidspress mot grundighet hvilket må innebære oppsplitting og at de opplagte, største gevinstene realiseres først. En aktiv bruk av COD vil automatisk kanalisere innsatsen mot de områdene med størst gevinstpotensiale. Da vil vi se at de sære unntakstilfellene godt kan vente. Vi behøver ikke alltid lage løsninger som skal treffe “alle”, ofte ligger 80-95% av verdien i å automatisere operasjoner for det typiske tilfellet. Særtilfellene kan vi vente med, eller eventuelt leve med manuelle operasjoner, siden volumet er lite.

Flytoptimalisering fremfor ressursoptimalisering

Boka Dette er Lean er nå Sveriges mest leste bok om ledelse. I denne boka tar Niklas Modig et kraftig oppgjør med den tradisjonelle ressursoptimaliseringen – en filosofi som passer svært dårlig til kunnskapsbasert arbeid i vår tid. Han skriver her om løsningen på effektivitetsparadokset. Problemet er enkelt sagt at vi legger sakene i kø fremfor å bare løse saken med en gang. Disse køene er et valg – en konsekvens av tankegangen og organiseringen der vi jobber med mange saker på en gang og der vi dyrker spesialiserte roller som arbeider hver for seg i stedet for tett teamarbeid. Et sterkt tverrfaglig team med myndighet vil kunne ta unna innkommende arbeid “én sak av gangen”.

Nå en sak ligger i kø skapes det sekundærbehov. Disse behovene vil også belaste systemet, og ofte være til stor ulempe for brukerne. Søknad om foreldrepenger har i mange år vært en ganske uforståelig vanskelig prosess – noe som fører til at en gjennomsnittelig søker må ringe inn flere ganger og få hjelp for å gjennomføre en i utgangspunktet enkel oppgave. NAV har i denne perioden sysselsatt et helt “scannekontor” som jobber med å scanne inn søknader som tidligere er printet ut. Når brukere venter på den endelige løsningen vil de naturlig nok lage seg sine små hacks – midlertidige løsninger. Det er klart disse helt unødvendige ulempene vil koste tid og penger – og må tas med i regnestykket når vi prioriterer.

Denne bevisstheten om å optimalisere flyten, sammen med aktiv bruk av Cost of Delay og smidige metoder vil på sikt kunne gi en langt mer effektiv og økonomisk sunn offentlig sektor.

IT-fadeser: Om læring og mentale modeller

Vi blir stadig påminnet om hvor vanskelig det er å lykkes med IT-prosjekter. Og det virker som problemet er økende. Vi leser om hundrevis av millioner som sløses bort, uten at særlig verdi er skapt.

I kjølevannet av dette blir selvsagt bransjen svar skyldig. Hva kan vi gjøre for å bøte på dette? Hva kan vi lære av det? Per-Morten Hoff i IKT-Norge vil ha mer styring og havarikommisjon, Cathrine Klouman i DnD vil at vi skal våge å feile – i forprosjekter før det ordentlige prosjektet starter, Difi ved seksjonssjef Ellen Strålberg vil ha enda mer kvalitetssikring før oppstart (obligatorisk KS1 og KS2) samt obligatorisk bruk av prosjektveiviseren. Professor Magne Jørgensen på Simula analyserer også prosjektsuksess, og kommer til at det synes som det kan lønne seg å kjøre “smidige prosjekter” som jobber iterativt og at det er vanskelig å estimere.

Alle disse analysene baserer seg på én felles mental modell av IT-utvikling, nemlig at dette skal skje gjennom å starte et prosjekt. Et prosjekt er som alle vet en fokusert innsats mot et konkret mål gjennom å etablere en midlertidig organisasjon. Vi tenker noe ekstraordinært som ikke kan kjøres “i linja”. Og når vi hører ordet prosjekt vil de fleste av oss også umiddelbart tenke faser. Vi får en analysefase, en planleggingsfase, en oppstartsfase, en gjennomføringsfase, en leveransefase, en avslutningsfase og til slutt en lang driftsfase der en annen organisasjon drifter og vedlikeholder prosjektresultatet. Vi tenker “plan the work – work the plan”.

ProsessDifi

En typisk fasebasert modell for prosjektplanlegging og -styring (hentet fra prosjektveiviseren.no).

Så med denne klare, intuitive modellen godt forankret i underbevisstheten skal vi altså forsøke å lære av erfaring. Helt naturlig da å tenke siden dette er så vanskelig og risikabelt, må vi gjøre grundig forarbeide og forsøke å “tenke på alt” før vi bestemmer oss for å sette i gang. Og like naturlig å tenke at vi må ha enda bedre styring og kontroll underveis.

Mentale modeller er kraftige saker og de vil påvirke oss sterkt i hvordan vi forstår verden rundt oss og hvordan vi analyserer årsakssammenhenger. I den etter hvert legendariske boka The Fifth Dicipline – The Art & Practice of The Learning Organisation viser Peter Senge hvor avgjørende våre rotfestede mentale modeller vil være og at vi aldri må ta disse for gitt. Vi må alltid ta de med i betraktining i våre analyser. Mentale modeller er en av de 5 disiplinene lærende organisasjoner må beherske. De andre er Personal mastery, Building a shared vision, Team Learning og til slutt den femte og mest avgjørende Systems Thinking.

La oss forsøke å bytte ut den intuitive mentale modellen vi får fra prosjektbegrepet. La oss et øyeblikk tenke at vi kanskje ikke hadde behøvd å behandle IT-utvikling som noe ekstraordinært og stort som krever en egen organisasjon. La oss tenke at vi delte opp problemet i mindre biter, prioriterte disse og leverte resultater i små deler. Og at IT-utvikling er noe som pågår ganske kontinuerlig og som faktisk kan kjøres “i linja” i permanente team. Da får vi et helt annet bilde av IT-utvikling.

smidigProsess

En alternativ, prosjektløs modell for IT-utvikling

Så med denne mentale modellen på netthinnen, hvilke tiltak ville vi nå anbefale for å lykkes med IT-utvikling? Det må jo da bli slikt som “vår evne til å levere små inkrementer av resultatet og å lære av disse”. Eller “vår evne til å løpende planlegge neste iterasjon uten å miste hovedmålet av syne”, “Vår evne til å fange opp brukernes basale behov underveis”. Kanskje “vår evne til å stoppe opp når kostnadene overstiger verdien”. Slike ting. Altså helt andre ting.

Ville det ikke vært verd et forsøk Difi, DnD, IKT-Norge, Simula og ellers alle som er opptatt av pengebruken i offentlige IT-satsninger?

Posted on October 11, 2015 at 2:09 pm by gamsjo · Permalink · Leave a comment
In: Planlegging, prosjektledelse, Risko, Samfunn · Tagged with: , , , ,

Risiko og innovasjon

“No pain – no gain”. “Den som intet våger intet vinner”. Alle forstår at om vi vil oppnå noe bra så innebærer det ofte også en viss risiko. Slik er det selvsagt også med IT-prosjekter. Men hvordan forholder vi oss til risiko i IT-prosjekter? Hva slags strategi skal vi ha for å håndtere denne?

Mye tyder på at vi er i ferd med å bli alt for risiko-averse i dette landet. Særlig i offentlig sektor, hvor vi virkelig trenger innovasjon!

wave2

Tankegangen innen innkjøp, styring og ledelse er at vi må forsøke å eliminere risikoen ved å gjøre grundige foranalyser, gjerne forprosjekter, før vi tar på oss økonomiske forpliktelser. Dette er intuitivt og fornuftig i mange sammenhenger. Grundig analyse og planlegging gjør at selve gjennomføringen går på skinner. Dette er sant, gitt noen rammebetingelser nemlig at vi

a) er i stand til å overskue og forstå problemet gjennom analyser og

b) har en grad av stabilitet underveis slik at forutsetningene vi må legge i starten ikke endrer seg

Men hvor godt fungerer denne tankegangen for IT-prosjekter? Har vi disse rammebetingelsene? Klarer analyser å gi oss den nødvendige forståelsen og har vi denne stabiliteten?

I offentlig sektor skal IT-prosjekter gjennom kvalitetssikringsmilepælene KS1 og KS2. Dette representerer to nivåer av beslutningsgrunnlag – for å sikre at vi bruker penger på prosjekter som gir større nytteverdi enn de koster. Dette er svært rigorøse og omfattende prosesser. I moderniseringsprosjektet til NAV kan vi lese et 177-siders dokument som er kvalitetssikringen av KS1 – konseptvalg (Takk til Tom Gilb som viste meg dette). Det er lett å se at dette skal bli et gigantprosjekt! Nesten et år senere (april 2012) kommer KS2-av prosjekt 1 et dokument på ca 100 sider. Deretter skal prosjektet utlyses på anbud, løsningsbeskrivelser og kravspesifikasjoner skrives osv.. Vi snakker 3-4 år før noen begynner å lage en kodelinje. Nå vet vi jo også fasiten – prosjektet ble stoppet og 3-4 år av moderniseringen gikk tapt. Pluss noen hundre millioner kroner. NAV-direktør Joachim Lystad uttaler i 2015:

Hovedårsaken til det var at det i 2010 ble planlagt å kombinere ny saksbehandlingsløsning for Nav med en løsning for uførereformen. Det viste seg å være feil.

En antagelse tatt for mange år siden fikk med andre ord leve lenge i prosjektet før man fant ut at den var feil…

Systemet legger opp til følgende håndtering av risiko: Jo større prosjekter, desto grundigere analyser og forarbeide. Samtidig vet vi at de som gjør dette forarbeidet er spesialister på nettopp dette – så de vil sette sin ære i å gjøre dette grundig og komplett. Vi vet jo også at de konsulentselskapene som leverer analysene vil ha noe å tjene på at omfanget blir stort. Derfor ser vi gang på gang at noe som i utgangspunktet er stort, lett blir enda større i analysefasen! Det er mange krefter som spiller inn her, blant annet a alle interessentene vet at det blir lenge til neste prosjekt, så de vil presse på for å komme med i prosjektet – og det blir enda større! Vi må også være klar over at verden rundt oss er omskiftelig og dynamisk, slik at sannsynligheten for at antagelser rekker å bli utdaterte allerede mens vi analyserer og planlegger er stor…

storSatsning

Uheldige virkninger av grundig, tidkrevende forarbeid

Og så kommer MilliardKronerSpørsmålet: “Hvor gode betingelser har et slikt prosjekt for å lykkes?” Ikke så veldig gode. Det finnes mange studier som analyserer IT-prosjekter. Disse er ikke alltid samstemte, bortsett fra en ting: Samtlige advarer mot å kjøre store prosjekter!

Vi som har vært ute en vinterdag eller to ser dette lett. IT-prosjekter er komplekse og for mange overraskende vanskelig å spesifisere korrekt på forhånd. Til det er behovene for ulne og abstrakte, og antall krav får fort en uhåndterlig størrelse. Dessuten blir selve prosjektet selv et svært komplekst, dynamisk sosialt system. Og til alt overmål har vi dynamikken, de uventede hendelsene (som vi vet kommer) og ønsket om innovasjon.

StortProsjekt

Store prosjekter kommer fort inn i en ond sirkel med økende kompleksitet og liten tid til innovasjon

NoThanks

Innovasjon betyr blant annet å ta vare på de gode ideene og mulighetene som oppstår underveis.

Alle disse sammenhengene skulle borge for å forsøke å unngå store prosjekter. Men disse sammenhengene er på en måte ikke det mest skremmende! Det mest skremmende er at i store prosjekter med få leveranser, vil feilaktige antagelser få lov til å leve alt for lenge. Dette er et system uten feedback, uten læring slik at den akkumulerte økonomiske risikoen blir skyhøy! Vi vet per definisjon ikke om det har vært vellykket før leveransen er idriftsatt og vi kan analysere hvordan den faktisk fungerte i praksis.

“The proof of the pudding is in the eating”

Britene vet at det er overraskende vanskelig å lage en perfekt pudding. Vi vet ikke om resultatet ble vellykket før puddingen er ferdig. Akkurat på samme måten er det med IT-prosjekter.

KostRisikoVannfallPudding

Dette innebærer at jo lengre vi venter med å fullføre noe, desto større akkumulert økonomisk risiko tar vi. Dette er jo innkjøpere og prosjekteiere klar over, men resepten med å analysere enda grundigere for å minske risikoen duger altså ikke. I stedet kan vi ta virkeligheten på alvor og akseptere usikkerhet og risiko.

Vi kan lære oss å surfe på bølgen som kommer i stedet for å forsøke å stoppe den – det er en bedre strategi å forsøke å forstå og beherske naturen enn å prøve å motvirke den.

Om vi deler opp problemet i små biter og legger opp til mange små leveranser kan vi oppnå flere ting. Vi vil da kunne “smake på puddingen” og validere resultatet om igjen og om igjen og på den måten absorbere risikoen.

KostRisikoSmidigPudding

Løpende validering av antagelser for å unngå å akkumulere opp risiko

Figuren viser hvordan vi ved å levere resultatet i små inkrementer vil kunne “spise opp risikoen” underveis. (Enkelte ganger -hvis nyhetsgraden er stor – vil det første trinnet måtte ta noe lengre tid enn de andre. Dette trinnet kan også romme forretningsutvikling). Dessuten vil vi i dette regimet ha mye bedre betingelser for innovasjon. Her er det unødvendig å ha et ferdig omfang på forhånd, siden vi hele tiden får feedback og kan la detaljene bli til underveis. Vi kommer ikke på etterskudd for det er ikke inngått forpliktende, langsiktige løfter. Nå ser vi at det er rekkefølgen vi løser problemet i som blir avgjørende. Vi spør oss hele tiden “hva er det neste vi skal lage som vil gi oss maksimal validering av antagelser?“. Dette regimet er altså basert på en løpende finansiering. Vi validerer resultatet og gjør kost/nytte vurderinger hele tiden. Gevinstrealiseringen er innbakt i prosessen. Vi manøvrerer her i usikkert farvann i stedet for å låse oss til en fast kurs – og håpe det beste.

På denne måten ser vi at vi fint kan “slippe unna” med langt mindre forarbeide, siden vi insisterer på å ikke ta på oss store økonomiske forpliktelser. Om sponsorer og eiere gjennom feedbacken finner ut at det er riktig å avbryte (enten fullstendig eller for å justere kursen), så må de ha mulighet til det. Kunsten å stoppe i tide er avgjørende!

 

 

Posted on September 25, 2015 at 3:18 pm by gamsjo · Permalink · Leave a comment
In: inkrementell utvikling, kompleksitet, ledelse, Planlegging, Samfunn · Tagged with: , , , ,

Er Scrum kompleks?

Scrum
 
Når jeg holder kurs åpner jeg ofte med å si at Scrum er et enkelt rammeverk som tilbyr “minst mulig struktur” for å organisere kunnskapsarbeid på en effektiv måte. Det er noen få regler, 5 verdier, 5 møter, 3 roller og 3 artefakter. Det baserer seg på agilemanifesto.org, støtter seg på Lean-tankegangen og baserer seg på empirisk prosesskontroll i iterasjoner på 1-4 uker.

Jeg sier også at det lønner seg å “ta hele kuren” og implementere Scrum etter boka og vinne erfaring, deretter å eksperimentere med egen prosess slik at arbeidsformen gradvis blir mer og mer optimal. Om man klarer å gjennomføre Sprint planlegging på 30 minutter så er det selvsagt greit (selv om angitt timeboks er 2 timer). Om man klarer seg med en halv time i uka til Produktkøraffinering er det også i orden. Scrum pålegger deg selvsagt ikke “overhead”, for i bunn og grunn er dette en prosessforbedringsprosess. Hvis noe ikke gir verdi er det “waste” og skal bekjempes. Jeg støtter meg her på Core Scrum fra Scrumalliance, men Scrumguiden fra Scrum.org forteller det samme.

(For ordens skyld: Det er ikke noe i veien for å levere mange ganger i løpet av en iterasjon, eller å kombinere Scrum med Lean Startup sin “Build-Measure-Learn” eller DevOps)

Men alt er selvsagt relativt, og vi som steller med Scrum er vant til at de som sverger til Kanban forteller at Scrum er rigorøs og kompleks og medfører overhead. I BEKK sin ferske “teknologiradar” kan vi for eksempel se at de anbefaler å avstå fra Scrum, men heller vurdere gammeldags prosjektstyring..

Jeg har hørt Kanban-faderen selv, David J Anderson, presentere Kanban ved flere anledninger, og det slår meg at han ikke evner å forklare Kanban uten å sammenligne det med Scrum (der alt ved Scrum får negativt fortegn). Kanban er opplagt enklere og mindre rigorøst enn Scrum, siden det ikke definerer hverken roller eller aktiviteter. Samtidig er Scrum langt enklere enn Rational Unified Process og f.eks ITIL. Eller Prince2 for den saks skyld. Figuren under (laget av Henrik Kniberg) forteller en del.

Personlig synes jeg Kanban er genialt enkel og når jeg gir råd til organisasjoner sier jeg alltid at det viktigste er at de forstår sin egen kontekst, sine egne forretningsmålsetninger og setter seg godt inn i konseptet Agile (hvis dette passer med målene da – hvilket det gjør for de fleste moderne selskaper). Deretter kan de velge rammeverk. Jeg anbefaler å starte med Scrum for det gir konkret støtte til snuoperasjonen. Det tydeliggjør en nødvendig endring, og gir “umodne” organisasjoner en trygghet. For eldre vannfallsorganisasjoner gir Scrum et visuelt bilde og på samme måte et tydelig målbilde. Så kan man etter hvert vurdere å bevege seg i retning av Kanban. Men om de foretrekker å gå rett på Kanban er det også greit. Da starter vi alltid med en verdistrømsanalyse, finner flaskehalser og køer, forenkler og så visualiserer vi ende-til-ende prosessen i et Kanban board.

Spotify er som mange lesere vil vite en svært smidig organisasjon som styres etter noen enkle prinsipper og verdier. De har 80-90 team som lager dette produktet, og alle teamene har frihet til å velge prosessmodell. Interessant nok har dette ført til at de har en salig blanding av Scrum, Kanban og “hjemmebrygg”. Noen team foretrekker de ganske stramme rammene og iterasjonene som Scrum gir, andre vil ha mer frihet og flyten til Kanban. Det samme ser vi i de fleste rutinerte, “modne” smidigselskapene.

BEKK forteller i radaren sin at Scrum er for kompleks for de uerfarne og at “det blir mye nytt å lære seg på en gang”. Seriøst? Jeg har jobbet på heltid med Scrum i over 10 år og sett utallige organisasjoner fomle og feile med Scrum i starten –men det har aldri vært på grunn av at rammeverket er vanskelig å forstå. Selv i norske, uerfarne småfirmaer finner vi faktisk veldig smarte folk. Det de fleste sliter med er heller knyttet til endring av tankesett (mindset), firmakultur og at kunden eller ledelsen fremdeles henger igjen i gamle rutiner. Og Agile er langt vanskeligere å forstå godt nok enn det Scrum er.

Jeg møter fra tid til annen svært erfarne, dyktige software-utviklere som fnyser av Scrum. De nyter stor respekt i egen organisasjon og har klart seg utmerket i tiår uten disse seremoniene og strenge iterasjonene. De ser ikke verdien av tett, tverrfaglig teamarbeid og føler ubehag av å stå og snakke i detalj om hva de skal gjøre og hva de har av problemer hver dag. Jeg kan skjønne dette. Jeg kan skjønne at disse foretrekker Kanban, som (i hvert fall tilsynelatende) gir rom for å fortsette som før.

Argumentet om at Scrum medfører overhead er underlig. Det er alltid rom for eksperimentering, optimalisering og å utfordre Status Quo så lenge man gjør dette som team og i lys av en strukturert prosessforbedringsprosess (Scrum retrospective). “Medfører” egentlig et rammeverk noe som helst? Må man ikke uansett selv ta ansvaret for egen prosess?

 

Posted on September 6, 2015 at 3:42 pm by gamsjo · Permalink · 2 Comments
In: Scrum · Tagged with: ,

Motiverte medarbeidere – 7 tips

Dette er en oppfølging av forrige post kalt Den indre motivasjonen.

katedral

Mary Poppendieck fortalte en gang en historie som jeg ofte bruker når jeg holder kurs. Den går omtrent slik:

En filosof gikk og vandret i fjellene nord i Italia og kom over tre menn som stod og hugget sten. Han gikk bort til den ene og sa “hei hva holder du på med?” Svaret kom kort og litt bryskt “er du blind, ser du ikke at jeg hugger stein?” OK, filosofen skynder seg bort til neste mann og stiller det samme spørsmålet “hva holder du på med?” Svaret denne gangen var noe helt annet; Han sa “jeg har en familie nede i dalen som trenger mat, så jeg står her og tjener til livets opphold”. Interessant, tenkte filosofen – et helt annet perspektiv på akkurat samme jobben! Så går han til siste mann og spør igjen “hva holder du på med?” Svaret denne gangen var episk: “jeg bygger en katedral” sa mannen.

Hvem av disse tre tror dere vil lete etter de beste stenene? Hvem vil legge sjela si i at arbeidet blir utført så godt som mulig? Svaret er innlysende – katedralbyggeren tenker hele tiden på sluttresultatet og har et betydelig eierskap til dette. Han vil gjerne yte det lille ekstra for å ende opp med en finest mulig katedral!

Alle jeg snakker med om systemutvikling er opptatt av kvalitet, særlig ledere. Men hvordan kan vi øke sannsynligheten for at kvaliteten blir ivaretatt tvers igjennom? Jo selvsagt, vi trenger katedralbyggere! Men hvordan får vi tak i disse? Kan vi gjøre steinhuggere om til katedralbyggere?

Innen kunnskapsarbeid – som for eksempel systemutvikling – er det spesielt viktig med katedralbyggere. Årsaken til dette ligger i kompleksiteten til arbeidet, ønsket om innovasjon og ikke minst at kvaliteten (på programkoden) er svært vanskelig å måle. Så, når vi klarer ikke å “spesifisere” høy kvalitet, blir vi avhengige av at de som gjør jobbe vil levere høy kvalitet.

Høy kvalitet og god håndtverksmessig standard er altså helt avgjørende for sluttresultatet, særlig på lang sikt. Katedralbyggeren vil insistere på å ta tiden som trengs for å bygge inn kontinuerlig integrasjon, automatiserte enhetstester og regresjon. Han vil gjøre kodereview eller jobbe i par. Og han vil re-faktorisere designet slik at koden til enhver tid er godt strukturert og lett for andre å sette seg inn i. Katedralbyggeren vil jobbe tett sammen med de ulike brukerne av systemet og forvisse seg om at vi har forstått deres egentlige behov. Katedralbyggeren vil ha en klar visjon og det nødvendige overblikket som skal til for å ta gode avgjørelser underveis.

Man kan si at katedralbyggeren er opptatt av å tilfredsstille brukerens behov, mens steinhuggeren er opptatt av å tilfredsstille kravstillerens krav (med så liten innsats som mulig).

Vi har altså slått fast at det er den indre motivasjonen som er verdifull, og at forsøk på stimuli i form av insentiver (ytre motivasjon) kan virke mot sin hensikt. Og vi har slått fast at motivasjon er knyttet til autonomitet, mestring og hensikt. Her kommer noen tips til hva vi kan gjøre.

7 råd for å skape katedralbyggere

Råd 1: De som skal gjøre jobben er med på å utforme visjonen. En god visjon er formulert på en lettfattelig, kortfattet måte og inneholder den viktigste informasjonen teamet trenger for å ta de nødvendige beslutningene underveis. Utviklingsteamet må med andre ord på plass veldig tidlig i et utviklingsløp.

Råd 2: Tett, løpende samarbeide med brukerne. Identifiser ekte brukere som er representative og som har et brennende ønske om å få løst noen problemer, så godt og raskt som mulig. Definer noen møteplasser der brukerne og de som lager løsningen kan være kreative sammen. Dette fører til et uvurdelig eierskap.

Råd 3: Husk bekreftelse! Vi trenger jevnlig å få bekreftet om vi er på rett vei – eller ikke. Det er veldig motiverende å få se smilet i ansiktet til en fornøyd sluttbruker! Samtidig må vi også få høre den brutale sannheten når vi har bommet. Kan vi få rask og målbar feedback på jobben vi har gjort, vil alle involverte få et dypt eierskap.

Råd 4: Legg til rette for øving! For å bli virkelig gode i noe trenger vi å repetere – noen ganger til det kjedsommelige. Om vi klarer å splitte opp arbeidet på en slik måte at vi stadig får analyserbare delresultater, kan vi gradvis perfeksjonere arbeidsprosessene, metodene og verktøyene vi bruker. Dette at hele teamet ser en kontinuerlig forbedring gir en uvurdelig mestingsfølelse – og motivasjon.

Råd 5: Tverrfaglighet. Kunnskapsarbeid er teamarbeid, og disse teamene vil alltid bestå av folk med ulik faglig spesialisering. For å oppnå sterkt eierskap hos flest mulig må vi dyrke det tverrfaglige teamarbeidet, fremfor å fokusere så mye på roller. Hvis vi lar de faglige siloene få leve vil vi ikke oppnå det kollektive eierskapet. Konsekvensen av dette er at de som bemanner teamene oftere må ut av både sitt faglige spesialfelt og sin komfortsone! Mye av den spennende innovasjonen skjer i skjæringspunktet mellom fagfelt.

Råd 6: Selvorganisering. La teamene få størst mulig autonomitet. Gi dem tillit og herredømme over deres egne arbeidsprosesser, metoder og verktøy! Behandle folk som voksne, positive, ansvarlige mennesker – og du vil få – voksne, positive, ansvarlige mennesker…

Råd 7: Slakk. Det ultimate beviset på tillit man kan gi et selvorganisert team er å unngå å presse på for å få framdrift. Når teamet opplever i praksis at de har tid til å ta vare på de gode ideene og til å perfeksjonere arbeidsprosessene sine kan vi være temmelig sikre på at den indre motivasjonen blir rotfestet.

Folk er forskjellige og det finnes sikkert mennesker som er “naturlige katedralbyggere” og det finnes nok også “notoriske steinhuggere”. Kunnskapsorganisasjoner trenger en god andel katedralbyggere, men kan også leve med at enkelte på et team er steinhuggere.

Tiltak

Det peker seg ut en del helt konkrete tiltak en ledelse kan begyne å jobbe med for å skape en høymotivert organisasjon. Dette må gjøres gradvis (kjør en “pilot” på et spesielt område) og vil nødvendigvis ta tid. Her kommer noen forslag til konkrete ting å starte med:

Unngå overleveringer – bygg ned siloene og “prosessorienteringen”. Lag i stedet en struktur der nederste nivået er robuste, permanente tverrfaglige team.

Unngå for mye spesialisering – dyrk teamarbeidet og utvikle medarbeidere som er teamorienterte og både spesialister og generalister.

Unngå detaljstyring – skrot de detaljerte prosedyrene, stillingsinstruksene og KPIene. Gi i stedet teamene den støtten de trenger for å komme i gang med selvorganisering.

Unngå insentiver – gi i stedet medarbeiderne ansvar og stimuler til eierskap. Sørg for at alle har en god lønn, slik at dette temaet får minst mulig oppmerksomhet.

Posted on August 30, 2015 at 2:47 pm by gamsjo · Permalink · Leave a comment
In: ansvar, Endringsledelse, Lean, ledelse · Tagged with: , , , ,

Den indre motivasjonen

Vi som jobber med smidig systemutvikling og prosessforbedring tar ofte til orde for at folks indre motivasjon er uhyre verdifull. Både fordi det gir bedre arbeidsplasser (selvfølgelig), men også fordi sluttresultatet antageligvis kan bli vesentlig bedre på den måten.

Når Dan Pink i 2011 publiserte Drive – The Surprising Truth About What Motivates Us falt brikkene på plass for meg. Jeg har vært der selv og jeg har sett det med egne øyne – folk som virkelig bryr seg leverer vesentlig bedre arbeid enn de som er mest opptatt av å heve lønn. Og hva er det som får folk til å virkelig bry seg? Autonomy, Mastery and Purpose er Dan Pinks kortversjon – og som det er lett å slutte seg til. Folk som får involvere seg i sluttresultatet og får herredømme over sine egne arbeidsprosesser vil få et eierskap og utløse den verdifulle, indre motivasjonen.

Her hjemme har jeg lenge fulgt BI-professor Bård Kuvaas som lenge har forsket på motivasjon og belønning. Han bekrefter på mange måter alt det Dan Pink sier – incentiver (ytre motivasjon) kan fortrenge den indre motivasjonen og virker således imot sin hensikt(!) Dette er særlig fremtredende ved kunnskapsintensivt arbeid – som jo systemutvikling i høyeste grad representerer. Jeg anbefaler alle å bruke en time på dette utmerkede foredraget Kuvaas nylig holdt om temaet:

Her blir disse fenomenene ytterligere styrket gjennom forskning og en nylig publisert metastudie med totalt over 200.000 bidragsytere.

Jeg mener systemet vi jobber i vil kunne stimulere til – eller komme i veien for – den indre motivasjonen. Ikke overraskende ligger de smidige metodene veldig godt an her. Dette gir jo nettopp en situasjon der de som gjør jobben opplever autonomitet, med eierskap til visjonen, selvstyrt teamarbeid og tett, direkte kontakt med kunden. På samme måten ser vi at tradisjonelle systemer (som for eksempel prosjektstyring) fører til fremmedgjøring, lang avstand til beslutningene, liten grad av tillit og ansvarsfølelse.

Så hva gjør ledere i privat og offentlig sektor med denne svært overbevisende forskningen? Alle ledere i kunnskapsorganisasjoner bør spørre seg: Hvordan utløser vi denne verdifulle, indre motivasjonen?

Posted on August 28, 2015 at 3:40 pm by gamsjo · Permalink · One Comment
In: ansvar, Forskning, ledelse, Samfunn, selvorganisering · Tagged with: , , ,

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 · 4 Comments
In: Forskning, kompleksitet, Scrum · Tagged with: , , , ,

Blinde og seende systemer

Kanskje litt off-topic, men den våkne leser vil se at det er spor av både Lean og Smidig her. Dette er fra virkeligheten.

 

Vi får en stadig økende andel eldre i Norge, og samfunnet har forpliktet seg til å ta seg av disse når de av ulike årsaker ikke klarer seg helt på egen hånd. Det er kommuner og bydeler som har dette ansvaret, og det er en trend at man ønsker at de eldre bor lengst mulig hjemme, framfor å tilby dem plass på eldre- eller sykehjem.

Elsa er 83 år og nylig blitt enke. Hun har diverse plager og begynner å bli dement, men klarer seg brukbart i hverdagen så lenge hun slipper å bevege seg ut av leiligheten som hun trives godt i.

Bydelen setter i verk følgende tiltak:

  1. Praktisk bistand
    • innkjøp av mat og annet én gang i uka
    • husvask annenhver uke
  2. Hjemmesykepleie med besøk tre ganger daglig for å sørge for medisinering og matinntak.

Etter noen uker merker pårørende som kommer på besøk (ca én gang per uke) at ikke alt er som det skal. Det er spesielt én essensiell ting som mangler, nemlig kaffe. Hun drikker mange kopper per dag. Dessuten oppdager pårørende at det begynner å lukte vondt i kjøleskapet, og ganske riktig der finner de mat som er i ferd med å råtne og mugne. I det hele tatt er kjøleskapet veldig fullt, urent og uappetittelig.

Hva er det egentlig som skjer her?

 

Et blindt system

blind

For det første må vi tenke over at dette gamle mennesket er dement og er dessuten kresen i matveien og har dårlig matlyst. Alt dette er vanlig. En annen ting å være klar over er at mange eldre mennesker helst ikke vil “være til bry”. Så på direkte spørsmål om hva hun mangler av matvarer vil ofte svaret være “jeg tror ikke jeg trenger noe, jeg”.

Så hva gjør hjemmehjelperen da? Improviserer, selvsagt. Kjøper inn noe enkel middagsmat og pålegg i håp om at det treffer noenlunde godt. Dette kan fungert fint over tid hvis en viktig faktor er til stede: nemlig at den samme hjemmehjelperen kommer tilbake neste uke. Hun ville da med egne øyne kunne se hva som var spist og hva som ikke ble spist. Hun ville gradvis i løpet av noen uker funnet et mønster i forbruket og kunne tilpasset innkjøpene deretter. Hun ville også sett at kaffeforbruket var stort og forstått at her må det storinnkjøp til.

Men denne forutsetningen er ikke til stede. Hjemmehjelperne rullerer – de befinner seg i en ressurspool og vil kunne få ulike ruter og sett med brukere fra uke til uke. Så det kan gå mange uker til den samme personen kommer tilbake. Hun vil da ikke få noen informasjon om forbruket ved å se inn i kjøleskapet, og vil da sannsynligvis fortsette å kjøpe inn matvarer som bare ble liggende til det blir kastet.

Hva så med hjemmesykepleierne som skal sørge for at hun får i seg næring? De har ingen enkel jobb her. De er jo prisgitt det de finner i kjøleskapet. De vil stadig oppleve at Elsa ikke har lyst på den maten de finner tilgjengelig. Og de finner bedervet mat i kjøleskapet som bare må kastes. Men heller ikke hjemmesykepleierne finner noe klart mønster her, for de rullerer også. Det kan gå mange dager mellom hver gang en pleier besøker henne.

Elsa stakkar blir tynnere og tynnere, selv om hun bruker mye penger på mat. Og hun blir dehydrert.

Det er tydelig at pleierne og hjelperne i dette systemet ikke er i stand til å finne mønstre (ingen kritikk av pleierne og hjelperne). De ser ikke konsekvensen av sine egne handlinger og besutninger. De opererer uten feedback og læring. De famler rett og slett blinde.

 

Å lære seg å se

eyes

Blinde systemer kan gjøres seende. Det er faktisk ganske enkelt å foreslå tiltak for å bøte på problemet.

Mulig tiltak 1:

Det mest åpenbare er å pålegge hjemmesykepleien og hjemmehjelperne å snakke sammen. Da vil jo de som sørger for at hun spiser lett kunne bygge opp en standard handleliste og de kunne be om påfyll av varer ved behov. Men dette er vanskelig i praksis siden hjemmesykepleien og hjemmehjelperne tilhører forskjellige enheter. Og det vil uansett  ikke gå av seg selv, siden det det er så mange forskjellige personer involvert hele tiden. Så her måtte det bygges opp et system som ville hatt en kostnad. Slike kostnader må tas fra samme hovedbudsjett og således gått utover tilbudet.

Mulig tiltak 2:

Omorganisere, slik at det er fast personell som kommer og yter tjenester til sine faste brukere. Da får disse en kontinuitet og vil selv kunne erfare hvilke særegne behov hver av sine brukere har.

Sykepleierne ville lære seg brukerne mye bedre og kjenne og ville lettere kunne følge med på vektutvikling og andre helseparametere og ville lettere kunne satt inn tiltak om det var fare for underernæring.

Hjemmehjelperne ville fra uke til uke bygd opp erfaring for hva slags varer som ble brukt opp og hva som ikke ble konsumert.

Vi har her et “seende system” som vil kunne bli langt mer treffsikkert i forhold til brukernes behov. Uten ekstra kostnad.

Mulig tiltak 3:

Det mest radikale og mest treffsikre tiltaket er (selvsagt) at de som sørger for mat også handler. De har jo første hånds kunnskap om behovet både på kort og lang sikt. Om vi et øyeblikk legger bort tanker om profesjon og rolle, forstår vi lett at dette er den mest treffsikre løsningen; Et tverrfaglig system.

En bieffekt av dette vil være at handlingen vil kunne ta mindre tid. Husk at de som har handling som eneste jobb, først må besøke Elsa og finne ut hva de skal handle og få med seg kontanter fra Elsas pung (det er slik det fungerer). Deretter reise ut for å handle. Om de som har første hånds kunnskap om behovet også handlet, ville de lett kunne svippe innom butikken på veien til henne og dermed slå to fluer i ett smekk! På denne måten kunne handlingen vært mer behovsstyrt både ut fra brukerens behov og hjelperens kapasitet. Dette er flyteffektivt og ikke optimalisert for ressurseffektivisering.

Posted on February 13, 2015 at 6:15 pm by gamsjo · Permalink · 4 Comments
In: ansvar, Lean