Fitting the Right Belts for Design for Lean Six Sigma

Every Lean Six Sigma deployment leader must eventually confront the critical decision of how the various Belt roles should be allocated and deployed throughout the organization. Lean Six Sigma has existed for more than 10 years now in a variety of manufacturing, service and distribution environments, and through trial and error fairly standard niches have been carved out for the Black Belt, Green Belt and Yellow Belt roles. Obviously there are differences in these roles from organization to organization, but in general deployments tend to use the roles in the following manner.

Black Belts: This is a dedicated, full-time position focused on process improvement through the use of a variety of problem-solving tools applied in the DMAIC or DMADV project cycles. Black Belts tend to be highly skilled in the use of Lean Six Sigma tools. The reporting structure varies, but in many cases this position reports directly through a separate function that is responsible for deploying Lean Six Sigma with a dotted-line responsibility to process owners or Champions. Occasionally, the reporting structure to process owners or Champions is direct with a dotted-line responsibility to the deployment team (which may include Master Black Belts). Black Belt projects tend to be fairly broad in scope and may rely on the assistance of Green Belts or Yellow Belts. The Black Belt position often requires them to mentor and support Green Belts or Yellow Belts, and it is often an important element of a career development plan for high-potential employees.

Green Belts: This is more of a level of internal certification in the use of Lean Six Sigma methods and tools as opposed to a unique job description. Green Belts maintain functional responsibility and exist within the standard reporting structure as they work Six Sigma projects in areas related to their functional role. These projects tend to be more narrowly focused than Black Belt projects, and they typically fall within the normal scope of the Green Belt’s functional role and scope of influence. Black Belts often assume a role similar to Green Belts when they are repatriated into the functional organization. Green Belts may also bear the responsibility of supporting and developing Yellow Belts in their functional areas.

Yellow Belts: This (or some other color of the Belt spectrum) is typically the name applied to the role of team members participating on Black Belt or Green Belt projects. Yellow Belts are familiar with the methods, tools and language of Six Sigma, and they are expected to be effective participants on Six Sigma project teams. Yellow Belts may also be directly involved in efforts to establish a process management infrastructure by documenting and measuring business processes that relate to their functional roles and scope of responsibility or influence. Like Green Belts, the Yellow Belt term is more a description of a level of certification rather than a specific job title.

The use of these roles over the last decade or so has developed into a robust and consistent deployment scheme in most organizational functions like Sales, Marketing, Operations, Distribution, Human Resources, Finance, IT (mostly) and other support functions. Where the intuitive and standard application of these roles tends to differ is in areas that are project management intensive like Research & Development, certain parts of IT and other functions (like opening new facilities or implementing large projects on the customer site). While the application of Lean Six Sigma or Design for Lean Six Sigma methods to standard project-management approaches is well established, the application of the various Belt roles is still maturing in project management environments.

Lean Six Sigma Fits Project Management Like a Glove

All environments where project management is the defining process experience the same basic sequence of events: they initiate, plan, execute, control and close (IPECC) each project. Whether this process is strictly defined or not, every effort to create something goes through these steps. When DFLSS (Design for Lean Six Sigma) is applied to this process, then DMADV (define, measure, analyze, design, verify) or IDOV (indentify, design, optimize, verify) becomes the tool set that enhances the basic IPECC design process. The various processes tend to integrate with each other as shown in the following figure.

How Processes Integrate

The natural consequence of this relationship is that DFLSS or IDOV becomes a set of methods and tools that facilitates the project management process. This is true regardless of the scope of the project or the nature of the project: construction, hardware development, software development, systems implementation or anything else that requires managed project resources.

Where Lean Six Sigma is integrated effectively with project management, the DFLSS philosophy (but not every DFLSS tool) is a core element of every project. Too often organizations make the mistake of distinguishing between DFLSS projects and “other” projects, thereby perpetuating the notion that DFLSS is a selective project-based approach. Since the goal of DFLSS is to deliver better results faster with fewer resources, then the issue is not which project is a DFLSS project but rather which DFLSS tools are most appropriate for any given project. Regardless of how the projects are executed – from a highly iterative agile approach to a stage-gated waterfall approach – DFLSS is a method that is integral to the project management process.

Organizations that try to differentiate types of projects tend to waste time and energy in the classification without accounting for the waste of failing to standardize an approach by fully integrating the tools and methods in their project management processes.

But One Size Does Not Fit All

Once the integration of DFLSS or IDOV with IPECC is defined, the allocation of the Belt resources becomes a challenge. Many organizations continue to struggle with this because they attempt to apply the resources in project management environments according to what is familiar: the mature application of Belt resources in a more operational process environment as described above. While the roles above align fairly well to project management environments, there are a few important, but different, features.

Black Belts: In the project management arena, projects tend to become more outwardly focused. This is because all projects, especially in systems implementation and hardware and software development, are solutions to problems or opportunities in the customer’s (internal or external) environment. The output of any given project (on time with all required features fully functional) has a direct impact on an organization’s value stream. Consequently, improving the project management process means that improving the ability to deliver all requirements, fully functional and on time, becomes a priority.

This tends to force Black Belts to focus on efforts to improve the processes of gathering and defining requirements through better understanding of the customer’s context. This effort improves on-time delivery by minimizing defects found downstream due to defects in the requirements engineering process, and it improves functionality, thereby ensuring that the right requirements are delivered with the right level of capability.

Of course, this is not to suggest that Black Belts never address improvement opportunities through the reduction of waste that creates excessive consumption of resources within the project management process, especially since that waste often delays project completion. Better understanding of the customer environment is a priority, not an obsession to the exclusion of other opportunities.

Companies that deploy Six Sigma successfully in their project management processes recognize that project management resource consumption is only a fraction of the cost of projects delivered late or with reduced functionality, especially when those failures affect the value stream. As noted above, the Black Belt role is best structured as a dedicated, full-time position focused on process improvement, with Black Belts retaining the role of supporting and mentoring Green Belts and Yellow Belts.

Green Belts: This role takes on less of an improvement project orientation and more of a project management orientation by using the understanding of the DFLSS tools to drive integration with the project management system. Project managers make excellent Green Belts, as do other managers (like architecture or systems specialists) who are exposed to a broad view of the project management process. This enables the Green Belts to practice and encourage use of the DFLSS methods and tools across a wide scope of the project management process.

Technicians, developers or engineers often do not make good Green Belt candidates because their view of the project management process tends to be limited to their focused area of responsibility, which will make many (but certainly not all) of the DFLSS tools seem irrelevant. Green Belts in the project management environment do tend to work on improvement projects, especially those that reduce waste in the project management process or align to Black Belt projects. Since most Green Belts will naturally have some management responsibility, their role will include mentoring and supporting Yellow Belts.

Yellow Belts: This is the more appropriate role for technicians, developers or engineers – especially those that have a limited view of the project management process. While Yellow Belts should be introduced to the methods and tools of the DFLSS process, the practice of those tools will typically be limited to their specific areas of expertise.

For example, requirements engineers may use VOC and language processing methods; design technicians may find themselves frequently using concept selection, robust design and tolerance analysis techniques; software developers may practice agile programming tools; and test engineers may apply DOE or combinatorial test methods. Few of these roles, however, will regularly practice the full range of DFLSS methods and tools, so in-depth understanding of all the techniques is typically not appropriate. Yellow Belts should participate on both Black Belt and Green Belt teams, and their process management responsibility should be to document and measure work processes in their areas of expertise.

All over the world, various organizations have successfully deployed Lean Six Sigma techniques to parts of their organizations that are driven by intensive project management methods. The synergy between traditional project management (IPECC) and DFLSS or IDOV is well documented, and while the general methods seem to integrate well, the traditional Six Sigma roles are not as easily leveraged to project management environments. Organizations that successfully deploy Lean Six Sigma in project management environments like R&D, IT project management and construction recognize that DFLSS is an integral part of the project management process and that the roles of Black, Green and Yellow Belts must be carefully tailored to the project management environment.

Continue reading

Designing Financial Services with DMEDI

As banking operations and check processing enters the 21st Century, so too the ways financial institutions design processes enters a new age. Long gone are the days of trial-and-error in bringing new products, services or technologies to market. Companies need to be able to implement solutions effectively – the first time – to provide superior customer service, while decreasing cost and boosting shareholder value.

In recent years, many financial organizations have turned to some form of Six Sigma or Lean Six Sigma in their search for tools to help them decrease defects and rework while increasing process velocity. But the basic toolkit associated with these methodologies does not incorporate the type of rigor needed when you want to invent a new service, product, or process (or overhaul something that is already in place). One methodology is powerful enough to handle the task. It is Design for Lean Six Sigma (DFLSS).

Design for Lean Six Sigma (DFLSS) is a complement to Lean Six Sigma’s DMAIC methodology. The basic difference between DFLSS and DMAIC is DMAIC focuses on bettering existing processes while DFLSS focuses on new processes or complete overhauls of existing processes. DFLSS concentrates a great deal of effort on designing a process to reach Six Sigma levels before it’s implemented, creating a completely new, Six Sigma-capable process from the start.

The key issue when you design a new service or process is that there are a lot more unknowns than when you tweak what you already have. You don’t really know what customers want. You don’t really know which models or approaches are workable. You may not have existing capabilities to provide the needed functionalities.

The preferred improvement model used for these situations goes by a number of names: some organizations call it DMEDI (for Define-Measure-Explore-Develop-Implement), some call it DMADV (for Define-Measure-Analyze-Design-Verify), and some just use the more general terms of Design for Six Sigma or Design for Lean Six Sigma (DFLSS). Though the labels differ, all are strategies for executing projects that require a significant amount of new design.

Define: The project team comes together with its sponsor to develop a well-defined charter that has clear ties to the business strategy and line-of-sight linkage to significant financial benefits

Measure: The team focuses on understanding the Voice of the Customer, information that will be used to design best-in-class products and services

Explore: The team innovates to develop multiple solution alternatives and selects the most promising concept, as well as confirms a high-level design

Develop: The team uses Lean and Six Sigma tools and simulation to create a robust design

Implement: The design is piloted, a control plan is developed, and the new product or service is launched

Define

The objective of the Define phase is to develop a well-defined charter for the project team that includes: a product/service description, business case, project goals, project scope, a high-level project plan, and team members. The charter should be sufficiently detailed so that the business objectives and the scope are clear to both the team and the management.

In addition, there are two major elements of risk to be considered in a DFLSS project. First, the risk that the project will not meet its objectives, which would primarily be a risk to the schedule and to benefits (technical, cost, schedule, and market risk). Second, there are the risks that the project poses to other elements of the business.

Measure

The purpose of Measure is to understand the Voice of the Customer (VOC), and to translate customer feedback into measurable design requirements.

The first step in capturing the Voice of the Customer is determining the appropriate customer segment. While in theory anyone in the world could buy your services, there is a particular subgroup, or segment, that is most likely to buy. If you’re interested in achieving maximum performance, you want to focus your products and services on the customer group where it is most likely to resonate in the marketplace.

Focus on the customer segment(s) that align with the company’s business strategy, are attractive from a size and profitability standpoint, and align with the business’s capability to satisfy them.

Start the VOC process by taking advantage of existing and available information within the business. Every company has customer contact sources that can provide a baseline for service/product design. Some sources to look at are complaints, compliments, returns or credits, contract cancellations, market share changes, customer referrals, closure rates of sales calls, market research reports, completed customer evaluations, industry reports, available literature, competitor assessments, web page hits, or technical support calls.

Once you understand the gap between the customer information you already have and what you need, use proactive methods to gather additional information. The most common techniques are interviews, focus groups and surveys.

Translating needs into requirements — If you survey customers and ask which features they would like to see in your services, they will undoubtedly say, “All of them!” However, customers don’t value all features equally. That’s why the DMEDI process exploits a tool known as Quality Function Deployment (QFD) that helps you understand customer priorities. The secret to QFD’s success is that it establishes design requirements that are:

◈ Measurable (quantifiable) so you can tell whether or not you’ve met them.
◈ Solution-independent, meaning the requirements aren’t linked to predefined solutions that the design team might have in mind (allowing for much greater creativity).
◈ Directly correlated to customer needs, so you know that you’re addressing issues that are important to customers.
◈ Easy to understand.

To achieve these goals, QFD walks through a series of steps:

1. Identifying customer needs from the VOC data you gathered
2. Prioritizing those needs
3. Establishing design requirements that address all customer needs
4. Prioritizing those design requirements (to help focus the design effort)
5. Establishing performance targets

These steps are linked together deliberately, so that at the end you can trace a path directly from customer needs to specific elements of the design.

The team also will assess the impact of failing to meet the targets and specifications, including an assessment of different risks (to the customer, to the business) and whether the organization’s current competencies are well matched to meet the performance targets.

Because there is such a learning curve in the Measure phase of a project, teams often discover quick wins: changes that look to be a sure thing, are easily reversible, and require little or no investment. The team should take advantage of quick wins as soon as possible, and begin accruing financial benefits.

Explore

After defining requirements, the team needs to answer the question: What is the best way to meet our customer needs at a conceptual design level?

This is where innovation occurs. Usually, teams will discover that there are conflicts between customer needs and the company’s ability to meet those needs, conflicts between different design parameters, or conflicts between cost and performance. Often, trade-offs or compromises are made — though finding solutions to resolve these conflicts rather than compromise leads to more innovative products and services.

The tool used here is a component of QFD called “functional analysis.” Every service or product has certain things that it must do in order to perform acceptably from a customer’s viewpoint. Functional analysis breaks the service down into its key tasks. For example, rather than brainstorm concepts for an imaging service at a system level, the team would identify the functions (prioritize paper items, scan paper to create images, validate scans, forward images) and then brainstorm solutions for each of the functions (e.g., prioritize paper images — on-us listing, transit listing, equipment, software).

The goal is to prioritize the functions that have the strongest link to the Voice of the Customer, because those will be the foundation of any new design. You also can use the House of Quality to flow down the high-level design targets into smaller design elements.

After generating many interesting concepts, the team will need to narrow the field to the one or two most promising alternatives. (Notice the key assumption that the team has multiple concepts to consider!) You want to be sure that all feasible alternatives have been explored before deciding on a single concept. World-class innovations don’t come from a one-horse race. If the investigation of concept ideas only brought about one or two options, it is strongly recommended you develop a plan to create additional options before moving forward.

Develop

The Develop phase is where the detailed design occurs. In addition to designing the core service, attention should be paid to developing information technology elements of the project, establishing a plan for human resources, developing sites/facilities, and purchasing materials that will be required for implementation.

As the solution is developed, the team should take advantage of lean tools to maximize speed and minimize waste in the new process. In particular, Value-Added Analysis is beneficial to many projects. The process map of the to-be service is reviewed and each step analyzed and assigned to one of three categories:

◈ Customer Value Add — Tasks that the customer would be willing to pay for (i.e., adds value to the service, provides competitive advantage).
◈ Business Non-Value Add — Tasks required by business necessity (i.e., financial reporting) but that do not provide value to customers.
◈ Non-Value Add — All other tasks (i.e., approvals, all rework loops, waiting).

Implement

The objective of the Implement phase is to successfully conduct a pilot, transfer ownership of the project to the new process owner, and implement the new service. One of the key benefits of the Six Sigma methodology is the rigor around implementation and process control. Everyone has worked on a project that started off well only to watch it fall apart when the solution was implemented. With solid up-front work in the Implement phase, these issues can be avoided.

Continue reading

DFSS Study: Develop Software to Track Drug Side Effects

Integrating Design for Six Sigma (DFSS), IDOV (identify, design, optimize, validate) roadmap and selected DFSS tools in the information technology (IT) system development methodology can strengthen the business focus of IT system delivery. Adding additional steps at the beginning and end of the traditional system development cycle for DFSS can support the better understanding of the business process and the customer requirements involved, and allow the organization to realize proven business results as well as continuously monitor process metrics.

A pharmaceutical company, Medistar, applied DFSS tools to develop a new pharmacovigilance system (captures and analyzes observed drug side effects) in association with the launch of a new drug. Such a system is necessary since after its market launch a drug is exposed to a much larger population than in the clinical studies conducted during the drug development. This can lead to a change in the known safety profile of a drug. Medistar recognized the need for an updated system using newer technology. Under the old system a physician manually completed a registration form and mailed it to the respective field service agent who then transferred the information manually into yet another system. The information regarding the adverse effect was then forwarded to the pharmacovigilance team. This process was slow, cumbersome and could take several days – too long given the potential consequences of an unidentified risk.

With the launch of the new drug Medistar wanted to play it safe – every side effect should be immediately identified and addressed. From capturing all relevant patient data to the medical director making a decision, all major process steps and influence factors were in the process-scope of the project.

The Identify Phase

At the beginning of the identify phase the project sponsor, the medical director of Medistar and the project manager agreed on a team with representatives from the IT department and pharmacovigilance organization. One of the team’s first tasks was to identify the system needs and what business processes it needed to address. The goal was to understand the process, its internal and external customers and their requirements before developing the system. Therefore, the team developed a high-level process map using SIPOC (suppliers, inputs, process, output, customers). The developers of the SIPOC map recognized that not every adverse event would necessarily entail a counter measure.

Figure 1:SIPOC

The next step was comprehensive voice of the customer (VOC) data collection. The team interviewed representatives from the pharmacovigilance teams, the medical director and the chief executive officer of the company. Most of the customers immediately referred to IT software requirements instead of expressing their needs and expectations with regards to the business processes lying behind the system. Only by repeatedly challenging the answers were the customers’ true process related needs identified. The team translated those requirements into measurable CTQs (critical to quality), which served as the basis for defining key performance indicators (KPIs) for the new pharmacovigilance process.

The translation of customer needs into CTQs and their prioritization was done using quality function deployment (QFD). Accordingly, the two main CTQs of the “should-be” process were the time between a side effect (or event) reported to Medistar and notification of the medical director, and the frequency with which the medical director could make a decision based on this information.

Figure 2: QFD 1

All CTQs were summarized with target values and tolerances in a design scorecard. This was used throughout the project to measure and document the system performance. Since the company already had a pharmacovigilance system in place (with reduced functionality), as-is performance data for the first four CTQs were collected and included in the scorecard.

Figure 3: Design Scorecard

The Design Phase

At the beginning of the design phase, the team created a detailed process of the should-be process. This showed detailed process steps and responsibilities as well as first requirements with regards to the new pharmacovigilance system.

Figure 4: Should-be Process Map

Using this map the team started defining the user requirement specifications (URS) for the system. In a workshop with previously interviewed customers URS were identified and – in order to ensure that all previously identified CTQs were considered – a QFD 2 matrix was used to map and prioritize the URS against the CTQs. The main priorities from a user perspective were a user-friendly input mask and the ability to automatically create summaries and detailed reports.

Figure 5: QFD 2 CTQs and User Requirements

In addition to the above requirements other technical, system and data requirements were defined. For example, the system should include a security system with user access, including permanent access to all information for the health authorities and other specific standards imposed by the company.

On the basis of this information an initial conceptual design of the new pharmacovigilance system was developed, and it was revealed that an off-the-shelf solution was not available. An existing software system, however, could be customized to meet the needs.

Another important step in the design phase was the development of functional specifications in accordance to the previously described system requirements. The team opted for the application of QFD 3, as this could guarantee traceability of the requirements. The team began to define service level requirements for the future maintenance and support organization of the pharmacovigilance system.

The Optimize Phase

The optimize phase was typical for a software development project. It included a detailed adaptation of the software according to the customer needs and the establishment of necessary testing and validation procedures. For the description of test cases the previously created QFD 3 was helpful and provided an overview of system requirements and functional specifications.

The Verify Phase

The added value of DFSS tools in the last phase of software development was to ensure the effective handover of the IT system to the process owner – the head of the pharmacovigilance team.

In coordination with the team leader, the project team developed a dashboard to monitor the process performance. Based on previously defined CTQs key performance indicators (KPIs) were defined – how often they had to be calculated, by whom, and to whom they had to be reported.

Graphic 6 provides an overview of the different aspects of the dashboards.

Figure 6: Dashboard Definition

During the verify phase the users were trained on the new system and the old pharmacovigilance system was shutdown. The transition from the old system to the new went well and was in place prior to Medistar launching the new drug.

Continue reading

Promises of Brand Strategy and Design for Six Sigma

“99.44 percent pure”
“It takes a licking and keeps on ticking”
“When it absolutely, positively has to be there overnight”
“The ultimate driving machine”
“We bring good things to life”

For recent generations of Americans, the slogans above have become synonymous with the high-profile brands they represent. But these words are not simply clever taglines. They are in fact shorthand descriptions of each company’s competitive strategy. These words describe what the companies are pledging to deliver as well as what is special about their products and services. In the cases of Federal Express, BMW and General Electric, consumers and stockholders would agree that the success of these brands is a function of both the relevance of their promises and how effectively and consistently the companies are able to keep them.

But what does making good on a brand promise get a company? First of all, it means the company is able to consistently deliver the products, services and experiences it promises to deliver. When this happens – and customers know about it – the customers benefit from easier shopping, reduced risk, greater perceived value and increased satisfaction. Resulting business benefits include lower marketing costs, greater pricing independence and higher net income.

Brand Promises Are Not Just Talk

Coca Cola, for example, can today sell a six-pack of its Coca Cola Classic for $2.50. Down the grocery aisle, a store brand virtually identical in its ingredients fetches a mere $1 for a six-pack. Coca Cola’s “brand tax” –which most consumers do not object to paying – has vaulted “the real thing” to No. 1 in Interbrand’s annual brand rankings, with its brand valued at more than $67 billion, according to BusinessWeek. Now that’s a powerful – and valuable – brand promise.

The top organizations in Interbrand’s 2005 rankings include not only Coca-Cola, Microsoft ($60 billion), and GE ($47 billion), but also Disney ($26 billion), McDonald’s ($26 billion) and Ford ($13 billion), companies currently struggling but continuing to be competitive in large part due to their powerful brands. Data from Interbrand and BusinessWeek illustrate the increased financial value of a powerful brand(Figure 1). As the experiences of these companies demonstrate, success is clearly related to keeping promises made to consumers, because an unkept brand promise means a failure to deliver the product, quality, service, experience or pricing customers expect. Consider “Born to perform,” “The document company” and “Reach out and touch someone.” The fact is that Jaguar’s U.S. sales in 2002 were 61,204 units and 45,875 units in 2004. Xerox was ranked 26th among the Fortune 500 in 1994 and 130th in 2004. And AT&T’s revenue/income in 2000 was $46.8 billion/$12.8 billion and $30.5 billion/-$10 billion in 2004. These companies’ sales and financial results tell the story.

Figure 1: Growth in Investment Value of Top Brands Versus S&P 500 (1990-2002)

Source: Stephen Root in “Branding for Banks,” UBS News for Banks, Vol. 4 (2003)

The reality is that building a strong brand means delivering maximum value to customers as consistently as possible. And that means every employee delivering on the brand promise, in every action affecting suppliers, coworkers and customers, every time. While most brand strategists might not immediately consider it, putting Six Sigma to work is one way to achieve this level of adherence to a brand promise.

Strategy, Marketing Communication and Operations

An effective brand promise rests on three legs – business strategy, communication of the promise and implementation (Figure 2). It is the third area – implementation – where plans often go astray. It is no coincidence that in organizations building vibrant, high-value brands, the constituencies responsible for the three legs – executive, marketing and operations teams – work in lockstep. The puzzle, for some, is how to get there.

Figure 2: Key Elements of Brand Promise Delivery

Six Sigma – too often viewed as being only about wringing variation and cost from business processes – is, in fact, a versatile, effective framework for connecting executive goals (business strategy), marketing communication (brand promise) and management (operational activities).

Consider the case of the business bank that wanted to increase its share in a regional market. The bank used the DMADV roadmap of Design for Six Sigma (DFSS) and adapted it for brand strategy (Table 1). By applying DMADV, the organization realized that to advance from the business strategy to marketplace results, it was necessary to first understand the brand, define the brand promise and identify specific actions required to deliver on it (Define, Measure, Analyze). Finally, the organization needed to make sure that the defined brand promise actually was fulfilled (Design, Verify).

Table 1: Adapting Design for Six Sigma’s DMADV for Brand Strategy
Design for Six Sigma	Brand Six Sigma
Define the project goals and customer (internal and external) deliverables.	Ensure that operational activity is delivering on the competitive advantage and customer expectations created by the brand promise.
Measure and determine customer needs and specifications.	Determine the measurable extent and scope of competitive advantage and customer expectations created by the brand promise.
Analyze the process options to meet the customer needs.	Work back from the brand promise through brand associations and tangible brand attributes/CTQs to ensure that operational building blocks – business goals, organization, processes, administration and metrics – are producing the competitive advantage and delivering on customer expectations generated by the brand promise.
Design detailed processes to meet customer needs.	Design and implement the operational building blocks.
Verify the design performance and ability to meet customer needs.	Use measurement to verify that the operational building blocks are producing the tangible brand attributes/CTQs contributing to the brand associations and brand promise.

The bank’s marketing team identified customer segments and their respective product and service needs, preferences and priorities; researched competitive threats and opportunities; and gathered complete information about the business itself – its economic model, strengths, weaknesses and internal capabilities. On the basis of that work, the organization was ready to commit to a clear brand promise: “The bank that helps small businesses succeed” (Figure 3).

Figure 3: Creating the Brand Promise

This is the point at which the brand and business strategies of many organizations’ falter. The advertising and point-of-purchase campaigns take wing, but nothing else changes. Customer expectations are raised and then dashed, with predictable results. To avoid this outcome, the business bank employed DFSS techniques to transform the brand promise into “brand associations,” “tangible brand attributes” and “operational building blocks,” ultimately defining very specifically how the organization was to deliver on the promise. And because executive, marketing and operations stakeholders participated together in the process, strategic goals, expectations and planning were understood and aligned effectively throughout the organization.

A Real-World Promise and Its Parts

As this bank example illustrates, defining the brand promise in operational terms involves three critical steps (Figure 4):

1. Translating the brand promise into specific brand associations or CTQs: Here, marketers, operations management and Six Sigma practitioners study the brand promise to identify the characteristics that typical customers will associate with it. These hypotheses are then tested in customer research. For the bank, the list of brand associations included:

◈ Professional, knowledgeable banking staff

◈ A bank that knows its clients as individuals

◈ Rapid loan processing

◈ The customer’s ability to make more money as a result of the banking relationship

◈ And others…

Figure 4: Defining a Promise in Operational Terms: Focus on 'Rapid Loan Processing'

2. Converting each of these brand associations into tangible brand attributes: For this bank, it was decided that “rapid loan processing” would require:

◈ Easy-to-understand paperwork

◈ Online application capability

◈ Online tracking of application progress

◈ Easy access to a banker who knows the client and the loan application

◈ Rapid loan approval

◈ Rapid provision of loan funds

3. Defining how each tangible brand attribute will be delivered operationally: Implementation of the attributes depends on some combination of human resources, processes and technology. For example, for just one attribute of rapid loan processing – easy access to a banker who knows the client and the loan application – there were implications for:

◈ Job specifications, hiring and staffing

◈ Training

◈ Loan evaluation and internal communication and reporting procedures

◈ Electronic case files

◈ Hours of operation

◈ Availability of banker email and cell phones

A Cautionary Tale

When laid out in the example of this regional business bank, the connections between strategy and operational building blocks seem almost too obvious. But history offers many examples of organizations that somehow lost the connection between their brand promises and the brand associations, attributes and building blocks needed to deliver them.

Here is just one: Between 1974 and 1986, Schlitz (“The beer that made Milwaukee famous”) lost 93 percent of its brand equity chiefly because of its decision to lower production costs. A premium brand – in fact, the No. 2 brand in its category at the time – Schlitz cut its costs in 1974 by changing ingredients and by reducing fermentation time from 12 days to four. While the cost reduction enabled Schlitz to build sales with aggressive discounts and promotions (precisely what Ford and GM are doing today), consumers noticed a difference in flavor that, coupled with the word-of-mouth story that the company was making “green beer” (improperly aged), motivated them to switch to other premium brands.

As a result, Schlitz went from selling 17.8 million barrels of beer to selling less than 1 million barrels per year. The problem, of course, was that Schlitz failed to maintain key brand associations – including taste and a reputation for quality brewing – critical to drinkers of Schlitz beer.

Continue reading

Creating a Recruiting Process: DFSS for Process Design

The following case study illustrates how a pharmaceutical company applied selected DFSS (Design for Six Sigma) tools to develop a new recruiting process for sales representatives. Tools and activities are described along the IDOV (Identify, Design, Optimize, Verify) phases, which served as a guiding roadmap through this process design project.

Identify

The need to completely redesign the recruiting process resulted from two weakness in the existing process. First, with an average of 60 days to fill a vacant sales representative position, it simply took too long. Second, due to a growing market in the upcoming three years, an increase of the sales force by 10 percent was planned, and the company wanted to organize its hiring process to make it as effective and efficient as possible.

Every day without a sales rep in a specific region meant a significant loss of revenue. Therefore, all vacant positions in Europe were in scope of the project. The process cycle time was measured from the point of time when the previous sales rep quit the job until the first working day of the new sales rep.

Under the project lead of a human resources (HR) associate, a team with representatives from sales and HR was established. Additionally, a steering committee with members from the same departments and from IT and Controlling was set up. They would meet at the end of each IDOV phase to review the project progress and to make go or no-go decisions for the next phase.

As one of the first steps, the team conducted a voice of the customer (VOC) data collection. Twenty district managers and four HR representatives who had all been involved in at least one recruiting process in the past were interviewed. The main questions to determine the customer needs, their relative importance and measurable CTQs (critical to quality) were:

◈ Which aspects of the recruiting process are important to you?
◈ On a scale from 1 – 5, how important are these aspects for you?
◈ How would you measure that the process is performing according to your needs, and how would you know that your expectations are not met?

The results from this internal VOC were structured via quality function deployment (QFD), as shown in QFD 1 in Figure 1. This showed that in addition to the recruiting cycle time, the most important CTQs were:

◈ How often the new employee could already be selected during the first interview round (i.e., no need to run a second round of interviews)
◈ How long it takes to establish the interview schedule
◈ How often the new employee agreed to the initially offered compensations and benefits (i.e., no re-negotiation of the contract)

Figure 1: QFD 1

The most important CTQs were summarized in a design scorecard (Figure 2). Using historically collected data, a first baseline could be established that showed the performance of the customer requirements at the project start. This baseline information was also used to set the project goals.

Figure 2: Design Scorecard

Design

At the beginning of the Design phase, the team conducted a functional analysis. In a process design, functions are the high-level process steps. Developing functions enabled the team to define the necessary steps of the recruiting process without immediately having to think about solutions, detailed concepts or a detailed process design.

The team used a function tree (Figure 3) to analyze the process steps. This allowed for a definition of the process on levels 1 and 2.

Figure 3: Function Tree

In order to determine those functions that would contribute most to meet the customer requirements, the team used the QFD 2 (Figure 4). This highlighted that the next step, the detailed process development, should mainly focus on these process steps:

◈ Create requisition

◈ Interview candidates

◈ Prepare compensation and benefits package

Figure 4: QFD 2

Optimize

The Optimize phase started with the detailed process design. Using a deployment flow chart, detailed process steps, roles and responsibilities for the previously prioritized level 2 processes were defined. Figure 5 shows the process for planning and conducting the candidate interviews as an example.

Further detailed process design elements were:

◈ Conduct an agency briefing meeting with HR, the hiring district manager and an external agency

◈ Standardize the number of interviewers and interviewees

◈ Parellelize the processes, interview candidates and prepare the contract

Figure 5: Detailled Process Mapping

Furthermore, detailed design elements in the categories of information systems, human resources and templates and tools, as well as supplier quality were developed for the same five prioritized processes steps. Figure 6 shows these design elements per process step. Among others, the team decided to establish an internal talent data base, to develop and conduct mandatory interviewer trainings, to create specific templates and guidelines for interviews, and to collaborate only with pre-qualified agencies.

Figure 6: Detailed Design Elements

As a last step in the Optimize phase, a risk analysis for the new process was conducted using the failure mode and effects analysis (FMEA) approach. The objective was to identify potential failure modes and their potential causes upfront so that appropriate mitigation actions could be determined. An extract of this FMEA is shown in Figure 7.

Figure 7: FMEA

Verify

The DFSS team piloted the implementation of the new recruiting process in three regions and collected new data for the CTQs. They also gathered and analyzed information with regard to the highest prioritized failure modes from the FMEA. In doing this, they wanted to validate what the critical process steps were that had to be controlled as leading indicators of the desired (lagging) process performance.

Based on the pilot experiences, the team made final modifications of the process. Among others, they decided to have the contract already prepared before the second interview date (even if that meant that up to three contracts had to be created in case three candidates were still left). All critical process steps, leading and lagging indicators, and a reaction plan were summarized in a process management chart (Figure 8).

Figure 8: Process Management Chart

After this successful completion of the pilot phase, the team handed the new process over to the process owner, in this case the head of HR. She was responsible for the implementation of the process in Europe. Six months later the first results of the implementation could be measured, and they fully met the expectations of all stakeholders.

Continue reading