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 2. Project Charter 2.1 Executive Summary 2.2 Project Purpose/Justification 2.2.1 Business Case/Need 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 Approach 3. Stakeholders Management Strategy Plan 3.1 Introduction 3.2 Identify Stakeholders 3.3 Key Stakeholders 4. Stakeholder Analysis 5. Scope management 5.1 Introduction 5.2 Scope Management Approach 5.3 Roles and Responsibilities 5.4 Scope Definition 5.5 Project Scope Statement 5.5.1 Project Scope Definition 5.5.2 Project Deliverables 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 7. Cost management 7.1 Introduction 7.2 Cost Management Approach 7.3 Measuring Project Costs 7.4 Project Budget 7.5 Reporting Format 7.6 Cost Variance Response Process 7.7 Cost Change Control Process 8. OpenProject Work Breakdown Structure 8.1 Introduction 8.2 Outline View 10. Resource management 10.1 Introduction 10.2 Roles and Responsibilities 10.3 Resource Management Roles and Responsibilities 10.4 Project Organizational Chart 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.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 14.2 Risk Monitoring 12.7 Risk Mitigation and Avoidance 12.8 Risk Register 13. Communication Management Plan 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.14 Glossary of Communication Terminology 13.15 Sponsor Acceptance 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.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 15.8 Handover and Acceptance

NAME	EMAIL
Jose Eugenio L. Quesada	[email protected]

NAME	EMAIL
Alvin C. Limpin	[email protected]

NAME	ROLE	EMAIL
Jacob Angelo C. De Villa	Project Manager	[email protected]
Kyle Philippe M. Santos	Product Owner	[email protected]
David C. Naldo	Scrum Master	[email protected]
Janson Crisostomo H. Pagharion	Documentation Manager	[email protected]
Ramon D. Surara	Frontend Developer	[email protected]

Company Name:	St. Alphonsus Mary de Liguori Parish Church
Company Logo
Address:	Humabon Place, Barangay Magallanes, Makati, Philippines
Contact Number:	+63(02) 8851 0275
Line of Business:	Church
Type of Customers:	Local Residents
Stakeholders:	Angelito Sulit Rev. Msgr. Robert Canlas
Number of Employees:	N/A

Chambers of the Burning Ashes (CBAS) is a software solution designed to address the challenges faced by the St Alphonsus Mary de Liguori Parish in managing their document system, which is currently handled manually. This manual process leads to issues such as double bookings due to human errors, overlooking pre-existing reservations for columbaries, and the risk of losing records during natural disasters like typhoons. To resolve these concerns, the project aims to develop a secure, web-based system utilizing technologies like Django Framework, Python, AWS for optical character recognition, and MySQL for database management. The system is targeted at Parish staff and admins, ensuring an efficient and secure method for handling records. The project adopts the Agile-Scrum development methodology to allow iterative cycles of gathering requirements, designing, developing, and testing. This ensures the software evolves based on user feedback and aligns with the parish's specific needs. The ultimate goal is to deliver a functioning and integrated software solution for the St Alphonsus Mary de Liguori Parish that enhances document management, minimizes errors, and safeguards records from potential disasters

The St Alphonsus Mary de Liguori Parish faces several challenges due to its reliance on outdated manual processes for managing operations like columbarium services, wedding bookings, and funeral arrangements. These methods result in human errors such as duplicated records, loss of vital information, incorrect data input, and miscommunication, potentially affecting customer satisfaction and operational efficiency. Furthermore, records are vulnerable to damage or loss during natural disasters like typhoons, putting the parish's data security and continuity at risk.

The proposed project aims to create a modern Database Management System tailored to the parish's needs. This solution is expected to automate processes, minimize errors, and secure sensitive records. As a result, the parish's operations will become more efficient, and the staff will be able to accommodate their growing customer base effectively. The end state of the project will ensure streamlined workflows, reduced manual workload, and enhanced satisfaction for both church staff and admins.

The approach for addressing the business problems of the St Alphonsus Mary de Liguori Parish with the implementation of the Chambers of the Burning Ashes (CBAS) project is done through the following: Assessment of Current Systems – Conduct a thorough evaluation of the parish's existing manual processes to identify inefficiencies, challenges, and risks such as human errors, duplicated records, and data vulnerability during natural disasters. This will include observation of workflows and gathering insights through testimonials from parish staff and admins.

• **Identification of Objectives and Requirements** – Collaborate closely with parish officers and stakeholders to define the objectives and requirements for the web-based management system. This involves determining key functionalities like booking accuracy, data security, and streamlined workflows that align with the parish's operational goals.
• **Training and Adoption** – Provide comprehensive training to parish staff and admins to ensure they can effectively use the new system. Additionally, offer ongoing support resources and guidance to foster smooth adoption and confidence in utilizing the solution.
• **Testing and Assurance** – Implement continuous testing throughout the development phase to identify and resolve potential issues that may impact the system's functionality or reliability. This ensures a high standard of quality before deployment.
• **Deployment and Monitoring** – Set up and implement the Database management system for use within the parish, closely monitor its performance, and gather feedback from the staff. Utilize this feedback to make any necessary adjustments or improvements for optimal operation and user satisfaction.

The implementation of the Chambers of the Burning Ashes (CBAS) project is necessary for modernizing the operations of St. Alphonsus Mary de Liguori Parish. The recommended solution was selected for its ability to address critical issues such as human errors in bookings, loss of records during natural disasters, and inefficiencies caused by manual processes. By utilizing technologies, the project ensures scalability, security, and ease of use.

Quantitative benefits include reduced administrative workload, increased booking accuracy, and the safeguarding of vital records, which collectively enhance the parish's operational efficiency and customer satisfaction.

Role	Description	Name
Product Manager	He is responsible for overseeing the project’s vision, planning, and execution to ensure successful delivery as the Product Manager.	Jacob De Villa
Product Owner	He is responsible for defining the project requirements, managing the backlog, and prioritizing tasks to meet stakeholders' needs as the Product Owner.	Kyle Santos
Scrum Master	He is responsible for facilitating Agile-Scrum processes, ensuring smooth collaboration among team members, and removing impediments as the Scrum Master.	David Naldo
Documentation Manager	He is responsible for maintaining accurate and comprehensive records, reports, and technical documentation for the project as the Documentation Manager.	Janson Pagharion
Stakeholder	He is responsible for providing input and feedback during the development process as the Stakeholder.	Angelito Sulit Rev. Msgr. Robert Canlas
Class Adviser	He is responsible for supporting and mentoring the team by offering guidance and insights throughout the project lifecycle as the Class Adviser.	Prof Jose Eugenio Quesada
Project Adviser	He is responsible for providing expert advice and technical direction to ensure the project aligns with its objectives and best practices as the Project Adviser.	Prof. Alvin C. Limpin

The St Alphonsus Mary de Liguori Parish is facing several challenges with its current manual management system. These include difficulty in accurately tracking the availability of columbaries, leading to duplicated records, and issues with monitoring customer payment statuses and contract validity. Additionally, the outdated methods for retrieving vault information are inefficient, further complicating day-to-day operations. The parish also lacks a dedicated facility to securely store customer and vault records, making data vulnerable to loss or mismanagement.

The implementation of the proposed project will modernize the parish's operational processes by introducing an automated document management system. This change will reduce reliance on manual workflows, minimizing errors and improving efficiency in retrieving and managing information. Parish staff roles may evolve to focus on overseeing and maintaining the system, requiring training to adapt to the new tools and technology. Additionally, the project will establish a secure facility for storing records, ensuring better data management and continuity during operations.

Migration to the new technology involves implementing a web-based management system built on Django Framework, Python, AWS, Digital Ocean, and MySQL. The legacy data will be digitized, verified, and migrated into the new database system, ensuring accuracy and integrity during the transition. Key obstacles, such as ensuring compatibility of existing records with the new format and training staff to operate the system, will be addressed with robust planning, comprehensive testing, and user support resources.

Chambers of the Burning Ashes (CBAS) is a software solution that aims to replace the current document management system of the St Alphonsus Mary de Liguori Parish which is currently only done manually. Due to the current system, they encounter problems such as duplicated bookings due to human error, forgetting that certain columbaries are already booked prior, and loss of records due to natural disasters such as typhoons. As such, the primary objective of this project is to develop a web-based system using the Django Framework, Python, AWS Textract, and AWS cloud for the Parish. This is to improve the document management system and provide security for document records. The target audience for this project is the Parish officers and admins. The project will follow an Agile-Scrum development methodology, with iterative cycles of requirements gathering, design, development, and testing. The expected outcome for this undertaking is a working software solution integrated into the system of St Alphonsus Mary de Liguori Parish.   

The proposed CBAS aims to centralize and automate the management of columbarium records as St. Alphonsus Mary de Liguori Parish relies on outdated methods. These manual processes are prone to human errors such as record duplication, information miscommunication, and potential loss of records, which necessitates a modern technological approach to enhance operational efficiency and data security. 

The goal of CBAS is to implement a customized, user-friendly web application for St. Alphonsus Mary de Liguori Parish. This will centralize and automate the management of columbarium records, ensuring accurate tracking of vaults, improving customer data security, and streamlining the retrieval of information. By migrating from physical and Excel-based records to a secure, centralized database with integrated backup and encryption features, the parish can significantly reduce human errors and enhance service delivery.  

1. Develop a local web application to manage, available columbaries, customer transactions, and other relevant documents. 2. Create a secure customer portal with retrieval of vault information with a 3-second data access, and multi-factor authentication.  3. Implement a cloud-based database to securely store and manage customer and vault information for the parish, ensuring real-time updates and accessibility. 

The project will use an agile approach to develop and implement the Chambers of the Burning Ashes System (CBAS). Specific documentation will be given to St. Alphonsus Mary de Liguori and its parish staff. The project aims to be a user-friendly platform to enhance efficiency and processes for the parish. A web application will be developed to streamline processes for customers and parish staff. 

To answer the identified problems, the project’s aim is to design a customized local web application. To be specific, this project aims to:   

  1. Implement a transaction and document management system with 99% accuracy, guaranteed storage, and sub-5 second retrieval times.   2. Develop a secure customer portal with sub-3 second retrieval, end-to-end encryption, and robust user authentication (e.g., multi-factor authentication).   3. Implement an automated daily backup system with AES-256 encryption, 100% backup success, 30-minute restoration, redundant storage (hybrid approach), and monthly integrity checks.  

For the project’s succession, it must meet the set of conditions below: 

1. CBAS must be tested by the assigned team prior to development.  2. The system must be implemented without interfering with the usual operations of the parish.

Further specifications may be set depending on the need of the client and must be approved by the project sponsor. Requirements may be changed several times due to the methodology used.

The project’s constraints are as follows: 

1. Manpower. The project team consists of a limited number of developers and stakeholders. No additional members may be brought in unless approved by the project adviser, which may impact workload distribution and development speed. 

2. System Integration. Ensuring compatibility with existing parish records and processes may present challenges. Proper data migration and system alignment with current workflows will require thorough testing and adjustments. 

3. User Training. Parish officers, admins, and service personnel must undergo training to effectively use the system. Resistance to change or unfamiliarity with digital tools may slow down adoption, requiring additional support and guidance. 

4. Funding. The project's budget will be constrained by available financial resources, which may limit the inclusion of additional features, hardware upgrades, or external technical support. Strategic cost management will be necessary to optimize implementation within the budget.   

Customer and Parish Staff Adoption

Assumption: Potential customers and parish staff are able to use the web application. 

Rationale: Customers will be able to easily use the web app, and parish staff are easily able to manage columbary records. 

Client Communication

Assumption: Successful communication with our client for effective implementation of the system during the project’s lifecycle 

Rationale: Input by client is essential to tailor CBAS to their needs. All input and feedback are necessary to make the project a success. 

Assumptions

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 research is limited to the creation and implementation of the new system. The system will be making use of MySQL as the main organization storage system and AWS as the backup organization storage system. Focusing on cloud storage, it does not include services irrelevant to the system’s design. The system will feature a user-friendly interface capable of catering to beginners in IT using the Django framework, an integrated cloud database backup storage through AWS Textract, an Amazon Web Service based Optical Character Recognition for data transferring, report generation for sales and availability of the columbaries, and analytics that utilizes machine learning. As the system will have analytics, it will also be making use of the relevant Python libraries for machine learning. Libraries like matplotlib will be heavily used for the analytics.

The following risks for the Chamber of the Burning Ashes system 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 
• Potential threat of data loss to security vulnerabilities 
• Potential threat of data loss to damaged hardware 
• Potential resource constraint due to limited time and budget 

The following deliverables must be achieved upon the successful completion of The Chambers of the Burning Ashes System. Any changes to these deliverables must be approved by the stakeholders and the project manager. 

• Progress Reports 
• Activity List 
• Gantt Chart 
• Vision and Scope Document 
• Software Requirements Specification (SRS) 
• Final MCSPROJ Document 
• Improvement Matrix from previous defense 
• Source Code 
• Project Charter 
• Test Cases 
• Change Management Plan 
• Contingency Plan 
• Client Review 
• Project SharePoint 
• User Manual 

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.

Project Milestone	Target Date (mm/dd/yyyy)
Project Start	07/11/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 summarized budget encompasses general cost components and planned costs. As the project progresses, these costs may be subject to change as tasks and requirements become more defined. Expect a more thorough breakdown of budget and how it came to be when team has taken subject PROJMAN wherein the team will task to create a more detailed documentation plan regarding how the proposed system will be deployed within Saint Alphonsus de Liguori Parish.

Project Component	Component Cost
Manpower	₱301,401.00
Hardware	₱25,290.00
Software and Licensing	₱600.00
Others	₱00.00
Total	₱331,291.00

Success for the Chamber of the Ashes System will be achieved when a fully tested web-based document management system solution, and all technical documentation, is fully deployed throughout the company within the time and cost constraints indicated in this charter. Additionally, this measure of success must include a recommendation list for future security considerations as the team anticipates the necessity of this solution to evolve to prevent future threats. Success will be determined by the Project Adviser, Mr. Alvin Limpin, who will also authorize completion of the project. 

The project's sponsor, Rev. Msgr. Roberto C. Canlas, holds the primary authority to approve project plans and any necessary changes throughout the project's duration. The Project Manager, Jacob Angelo De Villa, is responsible for managing and executing the project as per the approved project plan. The project team will include members who will be assigned to different sub-teams, including the development team and documentation team, to ensure all aspects of the project are addressed effectively. 

To facilitate the project, the team will use Jira and OpenProject to manage tasks, track progress, and ensure transparency. These tools will enable the team to document quality control measurements, organize tasks into sprints, and monitor progress through dashboards and Gantt charts. Jira and OpenProject will also support the team in conducting sprint reviews, retrospectives, and backlog refinement sessions, providing a clear visualization of the project’s status, and facilitating effective communication. 

This Stakeholder Management Plan has been developed by Team Phishda in support of the implementation of the Chambers of the Burning Ashes System (CBAS) at St. Alphonsus Mary de Liguori Parish. CBAS is designed to modernize and automate the parish’s current manual processes related to the acquisition and management of columbarium services.  

The parish, while maintaining its strong relevance and service to the community since its establishment in 1967, has faced operational challenges due to traditional, paper-based methods. Issues such as duplicated records, loss of information, miscommunication, and delays have highlighted the urgent need for technological integration.  

The successful deployment of CBAS requires careful management of all involved stakeholders, including parish officials, administrative staff, technology partners, and the parishioners themselves. This plan aims to identify key stakeholders, understand their needs and concerns, and outline effective strategies to engage, communicate with, and support them throughout the system’s development and implementation. 

By ensuring strong stakeholder involvement and clear communication, Team Phishda seeks to ensure that CBAS not only meets operational goals but also enhances the overall experience for the parish community.

Team Phishda identified the stakeholders through conducted interviews with Parish representatives as well as through the creation of a stakeholder analysis document detailing the stakeholders involved and the influence, they hold over the project.  

The stakeholders identified include parish personnel and customer representatives from St. Alphonsus Mary de Liguori Parish, listed as follows:  

Parish Priest – Rev. Monsignor Bobby Canlas    Chief Office Staff – Marilyn Salamida  Parish Secretary- Jehnny Ching  RCMG Head - Angelito Sulit   Attorney - Atty. Ma. Pacita Batino  

The identified key stakeholder from the methodologies utilized by Team Phishda is Mr. Angelito Sulit, who was appointed by the parish as the project coordinator and primary representative for the implementation of the Chambers of the Burning Ashes System (CBAS). This decision was confirmed by the parish officials themselves, as Mr. Sulit regularly led the coordination efforts and represented the parish in stakeholder discussions.

Team Phishda conducted weekly meetings with the parish team to ensure alignment, gather feedback, and monitor progress. During these sessions, the team often consulted with the parish secretaries, who provided valuable insights regarding the challenges they faced, particularly in the consolidation of old records and manual documentation. These recurring meetings played a critical role in identifying operational pain points and shaping the features and functionalities of CBAS to address the parish’s specific needs. 

This section outlines the approach that the project team will use to analyze the identified stakeholders. It will detail how stakeholders are categorized or grouped based on their roles, interests, and the level of influence or power they hold over the project. The analysis will also assess the extent of each stakeholder’s involvement and potential impact on project outcomes. Various tools and techniques—such as stakeholder matrices, power-interest grids, and influence-impact charts—will be described to illustrate how stakeholder influence and engagement levels are evaluated and prioritized.

Working Shared Link: https://asiapacificcollege.sharepoint.com/:x:/r/sites/PROJMANMI222SF221T3AY2024-2025/Shared%20Documents/Group%2009%20Group%20name%20Phishda/01%20projman%20midterm%20document%20requirements/Stakeholder%20Analysis%20-%20Phishda.xlsx?d=wbd63f7182c83498abba9d8b0127d8847&csf=1&web=1&e=hdtTnh

Name	Department	Position	Advisers	Objectives, Requirements, Interests	Influence	Project Contribution	Resistance
Angelito Sulit	Risen Christ Memorial Garden (RCMG)	RCMG Head		Makes sure that it is aligned with their provided business process and goals	High	Approves and provided the necessary equipment to implement the project	Will express some inaccuracies with the terminologies used in the system
Ma. Pacita Karla F. Batino	Risen Christ Memorial Garden (RCMG)	Attorney		Everything is aligned with the RCMG head goals	Low	Serves as a messenger to communicate with the higher ups	Concerns hiring a person to maintain their newly implemented system
Parish Secretaries	Parish Office	N/A	N/A	Clean and organized transferrence of the old files	Low	Stored and provided the old files of the RCMG	Concerns with the new system because of their unfamiliarity with technology
Rev. Monsignor Roberto C. Canlas	St. Alphonsus Mary De Liguori Parish	Parish Priest	N/A	Organize the old files and fix the problems with the old files	High	Approves everything that the people do within the church	N/A
Prof. Alvin Limpin	SoCIT	Project Adviser		Ensure the project aligns with academic goals and scope, with a focus on student learning outcomes	Med	Provides feedback and supervision; assists in guiding the project's direction	Minimal resistance; may express concern if the scope or timeline affects the educational value or feasibility for students

The Scope Management Plan outlines the processes necessary to ensure that the CBAS project includes all work required—and only the work required—to successfully complete the system. It defines how scope will be defined, validated, and controlled. The plan also identifies roles and responsibilities to maintain project focus and prevent scope creep.

Scope for CBAS will be managed using Agile methodology in alignment with documented requirements and user stories. The scope definition will be based on the approved Project Scope Statement, Work Breakdown Structure (WBS), and stakeholder feedback. 

Process	Tool/Method
Requirements Collection	Surveys, interviews, parish feedback
Scope Definition	Scope statement, WBS, backlog
Scope Validation	Sprint reviews, stakeholder approval
Change Control	Formal change request process

Role	Responsibility
Project Manager (Jacob De Villa)	Oversees scope, approves minor changes, communicates updates
Scrum Master (David Naldo)	Ensures Agile practice adherence
Product Owner (Kyle Santos)	Maintains backlog, aligns features with stakeholder needs
Development Team	Executes tasks based on scope
Stakeholders (Parish Staff/Admin)	Review and approve deliverables
Project Advisers	Ensure academic and institutional alignment

CBAS will automate columbarium service documentation and management. Key components include: 

• Booking and reservation module 
• Document scanning and storage using OCR (AWS Textract) 
• Admin dashboard for system monitoring 
• Secure MySQL database backend 

Component	Description
Product Scope Description	A web-based document and booking management system for the Parish
Product Acceptance Criteria	Fully functional system, no critical bugs, user training completed
Project Deliverables	Requirement docs, mockups, prototypes, final report, deployment
Project Exclusions	Payment integration, non-columbarium modules
Constraints	Fixed timeline, limited developer hours, hardware reuse
Assumptions	Timely feedback, existing infrastructure support

Phase	Tasks
Initiation	Requirements gathering, scope planning
Planning	Wireframes, scheduling
Execution	Booking, scanning, dashboard development, testing
Closure	Deployment, training, documentation

(https://github.com/user-attachments/assets/198526b7-91fc-4253-8414-7e5ae78c3605)

Formal scope verification will occur at each sprint review, where stakeholders will accept or reject completed features. The product backlog and scope baseline will serve as validation references. 

Verification Method	Purpose
Sprint Demos	Present deliverables for approval
Acceptance Testing	Confirm functionality meets expectations
Quality Checklists	Ensure standards and completeness
Jira Tracking	Measure performance and task completion

Scope changes will follow the process below:

Step	Action
1	Submission of Scope Change Request (SCR)
2	Evaluation by Project Manager & Product Owner
3	Impact analysis on timeline and budget
4	Approval by Advisers and Stakeholders
5	Backlog and scope document updates

The Schedule Management Plan for the Chambers of the Burning Ashes System (CBAS), developed using Agile methodology, outlines a comprehensive approach to planning, managing, and controlling the project timeline. This includes defining tasks, sequencing activities, estimating durations, and developing the schedule to ensure that project milestones are met. Schedule control processes will be applied to monitor progress and respond swiftly to deviations. Clear procedures for managing schedule changes and thresholds will be in place, including specific criteria for evaluating and approving changes to maintain control and transparency. The plan also addresses how scope changes will be identified, analyzed, and incorporated into the schedule. Altogether, these strategies promote adaptive execution, transparent communication, and on-time delivery—enhancing the parish's ability to manage documents efficiently and securely.

The Schedule Management Approach for CBAS provides a structured framework for creating and managing the project timeline, ensuring that system development is methodical and efficient. This strategy defines roles and responsibilities, highlights key project milestones, and outlines the scheduling tools and formats that will be used.

Scheduling Tools and Format Agile project management tools such as Jira, and OpenProject will be used to manage the schedule. These platforms support iterative development, real-time collaboration, and visibility for all team members and stakeholders. 

• Jira: For managing sprints, tracking tasks, maintaining the product backlog, and visualizing sprint progress through burndown charts and Kanban boards.
• OpenProject: To visualize the overall project timeline through Gantt charts, showing task dependencies and key milestones. 

This milestone schedule is subject to refinement as requirements evolve. Any schedule updates will be communicated during status meetings by the Project Manager. 

Project Milestone	Target Date
Project Start	07/11/2024
Planning
Midterm Presentation	05/13/2024
Project Plan Complete and Approved	06/25/2024
Analysis and Design
Midterm Presentation	09/11/2024
Final Presentation	10/19/2024
Development
Initial Release 1 Prototype	01/16/2024
Midterm Presentation	01/16/2025
Release 2 Prototype	02/26/2025
Final Presentation	02/26/2025
Final Release Prototype	03/10/2025
Implementation
Deployment of Solution	05/06/2025
Project Completion	09/11/2025

The Schedule Control section outlines how the project timeline will be managed throughout the CBAS development lifecycle. It includes mechanisms for evaluating progress, implementing updates, communicating changes, and assigning control responsibilities. The goal is to ensure timely delivery and system deployment with full transparency and accountability. 

Weekly Progress Reports: A detailed report will be distributed weekly to all team members and parish stakeholders. This report will highlight completed features, planned sprint goals, and any delays or risks that could impact project milestones. 

Project Dashboard: A real-time dashboard will be maintained using OpenProject and Jira, enabling team members and key parish personnel to monitor current development status, sprint velocity, and key performance metrics. 

Status Meetings: Regular status meetings will be conducted, including daily stand-ups, sprint reviews, and retrospectives, to ensure continuous alignment between developers, stakeholders, and parish staff. 

Roles and Responsibilities

• Project Manager: Oversees schedule adherence and timeline integrity. Conducts biweekly sprint reviews and milestone tracking to detect and correct any deviation. 
• Scrum Master: Ensures the team follows the Agile-Scrum process and that timeline-related blockers are promptly resolved in collaboration with the Project Manager and Product Owner. 
• Product Owner: Prioritizes the product backlog in accordance with the approved timeline and works with the team to adjust or approve scheduling changes based on stakeholder needs. 
• Development Team: Participates in sprint reviews and planning sessions. Provides timely updates on progress, flags issues, and proposes solutions for any task delays. 
• Stakeholders: Attend milestone meetings and provide feedback on the timeline status. Required to approve any major deviations from the original schedule. 
• Project Advisers/Class Advisers: Oversee alignment with academic and institutional standards. Ensure project progress aligns with course objectives and deadlines.

The Cost Management Plan defines how the costs for the “Chambers of the Burning Ashes System” 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

For a detailed study of project costs, the project 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.

Performance of the project will be measured using Earned Value Management. The following four Earned Value metrics will be used:

• Schedule Variance (SV)
• Cost Variance (CV)
• Schedule Performance Index (SPI)
• Cost Performance Index (CPI)

If the SPI or CPI has a variance between 0.1 and 0.2, the Project Manager must report the reason. If the variance exceeds 0.2, a detailed corrective plan must be submitted.

Performance Measure	Yellow	Red
Schedule Performance Index	Between 0.9 and 0.8 or Between 1.1 and 1.2	Less Than 0.8 or Greater than 1.2
Cost Performance Index	Between 0.9 and 0.8 or Between 1.1 and 1.2	Less Than 0.8 or Greater than 1.2

Category	Rate	Hours	Total
Documentation Manager	₱200/hour	175	₱26,250.00
Project Manager	₱167/hour	256	₱51,200.00
Scrum Master	₱150/hour	256	₱42,752.00
Team Leader (TL)	₱200/hour	256	₱51,200.00
Backend Developer	₱173/hour	140	₱24,220.00
Frontend Developer	₱150/hour	100	₱15,000.00
Fullstack Developer	₱215/hour	153	₱32,895.00
QA Analyst	₱125/hour	42	₱5,250.00
Security Analyst	₱200/hour	253	₱50,600.00
Total Manpower			₱301,401.00
Hardware			₱25,290.00
Software			₱600.00
Training	₱100/hour	20	₱2,000.00

Hardware Type	Brand	Cost
Processor	AMD Ryzen 5 5600G	₱7,650.00
Motherboard	MSI A520M-A Pro	₱3,300.00
RAM	Kingston Fury Beast 2x8GB DDR4 3200MHZ	₱3,050.00
Storage	Kingston NV2 500GB NVMe SSD	₱1,695.00
Power Supply Unit (PSU)	Thermaltake TR2 S 600W 80+	₱1,950.00
Case	Tecware Nexus M2 Micro-ATX	₱1,200.00
UPS	Secure 1000VA	₱2,995.00
Monitor	MSI MP223 PRO 21.5” 100hz	₱3,450.00
TOTAL		₱25,290.00

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 is a Cost Performance Index (CPI) or Schedule Performance Index (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 the means by which 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. 

The Work Breakdown Structure presented here represents all the work required to complete this project. Serving as a roadmap for the execution of the project that includes five phases that are Project Initiation, Planning, Execution, Control, and Closeout. This structure will help in monitoring and managing the project. Ensuring successful deployment for the St. Alphonsus Mary de Liguori Parish Church.

1. Chambers of the Burning Ashes System

1.1 Project Initiation

• 1.1.1 Talk with Clients
• 1.1.2 Consult with Adviser
• 1.1.3 Prepare Documentation

1.2 Planning

• 1.2.1 Find root cause of the problem
• 1.2.2 Create Scope Statement
• 1.2.3 Develop Baseline Plans
• 1.2.4 Develop Project
• 1.2.5 Create Use Cases
• 1.2.6 Submit Project Plan
• 1.2.7 Milestone: Project Plan Approval
• 1.2.8 Create Software Requirements Specification Document (SRS)
• 1.2.9 Milestone: SRS Document Approval

1.3 Execution

• 1.3.1 Initialize Development
• 1.3.2 Build Backend
• 1.3.3 Develop RBAC (Role Based Access Control)
• 1.3.4 Develop Database
• 1.3.5 Develop Frontend
• 1.3.6 Quality Testing
• 1.3.7 Data Migration
• 1.3.8 Milestone: Deployment to Production

1.4 Control

• 1.4.1 Project Management
• 1.4.2 Project Status Meetings
• 1.4.3 Update Project Management Plan
• 1.4.4 Risk Management

1.5 Closeout

• 1.5.1 Update Files/Records
• 1.5.2 Milestone: Project Turnover
• 1.5.3 User Training
• 1.5.4 Document Lessons Learned
• 1.5.5 Archive Files/Documents

=9. OpenProjectWork Packages (https://github.com/user-attachments/assets/fb7e4e24-0a2c-4a1f-8d84-5081322e26c2)

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.

The CBAS project is developed by a core student development team and supported by representatives from St. Alphonsus Parish, acting as stakeholders. 

CBAS Development Team (Student Developers): 

 '''Jacob Angelo de Villa – Project Manager, Team Lead and Backend Developer Oversees team progress and deployment tasks. Leads AWS cloud deployment, OCR integration, QA testing, and user acceptance activities to ensure system reliability and functionality.  

Ramon Surara – Frontend Developer and Data Analyst Responsible for designing and implementing user interfaces and visual elements. Also conducts data analysis to support system features and reporting needs. 

David Naldo – Scrum Master, and Full Stack Developer Leads sprints and ensures team collaboration by applying Agile principles. Acts as the primary decision-maker, manages stakeholder requirements, and coordinates overall project execution across the front and backend. 

Kyle Santos – Product Owner, Backend Developer, and Security Analyst Develops backend services and APIs, while ensuring security protocols and data protection standards are implemented. Manages the product backlog and ensures development aligns with user needs and church documentation processes. 

  Janson Pagharion – Backend Developer, and Documentation Committee Designs backend architecture using Django and MySQL. Leads system design documentation, including technical specifications and process flows. 

All team members report to the Scrum Master and collaborate based on Agile principles, with sprints reviewed biweekly.

St. Alphonsus Mary de Liguori Parish Stakeholders: 

Rev. Msgr. Roberto C. Canlas – Parish Priest Project sponsor and final approver of major features and releases. 

Marilyn Salamida – Parish Secretary Facilitates document handover for digitization, validates OCR output accuracy, and assists in system testing and validation. 

Angelito Sulit – Head of Risen Christ Memorial Garden (RCMG) Assists in onboarding existing parish records and provides feedback on administrative interface usability. 

Role	Authority	Responsibility	Competency
Documentation Manager	Oversees all documentation standards and approvals	Manages technical documents, user manuals, process flows, and system architecture records	Strong technical writing skills; familiar with system design, process mapping, and formatting tools
Project Manager	Overall authority on project planning and coordination	Leads project scheduling, resource allocation, and stakeholder communication; ensures project is on track with scope and deadlines	Advanced project management skills; knowledge of SDLC, stakeholder coordination, and risk management
Scrum Master	Oversees Agile implementation and sprint discipline	Facilitates Scrum ceremonies (planning, review, retrospective); removes blockers; promotes team productivity and Agile values	Strong Agile/Scrum knowledge; collaboration, conflict resolution, and time management skills
Team Leader (TL)	Operational team coordinator; leads day-to-day task execution	Delegates tasks, checks team output, ensures sprint progress, and supports both backend and frontend teams	Technical leadership; full system understanding; coordination and mentoring skills
Backend Developer	Controls data logic, database operations, and server-side services	Develops APIs, handles Django models and views, integrates with OCR and AWS Textract, and ensures database integrity (MySQL)	Proficient in Django/DjangoX, REST APIs, MySQL, and ORM frameworks
Frontend Developer	Oversees all user-facing visual components	Designs user interfaces, ensures responsiveness, and implements UI workflows for administrative users	Proficient in HTML, CSS, JS, and frontend frameworks; UX/UI design principles
Fullstack Developer	Bridges frontend and backend development	Develops and integrates features across both server and UI layers; ensures consistency and seamless user experience	Knowledgeable in both Django and frontend frameworks; full SDLC understanding
QA Analyst	Ensures the system meets functionality, reliability, and performance criteria	Designs and executes test cases, performs bug tracking, regression testing, and supports user acceptance testing (UAT)	Skilled in test planning, defect tracking tools, and software validation
Security Analyst	Maintains system security in the local environment	Implements role-based access controls, monitors system vulnerabilities, ensures data protection protocols in absence of cloud-based defenses	Understanding of local/offline security practices; Django permissions; backup strategy implementation
Parish Secretary	Validates content and provides clerical workflow feedback	Facilitates document handover for digitization, validates OCR accuracy, and supports testing phases	Familiar with existing document handling and basic digital systems
RCMG Head	Oversees integration with memorial garden operations	Assists in onboarding legacy records and provides feedback on usability of administrative interface	Knowledge of memorial garden records and process-specific workflows
Project Adviser	Guides the student team from the academic perspective	Reviews methodologies, provides expert feedback, and ensures project aligns with academic standards	Should be a faculty of SoCIT-APC; experienced in software projects and student mentoring

(https://github.com/user-attachments/assets/a39c3c38-674a-4a1a-b2dc-8265ab688854)

Name	Role	Reports To	Objectives / Interests	Influence	Project Contribution	Potential Resistance
Rev. Msgr. Roberto C. Canlas	Parish Priest / Project Sponsor	N/A	Reliable church records system, transparency, data security	High	Final approver of system features, releases, and policy alignment	Privacy concerns, system reliability
Marilyn Salamida	Parish Secretary	Parish Priest	Accurate digitization, document retrieval ease	Medium	Facilitates document handover, validates OCR output, supports testing	Learning curve, system complexity
Angelito Sulit	Head of RCMG	Parish Priest	Organized and accessible burial record management	Medium	Provides records for migration, gives feedback on admin usability	Technological adoption, interface changes
David Naldo	Scrum Master / Product Owner / Full Stack Developer	N/A	Agile project delivery, stakeholder alignment, functional system	High	Leads sprints, manages backlog, handles full stack development, communicates with stakeholders	Scope creep, conflicting stakeholder demands
Jacob Angelo de Villa	Team Lead / Backend Developer	Scrum Master	AWS deployment, OCR functionality, system stability	High	Leads deployment, OCR integration, QA testing, user acceptance	Cloud limitations, tool compatibility
Kyle Santos	Backend Developer / Security Analyst	Scrum Master	Secure backend services, user-aligned functionality	Medium	Develops backend APIs, implements security standards, manages backlog	Security policy constraints
Janson Pagharion	System Designer / Backend Dev / Documentation Committee	Scrum Master	Robust architecture, complete documentation	Medium	Designs backend with Django & MySQL, documents system structure	Technical debt, documentation overhead
Ramon Surara	Frontend Developer / Data Analyst	Scrum Master	Effective UI/UX, data-informed features	Medium	Develops interfaces, performs data analysis for reporting	UI misalignment, inconsistent data

The staffing strategy for CBAS ensures optimal resource use, growth, and alignment with project goals: 

• Acquisition: The core student team will be fully onboarded at project kickoff. No external hires are planned, but consultations with the parish tech team may occur. 
• Training: Developers: Internal sessions on Django optimization, AWS services (e.g., EC2, S3, Textract), and OCR data parsing. 
• Stakeholders: Admin staff will be trained on system operations, secure document uploads, and access controls. 

Performance Reviews: Conducted at the end of each sprint and after major milestones. Peer feedback, stakeholder satisfaction, and code quality will be key metrics. 

• Motivation & Recognition: Celebrations at sprint completions, public recognition during parish presentations, and possible endorsement letters or certificates from the parish. 
• Compliance: The team will adhere to data privacy standards (such as Philippine Data Privacy Act), especially regarding religious and personal documents. Cloud deployment will follow AWS security best practices. 

The Chambers of the Burning Ashes System Quality Management Plan will provide a thorough structure across the project’s lifespan. Maintaining strict standards is important to meet the needs of stakeholders and the Magallanes community. Methods such as the approach, standards, assurance, control, and measurements are outlined in this plan. This is to provide a reliable and easy-to-use web application to ensure that standards are up to par with stakeholders and the community alike.

• Quality Planning: Success criteria are based on stakeholder satisfaction, ensuring consistency and good standards for outcomes and procedures.
• Stakeholder Involvement: Continuous engagement with stakeholders ensures satisfaction and alignment with objectives.
• Iterative Development: Regular feedback is gathered with each new feature, allowing immediate issue resolution and refinement.
• Quality Assurance: Includes testing, reviewing, and data validation to meet stakeholder and user standards.
• Quality Control: Testing and inspections are conducted before production to catch issues early.
• Monitor Improvement: Performance is evaluated every cycle to apply lessons learned and improve quality.
• Communication and Documentation: Stakeholders are kept informed to ensure feedback and team alignment on quality goals.

• Stakeholder Collaboration: Define quality requirements such as performance, security, user acceptance, and scalability.
• Functional Requirements: Improve client experience by eliminating inefficiencies from legacy systems. Staff must manage customer and vault data effectively.
• Performance Requirements: Ensure fast response times and system reliability. Metrics include error rates and uptime.
• Security Requirements: Protect personal data with validation, authentication, audits, and mitigation strategies.
• Compatibility Requirements: Ensure seamless operation across all devices and platforms.
• User Acceptance Requirements: Focus on usability testing and stakeholder feedback to refine the user experience.
• Compliance Requirements: Adhere to DICT and GDPR regulations for legal compliance.

• Quality Control Measurements: Define metrics for functionality, performance, usability, compliance, and security.
• Implement Quality Audits: Conduct audits during iterations to verify compliance with quality standards.
• Continuous Improvement: Adapt quality assurance practices based on industry standards and regulatory updates.

• Continuous Testing: Identify issues early through testing in each sprint.
• Refinement of Product Backlog: Break down tasks for better quality focus during iterations.
• Regular Reviews and Adaptation: Use sprint reviews and retrospectives to evaluate and improve work.
• Dedicated Quality Assurance Roles: Assign roles like Product Owner and Scrum Master to prioritize and unblock quality-related tasks.

These measures ensure that the Chambers of the Burning Ashes System will deliver a reliable, usable, and effective system to meet the needs of the St. Alphonsus Mary de Liguori Church and its surrounding Magallanes community.

To meet standards and quality, a document will be created and stored on a shared platform (e.g., SharePoint or Google Drive). This document will include:

• Performance Table: Includes metrics such as error rate, response time, and benchmark achievement.
• Test Cases Table: Tracks UI issues, problem descriptions, and status (e.g., fixed, in progress, not started), with priorities from high to low.
• Vulnerability Checking: Conducted using tools like OWASP ZAP and BurpSuite to detect hidden security issues. Results are documented separately.

The document will provide real-time tracking of any issues and include detailed discussions for high-priority concerns.

The CBAS project seeks to digitize and automate the document management and columbarium booking processes for St. Alphonsus Mary de Liguori Parish. Built using the DjangoX framework and integrating AWS Textract for OCR, the system is intended for local deployment rather than cloud-based hosting, as requested by the client. Given its technical complexity and the involvement of multiple stakeholders, the project is subject to various risks. This Risk Management Plan outlines the approach to identifying, assessing, mitigating, and monitoring risks to ensure secure and successful implementation in a local environment.

• Data Loss Due to Local Storage Failures

Local storage systems may be more vulnerable to hardware failure or accidental deletion compared to cloud-based solutions.

• Dependency on Internet for AWS Textract

Although the system is locally deployed, AWS Textract requires internet access, which could pose reliability issues in unstable network environments.

• Resistance from Staff with Low Digital Literacy

Parish staff may find it difficult to adjust to digital workflows, affecting system adoption and day-to-day operations.

CBAS follows a proactive risk management methodology integrated with Agile practices. Risks are identified during sprint planning, retrospectives, and stakeholder discussions. Each risk is evaluated using a probability-impact matrix and recorded in a centralized risk register. A risk owner is assigned per item, with biweekly reviews ensuring accountability and adaptability throughout the project lifecycle.

Risks were identified through:

Risks have been identified through:

• Sprint retrospectives and development stand-ups
• Consultations with parish stakeholders and administrative staff
• Review of similar IT solutions implemented in low-connectivity or on-premise environments
• Technical feasibility checks for AWS Textract and DjangoX integration in offline-first settings

Risks are recorded in a Risk Register, discussed during sprint planning, and regularly updated during stakeholder check-ins.

Each identified risk is rated on a scale of 1–5 for probability and impact. The combined score helps prioritize which risks require mitigation planning or close monitoring. For instance:

A risk with probability = 4 and impact = 5 results in a risk score of 20 (High priority)

This prioritization guides resource allocation and contingency planning.

High-priority risks are tracked using the project dashboard. Owners are expected to provide weekly updates. Trigger events, such as OCR failure or local system crashes, are defined to allow preemptive responses. Biweekly reviews ensure ongoing risk awareness and adjustment of strategies as needed.

• Data Loss (Local Environment)

 ➤ Implement automated local backups (external drives or NAS). 
 ➤ Conduct periodic backup verification and store offsite copies. 
 ➤ Use file integrity checks and access controls. 

• AWS Textract Dependency

 ➤ Pre-validate internet connectivity during OCR use. 
 ➤ Add a queueing system to batch upload documents once online. 
 ➤ Explore fallback user input for emergency offline use. 

• User Resistance

 ➤ Provide focused training sessions for admin staff. 
 ➤ Offer user-friendly documentation and ongoing helpdesk support. 
 ➤ Gather user feedback in pilot phases to guide adjustments. 

If risks cannot be fully mitigated, fallback options such as reverting to manual document input or maintaining paper logs temporarily will be in place.

Risk ID	Risk Name	Description	Impact	Likelihood	Priority	Mitigation Strategy	Risk Owner	Status
R-01	Local Storage Failure	Risk of document loss due to hardware failure or mismanagement.	High	Medium	High	Regular backups, online storage, file system monitoring	Sysadmin	Open
R-02	AWS Textract Connectivity Failure	OCR services require internet; failure affects document digitization workflow.	High	High	Critical	Provide manual input of information in UI	DevOps	Open
R-03	User Resistance to System Use	Parish staff may be unprepared to adopt digital tools.	Medium	High	High	Deliver hands-on training, provide manuals, and assign tech support	Project Lead	Open
R-04	OCR Output Inaccuracy	Textract misreads handwritten or poorly scanned documents.	Medium	Medium	Medium	Validate OCR outputs; offer manual correction interface in UI	Backend Dev	Open
R-05	Unauthorized Access (Local Setup)	Risk of unauthorized personnel accessing sensitive data due to lax controls.	High	Medium	High	Role-based access control, login logs, system lockout policies	Security Analyst	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 Chambers of the Burning Ashes 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.

Within the team, a hybrid approach will be used, combining in-person and online meetings to support Agile and Scrum Methodology. A hybrid approach provides flexibility for the team to adjust meetings according to their needs or circumstances, like weather, availability issues, and personal problems. Communications approaches will be defined throughout the document, particularly in the 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 with 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 the Agile Scrum framework 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 5 bona fide students at Asia Pacific College and several key stakeholders under SAMLP. 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 the Batino Law Office in Paseo de Magallanes. For online meetings, any platform (e.g., Microsoft Teams, Zoom, Viber) 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 – including the identification of the frequency with which to conduct certain communications. More details shall be provided in the succeeding subsections of the document, particularly the matrix and flowchart.

Role	Description
Project Sponsor	Is the primary form of contact of the team and the one responsible for providing specifications and requirements for the team to follow.
Project Manager	Is responsible for overseeing the entire project from planning, executing, and deploying. The one who leads every meeting with team members and key stakeholders.
Scrum Master	Is responsible for facilitating Agile methodology and ensuring timely Sprints and retrospective meetings with the team.
Project Adviser	Communicates with the team on what to improve regarding documents and the system being developed.
Project Team	Is comprised of all persons who have a role performing work on the project. Requires a detailed level of communication which is achieved through day-to-day interactions with the Project Manager and other team members along with weekly team meetings.
Customer	Is the staff at Saint Alphonsus Mary de Liguori Parish as they will be the ones to receive the final product.

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	Bingo Batino	Lawyer of Batino Office	Batino Law	[email protected]
Project Manager	Jacob De Villa	Student	SOCIT, SAMLP IT	[email protected]
Scrum Master	David Naldo	Student	SOCIT, SAMLP IT	[email protected]
Project Adviser	Alvin Limpin	Professor	SOCIT	[email protected]
Project Team	Kyle Philippe Santos	Student	SOCIT	[email protected]
Project Team	Janson Crisostomo Pagharion	Student	SOCIT, SAMLP IT	[email protected]
Project Team	Ramon Surara	Student	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 Phishda 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 Phishda will be using Viber for communicating with the key stakeholders. Viber 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 account to be sent to the project manager for tracking.

The following table identifies the communications requirements for this project. (https://github.com/user-attachments/assets/3d47c76d-7202-4f0e-a988-28ddd77ad7a0)

(https://github.com/user-attachments/assets/4073bf54-c27f-4df3-9b9b-2ab54964c397)

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 PHISHDA 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 PHISHDA shall use the required tools in the project-based learning curriculum of Asia Pacific College, which comprises 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.

Approved by the Project Sponsor:

Date:

Bingo Batino
Lawyer

The CBAS project’s Change Management Plan outlines the formal process for managing change within the project scope, timeline, or deliverables. It ensures that changes are systematically proposed, reviewed, approved or rejected, and implemented with clear communication across the project team (Phishda Dev Team) and the stakeholders from St. Alphonsus Mary de Liguori Parish.

The CBAS project’s Change Control Board (CCB) oversees the evaluation and decision-making for any proposed changes. The board consists of key representatives from both the project development team and the parish stakeholders. Below are the roles and members of the CCB:

Name	Position	CCB Role
Rev. Msgr. Roberto C. Canlas	Parish Priest / Project Sponsor	CCB Chair
David Naldo	Scrum Master, Product Owner, Full Stack Developer	CCB Member
Jacob Angelo de Villa	Team Lead and Backend Developer	CCB Member

• Development Team (CBAS Dev Team): Must consult with the CCB before implementing any major changes that affect scope, timeline, features, or resources.
• Any concerns or change suggestions raised within the team must be communicated to the Scrum Master (David Naldo).
• The Scrum Master will lead internal team discussions and coordinate with the Team Lead (Jacob Angelo de Villa) to assess and refine change details.
• Once a proposed change is validated internally, the Scrum Master will escalate the matter to the Project Sponsor (Rev. Msgr. Roberto C. Canlas) for further review and formal deliberation.
• Approved changes are then documented, communicated back to the team, and reflected in updated project plans.

1. Identify Change: Either the CBAS Dev Team or parish stakeholders identify a potential change (technical, functional, or strategic).
2. Submit Change Request to CCB: Details of the proposed change are submitted to the Scrum Master for internal evaluation. The development team holds a discussion to specify technical or stakeholder implications.
3. CCB Review: The CCB conducts a meeting to assess the change, considering feasibility, risks, stakeholder impact, and timeline adjustments. The change may be approved, rejected, or sent back for revision.
4. Decision Communication: The Scrum Master communicates the CCB’s decision to the entire development team. Required updates are made to the project documentation and timeline.
5. Review and Closure: The Team Lead confirms that the change has been implemented and issues resolved. The change request is formally documented and marked as closed.

The Chambers of the Burning Ashes System (CBAS) was initiated to modernize the manual processes of the St. Alphonsus Mary de Liguori Parish, specifically focusing on their columbarium services. The objective is to implement a secure, user-friendly, and highly accurate document and transaction management system that reduces human error and improves customer satisfaction.

The project team consists of system developers, data analysts, and project managers who have overseen the planning, development, and pilot testing of the system. Coordination with parish administrators and staff was prioritized to ensure that the system is tailored to their needs.

To ensure full operational readiness and effective handover, the system implementation and transition will be completed before the end of the project term. This includes complete documentation, training, and deployment phases to ensure parish staff can confidently and independently operate CBAS.

The workforce transition will involve orienting the parish staff to the new system. Employees involved in columbarium records management will undergo structured training. These sessions will focus on:

• Navigating the Django-based system interface.
• Managing customer records, vault information, and document generation.
• Understanding backup procedures and data security protocols.

All relevant contracts and confidentiality agreements will be signed to ensure data integrity. Essential operations will continue uninterrupted during the transition.

During the transition phase, key activities will include:

• User Training: Parish staff will be trained in phases on core system operations, document handling, and use of analytics features.
• Stakeholder QA: Parish leaders and selected staff will review the system via quality assurance testing to verify completeness and functionality.
• Project Documentation: Full documentation including admin guides, troubleshooting manuals, and architectural overviews will be handed over.
• Project Close Out: Upon successful training, documentation, and final stakeholder approval, the project will be considered formally transitioned.

The CBAS software and all associated documentation and design files will be handed over to St. Alphonsus Mary de Liguori Parish. Intellectual property rights will be transferred free of charge, and non-disclosure agreements will be signed where necessary.

System credentials will be provided to authorized staff during the final turnover. Initial passwords will be issued securely and changed upon first login. Roles will include:

• Parish Administrator
• IT Support Staff

A structured 14-day knowledge transfer phase will be conducted, consisting of:

• Comprehensive Documentation: All system design files, user guides, and SOPs will be provided.
• Training Sessions: Regular onsite or virtual training sessions will be conducted, with support for Q&A and hands-on practice.

Led by the Project Manager and Developer, this phase ensures full knowledge handover to key personnel.

Activity	Responsible Party	Start Date	End Date
Final System Testing & QA	Project Manager, Stakeholders	2025-06-11	2025-06-12
Staff Training Sessions	Project Manager, Developer	2025-06-18	2025-07-03
Support Handoff	Project Manager, Developer	2025-06-18	2025-07-03
Documentation Handover	Documentation Specialist	2025-06-11	2025-06-13
Project Close-Out	Project Manager, Stakeholders	2025-06-27	2025-07-03

Final handover will include:

• Delivery of system access credentials
• Transfer of all documentation
• Final project report and QA checklist
• Formal sign-off meeting with parish representatives

A final acceptance report will be signed by all key stakeholders confirming that the system has been delivered, is functional, and meets all defined requirements.