The World’s 5 Biggest Projects, and How They Could Benefit from Six Sigma

Six Sigma began as a way to improve business processes at two large global enterprises. Both General Electric and Motorola founds ways of developing the methodology and using it to improve their corporate structures. To much success, both companies, and hundreds more, now use Six Sigma for every project, process, and task. Although Six Sigma has become relevant in multiple industries, there are still projects that could benefit from the organization and structure of the business methodology. Around the globe, multiple infrastructure and logistical projects are facing issues that can easily be solved with Six Sigma. In today’s article, we will analyze five unique projects across the world and how they could potential benefit from Six Sigma.

Midfield Terminal at Abu Dhabi International Airport – UAE

Abu Dhabi, the capital the United Arab Emirates and home to nearly 2.7 million people is undergoing a massive airport expansion. To better serve its citizens, and to a degree compete with its sister airport in Dubai, Abu Dhabi is constructing a new Midfield Terminal. Once completed, the new terminal will bring the airport’s capacity to 30 million passengers annually. However, numerous setbacks and delays have pushed the finish date from 2017 to fall 2019. The first area Six Sigma could improve this construction project would be to hire competent project managers. As certified Six Sigma professionals, these employees understand the need to follow strict guidelines and complete tasks in specific timeframes. Although other Six Sigma tools can help improve this project’s completion, adequate management is the priority.

Hyperloop – USA

Founder of TESLA, Elon Musk, is working on his latest project, Hyperloop. This project focuses on creating an innovative mode of transportation for both people and freight inside pods that move through a reduced-pressure tube. Hypothetically, these pods would exceed the speed of modern airlines and offer convenient service to large metropolitans. Being energy efficient, quiet, and exhilaratingly fast, what’s not to love? Unfortunately, the Hyperloop project faces strong criticism regarding emergency evacuations, passenger discomfort, and the likelihood of an accident. To combat these present issues, the project would benefit from the Six Sigma tool DMAIC. This acronym stands for Define, Measure, Analyze, Improve, and Control. For each critique, Hyperloop could use this tool to disprove any uncertainties investors, engineers, or passengers may have in this innovative transportation system.

South-North Water Transfer Project – China

Since the 1950’s, China has faced a water shortage problem. While the southern part of the country is abundant in water via the Yangtze River, the north is drastically more arid and lacks adequate irrigation. Currently, a multi-decade long mega project is being carried out in the People’s Republic of China. This project is known as the South-North Water Transfer Project. It aims to bring water from the Yangtze River to the northern territories through a series of three canal systems. Although bringing water to cities in need, this project faces a strong backlash from opponents.

Of the arguments against the project, the most prominent are fears of water wastage through evaporation, depleting the Yangtze River too much, and raising the price of water exponentially. In order to troubleshoot these issues at hand, the project would benefit greatly from the Six Sigma tool of Simulation Modeling. This tool would help not only visualize the risks this project faces, but also their severity and impact on the surrounding environment.

London Crossrail Project – England

London is home to one of the world’s largest and oldest underground metro systems in the world. Since the first tunnel dug in the late 1800’s, London’s underground has expanded and flourished in all directions. However, with the need for longer tunnels, more trains, and larger stations, the City of London has sought a massive expansion project. Known as the London Crossrail Project, the city plans to add 10 new lines, connecting to pre-existing stations and lines. While parts of the project will open in 2017, competition is not expected for a further three years.

One area where Six Sigma would benefit the London Crossrail Project is by implementing root cause analysis. As a tool used to locating and resolving the problems of critical errors, this can help prevent further delays. Additionally, this tool can help problem solve issues such as connecting to older metro lines with, passenger transfer times, and overall improvement of service.

 Hyderabad Metro Rail – India

Hyderabad, India’s 7th largest city at nearly 7 million citizen, is undergoing construction of a brand new metro rail system. As the first of its kind, the Hyderabad Metro Rail project will bring communication-based train control to India and alleviate the growing transportation needs in the south. Upon completion, there will be a total of three metro lines with 64 stations. However, the exact completion date is still unknown due to a series of delays. First, the initial start day was delayed by over a year. This delay led to an increase in the project’s budget by over $280 million. Additionally, a lack of government and private funding has created a risk for project underfunding.

There are multiple areas the Six Sigma methodology would benefit this project. However, the most useful would be value stream mapping. This Six Sigma tool allows investors, managers, and engineers to see exactly where funding is going within the project. Likewise, the cost of particular variables and aspects of the metro rail would become visible. This in return could lead to cost-cutting measures and improvements in overall efficiency.

Six Sigma has become a world class standard for projects across the world in hundreds of industries. From healthcare to infrastructure, Six Sigma’s process improvement methodology can improve the efficiency of any number of projects.

10 Things Every Black Belt Should Know

Unlike the lower Yellow and Green Belts, Black Belts represent the first level of full-time Six Sigma project management. These certified professionals achieve set goals, lead team members, and perform cross-functional management. Additionally, Six Sigma Black Belts report directly to executive and senior level management. More importantly, a Black Belt will also report to a Master Black Belt and receive training from them. While a Black Belt manages most operations and leads others in training, there are certain traits they must know. Below is our compilation of 10 traits every certified Six Sigma Black Belt should know as a working professional.

The Foundations

  1. The first thing every Six Sigma Black Belt should know is how to be organized. As a natural leader for projects, production, and manufacturing, these employees must understand how to organize their processes. Likewise, organization should be second nature in most cases, with little need for assistance.
  2. Following organization, every Six Sigma Black Belt must be able to effectively communicate the need for improvement. Whether certain benchmarks have been met or a project is just starting, this employee should manage communication between management and team members. As part of the business process improvement philosophy, there is always room for improvement!
  3. Next, a Six Sigma Black Belt should recognize and understand the roles of every person involved in a project. Whether a team leader, project manager, mentor or technical leader, they should know the role each position has.

Data Analysis

  1. Every Black Belt should know how to analyze quantitative data that comes from employees and customers. Likewise, they should understand the differences in variables, measurements, and estimations. Along with analysis, a Black Belt should know how to properly input data into its respected programs and platforms.
  2. Additionally, a Six Sigma Black Belt should know when and which statistical method to use for proper analysis. Furthermore, this should be accomplished when provided only with a metric on a specific scale.
  3. When given raw data, a professional Black Belt will know how to sort, visualize, and assess it without complications. This includes creating histograms, computing statistical measurements, and graphically plotting data in multiple forms.
  4. Linear Regression should be second nature. A thorough understanding of a project’s expected completion timeframe and if it’s along a critical path is mandatory for proper project management. 

The Final Details

  1. Up next, a Black Belt should know how to properly manage a project’s finances and know exactly where the money comes in and goes out. This professional should be able to use a variety of Six Sigma tools to assess the flow of finances, such as with Value Stream Mapping.
  2. In addition, this professional should understand the return on investment for the projects at hand. Likewise, he should be able to calculate the internal rate of return for the cash flow. This in return can help decide the lifetime and priority of a project.
  3. Lastly, the best Six Sigma Black Belt will know the limitations of the methodology. He will understand when a process needs change, how to execute the change, and how to properly manage it from origin to its final stage.

Improve Your Project Management Through Beta Distribution

Distribution

 

beta-distribution-graph

Employers seek certified Six Sigma professionals for a multitude of reasons. However, the main requirement is effective project management. Depending on your certification level, different project management roles may be available at your company. Green Belts and below typically assist project managers; whereas Black Belts and above will lead the projects they manage. As a project manager, though, your employer or clients will ask highly variable questions. How long will it take for 90% of the project to be complete? Where should you focus the most attention? What is the cost estimation for this project with the least variance? As a Six Sigma project leader, your goal is to not only answer these questions but to ensure their accuracy. To better help your tasks at hand, we will discuss Beta Distribution. What is it, how does it work, and how will it improve your project management?

What is Beta Distribution?

In the 1950’s, the U.S. Navy was working on the Polaris nuclear submarine project. This project let to the development of a program known as PERT, Program Evaluation and Review Technique. PERT is a program that measures hundreds of ongoing tasks and predicts their requirements. These requirements include time estimations, future costs, and how much work effort you will need. Likewise, PERT lead to the usage of a three-point estimation technique, that categorizes these requirements into “optimistic”, “most likely”, and “pessimistic”. When calculated with other statistical data, a clear image of a project, its costs, and its timeline is easily seen. For Six Sigma, this three-point estimation technique is referred to as ‘Beta Distribution’.

How Does It Work?

Like other statistical Six Sigma tools, Beta Distribution requires a condensed mathematical formula. However, before diving into the formula, we first need to define the variables needed. First, we calculate a, the “optimistic time”. This variable represents the minimum amount of time a project needs to be completed. Additionally, this factor assumes a small probability of less than 1%. Next, we calculate m, the “most likely time”. Unlike the first variable, mrepresents the time needed to complete a project based on historical data. Because of its higher probability, this factor is at the mode of the Beta Distribution curve. Last, we will calculate b, the “pessimistic time”. As the final variable, this represents the absolute maximum amount of time needed to complete the project. Like the first factor, b has a probability of less than 1%.

With all required factors now available, we input them into the Beta Distribution formula to give us: µ = a + 4m + b6. Where µ is the estimated mean, or average, of all variables. The next formula used for Beta Distribution is variance, which will show how wide the difference is in your variables. This equation is as follows: σ2 = (b-a/6)2. The greater difference in your optimistic and pessimistic values, the greater variance in your overall equation.

 How to Use Beta Distribution?

A tool is only helpful if you know how to properly use it. For Beta Distribution, the three-point estimation technique is a useful tool for optimal project management. With it, you can effectively visualize your project’s expected timeline, identify complicated or risky tasks, and provide confidence to your team. By knowing when to complete a project by, under specific circumstances, you will increase productivity and reduce errors. Likewise, calculating and isolating problematic tasks prepares your project team to handle situations accurately.

As a Six Sigma professional, your goal for every role is to decrease error, improve efficiency, and increase productivity. Using this tool, you will enhance your understanding of business process improvement and become a more advanced project manager.

Developing E-Learning the Six Sigma Way

Your e-learning development program may well be in trouble, and applying the Six Sigma methodology might be the solution. In this real-world Six Sigma – play-by-play – case study about e-learning development, you will learn from the Black Belt what tools were used throughout the DMAIC (Define, Measure, Analyze, Improve, Control) phases of a project to reduce development time by 50 percent and save almost $300,000 per year.

  • What is the true cost of your e-learning development?
  • If a vendor develops your e-learning, what additional costs are you incurring as a result of time spent reviewing and approving the products that the vendor develops?
  • What are the critical requirements of your e-learning customers?
  • Are you meeting those requirements?
  • What are the critical business imperatives that need to be addressed with the e-learning that you currently deliver?
  • Are you meeting those imperatives?
  • In articulating your e-learning vision, are you speaking a language that any business manager can understand?

If the answer to any of these questions is either “no” or “I don’t know,” your e-learning program may well be in trouble, and applying Six Sigma methodologies might be the solution to many of the problems that you are facing. Below is a case study detailing how the Customer Training department of The Depository Trust & Clearing Corporation (DTCC) applied Six Sigma methodologies to its e-learning development and, as a result, validated and exceeded critical customer and business requirements for e-learning:

  • Reduced e-learning development rework by 81 percent
  • Reduced the annual cost of developing e-learning by 30 percent, and
  • Saved the company $282,000.

Case Study Background – The Business Case

The Depository Trust & Clearing Corporation is the largest financial services post-trade infrastructure in the world, with operating facilities in multiple locations in the U.S. and overseas. With the company’s growth, it was becoming more difficult for the Customer Training department to satisfy the increasing volume of customer training requests. A growing product line presented challenges in finding instructors who were certified on each of the products, and the need to rapidly deploy updated information was becoming more and more crucial. The leadership of the Customer Training department was convinced that e-learning would allow the company to satisfy its customer training requests, reduce the cost of training and address the issue of trainer certification. Senior management was sold on the idea, an e-learning strategy was developed and DTCC became one of the financial service industry’s early adopters of e-learning.

Like many other training organizations, the Customer Training department spent significant money and resources researching and purchasing a learning management system (LMS), procuring a variety of authoring software packages and training personnel to use the new software. Monies were allocated to teach training professionals how to develop and deliver e-learning. A benchmarking study was undertaken in order to ensure that the e-learning was “done right,” a goal to convert all of the core instructor led courses into self paced electronic courses was set, a budget was established, a vendor was commissioned to assist with the project and the e-learning journey began.

Two years into the program concerns arose. Only two (of the six core) instructor-led courses had been converted for self-paced delivery. Two still uncompleted courses had been in development for close to a year. The consulting budget that was set aside to convert the core courses was totally spent. The staff of the customer training department openly expressed frustration about 1) the amount of time and rework associated with developing e-learning programs, 2) the cost of e-learning development and 3) the quality of the e-learning that was being developed.

In order to address these issues, additional funds were invested to implement project management methodologies, certify staff as project management professionals, and to improve the skills of the department’s instructional designers. After some initial optimism with these measures, the frustration returned.

The leadership of Customer Training, which was still committed to fixing the e-learning “problems,” volunteered to participate in the company’s second round of Six Sigma projects. An initial project charter was developed. A cross-functional team was assembled and the Six Sigma DMAIC project began.

The Organizational Structure

To fully appreciate the challenges that the Customer Training Six Sigma team faced, it is important to have an understanding of the structure of the organization (as it pertained to e-learning). The customer training department is responsible for delivering training services to participants or customers of DTCC. These customers are financial industry firms. The end users of this training are the employees of these firms. Training requests came to Customer Training in one of three ways:

  1. The member firm or participant would contact their relationship manager at DTCC with a training request. The relationship manager would in turn contact the customer-training department.
  2. Product management would identify a training need and then request that the customer training department develop a program.
  3. The customer training department would examine trend analysis information from service desk calls and develop training based on that data.

In all three cases, however, the development costs of the e-learning was charged to the budget of the appropriate product manager who ultimately had the authority to make decisions on content, look and feel, as well as instructional strategies.

The Customer Training department itself was comprised of four groups: an Information Product group responsible for all customer documentation, a Training group responsible for delivery of all instructor led programs, a Project Management group that was responsible for delivering all customer training projects on time and within budget, and an Instructional Technologies group responsible for e-learning development, instructional design and learning management system administration. A typical e-learning deliverable would require review, approval and sign off by each of these groups, as well as approval by Product Management.

What’s Important – The Define Phase

The Six Sigma team started the project with some advantages. The Customer Training department’s previous experience with project management provided some initial data with which to start. Many Six Sigma projects start with no analytical data whatsoever. At the project kickoff the draft charter was distributed to team members, and the work began refining it and filling in the missing pieces. The initial data seemed to indicate that there was tremendous opportunity to reduce rework, development time, and development cost. Rework accounted for up to 60 percent of the total development time. The development time was as much as 75 percent above the ASTD benchmark of about 200 hours of development time per hour of e-learning, and the development costs were impacted by both rework and development time.

As the team worked to perfect the charter, discussions arose around what the industry standard for e-learning consisted of, and which benchmark to use. It was finally agreed that the ASTD would be the benchmark. The next point of discussion centered on the project’s scope. After much debate the team finally agreed that the scope of the project would be from the time a training need was identified until the e-learning deliverable was approved by product management. The team then agreed on a preliminary project plan with an activity schedule and some initial milestones.

Process Mapping

With the charter approved, the team focused its work on documenting and analyzing the e-learning development process as it currently existed. This was accomplished by developing a variety of maps and charts to give a graphical representation of what was really taking place in the e-learning development process. The first map that the team developed was a supplier, inputs, process, and output, customer (SIPOC) diagram. This diagram, with its few details allowed the team to get a high level picture of what the major development steps were. As the team went through the exercise of developing this map, it became clear that the Customer Training department was developing e-learning without any direct input from the end user of the product.

Figure 1: CTIP Process

Figure 1: CTIP Process

The next graphical depiction that the team developed was a top-down chart. This map created a simple picture of the e-learning development process identifying two levels of detail. The first level showed the major steps in the process, with the second level showing the sub processes under each step. This chart gave a little more detail about the existing process even though it did not show delays, decision points and feedback loops.

Figure 2: Customer Training Development Process

Figure 2: Customer Training Development Process

The most difficult and time consuming graphical depiction of the e-learning process was the functional deployment process map. The team began developing this map with the expectation that it would be a fairly easy process since the team had access to project plans, historical data and subject matter experts to document what was believed to be occurring in the e-learning development process. As the work to develop the map began, it became quite obvious that what was written on paper and in project plans was not what was actually taking place. This exercise made it clear that not only was there tremendous variation in the e-learning development process, but the people who were involved in e-learning development were not quite sure of what tasks should be completed, who was responsible for completing them, and when they should take place.

The functional deployment map took almost four meetings (eight hours) to complete. It required 19 two-and-one-half by two-foot easel pads and encompassed all the walls of a medium sized conference room. This detailed map displayed all of the steps in the e-learning development process in sequential order. It illustrated where each step was performed, and who was involved. The map clearly displayed that the process contained a series of checks and rechecks that virtually guaranteed rework.

Qualitative Analysis

With the cross-functional process map complete, the team then performed a qualitative analysis of the process. The members looked at every step in the e-learning development process and classified each task as customer value added, operational value, not customer value added, or not operational value added. (Customer value added being defined as an activity that: the customer recognizes as valuable, changes the product toward something that the customer expects, or is done right the first time. Operational value added activities are activities that are required by contract or other laws and regulations, done right the first time, or required to sustain the workplace ability to perform customer value added activities).

The team found that there were a significant number of non-value added activities (NVA) in the e-learning development process. Many of these NVAs were the reviews and approvals required by the various groups within the Customer Training department and Product Management. Some of these reviews and approvals were required regardless of whether the reviewer or approving authority was a stakeholder in the deliverable. Removing these activities could potentially reduce the time and cost associated with e-learning development. Many of the steps that are accepted as best practices in the training industry were also identified as non-value added activities when Six Sigma methodology was applied.

Quick Wins

The NVA activities were then all categorized based on whether they were easy to implement, fast to implement, cheap to implement, within the team’s control and easily reversible. The NVAs that met all of these conditions were identified as quick wins.

Figure 3: Non-value-added Activities

Figure 3: Non-value-added Activities

The team then did a failure mode and effects analysis (FMEA) on each of the activities. A FMEA is a process that is used to determine what failures are occurring and what their impact and frequencies are. The FMEA validated that removing a step would ultimately do the process more good then harm, and also ensured that the proper controls were in place so that removing the step would not cause the process to fail. With the FMEA complete, the team agreed to implement ten quick wins. These quick wins basically removed redundant meetings and multiple levels of reviews and approvals from the process.

Voice of the Customer

With the quick wins identified the team began to work on defining customer requirements. Six Sigma accomplishes this first by identifying the voice of the voice of the customer (VOC). The VOC is then converted to key customer issues, which are in turn converted to critical customer requirements (CCR) or specific measurable targets. The Customer Training Six Sigma team captured the VOC by reviewing feedback from e-learning course evaluations and sending out surveys simply asking e-learning customers what was important to them. The team then took the customer statements and identified the underlying issues behind them. Those issues were then translated into critical customer requirements. The table below shows some of the critical customer requirements that were uncovered.

Figure 4: Critical Customer Requirements

Figure 4: Critical Customer Requirements

Using this approach to gather customer requirements was key to the success of the project. This disciplined process prevented individual prejudices from skewing the data. The Customer Training team found that many of the factors that team members thought were important to end users were not major contributors to customer satisfaction or dissatisfaction. This finding was important since the process map uncovered that much of the e-learning development time was being spent on issues that the team now knew were not important to the end user. (Critical customer requirements are overall requirements for the e-learning programs, not a specific needs analysis or task analysis to identify what the content of a specific e-learning course program should be).

Critical to the Process Issues

The team now knew what customers wanted. The next imperative was to clearly identify business requirements or critical to process issues. The broad, cross functional make-up of the Six Sigma team allowed it to quickly identify the Customer Training e-learning business requirements. These requirements were 1) e-learning development time be within 10 percent of the industry standard, 2) that rework be less than 10 percent of the overall e-learning development time and 3) that all e-learning deliverables be completed at or below the budgeted cost.

Critical to Quality

The critical customer requirements and the critical to process requirements were then consolidated into a single list that identified all of the measurable criteria that needed to be met in order for the e-learning deliverables to be considered at Six Sigma quality. Six Sigma calls this consolidated list the critical to quality (CTQ).

Figure 5: Identifying CTQs

Figure 5: Identifying CTQs

With the CTQs now identified the next step for the team was to move into the next phase of the DMAIC model and measure how the customer training department was doing against those requirements.

How Are We Doing? – The Measure Phase

To ensure the credibility of the data that would be collected, the team now needed to develop a data collection plan. This plan would dictate what data would be collected, where it would be collected from, how it would be collected, who would collect it, when it would be collected, and most importantly operational definitions or clear understandable descriptions of what was to be observed and measured. Once the plan was completed the measurement began. Below is a sample data collection plan.

Table 1: Example of Data Collection Plan
Performance Measures Operational Definition Data Source and Location Sample Size Who Will Collect the Data When Will Data Be Collected How Will Data Be Collected Other Data That Should be Collected at the Same Time
Course is developed within 10% of industry standard hours One hour e-learning developed in no more than 220 hoursThree-hour workshop developed in no more than 132 hours Project plans 17 (100%) of courses with data Kailym Islam 6/6-6/24 Development hours will be identified from project plan data Less than 10% of development time is associated with rework
Less than 10% of development time is associated with rework No more than 20 rework hours for one hour e-learningNo more than 12 hours rework for a three-hour workshop Project plans 17 (100%) of courses with data Kailym Islam 6/6-6/24 Rework data will be identified from project plan N/A

Once the data collection was complete, the results were put into pareto charts, run charts, and histograms which gave the team a visual representation of the state of e-learning. This representation had both good and bad news. The graphical depiction of how end users felt about the e-learning deliverables was the good news. The data showed that customers were fairly pleased with what they were receiving. This picture was quite different than what was expected by many team members who initially felt that there were quality issues with e-learning deliverables.

Figure 6: Ease of Navigation

Figure 6: Ease of Navigation

Figure 7: Realistic Exercises

Figure 7: Realistic Exercises

The data also showed however that there was tremendous opportunity for improvement around business requirements or critical to process issues. The build time of half of the e-learning developed was more than 10 percent above the industry standard.

Figure 8: Process Capability Analysis for Total Hours of E-learning Development

Figure 8: Process Capability Analysis for Total Hours of E-learning Development

Seventy-four percent of the e-learning developed – which represents more than 25 percent of the total development time – was rework.

Figure 9: Rework

Figure 9: Rework

The team now had a baseline measure of how the process was performing against both customer as well as business requirements. It had also identified improvement opportunities. With this information now validated, the team then updated the project goals to: “reduce the annual costs of rework in developing e-learning by 75 percent of the opportunity, and to reduce the remaining development time (above the industry standard) by 50 percent of opportunity.” The team then moved into the Analyze phase which would allow them to pinpoint and verify exactly what was wrong with the process.

What’s Wrong? – The Analyze Phase

One of the first tools used during the Analyze phase was a process capability analysis. The team wanted to see if the current process even had the capability of meeting the CTQ requirements. A process capability was done to measure the ability of the process to meet both total development time requirements as well as percent rework requirements.

Figure 10: Total Time Requirements

Figure 10: Total Time Requirements

The process capability analysis for total development time showed that the current process did not have the ability to meet the critical requirement of being within ten percent of the industry standard or about 220 hours of development time per hour of e-learning. Even increasing the upper specification limit to 250 hours would have the process failing to meet the requirements 56 percent of the time. Although the mean or average development time was 272 hours, the standard deviation was 136 hours, which verified the amount of variability in the process.

Figure 11: Further Rework Analysis

Figure 11: Further Rework Analysis

The process capability analysis for rework showed similar results. The existing development process did not have the ability to meet the critical requirement of limiting rework to ten percent of overall development time. Increasing the upper specification limit to 25 percent would have the process failing to meet the requirements 74 percent of the time. Although the mean or average amount of rework was 37 percent, the standard deviation was 18 percent, which again verified the amount of variability in the process.

Figure 12: Further Rework Analysis, Part 2

Figure 12: Further Rework Analysis, Part 2

A more concerning discovery that was uncovered during the analyze phase was that while the Customer Training department was spending upwards of 360 hours to design and develop e-learning programs in house, it was spending in the area of 400 hours reviewing and approving e-learning that were being developed by vendors. Translated into dollars, a one hour e-learning course was costing the product manager $14,000 more than if it were developed in the 200 hour ASTD standard (about $31,000) in-house. Paying a vendor to develop a one hour e-learning course was costing product management $71,000. ($71,000 was the cost of the vendor plus the cost of 400 hours spent by customer training personnel to review and approve material.)

With all of this baseline data now available the team became extremely energized and anxious to move into the improve phase and generate solutions for the problems. There was still more analysis to be done in the Analyze phase, however.

Root Cause Analysis

Although Six Sigma relies heavily on qualitative data and statistical analysis, it has tools that take into account the feelings, hunches and experiences of team members and subject matter experts. The team next embarked on identifying the root causes of the rework and additional development time. Much of the information about these causes was based on the experiences and recollections of various team members. A series of tools was used to convert this anecdotal data into statistical data and then to validate the data. First a cause and effect or fishbone diagram was developed. This diagram allowed the team to explore and graphically display all of the possible causes of both rework and development time. It also enabled the team to focus on the content of the problem and not on the history of the problem or the differing personal interests of the team members. In short, it forced the team to focus on causes and not symptoms.

Figure 13: Fishbone Diagram

Figure 13: Fishbone Diagram

Once all potential root causes of both rework and additional development time were identified, the team then used multi-voting to derive a prioritized list of the root causes and their impact on e-learning development. The results of this prioritization were displayed in a pareto chart.

Figure 14: Root Causes with Major Impact on Project Goals

Figure 14: Root Causes with Major Impact on Project Goals

The team then validated its root cause findings by sending out surveys to the designers who worked on the e-learning programs. The results of the survey verified the root cause analysis. Next a regression analysis was done on the historical data that was available. This analysis showed a correlation between the number of resources involved in the design of e-learning and the amount of rework. As the number of people doing e-learning design increased so did the amount of rework and the percentage of rework. This was quite eye opening since much of the thinking about e-learning development recommends getting many people involved with the design of e-learning. The data that the team collected clearly indicated the financial ramifications of that type of model.

Figure 15: Total E-learning Rework by Design Resources

Figure 15: Total E-learning Rework by Design Resources

The regression analysis also showed that the more resources there were on a project, the more overall hours, the more rework and the higher the cost. The strongest correlation however was the amount of resources in the design phase with the rework occurring during e-learning development. Putting the data through multi-vari charts and pareto charts verified the results of the regression analysis.

Figure 16: Mean Percentage of Rework to Overall Process by Phase

Figure 16: Mean Percentage of Rework to Overall Process by Phase

Figure 17: Multi-vari Chart for Total Hours by Total Resources for E-learning

Figure 17: Multi-vari Chart for Total Hours by Total Resources for E-learning

At this point in the process many team members were concerned about the amount of analysis that was being performed. The team was confident, however, that as a result of the data any changes that would be made could be validated and justified.

With the root causes identified and verified and the data validated, the team was ready to move into the improve phase where it would generate solutions for the validated causes of rework and additional development time.

What Do We Need To Do? – The Improve Phase

Up until this point, the team was focused on gaining greater levels of understanding of the deficiencies affecting the current e-learning development process. This focus gave the team an understanding and validation of the root causes of the deficiencies. The goal of the improve stage is to find and implement solutions that will eliminate those causes. To accomplish this, the team identified, evaluated, selected and developed solutions using a variety of traditional and non-traditional idea generation tools.

The team generated solutions using a variety of tools including traditional brainstorming, affinity diagrams and a tool called random word that allows teams to approach problems from different perspectives as opposed to patterned ways of thinking. The team also employed Edward De Bono’s six thinking hats technique.

Once the ideas were generated the team then evaluated the solutions and selected the ones that would have the greatest impact on the goals of the project. To accomplish this, the team developed a cause and effect matrix. This tool allowed the team to:

  1. Remove any solutions that were show stoppers,
  2. Consider the organizational fit of each solution,
  3. Narrow the list down,
  4. Develop a solution selection matrix,
  5. Weight the evaluation criteria,
  6. Determine the impact the solution would have on the project’s goals,
  7. Evaluate the time benefit of the solution, and
  8. Evaluate the cost impact of the solutions and finally evaluate other impacts.

With the solutions selected, the team then did a FMEA on the solutions. The FMEA validated that controls to make the solutions successful were in place. These controls also became indicators that would allow the team to identify problems and make adjustments long before the rework or additional development time occurred.

Updating the Process

The next step for the team was to take the solutions and use them to update the process as it currently existed. The original 19-page process map was so inundated with decision points, reviews and approvals, that the team agreed to develop a new process map, using the solutions that had been generated, as well as what was now known about the process as a guide. The new process map was developed in less than two hours, and required only six pages. It highlighted not only each task in the process, but who was responsible, accountable, who needed to be informed and who had to review or sign-off on the step. It also showed the controls that were in place to insure that tasks were done right the first time.

The analysis of the solutions projected that there would be an 81 percent decrease in rework, as well as an 81 percent decrease in the development time that was above the ASTD benchmark. Overall development time was also projected to be reduced by 30 percent. These improvements would translate into an annual savings of $282,000.

The Results

The team now had statistical projections indicating the benefit that should be realized based on the Six Sigma solutions. The only way to truly verify that the new process would produce the projected results would be to put it into practice. The new process was applied to three e-learning projects with the following results.

Table 2: Results of Six Sigma Applied to Three E-learning Projects
Project Course Hours Development Time (Hours) ASTD Development Time (Hours) Development Time/Hour ASTD Time/Hour Percentage Rework
1 1.5 203 300 135 200 8
2 2.0 220 400 110 200 8
3 2.5 350 500 140 200 12

As the table above clearly shows, using the process developed with Six Sigma methodology allowed the Customer Training department to develop e-learning programs in significantly less time than the industry average – while meeting all of the CTQs of the business and customers.

A comparison of critical to process issues before and after the Six Sigma improvements were implemented shows the dramatic improvements even more clearly.

Figure 18: Before and After Six Sigma Improvements

Figure 18: Before and After Six Sigma Improvements

Finally, a process capability analysis on the new process shows that it now had the ability to meet the development time requirements 84 percent of the time. And that the standard deviation was now 18 hours as opposed to the 145 hours prior to applying Six Sigma methodology.

Figure 19: Process Capability Analysis for Hours of Development per Hour of E-learning with Six Sigma Improvements

Figure 19: Process Capability Analysis for Hours of Development per Hour of E-learning with Six Sigma Improvements

How Do We Guarantee Performance – The Control Phase

The team had validated the improvements, and documented that they worked. The team also verified that the new development process was stable and capable of meeting the CTQs. The last phase of a DMAIC Six Sigma project is the Control phase, where the performance of the process is routinely measured to ensure that critical customer requirements continue to be met.

The root cause analysis that was performed during the project identified for the team which key outputs needed to be measured. The failure mode and effects analysis (FMEA) uncovered the action to be taken in the event that a measured output was outside of its control limit. A tracking log was set up to measure these outputs, and the results of this log are reported to executive management every six months.

A Final Thought

Developing e-learning the Six Sigma way has allowed DTCC’s Customer Training department to both identify and exceed critical customer and business requirements for e-learning, reduce overall development time by close to 50 percent, reduce annual development costs by $282,000 and articulate e-learning in a way that business managers understand. Perhaps just as important as the savings and the identification of customer and business requirements is the ability that the Customer Training department now has to maintain this high level of performance.

Developing E-Learning the Six Sigma Way

Your e-learning development program may well be in trouble, and applying the Six Sigma methodology might be the solution. In this real-world Six Sigma – play-by-play – case study about e-learning development, you will learn from the Black Belt what tools were used throughout the DMAIC (Define, Measure, Analyze, Improve, Control) phases of a project to reduce development time by 50 percent and save almost $300,000 per year.

  • What is the true cost of your e-learning development?
  • If a vendor develops your e-learning, what additional costs are you incurring as a result of time spent reviewing and approving the products that the vendor develops?
  • What are the critical requirements of your e-learning customers?
  • Are you meeting those requirements?
  • What are the critical business imperatives that need to be addressed with the e-learning that you currently deliver?
  • Are you meeting those imperatives?
  • In articulating your e-learning vision, are you speaking a language that any business manager can understand?

If the answer to any of these questions is either “no” or “I don’t know,” your e-learning program may well be in trouble, and applying Six Sigma methodologies might be the solution to many of the problems that you are facing. Below is a case study detailing how the Customer Training department of The Depository Trust & Clearing Corporation (DTCC) applied Six Sigma methodologies to its e-learning development and, as a result, validated and exceeded critical customer and business requirements for e-learning:

  • Reduced e-learning development rework by 81 percent
  • Reduced the annual cost of developing e-learning by 30 percent, and
  • Saved the company $282,000.

Case Study Background – The Business Case

The Depository Trust & Clearing Corporation is the largest financial services post-trade infrastructure in the world, with operating facilities in multiple locations in the U.S. and overseas. With the company’s growth, it was becoming more difficult for the Customer Training department to satisfy the increasing volume of customer training requests. A growing product line presented challenges in finding instructors who were certified on each of the products, and the need to rapidly deploy updated information was becoming more and more crucial. The leadership of the Customer Training department was convinced that e-learning would allow the company to satisfy its customer training requests, reduce the cost of training and address the issue of trainer certification. Senior management was sold on the idea, an e-learning strategy was developed and DTCC became one of the financial service industry’s early adopters of e-learning.

Like many other training organizations, the Customer Training department spent significant money and resources researching and purchasing a learning management system (LMS), procuring a variety of authoring software packages and training personnel to use the new software. Monies were allocated to teach training professionals how to develop and deliver e-learning. A benchmarking study was undertaken in order to ensure that the e-learning was “done right,” a goal to convert all of the core instructor led courses into self paced electronic courses was set, a budget was established, a vendor was commissioned to assist with the project and the e-learning journey began.

Two years into the program concerns arose. Only two (of the six core) instructor-led courses had been converted for self-paced delivery. Two still uncompleted courses had been in development for close to a year. The consulting budget that was set aside to convert the core courses was totally spent. The staff of the customer training department openly expressed frustration about 1) the amount of time and rework associated with developing e-learning programs, 2) the cost of e-learning development and 3) the quality of the e-learning that was being developed.

In order to address these issues, additional funds were invested to implement project management methodologies, certify staff as project management professionals, and to improve the skills of the department’s instructional designers. After some initial optimism with these measures, the frustration returned.

The leadership of Customer Training, which was still committed to fixing the e-learning “problems,” volunteered to participate in the company’s second round of Six Sigma projects. An initial project charter was developed. A cross-functional team was assembled and the Six Sigma DMAIC project began.

The Organizational Structure

To fully appreciate the challenges that the Customer Training Six Sigma team faced, it is important to have an understanding of the structure of the organization (as it pertained to e-learning). The customer training department is responsible for delivering training services to participants or customers of DTCC. These customers are financial industry firms. The end users of this training are the employees of these firms. Training requests came to Customer Training in one of three ways:

  1. The member firm or participant would contact their relationship manager at DTCC with a training request. The relationship manager would in turn contact the customer-training department.
  2. Product management would identify a training need and then request that the customer training department develop a program.
  3. The customer training department would examine trend analysis information from service desk calls and develop training based on that data.

In all three cases, however, the development costs of the e-learning was charged to the budget of the appropriate product manager who ultimately had the authority to make decisions on content, look and feel, as well as instructional strategies.

The Customer Training department itself was comprised of four groups: an Information Product group responsible for all customer documentation, a Training group responsible for delivery of all instructor led programs, a Project Management group that was responsible for delivering all customer training projects on time and within budget, and an Instructional Technologies group responsible for e-learning development, instructional design and learning management system administration. A typical e-learning deliverable would require review, approval and sign off by each of these groups, as well as approval by Product Management.

What’s Important – The Define Phase

The Six Sigma team started the project with some advantages. The Customer Training department’s previous experience with project management provided some initial data with which to start. Many Six Sigma projects start with no analytical data whatsoever. At the project kickoff the draft charter was distributed to team members, and the work began refining it and filling in the missing pieces. The initial data seemed to indicate that there was tremendous opportunity to reduce rework, development time, and development cost. Rework accounted for up to 60 percent of the total development time. The development time was as much as 75 percent above the ASTD benchmark of about 200 hours of development time per hour of e-learning, and the development costs were impacted by both rework and development time.

As the team worked to perfect the charter, discussions arose around what the industry standard for e-learning consisted of, and which benchmark to use. It was finally agreed that the ASTD would be the benchmark. The next point of discussion centered on the project’s scope. After much debate the team finally agreed that the scope of the project would be from the time a training need was identified until the e-learning deliverable was approved by product management. The team then agreed on a preliminary project plan with an activity schedule and some initial milestones.

Process Mapping

With the charter approved, the team focused its work on documenting and analyzing the e-learning development process as it currently existed. This was accomplished by developing a variety of maps and charts to give a graphical representation of what was really taking place in the e-learning development process. The first map that the team developed was a supplier, inputs, process, and output, customer (SIPOC) diagram. This diagram, with its few details allowed the team to get a high level picture of what the major development steps were. As the team went through the exercise of developing this map, it became clear that the Customer Training department was developing e-learning without any direct input from the end user of the product.

Figure 1: CTIP Process

Figure 1: CTIP Process

The next graphical depiction that the team developed was a top-down chart. This map created a simple picture of the e-learning development process identifying two levels of detail. The first level showed the major steps in the process, with the second level showing the sub processes under each step. This chart gave a little more detail about the existing process even though it did not show delays, decision points and feedback loops.

Figure 2: Customer Training Development Process

Figure 2: Customer Training Development Process

The most difficult and time consuming graphical depiction of the e-learning process was the functional deployment process map. The team began developing this map with the expectation that it would be a fairly easy process since the team had access to project plans, historical data and subject matter experts to document what was believed to be occurring in the e-learning development process. As the work to develop the map began, it became quite obvious that what was written on paper and in project plans was not what was actually taking place. This exercise made it clear that not only was there tremendous variation in the e-learning development process, but the people who were involved in e-learning development were not quite sure of what tasks should be completed, who was responsible for completing them, and when they should take place.

The functional deployment map took almost four meetings (eight hours) to complete. It required 19 two-and-one-half by two-foot easel pads and encompassed all the walls of a medium sized conference room. This detailed map displayed all of the steps in the e-learning development process in sequential order. It illustrated where each step was performed, and who was involved. The map clearly displayed that the process contained a series of checks and rechecks that virtually guaranteed rework.

Qualitative Analysis

With the cross-functional process map complete, the team then performed a qualitative analysis of the process. The members looked at every step in the e-learning development process and classified each task as customer value added, operational value, not customer value added, or not operational value added. (Customer value added being defined as an activity that: the customer recognizes as valuable, changes the product toward something that the customer expects, or is done right the first time. Operational value added activities are activities that are required by contract or other laws and regulations, done right the first time, or required to sustain the workplace ability to perform customer value added activities).

The team found that there were a significant number of non-value added activities (NVA) in the e-learning development process. Many of these NVAs were the reviews and approvals required by the various groups within the Customer Training department and Product Management. Some of these reviews and approvals were required regardless of whether the reviewer or approving authority was a stakeholder in the deliverable. Removing these activities could potentially reduce the time and cost associated with e-learning development. Many of the steps that are accepted as best practices in the training industry were also identified as non-value added activities when Six Sigma methodology was applied.

Quick Wins

The NVA activities were then all categorized based on whether they were easy to implement, fast to implement, cheap to implement, within the team’s control and easily reversible. The NVAs that met all of these conditions were identified as quick wins.

Figure 3: Non-value-added Activities

Figure 3: Non-value-added Activities

The team then did a failure mode and effects analysis (FMEA) on each of the activities. A FMEA is a process that is used to determine what failures are occurring and what their impact and frequencies are. The FMEA validated that removing a step would ultimately do the process more good then harm, and also ensured that the proper controls were in place so that removing the step would not cause the process to fail. With the FMEA complete, the team agreed to implement ten quick wins. These quick wins basically removed redundant meetings and multiple levels of reviews and approvals from the process.

Voice of the Customer

With the quick wins identified the team began to work on defining customer requirements. Six Sigma accomplishes this first by identifying the voice of the voice of the customer (VOC). The VOC is then converted to key customer issues, which are in turn converted to critical customer requirements (CCR) or specific measurable targets. The Customer Training Six Sigma team captured the VOC by reviewing feedback from e-learning course evaluations and sending out surveys simply asking e-learning customers what was important to them. The team then took the customer statements and identified the underlying issues behind them. Those issues were then translated into critical customer requirements. The table below shows some of the critical customer requirements that were uncovered.

Figure 4: Critical Customer Requirements

Figure 4: Critical Customer Requirements

Using this approach to gather customer requirements was key to the success of the project. This disciplined process prevented individual prejudices from skewing the data. The Customer Training team found that many of the factors that team members thought were important to end users were not major contributors to customer satisfaction or dissatisfaction. This finding was important since the process map uncovered that much of the e-learning development time was being spent on issues that the team now knew were not important to the end user. (Critical customer requirements are overall requirements for the e-learning programs, not a specific needs analysis or task analysis to identify what the content of a specific e-learning course program should be).

Critical to the Process Issues

The team now knew what customers wanted. The next imperative was to clearly identify business requirements or critical to process issues. The broad, cross functional make-up of the Six Sigma team allowed it to quickly identify the Customer Training e-learning business requirements. These requirements were 1) e-learning development time be within 10 percent of the industry standard, 2) that rework be less than 10 percent of the overall e-learning development time and 3) that all e-learning deliverables be completed at or below the budgeted cost.

Critical to Quality

The critical customer requirements and the critical to process requirements were then consolidated into a single list that identified all of the measurable criteria that needed to be met in order for the e-learning deliverables to be considered at Six Sigma quality. Six Sigma calls this consolidated list the critical to quality (CTQ).

Figure 5: Identifying CTQs

Figure 5: Identifying CTQs

With the CTQs now identified the next step for the team was to move into the next phase of the DMAIC model and measure how the customer training department was doing against those requirements.

How Are We Doing? – The Measure Phase

To ensure the credibility of the data that would be collected, the team now needed to develop a data collection plan. This plan would dictate what data would be collected, where it would be collected from, how it would be collected, who would collect it, when it would be collected, and most importantly operational definitions or clear understandable descriptions of what was to be observed and measured. Once the plan was completed the measurement began. Below is a sample data collection plan.

Table 1: Example of Data Collection Plan
Performance Measures Operational Definition Data Source and Location Sample Size Who Will Collect the Data When Will Data Be Collected How Will Data Be Collected Other Data That Should be Collected at the Same Time
Course is developed within 10% of industry standard hours One hour e-learning developed in no more than 220 hoursThree-hour workshop developed in no more than 132 hours Project plans 17 (100%) of courses with data Kailym Islam 6/6-6/24 Development hours will be identified from project plan data Less than 10% of development time is associated with rework
Less than 10% of development time is associated with rework No more than 20 rework hours for one hour e-learningNo more than 12 hours rework for a three-hour workshop Project plans 17 (100%) of courses with data Kailym Islam 6/6-6/24 Rework data will be identified from project plan N/A

Once the data collection was complete, the results were put into pareto charts, run charts, and histograms which gave the team a visual representation of the state of e-learning. This representation had both good and bad news. The graphical depiction of how end users felt about the e-learning deliverables was the good news. The data showed that customers were fairly pleased with what they were receiving. This picture was quite different than what was expected by many team members who initially felt that there were quality issues with e-learning deliverables.

Figure 6: Ease of Navigation

Figure 6: Ease of Navigation

Figure 7: Realistic Exercises

Figure 7: Realistic Exercises

The data also showed however that there was tremendous opportunity for improvement around business requirements or critical to process issues. The build time of half of the e-learning developed was more than 10 percent above the industry standard.

Figure 8: Process Capability Analysis for Total Hours of E-learning Development

Figure 8: Process Capability Analysis for Total Hours of E-learning Development

Seventy-four percent of the e-learning developed – which represents more than 25 percent of the total development time – was rework.

Figure 9: Rework

Figure 9: Rework

The team now had a baseline measure of how the process was performing against both customer as well as business requirements. It had also identified improvement opportunities. With this information now validated, the team then updated the project goals to: “reduce the annual costs of rework in developing e-learning by 75 percent of the opportunity, and to reduce the remaining development time (above the industry standard) by 50 percent of opportunity.” The team then moved into the Analyze phase which would allow them to pinpoint and verify exactly what was wrong with the process.

What’s Wrong? – The Analyze Phase

One of the first tools used during the Analyze phase was a process capability analysis. The team wanted to see if the current process even had the capability of meeting the CTQ requirements. A process capability was done to measure the ability of the process to meet both total development time requirements as well as percent rework requirements.

Figure 10: Total Time Requirements

Figure 10: Total Time Requirements

The process capability analysis for total development time showed that the current process did not have the ability to meet the critical requirement of being within ten percent of the industry standard or about 220 hours of development time per hour of e-learning. Even increasing the upper specification limit to 250 hours would have the process failing to meet the requirements 56 percent of the time. Although the mean or average development time was 272 hours, the standard deviation was 136 hours, which verified the amount of variability in the process.

Figure 11: Further Rework Analysis

Figure 11: Further Rework Analysis

The process capability analysis for rework showed similar results. The existing development process did not have the ability to meet the critical requirement of limiting rework to ten percent of overall development time. Increasing the upper specification limit to 25 percent would have the process failing to meet the requirements 74 percent of the time. Although the mean or average amount of rework was 37 percent, the standard deviation was 18 percent, which again verified the amount of variability in the process.

Figure 12: Further Rework Analysis, Part 2

Figure 12: Further Rework Analysis, Part 2

A more concerning discovery that was uncovered during the analyze phase was that while the Customer Training department was spending upwards of 360 hours to design and develop e-learning programs in house, it was spending in the area of 400 hours reviewing and approving e-learning that were being developed by vendors. Translated into dollars, a one hour e-learning course was costing the product manager $14,000 more than if it were developed in the 200 hour ASTD standard (about $31,000) in-house. Paying a vendor to develop a one hour e-learning course was costing product management $71,000. ($71,000 was the cost of the vendor plus the cost of 400 hours spent by customer training personnel to review and approve material.)

With all of this baseline data now available the team became extremely energized and anxious to move into the improve phase and generate solutions for the problems. There was still more analysis to be done in the Analyze phase, however.

Root Cause Analysis

Although Six Sigma relies heavily on qualitative data and statistical analysis, it has tools that take into account the feelings, hunches and experiences of team members and subject matter experts. The team next embarked on identifying the root causes of the rework and additional development time. Much of the information about these causes was based on the experiences and recollections of various team members. A series of tools was used to convert this anecdotal data into statistical data and then to validate the data. First a cause and effect or fishbone diagram was developed. This diagram allowed the team to explore and graphically display all of the possible causes of both rework and development time. It also enabled the team to focus on the content of the problem and not on the history of the problem or the differing personal interests of the team members. In short, it forced the team to focus on causes and not symptoms.

Figure 13: Fishbone Diagram

Figure 13: Fishbone Diagram

Once all potential root causes of both rework and additional development time were identified, the team then used multi-voting to derive a prioritized list of the root causes and their impact on e-learning development. The results of this prioritization were displayed in a pareto chart.

Figure 14: Root Causes with Major Impact on Project Goals

Figure 14: Root Causes with Major Impact on Project Goals

The team then validated its root cause findings by sending out surveys to the designers who worked on the e-learning programs. The results of the survey verified the root cause analysis. Next a regression analysis was done on the historical data that was available. This analysis showed a correlation between the number of resources involved in the design of e-learning and the amount of rework. As the number of people doing e-learning design increased so did the amount of rework and the percentage of rework. This was quite eye opening since much of the thinking about e-learning development recommends getting many people involved with the design of e-learning. The data that the team collected clearly indicated the financial ramifications of that type of model.

Figure 15: Total E-learning Rework by Design Resources

Figure 15: Total E-learning Rework by Design Resources

The regression analysis also showed that the more resources there were on a project, the more overall hours, the more rework and the higher the cost. The strongest correlation however was the amount of resources in the design phase with the rework occurring during e-learning development. Putting the data through multi-vari charts and pareto charts verified the results of the regression analysis.

Figure 16: Mean Percentage of Rework to Overall Process by Phase

Figure 16: Mean Percentage of Rework to Overall Process by Phase

Figure 17: Multi-vari Chart for Total Hours by Total Resources for E-learning

Figure 17: Multi-vari Chart for Total Hours by Total Resources for E-learning

At this point in the process many team members were concerned about the amount of analysis that was being performed. The team was confident, however, that as a result of the data any changes that would be made could be validated and justified.

With the root causes identified and verified and the data validated, the team was ready to move into the improve phase where it would generate solutions for the validated causes of rework and additional development time.

What Do We Need To Do? – The Improve Phase

Up until this point, the team was focused on gaining greater levels of understanding of the deficiencies affecting the current e-learning development process. This focus gave the team an understanding and validation of the root causes of the deficiencies. The goal of the improve stage is to find and implement solutions that will eliminate those causes. To accomplish this, the team identified, evaluated, selected and developed solutions using a variety of traditional and non-traditional idea generation tools.

The team generated solutions using a variety of tools including traditional brainstorming, affinity diagrams and a tool called random word that allows teams to approach problems from different perspectives as opposed to patterned ways of thinking. The team also employed Edward De Bono’s six thinking hats technique.

Once the ideas were generated the team then evaluated the solutions and selected the ones that would have the greatest impact on the goals of the project. To accomplish this, the team developed a cause and effect matrix. This tool allowed the team to:

  1. Remove any solutions that were show stoppers,
  2. Consider the organizational fit of each solution,
  3. Narrow the list down,
  4. Develop a solution selection matrix,
  5. Weight the evaluation criteria,
  6. Determine the impact the solution would have on the project’s goals,
  7. Evaluate the time benefit of the solution, and
  8. Evaluate the cost impact of the solutions and finally evaluate other impacts.

With the solutions selected, the team then did a FMEA on the solutions. The FMEA validated that controls to make the solutions successful were in place. These controls also became indicators that would allow the team to identify problems and make adjustments long before the rework or additional development time occurred.

Updating the Process

The next step for the team was to take the solutions and use them to update the process as it currently existed. The original 19-page process map was so inundated with decision points, reviews and approvals, that the team agreed to develop a new process map, using the solutions that had been generated, as well as what was now known about the process as a guide. The new process map was developed in less than two hours, and required only six pages. It highlighted not only each task in the process, but who was responsible, accountable, who needed to be informed and who had to review or sign-off on the step. It also showed the controls that were in place to insure that tasks were done right the first time.

The analysis of the solutions projected that there would be an 81 percent decrease in rework, as well as an 81 percent decrease in the development time that was above the ASTD benchmark. Overall development time was also projected to be reduced by 30 percent. These improvements would translate into an annual savings of $282,000.

The Results

The team now had statistical projections indicating the benefit that should be realized based on the Six Sigma solutions. The only way to truly verify that the new process would produce the projected results would be to put it into practice. The new process was applied to three e-learning projects with the following results.

Table 2: Results of Six Sigma Applied to Three E-learning Projects
Project Course Hours Development Time (Hours) ASTD Development Time (Hours) Development Time/Hour ASTD Time/Hour Percentage Rework
1 1.5 203 300 135 200 8
2 2.0 220 400 110 200 8
3 2.5 350 500 140 200 12

As the table above clearly shows, using the process developed with Six Sigma methodology allowed the Customer Training department to develop e-learning programs in significantly less time than the industry average – while meeting all of the CTQs of the business and customers.

A comparison of critical to process issues before and after the Six Sigma improvements were implemented shows the dramatic improvements even more clearly.

Figure 18: Before and After Six Sigma Improvements

Figure 18: Before and After Six Sigma Improvements

Finally, a process capability analysis on the new process shows that it now had the ability to meet the development time requirements 84 percent of the time. And that the standard deviation was now 18 hours as opposed to the 145 hours prior to applying Six Sigma methodology.

Figure 19: Process Capability Analysis for Hours of Development per Hour of E-learning with Six Sigma Improvements

Figure 19: Process Capability Analysis for Hours of Development per Hour of E-learning with Six Sigma Improvements

How Do We Guarantee Performance – The Control Phase

The team had validated the improvements, and documented that they worked. The team also verified that the new development process was stable and capable of meeting the CTQs. The last phase of a DMAIC Six Sigma project is the Control phase, where the performance of the process is routinely measured to ensure that critical customer requirements continue to be met.

The root cause analysis that was performed during the project identified for the team which key outputs needed to be measured. The failure mode and effects analysis (FMEA) uncovered the action to be taken in the event that a measured output was outside of its control limit. A tracking log was set up to measure these outputs, and the results of this log are reported to executive management every six months.

A Final Thought

Developing e-learning the Six Sigma way has allowed DTCC’s Customer Training department to both identify and exceed critical customer and business requirements for e-learning, reduce overall development time by close to 50 percent, reduce annual development costs by $282,000 and articulate e-learning in a way that business managers understand. Perhaps just as important as the savings and the identification of customer and business requirements is the ability that the Customer Training department now has to maintain this high level of performance.

What is Professional Certification?

Six Sigma are words on everybody’s lips in the business sector. It can eliminate waste, seek out defects that halt progress, improve process efficiency, and turn a company around. But what training does it entail? This is an important question to consider when pursuing Six Sigma training. Also are: What is professional certification in Six Sigma? Does it just come down to a certificate and skillset? Today, we will answer these questions by looking at professional certification in all its forms.

What is Professional Certification?

Professional certification is proof of achievement awarded to someone for completing a training program that qualifies them to perform a particular job. Like any qualification, professional certification involves extensive study and acquirement of knowledge. This is systematically tested and developed until all training requisites are met. This then entitles the person involved to a certificate that illustrates their achievement and acknowledges their newfound skills and/or knowledge.

What is Six Sigma Certification?

In Six Sigma, certification represents an acknowledgment and confirmation of a person’s skills within Six Sigma. It demonstrates the understanding of Six Sigma, as well as Lean principles, and completed assessments to hone their abilities. Once you have a Six Sigma certification, you are qualified to practice in the workplace, as one of the following:

  • Master Black Belt
  • Champion
  • Black Belt
  • Green Belt
  • Yellow Belt

Many employers seek out Six Sigma training for their staff to have dedicated practitioners on their team. This is usually only a small group, if not a single person, as certification is often very costly, although it is a wise investment for any company.

The Specifics of Six Sigma Certification  

Like any qualification, Six Sigma certification involves passing a written proficiency test and displaying significant knowledge of Six Sigma method. Likewise, this is done both in theory and in practice. Your employer will expect signs of competency in the workplace, as Six Sigma demands dedication and a proactive attitude. The training company or the company that has hired them will administer the written test. In-house training is a common feature in many large companies, as they will want to tailor staff to the specific needs of their company.

Once basic training is complete, individuals will work a series of successful, quality Six Sigma projects to demonstrate their skills. These are by no means practice projects, but are this early work will help practitioners learn to hone their skills. The number of projects required will vary for each belt classification. For example, Green Belts will typically only need to complete a single project, while Black Belts and Master Black Belts will complete two or more. This is due to the differing responsibilities involved, and the more intensive training for Black Belts reflects the demands of the role.

Furthermore, having the right attitude is essential and will set you apart from your peers and maximize your success. Six Sigma is as much about the individual as it is about the whole group, which is why marking yourself as an exemplary practitioner will benefit you both in training and in practice.

Use “Light” Lean Six Sigma When the Textbook Approach Is Not Possible

Practitioners cannot wait to use their newly acquired knowledge after they have finished Lean Six Sigma (LSS) training. They want to immediately apply the framework to their real-life projects. But what if, for numerous reasons, it is not possible to “go by the book”? In such cases, there are ways to break LSS down into pieces and make it accessible to everyone. Using the “light” approach may be the only option available; however, if used properly, the light approach can be the best approach.

When Does a Project Seem Undoable?

Depending on the environment, organization’s maturity, people and processes that must be dealt with, LSS practitioners may be in situations that prevent them from following a textbook project. These situations may include:

  • Lack of continuous improvement culture and awareness in the organization
  • Application of other methodologies which do not focus on improvement
  • Limited possibility to measure performance at no/little additional cost
  • Lack of sponsorship and senior management support for the project

Assuming one or more of the above elements are true, running a project can be a challenge. Not only can everything one has learned be viewed as a waste of potential and time, but a project may also be seen as too difficult to attempt. A simple way to turn these challenges into an opportunity is by extracting the maximum from the existing situation instead of fighting against it. A couple of examples demonstrate that using individual tools when they fit the purpose can be as rewarding as applying the whole framework – by the book.

Light LSS Example: Voice of Customer Applied to a Team

Every LSS training or guideline instructs to start a project by analyzing the voice of the customer (VOC). But what if there is no project and the practitioner does not interact with the end-product customer? There is a trick to adjust the VOC tool to help improve the organization.

Treat the SMEs as the customers. Let’s take the simplest scenario where one LSS expert is assigned to a team of SMEs attempting to improve their own processes. The objective here is three-fold:

  • Get the most valuable knowledge and advice from the experts.
  • Demonstrate that simple non-technical solutions can solve their problems.
  • Get the team involved and translate their ideas into improvements.

When it comes to implementing these principles, as with any customer feedback, the key is to establish a structured method for gathering, storing and reviewing the improvement ideas. The following are some tips that can assist in building a simple mechanism to manage a team’s improvement ideas:

  • Establish a repository for gathering the ideas and teach the team how to use it.
  • Define the RACI (responsible, accountable, consulted, informed) for submitting, reviewing and approving improvement ideas.
  • Set up a regular process for reviewing and approving new entries.
  • Enable a team to implement their own ideas (e.g., by freeing up 10 percent of their time).

With numerous “customers,” this process is more complicated; however, given team discipline and collaboration it can turn into success. The end goal should be for the team to become self-sufficient in improving their processes when the LSS expert is no longer available.

VOC is not the only instrument that teams can use by themselves. Other examples of useful tools that every team can use in everyday work include project management documents that bring structure to every initiative.

Light LSS Example: Project Documentation as the Basis for Every Initiative

Even if LSS is not used in everyday operations, a smart expert can still smuggle a few useful tools into the workplace. This is because every organization runs projects; all projects typically bring change and opportunities for improvement. As these tools are simple and universal, no matter what methodology an organization uses, LSS best practices around project management documentation can often be the first big win. This can apply to any initiative, starting with a local team project and finishing with a global organizational change. Here are some examples of tools that each person running a project should befriend:

  • RACI and governance structure: Any initiative (including team outdoor event) needs people responsible, people to be consulted and informed as well as sponsors. The bigger the project, the more complex the structure, but the basics should always be in place.
  • Project charter: Without specifying the problem, it is difficult to find the right solution. A well-written project charter helps resolve this issue and also serves as the perfect baseline document protecting the project manager against scope creep.
  • Project plan: Any project needs a schedule to keep everyone in check. Tools like MS Project and MS SharePoint are excellent in that respect, but can be considered too complex for small projects. In such cases, there is nothing preventing the team from using simpler tools like a flipchart or spreadsheet.
  • Communication plan: The tool that is often used for big projects can prove quite useful in any situation where multiple stakeholders are involved. And because communication in big organizations can be a challenge, giving it more structure is beneficial for all.

Light LSS Example: 5S in Everyday Operations

What if the LSS expert is assigned to a team that does not run any projects? One might argue that the space for improving their operations is limited. There is a tool, though, that can be applied in any circumstances and implemented by the team independently – 5S (sort, set in order, shine, standardize, sustain) only sounds like one tool, but it is by far one of the most helpful. Apart from the visible improvements 5S offers in each of the five phases of DMAIC (Define, Measure, Analyze, Improve, Control), 5S offers plenty of opportunities to embed the continuous improvement mindset quickly and effectively. (Again, if it is not possible to use all the elements at once, fit-for-purpose is the most sensible approach to follow.) 

In operations like human resources, finance or outsourcing, some 5S techniques can be applied as successfully as in manufacturing. Good analogies for a service environment relate to virtual workplaces. Some examples include setting up document repositories and shared locations, standardizing service inputs or outputs, and keeping the PC workplace tidy.

  • Sort: The simplest task that can help one deal with a large number of documents is to identify the items that are not required and move them into a separate space. Archiving and versioning techniques can be useful here.
  • Set in order: This step establishes a correct place for different types of documents or records. One of the ways to address this step is to use an established naming convention and folder structure that makes the document repository user-friendly.
  • Shine: It is a good habit to apply the “shine” phase in an iterative manner by removing items that are too old, not valid, etc. As in any workplace, operating in a tidy environment results in better outcomes and higher employee satisfaction.
  • Standardize: Activities around standardization can be extremely helpful, especially for more complicated document repositories. If every folder needs to follow a more complex structure, it might be helpful to document the approach in a standard operating procedure or a README file posted in a visible place.
  • Sustain: Last but not least, in order to maintain that perfect state, there are a few practical methods to be used. Some tools include regular reviews with the SMEs, or retrospective sessions with the team. Both allow gathering feedback on whether the document structure is consistent, up-to-date and up to stakeholder expectations. 

Light LSS: Process Mapping and Procedures Used for Process Design

The previous examples demonstrate how to improve an existing process with little effort. But what if the process is not there yet? In such instances, the LSS expert might be asked to design and implement an activity that was not previously performed.

When establishing a new function, going through re-organization or simply starting a new activity, a couple of LSS tools can be utilized to help define and document the change taking place.

  • Supplier, input, process, output, customer (SIPOC): When defining any kind of activity for the first time, identifying inputs and outputs, or pointing at the real customer of the product or service can be a challenge. On the other hand, knowing these and having them documented can help in understanding the critical points of the process and focusing the effort there.
  • Process map: No matter how complex the activity, one picture tells more than several pages of documentation. For any activity that was not defined previously, drawing a process flow with the respective phases, steps and actors can prove invaluable. This approach is the simplest way of spotting bottlenecks or pain points, and being able to address them straight away.
  • Standard operating procedure (SOP): Even though an SOP is known in LSS circles as the file used to document an improved process, SOPs can and should be used for any kind of activity. Combined with the high-level process map, SOPs tell the whole story, help train new staff and make the process output repeatable.

Benefits of Light LSS

When the reality is different from what was taught during training, the choices are to give up or adjust one’s approach. By using a fit-for-purpose approach and simplifying the tools, it is easier to make the tools easier to remember and, therefore, encourage the staff to use them more often. Many small improvements have a big chance of translating into a continuous improvement culture for the whole organization.

Six sigma JOB- Quality Assurance/Quality Control Manager

Job Description

Strong Quantitative and problem solving ability: Ability to conceptualize complex problems and develop an Analytical road map for them.

People Leadership: Ability to coach & mentor people

Demonstrates the ability to facilitate meetings to generate ideas and make key decisions

Creates a team environment of accountability and commitment for reaching project goals

Specific Competence (Desirable) Consulting / ‘Strategic Initiatives’ group / Lean Six Sigma experience Key Roles and Responsibilities:

Lead Quality Projects for the business, individually.

Identifying areas of significant Customer Business Impact and improvement opportunities therein and provide strategic direction & thought leadership

Focus on Process improvement and cost reduction for clients to deliver tangible benefits

Lead and Implement business process management system for new clients

Drive and Track Quality DNA – training, testing & certification, Lead any other analytics and productivity initiatives.

Coaching and Mentoring Process Owners and Team Members in DMAIC and Lean.

Salary: Not Disclosed by Recruiter
Industry: BPO / Call Centre / ITES
Functional Area: ITES, BPO, KPO, LPO, Customer Service, Operations
Role Category: Quality
Role: Quality Assurance/Quality Control Manager
Keyskills: Black Belt, Lean Six Sigma, Dmaic, Process Improvement. Quality Management. Six Sigma, Quality, Business Process Management, Cost Reduction, People Leadership, Problem Solving.

Benefits of Toyota Production System (TPS)

Toyota production system (TPS) is like a super charged Lean Six Sigma program. All the proven and intelligent methodologies of conventional TPS Six Sigma have been charged with immensely motivated team associates.

TPS is the outcome of such powerful Lean Six Sigma team associates sigma, which leads to high performance culture and lets employees to know their full strength. It also bestow creatively, while the firm gains from increased, profitability, market share, productivity and high customer satisfaction.

Toyota Motor Corporation created this Six Sigma system to offer best quality, low priced and shortest lead-time by eliminating wastes. Generally, TPS consists of two pillars such as Just-in-Time and Jidoka. People often illustrate it with the name House. TPS is improved and maintained through loops of consistent work and improved quality.

Elimination of Waste has several forms such as material, idle equipment, time, and inventory. Most organizations do waste about 70% to 90% of their existing resources. Hence, TPS emphasizes the detection of such waste followed by certain Six Sigma tools and systems to eliminate it.

Inventory is one such largest waste. It demolishes capital, become outdated and consumes both space as well as workforce. At times, it also hides other kinds of wastes. Almost each defect or difficulty makes a need of inventory. Thus, inventory is an outcome as well as evidence of overall manufacturing effectiveness.

TPS’s Six Sigma

Below discussed are some of the TPS’s (Toyota production system) Six Sigma strategies:

1. Decreased setup times: All setup procedures are wasteful, since they do not add any value and tie-up labor and equipment. By handling procedures, using carts and training employees to carry out their own setups, Toyota has managed to slash setup times from month to hours, and even minutes.

2. Minimum Production: Manufacturing things in bulk batches sometimes may lead to huge setup costs, capital cost, large inventories, unlimited lead times and huge defect costs. As Toyota has found this ideal method of minimum production to make setup inexpensive and short, now it has become possible for them to manufacture various things in smaller quantities.

3. Workers Empowerment and Involvement: Toyota ordered their employees to form teams and offered them the training and responsibility to carry out certain specialized tasks. Team members were also given the task to repair equipment and take care of internal factory work. Every team has a head, who also acts as one of the prospective employee in achieving specialized task assigned to them.

4. Dealers Participation: Toyota treats its dealers as company partner, as integral part of TPS (Toyota production system). Dealers are also well familiar with ways to decrease setup times, defects, inventories and machine breakdowns and take responsibility to render their best possible outcomes.

Overview

The Toyota Production System blends attitude, notion and specific techniques into a structured socio-technical Six Sigma system for manufacturing. Gradually, this Six Sigma system spread around Japan and finally to the West, and started gaining other names and variations. Toyota itself was not having any name for its manufacturing strategy until the 1970’s.

Just in Time, Stockless Production, World Class Manufacturing, Demand Flow Technology and several other terms are mostly the variations of Toyota’s Six Sigma system. Lean Manufacturing, given by James Womack, is a name that appears to sticking very firmly.

When everything has been well done, TPS fetches order of great improvements in inventory, material handling, scheduling, and customer satisfaction. The payoff to dealers and shareholders is important and well acknowledged.

The TPS’s Six Sigma system has been doing well for Toyota, its dealers, and several other companies. Often, Six Sigma is an ideal starting point, but is hardly a substitute for a personalized and well-throughout manufacturing strategy.

Use “Light” Lean Six Sigma When the Textbook Approach Is Not Possible

Practitioners cannot wait to use their newly acquired knowledge after they have finished Lean Six Sigma (LSS) training. They want to immediately apply the framework to their real-life projects. But what if, for numerous reasons, it is not possible to “go by the book”? In such cases, there are ways to break LSS down into pieces and make it accessible to everyone. Using the “light” approach may be the only option available; however, if used properly, the light approach can be the best approach.

When Does a Project Seem Undoable?

Depending on the environment, organization’s maturity, people and processes that must be dealt with, LSS practitioners may be in situations that prevent them from following a textbook project. These situations may include:

  • Lack of continuous improvement culture and awareness in the organization
  • Application of other methodologies which do not focus on improvement
  • Limited possibility to measure performance at no/little additional cost
  • Lack of sponsorship and senior management support for the project

Assuming one or more of the above elements are true, running a project can be a challenge. Not only can everything one has learned be viewed as a waste of potential and time, but a project may also be seen as too difficult to attempt. A simple way to turn these challenges into an opportunity is by extracting the maximum from the existing situation instead of fighting against it. A couple of examples demonstrate that using individual tools when they fit the purpose can be as rewarding as applying the whole framework – by the book.

Light LSS Example: Voice of Customer Applied to a Team

Every LSS training or guideline instructs to start a project by analyzing the voice of the customer (VOC). But what if there is no project and the practitioner does not interact with the end-product customer? There is a trick to adjust the VOC tool to help improve the organization.

Treat the SMEs as the customers. Let’s take the simplest scenario where one LSS expert is assigned to a team of SMEs attempting to improve their own processes. The objective here is three-fold:

  • Get the most valuable knowledge and advice from the experts.
  • Demonstrate that simple non-technical solutions can solve their problems.
  • Get the team involved and translate their ideas into improvements.

When it comes to implementing these principles, as with any customer feedback, the key is to establish a structured method for gathering, storing and reviewing the improvement ideas. The following are some tips that can assist in building a simple mechanism to manage a team’s improvement ideas:

  • Establish a repository for gathering the ideas and teach the team how to use it.
  • Define the RACI (responsible, accountable, consulted, informed) for submitting, reviewing and approving improvement ideas.
  • Set up a regular process for reviewing and approving new entries.
  • Enable a team to implement their own ideas (e.g., by freeing up 10 percent of their time).

With numerous “customers,” this process is more complicated; however, given team discipline and collaboration it can turn into success. The end goal should be for the team to become self-sufficient in improving their processes when the LSS expert is no longer available.

VOC is not the only instrument that teams can use by themselves. Other examples of useful tools that every team can use in everyday work include project management documents that bring structure to every initiative.

Light LSS Example: Project Documentation as the Basis for Every Initiative

Even if LSS is not used in everyday operations, a smart expert can still smuggle a few useful tools into the workplace. This is because every organization runs projects; all projects typically bring change and opportunities for improvement. As these tools are simple and universal, no matter what methodology an organization uses, LSS best practices around project management documentation can often be the first big win. This can apply to any initiative, starting with a local team project and finishing with a global organizational change. Here are some examples of tools that each person running a project should befriend:

  • RACI and governance structure: Any initiative (including team outdoor event) needs people responsible, people to be consulted and informed as well as sponsors. The bigger the project, the more complex the structure, but the basics should always be in place.
  • Project charter: Without specifying the problem, it is difficult to find the right solution. A well-written project charter helps resolve this issue and also serves as the perfect baseline document protecting the project manager against scope creep.
  • Project plan: Any project needs a schedule to keep everyone in check. Tools like MS Project and MS SharePoint are excellent in that respect, but can be considered too complex for small projects. In such cases, there is nothing preventing the team from using simpler tools like a flipchart or spreadsheet.
  • Communication plan: The tool that is often used for big projects can prove quite useful in any situation where multiple stakeholders are involved. And because communication in big organizations can be a challenge, giving it more structure is beneficial for all.

Light LSS Example: 5S in Everyday Operations

What if the LSS expert is assigned to a team that does not run any projects? One might argue that the space for improving their operations is limited. There is a tool, though, that can be applied in any circumstances and implemented by the team independently – 5S (sort, set in order, shine, standardize, sustain) only sounds like one tool, but it is by far one of the most helpful. Apart from the visible improvements 5S offers in each of the five phases of DMAIC (Define, Measure, Analyze, Improve, Control), 5S offers plenty of opportunities to embed the continuous improvement mindset quickly and effectively. (Again, if it is not possible to use all the elements at once, fit-for-purpose is the most sensible approach to follow.) 

In operations like human resources, finance or outsourcing, some 5S techniques can be applied as successfully as in manufacturing. Good analogies for a service environment relate to virtual workplaces. Some examples include setting up document repositories and shared locations, standardizing service inputs or outputs, and keeping the PC workplace tidy.

  • Sort: The simplest task that can help one deal with a large number of documents is to identify the items that are not required and move them into a separate space. Archiving and versioning techniques can be useful here.
  • Set in order: This step establishes a correct place for different types of documents or records. One of the ways to address this step is to use an established naming convention and folder structure that makes the document repository user-friendly.
  • Shine: It is a good habit to apply the “shine” phase in an iterative manner by removing items that are too old, not valid, etc. As in any workplace, operating in a tidy environment results in better outcomes and higher employee satisfaction.
  • Standardize: Activities around standardization can be extremely helpful, especially for more complicated document repositories. If every folder needs to follow a more complex structure, it might be helpful to document the approach in a standard operating procedure or a README file posted in a visible place.
  • Sustain: Last but not least, in order to maintain that perfect state, there are a few practical methods to be used. Some tools include regular reviews with the SMEs, or retrospective sessions with the team. Both allow gathering feedback on whether the document structure is consistent, up-to-date and up to stakeholder expectations. 

Light LSS: Process Mapping and Procedures Used for Process Design

The previous examples demonstrate how to improve an existing process with little effort. But what if the process is not there yet? In such instances, the LSS expert might be asked to design and implement an activity that was not previously performed.

When establishing a new function, going through re-organization or simply starting a new activity, a couple of LSS tools can be utilized to help define and document the change taking place.

  • Supplier, input, process, output, customer (SIPOC): When defining any kind of activity for the first time, identifying inputs and outputs, or pointing at the real customer of the product or service can be a challenge. On the other hand, knowing these and having them documented can help in understanding the critical points of the process and focusing the effort there.
  • Process map: No matter how complex the activity, one picture tells more than several pages of documentation. For any activity that was not defined previously, drawing a process flow with the respective phases, steps and actors can prove invaluable. This approach is the simplest way of spotting bottlenecks or pain points, and being able to address them straight away.
  • Standard operating procedure (SOP): Even though an SOP is known in LSS circles as the file used to document an improved process, SOPs can and should be used for any kind of activity. Combined with the high-level process map, SOPs tell the whole story, help train new staff and make the process output repeatable.

Benefits of Light LSS

When the reality is different from what was taught during training, the choices are to give up or adjust one’s approach. By using a fit-for-purpose approach and simplifying the tools, it is easier to make the tools easier to remember and, therefore, encourage the staff to use them more often. Many small improvements have a big chance of translating into a continuous improvement culture for the whole organization.