You've done your assessment and analysis. You know what needs to change. You work on a fool-proof business case and are now ready to launch. Now what?
Figuring out the optimal adoption strategy is probably the gating factor to moving forward with the solution. Communication style. Expectations. Company culture. Support for the solution. Detractors with agenda that really don't further the cause. These are a few things to take into account.
Regardless of how well a Six Sigma process improvement is planned, if it never makes it past ideation because of the above-mentioned factors, it will not yield results.
Thursday, July 1, 2010
Tuesday, June 29, 2010
Voice of the Customer....how do you speak to it?
Everyone knows that the voice of the customer must be heard in order for a requirement to be valid. But, how do we handle it when this voice is ....... all wrong.
All too often, we come up like cape crusaders, with noble intentions to solve a problem. And, we could, if left to our own devices. We use our metrics to demonstrate value for a solution that we know will work. We expect to win the enemy over to our side using hard facts and plain simple logic. When we are done, we expect they would be adopting our ways, success on hand, marching off to the sunset ....... as would a dream customer.
Little do we know, the customer engaged us with a bias, an expectation for a solution they have in their heads, that they use over and over, with repeated failure. (After all, wasn't this why we were called to the rescue?)
Not any of our metrics works to sway this customer. It does defy logic, but, this customer decides to go the opposite way from what the metrics say they should. I wonder. Would I have met with more acceptance if I probed my customer for this expectation and tailored my communication of my solution to that expectation (that is, instead of trying to push my agenda using my own communication style)? Maybe, I should have tailored the message to the way this customer wanted to hear it.
All too often, we come up like cape crusaders, with noble intentions to solve a problem. And, we could, if left to our own devices. We use our metrics to demonstrate value for a solution that we know will work. We expect to win the enemy over to our side using hard facts and plain simple logic. When we are done, we expect they would be adopting our ways, success on hand, marching off to the sunset ....... as would a dream customer.
Little do we know, the customer engaged us with a bias, an expectation for a solution they have in their heads, that they use over and over, with repeated failure. (After all, wasn't this why we were called to the rescue?)
Not any of our metrics works to sway this customer. It does defy logic, but, this customer decides to go the opposite way from what the metrics say they should. I wonder. Would I have met with more acceptance if I probed my customer for this expectation and tailored my communication of my solution to that expectation (that is, instead of trying to push my agenda using my own communication style)? Maybe, I should have tailored the message to the way this customer wanted to hear it.
Friday, June 25, 2010
Speak the language of the audience!
This should be so obvious, but, I fall into this constantly.
Assuming that your audience speaks your language in the same context almost guarantees miscommunication. One big lesson I learned from professionally being in many places is that people learn to communicate in their niche. This means the same sentence (even word) may imiply different things to a different environment.
One shop may use the term 'resolved' to imply 'issue closed'. In another, it may just mean 'recovered for this incident'.
As objective as I try to make my arguments are, for or against a point I am tryring to make, it is never as clear to everyone all at once. Frustrating, but, a fact of life, so it needs to be taken in account in all interpersonal interaction.
Assuming that your audience speaks your language in the same context almost guarantees miscommunication. One big lesson I learned from professionally being in many places is that people learn to communicate in their niche. This means the same sentence (even word) may imiply different things to a different environment.
One shop may use the term 'resolved' to imply 'issue closed'. In another, it may just mean 'recovered for this incident'.
As objective as I try to make my arguments are, for or against a point I am tryring to make, it is never as clear to everyone all at once. Frustrating, but, a fact of life, so it needs to be taken in account in all interpersonal interaction.
Thursday, June 24, 2010
Value is subjective!!
Just got this nugget of wisdom from economists Tom Walker, Sr and Jr of Praexis Labs.
Sounds simple, yet, explains perfectly why when I presented a clear business case for an obvious win for a stakeholder, they picked the exact opposite. Let me explain.
Let me demonstrate on a generic simplistic example.
Sounds simple, yet, explains perfectly why when I presented a clear business case for an obvious win for a stakeholder, they picked the exact opposite. Let me explain.
Let me demonstrate on a generic simplistic example.
Given:
- Option A, with a cost of $1 and an ROI of $12 over 10 days;
versus,
- Option B, with a cost of $1 and an ROI of $5 over 5 days
Translated to the same measurement system over the same period, Option A's ROI is $6 and Option B's is $5. Would seem obvious to me that the stakeholder would pick Option A over B given they would stand to benefit.
Fact: My stakeholder picked Option B. Now, why would they do that?
Did not consider the definition of VALUE to my customer. The obvious, which is COST, might not be what my customer considered of VALUE. As objective as COST appeared to be, it was not to this stakeholder.
Initially, it did not occur to me that the stakeholder may have cared more about image or perception management, which could not have anything to do with costing the problem at hand, or improvement metrics.
This stakeholder's concept of VALUE was actually subjective. Interesting!!
Tuesday, December 8, 2009
What's so scary about metrics?
I recently went on an interview for a consulting gig for a business-type program management assignment. Received feedback that I might be too 'metric-driven' to meld with my business customers.
What is it about metrics that scared my interviewer?
We were probably not communicating on the same plane. Everyone is afraid of their work being quantified not because of the fact, but, because of the implied 'non-value add' work it entails. It is fear of the tedium.
Valuable lesson when asking for metrics:
1. Be practical. The only goal when asking for metrics is to be able to quantify work completed, or results. There is a good balance between quantifying results and defeating the whole efficiency of getting the work done because of the metrics required to prove it was done.
2. Communicate clearly what you mean when you mean metrics. The word itself may imply more than just tedium and imply more negative connotations.
What is it about metrics that scared my interviewer?
We were probably not communicating on the same plane. Everyone is afraid of their work being quantified not because of the fact, but, because of the implied 'non-value add' work it entails. It is fear of the tedium.
Valuable lesson when asking for metrics:
1. Be practical. The only goal when asking for metrics is to be able to quantify work completed, or results. There is a good balance between quantifying results and defeating the whole efficiency of getting the work done because of the metrics required to prove it was done.
2. Communicate clearly what you mean when you mean metrics. The word itself may imply more than just tedium and imply more negative connotations.
Monday, July 27, 2009
Commenting on HBR Blog: Dismantle Trust between IT and the Business
Just read the HBR blog that Evan sent my way.
http://blogs.harvardbusiness.org/hbr/cramm/2009/07/dismantling-mistrust-between-i.html?cm_mmc=npv-_-TOPICEMAIL-_-JUL_2009-_-TECHNOLOGY2
To summarize, it advocates empowering business users by delegating the more routine IT tasks to them (such as reporting).
I agree! However, the problem it raises about IT fears about the business customer 'messing things up' and the business feeling snobbed by IT folks is really more about the training component more than anything else.
How can we use Six Sigma in this scenario?
If we, IT folks, believe that Six Sigma is about the customer, and that we are committed to the strategy described by the HBR blogger, then, a prerequisite should be making sure enough time and attention is devoted to training. One cannot expect the customer to get up to speed with the process by themselves. After all, even IT had to learn it.
The fear of the customer 'messing up' is probably valid (without the training). Also, IT is truly behaving like a snob by not acknowledging the fact that training is an absolute necessity (as if they learned intuitively).
Acknowledge training as an essential part of the adoption process. Plan it accordingly. Devote resources to its completion. Then, the article's premise holds!
http://blogs.harvardbusiness.org/hbr/cramm/2009/07/dismantling-mistrust-between-i.html?cm_mmc=npv-_-TOPICEMAIL-_-JUL_2009-_-TECHNOLOGY2
To summarize, it advocates empowering business users by delegating the more routine IT tasks to them (such as reporting).
I agree! However, the problem it raises about IT fears about the business customer 'messing things up' and the business feeling snobbed by IT folks is really more about the training component more than anything else.
How can we use Six Sigma in this scenario?
If we, IT folks, believe that Six Sigma is about the customer, and that we are committed to the strategy described by the HBR blogger, then, a prerequisite should be making sure enough time and attention is devoted to training. One cannot expect the customer to get up to speed with the process by themselves. After all, even IT had to learn it.
The fear of the customer 'messing up' is probably valid (without the training). Also, IT is truly behaving like a snob by not acknowledging the fact that training is an absolute necessity (as if they learned intuitively).
Acknowledge training as an essential part of the adoption process. Plan it accordingly. Devote resources to its completion. Then, the article's premise holds!
Thursday, July 23, 2009
Six Sigma: What's the big deal?
I was at a networking event today and as often as I mention that I am a Six Sigma Black Belt, I had a regular at these networking events ask me what it was and what made it special to be one.
I paused for a bit to make sure I gave my genuine, personalized description. I started out with with my academic description: Six Sigma is a methodology that centers around meeting a goal. The practice advocates identifying problems that prevent meeting that goal (and, identifying means articulating the problem in tangible terms, using metrics). The theory behind the metrics is if a problem can be quantified, definite actions can be taken to reduce (or eliminate) it in order to meet the customer's goal.
Then, I proceeded with explaining that if projects were done right, they would be done using the Six Sigma approach anyway. And, Six Sigma was a terminology set for that ideal process.
I think that sums it up quite succintly.
I paused for a bit to make sure I gave my genuine, personalized description. I started out with with my academic description: Six Sigma is a methodology that centers around meeting a goal. The practice advocates identifying problems that prevent meeting that goal (and, identifying means articulating the problem in tangible terms, using metrics). The theory behind the metrics is if a problem can be quantified, definite actions can be taken to reduce (or eliminate) it in order to meet the customer's goal.
Then, I proceeded with explaining that if projects were done right, they would be done using the Six Sigma approach anyway. And, Six Sigma was a terminology set for that ideal process.
I think that sums it up quite succintly.
Subscribe to:
Posts (Atom)
