1	Introduction
This report presents the project planning and management aspects for the development of the shared bike software system commissioned by the local government. The purpose of this report is to detail the Project Scope Management and Project Schedule Management plans, ensuring that the project is completed successfully within the stipulated time frame and meets all specified requirements.
The local government has launched an initiative to address urban challenges such as increasing traffic congestion and deteriorating air quality. To promote a healthier and more sustainable lifestyle, they have introduced a shared bike program. Our company has been contracted to develop the software system integral to the operation of this program. This software will facilitate bike rentals and returns, manage the bike fleet, provide a user-friendly mobile application, integrate pricing and payment systems, and support operations and customer service.
We need to conduct this project to deliver a robust and efficient software platform that meets the government's requirements, contributing to the overall success of the shared bike program and, consequently, to the improvement of urban living conditions.
Team Charter
The project team comprises experienced professionals dedicated to delivering high-quality results within the project's constraints. The team members and their roles are as follows:
Name	Role	Responsibilities
Leo	Project Manager	Overall project management, scheduling, resource allocation, stakeholder communication
Bill	Senior Developer	Analysis and design, software architecture, database design
Lisa	Developer	UI/UX design, client-side coding
Andy	Developer	Server-side coding, integration
Kent	Developer	Client-side coding, testing
Vision: Our vision is to contribute to the transformative initiative of the shared bike program by delivering a state-of-the-art software system that will ease urban congestion, improve air quality, and promote a sustainable and healthy lifestyle for city dwellers.
Mission: To develop and deploy a robust, user-friendly, and secure software system that facilitates bike rentals, manages the bike fleet efficiently, integrates seamless payment options, and supports comprehensive customer service, ultimately contributing to the program's success.
Report Structure
The structure of this report is as follows:
•	Section 2 Project Scope Management: Presents the Work Breakdown Structure (WBS) of the project, detailing all tasks and deliverables in a hierarchical tree structure.
•	Section 3 Project Schedule Management: Includes the project schedule with necessary elements, the Network Diagram using the Precedence Diagramming Method (PDM), and a Critical Path Analysis (CPA).
•	…
2	Project Scope Management
In this section, we present the Work Breakdown Structure (WBS) for the shared bike software system project and the corresponding Gantt Chart. The WBS outlines all tasks and deliverables in a structured hierarchical format, ensuring a comprehensive understanding of the project's scope.
2.1 Work Breakdown Structure (WBS)
The project is divided into four main phases: Analysis, Design, Implementation, and Deployment. Each phase consists of specific tasks required to meet the project's objectives.
 
WBS Dictionary
Below is a brief description of each task in the WBS:
•	Analysis
o	a: Conduct a background study on e-payment implementations in similar projects to gather best practices and potential pitfalls.
o	b: Collect detailed requirements from relevant government departments regarding design preferences, compliance standards, and user needs.
o	c: Develop a prototype to demonstrate the payment procedure and gather early feedback.
•	Design
o	d: Design the overall software architecture, defining the system components and their interactions.
o	e: Design the database schema to support all required functionalities.
o	f: Design end-user interfaces for mobile applications, focusing on user experience and accessibility.
o	g: Design interfaces for administrative functions on desktop computers.
o	h: Design the signal connection mechanisms with bike locks for control operations.
o	i: Design the security scheme to safeguard transactions over the internet, ensuring data protection and compliance.
o	j: Develop interface templates for review, including layout, navigation, and visual elements.
o	k: Create a site map or hierarchy chart to illustrate the flow of web pages and user interactions.
•	Implementation
o	l: Create individual web pages based on the approved designs.
o	m: Create the database as per the designed schema.
o	n: Source necessary library modules for client-side coding to enhance development efficiency.
o	o: Purchase a set of bike locks for coding and testing purposes.
o	p: Code server-side modules for system administration and operations.
o	q: Code server-side modules for end-user services.
o	r: Code client-side modules for system administration and operations.
o	s: Code client-side modules for end-user services.
o	t: Integrate server-side modules and web pages to form a cohesive system.
•	Deployment
o	u: Test the connection to bike locks with the shared-bike app to ensure proper functionality.
o	v: Perform performance stress tests on the system to verify handling of transactions and concurrent users.
o	w: Conduct User Acceptance Testing (UAT) with the sponsor and end-user representatives.
o	x: Install the website on the government's web server for operation.
o	y: Create technical training materials for staff.
o	z: Train staff in operating and maintaining the system.
2.2 Gantt Chart
The Gantt Chart below visualizes the project schedule, illustrating task durations and dependencies to ensure a clear understanding of the project timeline.
 
Note: The start date is set as 01-01-2024. The milestones are set to the dates provided by the sponsor:
•	Prototype Delivery Milestone (m1): Prototype must be delivered within two months (by 01-03-2024).
•	Intermediate Modules Milestone (m2): Intermediate modules must be delivered within five months (by 01-06-2024).
•	Project Completion Milestone (m3): Project must be fully completed within eight months (by 01-09-2024).
Task Dependencies and Durations
The table below outlines each task's duration and dependencies:
Activity ID	Activity Name	Duration (Days)	Predecessors
a	Background study on e-payment implementation	18	-
b	Requirements Analysis	20	a
c	Technical Feasibility Study	22	b
d	System Design	25	b
e	Module Design	15	d
f	Interface Design	25	d
g	Database Design	15	f
h	UI Design	15	d
i	Security Design	20	d
j	Integration Testing	12	f, g
k	System Testing	12	j
l	Coding Core Modules	30	k
m	Coding Module E	20	e
n	Coding Module F	20	f
o	Develop UI	12	h
p	Database Implementation	25	i, g
q	Security Implementation	30	i
r	Testing Module N	25	n
s	Testing Module S	25	n
t	Final Integration	20	l, m, p, q, r, s
u	Deployment Preparation	5	t, o
v	System Deployment	5	u
w	User Training	5	v
x	Project Handover	12	w
y	Post-Deployment Support	20	x
z	Project Closure	19	y
 
3	Project Schedule Management
In this chapter, we present the project schedule management plan, including the Network Diagram in Precedence Diagramming Method (PDM) format, and conduct a Critical Path Analysis (CPA).
3.1 Network Diagram in PDM
The following network diagram represents the project's activities using the Precedence Diagramming Method (PDM). Each node corresponds to a task identified by its activity ID.
Legend:
•	Nodes represent tasks labeled from a to z.
•	Arrows indicate task dependencies.
 
3.2 Critical Path Analysis
Critical Path Analysis (CPA) identifies the sequence of tasks that determines the minimum project duration. Tasks on the critical path have zero slack.
3.2.1 Forward Pass (Calculating Early Start and Early Finish)
Task	Duration (Days)	Predecessors	Early Start (ES)	Early Finish (EF)
a	18	-	0	18
b	20	a	18	38
c	22	b	38	60
d	25	b	38	63
e	15	d	63	78
f	25	d	63	88
g	15	f	88	103
h	15	d	63	78
i	20	d	63	83
j	12	f, g	103	115
k	12	j	115	127
l	30	k	127	157
m	20	e	78	98
n	20	f	88	108
o	12	h	78	90
p	25	i, g	103	128
q	30	i	83	113
r	25	n	108	133
s	25	n	108	133
t	20	l, m, p, q, r, s	157	177
u	5	t, o	177	182
v	5	u	182	187
w	5	v	187	192
x	12	w	192	204
y	20	x	204	224
z	19	y	223	243
3.2.2 Backward Pass (Calculating Late Start and Late Finish)
Assuming the project's finish time is 244 days.
Here's the completed backward pass table:
Task	Duration (Days)	Successors	Late Finish (LF)	Late Start (LS)	Slack (LS - ES)
z	19	-	243	223	0
y	20	z	224	204	0
x	12	y	204	192	0
w	5	x	192	187	0
v	5	w	187	182	0
u	5	v	182	177	0
t	20	u	177	157	0
l	30	t	157	127	0
k	12	l	127	115	0
j	12	k, p	115	103	0
g	15	j, p	103	88	0
p	25	t	152	127	24
q	30	t	152	122	39
m	20	t	157	132	54
e	15	m	132	117	54
d	25	e, f, h, i	63	38	0
f	25	g, j, n	88	63	0
r	25	t	152	127	19
s	25	t	152	127	19
n	20	r, s	127	107	39
i	20	p, q	122	102	42
o	12	u	177	165	87
h	15	o	165	150	87
b	20	d, c	38	18	0
a	18	b	18	0	0
c	22	-	60	38	0
3.2.3 Identifying the Critical Path
Tasks with zero slack form the critical path. The critical path for this project is:
•	a - b - d - f - g - j - k - l - t - u - v - w - x - y - z
Project Duration: 8 months, 243 days (Including holidays)

4	Project Budget Management
In this chapter, we detail the Project Cost Management plan, including resource allocation, cost baseline, and Earned Value Management (EVM) analysis. We also present the performance measurements, variance analysis, and forecasting based on the project’s progress at the end of the fourth month.
4.1	Resource Sheet
Below is the Resource Sheet summarizing all the resources involved in the project, their hourly rates, total hours worked, and total costs.
Table 4.1: Resource Sheet
Resource	Rate ($/hr) or Unit Cost ($)	Total Units or Hours	Total Cost ($)
Human Resources			
Project Manager (PM)	$500/hr	984 hours	$492,000
Bill (Senior Developer)	$300/hr	1,776 hours	$532,800
Lisa (Developer)	$200/hr	1,336 hours	$267,200
Andy (Developer)	$200/hr	1,552 hours	$310,400
Kent (Developer)	$200/hr	1,288 hours	$257,600
Subtotal Human Resources		6,936 hours	$1,860,000
Equipment Purchases			
Mobile Phones	$800/unit	5 units	$4,000
Bike Locks with Connectivity	$1,000/unit	10 units	$10,000
Total Equipment Purchases			$14,000
Other Costs			
Computing Facilities Rental	$29,000/month	8 months	$232,000
Subtotal Other Costs			$246,000
Total (Before Contingency)			$2,120,000
Contingency Reserve (20%)			$424,000
Total Project Cost			$2,544,000
 Notes:
Based on the project schedule and team capabilities, tasks have been assigned to team members to ensure efficient utilization of skills and fair distribution of workload among team members, excluding the Project Manager (PM). The PM oversees the entire development process and participates in key tasks.
Table 4.1.1: Work Breakdown Structure (WBS) with Resource Assignments
WBS ID	Task Name	Duration (Days)	Assigned To
1	Analysis Phase		
1.1	Background study on e-payment implementation	18	Bill
1.2	Requirements Analysis	20	Bill, PM
1.3	Technical Feasibility Study	22	Bill, PM
2	Design Phase		
2.1	System Design	25	Bill, PM
2.2	Module Design	15	Bill, Lisa
2.3	Interface Design	25	Lisa, Kent
2.4	Database Design	15	Bill, Andy
2.5	UI Design	15	Lisa, Kent
2.6	Security Design	20	Bill, Andy
2.7	Integration Testing	12	Andy, Kent
2.8	System Testing	12	Andy, Kent
3	Implementation Phase		
3.1	Coding Core Modules	30	Lisa, Andy
3.2	Coding Module E	20	Lisa
3.3	Coding Module F	20	Kent
3.4	Develop UI	12	Lisa, Kent
3.5	Database Implementation	25	Bill, Andy
3.6	Security Implementation	30	Bill, Andy
3.7	Testing Module N	25	Kent
3.8	Testing Module S	25	Lisa
3.9	Final Integration	20	All Team Members
4	Deployment Phase		
4.1	Deployment Preparation	5	PM, Andy
4.2	System Deployment	5	Andy
4.3	User Training	5	Lisa
4.4	Project Handover	12	PM, Bill
4.5	Post-Deployment Support	20	Andy, Kent
4.6	Project Closure	19	PM
Resource Assignments Summary
o	Project Manager (PM): Participates in tasks 1.2, 1.3, 2.1, 3.9, 4.1, 4.4, and 4.6.
o	Bill (Senior Developer): Leads analysis and design tasks; involved in tasks 1.1 to 2.6, 3.5, 3.6, 3.9, and 4.4.
o	Lisa (Developer): Focuses on UI/UX design and client-side coding; involved in tasks 2.2, 2.3, 2.5, 3.1 to 3.4, 3.8, 3.9, and 4.3.
o	Andy (Developer): Handles server-side coding and integration; involved in tasks 2.4, 2.6, 2.7, 2.8, 3.1, 3.5, 3.6, 3.9, 4.1, 4.2, and 4.5.
o	Kent (Developer): Works on client-side coding and testing; involved in tasks 2.3, 2.5, 2.7, 2.8, 3.3, 3.4, 3.7, 3.9, and 4.5.
Market Study on Needed Equipment
As part of the project's hardware requirements, the following equipment is needed for development and testing purposes:
1.	Mobile Phones (5 units):
o	Purpose: To test the mobile application on various devices.
o	Estimated Market Price per Unit: $800
o	Total Cost: 5 units * $800/unit = $4,000
2.	Bike Locks with Connectivity (10 units):
o	Purpose: To develop and test signal connection mechanisms with bike locks.
o	Estimated Market Price per Unit: $1,000
o	Total Cost: 10 units * $1,000/unit = $10,000
3.	Computers and Peripherals:
o	Note: The computing facilities are rented monthly and covered separately under computing facilities rental costs.
Total Equipment Purchases: $4,000 (Mobile Phones) + $10,000 (Bike Locks) = $14,000

4.2	Cost Baseline (Budget Schedule)
The Cost Baseline outlines the planned expenditures over the project’s duration, including the Contingency Reserve to account for potential risks.
Table 4.2: Cost Baseline
Month	PM ($)	Bill ($)	Lisa ($)	Andy ($)	Kent ($)	Computing Facilities ($)	Equipment Purchases ($)	Planned Cost ($)	Contingency Reserve (20%)	Cumulative Planned Cost ($)
1	61,500	66,600	33,400	38,800	32,200	29,000	14,000	275,500	55,100	330,600
2	61,500	66,600	33,400	38,800	32,200	29,000	0	261,500	52,300	644,400
3	61,500	66,600	33,400	38,800	32,200	29,000	0	261,500	52,300	958,200
4	61,500	66,600	33,400	38,800	32,200	29,000	0	261,500	52,300	1,272,000
5	61,500	66,600	33,400	38,800	32,200	29,000	0	261,500	52,300	1,585,800
6	61,500	66,600	33,400	38,800	32,200	29,000	0	261,500	52,300	1,899,600
7	61,500	66,600	33,400	38,800	32,200	29,000	0	261,500	52,300	2,213,400
8	61,500	66,600	33,400	38,800	32,200	29,000	0	261,500	52,300	2,527,200
Total	492,000	532,800	267,200	310,400	257,600	232,000	14,000	2,106,000	421,200	2,527,200
Notes:
o	Month 1 Equipment Purchases: $14,000 for mobile phones and bike locks.
o	Computing Facilities Rental: $29,000 per month for 8 months.
o	Contingency Reserve: Calculated as 20% of the monthly Planned Cost.

4.3	Planned Values (PVs) for the 8 Months
Table 4.3: Cumulative Planned Values
Month	Cumulative Planned Value (PV) ($)
1	330,600
2	644,400
3	958,200
4	1,272,000
5	1,585,800
6	1,899,600
7	2,213,400
8	2,527,200
4.4	Earned Value Management (EVM) Analysis at End of Month 4
At the end of the fourth month, we conducted an Earned Value Management analysis to assess the project’s performance.
Assumed Values at End of Month 4:
•	Planned Value (PV): $1,272,000 (from the Cost Baseline)
•	Actual Cost (AC): $1,320,000 (actual expenditure incurred)
•	Earned Value (EV): $ 1,200,000 (value of work actually completed)
4.4.1 EVM Calculations
•	Cost Variance (CV):
CV = EV - AC
CV = $1,200,000 - $1,320,000
CV = -$120,000
•	Negative CV indicates the project is over budget.
•	Schedule Variance (SV):
SV = EV - PV
SV = $1,200,000 - $1,272,000
SV = -$72,000
•	Negative SV indicates the project is behind schedule.
•	Cost Performance Index (CPI):
CPI = EV / AC
CPI = $1,200,000 / $1,320,000
CPI ≈ 0.9091
•	CPI less than 1 indicates poor cost efficiency.
•	Schedule Performance Index (SPI):
SPI = EV / PV
SPI = $1,200,000 / $1,272,000
SPI ≈ 0.9434
•	SPI less than 1 indicates the project is progressing slower than planned.
•	Estimate at Completion (EAC):
EAC = BAC / CPI
EAC = $2,527,200 / 0.9091
EAC ≈ $2,780,000
•	EAC projects the total cost at completion based on current performance.
•	Estimated Time to Complete (ETC):
ETC = Original Duration / SPI
ETC = 8 months / 0.9434
ETC ≈ 8.48 months
•	ETC estimates the total project duration based on current schedule performance.
•	Variance Analysis
•	Cost Variance (CV): The project is over budget by $120,000, indicating that more money has been spent than the value of the work completed.
•	Schedule Variance (SV): The project is behind schedule by $72,000 worth of work, meaning less work has been completed than planned up to this point.
•	Cost Performance Index (CPI): At 0.9091, the project is not utilizing its budget efficiently.
•	Schedule Performance Index (SPI): At 0.9434, the project is progressing slower than planned.
4.5	EVM Graph
Figure 4.5: EVM Graph at End of Month 4
 
Note: The EVM graph plots the cumulative values of PV, EV, and AC over the project duration.
4.6	Project Performance and Forecasting Description
At the end of the fourth month, the project is experiencing both schedule delays and cost overruns. The Schedule Variance (SV) of -$72,000 and Schedule Performance Index (SPI) of 0.9434 indicate that the project is behind schedule, with less work completed than planned. The delay could result from complexities encountered during the design phase or underestimation of task durations.
The Cost Variance (CV) of -$120,000 and Cost Performance Index (CPI) of 0.9091 reveal that the project is over budget, spending more than the value of the work completed. Possible reasons include:
o	Extended Work Hours: Team members may have worked overtime to address challenges, increasing labor costs.
o	Unexpected Expenses: Additional costs, such as higher equipment prices or extra resources, may not have been anticipated.
The Estimate at Completion (EAC) projects the total project cost to be approximately $2,780,000, exceeding the original budget (including contingency) by $252,800. The project is also projected to extend to approximately 8.5 months, nearly half a month beyond the planned duration.
To address these issues, we need to:
•	Analyze the Causes: Investigate the reasons for schedule delays and cost overruns, such as scope changes, resource inefficiencies, or technical challenges.
•	Implement Corrective Actions: Reallocate resources, optimize processes, and implement cost-saving measures to improve CPI and SPI.
•	Update the Schedule and Budget: Adjust the project plan to reflect realistic timelines and costs, ensuring that stakeholders are informed of any changes.
By taking proactive steps, we aim to bring the project back on track, minimize the cost overrun, and meet the project’s objectives within the adjusted budget and schedule.
5	Project Resource Management
In this chapter, we delve into the project's resource management aspects, focusing on the team dynamics, responsibility assignments, and workload distribution. Effective resource management ensures that the project progresses smoothly, with clear roles, efficient collaboration, and balanced workloads among team members.
5.1	Team Charter
Project Purpose
The Shared Bike App Platform project aims to develop a comprehensive software system to support the local government's shared bike program. This initiative addresses urban challenges by promoting sustainable transportation, reducing traffic congestion, and improving air quality.
Team Mission
Our mission is to collaboratively develop and deploy a high-quality software system that fulfills all specified requirements, meets user needs, and is delivered on time and within budget constraints. We strive to maintain a positive team environment that encourages innovation, professional growth, and a shared commitment to excellence.
Team Vision
Our vision is to be a cohesive and high-performing team that delivers a state-of-the-art software platform for the shared bike program. We aim to contribute significantly to sustainable urban living and set a benchmark for future projects in public transportation and environmental initiatives.
Team Goals
o	Deliver on Schedule and Budget: Complete the project within the stipulated time frame and budget.
o	Meet Quality Standards: Ensure the software meets all government specifications, compliance standards, and user requirements.
o	Effective Communication: Foster open and efficient communication channels within the team and with stakeholders.
o	Continuous Improvement: Encourage learning and professional development among team members.
o	Customer Satisfaction: Achieve high satisfaction levels from the sponsor and end-users through reliable and user-friendly solutions.
Team Members and Roles
o	Leo (Project Manager)
o	Responsibilities: Overall project management, scheduling, resource allocation, stakeholder communication, conflict resolution, risk management, and ensuring project objectives are met.
o	Bill (Senior Developer)
o	Responsibilities: Leading analysis and design phases, software architecture, database design, mentoring developers, overseeing technical quality, and ensuring adherence to best practices.
o	Lisa (Developer)
o	Responsibilities: UI/UX design, client-side coding, interface development, user experience optimization, and creating technical training materials.
o	Andy (Developer)
o	Responsibilities: Server-side coding, system integration, implementation of security features, performance optimization, and deployment preparation.
o	Kent (Developer)
o	Responsibilities: Client-side coding, testing, quality assurance, assisting with UI/UX development, and post-deployment support.
Core Values
o	Collaboration: We value teamwork and believe that collaborative efforts lead to superior outcomes.
o	Integrity: We commit to honesty and transparency in all interactions.
o	Excellence: We strive for the highest quality in our work and continuously seek ways to improve.
o	Respect: We treat each other with respect and value diverse perspectives and contributions.
o	Accountability: We take responsibility for our actions and their impact on the project and team.
Communication Guidelines
o	Meetings:
o	Team Meetings: Held twice a week on Mondays and Thursdays at 10 AM to discuss progress, issues, and plans.
o	Stakeholder Meetings: Scheduled as needed to provide updates and gather feedback.
o	Communication Channels:
o	Email: For formal communications and documentation.
o	Instant Messaging (Slack): For quick questions and discussions.
o	Video Conferencing (Zoom/Teams): For virtual meetings and presentations.
o	Reporting:
o	Team members submit weekly progress reports every Friday by 5 PM.
o	The Project Manager compiles and distributes a weekly project status report to stakeholders.
Decision-Making Guidelines
o	Consensus-Based Approach: Decisions are made collaboratively, seeking input from all relevant team members.
o	Escalation: If consensus cannot be reached, the Project Manager will make the final decision after considering all perspectives.
o	Documentation: All significant decisions are documented and shared with the team.
Conflict Resolution Guidelines
o	Direct Communication: Team members address conflicts directly and respectfully with the involved parties.
o	Mediation: The Project Manager acts as a mediator if conflicts cannot be resolved between individuals.
o	Focus on Issues: Discussions focus on resolving the issue at hand, not personal attributes.
Meeting Guidelines
o	Preparation: Agendas are distributed before meetings, and team members are expected to come prepared.
o	Punctuality: Meetings start and end on time.
o	Participation: All team members are encouraged to actively participate and share their insights.
o	Action Items: Responsibilities and deadlines are clearly assigned during meetings.
Team Agreements
o	Availability: Team members inform the Project Manager of any planned absences at least two weeks in advance.
o	Responsiveness: Team members respond to communications within 24 hours.
o	Quality Commitment: Adherence to coding standards, documentation requirements, and testing protocols is mandatory.
o	Support and Collaboration: Team members support each other and share knowledge to overcome challenges.
Team Performance Assessment
o	Regular Reviews: The Project Manager conducts monthly performance reviews with each team member.
o	Feedback Mechanism: Constructive feedback is provided promptly to acknowledge achievements and address any issues.
o	Recognition: Exceptional contributions are recognized during team meetings and in project communications.
________________________________________
5.2	RACI Chart
The RACI chart outlines the roles and responsibilities of team members for each project task, ensuring clarity and accountability. It aligns tasks with team members' skills and expertise, facilitating effective collaboration.
Legend:
o	R (Responsible): The person(s) who perform the task.
o	A (Accountable): The person who is ultimately accountable and has authority.
o	C (Consulted): The person(s) who need to be consulted before a decision or action.
o	I (Informed): The person(s) who need to be informed after a decision or action.
RACI Chart for Project Tasks (a to z)
Task ID	Task Name	Leo (PM)	Bill (SD)	Lisa (D1)	Andy (D2)	Kent (D3)
a	Background study on e-payment implementation	C	R/A	I	I	I
b	Requirements Analysis	R/A	R	I	I	I
c	Develop prototype for payment procedure	I	A	R	C	C
d	Design overall software architecture	I	R/A	C	C	I
e	Design database schema	I	R/A	I	C	I
f	Design end-user interfaces for mobile applications	I	C	R/A	I	C
g	Design admin interfaces for desktop computers	I	C	A	I	R
h	Design signal connection mechanisms with bike locks	I	C	I	R/A	I
i	Design security scheme	I	C	I	R/A	I
j	Develop interface templates for review	I	I	R/A	C	C
k	Create site map/hierarchy chart	I	C	R/A	I	C
l	Create individual web pages	I	C	R	I	R
m	Create the database	I	A	I	R	I
n	Source client-side coding libraries	I	I	C	I	R/A
o	Purchase bike locks	R/A	C	I	C	I
p	Code server-side modules for admin and operations	I	C	I	R/A	I
q	Code server-side modules for end-user services	I	C	I	R/A	I
r	Code client-side modules for admin and operations	I	C	C	I	R
s	Code client-side modules for end-user services	I	C	R	I	C
t	Integrate server-side modules and web pages	I	C	C	R/A	C
u	Test connection to bike locks with app	I	C	C	R/A	C
v	Perform performance stress tests	I	C	I	C	R/A
w	Conduct User Acceptance Testing (UAT)	R/A	C	C	I	I
x	Install website on government's web server	I	C	I	R/A	I
y	Create technical training materials for staff	A	C	R	I	I
z	Train staff in operating and maintaining the system	A	C	R	C	I
________________________________________
5.3	Resource Histogram
The Resource Histogram illustrates the distribution of work among team members over the project's duration. It helps identify periods of high or low workload, enabling the Project Manager to balance resources effectively.
Methodology
1.	Project Timeline Division: The 8-month project duration is divided into 16 two-week periods.
2.	Task Scheduling: Tasks are mapped to these periods based on their start and finish dates.
3.	Workload Calculation:
o	For each task assigned to a team member, we calculate the number of hours they work during each period.
o	A standard work schedule of 8 hours per day and 5 workdays per week (40 hours per week).
o	If a task spans multiple periods, the workload is distributed accordingly.
Resource Histogram Data
Total Work Hours per Team Member:
o	Leo (PM): 984 hours
o	Bill (SD): 1,776 hours
o	Lisa (D1): 1,336 hours
o	Andy (D2): 1,552 hours
o	Kent (D3): 1,288 hours
Work Hours Distribution:
Below is the distribution of work hours for each team member across the 16 periods.
Period Definitions:
o	Period 1: Days 0-13 (Jan 1 - Jan 14)
o	Period 2: Days 14-27 (Jan 15 - Jan 28)
o	Period 3: Days 28-41 (Jan 29 - Feb 11)
o	Period 4: Days 42-55 (Feb 12 - Feb 25)
o	Period 5: Days 56-69 (Feb 26 - Mar 10)
o	Period 6: Days 70-83 (Mar 11 - Mar 24)
o	Period 7: Days 84-97 (Mar 25 - Apr 7)
o	Period 8: Days 98-111 (Apr 8 - Apr 21)
o	Period 9: Days 112-125 (Apr 22 - May 5)
o	Period 10: Days 126-139 (May 6 - May 19)
o	Period 11: Days 140-153 (May 20 - Jun 2)
o	Period 12: Days 154-167 (Jun 3 - Jun 16)
o	Period 13: Days 168-181 (Jun 17 - Jun 30)
o	Period 14: Days 182-195 (Jul 1 - Jul 14)
o	Period 15: Days 196-209 (Jul 15 - Jul 28)
o	Period 16: Days 210-223 (Jul 29 - Aug 11)
Work Hours per Team Member per Period:
(Note: The following is an estimated distribution based on task assignments and durations.)
Period	Leo (PM) Hours	Bill (SD) Hours	Lisa (D1) Hours	Andy (D2) Hours	Kent (D3) Hours
1	24	80	0	0	0
2	40	80	0	0	0
3	40	80	0	0	0
4	40	64	48	0	0
5	24	64	80	16	16
6	0	64	80	80	64
7	0	64	64	80	80
8	0	64	64	80	80
9	0	64	64	80	80
10	0	40	40	80	80
11	0	0	0	64	64
12	0	0	0	64	40
13	16	16	16	16	16
14	40	0	0	0	0
15	40	0	80	0	0
16	40	16	0	0	0
Total	304	696	536	560	520
Explanation:
o	Periods 1-3: Leo and Bill focus on analysis and design tasks. Leo (PM) spends time on requirements analysis and feasibility studies.
o	Periods 4-5: Lisa and Kent begin UI/UX design tasks, while Andy starts initial development tasks.
o	Periods 6-10: Core development phase where all developers are heavily involved in coding and integration.
o	Periods 11-12: Andy and Kent focus on testing and deployment preparation.
o	Periods 13-16: Leo resumes significant involvement for UAT, training, and project closure. Lisa assists with training materials.
Resource Histogram Visualization
A bar chart (histogram) can be created to visualize the above data, with periods on the x-axis and work hours on the y-axis. Each team member's workload can be represented by a colored bar for each period.
Sample Histogram:
Due to the constraints of this document format, please refer to the attached chart or spreadsheet for the visual representation of the Resource Histogram.
Analysis and Workload Balancing
o	Peak Periods: Periods 6-10 show the highest workload for developers, aligning with the intensive coding and integration phase.
o	Leo's Involvement: The Project Manager's workload is heavier during early analysis and late-stage activities like UAT and project closure.

5. Project Risk Management
You are required to conduct a risk analysis for your project. Identify two incidences that could
potentially inflict risk on your project in the future, necessitating changes to keep the project on
track for success. You need to conduct evaluation on the incidences in terms of their
probabilities and impacts toward the project, and propose risk responses and
secondary/residual risks on them and identify the type of risk responses. The risk responses
include adjustments to address the incidence(s) while making an effort to adhere to the original
budget. If the change will result in a budget increase, you must provide a justification for this
increase. Additionally, consider the organizational structure and the procedure for submitting
change requests. Tailor your responses specifically to the context of your project (In other
words, avoid using vague language that could apply to any situation). If possible, include some
intriguing insights. For each incidence, please document your findings in at least 400 words but
no more than 600 words, organized into four paragraphs as follows.

⚫ Incidence (e.g. the sponsor requests the project manager to expedite the project and to
complete it 2 months earlier; a disaster happens; the chief engineer gets sick and is no
longer capable to carry on his/her duties; the delay of delivery of the equipment etc.)

⚫ Anticipated probability and impact on the project (in the 4 project objectives) (e.g. the
project would be impacted by the delay by one month and probably by the increase of
cost due to... etc.)
⚫ Risk response (i.e. propose actions addressing the risks brought by the incidences)
⚫ Potential secondary/residual risks (the potential secondary and residual risks that may
arise for the project if the proposed changes are implemented)
(Make an effort to incorporate as many project management concepts and terminologies as
possible, including considerations of scope, time, cost, quality, and risk. Utilize terms such as
fast-tracking, crashing, contingent plans, secondary risks, contingent reserves, change requests,
critical path analysis, and stakeholder expectations, as well as various risk response
strategies.).