Skip to main content

Why do you do this?

If you want to check how effective the change you brought in is or want to test the grounds to bring in a change to your place of work, I suggest the following.
Go around, talk to the people closer to the ground and ask them the question ‘Why do you do this?
It need not always be this question , but can be a variant of it.

I have given below a software example.
Question: Why do you do prepare RCA (Root Cause Analysis) documents and have Causal Analysis Meetings?

Answer 1: It allows us to analyze root cause of defects and prevent the defects, document it and hence prevent the defect from occurring again. It also helps us to be at CMM level 5
Answer 2: Worse: we were asked to do and that is why we are doing it :-(. Better: We are at CMM level 5 and hence we do this. :-

If you hear Answer 1, great and congratulations. Your changes are effectively implemented and shouldn’t have much problem bringing changes to your work place.

But, as much as you like to hear Answer 1 more often, it is answer 2 that you will hear majority of the time. Though this may sound simple, this is the difference between understanding and following vs blindly following. This also makes a whole lot of difference to the way anything new is perceived/welcomed.

When we get a response like answer 2 or something similar to it, we need to look at the problem from the user perspective and system perspective. The terms are defined as follows

User perspective: how the user (the person impacted by the change) views the change.
System Perspective: How the system sees the change brought in. Here system means the set of people in charge of conceptualizing and implementing the change.

User Perspective: we must try to find out why the person responded in the manner he/she responded. Some of the suggested questions, for continuing the conversation, are
  • Was enough information/training provided to the person to understand the necessity for the change?
  • Does the person feel if the change adds value?
  • Did the training communicate the value added by the change?
  • Are people not able to perceive the advantages brought out by the change?

The system perspective: The following are the suggested questions to be asked to them.

  • How does the change really add value?
  • How is/was the advantage of the change clearly articulated?
  • What kind of dissemination was done to educate people about the value-add by the change?

By asking the question to the person closer to the ground (from implementation and user perspective), I see the following advantages.

  • We will know how effectively the change we wanted is getting implemented.
  • By implementing lessons learnt from the responses to these queries, we bridge the gap between the User and System Perspective.
  • It also gives insights into fine tuning our implementation if we want to bring in something new.

And by the way, a good non software example can be the question to you, the reader “why did you read this article? “ :-) From a system perspective, I want managers to question what their team members do, to understand if the team is knowingly are blindly doing their jobs . If you understood that, then my job is done. Else let me know why not. :-)


  1. I guess we do not often ask the question "Why do we do this..." in our day-to-day lives...there are so many things we take for granted.

    We need to start asking "Why" more often - it shake us out of somethings we do routinely as a matter of habit, and lead to out-of-the-box ideas.

    Guess that's what Newton's asking "Why does the apple fall DOWN" led to!


Post a Comment

Popular posts from this blog

Kano Model of Customer Satisfaction - Notes to Self

Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development. 

To evaluate a product or service, following parameters are very important

The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition
But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation. 

The 3 important feature categories are 
Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…

Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...
Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.
All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.
But the problem is that people usually look at these factors in black and white. This may be ac…

Aggressive Schedules - Few thoughts...

During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.

After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following.
Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance.  Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …