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?

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 · Leave a 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: , , ,

3 konkrete råd for raskere omstilling

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

Artikkelen er publisert på digi.no

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

SameOldThinking

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

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

To konkurrerende paradigmer for programvareutvikling

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

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

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

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

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

Hvordan skape endring?

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

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

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

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

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

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

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

Råd 1: Utvikle et alterantiv til prosjektveiviseren

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

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

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

Råd 2: Bytt rådgivere

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

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

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

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

Råd 3: Ton flagg!

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

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

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

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

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

 

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

#NoEstimates – Nei til estimater!

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

http://noestimatesbook.com/

http://noestimatesbook.com/

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

Problematiske estimater

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

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

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

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

Hva er alternativet?

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

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

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

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

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

Hvordan ta beslutninger uten estimater?

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

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

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

Sven Schnee snakket om #noestimates på Smidig 2015

 

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

Tid er penger

TidErPenger

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

Ventekostnader – Cost of Delay

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

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

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

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

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

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

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

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

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

Flytoptimalisering fremfor ressursoptimalisering

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

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

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

IT-fadeser: Om læring og mentale modeller

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

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

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

ProsessDifi

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

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

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

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

smidigProsess

En alternativ, prosjektløs modell for IT-utvikling

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

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

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

Risiko og innovasjon

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

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

wave2

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

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

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

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

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

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

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

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

storSatsning

Uheldige virkninger av grundig, tidkrevende forarbeid

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

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

StortProsjekt

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

NoThanks

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

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

“The proof of the pudding is in the eating”

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

KostRisikoVannfallPudding

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

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

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

KostRisikoSmidigPudding

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

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

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

 

 

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

Er Scrum kompleks?

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

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

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

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

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

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

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

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

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

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

 

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