Problemer er ikke bare problemer

Hver evig eneste dag er der rigtig meget snak om teknologi og teknologiens velsignelser for teknologiens egen skyld. Fascinationen kan nogle gange virke nærmest grænseløs. Og man kan godt få det indtryk, at teknologi er svaret på alt – selv der hvor der i udgangspunktet slet ikke er defineret noget problem.

Mens det er forståeligt, at fascinationen kan give én tunnelsyn, er det ikke desto mindre en farlig vej at gå. For al erfaring viser, at noget af det mest risikable, man kan gøre, er at skride til udvikling af løsninger, før man har defineret det problem, man skal have løst, ordentligt.

Dette kan lyde banalt. Men i praksis kan det være langt sværere, end man lige regner med. Læs videre “Problemer er ikke bare problemer”

Har du en digital beredskabsplan?

Hvis man skal pege på én ting, som de fleste, der arbejder med digitale projekter og aktiviteter er konsekvent dårlige til, er det at lære af deres egne fejltagelser.

For tænk over det: Hvis fejl var noget, vi virkelig lærte af, ville det ikke stadig være sådan, at langt hovedparten af alle digitale projekter fejler i den forstand, at de aldrig nogensinde kommer til at leve op til de ambitioner, der var hele grunden til at sætte dem i værk.

Fejlene kan skyldes mange forskellige faktorer. Men én ting er mere end nogen andet skyld i, at vi har så svært ved at lære: Vi har enormt svært ved at være skarpe på, hvornår et digitalt projekt er kørt i hegnet, få det lukket ned og lært af vores erfaringer til brug for næste gang. Men det kan man godt blive.

Læs videre “Har du en digital beredskabsplan?”

Overlev den brændende platform

Eksistentielle udfordringer er noget af det værste for enhver virksomhed. For mens det er en åbenlys trussel – deraf navnet – kan det være rigtig svært at få armene omkring disse og gøre noget ved dem.

Årsagen til dette er, at mens udfordringerne er reelle nok på den lange bane, er de lige præcis så langt væk, at de ikke virker, som noget, det er livet om at gøre at få gjort noget ved på den helt korte bane. Dermed risikerer man i dagligdagen at lulle sig selv ind i de faste opgaver og derigennem opnå en falsk tryghed, der i sidste ende kommer tilbage for at hjemsøge én selv på et senere tidspunkt.

Dette er ikke bare livsfarligt. Det er også unødvendigt. For der er faktisk ting, man kan gøre for at gøre det abstrakte, eksistentielle ude i horisonten både nærværende og håndgribeligt her og nu.

Læs videre “Overlev den brændende platform”

Skab en enkel handlingsplan

Hvor svært kan det egentlig være at skaffe sig overblik over en række målsætninger og de aktiviteter, der skal til, for at man kommer godt videre med dem? Svaret er, at det hurtigt kan vise sig sværere end langt de fleste forestiller sig.

Risikoen er derfor, at man hurtigt går i stå, og at det, der egentlig skulle have været en fokuseret workshop eller møde ender i den rene snak uden hoved og hale, og hvor ingen går derfra meget klogere. Det er ærgerligt. For dels får man følelsen af at have spildt sin tid. Og dels kan man forledes til at undgå øvelser som disse fremadrettet – hvilket bestemt ikke hjælper på noget som helst.

Læs videre “Skab en enkel handlingsplan”

Skyd rigtigt på din plan

Struktur er Guds gave til at analyse og vurdere potentialer, muligheder, udfordringer og trusler i forhold til de tanker, man gør sig om, hvor ens virksomhed eller organisation skal bevæge sig henad. Ikke desto mindre er det rigtig svært for mange at anvende en struktureret tilgang til virkelig at trykprøve, om den plan, man enten har lavet eller er på vej til at få lavet rent faktisk også giver mening.

Men det behøver faktisk ikke være så svært. Der findes en ret enkel metode, der som en anden Egon Olsen-plan kun kræver nogle gule lapper, en kuglepen og et stopur – og nogle andres plan.

Læs videre “Skyd rigtigt på din plan”

Design dig ud af udfordringerne

Hvad bruger du det meste af din tid på? Brandslukning her og nu eller arbejde, der peger fremad på den lange bane og skaber forudsætningen for, at du og din organisation også har succes i morgen og dagen efter?

Hvis du er som langt de fleste andre, anvender du hovedparten af din tid på brandslukning (“Haster & Vigtigt”) og en signifikant del af din øvrige tid på, hvad dem over dig ellers i øvrigt synes er vigtigt, men ikke nødvendigvis er det for dig (“Haster & Ikke Vigtigt”).

Når du så engang imellem får for meget og har brug for en pause, bruger du tiden på alt muligt andet – overspringshandlinger (“Haster ikke & Ikke Vigtigt”). Og så er den dag forlængst gået.

Læs videre “Design dig ud af udfordringerne”

2016 i tilbageblik – og fremad

Nu hvor nytåret står for døren, og 2016 nærmer sig sin afslutning, er det ved at være tid til at gøre status over året der gik fra et fagligt synspunkt. Hvad lærte vi – og jeg – undervejs i året, der gik om fænomener som digitalisering, digital transformation, disruption, business model innovation og mange andre fine buzzwords? Hvad betyder de? Og hvad kan vi bringe med os videre ind i 2017?

Da jeg altid har været en stor fan af den amerikanske talkshow-vært David Letterman og hans “Top 10” lister, tænkte jeg, jeg ville forsøge at gentage det kunststykke her. Og i bedste Letterman-stil gøre det fra bunden og opad mod den vigtigste læring.

Læs videre “2016 i tilbageblik – og fremad”

Find kundens Jobs-to-be-done

En af de måder, man virkeligt kan gå galt i byen på, når man arbejder med innovation er ved at tage et indefra-ud perspektiv: Vi mener, markedet har brug for X, fordi…det ved vi bare. Det er den direkte vej hen imod en fiasko, for godt 90% af alle innovationsprojekter – store som små – der tager den tilgang, fejler. Nogle spektakulært. Andre siver bare stille og roligt uden det store postyr.

Når virksomheder tænker indefra-ud misser de én kritisk ting: Kundeperspektivet. De glemmer at sætte sig selv i kundens sted og se problematikken, virksomhedens produkt er sat i markedet for at kunne løse, fra synspunktet af den, der skal betale regningen. De glemmer ganske enkelt at sætte sig ind i, hvad det er for en opgave eller sæt af opgaver, kunden rent faktisk forsøger at finde løsninger de. De mangler at definere kundens job – Jobs-to-be-done (JTBD). Læs videre “Find kundens Jobs-to-be-done”

Sæt ild til innovationen

En af de helt store frustrationer omkring innovationsprojekter og -processer er, at mange oplever, det er for svært og går alt, alt for langsomt. Og mens det ofte er opportunt at bebrejde proces- og metodeapparat for alle de ting, der går galt, er det straks sværere at kigge indad i forsøget på at finde, hvad problemstillingen i sin kerne er.

Men det er faktisk ikke så svært at se. For udover at der kan være mange forskellige holdninger til innovation og det enkelte projekts levedygtighed, der afgør, om man vil bruge sin energi på det eller ej, er virkeligheden i alle virksomheder og organisationer, at der er noget, der altid tager forrang for fremtiden: Nutiden – den daglige drift.

Hyl som de andre ulve

Langt de fleste mennesker, der går på arbejde, deler hovedparten af deres tid op i to kasser: De ting, der er vigtige og haster – brandslukning – og de ting, der ikke som sådan er vigtigt, men haster – fordi chefen siger det. Bliver der lidt tid til overs, bliver den gerne brugt på ting, der hverken er vigtige eller haster – overspringshandlinger om man vil – og det eneste, der sjældent bliver tid til er ting, der er vigtigt, men ikke haster. Her befinder innovationsprojekterne sig.

For at løse op for den problemstilling, kan man vælge at anskue udfordringen fra to forskellige synsvinkler: Man kan enten forsøge at ændre kulturen og ad den vej få mere fokus på det lange perspektiv. Den vej er lang, trang, mørk – og måske endda i virkeligheden blokeret. Eller man kan forsøge at hyle som de ulve, man er iblandt og gøre innovationsprojekterne og -arbejdet til noget, der både er vigtigt og haster.

Og hvordan så det? Ikke ved at forsøge at italesætte det som sådan ved fine interne foredrag, memoer og andet godt, man kunne tænke sig. Men ganske enkelt ved et helt igennem banalt trick:

Stryg tændstikken

I stedet for at vise de store forkromede processer og modeller, handler det om at bryde innovationsarbejdet og -projekterne ned i så små enkeltbidder, at de – opgave for opgave – kommer til at ligne opgaver, der bare haster helt vildt meget.

Hvis vi skal holde fast på brandsluknings-analogien handler det kort fortalt om at sætte ild til sit projekt. På den – i denne sammenhæng – gode måde, forstås.

Banalt men effektivt

Ved at bryde opgaverne ned i noget, der er genkendeligt for den enkelte, kan der ske to meget væsentlige ting:

For det første stiger sandsynligheden for, at opgaverne rent faktisk bliver udført, fordi de kommer med i den almindelige slipstrøm af vigtige haste-sager, man alligevel behandler hver eneste dag.

For det andet involveres medarbejderne rundt omkring i organisationen nu på en meget direkte måde i innovationsarbejdet. Vel at mærke uden der forinden sker en fremmedgørelse via fremhævelse af innovation som noget mystisk og/eller særligt endsige terperi af metoder og processer. Det sker bare. Helt uden nogen for alvor opdager det. Og dermed også uden den organisatoriske, kulturelle modstand, der ellers er enhver innovations største fjende indenfor en etableret virksomhed.

Som nævnt er det et relativt banalt trick. Dermed ikke være sagt, at det er let at skabe denne nedbrydning, delegere og gøre det konsekvent. Men sammenlignet med frustrationen over, at ens innovationsprojekter og -arbejde rammer muren igen og igen, er det bestemt et stort skridt fremad, som det er værd at tage.

(Foto: Flickr/Steven Bochniewicz)

Godt i gang med Lean Startup

Agil udvikling er over de senere år for mange blevet det helt store dyr i åbenbaringen. Drevet af startup-miljøet og nytænkende organisationer, er det blevet et fantastisk attraktivt alternativ til store, komplekse vandfalds-projekter.

Centralt i hele den agile tilgang står Lean Startup metodikken. Metodikken kom først på banen i 2008, da amerikaneren Eric Ries førte den på banen, og siden da har den gået sin sejrgang over hele verden. Bogen bag har solgt og solgt, og der findes ikke den konference rundt omkring, hvor man ikke snakker om metoden og dens tre elementer: Build, Measure, Learn.

Metodikken er også rigtig god og anvendelig, når man arbejder med udvikling af nye produkter og tjenester. Men lige som alle andre metoder og filosofier, fortjener den lige at få en kritisk gennemgang. Så det vil jeg forsøge at komme med her.

Udgangspunktet i Lean Startup er som nævnt den iterative proces Build, Measure, Learn. Man starter med at bygge noget ret simpelt. Så måler man, hvordan det virker. Man uddrager den lære, man kan af det. Og så tager man denne læring med videre i den næste iteration af ens produkt eller tjeneste. Og sådan kører det ellers rundt i ring og skaber i princippet en løbende forbedring af ens offering uden brug af store forkromede planer, GANT-diagrammer og hvad vi ellers har af gamle redskaber fra den klassiske projektverden.

Start med idéen

Lad mig gennemgå de enkelte skridt i modellen.

I starten har man en idé, og med udgangspunkt i den, bygger man sit Minimum Viable Product; det mindst muligt omfattende produkt eller tjeneste, man kan slippe afsted med for at få en rigtig test af, hvorvidt idéen holder eller ej. Man bygger sig produkt – Build – og releaser det til markedet.

Når produktet kommer ud, går næste del i gang – Measure. Her måler man kort fortalt på, hvordan produktet performer. Som minimum har man sørget for, der er rigtig god tracking på alt, hvad der foregår, og de fleste har også nogle KPI’er, som de følger. Disse kan være relativt generiske – antal besøg, antal salg m.m. – mens de mest avancerede opstiller specifikke KPI’er, der er designet til at definere præcis, hvilke svar det er, man gerne vil have ud af denne test.

Er man så avanceret, er man godt på vej mod sidste fase som er Learn. Det er her, hvor man bruger de opsamlede data på testen til at se på, hvordan det så egentlig gik og – vigtigst af alt – hvilke nye idéer og initiativer, det giver anledning til i forhold til at komme godt videre med næste iteration. Det er en super vigtig del af processen, for det er, man mere end på noget andet tidspunkt definerer, hvad det er, man hælder ind i sit produkt efterfølgende.

Pas på faldgruberne

Ovenstående er Lean Startup metodikken i meget korte træk. Og det ser jo ganske overskueligt ud. Men der er også nogle områder, hvor man med Lean Startup skal være opmærksom.

Det første opmærksomhedsprodukt handler om det input, man giver til modellen. Som med de fleste andre processer gælder princippet om ‘Shit in, shit out’. Og hvis man ikke passer rigtig meget på, er der en fare for, man kommer en halvbagt idé ind i processen til at starte med, og så kommer hele resten af forløbet til at handle om at optimere på noget, der egentlig er temmelig fejlbehæftet til at starte med – eller hvor der måske i virkeligheden bare havde været en bedre idé at starte ud med, hvis man havde gjort sig lidt mere umage.

Man kan naturligvis argumentere for, at metodikken vil fange en rigtig dårlig idé gennem processen og optimere på den. Og i princippet er det også korrekt. Men man skal ikke være blind for, at der kan indsnige sig en eller anden form for ‘confirmation bias’ undervejs, hvor man mere fokuserer på at få de målinger og den læring, der passer til ens ene forudfattede meninger end lytte til den feedback, markedet faktisk giver. Sker det bliver hele processen suboptimal for at sige det meget pænt.

Læring er altafgørende – og svær

Den næste ting, man skal være opmærksom på er selve læringsdelen. Talrige praktiske erfaringer viser, at mens man generelt er ret gode til at bygge ting, og de fleste også kan finde ud af at måle på det, de bygger, står det sløjt til med evnen til at lære. Dette kan skyldes, vi bare ikke er særligt gode til at lære af vores fejl. Men det kan også skyldes, vi nægter at se virkeligheden i øjnene og dermed discounter den negative feedback, der egentlig var livsnødvendig for os at få ind i den næste iteration af produktet.

For at imødegå dette sidste problem findes der de praktikere, der mener, man skal anskue hele processen anderledes. I stedet for at sige Build, Measure, Learn bør man i stedet sige Learn, Measure, Build. Dette er ud fra tanken om, at man først sætter sig ned og definerer, hvad det er, man gerne vil have ud af sin test i den pågældende version af produktet, hvordan man har tænkt sig at måle på det og først til sidst bygger produktet.

De praktikere, der advokerer for denne version, gør det, fordi de kan se, at rigtig mange i praksis har enormt svært ved læringsdelen, som er den centrale i hele processen. Alle kan bygge, de fleste kan måle – men de færreste formår for alvor at indfri det potentiale, der ligger i læringsdelen. Hvis det at kunne gøre det kræver, at der rettes lidt ind i rækkefølgen, må det være et lille offer at bringe for en metodik, som ellers er super effektiv.

(Foto: Flickr/Rebeca Zuñiga)