G15 Team Hextech 3 L Variety Store: Inventory Management System with Online Ordering - apcjlquesada/APC_2024_2025_3rd_Term_PROJMAN GitHub Wiki

Table of Contents

PROJECT TITLE

3 L Variety Store: Inventory Management System with Online Ordering

PROJECT MEMBERS

Project Professor

NAME

EMAIL

Jose Eugenio L. Quesada

[email protected]

Project Adviser

NAME

EMAIL

Gonzalo Gumogda

[email protected]

Project Team

NAME

ROLE

EMAIL

Timothy Louise R. Perez

Project Manager

[email protected]

Rainier Edward Lopez

Lead Developer

[email protected]

COMPANY PROFILE

Company Name:

3 L Variety Storer

Company Logo

Address:

Anubing Street, Brgy. Cogon, 6541 Ormoc City

Contact Number:

+63 908 750 4425

Line of Business:

Variety Store

Type of Customers:

Local residents

Stakeholders:

Lorena Lacorte Erano

Number of Employees:

TODO

1. BUSINESS CASE

1.1 Executive Summary

The 3-L Variety Store Inventory Management System with Online Ordering is a comprehensive digital solution designed and developed by HEXTECH to modernize and enhance the operational efficiency of a small retail enterprise. This system was created in response to the pressing need of the 3-L Variety Store to transition from its traditional, manual processes to a streamlined, automated platform capable of handling the complexities of inventory tracking, sales reporting, and customer ordering.

At its core, the system introduces a centralized and secure environment that allows store administrators and staff to monitor stock levels, generate accurate and timely reports, and manage product records efficiently. Through role-based access, administrative users can oversee the entire operation while general staff have limited but functional access to day-to-day tasks. A key feature of the system is its customer-facing online ordering module, which allows customers to browse available products, place orders, and receive updates—making the store more accessible and competitive in the digital marketplace.

The implementation of this system brings numerous benefits to 3-L Variety Store. It significantly reduces the risk of human error, stock discrepancies, and redundant processes. It also improves the accuracy of inventory forecasting, which is critical for maintaining optimal stock levels and meeting customer demands. Additionally, the digital interface empowers customers with convenience and transparency, fostering loyalty and increasing sales.

By replacing outdated manual tracking methods with an intelligent, user-friendly, and data-driven solution, the HEXTECH system elevates the store’s operational maturity. It not only addresses immediate concerns regarding inventory mismanagement and inefficiencies but also positions the business for growth in a tech-driven retail environment. This system is scalable and serves as a strong foundation for potential future integrations such as mobile app support, analytics dashboards, and POS system connectivity.

Ultimately, the 3-L Variety Store Inventory Management System is more than just a software deployment—it is a strategic investment in digital transformation aimed at enhancing customer satisfaction, improving internal controls, and securing long-term business sustainability.

1.1.1 Issue

The existing operations of the 3-L Variety Store are hindered by manual inventory tracking and order processing. Common issues include data inconsistency, stock mismanagement, human error in logging, and inefficient customer service. Additionally, the lack of online ordering capabilities limits customer reach and accessibility, especially in an increasingly digital marketplace.

1.1.2 Anticipated Outcomes

• Accurate real-time inventory monitoring • Reduction in stock losses and data entry errors • Faster and more efficient customer order processing • Better sales tracking and reporting for business decisions • Improved customer satisfaction through online accessibility

1.1.3 Recommendation

The HEXTECH system should be fully deployed at 3-L Variety Store. It addresses all identified issues by automating core functions and introducing modern tools for inventory and order management. With user-friendly interfaces and backend control, the system is scalable and can be extended in the future with features like sales analytics or payment integration.

1.1.4 Justification

The custom-built system is designed specifically for the workflow of 3-L Variety Store. Unlike generic commercial solutions, it caters to the store's specific needs without requiring monthly subscriptions or complex configurations. Its cost-effectiveness, ease of use, and positive performance in testing make it a practical and sustainable solution.

1.1.5 Business Case Analysis Team

Role Description Name
Product Manager Oversees the entire project and leads the team by delegating responsibilities, setting timelines, and organizing meetings to ensure steady progress. Timothy Louise R. Perez
Product Owner Represents the interests of the business, defines the project requirements, and ensuresthe final product delivers value to the stakeholders. Ms. Lorena Lacorte Erano
Scrum Master Guides the development team in applying Agile practices, facilitates Scrum ceremonies, and ensures the team adheres to Scrum principles. Timothy Louise R. Perez
Documentation Manager Handles all project-related documentation, including capturing key discussions from meetings and tracking progress throughout the development lifecycle Rainier Edward Lopez
Scrum Team Member Collaboratively work on building the system by completing assigned tasks and contributing to the team’s shared objectives. Rainier Edward Lopez
Stakeholder Offers direction on the project's scope and goals, serves as the main end-user of the system, and validates the system’s readiness for full deployment. Ms. Lorena Lacorte Erano
Class Adviser Provides academic oversight and mentorship to the team, ensuring that project execution aligns with course standards and expectations. Prof. Jose Eugenio Quesada
Project Adviser Supports the team with expert guidance, ensuring the project maintains its relevance, meets its objectives, and aligns with both technical and user requirements Prof. Gonzalo Gumogda

1.1.6 Problem Statement

Manual inventory handling at 3-L Variety Store results in frequent product tracking issues, delayed reporting, and limited customer access. Without automation, the store risks inefficiency, inventory losses, and missed sales opportunities in an increasingly competitive environment.

1.1.7 Organizational Impact

The system will digitize daily operations, shifting staff responsibilities from manual tracking to supervised system use. Migration includes minor training and hardware setup. It empowers staff with quick inventory searches, simplified data entry, and real-time updates. This change enhances internal control and enables the store to compete with businesses that use modern systems.

1.1.8 Technology Migration

The developed system will be implemented in a phased manner to avoid disrupting the business operations. Initial deployment will involve setting up the server infrastructure with the lead engineers on their premises, followed by integration with existing ERP systems and finally, user onboarding of the existing users. Selected data from the legacy system will be transformed to ensure compatibility with the new system. This includes product data, cake design data, and branch data.

1.2 Project Overview

1.2.1 Project Description

The project involves the design and development of a web-based inventory management system with online customer ordering. Admins and staff can manage products, view transactions, and generate reports. Customers can browse items, place orders, and receive updates.

1.2.2 Goals and Objectives

• Automate product management and stock monitoring • Provide secure, role-based access for store employees • Enable customers to place orders through an online portal • Ensure data integrity, easy access to records, and timely reports

1.2.3 Project Performance

Project performance was measured through documentation, system prototyping, and testing. Testing included unit tests, validation of user roles, and successful order placements. Results showed the system met functionality goals and responded well under typical use conditions.

1.2.4 Project Assumptions

The following are the preliminary assumptions for the project:

• Staff can learn basic system functions with minimal training • Internet connection and basic PC hardware are available • Customers have access to devices to place online orders

1.2.5 Project Constraints

• The system is designed for Windows environments only • Development was limited by academic timelines • External services like payment gateways or SMS notifications were not included • Budget constraints limited third-party integration and professional UI design

1.2.6 Major Project Milestones

• Planning & Proposal: January 2024 • System Design: February-March 2024 • System Development: March–December 2024 • Final Testing & Documentation: January-November 2025 • System Turnover to Client: December 2025

1.3 Strategic Alignment

This project supports the business goal of expanding operations, reducing manual workload, and improving customer service. It introduces digital capabilities necessary to remain competitive and opens the door for future enhancements such as mobile integration or e-commerce features.

1.4 Cost Benefit Analysis

1.4.1 Manpower Cost

• Development done as an academic project (no development salary) • Future maintenance estimated at ₱3,000 annually for local technician support

1.4.2 Hardware and Software Cost

• 1 Desktop Computer – ₱25,000 • Internet Setup – ₱1,200/month • Software Tools – Free (Django, Python, VS Code, GitHub)

1.4.3 Benefits

• 60% reduction in time spent on manual stock checks • Better inventory control leads to fewer product losses • Increased sales via online ordering access • Improved customer retention through digital services

1.5 Alternatives Analysis

• Alternative 1: Continue Manual Operations Pros: No financial investment Cons: High risk of errors, inefficiency, customer dissatisfaction • Alternative 2: Purchase Off-the-Shelf POS System Pros: Comprehensive features, support available Cons: Expensive, includes unneeded features, subscription fees • Alternative 3: Use Spreadsheets (MS Excel or Google Sheets) Pros: Low cost, flexible for simple tracking Cons: No access control, poor scalability, lacks automation and customer interface • Preferred Solution: HEXTECH’s Custom System Pros: Tailored to business needs, low cost, flexible, user-friendly Cons: Requires initial training, limited to Windows OS

2. Project Charter

2.1 Executive Summary

The 3-L Variety Store Inventory Management System with Online Ordering is a digital solution developed by HEXTECH as part of their capstone project. Its primary goal is to replace the store’s manual inventory processes with an automated system that includes inventory tracking, reporting, and an online ordering feature for customers. The system offers role-based access for admins and staff and provides a customer interface for viewing and ordering products. By streamlining operations and improving data accuracy, the project enhances productivity, minimizes errors, and increases sales opportunities through digital engagement.

2.2 Project Purpose/Justification

2.2.1 Business Need/Case

The 3-L Variety Store Inventory Management System with Online Ordering was initiated to address persistent inefficiencies in stock monitoring, manual sales recording, and customer order tracking. The previous manual process resulted in frequent inventory errors, stock mismanagement, and missed sales opportunities. The new system aims to automate inventory tracking, enable real-time reporting, and offer an online platform where customers can conveniently place orders. By introducing this digital solution, the store expects to reduce laborintensive processes and increase customer satisfaction, with cost recovery anticipated through operational efficiency and improved revenue flow.

2.2.2 Business Objectives

The objectives of this project directly align with the business’s plan to digitize operations and enhance customer engagement while minimizing inventory-related losses. • Develop and deploy a digital inventory management system with an online ordering portal within the next 60 days • Achieve at least a 70% reduction in inventory tracking errors within the first 3 months of deployment • Decrease product stockouts by 50% within the first 6 months • Improve order processing speed and customer response time by at least 40% in the first year • Establish a scalable digital infrastructure for future system expansions such as analytics dashboards or mobile support

2.3 Project Description

The 3-L Variety Store Inventory Management System with Online Ordering aims to modernize and streamline the store’s operations by replacing its manual inventory and ordering processes with a web-based platform. The system will allow administrators and staff to manage inventory, monitor transactions, and generate detailed sales and inventory reports. At the same time, customers will be able to browse product listings, place orders online, and receive real-time updates on their order status. This project will be developed using Django (Python), HTML, CSS, JavaScript, and will utilize SQLite as its backend database. The platform will be hosted on a Windows-based local server and will be accessible over a secure local area network.

2.3.1 Project Objectives and Success Criteria

The objectives outlined below support the overall milestones and deliverables necessary for successful deployment and adoption of the system within 3-L Variety Store’s daily operations: • Design and develop a functional web-based inventory and online ordering system within 60 days • Conduct thorough testing of system modules, including inventory tracking, reporting, and online customer interface, within the next 75 days • Train staff and deploy the system in a live environment with minimal disruptions to operations within the next 90 days • Achieve at least a 70% reduction in inventory and sales recording errors within the first 3 months post-deployment • Increase customer order engagement by 30% through the online platform in the first 6 months

2.3.2 Requirements

To ensure project success, the following requirements must be met: • The system must be tested on the store’s local server environment before going live • The solution must support multi-user access with role-based privileges for administrators, staff, and customers • The platform must include a secure and intuitive interface for customers placing orders • Reports must be exportable and readable for business analysis

2.3.3 Constraints

The following constraints have been identified: • The solution must be fully operational on Windows OS, as specified by the client • Only local network access is permitted due to the business’s limited internet connectivity • The development team consists of two core developers and limited support staff • Budget allocations restrict the use of enterprise-level cloud services or third-party APIs

2.3.4 Assumptions

Upon approval of this document, the following assumptions are considered agreed upon by all stakeholders: • Project stakeholders, including the store owner, fully support the transition from manual to digital systems • Sufficient training will be provided to the store’s staff to ensure a smooth adoption process • All system features outlined in the scope are considered critical and will not be deprioritized unless agreed upon by both the development team and the stakeholder

2.3.5 Preliminary Scope Statement

The 3-L Variety Store project includes the full-cycle design, development, testing, and deployment of a local inventory management and online ordering platform tailored to the store’s operational workflow. The project will also encompass the training of the end users and handover of the system upon deployment. All deliverables will be completed independently of the store’s day-to-day activities to minimize disruptions. Project funding, resource allocation, and delivery timeline will be monitored and managed by the project lead, with additional approvals required for scope or budget adjustments. The project will be considered complete upon successful deployment and approval by the store owner.

2.4 Risks

The following risks for the HEXTECH project have been identified. The project manager will determine and employ the necessary risk mitigation/avoidance strategies as appropriate to minimize the likelihood of these risks: • Potential disruption of store operations during system deployment and staff onboarding • Risk of low adoption due to staff unfamiliarity with digital tools • Internet connectivity issues affecting system performance and customer ordering • Hardware or software limitations, as the system is restricted to Windows environments • Possible delays in system updates due to academic or budgetary constraints

2.5 Project Deliverables

The following deliverables must be met upon the successful completion of the HEXTECH project. Any changes to these deliverables must be approved by the project sponsor: • Fully functional web-based inventory management system with role-based access • Online ordering module for customer use with real-time status updates • Technical documentation and user manual for administrative and staff use • Final project documentation including test results, use-case validations, and system architecture • Successful system deployment and turnover to the client (3-L Variety Store)

2.6 Summary Milestone Schedule

The project Summary Milestone Schedule is presented below. As requirements are more clearly defined this schedule may be modified. Any changes will be communicated through project status meetings by the project manager. • Planning & Proposal: January 2024 • System Design: February–March 2024 • System Development: March–December 2024 • Final Testing & Documentation: January–November 2025 • System Turnover to Client: December 2025

2.7 Summary Budget

The following section outlines a summary of the budget based on projected costs for essential project components. Summary Budget – Breakdown of Project Expenses Project Component Estimated Cost • Human Resources ₱46,000 Total Project Cost ₱46,000

2.8 Project Approval Requirements

Success for the HEXTECH project will be achieved when a fully tested and deployed inventory management and online ordering system is delivered to the 3-L Variety Store, along with complete documentation. The system must function smoothly in a real-world retail environment and meet all project objectives within the specified academic and budgetary constraints. Approval and project completion will be authorized by the stakeholders, Timothy Louise R. Perez and Rainier Edward Lopez, in consultation with the Project Adviser, Prof. Gonzalo Gumogda.

2.9 Project Manager

Timothy Louise R. Perez is named Project Manager for the duration of the HEXTECH project. Mr. Perez is responsible for coordinating all project activities, scheduling, development, and communication. His role includes managing system requirements, ensuring progress aligns with the academic calendar, and handling deployment logistics. He shares management and development responsibilities with Rainier Edward Lopez. The team operates under the guidance of Prof. Gonzalo Gumogda (Project Adviser) and Prof. Jose Eugenio Quesada (Class Adviser).

3. Stakeholders Management Strategy Plan

3.1 Introduction

Stakeholders are fundamental to the success of any project, as their engagement and collaboration significantly influence its outcome. For the Inventory Management System with Online Customer Ordering, recognizing and effectively managing key stakeholders is crucial to ensure a seamless design, implementation, and transition into operations. By clearly identifying stakeholders and understanding their expectations, influence, and roles, Team Hextech can proactively mitigate risks, resolve concerns, and align the system’s deliverables with organizational goals. This approach will contribute to the long-term viability and efficiency of the client's inventory and ordering processes.

3.2 Identify stakeholders

Team Hextech identified the project stakeholders through collaborative meetings and requirement-gathering sessions with the client. These sessions included interviews and analysis activities aimed at mapping individuals and groups who have a vested interest in or will be directly affected by the system. The stakeholder identification process involves: 1. Stakeholder Analysis – Utilizing a stakeholder mapping framework to categorize both internal and external stakeholders. Internal stakeholders include the staff who will interact with the system regularly, such as administrators and employees. External stakeholders encompass customers and business owners who rely on the system’s outputs. 2. Stakeholder Analysis Table – The team will prepare a comprehensive table outlining stakeholder roles, goals, level of influence, contributions, concerns, and system access or permissions. Engaging stakeholders throughout the project lifecycle will help ensure the system addresses actual user needs and supports sustainable use.

3.3 Key Stakeholders

Based on Team Hextech’s analysis and discussions with the client, the following individuals and groups are identified as key stakeholders in the project: 1. System Administrator (Admin User) – Responsible for overseeing the entire system’s operation including product management, inventory tracking, and user access. The administrator’s feedback is vital for refining usability and functionality. 2. Store Staff – They will use the system to update product availability, process orders, and generate transaction reports. Their familiarity and adaptability to the system will reflect its success at the operational level. 3. Inventory Manager – Responsible for monitoring stock levels, managing replenishments, and coordinating inventory adjustments within the system. The Inventory Manager ensures inventory accuracy and optimizes product availability, directly impacting operational efficiency.

4. Stakeholder Analysis

This section describes how the project team will analyze its list of identified stakeholders. The analysis involves categorizing stakeholders based on their influence, power, and involvement in the Inventory Management System with Online Customer Ordering project. Understanding each stakeholder’s role and potential impact enables Team HEXTECH to prioritize their needs, manage expectations, and tailor communication and engagement strategies accordingly.

5. Scope management

This plan outlines the scope of the 3-L Variety Store Inventory Management System with Online Ordering project, particularly what Team HEXTECH will deliver and how scope-related tasks will be monitored and verified. The scope management process will follow five key steps: requirements collection, scope definition, work breakdown structure creation, scope verification, and scope control.

5.2 Scope Management Approach

1. Authority and Responsibility for Scope Management. The project manager, Timothy Louise R. Perez, holds the primary authority and responsibility for defining, managing, and controlling the scope of this project. Support and validation will be provided by the project sponsor, Rainier Edward Lopez, and the project adviser, Prof. Gonzalo Gumogda.

2. Scope Definition. Initial documents such as the Business Case, Project Charter, and Stakeholder Management Plan contribute to defining the project’s scope. Succeeding deliverables, including the Work Breakdown Structure and Status Reports, will further clarify and reinforce the boundaries, tasks, and objectives of the project.

3. Scope Measurement and Verification. To ensure the project remains within scope and produces expected deliverables, the following methods will be used:

Documentation Review: Scope will be referenced against project documents including the Business Case and Charter.

QA Code Reviews: The project manager will lead quality assurance reviews to verify that the system features align with scope requirements.

Sponsor Approval: The project sponsor will validate whether the completed work meets the initially approved scope through sign-offs and testing sessions.

4. Scope Change Process. Team HEXTECH has the authority to propose and document scope changes, which must be reviewed and approved by the sponsor, Rainier Edward Lopez, and the project adviser, Prof. Gonzalo Gumogda. Any approved change will be updated in the change log and shared with stakeholders.

5. Acceptance of Final Project Deliverable. The final system will be accepted based on its adherence to the defined project scope. The project manager, Timothy Louise R. Perez, will ensure that all deliverables meet quality standards and that key stakeholders are informed of changes and satisfied with outcomes.

5.3 Roles and Responsibilities

Role name Who Responsibilities
Project Manager Timothy Louise R. Perez Oversees project execution, manages team activities, and ensures scope alignment
Full-stack Developer Rainier Edward Lopez Develops system backend and frontend features using Django, HTML, CSS, and JS
UI/UX Designer Rainier Edward Lopez Designs customer interface and admin dashboard
Documentation Manager Timothy Louise R. Perez Manages project documentation and reporting
Project Sponsor Ms. Lorena Lacorte Erano Approves scope, provides support, and signs off on major deliverables
Project Adviser Mr. Gonzalo Gumogda Ensures academic alignment and supports strategic decision-making

5.4 Scope Definition

As agreed upon by the Project Sponsor and Project Adviser, the project scope includes:

Development of a local web-based inventory management and online ordering system tailored for the 3-L Variety Store. The system will include:

Admin/staff login system with access control

Product catalog with create, read, update, delete (CRUD) functionalities

Real-time inventory management and low-stock alerts

Order processing system for customers with order status tracking

Dashboard reports for stock movement and transaction history

Deployment on Windows-based local server with LAN accessibility only

The project uses Supabase, HTML, CSS, JavaScript, and SQLite, and follows an Agile-inspired iterative development cycle. The scope is subject to revision with documented approval from the sponsor and adviser.

5.5 Project Scope Statement

Product Scope Description – The 3-L Variety Store Inventory Management System is a localized web application that supports the daily operations of the store. The platform allows administrators and staff to handle product entries, stock adjustments, and transaction logs, while providing customers a user-friendly interface for placing online orders.

Core Features:

Secure login system with role-based access

CRUD functionalities for products and categories

Order management system with order history and status tracking

Inventory monitoring with alerts for low-stock levels

Report generation for admins and staff

User-friendly UI accessible via local network

Product Acceptance Criteria – The project is considered successful and complete if:

All core features function according to the scope

System is deployed, tested, and accepted by the store owner

Documentation and user manual are submitted and verified

Sponsor and adviser provide formal approval for project closure

Project Deliverables

Fully functional inventory and ordering system

Complete system documentation (Business Case, Scope, Diagrams)

User manual for staff and admin users

Change and deployment logs

Stakeholder and Scope Management Plans

Project monitoring and final review reports

Project Exclusions

  • Mobile application version
  • Public cloud hosting or remote access outside local network
  • Post-project system maintenance or bug resolution
  • Integration with external services (e.g., payment gateways)
Project Constraints
  • System must operate on Windows and local network only
  • Project must be completed no later than November 2025
  • Limited budget prevents use of commercial APIs or cloud services
Project Assumptions

The following are the assumptions related to the project:

  • Required resources (PCs, local server, internet) will be available
  • Store staff will participate in testing and training
  • Stakeholders will be available for feedback and review
Team has full access to open-source tools required for development

5.6 Work Breakdown Structure

5.7 Scope Verification

Scope will be verified using the following:

 * Reviews with project sponsor and adviser 
 * Issue tracking via version control and project tools 
 * Deliverable testing by developers and users 
 * Formal sign-off on deliverables after demo and walkthrough sessions  

5.8 Scope Control

Scope changes will be controlled through:

 * Documentation tracking via the Change Management Plan 
 * Approval process led by sponsor and adviser 
 * Version updates and logs in the project status report 
 * Regular team meetings to review scope alignment 

6. Schedule management

6.1 Introduction

 The purpose of this Schedule Management Plan is to provide a structured approach for managing the timeline and development activities involved in the 3-L Variety Store Inventory Management System with Online Ordering. This plan ensures that the project remains aligned with its intended deliverables and academic milestones while remaining within scope and time constraints. 

Team HEXTECH adopted a blended Waterfall and Agile methodology for development. Initial planning and documentation followed a structured Waterfall approach, while development and implementation proceeded in iterative modules guided by Agile practices. This combination allowed the team to maintain clear progress tracking while remaining responsive to feedback and evolving client needs.

This plan outlines all major phases, significant deadlines, expected outputs, and team responsibilities. Procedures for managing scheduling changes are also provided to ensure that any delays or adjustments are handled transparently and proactively.

By following this Schedule Management Plan, the team aims to ensure timely project delivery, client satisfaction, and alignment with academic and business goals.

6.2 Schedule Management Approach

A. Scheduling Tools

To plan and track all phases and development tasks, Team HEXTECH used the following tools:

 * Trello for task management and sprint tracking 
 * Microsoft Word/Excel for timeline reporting and Gantt charts 
 * GitHub Projects for version tracking and collaboration 

These tools ensured full visibility of task progress, coordination among members, and documentation of updates and dependencies.

B. Project Phases

The HEXTECH project is organized into five core phases:

  1. Planning
  • Identify objectives and deliverables
  • Hold initial meetings with client (3-L Variety Store)
  • Prepare business case, charter, and stakeholder plans
  1. Analysis and Design
  • Conduct process analysis and gather client requirements
  • Draft and finalize ERD, DFDs, and wireframes
  • Outline technical specifications
  1. Development
  • Build backend, frontend, and database modules
  • Implement features incrementally with feedback cycles
  • Maintain documentation for each module completed
  1. Testing and Implementation
  • Perform unit, integration, and user testing
  • Conduct UAT with store staff
  • Finalize deployment and prepare for turnover
  1. Closeout
  • Final project walkthrough and approval by client
  • Submit final documentation
  • Conduct reflection and post-mortem evaluations

6.3 Schedule Milestones

Summary Milestone Schedule – Project Timeline Overview

Project Milestone

Target Date

Project Start

January 10, 2024

Kick-off and Initial Meeting

January 15, 2024

Business Case Finalization

February 5, 2024

ERD/DFD and Wireframes

March 15, 2024

Prototype Design

April 10, 2024

Backend and Frontend Development Begins

May 5, 2024

Sprint 1 (Core Admin Functions)

May 3, 2025

Sprint 2 (Inventory & Product Features)

May 10, 2025

Sprint 3 (Customer Online Ordering)

May 15, 2025

Alpha Testing and Revisions

October 30, 2025

Final Integration and System Testing

November 30, 2025

Deployment and Client Handover

December 10, 2025

Final Documentation and Closeout

December 15, 2025

6.4 Schedule Control

Controlling the schedule is essential to deliver the 3-L Variety Store system on time. Team HEXTECH will monitor tasks weekly and perform retrospectives at the end of each sprint. Task updates and changes will be logged in Trello and reviewed in meetings.

Roles and responsibilities include:

Project Manager (Timothy Louise R. Perez): Oversees schedule adherence, documents progress, and updates all stakeholders

Product Owner (Rainier Edward Lopez): Reviews deliverables and aligns project goals with client expectations

Scrum Master (Timothy Louise R. Perez): Facilitates team coordination, identifies blockers, and ensures velocity is maintained

Scrum Team: Completes assigned tasks on time and communicates progress or issues

Documentation Lead: Maintains schedule logs and documentation

Project Adviser and Class Adviser: Provide feedback on academic milestones and help realign schedules if needed

Schedule status will be reviewed every week in team check-ins. Any risk of delay will be discussed with the sponsor and adjusted accordingly.

Project Manager

Responsible for developing and maintaining the project schedule using tools such as Jira and OpenProject. They will track and communicate progress between members and stakeholders, as well as coordinate with the scrum master and product owner in relation to schedule adjustments.

Product Owner

Ensures the Whisk features and deliverables align with the sprint timeline and overall project goals by collaborating with the Project Manager and Scrum Team to assess and plan changes.

Scrum Master

Facilitates the team’s adherence to the sprint schedule and Scrum practices. They will monitor the sprints and address blockers, making sure the team can manage their workload in a timely manner.

Scrum Team

Develops and delivers sprint tasks as scheduled by reporting their progress during daily standup meets and communicate blockers to the Scrum Master.

Documentation Manager

Maintains accurate and timely project documentation.

Stakeholders

Stakeholders review and accept project deliverables as defined by the project goals and requirements.

Class Adviser and Project Adviser

They will be overseeing the project and its development, providing feedback and ensuring alignment with relevant goals.

To control and adapt the schedule throughout development:

  • Progress will be reviewed weekly during sprint planning and review sessions.
  • Changes will be documented and resolved collaboratively.
  • Any changes to the schedule will be discussed with stakeholders and advisers, with updated timelines recorded in OpenProject or Jira.

6.5 Schedule Changes and Thresholds

Thresholds for significant schedule changes will be monitored throughout development. If a task or milestone is delayed by more than 15% of the scheduled time, the team will file a formal schedule change request. Minor shifts that don’t affect the final deadline or key deliverables will be communicated informally to the Project Sponsor and Advisers.

All schedule changes will include:

Change reason and description

Impact analysis on other milestones

Revised timeline

Sponsor approval (if required)

This approach ensures both flexibility and accountability in schedule adjustments.

6.6 Scope Change

Any changes to the project scope must be documented with detailed explanation, rationale, and expected outcomes. Changes will only be accepted if reviewed by the team and approved by the Project Sponsor and Project Adviser. If a scope change impacts the schedule, it must be reflected in the updated schedule and communicated to all stakeholders.

7. Cost management

7.1 Introduction

The Cost Management Plan outlines how costs for the 3-L Variety Store Inventory Management System with Online Ordering will be tracked, managed, and controlled throughout the project lifecycle. It defines roles and responsibilities for cost oversight, specifies budget authority levels, describes how cost performance will be monitored, and establishes the format and frequency of cost-related reporting.

Specifically, it:

  • Identifies who manages and monitors project costs
  • Details how cost deviations are handled
  • Describes how budget changes are approved
  • Defines cost reporting frequency and format

7.2 Cost Management Approach

Costs will be managed at the level of major project components as outlined in the Work Breakdown Structure (WBS), focusing primarily on development and deployment activities. As this is a student-led capstone project, the team will use manual tracking tools such as spreadsheets and weekly status reports to monitor resource use and ensure all cost items stay within estimated values.

The Project Manager, Timothy Louise R. Perez, will be responsible for tracking all incurred costs, including manpower, utility usage, and other operational expenses, and for ensuring alignment with the planned project scope, schedule, and budget.

7.3 Reporting Format

All cost updates and summaries will be reported as part of the bi-weekly Project Status Reports. These reports will include:

  • Summary of actual costs compared to baseline estimates
  • Variances in labor hours or material costs (if applicable)
  • Notes on any pending or approved cost change requests
  • Recommendations or actions for correcting deviations

7.4 Cost Variance Response Process

A Cost Performance Index (CPI) or Schedule Performance Index (SPI) of less than 0.8 or greater than 1.2 will trigger corrective action. If a threshold is crossed, the Project Manager will notify the Project Sponsor (Rainier Edward Lopez) within three business days. Within five business days, the Project Manager will prepare a Cost Variance Corrective Action Plan, outlining:

  • Root cause of the variance
  • Impact on overall budget and timeline
  • Recommended corrective measures
  • Plan for monitoring the effectiveness of these actions
Once approved, the corrective plan will be incorporated into the official project documentation and project tracking tools will be updated accordingly.

7.5 Cost Change Control Process

Any proposed changes that affect the overall budget must go through a formal change request process. Each request must include:

  • A clear justification for the change
  • A detailed impact assessment on timeline and scope
  • A recommended resolution plan
All cost-related changes must be reviewed and approved by the Project Sponsor. No cost changes are allowed without written approval.

7.6 Project Budget

Summary Budget – Estimated Project Costs

Category

Rate

Hours

Estimated Cost

Developer (Hextech)

₱120/hour

300 hrs

₱36,000

QA & Documentation

₱100/hour

50 hrs

₱5,000

Deployment

₱50/hour

50 hrs

₱2,500

Hardware & Software

Existing store equipment & open-source tools used

₱0

Electricity/Operations

Store-based setup, minimal additional usage

₱0

Miscellaneous Buffer

Contingency for local testing or printing

₱0

Total Estimated Cost: ₱42,500

8. OpenProject Work Breakdown Structure

8.1 Introduction

The Work Breakdown Structure (WBS) presented here represents all the work required to complete the 3-L Variety Store Inventory Management System with Online Ordering project. It organizes the project into manageable sections for planning, assignment, tracking, and delivery.

8.2 Outline View

3-L Variety Store Inventory & Ordering System

 Planning 
 • Problem and Project Scope 
 • Fact-Finding 
 • Feasibility Assessment 
 • Project Charter 
 • Development Timeline 
 System Analysis & Design 
 • Requirement Gathering 
 • Data Flow & Entity-Relationship Modeling 
 • Interface Design 
 • Database Schema Design 
 Development 
 • Backend Development 
 • Frontend Development 
 • Inventory Management Module 
 • Customer Ordering Module 
 • Admin Dashboard 
 • Testing & Debugging 
 Deployment 
 • Documentation Compilation 
 • User Training 
 • Final System Installation 
 Project Management 
 • Task Assignment and Monitoring 
 • Weekly Team Coordination Meetings 
 • Stakeholder and Risk Management 
 Closeout 
 • Final Client Presentation 
 • Sign-off and Acceptance 
 • Archive All Project Assets 

8.3 Hierarchical Structure

8.4 Tabular View

8.5 Tree Structure View

8.6 WBS Dictionary

8.7 Glossary of Terms

Level of Effort (LOE): The amount of labor required to complete a task or deliverable. WBS Code: A unique identifier used to indicate the position of a task in the WBS hierarchy. Work Package: A manageable section of the project containing deliverables or defined activities. WBS Component: Any element within a WBS, including a work package or higher-level task. WBS Element: A single identifiable unit in a WBS, which can contain work or other sub-elements.





9. OpenProject Work Packages

10. Resource management

10.1 Introduction

This document outlines the resource management strategy for the 3-L Variety Store E-Commerce System project. It defines the qualifications and responsibilities of each team member to ensure effective execution. This strategy supports the project team in delivering a functional inventory and sales system integrated with a customer-facing mobile application, developed by the MNTSDEV team.

10.2 Roles and Responsibilities

10.3 Project Organizational Charts

10.4 Staffing Management

Given that the project is conducted under the project-based learning framework of Asia Pacific College in partnership with 3-L Variety Store, the necessary human resources are already in place. Members of Team Hextech are expected to take on various roles throughout the project's duration. To ensure efficiency and a balanced workload, it is recommended that team members are distributed appropriately across all key roles defined in this document. The following table outlines the proposed staffing structure and management plan for the project.

11. Quality Management

11.1 Introduction

This Quality Management Plan outlines how Team Hextech will ensure the delivery of a reliable and efficient E-Commerce and Inventory Management System for 3-L Variety Store. Quality will be prioritized across all stages of development, focusing on performance, security, usability, compatibility, and scalability. Our approach promotes adaptability, team feedback, and frequent testing to maintain high standards from start to finish.

11.2 Quality Management Approach

Quality will be managed proactively by applying key principles and continuous review cycles. The team will focus on the following practices:

  • Requirement Review – Project requirements will be clearly defined, measurable, and aligned with the store’s business needs. Both functional and non-functional requirements will be documented to ensure traceability.
  • Test Planning – A test plan will guide testing scope, techniques, and tools to ensure consistency and effectiveness throughout all test phases.
  • Test Execution – The team will carry out tests based on defined cases, recording and resolving issues as they emerge.
  • Performance Testing – The system will be tested under different usage conditions to ensure that response times and operations remain stable during high loads.
  • Security Testing – Code and system vulnerabilities will be assessed, with best practices in security integrated to mitigate threats.
  • Usability Testing – End users will evaluate the application to provide insights for refining the interface and user experience.

11.3 Quality Requirements / Standards

To meet the required level of quality, the system must comply with the following:

  • Functional Requirements – The application must perform key operations such as inventory updates, sales processing, barcode scanning, and predictive restocking.
  • Performance Requirements – The system must respond within acceptable time limits, including optimized load times and smooth real-time updates.
  • Security Requirements – Data must be protected through encrypted communication, secure login, and role-based access.
  • Compatibility Requirements – The system must function consistently across devices, operating systems, and browsers.
  • Usability Requirements – The interface must be easy to navigate, visually accessible, and user-friendly for both staff and customers.
  • Scalability Requirements – The architecture must accommodate increasing users and data without performance degradation.
  • Compliance Requirements – Project outputs must comply with academic requirements and client specifications.
  • Documentation Standards – All deliverables including manuals, system architecture, and records must follow a clear and organized format.

11.4 Quality Assurance

The Team Hextech will apply consistent practices to uphold quality during development and evaluation:

  • Defined Standards – The project’s quality benchmarks will be documented and shared with all contributors and stakeholders.
  • Continuous Improvement – Issues identified in audits or team feedback will be analyzed and used to improve both the product and internal processes.
  • Compliance with Best Practices – The system will align with standards related to software security, accessibility, and privacy.

11.5 Quality Control

To make sure that deliverables meet expectations, the team will implement the following control measures:

  • Code Review – Developers will perform regular peer reviews to catch logic errors, maintain consistency, and ensure quality standards are followed.
  • Unit Testing – Core functions will be tested in isolation to validate that individual modules work as intended.
  • Integration Testing – Combined components will be tested to confirm seamless interaction and data flow between them.
  • User Acceptance Testing (UAT) – Users will interact with the system in realistic scenarios and provide feedback on usability, effectiveness, and performance.
  • Security Testing – Security checks will include assessments for common vulnerabilities and testing of access controls and data handling.
  • Monitoring and Maintenance – After deployment, the system will be monitored for bugs, performance issues, and necessary updates to maintain reliability.

11.6 Quality Control Measurements

For the MNTSDEV E-Commerce System, quality control is embedded within every sprint and development cycle to ensure the platform delivers a seamless inventory and sales system integrated with a mobile customer interface. Quality checks are aligned with Agile workflows and tracked through GitHub Projects, where issues, tasks, and improvements are monitored in real time.

The following measurements will be consistently recorded:

  • Measurement Date
  • Measurement Type
  • Findings
  • Reference Requirement
  • Responsible Member (Execution)
  • Responsible Member (Review)
  • Corrective Actions Taken
  • Date of Resolution
  • Responsible Member (Implementation)
Dashboards within GitHub will present live status updates of open bugs, resolved tickets, code coverage, and deployment verifications. These metrics will be reviewed during sprint retrospectives to ensure continuous improvement in system stability, usability, and feature accuracy.

The team aims to uphold project-wide transparency and performance standards by keeping all quality activities visible and traceable throughout the development process. This ensures that all system modules—from sales reporting to user authentication—meet the required benchmarks before delivery.

12. Risk Management

12.1 Introduction

In a digital system that manages both real-time inventory and customer orders, risks are unavoidable—from stock inaccuracies to security threats or system errors during peak order times. This Risk Management Plan outlines how the project team will systematically identify, evaluate, address, and monitor potential risks that could disrupt the development or operation of the Inventory Management System with Online Ordering for 3-L Variety Store. By managing risks proactively, the team aims to protect customer experience, ensure accurate stock levels, and deliver a reliable system aligned with business goals.

12.2 Top Three Risks

  • System Downtime During Business Hours
 Description: Risk of unplanned system outages or crashes during store hours due to server failure, bugs, or high traffic. 
 Impact: High — Interrupts customer transactions, resulting in potential revenue loss and negative customer experience. 
 Likelihood: Medium 
  • Inventory Mismatch or Sync Errors
 Description: Risk of discrepancies between the actual and system-recorded inventory due to syncing delays or bugs in the inventory management module. 
 Impact: High — Can result in customer complaints, over-ordering, or stockouts. 
 Likelihood: Medium 
  • Security Breach (Unauthorized Access or Data Leak)
 Description: Risk of unauthorized access to admin functions or leakage of customer data due to security misconfigurations or lack of encryption. 
 Impact: Critical — Can lead to data loss, legal issues, and loss of customer trust. 
 Likelihood: Medium 

12.3 Risk Management Approach

The project team will integrate risk assessment into sprint planning, stand-ups, and retrospectives. All risks will be documented in a live Risk Register, and the team will actively assess and update risk status during development. Key risks will be tracked with owners and mitigation plans to avoid delays and ensure quality.

12.4 Risk Identification

Risks were identified using the following approaches:

  • Brainstorming sessions with team members and advisers
  • Reviewing similar inventory-based projects
  • Technical consultations with cybersecurity and full-stack experts
  • Analysis of user requirements and stakeholder expectations
A centralized risk register will store all identified risks along with categories, status, and action plans. Risk identification is ongoing and reviewed every sprint.

12.5 Risk Qualification and Prioritization

Each risk is assigned a score based on its likelihood and impact and visualized in a probability-impact matrix. Risks marked “High” in both aspects will be prioritized for mitigation or avoidance. The team will update prioritization regularly based on testing and stakeholder input.

12.6 Risk Monitoring

Risks will be discussed bi-weekly in progress meetings. Key risks are also tracked on the project dashboard and marked in Jira for sprint-based visibility. Any changes in risk level will be flagged immediately, and all updates will be shared with both the technical team and stakeholders through the documentation manager.

12.7 Risk Mitigation and Avoidance

System Downtime During Business Hours

 Mitigation Strategy: 

Implement load testing early in development

Use monitoring tools to track uptime and respond to alerts quickly

Prepare hotfix deployment procedures

 Avoidance: 

Schedule deployments and updates during off-peak hours

Inventory Mismatch or Sync Errors

 Mitigation Strategy: 

Conduct unit and integration testing for the inventory sync module

Use logging for every inventory update

Validate stock levels using automated nightly checks

 Avoidance: 

Apply transactional database logic to prevent race conditions

Security Breach (Unauthorized Access or Data Leak)

 Mitigation Strategy: 

Apply role-based access controls

Enable data encryption in transit and at rest

Conduct security audits before release

 Avoidance: 

Minimize direct user access to sensitive functions in the MVP

Avoid storing plain-text sensitive data like passwords or emails

Risk Register

13. Communication management

13.1 Introduction

Effective communication is essential to the success of the 3-L Variety Store inventory management system with e-commerce. This plan outlines how information will be shared among the project stakeholders, defining communication methods, frequency, responsible parties, and protocols to maintain alignment and ensure smooth progress.

13.2 Communications Management Approach

The Project Manager will lead communication efforts, ensuring regular updates to the team, sponsors, and clients. Any changes to the project scope or schedule will be promptly shared to prevent misunderstandings or delays. Communication will combine face-to-face meetings with digital tools to encourage collaboration and quick resolution of issues.

13.3 Communications Management Constraints

  • Timing: Messages must be timely to keep the project on track. Approval is needed for any modifications to the communication process.
  • Availability: Team members balance academic and project commitments, so flexibility in scheduling is essential.
  • Channels: Meetings will be held physically on campus or online through platforms like Microsoft Teams or Google Meet. Confidentiality is maintained by limiting access to authorized personnel only.

13.4 Stakeholder Communication Requirements

Key stakeholders include the 3-L Variety Store owners, the development team, and project sponsors. Their communication preferences and needs are documented in the communications matrix and flowchart.

13.5 Roles

13.6 Project Team Directory

13.7 Communication Methods and Technologies

Communication will be conducted through:

  • Email for formal notifications and sharing documents
  • Microsoft Teams / Google Meet for meetings
  • Jira/OpenProject for task and sprint management
  • GitHub for source control and issue tracking
  • Facebook Messenger for quick informal communication

13.8 Communications Matrix

13.9 Communication Flowchart

13.10 Guidelines for Meetings

  • Agendas and related materials are sent out the day before meetings.
  • Minutes document key points and are promptly shared.
  • Attendance is expected unless excused in advance.
  • A note-taker records and distributes meeting minutes.

13.11 Communication Standards

  • All files and documents follow APC naming and formatting standards.
  • Collaboration tools ensure transparency and track project progress.

13.12 Communication Escalation Process

13.13 Glossary of Communication Terminology

  • Project Sponsor: Oversees funding and major decisions.
  • Communication Flowchart: Diagram showing info flow among stakeholders.
  • Communication Matrix: Summary table of communication types and methods.
  • Escalation: Steps for timely resolution of issues.

14. Change management

14.1 Introduction

The Change Management Plan ensures that any modifications to the project—whether they involve timeline shifts, feature adjustments, resource reallocations, or requirement changes—are evaluated, approved, and executed in a controlled manner. As the development of the E-Commerce System for 3L Variety Store progresses, unexpected changes may arise. Having a structured approach enables the team to manage these adjustments efficiently, with minimal disruption and full transparency.

14.2 Change Control Board

The Change Control Board (CCB) is responsible for reviewing and deciding on all change requests submitted during the project. Their role is to make sure proposed changes align with the system’s goals, stay within scope, and do not negatively impact the timeline or budget.

Primary Functions of the CCB:

  • Review and assess change requests and their impact on the project.
  • Decide whether to approve, reject, or delay a proposed change.
  • Ensure all approved changes are aligned with business goals and user needs.
  • Communicate decisions to all relevant stakeholders.

14.3 Roles and Responsibilities

Only changes approved by the CCB will be implemented. Unapproved change requests will still be documented for reference.

14.4 Change Control Process

The following standardized steps outline how change requests are handled throughout the project:

Change Request Submission

 Any team member or stakeholder may submit a Change Request Form via GitHub Issues or Jira. The form must include a clear description, reason for the change, urgency level, and its expected impact on the project. 

Initial Review

 The Project Manager logs and reviews the submitted change request to ensure all required information is provided. If valid, the request is forwarded to the Change Control Board for further evaluation. 

Impact Analysis

 The development team, including the Technical Lead and/or Developer, collaborates with the Product Owner to analyze the possible effects on budget, timeline, scope, and technical feasibility. The analysis is then submitted to the CCB for decision-making. 

CCB Decision

 The Change Control Board (CCB)—composed of the Owner, Project Manager, Scrum Master, and Developer—reviews the analysis and votes to approve, reject, or defer the change. 

All decisions are documented.

Rationale is communicated to the team and stakeholders through tools like GitHub, Jira, and OpenProject.

Implementation (if approved)

 The Project Manager updates project plans, documentation, and backlogs accordingly. Approved changes are assigned to relevant sprints or upcoming development phases. 

Communication

 All project stakeholders are notified of the decision and updated plans. Corresponding documentation and tools (e.g., Jira, GitHub, OpenProject) are updated to reflect changes. 

Monitoring

 The Scrum Master oversees the implementation and evaluates its impact to ensure the change does not cause delays, regressions, or misalignment with project goals. 

15. Implementation/Transition

15.1 Executive Summary

This transition-out plan outlines the structured process for handing over the 3L Variety Store E-Commerce System from the MNTSDEV development team to the client. The goal is to ensure a smooth transition that allows the store’s internal staff to operate, maintain, and enhance the system with minimal disruption.

Development began on May 11, 2024, and the system is scheduled to be fully deployed and transitioned between July 28 to October 10, 2025. The system was built using widely supported technologies that align with the client’s capabilities and infrastructure to ease onboarding.

15.2 Transition Team Organization

15.3 Workforce Transition

The Team Hextech will remain separate from the client organization. However, they are available for extended consultation or future feature requests as needed through a freelance or contract agreement.

15.4 Work Execution During Transition

15.5 Property Transition

15.5.1 Intellectual Property

The client will receive all deliverables, including source code, documentation, and media assets. While MNTSDEV retains authorship rights over reusable components, full usage and deployment rights will be licensed to 3L Variety Store.

15.5.2 User Accounts and Passwords

Initial admin and staff accounts were created for testing and demonstration. These will be disabled post-deployment and replaced with official staff accounts assigned by the client.

15.6 Knowledge Transfer

The client will be granted access to the project’s management platforms, including GitHub, Jira, and Microsoft SharePoint. These tools will provide the client with all relevant documentation and tasks, such as user manuals and development documentation. Additionally, Team Hextech will be available for consultation sessions every weekend following the deployment to assist with any questions or issues that may arise.

15.7 Schedule

⚠️ **GitHub.com Fallback** ⚠️