Å planlegge for det ukjente

Hvor langt kan vi se klart?

Erkjennelsen om at fremtiden er høyst usikker synker inn hos de fleste. Heldigvis. Vi vil opplagt tjene på å ha et realistisk syn på den virkeligheten vi befinner oss i. Hvilke konkrete implikasjoner har denne usikkerheten på måten vi setter mål, lager strategier, planlegger og følger opp? Og har det følger for hvordan vi bør organisere oss?

Virksomheter vil fortsatt sette seg store, ambisiøse mål som vil ta lang tid å oppnå. Vi må selvsagt fremdeles lage planer for dette.

En slik plan vil måtte basere seg på antagelser og forutsetninger. En leder- eller styringsgruppe bør nå snarest stille seg noen vitale spørsmål:

Det er altså en grense for hvor lenge en langtidsplan har verdi. Problemet er at den ofte vil få leve alt for lenge! Det er tross alt investert arbeid, penger og prestisje i denne planen. Dessuten har vi en tendens til å innbille oss at vi har med kontroll enn vi har grunnlag for.

“It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.”

Mark Twain

Så vi reagerer alt for ofte alt for sent.

Den ene, lineære langtidsplanen har altså utspilt sin rolle. Hvordan ser et mer realistisk planleggingsbilde ut da? Slik?

Å navigere mot mål i bevegelse

Jeg vil her ta til orde for 5 essensielle tankesett for vellykket planlegging i dagens virkelighet:

  1. Hold opsjoner åpne
  2. Innhent status basert på fakta
  3. Unngå indirekte kommunikasjon
  4. Bygg inn retrettmuligheter
  5. Endring er positivt

1. Hold opsjoner åpne

Det vil fremdeles kunne ta år å oppnå ambisiøse mål. Samtidig må vi ha stor ydmykhet i forhold til at forutsetninger kan endre seg underveis, slik at vi må endre mål og strategi. Og kanskje terminere først som sist før vi bruker for mye tid og krefter på noe som ikke har livets rett.

Så det første budet er altså å unngå å låse seg for tidlig. Det er i prinsippet to ulike måter å oppnå dette på

A) Løs problemet i korte, etterfølgende iterasjoner der flest mulig er egnet til å få realitetssjekket forutsetninger.

B) Jobb fram ulike løsninger i parallell, før en av disse velges.

Disse to strategiene kan utmerket godt kombineres. A) legger til rette for å raskt (og billig) få gjort en avsjekk på om vi er på vei mot et godt resultat. En “bieffekt” av denne fremgangsmåten er at gevinster kan realiseres tidlig og deretter fortløpende. B) vil naturlig nok koste en del og kan være egnet der usikkerheten er spesielt stor. I en tidlig designfase på et større delproblem vil man på denne måten kunne gjøre A/B testing eller Set based design for å validere ulike mulige valg opp mot hverandre.

Det er her fornuftig å se på valgmuligheter som verdifulle. Chris Matts og Olav Maassen argumenterer godt for dette under Real Options i boka Commitment :

Options have value

Options expire

Never commit early unless you know why.

I klartekst betyr dette at vi må holde planer og spesifikasjoner åpne så lenge som mulig. Langtidsplaner må ikke oppfattes som forpliktende. Dette er jo akkurat det smidige metoder som Scrum legger opp til. Omfanget er en kø med elementer som realiseres i en prioritert rekkefølge. Denne køen er ikke “komplett”. Løsningen leveres i små inkrementer som hele tiden integreres i totalproduktet.

Unngå dette: Definert prosesskontroll, tradisjonell prosjektstyring, grundig analyse og planlegging, separate roller.

Forsøk i stedet dette: Empirisk prosesskontroll, Lean Start-up, Scrum og permanente, tverrfaglige, selvstyrte team.

2. Innhent status basert på fakta

Vi må altså unngå å la antagelser få leve for lenge. Problemet er at det er svært krevende for de som er midt oppe i en problemstilling å vurdere disse på en objektiv måte. Man blir alt for lett “forelsket i ideen sin” og mister nødvendig kritisk sans.

Alle prosjekter baserer seg på en rekke mer eller mindre velfunderte antagelser. Hvor mye verd er utsagnet Status er “på plan” – hvis dette baserer seg på antagelsene om at brukerne aksepterer brukergrensesnittet, at systemet tåler mange samtidige brukere, at sikkerhetsløsningene er gode nok og at lite endrer seg underveis?

Så hva er alternativet? Jo det er lett – bare overlat dette til brukerne. Vel, det er ikke nødvendigvis lett, men ekte brukerne er en alt for lite benyttet ressurs.

I en oppstartsfase trenger vi å eksponere noe håndfast til et antall potensielle brukere. Disse første inkrementene kan godt være prototyper, så lenge vi kan få svar på grunnleggende spørsmål som “sett at denne var helt ferdig, er dette noe du kunne tenke deg å betale for?” eller “hva må vi gjøre med denne for at du vil bruke den?” På denne måten forsøker vi å validere selve ideen. Når vi så har kommet lenger og har levert noen “ekte produktinkrementer” må vi forvisse oss om at brukerne faktisk tar det i bruk i et slikt omfang vi håpet. Spørsmål som “hvor mange faste brukere må vi ha før vi er rede til å finansiere videre satsning” blir da helt avgjørende.

Når vi så har opparbeidet en kundebase kan vi logge brukeradferden i mer detalj og få rikelig med fakta å styre videre framdrift i forhold til. “Har vi tilstrekkelig mange førnøyde kunder nå til at vi skal skalere ytterligere opp?”

3. Unngå indirekte kommunikasjon

Det er altså helt vesentlig å ta beslutninger raskt, basert på faktisk status. Så hvordan designer vi raske, trygge beslutningsprosesser? Hvordan sikrer vi at de som faktisk fatter beslutninger er tett på virkeligheten og ser bildet klart? Hvordan minsker vi gapet mellom strategisk og taktisk nivå?

Det optimale er helt opplagt at de som sitter tett på brukerne og som samtidig er oppdatert på trender og teknologiutvikling bidrar sterkt i beslutningsprosessene. Ledergrupper er alt for ofte langt unna “den virkelige verden” og må basere seg på rapporter som forenkler virkelighetsforståelsen. Noen ser bare tallene, uten å ha grunnlag for å forstå hva som ligger bak disse.

Ergo; raske beslutninger må fattes av tverrfaglige, operative team. Kundesupport, drift, utvikling, test, markedsføring vil alle ha sine verdifulle perspektiver. Når et slikt team har kommet til en konklusjon må de kunne iverksette raskt. Noen tiltak vil utgjøre mindre justeringer slik at ledelsen bare trenger å informeres. Andre tiltak kan utgjøre en strategisk retningsendring, som naturlig nok må godkjennes (raskt) av ledelsen.

Om beslutninger skal fattes effektivt av operative team, må disse naturlig nok ha en like klar målforståelse som ledelsen. Så her er det ingen vei utenom å involvere bredt når nye strategiske mål og visjoner skal meisles ut. Dersom tverrfaglige team har et solid eierskap til selve visjonen de jobber mot vil de i stor grad kunne styre seg selv. Gjør som google og forsøk å gi tverrfaglige team best mulige betingelser for å lykkes.

Både hierarkier og fagorienterte avdelinger (“siloer”) fører til indirekte kommunikasjon, noe som igjen vil føre til misforståelser, kødannelser, sub-optimalisering og forsinkelser. Disse tradisjonelle mekanismene må aktivt bekjempes dersom man ønsker å skape en endringsdyktighet.

4. Bygg inn retrettmuligheter

Løsningene som fører fram mot målet må være fleksible av natur, slik at det ikke koster alt for mye å gjøre om på det som allerede er laget. Det er klart at en strategisk retningsendring vil ha en kostnad i form av at noe utført arbeid vil måtte “kastes” eller gjøres om. Ingen vei utenom dette. Trikset er å bygge opp tjenesten og produktet på en slik måte at ikke alt for mye berøres når ting må endres.

Det finnes utallige måter å strukturere programvarebaserte produkter på. Noen vil hevde at brukerfunksjonene må stå på en solid og veldefinert plattform. Noen vil si at det viktigste er å lage gjenbrukbare felleskomponenter. Andre vil vektlegge autonomitet der løst koblede tjenestemoduler kan operere mest mulig uavhengig av hverandre. Andre vil fokusere mest på svært enkle og veldefinerte API-er. Ikke noe av dette er fullstendig riktig eller galt, men moderne systemer må ta høyde for endringsevne og skalerbarhet. I det perspektivet kan noen basale prinsipper være til hjelp:

Arkitektur laget for fleksibilitet og ikke stabilitet. Ikke forvent at strukturen til systemet vil være stabil i lang tid – forvent at denne må jobbes med hele tiden. Og for all del, unngå at sentrale felleskomponenter får bli så store at selv små endringer får omfattende konsekvenser – og følgefeil – for brukerne av komponenten.

Akseptere duplisering. Duplisering av kode og data virker intuitivt uøkonomisk og skummelt, men må allikevel aksepteres dersom man skal klare å være mer styrt av brukernes behov enn av gamle tekniske valg.

Utnytt skyen. Skyen gir helt nye muligheter for å jobbe i raske sykluser og å unngå at man bli låst fast i egne løsninger som opprinnelig var laget med andre forutsetninger enn dagens for øye.

Rulle raskt tilbake. Når brukerne får noe annet enn de behøver og gir negativ feedback, må vi kunne respondere rask med å korrigere eller evt fjerne det vi lagde. Ta da jobben med å fjerne koden, slik at systemet ikke pådrar seg mer kompleksitet enn nødvendig.

5. Endring er positivt

Når omgivelsene endrer seg må vi altså hurtig tilpasse oss endrede forutsetninger. Hvis vi har på plass punkt 1-4 over vil vi etter hvert se at endringer ikke nødvendigvis er noe problem. Endring gir muligheter. Endring er verdi og ikke kostnad! Vel, endrede forutsetninger kan selvsagt også utgjøre trusler, men en endringsdyktig, robust organisasjon vi kunne omstille seg raskt nok til å utnytte situasjonen.

Når endring kommer inn i “virksomhetens DNA”, vil den begynne å oppføre seg annerledes. Folk venner seg til at vi stadig lærer og det blir tydelig at vi godt kan koste på oss og ta sjanser. Vi kan faktisk utføre små eksperimenter og på den måten teste ut mer eller mindre gjennomtenkte ideer.

Med disse 5 prinsippene på plass vil organisasjonen – offentlig som privat – være rustet for fremtiden og utnytte ressursene bedre enn det som ofte er tilfelle. Hvorfor ikke starte året med å legge en plan for endringsdyktighet?

Posted on February 27, 2017 at 5:44 pm by gamsjo · Permalink · 2 Comments
In: Endringsledelse, ledelse, Planlegging, produkteier, Uncategorized · Tagged with: , , , ,

Fri, eller i bånd?

barcofri3

Barco og jeg liker den fine tiden uten båndtvang i Oslomarka. Fra 20 August til 1 April kan han få svinse fritt omkring på tur. Det å møte andre hunder er alltid spennende og ganske uforutsigbart. Er det en tispe med løpetid? Er det en dominant hannhund? Er det en nervøs, liten gneldrebikkje? Enkelte ganger blir disse møtene kaotiske og det kan bli både gneldring og knurring. Men dette er en del av “gamet” – hunder er veldig fysiske og bruker alle sanser og særlig kroppsspråk for å finne ut av hverandre i slike møter. Det kan se voldsomt og kaotisk ut, men det blir aldri “voldelig”.

Enkelte ganger møter vi hunder i bånd – og det er disse møtene som blir problematiske. Disse hundene er helt klart hemmet av båndet og får ikke møtt løse hunder på en naturlig måte. Men enda viktigere er nok at de ikke har trening i å omgås andre hunder fri. Jeg setter bånd på Barco – når jeg rekker det – i slike tilfeller. Vil ikke risikere et møte med alt for mye aggressivitet.

Det hender jeg slår av en prat med hundeeiere med hunden i bånd, og det viser seg ofte at det bunner i en eller flere dårlige opplevelser i møte med andre hunder. Responsen er altså å skape en fysisk hindring (båndet) for at dette skal kunne skje igjen. For dem er løse hunder problemet. Alt ville vært enklere om hunder alltid gikk i bånd. Og de har for så vidt rett i det, men jeg tror ikke hundene er helt enig…

Frihet i arbeidslivet?

Når mennesker og dyr er fri blir det uryddig og uforutsigbart. Adferden kan bli mer styrt av impulser og relasjoner enn av kvantifiserte mål. Hvor mye frihet skal vi tillate i arbeidslivet?

Ledere på høyt nivå vil forståelig nok helst ha orden og forutsigbarhet. De har et opplagt behov for å skaffe seg informasjon og kontroll uten å måtte dukke ned i detaljene. Dette kan de oppnå gjennom å gi medarbeiderne klare, veldefinerte roller og klare mål. Og i forlengelsen av dette sette kvantifiserte målsetninger som kan følges opp og forbedres kvantitativt. Ledelsen får på denne måten servert en mulighet til å styre organisasjonen numerisk. Dette er målstyring, som er en del av New Public Management (NPM) – Norsk offentlig sektors valgte styringssystem. Dette er forståelig ut fra et rent styrings- og ledelsesperspektiv.

manleash

Skal vi holde saksbehandlerne i stramt bånd, eller skal vi våge å slippe de fri?

Fungerer egentlig NPM og målstyring etter hensikten? Blir det effektivt? Fører det til forbedring? Gir det god styring? Hva med kvaliteten?

Målstyring koster opplagt penger. Man slipper ikke unna et visst byråkrati for å definere, aggregere og følge opp mål. Fagfolk må stadig dokumentere og rapportere sine måltall slik at andelen produktiv tid synker. For leger har trenden vært jevnt nedadgående i en 10-års periode i følge Tidsskriftet.

At målstyring koster tid og penger er kanskje ikke det viktigste ankepunktet. Det største problemet tror jeg er at folk reduseres til lydige roboter og at samfunnet derfor ikke får nytte av kraften til “frie medarbeidere”. En fri saksbehandler har myndighet til å utøve skjønn og har tid til å gjøre en sak helt ferdig. Ikke slik det er i NAV, der saksbehandlere fortviler over at de blir tvunget til å gjøre en dårlig jobb for å oppfylle strenge målkrav. En dårlig jobb betyr ofte at saken ikke blir fullført og vil dukke opp igjen et annet sted i systemet. Dette er dårlig økonomi, og elendig kundebehandling. Men viktigere – dette gjør at saksbehandlerne føler avmakt i stedet for eierskap og stolthet. De fleste vil slutte å bry seg, og heller begynne å pynte litt på tallene for å komme bedre ut. Det beste man kan håpe på i et slikt system et middels resultat.

En illusjon av kontroll

Ledere ønsker seg altså forutsigbarhet og kontroll. Vi må spørre oss om dette er et realistisk ønske i dagens sammensatte samfunn. Verken saksbehandler eller bruker er maskiner – de er levende vesener som har følelser og skaper relasjoner og forståelse seg i mellom. Dette kan være uhyre verdifullt og nødvendig for å komme opp med gode løsninger. Men da må vi altså akseptere en grad av uorden og tillate fagpersoner å utøve skjønn.

blueredpill

Vi kan fortsette å flikke på New Public Management, fornye og forenkle og fjerne tidstyver, men det vil ikke hjelpe stort så lenge grunntanken er basert på en illusjon.

Jeg mener vi snarest må forkaste den blå, søte pillen som gir lederne anledning til å fortsette med dette systematiske selvbedraget. I stedet må vi svelge den litt bitre røde som innebærer å ta realitetene på alvor. Akkurat som at hunders livskvalitet betinger frihet fra bånd må vi innse at tjenestekvalitet bygger på eierskap og frihet til å finne gode løsninger – i tett samspill mellom fagperson og bruker.

Er “prosjekt” alltid riktig verktøy?

Alle er opptatt av digitalisering. Alle er også opptatt av innovasjon. Disse to begrepene er ofte sammenfallende, men ikke alltid. Det er fremdeles tilfeller der digitalisering ikke krever noe særlig nyskapning – oppgaven går i hovedsak ut på å automatisere eksisterende prosesser.

Det vi vil stille spørsmål ved i denne artikkelen er om prosjektet er riktige valg av verktøy for alle digitaliseringsinitiativene. Er det slik at alt må angripes med det samme verktøyet? Hvor godt kan egentlig resultatet bli om verktøyet er det samme hver gang?

Bruk prosjekt der det passer

Prosjektet er en arbeidsform der en midlertidig prosjektorganisasjon får mandat til å gjennomføre en oppgave og å levere et konkret resultat som er definert på forhånd. Dette resultatet går deretter over i en drift- eller vedlikeholdsfase. Eventuelle endringer underveis skal gjennom endringsbehandling der endringen estimeres, vurderes og dokumenteres. En helt fin form for organisering, under visse forutsetninger, der det finnes mye erfaring og en rekke rammeverk og modeller man kan følge. I offentlig sektor har man valgt Prince2  og utarbeidet Prosjektveiviseren som er basert på dette rammeverket. Dette kan fungere godt der det skal gjennomføres en anskaffelse som er veldefinert og der usikkerheten er liten. Og om hovedhensikten er å lage en teknologisk plattform for å støtte en virksomhet, kan man gjerne supplere med virksomhetsarkitektur og TOGAF. Disse rammeverkene er basert på samme grunntanken og fungerer fint så lenge ting er forutsigbart og det blir kun få endringer underveis.

En mer rikholdig verktøykasse

Norsk offentlig og privat sektor behøver en rikholdig verktøykasse som inneholder mer enn prosjektstyring for sine digitaliseringsbestrebelser.

hammerskrue1

Selv om du er god med hammeren er det ikke lurt å bruke den til alt mulig

Med innovative anskaffelser forstår vi anskaffelser med en ganske stor grad av nytenkning og nyskapning. Man skal med andre ord gjøre noe som ikke er gjort før. Lage noe som ikke er lagd før. Er det fornuftig å betrakte slikt som en anskaffelse og et prosjektstyringsproblem? Vi har dyrekjøpt erfaring som viser at prosjekter med stor usikkerhet fører galt av sted. Det blir rett og slett for mange, for dyre endringer underveis – noe som igjen fører til forsinkelser og galopperende kostnader. Det neste som skjer er at man forsøker å ta igjen det tapte gjennom å “jobbe fortere” hvilket fører til dårlig håndverk. Dårlig håndtverk materialiserer seg ikke nødvendigvis i feil og mangler, men ofte gjennom dårlig vedlikeholdsvennlighet. Utviklerne har ikke tid til å rydde i koden og den utvikler seg til en uoversiktelig spaghetti. Tyngre og tyngre å jobbe med. Dessuten vil denne arbeidsformen invitere til at man låser seg i tidlig fase som igjen gjør det vanskelig å utnytte lærdom man vinner underveis.

Verktøykassa for innovasjon

Innovasjon bør som regel angripes iterativt, slik at det blir lettere å utnytte lærdom underveis. Vi må starte med å erkjenne usikkerheten og unngå å låse oss til antagelser. I stedet forsøker vi å utnytte iterasjonene til å validere antagelser slik at vi står på litt tryggere grunn.

drillskrue

Riktig verktøy for oppgaven

En slik iterativ, utprøvende tilnærming er i konflikt med prosjektet slik vi kjenner det. De som forsøker å gjennomføre prosjekter med et fast omfang og mange låste beslutninger i starten, vil nesten garantert gå på en solid smell med galopperende kostnader og forsinkelser. Vi trenger altså et helt annet verktøy.

Vi trenger verktøy og metoder som tillater oss å starte raskere – å ta raskere, bedre beslutninger i oppstartsfasen. Vi trenger verktøy som kan holde flere opsjoner åpne til de er testet ut og validert.  Vi trenger verktøy som legger opp til hyppige, små leveranser som vi lærer av. Vi trenger metoder og verktøy som er brukersentrerte og som i praksis setter brukerne i førersetet. Og vi trenger verktøy som legger opp til en mer løpende finansiering, der også investeringen blir basert på det vi lærer underveis. Slike verktøy bør ikke baseres på Prince2 eller på Prosjektveiviseren slik den fremstår i dag. Ikke en gang på prosjektet som arbeidsform. Nei, til dette trenger vi en tilnærming som starter med brukerens behov og som forutsetter korte iterasjoner med feedback som drivkraft. Dette er verktøy basert på Lean- og Smidig- tankegangen.

iterasjonertversigjennom

Et fremgangsmåte skreddersydd for innovasjon og styring under usikkerhet

Iterativ oppstartsfase

Denne tilnærmingen vil kjøre oppstartsfasen iterativt. Her vil man teste ut både selve idéen og teknologiske valg. Det forutsettes at utviklere (i full tverrfaglighet) involveres tidlig. Metoder og verktøy for dette kan være Bygg-mål-lær (Lean Startup), Behov-Løsning-Test (BLT), Business Model Canvas, User Story Mapping, Impact Mapping, Design thinking og Scrum. For å nevne noen.

Iterativ planlegging og gjennomføring

Når oppstartsfasen (eventuelt) har gitt trygghet for at dette er verd å satse på, skaleres det opp og man iverksetter en løpende planleggingsprosess, en gjennomføringsprosess og en gevinstrealiseringsprosess. Alt dette kan baseres på Scrum, eller andre smidige, iterative rammeverk. Vi gjør her løpende kost/nytte-vurderinger som vil gi grunnlag for å beslutte når vi ikke klarer å tilføre nok ny verdi og det er riktig å stoppe opp og skalere ned igjen. Vi kan ikke på forhånd vite når et IT-system er ferdig utviklet, og det er fornuftig å se på dette som en vedvarende linjeoppgave. Ingen grunn til å skape en kunstig, midlertidig organisasjon når det er fullt mulig å gjøre jobben der hvor gevinstene skal skapes. Særlig når innovasjon basert på IT-utvikling er “Business As Usual”. 

Iterativ finansiering og prioritering

Vi må akseptere at usikkerheten ikke tillater oss å øremerke midler med lang tidshorisont. Dette fører bare til at pengene blir brukt opp og målsetningene (kanskje) oppfylt selv om det i mellomtiden har dukket opp bedre, alternative muligheter. Offentlig finansiering bør snarest ta lærdom av Beyond Budgeting som blant annet legger opp til en mer løpende evaluering av hvilke satsinger som skal prioriteres. Risikoen reduseres og mulighetene for å lære underveis økes.

—-

Flere referanser om svakhetene med prosjekt i IT-utvikling.

BEKK Open: Slutt med IT-prosjekt

Miles blogg: Trenger vi egentlig prosjektledere?

Det smidige hjørne: Prosjektets tre problemområder

INFOQ: If you need to start a project you´ve already failed

Det er lett å finne flere referanser ved å søke på #noproject

Posted on November 11, 2016 at 11:35 am by gamsjo · Permalink · Leave a comment
In: inkrementell utvikling, ledelse, Planlegging, prosjektledelse · Tagged with: , , , ,

The Future of Work – nok prat!

Vi ser stadig artikler og meningsytringer om fremtidens arbeidsliv blafre forbi på de fleste medier. Fellesnevner er store omveltninger. Det er utvilsomt mye i dette, og vi får servert mange ulike drivere for denne utviklingen. Jacob Morgan (thefutureorganization.com) fokuserer på Globalization, Mobility, Millennials, New Behaviours, Technology. Fint og viktig det, men ikke særlig konkret. Mye svada. Andre vil vektlegge mer teknologiske trender som robotisering, maskinlæring, Internet of Things og Big Data. Andre igjen trekker frem selve dynamikken og usikkerheten vi opplever, der få detaljplaner overlever særlig mange måneder. Men hva er så løsningen? Her møter vi en orgie i floskler – noe som for leden toppet seg med den allerede legendariske Purpose-videoen fra Oslo Business Forum. Foredragsholderne fra Brainwells forsøker her på alle mulige og overflatiske måter å gi inntrykk av å være konkrete og to the point – men skaper i stedet en fornøyelig parodi.

Det snakkes overalt om å våge å feile, om raskere beslutninger om omstillingsevnedelegering og eierskap. Men svært få våger å konkretisere hva dette egentlig innebærer. De fleste forståe at vi må minske avstanden mellom strategisk og taktisk nivå, men hvor mange fjerner mellomlederskikter? Når vi innfører eierskap hva skal vi da ta bort?? Hvordan ser en organisasjon som virkelig våger å feile ut? Hva slags organisasjonskutur trenger vi for dette? Hvordan får vi organisasjonen til å naturlig tilpasse seg endringer i omgivelsene? Hva krever det av lederne?

Nå er det på tide å ta dette ned på jorda. Smidigbevegelsen har smidigkonfadressert de samme utfordringene siden millenniums-skiftet, men da på en konkret og operasjonell måte, samtidig som det er forankret i empiriske studier og vitenskap. Eierskap og delegering får vi gjennom å insistere på at jobben skal gjøres i tverrfaglige, selvstyrte team i tett samarbeid med brukerne. Raskere beslutninger får vi både gjennom å kortslutte hierarkiet og gi en produkteier store fullmakter. Vi kan med smidig trygt våge å feile fordi vi jobber i korte iterasjoner og leverer resultater svært ofte.

Kommer du på smidigkonferansen 24-25 oktober kommer du til å få servert svært konkrete historier om hvordan dette kan gjennomføres i praksis. Hovedtema er tverrfaglig teamarbeid.

 

screen-shot-2016-09-21-at-13-30-25

Keynote Speaker Niels Pflaeging: “Organizing for Complexity”

På Smidig i år får du høre om hvordan organisasjoner bør designes ut fra en forståelse av kompleksitet. Samfunnet er preget av en økende kompleksitet, og dette må gjenspeiles i organisasjonenes design. De som gjør jobben må i tett samarbeid med markedet kunne ta selvstendige beslutninger; den tradisjonelle pyramiden vil ikke fungere lenger. Dette vil påvirke planlegging, kvalitetssikring, karriærestiger, belønnningssystemer og ledelsesfaget. Alt dette blir diskutert på årets smidig.

MELD DEG PÅ HER

 

 

Prosjektveiviseren med Scrum

Vanskelig kombo

Vanskelig kombo

Når jeg forstod at Direktoratet for IT (Difi) hadde tenkt å tilby kurs i Prosjektveiviseren med Scrum fikk jeg umiddelbart lyst på denne utfordringen. For utfordrende er det til gangs!

Disse to rammeverkene kommer i utgangspunktet fra to ulike verdener og lar seg ikke i uten videre kombinere på en enkel måte. Scrum er et svært enkelt – og dermed tilpasningsdyktig – rammeverk med noen få klare aktiviteter og regler, definert i Scrumguiden (juli 2016). Det er ikke rom for å endre på Scrum.

Her er presentasjonen om dette temaet fra #SmidigDig.  Her er video av foredraget.

 

Ulikhetene

Prosjektveiviseren er en tradisjonell “Tall-gate” eller “Phase-gate” modell med faser i sekvens. Formelle beslutningspunkter i faseovergangene. Fokus er på “ovenifra-og-ned” styring (virksomhetsstyring, prosjekteierstyring og prosjektstyring). Jeg har selv vært med på å lage slike (for en del år siden).

Virksomheten utreder en idé og utarbeider mulige konsepter. Grundig analyse og planlegging i starten. Deretter starter et prosjekt som lager mer detaljerte planer og analyser og deretter gjennomfører prosjektet iht plan. Prosjektet avsluttes og resultatet overføres tilbake til virksomheten som realiserer de planlagte gevinstene.

Prosjektveiviseren er “dokumentdrevet” og krever at alt som utarbeides lagres i ulike forhåndsdefinerte dokumenter. Kommunikasjonen mellom de ulike interessentene foregår altså i stor grad gjennom dokumenter. Følger man denne veiviseren vil man estimere omfanget for deretter å låse dette. Endringer som kommer etter dette skal gjennom formell endringsbehandling. Veiviseren åpner for at man kan iterere i gjennomføringsfasen, men tar ikke stilling til hyppige eller én enkelt leveranse. Gevinster realiseres – som man lett ser av figuren – på slutten.

Scrum er et enkelt rammeverk for smidig gjennomføring av kunnskapsarbeid – opprinnelig laget for programvareutvikling. Smidig ble definert som en slags motreaksjon mot de plan- og dokumentdrevne, ovenifra-og-ned-orienterte modellene som dominerte i 2001.

Scrum er basert på empirisk prosesskontroll i korte iterasjoner, hvilket innebærer at man trygt kan starte et initiativ uten alt for mye forarbeid. Smidig foreskriver helt eksplisitt at graden av forarbeid må holdes på et minimum. Alle iterasjonene skal resultere i et ferdig produktinkrement som skal evalueres i samarbeid med interessenter/brukere; Skal vi levere det? Er vi på rett vei og kan fortsette, eller må vi justere kursen – eller kanskje avbryte hele satsningen? Og hva fungerte godt som vi skal fortsette med og hva skal vi forbedre i neste sprint?

Scrum baserer seg på at alt arbeid gjøres av tverrfaglige, selvorganiserende team med myndighet til å fatte raske selvstendige beslutninger. Alle team har en Produkteier som vedlikeholder en produktkø – en dynamisk og ordnet liste over det som skal gjøres. I Scrum går kommunikasjonen først og fremst gjennom å skape gjennomsiktighet. Avhengigheter (Impediments) bekjempes, slik at kommunikasjonsbehovet holdes på et minimum. De som behøver å vite status kan enkelt se hva som foregår gjennom alle de hyppige leveransene og gjennom å følge med på produktkøens utvikling. Den mest kraftfulle formen for kommunikasjon skjer ansikt-til-ansikt.

Det er mulig å følge de fleste Scrum-reglene uten å være særlig smidig i henhold til manifestet. Og det er fullt mulig å jobbe i iterasjoner uten å ende opp med et helt ferdig inkrement. Det er selvsagt mulig (og alt for vanlig) å unnlate å forbedre prosessene i hver sprint. Det er fullt mulig å låse omfanget på forhånd, selv om man har til hensikt å lære underveis og forventer store endringer. Og det er fullt mulig å lage team som ikke fullt ut er selvstyrte eller tverrfaglige. Spørsmålet er om det er særlig smart.

Som man nå forstår baserer disse to modellene seg på to ulike tankesett. Med Prosjektveiviserens innebygde tankesett vil vi resonnere “dette kommer til å bli vanskelig og krevende – så her må vi gjøre grundig forarbeid”.

Med smidig tankesett vil vi tenke “dette kommer til å bli vanskelig og krevende – så her må vi komme i gang raskt slik at vi vinner erfaring”.

Ulike leveransemodeller

Det er altså mulig å bruke Scrum uten å være særlig smidig. Dette vil være nødvendig for mange organisasjoner for å komme i gang. Vi må ikke være naive og tro at en tradisjonell organisasjon kan endre tankesett over natta. Dette vil være en evolusjon i retning av gradvis hyppigere leveranser. Derfor kan det være fornuftig å se nærmere på ulike måter å bruke prosjektveiviseren på – alt fra den helt tradisjonelle med en leveranse på slutten, til den smidige varianten der man må gjøre visse grep for å tillate hyppige leveranser og læring underveis. Jeg har kalt dem type 1 til type 4.

Disse typene er ikke tatt ut av løse lufta. Jeg har hatt mange på Scrum kurs (ca 1000 de siste 5 årene) der mange enten jobber i offentlig sektor eller er konsulenter i offentlige prosjekter. Så disse typene er et resultat av det jeg har oppfattet gjennom dialogen i kursene.

Type 1: Basismodellen

Kjennetegn:

Anvendelsesområde: Når brukernes behov og løsningen er godt forstått. Lite endringer underveis.

Utfordring: Stor risiko, da antagelser får leve helt til slutten. Usikker og svært sen gevinstrealisering.

 

Type2: Iterasjoner

Kjennetegn:

Anvendelsesområde: Når brukernes behov er godt forstått. Løsningen er middels godt forstått. Lite endringer underveis.

Utfordring: Stor risiko, da antagelser får leve helt til slutten. Usikker og svært sen gevinstrealisering.

 

Type3: Inkrementer

Kjennetegn:

Anvendelsesområde: Når brukernes behov er middels godt forstått. Løsningen er usikker og trenger utprøving. Lite endringer underveis.

Utfordring: Endring fremdeles kostnad; Galopperende kostnader da endringene som kommer fra lærdommen fra inkrementene lett fører til tillegg.

 

Type4: Smidig

Kjennetegn:

Anvendelsesområde: Innovasjon; Når brukernes behov er uklare og løsningsrommet er åpent og trenger utprøving. Forventer endringer og læring underveis.

Utfordring: Stor endring for hele verdikjeden. Manglende kompetanse på de ulike smidige metodene og teknikkene. Manglende kontinuerlig totalintegrasjon blir smertefullt.

Konklusjon

Man kan velge å bruke Scrum som gjennomføringsmodell på mange ulike måter i kombinasjon med Prosjektveiviseren. Spørsmålet er hva man baserer valget på. Dette kreve modenhet og evne til å gjøre en informert selvevaluering.

Når usikkerheten og kompleksiteten er stor bør man altså gå for Type 4 som nettopp er en problemløsningsprosess for slike utfordringer. Dette er den eneste muligheten for å jobbe smidig. Fremtiden vil kreve utstrakt bruk av denne typen prosesser. Det er fullt mulig å følge en metode til punkt og prikke, uten å oppnå det man ønsker. Gode metoder og rammeverk er fint og viktig, men det er ikke nok. Fremtiden vil kreve at vi tenker på en slik måte at vi lett tar inn læring og endringer underveis.

På kurset Prosjektveiviseren med Scrum vil vi bruke en hel dag på å gå igjennom slike beslutningsprosesser og å drøfte fordeler og ulemper med ulike modeller og tankesett.

Mer info om kurset og påmelding her

 

 

 

Posted on July 15, 2016 at 12:23 pm by gamsjo · Permalink · Leave a comment
In: ledelse, prosjektledelse, Scrum · Tagged with: , , , ,

Slipp aldri brukeren av syne!

Vi lager IT-systemer for å skape gevinster. Noen ganger for å gjøre sluttbrukerens hverdag bedre. Noen ganger for å skape verdier for en virksomhet. Noen ganger for samfunnet. Som regel er det sammensatt.

Man kan si det finnes to alternative tilnærminger for gevinstrealisering:

  1. Den ene har utspring i prosjektstyring og vil ta til orde for planlegging av gevinster i starten av et prosjekt. Her kvantifiseres overordnede mål som brytes ned og danner styringsgrunnlag for selve prosjektet. Når prosjektet så er overstått kommer sannhetens time, der gevinstene skal høstes gjennom at brukerne endrer seg og tilpasser seg nye, forbedrede arbeidsprosesser. Som beskrevet her av Celine Marie Hasle i Sopra Steria. 
  2. Den andre tilnærmingen kommer fra tjenestedesign. Designere har alltid vært ekstremt opptatt av å forstå brukeren godt, før man endelig slipper et produkt eller en tjeneste. De sverger til en utprøvende, iterativ framgangsmåte i tverrfaglighet der brukere er en selvsagt del av prosessen. Veikartet Samveis utarbeidet av KS er et eksempel på en slik framgangsmåte.

Tilnærming nummer 1 kan vi kalle et “push-system“. Gjennom grundige prosesser helt i starten forsøker noen å forstå og beskrive gevinstpotensialet til en satsning. Her vil man forsøke å “tenke på alt” og å skaffe en komplett oversikt over det totale potensialet. I denne prosessen vil det også gjerne ligge i kortene at et stort gevinstpotensial kan øke sjansene for å få tilslag – altså få en budsjettbevilgning til å gjennomføre prosjektet. I en slik tilnærming er det anbefalt å ta med “ekte brukere” på råd i starten der det er hensiktsmessig. Men allikevel ser man stadig at det blir vanskelig å få brukerne med på den nødvendige endringsprosessen for å realisere gevinstene. Dette bør ikke være overraskende med all den empiri og erfaring vi nå har fra IT-prosjekter; Det holder ikke å spørre brukerne. Når brukerne får prøve ut nye løsninger for første gang finner de feil og mangler med en gang, som Johannes Brodwall fra Sopra Steria poengterer her i dette foredraget fra Difis Digitaliseringskonferanse.

GevinstProblemet

Og de lukrative gevinstene lar vente på seg, lar seg ikke realisere. Vi vet dette. Det gjentar seg om igjen og om igjen. “Løsningen” i et slikt push-system er å utnevne en gevistansvarlig som skal følge opp prosjektet basert på gevinstplanen. Når resultatet foreligger skal da gevinstansvarlige gjennom endringsledelse forsøke å få brukerne med på laget til å faktisk endre sine vaner og arbeidsprosesser. Det ligger her i kortene at brukerne ofte er “vanskelige” og lider av endringsvegring. Og – som Mari Vestre fra Difi her påpeker på digitaliseringskonferansen – problemet med for detaljerte planer og krav blir enda større om prosjektet skal ut på anbud, slik at omfanget i alt for stor grad blir låst og løsningen i alt for liten grad harmonerer med brukernes egentlige behov. Vi bør etter min mening forlate denne tilnærmingen innen all digitalisering som fordrer en viss grad av innovasjon.

Tilnærming 2 baserer seg på “pull-prinsippet“, der vi plasserer brukeren i sentrum; Brukerne trekker løsninger ut av prosjektene. Vi retter fokus mot brukerne lar disse i stor grad styre hvordan vi prioriterer – og vi holder dette fokuset hele veien. Vi velger metoder og verktøy som er utprøvende og iterative av natur, og er åpne for at vi kommer til å endre kurs underveis basert på ideer og lærdom vi vinner i tverrfaglighet. Men hva med de andre gevinstene? Det er vel ikke sikkert at brukerne bryr seg om de overordnede innsparingsgevinstene? Nei selvsagt ikke. Vi må ikke være naive og utelukkende fokusere på sluttbrukernes ve og vel. Det smidige tankesettet og Scrum støtter opp under denne tosidigheten. Produkteier prioriterer basert på overordnede mål og kost/nytte-vurderinger, og de leverer svært ofte til brukerne og får tilbakemeldinger slik at de ender opp med løsninger brukerne liker. Og brukerne kan endre seg gradvis, i takt med de små leveransene som de faktisk har endret på selv. Begrenset behov for endringsledelse. Gevinstrealiseringsproblemet er løst! Dette er vel egentlig et ikke-problem som egentlig er skapt av push-tankegangen?

UK CTO, Liam Maxwell

UK CTO, Liam Maxwell

Det er gledelig at Difi i år har satt “Brukeren i sentrum” på digitaliseringskonferansen. Det er på høy tid, “push-prinsippet” har fått råde alt for lenge. I Storbritannia tok de et oppgjør med de store push-baserte IT-prosjektene allerede i 2011 og innførte en obligatorisk pull-modell som starter med utprøvingsiterasjoner tett sammen med brukere: Discovery, Alpha, Beta, Live. Dette er faktisk en forutsetning for å få finansiering.

Dette har vært en gigantisk og svært vellykket snu-operasjon mye takket være en visjonær og tydelig leder i Liam Maxwell som benyttet alle anledninger til å fremheve at vi er til for publikum og vi må alltid spørre oss “hva er det brukerne egentlig trenger?”

 

Målstyring og prosjektstyring

Jeg har forståelse for at ledere har et presserende behov for å forenkle. Jo fler folk du har under deg, desto større behov vil du ha for å lage mekanismer som gjør at det er mulig å følge med på hva som foregår uten å bry deg om detaljene. Og uten å være fagekspert. Ledelse er jo et fag i seg selv, er det ikke?

Målstyring er i utgangspunktet en god ting. målebåndNoe som kan hjelpe en medarbeider til å sette seg utviklingsmål. Noe som kan være drivkraft i prosessforbedring. Og ikke minst en god mulighet til å følge opp forretningsstrategier og salgsmål. Og noe som gjør det overkommelig å være leder uten å være fagperson. Du kan følge med på indikatorene i stedet for å måtte forstå hva som egentlig skjer. Allikevel får vi stadig påminnelser om at målstyring praktiseres på en nærmest dysfunksjonell måte.

Måling har mye kraft i seg, og det kan effektivt styre adferd. Når noe blir målbart blir det klart og tydelig og da får det fokus. Og man kan ytterligere forsterke effekten gjennom å knytte belønning opp mot måloppnåelse. At ledere og selgere har en stor andel av lønna gjennom bonuser er vi vant til. Men dette sprer seg også lett nedover i hierarkiet.

Innen prosjektstyring ser vi det samme. Vi forsøker å bryte prosjektet ned i håndterbare biter som måles separat (WBS) og vi lager detaljerte milepælsplaner som vi kan rapportere fremdrift i forhold til. Dette gjør at styringsgruppa kan mene noe om – og styre – prosjektet. Uten at de har noe som helst innsikt i hva som faktisk foregår. Dette blir da målstyring med fokus på framdrift og pengeforbruk. Prosjektleder bruker slik indikatorer for å anslå om prosjektet kommer til å levere hele omfanget innenfor rammene eller ikke.

Utilsiktede konsekvenser

Det du måler vil få fokus og altså styre adferden i retning av måloppnåelse. Problemet er bare at vi sjelden klarer å uttrykke det aller viktigste med måltall. Vi ender stadig opp med å måle det som er enkelt å måle, mens de litt mer ulne vanskelig målbare tingene glemmes.

Målstyring kommer med en kostnad. Selve målstyringsregimet skal defineres, vedlikeholdes og følges opp og medarbeidere og avdelinger skal veies i forhold til mål. Når politikerne i sin iver etter å fornye, forenkle og forbedre vil byråkratiet til livs, vil de dermed gjøre det enda vanskeligere å sette gode måltall på det som er vanskelig å måle. Vi ender da lett opp med en overforenkling der fokus havner på det lett målbare.

Kvalitet ofres

Om en tjeneste har høy kvalitet eller ikke er det ganske vanskelig å måle presist. Dette må vi jo spørre brukeren om, altså mennesker. Kvalitet er subjektivt. Her kan vi få en viss pekepinn gjennom kundetilfredshetsundersøkelser, men slikt vil være mer ullent enn for eksempel kostnad eller tidsforbruk. Så kvaliteten taper. Når hjemmehjelpere blir målstyrt på tid, vil brukerne/pasientene lett bli behandlet på en lite verdig måte. Brukerne er mennesker og for å yte gode tjenester må man ta seg tid til å lytte og forstå behovene. Denne tiden har de ikke lenger og ender opp med korte, målrettede besøk som ikke fanger opp de egentlige behovene.

Innen IT-prosjektet har vi sett et mønster i lang tid. Prosjekter starter med optimistiske estimater og uventede hendelser skjer underveis. Vi kommer altså på etterskudd. For å manøvrere prosjektet sånn noenlunde i havn, må man da forsøke å jobbe fortere. Dette har den konsekvensen innenfor alt håndtverk at kvaliteten forringes. Innen programvareutvikling ser vi at det gode håndtverket – som fører til vedlikeholdsvennlig kvalitetskode – ofres til fordel for framdrift. Det er jo tross alt det prosjektet og leverandøren blir målt på. Vi kaller dette akkumulert teknisk gjeld. The Project Management Triangle (kostnad – framdrift – omfang) representerer kanskje den groveste overforenklingen i vanlig bruk i dag. Her er en god artikkel som angriper dette fenomenet.

I Poilitet er oppklaringsprosent en viktig måleindikator. Hva skjer da? Jo dette er ganske forutsigbart: de vanskelige sakene prioriteres ned, sammen med forebyggende arbeid. Er dette ønskelig? Gir ikke dette en alt for enkel prioriteringsmekanisme? Og igjen ser vi at det langsiktige (forbygging) taper for det kortsiktige.

Den indre motivasjonen forsvinner

I utgangspunktet kommer de fleste på jobb for å gjøre noe bra. Folk har lyst til å yte service og å se gode resultater av jobben de gjør. I utgangspunktet. Men når målstyringen slår inn for fullt med sine innbakte motivasjonsfaktorer vil den lett overta for den indre motivasjonen.

Målstyring har altså makt til å fortrenge folks innebygde trang til å levere bra saker og å yte litt ekstra når det trengs.

Målstyring == standardisering

Når arbeid blir definert gjennom målinger må dette arbeidet naturlig nok standardiseres. Vi må knytte målingene til prosedyrer, hvilket igjen fører til at vi setter faglig basert skjønn til side. Dette er alvorlig! Andelen arbeid som lar seg standardisere synes å være synkende. Vi snakker om kunnskapsarbeid og at vi lever i kompleksitetens tidsalder. Nye innovative løsninger dukker opp fra intet. Hvordan kan dette kombineres med standardisering på en fornuftig måte? Er ikke det gode, faglig baserte skjønn viktigere enn noensinne?

NB: Dette fenomenet inntreffer først og fremst i “silo-organisasjoner”. Knytter man kun målinger opp mot effekten av sluttresultatet fordrer ikke målstyring standardisering av oppgaver.

Juksekultur

De som er utsatt for målstyring vil raskt oppfatte at det er om og gjøre å tilfredsstille systemet og oppnå gode tall. Siden målingene ikke vil kunne presist beskrive arbeidet – ei heller kunne reflektere mangfoldet – vil det være lett å fremstå som litt bedre enn man egentlig er. Dette kalles gaming the system der enkeltpersoner og grupper definerer saker inn i de rette kategoriene slik at de oppnår gode tall. Det klassiske eksemplet er feil og mangler. Slik må selvsagt kategoriseres og her vil det være veldig fristende å klassifisere feil i en svakere kategori, eller forsøke å feie hele problemet under teppet. Hva gjør dette med folks holdninger til ærlighet og redelighet?

Mistillit satt i system

Byråkrater elsker målstyring. Dette gir dem makt. Helt uten fagkunnskap kan de nå presse igjennom en adferd som er “effektiv” gjennom å kontrollere at alle opererer innenfor systemets definerte rammer. Når noen forsøker å utøve faglig skjønn som går på tvers av målsetninger og rammer overprøves de suverent.

Det er forståelig at NAV har en målsetning om å ikke betale ut mer penger til yrkesskadeerstatning enn nødvendig. Men dette har ført til at de med alle midler forsøker å motbevise at en skade faktisk kvalifiserer til erstatning. Fastlege og spesialister blir overprøvd og personer mistenkeliggjort. Her er et ferskt eksempel der en professor i rullestol må bruke alt for mye tid og ressurser på å rapportere og rettferdiggjøre sitt behov.  Dette behovet er opplagt for et vanlig menneske, men altså ikke for byråkratene i NAV. I tillegg skaper dette en god del helt unødvendig arbeid i NAV.

Jeg tror det gjør noe med oss når vi stadig opplever å ikke å bli trodd. Jeg tror folk – helt unødvendig – oppfatter “systemet” som en motstander snarere enn en medspiller.

Siloer for fall

De fleste organisasjoner av en viss størrelse og alder er bygget oppSilos av funksjonelle enheter/avdelinger. I disse enhetene har folk dyrket sitt fag, skapt en sterk identitet knyttet til dette og endt opp med helt særegen kultur. For å få en rekke slike enheter til å jobbe mot felles mål, har man laget tverrgående prosessbeskrivelser, brukt ulike ERP-verktøy og benyttet seg av rene koordineringsroller for å ivareta helheten. Erfaringen er klar: det går ikke problemfritt når helt ulike kulturer behøver å samarbeide.

Kulturkløfter

Ta for eksempel utvikling og drift. Utviklerne vil være kreative og teste ut nye ideer på brukerne, og de vil gjerne ha tilbakemelding raskt. Drifterne derimot, vil ha stabilitet og trygghet og vil for all del ikke slippe nye funksjoner inn i produktet før alt er sjekket. Utviklerne betraktes som skjødesløse og udisiplinerte. En klassisk og velkjent konflikt.

Forretningssiden betrakter utvikling med stor skepsis. De er overbeviste om at utviklerne gjerne sitter og utvikler masse nye teknologisk utfordrende ting for å more seg. De mener bestemt at de bør presses til å jobbe fortere med akkurat det forretning trenger.

Designerne har også sin egen kultur og vil gjerne ha stor frihetsgrad og jobbe for seg selv for å komme til bunns i hva brukerne virkelig trenger. Så kan et fikst ferdig design sendes til utviklerne for implementering. Utvikling betrakter designerne som urealistiske drømmere og primadonnaer det er vanskelig å samarbeide med.

Friksjon

Ikke så rart at en organisasjon som trenger at disse fagenhetene samarbeider sliter med framdrift, misforståelser og at koordineringsbehovet er stort. Alt for mye energi går bort i ren friksjon. Så spørsmålet blir jo da om det går an å få bukt med friksjonen og å få disse ulike kulturene til å samarbeide bedre. De er jo tross alt med på å lage det samme produktet og bør være like interessert i at sluttresultatet blir bra!

DevOps eller dø

DevOps er syntesen av utvikling (Dev) og drift (Ops). Denne sammenslåingen har vært nødvendig for de mest innovative selskapene i verden som er helt avhengig av programvareutvikling. Kreative, endringsdyktige selskaper behøver rask tilbakemelding på jobben som er gjort, og dette viser seg umulig dersom utvikling må sitte og vente på feedback siden drift insisterer på å samle opp mange endringer og å få testet igjennom alle mulige scenarier før det kan leveres ut til brukerne. Dette problemet har utviklerne løst rent teknisk gjennom automatisering. Teknisk avanserte løsninger måtte lages for å automatisere integrasjon, enhetstest, systemtest og leveranse. Men teknologi var ikke nok. De måtte også adressere kulturforskjellene og utvikling måtte bevise at de også kunne være disiplinerte nok til å levere små inkrementer ut til brukerne på en trygg måte. De to enhetene fikk helt tydelig et skjebnefellesskap og ble tvunget til å samarbeide tett. Og de fant at kreativitet, disiplin og struktur ikke nødvendigvis er gjensidig utelukkende.

Økonomiske tidsskrifter som Forbes begynner i økende grad å publisere artikler om DevOps. Dette viser at vi her har å gjøre med en utvikling som vil få stor innvirkning på innovasjonsevnen fremover. I For DevOps Success, Embrace Cultural change viser Chris Cancialosi på en svært ikke-teknisk måte hvordan man kan lykkes i å bygge innovative, raske organisasjoner blant annet med DevOps.

Kultur, teknologi og struktur

Framtidens organisasjoner må bli betydelig raskere enn det som er tilfelle i dag. Hurtig flyt – der man til enhver tid har få saker i arbeid – gir mulighet til å teste ideer på en trygg måte. Og det gir mulighet til å endre seg raskt; Akkurat det vi trenger både i offentlig og privat sektor. For å få til dette må vi minske kulturkløftene og legge mye bedre tilrette for samarbeid. Tett samarbeid og felles eierskap vil gi mulighet til å redusere mistro og friksjon på en effektiv måte. Men da må vi selvsagt lage styringssystemer som legger opp til dette. Og vi må evne å utnytte teknologi for å skaffe oss hurtig feedback. Skyen vil for mange være forløsende. De kraftige APIene som ligger og venter på å tas i bruk gir helt nye muligheter til å eksperimentere med markedet og langt mer presist treffe brukernes behov. Vi må lytte til nerdene og samtidig må lederne bli langt bedre på teknologi skriver Espen Andersen her.

Offentlig sektor

Dagens styringsystemer i offentlig sektor er rolle- og siloorientert og legger opp til langsom flyt. Hverken avtaleverk, anskaffelsesreglement eller prosjektmetodikk adresserer hurtighet, feedback eller endringsdyktighet selv om alle tre vil påvirke disse tingene sterkt. Selv den “smidige” avtalestandarden (SSA-S) til Difi legger opp til svært sjeldne leveranser, med anbefaling om 3 måneder eller mer mellom delleveransene. Dette til tross for at smidig nettopp er laget for å levere hyppigst og hurtigst mulig i tverrfaglig, tett samarbeid.

Heldigvis har vi fremoverlente og kompetente ledere rundt om å offentlig sektor som i tett samarbeid med leverandørene ser bort fra veiledningen og rådene fra Difi og kjører IT-prosjekter optimalisert for rask flyt med DevOps. På seminaret Smidig Digitalisering i offentlig sektor får vi den 26 mai høre hvordan både Oslo Kommune og Posten Digipost har innført DevOps og er i stand til å levere så ofte de ønsker. Bare å melde seg på her!

Også i Skatteetaten og i Statens Pensjonskasse er de i ferd med å knekke denne koden og fremstår nå som moderne, hurtige utviklingsorganisasjoner til samfunnets beste. Men hva med NAV? Hvordan har de tenkt å organisere og styre sitt neste gigantprosjekt til 1.3 milliarder kroner?

 

Det perfekte team

Det synes som teamarbeid i økende grad brukes Team1i arbeidslivet, kanskje særlig den delen som er mest innovativ og kunnskapsbasert.  I Google har de i en 5-års periode jobbet hardt for å finne ut hvordan man kan sette sammen “det perfekte team”. Hva er fellesnevnerne? Hva er “oppskriften”? New Your Times publiserte nylig en veldig god artikkel om dette.

Within companies and conglomerates, as well as in government agencies and schools, teams are now the fundamental unit of organization.

Google er kjent for å være ekstremt datadrevet. Ikke bare lever de av å tolke og systematisere store datamengder, men de bruker også denne ekspertisen internt. Så, de startet et internt forskningsprosjekt kalt Project Aristotle der de studerte teamadferd nøye og forøkte å finne felles mønstre. Er det noe Google er gode på så er det nettopp dette. Men de måtte etter noen år innse at de ikke klarte å finne noen tydelige slike mønstre.

Hvilket team er best?
Team A består av smarte, profesjonelle folk. Når de sitter sammen og diskuterer et problem holder de seg til agendaen, til tidsskjemaet og folk får snakket ferdig før neste mann tar ordet.

Team B er mer “broget”. En observatør vil se at de løser problemer på en helt annen måte enn Team A: Folk avbryter og snakker i munnen på hverandre. Plutselig drar de avgårde på et sidespor, og ingen henter dem inn igjen. Tidsskjemaet sprekker.

Team A og B har etablert helt ulike normer, og det er nettopp slike normer som forskerne etter hvert fant ut at ville bety mest for teamets effektivitet. Hvilke normer er det da som betyr mest?

Forskerne på Google studerte forskningsresultater for å finne ut hvordan de skulle få mer ut av de massive dataene de hadde samlet. Blant annet fant de denne artikkelen om Collective Intelligens Factor.

Det var her særlig to normer som dominerte for de beste teamene

  1. Teamene var balanserte i den forstand at alle i teamet snakket omtrent like mye (over lang tid) og
  2. Teamene hadde høy “average social sensitivity” – med andre ord de var gode til å forstå hverandre også på et følelsesmessig plan.

Dette ledet Google-forskerne videre til å undersøke mer følelsesmessige aspekter ved teamarbeidet, og etter en stund falt brikkene på plass. Det som kjennetegnet de beste teamene var rett og slett en følelsesmessig sterk tillit og trygghet innad i teamet.

When Rozovsky and her Google colleagues encountered the concept of psychological safety in academic papers, it was as if everything suddenly fell into place.

OK, tillit og trygghet er altså viktig. Men hvordan “implementerer” vi dette? I følge artikkelen har de nå innsett at de ansatte må bruke “hele seg selv” når de er på jobb. Vi må våge å vise fram våre svake sider. Vi må ta ordet, selv om vi frykter at spørsmålet vi stiller blir oppfattet som “dumt”. Vi må adressere det psykologene kaller “impression management”. Vi må derfor viske ut skillet mellom arbeid og fritid. Og folk må tåle å “snakke om følelser”. En god del Google-ansatte har kanskje havnet nettopp der fordi de er mer komfortable med datamaskiner og tall enn med følelser… så dette er ikke nødvendigvis så enkelt.

Det er opplagt en rekke ting man kan gjøre for å skape trygghet. Vi som holder på med smidige, tverrfaglige team har jo vært klar over dette lenge, selv om det ikke har vært så godt dokumentert. De som ble inspirert til å adressere trygghet og tillit kan jo for eksempel starte med bloggen til Olaf Lewitz, the Trust Artist

Update! Harvard Business School professor Amy Edmondson on “psychological safety”:

Posted on February 28, 2016 at 4:35 pm by gamsjo · Permalink · One Comment
In: ansvar, Coaching, Endringsledelse, selvorganisering, Teamarbeid · Tagged with: , , ,

To typer Lean?

Det slo meg i en diskusjon med Paul Chaffey på Facebook i dag (jeg er glad vi har politikere som virkelig diskuterer i kommentarfeltene!) at det verserer to ulike forståelser av Lean. Vi snakker stadig forbi hverandre på grunn av dette. I Produktivitetskommisjonens første rapport (på 420 sider) nevnes Lean i en liten seksjon og det vises til at lungekreftpasienter på UNN hadde fått forkortet ventetid fra 64 til 44 dager ved hjelp av Lean. Man hadde kuttet fastlegelddet. HALLO! Var dette alt de klarte? Dette synes jo “signifikant”, men i en slik rapport som nevner Lean kan de ikke en gang vise til dobbelt så raskt?

Innen den pågående tidstyvfangsten til regjeringen nevnes også Lean, men når en leser om dette – f.eks rapporten som evaluerer fangsten tyder lite på at de har gjort gjennomgripende grep for å ta de virkelig store tyvene?

Hvor stort er potensialet?

I boka Dette er Lean viser forfatterne at en brystkreftpasient kan få stilt diagnose 500 ganger raskere (fra 42 dager to 2 timer!). Men dette krever selvsagt radikal omstilling. Radikalt, men slett ikke så vanskelig i prinsippet. Det eneste man trenger å gjøre er å rive de faglige siloene og i stedet utføre jobben i tverrfaglige team. Dette er selvsagt lettere sagt enn gjort, siden det rokker ved den fundamentale tankegangen innen organisasjon og ledelse (som er basert på Taylors Scentific Management). Og så må de som styrer gå vekk fra ressursoptimalisering over til flytoptimalisering (anbefaler alle å lese om dette i Dette er Lean). Men så kommer rosinen i pølsa: Det blir vesentlig mer effektivt å løse sakene raskt! Ventetiden vil indirekte generere belastninger på systemet. Dessuten gir rask problemløsning umiddelbar feedback – hvilket er en forutsetning for kontinuerlig forbedring. Og som om ikke det var nok – dette legger også til rette for innovasjon! Det blir mindre risikabelt å ta sjanser og de som er midt oppe i problemet får lettere ideer og anledning til å sette de ut i live. Alle vinner – bortsett fra enkeltpersoner med rene styring- og koordineringsroller.

Lean kommer i utgangspunktet fra produksjonsbedrifter. Ideen var å gradvis optimalisere de dels mekaniske produksjonsprosessene gjennom å fjerne “waste”. Når flyten gjennom systemet består av fysiske ting, vil ofte naturlovene gjøre at man må jobbe i en viss sekvens og flytenheten vil måtte vandre fra stasjon til stasjon. Under slike forutsetninger vil 30% forbedring kunne utgjøre en signifikant fordel.

Men innen kunnskapsarbeid (som vi stort sett snakker om her) så har vi med ett muligheten til å gi myndighet til sterke tverrfaglige team, som kan jobbe med “én sak av gangen”. Her blir da potensialet gigantisk i forhold! I IT-bransjen har vi flere eksempler på organisasjoner som har gått fra å levere programvare annet hvert år, til å levere daglig (gidder ikke å regne ut hvor mange ganger raskere dette er). Dette er selvsagt ikke mulig uten å radikalt endre på strukturer, roller, ansvar, metoder, verktøy – og kultur. Vi snakker altså om gjennomgripende (til dels smertefulle) omstillinger der enkelte roller og stillinger vil forsvinne. Når koordineringsbehovet blir mindre kan organisasjonen etter hvert bestå av nesten bare verdiskapende roller. Altså radikalt mindre byråkrati og annet “overhead”.

Jeg kan forstå at man er skeptisk til vyer om 500 ganger forbedring. “Om noe ser for godt ut til å være sant, er det nok nettopp dette det er”. Men hvorfor ikke prøve? Hvorfor ikke studere dette nærmere? Det er nok av eksempler i norsk og utenlandsk helsevesen som har eksperimentert med flytoptimalisering gjennom tverrfaglige team. Buurtzorg er et eksempel som bør kunne inspirere tidstyvjegere, statssekretærer og produktivitetskommisjoner.

Virkelig to typer Lean?

Vel, Lean hadde Toyota Production System som opphav og det er naturlig at “basis-Lean” har dratt avgårde på dette sporet. Altså fortsatt med produksjon som mål. Vi har bl.a. fått Lean 6sigma som fokuserer på datainnsamling langs hele produksjonslinja og bruke målinger som utgangspunkt for små, systematiske forbedringer. Dette kalles Kaizen på japansk. Men så har vi fått en annen mer radikal form for forbedring; Den som Niklas Modig tar til orde for i Dette er Lean. Dette kalles Kaikaku. Vi trenger (selvsagt) begge typer. Vi må evne å spille på et større register. Personlig har jeg bare studert denne formen for Lean, særlig gjennom bøkene til Mary og Tom Poppendieck, Craig Larman/Bas Vodde og Donald Reinertsen. Alle disse drøfter spesielt produktutvikling og at dette ikke uten videre bør behandles som produksjon. Potensialet er så uendelig mye større om vi angriper slike prosesser med tanke på radikalt raskere flyt!

Tilsvarende for smidig

Jeg har sett noe lignende innenfor smidig systemutvikling. Mange legger til grunn at “smidig skal passe inn i det bestående” og at man derfor ikke er beredt til å endre på annet enn selve utviklingsprosessen. Dette vil ofte være bedre enn ikke-smidig, men det har en klar øvre grense for hvor bra det egentlig kan bli. For å høste de store gevinstene må vi omorganisere og angripe problemet allerede fra innkjøpsprosessene. Anskaffelse, anbud, porteføljestyring, prosjektstyring, leveranse og ikke minst gevinstrealisering berøres i høy grad. IKT-direktoratet Difi har i de senere årene åpnet for smidig “nede i it-avdelingen”, eller i gjennomføringsfasen. Men Difi har tilsvarende Produktivitetskommisjonen for Lean lagt en svært “svak” fortolkning av smidig til grunn. De som følger Difis råd vil altså gi avkall på et stort forbedringspotensiale. Nå er heldigvis Difi på glid. De vil åpne for at Prosjektveiviseren også kan basere seg på smidig tankegang med Scrum som rammeverk. Jeg har selv fått i oppdrag å lage kurs for dette. Da må vi gjøre noen ganske enkle grep i forhold til veiviseren. Dette baserer seg enkelt forklart på å dyrke tverrfaglig samarbeid, gjøre planlegging og gevinstrealisering til mer kontinuerlige prosesser i stedet for faser, og å eksplisitt ta til orde for enkle løsninger og raskere oppstart.

Kanskje tiden nå er moden for å angripe de virkelig store tidstyvene? Vi kan gjerne kalle dem bakmennene.

Posted on February 11, 2016 at 8:26 pm by gamsjo · Permalink · 2 Comments
In: Lean, ledelse, prosjektledelse, Uncategorized · Tagged with: , , ,