Hvorfor 'mislykkes fort' er en forferdelig forretningsfilosofi for de fleste selskaper

Video: De 4 cs for innovasjon På Landmark CIO-toppmøtet i New York City forklarte Steven Pelztman fra Forrester Research fire grep virksomheter må ta for å transformere seg digitalt.

I løpet av de siste par årene har du kanskje hørt forslaget om at firmaet eller organisasjonen din trenger å lære seg å "mislykkes raskt, " og speiler Silicon Valley-startups i deres ekstreme skjevhet til handling. I stedet for å nøye vurdere en aktivitet, planlegge beredskaper og ta en målrettet tilnærming til henrettelse, tyder den "mislykkelige" tankegangen på at du handler først og stiller spørsmål senere. Antagelsen er at noen få feil til slutt vil gi deg det rette svaret raskere enn mer målte handlinger, og den raske fremgangen og kontanter som påkostet ved "mislykkes raske" startups ser ut til å bevise saken.

For mer tradisjonelle selskaper er det noe som appellerer til denne oppfatningen. Hvis organisasjonen din vanligvis trenger et halvt dusin møter for å bestemme hva du skal bestille til lunsj, er ideen om å sette i gang med bare en vag forestilling om en plan og en "lisens til å mislykkes". Faktisk har noen selskaper innført en rekke retningslinjer for å oppmuntre til "rask fiasko", selv i den grad de krever at teamene stiller opp og applauderer når en kollega kunngjør at de har feilet.

Svikt i å feile raskt

Som alle forestillinger som er tatt til det ekstreme, er det noen positive sider ved mantraen om å mislykkes raskt. Jeg jobber først og fremst med større selskaper, og det er ekstremt sjelden at jeg kommer over et som ikke tar feil av siden for mye forsiktighet. I mange tilfeller kan det være gunstig å vippe balansen mot handling.

Magien med vellykkede oppstarter er imidlertid ikke nødvendigvis at de belønner fiasko, og det er sjelden at et vellykket selskap kom dit bare ved å lure fra fiasko til fiasko. I stedet for å kaste initiativer på den ordspråklige veggen for å se hva som stikker, søker de beste selskapene å utvikle seg og gå videre gjennom testing og læring. Det kan virke som en semantisk forskjell, men testing og læring er vesentlig annerledes enn å mislykkes raskt. Når det gjelder førstnevnte, når selskaper står overfor en vanskelig utfordring, fra å utvikle et nytt produkt til å implementere en ny teknologi, søker de å dele problemet ned i mindre utfordringer som kan testes, og resultatet av den testen brukes til å informere resten av prosessen.

En åpenbar manifestasjon av denne prosessen som du sannsynligvis allerede er kjent med, er prototyping. For eksempel vil et selskap som designer et komplekst produkt som et fly eller en bil bygge en mindre modell for å teste i en vindtunnel før en bygger en fullskala versjon. Dette gjør det mulig å samle verdifull informasjon som informerer utformingen av det endelige produktet, til en lavere pris og raskere tidsramme.

Prototyp alt

Analogien til prototyping kan virke som en blendende flash av det åpenbare, men likevel klarer ikke mange IT-ledere å utnytte prototyper for å teste og lære regelmessig, og vi har en tendens til å tenke på "prototyper" som ganske kompliserte, tidkrevende hendelser, eller hvis din organisasjon utfører jevnlige raske prototyper, mange klarer ikke å vurdere hvordan de skal utforme prototypen slik at den genererer maksimal verdi.

I stedet for å tenke på prototyper som en hendelse i seg selv, kan du vurdere dem som en del av et bredere eksperiment. I vitenskapene vil et godt designet eksperiment svare på flere spørsmål og gi en vei fremover, uavhengig av om det hadde fått resultatet som eksperimentøren ønsket.

Å bruke denne filosofien på teknologi er lik. Et dårlig designet eksperiment kan bestå i å gi en liten gruppe brukere et nytt programvareprodukt og spørre dem om de likte det eller ikke. På slutten av dette eksperimentet har du en vag forestilling om programvaren kan være nyttig for den bredere organisasjonen.

Et mer effektivt eksperiment kan starte med en problemstilling som gjør at flere hypoteser kan testes. I stedet for å teste en programvarepakke, kan vi prøve å validere at vi kan forbedre samarbeidet i salgsteamene våre. Vi kunne teste om ny programvare, bedre opplæring eller forskjellige permutasjoner av de to endret en nøkkel salgsmetrik mot en lignende kontrollgruppe. Hvis vi fant ut at programvare fungerte bedre enn trening, eller omvendt, kunne vi deretter starte ytterligere eksperimenter med forskjellige typer programvare, eller mobile apper kontra webverktøy, etc., til slutt ved å bruke en serie små, raske eksperimenter for å teste forutsetningene våre, Lær hvordan du kan forbedre dem og komme til et svar som støttes av resultater fra den virkelige verden.

Kontrast det med den typiske tilnærmingen de fleste selskaper tar til et lignende problem. Du kan ansette noen eksterne rådgivere eller konsulenter, be dem om å gjøre noen benchmarking eller gi en liste over "beste fremgangsmåter", etterfulgt av en detaljert analyse av forskjellige programvarepakker komplett med noen fabelaktige diagrammer som peker for å vise de beste verktøyene for problemet du prøver å løse. Selv om dette vil gi deg dusinvis av vakre PowerPoint-lysbilder, har du til slutt ingen anelse om hvordan denne veiledningen vil oversette fra den virkelige verden til den teoretiske. Videre kan en bedrager konkurrent være med på det tredje eksperimentet, eller være klar til å rulle ut noe som vil gi et konkret konkurransefortrinn, mens du fremdeles fordøyer en dekk på 172 sider. Organisasjonen som lærte gjennom eksperimentering vil også ha praktisk erfaring i hvordan løsningen deres opererte innenfor de fire veggene. Selv om det ikke er en garanti for suksess, er det som å felt soldater som har sett noen få slag mot nyansatte rekrutter.

Eksperimenter med testing og læring

I motsetning til noen råd, er det ganske enkelt å prøve ut testing og lære i din egen organisasjon. Finn et lite problem, der din normale reaksjon ville være å innkalle et team til å utføre en analyse over en serie på uker og dusinvis av møter. I stedet skal du utnevne en eller to personer til å designe et eksperiment som vil svare på noen kritiske spørsmål om problemet, gi en konkret retning mot neste eksperiment og validere eventuelle antagelser.

Se om du har en beslutning av høyere kvalitet, eller om det ble avdekket informasjon som normalt ikke ville bli avslørt bare gjennom analyse. I stedet for å formane personale om å mislykkes, kan du be dem om å utforme en prosess som gir verdifull informasjon uavhengig av utfallet, og husk at "dette aldri vil fungere, og her er faktorene som førte til denne konklusjonen" fremdeles er et verdifullt, vellykket resultat . I stedet for å humle mellom feil på jakt etter suksess, vil du bli dyktig til å bryte problemer i små biter som kan testes, med hver test som gjør organisasjonen din smartere, mer flink og i stand til å bevege deg raskere mot vellykkede resultater.

Executive Briefing Nyhetsbrev

Oppdag hemmelighetene for suksess med IT-ledelse med disse tipsene om prosjektledelse, budsjetter og håndtering av daglige utfordringer. Leveres tirsdager og torsdager

Registrer deg i dag

Se også:

  • CIO-jury: 50% av teknologiledere implementerer DevOps (TechRepublic)
  • 3 måter å bryte ut av din profesjonelle boble (TechRepublic)
  • 8 digitale transformasjonsoppløsninger for CIOs i 2018 (TechRepublic)
  • Slik utfører du strategi: Få gode ideer fra tavlen til styrerommet (ZDNet)
  • Endring øverst: Dette er hvem som skal kjøre din agenda for digital virksomhetstransformasjon (ZDNet)
Bilde: iStock / ilkercelik

© Copyright 2020 | mobilegn.com