Control Phase: Lean Six Sigma Application in Information Technology Tutorial

7.1 Lesson 07 Control

Hello and welcome to the seventh lesson of the Lean Six Sigma Application in Information Technology course offered by Simplilearn. This lesson covers the concept of Control in detail. Let us explore the objectives of this lesson in the next screen.

7.2 Objectives

After completing this lesson, you will be able to: Identify commonly used control charts Choose the correct control chart based on the type of data Apply control charts to monitor performance Articulate the core components of a visual management system Apply visual management to IT processes Let us do the Control Phase Review in the next screen.

7.3 Control Phase Review

The purpose of the control phase is close the project and ensure improvements are sustained. Specific deliverables in the control phase are: Test for Improvements - Compare baseline metric-to-metric after implementation Control Plan - Monitor and take action as metric degrades On-Going Monitoring - Control chart monitoring Project Transition - Closure of project and transition to process owner Let us move on to the first topic of this lesson.

7.4 Control Topic 1 Control Charts for Common IT Metrics

This topic focuses on Control Charts for Common IT metrics. We will learn about control chart in the next screen.

7.5 Control Chart

Control charts theory is based on the work of Walter Shewhart. A control chart measures the health and stability of a given process It is based on actual process performance, so it provides a good measure of the voice of the process. The purpose of a control chart is to determine if the variation in the process is normal or caused by something that needs to be investigated and addressed The types of variation will be covered in the next screen.

7.6 Types of Variation

All measurements display variation over time- control charts help to visualize two types of variation Common Cause: Common cause variation is consistent, random variability seen in a normal process. Common cause variation results from the design of the process itself and can be hard to reduce. Special Cause variation is variability caused by a specific event or set of circumstances. Special cause variation manifests itself as an outlier or pattern in the control chart. Special cause variation is easy to identify and generally easy to eliminate. An example of special cause variation would be a spike in delivery times during a snowstorm Let us discuss some of the common Control Chart terminologies in the next screen.

7.7 Control Chart Terminology

Common terms used when working with controls chart include: A process is considered to be in control if there is no special cause variation present. It is important to note that just because a process is in control does not mean it is performing to the level required by the customer or that the amount of variation seen is acceptable, it just means the output of the processes is exhibiting statistically normal variation. The control limits are statistically calculated boundaries in which a process in control will operate- in general the control limits are plus and minus 3 standard deviation from the mean. Control limits do not have any relationship to customer specifications and should not be manually changed. A subgroup is a group of measurements taken at roughly the same time. Each data point on the control chart is the average of the subgroup. Examples of subgroup data for a control chart might be hourly, daily, or monthly Let us look at data types in the following screen.

7.8 Data Types

Different processes produce different data It is important to understand what type of data is available, as this will determine the type of control chart that can be used to monitor ongoing performance. There are two main types of data. They are continuous or variable and discrete or attribute. Continuous data is the measurement data. Examples of continuous data include height, weight, time, temperature, and length. Attribute or Discrete data is descriptive or count data. Good /Bad; Pass/ Fail: Low/Medium/High, grades, survey scale of 1 to 5 and so on are the examples of discrete or attribute data. Discrete data is often shown in the form of a proportion or percentage. Care should be taken when working with survey data as it can be averaged and is easily mistaken for continuous data. Continuous data is common in manufacturing and operational types of processes, while attribute data is more often found in transactional processes. The next screen will show how to select a control chart for continuous data.

7.9 Control Chart Selection Continuous Data

Selecting the correct control chart based on the type of data is critical to the effectiveness of monitoring Given here is a table detailing the selection criteria for control charts utilizing continuous data: If individual data points are being plotted- use an I-MR chart In the case of a small subgroup size ( 10 or less) an x bar and r chart should be used When a larger subgroup size (more than 10) is used, the x bar and s chart is the appropriate control chart. In the next screen we will discuss discrete data control chart selection.

7.10 Control Chart Selection Discrete Data

Given on the screen is a table detailing the selection criteria for control charts utilizing discrete data: When using defect (count) data, if you have the same subgroup size at each collection, the c chart is used- if there are different subgroup sizes at each collection, a u chart should be selected. When using defective (percentage) data, if you have the same subgroup size at each collection, the np chart is appropriate to use- if the subgroup sizes are different at each collection, then use a p chart. In the next screen we will discuss the interpretation of control charts.

7.11 Interpreting Control Charts

The graph on the screen is an x-bar and r chart of help desk call times in seconds. Let’s take a closer look at the top chart, which is the x-bar chart: The green line represents the mean of the process, and the brown lines are the control limits. The x- bar chart depicts the differences between the subgroups. No data points are flagged, which means this process is performing with normal variation and is in control. The chart on the bottom of the graph is the range chart. The range chart measures what is called the within variation- that is the variation within each subgroup. It is also showing normal variation. Let us now look at a control chart with out of control points in the next screen.

7.12 Out of Control Points

The graph on the screen is an np chart of help desk cases closed within 24 hours. Similar to the previous control chart, the green line represents the mean of the process, and the brown lines represent control limits. The p chart records the percentage of cases closed within 24 hours. In this example, there is an out of control point, which should be researched to see why a statistically significant amount of variation happened in sample 16. We will cover the common IT metrics and control charts in the next screen.

7.13 Common IT Metrics and Control Charts

Some common IT metrics and the correct control chart to monitor their stability are: Cycle Time. Sample metrics are : Call answer time Time to close ticket Project cycle time System downtime Hold times Processing speed Control charts is x bar and R, x bar and s For defects, sample metrics include : Defects per requirements Intrusion events Escalated cases Defects in production Test case completion Control charts are : c chart u chart For defects, sample metrics include Missed SLA % Requirements accuracy. Controls charts are p chart and np chart Let us proceed to the next screen for the steps to create a monitoring program.

7.14 Steps to Create a Monitoring Program

To establish a meaningful monitoring program with control charts, considerable thought must be given to the program design. The following six step process will enhance the odds of a successful program implementation: Step 1: Identify the critical metrics to be monitored via control chart. The metrics should be critical to operations and aligned with the goals and metrics of the IT organization to ensure attention is drawn and action is taken. Step 2: establish how often the control charts will be produced and published. True SPC is done real time, and there are many IT processes that could benefit from real time monitoring to ensure stability and optimal performance- Server performance is a good example of an IT metric that should be monitored in real time. If real time results are not feasible or applicable, daily or at the most weekly control chart production should be established. Step 3: Establish data collection plan- it is important to understand what data will be collected, and at what interval. The data collection plan should include the methodology for subgrouping the data. Step 4: Once the data type and subgroup strategy are established, the next step is to select an appropriate control chart. Step 5: Establish a plan of action to address out of control points if and when they occur. The plan should be detailed including the action to be taken and person responsible for taking it. Step 6: The final step is to launch the control chart program. Let us proceed to the next topic of this lesson in the next screen.

7.15 Control Topic 2 Case Study 1

This topic covers the first case study of this lesson on leveraging control charts to monitor and react to web analytics. Let us review the background for the case study in the next screen.

7.16 Background

Read as appear on screen In the next screen, we will look at the first question.

7.17 Case Study Question 1

What control chart should be used to monitor page views per visit? Depending on the subgroup size, the (x bar) and R or x bar and s chart should be used for the monitoring program. Let us proceed to the next screen to continue the case study

7.18 Control Chart Set Up

Read as appears on screen Let us see the control chart results in the next screen.

7.19 Control Chart Results

The graph on the screen is the x bar and r chart of page views. You can use the output given on the screen to answer the next two case study questions. Let us proceed to the next screen for the second question.

7.20 Case Study Question 2

What is the mean number of page views? 2.75 Let us see the third question in the next screen.

7.21 Case Study Question 3

Should Nutri Worldwide Inc. be concerned about the variation in their process? Statistically speaking, the variation in the process is stable and the process is in control. Hence, the enterprise need not be concerned about the variation in their process. Control chart does not indicate if the amount of variation is acceptable from a business purpose. Let us now proceed to the next topic of this lesson in the following screen.

7.22 Control Topic 3 Visual Management in IT

This topic will focus on visual management in IT. We will cover the basics of visual management in the next screen

7.23 Basics of Visual Management

Listed on the screen are some basics of visual management A good visual management consists of simple visual tools that can be understood by anyone at a glance visual management ensures that the problems stand out and everyone sees the same performance information at the same time Utilizing visual management drives standards and accountability Finally, strong visual management practices allow employees and managers to take quick action and solve problems rapidly The next screen will present a simple example of visual management

7.24 Visual Management Example

Let us look at a quick example of what it means to have visual management that can be understood at a glance by anyone If you were to walk into an office and see the two stacks of papers as shown on the screen, which one would you think needs immediate attention? No words are needed-it is easy to interpret the red pile is the one that needs immediate attention, simply due to the color. Let us discuss Agile Project Management in the next screen.

7.25 Agile Project Management

Agile project management and software development practices share many items in common, including the concept of visual management. There are various visual management that can be used in Agile, such as Project burn down chart, Kanban Board, and Visual Boards. (An example of project Burndown chart is shown here.) Let us see an example of project Burn Down chart in the following screen.

7.26 Project Burn Down Chart

A sample of project burndown chart is shown on the screen. This simple chart allows everyone to see how the team is progressing in comparison with the actual plan for completing tasks. This type of chart is updated daily. It allows the team to adjust assignments and bring in flexible staff when the actual tasks remaining are above the planned tasks remaining. Although this example is specific to the build process, a similar concept of plotting actual output versus expected output can be implemented in all areas of IT. The next screen will illustrate another effective agile visual management tool, called Kanban board.

7.27 Kanban Board

A Kanban board is a simple tool utilizing sticky notes and paper. The purpose of the Kanban is to illustrate the tasks left to do, what is in process, and what has been completed. The Kanban board can be color coded by type of task, or by person working on the task to manage tasks across the team. This type of board is effective not only for project work, but also for any assignment based activities that are completed in an IT organization. Let us learn about visual boards in the next screen.

7.28 Visual Boards

Visual Boards are a another component of the visual management system A visual board provides a central location where performance is tracked and discussed The purpose of a visual management board is to create transparency on performance The transparency provided by the visual board allows managers to manage daily performance Visual boards provide ability to flex activities and staffing based on current performance An example of a visual board is shown in the next screen

7.29 Visual Board Example

A sample visual board used in a tier 2 customer support team is shown on the screen. Let us look into its sections: Section 1 monitors the expected cases vs the actual cases resolved. The expected information is updated everyday based on the escalated items in queue. Employees who are on target or above the target are listed in green, those who do not meet the target are red. It is important to note that the purpose of the visual board is not to call out employees or reprimand employees who are running behind, it is meant to provide visibility and flex resources as needed. In this example, since Jeff is ahead of his target, the supervisor might shift him to help Jill and Alex who are behind. Section 2 is meant to document the problems that occur during the day. In this case, Alex identified some missing invoices in the database. Once the problem is identified, it is assigned out to be solved, and progress toward solving is recorded. Section 3 on this board is a place to document improvement ideas. This section should be reviewed everyday and implemented if it is a quick hit or assigned to a dedicated problem solving effort if it is more complicated. The next screen will cover the guidelines for good visual management.

7.30 Visual Management Guidelines

Some of the guidelines for a good visual management is listed on the screen. Information on the visual management board should be linked to the critical business metrics and activities The visual board is maintained by the employees doing the work It should be updated at regular intervals, throughout the day The visual board should be located in a central place in the workplace where it is easy to view and access. Traditionally a visual board is an actual physical board however virtual boards can be effective with virtual or geographically dispersed teams. The board should be designed in such a way that the information on the chart and the signs are clear and visible finally, the performance information should include the standard or goal, and the current performance against the goal In the next screen we will begin the case study.

7.31 Control Topic 4 Case Study 2

We will now cover the second case study of this lesson, which is on Visual Management in IT. Let us proceed to the next screen to review the background of the case study

7.32 Background

Read bullets as appeared In the next screen, we will discuss the subset of the metrics currently being

7.33 Subset of Metrics

Review the current metrics being tracked that relate to potential causes and response to critical or Severity 1 incidents.

7.34 Case Study Question 1

Are the metrics as currently produced appropriate to use for a visual management board? No. All the current metrics reflect monthly performance. To effectively manage response to critical incidents, real time information is needed. Let us proceed to the next screen to view modifications to the current metrics the team identified.

7.35 Revised Metrics

The revised metrics or tracking is shown on the screen. The team modified the cadence and purpose of existing metrics to make them meaningful and actionable. The visual board developed by the team is on the next screen.

7.36 Visual Board Updated

The visual board implemented by the team, who meet every morning to review the previous day’s events is shown on the screen. The visual board tracks sev 1 event response times, including the estimated solve time and how it compares to the SLA for solve time. The visual board also tracks system actual system downtime vs the goal and documents reason for downtime.In addition to the visual board, the director installed monitors in the work area to display the infrastructure utilization and disk utilization control charts. The director has also assigned responsibility to the applicable team members to monitor and react when out of control conditions are observed. Use this visual board image and answer the questions in the next two screens. The second question of this case study is given in the next screen.

7.37 Case Study Question 2

As per the updated visual board, is the team in danger of missing the Sev 1 SLA? Yes. Currently, the estimated response time is 5 hours versus an SLA of 4 hours. The third question of this case study is given in the following screen.

7.38 Case Study Question 3

What is the team doing to get the response time back on track? According to status or updates, an additional technical resource has been called in to work on the issue. This concludes the case study.

7.39 Quiz

Following is the quiz section to test your understanding of the topics covered in this lesson

7.40 Summary

Here is a quick recap of what we have learned in this lesson: The control phase of a Lean six sigma project is focused on testing the improvement and ensuring the process will sustain the improvements. Control charts illustrate the voice of the process and measures the health of the process. Control charts identifies 2 types of variation, common and special cause. Visual management is a method to make problem stand out. It allows quick action and problem solving. Visual boards provide a forum for creating transparency and managing daily performance.

7.041 Conclusion

This concludes lesson Seven, Control In the next lesson, we will discuss Design for Six Sigma in IT.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*