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

A Parallel Process View for Information Technology

The value and impact that a solid Design for Six Sigma (DFSS) approach can bring to an IT business is well known. While many organizations understand the relationship between DFSS and their own project management approach, what they often miss is attention to the foundational concepts of Lean and DMAIC (Define, Measure, Analyze, Improve, Control) to ensure that DFSS is applied most effectively.

The IT practitioners’ situation is uniquely challenging in that they must see their world from two very different perspectives:

1. How the business uses their services.
2. How IT provides services to the business.

Interestingly, both views of the organization distill to one fundamental concept – the value stream, applied in two different ways. And of course, anyone with even limited experience with Lean or Six Sigma will recognize this concept as a critical element of both process management and process improvement.

Better Core Business Processes

From a simplistic point of view, the IT function exists to make the core business processes (marketing, developing, selling, producing and distributing a product or service) more successful. In fact, whether providing its wares to external customers or supporting the management systems and operations of its own organization, the IT function is an operation unto itself. IT’s processes provide products (applications, hardware, networks) and services (security, maintenance, support, technology consulting) that create value for its customers (internal and external).

Users of IT products and services seem to demonstrate a unique lack of restraint when expressing feedback relative to the quality (cycle time, capability and cost) of their customer experience. As a result, when introduced to the utility of the Six Sigma approach, many IT managers immediately embrace the notion that DFSS is the most useful application of Six Sigma to enhance their current project management discipline and delivers better applications, networks or hardware faster and at a lower cost. In executing this well-conceived notion, IT organizations are quick to realize the importance of understanding the customer’s value stream and both the latent and expressed requirements through the effective analysis of use cases and language data. By this point, a typical DFSS project will have facilitated completion of the requirements-gathering component of a project management discipline by executing the Define and Measure phases of the DMADV (Define, Measure, Analyze, Design, Verify) approach.

But the IT dilemma becomes more acute in the Analyze phase of the DMADV cycle when a project team must determine which combination of features and levels of functionality will best satisfy the requirements of the customer(s) in terms of quality, cycle time and cost. To make matters more difficult, the project team must have some way to objectively evaluate cost and quality both in terms of the initial release as well as ongoing support. The DFSS project team must optimize the natural conflict between the need to satisfy the customer requirements and the capability of the complex IT architecture – the combination of people, hardware, networks and management systems that defines the IT organization. Many useful tools exist within Six Sigma to conquer this challenge. They range from the very simple (brainstorming and prioritization matrices) to the very complex (statistical experimentation and simulations). But no objective assessment of the alternatives is possible without quantitatively measuring the various value streams that exist within the IT organization. And furthermore, no meaningful project plan can be developed without the same IT process information.

Back to the Dual Process View

This brings the subject back to the dual process view that characterizes the IT environment. For any given project, a DFSS project team must understand the value stream of its customers. This is often facilitated by some combination of the voice of the customer tools from the DMADV roadmap and the data provided by the customer’s own process management system. (Any effective process design should include the ability to document, measure, monitor, report and control the critical aspects of that process. IT software, hardware and network development projects must take those process management needs into account when participating in the design of new processes. In addition, the new process should be flexible enough to change its management system when critical process characteristics change.)

But this understanding of the customer value stream is not enough. The IT organization must document, measure and control its own value streams if DFSS projects are to be successful. This view then completes the Six Sigma management system within IT by addressing the three process dimensions upon which the Six Sigma methodology is built:

1. Process management – document, measure, monitor and control internal processes.
2. Process improvement – use the DMAIC cycle repetitively to continuously improve.
3. Product/process design – apply DFSS (DMADV) to radically redesign internal processes or to create new products/services for customers.

Dilemma of the Analyze Phase

Inevitably the dilemma of the Analyze phase of the DMADV cycle begs the question: “If we need process management data to execute DMADV projects but we have urgent needs to apply DMADV tools to new projects, do we need to implement process management before applying DFSS in our project management system?” Fortunately, the answer is no. But understand that without an effective process management and improvement system the results of DFSS projects will necessarily be compromised. As a result, the Six Sigma deployment plan for an IT organization must account for the need to document, measure and – where applicable – manage and improve both types of value streams.

One important characteristic of Six Sigma is that no project is perfect and no set of data is perfect. This is particularly true in new Six Sigma deployments where the three process dimensions have not yet been adequately addressed. Choosing to apply DMADV to current or new projects without the benefit of a robust process management infrastructure is a viable strategy as long as there is an explicit plan to document, measure and control the critical value streams within the IT organization. The development of a mature process management system takes time and will ultimately require the participation of most, if not all, IT employees. The result, however, will be powerful as this view of the internal value streams will provide the organization with the basic understanding of Lean principles as it relates to value, waste and process performance measures (including quality, cycle time and cost). This internal process perspective will provide a foundation which will enhance the application of DMAIC to continuously improve internal processes and DMADV to optimize the effect of IT products and services on the customers which it supports.

In both service and manufacturing environments, the IT systems play an important role in determining the capacity, flexibility and capability of its customers’ processes. As a result, the IT organization is particularly suited to deployment of the three Six Sigma process dimensions. Recognizing the need to understand both internal value streams and customer value streams is an important first step to creating a successful Six Sigma deployment in IT.

Continue reading