The Most Un­der­rated Skill in Man­age­ment

Here’s how to up your game — and avoid some com­mon mis­takes — as you go about de­vel­op­ing what we be­lieve to be the most un­der­rated skill in man­age­ment.

Rotman Management Magazine - - CONTENTS - By N. Repen­ning, D. Ki­ef­fer and T. As­tor

The au­thors ar­gue that one par­tic­u­lar skill has emerged as the most im­por­tant — and un­der­rated — skill in all of man­age­ment prac­tice.

we have worked with dozens of or­gaOVER THE PAST TWO DECADES, niza­tions, help­ing them with ev­ery­thing from manag­ing beds in a car­diac surgery unit to se­quenc­ing the hu­man genome. While the work it­self has been highly var­ied, one thing has be­come clear to us: Prob­lem for­mu­la­tion is the sin­gle most un­der­rated skill in all of man­age­ment prac­tice.

There are few ques­tions more pow­er­ful than, ‘What prob­lem are you try­ing to solve’? In our ex­pe­ri­ence, lead­ers who can for­mu­late a clear prob­lem state­ment get more done with less ef­fort and move more rapidly than their less-fo­cused coun­ter­parts. Be­fore we de­scribe how to im­prove this ca­pa­bil­ity within your­self, let’s take a quick look at some­thing that of­ten gets in the way: the work­ings of the hu­man mind.

Re­sist­ing the As­so­cia­tive Ma­chine

Re­search in­di­cates that our brains have two pri­mary meth­ods for tack­ling prob­lems, and which method dom­i­nates — and thus de­ter­mines the fi­nal answer — de­pends on both the sur­round­ing con­text and the cur­rent state we are in.

As the name sug­gests, con­scious pro­cessCONSCIOUS PRO­CESS­ING. ing rep­re­sents the part of your brain that you con­trol. When­ever

you are aware of your men­tal ef­fort or tell some­one that you are think­ing about some­thing, you are us­ing con­scious pro­cess­ing. This type of cog­ni­tion can be both pow­er­ful and pre­cise. It is the only part of the brain ca­pa­ble of what psy­chol­o­gists call cog­ni­tive de­cou­pling and men­tal sim­u­la­tion — the abil­i­ties to form a men­tal pic­ture of a sit­u­a­tion and then play out dif­fer­ent pos­si­ble sce­nar­ios, even if those sce­nar­ios have never oc­curred be­fore. Con­scious pro­cess­ing is the do­main of logic, in that it uses knowl­edge about the world to con­struct pos­si­bil­i­ties that ex­tend be­yond our own ex­pe­ri­ence.

Men­tally com­par­ing a de­sired state to the cur­rent one is likely to lead to the de­sired change.

We can­not con­trol this type of think­ing or AU­TO­MATIC PRO­CESS­ING. even ‘feel’ it hap­pen­ing; we are only aware of the re­sults — such as hit­ting the brakes when some­one stops sud­denly on the road in front of us. If a piece of long sought-af­ter in­for­ma­tion has ever just ‘popped’ into your head days later, you have ex­pe­ri­enced the work­ings of your au­to­matic-pro­cess­ing func­tion. Be­cause we lack direct ac­cess or con­trol, the work­ings of the au­to­matic pro­cess­ing func­tion some­times feel mag­i­cal and we use words like ‘gut in­stinct’ and in­tu­ition to de­scribe them.

Not sur­pris­ingly, our au­to­matic pro­cess­ing func­tions tackle prob­lems very dif­fer­ently than their con­scious coun­ter­parts. When we tackle a prob­lem con­sciously, we pro­ceed log­i­cally, try­ing to con­struct a con­sis­tent path from the prob­lem to a so­lu­tion. In con­trast, the au­to­matic sys­tem works based on as­so­ci­a­tions or ‘pat­tern match­ing’. When con­fronted with a prob­lem, the au­to­matic pro­ces­sor tries to match the chal­lenge to a pre­vi­ous sit­u­a­tion and then uses past ex­pe­ri­ence as a guide for how to act. Be­cause au­to­matic pro­cess­ing is re­liant on pat­terns from our past ex­pe­ri­ence, it can bias us to­wards the sta­tus quo.

As you at­tempt to im­prove your prob­lem-for­mu­la­tion skills, it is im­por­tant to be aware of these two very dif­fer­ent types of think­ing. If you don’t take the time to for­mu­late a clear prob­lem state­ment, you are es­sen­tially re­ly­ing on your brain’s au­to­matic pro­ces­sor, which is a lot faster but only reaches into your own li­brary of past ex­pe­ri­ences for so­lu­tions.

The Art of Prob­lem For­mu­la­tion

A pow­er­ful prob­lem state­ment has four key el­e­ments.

1. IT REF­ER­ENCES SOME­THING THAT YOUR OR­GA­NI­ZA­TION CARES ABOUT You should AND CON­NECTS THAT EL­E­MENT TO A CLEAR, SPE­CIFIC GOAL. be able to draw a direct path from the prob­lem state­ment to your over­all mis­sion. Too many ef­forts to in­tro­duce new tools like those em­bod­ied in TQM, Six Sigma and Lean have failed be­cause their con­sid­er­able power was di­rected at ir­rel­e­vant prob­lems.

2. IT CON­TAINS A CLEAR AR­TIC­U­LA­TION OF THE GAP BE­TWEEN THE CURRe­search shows that men­tally RENT STATE AND THE GOAL STATE. com­par­ing a de­sired state to the cur­rent one — a process known as men­tal con­trast­ing — is likely to lead to the de­sired change. In con­trast, fo­cus­ing only on the fu­ture state or on the chal­lenges in your way is less pro­duc­tive. Re­search also shows that peo­ple draw sig­nif­i­cant mo­ti­va­tion from the feel­ing of progress — the sense that their ef­forts are mov­ing to­wards an im­por­tant goal. A clearly ar­tic­u­lated gap will help you plan and fo­cus your ef­forts.

3. THE KEY VARI­ABLES—THE TAR­GET STATE, CUR­RENT STATE AND GAP— ARE ALL QUAN­TIFI­ABLE. Be­ing able to mea­sure the gap be­tween the cur­rent state and your tar­get will sup­port an ef­fec­tive project. How­ever, not ev­ery­thing that mat­ters can be mea­sured ac­cu­rately. Struc­tured prob­lem solv­ing can be suc­cess­fully ap­plied to set­tings that do not yield im­me­di­ate and pre­cise mea­sure­ments. Even if they can­not be ob­jec­tively mea­sured, most at­tributes can be ‘sub­jec­tively quan­ti­fied’. This sim­ply means that the at­tribute you are fol­low­ing has a clear di­rec­tion and that you know that more or less of it is bet­ter or worse. For ex­am­ple, or­ga­ni­za­tions of­ten strug­gle with ‘soft’ vari­ables like cus­tomer sat­is­fac­tion and em­ployee trust. Though these can be hard to mea­sure pre­cisely, they can be quan­ti­fied: In both cases, we know that more is bet­ter.

4. IT IS SUF­FI­CIENTLY SMALL IN SCOPE THAT YOU CAN TACKLE IT QUICKLY. A good prob­lem state­ment is ‘scoped down’ to a spe­cific man­i­fes­ta­tion of the larger is­sue you care about. Many or­ga­ni­za­tions have be­come overly en­am­oured of large-scale change ini­tia­tives — of­ten la­belled with acronyms that are en­shrined on T-shirts and cof­fee mugs. But this ap­proach to change is a bad match with our nat­u­ral propen­sity for pat­tern match­ing. As in­di­cated,

our brains love to ‘match’ new pat­terns — it quite lit­er­ally feels good — but we can only do so ef­fec­tively when there is a short time de­lay be­tween tak­ing an ac­tion and ex­pe­ri­enc­ing the out­come. Well-struc­tured prob­lem solv­ing cap­i­tal­izes on this by fo­cus­ing on de­com­pos­ing big prob­lems into lit­tle ones that can be tack­led quickly. Put sim­ply, you will make faster progress if you do 12 one-month pro­jects rather than one 12-month project.

Hav­ing re­searched and taught this ma­te­rial for over a decade, we have ob­served two com­mon fail­ure modes. Avoid­ing them is crit­i­cal to for­mu­lat­ing ef­fec­tive prob­lem state­ments and fo­cus­ing your at­ten­tion on the is­sues that re­ally mat­ter.

The most comERROR 1: ‘WE AL­READY KNOW WHAT THE PROB­LEM IS’. mon mis­take is skip­ping prob­lem for­mu­la­tion al­to­gether. Some­times peo­ple as­sume that be­cause they ‘agree’ on the prob­lem, they should just get busy try­ing to fix it. Un­for­tu­nately, such clar­ity is usu­ally un­founded: With­out ex­plicit at­ten­tion to and dis­cus­sion of var­i­ous prob­lem state­ments, we all rely on our in­di­vid­ual past ex­pe­ri­ence to guide our ac­tions. If you are in a meet­ing that seems to wan­der, chances are that the lack of a clear prob­lem state­ment is at the root. Noth­ing brings aim­less con­ver­sa­tion to a halt faster than our favourite ques­tion: What prob­lem are we try­ing to solve?

ER­ROR 2: PROB­LEM STATE­MENT AS DI­AG­NO­SIS OR SO­LU­TION IN DIS­GUISE. A prob­lem state­ment that pre­sumes the di­ag­no­sis sounds some­thing like, ‘The prob­lem is, we lack mar­ket­ing ca­pa­bil­ity’, or ‘the prob­lem is that the peo­ple in man­u­fac­tur­ing are poor com­mu­ni­ca­tors’. Both state­ments could eas­ily be true, but nei­ther is an ef­fec­tive prob­lem state­ment, be­cause they don’t ref­er­ence goals or tar­gets that the or­ga­ni­za­tion cares about. The over­all tar­get is im­plicit and the per­son for­mu­lat­ing the state­ment has jumped straight to a di­ag­no­sis as to why that tar­get is not be­ing met. Al­low­ing di­ag­noses to creep into prob­lem state­ments means that that you have skipped a step in the log­i­cal chain and missed an op­por­tu­nity to en­gage in con­scious cog­ni­tive pro­cess­ing. In our ex­pe­ri­ence, this mis­take tends to re­in­force ex­ist­ing dis­putes.

A Hy­brid Ap­proach

We have de­vel­oped a hy­brid ap­proach to struc­tured prob­lem solv­ing that is both sim­ple and ef­fec­tive. The frame­work is es­sen­tially a sim­pli­fied ver­sion of Toy­ota’s renowned A3 ap­proach to struc­tured prob­lem solv­ing and con­tin­u­ous im­prove­ment.

The first step is to forSTEP 1: AR­TIC­U­LATE THE PROB­LEM STATE­MENT. mu­late a clear prob­lem state­ment fol­low­ing our guide­lines. In the Back­ground sec­tion of the frame­work, you should pro­vide enough in­for­ma­tion to clearly link the prob­lem state­ment to your or­ga­ni­za­tion’s larger mis­sion. Much of struc­tured prob­lem solv­ing is sim­ply stat­ing as­sump­tions that would other­wise be im­plicit—thereby hope­fully en­gag­ing more con­scious pro­cess­ing. The Back­ground sec­tion gives you the op­por­tu­nity to ar­tic­u­late the ‘why?’ for your prob­lem-solv­ing ef­fort.

When tack­ling a prob­lem in STEP 2: EX­AM­INE THE CUR­RENT DE­SIGN. the field, the most rel­e­vant knowl­edge re­sides in the heads and hands of the peo­ple do­ing the work. The chal­lenge is that, due to au­to­matic pro­cess­ing, most peo­ple can­not ac­cu­rately de­scribe how they ac­tu­ally ex­e­cute their work. They have de­vel­oped a set

of ha­bit­ual ac­tions and rou­tine re­sponses of which they are not en­tirelyaware.asare­sult,wheny­oube­gindig­ging­in­toaprob­lem, you­can­notre­lyon­self-re­ports.in­stead,youmust­ge­tas­clos­e­tothe lo­cus of the prob­lem as you can and watch the work be­ing done. Of course, as you an­a­lyze the re­sults of your in­ves­ti­ga­tion, your own au­to­matic pro­cess­ing func­tions will be map­ping the ob­ser­va­tions made onto past ex­pe­ri­ences in ways that are con­sis­tent with your ex­ist­ing be­liefs, mak­ing it dif­fi­cult to find new so­lu­tions.

To off­set this ten­dency, the next task in this step is to an­a­lyze root causes. Toy­ota In­dus­tries Cor­po­ra­tion founder Sa­kichi Toy­oda sug­gested ask­ing ‘the five whys’: For each ob­served prob­lem, the in­ves­ti­ga­tor should ask why five times. Why won’t the car start? The bat­tery is dead. Why is the bat­tery dead? The al­ter­na­tor isn’t charg­ing it. Why isn’t the al­ter­na­tor work­ing? etc. — in the hope that five lev­els of in­quiry will re­veal the fun­da­men­tal cause.

In some sense, this step is just a STEP 3: CRE­ATE A TAR­GET DE­SIGN. mir­ror im­age of the pre­vi­ous step’s root-cause anal­y­sis. Hav­ing linked fea­tures of the work sys­tem to the prob­lem you want to solve, you now pro­pose an up­dated sys­tem that will gen­er­ate less of the prob­lem. In this step, you map out the struc­ture of an up­dated work sys­tem that would func­tion more ef­fec­tively. This might be as sim­ple as say­ing, ‘From now on, we will al­ways print the gen­eral ledger code on the in­voice form’ or ‘Make changes to the em­ployee train­ing qual­i­fi­ca­tion pro­gram’. The changes should be spe­cific, tar­geted mod­i­fi­ca­tions to the ex­ist­ing sys­tem that are built on your root cause anal­y­sis.

A good goal state­ment builds di­rectly from the prob­lem state­ment by pre­dict­ing both how much of the gap you aim to close and how long it will take. Thus, if your prob­lem was ‘24 per cent of our ser­vice in­ter­ac­tions do not gen­er­ate a pos­i­tive re­sponse from cus­tomers — greatly ex­ceed­ing our tar­get of five per cent or less’, then a tar­get state­ment might be: Re­duce the num­ber of neg­a­tively re­lated ser­vice in­ter­ac­tions by 50 per cent in 60 days.

In the up­per por­tion of the project STEP 4: EX­E­CUTE THE PLAN. frame­work, you lay out a plan for im­ple­ment­ing your pro­posed

de­sign. Be sure that the plan is bro­ken into a set of dis­tinct ac­tiv­i­ties (e.g. ‘Have in­voice form reprinted with the GL code’ or ‘hold a daily meet­ing to re­view qual­ity is­sues’) and that each ac­tiv­ity has an owner and a clear de­liv­ery date. Even as you start ex­e­cut­ing, you are not done, be­cause you will need to ab­sorb all of the as­so­ci­ated lessons along the way. Track each ac­tiv­ity rel­a­tive to its due date and note when ac­tiv­i­ties fall be­hind. These gaps can also be the sub­ject of struc­tured prob­lem solv­ing.

Keep in mind that in the realm of man­u­fac­tur­ing, ser­vice de­sign and new prod­uct de­vel­op­ment, fix­ing one prob­lem typ­i­cally re­veals three or more other press­ing is­sues. Close out your project form by out­lin­ing the next prob­lem that you need to fo­cus on.

In clos­ing

For­mu­lat­ing a good prob­lem state­ment is a skill that any­one can learn, but in our ex­pe­ri­ence, it takes con­tin­ued prac­tise and dis­ci­pline. More than 15 years af­ter we be­gan this work, we still some­times find our­selves de­volv­ing to au­to­matic pro­cess­ing. By em­brac­ing the prin­ci­ples out­lined herein, you will be on your way to de­vel­op­ing what we be­lieve to be the most un­der­rated skill in man­age­ment.

When tack­ling a prob­lem in the field, the most rel­e­vant knowl­edge re­sides in the heads and hands of the peo­ple do­ing the work.

FIG­URE ONE

Newspapers in English

Newspapers from Canada

© PressReader. All rights reserved.