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.

How does one use Six Sigma to Initiate Change in IT?

Change is always difficult to initiate anyway. But, a good recipe for championing change is to bring out the pain that will be mitigated by the change. Present this pain in terms of the metric that is currently being negatively moved and make sure that this is the voice of the customer, i.e., the voice of a stakeholder who is the right customer for problem.

So, the overall advise does not vary. Identify the right customer. Make sure it is a complete list of customers. Find out their stake in the game. Find out the metric that can impact their stake positively. At this stage, you would have gotten sponsorship for your change. You're ready to move your change to execution.

In my opinion, execution is very rarely the source of the challenge. It is at problem definition and identifying the project objective that change gets hung up.

Business Value! Business Contribution!

There is an emergence of the mindset of providing value to business. I guess we want to address the age-old problem of IT being viewed as overhead.

I have always said that we should treat out IT projects as if we were a small business. In that world, everything we procure for the business needs to provide a tangible bottom-line value....or, we don't acquire it. If we did this to our IT projects, despite kicking and screaming customers, we would stop being just an expense in organizations.

I say this principle is the essence of Six Sigma.

Now, having said that, I am running into ITIL V3 -- pretty much an evolution of ITIL into the same business value mindset. Basically, it is the same principles from ITIL V2 except, instead of focusing on process, it starts with Strategy, which is really defining value to the business.

Overcoming the Six Sigma Stigma

As part of my creating my PODCAST presentation, I discuss my material with Reinhold, who is in engineering and is not a big fan of the general idea of Six Sigma. I've mentioned, time and again, that Six Sigma is really just the formalization of a methodology that advocates performing work based on real value to the relevant customer. This is the premise I develop in my presentation. This idea has evolved from the beginnings of the methodology from back in the days when it was applicable only to manufacturing environments.

Reinhold further challenges me with the ultimate point of my presentation. I contend that I am campaigning to correct the misconception that Six Sigma is only for the bureaucratic big corporations. It is, in fact, innate to the smaller corporate organization, who is highly intolerant of inefficiency in its struggle to keep itself viable, especially in a volatile economy.

How this is so is, I am saying we should stop doing IT projects for the sake of doing them because they are in the budget. We should reach out to the customer and identify how it will make their lives better. If we continue on this track, we, IT, will cease to be a cost center. Companies will have money for us, since we will start to represent recaptured revenue.

How can the Six Sigma mindset positively impact the floundering business?

We all complain about our floundering economy and 'blamestorm' on whose fault it is. We all need to inspect our microcosm to find the root cause of the problem. At work, I often observed that we generally conduct business like we had no stake in the result. Not true of everyone, but a good majority.


If we all conducted our jobs as if we were asked for the value to the organization of every piece of work we do, so we can actually quantify it. And, if this actually meant something to the organization at the end of the day, we would end up with a culture of caring corporate citizens. After all, whatever we do that pulls the organization down is collectively what has pulled our economy down.


One can argue that it starts from the top. True. But, this massive problem would not be such if it was not collective failure.


So, use the Six Sigma mentality of doing something if it provides value. Value is quantifiable. Identify what that is and be accountable for the result. Be corporately responsible.

Common Misconceptions about Six Sigma for IT

The methodology is straight-forward. Heck, even the acronym, by itself tells you what you need to do. So, what's so different about applying Six Sigma to IT that makes it different from all other applications?

Here's a typical scenario. Customer wants a report from, let's call it System X. They submit a request for this report. The request sits in a queue for the IT development team that's going to work it. When the stars align, IT development team gets the budget to execute the request and moves forward. Based on the DMAIC approach (since this is considered to be process improvement), we start with DEFINE. Literally translated, the problem statement can be articulated as missing information, the MEASURE can be the existence of the report and the ANALYSIS, the conversation with the customer probing for the report requirement.

What's wrong with this picture?

Let's continue. Moving on to IMPROVE, IT creates the report based on customer specifications, within constraints of time, resource and scope and with close to perfect quality. Finally, the report is installed in production, with all the monitoring and disaster recovery required to sustain it -- great CONTROL.

Customer inspects the result of the report (as part of user acceptance), realizes that the report, though perfect in execution, had unacceptable latency. The input data was not available in time for what they had intended to use the report for, and refused to sign off the request, modifying the request altogether to fit their need.

How would this have been better using the Six Sigma approach more appropriately?
At the point IT received the request, going back to the customer to find out the value expected from the report might have brought out the latency issue. We might have had to update the requirement to something other than a report, using technology that the customer may not even know about.

Six Sigma: To be or not to be. That is the question.

Calling it Six Sigma may not be the best approach for a non-Six Sigma shop. It's happened a few times now.

I explain the mindset to people all the time. Six Sigma always carries with it the insinuation that it is purely Statistics. This is not valid. Statistical tools sure play a big role in accomplishing the tasks in Analysis and Measure phases of either the DMAIC or DMADV approach. But, this is not the essence of Six Sigma. Of course, I say that in the IT context. To me, when one says Six Sigma approach, it is defining a problem by using measurable criteria, and solving the problem by moving that metric defined by the problem. This is completely different from living in the pure world of Statistics.

Hence, it is absolutely valid to use the Six Sigma approach without referring to it as such, especially to an untrained audience that assumes that we Black Belts are using high-falluting terminology to alienate argument.

What's the problem with defining the problem using the Six Sigma approach?

In a previous blog, I alluded to going back to the actual customer and exploring what their actual use for the project deliverable was. I also mentioned that this was for the purpose of helping them see other possible solution options that they may not have seen when they articulated the problem.

The issue I've had with doing this was a customer that responded to me saying I was going beyond the scope of what I was being asked. In other words, Mr. Customer wanted me to 'just do it' and felt that I was going beyond the scope of my work to ask him what he was going to use it for.

This response is typical. Customers do not want to feel that you are questioning their knowledge or ability to understand technology (even when, at their hierarchical organizational level, it should be inconsequential). At this stage, it all boils down to communication style and phrasing. The customer will always be the customer (and, the customer is always right). Create your business case for asking the question. Show them how understanding their purpose might help you come up with an even more cost-effective solution. A cheaper solution is always a value proposition.

Defining an IT problem using the Six Sigma Approach

The traditional approach for defining an IT problem is usually based on what is literally asked for by the customer. This is making the assumption that the customer is technologically savvy and has weighed the solution options. This is hardly true.

It is our job as IT professionals to go back to our customer to find out the result they are trying to achieve and validate that the solution being asked for will yield that result.

A good example to support this is a customer I once had that wanted a report. I did my due diligence to document how he wanted the report, what information he wanted on it and all that relevant information. Unfortunately, I fell short. I did not ask him what he wanted to use it for. When I delivered the report based on the documented need, it did not serve his purpose, a purpose I knew nothing about. It was not timely for his need. I did not know that this timing requirement was even relevant and Mr. Customer did not realize it was even a consideration.

Lesson learned: I should have asked Mr. Customer what he was going to use the report for. If I did, the other relevant questions like timing, or, if there was other information needed would have come up. I could have helped him define what problem he was trying to solve using something tangible to base the result on.

Defining an IT problem is identifying that tangible metric that will have to move a particular direction to give my customer his desired result. If done correctly, the successful completion of the project will not only mean my successful completion of the project, but, a satisfied customer, as well.

How do you determine a measure for your IT Project?

As is true for any Six Sigma project, what do you measure and how do you determine if it is a good thing to measure? The essence of this question is determining what problem one is trying to fix and applying the Six Sigma principles to it.

The goal of measuring is to establish an objective baseline so that when the project is completed, the success criteria is clearly established as satisfied. So, the key is defining the problem well.

For IT, candidate measures are time (to derive a discrete result), effort (maybe, in terms of rework), when quanitifiable, ideally, dollars expended/saved, quality (when a standard objective measure for it can be established); all these, nothing different from the dimensions of project management. So, what's different? The operating word here is finding that objective measure that can be the basis of determining success of the project.

What is the business case for an IT project?

The IT mindset has traditionally been one of entitlement: a budget is provided and a project executed within that budget. The project execution within that constraint is the only completion goal. The project justification is often left to the customer requesting the work. And, even then, it is assumed they know what the solution options are for their problem and can articulate a clear objective.

Let me share with you how this can be counter productive. Let refer to the Ford quote about requirements for the car: If the people were asked about it, they would have said they wanted a faster horse. The people then did not know about the technology for a car. Their perspective was confined to what they knew, the horse as a means of transportation. This is no different for a customer for an IT project. They do not necessarily know all the solution options.

We as IT professionals need to guide them. We need to understand the problem they are attempting to solve so we can help articulate a clear objective and achieve measurable success.
We need to be able to state what it is they will gain from the successful completion of the IT project (even if it means changing the project itself).

Is there such a thing as a cookie cutter recipe for the Six Sigma for IT?

I have had an opportunity for an interview where an interviewer asked me whether I could come up with a recipe for the Six Sigma approach in IT. Another individual even asked if this is valid.



The response is, generally, yes. But, the approach will not hold for 100% of the cases. It will, however, hold for a good majority. When I talk about what it is that will not hold, I am referring to the specific tools in the toolkit.



I created such a process for a client and went through the template with them on my last day with them. I think they'll do fine with most of the material. Where I anticipate they would run into ambiguity is identifying the measures (to create the baseline). This, by the way, is a very crucial part of the project definition as it determines the success factor for completion of the effort. There is a generic list of metrics one can use in IT. What I proceeded to do was to list these and indicated that if this list did not contain what was required for this specific application, that a more specialized inspection might be required.

Again, for the most part, the formula will work for a good number of applications, just not every one. Well, that's why there's people like me.......

How does Six Sigma translate to IT Program Management?

It's all too common to find opportunities in the market for Six Sigma Black Belts for Manufacturing environments. Oftentimes, an IT-experienced Black Belt would be discounted for such an opportunity. In the experience maturity timeline, it shouldn't matter. The fact that Six Sigma identifies a problem using statistical measures, coupled with the myth that IT problems may be difficult to quantify and statistically measure contributes further to this perception.



The Six Sigma methodology translates very well to IT. The difficulty of use is up front, at the point of applying rigor to problem definition. Since gathering statistics to measure a baseline often entails proportionally significant cost, it is often foregone for a nebulous problem definition that can sometimes even be ambiguous.

The Market and Six Sigma Resources

Today, I got e-mail from a recruiter asking for a Six Sigma Black Belt with heavy experience in some specific type of industry. I thought this was interesting, almost defeating the purpose of being a Six Sigma practitioner.

Six Sigma shows us how to navigate a mess to be able to define a problem (in a nutshell). What does it matter what subject area that problem lies in? A good practitioner should be able to do the drill: Identify the customer, define the problem quantitatively (by asking the right questions), and work through solution options. In problem quantification, it is mostly statistical work.

Again, it is simply my opinion.

Is Six Sigma a Fad only for the Big Guys?

Over ten years old.....I don't think so. But, maybe, I am biased.

It is so clear to me. But, Reinhold questions the validity of the methodology as it applies to small organizations (which comprises majority of business America). He challenged me with a thought that Six Sigma is only for big guys to which I retorted, the small players are using the approach without realizing so. I thought about this. The solution seems to be to stop using the methodology terminology or figure out a way to do the translation.

Interesting though, as I tried to do this, there is nothing in what I wrote that is new or revolutionary. In fact, as I had explained to Reinhold, the words are a way of branding the methodology as a process in itself. There is obviously more work there. But, I'm writing this down as I intend to expound on this thought in the book.

For now, I am trying to write my problem statement, the premise of the book. I am trying to narrow down the audience I will be catering to....

Six Sigma and your Customer

Why the customer is important is because they are the consumer for the project deliverable, Six Sigma or not. What Six Sigma brings to the table is a toolkit for achieving customer focus.

Step 1 for achieving this is identifying who the customer is for your project. They are the entity that is going to provide you with your project success criteria. It is an important part of this step to make sure you have identified all the customers that have a stake in your project.

This customer base you have identified is going to be the source of your requirement. As simple as this seems, this is not as straight-forward as it sounds. Soliciting requirements from the customer means understanding the customer enough to recognize what they are saying, even if they are not articulating it correctly.

Then, once captured, call it back out to your customer in terms they can understand. Be redundant. Say it how ever many times it takes to have your point clearly communicated.

After having done this, you would have achieved the first goal of your project -- achieving an alliance with your customer. You're on your way!

6Sigma Project Management if you are not a 6Sigma shop......

It is quite interesting how you can be blocked off by a two-word subject line like Six Sigma. (Heck, sometimes it works the opposite way.)


If one were to perform proper project/program management, it should be following the principles of Six Sigma anyway.

I often get flack from folks in smaller organizations who claim that Six Sigma applies to bigger shops. I retort by saying whatever it is they do is really in line with the general philosophy of Six Sigma anyway. For instance, in a small company, a project wouldn't fly unless a quantifiable return to a customer who matters to the business is deemed worth it. That, by itself, is in line with my generalization of the Six Sigma approach to a project -- identifying my customer, quantifying a value to my customer and communicating that value to that customer.

So, case in point. There is no room to consider any other approach in a smaller organization. It may just not be known as Six Sigma.

Corporate America and the Great Cleanup

I was talking to Reinhold tonight about the Smiling and Dialing session this morning, how there were people who were let go from companies I found jobs in the job boards for.

Back in the days, we theorized that people who are retrenched (let go/layed off -- many terms for losing ones job) were really the 'runt of the litter'. I've come to realize this is not correctly stated. 'Runt of the litter' is really a subject categorization. The way this should be stated should be that the politically savvy survive.

If you are a 'value add' to your organization but are not politically savvy enough to position yourself to be able to convince the organization of this value, you become the proverbial 'runt of the litter'. If all you are is politics and nothing else, you survive the slaughter. The converse, which is being a contributor without minding the politics of your contribution is the dangerous position to be in. You become this 'runt of the litter'.

The big question now is, as corporate America 'cleans up', is it really eliminating the doers? Are we in trouble in corporate America because we are at this threshold where we mostly have no essence and pure politics in our ranks, where the balance is off between doers and plain political animals? Who then is left to do the work?

6Sigma Demystified

When I think of 6Sigma, I think of three elements -- Customer, the value one needs to deliver to the customer and communicating that value to that customer.

That is obviously not all there is to the Six Sigma methodology, but, sums up why you go throught the exercise of using the tools.....

Process Improvement using 6Sigma Handbook?

At my last assignment, a client asked me to create a 'cookie cutter' step-by-step for process improvement employing the 6Sigma approach. It took years of experience and Business Excellence training to model the 'common sense' techniques into a recipe I could implement (though no individual step in the process was new to me or even remotely revolutionary).

Sounded impossible at first. But, big ideas are usually many simple ideas ingeniously put together. I started out with a framework of 11 steps, then developed the individual ideas by example, employing a tool in my repertoire. I think, for straight-forward ideas, the recipe should work fine.

I may have just come up with my own version of the steps to improving process. I may elaborate on the idea and turn it into a handbook.

Swimming The IT Consulting Market

Interesting how one gets a preview to the competition when placed side by side against them. I relate so much to the ad for The Ladders on TV, of the tennis players on the court, and a hoard of spectators jumping in to volley the ball, and a mess of spectators with racquets.

How does one stand out from among the crowd when everyone has heard of image enhancement techniques and simply follow them without the supporting substance? We all have great looking resumes that we've paid dearly for. Some of us use it to put our best foot forward. Others, to create the image of that best foot. Heck, creating this image has become a full time preoccupation, by itself.

I'll say, join the club! It is no longer value add to just be good and competent. We must spend equal time advertising that value, as well. Even as remote from advertising and communications as we are in the technical arena, we must recognize that if we do not get ourselves up to speed, that that competence gets eclipsed. There's always a chance someone with a lower level of technical skill from us but with better self-promoting skills gets a better rap.

Recognizing this, I shall begin my journey!!!!