Table of Contents PROJECT TITLE PROJECT MEMBERS Project Professor Project Adviser Project Team COMPANY PROFILE 1. BUSINESS CASE 1.1 Executive Summary 1.1.1 Issue 1.1.2 Anticipated Outcomes 1.1.3 Recommendation 1.1.4 Justification 1.1.5 Business Case Analysis Team 1.1.6 Problem Statement 1.1.7 Organizational Impact 1.1.8 Technology Migration 1.2 Project Overview 1.2.1 Project Description 1.2.2 Goals and Objectives 1.2.3 Project Performance 1.2.4 Project Assumptions 1.2.5 Project Constraints 1.2.6 Major Project Milestones 1.3 Strategic Alignment 1.4 Cost Benefit Analysis 1.4.1 Manpower Cost 1.4.2 Hardware and Software Cost 1.4.3 Maintenance Cost 1.4.4 Benefits 1.5 Alternatives Analysis 1.5.1 Status Quo 1.5.2 AWS/Azure/GCP 1.5.3 Migrating to ERP with Ordering Feature 2. Project Charter 2.1 Executive Summary 2.2 Project Purpose/Justification 2.2.1 Business Need/Case 2.2.2 Business Objectives 2.3 Project Description 2.3.1 Project Objectives and Success Criteria 2.3.2 Requirements 2.3.3 Constraints 2.3.4 Assumptions 2.3.5 Preliminary Scope Statement 2.4 Risks 2.5 Project Deliverables 2.6 Summary Milestone Schedule 2.7 Summary Budget 2.8 Project Approval Requirements 2.9 Project Manager 3. Stakeholders Management Strategy Plan 3.1 Introduction 3.2 Identify stakeholders 3.3 Key Stakeholders 4. Stakeholder Analysis 5. Scope management 5.2 Scope Management Approach 5.3 Roles and Responsibilities 5.4 Scope Definition 5.5 Project Scope Statement 5.6 Work Breakdown Structure 5.7 Scope Verification 5.8 Scope Control 6. Schedule management 6.1 Introduction 6.2 Schedule Management Approach 6.3 Schedule Milestones 6.4 Schedule Control 6.5 Schedule Changes and Thresholds 6.6 Scope Change 7. Cost management 7.1 Introduction 7.2 Cost Management Approach 7.3 Reporting Format 7.4 Cost Variance Response Process 7.5 Cost Change Control Process 7.6 Project Budget 8. OpenProject Work Breakdown Structure 8.1 Introduction 8.2 Outline View 8.3 Hierarchical Structure 8.4 Tabular View 8.5 Tree Structure View 8.6 WBS Dictionary 8.7 Glossary of Terms 9. OpenProject Work Packages 10. Resource management 10.1 Introduction 10.2 Roles and Responsibilities 10.3 Project Organizational Charts 10.4 Staffing Management 11. Quality Management 11.1 Introduction 11.2 Quality Management Approach 11.3 Quality Requirements / Standards 11.4 Quality Assurance 11.5 Quality Control 11.6 Quality Control Measurements 12. Risk Management 12.1 Introduction 12.2 Top Three Risks 12.3 Risk Management Approach 12.4 Risk Identification 12.5 Risk Qualification and Prioritization 12.6 Risk Monitoring 12.7 Risk Mitigation and Avoidance 13. Communication management 13.1 Introduction 13.2 Communications Management Approach 13.3 Communications Management Constraints 13.4 Stakeholder Communication Requirements 13.5 Roles 13.6 Project Team Directory 13.7 Communication Methods and Technologies 13.8 Communications Matrix 13.9 Communication Flowchart 13.10 Guidelines for Meetings 13.11 Communication Standards 13.12 Communication Escalation Process 13.13 Glossary of Communication Terminology 14. Change management 14.1 Introduction 14.2 Change Control Board 14.3 Roles and Responsibilities 14.4 Change Control Process 15. Implementation/Transition 15.1 Executive Summary 15.2 Transition Team Organization 15.3 Workforce Transition 15.4 Work Execution During Transition 15.5 Property Transition 15.5.1 Intellectual Property 15.5.2 User Accounts and Passwords 15.6 Knowledge Transfer 15.7 Schedule

NAME	EMAIL
Jose Eugenio L. Quesada	[email protected]

NAME	EMAIL
Jose Eugenio L. Quesada	[email protected]

NAME	ROLE	EMAIL
Justin Clark H. Ong	Project Manager	[email protected]
Brylle Ace Nuñez	Lead Developer	[email protected]
Maryrose Pergis	Graphic Designer	[email protected]
Paul Damian Mariano	Documentation Manager	[email protected]

Company Name:	Bakers' Fair
Company Logo
Address:	1016-1020 Oroquieta Street, Sta. Cruz Manila, Philippines
Contact Number:	+63 2 567-1234 / +63 2 736-0483
Line of Business:	Bakery
Type of Customers:	Local residents
Stakeholders:	Thomas Ong
Number of Employees:	TODO

Bakers’ Fair’s current existing stock and cake ordering systems are fragmented and inefficient, this has led to operational challenges that have been growing in concern due to their rapid expansion. The limitations brought upon by the operational challenges cause delays, stockouts, and poor user experience which impacts both branch operations as well as management oversight.

In order to address the aforementioned challenges, the project proposes the development and implementation of an integrated web-based stock and cake ordering system. The system will streamline the existing business processes, improve data management, enhance user experience, and support scalability for future growth unlike the dated systems.

The project will be following a phased deployment strategy in order to minimize business disruptions, migrating the selected data from the legacy system and ensuring full integration with the pre-existing ERP system. The project aligns with Baker’s Fair’s goal of expanding its market reach across CALABARZON and Northern Luzon via the optimization of its internal operations.

The expected outcomes involve improved operational efficiency, quicker and more reliable ordering processes, better decision-making via data-driven insights, and enhanced customer satisfaction. The success of the project will be measured via usability feedback, system performance, and functional completeness.

A cost-benefit analysis highlights that there are significant long-term operational savings as well as scalability benefits compared to having to maintain the current processes. Alternative solutions such as hosting on cloud platforms or migrating to a different ERP system with built-in ordering features were considered but was seen as risky due to potentially higher operational costs or causing business process disruptions. Therefore, the decision to develop a custom web-based system was selected as the best solution.

Bakers’ Fair’s current stock and cake ordering systems are fragmented and outdated, resulting in inefficient workflows, delays, frequent stockouts, and inconsistent user experience. These issues are magnified by the company’s rapid expansion, hindering the ability of both branch-level operations and head office management to make timely, accurate decisions.

The implementation of the proposed system is expected to result in significant improvements across various operational areas. It will enhance overall efficiency by streamlining the stock and cake ordering processes into a unified platform. The solution will allow faster and more reliable transaction handling, leading to quicker order fulfillment and reduced operational lag. Additionally, it will enable data-driven decision-making by providing centralized access to accurate and timely information. Customer satisfaction is expected to rise as a result of the fewer order errors and delays, and the system's ability to scale with the business will support Bakers’ Fair’s long-term expansion objectives. Project success will be evaluated through usability feedback, system performance benchmarks, and the completeness of required functionalities.

Develop and deploy a custom, web-based integrated stock and cake ordering system. This system should be designed to consolidate existing fragmented processes, integrate with the current ERP, and provide a scalable platform that supports future growth. The solution will be rolled out in phases to minimize operational disruption.

A custom-built web application is the most viable solution given the nature of the problems and the scale of operations at Bakers’ Fair. Compared to maintaining the current process or migrating to a new ERP system, a tailored solution offers greater flexibility, operational control, and compatibility with existing workflows. The cost-benefit analysis shows that this option leads to significant long-term savings, primarily by reducing the frequency of order failures, stock discrepancies, and the time spent on manual processing.

Alternative approaches, such as hosting the solution on cloud platforms or switching to ERP systems with built-in ordering capabilities, introduce risks related to higher operating expenses, potential vendor lock-in, and major workflow disruptions. On the other hand a custom solution can be developed using existing infrastructure and open-source technologies, keeping costs manageable while still being able to deliver a system aligned with the company’s strategic goal of expanding operations in CALABARZON and Northern Luzon.

Role	Description	Name
Product Manager	He is responsible for managing the project and its members, including assigning tasks and scheduling meetings.	Justin Clark Ong
Product Owner	He is responsible for the product and	Mr. Thomas Ong
Scrum Master	He is responsible for facilitating the agile development process and ensuring that the team is following the Scrum methodologies.	Justin Clark Ong
Documentation Manager	She is responsible for managing documentation for the project, particularly with documenting meeting discussions and project progress.	Maryrose Pergis
Scrum Team Member	They are responsible for completing the project deliverables and working together with the rest of the team to ensure success of the project.	Brylle Nunez Maryrose Pergis Paul Damian Mariano
Stakeholder	He is responsible for providing input on the project’s scope. He is the primary beneficiary of the developed and deployed system. He will approve the system’s readiness for deployment and ensure a smooth transition from development to full implementation.	Mr. Thomas Ong
Class Adviser	He is responsible for providing guidance and support to the Project Manager and team using relevant project management principles. He ensures that the project aligns with the academic requirements.	Prof. Jose Eugenio Quesada
Project Adviser	He is responsible for providing guidance and support to the team. He ensures that the project has value and actually meets the agreed upon objectives between product owner and the scrum team.	Prof. Jose Eugenio Quesada

As Bakers’ Fair experiences rapid expansion throughout Luzon, the existing stock ordering and cake ordering system struggles to support operational demands, leading to inefficiencies, data management issues, and scalability issues. With the rudimentary and outdated solution, the company faces delays and failures in ordering cakes and stock replenishment, resulting in losses and compromised user experience for both store owners and head management.

The proposed project will introduce a new stock and cake ordering system to replace the old and fragmented process. In this system, stock ordering is now integrated with the cake ordering system, reducing the need for another separate subsystem. Additionally, the integrated ordering system has several novel features that aims to improve the user experience of store owners, head office managers, and customers. These include generative AI, 3D graphics, machine learning model, and modern user interface (UI) frameworks for aesthetics.

The introduction of this system will unify roles and responsibilities in maintaining the application that are otherwise not defined clearly in the old system, giving them new meaning; These are system administrators, branch managers, head office managers, and cake designers.

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.

This project focuses on the need for Bakers’ Fair to develop a new stock and cake ordering system due to the rapid expansion of their business that affects the scalability and usability of the current system. The main goal of the project is to integrate the business process from separate systems to a single unified system, moving Bakers’ Fair ordering business process from native desktop application to a web application. With an integrated web-based application, maintainability of the system is readily attainable and ordering process will be standardized.

This project aims to make the business process of Bakers’ Fair specifically their stock ordering and cake ordering processes more efficient by delivering a web-based platform to facilitate the process. This and other objectives of the to-be system are enumerated as follows:

• Ability to submit cake and stock orders that adheres to RESTful design standards which provides a more faster and more reliable method for performing such business process.
• Ability to provide a dashboard interface to provide predictive insights into the ordering process with the aim of reducing stockouts.
• Ability to store and manage cake designs to be used in cake ordering in a standardized and structured manner, replacing the current unstructured file-based approach.

The success of the project will be measured based on the following performance indicators:

• Usability and Acceptance – user feedback is one of the best ways to measure whether the system developed is likely to be adopted by the stakeholders.
• Performance – if the system proved to be much more performant than the current process in terms of average request/response time or latency.
• Functional completeness – all the expected operations succeed in testing and production environments.

The following are the preliminary assumptions for the project:

1. The system will only be accessible by Bakers’ Fair staff, particularly the store owners, head office staff, and system administrators.
2. Bakers’ Fair IT department has the necessary resources to support the development, testing, deployment, and maintenance of the system.
3. The scrum team possess the relevant skills to learn and apply the company’s technology stack in developing the system, such as AngularJS, ASP.NET Core 6, and SQL Server.

The following are the preliminary constraints for the project:

1. Cost – the project is limited within the allotted funds.
2. Schedule – the project is limited by the timeline imposed by stakeholders or outside sources.
3. Scope – the project only addresses a specific business domain of the company, it will not affect the current enterprise resource planning system of the company.
4. Resources – there will be one lead developer, two supporting developers, and one security specialist that will manage the system development.

Project Milestone	Target Date (mm/dd/yyyy)
Project Start	03/20/2024
Complete Solution Design	11/14/2024
Acquire Hardware and Software	11/20/2024
Complete Ordering System with New Hardware/Software	03/13/2025
Complete and Tested Ordering System	11/21/2025
Deploy Solution	11/21/2025
Project Complete	11/21/2025

The development of this system aligns with the strategic plan of Bakers’ Fair in terms of further expanding its operations throughout nearby Luzon regions such as CALABARZON and parts of Northern Luzon. As quoted in their web site:

“Realizing the need to reach more customers, Bakers’ Fair chose to expand to more cities outside Metro Manila. This is why you can always find a Bakers’ Fair branch near you – whether you’re in the heart of the city, or in Bulacan, Alabang, Antipolo, Cavite or Laguna. Just look for the nearest bus station, wet market, public school, town church or shopping mall.”

By developing this system, we allow Bakers’ Fair to realize its goal to expand its reach starting from the upper management down to the franchisers who will spearhead the operations of the company. With a new system ready to accept orders – may it be stock replenishment or made-to-order cakes – expansion will be much more attainable than staying with the current process which is likely to hinder if not delay them from achieving the strategic plan.

Based on the meetings with Bakers’ Fair, the labor cost of the team who will work on the project for more than a year are as follows:

1. Project Manager/Security Analyst. The hourly rate for a project manager in Bakers’ Fair is at most Php 168. The estimated working hours of the project manager in the project are 383, totaling Php 64,447.
2. Full-stack Developer. The hourly rate for the full-stack developer in Bakers’ Fair is at most Php 134. The estimated working hours of the full-stack developer are 386, totaling Php 51,961.
3. Graphic Designer. The hourly rate for the graphic designer in Bakers’ Fair is at most Php 96. The estimated working hours of the graphic designer in the project are 200, totaling Php 19278.
4. Frontend Developer. The hourly rate for the frontend developer in Bakers’ Fair is at most Php 96. The estimated working hours of the frontend developer in the project are 209, totaling Php 20,144.

The total manpower cost estimate in this project is Php 155,832.

There is no cost for the procurement of hardware and software licenses as there are already existing devices and software ready to be deployed and used by Bakers’ Fair staff, and the tools that the company mainly use are free and open-source, such as OpenVPN services.

Since the company will be using open-source tools and hosting their servers on-premises, the following cost elements are estimated:

1. Electricity costs. As of April 2025, Meralco rates are Php 13.01 per kWh. Since the servers are ran daily with no downtime, and standard server racks consume about 5 kW, the total cost per year for running the servers is Php 1,368,547.

By accomplishing this project, the following benefits will be realized:

1. Standardized communication for stock ordering. The system is expected to standardize the way branch managers submit and create stock orders. By eliminating the use of flat-file communication, the risks of failed and poorly estimated stock orders are reduced.
2. Standardized communication for cake ordering. Likewise, there is a standard way of ordering and tracking cake orders within the system, reducing fragmentation from using flat files.
3. Enhanced user experience. The system uses modern frameworks and design patterns that aim to give better user experience for the branch managers, head office managers, and cake designers.

In this option, Bakers’ Fair continues to perform the current process.

Pros: No need to hire developers or provision new servers. Staff are already familiar with the current processes.

Cons: The current process remains rudimentary, failure-prone, delay-prone, and fragmented.

In this option, Bakers’ Fair would host the new system in the cloud from a selected provider.

Pros: Provisioning servers would be easier to do, and development, testing, and deployment is faster than on-premises. Also, scalability and flexibility are guaranteed if the system is deployed in the cloud.

Cons: Possible increased operational expenditure, vendor lock-in, privacy issues, and unexpected costs that might be incurred in the cloud.

In this option, Bakers’ Fair chooses to migrate their existing business processes from the current ERP to the one with an ordering feature enabled, such as Odoo

Pros: Provides an all-in-one, integrated solution with built-in ordering capabilities, reducing the need for multiple disconnected systems.

Cons: The migration process may incur significant costs, including data migration, retraining, and customization. Additionally, the selected ERP (e.g., Odoo) may be overly opinionated, requiring Bakers’ Fair entire IT department along with other departments to adapt its workflows to fit the system rather than the other way around.

Whisk is a software solution that aims to replace and improve the current desktop-based production assessment system of Bakers' Fair, a rising bakery chain in the National Capital Region and beyond. Bakers’ Fair is currently struggling with the expansion of its business operations due to inefficiencies brought on by its obsolete systems, such as inaccuracies in managing orders. The primary objective of this project is to develop and deploy a web-based system using AngularJS, C# .NET, and Microsoft SQL for Bakers' Fair. This is to improve order management, inventory tracking, and user experience of the system users of Bakers' Fair.

The Whisk project has been created to streamline and optimize ordering processes in Bakers’ Fair, with the goal of reducing stockouts and errors. The costs associated with the successful design and implementation of these ordering mechanisms will be recovered as a result of the anticipated reduction in opportunity loss.

The business objectives for this project are in direct support of our corporate strategic plan to reduce stockouts and improve the reliability of ordering.

• Design a new ordering system within the next 30 days
• Complete implementation of the new ordering system within the next 365 days
• Reduce the amount of stockouts within the first half of store opening hours by 50% in the first year of deployment

The Whisk project will reduce stockouts in the stores of Bakers’ Fair through the implementation of sales forecasting and reliable ordering systems. The Whisk project will utilize the current technological stack of .NET, AngularJS, Keycloak, and Microsoft SQL to ensure smooth integration with the company’s current systems. The system will be deployed on the company’s onsite servers and accessed remotely by branches through OpenVPN, secured by both a password login and a private SSL certificate.

The objectives which mutually support the milestones and deliverables for this project have been identified. To achieve success on the Whisk project, the following objectives must be met within the designated time and budget allocations:

• Develop a functional sales forecasting solution to present to the head of IT within the next 20 days
• Create a simulated testing solution for the project’s APIs to stress test in preparation for real-world workloads within the next 60 days

The objectives which mutually support the milestones and deliverables for this project have been identified. In order to achieve success on the ISA project, the following objectives must be met within the designated time and budget allocations:

• Develop security solution methodology to present to the VP of Technology within the next 20 days
• Complete list of required hardware/software which meets budget allocation within the next 25 days
• Create a simulated solution in the IT lab using all purchased hardware and software to test the solution within the next 60 days
• Achieve a simulated solution which allows no security breaches and complete testing within the next 90 days
• Implement the solution across the organization within the next 120 days

This project must meet the following list of requirements in order to achieve success:

• The solution must be tested in the IT lab prior to deployment
• Solution must be implemented without disruption to operations

This project must meet the following list of requirements in order to achieve success.

• The solution must be tested in the IT lab prior to deployment
• Solution must be implemented without disruption to operations

Additional requirements may be added as necessary, with project sponsor approval, as the project moves forward.

The following constraints pertain to the Whisk project:

• All frameworks used must be compatible with our current IT platforms
• The software must meet the performance requirements while running on the server allocated for the project
• One lead developer, two supporting developers, and one security specialist will be provided as resources for this project

The following is a list of assumptions. Upon agreement and signature of this document, all parties acknowledge that these assumptions are true and correct:

• This project has the full support of the project sponsor, stakeholders, and all departments
• The purpose of this project will be communicated throughout the company prior to deployment
• The IT manager will provide additional resources if necessary

The Whisk project will include the design, testing, and delivery of an improved ordering system for the organization. All personnel and software resources will be managed by the project team. All project work will be independent of daily and ongoing operations and all required testing will be done in the IT laboratory. All project funding will be managed by the project manager up to and including the allocated amounts in this document. Any additional funding requires approval from the project sponsor. This project will conclude when the project is tested and deployed throughout the organization, as well as transitioned to custody of the client’s in-house development team.

The following risks for the Whisk 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 to operations during solution deployment and onboarding
• Potential overstocking from prediction inaccuracy
• Potential inefficiency from overloading of project endpoints

The following deliverables must be met upon the successful completion of the Whisk project. Any changes to these deliverables must be approved by the project sponsor.

• Fully deployed ordering system solution
• Technical documentation for the project’s forecasting solution
• User manual for branch managers, head office managers, and cake designer

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.

Summary Milestone Schedule – List key project milestones relative to project start.
Project Milestone	Target Date (mm/dd/yyyy)
Project Start	03/20/2024
Complete Solution Design	11/14/2024
Acquire Hardware and Software	11/20/2024
Complete Ordering System with New Hardware/Software	03/13/2025
Complete and Tested Ordering System	11/21/2025
Deploy Solution	11/21/2025
Project Complete	11/21/2025

The following table contains a summary budget based on the planned cost components and estimated costs required for successful completion of the project.

Hardware and software licensing costs are not listed as they are negligible due to existing assets from the client.

Summary Budget – List component project costs
Project Component	Component Cost
Personnel Resources	₱155,832
Total	₱155,832

Success for the Whisk project will be achieved when a fully tested ordering system solution, and all technical and user documentation, is fully deployed throughout the company within the time and cost constraints indicated in this charter. Success will be determined by the Project Sponsor, Mr. Thomas Ong, who will also authorize completion of the project.

Justin Clark Ong is named Project Manager for the duration of the Whisk project. Mr. Ong’s responsibility is to manage all project tasks, scheduling, and communication regarding the Whisk project. His team consists of one lead developer, two supporting developers, and one security specialist. Mr. Ong will coordinate all resource requirements through the IT department manager, Thomas Ong, who will serve as the Project Sponsor. Mr. Ong will provide weekly updates to the Project Sponsor.

Stakeholders are the anchor and support of projects, and their success is dependent on stakeholder involvement. And for Whisk, identifying and understanding key stakeholders is essential to ensure smooth development, implementation, and adoption of the system. By clearly defining and classifying stakeholders, the project team can proactively manage expectations, address concerns, and foster collaboration. This strategy ensures that the value delivered by the project aligns with stakeholder needs and contributes to the long-term success of Bakers’ Fair’s operations.

Team Chromatic decided on the stakeholders with the help of meeting sessions with Bakers’ Fair. These meetings included interviews and brainstorming activities to identify key players who are involved and interested in the system’s development and implementation.

The identification process will follow these steps:

1. Stakeholder Analysis – The team will utilize a stakeholder analysis framework to identify both internal and external stakeholders. Internal stakeholders will include employees directly involved in Bakers’ Fair’s operations (e.g., Branch Managers, Head Office Managers, Cake Designers, and IT Operations), while external stakeholders may include franchise owners and system implementers.
2. Stakeholder Analysis Table – The team will systematically define each stakeholder using a structured table that outlines their goals, required contributions, the power they will have within the webapp, concerns and constraints that they may face during the development.

Clear communication channels and active involvement of stakeholders will help align the system’s goals with the business needs of Bakers’ Fair

Based on the meetings and activities conducted by Team Chromatic and Bakers’ Fair, the following key stakeholders are identified:

1. Branch Managers – They are the franchise owners of Bakers’ Fair. Since they might be resistant to the change that the project may bring, their level of acceptability to the developed system will tell how successful the project is.
2. Head Office Managers – They head the production and logistics operations in the company; Since they will be managing all stock and cake orders, they are strongly affected by the project and their level of resistance will describe the success of the project.
3. Cake Designers – Similar to branch managers and head office managers, they will also use the system.
4. IT Operations and Development – They will be the intended recipient of the development materials in the system, particularly the codebase. With their support, it will be easier to plan how the project will be implemented.

This plan outlines the scope of the project Whisk, particularly what the team will do and what deliverables should be produced to ensure that the project remains on track. To this end, this document will follow a five-step process seen in various subsections: collection of requirements, definition of scope, creation of work breakdown structure, verification of the scope, and controlling of the scope.

1. Authority and Responsibility for Scope Management. The product manager, Justin Clark Ong, has the primary authority and responsibility for scope management, while the project sponsor, Mr. Thomas Ong, will provide support and guidance to define and improve the scope of the project at hand.

2. Scope Definition. The first documents presented: Project Charter, Business Case, and Stakeholder Management Plan should contribute to the definition of project scope. As well, the succeeding documents including this plan such as Work Breakdown Structure should provide understanding of the project’s scope, objectives, requirements, and current progress.

3. Scope Measurement and Verification. To measure the scope and verify it, the following procedures will be followed:

   1. Existing documentation. Documents such as the project charter will be used as a reference point to check if the actual works of the team faithfully follow the planned scope.

   2. QA reviews. Code reviews during the execution of the project that is also conducted by the product manager, Justin Ong, will make sure that the work done on the system aligns with the project scope.

   3. Project sponsor approval. The project sponsor’s feedback should tell if the actual work accomplished deviates from the scope of the project or not.

4. Scope Change Process. Team Chromatic has the authority to change the project’s scope, guided by the project sponsor, sir Thomas Ong, other relevant stakeholders, and project adviser, sir Joe Gene Quesada to ensure that changes being done in the project scope are meaningful, feasible, and necessary.

5. Acceptance of Final Project Deliverable. The final project deliverable must be accepted, and the project scope should be approved by the project sponsor, sir Thomas Ong. The team’s leader, Justin Clark Ong, will ensure that project deliverables submitted are according to the scope, and that the key stakeholders are updated with the changes made throughout the cycle.

Role name	Who	Responsibilities
Project Manager	Justin Clark Ong	Manages the whole scrum team and ensures that the project is planned and executed according to the scope.
Security Analyst/Tester	Justin Clark Ong	Ensures that the system developed for the project is secure, functional, and adheres to the defined scope and objectives.
Full-stack Web Developer	Brylle Ace Nunez	In charge of designing and implementing the frontend, backend, and database system using the required tools for the project.
Graphic Designer	Maryrose Pergis	In charge of designing various image assets such as logos to be used in the project.
3D Modeler	Maryrose Pergis	In charge of developing the 3D models of cake to be used in the project.
Frontend Developer	Paul Damian Mariano	Works closely with the project manager and full-stack developer in providing a visually appealing and user-friendly interface of the system.
Project Sponsor	Mr. Thomas Ong	In charge of providing necessary resources to realize the project, such as training support and technological support. They are also responsible for the planning, approval, and execution of the said project.
Project Adviser	Mr. Joe Gene Quesada	In charge of checking the required documentation for the project and providing support to the team to realize the project.

As approved by the Project Sponsor and Project Adviser, the identified scope of this project in line with the project-based learning (PBL) are as follows:

• Creation of a web application system using Angular, ASP.NET Core 6, and Microsoft SQL Server for Bakers’ Fair with the following requirements and/or features:

  1. The system is an integrated cake and stock ordering system to manage cake and stock orders to be used by branch managers and head office managers.

  2. The system has the following extra features that should provide support for the intended audience of the system: 3D cake models, generative AI, and machine learning forecasting model.

  3. The system is not available in the public internet, but it is only accessible via a virtual private network hosted in the premises of Bakers’ Fair.

• The development of the system follows that of Agile Methodology.

The scope is subject to change if either the team or project sponsor deem the suggested changes to be necessary.

Product Scope Description – Whisk is a web application for the staff of Bakers’ Fair which provides a unified platform for managing cake and stock order operations that adopts modern industry standards. In this system, the system shall provide the following functions:

• Create, read, update, and delete cake orders
• Create, read, update, and delete stock orders
• Create, read, update, and delete cake designs
• Dashboard interface for sales visualization
• Forecasting mechanism for sales prediction

Product Acceptance Criteria – this project will be deemed successful once the following criteria have been met:

• The system is fully functional according to the defined objectives in the project scope statement and relevant documents such as project charter.
• Project sponsor formally approves the final deployment of the system, confirming that it meets all functional and non-functional requirements, aligns with the intended project objectives, and adheres to expected design standards.
• The developed system is successfully deployed and tested both by the developers and intended users.

Project Deliverables

The following list of deliverables should be ready by the end of the project cycle:

• Fully functional system
• Complete documentation for the system (requirements, diagrams, etc.)
• User manual
• Business Case
• Stakeholders Strategy Management Plan
• Scope Management Plan
• Cost Management Plan
• Time Management Plan
• Human Resource Management Plan
• Communication Management Plan
• Procurement Management Plan
• Project Status Reports Distribution Plan
• Change Request Documentation
• Project Execution Monitoring Report
• Implementation Plan
• Change Management Plan
• Project Status Reports
• Transition-out Plan
• Project Turn-over Plan
• Post-Project Review Plan

Project Exclusions

The following is outside of the scope of the project:

• Integration of other subsystems or modules by the company that are not explicitly mentioned in the agreed-upon project scope.
• Any fixes, bug resolutions, or improvements required after the project is fully turned over are not included in the scope.
• The system will not be developed on any other platforms such as mobile platforms.
• Ongoing maintenance after the project completion is not included in the project scope.

Project Constraints

The following are the constraints related to the project:

• Availability of the hardware and software needed to execute the development process by each team member
• Legal barriers or constraints that the system might encounter as it will be used by a legitimate business entity
• Limited time and financial resources of the development team (e.g., the project must be finished no later than November 2025.)

Project Assumptions

The following are the assumptions related to the project:

• All necessary funding and resources are available upon request throughout the duration of the project.
• All key stakeholders should be able to provide input as needed throughout the duration of the project.
• The project team should have the necessary expertise and skill sets needed to accomplish the project.
• The project team will use the recommended tools by the project sponsor needed to realize the system.

The project team will use various techniques for scope verification as referenced in Project Scope Statement to guarantee that the Whisk System project deliverables satisfy the original scope. An example includes close collaboration with the Product Sponsor and Project Adviser via online or onsite meetings, emails, and messaging in reviewing the proposed charter and guaranteeing that all needs have been met, and deliverables are aligned with the objectives.

Quality Checklists. The checklists in the form of OpenProject tickets or GitHub issues, among other things will be used by the team to ensure that the functionality of the project meets the requirements and quality standards of the Project Sponsor.

Work Performance Measurements. The quality of output of each project member will be measured through insights provided by OpenProject, GitHub, and/or Jira.

Scope Baseline. Scope baseline is provided by the work breakdown structure acting as the snapshot of the original scope.

Formal Acceptance. This subsection provides key documents where the Project Sponsor has accepted the product of the project. This could include the Scrum Reviews, Deed of Donation document, or any formal document that acknowledges the deliverables by the Project Sponsor.

The related documents such as project charter and change management plan should be monitored closely if the project scope is changed, as procedures and key deliverables are being followed. Aside from the reference documentation, the team must consult with the Product Sponsor and/or Project Adviser to confirm changes to the project scope so that transparency is preserved.

The purpose of this Schedule Management Plan is to provide a structured approach to managing the timeline and activities involved in the development and implementation of the Whisk Web Application Project. This plan serves as a guide to ensure that the project remains on track, within scope, and aligned with its intended goals and deliverables.

Team Chromatic will be using Waterfall and Agile Scrum Methodology throughout the development of Whisk. Foundational planning and requirements gathering will follow a Waterfall approach, while development and implementation will proceed in iterative sprints guided by Agile principles. This strategy allows the team to maintain clear documentation and structure, while remaining adaptable to change and continuous feedback.

The Schedule Management Plan outlines the key phases of the project, significant milestones, expected deliverables, and estimated timeframes. It also defines the responsibilities of each team member in maintaining the timeline, managing dependencies, and addressing potential delays. Procedures for handling changes to the schedule are included to ensure that risks are managed proactively and transparently.

By following this plan, the Whisk project aims to ensure smooth execution, timely delivery, and stakeholder satisfaction at every stage of development.

A. Scheduling Tools

To plan, track, and manage the progress of activities and phases, Team Chromatic will employ the following tools:

• Microsoft SharePoint for documentation and team collaboration.
• Jira for managing Agile sprints, tasks, and issue tracking.
• OpenProject for extended documentation and client transparency.

These tools enable transparency, accountability, and real-time updates throughout the project lifecycle.

B. Project Phases

The Whisk project is divided into five main phases, each with a distinct focus:

1. Planning
   • Define goals, scope, user requirements, and objectives.
   • Draft high-level documentation and create the Sprint Plan.
   • Assign initial roles and responsibilities.
2. Analysis and Design
   • Analyze business processes and user needs.
   • Develop wireframes, data models, and system architecture.
   • Finalize technical specifications to guide the development team.
3. Development
   • Implement features in iterative 2-week sprints.
   • Conduct sprint reviews and planning for each cycle.
   • Ensure continuous integration and feedback.
4. Implementation
   • Perform functional, usability, and performance testing.
   • Gather user feedback and address issues.
   • Begin deployment preparations and finalize user manuals.
5. Closeout
   • Conduct system handover and user training.
   • Finalize documentation.
   • Evaluate project success through stakeholder feedback and retrospectives.

The Summary Milestone Schedule for Whisk will guide the overall timeline. As requirements become clearer and tasks evolve, adjustments may be made. All schedule changes will be evaluated, documented, and communicated during regular stand-ups or project meetings.

Summary Milestone Schedule - List key project milestones relative to project start
Project Milestone	Target Date (mm/dd/yyyy)
Project Start	3/20/2024
Planning Kick-off meeting Project initiation Initial Meeting with Client (Online) Onsite meet with client Project proposal drafting Project proposal approval	01/04/2024 04/25/2024 05/27/2024 05/31/2024 06/01/2024 06/31/2024
Analysis and Design DFD and ERD drafting Initial diagrams presentation Project diagram finalization Initial Prototype development	08/13/2024 09/15/2024 10/04/2024 10/29/2024
Development Working prototype evaluation Release 1 Evaluation Finalization of Release 1 Release 2 Evaluation Finalization of Release 2 Release 2 Evaluation Finalization of Release 2 Refinement Refinement of working release	11/25/2024 01/15/2025 01/22/2025 02/01/2025 02/17/2025 03/13/2025 03/22/2025 04/17/2025 05/19/2025
Testing Quality control and test case evaluation Stress Testing	08/11/2025 09/19/2025
Implementation Finalized webapp deployment	10/11/2025
Closeout Project closeout meeting	11/30/2025

Controlling the schedule is important to ensure the successful and timely completion of Whisk. Team Chromatic will be implementing active monitoring and clear distribution of workloads among all members and those highly involved in the project. Schedule control will be maintained through regular sprint planning, reviews, and adaptive responses to any unforeseen challenges or delays.

To maintain control over the schedule, the following roles and responsibilities have been established:

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.

For Whisk, boundary conditions and scheduling thresholds will be established through careful consultation between the team and the client. The team will monitor the schedule as it changes during development, and this includes revised, removed or new project goals or features. Any adjustments made outside of the original plan will be carefully assessed to determine their impact. If it is identified that the changes exceed the defined thresholds, a schedule change request will be filed. Changes that fall below the threshold, such as minor adjustments that do not significantly impact the project's critical path or deliverables, will be discussed with the Project Sponsor for informal approval. Maintaining transparency throughout the process ensures the team remains on track with project goals, while retaining the flexibility to adapt to changing needs.

Scope changes during the development must be documented in detail, ensuring transparency, clarity and accountability. The nature of change, rationale, and impact of a change will be documented, and clear expectations for new deliveries, timelines and outcomes will be discussed and established.

The Cost Management Plan defines how the costs for the WHISK project will be managed throughout its lifecycle. It outlines the roles, responsibilities, and standards by which project costs will be measured, reported, and controlled. Specifically, it:

• Identifies who manages costs
• Specifies authority levels for budget changes
• Details how cost performance is measured
• Establishes reporting formats and frequencies

Cost accounts will be managed at the level of key deliverables as defined in the Work Breakdown Structure (WBS). In the absence of a Project Management Information System (PMIS), we will monitor costs by major roles and resource categories (e.g., development, design, operations). The cost data will be tracked against planned hours and rates to ensure resource usage aligns with the project scope and timeline.

Cost-related performance will be included in the monthly project status report. This report will contain:

• Summary of current costs vs. baseline
• Variance explanations (if any)
• Recommended corrective actions
• Status of any approved budget changes

The Control Thresholds for this project are a CPI or SPI of less than 0.8 or greater than 1.2. If the project reaches one of these Control Thresholds a Cost Variance Corrective Action Plan is required. The Project Manager will present the Project Sponsor with options for corrective actions within five business days from when the cost variance is first reported. Within three business days from when the Project Sponsor selects a corrective action option, the Project Manager will present the Project Sponsor with a formal Cost Variance Corrective Action Plan. The Cost Variance Corrective Action Plan will detail the actions necessary to bring the project back within budget and how the effectiveness of the actions in the plan will be measured. Upon acceptance of the Cost Variance Corrective Action Plan, it will become a part of the project plan, and the project will be updated to reflect the corrective actions.

All proposed changes impacting cost require a formal change request submitted to the Project Sponsor. Each change must include:

• Justification
• Impact assessment
• Proposed resolution

No changes to project costs will be implemented without written approval from the Sponsor.

Category	Rate	Hours	Total
Full-stack Developer	Php 134/hour	386	Php 51,961
Frontend Developer	Php 96/hour	209	Php 20,144
Graphic Designer	Php 96/hour	200	Php 19,278
Total Manpower			Php 91,383
Server Electricity	Php 13.01/kWh × 5 kW × 24/7 usage/year	-	Php 1,368,547
Hardware/Software	Existing hardware/software will be reused	-	-

The Work Breakdown Structure presented here represents all the work required to complete this project.

1. Integrated Ordering System
   1. Planning
      1. Problem and Project Scope
      2. Fact-Finding
      3. Evaluate Feasibility
      4. Project Charter
      5. Roadmap
   2. System Analysis & Design
      1. Data Modeling
      2. System Design
      3. Database Design
   3. Development
      1. System Onboarding
      2. Backend Development
      3. Frontend Development
      4. Quality Assurance Testing
   4. Deployment
      1. Project Management
      2. Project Status Meetings
      3. Risk Management
   5. Closeout
      1. Project Turnover
      2. Gain Formal Acceptance
      3. Archive Files/Documents

The hierarchal structure is similar to the outline view but without indentation. Although this format is more difficult to read, it may be useful where you have many levels and indenting each level would make the table to large to fit into a document.

Level	WBS Code	Element Name
1	1	Integrated Ordering System
2	1.1	Planning
3	1.1.1	Problem and Scope
3	1.1.2	Fact-Finding
3	1.1.3	Evaluate Feasibility
3	1.1.4	Project Charter
3	1.1.5	Roadmap
2	1.2	System Analysis & Design
3	1.2.1	Data Modeling
3	1.2.2	System Design
3	1.2.3	Database Design
2	1.3	Development
3	1.3.1	System Onboarding
3	1.3.2	Backend Development
3	1.3.3	Frontend Development
3	1.3.4	Quality Assurance Testing
2	1.4	Deployment
3	1.4.1	Project Management
3	1.4.2	Project Status Meetings
3	1.4.3	Risk Management
2	1.5	Closeout
3	1.5.1	Project Turnover
3	1.5.2	Gain Formal Acceptance
3	1.5.3	Archive Files/Documents

Level 1	Level 2	Level 3
1 Integrated Ordering System	1.1 Planning	1.1.1 Problem and Project Scope 1.1.2 Fact-Finding 1.1.3 Evaluate Feasibility 1.1.4 Project Charter 1.1.5 Roadmap
	1.2 System Analysis & Design	1.2.1 Data Modeling 1.2.2 System Design 1.2.3 Database Design
	1.3 Development	1.3.1 System Onboarding 1.3.2 Backend Development 1.3.3 Frontend Development 1.3.4 Quality Assurance Testing
	1.4 Deployment	1.4.1 Project Management 1.4.2 Project Status Meetings 1.4.3 Risk Management
	1.5 Closeout	1.5.1 Project Turnover 1.5.2 Gain Formal Acceptance 1.5.3 Archive Files/Documents

Level	WBS Code	Element Name	Definition
1	1	Integrated Ordering System	All work to implement an integrated ordering system.
2	1.1	Planning	The work for planning the project.
3	1.1.1	Problem and Scope	Identifying the problem and defining the scope to be covered by the system.
3	1.1.2	Fact-Finding	Researching existing literature and solutions to solve the problem.
3	1.1.3	Evaluate Feasibility	Evaluating the feasibility of various solutions.
3	1.1.4	Project Charter	Project Manager to develop Project Charter.
3	1.1.5	Roadmap	The schedule for the development of the system.
2	1.2	System Analysis & Design	The analysis and design of system components.
3	1.2.1	Data Modeling	Defining the flow and structure of data in the system.
3	1.2.2	System Design	Defining the system functions and output.
3	1.2.3	Database Design	Defining the rows, tables, and relationships for the database.
2	1.3	Development	The work to create a functional system.
3	1.3.1	System Onboarding	Onboarding to the systems used by the client.
3	1.3.2	Backend Development	Developing the backend system.
3	1.3.3	Frontend Development	Developing the frontend system.
3	1.3.4	Quality Assurance Testing	Testing the developed systems for security vulnerabilities and bugs.
2	1.4	Deployment	The work to deploy the completed system.
3	1.4.1	Project Management	Overall project management for the project.
3	1.4.2	Project Status Meetings	Weekly team status meetings.
3	1.4.3	Risk Management	Risk management efforts as defined in the Risk Management Plan.
2	1.5	Closeout	The work to close-out the project.
3	1.5.1	Project Turnover	The turnover of the project to the client.
3	1.5.2	Gain Formal Acceptance	The Project Sponsor formally accepts the project by signing the acceptance document included in the project plan.
3	1.5.3	Archive Files/Documents	All project related files and documents are formally archived.

Level of Effort: Level of Effort (LOE) is how much work is required to complete a task.

WBS Code: A unique identifier assigned to each element in a Work Breakdown Structure for the purpose of designating the elements hierarchical location within the WBS.

Work Package: A Work Package is a deliverable or work component at the lowest level of its WBS branch.

WBS Component: A component of a WBS which is located at any level. It can be a Work Package or a WBS Element as there's no restriction on what a WBS Component is.

WBS Element: A WBS Element is a single WBS component and its associated attributes located anywhere within a WBS. A WBS Element can contain work, or it can contain other WBS Elements or Work Packages.

This document is developed to outline the strategy for managing human resources in this project, which is necessary in clarifying the qualifications of each member in their assigned role to ensure that the human resources are capable in realizing the end goal of the project. The project manager and the project team, in turn, can use this as a guide to the key responsibilities and capabilities of the project team.

Role	Authority	Responsibility	Competency
Project Sponsor	Key decision-making authority for the project; approves or denies changes in the project scope	Provides necessary resources for the project; Reviews deliverables and changes in the project lifecycle.	Should know key business processes and business management skills.
Project Manager	Oversees the project execution	Manages the whole project cycle, from planning to closeout; They manage the key human resources for the project; They facilitate communication between key stakeholders.	Should know advanced project management and system development skills.
Scrum Master	Conducts the Agile Scrum methodologies	Manages the agile development process and ensures that the team is conducting proper Scrum ceremonies.	Should possess organizational and collaboration skills and be competent enough to follow and lead with a scrum framework.
Scrum Team	Designs, develops, and tests the system	Works closely with project manager and scrum master to accomplish project deliverables.	Should know at least basic system analysis, design, and development skills alongside Agile skills.
Documentation Team	Manages the key documentation for the project	Manages the project documentation.	Should possess project management skills, system development skills, and technical writing skills.
Project Adviser	Provides support, recommendations, and guidance to the team throughout the project cycle	Manages the project team by providing guidance and recommendations on the project and its methodologies.	Should be a bona fide faculty of School of Computing and Information Technologies in Asia Pacific College

The following diagram illustrates the organizational chart of the Whisk project.

As human resources requirements are already satisfied due to the project-based learning curriculum of Asia Pacific College and partnership with Bakers’ Fair. It is assumed that the students taking responsibility for this project (Team Chromatic) will be part of the staff over the course of the project. However, ideally, the number of staff should be fairly distributed for each of the defined roles in the project documentation. The table below shows the staffing management plan for this project.

Role	Project Responsibility	Skills Required	Number of Staff	Performance Reviews	Recognition and Rewards
Project Sponsor	Provides support and resources for the project	Business management skills and leadership skills	1	Monthly or as needed	Bonus or promotion
Project Manager	Manages the entire project operations	Leadership, communication, collaboration, and project management skills	1	Monthly or as needed	Bonus or promotion
Scrum Master	Leads the Scrum team in conducting Scrum ceremonies	Scrum and Agile competency, and communication skills	1	Weekly	Bonus or promotion / Salary increase
Scrum Team	Works hand-in-hand with Scrum Master in accomplishing project deliverables	Technical skills, Agile competency, and collaboration skills	Varies depending on the project requirements	Weekly	Bonus or promotion / Salary increase
Documentation Manager	Manages the entire project’s required documentation	Technical writing skills, project management skills	1	Weekly	Bonus or promotion / Salary increase
Project Adviser	Contributes to the validation and improvement of the project	Technical, analytical, and leadership skills	1	As needed

The Quality Management Plan outlines the requirements and standards for the Baker’s Fair project. It encompasses various aspects of quality which involve functionality, performance, security, usability, compatibility, and compliance. The plan promotes a collaborative and iterative approach which is inspired by the Agile methodologies. The team will be proactivtly addressing issues, mitigate risks, and maintain the desired quality levels throughout the project via incorporating continuous feedback and improvement cycles.

Quality management is an ongoing process which requires regular review and improvement based on feedback and changing requirements. The following are key principles and approaches which will be followed in order to ensure an ideal, high level of quality.

• Requirement Analysis: The team will be defining and documenting the project requirements which includes both functional and non-functional requirements that are measurable, testable, and aligned with user expectations
• Test Planning: A comprehensive test plan will be developed which outlines the testing strategy, scope, and objectives, including the tools and techniques which will be used.
• Test Execution: Test cases will be executed according to the test plan. All test results and issues will be tracked and recorded
• Performance Testing: Performance testing will evaluate the application’s responsiveness, scalability, and stability when it comes to the expected and peak loads
• Security Testing: Security testing will be the identification of the application’s vulnerability, ensuring the application is protected against potential threats. The code will be reviewed in order to identify security vulnerabilities, and the best and ideal security practices are aimed to be implemented.
• Usability Testing: Usability testing will involve real users in order to evaluate user experience. Feedback and insights from said users will be gathered in order to further improve the user interface, navigation, and overall user satisfaction.

Regular review and updates of the requirements and adherence to standards are necessary when it comes to the maintenance of the desired quality throughout the development.

• Functional Requirements: Define the expected behavior and functionality of the application which involves user authentication, data retrieval, form submission, and other features which are relevant to the application.
• Performance Requirements: Focus on the application’s responsiveness, speed and efficiency, including metrics such as response time, page load time, and server processing time.
• Security Requirements: Protect the application and its users from vulnerabilities and threats which includes secure authentication, authorization mechanisms, and data encryption.
• Compatibility Requirements: Ensure the application functions correctly across different browsers, devices, and operating systems.
• Usability Requirements: Enhancement of user experience and ease of use, including navigation, user interface design, and accessibility.
• Scalability Requirements: Address the application’s ability to handle increasing user loads and data volumes.
• Compliance Requirements: Adherence to legal, regulatory, and industry-specific standards, such as data privacy regulations
• Documentation Standards: Establish Standards for documenting requirements, user manuals, release notes, design specifications, and other relevant documentation.

Quality Assurance will be based on Agile methodologies which emphasize quality through iterative development, collaboration, and continuous improvement. The following steps will be followed:

• Defining Quality Standards: Quality standards for the project will be defined and documented in the quality management plan and communicated to all the stakeholders.
• Continuous Improvement: Feedback from quality audits and metrics will be used in order to improve the product and the quality processes. Stakeholder collaboration will identify improvement opportunities and implement necessary changes.
• Compliance with Industry Standards: The application will conform to applicable industry standards, including data privacy, accessibility, and security standards.

The quality control process is an integral part of the application's development and maintenance. It ensures that all aspects of the application meet the defined quality standards and requirements. The following quality control measures will be implemented:

• Code Review: Regular code reviews will be conducted to identify and rectify issues or bugs, maintain code consistency and readability, and ensure adherence to coding standards.
• Unit Testing: Unit testing will validate the functionality and correctness of individual components. Tests will be executed frequently to detect and fix defects early.
• Integration Testing: Integration testing will verify the proper functioning of integrated components, ensuring that interactions between modules, APIs, and databases function correctly.
• User Acceptance Testing (UAT): UAT will involve end-users to simulate real-world usage scenarios and provide feedback on usability, functionality, and user experience. Issues and feedback will be recorded and prioritized.
• Security Testing: Comprehensive security testing will identify and mitigate potential vulnerabilities, including testing for common security threats. Regular security audits and penetration testing will be conducted.
• Continuous Monitoring and Maintenance: Post-deployment, the application will undergo continuous monitoring and maintenance to ensure ongoing performance, security, and reliability. This includes monitoring logs, analyzing error reports, and applying updates and patches.

Agile methodologies will be employed to promote continuous inspection and modification throughout the project lifecycle. A transparent and collaborative approach to quality control will be adopted.

In order to ensure the application meets defined standards and criteria, quality control measures will be implemented at each stage of the development process and documented on a shared, viewable platform (e.g., a project management tool) rather than a static spreadsheet.

The platform will include the following details:

• Measurement date
• Measurement type (e.g., automated testing, code review, user story acceptance)
• Findings of the measurement (e.g., passed/failed, number of flaws, code coverage)
• Requirements and standards for comparison
• Team member responsible for measuring
• Team member responsible for assessing results
• Actions taken for corrective measures
• Date when corrective measures were completed
• Team member responsible for implementing corrective measures

Dashboards and visual tools will track quality control measurements in real-time, providing easy access and comprehension of the data. These tools will highlight patterns and problem areas, enabling prompt action and necessary adjustments.

Quality control metrics and methodologies will be reviewed and adjusted during routine team reviews, such as sprint reviews and retrospectives. The team will collaborate to identify improvements and implement necessary changes.

In conclusion, Agile methodologies will be used to implement a collaborative and dynamic quality control strategy. The application’s quality will be assessed regularly, and necessary improvements will be made. All quality control measurements will be collected and tracked on a common platform, allowing for real-time monitoring and team collaboration.

Risk comes with any ambitious project. Any feature or function can suddenly malfunction, or sudden changes can affect the project’s schedule, cost, scope, and quality. Which is why risk management is part of any project management. The purpose of this Risk Management Plan is to outline the framework for identifying, assessing, monitoring, and mitigating risks throughout the lifecycle of the project.

1. 3D Model Integration Failure
   • Description: Risk of technical issues when integrating 3D cake customization features with Angular and Three.js, such as incorrect rendering, performance lags, or broken model behavior during user interaction.
   • Impact: High – This is a core feature of the project; failure could compromise the user experience and delay deployment.
   • Likelihood: Medium
2. AI-Generated Image or Restock Suggestion Failure
   • Description: Risk that the AI system used for generating cake previews or suggesting number of restock items may fail due to poor model performance, API limitations, or integration issues.
   • Impact: High – Could lead to incorrect or missing functionality in key features, affecting usability and trust in the system.
   • Likelihood: Medium
3. Scope Creep
   • Description: Risk of additional feature requests or changes being introduced outside the original project scope, especially as stakeholders see evolving outputs and request enhancements.
   • Impact: High – May result in resource overuse, increased workload, and schedule overruns.
   • Likelihood: High

The team chose to approach risks in a proactive and structured way. Risks will be identified at the start of the project and monitored throughout each development sprint. During sprint planning and retrospectives, the team will reassess existing risks and discuss emerging ones. Priority will be given to the top three risks.

By incorporating risk management into daily operations, Team Chromatic can minimize disruptions, adapt quickly to emerging issues, and ensure the project stays aligned with its timeline, scope, and budget.

Risks were identified through the following methods:

• Brainstorming sessions with the project team and class advisers.
• Review of previous capstone and software projects, particularly those with similar tech stacks.
• Interviews and informal discussions with subject matter experts in UI/UX, 3D modeling, and web security.
• Project retrospectives and continuous sprint reviews.

Identified risks are recorded in a standardized Risk Register, which includes details such as risk description, probability, impact, mitigation strategy, assigned owner, and status. Risk identification is an ongoing process and will be revisited in bi-weekly project meetings.

Each risk is evaluated using a Probability-Impact Matrix, helping the team prioritize focus and response strategies. High-impact and high-probability risks, such as scope creep, receive the highest attention. Each risk is scored and categorized as Low, Medium, or High in both dimensions to guide the team's mitigation and monitoring strategy.

Risks will be reviewed bi-weekly during project meetings. The top-priority risks (listed above) are added to the project schedule as milestones with assigned Risk Managers. Each identified risk includes defined trigger conditions, which will alert the team if the risk is becoming more likely. Updates will be documented and communicated to all stakeholders.

Once risks are qualified, the team develops strategies to mitigate or avoid them. Options include:

• Avoidance: Change project scope or workflow to eliminate the risk.
• Mitigation: Take steps to reduce the impact or probability.
• Acceptance: Acknowledge and monitor the risk without immediate action (used for low-priority risks).
• Transfer: Assign responsibility to a third party or tool, when feasible.

The following mitigation and avoidance strategies will be applied to the top identified risks:

1. 3D Model Integration Failure

• Mitigation Strategy:
  

The team will begin development by building and testing small, isolated components of the 3D model using Three.js in a sandbox environment. Integration with Angular will be done incrementally to catch compatibility issues early. Technical spikes and pair programming will be used during sprints to solve complex rendering and animation challenges. Backup implementation using static previews will be prepared if real-time rendering is delayed.

• Avoidance:
  

Select proven and compatible 3D file formats and test them early in development. Reduce the number of real-time features if performance risks remain high.

2. AI-Generated Image/Restock Suggestion Failure

• Mitigation Strategy:
  

The team will use pre-tested models and libraries for AI integration and set up unit and end-to-end tests to ensure image generation and inventory logic function correctly. Logs and alerts will be configured to detect early signs of AI model errors or misbehavior.

• Avoidance:
  

Avoid using overly complex models in the MVP. Stick to lightweight and locally testable AI models to minimize the risk of integration failure or performance bottlenecks.

3. Scope Creep

• Mitigation Strategy:
  

All new feature requests will be evaluated through a formal change request process. The Product Owner will maintain a prioritized product backlog and ensure stakeholders understand that features outside the current sprint will be queued for future consideration. Regular sprint reviews will include scope reaffirmation discussions.

• Avoidance:
  

A clear project scope statement will be documented and signed off by stakeholders. Strict sprint boundaries will be enforced, and communication channels will be used to reinforce scope limits.

Risk Register

The risk register, which will be maintained and updated throughout the project, will contain detailed descriptions of each identified risk, including its likelihood, potential impact, and corresponding mitigation strategies. It will be reviewed regularly to ensure it reflects the current risk landscape of the project. Stored in a shared and centralized location, the risk register will remain accessible to all stakeholders to encourage transparency and timely action.

Risk ID	Risk Name	Description	Impact	Likelihood	Priority	Mitigation Strategy	Risk Owner	Status
R-01	3D Model Integration Failure	Technical issues may occur when integrating 3D customization with Angular + Three.js.	High	Medium	High	Build and test in isolated modules; conduct technical spikes; prepare static fallback previews.	ThreeJS Dev	Open
R-02	AI Image/Restock Suggestion Failure	Failure in generating AI-based images or restocking suggestions.	High	Medium	High	Use proven libraries; implement fallback logic and logging; test AI locally before production.	AI Developer	Open
R-03	Scope Creep	Unplanned feature requests from stakeholders can disrupt the project scope.	High	High	Critical	Use formal change request process; maintain a prioritized backlog; reinforce sprint boundaries during regular reviews.	Product Owner	Open

Effective communication ensures that a project is in the right direction. This document establishes an approach for ensuring appropriate execution of communications strategy between key stakeholders. It outlines the communication needs and expectations of all stakeholders involved in the project and how to properly communicate throughout the project cycle. Included in this plan for Project Whisk are the following:

• What information will be communicated;
• How communication between the stakeholders will be conducted;
• When or how often the information should be distributed among the stakeholders;
• Who is responsible for spearheading the communications in this project;
• Communication requirements for all project stakeholders;
• Resources needed to be allocated;
• Practices in handling sensitive or confidential information;
• Practices in handling changes in the communication process;
• Flow of project communications;
• Constraints that may affect communication;
• Templates or documents to be used for communication; and
• Escalation procedures for resolving communication-based conflicts.

The project manager, Justin Ong, shall ensure that effective communication is practiced proactively in this project. Communications approaches will be defined throughout the document, particularly in communications matrix to be used as a guideline in conducting strategic communications among stakeholders and project members.

Changes or updates that might be presented throughout the project lifecycle, such as changes in personnel, scope, or budget are managed by the project manager provided support from the project adviser and/or project sponsor. These changes should be communicated well by the project manager to all involved stakeholders in the project to lessen project management problems such as miscommunication. Approved approaches like Agile Scrum framework, through online or physical means, help reinforce proactivity and reactivity in communications among key stakeholders and project members.

The following constraints are presented in this document including but not limited to:

• Schedule constraints. The communication matrix outlines the required communication activities to be conducted by the team. If not followed faithfully, it may introduce excessive costs or delays subsequently. Changes in the communications strategy should be communicated by the project manager to the key stakeholders and be approved by the project sponsor before taking effect.
• Limited personnel. The team members initially comprised of 4 bona fide students at Asia Pacific College and several key stakeholders under Bakers’ Fair. As a result, availability might be compromised due to other commitments and responsibilities of each of the student-members of the project, especially the project manager.
• Communication channels. For onsite physical meetings, only two locations are appropriate: premises of Asia Pacific College, and official Bakers’ Fair branches. For online meetings, any platform (e.g., Microsoft Teams, Google Meet) can be used but only meetings officially scheduled by the project manager or the project sponsor will be attended by the intended participants. This ensures confidentiality among the participants to avoid data leakage.

Stakeholders are identified and analyzed under the Stakeholder Management Plan. To ensure effective communication with each of the key stakeholders for this project, the project manager shall communicate firsthand with the stakeholders to identify how the communications will be conducted. This includes identifying the frequency with which to conduct certain communications, its methodology, among others. More details shall be provided in the succeeding subsections of the document, particularly the matrix and flowchart.

Project Sponsor

The project sponsor is the champion of the project and has authorized the project by signing the project charter. This person is responsible for the funding of the project and is ultimately responsible for its success. Since the Project Sponsor is at the executive level communications should be presented in summary format unless the Project Sponsor requests more detailed communications.

Program Manager

The Program Manager oversees the project at the portfolio level and owns most of the resources assigned to the project. The Program Manager is responsible for overall program costs and profitability as such they require more detailed communications than the Project Sponsor.

Key Stakeholders

Normally Stakeholders includes all individuals and organizations who are impacted by the project. For this project we are defining a subset of the stakeholders as Key Stakeholders. These are the stakeholders with whom we need to communicate with and are not included in the other roles defined in this section. The Key Stakeholders includes executive management with an interest in the project and key users identified for participation in the project.

Change Control Board

The Change Control Board is a designated group which is reviews technical specifications and authorizes changes within the organizations infrastructure. Technical design documents, user impact analysis and implementation strategies are typical of the types of communication this group requires.

Customer

The customer for this project is the staff of Bakers’ Fair Philippines. They will be the stakeholder who will accept the final project deliverable. They shall be informed of the status and deliverables for this project.

Project Manager

The Project Manager has overall responsibility for the execution of the project. The Project Manager manages day-to-day resources, provides project guidance and monitors and reports on the projects metrics as defined in the Project Management Plan. As the person responsible for the execution of the project, the Project Manager is the primary communicator for the project distributing information according to this Communications Management Plan.

Project Team

The Project Team is comprised of all persons who have a role performing work on the project. The project team needs to have a clear understanding of the work to be completed and the framework in which the project is to be executed. Since the Project Team is responsible for completing the work for the project they played a key role in creating the Project Plan including defining its schedule and work packages. The Project Team requires a detailed level of communications which is achieved through day to day interactions with the Project Manager and other team members along with weekly team meetings.

Technical Lead

The Technical Lead is a person on the Project Team who is designated to be responsible for ensuring that all technical aspects of the project are addressed and that the project is implemented in a technically sound manner. The Technical Lead is responsible for all technical designs, overseeing the implementation of the designs and developing as-build documentation. The Technical Lead requires close communication with the Project Manager and the Project Team.

The following table presents contact information for all persons identified in this communications management plan. The email addresses and phone numbers in this table will be used to communicate with these people.

Role	Name	Title	Organization/ Department	Email
Project Sponsor	Thomas Ong	Senior IT of Bakers’ Fair	IT	[email protected]
Project Manager	Justin Clark Ong	Project Manager	PMO	[email protected]
Project Stakeholders	See Stakeholder Register	See Stakeholder Register	See Stakeholder Register	See Stakeholder Register
Technical Lead	Lawrence Salonga	Senior Developer of Bakers’ Fair	IT	[email protected]
Project Team - Development	Brylle Nunez	Student	SOCIT, Bakers’ Fair IT	[email protected]
Project Team – Design	Maryrose Pergis	Student	SOCIT, Bakers’ Fair IT	[email protected]
Project Team - Development	Paul Damian Mariano	Student	SOCIT, Bakers’ Fair IT	[email protected]
Project Adviser	Prof. Joe Gene Quesada	Professor	SOCIT	[email protected]

The project team together with the key stakeholders and the project sponsor shall determine the most effective communication methods and technologies based on factors such as accessibility, stakeholder communication requirements, available technologies, and sensitivity and type of information to be exchanged.

Team Chromatic will use a dedicated SharePoint directory, project management tools such as Open Project and Jira, and a codebase management platform such as GitHub Issues to track key documentations and reports for this project. For official conferences and meetings, Team Chromatic will use Microsoft Teams and Google Meet to schedule meetings. For email communications, Team Chromatic will be using Outlook for communicating with the key stakeholders. Finally, a private group messaging application, namely Facebook Messenger, will be used for real-time messaging with the project sponsor and other stakeholders in this project. All the platforms mentioned are open access and free-to-use. To this end, all participants for this project should have a working and official accounts to be sent to the project manager for tracking.

The following table identifies the communications requirements for this project.

To conduct meaningful meetings, the following guidelines should be followed:

• Agenda and other meeting details should be disseminated to the intended participants at least 1 day in advance to ensure that all participants are prepared before the meeting.
• The minutes of the meeting should include all meaningful interactions and important notes and should be disseminated to the participants no later than the next scheduled meeting.
• The secretary is responsible for documenting the status of all meeting items and is responsible for taking notes during the meeting. They shall also be responsible for disseminating the minutes of the meeting to the intended participants.
• All members included in the scheduled meeting should be present on the day of the meeting. If the member is unable to attend the meeting, he/she should notify the secretary in advance. The member is also responsible for catching up with the meeting by reviewing the recorded sessions and minutes of the meeting.

The following are the communication standards that should be followed by all team members to ensure that output is standardized:

• Team Chromatic shall have a consistent naming convention for documents and files that are shared within the project space. This includes following the professor’s preferred template or name formatting of the documents and other soft copies of media. For example, scrum meeting documents for Project Management (PROJMAN) should adhere to the default template provided by the subject instructor.
• Team Chromatic shall use the required tools in the project-based learning curriculum of Asia Pacific College, which comprises of GitHub, Jira, OpenProject, Microsoft Teams, and Microsoft SharePoint for the creation and dissemination of information.

To effectively resolve any issues within the project communications, issues should be well-defined. To define the issues being escalated, the following escalation priority matrix will be used as a reference:

Level	Definition	Decision Authority	Timeframe for Resolution
1	Major impact on the project operations	Project Sponsor	Within a day
2	Medium impact on the project operations	Project Sponsor	Within 3 days
3	Minor impact on the project operations	Project Manager or Project Adviser	Within a week
4	Little to no impact on the project operations	Project Manager or Project Adviser	Work continues; issue will be addressed next sprint or review

Term	Definition
Communication Flowchart	A visual representation of the steps on how the information should move around project members and key stakeholders.
Communication Escalation Matrix	A tabular reference on identifying and escalating communication issues among project members and its corresponding authority to resolve it.
Communication Standards	Set of guidelines that dictate the formats and channels for exchanging information among the project members.
Project Sponsor	The person with the highest authority who approves changes and the project deliverables throughout this project lifecycle.

The Change Management Plan is important in the successful implementation of Whisk. All projects are subject to sudden changes, be it adjustments in project scope, timelines, resources, or requirements. To ensure that such changes are handled efficiently and transparently, a structured management process is necessary. This ensures that any changes are structured and documented.

The Change Control Board (CCB) is the primary body responsible for evaluating and approving or rejecting proposed changes. The board ensures that all changes are aligned with the project's objectives, timeline, and scope.

Purpose of the Change Control Board:

• To assess the impact of proposed changes on the project schedule, budget, and deliverables
• To ensure consistency with project goals and stakeholder expectations
• To authorize or reject change requests based on formal evaluation

Role	Member	Responsibility
Project Manager	Justin Clark Ong	The bridge between product owner and the team. They facilitate change request meetings and ensure all proposed changes are fully documented and evaluated. Updates the project plan accordingly.
Product Owner	Bakers’ Fair	Reviews the impact of changes on requirements and prioritization; collaborates on whether changes align with project value. Provides valuable comments and input.
Scrum Master	Justin Clark Ong	Ensures the proposed changes follow the Scrum framework during sprints; assesses feasibility within sprint timelines. Provides insight into how feasible proposed changes are.

Only changes approved by the Change Control Board will be implemented. Unapproved changes will be documented but not integrated into the ongoing development.

The following standardized process will be followed for all change requests:

1. Change Request Submission

• Any team member or stakeholder may submit a Change Request Form via Jira or email. The form must include the description, reason, urgency, and expected impact of the change.

2. Initial Review

• The Project Manager logs the request and conducts an initial review to verify completeness. If the request is valid, it is escalated to the Change Control Board for evaluation.

3. Impact Analysis

• The Scrum Team, Product Owner, and relevant specialists (e.g., UI/UX, Machine Learning and AI) analyze the technical, budgetary, and timeline implications. Findings are presented to the board for informed decision-making.

4. CCB Decision

• The board votes to approve, reject, or defer the change. Decisions are documented, and rationale is shared with the team and stakeholders.

5. Implementation (if approved)

• The Project Manager updates the project schedule, backlog, and documentation. Approved changes are assigned to relevant sprints or development phases.

6. Communication

• All stakeholders are informed of the change decision and the revised plan. Relevant documents and tools (e.g., Jira, OpenProject, SharePoint) are updated.

7. Monitoring

• The Scrum Master monitors the impact of the implemented change to ensure it does not cause regressions or misalignment.

This transition-out plan aims to define the processes for handing over the project from team Chromatic to Bakers’ Fair’s in-house development team. The transition should be smooth and problem-free, ensuring that the in-house team can continue to maintain and develop the project for years to come.

Chromatic started working with Bakers’ Fair starting March 20, 2024. To facilitate the future hand-off, the team matched the tech stack that was already in use by Bakers’ Fair. The project will be transitioned during July 1, 2025 to August 31, 2025 to Bakers’ Fair to be deployed in their branch and head office systems.

Name	Role	Description
Justin Clark Ong	Chromatic Project Manger	He will communicate with the client and coordinate any changes necessary to hand off the project.
Brylle Ace Nunez	Chromatic Lead Developer	He will implement any refactors requested by the client.
Maryrose Pergis	Chromatic Graphic Designer	She will adjust the project’s branding and user interface as requested by the client.
Paul Damian Mariano	Chromatic Documentation Manager	He will document any changes requested by the client.
Thomas Ong	IT Department Head	He will review the project and assess whether it sufficiently meets the client’s requirements.
Lawrence Salonga	Bakers’ Fair Lead Developer	He will review the codebase and request any changes necessary to import the project.

Chromatic’s workforce will remain independent from the client due to differing engagements. However, they will remain available to be contracted for the development of additional features.

Since Chromatic will be working closely with Bakers’ Fair during the development of the system, the amount of work to be executed during the formal transition will be minimal.

Component	Action
OpenVPN	Connect the branch and head office computers to the OpenVPN server.
Database	Create a new database for production use.
Feedback	Obtain user feedback and refactor as necessary.
Performance	Stress test performance in the production environment.

The client, Bakers’ Fair, will be given a license to all of the intellectual property associated with the project. Chromatic will still retain copyright on all of their original intellectual property but will no longer have access or rights to Bakers’ Fair assets, trademarks, and data.

Chromatic’s project currently uses a placeholder project in Keycloak, storing temporary user accounts for testing. Listed below are these user accounts, which will need to be deactivated and have their roles migrated to current employee accounts upon deployment:

Account Name	Role	Description
test-bm	client-whisk-branch-manager	Branch Manager
test-hom	client-whisk-head-office-manager	Head Office Manager
test-cd	client-whisk-cake-designer	Cake Designer

The client will be given access to the project’s project management sites, including GitHub, Jira, and Microsoft SharePoint. This will give them access to all documentation and tasks, including user manuals and development documentation.

Chromatic will be available for consultation sessions for a month after the deployment.