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!
Monday, July 27, 2009
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.
Monday, July 20, 2009
Responding to Genna's Question: How does one align the customer experience to the process improvement?
Process improvement is undertaken by an organization for the purpose of realizing benefits that will ultimately impact a customer’s bottom line goal. Alignment of customer experience with the improvement takes a back seat to the primary goal for which the improvement is being undertaken. Not that it is to be ignored, but, recognize that the process improvement must deliver the value for which it is being undertaken to the customer first. Given that, it is important to articulate that impact since it could potentially be included by the customer as part of the value of the process improvement. If so, the conventional tools can be used to elicit the requirement for the alignment of customer experience: stakeholder analysis (to determine all customers), VOC (to determine customer desires and priority), maybe QFD (to help the prioritization process for the improvements)
A case study is presented on this specific subject in a full article the following link:
http://www.sixsigmaiq.com/article.cfm?externalID=1138
A case study is presented on this specific subject in a full article the following link:
http://www.sixsigmaiq.com/article.cfm?externalID=1138
Wednesday, July 8, 2009
Why are some stakeholder roles not represented in some organizations that practice the Six Sigma Methodology?
I noticed, that after practicing Six Sigma in more than one company, that all companies value all the roles to a project and others seemingly don't. Again, operating word is 'seemingly'. And, I believe this is so. Some roles are merged in some environments not because they belong together or logically merge, but for logistical reasons.
I still think that when learning the basics of practicing Six Sigma, one understands the role of each one of the stakeholders to a project. In fact, it is important to declare responsibilities of the roles in order to ascertain that this role's view is properly represented in the project.
I still think that when learning the basics of practicing Six Sigma, one understands the role of each one of the stakeholders to a project. In fact, it is important to declare responsibilities of the roles in order to ascertain that this role's view is properly represented in the project.
Tuesday, July 7, 2009
In Six Sigma, what is value?
What does it mean to look at value from the customer's perspective?
Value is the bottom line benefit derived by a customer -- regardless of the improvement one is implementing in a solution. The Six Sigma approach advocates that a solution must provide value. A concrete return on the investment for the solution must be clearly stated in the business case. The responsibility for creating this business case should belong to the customer, but, when it is not provided, the project manager must step up to the plate and clarify before moving forward with the solution.
It is easy to state this for most IT applications, as our general excuse of the solution being infrastructure preparation (implying that it may be totally out of proportion to the problem it is solving). Not true. Even for infrastructure, ROI can be determined. It may be a longer ROI but, it is important for the customer to know that when they agree on a solution.
I always stress to my project sponsor that it may seem out of the scope of the work they want me to perform to elucidate the business case (after they assign me a specific problem), but, the bottom line value question is important because it dictates the overall strategy, and this is a guideline we should always abide by when providing a solution.
Value is the bottom line benefit derived by a customer -- regardless of the improvement one is implementing in a solution. The Six Sigma approach advocates that a solution must provide value. A concrete return on the investment for the solution must be clearly stated in the business case. The responsibility for creating this business case should belong to the customer, but, when it is not provided, the project manager must step up to the plate and clarify before moving forward with the solution.
It is easy to state this for most IT applications, as our general excuse of the solution being infrastructure preparation (implying that it may be totally out of proportion to the problem it is solving). Not true. Even for infrastructure, ROI can be determined. It may be a longer ROI but, it is important for the customer to know that when they agree on a solution.
I always stress to my project sponsor that it may seem out of the scope of the work they want me to perform to elucidate the business case (after they assign me a specific problem), but, the bottom line value question is important because it dictates the overall strategy, and this is a guideline we should always abide by when providing a solution.
Subscribe to:
Posts (Atom)
