G03 DASALGORITHM RAMKOLEK  - apcjlquesada/APC_2023_2024_3rd_Term_PROJMAN GitHub Wiki

Table of Contents

PROJECT TITLE

Ramkolek: Document Management System for Project Documentation Papers Submission

PROJECT MEMBERS

Project Professor

NAME

EMAIL

Jose Eugenio L. Quesada

[email protected]

Project Adviser

NAME

EMAIL

Roselle Wednesday L. Gardon

[email protected]

Project Team

NAME

ROLE

EMAIL

Jeb Vincent Cajayon

Team Leader/Product Owner

[email protected]

Leila Angela Arcega

Team Member/Scrum Master

[email protected]

Jonlord Mirando

Team Member

[email protected]

Daniella Diana Soquiat

Team Member

[email protected]

Raina Marie Terania

Team Member

[email protected]

Lyka Tesorero

Team Member

[email protected]

1. COMPANY PROFILE

1.1 Company Background

Asia Pacific College, empowered by education and industry professionals as faculty and a balanced curriculum, aims to provide business and the information and communications technology industry in the Philippines and in the global community lifelong learning graduates who are anchored on the principles of integrity and professionalism.

Vision

Asia Pacific College envisions itself to be the preferred Higher Education Institution bridging academe and industry with its programs founded on the concepts and applications of IT, guided by the core values of integrity, industry and innovation that works.

Mission

Asia Pacific College, powered by education and industry professionals as faculty and a balanced curriculum, aims to provide business and the information and communications technology industry in the Philippines and in the global community lifelong learning graduates who are anchored on the principles of integrity and professionalism.

Values

APC aims to produce graduates with strong sense of industry or hard work, integrity or being honest and having strong moral / ethical principles, and innovation or constantly introducing new and creative methods or ideas.

2. BUSINESS CASE

2.1 Executive Summary

Asia Pacific College (APC) implements Project-Based Learning in their curriculum. These are capstone projects where students learn and apply it to the output. The current process of submitting project papers lacks a dedicated platform for viewing, managing, and submitting documents. Ramkolek provides a centralized project documentation process.

2.1.1 Issue

The current process of submission for documents online requires the sending of emails and using Microsoft teams. Asia Pacific College with PBL project documentation has no singular platform to use. This results in oversaturating different emails between proofreaders and students of PBL.

2.1.2 Anticipated Outcomes

This project anticipates deploying Ramkolek for Asia Pacific College in 2024. Ramkolek will be a document management system for APC students and faculty aimed at streamlining project document submission and improving overall efficiency in the PBL process. In the end state of the project, Ramkolek centers on paper submission and proofreading request processes. It will have an option to archive submissions, proofreading requests, and teams must be available in the system. Users can view the dashboard and get auto-generated reports. The system will also include a team module for professors to create groups for students.

2.1.3 Recommendation

The current system is recommended to centralize the project documentation process. Storing the documents in a single and organized location is an effective approach in keeping the project documents. This is more accessible for everyone involved. Ramkolek focuses on effectively improving the process of PBL by streamlining the document submission process and improving overall efficiency in the PBL process.

  • Ramkolek will provide a system that streamlines the project document submission and proofreading requests. This tracks the updates and the progress of the paper. The proposed system will eliminate the need for emailing or messaging the document the updates.
  • The proposed system tackles the challenge of time-consuming manual report creations and data collections for group project documentation. It will implement auto-generation of reports and data-gathering.
  • 2.1.4 Justification

    The reason why this project should be implemented in the first place is because once the students are done with PBL subjects it's off to be proofread, the problem is that only one member which is the leader of the group is the one and only to get the message of the proofreader only using via private message in Teams or Outlook as there is no guarantee way of knowing when the proofreading process is in work-in-progress or completed, especially that emails tend to be oversaturated with different notification, this caused a communication problem to both parties as these causes delays on viewing the PBL projects causing disorganization on sending the papers to the right people.

    2.2 Business Case Analysis Team

    Role

    Description

    Name

    Team Leader/Product Owner

    Manages the project, directs the team, and communicates with stakeholders.

    Jeb Vincent Cajayon

    Team Member/Scrum Master

    Facilitates meetings and works on documentation.

    Leila Angela Arcega

    Team Member

    Works on documentation.

    Jonlord Mirando

    Team Member

    Works on documentation.

    Daniella Diana Soquiat

    Team Member

    Works on documentation.

    Raina Marie Terania

    Team Member

    Works on documentation.

    Lyka Tesorero

    2.3 Problem Definition

    2.3.1 Problem Statement

    The current process of submitting project papers lacks a dedicated and organized platform for viewing, managing, and submitting project documentations. Additionally, the process of endorsing complete PBL papers for proofreading to English Cluster Heads suffers from the lack of updates on the side of students, as only one student per group receives notifications, leading to miscommunication among group members and professors, impacting both group and individual PBL participants.

    Specific Problems

  • The current process for project submissions along with the proofreading request form makes it difficult to keep track of files and updates because submission is done through email and MS Teams. Managing project submissions and proofreading requests lacks real-time status updates and the file versions are scattered in different locations. Notifications of updates and progress are done within MS Teams and email but can easily be lost among other messages, hindering the ability of the people involved to keep updated.
  • For the PBL professors and PBL coordinator in the current system it needs them to manually create reports and manually gathered data about a group’s project, that can be time-consuming for the faculty involved because they must locate and ask for the documents relating to a group’s project from the other PBL professors through email and MS Teams while storing those documents in a team created in MS Teams.
  • 2.3.2 Organizational Impact

    The implementation of Ramkolek will replace the currently used system, which uses Microsoft Teams and Microsoft Outlook as the primary platforms used in submission. It will also automate the process of notifying people in the submission and proofreading process of the current stage that the submission is in. Since the files will not be transferred through email and Teams, individual local copies of files will be avoided.

    As for the different roles in the current submission process, roles in the Ramkolek system remain largely the same as the current system as well. Having the same roles as the current system will help the system adhere to the business processes of APC and avoid generating confusion for the users.

    2.3.3 Technology Migration

    The system will be developed using the Laravel web-development framework. The Ramkolek system, to be more specific, will use the Filament starter kit uses the TALL stack for faster and more efficient development. The system will be hosted using Amazon Web Service as it is the cloud platform used by APC to host their websites. Account information for Ramkolek will be taken from APC’s existing information system.

    2.4 Project Overview

    2.4.1 Project Description

    Ramkolek is a web application that aims to serve as a portal for students to submit their project documentation papers by establishing a centralized and organized environment for uploading the papers and managing the project documents during the submission process. The project will consolidate all the file transfers involved in paper submission into one platform and create a multi-layered submission approval workflow system that will include the actors in the current process for access control.

    The proofreading request process and submission approval workflow will be based on the process used by the current system, except file transfers and the movement of the submission along the process will be done through the system. The project submission data will remain updatable before it gets the final approval from the professor to allow the users to make changes during the submission.

    As a dedicated platform, it will serve as a hub for students, faculty, and the library to access and manage the submitted papers, streamline the submission process, and reduce the amount of data encoded by the librarian.

    2.4.2 Goals and Objectives

    To develop a document management system for APC students and faculty aimed at streamlining project document submission and improving overall efficiency in the PBL process.
    Specific Objectives

  • To provide a web application that will streamline project documentation submission and proofreading requests, eliminating the need for sending files and updates through emailing or messaging via platforms like MS Teams. This application will also incorporate a status tracking system, enabling users to monitor the status, updates, and progress of each paper throughout the submission process while keeping the files in one system.
  • To implement a way to automate report generation and data gathering, by creating a system that allows users to view reports containing a summary regarding the submissions.
  • 2.4.3 Project Assessment

    Ramkolek aims to streamline processes, improve data management, ensure security and accessibility, and enhance communication within our academic community. To evaluate the performance of Ramkolek, the following measures could be considered:

  • Assess how effectively Ramkolek simplifies project submission and proofreading processes, reducing manual tasks, and improving overall efficiency.
  • Evaluate the system's ability to automate report generation and data gathering, providing valuable insights into project submissions and proofreading requests.
  • Determine the system's effectiveness in enhancing security and accessibility by centralizing project documentation and providing role-based permissions.
  • Measure the system's impact on communication between students, faculty, and librarians, focusing on real-time updates and notifications.
  • 2.4.4 Project Assumptions

    Here are the preliminary assumptions for the proposed system:

  • The users of the system are familiar with basic computer operations and can navigate the web application with minimal guidance.
  • Users have access to stable internet connections for seamless use of the web application.
  • The APC information system can provide necessary user data for account management and authentication.
  • Users adhere to the file format requirements for project documentation submission (Word and PDF).
  • Ramkolek will be hosted using APC’s AWS subscription.
  • APC’s Information Technology Resource Office will assist the development group in the deployment of Ramkolek.
  • The ITRO (information technology resources office) will also handle the system’s maintenance after deployment.
  • 2.4.5 Project Constraints

    Here are the preliminary constraints for the proposed system:

  • The system will only accept files up to 50MB in size for submission.
  • Project documentation papers must adhere to specific formatting and content guidelines.
  • The system will focus exclusively on PBL subjects within this school, limiting its usage to specific courses.
  • Users must download files from the system to make changes, which may introduce versioning challenges.
  • Access to the system requires valid APC credentials.
  • Teams that have completed the project submission process will be archived, limiting ongoing access to historical data.
  • Users cannot change their passwords within the system directly, requiring additional administrative steps for password management.
  • 2.4.6 Major Project Milestones

    Major milestones

    Milestone Dates

    Milestone Title

    Milestone 1
    (April 21, 2023)

    Project Milestone

    Milestone 2
    (May 4, 2023)

    First Client Meeting

    Milestone 3
    (Nov 23, 2023)

    Finalizing the system’s design and function

    Milestone 4
    (March 11, 2024)

    Prototype Presentation

    Milestone 5
    (July 15, 2024)

    Development (Software Coding)

    Milestone 6
    (September 23, 2024)

    Deploy System

    Milestone 7
    (October 9, 2024)

    Project Complete

    2.5 Strategic Alignment

    Asia Pacific College aims to provide business and the information and communications technology industry in the Philippines and in the global community lifelong learning graduates who are anchored on the principles of integrity and professionalism. The school prides itself on its industry-based learning, which is the core of their project-based learning approach. Ramkolek directly supports APC’s strategic plan as the system is built for the purpose of automating some aspects and streamlining the PBL documentation submission process. The system will serve as a platform that will assist users in managing PBL and proofreading documents in a more organized manner, enhancing the experience of handling PBL projects.

    2.6 Cost Benefit Analysis

    Benefits:

  • This automates report generation and data gathering, providing valuable insights.
  • A centralized platform that enhances communication through real-time updates and notifications.
  • The system provides a secure platform with role-based permissions, ensuring accessibility for authorized users.
  • It streamlines project documentation submission, saving time and effort for students, faculty, and librarians.

  • Costs:
  • Overall cost for the entire project is ₱3,095,503.95.
  • Hosting of the system will cost ₱ 1,300.79 per month using AWS EC2.
  • Maintenance and updates of the system may require additional labor from the ITRO.
  • 2.7 Alternative Analysis

    Outlook. Outlook is Microsoft’s email service provider. Because APC uses Microsoft 365, Outlook is the software used by students, faculty, and library for communication.

    MS Teams. Teams is a collaboration platform developed by Microsoft. It provides a centralized hub for team communication and collaboration, allowing users to chat, hold video meetings, share files, and work on documents together in real-time. The professor uses Microsoft Teams to post the final copies of the student's paper to the Ramkolek Teams. This ensures that the document is securely stored in a specific location and easily accessible to all relevant parties involved.

    APC Wikis. APC Wiki is an open-source system, wherein students can encode the content of every section of their project thesis/paper before submitting the final version of its documentation. Alternative methods like outlook, MS Teams, and APC Wikis were considered but were found lacking in terms of organization, security, or accessibility, making Ramkolek the preferred solution.

    2.8 Approvals

    Approval for the project will come from Mr. Manuel Sebastian Sanchez, the Project Sponsor, and a key stakeholder for the system.

    3. PROJECT CHARTER

    3.1 Executive Summary

    Project-Based Learning (PBL) is part of the curriculum in Asia Pacific College that is necessary for students to learn and apply the output of the projects in a form of capstone projects, these subjects include “Introduction to System and Design”, “System Analysis and design”, “Applied Project System Prototype”. But the latter part on proofreading is from “Applied Project System Prototype” to ensure the quality of the written document is up to standards. Currently to get these documents to be proofread there is no dedicated platform on viewing, managing, and submitting project documents, as students and professors will get miscommunications on the updated versions of the paper as this was done using via Emails or Teams but only one member of the PBL team will get the messages and updates leaving the other members announced, for PBL professors and coordinators they have to manually look up on reports on edited documents and any relationships to the documents based on the project. That is why this project will be the creation of a document management system in a form of a website called Ramkolek, this system can create current team members from PBL, generating report and gathering data by letting users to view and download the reports, and giving updates in a form of messages included on the website.

    3.2 Project Purpose/Justification

    3.2.1 Business Need/Case:

    The purpose of developing a documentation management system for the APC is to have a formal process of submission for project documentations online instead of having to do so through email and Microsoft Teams. Currently, there is no singular platform used by APC to handle PBL project documentations. Microsoft Teams and Outlook are used in notifying and transferring files between students and their professors. The need for a singular platform for proofreading in PBL is necessary as emails and other messaging platforms tend to be oversaturated with different emails causing a mix-up between the assigned proofreaders and students of PBL.

    3.2.2 Business Objectives

    Asia Pacific College aims to provide business and the information and communications technology industry in the Philippines and in the global community lifelong learning graduates who are anchored on the principles of integrity and professionalism. The school prides itself on its industry-based learning, which is the core of their project-based learning approach. Ramkolek directly supports APC’s mission as the system is built for the purpose of automating some aspects and streamlining the PBL documentation submission process. The system will serve as a platform that will assist users in managing PBL and proofreading documents in a more organized manner, enhancing the experience of handling PBL projects

    3.3 Project Description

    The project, Ramkolek, is a web application that aims to serve as a portal for students to submit their project documentations by establishing a centralized and organized environment for uploading the papers and managing the project documents during the submission process. The project will consolidate all the file transfers involved in paper submission into one platform and create a multi-layered submission approval workflow system that will include the actors in the current process for access control. The proofreading request process and submission approval workflow will be based on the process used by the current system, except file transfers and the movement of the submission along the process will be done through the system. The project submission data will remain updatable before it gets the final approval from the professor to allow the users to make changes during the submission. As a dedicated platform, it will serve as a hub for students, faculty, and the library to access and manage the submitted papers and streamline the submission process.

    3.3.1 Project Objectives and Success Criteria

    To develop a document management system for APC students and faculty aimed at streamlining project document submission and improving overall efficiency in the PBL process.

    Specific Objectives

  • To provide a web application that will streamline project documentation submission and proofreading requests, eliminating the need for sending files and updates through emailing or messaging via platforms like MS Teams. This application will also incorporate a status tracking system, enabling users to monitor the status, updates, and progress of each paper throughout the submission process while keeping the files in one system
  • To implement a way to automate report generation and data gathering, by creating a system that allows users to view reports containing a summary regarding the submissions.
  • 3.3.2 Requirements

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

  • The web application must include the paper submission and proofreading request processes.
  • The system must have summary dashboards and be able to generate reports.
  • The system must include a team module for professors to create groups for students.
  • An option to archive submissions, proofreading requests, and teams must be available in the system.

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

    3.3.3 Constraints

    The following constraints pertain to the Ramkolek project:

  • Data gathering, system design, and development of the system is limited to only 9 months, which may not be enough time to adjust and implement additional features and changes.
  • 3.3.4 Assumptions

    Here are the preliminary assumptions for the proposed system:

  • The users of the system are familiar with basic computer operations and can navigate the web application with minimal guidance.
  • Users have access to stable internet connections for seamless use of the web application.
  • The APC information system can provide necessary user data for account management and authentication.
  • Users adhere to the file format requirements for project documentation submission (Word and PDF).
  • Ramkolek will be hosted using APC’s AWS subscription.
  • APC’s Information Technology Resource Office will assist the development group in the deployment of Ramkolek.
  • The ITRO (information technology resources office) will also handle the system’s maintenance after deployment.
  • 3.3.5 Preliminary Scope Statement

    The Ramkolek project will include the design, testing, and delivery of a document management system for APC. The development of the system will be done on the development teams’ personal devices. Additional computers used for development will be borrowed from APC’s open laboratories. APC will also provide the AWS subscription required to host the system and store the project documents. Account information for users will be taken from APC’s existing information system.

    3.4 Risks

    The following risks for the Ramkolek 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:

  • External threats of attack on the deployed system are possible.
  • There might be a learning curve for users when the system is deployed.
  • 3.5 Project Deliverables

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

  • Centralized platform for project documentation submission
  • Proofreading requesting process module
  • Summary dashboard and reports generation
  • Team creation and management module
  • 3.6 Summary Milestone Schedule

    The project Summary Milestone Schedule is presented below. As requirements are more clearly defined this schedule may be modified. Any changes will be communicated through project status meetings by the project manager.

    Major milestones

    Project Milestone

    Target Date
    (mm/dd/yyyy)

    Project start

    04/21/2023

    First Client Meeting

    05/04/2023

    Finalized System Design

    11/23/2023

    System Development Start

    01/08/2024

    System Presentation

    03/11/2024

    System Testing Complete

    08/09/2024

    Project Handover

    09/20/2024

    Project Complete

    09/27/2024

    3.7 Summary Budget

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

    Summary Budget – List component project costs

    Project
    Component

    Component
    Cost (₱)

    Units

    Duration
    (Month)

    Total Cost (₱)

    Development Team

    Project Manager

    ₱35,000.00

    1

    12

    ₱420,000.00

    Web Developer

    ₱34,000.00

    5

    12

    ₱2,040,000.00

    Desktops

    ₱25,000.00

    6

    1

    ₱125,000.00

    AWS EC2

    ₱1,300.79

    1

    5

    ₱6,503.95

    Office Space

    ₱37,000.00

    1

    12

    ₱444,000.00

    Electricity

    ₱4,000.00

    1

    12

    ₱48,000.00

    Internet

    ₱1,000.00

    1

    12

    ₱12,000.00

    Total

    ₱3,095,503.95

    3.8 Project Approval Requirements

    Success for the Ramkolek project will be achieved when a fully tested system, and all technical documentation, is deployed within the time and cost constraints indicated in this charter. The system must meet or exceed the predefined requirements agreed upon with the stakeholders. Equally important is security compliance, mandating adherence to standard regulation, and industry best practices to safeguard sensitive data and ensure privacy. This approach ensures transparency, criteria adherence, and valuable insights for future projects. Success will be determined by the Project Sponsor, Sir Manuel Sebastian Sanchez, who will also authorize the completion of the project.

    3.9 Project Manager

    Jeb Cajayon is the project manager for the Ramkolek Project. The project manager’s responsibility is to manage all project tasks, scheduling, and communication regarding the Ramkolek project. His team, consisting of 5 members, excluding the team leader. The project manager will oversee the development and implementation of the document management system project. He is also responsible for managing project expenditures within the approved budget, allocating resources, and maintaining communication with all stakeholders. The project manager’s knowledge and expertise in development contribute to the project’s success by guiding development and ensuring alignment with organizational goals. Any additional funding must be requested through the project sponsor, Asia Pacific College. The project manager will provide weekly updates to the project sponsor.

    4. STAKEHOLDER MANAGEMENT STRATEGY

    4.1 Introduction

    This Stakeholder Management Strategy outlines a comprehensive approach to identify, engage, and collaborate with all parties involved in the project management system. Our core objective lies actively in engaging and managing the expectations of all stakeholders throughout the project lifecycle. Effective stakeholder management is pivotal for a project success because it allows us to do the following:

  • Secure project buy-in: By understanding stakeholders' priorities, we can build a strong support for the system’s implementation.
  • Navigate challenges: Having a good stakeholder management strategy helps with anticipating future disputes or opposing views. We can then develop plans and strategies to mitigate these challenges and ensure all voices are heard.
  • Optimize project outcomes: By understanding each stakeholder’s needs, we can tailor the system’s capabilities to deliver the most value for all parties involved.
  • With this strategy, stakeholders will profit from a system that meets their individual demands, and the project will thrive with their active involvement and support. Our goal with this strategy is to create a system that will satisfy all stakeholders.

    4.2 Identify Stakeholders

    The team identified the different stakeholders of this project by understanding the flow of how the current system works, while also finding the current issues and inefficiencies in it. This was achieved by conducting different sessions of interviews with them through meetings and consultations. We aimed to understand not only the flow of the current system but also the interests and influence of each stakeholder. Our goal is to ensure that all stakeholders' needs and expectations are effectively managed throughout the project. Therefore, we engaged with stakeholders regularly through various channels such as meetings and consultations. It was essential to recognize that stakeholders have a personal stake in the project and will be impacted by its implementation or success.

  • The identified stakeholders we found that will benefit from this project are, the developers, PBL Coordinator, Head Librarian, Executive Director, The Head of ITRO (Information technology resources office), English Cluster Head, and the students of APC. This list of stakeholders was established after pinpointing the vital people in the project paper submission and proofreading requesting processes.
  • To understand the influence of the identified stakeholders the team needs to gauge their interest in how they feel and use the current system and process while the team gathers data on what improvements they would want to see.
  • To effectively manage the stakeholders' needs and expectations with this project, we created different needs statements when the team was consulting with them about their issues with the current system so we could identify their pain points. Because of that, the team created a list of objectives they wanted to achieve along with a backlog of features that can be implemented into the system to meet their needs.
  • 4.3 Key Stakeholders

    The success of Ramkolek depends on understanding the needs of key stakeholders in APC's PBL program. The project's key users are students, the PBL coordinator, and professors. Ramkolek will meet their needs by streamlining the submission process for students, improving project monitoring for coordinators, and integrating proofreading features for academics.

    Additionally, the Executive Director and the English cluster head have also been identified as a key stakeholder as they have an important role in the system especially in the proofreading request process. It is crucial to involve these stakeholders in the decision-making process and ensure their input and thoughts are considered throughout the project.

    4.4 Stakeholder Analysis

    Conducting a stakeholder analysis is an essential element of the stakeholder management plan for the Document Management System. This analysis involves identifying and categorizing stakeholders based on their level of power, interest, and engagement in the project. By understanding the stakeholders’ perspectives and requirements. This enables the team to manage expectations efficiently and effectively throughout the project. The table below outlines the stakeholders for the project, indicating those who have a high or low level of interest and power in the development process.

    Name

    Position

    Internal/External

    Project Role

    Contact Information

    Team
    Dasalgorithm

    Team
    members of
    operations

    Internal

    Development
    Team

    [email protected] [email protected]
    [email protected]
    [email protected]
    [email protected]
    [email protected]

    Sir Manuel
    Sebastian
    Sanchez

    PBL
    Coordinator

    External

    External User

    [email protected]

    Ms. Maylene
    Mallari

    head Librarian

    External

    External User

    [email protected]

    Ms. Rhea-Luz
    Valbuena

    Executive
    Director

    External

    External User

    [email protected]

    Sir Jojo Castillo

    Head of ITRO

    External

    consultant

    [email protected]

    Sir Leonardino
    Lapira

    English Cluster
    Head

    External

    External User

    [email protected]

    Stakeholder Analysis

    Name

    Power/Interest

    Current
    Engagement

    Potential Management Strategies

    Team
    Dasalgorithm

    Low/High

    Supportive

    Development TeaM

    Mr. Manuel
    Sebastian
    Sanchez

    High/High

    Supportive

    Sir Sanchez works closely with the team throughout the development of the system and gave us the information on the current system used in handling PBL documentations’ submission. He is approachable and is accessible through messaging, email, and both online and face-to-face meetings

    Ms. Maylene
    Mallari

    Medium/Medium

    Neutral

    Ms. Mallari gave us information on the data needed by the library from our system. She also gives us information on the library’s own system of storing and accepting papers.

    Ms. Rhea-Luz
    Valbuena

    Medium/Medium

    Neutral

    Ms. Valbuena gave us more insight on the process for PBL submission and analytics that may be needed from the system.

    Mr. Leonardino
    Lapira

    Medium/Medium

    Neutral

    Mr. Lapira gave us the information on the proofreading process in APC’s English cluster that we will need to follow for our system.

    Mr. Jojo Castillo

    Medium/High

    Supportive

    Mr. Castillo advices us on how we can transfer the current users into our system. He also gives us insight on what technologies we can utilize for our project.

    5. SCOPE MANAGEMENT PLAN

    5.1 Introduction

    The Scope Management Plan details how the project scope will be defined, developed, and verified. It clearly defines who is responsible for managing the projects’ scope and acts as a guide for managing and controlling the scope.

    Project Scope Management follows a five-step process; Collect Requirements, Define Scope, Create WBS, Verify Scope, and Control Scope.

  • Collect Requirements – This step involves gathering information from all the stakeholders involved in Ramkolek: Document Management System for Project Documentation Papers Submission.
  • Define Scope – Once the requirements are collected, the second step is to analyze and to use the requirement to define the scope.
  • Create WBS – This process breaks project deliverables down into progressively smaller and more manageable components which, at the lowest level, are called work packages.
  • Verify Scope – this step involves formal approval on the defined scope. This is to ensure that all stakeholders approve Ramkolek: Document Management System for Project Documentation Papers Submission of its goals and deliverables.
  • Control Scope – this is the process of monitoring/controlling the project/product scope as well as managing any changes in the scope baseline.
  • 5.2 Scope Management Approach

    The project manager handles and manages the scope management. The scope management involves defining, identifying, and controlling the scope, creating the work breakdown structure (WBS). The web application’s scope statement is defined by aiming to streamline project document submission and improving overall efficiency in the PBL process. The scope used was defined using Work Breakdown Structure (WBS). The scope was measured and verified also with Scope Baseline. The scope changes its process with the authorization, and the approval from the project sponsor. The project sponsor will also be accepting the final project deliverable and approves acceptance of project scope.

    5.3 Roles and Responsibilities

    This section provides information on the Roles and Responsibilities for the Scope Management Document. Product Owner, Scrum Master, Team Members, Stakeholders and other key persons who are involved in managing the scope of the project.


    Project Sponsor - The Project Sponsor defines the project’s objectives and the scope. All the project’s deliverables are to be approved by the Project Sponsor. Project Adviser - They offer strategic guidance with their deep understanding of similar projects that they have encountered. They also provide project insights that better define the project.
    Product Owner - The responsibility of a Product Owner is to collaborate with the stakeholders. They are also in charge of a strategic plan that outlines how the project will evolve.
    Scrum Master – Scrum Masters lead and facilitate meetings such as product backlog refinement, sprint planning, retrospectives that point out areas to improve and to promote effective collaboration within the team.
    Project Manager - They lead the team through the project. They are generally the one in charge of the project’s execution and are the primary communicator for the project sponsor and stakeholders.
    Developer – The responsibility of a developer is creating deliverables. This involves documentation and submitting project increments from the sprint planning meeting.
    Stakeholders - They provide insightful feedback on the project to maximize its value. Their comments and concerns are highly valuable to the project to make sure that the project will meet all stakeholders’ needs.

    5.4 Scope Definition

    Ramkolek aims to provide a system that will serve as a platform that will assist users in managing PBL and proofreading documents in a more organized manner, enhancing their experience of handling PBL projects. This scope of Ramkolek will be serving as a portal for students to submit their project documentations by establishing a centralized and organized environment for uploading the papers and managing the project documents during the submission process.

    5.5 Project Scope Statement

    The project aims in streamlining project document submission and improving overall efficiency in the PBL process.
    The following are list of requirements to achieve success:

  • Ramkolek should feature paper submission and proofreading request processes.
  • The system must have summary dashboards and be able to generate reports.
  • It should include a team module for professors to create groups for students.
  • An option to archive submissions, proofreading requests, and teams must be available in the system.

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

    The following are deliverables that Ramkolek will provide:

  • Centralized platform for project documentation submission.
  • Proofreading requesting process module.
  • Summary dashboard and reports generation.
  • Team creation and management module.

  • Project Deliverables
    The following are project exclusions from the project deliverable:

  • The project excludes other departments, except for only the school of computing and IT, which is why only the PBL subjects: NTSDEV, SYADD, and CSPROJ will be used
  • The system will not be available to non-APC individuals without APC accounts.
  • Files cannot be edited within the system. And because of that the file needs to be downloaded from the system to make changes within the document.
  • The system can’t change the account’s password, that needs to be done with the ITRO because those are Microsoft accounts that the system doesn’t have access to.

  • The following constraints pertain to the Ramkolek project:

  • Data gathering, system design, and development of the system is limited to only 9 months, which may not be enough time to adjust and implement additional features and changes.

  • The following are the project assumptions from working under to complete the project:

  • The users of the system are familiar with basic computer operations and can navigate the web application with minimal guidance.
  • Users have access to stable internet connections for seamless use of the web application.
  • The APC information system can provide necessary user data for account management and authentication.
  • Users adhere to the file format requirements for project documentation submission (Word and PDF).
  • Ramkolek will be hosted using APC’s AWS subscription.
  • APC’s Information Technology Resource Office will assist the development group in the deployment of Ramkolek.
  • The ITRO (information technology resources office) will also handle the system’s maintenance after deployment.
  • 5.6 Work Breakdown Structure

    This WBS follows the Project Management Body of Knowledge (PMBOK) project life cycle. The Ramkolek project’s components are divided into the five PMBOK life cycle phases: initiation, planning, execution, control, and closing. Each of these phases is further broken down into smaller components in the form of tasks and work packages. In addition to the PMBOK life cycle, the execution phase incorporates Agile methodology, using sprints to align with scrum practices for the system's development.

    Level

    WBS Code

    Element Name

    1

    1

    Ramkolek

    2

    1.1

    Initiation

    3

    1.1.1

    Study the Current Project Paper Submission Process

    3

    1.1.2

    Develop the Business Case

    3

    1.1.3

    Develop the Project Charter

    3

    1.1.4

    Develop Stakeholder Analysis

    2

    2.1

    Planning

    2

    2.1

    Planning

    3

    2.1.1

    Develop the Work Breakdown Structure

    3

    2.1.2

    Develop the Scope Management Plan

    3

    2.1.3

    Develop the Schedule Management Plan

    3

    2.1.4

    Develop the Cost Management Plan

    3

    2.1.5

    Develop the Work Packages

    3

    2.1.6

    Develop the Human Resources Plan

    3

    2.1.7

    Develop the Change Management Plan

    3

    2.1.8

    Develop the Communication Management Plan

    3

    2.1.9

    Develop the Quality Management Plan

    3

    2.1.10

    Develop the Risk Management Plan

    3

    2.1.11

    Develop the Procurement Management Plan

    3

    2.1.12

    Develop the Implementation Plan

    3

    2.1.13

    Design System

    2

    3.1

    Execution

    3

    3.1.1

    Develop System

    4

    3.1.1.1

    Sprint 01

    5

    3.1.1.1.1

    User Authentication

    5

    3.1.1.1.2

    Project Submission Form

    5

    3.1.1.1.3

    Proofreading Request Form

    4

    3.1.1.2

    Sprint 02

    5

    3.1.1.2.1

    Roles and Permissions

    5

    3.1.1.2.2

    System Notifications

    5

    3.1.1.2.3

    Submission and Request Form Approval

    4

    3.1.1.3

    Sprint 03

    5

    3.1.1.3.1

    User Dashboard

    5

    3.1.1.3.2

    Report Generation

    2

    4.1

    Control

    3

    4.1.1

    Project Progress Tracking

    3

    4.1.2

    User Acceptance Testing

    2

    5.1

    Closeout

    3

    5.1.1

    Documents Compilation and Finalization

    3

    5.1.2

    Project Handover and Acceptance

    3

    5.1.3

    Closure Meeting

    5.7 Scope Verification

    The project team will use various techniques for scope verification to guarantee that Ramkolek: Document Management System for Project Documentation deliverables satisfy the original scope. These methods include:

  • Documentation - It helps ensure that Ramkolek: Document Management System for Project Documentation is delivered on time and within budget. This ensures features align with what was originally planned.
  • System Demonstration - Showcasing the functionalities of Ramkolek: Document Management System for Project Documentation Papers Submission allows the stakeholders to see the system in action and verify that it meets their expectations according to the scope.
  • Sign-off Criteria - This provides a formal record of stakeholder approval, ensuring they are satisfied with what was delivered within the agreed scope.
  • Stakeholder Meeting and documentation - The formal meetings with the stakeholder ensure that the project meets the established scope requirement. Documentations of the meeting such as minutes of the meeting records the formal acceptance of deliverables.
  • 5.8 Scope Control

    Scope control is the process of monitoring the status of the scope of Ramkolek: Document Management System for Project Documentation. This section also details the change process for making changes to the scope baseline.

  • Identifying the Change - Any stakeholder or team member can identify a need for a change request. This provides the proposed change, and its impact on Ramkolek: Document Management System for Project Documentation.
  • Review and Evaluation - The evaluation of the change request will review its impact on the project scope, deliverables, and goals.
  • Change Request Documentation - This document the change request. The document includes details about the change request, and its effect upon implementation.
  • Change Process Approval - This step involves the project manager whether to approve the change request.
  • Implementing Approved Changes - This step involves the changes Ramkolek: Document Management System for Project Documentation and its documentation to be updated.
  • Communication about the update - It is important that all team members and stakeholders communicate on the update on the system and the document. This will clear confusion about the project.
  • The rejected change request will keep the original goals and objectives of the project.
  • 6. COST MANAGEMENT PLAN

    6.1 Introduction

    Throughout the project’s lifecycle this document will define the cost management plan of the Ramkolek. The document will contain information on the person responsible of setting the costs, the method of which the project costs are measured, and how the costs will be controlled.

    6.2 Cost Management Approach

    The cost management approach will be explained in the following:

  • Planning:
    To ensure that the system will be delivered on time and on budget, the team will be using Open Project as the project management software. The project will utilize the Work Breakdown Structure (WBS) based on Project Management Body of Knowledge (PMBOK) these cycles will help breakdown the work packages based on layers levels of system features that are a priority on creating Ramkolek as project lifecycles. This will allow the team to monitor the progress and costs of the project.
  • Cost estimations:
    The cost of Ramkolek’s budget will be reflected on the human resources and hardware requirements for both the creation and operation on the website, as each update on features of the website will add the cost, as the team keep on track on the project’s schedule and budget on par with the project’s expected outcome. These estimations are based on the standard rates for each unit.
  • 6.3 Measuring Project Costs

    In this section, this will explain how the WBS structure works in creating system features, as each will be explained in different layers of levels.

    The PMBOK focuses on Earned Value Management for measuring and controlling a project’s costs. Earned Value Management is the best tool used that provides comprehensive data that we can use in our project. Four Measurements; Schedule Variance (SV), Cost Variance (CV), Schedule Performance Index (SPI) and Cost Performance Index (CPI) will provide insight effective management without overburdening the Project Manager with Earned Value calculations and measurements.

    Schedule Variance (SV) is a measurement of the schedule performance for a project. It’s calculated by taking the Earned Value (EV) and subtracting the Planned Value (PV). This tells us if Ramkolek is behind or ahead of schedule. If SV is zero, then the project is perfectly on schedule. If SV is greater than zero, the project is earning more value than planned thus it’s ahead of schedule. If SV is less than zero, the project is earning less value than planned thus it’s behind schedule. This means that the team should identify the cause of the delay.

    Cost Variance (CV) is a measurement of the budget performance for a project. CV is an indicator of how we maintain the project in Ramkolek. CV is calculated by subtracting Actual Costs (AC) from Earned Value (EV). EV is the actual value earned in the project. AC is the actual costs incurred to date, thus when we subtract what our actual costs from the EV, we have a good measurement which tells us if we are above or below budget. If the CV is zero, then the project is perfectly on budget. If the CV is positive, then it means we are underbudget. The project has earned more than the planned cost. If the CV is negative, it is overbudget. It has earned less than planned.

    Schedule Performance Index (SPI) measures the progress achieved against that which was planned. SPI is calculated as EV/PV. If EV is equal to PV, the value of the SPI is 1. If EV is less than the PV then the value is less than 1, which means the project is behind schedule. If EV is greater than the PV the value of the SPI is greater than one, which means the project is ahead of schedule. A well performing project should have its SPI as close to 1 as possible, or maybe even a little under 1.

    Cost Performance Index (CPI) measures the value of the work completed compared to the actual cost of the work completed. CPI is calculated as EV/AC. If CPI is equal to 1 the project is perfectly on budget. If the CPI is greater than 1 the project is under budget, if it’s less than 1 the project is over budget.

    6.4 Reporting Format

    Since the stakeholders can be easily reported on it will be contacted on a weekly basis via spreadsheet showing the cost elements, the baseline costs, and the units. With each report being addressed this will be part of the cost management plan as it will give the team the information on the action necessary to address the client and the stakeholder’s concerns on Ramkolek.

    6.5 Cost Variance Response Process

    The Control Thresholds for this project is 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.

    6.6 Cost Change Control Process

    The cost change control process will follow the established project change request process. If any change in the cost and budget are to be done to the project, the group will have to communicate that to the project sponsor. Official changes can only occur after the project sponsor has reviewed the request for change and approval is given.

    6.7 Project Budget

    The summary budget is presented below.

    Summary Budget – List component project costs

    Project
    Component

    Component
    Cost (₱)

    Units

    Duration
    (Month)

    Total Cost (₱)

    Development Team

    Project Manager

    ₱35,000.00

    1

    12

    ₱420,000.00

    Web Developer

    ₱34,000.00

    5

    12

    ₱2,040,000.00

    Desktops

    ₱25,000.00

    6

    1

    ₱125,000.00

    AWS EC2

    ₱1,300.79

    1

    5

    ₱6,503.95

    Office Space

    ₱37,000.00

    1

    12

    ₱444,000.00

    Electricity

    ₱4,000.00

    1

    12

    ₱48,000.00

    Internet

    ₱1,000.00

    1

    12

    ₱12,000.00

    Total

    ₱3,095,503.95

    7. SCHEDULE MANAGEMENT PLAN

    7.1 Introduction

    The schedule management plan plays an important part in project management. This document covers the approach used by the team in schedule management, how the team will respond to changes, and the procedure by which the team will manage the project timeline. This plan will ensure that the project will be finished within the set timeline and how the team may react to deviations in events.

    7.2 Schedule Management Approach

    For this project, the schedule will be managed using the project management software, Open Project. Open Project will help the team schedule and set the duration of tasks as work packages. The tool can also be utilized to visualize the schedule as a Gantt chart, making it easier to keep track of the individual work packages. Development of the schedule will be the responsibility of all members of the team. The project manager will lead scheduled meetings and individual members will give their input and feedback during the meeting to gain the insight of all members.

    7.3 Schedule Control

    As the project follows a mixture of PMBOK and Agile methodology, control on the project schedule varies depending on the phase that the project is in. During initialization and planning, the team more closely follows a PMBOK practice so long-term schedules are set at the beginning of each phase based on the timeline set by the project sponsor. On the other hand, the execution phase follows Agile methodology more, which is why the team uses Scrum sprint practices. Schedules are set for short term periods, specifically three-week sprints. The schedules for each sprint are set at the beginning of the sprint during the sprint planning meeting. Schedules are reviewed at the end of each sprint during the sprint review and sprint retrospective meetings where feedback from the members is taken. Updates on the schedules are then done at the next sprint planning meeting with the feedback in mind from the review and retrospectives.

    Role

    Responsibilities

    Project Manager

    Facilitates scheduling meetings and communicates with the stakeholders.

    Development Team

    Gives their insight and feedback on the schedules set. They can also change schedules and durations of tasks on the Open Project schedule.

    Stakeholders

    Can give the development team their feedback on the project’s development and schedules.

    7.4 Schedule Changes and Thresholds

    The project’s planned schedule is designed to adhere to the timeline set by the project sponsor, the schedule may be subject to change. For example, if unexpected events were to occur or if a false estimation may have been made during the initial planning. In such cases, great changes to the schedule must first be requested of the project sponsor. After the request has been acknowledged and permission for change has been granted, only then is the team allowed to update the set dates on the schedule.

    7.5 Scope Change

    As the project’s scope may be subject to change for one reason or another, re-baselining of the schedule will follow the modification. Once the scope has been altered with approval from the project sponsor, the team will follow the following steps and adjust the schedule accordingly:

  • Estimation of Effort
    The amount and difficulty of any additional work to be done will be quantified for ease of understanding within the team. Estimation will be done in a team meeting involving active and open discussion with the members. Factors like complexity and available resources will be considered for the new tasks.

  • Estimation of Time
    Once the difficulty of the work has been assessed and communicated, the team will then create an estimate of the amount of time needed to complete the task. This will be done with the team’s currently active tasks and skill level in mind to set a realistic goal for the new task.

  • Schedule Fitting
    After the difficulty and estimated duration of any new tasks have been set, changes into the schedule may now begin. The team will integrate the additional tasks into the schedule and adjust it as needed.

  • Sponsor Approval
    The new schedule will be presented to the project sponsor for validation. Only after approval will the new tasks be finalized in the project schedule and hence officially be part of the latest schedule.
  • 8. WORK BREAKDOWN STRUCTURE

    8.1 Introduction

    Ramkolek is a web-based document management system that aims to serve as a portal for students to submit their project documentations. To ensure effective project management, a Work Breakdown Structure is included among the documents to be delivered with the system. The WBS defines the scope and outlines the various components throughout the project phases that must be completed.

    This WBS follows the Project Management Body of Knowledge (PMBOK) project life cycle. The Ramkolek project’s components are divided into the five PMBOK life cycle phases: initiation, planning, execution, control, and closing. Each phase is further broken down into smaller components in tasks and work packages. In addition to the PMBOK life cycle, the execution phase incorporates Agile methodology, using sprints to align with scrum practices for the system's development.

    8.2 Outline View

    The outline view of the Ramkolek web application provides a clear and summarized high-level overview of the project’s development. As presented below, the components are presented in a structured and indented list. Each item is numbered uniquely for identification and indented to represent the component’s relationships as either parent or child.

    1. Ramkolek

    1.1 Initiation


    1.1.1 Study the Current Project Paper Submission Process
    1.1.2 Develop the Business Case
    1.1.3 Develop the Project Charter
    1.1.4 Develop Stakeholder Analysis
    1.1.5 Develop Stakeholder Management Strategy

    2.1 Planning


    2.1.1 Develop the Work Breakdown Structure
    2.1.2 Develop the Scope Management Plan
    2.1.3 Develop the Schedule Management Plan
    2.1.4 Develop the Cost Management Plan
    2.1.5 Develop the Work Packages
    2.1.6 Develop the Human Resources Plan
    2.1.7 Develop the Change Management Plan
    2.1.8 Develop the Communication Management Plan
    2.1.9 Develop the Quality Management Plan
    2.1.10 Develop the Risk Management Plan
    2.1.11 Develop the Procurement Management Plan
    2.1.12 Develop the Implementation Plan
    2.1.11 Design System

    3.1 Execution


    3.1.1 Develop System
    3.1.1.1 Sprint 01
    3.1.1.1.1 User Authentication
    3.1.1.1.2 Project Submission Form
    3.1.1.1.3 Proofreading Request Form
    3.1.1.2 Sprint 02
    3.1.1.2.1 Roles and Permissions
    3.1.1.2.2 System Notifications
    3.1.1.2.3 Submission and Request Form Approval
    3.1.1.3 Sprint 03
    3.1.1.3.1 User Dashboard
    3.1.1.3.2 Report Generation

    4.1 Control


    4.1.1 Project Progress Tracking
    4.1.2 User Acceptance Testing

    5.1 Closeout


    5.1.1 Documents Compilation and Finalization
    5.1.2 Project Handover and Acceptance
    5.1.3 Closure Meeting

    8.3 Hierarchical Structure

    Like the outline view, the hierarchical structure presents the project’s overview but does not use an indented list. Instead, the hierarchical structure uses a table with three columns to represent the level, number code, and name of each component.

    Level

    WBS Code

    Element Name

    1

    1

    Ramkolek

    2

    1.1

    Initiation

    3

    1.1.1

    Study the Current Project Paper Submission Process

    3

    1.1.2

    Develop the Business Case

    3

    1.1.3

    Develop the Project Charter

    3

    1.1.4

    Develop Stakeholder Analysis

    2

    2.1

    Planning

    2

    2.1

    Planning

    3

    2.1.1

    Develop the Work Breakdown Structure

    3

    2.1.2

    Develop the Scope Management Plan

    3

    2.1.3

    Develop the Schedule Management Plan

    3

    2.1.4

    Develop the Cost Management Plan

    3

    2.1.5

    Develop the Work Packages

    3

    2.1.6

    Develop the Human Resources Plan

    3

    2.1.7

    Develop the Change Management Plan

    3

    2.1.8

    Develop the Communication Management Plan

    3

    2.1.9

    Develop the Quality Management Plan

    3

    2.1.10

    Develop the Risk Management Plan

    3

    2.1.11

    Develop the Procurement Management Plan

    3

    2.1.12

    Develop the Implementation Plan

    3

    2.1.13

    Design System

    2

    3.1

    Execution

    3

    3.1.1

    Develop System

    4

    3.1.1.1

    Sprint 01

    5

    3.1.1.1.1

    User Authentication

    5

    3.1.1.1.2

    Project Submission Form

    5

    3.1.1.1.3

    Proofreading Request Form

    4

    3.1.1.2

    Sprint 02

    5

    3.1.1.2.1

    Roles and Permissions

    5

    3.1.1.2.2

    System Notifications

    5

    3.1.1.2.3

    Submission and Request Form Approval

    4

    3.1.1.3

    Sprint 03

    5

    3.1.1.3.1

    User Dashboard

    5

    3.1.1.3.2

    Report Generation

    2

    4.1

    Control

    3

    4.1.1

    Project Progress Tracking

    3

    4.1.2

    User Acceptance Testing

    2

    5.1

    Closeout

    3

    5.1.1

    Documents Compilation and Finalization

    3

    5.1.2

    Project Handover and Acceptance

    3

    5.1.3

    Closure Meeting

    8.4 Tabular View

    The tabular view, like the hierarchical structure, uses a table to provide the overview of the project. This table divides the project according to the level of the component, which makes it easier to view the components of the same level grouped together in relation to the parent component.

    Level 1

    Level 2

    Level 3

    Level 4

    Level 5

    1 Ramkolek

    1.1 Initiation

    1.1.1 Study the Current Project Paper Submission Process
    1.1.2 Develop the Business Case
    1.1.3 Develop the Project Charter
    1.1.4 Develop Stakeholder Analysis
    1.1.5 Develop Stakeholder Management Strategy

    2.1 Planning

    2.1.1 Develop the Work Breakdown Structure
    2.1.2 Develop the Scope Management Plan
    2.1.3 Develop the Schedule Management Plan
    2.1.4 Develop the Cost Management Plan
    2.1.5 Develop the Work Packages
    2.1.6 Develop the Human Resources Plan
    2.1.7 Develop the Change Management Plan
    2.1.8 Develop the Communication Management Plan
    2.1.9 Develop the Quality Management Plan
    2.1.10 Develop the Risk Management Plan
    2.1.11 Develop the Procurement Management Plan
    2.1.12 Develop the Implementation Plan
    2.1.13 Design System

    3.1 Execution

    3.1.1 Develop System

    3.1.1.1 Sprint 01
    3.1.1.2 Sprint 02
    3.1.1.3 Sprint 03

    3.1.1.3.2 User Authentication
    3.1.1.3.3 Project Submission Form
    3.1.1.3.4 Proofreading Request Form
    3.1.1.1.1 Roles and Permissions
    3.1.1.1.2 System Notifications
    3.1.1.1.3 Submission and Request Form Approval
    3.1.1.1.1 User Dashboard
    3.1.1.1.2 Report Generation

    4.1 Control

    4.1.1 Project Progress Tracking
    4.1.2 User Acceptance Testing

    5.1 Closeout

    5.1.1 Documents Compilation and Finalization
    5.1.2 Project Handover and Acceptance
    5.1.3 Closure Meeting

    8.5 Tree Structure View

    Moving away from lists and tables, the tree structure view is the project plan overview in the form of a visual representation to make the understanding of the project components and relationships more intuitive. Each component is represented by a node. High level components are placed higher on the tree and connect to the lower levels through branches.

    View it here at page 25

    8.6 WBS Dictionary

    The WBS Dictionary contains all the details of the WBS which are necessary to successfully complete the project. Most importantly it contains a definition of each Work Package which can be thought of as a mini scope statement.

    Level

    WBS Code

    Element Name

    Definition

    1

    1

    Ramkolek Web Application

    All work to implement a new document management system.

    2

    1.1

    Initiation

    The work to initiate the project.

    3

    1.1.1

    Study the Current Project Paper Submission Process

    Investigate the current process being used for project documentation submission by interviewing the stakeholders and the client.

    3

    1.1.2

    Develop the Business Case

    3

    1.1.2

    Develop Project Charter

    Project Manager to develop the Project Charter.

    3

    1.1.3

    Deliverable: Submit Project Charter

    Project Charter is delivered to the Project Sponsor.

    3

    1.1.4

    Project Sponsor Reviews Project Charter

    Project sponsor reviews the Project Charter.

    3

    1.1.5

    Project Charter Signed/Approved

    The Project Sponsor signs the Project Charter which authorizes the Project Manager to move to the Planning Process.

    2

    1.2

    Planning

    The work for the planning process for the project.

    3

    1.2.1

    Create Preliminary Scope Statement

    Project Manager creates a Preliminary Scope Statement.

    3

    1.2.2

    Determine Project Team

    The Project Manager determines the project team and requests the resources.

    3

    1.2.3

    Project Team Kickoff Meeting

    The planning process is officially started with a project kickoff meeting which includes the Project Manager, Project Team and Project Sponsor (optional).

    3

    1.2.4

    Develop Project Plan

    Under the direction of the Project Manager the team develops the project plan.

    3

    1.2.5

    Submit Project Plan

    Project Manager submits the project plan for approval.

    3

    1.2.6

    Milestone: Project Plan Approval

    The project plan is approved and the Project Manager has permission to proceed to execute the project according to the project plan.

    2

    1.3

    Execution

    Work involved to execute the project.

    3

    1.3.1

    Project Kickoff Meeting

    Project Manager conducts a formal kick off meeting with the project team, project stakeholders and project sponsor.

    3

    1.3.2

    Verify & Validate User Requirements

    The original user requirements is reviewed by the project manager and team, then validated with the users/stakeholders. This is where additional clarification may be needed.

    3

    1.3.3

    Design System

    The technical resources design the new widget management system.

    3

    1.3.4

    Procure Hardware/Software

    The procurement of all hardware, software and facility needs for the project.

    3

    1.3.5

    Install Development System

    Team installs a development system for testing and customizations of user interfaces.

    3

    1.3.6

    Testing Phase

    The system is tested with a select set of users.

    3

    1.3.7

    Install Live System

    The actual system is installed and configured.

    3

    1.3.8

    User Training

    All users are provided with a four hours training class. Additionally, managers are provided with an additional two hours class to cover advanced reporting.

    3

    1.3.9

    Go Live

    System goes live with all users.

    2

    1.4

    Control

    The work involved for the control process of the project.

    2

    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.

    3

    1.4.4

    Update Project Management Plan

    Project Manager updates the Project Management Plan as the project progresses.

    2

    1.5

    Closeout

    The work to close-out the project.

    3

    1.5.1

    Audit Procurement

    An audit of all hardware and software procured for the project, ensures that all procured products are accounted for and in the asset management system.

    3

    1.5.2

    Document Lessons Learned

    Project Manager along with the project team performs a lessons learned meeting and documents the lessons learned for the project.

    3

    1.5.3

    Update Files/Records

    All files and records are updated to reflect the widget management system.

    3

    1.5.4

    Gain Formal Acceptance

    The Project Sponsor formally accepts the project by signing the acceptance document included in the project plan.

    3

    1.5.5

    Archive Files/Documents

    All project related files and documents are formally archived.

    Level

    WBS Code

    Element Name

    Definition

    1

    1

    Ramkolek

    A document management system for project paper submission.

    2

    1.1

    Initiation

    Work involved in initiating the project

    3

    1.1.1

    Study the Current Project Paper Submission Process

    Research on the business processes for paper submission.

    3

    1.1.2

    Develop the Business Case

    Development of the Business case.

    3

    1.1.3

    Develop the Project Charter

    Development of the project charter

    3

    1.1.4

    Develop Stakeholder Analysis

    Analysis the stakeholders.

    2

    2.1

    planning

    Work involved to planning the project.

    3

    2.1.1

    Develop the Work Breakdown Structure

    Creation of the WBS on open project and as a document.

    3

    2.1.2

    Develop the Scope Management Plan

    Development of the scope management plan

    3

    2.1.3

    Develop the Schedule Management Plan

    Development of the schedule management plan.

    3

    2.1.4

    Develop the Cost Management Plan

    Development of the cost management plan.

    3

    2.1.5

    Develop the Work Packages

    Development of the work packages document.

    3

    2.1.6

    Develop the Human Resources Plan

    Development of the work packages document.

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