How to Collect Data for a Research Project (Without Wasting Weeks)

I keep a folder of data collection disasters from past students, names removed, and I show one of them to every new research methods group. It is a spreadsheet with 340 rows. A student spent three weeks gathering survey responses about “study habits,” sat down to write, and discovered that none of her twelve questions could answer her thesis question, which was about whether part time work hurt grades. She had asked how many hours people studied. She had never asked whether they worked. Three weeks, gone.

Almost every data collection failure I have seen has the same root: the student started collecting before knowing exactly what the data had to prove. What follows is the process I teach to prevent that, from method to records to consent, with one small project followed all the way through.

Write the question first, then pick a method to fit it

Your research question is a contract. Every piece of data either helps fulfil it or becomes noise you will have to explain away later. So before you open a survey tool or email a single interviewee, write the question in one sentence, then a second sentence that begins “To answer this I would need to know…”

That second sentence is the whole game. If your question is “Does part time work lower GPA among first year students,” the second sentence must contain, at minimum, employment status, hours worked, and GPA, all for the same people. If you cannot finish the sentence, the question is not ready, and you should go back to narrowing the topic before you touch any data.

I also ask students to decide, at this stage, whether they could still write the paper if the result disappointed them. If the honest answer is “no, I need the hypothesis to be true,” you are doing advocacy rather than research, and your method choices will quietly bend that way. A good question survives a null result.

Primary or secondary, qualitative or quantitative

These two axes are usually taught as definitions to memorise. I would rather you treat them as decisions about cost. Primary data, which you gather yourself, is expensive in time and gives you exactly what you asked for. Secondary data, gathered by someone else for their own purpose, is cheap and fast and never quite fits. Quantitative data counts things and lets you compare and test. Qualitative data describes things and lets you explain why.

Here is the rough fit I draw on the board:

Your question sounds like	Lean toward	Why
”How many,” “how often,” “is there a difference between”	Quantitative, secondary first	Counts and comparisons need numbers and enough cases
”Why do people,” “what is it like to”	Qualitative, primary	You need people’s own words and reasoning
”How does this specific group experience Y”	Primary, qualitative or mixed	The group is too specific for existing datasets
”Does intervention A produce outcome B”	Primary, quantitative, with a comparison group	You need to control what happened to whom

The step most students skip is checking whether secondary data already exists. Government statistics offices, open data portals, and the supplementary files attached to published papers hold a great deal of material nobody has asked your particular question of. Two hours searching for a dataset can save four weeks of gathering your own, and even if you still collect primary data, the existing numbers give you a benchmark.

Mixed methods, a modest survey plus a few interviews, is often right for undergraduate work. The numbers show the pattern; the interviews explain it. Just say plainly in the write up that the interviews are illustrative rather than representative.

Plan a sample you can actually reach

A sample is the slice of the world you will look at. The two questions that matter are who is in it and how they got there.

Who belongs in it follows from your question. If the question is about first year students, the sample is first year students, not “whoever clicked the link I posted.” Write your inclusion criteria down before you recruit. Every year I read papers where the sample description says “university students” and half the respondents graduated years ago.

How they got there is about selection. Truly random sampling, where every member of the population has an equal chance of being chosen, is the ideal and almost never available to a student. What you can do is be deliberate about convenience sampling instead of pretending you avoided it. Recruit across several sections, times of day, and channels, and record where each response came from so you can check later whether the Tuesday morning group differs from the Friday evening group.

On size, I give a rule of thumb rather than a formula. For an interview project, eight to fifteen conversations is usually where you stop hearing new themes. For a survey comparing two groups, you want dozens of people in the smaller group, not single digits, so a handful of odd answers cannot swing the result. If you intend to run a formal statistical test, use a sample size calculator for that test before recruiting, not after.

Build in attrition. A third of agreed interviews will cancel and a quarter of survey starts will be abandoned halfway. Recruit accordingly.

Build the instrument, then try to break it

The instrument is whatever sits between you and the data: questionnaire, interview guide, observation sheet. Each fails in its own way.

Surveys fail through ambiguity and through leading. “Do you often study late?” contains two undefined words. Replace “often” with a frequency scale and “late” with a clock time. Never ask two things in one question (“Do you find the library quiet and well lit?”). Put demographic questions at the end, where fatigue does less damage, and keep the whole thing under ten minutes.

Interviews fail through the interviewer talking too much. Your guide should hold eight to twelve open questions with a few planned probes (“Can you give me an example?”). Your job is to ask, wait, and ask again. Record with permission, take brief notes anyway because recordings fail, and transcribe within a day while tone and context are fresh.

Observation fails through vague categories. If you are watching how students use a study space, decide in advance what counts as “working,” “socialising,” and “on phone,” write the definitions down, and observe in fixed intervals. Two observers coding the same ten minutes independently, then comparing, quickly shows whether your categories hold.

Whatever you build, pilot it. Give the survey to five people outside your sample and watch them take it. Run one interview with a friend and listen back to how often you interrupted. Every pilot I have supervised changed the instrument. Students who skip it find the problem in the real data, where it cannot be fixed.

Records that survive a bad week

Clean records are not a personality trait. They are habits you decide on before the first response arrives.

Give every participant or record an ID the moment it is created and use it everywhere: consent form, recording, transcript, spreadsheet row. Keep the key linking IDs to real names in a separate, password protected file, and nowhere else.

Keep a raw data file that you never edit. Copy it and work on the copy. When you recode a variable, drop a row, or fix a typo, write what you did and why in a running log with the date. This log becomes your methods section, and it rescues you when, in week twelve, you cannot remember why participant 14 is missing.

Name files so they sort. 2026-03-04_interview_P07_audio.m4a tells you everything; recording (3).m4a tells you nothing. Back up to two places, one off your laptop, every time you add data.

Finally, keep a codebook: one document listing every variable, what it measures, what its values mean, and how missing data is marked. It takes twenty minutes to write and is the document I most wish students would hand in with the paper.

Consent, anonymity, and the review board

If your data comes from people, you owe them three things: they know what they are agreeing to, they can stop at any time without penalty, and their information is protected as you promised.

Most institutions require some form of ethics review before you collect data from human participants, even for coursework, and the committee’s expectations are usually published on its website. Read them early. Approval typically takes weeks, and I have watched projects die because the student emailed the committee the week before recruitment. If you are unsure whether yours needs review, ask your instructor in the first fortnight. The answer is usually “yes, but there is a lighter track for minimal risk student projects.”

Consent should be informed and documented. A short form stating who you are, what the study involves, how data will be stored and who will see it, and how to withdraw is enough for most low risk work. For an online survey, the first page can carry the consent text and an “I agree to take part” button. For interviews, a signature or a recorded verbal agreement at the start.

Be precise about what you promise. “Anonymous” means you never collect identifying information at all. “Confidential” means you collect it but protect it. Do not promise anonymity if you are recording voices, and do not promise to delete data your institution requires you to keep. Students regularly overpromise in the consent form and then find they cannot deliver.

Minors, vulnerable groups, sensitive topics such as health, sexuality, or illegal behaviour, and any form of deception all raise the bar substantially. If your project touches any of those, talk to your instructor before you design the instrument, not after.

A worked example: Maya’s part time work study

Let me walk one small project through all of this, because principles are clearer with something concrete. The student is a composite; the project’s shape is real.

Maya’s question: “Among first year students at my university, is there an association between weekly hours of paid work and self reported GPA, and how do working students describe the effect on their studying?”

Her “to answer this I would need” sentence: employment status, weekly paid hours, GPA, year of study, plus students’ own account of how work affects study. That meant a short survey for the numbers and a few interviews for the words. Secondary sources gave her national figures on student employment as a benchmark, but nothing linking hours to GPA at her institution. So primary data it was.

Her sample: first year students only, recruited through three course forums and two noticeboards, source recorded for each response. Target: 80 completed surveys, assuming a third abandoned, and 8 interviews drawn from respondents who ticked a box agreeing to be contacted.

Her survey had eleven questions. Hours worked as a number, not a range. GPA as a number with an “I prefer not to say” option. Year of study as a screening question at the top, so anyone outside first year was thanked and exited. She piloted it on four friends and discovered the hours question did not say whether unpaid internships counted. She fixed the wording.

Her interview guide had nine questions, opening with “Tell me about a typical week” and closing with “Is there anything about working and studying you wish the university understood?” She recorded on two devices after her phone died during the pilot.

Records: survey responses got IDs from the tool; interviewees became P01 through P08, contact details in one encrypted file. Raw export untouched; cleaned copy with a change log; codebook written the day the survey went live.

Ethics: she submitted to her department’s expedited review in week two, received approval in week five, and started collecting in week six. Her consent page said data would be confidential rather than anonymous, because she needed contact details for interview follow up.

She finished with 71 usable surveys and 7 interviews. The numbers showed a modest negative association between hours and GPA above roughly fifteen hours a week and nothing noticeable below it. The interviews explained the threshold: the problem was not total hours but shifts landing on the evenings before deadlines. That explanation, which no survey question would have surfaced, became the centre of her discussion section.

The mistakes that actually sink the paper

I have graded enough data driven papers to keep a short list of what goes wrong. Almost none of it is about statistics.

• Collecting first, asking later. The 340 row spreadsheet. The cure is the “to answer this I would need” sentence, written before recruitment.
• Sample drift. Criteria say one thing; respondents are another. Screen at the start of the instrument and report what you excluded.
• Leading questions. “How much has the new policy improved your experience?” cannot produce a negative answer. Have a sceptical friend hunt for the assumption inside every question.
• No pilot. The flaw will be found. Your only choice is whether you find it in five test responses or eighty real ones.
• Editing the raw file. Once the original is gone, neither you nor your reader can check your work.
• Promising what you cannot keep. Anonymity you cannot provide, deletion you are not permitted to carry out, a summary of results you never send.
• Overclaiming. Seventy one students at one university is a case study, not a national finding. Say what your data supports and stop there.

Data collection cannot be rushed at the end, because the end is when you discover what you failed to collect. Spend the first two weeks on the question and the instrument, pilot before you launch, and keep records as though someone will audit them. Then the data will actually answer the question you asked, which is the whole point of gathering it.