The illustration to the left, for example, shows a beautifully straight lower area for work that has been completed. The slope is upward and consistent. This process is completing work consistently. The middle segment of this illustration is a big ragged, but still relatively consistent. And the upper segment is trending upward at about the same rate (slope) as is the work being completed. This is rather an ideal situation. Work is being completed consistently. There is a small backlog of work but it does not seem to be impacting the process. Nor does the process appear to be starved for work.
The diagram to the left illustrates a backlog. Notice that the work being completed has a good upward flow and the work pending (the middle section) parallels the work being completed. This implies that the work that is active is being managed consistently. But the upper segment of this graph is increasing in height. This implies a backlog. More and more work is being queued up with no place to go. This implies that the process is a bottleneck. There is additional work that could be completed if the process was more efficient or if more resources were added to the process.
It is important that the bottom segment of the CFD show a consistent upward trend to indicate work being completed. It is important that the middle segment of the CFD parallel the bottom segment. If the middle segment dips close to the bottom segment, this implies that the process was starved for a resource and could not take on new activities. If the middle segment begins to climb at a rate faster then the bottom segment then this implies thrashing. The process is accepting input faster than it can process that input and is likely to soon loose efficiency. Both of those patterns are visible in the diagram to the left. At this point in time these are warning indicators. The work being completed is still consistent, but unless these warnings are addressed the work being completed is likely to deteriorate.

There are three levels within a corporation that must be assessed -- the senior executives, the executing managers and the resources doing the work. Each requires a different approach. In my experience, the senior executives have the least amount of time and must be given short, quick surveys. The employees and associates doing the work have the most time but typically have the least vested interest. It is the managers in the middle that see the benefit and understand the investment required to change an organization. Thus I focus most of my attention on the middle managers.

I recommend defining a well worded assessment survey and then repeat exactly the same survey every thirty to ninety days. Shuffle the order of the questions if desired, but keep every word the same so that you detect changes in opinion as opposed to changes in the tool. It is also important to ensure consistency between the questions. The Guttman format works very well in that each response incorporates the prior response thus generating a hierarchy of excellence. Consider the following question and responses.

Q01: Assess and Manage IT Risks: Are risks evaluated before work begins? Is there a formal process for identifying, ranking and planning for risk management? Is the risk management process well managed and continually refined?
	0 Not Applicable
	1 Never
	2 Seldom
	3 Usually
	4 Consistently
	5 Always

This question is compound for two reasons. First, the goal is to assess the maturity of the process as a whole and second, to reduce the number of questions and thus make the survey appear shorter. Responses to this type of question can be summarized and translated directly into a COBIT maturity level. The alternative, shown below, requires multiple questions and it requires applying a rating scale to the value of each response.

Q02: Assess and Manage IT Risks: Are risks evaluated before work begins?
	0 Not Applicable
	1 Never
	2 Seldom
	3 Usually
	4 Consistently
	5 Always

Q03: Is there a formal process for identifying, ranking and planning for risk management?
	0 Not Applicable
	1 Never
	2 Seldom
	3 Usually
	4 Consistently
	5 Always

Q04: Is the risk management process well managed and continually refined?
	0 Not Applicable
	1 Never
	2 Seldom
	3 Usually
	4 Consistently
	5 Always

A response of 3 to Q01 means that there is a defined process and it is often but not consistently applied. In contrast, a response of 5 to Q02 does not mean that the process has achieved Level 5 maturity, it only means that this one aspect of the process has been optimized. Next you would need to combine the ratings from Q02, Q03 and Q04. Do you go with the lowest rating or the average? My preference is to let the middle managers weigh the choices and then provide one rating that expresses their best judgement. My goal is to capture their assessment rather than taking opinions and applying my own rating. Thus I format my questions like Q01 and I avoid the pattern shown in Q02 through Q04.

The next step is to validate the responses for consistency. I recommend “box plots” for that purpose. A box plot is a simple bar graph that shows the range of responses and the median. I use one box plot to search for patterns among the respondents, a second box plot to search for patterns among the questions and a third box plot to assess the responses.

Consider the box plot shown to the right. Notice the division of opinion. Some of the managers answered only in the range from 2.0 to 3.0. Other managers answered only in the range from 3.0 to 4.0. There is a clear division of opinion between these managers. That division warrants closer attention. Some groups appear to be benefiting from the process improvement initiative while other groups are not. If the overall effort is to succeed, then more attention must be focused on consistency. Effort needs to be put into raising the low ranking values so that they overlap with the higher values.

The box plot shown to the right illustrates a comparison between questions. Notice that Q2 received the highest ratings while Q7 was rated the lowest. The value of that observation depends upon the objective for the survey. The box plot graphically highlights areas of concern. It is then up the team to assess the meaning of those values.

The response summary also reveals patterns about both the survey and the respondents. For example, consider the box plot and histogram immediately below. Notice the outline of a normal curve in the box plot and see how well it matches the distribution pattern expected from a normal curve. This is desirable. This indicates that the responses were well distributed and the respondents were spread in a typical pattern.

In contrast, compare the scattered pattern of user responses shown in the box plot below and the resulting histogram. In my interpretation, the histogram reveals three distinct groups of users. There is a group of users that scored at 0.0, a distribution of users that scored between 0.2 and 0.6 and a group of users that rated everything at 1.0. This pattern shows the value of the survey in that it has highlighted a problem. Next the team needs to decide how to raise the 0.0 user group and also assess whether or not the users responding with 1.0 ratings actually understand the process.

One way to minimize the risk of receiving ratings of all 0.0 or all 1.0 is to change the style of the questions and responses. I recommend doing this when sending surveys to the employes and contractors doing the work. They tend to have the least interest in the survey and sometimes respond by slamming their responses all the way to one pole or the other. This behavior is most evident in mandatory surveys -- like those given out by instructors following a classroom presentation. Consider the following questions.

Q05: How often do you check your email for notifications about this project?
	0 Constantly
	1 Once an hour
	2 Daily
	3 Once a week
	4 Seldom

Q06: How often do you connect to the knowledge base and search for new policies?
	0 Constantly
	1 Once an hour
	2 Daily
	3 Once a week
	4 Seldom

Someone checking their email “constantly” is either not working very efficiently or is not providing realistic responses to this survey. Thus responses that “line” down this pole of the responses indicate a data set that is not accurate. For Q05 the “best” response is either “1 Once an Hour” or “2 Daily”. In contrast, a response of “1 Once an Hour” to Q06 is questionable. Do you really want your employees taking time out of every hour to go search for new policies? I would prefer to see Q06 answered with response “3 Weekly” or even “4 Seldom”. Any other response indicates that the respondent is either not reading the question or not interested in participating.

The disadvantage of this approach is that the analysis is made more complex. The simplicity of the Guttman approach is that response 0 can be assigned a value of 0 and response 5 can be assigned a value of 5. This simplifies the analysis. When the weight assigned to each response varies between questions, then it is necessary to apply a formula. The following formula illustrates the process.

   IF(B15=1,0,IF(B15=2,0,IF(B15=3,1,IF(B15=4,2,IF(B15=5,3,IF(B15=6,4,0))))))/4

This formula first gives each a response a weight.

1		0
2		0
3		1
4		2
5		3
6		4
Other		0

Then the formula divides that weighted result by the maximum weight. This yields a number between 0.0 and 1.0.

Before closing this topic there is one more point to consider. Not all respondents will answer all questions. You need to plan in advance how to rate non-responses. The formula shown above assigns “other” to the value of zero. In essence this says that not responding is the same as responding at the lowest rating. Alternatively, not responding can mean no data. If that is the case, then remove that response when calculating the median and mode of the responses.

Bar Charts

Bar charts are one of the simplest ways to display metrics. They are easy to understand, easy to put together and serve a useful purpose. The biggest limitation to bar charts is that they are historic. They provide little information about the present and almost no information about the future. Thus, in spite of the wealth of data they display their information content is low. Consider the following two bar charts. The bar chart and the Cumulative Flow Diagram (CFD) show the same data. Can you see the trend displayed on the CFD? Do you notice how hard it is to discern the same trend on the bar chart? I recommend using bar charts for data exploration. Then either use a Pareto histogram to order the bars by importance, a line or area chart to display trends or a more sophisticated tool such as a process control chart.

Line Charts, Trend Lines and Forecasts As noted above, a line chart does a better job of visualizing trends than does a bar chart. This makes a line chart more useful than a bar chart for visualizing the past and present. Additionally, it is easy to add a trend line to a line chart and thus predict a possible future outcome. Consider the bar chart and the line chart shown on the next page. Notice the trend line added to the line chart. This was very helpful on a project where the apparent trend was upward without limit. By adding a polynomial trend line to the chart it became clear that the pace was slowing.

You can also mix bar charts with line charts, but this is rather like mixing apples with oranges. Consider the following example. This image conveys a large amount of data in a very compact space. Again, the bars represent past activity while the line allows you to visualize future trends. But, in my opinion, the reason this type of graph is so popular is that it allows everyone to quickly gloss over the relevant information.

There is too much data with too little information. Everyone, and I include myself because I have created plenty of these charts in the past, can sit in a meeting, look at this chart and feel like they now have a better understanding of the process. And yet, nothing here explains why the bars are higher one week than another, why there are more Tier 1 Restores in one week than in another or when the tape relabeling project will end. One of the key principles of Six Sigma is to collect and analyze the right data -- not reams of data, but a few precise items that provide strategic importance. Would the number of restores be more relevant if it was displayed as a Cumulative Flow Diagram so that the ongoing backlog was included in the analysis? Would the line chart be more meaningful if it was represented as a percent completion rather than just a raw number? Those are the types of decisions that separate Six Sigma from other metrics initiatives.

Radar Charts Radar Charts are really just line charts that go in a circle. They have become a standard tool in assessing and reporting process improvement. The chart to the right, for example, compares the assessment of twelve key processes over a three-month cycle. It is easy to see the processes where improvement took place and where the initiative did not get the expected results. On this chart the processes covered by Q2, Q3, Q10, Q11 and Q12 demonstrated improvement. The processes covered by Q1, Q5, Q6, Q7, Q8 and Q9 show little improvement. And it is easy to see which processes are closer to the ideal of Level 5 and which are still lingering around Level 2.

Process Mapping
One of the most important tools in Six Sigma is a Process Map. There are variations known as Cross-Functional Flowcharts, Work Flow Diagrams or even Flow Charts. All are distinct, yet all can serve a similar purpose. The goal is to document the actions and the decisions that must be made to complete the work required for a process. A simple cross-functional flowchart is shown on the next page. Notice the lines used to delineate responsibility. Those lines resemble the lines used to separate swimmers in competition and thus these charts are commonly known as swim-lane diagrams.

During a business improvement initiative, it is common to document the past -- known as the “As Is” process -- and then document the future -- known as the “To Be” process. Once the project is completed the “To Be” the “As Is” for the next round of improvement.

I strongly recommend using text to describe each step in a cross-functional flowchart. The table, below, illustrates the type of text that would accompany a simple business process. More complex processes require greater depth in the explanatory text.

Label Description Authority Executive Management must grant authority to the Portfolio Administrator to define the portfolio and collect the data. Define component types The Portfolio Administrator must work with the Subject Matter Experts (SMEs) to define a list of component types. Modify component types The SMEs have specific knowledge relevant to this industry and this environment. They need to assist in defining the component types so that the result is mutually beneficial. Current component types At any point in time there must be a readily accessible list of component types available for review by all appropriate resources. Identify current activities The initial exploration to discover on-going activities and categorize those activities into component types is a collaborative effort. Do not expect to achieve 100% coverage initially but strive to get closer to 100% coverage over time. Review and feedback Executive Management needs brief overviews of the total and exception reporting on the activities that require action. Reporting The selection and packaging of this information is an iterative process with the Portfolio Administrator responding to the feedback from both Executive Management and the Subject Matter Experts. Status, review and feedback The SMEs have the best view of the real status on each activity. The SMEs also have a insight into the prioritization and scope of the activities that should be reported to Executive Management.

SIPOC (Supplier-Input-Process-Output-Customer) The SIPOC chart is a new twist to a very old format. One of the earliest process documentation tools was IPO. Six Sigma added to the left and right in order to document the customer focus required for a process-centered organization. A simple SIPOC begins by identifying who supplies the inputs, document the list of inputs, then use a process flow diagram of some sort to document the process. Next document the outputs and describe who the customer is for this service. IT departments often tend to think that the customer is IT itself. It is important to get beyond that focus and think about the “consumer” of the service delivered by the process. A simple SIPOC is shown, below.

Supplier	Input	Process	Output	Customer
Data center enviroment Network connectivity Existing SAN infrastructure	Request for storage space	Review the request Allocate SAN space Verify connectivity Mount the space Monitor and Manage	Allocation of storage space	Business application XYZ

Work Breakdown Structures A work breakdown structure (WBS) is both a product management and a project management tool. As a product management tools, a documents the product to be developed, documents the product that is now supported and continues to document the product as it was in the past. A WBS should therefore be developed and maintained both as a tool for looking ahead and as a source of information for what previously was. The project management use of a WBS is primarily focused on defining the major deliverables from the project so that those deliverables can be assigned to appropriate resources. The WBS then serves as a tool to clarify the project management approach and it should be archived to serve as a starting place for the next project. A very simple WBS is shown to the right.

Note that there are predefined WBS templates available through the Project Management Institute, the USA government and other bodies for many products and projects. In some cases use of those templates is mandated by law or by contract.

Worksheets, Check Sheets and Checklists
Standardized forms and templates are one of the keys to effectiveness and efficiency. Repeatable processes require reusable documents. Efficiency requires that the thought that goes into an effort be done once and captured in a reusable form.

There is a clear distinction between a worksheet, a check sheet and a checklist. A worksheet is a standardized form for documentation. A check sheet is a form for capturing information. A checklist is a document that describes the steps to execute in order to complete a process. An example of each is shown below beginning with a simple worksheet for calculating the return on investment and internal rate of return for a proposed project.

Return on Investment (ROI) Worksheet

	Year 1	Year 2	Year 3	Year 4	Year 5
Expected Income
Expected Cost Savings
Total gain for this year    (sum of Expected Income and Expected Cost Savings)
Planned Expenditures
Net gain for this year    (Total gain minus Planned Expenditures)
Five year gain at zero interest (sum of the Total gains for all five years)
Five year expenditures at zero interest (sum of the Planned Expenditures for all five years)
Simple Return on Investment    ((5 Year Gain - 5 Year Expenditures) / 5 Year Expenditures)
Present Value of the five year gain (Use the Microsoft Excel NPV function)
Present Value of the five year expenditure (Use the Microsoft Excel NPV function)
Present Value of the net gain    (Present Value of the Gain - Present Value of the Expenditures)
RETURN ON INVESTMENT    ((PV Gain - PV Expenditure) / PV Expenditure)
INTERNAL RATE OF RETURN (Use the Microsoft Excel IRR function)

A good illustration of a defect check sheet is the form used by rental car companies and insurance adjusters to document the dings and dents in an automobile. The form provides an illustration of the object being studied and a means for applying check marks, arrows or notes to describe the areas of concern. A check sheet can also consist of a form in which you put check marks to count the number of occurrences of some event. For example, a service desk employee might make tick marks on a form every time their resolution efforts are interrupted by telephone calls so as to support the effort at reducing the mean time to resolution.

One of the most commonly used examples of a checklist is the simplest form for a project schedule. A well documented project schedule includes much more information than just a list of tasks, but, at the core it is still a checklist. It lists the work that needs to be done and provides a sequence. The example shown below represents a small piece of a simple project schedule.

Gantt Charts and Network Diagram
The image shown above includes the checklist of activities on the left and a Gantt Chart on the right. A Gantt Chart is one of the oldest graphical tools for showing the sequencing of work. Nearly all project management software includes the ability to generate multiple graphical outputs including Gantt charts. One of the other commonly used graphical scheduling tools is a network diagram. While many students studying for the Project Management Professional (PMP) certification learn to draw these diagrams by hand, most project management tools include the ability to automatically generate these diagrams. The example shown below illustrates a network diagram used to locate the critical path on a very small project.

Force Field Diagram A force field diagram is a tool brought over from the science of physics. The concept is that there are always “Drivers” -- forces pushing for change -- and “Restraints” -- forces pushing against change. By itemizing these factors it is possible to gain a better understanding of why an initiative is working well in some areas and failing to achieve the same results in other areas. The illustration to the left is a rather generic force field diagram showing the forces impacting a process improvement initiative. Tree Diagrams There are numerous types of Tree Diagrams. Two that overlap with Six Sigma and Project Management are the “Expected Monetary Value” and the “Decision Tree”. The key difference between the two is whether your work from left to right or right to left in order to get the final answer. An Expected Monetary Value diagram is illustrated, below. A detailed explanation follows.

This explanation of the Expected Monetary Value diagram is a bit lengthy. It begins with the following scenario.

Your company requires a large quantity of widgets. Vendor B has historically delivered widgets ontime 70% of the times they were selected as the primary vendor. Vendor C has only delivered on-time 40% of the times they were selected. But Vendor C sells widgest for $42 each while Vendor B charges $50 each. Your company needs 1,000 widgets and neither Vendor B nor Vendor C has enough capacity to product 1,000 widgets on-time. To ensure that as many widgets as possible arrive on-time, you have decided to split the total and place an order with Vendor B for 350 widgets and an order with Vendor C for 650 widgets. Historically, when Vendor B is late, it has been necessary to stop production entirely at a cost of $50,000. Historically Vendor C is never completely late. Instead Vendor C ships new widgets every week until they are caught up. In general that delay costs about $23,000 if it is kept under three months, but then escalates to $43,000 when the delay runs longer than three months. Allowing for the downtime that your assembly facility suffers when widgets arrive late, how much do you need to budget for this critical component?

You begin this analysis by drawing a tree. Node A represents the expected monetary value -- the amount you need to budget. Node B represents Vendor B and Node C represents Vendor C. Next add branches to Vendor B to show the two likely outcomes -- either everything ships on time or there is up to a three month delay. Label those branches Nodes D and E. Now add branches to Vendor C for the possible outcome that all the widgets will ship on time, the possible outcome that some of the widgets will be up to three months late and the possible outcome that some of the widgets might be up to five months late. Label those branches Nodes F, G and H.

At Node D fill in the probability that these widgets will ship on time (70%) and the purchase price ($50 each * 1,000 total required). Now multiple the probability by the cost and calculate the probably cost (70% * $50,000 = $35,000).

If the probability at Node D is 70%, then the probability of not delivering on time is 30% (100% - 70% = 30%). Add this value to Node E. The cost at Node E is the cost of the widgets plus the cost of the downtime ($50,000 + $50,000 = $100,000). Multiple the probability by the cost.

The probable cost of the portion of the purchase from Vendor B is calculated by adding the probable cost at Node D to the probable cost at Node E ($35,000 + $30,000 = $60,000) and multiplying by the percentage of the order (350 / 1,000 = 35%) that will be placed with Vendor B ($60,000 * 35% = $22,750).

Repeat that process now for Vendor C and calculate the probable cost of the purchase from Vendor C ($38,870).

The budget amount is the Expected Monetary Value calculated by adding the probable cost at Node B with the probable cost at Node C ($22,750 + $38,870 = $61,620).

And that is how you work an Expected Monetary Value (EMV) problem.

Now, as long as we are dealing with scenarios, what would the EMV be if Vendor C would implement Six Sigma? The answer is $42,000 because they would be so profitable they could increase their capacity to handle the required volume and they would always ship on time. Thus your company would save $19,620 ($42,000 - $61,620 = -$19,620) on this one order alone if you can convince Vendor C of the value of Six Sigma.

Cause and Effect Diagrams
Cause and Effect Diagrams are a diagnostic tool. They are often referred to as Fishbone Diagrams or Ishikawa Diagrams. The purpose for these diagrams is to show the connections between potential causes and possible effects. In many industries these diagrams are built in advance of the need and are then readily available when a problem arises. They serve as a useful format for organizing a large collection of data. The Cause and Effect diagram shown on the next page is loosely adapted from the Project Management Institute Project Management Body of Knowledge (PMBOK). The outputs from the PMBOK processes are shown on this diagram to show where they might originate. Note that in this case several outputs could originate from multiple different locations. Requested Changes, for example, is a very common output from multiple processes.

Contrast the organization of the data shown in this Cause and Effect diagram with the single level work breakdown structure on the subsequent page. While neither diagram truly represents the hierarchical nature of the PMBOK artifacts, both illustrate the diagram and provide a simple means for comparing the formats.

As noted earlier, a work breakdown structure is both a project and a product management tool. A Cause and Effect diagram is product focused. Both allow for a hierarchical representation of complex data. And both are especially valuable when they are prepared in advance and thus readily available when a problem arises.

Cause and Effect illustration from the PMBOK artifacts

Work Breakdown Structure illustration from the PMBOK artifacts

Affinity Diagram An Affinity Diagram is a tree diagram that shows the relationship between features. A common application is to graphically link the Critical To Quality (CTQ) features identified through customer surveys. The process I prefer is to use an assessment survey to collect the data, validate the data through box plots and histograms and then rank the data on a Pareto diagram, like the one shown below and to the right. Next, I find an Affinity Diagram useful as a presentation tool. It helps focus the discussion and gives the subject matter experts a tool to group the CTQs accurately. Thereafter I recommend using a correlation matrix (see below) to rank the CTQs and to manage the product. The Affinity Diagram shown to the right is an illustration of the format. Like all of the illustrations provided in this document, it shows the format and yet it is greatly simplified.

Correlation Matrix Project management and other disciplines make use of simple tables to organize data. One of the most common project management tables is the responsibility assignment matrix (RAM). One format of that table is called an ARCI.    Accountable    Responsible    Consultative    Informed. The table on the right is a simple ARCI.

Project Artifact Sponsor Project Manager Customers Users Development Team Project Charter A R C C C Project Plan R A C C R Project Schedule C A I I R Project Deliverables C R C C A

Another variation on this theme is a features matrix. A very simple features matrix is shown below.

Feature Group	Feature	Prior Design	Benchmark	New Design
White space	Maximum of 78 data cells per screen	Too much data	Defined the standard	Verified
	More space for data than for navigation	Too much navigation	No clear pattern	Verified
Navigation	Ability to filter the data	Minimal ability	Not visible	Verified
	Minimize hopping between screens	Verified	Yes	Verified

One more important project management matrix is the Probability-Impact-Matrix (PIM). A good use for this matrix is to combine two qualitative criteria in order to derive a risk ranking. A very simple format for a PMI is shown to the right. Six Sigma goes beyond these simple tables with a format known as a Correlation Matrix. The starting place for a Correlation Matrix can be a features matrix. Next, each cell in the matrix needs to be rated as to the overall contribution it makes to the end goal. The ratings system can be based upon any agreed upon mechanism. I think a PIM is very helpful here. The means for recording those ratings needs to be agreed upon. Pyzdek uses a series of graphical characters to represent the relative importance of each cell. I find it difficult to remember the ranking of the graphical characters so I prefer numbers or letters. A simple table showing my ranking of key criteria regarding a job search is shown below.

Job Search Rankings: 5=Very desirable, 4=Desirable, 3=Acceptable, 2=Tolerable, 1=Difficult

Job Focus	Technical		Environment			Payment	Schedule	Score
	Challenging Job	Appropriate Staff Size	Difficult Corporate Politics	Company Growing Slowly	Company Growing Rapidly	Pay My Asking Price	Standard Working Hours
ITIL	5	5	1	2	5	5	3	26
Six Sigma	5	3	3	4	5	4	4	28
Project Management	3	3	4	3	3	2	2	20
Governance	4	4	3	2	4	3	2	22
Mentoring	5	4	5	4	3	4	5	31
Vision	5	5	2	1	2	4	4	23
Growth	5	4	2	1	5	5	2	24
Score	32	28	20	17	27	27	22	Avg=25

The Six Sigma Quality Function Deployment (QFD) process then goes beyond the simple matrix. The diagram shown below begins with the job search criteria table that was introduced earlier. Then diagonal lines are added to the top of the chart to provide space to show the intersecting values. This illustration shows that I perceive a strong correlation between a challenging job and both the size of the staff and the growth rate of the company. In my assessment, I did not find a correlation between a challenging job and working a standard work week. As with all of these illustrations, it is an illustration. Focus on the process and the format and do not let the content distract from the goal of the illustration.

Benchmarking
Benchmarking is the process of comparing similar processes, departments, companies or products. A very simple benchmark is stock price. If the stock in your company goes up in value while the valuation of the stock in your competitors either goes down or goes up more slowly, then someone somewhere must be doing something right. Once you drill down from there you enter into a realm fraught with legal implications. For example, nearly all gasoline stations in a neighborhood will go up in prices at the same time and come down in price at the same time. While some accuse the oil companies of collusion, this is actually a very well defined and automated form of benchmarking. All of the major oil companies subscribe to third party data feeds that sell them competitive information. If Chevron goes up by two-cents then Shell will know about it within twelve to forty-eight hours depending upon the importance placed on that market location. And once that data is fed into Conoco’s computer systems, the automated pricing guidelines will recommend matching that move. This is benchmarking in practice.

For you to do the same thing in a competitive market is hazardous. The oil companies use the third party data sources to provide benchmark data in a way that gives those oil companies an approved legal separation. You want the same type of protection from accusations of collusion or reverse engineering.

One safe alternative is to use industry guidelines as the benchmark criteria. COBIT, for example, provides an excellent description of process maturity. The Project Management Institute sells a benchmarking tool called OPM3 (Organizational Project Management Maturity Model). Pink Elephant and other vendors sell a service to assess a companies ITIL compatibility -- in essence a benchmark of your processes against the ITIL standard process definitions.

An approach I have used successfully is to pull the concepts from COBIT or ITIL or PMI and rephrase those concepts into my own words. Then I conduct assessment surveys to get feedback from the senior executives, from the executing managers and from the resources doing the work. This provides a simple benchmark of perception versus ideal. By repeating those assessments at predefined intervals you can measure progress. Another approach is to use interviews and documentation reviews to form a subjective impression of the gap between the benchmark and the “As Is” practice. Next document the “As Is”, the “gap” and the “To Be” and obtain authorization to close the gap and take the company closer to the “To Be”.

I recommend using a correlation matrix to document the rankings and a radar chart to display progress.

Dashboards
Pyzdek provides exceptional details about dashboard layouts. Most other authors are less precise. All, however, agree with the core concept from Six Sigma that you want to manage with a selected strategic information and avoid drowning in volumes of data. The illustration, below, shows a single page from a dashboard I recently created.

Notice that this dashboard provides information about past performance, current activities and a forecast of future efforts. It provides information about the product being produced by this process and it provides information about the process. In this particular instance the process is a troubled process. Do not hide the problems. Show the troubled processes and offer advice on how to fix them.

The most meaningful dashboards have what the user wants to see. If possible, provide the dashboard information through an online portal and give the users the ability to customize the dashboard with the charts and graphs they find the most meaningful.

Statistical Process Control
Statistical Process Control (SPC) is a core element in Six Sigma. It reflects the manufacturing origination of this approach. SPC is not a common tool in the data processing environment, but it can be adapted and used effectively. Since the purpose for this guide is to illustrate Six Sigma, I have chosen a data set that will allow for a comparison of the SPC charts. Neither the data nor the analysis is not particularly valuable, it is the illustration that has value. That said, I have chosen to use running times from the last six Boston Marathons as the raw data to illustrate SPC.

One of the complexities of SPC is the number of different types of charts available. Pyzdek uses a decision tree to outline the criteria for each chart (page 419). Gitlow and Levine use a flow chart (page 454). To avoid copyright contention I will use a Cause and Effect diagram to outline the genus and species for the different types of SPC charts.

The first criteria used to separate the types of charts is that of integer versus variable data. Integer data is typically associated with counts or with boolean values like true versus false. Another name for integer data is attribute data. Variable data is typically associated with measurements like time, distance, weight and temperature. For this first illustration I am going to use the finish time for the fastest male runner in the last six races. Time is a measurement so we branch over to the variable side of the chart. The next branch point is related to the size of the data set. Since this first chart only shows the fastest time for male runners, there is only one element in each data set. Following the branching on the Cause and Effect diagram this leads to two useful choices -- an Individual Chart and a Moving Range Chart. Both are shown on the below.

Fastest Men's Times Year Minutes Moving Range 2001 129.72 * 2002 129.03 0.68 2003 130.18 1.15 2004 130.62 0.43 2005 131.75 1.13 2006 127.23 4.52

Note that both charts show a process that is in control. There are minor variations but few radical changes. The moving range chart values are calculated by taking the absolute value of the difference between one year and the prior year. This is a good indication of the rate of change. Note that the final year had a more dramatic change, but it was still within the control limits. Deriving the control limits is explained in both Pyzdek and in Gitlow and Levine. However, Minitab does an excellent job of calculating those values for you and it does so consistently and accurately every time.

The next branch off the Variable side of the diagram is for data sets where there are between two and nine elements to be averaged. To illustrate this set of charts I calculated the average for the top five women runners and the range of time from the first to the fifth place winner in the women’s running division. The data is shown to the right and the resulting charts are shown below. Note that the concept is to take an average so that there is a single value to plot and use the range to assess the variability of the data. In this case the “range” is the maximum minus the minimum within one set of data. For this illustration the range was calculated for each year by subtracting the fifth place running time from the first place running time. Note again that this process is in well within the control limits calculated by Minitab.

Fastest Women's Times Year Minutes Moving Range 2001 146.78 4.25 2002 144.67 7.25 2003 147.53 5.13 2004 147.55 6.28 2005 149.27 7.47 2006 144.78 3.23

When there are more than nine data values in each set the “range” is an inadequate indication of variability. The Standard Deviation provides a more consistent measure of variability. To see how this works, first examine the set of charts shown below.

The chart on the left shows the average finish time for the top ten entrants in the wheelchair division accompanied by the chart of the standard deviations. The chart on the right shows the average finish time for the top ten entrants in the wheelchair division accompanied by the chart of the range from the fastest finisher to the slowest finisher in this division. Notice that there is very little difference between the chart for the standard deviation and the chart for the range.

That first set of charts are based on ten data points per year. The charts shown below are based upon a repetition of data. The process used to fabricate the data for this new set of charts was to repeat the time for the fastest wheelchair ten times, repeat the value for the second fastest wheelchair nine times, repeat the value for the third fastest wheelchair eight times, etc. This fabrication technique created a data set weighted towards the faster times. You can see that the resulting standard deviation tracks closer to the middle of the control limits than does the range. And that is the point. For small data sets, the standard deviation and the range will appear very similar. For larger data sets, a small number of exceptions will distort the range while the standard deviation tracks closer to the midpoint. This gives a visual representation of the benefit of using the standard deviation over the range.

Attribute data is often based upon counts. The data shown in the table to the right, for example, shows the count of the number of women over 70 that finished the Boston Marathon, the count of the number of those women that finished slower than the 15th place male finisher in the over-70 age group and the ratio of the count of those who finished slower to the total number of women over 70 that finished. The first three columns represent attribute data. The final column is variable data that has been appended to this illustration to show the advantages of using attribute charts for attribute data.

Year Finishers Slower Rate 2002 1 1 1.00 2003 4 3 0.75 2004 2 2 1.00 2005 4 4 1.00 2006 7 4 0.57

The chart to the left, below, is an attribute chart. Since the number of finishers varies, the appropriate chart for this data is a p-chart. Note that Minitab automatically adjusts the lower control limit based upon the data in each sample -- each year. Note that Minitab also sets the upper limit at 1, corresponding to 100%. The maximum number of women that can finish slower than the men is the number of women that ran.

In contrast, the i-chart to the right of the p-chart has no inherent knowledge of the upper physical limit and thus calculates an upper control limit that is too high. Also, converting the counts into rates masks the sample size. While this is a useful technique when working with variable data, this produces an averaged lower control limit that does not represent this data as well as does the lower control limit shown on the p-chart.

An np-chart is essentially a p-chart with a caveat that each sample must be of the same size. To illustrate this, I took the results for each year and examined only the top fifteen women in the 40 to 49 age group. I then counted the number of those women that finished faster than the fifteen fastest male in the 40 to 49 age group. Each sample has fifteen items -- women runners -- thus each sample is of the same size. The resulting data and np-chart are shown below. Minitab correctly sets the upper control limit at the size of the sample and calculates a lower control limit.

Year Finished Slower 2001 14 2002 14 2003 13 2004 14 2005 13 2006 13

The c-chart is very similar to the np-chart. It is based upon attribute data. It is defined to be used when the sample range is fixed. But, while the np-chart is based upon counting occurrences in a set, the c-chart is more appropriate for counting occurrences in a time interval. For example, the number of phone calls received by a call center during a 24-hour time period is an attribute -- a count. The interval is constant -- 24-hours. But there is no “sample size”. While some could argue that there is some maximum phone line capacity constraint, such a constraint is not likely to actually impact this data set.

To illustrate this I counted the number of runners with times posted on the Boston Marathon web site summary page where the runners time was under three hours. The time interval is the constraint. While some of the postings are limited to the top fifteen runners, other listings show all runners that finished in that category. Thus there is no “theoretical” limit to the size of each result set. The data and c-chart are shown below.

Year Runners Under 3-Hours 2001 69 2002 76 2003 62 2004 56 2005 69 2006 71

The final control chart in this set is the uchart. A u-chart is very similar to a c-chart. Both display attribute data with the number of occurrences. The difference is that the sample size is constant for the c-chart and variable for the u-chart. For the purpose of this illustration I created a variable sized interval by dividing the slowest runner’s posted time by two. While this might not be the most logical thing to do, it does make for an appropriate illustration of the u-chart. The interval is variable. The attribute is the count of the number of runners with posted times that are faster than the defined interval. The data is shown in the table, above and the resulting u-chart is shown to the right. Note that the u-chart adapts automatically to variable sized samples by recalculating the upper and lower control limits for each sample.

Year Time Count 2001 165.3 51 2002 173.1 60 2003 165.8 42 2004 189.6 64 2005 164.8 42 2006 163.5 51

Failure Mode and Effect Analysis (FEMA)
FEMA is a standardized process for assessing and documenting risks. The PMI risk register is closely aligned with a FEMA worksheet. A simple illustration is shown below to document the risks associated with the process for creating and publishing this set of reference notes. Pyzdek has an excellent description of the process for performing this type of risk assessment including a table with guidelines for assigning quantitative values to the Severity, Occurrence and Detection columns. The PMI PMBOK also contains a well written explanation of risk management. Note that the table shown below is from the planning phase and does not yet have columns to record the occurrence or responses to these risks.

Function	Risk	Effect	Causes	Controls	Severity	Occurrence	Detection	Rating	Mitigation	Owner
Knowledge	Insufficient knowledge of the subject matter	Poorly written or erroneous notes	Insufficient exposure or reading or time or understanding	Proof readers	2	4	4	16	Study more and get more feedback	Perrine
Math	Inaccurate calculation	Erroneous illustration	Manual calculations or error in using tools	Double check calculation	2	2	3	12	Prefer tools over manual methods	Perrine
Versioning	Beta version distributed	Lower receptivity	Posting to web too soon	Accepted risk	3	4	6	72	Balance this risk with the need for proof readers	Perrine

The point of any type of risk assessment is to prioritize the effort. In the table shown above the greatest risk rating is assigned to the problem of version control. There is a need to publish early in support of other efforts that are now underway. Publishing early, however, is rather like releasing software early in that there are more likely to be errors. And those errors can become annoying to the users and cause the users to abandon the product. Thus, focused efforts must be made to address this risk.
 
 
Remaining Topics
Sometime in the future I plan to add notes to this document on the following topics:

• Balanced Scorecards
• Fault Tree
• Hypothesis testing
• Gauge testing
• Design of Experiments (DOE)

References
Reference Guides for Six Sigma
Thomas Pyzdek; The Six Sigma Handbook; McGraw-Hill; 2003; ISBN 0-07-141015-5
Howard S. Gitlow and David M. Levine; Six Sigma for Green Belts and Champions; Prentice Hall; 0-13-117262-X
Minitab; Meet Minitab; Minitab; 2004; ISBN 0-925636-48-7

Management Guides for Six Sigma
Subir Chowdhury; The Power of Six Sigma; 2001; Dearborn Trade Publishing; ISBN 0-7931-4434-5
Pete Pande and Larry Holpp; What is Six Sigma; McGraw-Hill; 0-07-138185-6
Pete S. Pande, Robert P. Neuman and Roldand R. Cavanagh; The Six Sigma Way; McGraw-Hill Audio; 0-9724889-5-2 (audio CD)
Greg Brue; Six Sigma for Managers; 2002; McGraw-Hill; ISBN 0-07-138755-2
Jay Arthur; Six Sigma Simplified - Green Belt Training Made Easy; 2004; LifeStar; ISBN 1-884180-19-1 (audio cassette)

Supplemental Guides for project management and project deployment
Project Management Institute (PMI); A Guide to the Project Management Body of Knowledge (PMBOK) 2004 edition; PMI; ISBN 193069945-X.
IT Infrastructure Library (ITIL); Best Practices Guide to Service Delivery; ISBN 0-11-330017-4 (book) or ISBN 0-11-330893-0 (CD)
IT Infrastructure Library (ITIL); Best Practices Guide to Service Support; ISBN 0-11-330015-8 (book) or ISBN 011-330867-1 (CD)
IT Governance Institute (ITGI); COBIT 4.0; ITGI; 2006; ISBN 1-933284-37-4

Other useful references
David J. Anderson; Agile Management for Software Engineering; Prentice Hall; 2003; ISBN 0-13-142460-2
David J. Anderson; "Using Cumulative Flow Diagrams"; http://bdn.borland.com/article/0,1410,32410,00.html