Starting Your Research (v2)

Research

This post is a revised and expanded version of an article I wrote in 2016. Having supervised many postgraduate and undergraduate research students—and repeating the same set of tips to each new student—I decided to document these guidelines in one place. While these tips are tailored primarily for my students, I trust they may be useful to others as well. Always check with your supervisor, as they may use a different approach when starting research.

Identifying a Research Problem

Identifying and understanding a research problem is arguably the hardest part of any research endeavour.

Rather than fabricating a hypothetical problem, look for real problems around you—a felt need to improve an unsatisfactory solution, increase efficiency or scalability, or design an alternative process that addresses the problem more effectively. Good places to look include:

  • Your home or neighbourhood
  • Your workplace or university
  • Social or volunteer organisations
  • Your daily commute
  • Industry practices you are familiar with

Conduct a brief online search on the problem and existing solutions. This initial scan will later expand into a structured literature survey. If people are discussing it, the problem is likely relevant. Do not be disheartened if solutions already exist—research often involves developing better, more efficient, or better‑justified solutions.

Example: From Observation to Research Problem

Observed problem Logistics managers lack real-time visibility across multi‑organisation supply chains.

Existing solutions Centralised dashboards provide visibility, but require full data sharing across parties.

Gap Organisations are unwilling to share commercially sensitive data—often a source of competitive advantage—due to limited trust and inadequate governance mechanisms.

Research problem How can real-time supply chain visibility be achieved without centralised data ownership or full disclosure of sensitive commercial information?

Why this is research The focus is not on building another dashboard, but on understanding how trust models, access control mechanisms, and decentralised architectures can enable commercially-sensitive data sharing, and where effective trade-offs between transparency, traceability, and commercial confidentiality lie.

Discuss potential problems with others. Encourage them to share the issues they observe, and ask for feedback on the problems you are considering. Others will often see dimensions you have overlooked. While this means many ideas will be discarded early, it enables you to fail fast and learn faster.

A well-defined research problem should be:

  • Relevant (there is a genuine need or gap)
  • Worth solving (there is value in addressing it)
  • Manageable (it fits your time, skills, and resources)

Research Gaps and Relevance

Justifying relevance often involves articulating a research gap—an area or question that has not been sufficiently explored, or where existing approaches fall short. A research gap does not mean:

  • “No one has worked on this”
  • “This has never been done before”

Instead, it often means:

  • Existing solutions make unrealistic assumptions
  • Important constraints are ignored
  • The context has changed (scale, regulation, and technology)
  • Evaluation is missing or weak

Ideally, addressing the gap should align naturally with industry or societal needs, rather than forcing research outputs onto an uninterested audience.

Managing Scope (Critical but Often Overlooked)

Many promising ideas fail—not because they are uninteresting, but because they are too large.

A good research problem is not the biggest problem you can imagine, but the smallest version you can study rigorously.

Always sanity‑check your problem against:

  • Available time (one semester vs multi‑year)
  • Availability of data or participants
  • Skills and infrastructure you already have
  • Evaluation feasibility

Reducing scope is a sign of research maturity, not weakness.

Research vs Engineering: Knowing the Difference

A common pitfall, especially for industry‑experienced students, is proposing engineering projects rather than research.

Engineering ProjectResearch
Build a systemAsk a question
Add featuresInvestigate trade‑offs
Deliver functionalityProduce insight or evidence
Success = working softwareSuccess = validated claims

Example: Engineering vs Research

❌ “Build a blockchain-based supply chain platform”

✅ “Evaluate how decentralised access control models affect data sharing incentives in supply chains”

Both may involve implementation, but only one is driven by a research question.

Resources

Conducting a Literature Survey

A literature survey serves to:

  • Understand what is already known
  • Refine your problem
  • Avoid rediscovering known results
  • Position your work clearly

Start light, then deepen:

  • Initial scoping: ~10–20 papers
  • Focused understanding: ~30–50 papers
  • Thesis-level work: continuous refinement and saturation

Key Papers vs Total Papers

“Key papers” are those that directly shape your research question, methodology, or evaluation approach.
They form the intellectual backbone of your work. In practice:

  • You will read many more papers than you cite prominently
  • Only a subset will appear as “key” references
  • Proposals typically list twice as many papers as the minimum number of key sources, as not all read papers become central to the argument.

Expected Literature Coverage (Minimum Guidance)

While the exact number varies by discipline and supervisor, the following minimum expectations are a useful guide:

  • Undergraduate projects: at least 8+ key papers
  • MSc projects: at least 15+ key papers
  • PhD research: typically 30+ key papers forming a comprehensive review

How to read efficiently:

  1. Start with abstracts
  2. Scan introductions and conclusions
  3. Ask why this paper exists, not just what it does
  4. Track assumptions, limitations, and evaluation contexts

Your goal is not memorisation, but pattern recognition.

Resources

Resources to guide you in conducting a thorough literature survey:

The following tools are useful for keeping track of literature sources:

Formulating the Problem Statement

Once you have a preliminary understanding of your research problem, it is time to start documenting it.

Many students believe they understand their research problem, but when asked to explain it to someone else, or to put it into writing, they often struggle. This difficulty is a strong indicator that the problem is not yet sufficiently well understood.

Albert Einstein is often attributed with the idea that if you clearly define the problem, you have already solved most of it. While precisely defining a research problem can be challenging, working on a clearly articulated problem is far more manageable than dealing with a vague or loosely framed one.

At this stage, your goal is not to produce a perfect or final problem statement. Instead, the goal is to make an early, explicit attempt, fully expecting that the problem statement will evolve as you:

  • read more literature,
  • discover constraints or limitations,
  • receive feedback from your supervisor.

Early formulation accelerates this refinement process.

The Three Fundamental Questions

A good problem statement should effectively address three fundamental questions, in any suitable order:

  • What is the problem?
  • Why is it important?
  • How do you plan to address it?

Although these questions are borrowed from a different domain (e.g., Start With Why by Simon Sinek), they are highly relevant in research contexts.

First Attempt: A Short Write-up

Initially, aim for a half‑page write-up that addresses these three questions.

Many students find it easier to start with the “why”:

  • Why does this problem matter?
  • Who is affected by it?
  • What are the consequences of not addressing it?

Present your thoughts in paragraph form, not as bullet points. Writing full sentences forces clarity.

If you find it hard to put your problem into words, treat this as a useful diagnostic, not a failure, it usually means the problem needs further refinement. In such cases:

  • Discuss the difficulty openly with your supervisor
  • Try explaining the problem to colleagues outside your immediate research area

Being able to explain your research problem to someone with a general background in Computer Science, but not necessarily expertise in your niche, is a valuable and necessary skill.

Returning to the literature at this stage often helps sharpen your understanding and expose gaps or assumptions you had not previously considered.

Developing a Detailed Problem Statement

Once your understanding improves, you should write a more detailed problem statement, typically around 300 words.

Where this appears depends on the document:

  • Project proposals / literature surveys: usually in Chapter 1
  • Theses: often in Chapter 3 (sometimes Chapter 1, depending on structure)

A detailed problem statement should include the following components:

  • Background and Motivation
    Provide sufficient background to contextualise the problem and explain why it is significant. If appropriate, briefly describe one or two use cases to make the problem more tangible. This section acts as the motivational lead‑in to your research problem.

  • Problem Statement (The “What”)
    Clearly articulate the specific problem you aim to address. Real‑world problems are often broad and complex. A research project typically focuses on a well‑defined sub‑problem within that larger space. Explicitly:

    • define the scope of your work,
    • state assumptions,
    • clarify what is out of scope.

    Supervisors and review panels frequently comment that problem statements are too broad. This is where disciplined scoping matters most.

  • Research Gap (The “Why”)
    Drawing on your literature survey, describe what is missing from existing work:

    • unanswered questions,
    • unrealistic assumptions,
    • limitations in scale, context, or evaluation.

    This section explains why your work is necessary and why addressing the problem is worthwhile.

  • Proposed Solution and Methodology (The “How”)
    Provide a concise overview of your proposed solution and its key objectives. At this stage:

    • you are not expected to have all answers,
    • but you are expected to have a preliminary plan.

    Explain:

    • what your approach is,
    • why you believe it is promising,
    • how each objective will be pursued.

    This preliminary plan is your research methodology. Where appropriate, include high‑level diagrams illustrating:

    • the solution concept,
    • major components,
    • workflow or interactions.

    Diagrams are often the most effective way to communicate research methodology clearly and quickly.

  • Research Question
    Formulate a single‑sentence research question that captures the core of your investigation. Research questions typically begin with phrases such as:

    • What is…
    • How can…
    • To what extent…

    The research question acts as a focal point that keeps your work coherent and prevents scope creep.

Problem Statement vs Purpose Statement

In some programs, the problem formulation is divided into:

  • a problem statement, and
  • a purpose statement.

These may be written together or separately, depending on:

  • degree requirements,
  • research methodology,
  • supervisor preferences.

Resouces

Writing the Literature Survey

A literature survey is best thought of as a growing tree. A small number of key papers lead you to many seemingly relevant ones, which in turn guide you to even more. This expansion is natural—and necessary—when exploring a research area.

However, there comes a point where you must pause the search for new literature. This pause usually occurs once you have developed a solid understanding of your area and your research problem has become sufficiently clear and well‑scoped.

Students often struggle to find this balance. Those who strive for perfection may feel compelled to keep reading indefinitely, delaying the transition to actual research. Others may prematurely stop after reading only a handful of papers, risking blind spots and weak justification. Supervisor feedback is often the most reliable signal indicating when to slow down (or temporarily stop) expansive literature searching.

Literature Review as an Ongoing Process

In practice, a literature review is not a one‑off task. It continues, in different forms, until the final version of your thesis is submitted.

Additional literature is typically sought during several phases:

  • Solution design
    Designing a solution often requires exploring alternative algorithms, architectures, tools, databases, middleware, or survey instruments. Multiple options may need to be evaluated before selecting the most appropriate ones.

  • Solution implementation and evaluation
    During implementation, simulation, or empirical evaluation, further literature may be required to determine configuration parameters, experimental settings, performance metrics, or to refine survey instruments.

  • Writing the thesis
    As you write, you may identify gaps in argumentation or insufficient justification for design decisions. Additional literature helps solidify your narrative and strengthen claims.

  • Long‑term research projects
    For multi‑year research (e.g., PhD or part‑time research), staying abreast of newly published work is essential. Subscribe to relevant conferences and journals, track new publications, and use tools such as Google Scholar alerts or mailing lists.

From Reading to Writing

Once you have absorbed the relevant literature, documenting your understanding becomes critical. This documentation often forms Chapter 2 of a thesis.

When writing the literature survey:

  • Cover seminal papers, alternative approaches, emerging trends, and competing designs.
  • Compare and contrast approaches rather than summarising papers in isolation.
  • Write in your own words to reduce similarity and avoid plagiarism.
  • Explicitly discuss how different works relate to one another, including strengths, weaknesses, assumptions, and limitations.

If you find yourself constantly referring back to original papers while writing, this usually indicates insufficient understanding. Effective reading strategies, such as highlighting, annotating, and summarising key ideas, are essential at this stage.

Your literature survey should tell a coherent story, not read like a disconnected list of papers.

Plan Before You Write

Before drafting the literature survey, create a detailed outline:

  • Arrange topics based on importance and conceptual dependencies
  • Identify missing themes or unexplored areas early
  • Ensure a logical progression of ideas

Planning upfront is far more efficient than restructuring an entire chapter after writing it. This planning step may also reveal the need to explore additional literature before proceeding.

What a Good Literature Survey Should Contain

A well‑written literature review typically includes the following elements:

  • Summary of related solutions
    Summarise relevant solutions, technologies, algorithms, techniques, and tools. Even if your work focuses on a specific approach, discuss alternatives and justify why your chosen option is appropriate.

  • Motivation and justification
    Use the literature to motivate and justify your research problem. Clearly demonstrate why the problem matters and where existing work falls short.

  • Visual aids
    Include figures and tables where helpful. Avoid screenshots from original papers; instead, create your own diagrams to improve clarity and originality.

  • Critical evaluation
    Critically evaluate existing work. Discuss strengths and weaknesses, validity of assumptions, performance results, scalability, and applicability to your problem context.

  • Solution summaries and comparisons
    Summarise key techniques and explicitly compare similar approaches. Tables are often effective for presenting comparisons.

  • Coherent structure
    Ensure logical flow. Start with concepts that can stand alone before introducing dependent ideas.
    For example, if your work involves IoT big‑data processing, introduce IoT and big data concepts before discussing specific systems.

  • Proper citation
    Accurately cite all sources using an appropriate referencing style (e.g., IEEE, ACM, APA), as required by your program.

  • Language and style
    Use an academic writing style that prioritises clarity and precision. Be cautious when using language‑editing or generative AI tools, as they may introduce overly conversational phrasing or subtle inaccuracies.

Further Reading

The following resources provide useful guidance on academic writing and literature surveys:

Common Red Flags (Watch Out)

The following warning signs frequently appear when students struggle with problem formulation or literature surveys. Spotting them early can save significant time and frustration later.

Red Flags in Problem Understanding and Formulation

  • “I understand the problem, but I’m struggling to write it down.”
    Difficulty articulating the problem, either verbally or in writing, is a strong indicator that the problem is not yet sufficiently clear.

  • “I’ll finalise the problem statement later.”
    Postponing problem formulation often leads to wasted effort. Early, imperfect formulations are essential for refinement.

  • “My problem keeps changing, so I won’t write it yet.”
    Problem evolution is normal. Documenting early versions helps track progress and guides focused literature exploration.

  • “It’s hard to explain this to someone outside my niche.”
    If the problem cannot be explained to someone with a general Computer Science background, it is likely too vague or overly jargon‑heavy.

  • “My problem is broadly about improving X.”
    Overly broad problem statements usually indicate insufficient scoping. Research problems should focus on a well‑defined sub‑problem.

Red Flags in Research Questions and Scope

  • Multiple loosely related research questions.
    A strong project typically revolves around one core research question, not a collection of disconnected ones.

  • Research questions that already assume a solution.
    Questions framed around a specific tool or technology often indicate solution‑driven rather than problem‑driven research.

  • “I’ll solve the whole problem first and then evaluate.”
    This often signals an engineering mindset rather than a research one. Research progresses through inquiry, validation, and iteration.

Red Flags in Literature Review Behaviour

  • “I’ve read enough—I’ve looked at five or six papers.”
    This almost always indicates under‑reading. Minimum expectations for literature coverage are rarely met with such small numbers.

  • “I’ll stop reading once I start implementing.”
    Literature surveys continue throughout the project, including design, implementation, evaluation, and writing phases.

  • “Every paper seems important.”
    Inability to distinguish key papers from peripheral ones often reflects surface‑level reading rather than deep understanding.

  • “I just summarised each paper one by one.”
    A literature survey should synthesise and compare work, not list summaries in isolation.

  • Heavy reliance on direct wording from original papers.
    Frequent copying or close paraphrasing signals insufficient comprehension and risks plagiarism.

  • “I used AI to summarise the papers, so I don’t need to read them fully.”
    AI tools are valuable for discovering, filtering, and summarising literature, but they are not a substitute for carefully reading key papers end‑to‑end. A strong literature survey requires deep engagement with foundational and closely related work, including understanding assumptions, methods, results, and limitations. Relying solely on AI‑generated summaries leads to shallow understanding and missed nuances. “

Red Flags in Writing the Literature Survey

  • Writing before creating an outline.
    A missing or weak outline often leads to a disjointed, repetitive, or poorly structured chapter.

  • Sections that feel unrelated or abruptly ordered.
    Poor flow usually means conceptual dependencies have not been respected.

  • No explicit comparison between similar approaches.
    Failing to compare alternatives undermines critical evaluation and weakens justification.

  • No clear link between the literature survey and the research problem.
    If the literature does not naturally motivate the problem statement, the survey is incomplete.

  • Overly conversational or collaborative tone.
    This may result from heavy use of generative AI tools without careful review and correction.

  • Inconsistent or missing citations.
    This raises academic integrity concerns and suggests poor engagement with the literature.

  • “My supervisor will fix the problem statement or literature review.”
    Supervisors guide and refine, they do not replace the fundamental thinking and writing that the student must do.

Recognising one or two of these red flags is normal. However, if multiple signs appear simultaneously, it is a strong indication that you should pause, reflect, revisit the literature or problem formulation, and actively seek feedback from your supervisor. It’s also worth checking your meeting notes and previous email exchanges, as your supervisor may have already communicated this guidance earlier, though you did not notice.