A research proposal for an M.Tech or MCA computer science thesis is the two-to-eight-page document that gets your topic approved before you write a line of the dissertation itself — it argues that a specific problem is worth solving, that you have a workable approach to it, and that the approach fits inside the time you have left. This guide gives you the ten-part structure most Indian computer science departments expect, then a full worked specimen for a realistic machine-learning topic, section by section.
This is not the final dissertation report, which is a different document written after the work is done; that structure, with a worked IEEE citation example, is covered in our guide to how to write an M.Tech dissertation report. A proposal is shorter, forward-looking, and its job is to get a committee to say yes.
Step 1: Know what the proposal has to convince a committee of
Three things, in this order, and nothing else. The problem is real — it is not solved, or not solved well enough, by what already exists. The approach is feasible — it can plausibly be built and evaluated by one student in the time available, typically one to three semesters depending on your programme. The scope is bounded — the proposal names what is in and, just as importantly, what is out. A proposal that reads like a survey of the whole field, with no committed approach, is the single most common reason a committee sends one back for revision.
Step 2: Build the ten-section structure
- Title. States the technique and the problem in one line, not just the domain.
- Problem statement and motivation. What is broken or missing today, and why it matters.
- Brief literature positioning. Three to six directly relevant prior works, organised by approach, ending in the gap this proposal targets.
- Objectives. Three to five, each a verb plus a measurable outcome.
- Proposed methodology / system design. An architecture sketch at the level a proposal needs, not full implementation detail.
- Dataset and tools. What data the work will use and where it comes from, what software and hardware the plan needs.
- Evaluation plan. The metrics and baselines the finished work will be judged against.
- Expected outcomes. What the dissertation will be able to claim if the plan succeeds.
- Timeline. A term-by-term or month-by-month plan against your actual submission deadline.
- References. The works cited in the literature-positioning section, in your department’s required style.
Institutes vary in exactly which of these get their own heading versus folded together — some ask for “background and motivation” as one section, others split them — but a proposal missing any of the ten jobs above is incomplete regardless of the heading structure. Your department’s proposal template, where one exists, decides the exact section numbering; confirm against your own before formatting.
Step 3: Write the problem statement so it earns the approach
The order that works: state the domain problem in one sentence, name what current approaches do, name specifically what they fail to do or where they fall short, then state that this proposal addresses that shortfall. A problem statement that never names what existing work fails to do reads as background, not as a case for doing anything new.
Step 4: Position against the literature briefly, not exhaustively
A proposal’s literature section is three to six works, not thirty. Group them by approach family (for example, classical machine learning baselines, deep-learning approaches, and any domain-specific prior systems), state in one sentence what each family achieves and where its limitation lies for your specific problem, and close with the one gap your proposed approach targets. The full literature-survey discipline for the eventual dissertation chapter, once the work is further along, is covered in our guide to writing a literature review, though that guide is written at PhD scope; a proposal’s version is a fraction of that length and depth.
Step 5: State objectives that the evaluation plan can actually answer
Each objective should be a verb plus a measurable outcome: “to design a [method] for [task]”, “to evaluate [method] against [baseline] on [dataset] using [metric]”, “to analyse the effect of [factor] on [outcome]”. An objective with no metric behind it cannot be marked achieved or not achieved at the end, and that ambiguity is exactly what a committee is checking for at the proposal stage.
Step 6: Sketch the proposed methodology at proposal depth
A proposal names the architecture family (for example, a transformer-based classifier, a graph neural network, a hybrid rule-and-ML pipeline), the major components and how data flows between them, and the design decisions that are already fixed versus the ones still open. It does not need pseudocode-level detail or a working implementation — that belongs in the dissertation’s design chapter once the work is under way. What it does need is enough specificity that a reader can tell the approach apart from any other approach to the same problem.
Step 7: Name the dataset and the evaluation metric together
State which dataset the work will use, where it comes from, its rough size, and any known limitation (class imbalance, small size, a licence restriction). Pair that immediately with the metric the evaluation will report, and why that metric fits the task — accuracy is rarely the right single metric for an imbalanced classification problem, for instance. The reasoning behind choosing a metric to fit a task, not the other way round, is covered in our guide to choosing an evaluation metric for an MCA machine learning project. Where a dataset does not yet exist and one is being collected as part of the work, say so explicitly and state the collection plan and its own timeline risk.
Step 8: Build a timeline that survives contact with the semester
A realistic timeline names five phases — literature finalisation, design, implementation, evaluation, and writing — against actual calendar months, and states which phase has the most schedule risk. Implementation nearly always overruns its planned window; a proposal that gives implementation the same number of weeks as writing is read as optimistic rather than planned. Building in a two-to-four-week buffer before the department’s own internal review dates, not just the final submission date, is what keeps a timeline usable rather than decorative.
Step 9: A full worked example
Below is a complete, condensed specimen proposal for a realistic MCA/M.Tech topic. Every number and dataset name is illustrative, and each bracketed [cite …] marker shows where one of your own verified references goes — check current dataset availability and dataset size for any topic you actually pursue, since dataset hosting and versions change.
Title: A Hybrid BERT and Metadata-Based Classifier for Detecting Fake Product Reviews on Indian E-Commerce Platforms
Problem and motivation: Fake reviews distort purchase decisions on Indian e-commerce platforms, and purely text-based detectors are increasingly evaded by fluent, AI-generated review text. Existing published detectors largely rely on review text alone; reviewer-behaviour metadata (posting frequency, account age, rating-distribution skew) is comparatively under-used in the literature for this specific combination, particularly on Indian-platform data.
Literature positioning: Classical approaches use n-gram and TF-IDF features with SVM or Naive Bayes classifiers, achieving moderate accuracy but degrading against paraphrased fake text [cite a classical-baseline study]. Deep-learning text classifiers using BERT-family models improve on this but are mostly evaluated on English-language datasets from non-Indian platforms [cite two BERT-based studies]. Metadata-only approaches using reviewer behaviour features show promise for detecting coordinated fake-review campaigns but are not combined with text signal in the surveyed work [cite a behaviour-feature study]. The gap this proposal targets is a hybrid model combining BERT-based text representations with reviewer-behaviour metadata, evaluated on Indian e-commerce review data.
Objectives:
1. To construct a labelled dataset of genuine and fake reviews from a named Indian e-commerce category.
2. To design a hybrid classifier combining a fine-tuned BERT text encoder with reviewer-metadata features.
3. To evaluate the hybrid classifier against a text-only BERT baseline and a metadata-only baseline using F1-score and AUC.
4. To analyse which metadata features contribute most to detection accuracy.Proposed methodology: A two-branch architecture: a fine-tuned BERT encoder processes review text into a dense representation; a separate feature branch processes reviewer metadata (account age, review frequency, verified-purchase flag, rating deviation from product average); the two representations are concatenated and passed through a classification head. Labelled data will combine a public fake-review benchmark dataset (for pretraining/transfer) with a smaller manually annotated set of Indian-platform reviews for fine-tuning and evaluation, given that a large labelled Indian-specific dataset is not known to exist publicly at proposal stage.
Dataset and tools: Python, PyTorch, the Hugging Face Transformers library for the BERT backbone, scikit-learn for baseline classifiers and evaluation metrics. Primary dataset: a public fake-review benchmark (exact source and licence to be confirmed and cited in the dissertation once selected); secondary dataset: a manually annotated sample of approximately 2,000 reviews from a named product category, annotated using a stated protocol with inter-annotator agreement reported.
Evaluation plan: F1-score and AUC against the text-only and metadata-only baselines, on a held-out test split never used in training or validation; a confusion matrix reported alongside the headline metrics because a single F1 figure can mask which error type (false positives versus false negatives) the model actually makes.
Expected outcomes: A working hybrid classifier, a comparative evaluation showing whether metadata features improve on text-only detection for this data, and an analysis of feature importance. If the hybrid approach does not outperform the text-only baseline, that negative result is itself a reportable finding, stated as such rather than hidden.
Timeline (illustrative, 2-semester MCA project): Months 1–2: dataset collection and annotation. Month 3: baseline implementation. Months 4–5: hybrid model implementation (highest schedule risk). Month 6: evaluation and analysis. Months 7–8: writing, buffered two weeks before the department’s internal review.
Notice that every objective in the specimen maps to a specific line in the evaluation plan, and the methodology names the architecture family without pretending the implementation is already built. That discipline is what a proposal committee is actually checking.
Step 10: Five faults that get a proposal returned
- A survey with no committed approach. Ten pages of prior work and no stated design of your own.
- Objectives with no metric behind them. “To study” or “to explore” instead of a verb the evaluation plan can answer.
- A dataset named but never checked. Confirm the dataset is actually accessible, at the size and licence you need, before the proposal is submitted, not after.
- A timeline with no buffer. Every phase planned back-to-back with no slack invites a request for revision on schedule risk alone.
- Scope that keeps growing in the text. The objectives promise four things; the methodology section quietly proposes six. Keep the two sections in lockstep.
Once the proposal is approved, the topic-and-dataset pairing you committed to becomes the anchor for the rest of the work; thirty further M.Tech CS topics, each already paired with a real dataset, are catalogued in our guide to M.Tech computer science thesis topics with a free dataset behind each one if you are still choosing rather than refining an existing idea.
Frequently asked questions
How long should a research proposal be?
Most Indian M.Tech and MCA departments expect two to eight pages, though the exact limit is set by your department’s own template or guideline. Confirm the page or word limit before drafting, since some departments count references and appendices against the limit and some do not.
Is a research proposal the same as a synopsis?
They serve the same purpose — getting a topic approved before the work begins — but “synopsis” in Indian usage more often refers to the PhD-level pre-registration document, while “research proposal” or “project proposal” is the term used at the M.Tech/MCA level. The content overlaps closely; the length and formality differ by programme.
Do I need preliminary results in the proposal?
Not usually. A proposal argues the approach is feasible and states expected outcomes; it does not require results already in hand. Some departments do welcome a small pilot result if one exists, clearly labelled as preliminary.
What if my dataset changes after the proposal is approved?
Tell your guide and document the change. A dataset substitution is common when an intended source turns out to be inaccessible, too small, or licensed in a way that blocks academic use; a disclosed substitution is normal, an undisclosed one is a discrepancy an examiner will eventually find.
Should the proposal include a full related-work table?
A short comparison table of three to six works, each row stating the approach and its limitation for your problem, is more useful at proposal stage than an exhaustive survey. The exhaustive version belongs in the dissertation’s literature chapter later.
How many objectives should a proposal have?
Three to five is typical. Fewer than three usually means the scope is too narrow to justify a dissertation; more than five usually means the scope needs cutting before a committee will approve it.
What citation style should the proposal use?
Most Indian computer science departments require IEEE numeric style, matching the eventual dissertation; some use APA. Confirm with your department and stay consistent between the proposal and the final report.
Can the proposal’s methodology change once work begins?
Yes, within reason, and this is normal — a proposal is a plan, not a contract fixed in every detail. A substantial change of approach (not just a parameter or a dataset swap) is worth flagging to your guide, since the committee approved the original plan.
Does a proposal need a literature review chapter, or just a section?
A section, not a chapter. The full literature review chapter belongs in the dissertation itself, written after the work is further along and the relevant literature is better understood.
What is the most common reason a CS research proposal is rejected outright?
A problem that is not actually novel or is already comprehensively solved by an existing, well-known approach, with no stated gap the proposal addresses. Checking this honestly before submission saves more time than any formatting fix.
Turn your proposal into a working plan
The ten sections above are a checklist, but assembling them into a document that reads as one coherent argument — problem, gap, approach, evidence it will work — is where most drafts stall. Tesify structures your proposal from your stated problem and objectives, keeps the methodology and evaluation sections in agreement, and carries the same structure forward into the dissertation once your proposal is approved.