Information Technology Reference
In-Depth Information
Research Planning
Students commencing their first research project are accustomed to the patterns
of undergraduate study: attending lectures, completing assignments, revising for
exams. Activity is determined by a succession of deadlines that impose a great deal
of structure.
In contrast, a typical research project has just one deadline: completion. Admin-
istrative requirements may impose some additional milestones, such as submission
of a project outline or a progress report, but many students (and advisors) do not take
these milestones seriously. However, having a series of deadlines is critical to the
success of a project. The question then is, what should these deadlines be and how
should they be determined?
Some people appear to plan their projects directly in terms of the aspects of the
problem that attracted them in the first place. For example, they download some code
or implement something, then experiment, then write up. A common failing of this
approach to research is that each stage can take longer than anticipated, the time for
write-up is compressed, and the final report is poor. Yet the write-up is the only part
of the work that survives or is assessed. Arguably, an even more significant failing
is that the scientific validity of the outcomes can be compromised. It is a mistake,
for example, to implement a complete system rather than ask what code is needed to
explore the research questions.
A strong approach to the task of defining a project and setting milestones is to
explicitly consider what is needed at the end, then reason backwards. The final thing
required is the write-up in the form of a thesis, paper, or report; so you need to plan
in terms of the steps necessary to produce the write-up. As an example, consider
research that is expected to have a substantial experimental component; the write-up
is likely to involve a background review, explanations of previous and newalgorithms,
descriptions of experiments, and analysis of outcomes. Completion of each of these
elements is a milestone.
Continuing to reason backwards, the next step is to identify what form the exper-
iments will take. Chapter
14
concerns experiments and how they are reported, but
prior to designing experiments the researcher must consider how they are to be used.
What will the experiments show, assuming the hypothesis to be true? How will the
results be different if the hypothesis is false? That is, the experiments are an evalua-
tion of whether some hypothesised phenomenon is actually observed. Experiments
involve data, code, and some kind of platform. Running of experiments requires that
all three of these be obtained, and that skeptical questions be asked about them:
whether the data is realistic, for example.
Experiments may also involve users. Who will they be? Is ethics clearance
required? Computer scientists, accustomed to working with algorithms and proofs,
are often surprised by how wide-ranging their university ethics requirements can be.
Many research activities do not have an experimental component, and instead
concern principles, or fresh analysis of data, or qualitative interpretation of a case
study, or a comparative reflection, or any of a wide range of other kinds of work.
