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.

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.

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.

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

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 omstillingsevne, delegering 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 adressert 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.

 

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

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:

• Grundig analyse, utredning og planlegging.
• Komplett, låst omfang
• Én leveranse
• Gevinstrealisering på slutten

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:

• Grundig analyse, utredning og planlegging.
• Komplett, låst omfang
• Iterasjoner med leveranse til “test-system”
• Én leveranse
• Gevinstrealisering på slutten

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:

• Grundig analyse, utredning og planlegging.
• Komplett, låst omfang – som regel grovt definert
• Iterasjoner med ekte leveranser
• Løpende gevinstrealisering

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:

• Rask analyse og planlegging med andre metoder enn tradisjonelle (Build-Measure-Learn, Lean Canvas, User Story Mapping, Impact Mapping, Co-Design etc)
• Solid visjon
• Åpent omfang
• Iterasjoner med ekte leveranser
• Løpende gevinstrealisering

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

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.

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?

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. Noe 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 opp 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 i 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”:

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.

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.

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.

 

#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!

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.

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:

• Når vil vi sannsynligvis nå en nytteverdi som er høyere enn kostnadene?

• Kjører dette teamet fort nok, eller bør vi bemanne opp? Kanskje sette på et helt team til?

• Skal vi skrinlegge hele satsningen, siden teamet ikke oppnådde den hastigheten vi hadde håpet?

• Har vi for svakt team / feil team til å gjøre denne jobben?

• Bør vi revurdere hele ideen, siden noen antagelser viste seg å ikke være til stede?

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

 

• En Smidigblogg av

  Lean Venture

• Ressurser

  • Agile (is) Risk Management (video)
  • Debugging the organisation with Scrum (video)
  • Presentasjoner (slideshare)
  • Prosjektveiviseren med Scrum (video)
  • Raskere, billigere, tryggere,bedre (video)
  • The Power of Why (video)
  • Tidstyveri (video)

• Temaer

  Ansvarliggjøring Brukervennlighet Business Model Generation Coaching Customer Development DevOps DRM endringsledelse EVO eXtreme Programming fildeling forretningssiden forskning gruppedynamikk innovasjon ITIL Kanban kommunikasjon kompleksitet kontrakt kundeverdi kunnskapsdeling Kvalitet Lean Lean Startup ledelse ME målstyring opphavsrett organisasjon Prioritering produkteier prosessforbedring prosjektstyring saksbehandling Scrum ScrumBut sertifisering Skalering Smidig Styring systems thinking ulovlig fildeling

• Siste kommentarer

  • Heidi Ihle Edvardsen on Kurs
  • gamsjo on Ny versjon av Scrum Guiden – hva er nytt?
  • Ronny Justsen on Ny versjon av Scrum Guiden – hva er nytt?
  • gamsjo on Å planlegge for det ukjente
  • Jon Steinar Kjøllesdal on Å planlegge for det ukjente
  • Det smidige hjørne » Å planlegge for det ukjente on Det perfekte team
  • Det smidige hjørne » Å planlegge for det ukjente on Empirisk prosesskontroll

• Arkiv

  Arkiv Select Month August 2023  (1) August 2022  (1) July 2022  (1) August 2021  (1) May 2020  (1) August 2019  (1) December 2017  (1) April 2017  (1) February 2017  (1) December 2016  (1) November 2016  (1) September 2016  (1) July 2016  (1) June 2016  (1) May 2016  (1) March 2016  (1) February 2016  (2) December 2015  (1) November 2015  (1) October 2015  (2) September 2015  (2) August 2015  (2) February 2015  (2) January 2015  (1) November 2014  (4) October 2014  (2) August 2014  (2) July 2014  (2) June 2014  (1) April 2014  (1) March 2014  (2) February 2014  (1) January 2014  (3) November 2013  (2) September 2013  (1) August 2013  (1) July 2013  (1) June 2013  (1) May 2013  (1) April 2013  (1) March 2013  (3) February 2013  (1) January 2013  (1) November 2012  (1) October 2012  (1) September 2012  (2) August 2012  (1) July 2012  (2) June 2012  (1) May 2012  (1) April 2012  (3) March 2012  (1) February 2012  (1) January 2012  (2) October 2011  (1) August 2011  (1) July 2011  (1) June 2011  (1) April 2011  (1) February 2011  (1) December 2010  (1) November 2010  (1) August 2010  (2) July 2010  (1) May 2010  (1) March 2010  (1) February 2010  (2) December 2009  (1) November 2009  (3) October 2009  (2) September 2009  (1) August 2009  (3) July 2009  (1) May 2009  (1) April 2009  (5) March 2009  (5) February 2009  (6)