Yesterday I read a research application that contained no research methods at all.
Well, that’s not exactly true.
In an eight-page project description, there were exactly three sentences that described the methods. Let’s say it went something like this:
- There was to be some fieldwork (to unspecified locations),
- Which would be analysed in workshops (for unspecified people), and
- There would be analysis with a machine (for unspecified reasons).
In essence, that was the methods section.
As you might imagine, this led to a difficult (but very productive) discussion with the project leader about what they really planned to do. They knew what they wanted to do, and that conversation teased this out. I thought that I might replicate some of that discussion here, as it might be useful for other people, too.
I’ve noticed that most researchers find it easy to write about the background to their project, but it’s much more difficult to have them describe their methods in any detail.
In part, this is a product of how we write journal articles. Journal articles describe, in some detail, what happened in the past. They look backwards. Research applications, in contrast, look forwards. They describe what we plan to do. It is much harder to think about the future, in detail, than it is to remember what happened in the carefully documented past.
As a result, I often write on draft applications ‘less background, more methods’. Underlying that statement is an assumption that everybody knows how to write a good methods section. Given that people often fail, that is clearly a false assumption.
So, here is a relatively simple way to work out what should go into your methods section.
Write what you know
First, write down what you know you want to do. Write it as a list. It might look something like this:
- Fieldwork in KL, Singapore, and Jakarta.
- Workshop to analyse data from each location.
- Run simulations on a Thingatron to see if we can replicate results.
For your methods section, it’s a good start, but you need to be much more detailed than that. Given that this is all you know about the project at this stage, you might need some help.
Phone a friend
Give your list to a colleague or your friendly neighbourhood research whisperer. Buy them a coffee and tell them what you plan to do. Ask them to make a quick note of anything that isn’t on the list. It doesn’t need to be detailed – they should try not to break your conversational flow. You just need enough to jog your memory when you review it later.
If they are smart, they might ask you a few helpful questions that will help you to focus on your plan. Either way, you’ll probably find that you can provide more information when you are talking about the project than when you write about the project. Partly, this is because we are social creatures. Partly, it is because we pick up on tiny cues when people are confused, and we add detail to help them to understand. However it works, I find it helps to talk about the project, and capture what is said.
Revise your list to add the extra information from the conversation. You should, by now, have a relatively detailed list describing what you want to do.
- Fieldwork in KL, Singapore, and Jakarta: 10 interviews in each location, working with partners to locate interview subjects. Need to recompense interviewees. Interview questions will be highly structured.
- Workshop to analyse data from each location: All investigators plus two invited experts, in Melbourne – one day each.
- Run simulations on a Thingatron to see if we can replicate the fieldwork results – three trials a month for a year.
Work out your timeline and your budget
Your list should be detailed enough now that you can work out a rough timeline and budget for your project.
Working up a Gantt chart for your project will force you to think about how long different phases of the project will take. This is important because it gets you to the level of specificity that you need for a detailed methods section. It isn’t enough to say that you are going to do fieldwork, you need to say precisely where and how long you will be in the field for. An assessor needs to know if you are going to be in the field for a week or for three months before they can judge whether you will collect the data you need to answer your research question.
Similarly, working out a budget for your workshops will force you to be specific about how many people will be attending (venue size), how long they will be there for (catering) and where they will be coming from (travel costs).
By now, you should have a very detailed project plan. That’s good, but it’s only part of your methods section.
On data, and the analysis of data
Now you need to be equally specific about the data that you will collect at each step, and why.
Each activity should gather data, analyse data, write up your results, or disseminate them. You need to know exactly what data you are gathering before you can do any of the other things. So, think hard about which activities will gather data, and what data will come out of each activity.
- Interviews: 30 transcripts of 60 minutes each, coded using NVivo. Themes might include puppy dogs, rainbows, and world peace.
- Thingatron: 36 trials producing 4 Gbytes of statistics each, analysed to produce Hadamard matrices. Looking for maximum determinants and outliers.
Now, describe in detail how you will analyse the data. If your data is relatively homogenous, then this bit may be straightforward. If, on the other hand, you have different types of data, you’ll need to demonstrate both how you will analyse the data and how you will link the different analyses together.
For example, if you have survey data and interview data, how will you make sure that the interview data correlates with the survey data? How will you identify and deal with anomalies and contradictions? Here’s one way to do it:
- Interviews: Three workshops of four investigators plus two external experts on the city being examined. Reviewing data for regional conformity, as well as possible links to new international work.
- Thingatron: as above.
- Combining the data: The Thingatron data will be used to create simulations of interview answers for the three target cities. If the themes of the interview answers conform to actual themes, then success. Otherwise, try again.
Now tell us why
Up until now, the whole exercise has been relatively value-free. That is, it has been pretty direct and dry.
Time to spice it up a bit. Go back to the start and tell us why you have made every single decision. Tell us why in a very special way – tell us how each item on your list will help you answer your research question and achieve your research aims.
Why do you need to do fieldwork? Why these locations? Why this data? How does this align with your aim? Which aim? Why have you chosen to analyse your data in that way? How will that help you to answer your question?
If there isn’t a convincing reason why you are doing something, think about three different things:
- Are you looking closely enough? If your reasons are muddy, it might be because you haven’t gone deep enough, and you still need to separate things out a bit.
- Are you looking too closely? If you group a few things together, does the ‘why’ question make more sense?
- Do you have the wrong data or the wrong method? Or, maybe, it doesn’t matter – if so, why are you doing it at all?
By the end, you should be able to:
- say exactly why you are doing everything that you are planning to do.
- explain how each element will bring you closer to answering your questions and achieving your aims.
- write a clear rationale describing why this analysis of this data will achieve the objective of the project.
Aren’t you a clever clogs?
Finally, tell us why your methods are cleverer than anyone else who has tried to answer this question. There are very few completely new questions – someone will have had a crack at this issue, or something related, before. You will probably have talked about them when you described the background to your project. Why will you succeed where they have failed? What is clever about your method? What is different about what you have done, compared to what others have done before you?
This ingenuity might just be the thing that gets you funded. However, you can’t write about that in a convincing way if you don’t have a clear, detailed, and compelling description of what you want to do.
Without a clear, detailed, and compelling methods section, you’re unlikely to be in serious contention for competitive funding.
Also in the ‘simple grant’ series: