For defining the 'VOC' (Voice of the Customer), I typically use a QFD (Quality Factor Diagram) -- Of recent, I have found that QFD's can be hard to understand for some, while even more painful for belts to explain to others.

If you find this to be the case, there are 3 tools used sequentially that can arrive at a similar answer:

1. Start wtih an affinity grouping diagram - This approach will help to logically group the world of potential answers you get while interviewing folks in your company. It will also help to keep the lens of the customer's value proposition with your company on during your analysis. Two that wash to the top, for example, are website experience & customer service operators.
2. Those groupings can be used as two of the bones of a fishbone diagram (aka cause and effect diagram) - They are synonymous to Manpower and Machinery, two traditional bones of the diagram, if you think about it in terms of the 6 M's. Website experience is a machine, and call center operators would equate to Man. Once you populate all of the drivers or inputs (or x's) that affect a customer's value proposition when they use the website or call into the call center on the fishbone, along with the other 4 bones: Methods(Process), Mother Nature(Environment), Measurements and Materials (tools to do their job), you will most likely notice a commonality between the smaller bones under each heading. For example, under website experience, Manpower (Agents, in our example), you might see inputs like training, administration/support procedures and computer response latency, which are affecting their ability to service the customer. I would expect to see computer response latency under Machinery as well. Likewise, I would expect to see administration/support procedures under Methods as well.
3. Use those sub-bones that show up the most for fill in the next step which is to apply a cause and effect matrix, to help simplistically drive a stack ranked priority based on relative importance of each output and factor (input) to your business. In my opinion, tt is a poor man's way of extrapolating some of the same benefits that using a QFD would provide while not completing confusing the folks who are trying to distill information from the results set.

Recently, I had the fortunate or unfortunate pleasure of pulling my head out of the sand, and becoming more versed in another one of our internal surveys - It comes in the form of a link, appended to an automated case response sent to end users when a service request case (think CRM) is resolved / closed. It is intended to provide voice of the business metrics since most users are from the business that submit the types of tickets in which I refer.

On the front end, I was more than shocked to here the current satisfaction score: 92%! And I was thrilled...Until, I had a need to open a ticket, and upon it's resolution, was shocked to click through the link to what I can scarcely call a survey. It did not offer 5 response options to customers, as inspected, since the reports of satisfaction stated 'Top 2 Box Score'. By definition, Top 2 Box infers the total number of respondents who gave a 4 or a 5 on a given question / (divided by) total number of responses. If you offer only 4 options, where 4 if Excellent, 3 is Good, 2 is Poor and 1 is Bad, you are force fitting users into 1 of the 2 swings of this pendulum, without offering those "on the fence" an avenue by which to answer. Typically, 3 would be comme ce, comme ca (so-so) or neutral, which yields even greater accuracy by those taking a survey specifically because it deals with those "on-the-fencers" who don't swing either way. 5 options is always best, and necessary to calculate Top 2 Box standard satisfaction %.

Top 2 Box is the standard survey score you hear about - Whether ASCI or Malcolm Baldridge award...Check your surveys before you quote the statistic - i.e. walk the process before you drink the Kool-aid!

As my title would suggest, the concepts of business intelligence and Six Sigma seem to be revolve around each other according to most practioners, rather than intersect, like I believe. Gone are the days (or should be) where the applications and business processes are distinct, individual units operating outside the realm of process improvement projects. Wait, back up -- If SOA, or Service Oriented Architecture, is by textbook defined as the 'archtectural retooling of software that allows for the exploitation of open standards that have been adopted by software companies (page 6, ICMI Call Center Magazine, June 2007).' Woah - What?

In other words, SOA allows various silo'ed business processes to work together through the use of the middleware concept that presents the end-user with a standard user interface, but allows the same end user the power to custom-configure these applications based on their own unique needs. Think of a Chinese restaurant menu's family dinner, where you can mix and match from a variety of delicacies in order to create the most perfect family meal for you and your party. Likewise, Service Oriented Architecture does the same, except you are creating your most perfect picture of your business through the use of intelligence, reporting, scorecarding / dashboarding (also known as Enterprise Performance Management).

What is the key though to the intersection and why am I writing about this in a six sigma online community forum? Think of all of the disparate business processes that we work on everyday, and think of all of the projects you have worked on in which you a) had to fight to prove your benefits saved with finance (especially if your company allows soft benefits), b) needing to produce reports as a means of delivering numbers to the process owner and champion on the success of your outputs as defined by your control plan over time, c) needed to validate whether your project even warranted a black or green belts time by leveraging business repots to do so or d) like myself, just have a keen love for the colors or red, yellow and green when used to measure the health of the business.

Ok, I suspect there are fewer of us in the D category, but I may be wrong - My hypothesis is that most of you out there fall into a, b or c or a combination of such characters depending on your business. I am also assuming that you have some type of underlying database structures before you launch six sigma in general, otherwise, I might pull my project in lieu of working on setting up an enterprise data warehouse, but that is a whole other can of worms for another blog, for another day. I diverge... And now we are back...

If any of the options above describe you, then you are in need or wanting business intelligence. And, since my example was scoped to helping you establish your project or report on the success of a project, I suspect you see the analogy I am trying to make when I say there is an intersection between business intelligence and six sigma. In any effort to create consistency or less variation, which is a tenant of the DMAIC methodology, one should gravitate towards the learnings of SOA for BI -- either as a poke yoke or SPC/SPM vehicle, a savings validation or a time / project management tracker; subject matter doesn't matter - what does is an implicit understanding in the principles at large. It is no longer limited to just IT; it is all of our responsibility.

Anyone who knows me knows I am one of the largest fans of the modified balanced scorecard/business scorecard approach. I came across the following study results comparing gender differences at the executive level within organizations. There are those who claim men are more left-brained, thus, women = right dominance. Yet, there is a rise in female engineers, mathematicians and statisticians alike. So, it seems to be a case of reality or VOP not being measured accurately. Looking at the following, I was interested to see women coming into view in every bucket scorecard:

Sources: Business Week @ http://www.businessweek.com/2000/00_47/b3708147.htm

and @ http://www.mhhe.com/business/management/obonline/

Recommended Y (outputs) for a service / transactional project in call centers:

Goal	Metric	Metric Type (CustSat, Cost)
Decrease Cost of Sales	Attendance Adherence Average Not Ready Time Average Talk Time Average Loss per Override Credit Average Fraud Loss	Cost
Increase Customer Satisfaction	Average ASA Customer-Directed Coaching Customer Satisfaction First Call Resolution Transfer Rate Peer Coaching Consult Rate Call Escalation Rate	Customer Satisfaction

Lately, I have written a lot on call center points of interest, as I have just rolled off three back to back projects in that space. These are some of the hardest six sigma project types, that is, when compared to manufacturing from the control perspective only. Now, I am not at all claiming that manufacturing projects are any less significant. But, in reality, when you are "controlling" a machine using control charts, and watching for deviations outside of your control limits, you can go and tweak a knob here or pull down a lever there, as based on your control plan, and immediately see the results in your SPC charts.

In human processes, however, it is a bit trickier. When a process goes out of control due to human variation, there is no level to pull that can quickly show results in a set of SPC’s. Instead, one often has to look deeper into the root causes that they are controlling, for the potential of multi-colinearity between inputs, or inputs that were not surfaced during the DMAI of your project. Many things affect human performance. In fact, have you ever done a process the same every day, whether getting dressed in the morning or the classic, making toast example? I dare to guess that the answer is NO, if you are like me.

The frustrating part of this for black belts is that often deployment leaders expect similar results as they saw in manufacturing companies which again isn’t an apples to apples comparison. Instead, one must look into the softer motivational tactics that keep these agents coming to work, and most often, will need to look into how your incentivize their work. You get what you pay for, in soft dollars (i.e. free food, recognition programs like Agent of the Month, etc) as well as hard dollars (i.e. salaries), so make sure you align your performance management goals with your incentives.

For example, if you are looking to reduce AHT but incentivize your centers for high C-Sat, you are shooting yourself in the foot. Quality often slows down a call, because agents are truly "listening to needs" and proactively driving suggestions that will help them appear more knowledgeable and willing to assist a customer’s request. If you incent time, you will find agents doing what ever they can to get off the phone by the target time, in order to get incentive, even if it means taking a QA hit (if that was how you were thinking of controlling the C-Sat situation).

Instead, look at building in controls that band behavior, like a scorecard would. Instead of having an AHT incentive, look to rewarding low hold time or ACW time (two components of the AHT calculation) because talk time is the true driver of C-Sat. Hold time, BTW, is not the time it takes for an agent to pick up the phone, a.k.a Average Speed of Answer, as that is a C-Sat driver, but isn’t part of the AHT calculation. Don’t confuse the two. Hold time during a call, is when an agent asks to put you on hold while they (...call the carrier for you, process your request, waive fees etc). This is seen as VA time if you look at your own VOC. I promise you...Just dig deeper, and know that you can control human variation but you must align your incentive and performance management structure to do so.

Not all that glitters, is gold, and so is true in a call center. Most performance management and incentive programs focus heavily on the financial or monetary benefits to help incentivize agent performance. But, in a black belt project, you focus on ways to drive down costs, so I ask you, can it be done?

The answer is YES! Especially, in your offshore and outsourced operation centers. If you have every traveled to meet your teams overseas, you will find a wonderful group of self-motivated and driven individuals who want to exceed at running your account, to the contrary the popular belief system that agents are always looking to cut corners, 'game the system' or do whatever they can to get off of the phone. While the latter may hold the most "somewhat truth", the real opportunity lies in the environment that they work. Take a look around the center and ask yourself a few critical questions -- Do you see a lot of recognition on the walls, i.e. portraits of high performing agents? Do you hear about a lot of motivational events, like 'Agent Appreciation Week' or 'XXX Food Cookoff Competition' or any SWAG give away in which the agents can win logo prizes? What managers who have preconceived notions may scoff at (bad black belt if you are scoffing at any improvement effort without first analyzing the data -- but shush, I won't tell)

Most performance lies within the agent; it starts with tenure and moves into morale as they become more seasoned. Don't worry if you have just received a six sigma project related to improving agent performance without raising salaries because softer things like I mentioned above, do make a difference. You will just need to set up interviews with agents to prove so. I suggest stratifying your data by the following three dimensions: a) tenure, b) current performance (high performer, low performer or average) and lastly c)agent name (for identification purposes). Your output should be agent satisfaction scores (C-Sat surveys given to customer based on their experience with an agent during a call or email) but if it AHT, that is fine, except I would break it down into the components of AHT (see previous post) since AHT by definition is an AVERAGE. Lastly, overlay all of this using the Matrix Plot graphing option in Minitab to view interactions between each input dimension and output. Then, interview those that fall into the following buckets - newbie, high performer vs. oldie, high performer; newbie, low performer vs. oldie, low performer and compare drivers. You should ask questions that really get them thinking and make sure you set up a "safe environment"; i.e. one that is off of the floor, possibly in a conference room, so they feel free to answer honestly. Reassure them that their answers are anonymous and for research purposes only and really try to relate on their level before launching into your questions. Like I said before...Not all that glitters, is gold and such is true with what will drive your human performance related six sigma projects.

Resolution, resolution, resolution...that’s what I always say...and so when I see black belts going after AHT (average handle time) as their key output (KPOV) variable, I cringe. Instead, why not break it down to the components of AHT: Talk Time, Hold Time and After-Call Wrap Time.

Ok, some of you are saying , "what if you don’t include hold time in your AHT calculation?" To that, I would challenge your calculation by saying that you are missing a huge opportunity and understating the true AHT. WHY? If you have a complex product like we do, you will find that during periods of lower agent tenure, your hold time will increase substantially because those newbie agents are somewhat unsure of themselves, even after nesting. Thus, talk time might be affected, but they are more likely to put customer’s on hold during a call to ask a supervisor or lead a question -- Result: a high amount of hold time = large opportunity for improvement. Break it down. Go after one of the three components.

If you only include Talk Time and ACW, then add hold time to the mix. Most switch’s will output hold time, so grab it. Going after AHT will only frustrate the black belt as they try to prove reductions. By reducing one of the components in the calculation, you by default, will improve the overall AHT

In preparation for an award I am accepting for being a pioneer in the CPM (Corporate Performance Management) and BI space for the work done infusing the balanced scorecard (BSC) methodology prior to our deployment of lean six sigma (LSS) , I started thinking about how many blank faces I see when I start talking about the natural overlap between the two methodologies.

There are those who will vehemently argue that there is no overlap, while others see the two schools of thought as having the potential to intersect but not without intervention -- Then there are those, myself included, who view LSS and BSC more holistically -- After all, aren’t they both methodologies for measuring and improving performance from either the top-down or bottoms-up vantage point? As Praveen Gupta quoted in his book Six Sigma Business Scorecard, without a strong grasp of performance metrics, a company can have no clear, quantitative indication of its quality improvements." From this standpoint, let’s dive further into where I think Praveen fell short --> Yes, scorecards are a great way to measure project success...But it doesn’t stop there --

Instead, if you look at LSS and BSC more holistically, there emerges this kind of "proverbial toolkit" to be situationally employed to help 1) measure and improve products or processes and quality improvement initiatives...as well as 2) BSC can effectively help a deployment leader with project prioritization and selection - In fact, it is one of the 5 pathways to selecting and stack ranking potential future projects.

The "proverbial toolkit approach" is a way to build a quality empire, one improvement initiative at a time, without tying up corporate resources or dollars - Huh?

Think of it like this: even in a pure DMAIC organization, do all six sigma projects require the rigor that DMAIC or DMADV prescribe? Well, no...Not when you add the "L" (Lean) to "LSS" (Lean Six Sigma). With Lean, comes the concepts of Kaizen & JIT (’Just In Time’), to name a few. So, should any organization who employs LSS start calling themselves a LSS with Kaizen shop? or LSS with a little bit of JIT?

Not in our eyes. Kaizen, JIT, Lean, Six Sigma all represent tools in our tool-belt; Balanced Scorecards are another tool, equal to those aforementioned in our toolkit. When a Green or Black belt is assigned a project, they shouldn’t be forced to ’pick’ a certain methodology; likewise, when a company starts planning a Six Sigma deployment, they should not force themselves to determine a % to allocate to DMAIC projects vs. Lean projects vs. Kaizens. They will end up moving the target so much to meet the needs of the business, (today, we are a 40% / 40% / 20% shop across all three methodologies; tomorrow, the business shifts slightly, and we are a 50% / 30% / 20%, etc), that they will seem like they are unsure of their program and what they are trying to accomplish . Sounds like a lot of rework to me, and if anybody should know better than to cause a lot of rework in a given process, it is the prescribers themselves, i.e. the deployment leader, MBB &/or GB / BB.

Instead, try looking at as a "Toolkit Approach" with guidelines that mirror business rules, such that they have criteria around them defining which path would most likely yield the biggest bang for the buck without causing work to be scrapped or reworked -- The following are example business rules that one can build around their process.

"If project type A is XXXX, then employ DMAIC with a black belt driving, where XXXX =

• big and hairy
• tried by others but without success
• high DPMO, large gaps between VOC and VOP caused by process variability and/or defects
• top down support and exposure
• 4-6 month expected project duration
• minimum hard dollar savings of $250K
• is a red key performance indicator as measured on the executive scorecard; if it isn’t measured in the same place as the CEO or president measures their success, one should ask why they are taking it on as a black belt project; we manage what we measure, and more importantly, we measure what we manage (aka care about, to be frank)"

If you hear someone say "we need to stop the bleeding" or "quick wins", than you should move onto the next example since both are synonymous with the shorter, "get in, get out" projects ; Thus...

"If project B is YYYY, then employ Lean Principles with a Green or Black Belt driving, where YYYY =

• 1 -4 month project duration
• Process is filled with waste (think 8 wastes)
• Cycle time deficiencies
• Gap between VOP and VOC caused by delivery (time) delays rather than quality (though the latter may be a driver, it isn’t the focus of Lean)
• Something than might be bottoms-up or top-down
• Something than can be driven by a green or black belt"

"If project C is ZZZZ, then employ Kaizen, where ZZZZ =

• 1 week project duration
• New or improved standards can be developed and implemented during the Kaizen event window (or at a minimum, submitted for approval)
• Can be used to supplement both DMAIC and Lean projects at two different phases of the project lifecycle:
  1. First, it can be used to help kick off a larger project from a discovery POV
  2. During the Improve phase, Kaizen events are extremely helpful when there are multiple work streams and processes that need to be improved (though each one should have their own Kaizen event dedicated to improving that individual process - If lumped together, you will be less effective at driving the improvements, as you wont have one process to walk, but many.

Lastly, no matter what type of tool you utilize based on the given criteria, you should leverage the concept of BSC and strategy maps (more to come on the latter point in a separate post). Not only can it help you select your project, but it can also be used to measure and track you GB/BB project status and performance as they move through the project lifecycle. In addition, if you are the GB/BB, as you get into the Control phase or to the point of implementing Visual Controls, SPC/SPM charts, how best to do that than by building a project related dashboard/scorecard that rolls up your outputs into the strategic goals that you are working towards improving, which if done correctly, should have come to the business unit as they cascaded down from the top line senior leadership performance indicators which should only be referencing those metrics that will shape how successful the company was at meeting their annual strategic goals & objectives.

Stay tuned for part 2: What is a Strategy Map in terms of Balanced Scorecards, and how can they help me elevate my Six Sigma deployment to gain true visibility at the executive level in my organization...

Successful operations planning can be a powerful cost reduction and organizational development strategy to help define resources and processes needed to sustain the project’s business outcome after control phase, especially in the contact center space. The black/green belts should not keep the responsibility for the product after delivery, nor be listed anywhere in the control plan. You need to agree ahead of time with the vendor:

a. how the new process/product will be maintained

b. who will have responsibility for maintaining it

c. how will it be enforced in the centers

Process Owner Reviews: Assuming you have already decided amongst alternative project solutions, stack ranked against market conditions, call center performance metrics, like Time to Resolve and AHT, in a prioritization matrix or QFD (my personal fave), has it been reviewed with your process owners? If not, use a QFD to rank your call center initiatives with the least impact to the day to day operations as possible.

Project Closure Approach Transparency: Once reviewed, develop an overall project closure approach for to be discussed with the vendor. In it, identify the resources and schedule for the implementation and control plan reviews - I recommend a 60/40% mix of call center to non-call center representation – Some things to consider:

1. Have the failure modes on outputs and vital inputs of the process been updated in the FMEA?
2. Next, determine how changes to the process happen & who makes them happen :
3. Update the project RACI using the lens of who (roles) and what (responsibilities) will enable your implementation and control plans to be successful (for example, your process owner is certainly a candidate) -- Send assigned tasks to them for review. <Decision Point>
4. Is there a project team role gap (i.e. roles needed but not assigned/available?
5. If yes, have staffing options been identified, either Contractor/vendor or FTE?
6. Determine who is responsible for maintenance and ongoing report-outs – process owner may delegate to an operations excellence role or similar for ongoing support
7. Has a timeline been determined for frequency of SPC/SPM measurements for your control charts; for other visual controls?
8. List tasks associated with your preventative maintenance and control chart KPIs (inputs/outputs) that swing out of control, including:
   1. Have measurement systems been set up to capture project outputs being tracked & how are they being tracked: online/offline?
   2. Are costs associated with post-implementation operations documented and understood in your COPQ analysis? (Black Belt note: Often a hidden cost that gets overlooked during the financial cost / benefit analysis period, though seldom passes the eye of your financial champion).

Enforcing the changes : Control plan hand-off process to your process owner including hand-off of the FMEA, implementation plan and visual control mechanisms.

1. Was information enough for process owners and champion to feel comfortable enough to signoff on belt project?
   1. Do the process owners see any existing gaps to enforcing control plan and preventative maintenance tasks associated with the newly optimized processes and practices within the centers, in-source or outsource?
   2. If not, has sufficient documentation been reviewed and propagated online/offline by the belts for the process owner such that the latter knows where to go when something goes out of control? (Black Belt note: We use Sharepoint to deliver the content)
2. Has a process been identified and provided for how change requests to the process are made, by whom and with what SLA?
   1. Has version control been built into the control plan, should the process need to be reverted?
      1. If so, was there reference to the Preventative maintenance task associated to the control plan input/output by the black belt?
      2. Have you identified the current preventative maintenance task owners? (Black Belt note: Often this is your process owner, but the role / persons may have changed since project hand-off).
      3. Have you drafted “how-to process guides” or “helpful hints” to fill knowledge gaps found to be a critical X in the control plan? (Black Belt note: in call center projects, having a document that specifies “if this call type, then do that action” is highly effective if and only if it is kept in front of agents for each of the Top call drivers (go after 80% coverage of call types; if it is cluttered with too many scenarios, they wont use it).

For your champion & deployment leaders to think about: Are you capturing a project management health metric (i.e. metrics that grade the individual project or black belt)? These should be cascaded down from a program management (i.e. Six Sigma program) level set of metrics. (Black belt note: this will prevent downstream issues with the project success metrics should they not be followed by the process owners so that the belt doesn’t take full blame).