In my previous article we looked at the difference between business based and customer based thinking, investigated the true value of a customer and determined that it is not enough to just satisfy the customer. The next question is what we do about this in improvement projects.

At SigmaPro we use a four step process to collect and analyse customer data. These four steps are:

  • Identify
  • Collect
  • Analyse
  • Translate

You will note that they spell the acronym



Identify is to identify who the customer are. Customer can be internal or external, and there may be one customer or several customers with different needs.

Collect is to collect customer needs. This may be as straightforward as obtaining a copy of a service level agreement, or specification, or as complex as conducting a full range of surveys of different customers and there varying requirements.

Analyse is to examine the collected requirements and start to think about how they can be made relevant to the project, for example summarising survey results, both qualitatively and quantitatively. At this stage we should also be confirming whether our customers and their needs should be segmented, or divided into different groups. If this is the case then of course it will impact on the subsequent phases of our project.

Translate means to take our analysed requirements and turn them into meaningful data for our project, in the form of specifications and tolerances.

Each of the 4 phases above has tools which can be used, and the table below shows the phase, and tools.



SIPOC is an acronym for Supplier, Input, Process, Output, Customer, and is a high level scoping tool which is used to understand the process boundaries, suppliers and customers. It is not a process mapping tools, and does not require an understanding of how the process operates in detail to construct it. People often do make this mistake and confuse its construction with process mapping.


At this point of a project we are still in Define, and as such do not yet have a need for a detailed understanding of the process, so SIPOC is perfect for capturing and displaying that high level overview.

A SIPOC is constructed using the 5 steps listed below in the following order:

  1. Identify the process, its start and end points.
  2. Identify the process outputs
  3. Decide who the customers are for each of the outputs
  4. Identify the process inputs required for the process to operate
  5. Work out who the suppliers are for the process inputs

An example of SIPOC is shown below for making pasta in a restaurant.



There are basically 2 ways of obtaining data about customer needs, these are Leading and Lagging indicators. Lagging indicators are useful to give information about past customer behaviour, for example warranty or complaint data, the data usually already exists. Leading indicators give information about future customer behaviour or needs, for example customer surveys. Often this data does not already exist and needs to be collected proactively.

The cost of collecting lagging data is typically low as it already exists, but of course the business will most likely have already incurred costs due to having to correct warranty problems or put right complaints. The cost of collecting leading data is higher, but as it is forward looking there will most likely not be any cost already incurred.

It is important when considering data collection methods to bear in mind the total cost, which is a combination of the Cost of Quality (cost already incurred) and the data collection cost.

The chart below illustrates the total cost of data collection. The blue line shows the data collection costs, and the blue line shows failure costs. Lagging indicators have low collection costs, but incur high failure costs, whilst leading indicators have low failure costs but incur high collection costs. The total cost is the sum of the two elements.


Examples of lagging indicators include the following:

  • Existing customer surveys
  • Warranty information
  • Industry publications and articles
  • Research reports
  • Market forecasts
  • Strategic planning documents
  • Specifications and Service Level Agreements (SLA’s)

Specifications and Service Level Agreements are very useful sources of data about customer requirements, and of course should not be overlooked. In many cases capturing the customer requirements is no more complex than obtaining the specification! However, just because there is a specification does not mean it fully captures the requirements, or that it is accurate. It is always worth asking questions of the customer about the validity and accuracy of the specification.

Leading indicators include the following:

  • Interviews
  • Focus Groups
  • Surveys
  • Market Research

An interview is a formal methodology for collecting customer needs using phone or face to face methods. An interview would usually be used to learn about a particular customer segment, and is an opportunity to find out a lot of qualitative data about customer needs. It is a useful method to get in-depth information from customers where there is no real understanding of their needs.

A focus group brings together a small group of customers to uncover general needs. It is used to capture a collective point of view from several customers at the same time, exploring the needs and concerns of specific customer segments.

Focus groups are reflection oriented, and designed to understand factors influencing needs, wants and delighters. They are often used as a follow up to interviews, or as an introductory step before a big survey effort.

Surveys are a research method to understand customer wants and perceptions using a large sample to gather valid, reliable and useful information that can help to provide quantitative data on customer wants, needs & opinions. They are most often carried out on a scale large enough to draw statistically valid information. They can also be used to benchmark a position, and the survey can be repeated at agreed intervals to track progress over time.

Market research is a general heading for any organized effort to gather information about target markets or customers. Market research provides important information to identify and analyse the market need, market size and competition. Any of the above techniques may be used in market research, but it is also possible to commission market research from an independent agency, who will then systematically gather information for the organisation to gain insight into customers and markets.

Bias in Surveys

Bias in a survey occurs whenever respondents are led away from an accurate or truthful response. This is potentially a problem in structured interviews or surveys. Bias can have a large impact on the validity of the questionnaire or survey results.

Bias can be caused by a number of factors, all relating to the idea that humans do not respond passively to stimuli, but actively integrate multiple sources of information to generate a response in a given situation. Because of this, almost any aspect of a survey may cause bias. For example, the way questions are phrased in surveys, the attitude of the researcher, the way the experiment is conducted, or the desires of the participant to provide socially desirable responses may all bias the response given in some way.

It is therefore important for researchers to be aware of response bias and the effect it can have on their research so that they can attempt to prevent it from impacting their findings.


Data is likely to be collected in quantitative (from questionnaires) or qualitative (from interviews) form and both need to be analysed. Quantitative data is best analysed using simple statistical analysis tools such as mean, median, maximum, minimum, standard deviation etc. The results can be shown graphically.

Qualitative data, typically produced from survey interviews and focus groups may produce a large number of statements of customer requirements, but these will be unclear (fuzzy) or poorly defined. The statements will often also have different levels of consistency and be worded differently from different respondents.

An example might be that one respondent states “I want excellent delivery service” whilst another states “I want my product on time within 2 days of order placement”. Both statements relate to delivery performance.

A method to help with this kind of analysis is the Affinity Diagram. Affinity diagrams organize and group customer needs, and are best constructed using a team approach.

To create an Affinity diagram start by collecting all the customer needs, wants & opinions and have each need recorded on an adhesive note on a large surface, for example a white board or table. The team working together then arranges the customer needs into several logical groups (products, delivery, markets, user types, etc.)


For each of the groups in turn, the team works toward a list of clearly defined customer needs by arranging the highest level needs at the top, and aligning lower level needs underneath, so the more specific statements are at the bottom.

An example might be that “excellent delivery service” would be at the top, and “deliver on time within 2 days” would be underneath. “Great quality product” would be in a different group as it does not relate to delivery service.

More complex needs can be split into two or more sub groups. Similar concepts are grouped together and any duplicates can be removed. Balancing of requirements at lower level is best done separately, either by a sub-team or by one person. Take time to edit results offline if there’s likely to be disagreement.

Once the offline editing has been done, the team can then work together again to finalise.

Loop through “sub-team creates – whole team edits” process until you have full team consensus that requirements groups are roughly equal in importance and the levels are all clearly defined.

One the data has been collected and analysed, it can be added to the original SIPOC chart, to extend it to include clear statements of requirements for each process output. These can be grouped as per the affinity, or an alternative framework used of quality, cost (or price) and delivery if no affinity diagram has been created. Requirements can be listed for both customers and suppliers.

If there are a number of different customer groups with differing requirements, they may need to be segmented. This in turn may impact on subsequent process design, the process may need to cope with these differing needs, or indeed different processes may be required for different customer groups.


The final analysis stage is to translate the requirements into meaningful data for the project. There are 2 useful methods, CTS trees and Kano analysis. Kano analysis will be described in a separate article.

Even after surveying, customers’ needs are often expressed in broad terms often using subjective statements such as “I want good service”. These loose statements are not sufficient to specifically define the customers need for the project.

The Critical to Success (CTS) tree is a tool that provides a way to break subjective statements into something more meaningful to a point where specific and measurable attributes can be defined.

There are three phases in creating a CTS tree:

  1. Starting with the statement of requirement from the customer, define what that means in business terms, or what is critical for the business to do to meet the customer requirement. For example, “I want great service” may be translated into business terms as “it is critical we deliver when we promised”.
  2. Once this CTS has been defined, then the second stage is to identify the process characteristic that influences it. An example would be that Delivery on Time is the process characteristic that influences delivery when promised.
  3. Once the process characteristic has been identified, then a suitable measure should be defined, with a nominal value and tolerance. An example would be that delivery on time can be measured as the time from receipt of order to order fulfilment, with a nominal value of 3 days, and a tolerance of plus zero, and minus ½ day (in other words up to half a day early is OK, but nothing later than promised).



Capturing Customer Requirements and turning it into meaningful data is an important part of any project, and should not be neglected.

Of course, in some cases capturing requirements is simply a question of obtaining the specification and verifying that it is accurate; if at all possible keep it simple! If not It can appear a daunting task, but by following the 4 steps of ICAT, and using appropriate tools, it can be made a logical and straightforward process.

Those projects where time is not spent capturing customer requirements will most likely suffer in later stages when solutions are proposed to problems that do not exist, or solutions are not proposed to problems that do exist!

Original Post