What's so un-Six Sigma about having the wrong leadership for a project?

One wonders. As a consultant, I have managed many a project where a subject matter expert is made to lead the project, versus a legitimate role of a driving project manager. I guess the theory is, given the subject matter expertise, it is a valid conclusion that this individual will be the best resource to recognize the business case for the project.

This may be true, but, if the skillset for driving a project forward is missing, it may be a good analogy to describe the subject matter expert as a passenger of a plane. You want to get there, because you would not be on the plane if you did not need to. But, truly, the pilot is the person skilled to fly the plane over. No desire of yours to move the plane towards your desired destination will make it go there if you do not have the skills to fly the plane there.

Caveat: There are folks that use Six Sigma to legitimize the same old approach that could never work

Yes, I have seen where people jump into the Six Sigma bandwagon, only to legitimize the 'good old' approach that they were wanting to improve on in the first place.

How's this? Shop goes Six Sigma. Shop hires top-notch Six Sigma talent to revamp process. Six Sigma professional starts with the tough questions to put together the business case for the problem on the table by engaging the targetted customer. Customer pushes back.

Yes, I've personally run into this. I start to ask the questions to help put the business case together. Questions like: Why do we want to undertake this improvement? What metric gives the customer the perception that there is a problem? What level can we calibrate this metrc down to to say we have solved the problem? Who are the customers we are targetting to satisfy with the solution? These questions sound relevant, but, when targetted to an executive who, in many occasions, is the designated strategist for the problem-solving effort, it is perceived to be challenging the executive's direction instead of guidance toward creating the legitimate business case.

Many times, the process does not take off because the executive never had any intention of changing the good old approach. Instead, they only intended to change the moniker of the process they have always been used to, to add legitimacy and a perception of being progressive.

Easing Adoption....

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.

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.

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.

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.

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!!

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.

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!

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.

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

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.

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.

I'm not a hard-___ Six Sigma Black Belt. I just want to bring the practice to common use.

Was trying to explain how I was 'bringing Six Sigma for IT down to the trenches' to a bunch of IT folk and got an interesting reaction on that short phrase. I was contending that the main fault of most Six Sigma practitioners is the elitism they feel they have to demonstrate, that need to alienate everyone else to make being a Black Belt special.

I was explaining that simplifying it into a philosophy for executing work is probably the best way to allude to Six Sigma and have it be accepted into mainstream process.

Remember, Statistics-focused Black Belts, the less we get accepted mainstream, the more we get relegated to a fad, a passing fancy....

Six Sigma .....for Job Hunting?

Six Sigma has always been advertised as a framework for problem solving. Technically, the job hunting process is a problem in search for a solution.

I believe the first order of things is to rise above the process and view the process from a third party perspective. At that point, it becomes a problem just like any other.

Find the customer for whom you are the solution. (Easier said than done! I say that because that statement comes with a bigger job -- identifying what you are based on what you would like to do or what you would bring to the table.) Next, determine your value add and advertise it. At this point, it comes down to presentation skills. Then, determine a strategy for execution. There are various schools of thought on doing this, many using the same words -- networking. I have my opinions about how this idea is misused, but, that is another issue.

Finally, control -- the nemesis of many an initially successful project. Figure out a way to get to task until that 'happy ending' is achieved. More on this later....

Six Sigma in Accounting? Coming Soon!!

Grace approached me with the idea of figuring out how Six Sigma plays into Accounting. The idea came to her when we networked with a very progressive accounting professional. She had her material in a portfolio folder and as she walked us through her process, it occurred to me. She had the very same ideas I had about IT, except she had them for Accounting process.

Yes, it is very relevant. Since accounting is numbers, it is very easy to put the measures in place. The big task is figuring out which numbers indicate the problem, and, unlike IT, where we can just declare that the project objective is written as the act of moving the metric in a positive direction, there are basic considerations. These considerations could be regulatory in nature. They may also be best practices in the Accounting space.

I've approached Linda with the idea on collaborating on material that addresses this subject. It will come very shortly!

Six Sigma: The big bosses must get it first!

I volunteered to impart my Six Sigma knowledge to folks on the SMPNet group, with the intent of demystifying it to these folks as I have taken upon myself to do with the IT folks. As I was doing the presentation, everything made perfect sense. The material applied to sales and marketing with minimal translation. At the end, the question my audience presented me with, was: If everything is just so logical, and seems like the right thing anyway, what is the problem with adaptation?

My answer: top management. For a change as sweeping as Six Sigma, the mandate has to come from the top. And, it can't be lip service either. When the requirement to state a business case from the customer's perspective is mandated, it must be taken to heart. The executive in charge must truly require it, or it loses the value add to the bottom line.

What is the best way to introduce the Six Sigma approach to non-believers?

One sentence. Don't use the word Six Sigma.

Six Sigma has gotten a big rap as another big thing that is going to fall off the planet just like most things have. In reality, as I see other methodologies evolve, they all gravitate to the same principle -- of doing projects for the customer. Work the business case so it demonstrates, very clearly, the value that will be derived by your customer. Very important, take the time to clearly state this business case. I see this professed again in the new ITIL V3 Service Strategy phase, for one.

As Six Sigma professionals, we should not be so arrogant as to assume that doing business this way is only our domain. It is a reality that other good managers have done it this way, even before the terminology was coined so.

Responding to Genna's Question: Are attacks at Six Sigma (being ineffective) justified?

There are two ways to respond to Genna's question. (Genna is Senior Editor of www.sixsigmaiq.com.)

The YES part: The culprit in this scenario is the elitist Six Sigma practitioner who wants to add mystique to the process and subliminally wants to alienate the masses. This is the individual that things that the statistics part of Six Sigma is the distinctive feature to the methodology. And, to those folks, please be aware, Stat 101 can be learned in a few classes. In fact, they offer those classes in high school sometimes.

When the Six Sigma methodology is practiced in this manner, without the essence of the methodology, it becomes bureaucratic. It loses touch with the value it provides for business. It becomes a mumbo-jumbo of numbers that most people think applies only to the academicians. Hence, the attacks.

The NO part, my answer: When Six Sigma is not practiced with the right intent, that is, in keeping with the original premise (that the intention of the statistics is to provide a vehicle to identify a tangible that illustrates a problem), then it fails. When this is the case, it is not Six Sigma that failed, but the arrogance of the practitioner who thinks that they are above everyone else.

First, some people have responded that Motorola and GE would have failed bigger if not for Six Sigma. I suspect that even if that were true, that it was the preponderance of the elitist set that Six Sigma unfairly gets a bad rap.

Using the Six Sigma approach to Achieve Success

Being called on to solve problems is part of all our daily grinds, whether personally or professionally. But recognizing what has evolved to be the Six Sigma approach, can greatly increase the success of the endeavor.

For instance, I've had to call on a client that wanted a specific assessment on their QA process. At that instant, it was quite tempting to respond with the exact verbiage they were asking for. How does this become a risk (if we are giving the customer what they want)?

First, when customers come to ask for help, they have a problem they are wanting to solve. The market place is not conducive to helping a customer that does not know what kind of help they need, so, we have been conditioned to find a solution (whether or not we know how) and shop around for that solution. On the other hand, service providers respond to that solution request by providing a quote for literally what the customer was asking for.

Enter Six Sigma approach!

If, as a solution provider, we went back to the customer and asked for the problem they are trying to solve, guiding them in terms of identifying a perceived value they are not getting, and assist them in assessing if the solution they were asking for solves the problem. Using this approach, we are more likely to come up with a relevant solution, maybe, one that the customer may not have even thought of and that actually addresses the problem. Guess what? When that happens, we end up with a happy customer.

Six Sigma or not, it's still Six Sigma

Did a lot of networking and in the course of all that, mentioned my podcast at sixsigmaiq.com. Most folks just recognize the buzz word -- SIX SIGMA. Most don't realize that it is not so much a literal translation of the methodology into IT. (It almost seems logical to do so. After all, DMAIC, which is 'Define, Measure, Analyze, Improve and Control' do mean something in IT terms.)

I talk more about this in my podcast:
http://www.sixsigmaiq.com/video.cfm?id=122

The reason I do this is to indicate that most best practices that work are actually part of the correct application of the Six Sigma methodology. There is no contradiction. Six Sigma or not, if it works, it's still Six Sigma --whether you agree to call it that or not.