6.4 Data Collection Techniques: Check Sheets, Checklists, Surveys & Interviews

Data Collection Techniques: Check Sheets, Checklists, Surveys & Interviews

Quick Answer: The CSSYB Body of Knowledge asks you to use four data collection techniques: surveys, interviews, check sheets, and checklists. A check sheet counts or locates events as they happen and feeds Pareto charts and histograms. A checklist confirms that required steps were done. Surveys collect structured answers from many people at low cost, while interviews collect detailed reasons from a few. Automated logs and sensors supplement these methods whenever the data already exists in a system. Independent CSSYB study guide by OpenExamPrep.

Why the Choice of Technique Matters

The data collection plan (Section 6.3) says what to measure, where, how often, and by whom. The technique is the "how": the form, question list, or device that turns observations into records. A poor technique can ruin a good plan. A tally sheet with vague categories produces counts nobody can analyze, and a survey with leading questions produces biased ratings. The BoK tests this topic at the Apply level, so expect scenario questions that ask which technique fits a situation.

A quick way to choose:

---

Check Sheets

A check sheet (one of Ishikawa's Seven Basic Quality Tools) is a visual, structured form designed for real-time manual data collection directly at the workplace. It enables operators to record defect occurrences, locations, and patterns systematically using simple tally marks without interrupting production workflow.

• Defect Location Check Sheet (Measles Chart): Displays a physical schematic, blueprint, or silhouette of the product (such as a vehicle body panel, surgical gown, or circuit board). Operators mark an "X" or dot at the exact physical location where a scratch, void, or tear occurs. Cluster patterns immediately highlight localized tooling wear or material handling damage.
• Defect Cause Check Sheet: Lists predefined defect categories along the vertical axis and operating shifts, days, or workstations along the horizontal axis, transforming raw tallies into an immediate precursor for Pareto analysis.

Building a Check Sheet in Five Steps

1. Agree on the question. For example: "Which invoice errors occur most often, and on which days?"
2. Define each category operationally so every collector records the same event the same way (Section 6.3). Include an "Other" column with space to describe unexpected errors.
3. Decide the time frame and stratification (by day, shift, machine, or clerk) so later analysis can separate the data.
4. Design a simple layout with categories down the side and time periods across the top, and record who collected the data and when.
5. Pilot the form for one shift, fix confusing categories, and then collect for the full period in the plan.

Worked example: An accounts payable team tallies invoice errors for one week:

Missing PO numbers account for 22 of 40 errors (55%), so a Pareto chart built from this sheet would point the team there first. The daily totals also show that Friday is the worst day, a clue to stratify by day during analysis.

---

Check Sheets vs. Checklists

The CSSYB BoK lists check sheets and checklists as separate techniques, and exam questions test the difference:

A check sheet produces data for analysis and feeds Pareto charts and histograms. A checklist is a memory aid and verification tool that prevents omissions, and the data it produces is usually yes/no compliance.

Designing an Effective Checklist

• Keep it short and limited to critical steps that people actually skip or forget.
• Write each item as a checkable action ("Torque wrench set to 25 N·m") rather than a vague reminder ("Check tools").
• List items in the order the work is done, and state who completes the list and when.
• Record completion (initials and date) so the checklist also produces yes/no compliance data the team can count.

---

Surveys and Interviews

When the data lives in people's experience rather than in a machine log, teams use surveys and interviews:

• Surveys gather structured answers from many respondents at a low cost per response. Use closed-ended questions (rating scales, multiple choice) when you need numbers you can summarize, and pilot the survey first to catch confusing wording. Watch for low response rates and nonresponse bias, because the people who reply may differ from those who do not.
• Interviews gather detailed answers from fewer people. They are slower and cost more per response, but the interviewer can ask follow-up questions and uncover the reasons behind a problem. Use a written interview guide so every interviewer asks the same core questions, and record answers consistently.
• Choosing between them: Interviews work well early, to discover what matters; a survey then measures how widespread each issue is. Both methods need an operational definition for every rating or category, just like measured data.

Writing Good Survey Questions

• Ask one thing per question. "Was the agent quick and helpful?" is double-barreled; split it into two questions.
• Avoid leading wording. "How satisfied were you with our excellent service?" pushes respondents toward a positive answer.
• Use balanced rating scales with the same number of positive and negative choices, and label the end points.
• Sample the right people. Survey a random or stratified sample of the customers who actually use the process, not only those who are easy to reach.
• Keep it short. Long surveys lower the response rate and increase nonresponse bias.

Interview Formats

• Structured interviews ask every person the same questions in the same order, so answers can be compared or counted.
• Semi-structured interviews use a core question list but let the interviewer follow up; they suit most Define and Measure work.
• Unstructured interviews are open conversations, useful at the very start of a project but hard to summarize.

Record answers the same way each time, and group them by theme (for example, with an affinity diagram) before drawing conclusions.

---

Automated Sensors and System Logs

Wherever possible, teams leverage automated programmable logic controllers (PLCs), barcoding scanners, and IoT temperature/pressure sensors. Automation eliminates manual transcription errors, keystroke typos, and intentional operator falsification. Before relying on a system log, confirm that its fields match the plan's operational definitions; a time stamp recorded when a record is saved may not match the event the team defined as the start of the process.