ISO 9126 Software Quality Characteristics

An overview of the ISO 9126–1 software quality model definition, with an explanation of the major characteristics.

Article Purpose

The purpose of this article is to present an overview of the ISO 9126 standard and to give a detailed description of the software quality model used by this standard.

ISO 9126 is an international standard for the evaluation of software. The standard is divided into four parts which addresses, respectively, the following subjects: quality model; external metrics; internal metrics; and quality in use metrics. ISO 9126 Part one, referred to as ISO 9126–1 is an extension of previous work done by McCall (1977), Boehm (1978), FURPS and others in defining a set of software quality characteristics.

ISO9126–1 represents the latest (and ongoing) research into characterizing software for the purposes of software quality control, software quality assurance and software process improvement (SPI). This article defines the characteristics identified by ISO 9126–1. The other parts of ISO 9126, concerning metrics or measurements for these characteristics, are essential for SQC, SQA and SPI but the main concern of this article is the definition of the basic ISO 9126 Quality Model.

The ISO 9126 documentation itself, from the official ISO 9126 documentation, can only be purchased and is subject to copyright. SQA.net only reproduces the basic structure of the ISO 9126 standard and any descriptions, commentary or guidance are original material based on public domain information as well as our own experience.

The ISO 9126–1 software quality model identifies 6 main quality characteristics, namely:

• Functionality
• Reliability
• Usability
• Efficiency
• Maintainability
• Portability

These characteristics are broken down into subcharacteristics, a high level table is shown below. It is at the subcharacteristic level that measurement for SPI will occur. The main characteristics of the ISO9126–1 quality model, can be defined as follows:-

Functionality
Functionality is the essential purpose of any product or service. For certain items this is relatively easy to define, for example a ship’s anchor has the function of holding a ship at a given location. The more functions a product has, e.g. an ATM machine, then the more complicated it becomes to define it’s functionality. For software a list of functions can be specified, i.e. a sales order processing systems should be able to record customer information so that it can be used to reference a sales order. A sales order system should also provide the following functions:

• Record sales order product, price and quantity.
• Calculate total price.
• Calculate appropriate sales tax.
• Calculate date available to ship, based on inventory.
• Generate purchase orders when stock falls below a given threshold.

The list goes on and on but the main point to note is that functionality is expressed as a totality of essential functions that the software product provides. It is also important to note that the presence or absence of these functions in a software product can be verified as either existing or not, in that it is a Boolean (either a yes or no answer). The other software characteristics listed (i.e. usability) are only present to some degree, i.e. not a simple on or off. Many people get confused between overall process functionality (in which software plays a part) and software functionality. This is partly due to the fact that Data Flow Diagrams (DFDs) and other modeling tools can depict process functionality (as a set of data in\data out conversions) and software functionality. Consider a sales order process, that has both manual and software components. A function of the sales order process could be to record the sales order but we could implement a hard copy filing cabinet for the actual orders and only use software for calculating the price, tax and ship date. In this way the functionality of the software is limited to those calculation functions. SPI, or Software Process Improvement is different from overall Process Improvement or Process Re-engineering, ISO 9126–1 and other software quality models do not help measure overall Process costs\benefits but only the software component. The relationship between software functionality within an overall business process is outside the scope of ISO 9126 and it is only the software functionality, or essential purpose of the software component, that is of interest for ISO 9126.

Following functionality, there are 5 other software attributes that characterize the usefulness of the software in a given environment.
Each of the following characteristics can only be measured (and are assumed to exist) when the functionality of a given system is present. In this way, for example, a system can not possess usability characteristics if the system does not function correctly (the two just don’t go together).

Reliability
Once a software system is functioning, as specified, and delivered the reliability characteristic defines the capability of the system to maintain its service provision under defined conditions for defined periods of time. One aspect of this characteristic is fault tolerance that is the ability of a system to withstand component failure. For example if the network goes down for 20 seconds then comes back the system should be able to recover and continue functioning.

Usability
Usability only exists with regard to functionality and refers to the ease of use for a given function. For example a function of an ATM machine is to dispense cash as requested. Placing common amounts on the screen for selection, i.e. $20.00, $40.00, $100.00 etc, does not impact the function of the ATM but addresses the Usability of the function. The ability to learn how to use a system (learnability) is also a major subcharacteristic of usability.

Efficiency
This characteristic is concerned with the system resources used when providing the required functionality. The amount of disk space, memory, network etc. provides a good indication of this characteristic. As with a number of these characteristics, there are overlaps. For example the usability of a system is influenced by the system’s Performance, in that if a system takes 3 hours to respond the system would not be easy to use although the essential issue is a performance or efficiency characteristic.

Maintainability
The ability to identify and fix a fault within a software component is what the maintainability characteristic addresses. In other software quality models this characteristic is referenced as supportability. Maintainability is impacted by code readability or complexity as well as modularization. Anything that helps with identifying the cause of a fault and then fixing the fault is the concern of maintainability. Also the ability to verify (or test) a system, i.e. testability, is one of the subcharacteristics of maintainability.

Portability
This characteristic refers to how well the software can adopt to changes in its environment or with its requirements. The sub characteristics of this characteristic include adaptability. Object oriented design and implementation practices can contribute to the extent to which this characteristic is present in a given system.

ISO 9126 Observations

For the most part, the overall structure of ISO 9126–1 is similar to past models, McCall (1977) and Boehm (1978), although there are a couple of notable differences. Compliance comes under the functionality characteristic, this can be attributed to government initiatives like SOX. In many requirements specifications all characteristics, that are specified, that are not pure functional requirements are specified as Non-Functional requirements. It is interesting to note, with ISO 9126, that compliance is seen as a functional characteristic.

Using the ISO 9126 (or any other quality model) for derivation of system requirements brings clarity of definition of purpose and operating capability .
For example a rules engine approach to compliance would enable greater adaptability, should the compliance rules change. The functionality for compliance could be implemented in other ways but these other implementation methods may not produce as strong an adaptability characteristic as a rules, or some other component based, architecture.

Also, a designer typically will need to make trade offs between two or more characteristics when designing the system. Consider highly modularized code, this code is usually easy to maintain, i.e. has a good changeability characteristic, but may not perform as well (for cpu resource, as unstructed program code). On a similar vein a normalized database may not perform as well as a not normalized database. These trade offs need to be identified, so that informed design decisions can be made.

Although ISO 9126–1 is the latest proposal for a useful Quality Model, of software characteristics, it is unlikely to be the last. One thing is certain, the requirements (including compliance) and operating environment of software will be continually changing and with this change will come the continuing search to find useful characteristics that facilitate measurement and control of the software production process.

MYERS BRIGGS PERSONALITY TYPES

ISTJ

Quiet, serious, earn success by thoroughness and dependability. Practical, matter-of-fact, realistic, and responsible. Decide logically what should be done and work toward it steadily, regardless of distractions. Take pleasure in making everything orderly and organized — their work, their home, their life. Value traditions and loyalty.

ISFJ

Quiet, friendly, responsible, and conscientious. Committed and steady in meeting their obligations. Thorough, painstaking, and accurate. Loyal, considerate, notice and remember specifics about people who are important to them, concerned with how others feel. Strive to create an orderly and harmonious environment at work and at home.

INFJ

Seek meaning and connection in ideas, relationships, and material possessions. Want to understand what motivates people and are insightful about others. Conscientious and committed to their firm values. Develop a clear vision about how best to serve the common good. Organized and decisive in implementing their vision.

INTJ

Have original minds and great drive for implementing their ideas and achieving their goals. Quickly see patterns in external events and develop long-range explanatory perspectives. When committed, organize a job and carry it through. Sceptical and independent, have high standards of competence and performance — for themselves and others.

ISTP

Tolerant and flexible, quiet observers until a problem appears, then act quickly to find workable solutions. Analyse what makes things work and readily get through large amounts of data to isolate the core of practical problems. Interested in cause and effect, organize facts using logical principles, value efficiency.

ISFP

Quiet, friendly, sensitive, and kind. Enjoy the present moment, what’s going on around them. Like to have their own space and to work within their own time frame. Loyal and committed to their values and to people who are important to them. Dislike disagreements and conflicts, do not force their opinions or values on others.

INFP

Idealistic, loyal to their values and to people who are important to them. Want an external life that is congruent with their values. Curious, quick to see possibilities, can be catalysts for implementing ideas. Seek to understand people and to help them fulfil their potential. Adaptable, flexible, and accepting unless a value is threatened.

INTP

Seek to develop logical explanations for everything that interests them. Theoretical and abstract, interested more in ideas than in social interaction. Quiet, contained, flexible, and adaptable. Have unusual ability to focus in depth to solve problems in their area of interest. Sceptical, sometimes critical, always analytical.

ESTP

Flexible and tolerant, they take a pragmatic approach focused on immediate results. Theories and conceptual explanations bore them — they want to act energetically to solve the problem. Focus on the here-and-now, spontaneous, enjoy each moment that they can be active with others. Enjoy material comforts and style. Learn best through doing.

ESFP

Outgoing, friendly, and accepting. Exuberant lovers of life, people, and material comforts. Enjoy working with others to make things happen. Bring common sense and a realistic approach to their work, and make work fun. Flexible and spontaneous, adapt readily to new people and environments. Learn best by trying a new skill with other people.

ENFP

Warmly enthusiastic and imaginative. See life as full of possibilities. Make connections between events and information very quickly, and confidently proceed based on the patterns they see. Want a lot of affirmation from others, and readily give appreciation and support. Spontaneous and flexible, often rely on their ability to improvise and their verbal fluency.

ENTP

Quick, ingenious, stimulating, alert, and outspoken. Resourceful in solving new and challenging problems. Adept at generating conceptual possibilities and then analysing them strategically. Good at reading other people. Bored by routine, will seldom do the same thing the same way, apt to turn to one new interest after another.

ESTJ

Practical, realistic, matter-of-fact. Decisive, quickly move to implement decisions. Organize projects and people to get things done, focus on getting results in the most efficient way possible. Take care of routine details. Have a clear set of logical standards, systematically follow them and want others to also. Forceful in implementing their plans.

ESFJ

Warm-hearted, conscientious, and cooperative. Want harmony in their environment, work with determination to establish it. Like to work with others to complete tasks accurately and on time. Loyal, follow through even in small matters. Notice what others need in their day-by-day lives and try to provide it. Want to be appreciated for who they are and for what they contribute.

ENFJ

Warm, empathetic, responsive, and responsible. Highly attuned to the emotions, needs, and motivations of others. Find potential in everyone, want to help others fulfil their potential. May act as catalysts for individual and group growth. Loyal, responsive to praise and criticism. Sociable, facilitate others in a group, and provide inspiring leadership.

ENTJ

Frank, decisive, assume leadership readily. Quickly see illogical and inefficient procedures and policies, develop and implement comprehensive systems to solve organizational problems. Enjoy long-term planning and goal setting. Usually well informed, well read, enjoy expanding their knowledge and passing it on to others. Forceful in presenting their ideas.

FISHBONE (ISHIKAWA) DIAGRAM

Fishbone Diagram

A fishbone diagram, also called a cause and effect diagram or Ishikawa diagram, is a visualization tool for categorizing the potential causes of a problem in order to identify its root causes.

Dr. Kaoru Ishikawa, a Japanese quality control expert, is credited with inventing the fishbone diagram to help employees avoid solutions that merely address the symptoms of a much larger problem.

A fishbone diagram is useful in brainstorming sessions to focus conversation. After the group has brainstormed all the possible causes for a problem, the facilitator helps the group to rate the potential causes according to their level of importance and diagram a hierarchy. The design of the diagram looks much like a skeleton of a fish. Fishbone diagrams are typically worked right to left, with each large “bone” of the fish branching out to include smaller bones containing more detail.

Fishbone diagrams are used in the “analyze” phase of Six Sigma’s DMAIC (define, measure, analyze, improve, control) approach to problem solving.

When to Use a Fishbone Diagram

· When identifying possible causes for a problem.

· Especially when a team’s thinking tends to fall into ruts.

How to create a fish diagram:

· Create a head, which lists the problem or issue to be studied.

· Create a backbone for the fish (straight line which leads to the head).

· Identify at least four “causes” that contribute to the problem. Connect these four causes with arrows to the spine. These will create the first bones of the fish.

· Brainstorm around each “cause” to document those things that contributed to the cause. Use the 5 Whys or another questioning process such as the 4P’s (Policies, Procedures, People and Plant) to keep the conversation focused.

· Continue breaking down each cause until the root causes have been identified.

This example illustrates how a group might begin a fish diagram to identify all the possible reasons a web site went down in order to discover the root cause.

CHECK SHEET

The Check Sheet is a simple document that is used for collecting data in real time and at the location where the data is generated. The document is typically a blank form that is designed for the quick, easy, and efficient recording of the desired information, which can be either quantitative or qualitative. When the information is quantitative, the check sheet is sometimes called a tally sheet. The check sheet is one of the seven basic tools of quality control made popular by Dr. Kaoru Ishikawa.

A defining characteristic of a check sheet is that data is recorded by making marks (“checks”) on it. A typical check sheet is divided into regions, and marks made in different regions have different significance. Data is read by observing the location and number of marks on the sheet.

When to Use a Check Sheet

· When data can be observed and collected repeatedly by the same person or at the same location.

· When collecting data on the frequency or patterns of events, problems, defects, defect location, defect causes, etc.

· When collecting data from a production process.

Check Sheet Procedure

1. Decide what event or problem will be observed. Develop operational definitions.

2. Decide when data will be collected and for how long.

3. Design the form. Set it up so that data can be recorded simply by making check marks or Xs or similar symbols and so that data do not have to be recopied for analysis.

4. Label all spaces on the form.

5. Test the check sheet for a short trial period to be sure it collects the appropriate data and is easy to use.

6. Each time the targeted event or problem occurs, record data on the check sheet.

Check Sheet Example

The figure below shows a check sheet used to collect data on telephone interruptions. The tick marks were added as data was collected over several weeks.

Five basic types of check sheets include:

Classification check sheet: A trait such as a defect must be classified into a category. If you just kept track of the total defects, you would know that you had 101 total defects. That is somewhat useful but that, in and of itself, does not provide much insight as to which day is the worst day or which source of defects is in the worst shape, etc. With a classification check sheet, it provides a visual overview of the problem areas.

Defect location check sheet: The physical location of a trait is indicated on a picture, or illustration of a part or item being evaluated. Instead of just keeping track of the number of defects, the defect location check sheet can sometimes reveal an area of the product that tends to see most of the defects. Once this is known, the team can go back to the process to see what it is about the upper right-hand corner of the product that is causing the defects.

Frequency check sheet: The presence or absence of a trait or combination of traits is indicated. Also, number of occurrences of a trait on a part can be indicated. Notice that if you just tracked the number of defects, you may not realize that Wrong Colour has the highest frequency of occurrence. Furthermore, if Wrong Colour was not broken down further, you might not realize that GREEN is giving you the most defects.

Measurement scale check sheet: A measurement scale is divided into intervals and measurements are indicated by checking an appropriate interval.

Check List: The items to be performed for a task are listed so that as each is accomplished it can be marked as having been completed.

SCATTER DIAGRAM

Also called: scatter plot, X–Y graph

The scatter diagram graphs pairs of numerical data, with one variable on each axis, to look for a relationship between them. If the variables are correlated, the points will fall along a line or curve. The better the correlation, the tighter the points will hug the line.

When to Use a Scatter Diagram

· When you have paired numerical data.

· When your dependent variable may have multiple values for each value of your independent variable.

· When trying to determine whether the two variables are related, such as…

· When trying to identify potential root causes of problems.

· After brainstorming causes and effects using a fishbone diagram, to determine objectively whether a particular cause and effect are related.

· When determining whether two effects that appear to be related both occur with the same cause.

· When testing for autocorrelation before constructing a control chart.

Scatter Diagram Example

The ZZ-400 manufacturing team suspects a relationship between product purity (percent purity) and the amount of iron (measured in parts per million or ppm). Purity and iron are plotted against each other as a scatter diagram, as shown in the figure below.

There are 24 data points. Median lines are drawn so that 12 points fall on each side for both percent purity and ppm iron.

To test for a relationship, they calculate:
A = points in upper left + points in lower right = 9 + 9 = 18
B = points in upper right + points in lower left = 3 + 3 = 6
Q = the smaller of A and B = the smaller of 18 and 6 = 6
N = A + B = 18 + 6 = 24

Then they look up the limit for N on the trend test table. For N = 24, the limit is 6.
Q is equal to the limit. Therefore, the pattern could have occurred from random chance, and no relationship is demonstrated.

Scatter Diagram Considerations

· Here are some examples of situations in which might you use a scatter diagram:

· Variable A is the temperature of a reaction after 15 minutes. Variable B measures the colour of the product. You suspect higher temperature makes the product darker. Plot temperature and colour on a scatter diagram.

· Variable A is the number of employees trained on new software, and variable B is the number of calls to the computer help line. You suspect that more training reduces the number of calls. Plot number of people trained versus number of calls.

· To test for autocorrelation of a measurement being monitored on a control chart, plot this pair of variables: Variable A is the measurement at a given time. Variable B is the same measurement, but at the previous time. If the scatter diagram shows correlation, do another diagram where variable B is the measurement two times previously. Keep increasing the separation between the two times until the scatter diagram shows no correlation.

· Even if the scatter diagram shows a relationship, do not assume that one variable caused the other. Both may be influenced by a third variable.

· When the data are plotted, the more the diagram resembles a straight line, the stronger the relationship.

· If a line is not clear, statistics (N and Q) determine whether there is reasonable certainty that a relationship exists. If the statistics say that no relationship exists, the pattern could have occurred by random chance.

· If the scatter diagram shows no relationship between the variables, consider whether the data might be stratified.

· If the diagram shows no relationship, consider whether the independent (x-axis) variable has been varied widely. Sometimes a relationship is not apparent because the data don’t cover a wide enough range.

· Think creatively about how to use scatter diagrams to discover a root cause.

· Drawing a scatter diagram is the first step in looking for a relationship between variables.

HISTOGRAM

A histogram is a plot that lets you discover, and show, the underlying frequency distribution (shape) of a set of continuous data. This allows the inspection of the data for its underlying distribution (e.g., normal distribution), outliers, skewness, etc. An example of a histogram, and the raw data it was constructed from, is shown below:

How do you construct a histogram from a continuous variable?

To construct a histogram from a continuous variable you first need to split the data into intervals, called bins. In the example above, age has been split into bins, with each bin representing a 10-year period starting at 20 years. Each bin contains the number of occurrences of scores in the data set that are contained within that bin. For the above data set, the frequencies in each bin have been tabulated along with the scores that contributed to the frequency in each bin (see below):

Notice that, unlike a bar chart, there are no “gaps” between the bars (although some bars might be “absent” reflecting no frequencies). This is because a histogram represents a continuous data set, and as such, there are no gaps in the data (although you will have to decide whether you round up or round down scores on the boundaries of bins).

Choosing the correct bin width

There is no right or wrong answer as to how wide a bin should be, but there are rules of thumb. You need to make sure that the bins are not too small or too large. Consider the histogram we produced earlier (see above): the following histograms use the same data, but have either much smaller or larger bins, as shown below:

We can see from the histogram on the left that the bin width is too small because it shows too much individual data and does not allow the underlying pattern (frequency distribution) of the data to be easily seen. At the other end of the scale is the diagram on the right, where the bins are too large, and again, we are unable to find the underlying trend in the data.

Histograms are based on area, not height of bars

In a histogram, it is the area of the bar that indicates the frequency of occurrences for each bin. This means that the height of the bar does not necessarily indicate how many occurrences of scores there were within each individual bin. It is the product of height multiplied by the width of the bin that indicates the frequency of occurrences within that bin. One of the reasons that the height of the bars is often incorrectly assessed as indicating frequency and not the area of the bar is due to the fact that a lot of histograms often have equally spaced bars (bins), and under these circumstances, the height of the bin does reflect the frequency.

What is the difference between a bar chart and a histogram?

The major difference is that a histogram is only used to plot the frequency of score occurrences in a continuous data set that has been divided into classes, called bins. Bar charts, on the other hand, can be used for a great deal of other types of variables including ordinal and nominal data sets.

PARETO CHART

What Is a Pareto Chart, and How Do You Use It?

A Pareto chart is a basic quality tool that helps you identify the most frequent defects, complaints, or any other factor you can count and categorize. The chart takes its name from Vilfredo Pareto, originator of the “80/20 rule,” which postulates that, roughly speaking, 20 percent of the people own 80 percent of the wealth. Or, in quality terms, 80 percent of the losses come from 20 percent of the causes.

You can use a Pareto chart any time you have data that are broken down into categories, and you can count how often each category occurs. As children, most of us learned how to use this kind of data to make a bar chart:

A Pareto chart is just a bar chart that arranges the bars (counts) from largest to smallest, from left to right. The categories or factors symbolized by the bigger bars on the left are more important than those on the right.

By ordering the bars from largest to smallest, a Pareto chart helps you visualize which factors comprise the 20 percent that are most critical — the “vital few” — and which are the “trivial many.”

A cumulative percentage line helps you judge the added contribution of each category. If a Pareto effect exists, the cumulative line rises steeply for the first few defect types and then levels off. In cases where the bars are approximately the same height, the cumulative percentage line makes it easier to compare categories.

Its common sense to focus on the ‘vital few’ factors. In the quality improvement arena, Pareto charts help teams direct their efforts where they can make the biggest impact. By taking a big problem and breaking it down into smaller pieces, a Pareto chart reveals where our efforts will create the most improvement.

If a Pareto chart seems rather basic, well, it is. But like a simple machine, its very simplicity makes the Pareto chart applicable to a very wide range of situations, both within and beyond quality improvement.

How to Create a Pareto Chart

Creating a Pareto chart is not difficult, even without statistical software. Of course, if you’re using Minitab, the software will do all this for you automatically — create a Pareto chart by selecting Stat > Quality Tools > Pareto Chart… or by selecting Assistant > Graphical Analysis > Pareto Chart. You can collect raw data, in which each observation is recorded in a separate row of your worksheet, or summary data, in which you tally observation counts for each category.

1. Gather Raw Data about Your Problem

Be sure you collect a random sample that fully represents your process. For example, if you are counting the number of items returned to an electronics store in a given month, and you have multiple locations, you should not gather data from just one store and use it to make decisions about all locations. (If you want to compare the most important defects for different stores, you can show separate charts for each one side-by-side.)

2. Tally Your Data

Add up the observations in each of your categories.

3. Label your horizontal and vertical axes.

Make the widths of all your horizontal bars the same and label the categories in order from largest to smallest. On the vertical axis, use round numbers that slightly exceed your top category count, and include your measurement unit.

4. Draw your category bars.

Using your vertical axis, draw bars for each category that correspond to their respective counts. Keep the width of each bar the same.

5. Add cumulative counts and lines.

As a final step, you can list the cumulative counts along the horizontal axis and make a cumulative line over the top of your bars. Each category’s cumulative count is the count for that category PLUS the total count of the preceding categories. If you want to add a line, draw a right axis and label it from 0 to 100%, lined up with the with the grand total on the left axis. Above the right edge of each category, mark a point at the cumulative total, then connect the points.

Use a Pareto Chart Early in Your Quality Improvement Process

At the leadership or management level, Pareto charts can be used at the start of a new round of quality improvement to figure out what business problems are responsible for the most complaints or losses, and dedicate improvement resources to those. Collecting and examining data like that can often result in surprises and upend an organization’s “conventional wisdom.” For example, leaders at one company believed that the majority of customer complaints involved product defects. But when they saw the complaint data in a Pareto chart, it showed that many more people complained about shipping delays. Perhaps the impression that defects caused the most complaints arose because the relatively few people who received defective products tended to complain very loudly — but since more customers were affected by shipping delays, the company’s energy was better devoted to solving that problem.

Use a Pareto Chart Later in Your Quality Improvement Process

Once a project has been identified, and a team assembled to improve the problem, a Pareto chart can help the team select the appropriate areas to focus on. This is important because most business problems are big and multifaceted. For instance, shipping delays may occur for a wide variety of reasons, from mechanical breakdowns and accidents to data-entry mistakes and supplier issues. If there are many possible causes a team could focus on, it’s smart to collect data about which categories account for the biggest number of incidents. That way, the team can choose a direction based on the numbers and not the team’s “gut feeling.”

Use a Pareto Chart to Build Consensus

Pareto charts also can be very helpful in resolving conflicts, particularly if a project involves many moving parts or crosses over many different units or work functions. Team members may have sharp disagreements about how to proceed, either because they wish to defend their own departments or because they honestly believe they know where the problem lies. For example, a hospital project improvement team was stymied in reducing operating room delays because the anesthesiologists blamed the surgeons, while the surgeons blamed the anesthesiologists. When the project team collected data and displayed it in a Pareto chart, it turned out that neither group accounted for a large proportion of the delays, and the team was able to stop finger-pointing. Even if the chart had indicated that one group or the other was involved in a significantly greater proportion of incidents, helping the team members see which types of delays were most ‘vital’ could be used to build consensus.

Use Pareto Charts Outside of Quality Improvement Projects

Their simplicity also makes Pareto charts a valuable tool for making decisions beyond the world of quality improvement. By helping you visualize the relative importance of various categories, you can use them to prioritize customer needs, opportunities for training or investment — even your choices for lunch.

Functional Flowcharts

What are cross functional flowcharts?

Flowcharts are widely popular and one of the most frequently diagram types. They are great for mapping the flow of steps, decisions that need to be made etc. in a process.

However flowcharts have just more than the process names, their flow and type of action embedded. Things like owners, stages, timelines need addition of more data to the flow and cross functional flowcharts are a solution to this problem.

When you have a process that requires the involvement of multiple people, teams or departments it can get difficult to illustrate this in a normal flowchart. Cross functional flowcharts sometimes referred as swim lanes can simply illustrate the owners of each step in the flowchart by organizing them into columns or rows.

The simple layout makes it easy to understand additional attributes about each step without much hassle while being able to comprehend the flowchart at a glance.

Multiple types of cross functional flowcharts

While the name implies these flowcharts are meant to be used to demarcate process flows that go between multiple functional departments, they are far more widely applicable. Any other dimension of information can be added via the cross functional layout.

Deployment flowcharts

Historically Deployment Flowcharts were used to group process flows sequentially. Typically used in things like documenting manufacturing processes such as assembly of vehicles. By grouping the processes it makes it easier to understand who and what is responsible for each step of the flow as well as how balanced the workflow is.

You can also use these charts to see how the stakeholders interact with each other as well as spot waste and unnecessary delays and repetitive tasks.

These can be scaled down to individuals that work on a process or different roles in a process.

Opportunity flowcharts

Another common type of flowchart is the opportunity flowchart that can be used to clearly see where value is being added in the process. While value-add is subjective, it’s important that you understand from which perspective you are analyzing the process.

You’d break down the processes into two simple columns and identify if the step is value adding or not. Once you have this, you may be able to cut out non-value adding processes and further optimize your flow of work in your process.

Cross functional flowchart layouts

Each column in such a diagram is called a Swim Lane. And the entire container is called a Pool. A very familiar analogy!

The swim lanes can be laid out horizontally or vertically depending on the type of process and the length of the flow. There is no real format or technical requirement for this choice, it’s a simple matter of making sure if the chart easier to understand if it’s laid out horizontally or vertically.

Tools to draw Cross Functional Flowcharts

There are a few products that you can draw flowcharts with yet not every product supports easy drawing of Cross Functional Flowcharts or swim lanes.

You could of course use Microsoft Word drawings to get a very basic flowchart out but that quickly gets tiresome with manual controls of everything from the boxes to connecting lines.

Having pre-made templates and shapes would greatly ease creation of cross functional flowcharts. Our online flowchart software is an easy choice in looking for such products as it comes with pre-made cross functional flowchart templates as well as a comprehensive set of cross functional flowchart shapes.

What is the difference between Deployment flowcharts & cross-functional flowcharts?

As far as I have seen, there is no significant difference between both. Actually, deployment flowcharts and cross-functional flow-charts seem to be two synonyms for the same concept, otherwise referenced in one paper as a “Process Map”. Diagrammatically, Deployment charts seem to me more like UML Activity diagrams with Swim lanes (if you’re familiar with UML you’ll immediately understand what I mean). In other words, deployment diagrams are flowcharts that focus on showing “who does which activity”. I’ve came across a definition that says “A Deployment Flowchart shows the actual process flow and identifies the people or groups involved at each step.

This type of chart shows where the people or groups fit into the process sequence, and how they relate to one another throughout the process.” I also came across a paper that identifies both as being the same: “The process map-otherwise known as a cross-functional flowchart or deployment chart-is an excellent tool for clearly displaying process flows across organizational boundaries and identifying delays, repetitive steps, excessive control points, specialized tasks, and potential points of process failure.” So, I believe it is plausible to assert that cross-functional charts and deployment charts both refer to the same concept.

Cross functional: display the workflow and the functional positions which are involved with each step in the workflow.

Cross Functional Flowchart: The Tools

Most people associate process mapping with basic flowcharting. However, we actually use six different process mapping tools to help companies improve processes:

• Top-down flowchart
• Block diagram (decision tree or logic diagram)
• Flow process chart
• Work flow diagram
• Process map
• State change chart

Each has its own strength and weakness. The flow process chart, for example, helps you identify waste and capture processing time but does not clearly display cross-functional activities. For brevity’s sake, we will focus on the process map.

The process map — otherwise known as a cross-functional flowchart or deployment chart — is an excellent tool for clearly displaying process flows across organizational boundaries and identifying delays, repetitive steps, excessive control points, specialized tasks, and potential points of process failure.

Building a process map is easy but the results may appear complex if many steps and players are involved. Begin by listing all process players (people or departments) down the left side of a sheet of paper. Separate each player with a horizontal line. Use a double line if the player is from outside of your organization. The bottom access is time, moving left to right.

Write the first process step next to the name of the player who performs that task. If you’d like, you may draw a box around this description. Move from left to right as time elapses. Write and box the second process step on the appropriate row. Connect the two steps with a line. Continue to the right documenting each activity on the appropriate row. Any concurrent activities should be aligned vertically. When you are done, the “as is” process will be clearly documented. It can then be analyzed and improved.

Analyzing Cross Functional Flowchart

A process can be an enlightening yet shocking experience. Processes typically evolve over time as people and business conditions change. The result is unneeded layers of complexity and inspection. Your first reaction may be, “Is that really what we do?”

Your second reaction will be to fix the process. Here’s a list of what you should look for: Non-value added steps. Challenge each process step. Ask yourself, “What value does this activity add? Does our customer care?” Combine, simplify or eliminate activities that do not contribute value.
Excessive control points. Inspections and supervisor approvals do not always add value. They evolve primarily due to a lack of confidence in the process. Eliminate control steps that are not critical for quality outcomes.

Excessive handoffs. Every time process activities move from one player to the next, there is potential for delay or miscommunication. Try to organize work so that each player becomes more of a generalist and less of a specialist. This will reduce the complexity of multiple handoffs.

Task specialization. Assembly line processing is giving way to cellular models for organizing work groups or teams, both on the plant floor and administrative offices. Information flows faster, with less distortion, improving both the quality and speed of work. Consolidate tasks where possible.

Run charts

Run charts (often known as line graphs outside the quality management field) display process performance over time. Upward and downward trends, cycles, and large aberrations may be spotted and investigated further. In a run chart, events, shown on the y axis, are graphed against a time period on the x axis. For example, a run chart in a hospital might plot the number of patient transfer delays against the time of day or day of the week. The results might show that there are more delays at noon than at 3 p.m. Investigating this phenomenon could unearth potential for improvement. Run charts can also be used to track improvements that have been put into place, checking to determine their success. Also, an average line can be added to a run chart to clarify movement of the data away from the average.

Alternatives with run charts:

1. An average line, representing the average of all the y values recorded, can easily be added to a run chart to clarify movement of the data away from the average. An average line runs parallel to the x axis.
2. Several variables may be tracked on a single chart, with each variable having its own line. The chart is then called a multiple run chart.
3. Run charts can also be used to track improvements that have been put into place, checking their success.

Questions to ask about a run chart:

1. Is the average line where it should be to meet customer requirements?
2. Is there a significant trend or pattern that should be investigated?

Two ways to misinterpret run charts:

1. You conclude that some trend or cycle exists, when in fact you are just seeing normal process variation (and every process will show some variation).
2. You do not recognize a trend or cycle when it does exist.

Both of these mistakes are common, but people are generally less aware that they are making the first type, and are tampering with a process which is really behaving normally. To avoid mistakes, use the following rules of thumb for run chart interpretation:

1. Look at data for a long enough period of time, so that a “usual” range of variation is evident.
2. Is the recent data within the usual range of variation?
3. Is there a daily pattern? Weekly? Monthly? Yearly?

Using run charts to detect “special causes” of variation:

If you have 25 points or more in your data series, you can use run charts to detect special causes — something beyond the usual variability of the process -acting on the process.

1. Shifts: If you see eight or more consecutive points on one side of the center line, that indicates that a special cause has influenced the process. Points on the center line don’t count; they neither break the string, nor add to it.
2. Trends: Six consecutive jumps in the same direction indicate that a special cause is acting on the process to cause a trend. Flat line segments don’t count, either to break a trend, or to count towards it.
3. Pattern: If you see a pattern that recurs eight or more times in a row, it is a good idea to look for a special cause.

For more robust monitoring of a process, and better information about when your process is showing variation beyond what is expected, try using a control chart. It will detect special causes more quickly, and with more accuracy.

Run chart statistics:

For each line in the run chart, the following statistics are calculated:

Mean

The average of all the data points in the series.

Maximum

The maximum value in the series.

Minimum

The minimum value in the series.

Sample Size

The number of values in the series.

Range

The maximum value minus the minimum value.

Standard Deviation

Indicates how widely data is spread around the mean

Pitfalls to Avoid

The most common ways to misinterpret run charts are 1) to conclude that some trend or cycle exists, when in fact what is being seen is normal process variation (every process will show some variation), or 2) not to recognize a trend or cycle when it does exist. People are generally less aware that they are making the first type of error; they are tampering with a process that is behaving normally.3 In order to avoid mistakes, use the following guidelines for successful run chart interpretation:

1. Look at data representing a long enough period of time so that a “usual” range of variation is experienced. (This requires some process knowledge.)

2. Is the recent data within the usual range of variation?

3. Is there a cyclical pattern? Weekly? Monthly? Yearly?

4. Draw a best-fit trend line from the beginning to the end of the data on the run chart. If the line is approximately horizontal, then the mean of the process can be considered stationary over this time interval. If not, then the process mean is considered no stationary, or unstable. Drawing this inference requires sufficient data, usually 50 or more observations (i.e., two points are not sufficient).

SIX SIGMA

Six Sigma is an approach to data-driven management that seeks to improve quality by measuring how many defects there are in a process and systematically eliminating them until there are as close to zero defects as possible. In 1984, a Motorola engineer named Bill Smith developed the Six Sigma management system to reduce the variations in Motorola’s electronic manufacturing processes that were causing product defects. Since then, the strategies, tools and cultural norms that support the management system have been adopted by companies in a wide variety of industries and the meaning of the word “defect” has broadened to include any deficiency that prevents a company from meeting its customer’s needs.

Differing opinions on the definition of Six Sigma:

Philosophy — The philosophical perspective views all work as processes that can be defined, measured, analyzed, improved and controlled. Processes require inputs (x) and produce outputs (y). If you control the inputs, you will control the outputs. This is generally expressed as y = f(x).

Set of tools — The Six Sigma expert uses qualitative and quantitative techniques to drive process improvement. A few such tools include statistical process control (SPC), control charts, failure mode and effects analysis, and process mapping. Six Sigma professionals do not totally agree as to exactly which tools constitute the set.

Methodology — this view of Six Sigma recognizes the underlying and rigorous approach known as DMAIC (define, measure, analyze, improve and control). DMAIC defines the steps a Six Sigma practitioner is expected to follow, starting with identifying the problem and ending with the implementation of long-lasting solutions. While DMAIC is not the only Six Sigma methodology in use, it is certainly the most widely adopted and recognized.

Metrics — In simple terms, Six Sigma quality performance means 3.4 defects per million opportunities (accounting for a 1.5-sigma shift in the mean).

What is lean Six Sigma?

Lean Six Sigma is a fact-based, data-driven philosophy of improvement that values defect prevention over defect detection. It drives customer satisfaction and bottom-line results by reducing variation, waste, and cycle time, while promoting the use of work standardization and flow, thereby creating a competitive advantage. It applies anywhere variation and waste exist, and every employee should be involved.

The demarcation between Six Sigma and lean has blurred. We are hearing about terms such as “lean Six Sigma” with greater frequency because process improvement requires aspects of both approaches to attain positive results.

Six Sigma focuses on reducing process variation and enhancing process control, whereas lean drives out waste (non-value-added) and promotes work standardization and flow. Six Sigma practitioners should be well versed in both.

Integrating lean and Six Sigma

Lean and Six Sigma have the same general purpose of providing the customer with the best possible quality, cost, delivery, and a newer attribute, nimbleness. There is a great deal of overlap, and disciples of both disagree as to which techniques belong where.

The two initiatives approach their common purpose from slightly different angles:

• Lean focuses on waste reduction, whereas Six Sigma emphasizes variation reduction

• Lean achieves its goals by using less technical tools such as kaizen, workplace organization, and visual controls, whereas Six Sigma tends to use statistical data analysis, design of experiments, and hypothesis tests

The most successful users of implementations have begun with the lean approach, making the workplace as efficient and effective as possible, reducing waste, and using value stream maps to improve understanding and throughput.

When process problems remain, the more technical Six Sigma statistical tools may be applied. One thing they have in common is that both require strong management support to make them the standard way of doing business.

Some organizations have responded to this dichotomy of approaches by forming a lean-Six Sigma problem-solving team with specialists in the various aspects of each discipline but with each member cognizant of others’ fields. Task forces from this team are formed and reshaped depending on the problem at hand.

There are two very important methodologies for executing a Six Sigma initiative: Six Sigma DMAIC and Six Sigma DMADV. Each term’s name is derived from the major steps in its process, but each has its own use. DMAIC (define, measure, analyze, improve, control) is used to correct a process that already exists. DMADV (define, measure, analyze, design, validate) is used to create a new process.

Six Sigma DMAIC

Here is a step-by-step breakdown of Six Sigma DMAIC:

1. Define: Identify the project goals and all customer deliverables.

2. Measure: Understand current performance.

3. Analyse: Determine root causes of any defects.

4. Improve: Establish ways to eliminate defects and correct the process.

5. Control: Manage future process performance.

Six Sigma DMADV

Here is a step-by-step breakdown of Sigma DMADV. The first three steps of this methodology are identical to DMAIC. Because the two acronyms are so similar, some companies use the acronym DFSS (Design for Six Sigma) in place of DMADV.

1. Measure: Understand current performance.

2. Analyse: Determine root causes of any defects.

3. Design: Create a process that meets customer needs and expectations.

4. Verify: Ensure process designed meets customer needs and performs adequately.

When contemplating Six Sigma DMAIC versus DMADV, it is important to understand the circumstances in which each should be used. The DMAIC methodology should be used when an existing product or service is not meeting customer needs or performing to its highest standards. The DMADV methodology should be used when an organization is developing a new product or service, or when using DMAIC for a current project or process fails.