Minor Project‑II (EX-608) - Unit 1 Short Notes

UNIT 1: Project Initiation & Planning

This unit covers the foundational phase of defining, scoping, and planning a minor research/development project. Mastery of these concepts is essential for a successful project proposal and execution.

1.1 Understanding the Minor Project

• Definition & Purpose: A structured, time-bound academic exercise where a student synthesizes and applies knowledge from coursework to solve a defined problem or conduct research. It demonstrates independent learning and problem-solving ability.

• Minor Project‑I vs. II: Minor Project‑II typically involves greater complexity, depth of analysis, and more substantial deliverables (e.g., a functional prototype, a comprehensive research paper, or a detailed system design) compared to Project‑I.

• Key Stakeholders:

  • Student: Primary executor and owner of the project.

  • Guide/Supervisor: Provides mentorship, technical guidance, and evaluation.

  • Department: Sets academic standards and provides resources.

  • Industry/Client (if applicable): May provide a real-world problem and act as a secondary stakeholder.

[!TIP] Exam Focus: Be prepared to differentiate between Minor Project‑I and II based on scope, depth, and expected deliverables. Always identify all stakeholders in your proposal.

1.2 Problem Identification & Formulation

• Sources of Ideas: Industry pain points, gaps in academic literature (research gaps), social/environmental needs, and emerging technological trends.

• Identification Techniques:

  • Observation & Interaction: Directly engaging with users or processes.

  • Literature Survey: Identifying unresolved questions in published work.

  • Brainstorming: Generating a wide range of potential ideas.

  • SWOT Analysis: Assessing Strengths, Weaknesses, Opportunities, Threats related to a domain.

• Problem Statement: A clear, concise, and focused description of the issue to be addressed. It should answer: What is the problem? Who is affected? What are the consequences of not solving it?

• Project Objectives: Must adhere to SMART criteria:

$$\boxed{\text{SMART = Specific, Measurable, Achievable, Relevant, Time-bound}}$$

*Example:* "To develop and test a mobile application that reduces daily water wastage by at least 15% for residential users in Zone X, by [Month, Year]."

[!TIP] Common Pitfall: Avoid vague problem statements like "Improve education." Always specify the context, target user, and measurable impact.

1.3 Scope Definition & Management

• Project Scope: The total work required to deliver the project's outputs. It defines what is included (In‑Scope) and what is explicitly excluded (Out‑of‑Scope).

• Scope Statement: A documented description of the project scope, including major deliverables, boundaries, and constraints.

• Scope Creep: Uncontrolled changes or additions to the project scope without adjustments to time, cost, or resources. It is a primary cause of project failure.

• Work Breakdown Structure (WBS): A hierarchical decomposition of the total scope of work into manageable, deliverable-oriented components. It is the foundation for all planning.

  
  Level 1: Minor Project-II
  
    ├── Level 2: Research & Analysis
  
    │     ├── Task: Literature Review
  
    │     └── Task: Requirement Gathering
  
    ├── Level 2: System Design
  
    │     ├── Task: Architecture Design
  
    │     └── Task: UI/UX Mockups
  
    └── Level 2: Implementation & Testing
  
          ├── Task: Frontend Development
  
          └── Task: Unit & Integration Testing
  
  

• Deliverables List: A catalog of all tangible (software, report, prototype) and intangible (research findings, analysis) outcomes to be produced.

[!TIP] Exam Tip: You may be asked to create a simple WBS for a given problem. Remember: WBS is deliverable‑oriented, not activity‑oriented. It answers "What" needs to be delivered, not "How."

1.4 Preliminary Literature Review & Background Study

• Purpose: To understand the current state of knowledge, identify existing solutions, recognize methodologies, and justify the novelty of your proposed project.

• Process:

  1. Identify Keywords: From your problem statement.

  2. Search Databases: Use IEEE Xplore, Scopus, Google Scholar, etc.

  3. Select & Analyze: Focus on recent (last 5 years), high-quality, relevant publications.

  4. Synthesize: Group findings by theme, methodology, or outcome. Identify trends, contradictions, and gaps.

• Output: An annotated bibliography (summary + critique of each paper) or a summary matrix (a table comparing papers on criteria like year, method, findings, limitations).

• Link to Proposal: The review directly informs your problem statement, objectives, and methodology by showing what has been done and what remains to be done.

[!TIP] Key Skill: Do not just list papers. Synthesize them to tell a story about the research landscape and pinpoint where your project fits.

1.5 Project Methodology & Approach

• Selection Criteria: Choose based on project type (research vs. development), level of requirement certainty, need for client feedback, and team expertise.

• Common Methodologies:

  | Methodology | Best For | Key Phases | | :--- | :--- | :--- | | Waterfall | Well‑understood, stable requirements | Requirements → Design → Implementation → Testing → Maintenance | | Agile (Scrum) | Software with evolving requirements | Sprints (2‑4 wks), Daily Stand‑ups, Sprint Review/Planning | | Design Thinking | User‑centric, innovative solutions | Empathize → Define → Ideate → Prototype → Test | | Experimental | Testing hypotheses, cause‑effect relationships | Hypothesis → Experiment Design → Data Collection → Analysis | | Prototype Development | Building and iterating on a functional model | Build → Measure → Learn (Iterative) |

• Justification: In your proposal, explicitly state why your chosen methodology is the best fit for your project's objectives and constraints.

1.6 Feasibility Analysis

A preliminary assessment to determine if the project is viable. Conducted for five key areas:

[!TIP] Exam Alert: Be ready to define each feasibility type and give one example question for each. Economic feasibility often requires a basic CBA calculation.

1.7 Resource Planning & Estimation

• Resource Types:

  • Human: Student time (hours/week), Guide's time, any team members or external experts.

  • Material/Software: Specific sensors, development boards (Arduino/Raspberry Pi), software licenses (MATLAB, CAD), datasets.

  • Financial: Budget for hardware, software, travel, publication fees, contingency (~10%).

• Estimation Techniques:

  • Analogous Estimating: Using data from a similar past project.

  • Parametric Estimating: Using a statistical relationship (e.g., cost = $X per line of code).

• Scheduling Tool: A preliminary Gantt Chart for major phases/milestones, showing start/end dates and dependencies.

[!TIP] Practical Tip: Underestimate human resource availability (student time) and overestimate task duration to build in buffer. Always list all resources, even freely available ones (e.g., open-source software).

1.8 Risk Assessment & Management (Preliminary)

• Risk Identification: Brainstorm potential threats (e.g., "guide unavailable," "key component delayed," "algorithm performance below expectation").

• Qualitative Analysis: Use a Probability & Impact Matrix to prioritize risks.

  
  High Impact
  
     │
  
     │  High Risk   │  Medium Risk  │
  
     ├─────────────┼───────────────┤
  
     │  Medium Risk│  Low Risk     │
  
     └─────────────┴───────────────┘
  
            Low    Medium   High Probability
  
  

• Risk Register: A simple table to log key risks.

  | Risk | Probability (H/M/L) | Impact (H/M/L) | Mitigation Strategy | | :--- | :--- | :--- | :--- | | Delay in component delivery | M | H | Identify alternative supplier; order early. |

• Initial Mitigation: For high-priority risks, define a contingency plan (action if risk occurs) or avoidance strategy.

[!TIP] Common Mistake: Students often list only technical risks. Remember managerial (guide feedback delays) and external (university holidays, market changes) risks are equally important.

1.9 Documentation & Proposal Writing

• Standard Proposal Structure:

  1. Title Page

  2. Problem Statement (Clear & concise)

  3. Objectives (SMART)

  4. Scope (In/Out-of-scope, Deliverables)

  5. Methodology (Justified choice & phases)

  6. Preliminary Literature Review Summary (Key findings & gap)

  7. Feasibility Analysis (Brief 1‑2 lines per type)

  8. Timeline (Gantt chart for major phases)

  9. Resource Requirements (List with justification)

  10. Risk Analysis (Top 3‑5 risks from register)

  11. References (IEEE/APA format)

  12. Appendix (If any: detailed WBS, survey questionnaire)

• Writing Principles: Formal academic tone, clarity, conciseness, logical flow. The proposal is a contract with your guide—it sets expectations.

[!TIP] Pro Tip: Write the Abstract/Summary LAST. It should be a powerful, standalone snapshot of the entire proposal.

1.10 Project Kick‑off & Setting Up

• Initial Meeting: Discuss and finalize the proposal with your guide. Agree on expectations, meeting frequency (e.g., weekly), and evaluation milestones.

• Proposal Approval: Obtain formal sign-off from the guide and/or department. This marks the official project start.

• Setup Infrastructure:

  • Communication: Define primary channel (email, WhatsApp, Teams) and response expectations.

  • Version Control: Initialize a Git repository (GitHub/GitLab) from day one for all code and documents.

  • Document Storage: Use a shared cloud folder (Google Drive, OneDrive) with a clear folder structure.

• Create Detailed Project Plan: Break the approved proposal's WBS into weekly tasks, assign estimated hours, and populate a detailed Gantt chart for the entire semester.

[!TIP] Critical First Step: Setting up Git and a shared drive correctly at the start prevents massive confusion and version loss later. Document this setup in your project plan.