Demonstrate the ability to write technical reports and research proposals, and to present research findings effectively.
This lecture is the centre of CO4. Lecture 1 supplied the writing craft; this lecture applies it to the artefact the course is built around — the research proposal.
The lecture consolidates two syllabus topics — developing a research proposal and proposal format and components — and these notes keep that division. Sections 4–10 are the intellectual core: the argument the proposal makes. Section 11 is the document: the ten components that carry it.
The order matters. A beautifully formatted proposal built on an ill-defined problem is rejected; a rough draft of a sharp idea can be rewritten. Do not format your way out of a weak problem statement.
One test runs through the whole lecture and is the self-check before you submit Assignment 2: every objective must be addressed by the methodology, produce a deliverable in the outcomes, and occupy time in the work plan.
1. Learning Outcomes
- Distinguish between a research problem, a research question and a research hypothesis.
- Apply structured techniques to identify, refine and justify a research problem in computer science.
- Formulate clear, measurable research objectives and testable hypotheses — and recognise when hypotheses do not apply.
- Conduct and synthesise a focused literature review aligned with a chosen problem.
- Articulate the significance, scope and feasibility of a proposed study with rigour.
- Identify and construct the ten standard structural components of a research proposal, including work plan, timeline and budget.
- Critically evaluate a sample research proposal against standard academic criteria.
2. What a Research Proposal Is
A research proposal is a formal document that outlines intended research, justifies its necessity, and describes the methods by which the investigator will conduct it. In computer science, where projects often involve rapidly evolving technologies and complex systems, the proposal serves as a roadmap for the researcher and a contract of academic accountability with reviewers, funding agencies and supervisors.
- Persuasive document. It convinces reviewers, funding agencies or supervisors that the proposed research is worthwhile, feasible and methodologically sound. Nothing else in the document matters if this fails.
- Planning document. It forces the researcher to think systematically about problem, approach, resources and schedule — before committing eighteen months to them.
- Contractual document. Once approved, it becomes the benchmark against which progress and deliverables are evaluated. What you promised is what you will be asked for.
Proposals are required for academic theses, funded research (DST-SERB, MEITY, NSF, EU Horizon), industrial R&D submissions and conference workshop papers. Specific funding bodies impose slight variations, but the structure is largely standardised; mastering the universal template enables rapid adaptation to any sponsor-specific format.
3. Key Concepts Overview
| Element | Purpose |
|---|---|
| Research problem | Defines the gap or issue the study addresses |
| Research questions | Operationalises the problem into answerable inquiries |
| Objectives | States the concrete aims of the investigation |
| Hypotheses | Provides testable predictions, where applicable |
| Literature review | Establishes context, identifies gaps, avoids duplication |
| Significance | Justifies why the research matters |
| Scope | Delimits what the study will and will not cover |
| Feasibility | Demonstrates that the study can realistically be executed |
4. Identifying the Research Problem
4.1 What Constitutes a Research Problem
A research problem is a specific issue, difficulty or contradiction that can be investigated through empirical, theoretical or computational means.
A well-stated problem answers three implicit questions: (1) What is the observed phenomenon or deficiency? (2) Where and under what conditions does it occur? (3) Why does it matter to the field, stakeholders or society?
In computer science, problems typically arise from:
- Performance bottlenecks in existing algorithms or systems.
- Limitations of current models in handling new data types or scales.
- Unmet user requirements in human–computer interaction contexts.
- Open theoretical questions in formal models — complexity theory, computability.
- Sociotechnical concerns such as privacy, fairness or the sustainability of digital systems.
4.2 Sources of Research Problems
- Personal experience with a system, tool or framework.
- Literature gaps identified through surveys and systematic mapping studies.
- Industry reports (Gartner, ACM TechReports) highlighting unsolved challenges.
- Conference proceedings (NeurIPS, SIGCOMM, CHI) that propose open problems.
- Replications and contradictions in prior empirical findings.
- Interdisciplinary intersections — NLP applied to legal corpora, blockchain for healthcare records.
4.3 Five Techniques for Problem Identification
- Brainstorming and mind mapping. Generate broad themes and cluster them into narrower sub-issues.
- The 5W1H framework. Apply What, Why, Who, Where, When, How to dissect a broad topic.
- PICO(T). Adapted from evidence-based research — Population (the data or system users), Intervention (the proposed technique or model), Comparison (baseline or state of the art), Outcome (the measured metric: accuracy, latency, energy), Timeframe (evaluation period).
- Problem tree analysis. Map causes, effects and the core issue, separating symptoms from the thing worth solving.
- Critical reading. Identify limitations explicitly acknowledged by the authors of seminal papers.
It is the fastest route from a vague interest to a comparable, measurable claim, because it forces a baseline and a metric into existence. A problem without a named baseline cannot be shown to be unsolved; a problem without a metric cannot be shown to be solved.
Equally, the “Limitations” and “Future work” sections of strong papers are the cheapest source of legitimate research problems available to a student.
4.4 SMART Characteristics of a Good Problem
- Specific — focused on a defined sub-domain. “Cybersecurity” is a field; “intrusion detection in IoT networks using deep learning” is a problem.
- Measurable — outcomes can be quantified: precision, recall, F1, throughput.
- Achievable — within the technical and resource capacity of the researcher.
- Relevant — addresses a recognised gap or stakeholder need.
- Time-bound — completable within the project duration.
Weak: “Machine learning is not very accurate.”
Strong: “Existing convolutional neural network architectures for skin lesion classification achieve a maximum F1-score of 0.81 on the ISIC 2019 dataset, which is insufficient for clinical deployment where false negatives carry high patient risk. This study seeks to improve classification accuracy while maintaining interpretability.”
The strong version names the what (F1 of 0.81 on a named dataset), the why (false negatives carry patient risk) and the so what (clinical deployment is blocked).
5. Formulating Research Objectives
Objectives translate the problem into actionable intents. They describe what the researcher intends to accomplish and serve as the benchmarks against which the project’s success is later evaluated. Objectives define what success looks like.
5.1 Hierarchy and Characteristics
- Primary (general) objective — the overarching goal that captures the spirit of the research.
- Secondary (specific) objectives — discrete, sequential sub-goals that together deliver the primary objective.
Effective objectives are: clear (unambiguous, plain language); realistic (achievable given constraints); measurable (evaluable against specific metrics); ordered (foundational before applied); and action-oriented (beginning with strong verbs such as design, develop, evaluate, compare, analyse, implement, validate).
- Too broad — “To study machine learning.”
- Objectives confused with methods — “To use Python and TensorFlow.”
- Activities listed as outcomes — “To conduct a literature review” is a task, not an objective. This is the single most common error in submitted proposals.
Avoid the verbs study, understand and explore unless they are followed by a measurable complement.
5.2 Worked Example — Smart Traffic Management
Primary objective: To design and evaluate a deep reinforcement learning framework for adaptive traffic signal control in heterogeneous urban environments.
Secondary objectives:
- To analyse the limitations of existing fixed-time and actuated traffic control systems through a systematic literature review.
- To develop a multi-agent reinforcement learning model that dynamically adjusts signal phases based on real-time traffic density.
- To implement the proposed framework in a simulated urban grid using SUMO and to benchmark it against baseline controllers.
- To evaluate performance across metrics of average vehicle delay, throughput, queue length and emissions.
- To assess the transferability of the trained policy across varying traffic demand profiles.
Read the sequence: survey → build → implement and benchmark → measure → generalise. Each objective is a verb plus a measurable complement, and each depends on the one before it. That ordering is what makes the work plan in Section 11.6 possible.
6. Formulating Hypotheses
A hypothesis is a tentative, testable prediction about the relationship between two or more variables. In computer science, hypotheses are particularly relevant to experimental, empirical and analytical research where causal or correlational claims are made.
6.1 Four Types of Hypothesis
| Type | Description | Example |
|---|---|---|
| Null (H0) | States that there is no significant effect or difference | “There is no significant difference in classification accuracy between the proposed CNN model and the baseline ResNet-50 on the CIFAR-10 dataset.” |
| Alternative (H1 / Ha) | Asserts a meaningful effect or difference | “The proposed CNN model achieves significantly higher classification accuracy than ResNet-50 on CIFAR-10.” |
| Directional | Specifies the expected direction of the effect | “Increasing the number of transformer layers beyond 12 will degrade performance on low-resource translation tasks due to overfitting.” |
| Non-directional | Specifies an effect without direction | “There is a relationship between dataset size and model robustness.” |
6.2 Characteristics of a Good Hypothesis
- Testable — can be validated using statistical or empirical methods.
- Falsifiable — can, in principle, be disproved.
- Specific — clearly identifies variables and their relationship.
- Grounded — derived from theory or prior literature.
- Concise — ideally expressible in a single declarative sentence.
6.3 Mathematical Expression
A comparative hypothesis in performance evaluation takes the general form
H1 : μproposed − μbaseline ≠ 0(1)
where μ represents the population mean of a performance metric — accuracy, latency, throughput. The researcher collects sample data and conducts a statistical test (paired t-test, Wilcoxon signed-rank test) to determine whether to reject H0 at a chosen significance level α, typically 0.05.
In exploratory, descriptive or design-science research, hypotheses may be inappropriate. A study that proposes a new software architecture pattern does not require hypothesis testing; it employs design principles, heuristics or qualitative evaluation criteria such as utility, elegance and reusability.
Forcing a hypothesis onto design-science work is a visible error: reviewers read it as a misunderstanding of your own research paradigm.
Are you comparing measurable outcomes between conditions? If yes, state H0 and H1 and name the statistical test. If you are building an artefact and arguing it is better by construction, state evaluation criteria instead. Students routinely write H1 and omit H0 entirely; state both.
7. The Literature Review in a Proposal
7.1 Four Functions
- Establishes the scholarly context of the proposed work.
- Identifies the gaps that justify the new study.
- Prevents duplication of prior efforts.
- Informs methodological choices by surfacing effective techniques, datasets and evaluation practices.
7.2 Types of Literature Review
| Type | Description | Use case |
|---|---|---|
| Narrative | Broad synthesis of the field | Doctoral proposals, introductions |
| Systematic | Protocol-driven search, inclusion criteria, quality assessment | Evidence-based CS research |
| Mapping study | Categorises the landscape of research | Software engineering, HCI |
| Meta-analysis | Statistical aggregation of effect sizes | Algorithm benchmarking |
| Scoping review | Maps breadth and depth of literature | Emerging topics, e.g. quantum ML |
7.3 Conducting a Systematic Literature Review
The standard process follows the Kitchenham guidelines:
- Define research questions for the review.
- Develop a search strategy — databases (ACM DL, IEEE Xplore, Scopus, arXiv), keywords, inclusion and exclusion criteria.
- Select primary studies through multi-stage screening.
- Assess study quality using validated checklists.
- Extract data using standardised forms.
- Synthesise findings thematically or quantitatively.
7.4 Structuring the Review Section
- Background — define key concepts and their evolution.
- Theoretical foundations — anchor the work in established theory (PAC learning, distributed systems theory).
- State of the art — summarise contemporary approaches and their performance.
- Critique — identify limitations, contradictions and methodological weaknesses.
- Gap identification — explicitly state what is missing and how the proposed work addresses it.
The last move must be explicit. A review inside a proposal that ends in a survey rather than a gap statement has not done its job.
7.5 Four Pitfalls
- Annotation without synthesis — listing paper summaries rather than integrating insights.
- Citation bias — over-representing Western, English-language or industry sources.
- Outdated evidence — ignoring recent preprints and open-source benchmarks.
- Lack of critical voice — accepting claims at face value without evaluating methodology.
A review on Privacy-Preserving Federated Learning for Electronic Health Records traces the progression from centralised machine learning (Konečný et al., 2016) to differentially private federated systems (Wei et al., 2020) to personalisation under non-IID data (Li et al., 2023). The synthesis highlights recurring limitations — communication overhead, heterogeneity, adversarial vulnerability — thereby justifying a new contribution such as a lightweight secure aggregation protocol.
8. Significance of the Study
Significance conveys the contribution of the proposed research to theory, practice or society. Reviewers and funding agencies expect a crisp articulation of why the study matters.
8.1 Five Dimensions of Significance
- Theoretical contribution — advances conceptual understanding, e.g. a new complexity bound or model.
- Methodological contribution — introduces improved procedures, tools or evaluation frameworks.
- Empirical contribution — provides new datasets, benchmarks or experimental insights.
- Practical contribution — solves an industry problem, informs policy, improves user experience.
- Societal contribution — addresses ethical, environmental or equity considerations.
8.2 Writing a Strong Significance Statement
“This study is significant because it [addresses / resolves / extends] [specific gap] in [domain]. The findings will [advance theory / inform practice / support stakeholders] by [specific mechanism].”
“This study is significant because it addresses the lack of lightweight intrusion detection models for edge devices in IoT networks. The proposed framework will advance theory in resource-constrained deep learning and will offer practitioners a deployable artifact capable of identifying threats in real time without relying on cloud infrastructure.”
9. Scope of the Study
Scope establishes the boundaries of the research. It ensures clarity, manages stakeholder expectations and prevents scope creep. Stating exclusions is a strength, not an admission of weakness: undeclared scope is the root of most unfair criticism a proposal receives.
9.1 Five Boundaries to Declare
- Topic boundaries — the specific algorithms, systems or phenomena covered.
- Theoretical boundaries — frameworks adopted or excluded.
- Methodological boundaries — methods, tools and datasets used.
- Geographical or demographic boundaries — relevant for social computing, HCI and policy-oriented CS research.
- Temporal boundaries — the time period of data collection or system operation.
“This study is limited to the evaluation of deep reinforcement learning algorithms (PPO, SAC, DQN) for adaptive traffic signal control in simulated urban grids of up to 20 intersections. Real-world deployment, large-scale metropolitan networks and pedestrian-priority optimisation fall outside the scope of this study.”
- Too broad — attempting to solve multiple unrelated problems.
- Too narrow — insufficient to yield meaningful conclusions.
- Unstated assumptions — implicitly assuming data availability or hardware access without verification.
10. Feasibility of the Study
Feasibility demonstrates that the proposed research can realistically be executed within the constraints of time, expertise, equipment, data and budget.
10.1 Six Pillars of Feasibility
| Dimension | Key question |
|---|---|
| Technical | Are required tools, libraries and hardware accessible? |
| Data | Are datasets available, accessible and legally usable? |
| Operational | Are institutional approvals (IRB, ethics) in place? |
| Schedule | Is the timeline realistic given task dependencies? |
| Economic | Is the budget adequate for computation, travel and dissemination? |
| Human resources | Does the team possess the necessary expertise? |
10.2 Four Analysis Techniques
- SWOT analysis — strengths, weaknesses, opportunities, threats.
- Gantt chart — visualises task scheduling and milestones.
- Risk register — identifies risks, likelihood, impact and mitigation strategies.
- Proof of concept — a small-scale preliminary implementation that validates assumptions.
10.3 Five Risk Categories in CS Research
- Data risks — insufficient or biased datasets, licensing restrictions.
- Compute risks — hardware failures, GPU shortages, cost overruns.
- Algorithmic risks — non-convergence, instability, poor generalisation.
- Operational risks — staff attrition, dependency on third-party APIs.
- Ethical risks — use of personal data, dual-use concerns in security research.
“The proposed study is technically feasible because all required libraries (PyTorch 2.1, Ray RLlib) are open-source, and computation can be performed on the institutional GPU cluster (4× NVIDIA A100). The PEMS-BAY traffic dataset is publicly available through the California Department of Transportation. A preliminary PoC using SUMO on a 4-intersection grid has been completed, confirming that a single training episode requires approximately 12 minutes, well within the project’s computational budget.”
Contrast this with “the project is feasible”. Each claim names a version, a named cluster, a public dataset, and a completed proof of concept with a measured runtime.
11. The Ten Components of the Proposal Document
Everything above is the argument. The ten components below are the vehicle that carries it to a reviewer who has forty proposals to read and will spend four minutes on yours before deciding how carefully to read the rest.
| # | Component | Purpose |
|---|---|---|
| 1 | Title page | Identifies project, investigators and submitting organisation |
| 2 | Abstract | Single-paragraph summary of the entire proposal |
| 3 | Introduction | Establishes context, background and motivation |
| 4 | Objectives | States specific goals the research intends to achieve |
| 5 | Methodology | Describes methods, tools, datasets and analytical procedures |
| 6 | Work plan | Outlines tasks, phases and responsibilities |
| 7 | Timeline | Visualises the schedule using Gantt charts or milestone tables |
| 8 | Budget | Estimates financial resources required |
| 9 | Expected outcomes | Specifies deliverables, publications and societal impact |
| 10 | References | Lists all cited works in a consistent citation style |
11.1 Title Page
Essential elements: a project title (10–15 words, descriptive, containing the key technical terms that index the proposal in databases); the Principal Investigator and Co-Investigators with designations, affiliations and contacts; the submitting institution and department; the funding agency and call identifier; the submission date and version number; and declarations or signatures where required.
Weak: “A Study on Machine Learning” — too vague, no scope, no domain.
Strong: “A Hybrid Deep Learning Framework for Real-Time Anomaly Detection in IoT-Enabled Smart Grid Networks” — specific; identifies technique, application area and problem.
Avoid abbreviations unless universally understood (AI, ML, IoT). Do not end the title with a full stop. Use title case or sentence case consistently.
11.2 Abstract
A self-contained summary of approximately 200–300 words (some agencies mandate 150). It is often the only section many reviewers read carefully in the first screening round. It follows the IMRaD-lite structure:
- Context (1–2 sentences) — background and problem domain.
- Problem / gap (1–2 sentences) — what is missing in existing literature or practice.
- Objective (1 sentence) — what this research aims to do.
- Methodology (2–3 sentences) — how it will be done.
- Expected outcomes (1–2 sentences) — anticipated deliverables and impact.
- Keywords (4–6 terms) — placed at the end for indexing.
“The rapid proliferation of Internet of Things (IoT) devices in healthcare has introduced unprecedented cybersecurity vulnerabilities, particularly in patient monitoring systems. Existing intrusion detection mechanisms struggle to identify zero-day attacks while maintaining low false-positive rates. This research proposes a hybrid deep learning framework that combines Convolutional Neural Networks (CNNs) for spatial feature extraction and Long Short-Term Memory (LSTM) networks for temporal pattern recognition in network traffic. The model will be trained and evaluated on the CIC-IoT-2023 benchmark dataset and tested in a simulated smart hospital environment. The expected outcome is a real-time anomaly detection system with a detection accuracy exceeding 98 percent and a response latency under 50 milliseconds. The findings will contribute to safer medical IoT deployments and inform regulatory standards.”
Keywords: IoT security, deep learning, anomaly detection, smart healthcare, LSTM, CNN.
- Including citations or equations.
- Writing an abstract that does not match the actual content of the proposal.
- Exceeding word limits — grounds for desk rejection in many calls, meaning the proposal is never read at all.
- Using jargon without defining it.
11.3 Introduction
The introduction situates the research within its broader disciplinary landscape. It is typically 800–1,500 words and contains five subsections.
- Background — the foundational knowledge needed to understand the problem.
- Problem statement — a focused paragraph answering: what is wrong with current approaches, and why does it matter? It follows a funnel structure from broad context to a specific unresolved issue.
- Motivation — why the problem matters now: increasing prevalence with statistical evidence, economic, social or regulatory implications, and technological enablers that make the solution feasible.
- Literature gap — what is missing after the survey.
- Contribution summary — the enumerated claims of the proposed work.
- Cybersecurity is critical for digital infrastructure.
- Cloud computing environments face evolving threats.
- Existing signature-based intrusion detection fails against polymorphic malware.
- There is a need for an adaptive, behaviour-based detection mechanism.
Each step discards everything the next step does not need. Positioning phrases that do this work: “However, none of the existing approaches have addressed…”; “To the best of the authors’ knowledge, no prior study has investigated…”; “A critical limitation of current methods is…”
“The major contributions of this research are: (i) a novel hybrid CNN-LSTM architecture for IoT anomaly detection, (ii) a curated benchmark dataset for smart healthcare scenarios, (iii) extensive empirical evaluation demonstrating superior accuracy and latency, and (iv) an open-source reference implementation to facilitate reproducibility.”
11.4 Objectives — the SMART Framework
| Criterion | Description | Example |
|---|---|---|
| Specific | Clearly defines what is to be achieved | To design a hybrid deep learning model for IoT anomaly detection |
| Measurable | Outcomes can be quantified or verified | Achieve detection accuracy of at least 98 percent |
| Achievable | Realistic given resources and timeline | Use existing benchmark datasets and GPU access |
| Relevant | Aligned with the identified gap and motivation | Address zero-day attack detection |
| Time-bound | Has a defined completion deadline | Complete within 18 months |
Main objective: To develop and validate a real-time anomaly detection framework for IoT-based smart healthcare systems. Sub-objectives: (1) survey and benchmark state-of-the-art intrusion detection techniques; (2) design a hybrid CNN-LSTM architecture with optimised hyperparameters; (3) collect, preprocess and label network traffic data from a simulated hospital IoT environment; (4) evaluate using accuracy, precision, recall, F1-score and latency; (5) deploy on an edge computing device and validate real-time performance.
11.5 Methodology
The methodology is the heart of the proposal — and carries the largest rubric weight, typically 20–25 percent. It describes how the objectives will be achieved, organised around the research design paradigm: experimental, simulation-based, theoretical, design-science or mixed methods.
Typical subsections:
- Research design — overall approach (experimental, prototype-based, case study, simulation).
- Data collection — sources, datasets, ethical considerations, preprocessing techniques.
- Proposed model / algorithm — mathematical formulation, architectural details, pseudocode or workflow diagrams.
- Implementation tools — programming languages, frameworks, libraries, hardware platforms.
- Evaluation metrics — quantitative metrics with justification.
- Validation strategy — cross-validation, baseline comparisons, ablation studies, statistical tests.
Computer science proposals often include formal definitions. Define every symbol on first use:
where L(θ) is the binary cross-entropy loss, θ the model parameters, N the number of samples, yi the true label and ŷi the predicted probability. Algorithm sketches are presented similarly:
Input: Network traffic sequence X = {x1, x2, …, xT} Output: Anomaly score s ∈ [0, 1]
1: Extract spatial features using CNN layers: F = CNN(X)
2: Model temporal dependencies using LSTM: H = LSTM(F)
3: Compute anomaly score: s = σ(W·H + b)
4: Return s
- Open-source code repositories (GitHub, GitLab).
- Public dataset usage or clear licensing for proprietary data.
- Specification of hardware, e.g. NVIDIA RTX 3090, 64 GB RAM.
- Random seeds and hyperparameter settings.
Seeds and hyperparameters stated in a proposal signal a researcher who has actually run experiments. This is the modern differentiator.
Commonly referenced tools: languages — Python, R, Julia, C++, Java; frameworks — TensorFlow, PyTorch, scikit-learn, Keras; data tools — pandas, NumPy, Matplotlib, Seaborn; experiment management — MLflow, Weights and Biases, DVC; cloud platforms — AWS SageMaker, Google Vertex AI, Azure ML.
11.6 Work Plan
The work plan decomposes the research into discrete tasks or work packages (WPs). Each WP is assigned to a team member with a deliverable.
| Work package | Title | Duration (months) | Lead |
|---|---|---|---|
| WP1 | Literature review and problem refinement | 1 to 3 | PI |
| WP2 | Dataset collection and preprocessing | 3 to 5 | Co-PI |
| WP3 | Model design and implementation | 5 to 9 | Research Scholar |
| WP4 | Experimental evaluation | 9 to 13 | Research Scholar |
| WP5 | Deployment and real-time testing | 13 to 16 | Industry Partner |
| WP6 | Documentation, publication and reporting | 16 to 18 | All |
- Each WP has a clear, verifiable deliverable — a report, dataset, code module or publication.
- Dependencies between WPs are stated explicitly.
- Every major WP carries a risk mitigation line: “If GPU procurement is delayed, cloud instances will be used as fallback.” This detail separates a student work plan from a professional one.
11.7 Timeline
The timeline visualises the work plan chronologically, most commonly as a Gantt chart: rows are tasks, columns are months, shaded cells are periods of activity. Overlapping bars are not a flaw — they show parallel work and reveal where the critical path runs.
Milestones are critical checkpoints tied to specific deliverables:
- M1 (month 3) — completion of the literature review report.
- M2 (month 5) — finalised and preprocessed dataset.
- M3 (month 9) — working prototype with baseline performance.
- M4 (month 13) — full experimental evaluation complete.
- M5 (month 18) — final report and project closure.
11.8 Budget
| Head | Description | Example items |
|---|---|---|
| Manpower | Salaries for JRF, SRF, project staff | Research Fellow: Rs. 31,000 + HRA/month |
| Equipment | Hardware and software purchases | GPU workstation, server licences |
| Consumables | Items used up during the project | Cloud computing credits, datasets |
| Travel | Conference attendance, fieldwork | Registration, airfare, per diem |
| Contingency | Unforeseen expenses (typically 5 to 10 percent) | Emergency repairs, supplementary tools |
| Institutional overhead | Administrative charges to host institution | Often 10 to 20 percent of total |
| Publications and dissemination | Article processing charges, open access fees | APC for IEEE Access: USD 1,950 |
| S.No. | Item | Quantity | Unit cost (INR) | Total (INR) |
|---|---|---|---|---|
| 1 | GPU workstation (NVIDIA RTX 4090, 64 GB) | 1 | 250,000 | 250,000 |
| 2 | JRF stipend (24 months) | 1 | 744,000 | 744,000 |
| 3 | Cloud compute (AWS) | 12 months | 10,000 | 120,000 |
| 4 | Conference travel | 2 | 75,000 | 150,000 |
| 5 | Publications (2 journals) | 2 | 100,000 | 200,000 |
| 6 | Contingency | — | — | 100,000 |
| Total | 1,564,000 |
Each budget head must be accompanied by a one-paragraph justification explaining why the cost is necessary and reasonable. An unjustified line is simply cut — and a cut line often removes the activity it was funding. Note also that manpower, not equipment, is almost always the largest head.
11.9 Expected Outcomes
- Academic deliverables — 2 to 3 journal publications in SCI/Scopus-indexed venues; 1 to 2 conference papers (IEEE, ACM, Springer); one Ph.D. thesis where the project supports doctoral research.
- Technical deliverables — open-source software toolkit; curated and annotated benchmark dataset; prototype or proof-of-concept system.
- Human resource development — trained research scholars and postgraduate students; workshops or training programmes conducted.
- Societal and industrial impact — reduction in cyberattack incidents in the target deployment; technology transfer to industry partners; policy recommendations for regulators.
“A peer-reviewed journal article will be submitted to IEEE Transactions on Information Forensics and Security by month 18.”
“The proposed framework will achieve a detection accuracy of at least 98 percent on the benchmark dataset.”
Both are checkable. “We expect good results” is not a deliverable.
11.10 References
| Style | Common usage | Example |
|---|---|---|
| IEEE | Most engineering and CS journals and conferences | [1] S. Gupta et al., “Hybrid CNN-LSTM for IoT security,” IEEE Trans. Inf. Forensics Secur., vol. 18, pp. 1234–1245, 2023. |
| ACM | Computing conferences and journals | Suraj Gupta et al. 2023. Hybrid CNN-LSTM for IoT Security. ACM Trans. Priv. Secur. 26, 4, Article 12 (2023). |
| APA 7 | Social-science-adjacent CS research | Gupta, S., & Kumar, R. (2023). Hybrid CNN-LSTM for IoT Security. IEEE Transactions on Information Forensics and Security, 18, 1234–1245. |
| Springer (numeric) | LNCS proceedings | Gupta, S., Kumar, R.: Hybrid CNN-LSTM for IoT Security. In: Proc. ICSAI, pp. 1234–1245. Springer (2023). |
Reference management tools: Zotero (free, open-source, browser-integrated); Mendeley (Elsevier-owned, strong PDF annotation); EndNote (institutional licences); BibTeX / BibLaTeX (preferred for typesetting).
- Cite recent work — at least 40 percent from the last 3 to 5 years.
- Include seminal and foundational papers.
- Avoid excessive self-citation.
- Use primary sources; avoid citing secondary interpretations.
- Ensure every citation in the text appears in the reference list, and vice versa.
The 40-percent criterion is checkable in two minutes, and it is checked.
12. Worked Case: A Complete Proposal in Miniature
Title: Privacy-Preserving Federated Learning for Cross-Organisation Medical Imaging Analysis.
- Abstract — a 250-word summary covering context, gap, objective, methodology and outcomes.
- Introduction — establishes the importance of medical AI, the data privacy barrier imposed by HIPAA and India’s DISHA, and the emergence of federated learning as a solution.
- Objectives — (1) design a federated learning framework enabling multi-hospital collaboration without sharing raw patient data; (2) integrate differential privacy mechanisms providing formal privacy guarantees; (3) validate on three benchmark medical imaging datasets (chest X-ray, brain MRI, histopathology).
- Methodology — the federated averaging algorithm, the differential privacy budget ε, and an experimental setup with simulated hospital clients.
- Work plan — six work packages spanning 24 months. Timeline — Gantt chart with quarterly milestones. Budget — Rs. 22 lakh covering a JRF, GPU server, cloud credits and travel.
- Expected outcomes — two SCI publications, an open-source framework on GitHub, and a workshop for radiologists.
- References — 45 entries in IEEE format, including foundational works on federated learning (McMahan et al., 2017) and differential privacy (Dwork and Roth, 2014).
Title: Hybrid Quantum-Classical Neural Networks for Early Detection of Diabetic Retinopathy.
Problem: Existing CNN models for diabetic retinopathy detection require substantial labelled data and computational resources, limiting deployment in resource-constrained rural clinics.
Research questions: (1) How does a hybrid quantum-classical network compare against a purely classical CNN on the APTOS 2019 dataset? (2) Can hybrid architectures reduce trainable parameters without sacrificing accuracy? (3) What is the effect of quantum noise and circuit depth on robustness?
Hypotheses: H0 : μaccuracyhybrid = μaccuracyResNet-50 against H1 : μaccuracyhybrid ≠ μaccuracyResNet-50.
Significance: contributes to quantum machine learning theory while addressing a tangible healthcare delivery gap. Scope: limited to binary classification (referable vs. non-referable); quantum simulation via PennyLane rather than physical hardware. Feasibility: datasets publicly accessible; simulation on institutional HPC; preliminary circuit designs validated in PennyLane.
13. The Alignment Test and Common Mistakes
Read your own proposal in one direction only:
objective → methodology → work package → deliverable
Any objective that cannot be traced along that chain is either unfunded, unscheduled, or not really an objective. Reviewers check this alignment first, because misalignment is the cheapest available signal that a proposal was assembled rather than designed.
13.1 Seven Common Mistakes
- Mismatched components — objectives that the methodology does not address.
- Vagueness — phrases such as “appropriate methods will be used”. Specify exactly which methods.
- Inflated budgets — unrealistic or unjustified expenses lead to budget cuts or rejection.
- Missing risk analysis — always include a brief risk matrix.
- Ignoring ethics — mention ethics committee approval, data anonymisation and informed consent where human subjects or sensitive data are involved.
- Poor grammar and formatting — use spell-check, consistent fonts and standard margins.
- Lack of innovation — proposals that replicate existing work without a clear novelty claim rarely succeed.
14. Summary
- A proposal is persuasive, planning and contractual at once. The contractual reading is the one students underestimate.
- The research problem anchors the inquiry: SMART, with a named dataset and a named metric.
- Research questions decompose the problem; objectives operationalise intent as verbs plus measurable complements, logically ordered; hypotheses provide testable predictions where the research paradigm supports them.
- The literature review situates the work and must terminate in an explicit gap statement.
- Significance spans theoretical, methodological, empirical, practical and societal dimensions; scope delimits the work; feasibility is argued with evidence, not asserted.
- The ten components transform a research idea into a fundable, executable and evaluable project.
- Above all, objective → methodology → work package → deliverable must align.
15. Exam Preparation
- Memorise the structural anatomy. Be able to write the ten components in correct sequence without hesitation. Examiners frequently ask for this outright.
- Practise hypothesis writing. Be prepared to convert objectives into testable H0 and H1, and to say when hypotheses do not apply.
- Practise writing SMART objectives. This skill is tested often and directly.
- Be precise with methodology language. Avoid generic phrases; specify algorithms, tools and metrics.
- Understand objectives versus tasks. A common trick question.
- Familiarise yourself with one citation style. IEEE is the most common in CS examinations.
- Practise drafting Gantt charts in tabular form or with free tools such as ProjectLibre.
- Read successful proposals. NSF, European Commission CORDIS and DST-SERB host exemplary funded proposals.
- Allocate planning time. In the examination, spend roughly 10 percent of the time planning before writing.
15.1 Short-Answer Questions
- Differentiate between a research problem and a research question with a suitable example from computer science. 3 marks
- Why are SMART criteria important when formulating a research problem? Illustrate with an example in software engineering. 3 marks
- Distinguish between a null hypothesis and an alternative hypothesis. Under what conditions would you use a directional hypothesis? 3 marks
- State two reasons why a literature review is essential before finalising a research proposal. 2 marks
- Differentiate between scope and feasibility in a research proposal. 3 marks
- List the standard components of a research proposal in computer science. 3 marks
- What is the difference between an abstract and an introduction? 2 marks
- Distinguish between a work plan and a timeline. 2 marks
- Name three citation styles commonly used in computer science research. 2 marks
15.2 Long-Answer and Analytical Questions
- Consider a real-world domain (AI in agriculture, blockchain in supply chains, NLP for low-resource Indian languages). Draft a complete research problem statement, three research objectives and two testable hypotheses for a proposed study. 12 marks
- Critically evaluate the following problem statement: “This project aims to use AI to solve traffic problems.” Rewrite it according to SMART criteria and justify each improvement. 10 marks
- Critically evaluate the objective “To study deep learning.” Rewrite it as three SMART sub-objectives for a specific problem in your domain. 8 marks
- Design a work breakdown structure with at least five work packages for a project on “Automated Detection of Phishing Websites Using Graph Neural Networks”. Include deliverables and durations. 10 marks
- Draft a 250-word abstract for a hypothetical proposal on “Energy-Efficient Scheduling Algorithms for Edge Computing in IoT Networks”, following the IMRaD-lite structure. 10 marks
- Prepare a budget for a two-year project with one Junior Research Fellow, a GPU workstation, travel and publications. Justify each line item. 10 marks
- A faculty review committee has rejected your proposal citing “lack of feasibility”. Outline the specific elements you would revise and justify your reasoning. 10 marks
- Explain the importance of reproducibility in computer science proposals. List at least four practices that strengthen it. 8 marks
15.3 Multiple-Choice Questions
- Which of the following is the strongest example of a research problem statement?
(a) AI is interesting. (b) There is a need for better AI. (c) Current transformer-based chatbots hallucinate in 22% of responses on the LegalQA dataset, exposing users to legal misinformation. (d) AI will change the world. - A null hypothesis in a comparative algorithm study typically states that:
(a) The proposed algorithm is always better. (b) There is no significant difference between the algorithms on the chosen metric. (c) The proposed algorithm will fail. (d) The dataset is irrelevant. - Which section of a research proposal justifies why the study matters?
(a) Scope (b) Feasibility (c) Significance (d) Methodology - The Kitchenham guidelines are most associated with:
(a) Writing systematic literature reviews in software engineering. (b) Developing neural network architectures. (c) Designing software testing frameworks. (d) Conducting user interviews in HCI. - Scope creep is best prevented by:
(a) Expanding objectives iteratively. (b) Avoiding deadlines. (c) Clearly defining boundaries of the study in the proposal. (d) Adding more team members.
1 — (c) · 2 — (b) · 3 — (c) · 4 — (a) · 5 — (c)
15.4 Think-and-Apply
- Conduct a mini systematic literature mapping (at least 10 papers) on a chosen CS topic. Identify three themes and one unresolved gap, and present the synthesis as a structured paragraph.
- For a hypothetical federated learning project, prepare a feasibility plan addressing technical, data, operational and ethical risks.
- Take a recent IEEE or ACM paper from your sub-domain and reconstruct its likely proposal structure.
- Identify a funding call (DST, SERB, MEITY or a global equivalent) and map its template onto the ten components in Section 11.
- Pair with a classmate and critique each other’s draft abstracts using the IMRaD-lite checklist.
A full research proposal in the prescribed format, 10 marks, CO4. Use the ten components of Section 11 as your section headings and the alignment test in Section 13 as your self-check before submission. Due at lecture V.3.
16. Suggested Reading
- Creswell, J. W., & Creswell, J. D. (2018). Research Design: Qualitative, Quantitative, and Mixed Methods Approaches (5th ed.). SAGE Publications.
- Kothari, C. R., & Garg, G. (2019). Research Methodology: Methods and Techniques (4th ed.). New Age International Publishers.
- Kitchenham, B., & Charters, S. (2007). Guidelines for Performing Systematic Literature Reviews in Software Engineering. EBSE Technical Report. The standard protocol reference for Section 7.3.
- Day, R. A., & Gastel, B. (2016). How to Write and Publish a Scientific Paper (8th ed.). Cambridge University Press.
- Punch, K. F. (2013). Introduction to Research Methods in Education (2nd ed.). SAGE Publications.
- McMahan, H. B., et al. (2017). Communication-efficient learning of deep networks from decentralized data. Proceedings of AISTATS.
- Dwork, C., & Roth, A. (2014). The algorithmic foundations of differential privacy. Foundations and Trends in Theoretical Computer Science, 9(3–4).
- IEEE Editorial Style Manual. Available at https://ieeeauthorcenter.ieee.org/
- ACM Computing Surveys — Author Guidelines. Available at https://dl.acm.org/
- Your target agency’s own proposal template — DST-SERB, MEITY or AICTE. Read one before you draft Assignment 2.