Raske resultater

I forrige artikkel så vi på hvordan organisasjonsstrukturer påvirket hvilke beslutninger og tiltak hos treningskjedene Generasjon X og Y. Med utgangspunkt i den samme utfordringen gjorde de ulike prioriteringer. Samtidig virket alt logisk og fornuftige utifra situasjonen og forventningene.

Del 1: Kundedrevet virksomhetsstyring. Er det ikke det vi alltid har gjort?
Del 2: Er det kun Salg og Marked som skal tenke på kundene? Og hvorfor vil de det?

I denne tredje artikkelen vil vi se nærmere på hvilken effekt beslutningene får på kort sikt.

Ingen effekt, kun ledetråder

Det har blitt jul og vi møter ledergruppen i Generasjon Y 3. juledag. Konsernsjefen har kalt inn til et krisemøte…

Continue reading

Er det kun Salg og Marked som skal tenke på kundene? Og hvorfor vil de det?

Del to av artikkelen Kundedrevet virksomhetsstyring? Er det ikke det vi alltid har gjort?

Hvorfor

I denne artikkelen ønsker forfatteren å debattere hvorfor bedrifter ender opp med å la interne problemer/behov styre handlinger og beslutninger, fremfor å være kundedrevet, som de fleste sier at de ønsker å være.

I første ledermøtet med treningskjeden Generasjon X, er vi vitne til at temaer for møtet handler om interne anliggende:

  • gjennomgang av IT-sikkerhet
  • budsjettprosessen
  • nytt IT-system for kundeoppfølging (CRM) 

Generasjon Y har en annen tilnærming hvor de organiserer seg ift sine primærmålgrupper, selvom de sliter med de samme utfordringene. Diskusjoner starter utenifra og innover.

Continue reading

- Kundedrevet virksomhetsstyring? Er det ikke det vi alltid har gjort?

Inspirert av tanker fra Lean filosofi og tanker fra Beyond Budgeting.

Del 2 av artikkelserien finner du her. Del 3 kan du lese etter del 2. God reise!

 

Et tankeeksperiment

Denne artikkelserien ønsker å utfordre noen etablerte sannheter knyttet til hvordan de fleste virksomheter styres, bl a rundt den etablerte måten å gjennomføre budsjettering. Det interessante er at de fleste ledere vi snakker med, selv ikke liker budsjettprosessen, fordi konkurransen og markedet endrer seg så raskt at det er umulig å vite hva behovet er 3-6 måneder frem i tid. Hvorfor fortsetter vi da på denne måten?

Hva om ALT vi gjorde i vår bedrift var tuftet på å forstå og løse kundens problem/behov? Og alle saker som ble diskutert i ledermøtene hadde direkte utspring i et konkrete mål om å forbedre kundeopplevelsen – eller kundereisen.

Er det ikke det vi alltid har gjort, tenker du. Kanskje. Bli med og observér et ledermøte hvor virkelig alle beslutninger er utledet fra kundens behov. På slutten av denne artikkelen kan du lese utdrag fra et annet ledergruppemøte, hvor det er andre prioriteringer som driver beslutningene.

Continue reading

How can reducing the speed limit in a city remove traffic jam? #contextswitching #dependencies #jam

Dear System Developer. I have seen the agony and frustration in your face. The every day context switching and inability to concentrate on one task at the time. Many years ago I felt it myself, back when I also did programming. As project manager I want to help you. But, in order to achieve our common goal, you need to help me back. I need you to help the tester and myself create specifications that make tasks small and independent. Only then we can achieve our common goal of a continuous single flow of valuable features delivered to the customer. No more headaches.

In this blog article I would like to discuss the concept of flow in software development by sharing my experiences from a current assignment.  I want to show you how our inability to define small, independent, functional requirements ends up with headaches and stress. Even though the concept of feedback loops is a central part of this, I will hand it to my good friend and colleague Rune Larsen to explain more about Knowing your feedback loop.

When you finish reading this article I want you to ask yourself this question: Can we deliver more and better if we slow down and do one thing at a time (per developer)?

Continue reading

En programmerers evolusjon – Produktutvikleren.

Hvordan kan du levere et godt produkt om du ikke bryr deg om å forstå kundens opplevelse? Kunden selv har aldri bygget kjøkken før. Det har du.”

Siden EDB kom til verden hvor vi måtte lære oss å programmere “bits & bytes” og frem til i dag, har både  kravet og egenskapene til den moderne programmereren endret seg. Fra barneårene med prøving og feiling, gjennom tenårene i kjelleren, til en voksen person som er likestilt med andre voksne jobber. Dessverre har ikke alle den samme forståelsen av hva en programmerer kan og bør gjøre. Noen programmerere er fortsatt mentalt i kjelleren og bør komme seg opp og få litt lys og oversikt. Noen ledere ser fortsatt på programmereren som “hodet” som trenger å bli fortalt hva som skal gjøres.

Programmereren har aldri vært opptatt av penger og makt (det er alltid noen unntak selvfølgelig…). Indre drivkraft har vært å løse analytiske utfordringer og få datamaskinen til å gjøre ting – gjerne nyttige ting. Man har vært opptatt av å lage, leke og lære.

Med Internett ble det raskt et behov å forstå forretning og kommunikasjon også, i tillegg til selve teknologien. Flere fagområder ble tatt inn på teamet i utviklingen av IT-systemer. Programmereren ble etterhvert degradert og plassert stillesittende i et hjørne. Flere og flere lærte seg å programmere og gjorde kompetansen tilgjengelig blant mange – ihvertfall på papiret. Håndverket er programmering. Noen kaller dem hoder, kodere eller utviklere. Og da kommer raskt assosiasjonen til nerdene som sitter nede i en mørk kjeller. Code monkeys. Gi dem dem nok bananer og la dem være i fred.

Jeg mener at alle programmerere, og prosjektdeltagere forsåvidt, kan bidra i mye større grad om vi klarer aktivisere hele mennesket i oss og fremprovosere den kollektive kunnskapen. Da vil vi ta de klokeste beslutningene. Da kan vi etterhvert også få ned størrelsen på teamene og en mye mer effektiv kommunikasjon og beslutningeprosess i utviklingen av produktet. Det krever at vi forstår programmeringens moderne rolle.

Continue reading

Innovasjon i større organisasjoner

Mange større bedrifter har innovasjon høyt på agendaen og streber etter å øke sin innovasjonsstyrke. Det viser seg imidlertid vanskelig, hvor utfordringen hos mange ligger i selve bedriftskulturen. Innovasjon handler om evnen til å fornye og tilpasse produkter, tjenester, prosesser etc for å være konkurransedyktige i sitt marked. De fleste er enige om at det finnes bedre og mer helhetlige måter å drive innovasjon og verdiskapning, men har vanskeligheter for å finne de rette virkemidlene for å få det til å skje i praksis. Så hva skyldes dette?

Det viser seg at problemet delvis ligger fundert i frykten for å miste kontrollen (eller følelsen av å ha kontroll). De selskapene som har lykkes med innovasjon har bygget hele sin bedriftskultur hvor det å lære, samt validere læringen, er den viktigste styringsparameteren. De har bygget en lærende organisasjon. Hva skal til for å bygge en lærende organisasjon?

Den nakne sannheten om IT-prosjekter (Del II)

Som jeg lovet i DEL I, så skulle jeg dele mine erfaringer om hvorfor det er viktig å gjøre kunden god i egen organisasjon. Jeg skal også røpe noen ukonvensjonelle triks som viser hvordan du gjør dette mest effektivt.

Det vil hjelpe om vi ser dette i kontekst av tradisjonelle IT-prosjekter. Eksempelvis betyr dette at kundens prosjektleder eller produkteier, som har fått et leveranseansvar internt, vet at det egentlig kun er TO ting som betyr noe; at det leveres “noe” til avtalt tid og budsjett. Resten er i praksis underordnet.

Jeg kunne godt skrevet et helt blogginnlegg om hvor UENIG jeg er i den tradisjonelle prosjektmodellen, hvor leverandør setter nytt system i produksjon og overleverer til linjen i mottagende organisasjon. Faktum er at en denne modellen virker mot sin hensikt som er å oppnå en definert forretningsmessig verdiøkning. Men, det får vi diskutere en annen gang. Tilbake til dagens tema…

DEL II

Som konsulent har du et ansvar for å gjøre kunden god i egen organisasjon

Husker du historien om da jeg skulle kjøpe meg nye ski fra del 1 av denne bloggserien? (hvis ikke kan det være greit å friske opp minnet før du leser videre). Hva nå om jeg skulle kjøpe ski til kona. Med bestilling fra kona.

Hva ville en dårlig selger gjort? For det første så ville han ikke brydd seg om å finne ut hva dine reelle behov er (og i de fleste tilfeller så vet vi jo knappt det selv). Deretter ville han spurt deg hvilke type ski og merke du har tenkt deg. Hvis du i beste fall er så ærlig at du innrømmer å ikke helt vite det selv, så har man fortsatt en liten sjanse for at vedkommende innser at han må tilkalle forsterkninger. I realiteten ender man som regel med at selgeren finner frem 2-3 vilkårlige alternativer som du presenteres. Dette hjelper ikke særlig.

Hva gjør en god selger? Han får tankene dine bort fra pris og fokuserer på at utstyret skal passe med ditt behov og ønskede kjøreopplevelse. Det er tross alt det du vil huske resten av sesongen (prisen husker du i verste fall frem til neste lønning eller skitur).

Denne historien handler ikke om hvorvidt selgeren er sleip og har et underliggende ønske om å prakke på deg mest mulig. Den handler om konsekvensene av å føye seg etter kunden for å fremstå “hyggelig” i stedet for å gjøre kunden en ordentlig tjeneste og lære han mer om sine egne behov og presentere noen relevante løsningsalternativer. Hvis noen kommer og spør om råd, så er det som oftest fordi man trenger rådgivning. Anta da ikke at vedkommende kjenner alle sine behov. POENGET her er om man klarer å finne en løsning som vil fungere – for kona – på sikt. Det er stor fallhøyde for meg som “kundens prosjektleder” om man ikke lykkes.

Dersom kjøreopplevelsen for kona ikke er god i det lange løp pga skivalget, så hjelper det ikke lenger om skiene hadde riktig farge eller var billige nok i utgangspunktet. Opplevelsen går fra god til dårlig. Vi klarer ikke å gjøre kunden god i egen organisasjon hvis de alltid må gå fra gode til dårlige nyheter.

Bygg så store buffere du kan, men ikke si noe til kunden
De færreste produkteiere eller andre kunderepresentanter har noen formening om hvor lang tid det tar å implementere funksjon x og funksjon y. Hva det koster. En målsetning er da at man unngår å gå fra et estimat til et høyere tall i faktisk forbrukt tid. Det beste du kan gjøre – for begge parter – er å legge til grunn et best mulig rasjonale for ditt høyeste estimat.

Selv om kunden er aldri så misfornøyd med tallet du presenterer (fordi de hadde håpet at det skulle være lavere) så vil man med større trygghet kunne forklare i sin egen rapport til intern ledelse hvorfor dette er slik (intern ledelse har heller ingen forutsetning for å vite hva funksjonen koster, men forholder seg naturlig nok til budsjettet eller tidligere estimater).

Skulle du være så “snill” å gi kunden det laveste estimatet, så er risikoen langt større for at det kommer ubehagelige overraskselser senere. Ingen liker å gå fra gode nyheter til dårligere nyheter. Alle liker å gå fra dårlige nyheter (høyt estimat) til bedre nyheter (levert under estimat). Skulle det vise seg at de dårlige nyhetene (høyt estimat) forblir dårlige nyheter (leveres på tid), så har man med tiden vent seg til tanken. Det gjør ikke så vondt lenger.

Bare tenk dere forskjellen på om man i første scenario kommuniserer et “snilt” estimat på 50 timer, hvorpå sluttresultatet blir 75 timer. I scenario to argumenterer du først for et estimat nærmere 100 timer, hvorpå endelig forbrukt tid ender på 75 timer.  Hva er å foretrekke?

Det er konsulentens ansvar å lære opp kunden
Man kan ikke forvente at kunden som til vanlig jobber med et helt annet domene, skal vite hvordan et komplekst system som IT-utvikling må håndteres. Som proffesjonelle utøvere innenfor utvikling av IT-løsninger, må vi bistå en kunde og deres organisasjon konsekvensene av sine valg (både fordeler og ulemper).

Hvorfor skal vi alltid starte med å sende ut minst fem endringsmeldinger i løpet av de to første ukene i et fastprisprosjekt? Det er for å lære kundene effekten og resultatet av å “sikre seg” gjennom fastpris-avtaler. Gjør man ikke dette, så vil man for det første ende opp med at kunden ikke forstår at det koster å omprioritere ofte (det er krevende å endre kontekst ofte).I tillegg er det viktig at alle parter forstår hvordan den underliggende konsekvensen av å kjøre fastpris-prosjekter er at a) kunden ikke blir så opptatt av hva som er innenfor eller utenfor omfanget og b) leverandøren blir veldig opptatt av å ikke inkludere mer enn nødvendig i kravene. Og tilslutt endre man opp med å bruke altfor mye tid på å diskutere hva som er utenfor og innenfor oppdraget…

I smidige prosjekter sier man at man omfavner endringer. Det betyr ikke at det er uten kostnad å omprioritere og bytte kontekst ofte. Grunntanken her er at man ikke skal låse seg til en detaljert krav-/løsningsspesifikasjon gjennom et prosjekt.

Vi har alle behov for å føle oss trygge

Uansett hvilken stilling og rolle vi har fått i samfunnet, så har vi alle de samme grunnleggende behovene. Det må vi aldri glemme.Helt avslutningsvis har jeg valgt å sitere et utdrag fra en av mine tidligere bloggartikler (og starten på noe som kan bli en bok en dag), “People. Culture. Fire. A gut feeling.“:

“As a human being I am filled with emotions. Sometimes I laugh. Sometimes I cry. Sometimes I get upset, even though I´m not sure why. Sometimes I can´t control my emotions. Sometimes my pride gets in my way – in everyone’s way. Please don´t fight me. Try to see my perspective. Help me, and I will want to help you. I´m only human.”

I DEL III vil jeg dele mine erfaringer fra hvordan vår streben etter å føle kontroll og måten vi organiserer oss i realiteten undergraver vår evne til å optimalisere helheten og nå våre mål.

Bang