1.

Scope Management Document

The purpose of the Scope Management Plan is to ensure the project is composed of all the work
required, and only the work required, to successfully complete the project. The processes defined
in the following sections provide a blueprint for how scope will be defined, developed, verified,
and controlled. This Scope Management Plan documents the scope management approach,
defines the roles and responsibilities, processes, and procedures for managing scope, and serves
as a guide for managing and controlling project scope.

1.1 Approach
This Scope Management Plan addresses the following 5 processes:
● Scope Definition
● Collect Requirements
● Work Breakdown Structure (WBS) Creation
● Scope Validation
● Scope control

These processes interact with each other and with the processes in the other management plans
defined in the Project Management Plan. When implemented properly, the scope management
processes will help effectively manage the Triple Constraint elements of time, schedule, and cost
to suppo
rt a high quality project.

2. Roles and Responsibilities

Role Responsibility

Project Sponsor ● Approves Scope Management Plan.

● Provides high-level scope definition (Project Charter).
● Reviews escalated scope issues and provided direction
for resolution.
● Approves major scope change requests.
● Overall decision-making responsibility for Scope
Management activities.

Executive Steering ● Participates in Scope definition activities.

● Provides final approval of Scope Management Plan (if
committee(If used)
decision-making committee).
● Reviews major scope change requests and makes final
decisions or recommendations to the Project Sponsor.

Project Manager ● Overall responsibility for scope management.

● Oversees the development of the Scope Management
Plan.
● Oversees the scope change management process.
● Approves scope change requests within his/her
authority.
● Escalates scope and changes issues.
● Ensures that scope changes are incorporated into
appropriate project documents
● Understanding of software development
 ● Project Estimation
● Scheduling
● Staffing
● Risk Management
● Miscellaneous plans

Contract Manager ● May have a role in deliverable verification and

acceptance when the deliverable is required under
contract terms.

Project Team ● Help develop the project scope statement.

● Submit scope change requests.
Members and Subject
● Review Scope Change requests when assigned.

Experts (SMEs) ● Provide feedback as and when required.

● Participate in team-level scope change reviews.

Independent Verification ● Provides an ongoing independent review and analysis

of project scope management practices.
and Validation
● Monitors scope changes and provide feedback.

(IV&V)

4. Scope Management Processes

4.1 Requirement Collection
We have identified key steps for the requirement collection process.
● Identify the relevant stakeholders: Qualified representatives were identified from each
relevant stakeholder group. Some of these representatives include decision makers, users,
system administrators and internal stakeholders.
● Establish project goals and objectives: the overall outcomes that customers want, business
goals, actionable objectives needed to achieve the goals and outcomes.
● Elicit requirements from stakeholders: this step included several cycles of elicitation,
documentation, review/confirmation to achieve a workable specification to begin
development. Requirement Elicitation was performed using techniques like surveys and
interviews.
● Document the requirements: The requirements that emerged from the elicitation process
were documented. This document is available for review by all stakeholders and can be easily
navigated by the team.
● Confirm the requirements: requirements were reviewed together with all stakeholders and
made sure they capture what was intended and that all parties have a common understanding
of each requirement.
● Prioritize the requirements: based on their impact level, requirements were prioritized. This
was done by labeling and ranking the requirements.

4.2 Scope Definition

The project scope statement describes what the project entails. It sets forth the sum of products,
services and results that will be provided.
The scope statement includes :
● Major deliverables
● Objectives of the project
● Benefit of the project
● Brief summary of the project
● Project Exclusions
The project manager is responsible to develop the scope statement using inputs like the project
charter, scope management plan, and requirements documentation.
4.3 Creation of the Work Breakdown Structure (WBS) and Dictionary
A. Work Breakdown Structure (WBS)

Figure 1 - Work Breakdown structure

2. WBS Dictionary

WBS WBS Description Deliverables

level Element Name of Work

LCCS
1 A system that simplifies A web-based and mobile application
Management operational responsibilities platform compliant with user requirements.
System for the staff and
students in the school.

2 Project Lead team to complete the Items that accomplish goals and objectives
 Management deliverables. set.

2 Requirements Identify functionality, Measurable, consistent and stakeholder-

Performance level and other Approved requirements.
Characteristics in order for it
To be acceptable to
customer.

2 Infrastructure Define the technical Specification for hardware and software

Computing infrastructures infrastructure.
Such as database programs
for the project.

2 Back End Specify server side software Application programming interface (APIs),

And logic needed to provide Architecture and servers

Data for the client.

2 Web Application Establish web application Structure and elements included in the web
components for the application.
that users will interact with.

3 Mobile App Establish the components Structure and elements included in the web
Of the mobile application. application.

3 Scope Statement Prepare document that Project goals, objectives, requirements,

defines all the elements of scope description, project exclusion, project
the project scope. constraints.

3 Work Breakdown
Structure
3 Quality
Management
Plan

3 Test Strategy

3 Project
Management Plan

3 Stakeholder
requirements

3 Requirements
Traceability matrix

3 Software
Architecture
Document

3 UI Designs

3 Infrastructure
Specification

3 Infrastructure
Cost Predictions

3 Media Database

3 Client
Management
System
 3 Authentication
Provider

3 Home Page

3 Login Page

3 User’s Library

3 Admin Portal

3 Web App Beta

Version

3 Mobile App Beta

Version

3 Release
Approvals

3 Regression
Testing

3 Release
Candidate

3. Deliverable Validation and Acceptance

The project’s deliverables and products will be accepted through the project’s formal acceptance
processes. These processes are designed to ensure that individual deliverables and products are
accepted only if they meet their respective acceptance criteria.

4. Control Scope
Requests for change in project scope will be processed through the project’s change management
procedure. Proposed scope changes will be reviewed. If the request has merit according to the
project manager and project sponsor, it will be analyzed for its impact to project time and project
costs, and a risk assessment of the scope change will be conducted.
If the change is approved, the project’s WBS and WBS dictionary, project schedule and project
requirements set will be updated.

Stakeholder Management

Stakeholder Management includes the processes required to identify the people, groups and
organizations that could affect or be affected by the project, to analyze stakeholder expectations
and their impact on the project, and to develop appropriate strategies and tactics for effectively
engaging stakeholders in a manner appropriate to the stakeholders’ interest and involvement in
the project. The Stakeholder Management Plan helps ensure that stakeholders are effectively
involved in project decisions and execution (PMBOK 5th Edition) throughout the lifecycle of the
project, to gain support for the project and anticipate resistance, conflict, or competing objectives
among the project’s stakeholders. The Stakeholder Management Plan includes several sections:

Identify Stakeholders ,Register and Analysis

identify by name and title the people, groups, and organizations that have significant influence
on project direction and its success or who are significantly impacted by the project.

Communication management plan -how everyone working on a project can commun

icate best The plan can define each team member's responsibilities regarding communication and
which channels are best
Manage Stakholder engagement -Outline the process and the staps that will be Undertaken to
carry out the planned strategy

Stakeholder register

Stakehol Role Categor Contact Influence interset Expectations/

der’s y(Intern (Power) Responsibilities
Name al /
 external
)

External High High evaluates the

Aba Client power/infl interest progress against
Tekle /Sponsor uence what was planned
and also help the
Mekonne project manager
n and teamwork more
autonomously to
solve issues, while
making sure that
processes are being
followed.

Mr.Abera External Medium- Low

Client influence interest

Internal se.elda.gi High- High Project to be

Elda Project rma@gm influence interest delivered on time
Girma Lead ail.com with budget

Internal se.mekid High- High Clear requirements

Mekides Project es.getahu influence interest and timely
Getahun manager n@gmail. completion of
com documentation

Send weekly status

emails to sponsor

Internal rebeccas High- Medium Change should not

Rebecca Infrastruct amuel999 influence interest affect the optimum
Samuel ure team @gmail.c of the system no
lead om memory spisk

responsible for the

design, installation,
maintenance, and
retirement of the
systems and
personnel that are at
the core of an
organization.

Internal se.ruth.m High High User friendly and

Ruth Front-end atewos@ influence interest responsive UI
Matewos Developer gmail.co across tablets and
m desktop
 Internal se.simret High High Main focus is on
Simretea Back-end eab.mekb Power/infl interest coding, debugging
b Developer ib@gmail. uence and Collaborate
com with Front-end
Mekbib
developers to
define and
communicate
technical and
design
requirements.

Parents Users External - Low High Providing project

and Power/infl interest development
Students uence requirements
Pirioritizing tasks
Reporting problems

Google External Google High Low Should

Play (Androi authenticate our
Store d) app before it can
be used by our
customers on
their
smartphones.

Google Play’s SDK

will be used.

App features,
privacy, and
security issues
should be complied
with.

New apps must

target at least
Android 11 (API
level 30).

Google Play
guidelines must
 be followed for
compliance.

Stakeholder Analysis

As mentioned above, theLccs management system project is assessing each group’s position,
as well as their impact on the project and/or how they are impacted by the project. One purpose
of this activity is to help identify and categorize groups so that appropriate attention can be
given to each group according to the level of engagement needed. To help in this process, the
project will use the PMBOK Power/Interest Grid to categorize each stakeholder group. The
Power/Interest Grid analyzes stakeholder groups in a visual manner to further establish
stakeholders’ level of interest or concern and their ability to influence the project outcomes.
An important outcome of the stakeholder identification and analysis work, including the
Power/Interest Grid, is to identify the most influential and most impacted stakeholder groups so
that a focused stakeholder management strategy and plan can be developed and executed.

HIGH Keep Satisfaie Manage Closely

● Google play
● App Store ● Aba Tekle Mekonnen
● Browses (for websites) ● Elda Girma
● Mekides Getahun
● Simreteab Mekbib
 ● Ruth Matewos

LOW Monitor(Minimum effort) Keep informed

● Government ● Parents and Students
● Departments and employees
of the school

LOW HIGH

Communication plan

Communication plan

Stakeholder’s Name Role Engagement Communicati Communicati

Action on on frequency
Method/chann
el

Keep informed Email Low

Aba Tekle Mekonnen Sponsor

Mr.Abera Degife Email Midium 3days

Project a week
Manager

Monitor Physical, Google High daily

Elda Girma Project Lead meet

monitor Physical, Google High-daily

Mekides Getahun Project Manager meet

Manage Physical, Google High-daily

Rebecca Samuel Infrastructure closely meet
team lead
 Engage closely Physical, Google High-daily
Ruth Matewos Front-end meet
Developer

Engage closely Physical, Google High-daily

Simreteab Mekbib Back-end meet
Developer

The five levels of stakeholder engagement

● Leading: A leading stakeholder is aware of the project’s impact and is actively
involved.
● Supporting: A supporting stakeholder is aware of the project’s impact and
supports the project.
● Neutral: A neutral stakeholder is aware of the project’s impact but neither resists
nor supports the project.
● Resistant: A resistant stakeholder is aware of the project’s impact but resists
change.
● Unaware: An unaware stakeholder doesn’t know about the project or its impact.

Stakeholde Unaware Resistant Neutral Supportin Leading

r g

C D
Aba Tekle
Mekonnen

Mr.Abera

C D
Elda Girma

C D
Mekides
Getahun
 C D
Rebecca
Samuel

C D
Ruth
Matewos

C D
Simreteab
Mekbib

Parents,Stu C D
dents and
employees
of the
school

Google play C D

*C: Current, D: Desired

C. Schedule management

Schedule Tolerances
The schedule tolerances of this project are percentage deviations from the schedule’s baseline.
It is acceptable to be behind schedule by up to one week, but any further delay would trigger a
project board escalation.

1.1.1 Schedule Management Plan

The project divided into 4 sprints
Sprint 1 : Lideta Catholic Cathedral System for Teachers
Sprint 2 : Lideta Catholic Cathedral System for Students
Sprint 3 : Lideta Catholic Cathedral System for Parents
Sprint 4 : Lideta Catholic Cathedral System for Admins

Task Name Duration Start Finish Complete

High Level Sprint 63 days Dec 11, 2022 Feb 11, 2023 60%
Planning

Create project 20 days

timeline

Draft resource 20 days

plan

Plan project 23 days

budget

Sprint - 1 60 days Feb 12, 2023 Apr 12, 2023

Sprint 1 - Planning 12 days

Sprint 1 - 12 days
Execution

Sprint 1 - Demo 12 days

Sprint 1 - 12 days
Implementation

Sprint 1 - 12 days
Retrospective

Sprint - 2 62 days Apr 13, 2023 Jun 13, 2023

Sprint 2 - Planning 12 days

Sprint 2 - 12 days
Execution

Sprint 2 - Demo 12 days

Sprint 2 - 14 days
Implementation

Sprint 2 - 12 days
Retrospective

Sprint - 3 62 days Jun 14, 2023 Aug 14, 2023

Sprint 3 - Planning 12 days

Sprint 3 - 12 days
Execution

Sprint 3 - Demo 12 days

Sprint 3 - 14 days
Implementation

Sprint 3 - 12 days
Retrospective

Sprint - 4 62 days Aug 15, 2023 Oct 15, 2023

Sprint 4 - Planning 12 days

Sprint 4 - 12 days
Execution

Sprint 4 - Demo 12 days

Sprint 4 - 12 days
Implementation

Sprint 4 - 12 days
Retrospective

Deployment and 62 days Oct 16, 2023 Dec 16, 2023

Testing

Finalizing project 45 days Dec 17, 2023 Jan 30, 2024

Table 1.1 : Schedule management plan

Gantt chart

Figure 1.3 Gantt Chart

c

C. Schedule management

Schedule Tolerances
The schedule tolerances of this project are percentage deviations from the schedule’s baseline.
It is acceptable to be behind schedule by up to one week, but any further delay would trigger a
project board escalation.

1.1.1 Schedule Management Plan

The project divided into 4 sprints
Sprint 1 : Lideta Catholic Cathedral System for Teachers
Sprint 2 : Lideta Catholic Cathedral System for Students
Sprint 3 : Lideta Catholic Cathedral System for Parents
Sprint 4 : Lideta Catholic Cathedral System for Admins

Task Name Duration Start Finish Complete

High Level Sprint 63 days Dec 11, 2022 Feb 11, 2023 60%
Planning

Create project 20 days

timeline

Draft resource 20 days

plan

Plan project 23 days

budget

Sprint - 1 60 days Feb 12, 2023 Apr 12, 2023

Sprint 1 - Planning 12 days

Sprint 1 - 12 days
Execution

Sprint 1 - Demo 12 days

Sprint 1 - 12 days
Implementation

Sprint 1 - 12 days
Retrospective

Sprint - 2 62 days Apr 13, 2023 Jun 13, 2023

Sprint 2 - Planning 12 days

Sprint 2 - 12 days
Execution

Sprint 2 - Demo 12 days

Sprint 2 - 14 days
Implementation

Sprint 2 - 12 days
Retrospective

Sprint - 3 62 days Jun 14, 2023 Aug 14, 2023

Sprint 3 - Planning 12 days

Sprint 3 - 12 days
Execution

Sprint 3 - Demo 12 days

Sprint 3 - 14 days
Implementation

Sprint 3 - 12 days
Retrospective

Sprint - 4 62 days Aug 15, 2023 Oct 15, 2023

Sprint 4 - Planning 12 days

Sprint 4 - 12 days
Execution

Sprint 4 - Demo 12 days

Sprint 4 - 12 days
Implementation

Sprint 4 - 12 days
Retrospective
Deployment and 62 days Oct 16, 2023 Dec 16, 2023
Testing

Finalizing project 45 days Dec 17, 2023 Jan 30, 2024

Table 1.1 : Schedule management plan

Gantt chart

Figure 1.3 Gantt Chart

E. quality management
1.1.1.1 Quality Planning
The goals of this project are admission management, reducing communication gap, course and
subject management, student performance monitoring, organizing and simplifying everyday
tasks, centralized data and easy access to all, time table and attendance Management.

To reduce technical debt, improve customer satisfaction and deliver a higher quality product we
follow the procedures listed below

1. Design the flow of the system

2. Divide the designed system into module
3. Make a prototype for the first selected module
4. Implement prototype
5. Test module
6. Present the module to the customer that is implemented
 7. If there is any comment about the module based on the change management rule if
necessary correct it and continue to the other module
8. after all modules are done by this cycle make general testing on system flow
9. If there is any bug correct it
10. Finally, host the system and make testing
11. If there is any bug correct it and provide the product to customers

1.1.1.2 Quality Assurance

Figure 1.4 Quality Assurance Steps

● Design: The design for the product will be discussed by the team and start
prototyping the module.
● Implementation: After prototyping the module, start the code implementation.
● Testing: Once the development is done for the module, the testing will continue to
test the product with various testing techniques to ensure that all the requirements are
met.
● Feedback: To get feedback from the customers to satisfy their needs if anything they
expect. With help of the feedback, the project team will get to know about the further
expectations of the customer.
● Correction: Here, the maintenance for the software like further updates, repairs,
customers feedback and breaks if it occurs will be done by the team.
● Deployment: After testing is done successfully, the product is ready to go live in the
 market for real-time use for the customers.
Methodologies in Quality Assurance: There will be two testing methods in Quality Assurance:
● Non-Functional Testing.
● Functional Testing.
A. Non-Functional Testing: Non-functional testing is the process of performing load testing,
stress testing, and checking minimum system requirements which are required to meet the
requirements. It will also detect risks, errors and optimize the performance of the database.
a. Load Testing:
● Load testing involves testing the performance and scalability of the database.
● It determines how the software behaves when it is being used by many users
simultaneously.
● It focuses on good load management.

For example, if the web application is accessed by multiple users at the same time and it does not
create any traffic problem then the load testing is successfully completed.

b. Stress Testing: Stress Testing is also known as endurance testing. Stress testing is a testing
process that is performed to identify the breakpoint of the system.
● In this testing, an application is loaded till the stage the system fails.
● This point is known as a breakpoint of the database system.
● It evaluates and analyzes the software after the breakage of system failure. In case of
error detection, It will display the error messages.
For example, if users enter the wrong login information, then it will throw an error message.
c. Volume Testing: In which, the software is tested with a huge volume of data to check the
stability of the software. This is done to identify what problems may occur with increasing
volumes of data. It’s also known as flood testing. Volume tests can be used to check if there’s
any data loss, warning or error messages, or data storage issues.

d. Scalability Testing: It is a type of testing which tests the software with scaling up and scaling
down the number of users. A scalability test is a type of load testing that measures the applicant’s
ability to scale up or down as a reaction to an increase in the number of users.
B. Functional Testing: It includes various testing services to check the system. Some of them
are listed below
● Unit Testing: It is a type of software testing where individual components of the
software are tested. It could be a function, procedure, etc.,
● Component Testing: It is also called module testing. In which, each component is
tested individually without integrating with each other.
● Integration Testing: In which, each individual module is integrated as a group to test
the software.
● Regression Testing: It is a type of testing where the product is tested again after
making changes to any of the functions or modules.
● Usability Testing: It is also known as UX (User Experience) testing. In which, it
measures how easy and user-friendly a web application is.
● UI/GUI Testing: In which, the front-end design part of the web application is tested
such as menu bars, buttons, etc.,
● User Acceptance Testing: It is performed by the end-users or clients to check the
entire software before it is introduced in real-time use.

● Application Testing: In which an application the company is developing is tested.

Information Management: It is the collection of all information from various sources and
storing it under safe circumstances that helps for quality assurance. It is used to collect, manage,
preserve, store and deliver information. To eliminate risks like machine malfunction of one
group member while doing something about a project, get updated and safe data at the same time
as a group we will use services like Google doc, GitHub etc.
The two ways to store the information are:
1. Document Management: It is storing all the information in a word or related document
format. It consists of all details about the project like goal, objectives, tasks divided among team
members, deadlines, testing details, etc. To manage this, we use google tools like google doc.
Here, we can easily add, modify, update and delete our details.

Advantages of Document Management:

 ● Increased product and process quality.
● Consistency.
● Compliance.
● Increased safety.
● Focus on improvement.
2. Record-Keeping: It is managing the files electronically. Here, the stored information will be
managed by ourselves electronically by using online services like GitHub, Figma, Trello etc.

Advantages of Record Keeping:

● Decrease the risk of file loss.
● Up to date about any members work at any time.
● All members will be on the same page about the project.

1.1.1.3 Quality Control

● Output Review Procedures: Here, the process will be divided into various review
processes. In the first review, we will submit only a detailed description of the project. It
will be reviewed by the business client and take the first review confirmation from the
client. After that, the next process will be initiated. If the client suggests any changes then it
will be done by the next review. The project contains many reviews and It is totally
dependent on the project size and client or management decision. Like this, each phase and
the output of the phase will also be reviewed. If the client or management suggests any
changes then they will be implemented and confirmed the same. If the output of that phase
is accepted then the team members will be concentrated on the next phase of the project.
● Output Acceptance Procedures: It is essential that output acceptance by the business
client is appropriately defined and documented. Once the output of the process is accepted
and finalized, it will be further discussed with the client to deploy the project in the real
market.
Risk management plan

This document describes how the project team will manage the project risks, roles and
responsibilities, and tools they use.This Risk Management Plan defines how risks
associated with the Lccs management system t will be identified, analyzed, and
managed. It outlines how risk management activities will be performed, recorded, and
monitored throughout the lifecycle of the project and provides templates and practices
for recording and prioritizing risks.

A Risk is an uncertain event or condition that, if it occurs, has a positive or negative

effect on a project’s objectives.

The main flow of Project Risk Management includes the following processes:

1. Risk Identification
2. Qualitative Risk Analysis
3. (Optional) Quantitative Risk Analysis
4. Planning Risk Responses
5. Implementing Risk Responses
6. Monitoring Risks

The project manager is responsible for educating the project team, clients, and key
stakeholders in proper risk management skills.

PM should initiate and facilitate all related activities.

Process

The project manager working with the project team and project sponsors (Aba Tkle
mekonnen ) will ensure that risks are actively identified, analyzed, and managed
throughout the life of the project. Risks will be identified as early as possible in the
project so as to minimize their impact. The steps for accomplishing this are outlined in
the following sections.

1,Risk Identification

During the whole project time line, all stakeholders and project team will continuously
identify risks. All the time, we should ask a simple question, “What can go wrong here?
Do you see any risks?”

The Project Team should log identified risks into the Risk Register. It’s acceptable to
perform risk analysis in batches at a later date.

Access Risk Register :

Risk Risk Risk description Inherent Risk owner Risk status

ident Category Risk
ifier

001 Schedule High Active

Risk. Aggressive Elda Girma
deadlines

Medium Active
Unmet Aba Tekle
expectations Mekonnen

Unexpected High Usres Active

project scope
expansions.

002 Budget Wrong budget High Inactive

Risk estimation Elda Girma,Mekides
Getahun
 Cost overruns High Inactive
Elda Girma,Mekides
Getahun,Rebecca
Samuel

002 Operation Risk of loss due to High

al Risks improper process Ruth
implementation, Matewos,Simretab
failed system or Mekbib
some external
event risks.

No communication
within the team.

High Inactive
Project team Elda Girma,Mekides
members leaving Getahun

Failure to resolve Medium Inactive

responsibilities Elda Girma,Mekides
Getahun

003 Technical Technical risks High Active

Risks generally lead to Elda Girma,Mekides
failure of Getahun
functionality and
performance.

Continuously
changing
requirements

The product is High Inactive

complex to Ruth
implement. Matewos,Simretab
Mekbib

Difficult project High Inactive

module
 integration.

004 These are external Low Inactive

Programm risks beyond the
atic Risks operational limits.
These are all
uncertain risks
that are outside
the control of the
program.

Running out of Medium Aba,Tkle Mekonen

funds.

Marketing Medium Abera

development

Changing Medium Users

customer product
strategy and
priorities.

Government rule LOW Government Inactive

changes.
The Project Team will use the following techniques:

1. Interview
2. Meeting
3. Brainstorming
4. Requirements Analysis
5. Project Documentation Review
6. Delphi Technique
7. Expert Interview

Besides continuous identification, the team will perform a dedicated Risk Identification
Session for the following events/artifacts:

1. During all grooming sessions.

2. During a review of the Release Plan.
3. Analysis of Work Breakdown Structure.
4. When a Change Request is approved.
5. During an inspection of Architectural Design.
6. During the Sprint Planning Meeting.

The Project Manager is also responsible for identifying risks outside of the Project
Team.

The Project Manager will review and analyze the company’s Risk Categories regularly.
Risk Breakdowns Structure is located here:
Qualitative Risk Analysis
The goal of this process is to make a list of risks that require a proactive response. We should
also identify urgent risks that require a response right now.Project Team should assess all risks in
the Risk Register and identify Probability and Impact.

Impact is a level of effect that risk will have on the project.

Probability is a level of likelihood of occurrence of the risk.

It's not an in-depth analysis. Project Team should spend an adequate amount of time to assess the
risks.The project operates under the dedicated team model. Therefore, we will represent a risk's
impact in the team's effort, for example, person-days.As we develop the product as a series of
product releases, we calculate risk management efforts within the boundaries of one release
(project).

Rating Interprition

10 Schedule Over the project's deadline by

Risk.Aggressive 50%. Project goals and
deadlines constraints are out of sync.
Feasibility is at risk.

9 Unexpected project
scope expansions.

8 Risk Budget

7 Cost overruns

6 Unmet expectation

5 Market development

4 Short of staff, need more

people

3 Unreasonable requirements

2 Currency change
1 Change in government
policies

Red – risks that warrant a response.

Yellow – risks that require further analysis and investigation.
Green – risks that can be ignored.

G. communication management
1.9.2 Communication Management Plan

Type of Method / Tool Frequency/ Information Participants

Communication Schedule Responsibility

Internal Communication:

Project Face To Face, Day to day Project status, System

Development
Telegram, problems Developers
Meetings
Google meet

Project Face To Face, Within 3 days Project status, Project Manager,

Meetings
Telegram, problems, risks,
System
Google meet changed Developers
requirements

Sharing of GitHub, Weekly New Updates Project Manager,

project data
Telegram, Face
System
to Face and Developers
Google meet

Sprint Review Telegram, After completion Review sprint, Project Manager,

Google meet, challenges we
 and Face to Face of each sprint faced System
Developers

Milestone Face to face, Weekly Project status Project Manager,

Meetings
Telegram, (progress)
System
Google meet and Developers
GitHub

Monthly Face to face and Monthly Wrap-up Project Manager,

Project Meeting Google meet Experiences
System
Developers

External Communication:

Weekly Report Excel sheet New Updates Project Manager, Project Manager,
System System
Developers, Developers,
Sponsor Sponsor

Project Report Face to Face and Monthly Project status Project Manager,
Google meet - progress System
- forecast Developers,
- risks Sponsor
Project Face to Face Once Presenting the Project Manager,
Submission
final product of System
the project to the Developers,
sponsor and Sponsor
submit the product

Human Resource Management Plan

This part of the project planning document (“human resource management”) identifies and documents
project roles, responsibilities, required skills, also includes reporting relationships and creating staffing
management plans. The process includes plan human resource management, acquire project team,
develop project team and manage project team.

Plan human resource management

By considering the project life cycle processes and the timeline given to the project completion which is
26 months it’s decided

Organization charts and position description

Hierarchical Relationships
Responsibility assignment matrix(RAM)
-The value donated by RACI stands for:

● Responsible
● Accountable
● Consulted
● Informed

Activity Ato Abera Elda Girma Mekides Rebecca Ruth Simreteab

Getahun samuel Matewos Mekbib

Project plan R C C C C C

Analysis R C C C C C

Design C R R C C C

Implementati I R R R R R
on

Testing I C C A A A
Deployment I C C A A A

People working motivation management :- The worker/team members will be rewarded for their additional
effort or early completion of tasks. They will also be punished for late delivery or failure to complete their
tasks appropriately. Different personal development trainings will be given to the project workers in order
to keep them in a good working position,

The project manager will have to request the functional manager to assign team member from different
departments

Procurement Management
The purpose of the procurement management plan is to define and plan the goods or services acquired
from the outsource that are significant for the successful completion of the project.

Here the plan is made assuming the supplier will be able to provide the required items, products and
services within the time limit mentioned.

item/service needed purpose due date

Server To provide service of the hosted dec, 2023

system

Procurement constraint
Quality constraint - The supplier might not provide the goods with the needed quality standard.

Time constraint - The goods might not be provided on the time expected.

cost constraint - The goods might cost larger amount of money than expected

1 INTRODUCTION
1.1 PURPOSE OF THE CHANGE MANAGEMENT PLAN
The Change Management Plan documents and tacks the necessary information
required to effectively manage project change from project inception to delivery.
The Change Management Plan is created during the Planning Phase of the
project. Its intended audience is the project manager, project team, project
sponsor and any senior leaders whose support is needed to carry out the plan.
2 CHANGE MANAGEMENT PROCESS
The Change Management process establishes an orderly and effective procedure
for tracking the submission, coordination, review, evaluation, categorization, and
approval for release of all changes to the project’s baselines.
2.1 CHANGE REQUEST PROCESS FLOW REQUIREMENTS
Step Description
Generate CR A submitter completes a CR Form and sends the completed form to the
Change Manager
Log CR Status The Change Manager enters the CR into the CR Log. The CR’s status is
updated throughout the CR process as needed.
Evaluate CR Project personnel review the CR and provide an estimated level of effort to
process, and develop a proposed solution for the suggested change
Authorize Approval to move forward with incorporating the suggested change into
the project/product
Implement If approved, make the necessary adjustments to carry out the requested
change and communicate CR status to the submitter and other
stakeholders
2.2 CHANGE REQUEST FORM AND CHANGE MANAGEMENT LOG
Element Description
Date The date the CR was created
CR# Assigned by the Change Manager
Title A brief description of the change request
Description Description of the desired change, the impact, or benefits of a change
should also be described
Submitter Name of the person completing the CR Form and who can answer
questions regarding the suggested change
Phone Phone number of the submitter
E-Mail Email of the submitter
Product The product that the suggested change is for
Version The product version that the suggested change is for
Priority A code that provides a recommended categorization of the urgency of the
requested change (High, Medium, Low)

2.3 EVALUATING AND AUTHORIZING CHANGE REQUESTS

Change requests are evaluated using the following priority criteria:
Priority Description
High changes that are directly related to the modules of the project and
database
Medium changes related to the user experiance
Low changes related to the user interface

Change requests are evaluated and assigned one or more of the following change
types:
Type Description
Scope Change affecting scope
Time Change affecting time
Duration Change affecting duration
Cost Change affecting cost
Resources Change affecting resources
Deliverables Change affecting deliverables
Product Change affecting product
Processes Change affecting process
Quality Change affecting quality

Change requests are evaluated and assigned one of the following status types:
Status Description
Open Entered/Open but not yet approved or assigned
Work in CR approved, assigned, and work is progressing
Progress
In Review CR work is completed and in final review prior to testing
Testing CR work has been reviewed and is being tested
Closed CR work is complete, has passed all tests, and updates have been
released.
1 INTRODUCTION
1.1 PURPOSE OF THE CONFIGURATION MANAGEMENT PLAN
The overall objective of a Configuration Management (CM) Plan is to document and
inform project stakeholders about CM with the project, what CM tools will be used, and
how they will be applied by the project to promote success. The Lideta Catholic
Cathedral School management system CM Plan defines the project’s structure and
methods for
● Identifying, defining, and baselining configuration items (CI)
● Controlling modifications and releases of CIs
● Reporting and recording the status of CIs and any requested modifications
● Ensuring completeness, consistency, and correctness of CIs
● Controlling storage, handling, and delivery of the CIs

The intended audience of the CM Plan is the project manager, project team, project
sponsor and any senior leaders whose support is needed to carry out communication
plans.

2 CONFIGURATION MANAGEMENT
2.1 APPROACH
We will use the configuration data to create a component. It is to manage configuration
data like a software approach. we will plan and review changes and then check them to
a code repository which automatically creates a component. This approach ensures that
our configuration data always matches the actual components.

3 CONFIGURATION MANAGEMENT ACTIVITIES

3.1 CONFIGURATION ITEMS
These are some of the configuration items under the project’s configuration management.
● Devices
● the system
● networks
● database
3.2 CONFIGURATION IDENTIFICATION
Configuration identification is used to maintain control of the project by uniquely identifying the
project, revisions of the project, and the component of each revision. it also maintains control by
understanding the status of configuration items as they progress through the development
process.
it can be done by:
 ● breaking the system into several known and manageable parts
● uniquely identifying the parts
● identifying the various revisions of a part as it evolves throughout its development life
cycle
● keeping track of the aggregates of the parts that make up a deliverable item of software
● keeping detailed accurate records of the configuration items

Integration Management
Project integration management involves coordinating all project management knowledge areas
throughout a project’s life cycle. This integration ensures that all the elements of a project come
together at the right times to complete a project successfully.

To effectively coordinate project activities, the following steps were followed:

1. Develop Project Charter

The project charter document provides an overview of the project and identifies the key
stakeholders involved in the project. It includes the scope, overview, purpose, objectives and
deliverables, project team members, budget information and project risks.

The project which is titled Lideta Catholic Cathedral School Management System will be
developed to simplify the day-to-day operational responsibilities of teachers, students, parents,
admins within the school. This project’s motive is to increase productivity, improve
communication, simplify tasks and have more efficient scheduling. Stakeholders for the system
are researchers, Lideta Catholic Cathedral School, Manager, Team Lead and developers.

2. Develop Project Management Plan

During this step, all planning efforts were coordinated to create a consistent and coherent
document.

3. Direct and Manage Project Work

Activities in the project management plan were carried out. The outputs of this process are
deliverables, work performance information, change requests and project document updates.

A few deliverables for this project include:

· Web and mobile application platform compliant with the requirements.

· Project related documents including project initiation, project plan SRS / SDS, Risk
Management, Change Management, test plan, project summary and configuration management.

4. Monitor and Control Project Work

This step involves overseeing activities to meet the performance objectives of the project.
Deliverables from this phase are change requests, project management plan updates and project
document updates.

5. Perform Integrated Change Control

This phase includes identifying, evaluating and managing changes throughout the project life
cycle. The outputs are updates regarding change request, project management plan and project
document.

6. Close Project or Phase

In this step, all activities are finalized to formally close the project. Deliverables from this phase
are the final product, service or result transition and organizational process assets updates