tirsdag 26. oktober 2010

Smidig IT-ledelse

Onsdag den 27.10. vil jeg holde foredrag om Smidig IT-ledelse på IT-lederkonferansen 2010. Presentasjonen er lagt ut på Slideshare.

Ser fram til å presentere smidige tanker for ledere som nok er vant til ITIL og tradisjonell IT-organisering. Budskapet er enkelt, samtidig så vanskelig da løsningen ligger i stor grad på utsiden av IT-lederens ansvarsområde. Men jeg tror mye kan gjøres uten å endre organiseringen, bare man kjenner til smidige prinsipper og klarer å frigjøre seg fra den individuelle effektivitetens åk (jeg tror stor del av moderne kunnskapsbedrifters problem er at de ubevisst følger prinsipper fra industriell lederfilosofi) .

mvh Rune

mandag 25. oktober 2010

Skal vi akseptere feil?

Jeg må erkjenne at jeg er et konkurransemenneske, selv om jeg har fått skuffende uttelling på idrettsarenaen (jeg har kun en 4. plass som deltager i Smurferennet 1978 å skryte av). Det var de skuffende idrettresultatene som var årsaken til at jeg for noen år siden fortalte en coach at jeg ikke var noe konkurransemenneske. Overrasket kunne jeg høre denne kvinnen si at jeg var en av de mest konkurransedrevne menneskene hun noen gang hadde coachet. Etter den første skuffelsen var lagt seg over at jeg aldri satset på en idrettskarriere, skulle jeg for første gang i mitt liv erkjenne for meg selv at jeg ble trigget av konkurranse. Min konkurransearena har derimot alltid vært arbeidslivet, og jeg hater å feile.

Det er kanskje derfor jeg irriterer meg over “innovative” foredragsholdere som sier at vi må akseptere å feile! Å feile er vel ingen opsjon? Vi skal jo lykkes! Å akseptere nederlaget er etter min mening det første steg mot fiasko og resignasjon. Hvor ofte har vi ikke sett organisasjoner som ikke vet hvordan de skal lykkes, og som kaffedrikkende aksepterer røde tall og nedbemanninger? Kjære foredragsholdere: Tror dere Rosenborg startet sesongen med følgende uttalelse: Vi må akseptere å feile! Min holdning er at vi må gjøre alt i vår makt for å lykkes! Vi skal skape konkurrentknusende organisasjoner som med høy presisjon, langsiktig kløkt og strategisk vett klarer å løse gamle problemer for nye kunder! Vi må implementere bedre enn alle andre, og da kan vi ikke akseptere nederlaget!

Men det som derimot er viktig, er at vi lærer av våre handlinger. Hvordan tror du Northug har det når han kommer inn på 76. plass? Kommer han smilende i mål og sier at “vi må akseptere våre feil”?  Rasende vil han gjøre alt i sin makt for å bedre prestasjonene. Han vil granske alle feil, og lære av egne og støtteapparatets handlinger. Men drivkraften er ikke at han aksepterer å feile, men at han elsker å vinne.
Min hypotese er dermed at organisasjoner som elsker å vinne, lettere vil akseptere midlertidige nederlag og lære av dem. Dette fordi de innser at å granske nederlagene vil gjøre dem enda bedre. Forutsetningen er at de er bevisste sine handlinger, og den påvirkning organisasjonen har på kundens tilfredshet.

Det innovasjonsekspertene nok har sett er de lite innovative bedriftene som hysjer ned egne feil. Men hvorfor skal en dødsdømt mann dvele ved sine feil? Bedrifter uten energi og livsgnist vil igjen og igjen ignorere sine feil, så de skal orke å komme seg på jobben dagen derpå. Men en ting skal jeg være enig i: dersom slike bedrifter begynner å slå hardt ned på feil, vil dette bli den siste spikeren i kista. Dersom frykten for å mislykkes blir større enn iveren etter å lykkes, vil vi få bedrifter som slutter å ro av frykt for å gjøre noe feil selv om de hører fossen buldre i det fjerne. Men problemet er etter min mening ikke at bedriftene slår ned på feil, men at de ikke styrer mot suksess.

Dersom ditt selskap sliter, ikke aksepter feil da dette neppe skaper vinnerkulturen du er ute etter! Skap heller en vinnerbedrift gjennom å forstå omverdenen (konkurrenter, teknologi og kunder), definer suksess så alle i selskapet forstår, og sett i gang bedriftens svinghjul (etabler en lærende organisasjon med flyt). Lær av egne feil med et mål i blikket: Suksess!

Men husk at suksess kan være så mangt. I vinter deltok jeg i Birken på ski for første gang. Mine sønner kunne ikke forstå hvorfor jeg skulle delta dersom jeg ikke kom til å vinne! Tiden var katastrofal (6,5 timer), og flere tabber underveis (for mye klær, feil smøring, for lite drikke, for ivrig i starten) tok meg ned i kjelleren. Men jeg kom i mål som en vinner, da målet realistisk var av meg selv satt til å fullføre! Neste år vil jeg delta nok en gang, med litt høyere krav til sluttid (5,5 timer). Og jeg aksepterer ikke nederlag!

tirsdag 19. oktober 2010

Lærende prosjekter, få suksess uten kravspesifikasjon!

På Prosjekt 2010 holdt jeg et foredrag om Lærende prosjekter. Du finner presentasjonen her: http://slidesha.re/dfRpea

Jeg har lyst til å kommentere presentasjonen noe.

Min argumentasjon knytter seg først og fremst til følgende argumenter:
  • Dersom du skal lage noe nytt for en bedrift, så får du ingen tydelige svar tidlig i prosjektet. Dette blir kalt taus(tacit) kunnskap av Nonaka.
  • Utover i prosjektet så vil du lære om hva som fungerer, og denne kunnskapen bør du benytte for å gjøre løsningen bedre. I henhold til Nonaka vil man få økt den eksplisitte kunnskapen (explicit) i løpet av prosjektets gang.
Gjennom mange år har IT bransjen levert prosjekter som har skuffet oppdragsgiveren (i henhold til en ny undersøkelse av Devoteam daVinci har 75% ikke oppnådd gevinstmålene). For de prosjektene som lanserer en fungerende løsning, viser undersøkelser fra Norge og utlandet at man bruker kun 40% av utviklede funksjoner. Dersom vi antar at alle funksjonene koster like mye å utvikle, så kan vi si at 60% av prosjektkostnaden går på å lage funksjoner som ikke er nødvendige!

Til tross for dette, så fortsetter vi å lage spesifikasjoner FØR vi starter utviklingen. Forskning og tilgjengelig empiri viser altså at denne framgangsmåten ikke gir ønskede resultater, og vil øke prosjektkostnaden unødvendig. Rundt omkring i Norge sitter det akkurat i dag mange prosjektledere og oppdragsgivere som skriver kravspesifikasjoner til fingertuppene blir såre. De som har pratet med brukerne, har fått tvetydige og usikre behov. Men dette stopper ikke analysefasen, da man må være tydelig i spesifikasjonen. Resultatet av analysefasen er dermed en liste over krav, ofte tatt fra funksjonslisten til mulige samarbeidspartnere. Man plukker de funksjonene man synes er kule, og ber underleverandører komme med pristilbud.

Konsulentselskapene elsker denne type kontrakter, da de vet at kunden vil lære underveis. Resultatet av denne læringen er endringsforespørsler fra kunden, noe leverandørene tjener meget godt på. Underprisede fastpriskontrakter er vanlig, da man vet at endringsmeldingene vil strømme inn i løpet av prosjektets gang.

Løsningen etter min mening er å erkjenne fakta: ved starten av prosjektet kjenner man løsningen og brukeratferden minst. Man bør dermed bestrebe:
  • Tidlig finne prosjektets hensikt, og suksessparametere 
  • Raskt å lansere en basisversjon (minimum marketable feature - MMF) av løsningen ut til testbrukere
  • Etablere en produkteier (med strategisk og teknisk forankring) som kan dra ut ideer og kunnskap av de involverte i løpet av prosjektets gang, og levere stadig bedre bestillinger til utviklingsteamet
Smidige prosjekter (som Scrum) med lanseringer hver 30. dag passer som hånd i hanske inn i denne lærende prosjektfilosofien. Man bør sette opp absolutte tidsfrister, og timeboxe leveransene. Resultatet vil bli prosjekter som leverer nytte til organisasjonen i større grad enn fossefallsprosjekter, under sterkere reell kontroll på tid og kostnad.

Derimot vil man ikke kunne garantere at alle funksjonene som man hadde sett for seg ved starten kan lanseres, noe som uansett ikke er så farlig for de som skal benytte løsningen. Undersøkelser viser jo at de ikke ville ha benyttet de aktuelle funksjonene uansett! I stedet vil man kunne få nye ideer som dukker opp i løpet av prosjektets gang som implementeres raskt, og som har stor reell nytte for brukerne.

Eksempel på et slikt prosjekt er Innovasjon Norges søkemotorprosjekt hvor jeg fungerte som produkteier. Store og små ideer ble tatt tak i og implementert i løpet av prosjektets gang, og resultatet er en løsning de ansatte faktisk benytter og liker! Grunnet tidlig lansering kunne vi ta tak i tilbakemeldinger fra brukerne og drift, som førte til en mer stabil løsning som sannsynligvis er rimeligere å drifte enn ved “big-bang” lanseringer.

Det eneste man må gjøre, er altså å frigjøre seg fra troen at man i en tidlig fase er i stand til å:
  • Forutse all kompleksitet som vil dukke opp
  • Forstå teknologien godt nok
  • Forutse brukerbehovene
I tillegg må man få juristene til å lage kontrakter hvor man kan få størst nytte ut av hver investerte krone, i motsetning til i dag hvor man ber om å få levert noe man slettes ikke er sikker på vil bli benyttet.