Most M.Tech students spend more time worrying about the dissertation topic than actually choosing it. The worry makes sense. The topic decides which papers get read at 2 a.m., which lab gets booked for weeks, what the external examiner digs into during the viva and whether job interviews turn into real technical conversations.
A good topic is rarely a flash of inspiration. It usually comes out of a process of narrowing a broad interest until an unsolved problem shows up, then testing that problem against the time and resources actually on hand. This matters because research on postgraduate students’ academic and research experiences shows how strongly the research environment and related academic factors can shape the postgraduate experience. Students who skip the process tend to pick something trendy and then discover in the fourth semester that the gap was closed two years ago.
This guide breaks the process into eight practical steps and pairs them with a simple scoring model, the RIGOR Framework, for comparing candidate topics side by side. A ready-to-use checklist sits near the end for the last review before the topic goes to the department committee.
Why the Topic Decision Matters More Than It Seems?
In most Indian universities and IITs, the M.Tech dissertation runs across the third and fourth semesters. Many institutes split it into a Phase I (literature review leading to a written proposal) and a Phase II (implementation through to the final thesis). The topic gets locked early in Phase I, and changing it later almost always means throwing away weeks of reading and setup.
The dissertation also tends to be the single heaviest credit component of the program. Beyond grades, it is the one piece of work that shows up in a PhD application or a research engineer interview, and often in a first conference paper. A weak topic does not just make the year harder. It makes the year harder to talk about afterwards.
Table 1: What the topic choice changes across the year
| Area | With a weak topic | With a well-chosen topic |
| Literature review | Either hundreds of loosely related papers or almost none | A focused set of 25 to 40 papers that clearly frame the gap |
| Implementation | Stalls on missing data, hardware or licenses | Runs on resources confirmed before the work began |
| Results | Hard to compare against anything | Clear baseline and a measurable improvement |
| Viva | Examiner questions expose a vague contribution | Contribution can be stated in two sentences |
| Publication | Rarely publishable | Often good enough for a conference or a Scopus-indexed journal |
| Career | Generic talking point | A specific story for interviews and PhD statements |
The RIGOR Framework at a Glance
Before getting into the steps, it helps to know how candidate topics will finally be judged. RIGOR is a five-part filter. Every serious candidate gets scored on each criterion, and the weights reflect what actually sinks M.Tech projects. Gap and feasibility carry the most weight because a topic with no real gap fails the viva, and a topic with no data or hardware never reaches the viva at all.
Table 2: The five RIGOR criteria and their weights
| Letter | Criterion | The question to ask | Weight |
| R | Relevance | Does the problem matter to the field or to industry right now? | 20% |
| I | Interest | Will this still feel worth working on in month nine, when the experiments keep failing? | 15% |
| G | Gap | Is there a documented, specific limitation in recent literature that this work addresses? | 25% |
| O | Operational feasibility | Are the data, compute, equipment, skills and time available or easily obtainable? | 25% |
| R | Return | Does it help with the next step after M.Tech, including a possible publication? | 15% |
The eight steps below feed into this scoring. Steps 1 to 4 are about discovery, building a short list of real options. Steps 5 to 8 are about decision, testing that list hard and committing to one topic.
Figure 1: The eight-step topic selection process, with a loop back to reading when scores come out low
Treat the loop seriously. When every candidate scores poorly, the fix is almost never to lower the bar. It is to go back to the literature with a narrower question.
Step 1: Start With an Honest Self-Assessment
Topic selection starts with the person, not the paper list. Two students in the same branch can pick the same title and have completely different years, because one enjoys debugging code for hours and the other prefers building and measuring physical setups.
1.1 List the Subjects That Held Attention
Go back through the B.Tech and first-year M.Tech transcripts and pick out the courses where assignments felt less like a chore. Note the electives and any internship work that went beyond what was required. A short list of four to six subjects is enough. Interest alone does not decide the topic, but a topic outside every one of these subjects should raise a question.
1.2 Match Strengths to a Research Style
Every M.Tech topic falls into one or two broad styles of work. Knowing which style fits makes the next steps much faster.
Table 3: Common research styles in M.Tech dissertations
| Research style | What the work looks like | Suits someone who | Example |
| Simulation-based | Modelling a system in MATLAB, ANSYS, NS-3 or similar and studying its behaviour | Likes models and parameter studies | MPPT controller under partial shading in MATLAB/Simulink |
| Experimental or hardware | Building a prototype or test rig and taking measurements | Enjoys the lab and hands-on debugging | IoT soil moisture node with LoRa and power profiling |
| Data-driven or ML | Training and evaluating models on datasets | Codes comfortably in Python and enjoys iteration | CNN for defect detection on PCB images |
| Analytical | Deriving and proving mathematical results | Is strong in mathematics and theory | Closed-form outage analysis for a relay network |
| Design and optimization | Improving a design against cost or weight targets | Likes trade-offs and engineering judgement | Topology optimization of a brake pedal |
| Material or field study | Testing materials or collecting field data | Is patient with long test cycles | Steel slag as fine aggregate in M30 concrete |
1.3 Let the Career Goal Shape the Topic
The topic is also a signal to future employers and admission panels. Pick the style of topic that points in the right direction.
Table 4: Matching the topic to the next step
| Goal after M.Tech | Topic type that helps most | Why |
| PhD or research career | A topic with a clear novelty claim and publication potential | Admissions panels look for evidence of independent research |
| Core industry role | Applied problems close to industry practice, ideally with an industry partner | Shows the ability to work on real constraints |
| Software or AI role | Implementation-heavy topics with code on GitHub | Gives concrete material for technical interviews |
| PSU or government role | Topics tied to energy, infrastructure, defence or public systems | Aligns with the work these organisations do |
| Startup or product | A problem with an identifiable user and a working prototype | Doubles as a proof of concept |
Step 2: Pick a Domain and Narrow It Down
The most common reason students feel stuck is that they are still thinking at the domain level. “Machine learning” or “renewable energy” is not a topic. It is a library section. Narrowing happens in layers, and each layer cuts the reading list by an order of magnitude.
Figure 2: Each layer of the funnel narrows the reading list until a specific, testable topic remains
A topic that has only reached the application space layer is still too broad. “Medical image analysis” can fill a whole PhD. The goal is to get to the bottom two layers, where a single sentence describes exactly what will be built or tested and for whom.
Where Good Topic Ideas Usually Come From
- Future work sections of recent papers, where authors openly list what they did not get to
- Survey and review papers from the last three years, which map the open problems in a sub-area
- Ongoing projects of faculty members, especially sponsored ones with equipment already in place
- Internship and industry problems, where the data and the user already exist
- National mission areas such as electric mobility, semiconductor design, water management and grid integration of renewables
A quick test for any idea
Try to finish the sentence “This project will show that ___ improves ___ for ___.” If the blanks cannot be filled with specific words, the idea needs another round of narrowing.
Step 3: Read Strategically to Find the Research Gap
This is the step that takes the longest and the one most students rush. A research gap is a specific thing that recent work has either not done or has only done under limited conditions. It must be visible in the literature, not just in the student’s head.
3.1 Where to Search
Table 5: Where to look for literature
| Source | Best for | Practical tip |
| IEEE Xplore | Electrical, electronics, communication and computing | Filter by the last three to five years and sort by citations |
| ScienceDirect and SpringerLink | Mechanical, civil, materials, energy and chemical | Access is usually through the institute library network |
| Google Scholar | Broad discovery across all fields | Use “Cited by” to move forward in time from a key paper |
| arXiv | Latest preprints in CS, AI, signal processing and physics | Check whether a preprint was later published at a venue |
| Scopus | Checking where a topic is being published and by whom | Useful for picking target journals later |
| Shodhganga (INFLIBNET) | Indian theses and dissertations | Good for spotting topics already done to death in Indian institutes |
| NPTEL | Filling skill gaps before committing | Short courses help test whether a new area feels workable |
3.2 Read in Passes, Not Cover to Cover
S. Keshav’s well-known three-pass method saves a huge amount of time at this stage. The first pass covers only the title, abstract, introduction, section headings and conclusion, and takes five to ten minutes. Most papers stop there. The second pass follows the main argument through the figures and tables while skipping proofs. Only the handful of papers that matter most get a third pass, where the reader effectively rebuilds the work in their own head.
Record every paper in a literature matrix from day one. A spreadsheet works fine. By the time 20 to 30 papers are in it, the gaps often show up as patterns in the last two columns.
Table 6: A literature matrix template (illustrative rows)
| Paper | Year | Method | Dataset or setup | Key result | Limitation | Future work stated |
| Author et al. | 2024 | ResNet-50 transfer learning | EyePACS | High grading accuracy | Large model, server only | Mobile deployment |
| Author et al. | 2025 | MobileNetV3 | APTOS | Fast inference on phone | Drops on low-quality images | Robustness to image quality |
3.3 Know the Types of Research Gaps
Naming the type of gap makes it far easier to defend in the proposal and the viva.
Table 7: Six common types of research gaps
| Gap type | What it means | How it shows up in papers | Example |
| Performance | Existing methods fall short on accuracy or speed | Results tables with clear room to improve | Faster convergence for a PV optimizer |
| Methodological | A problem has only been tackled with one family of methods | Every paper uses the same approach | Trying graph neural networks where only CNNs exist |
| Contextual | Proven elsewhere but untested in a new setting | Studies limited to one region or material | Testing a pavement model under Indian monsoon conditions |
| Data | No suitable public dataset exists | Authors mention small or private datasets | Building a labelled dataset of local crop diseases |
| Validation | Shown only in simulation, never on hardware | No experimental section | FPGA implementation of a simulated filter design |
| Integration | Two strong ideas have never been combined | Separate literatures that never cite each other | Digital twin plus predictive maintenance for CNC spindles |
Rule of thumb
Read at least 15 to 20 papers from the last three to five years before claiming a gap. A gap claimed after reading five papers is usually a gap in the reading, not in the literature.
Step 4: Turn Gaps Into 3 to 5 Candidate Problem Statements
At this stage the aim is options, not a single answer. Three to five candidates give enough choice for a real comparison without spreading the effort too thin. Write each one as a proper problem statement using this template:
Problem statement template
Develop / design / analyse [what] for [application or context] that improves [metric] compared with [baseline] under [constraint].
The template forces specifics. A vague idea becomes something a supervisor can react to and an examiner can test.
Table 8: From vague idea to candidate problem statement
| Branch | Vague idea | Sharpened problem statement |
| CSE | AI in healthcare | Design a lightweight CNN for diabetic retinopathy grading on smartphone fundus images, keeping the model under 10 MB while staying within 2% of a ResNet-50 baseline |
| EE | Something with solar panels | Develop an MPPT controller for partially shaded rooftop PV arrays using a modified grey wolf optimizer and compare tracking efficiency against perturb and observe |
| ECE | IoT security | Design a lightweight authentication scheme for LoRa-based agricultural sensor nodes and measure its energy cost on ESP32 hardware |
| Civil | Concrete with waste materials | Analyse the effect of replacing fine aggregate with steel slag (10% to 40%) on the compressive and split tensile strength of M30 concrete |
| Mechanical | Lightweight automotive parts | Apply topology optimization to an automotive brake pedal in ANSYS to cut mass by at least 20% without exceeding the allowable stress |
Step 5: Run a Feasibility Check on Every Candidate
Feasibility kills more M.Tech topics than any other factor, and it usually happens quietly. The dataset turns out to need a license. The GPU queue in the lab is three weeks long. The spectrum analyzer is booked by PhD scholars every afternoon. Check each candidate against the resources below before falling in love with it.
Table 9: Feasibility check by resource
| Resource | Questions to ask | Red flag |
| Data | Is a suitable dataset public, or can it be collected in time? | Data depends on a company or hospital that has not agreed in writing |
| Compute | Can the experiments run on the lab machines or Colab? | Needs multi-GPU training for weeks |
| Equipment and lab | Is the hardware available and bookable for the full duration? | Equipment is heavily shared or still on order |
| Software | Are the tools licensed by the institute or open source? | Relies on a paid license nobody has |
| Skills | Can missing skills be learned within four to six weeks? | Needs an entirely new field from scratch |
| Time | Does the plan fit in roughly ten months with buffer? | No slack anywhere in the timeline |
| Supervision | Does the supervisor or a co-guide know this area? | Nobody in the department can review the methodology |
| Cost | Are components and consumables affordable or funded? | Prototype costs exceed what the student or lab can cover |
The timeline deserves special attention. Count backwards from the thesis submission date rather than forwards from today. Once review dates and writing weeks are blocked out, the window for actual implementation is shorter than most students expect.
Figure 3: A typical two-semester dissertation timeline, showing how little slack sits around implementation
A useful visual check at this point is to plot every candidate on two axes, interest and career fit on one side, feasibility on the other. Topics in the top right move forward. Topics in the bottom right are exciting but need rescoping before they can be scored fairly.
Figure 4: An interest vs feasibility map for six example candidate topics
Step 6: Score the Candidates With RIGOR
Now each surviving candidate gets a score from 1 to 5 on every RIGOR criterion. Use the rubric below so the scores mean the same thing across candidates. Then multiply each score by the criterion weight and divide by 5 to get a total out of 100.
Table 10: RIGOR scoring rubric
| Criterion | Score 1 | Score 3 | Score 5 |
| Relevance | Niche problem nobody is working on | Recognised problem with moderate interest | Active problem with recent papers and real-world demand |
| Interest | Chosen mainly because it looked easy | Mildly interesting | Genuinely curious and keen to keep going |
| Gap | Gap not visible in the literature | Gap exists but is broad or partly addressed | Specific gap stated in several recent papers |
| Operational feasibility | Key data or equipment missing | Most resources available, one uncertain | All resources confirmed with buffer time |
| Return | No link to career goals or publication | Some value for the next step | Directly supports the job, PhD or paper target |
A Worked Example
Consider a CSE student weighing three candidates: (A) a lightweight CNN for diabetic retinopathy grading on smartphones, (B) a blockchain-based land records system and (C) federated learning for intrusion detection in IoT networks.
Table 11: RIGOR scores for the three example candidates
| Criterion (weight) | A: Lightweight CNN | B: Blockchain records | C: Federated IDS |
| Relevance (20) | 5 | 3 | 5 |
| Interest (15) | 4 | 3 | 5 |
| Gap (25) | 4 | 2 | 4 |
| Operational feasibility (25) | 4 | 3 | 2 |
| Return (15) | 4 | 3 | 5 |
| Weighted total (out of 100) | 84 | 55 | 80 |
Figure 5: The RIGOR profile of each candidate shows where it is strong and where it is exposed
The radar view tells a more useful story than the totals alone. Topic B is weak almost everywhere, mainly because blockchain land registries have been studied heavily and the gap is thin. Topic C is the most exciting of the three but has one deep dent in feasibility, since a realistic federated setup needs many clients with uneven data and a lot of compute.
That dent does not have to be fatal. If the student rescopes C to use a public IoT intrusion dataset and simulate five clients on a single workstation, feasibility rises from 2 to 4 and the total jumps to 90, overtaking A.
Figure 6: Weighted RIGOR scores, including a rescoped version of Topic C
Table 12: Reading the RIGOR total
| Total score | What it means | Next move |
| 80 and above | Strong candidate | Take it to the supervisor |
| 65 to 79 | Workable but exposed somewhere | Rescope the weak criterion and rescore |
| Below 65 | Too risky for a ten-month project | Drop it or go back to Step 3 |
Step 7: Validate With the Supervisor Using a Concept Note
Walking into the supervisor’s office with “I am thinking of something in machine learning” wastes a meeting. Walking in with a one or two page concept note for the top one or two candidates turns the same meeting into a real decision.
Table 13: Concept note structure
| Section | What to include | Approx. length |
| Working title | Method plus application, in one line | 1 line |
| Background | Why the problem matters, with two or three references | 1 paragraph |
| Problem statement | The sharpened statement from Step 4 | 2 to 3 lines |
| Research gap | The gap type and the 3 to 5 papers that show it | 1 paragraph |
| Objectives | Two to four measurable objectives | Bullet list |
| Proposed methodology | Approach, tools, dataset or test setup and baseline | 1 to 2 paragraphs |
| Resources needed | Data, compute, equipment and anything still unconfirmed | Short list |
| Expected outcome | What will exist at the end and how success is measured | 2 to 3 lines |
| Timeline | Month-wise plan through both phases | Small table |
Questions Worth Asking in That Meeting
- Has anyone in the lab or department already worked on something close to this?
- Is the gap convincing, or is there recent work that already closes it?
- Which resource on this list is most likely to cause trouble?
- Would this suit a conference paper or a journal?
- Is there a co-guide or industry contact who could strengthen the work?
It also pays to run the concept note past a senior PhD scholar in the lab. Scholars know which machines actually work, which datasets have hidden problems, which licenses expire mid-year and which reviewers in the department care about what.
Step 8: Lock the Scope and Write the Final Title
Once the supervisor agrees, write down the scope in two short lists: what the project will do and what it will deliberately not do. The second list matters as much as the first. It is the document to point to in month seven when someone suggests adding a mobile app and a second dataset.
Table 14: An example scope statement
| In scope (example: Topic A) | Out of scope |
| Model design and compression for DR grading | Building a full clinical mobile application |
| Training and testing on two public fundus datasets | Collecting new patient data from hospitals |
| On-device inference tests on two mid-range Android phones | Testing on iOS and every Android version |
| Comparison with ResNet-50 and MobileNetV3 baselines | Regulatory or clinical validation |
Writing a Title That Holds Up
A strong title names the method and the application, and often hints at the outcome. It avoids buzzwords that promise more than the project delivers.
Table 15: Weak titles vs stronger titles
| Weak title | Why it fails | Stronger title |
| AI in Healthcare | Names a field, not a project | A Lightweight CNN for Diabetic Retinopathy Grading on Smartphone Fundus Images |
| Study of Solar Energy | No method, no problem, no outcome | Modified Grey Wolf Optimizer Based MPPT for Partially Shaded Rooftop PV Arrays |
| Smart IoT System Using ML | Stacks buzzwords without a contribution | Energy-Aware Authentication for LoRa-Based Agricultural Sensor Nodes |
| Use of Waste in Concrete | Too broad to test | Effect of Steel Slag as Partial Fine Aggregate Replacement on M30 Concrete Strength |
How Much Time Should Topic Selection Take?
Around four to six weeks is realistic for most students, ideally starting in the break before the third semester. The split below gives reading the biggest share on purpose. Everything else depends on it.
Figure 7: A suggested 5-week split for the topic selection phase
Common Mistakes That Derail M.Tech Topics
Table 16: Mistakes to avoid
| Mistake | Why it hurts | Fix |
| Chasing the trendiest buzzword | Crowded space and tough examiner questions | Pair the trend with a narrow, specific application |
| Copying a past-year project | No novelty and easy to spot on Shodhganga | Extend it with a clear new contribution or skip it |
| Keeping the scope too broad | Implementation never finishes | Write the out-of-scope list in Step 8 |
| Relying on unconfirmed data or hardware | Work stalls for weeks mid-semester | Get access confirmed in writing before approval |
| Picking only to please the supervisor | Motivation collapses by month six | Bring options the supervisor can shape, not a blank slate |
| Ignoring the publication angle | Misses an easy boost for PhD or job applications | Choose a measurable contribution from the start |
| Switching topics late | Loses most of Phase I | Rescope the existing topic instead of replacing it |
Active Research Areas by Branch in 2026
The table below is a starting point for Step 2, not a list of ready-made topics. Every area here is active, which also means every area is crowded at the top level. The gap still has to be found in the literature.
Table 17: Starting points by branch
| Branch | Areas with active research |
| Computer Science | Small and efficient language models, federated learning, explainable AI, edge AI, security for IoT and cloud systems |
| Electronics and Communication | Low-power VLSI and RISC-V design, 6G and mmWave systems, biomedical signal processing, hardware security |
| Electrical | EV charging and battery management, grid integration of renewables, SiC and GaN power electronics, microgrid control |
| Mechanical | Additive manufacturing, digital twins, thermal management of EV batteries, composite materials, predictive maintenance |
| Civil | Sustainable concrete using industrial waste, structural health monitoring, flood modelling with GIS, smart water networks |
| Chemical and Environmental | Green hydrogen, advanced wastewater treatment, carbon capture, biofuels |
The Final M.Tech Topic Checklist
Run through this list before submitting the topic to the department. Every box should be ticked. Any unticked box is a conversation to have with the supervisor now, not in the fourth semester.
| Fit and motivation | |
| ☐ | The topic sits inside a subject that held attention during coursework or internships |
| ☐ | The research style (simulation, hardware, data, analytical) matches existing strengths |
| ☐ | The topic supports the goal after M.Tech, such as a job or a PhD |
| ☐ | There is still curiosity about the problem after a month of reading |
| Research gap | |
| ☐ | At least 15 to 20 papers from the last three to five years are in the literature matrix |
| ☐ | The gap type is named (performance, methodological, contextual, data, validation or integration) |
| ☐ | Three to five recent papers clearly show the gap |
| ☐ | Shodhganga and recent conference proceedings show no near-identical work |
| Feasibility | |
| ☐ | Data source confirmed and accessible |
| ☐ | Compute, equipment and software licenses available for the full duration |
| ☐ | Missing skills can be learned within four to six weeks |
| ☐ | A month-wise timeline fits within both phases with buffer |
| ☐ | Costs are covered by the lab or a grant |
| Scoring, scope and approval | |
| ☐ | The RIGOR total is 80 or above, or the weak criterion has been rescoped |
| ☐ | The problem statement follows the template, with metric, baseline and constraint |
| ☐ | In-scope and out-of-scope lists are written down |
| ☐ | The title names the method and the application |
| ☐ | The concept note has been reviewed by the supervisor and ideally a senior scholar |
Frequently Asked Questions
When should an M.Tech student start looking for a topic?
Ideally by the end of the second semester. That leaves the semester break for reading, so the third semester can start with a short list instead of a blank page.
Can the M.Tech topic extend a B.Tech project?
Yes, as long as the M.Tech work adds a clear new contribution such as a new method or a hardware validation of earlier simulation results. Repeating the B.Tech work with a new title will not survive a careful examiner.
Is it fine to pick a topic outside the supervisor’s specialization?
It can work, but it is risky. Without a supervisor who knows the area, methodology problems surface late. A co-guide from another department or an industry mentor reduces that risk.
How many papers should be read before finalizing the topic?
Around 15 to 20 recent papers is a reasonable minimum to claim a gap. The final thesis literature review usually grows to 30 to 50 references as the work progresses.
Is a pure review or survey acceptable as an M.Tech dissertation?
Most universities expect implementation or experimental work. A survey makes an excellent first publication from Phase I, but it rarely stands alone as the full dissertation.
What if the chosen topic stops working halfway through?
Rescope rather than switch. Narrow the objectives or change the dataset, and reframe the contribution around what does work. Well-documented negative results, explaining why an approach did not work, are still a legitimate research outcome and are far better than restarting in month eight.