University Project: Project Management of RALS Rostering Application

Verified

Added on  2019/09/26

|13
|2093
|119
Project
AI Summary
This project management assignment focuses on the development of a RALS rostering application, aiming to improve organizational efficiency. The assignment includes a Measurable Organizational Value (MOV) assessment, outlining the project's strategic, customer, financial, and operational impacts. It details a comprehensive Scope Management Plan, considering mobile and web application usability and outlining required resources and human resources. A Work Breakdown Structure (WBS) is provided with detailed task durations, start and finish dates, and resource allocation. The assignment also includes a Risk Analysis and Plan, identifying potential risks such as scope creep, resource crises, and technical bugs, along with mitigation strategies. Finally, a Quality Management Plan ensures adherence to project standards and client requirements, emphasizing clear communication and verification processes throughout the development lifecycle. References to relevant project management literature are also provided.
tabler-icon-diamond-filled.svg

Contribute Materials

Your contribution can guide someone’s learning journey. Share your documents today.
Document Page
Project Management
RALS Rostering Project
Student Name:
Student ID:
Course Name:
Course ID:
Faculty Name:
University Name:
tabler-icon-diamond-filled.svg

Secure Best Marks with AI Grader

Need help grading? Try our AI Grader for instant feedback on your assignments.
Document Page
1
Table of Contents
Part One: Measurable Organizational Value...................................................................................2
Part Two: Scope Management Plan.................................................................................................2
Part Three: Work Breakdown Structure..........................................................................................2
Part Four: Risk Analysis and Plan...................................................................................................2
Part Five: Quality Management Plan...............................................................................................2
References........................................................................................................................................2
Document Page
2
Part One: Measurable Organizational Value
The measurable organizational value has considered the goals and objectives of the project as per
the overall goal of the organization.
The system is about the RALS rostering project. Mentioned below are the goals of the project.
The area of impact that has been identified is customers, operational, and strategic. It is also
financial to some extent.
The goal is to develop an application that will improve the daily functioning of the organization.
The new online application will allow the individuals (from top management to the employees
working on the floor) to properly view their scheduled activities (Song, 2013).
Strategic: From the strategic point of view the company will benefit more as the employees will
be able to work efficiently and improve the overall productivity of the organization.
Customers: They will be able to receive quicker and efficient service as all will be clear about
their goals and functionalities.
Financial: The Company will be able to save unnecessary time wastage of the employees’ thus
efficient use of resources converting into better earning.
Operational: Operation will be more efficient and fast. There will be less confusion and seamless
functioning.
The metric of MOV will be significant as the roster is directly concerned with the operation of
the organization. Therefore, it can be stated that the overall MOV can be 50-60 percent.
Document Page
3
The time frame for the MOV has been considered to be of three years.
The project will be successful if the management cooperates with the required resources and
allows significant project time.
Part Two: Scope Management Plan
The project development of the application has considered the usability of the application on
mobile phones as the employees are more active on the phone rather than on desktop. However,
there will also be web version which will be used by the administrators and the management to
update the roster as and when required (Cooper, 2013).
Mentioned below are the required resources:
- Individuals to develop the project
- Budget to install development facility and developed project
Mentioned below are the human resources that will be required by the project:
Item Provider Audience Form / Media Frequency
Project
Component
Documentation
Business
Analyst
Sponsor, PM
and team
members
Document on
Confluence
page with
authorized
access
After every
release of the
component
Project Status
Meeting
Project
Manager
Sponsors and
Users
Meeting and
Presentation
Every Two
weeks
Blockers List Project
Manager
Dependent
Teams
Managers
Email Whenever there
is any blocker
Risk Document Business
Analyst
Sponsors Report Bi-Weekly
Change Change PM, Change At every
tabler-icon-diamond-filled.svg

Secure Best Marks with AI Grader

Need help grading? Try our AI Grader for instant feedback on your assignments.
Document Page
4
Management
Report
Authorizer Stakeholders
and Developers
Request Form release of the
component
There is no external hardware or software required to run the new application. The application
will be compatible with the major operating system provided in the market and available with the
company mobile. Moreover, the web version of the site can be opened on all browsers. However,
the project development will require resources for the development which includes five computer
system and internet connection.
The team will be working within the company. The space has been provided by the company and
no extra charge is being incurred on the same. There will be initial training of the individuals
which particularly will be on project deliverable and how to work together efficiently to
complete the project within defined budget and duration.
Part Three: Work Breakdown Structure
Mentioned below is the work break down structure with the milestones:
Task Name Duration Start Finish Predecessors Resource Names Milestone
RALS Roster
Development 81 days?
Mon
03-10-
16
Mon
23-01-
17
No
Scope 10 days?
Wed
05-10-
16
Tue
18-10-
16
No
Determine project
scope 2 days
Wed
05-10-
16
Thu
06-10-
16
Project Manager No
Secure project
sponsorship 3 days Fri 07-
10-16
Tue 11-
10-16 3 Project Analyst No
Define
preliminary resources 2 days
Wed
12-10-
16
Thu
13-10-
16
4 Project Manager No
Document Page
5
Secure core
resources 2 days Fri 14-
10-16
Mon
17-10-
16
5 Business Analyst No
Scope Document 1 day?
Tue
18-10-
16
Tue 18-
10-16 6 Yes
Analysis/Software
Requirements 17 days?
Mon
03-10-
16
Tue
25-10-
16
No
Conduct needs
analysis 2 days?
Mon
03-10-
16
Thu
06-10-
16
Business
Analyst,Project
Manager
No
Draft preliminary
software specifications 3 days Fri 07-
10-16
Tue 11-
10-16 9 No
Review software
specifications/budget
with team
2 days
Wed
12-10-
16
Thu
13-10-
16
10 Project Analyst No
Incorporate
feedback on software
specifications
3 days Fri 14-
10-16
Tue 18-
10-16 11 No
Develop delivery
timeline 2 days
Wed
19-10-
16
Thu
20-10-
16
12 No
Obtain approvals
to proceed (concept,
timeline, budget)
1 day? Fri 21-
10-16
Fri 21-
10-16 13 No
Secure required
resources 1 day?
Mon
24-10-
16
Mon
24-10-
16
14 No
Software
Rquirement Document 1 day?
Tue
25-10-
16
Tue 25-
10-16 15 Yes
Design 4 days?
Mon
03-10-
16
Thu
06-10-
16
Project Manager No
Review
preliminary software
specifications
2 days?
Mon
03-10-
16
Tue 04-
10-16
Project
Analyst,Project
Manager
No
Develop
functional
specifications
3 days
Mon
03-10-
16
Wed
05-10-
16
No
Develop prototype
based on functional
specifications
4 days
Mon
03-10-
16
Thu
06-10-
16
No
Document Page
6
Review functional
specifications 1 day?
Mon
03-10-
16
Mon
03-10-
16
No
Incorporate
feedback into
functional
specifications
3 days
Mon
03-10-
16
Wed
05-10-
16
No
Obtain approval to
proceed 2 days
Mon
03-10-
16
Tue 04-
10-16 No
Design Document 3 days
Mon
03-10-
16
Wed
05-10-
16
Yes
Development 28 days
Thu
06-10-
16
Mon
14-11-
16
Developer,Developer
2 No
Review functional
specifications 2 days
Thu
06-10-
16
Fri 07-
10-16 24 No
Identify
modular/tiered design
parameters
3 days
Mon
10-10-
16
Wed
12-10-
16
26 No
Assign
development staff 2 days
Thu
13-10-
16
Fri 14-
10-16 27 No
Develop code 15 days
Mon
17-10-
16
Fri 04-
11-16 28 No
Developed System 6 days
Mon
07-11-
16
Mon
14-11-
16
29 Yes
Testing 27 days
Tue
15-11-
16
Wed
21-12-
16
Testers No
Develop unit test
plans using product
specifications
5 days
Tue
15-11-
16
Mon
21-11-
16
30 No
Develop
integration test plans
using product
specifications
6 days
Tue
22-11-
16
Tue 29-
11-16 32 No
Unit Testing 13 days
Tue
22-11-
16
Thu
08-12-
16
No
tabler-icon-diamond-filled.svg

Paraphrase This Document

Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
Document Page
7
Review modular
code 3 days
Tue
22-11-
16
Thu
24-11-
16
32 No
Modify code 3 days Fri 25-
11-16
Tue 29-
11-16 35 No
Re-test modified
code 3 days
Wed
30-11-
16
Fri 02-
12-16 36 No
Unit Test
Document 4 days
Mon
05-12-
16
Thu
08-12-
16
37 Yes
Integration
Testing 9 days
Fri
09-12-
16
Wed
21-12-
16
No
Test module
integration 3 days Fri 09-
12-16
Tue 13-
12-16 38 No
Modify code 4 days Fri 09-
12-16
Wed
14-12-
16
38 No
Re-test modified
code 3 days
Wed
14-12-
16
Fri 16-
12-16 40 No
Integration
Testing Document 3 days
Mon
19-12-
16
Wed
21-12-
16
42 Yes
Documentation 6 days?
Wed
14-12-
16
Wed
21-12-
16
Technical
Communication No
Develop Help
specification 1 day?
Wed
14-12-
16
Wed
14-12-
16
40 No
Develop Help
system 1 day?
Thu
15-12-
16
Thu
15-12-
16
45 No
Review Help
documentation 1 day? Fri 16-
12-16
Fri 16-
12-16 46 No
Incorporate Help
documentation
feedback
1 day?
Mon
19-12-
16
Mon
19-12-
16
47 No
Develop user
manuals 1 day?
Tue
20-12-
16
Tue 20-
12-16 48 No
Documentations 1 day? Wed
21-12-
Wed
21-12-
49 Yes
Document Page
8
16 16
Pilot 16 days
Thu
22-12-
16
Thu
12-01-
17
Project Manager No
Identify test group 3 days
Thu
22-12-
16
Mon
26-12-
16
50 No
Develop software
delivery mechanism 3 days
Tue
27-12-
16
Thu
29-12-
16
52 No
Install/deploy
software 2 days Fri 30-
12-16
Mon
02-01-
17
53 No
Obtain user
feedback 3 days
Tue
03-01-
17
Thu
05-01-
17
54 No
Evaluate testing
information 2 days Fri 06-
01-17
Mon
09-01-
17
55 No
Pilot Testing
Report 3 days
Tue
10-01-
17
Thu
12-01-
17
56 Yes
Deployment 81 days
Mon
03-10-
16
Mon
23-01-
17
Developer,Developer
2 No
Determine final
deployment strategy 2 days
Mon
03-10-
16
Tue 04-
10-16 No
Develop
deployment
methodology
3 days
Tue
10-01-
17
Thu
12-01-
17
56 No
Secure
deployment resources 2 days Fri 13-
01-17
Mon
16-01-
17
57 No
Deploy software 3 days
Tue
17-01-
17
Thu
19-01-
17
61 No
Deployment
Document 2 days Fri 20-
01-17
Mon
23-01-
17
62 Yes
Document Page
9
Part Four: Risk Analysis and Plan
Given below is the detailed risk matrix register that shows the risks that have been identified for
the project:
Prep
ared
By:
Business Analyst/
Risk Analyst Date:
May
13th,
2015
No
Ran
k Category
Risk
Name
Descript
ion
Trigger
s
Potential
Responses Owners
Proba
bility
(1-3)
Im
pac
t
(1-
3)
Sc
or
e
Sta
tus
RIS
K1 4 Scope
Scop
e
Creep
Workin
g on the
project
things
that are
not in
scope.
Unwan
ted
user
deman
d
Sign off
initially PM 2 3 6 C
RIS
K2 6
Resources
and Team
RT
Crisis
Any
crucial
resource
decides
to leave
midway
.
Emplo
yee
unsatis
faction
Contract
Signing PM 1 2 2 E
RIS
K3 6
Resources
and Team
RT
Crisis
Lack of
Experie
nce and
Skill.
High
Difficu
lty
level
of
Project
Backup
resource PM 1 2 2 E
RIS
K4 5
Design
Ldesi
gn
Low
Quality
Design
Poorly
Techni
que for
user
feedba
ck
Users
Approval
Designe
r and
BA 1 3 3 E
RIS
K5
7 Technical CBug Security
and
Scalabil
Unkno
wn
bugs
Security
Protocols
Implement
Develop
er
2 2 4 E
tabler-icon-diamond-filled.svg

Secure Best Marks with AI Grader

Need help grading? Try our AI Grader for instant feedback on your assignments.
Document Page
10
ity
and
use
cases ation
RIS
K6 1
Quality
Cqual
ity
Inferior
quality
of code
might
trigger
rework
that can
lead to
project
failure
Lack
of
testing
and
review
s
Unit
Testing,
UAT,
Integratio
n Testing
Develop
er and
BA 1 3 3 C
RIS
K7 8
External Agen
ts
Delay in
approva
ls
Red
tape in
Admin
Escalation
s
Sponsor
s 1 1 2 C
RIS
K8 2
User
Acceptance
UAR
Possibil
ity of
user not
liking
the end
product
and do
not
prefer
using
the
online
platform
Poor
design
and
interfa
ce
User
Feedback,
Testing
PM and
Sponsor
s 2 2 4 C
RIS
K9 3
Mobile
Applicatio
n
UMA
R
Lack of
compati
bility on
Differen
t
devices
Develo
pers
inexper
ience,
Poor
design,
Lack
of
compat
ibility
Skilled
developer
for mobile
platforms
and
testing
PM/
Develop
ers 2 3 6 C
The table below shows the risks assigned to the individuals within the team:
Document Page
11
Identified
Risks
Assigned Individuals
Scope Creep PM
RT Crisis Developer
RT Crisis Developer
Ldesign Developer
CBug Developer
Cquality PM
Agents PM
UAR Developer
UMAR Developer
Part Five: Quality Management Plan
The quality will be assessed in accordance with the deliverables and the project standard. The
quality project will be delivered to the client to ensure that the similar client approach the
development in the later period. The project team will ensure that the entire requirement of the
project have been taken into consideration prior to moving ahead with the project. Moreover, the
team members should have clear communication about the project so that no confusion arise
about the project quality.
The project will be verified by the client to ensure that the project meets all the requirements
stated in the beginning and then these systems will be validated by running the system.
Document Page
12
References
Burke, R. (2013). Project management: planning and control techniques. New Jersey, USA.
Cooper, V. N., & Haddad, H. M. (2013, January). Study of Agility in Mobile Application
Development. In Proceedings of the International Conference on Software Engineering
Research and Practice (SERP) (p. 1). The Steering Committee of The World Congress in
Computer Science, Computer Engineering and Applied Computing (WorldComp).
Kerzner, H. R. (2013). Project management: a systems approach to planning, scheduling, and
controlling. John Wiley & Sons.
Nourbakhsh, M., Mohamad Zin, R., Irizarry, J., Zolfagharian, S., & Gheisari, M. (2012). Mobile
application prototype for on-site information management in construction industry. Engineering,
construction and architectural management, 19(5), 474-494.
Schwalbe, K. (2015). Information technology project management. Cengage Learning.
Song, J., Choi, H., Baker, J., & Bhattacherjee, A. (2013). Mobile application development
platform adoption: A grounded theory investigation.
chevron_up_icon
1 out of 13
circle_padding
hide_on_mobile
zoom_out_icon
logo.png

Your All-in-One AI-Powered Toolkit for Academic Success.

Available 24*7 on WhatsApp / Email

[object Object]