The wisdom of "Whys"

It's wise to ask 'why?'


Patients who ask “why ?” are part of a revolution in health care.  As it gathers momentum, we will manage our own health using digital data.


Shareholders who keep asking “why ?” are changing the basis of governance and rewards in board rooms from week to week. They may change the boundaries of the organisation and redefine assumptions about transaction costs and principle agent dilemmas.


Employees who ask “why ?” before applying themselves to a task are forcing senior managers to redefine the way they delegate.  This may change the nature of communication in organisations.


A few years ago, in a social experiment, researchers approached the front of a line (queue) and pushed in.  When they only said “I have to go first”, it didn’t work out very well. 


But, when they explained why, “I have to go first because I have an important job to complete (or a plane to catch)”, then people in the queue (line) were much more accommodating.  The interesting thing was that “I have to go first, because I’m in a hurry” worked almost as well. 


As a generation of employees (born in about 1980-2000 and labelled Generation Y, funnily enough) bring their need to be informed to the workplace, they will do more for openness and management accountability than any number of regulatory procedures. 


McGregor’s Theory Y is based on the idea that work is as natural as play, that people will commit to work and seek responsibility, instead of Theory X shunning work and avoiding responsibility.  Explaining ‘why’ develops trust as well.


The Five Whys (or more if you prefer) is an approach to get to the heart of a problem. 


Are ‘whys’ the way to be wise?  Interestingly, wisdom has the same Latin root as vision and guidance.


The art of innovation with a creative dialogue

The art is to create a dialogue between market and technology with an evolved attitude of co-responsibility and partnership.  This is where to find the opportunities to make significant gains in performance.


What are some elements of a creative and constructive dialogue Y or not X ?   '(see below)


Y  What it is    


 What it isn’t  


Y  "This is the purpose and the benefit of what we are trying to achieve"


X  "I pay; you just get the job done"            


Y  "These are the outcomes we seek; help us to define the most suitable options"


X  "These are my needs; just deliver"              


Y  "We evaluate the options together and educate each other"


X  "I tell you what to do; you execute"    


Y  "We both think about the price" 


X  "The value is my secret, the cost is your secret"        


Y  "We are as transparent as we can be about value and cost"


X   "I told you once; don’t ask again"        


Y  "Understanding is a constant dialogue"


X   "I know the answer before we start"


Y   "There’s usually more that we don’t know than what we do know"


X    "Do it right first time"


Y   "Do the right thing and on time"


X   "We work with best suppliers; they should do what they are told"


Y   "We work with best suppliers; and we endeavour to be a best customer"


X   "We have defined our requirments perfectly clearly"


Y   "There is no such thing as a perfectly defined requirment; unless we check understanding together"


X   "We only progress when everything is ready"


Y   "We go forward knowing the risks; and clarifying who is responsible for the risks"


Bridges or Cathedrals?

There is a familiar discussion in project management forums about the problems of IT projects, and why information technology projects cannot be more like construction projects.


First of all, I'm not convinced that the Standish Report and other statistics account adequately for projects that are stopped early.  If you start a project and stop it the next day, is that a failure or a success?  If you stop it after 20% of the work and save 80%, is the project a success or a failure?  Was US Airways flight 1549 landed by Sullenberger on the Hudson a failure or a success?  When your flight gets cancelled due to weather conditions, do you count it as a failure? 


People often tell me that IT projects should be built like bridges.  Check how many bridges have the same 'too-thin gusset plates' as in the collapsed I-35W Mississippi River bridge.  Did the contractor enjoy the rewards?  Henceforth, if future bridges are built more like agile IT projects, there will be more early testing and early prototyping (for example to test the design of the gusset plates) - design of experiments, conjoint analysis, stress loads, ease of assembly, ease of maintenance, risk factors - using physical modelling and computer-aided design - more cooperative and informed decision-making, less nonsense.  There will be fewer costly, disastrous and fatal bridge designs.  And future failed projects will be corrected, or stopped.  Will that be failure or success?  Then maybe we will be building cathedrals, not bridges.  


If you know the Sir John Egan report, "Rethinking Construction", please convince me that it isn't aligned with agile thinking.  


Metanaction.com : Ian Stokes, Project Leader and Advisor

sitemap xml