Projectmanagement 2

2001ICT Project Management
School of Information & Communication

Technology
Semester 2, 2014
Group 6- Part 2
Members:
s2843586
s2801992
s2902632
s2919932
Kirk Roberts
Isaac Hoban
Lorenzo Lim
Francis Fernandez
1. Project Charter
Revision History
Date
Ver.
Author
Addition/Alteration
28/7/2014
1.0
Lorenzo Lim
Completed business experience, project

description.
4/8/2014
1.1
Isaac Hoban
Completed project objectives, success

criteria and project approach.
11/8/2014
1.2
Kirk Roberts
Identified Primary stakeholders and

completed Onion Diagram.
11/8/2014
1.3
Lorenzo Lim
Completed budget estimate.
15/08/14
1.4
Francis Fernandez
Began stakeholder analysis and

communication strategy.
18/08/14
1.5
Kirk Roberts
Completed stakeholder analysis.
18/08/14
1.6
Isaac Hoban
Completed communication strategy and

completed stakeholder influence grid.
12/09/14
2.0
Isaac Hoban
Edited stakeholder analysis.
13/09/14
2.1
Isaac Hoban
Edited communication strategy.
1.1 Company Information

Project Title: ABC Server Hardware Tender
Project Manager: Lorenzo Lim
Company Name: Group 6
Team Members: Kirk Roberts, Isaac Hoban, Lorenzo Lim, Francis Fernandez.
Business Experience: Our company is an international company that has been in
operation for 20 years. We are a highly trained professional team that have been
entrusted with numerous projects from different companies.
Project Description: The Technology Division of the Australian Broadcasting
Corporation are seeking vendors responses for the supply of Server Hardware(x86
Architecture only) and system management tools associated with it over an initial term
of (3) years with two possible one (1) year extensions at the ABCs discretion for a total
term of five (5) years. It is assumed that ABC need new servers because their current
servers might be out of date and need to be replaced. The new servers that will be
implemented will also be able to integrate into the already existing ABC system.
Project Objectives and Success criteria:

Project Objectives
Success Criteria
Person Approving
Scope:
Supply of Server
Hardware and system
management tools.
All functional and

technical requirements of
supply are met.
Project Manager
Project completed
between the dates of
July 28th 2014 and
October 19th 2014.
Project Manager
Project completed within

a budget of $24,000 and
$30,666.
Project Manager
Time:
Project completion within
the timeframe.
Cost:
Project completion within
budget.
Approach:
The Waterfall model will be the most relevant Software Development Lifecycle(SDLC)
for this project as we will not require any prototypes. The waterfall is being used for this
project as we have clear understanding of the initial requirements for the system to be
developed, and these requirements are to remain unchanged. The ABC has an IT
department so it wont be necessary for us to continually give them new hardware,
implement and maintain them. Prototyping is also not necessary since our only client is
ABC and we would only need to consult them with the project instead of multiple clients.
The agile approach is also not needed because it is a simple hardware procurement
project.
Stakeholders:
The onion diagram is useful when identifying who the key stakeholders are within a
project, it helps you group stakeholders together to become more manageable and
understandable.
Layer 1: Stakeholders tightly integrated with the creation of the project.
Layer 2: People that will be impacted directly by the system.
Layer 3: People backing the project financially.
Layer 4: Stakeholders that are external to the project however are still relevant.
Start and Finish:
Start Date: July 28th 2014
Finish Date: October 19th 2014
Budget:
PERT Estimation
(O + 4M + P)/6
O= Optimistic Estimate
M= Most Likely Estimate
P= Pessimistic Estimate
After researching multiple websites, a budget was calculated using the PERT Estimation
method. These prices have been acquired from the following sites: Umart, Ebay, Brocade and
Cisco.
Configuration
Amount
Requirement
16
Blade Server Slots
$1239
Cisco Network Switches
$425
Brocade 8GB SAN Switches
$2137
Full redundancy for all enclosure components

including Power Supplies, Fans, Onboard
Management, Switches and Backplane where
applicable for your offering
$500
Management Licences
$900
Warranty
Included with
Hardware
Total cost for configuration 1:
Price
$28,048
Using this amount, we calculated the budget using the PERT Estimation method.
O = $24,000
M = $28,048
P = $50,000
(24,000 + 4 x 28,048 + 50,000)

_______________________
6
Budget Estimate = $30,666
The above budget is was calculated for the hardware procurement and does not include the
salary of the team members of this project or the tech support engineer. The calculated salary
would be $40/hour per person which come to a total of $150-160/hour for the team and $200210/hour with the tech support engineer included.
1.2 Stakeholder Analysis

Name of Client Liaison: Francis Fernandez
Stakeholder Analysis
Stakeholders
Level of
Interest
Level of
Influence
CEO (Chief
Executive
Officer)
Very High - The

CEO maintains
a large interest
in the project
due to the
responsibility of
managing and
monitoring all
operations within
the organisation
ABC Senior
Executives
Tech Support
Engineer
Critical
Informati
on
Work
Products
Communi
cation
Method
Strategy
Very High - Project

Has the
informatio
ability to
n
cancel the
project at
any time
and make
decisions
which may
alter the
course of
the project
Project Plan,
Project
Updates,
Budget,
Meeting
Minutes
Face to
Face
Weekly
High - Each of
the executives
has a role in
authorising the
project and thus
maintains
substantial
interest in its
progress
Very High - Project

Has the
informatio
ability to
n
bring any
concerns
to
meetings
and alter
the course
of the
project.
Decisions
carry a
large
degree of
weight
Project Plan,
Project
Updates,
Budget,
Meeting
Minutes
Face to
Face
Weekly
Very High - The

stakeholder
High - The
testing
Hardware,
Software,
Email &
Phone
Monthly
System
Informatio
desires a
successful
outcome to the
project in order
to replace the
old hardware
and software
systems
phase of
n
the project
has the
potential to
make a
number of
userinterface
design
changes
Technical
Training
Very High - The

project has a
large impact on
the stakeholder.
Finances, time,
and business
processes are
all dependent on
successful
completion of
the project
High System
Stakeholde Informatio
r concerns n
about
design are
valuable to
developme
nt, as
satisfaction
ensures
successful
delivery
ABC
Employees
Moderate - The
project is quite
large and
extensive.
Employees may
have questions
about the effect
it may have on
their position
Low - The
involveme
nt of the
stakeholde
r will not
evolve
beyond
elementary
research
gathering
Project
Informatio
n and
Guides
News/Televisio Moderate - The

n/Radio Staff
stakeholder may
be interested in
Low - The
project will
not be
Project
Informatio
n and
Project
Updates,
Hardware
Manuals,
Changelogs/R
elease Notes,
Operating
Guides,
Installation
Guides, Data
Centre
Requirements,
Third Party
Certifications,
Standards
Documentation
, Systems
Manuals
Email &
Phone
Monthly
Changelogs,
User Manuals,
Operating
Guides,
Support
Guides
Email
Monthly
Changelogs,
User Manuals,
Operating
Email
Monthly
the progress,
outcome, and
impact of the
end product
influenced
by the
stakeholde
r
Guides
Guides,
Support
Guides
Marketing
Staff
Moderate - The
changes to a
core system of
the client may
be of some
interest to future
marketing
Low - Has
the ability
to make
any details
released
by the
organisatio
n but does
not have
an
influence
on the
direction of
the project
Project
Informatio
n and
Guides
Changelogs,
User Manuals,
Operating
Guides,
Support
Guides
Email
Monthly
Hardware
Suppliers
Low - Consultant
organisations
only interest is
ensuring the
successful
completion of
the task which
they are
employed for
High - Will
be
instrument
al in
constructio
n of the
hardware
in order to
ensure
project
completion
Hardware
Requirem
ents
Hardware
Requirements
Email &
Phone
When
Needed
Software
Suppliers
Low - Consultant
organisations
only interest is
ensuring the
successful
completion of
the task which
they are
employed for
Moderate Will be
involved in
constructio
n of the
software in
order to
ensure
project
completion
Software
Requirem
ents
Software
Requirements
Email &
Phone
When
Needed
Project
Manager
Very High Interested in the

outcome, the
Very High - All Critical

Decisions
Informatio
made by
n
Project Plan,
Budget,
Project
Face to
Face
Weekly
Project Team
control, the
planning, and all
aspects of the
project
the project
manager
will have a
substantial
influence
on the
project
Very High Interested in the

outcome of a
particular aspect
of the project
High Decisions
will need to
be
approved
by the
Project
Manager,
but have
the
potential to
have a
large
impact
Updates,
Hardware
Requirements,
Software
Requirements,
Hardware
Manuals,
Meeting
Minutes,
Changelogs/R
elease Notes,
Operating
Guides,
Installation
Guides, Data
Centre
Requirements,
Support
Guides, Third
Party
Certifications,
Standards
Documentation
,
Administration
Manuals,
Systems
Manuals, Best
Practice
Guides, User
Manuals
Time
frame,
Requirem
ents
Project Plan,
Hardware
Requirements,
Software
Requirements,
Changelogs/R
elease Notes,
Data Centre
Requirements
Face to
Face
Weekly
1.3 Communication Strategy

Recipient
Stakeholder
Position
Communication
Available
Communication
Method
Frequency
and
Attendants
Formalit
y
Priority
CEO(Chief
Executive
Officer)
CEO of
ABC
-Office Address
-Email Address
-Phone Number
-Office Hours
Face to Face
presentation and
approval of
Project Plan,
Project Updates,
Budget, Meeting
Minutes.
Weekly
meeting
between
CEO and
Client
Liaison
Formal
High
Tech Support
Engineer
ABC
System
Admin
-Email Address
-Phone Number
Email or phone
meeting for
presentation of
Hardware,
Software,
Project Updates,
Hardware
Manuals,
Changelogs/Rel
ease Notes,
Operating
Guides,
Installation
Guides, Data
Centre
Requirements,
Third Party
Certifications,
Standards
Documentation,
Systems
Manuals.
Phone
Formal
meeting or
email
presentatio
n between
Client
Liaison and
Technical
Trainer
when
deliverables
are
available.
High
Technical
Trainer
ABC
System
Trainer
-Email Address
-Phone Number
Formal
High
ABC
Employees
ABC
System
User
-Mass Email
Address
Formal
Low
Mass
Email/bulletin
containing
Periodical
mass email
from
Changelogs,
User Manuals,
Operating
Guides, Support
Guides.
Project
Manager to
ABC Staff.
News/Televisi ABC
on/Radio Staff System
User
-Mass Email
Address
Formal
Low
Marketing
Staff
ABC
System
User
-Mass Email
Address
Formal
Low
Hardware
Suppliers
Hardware
System
Supplier
-Email Address
-Phone Number
Email & Phone

discussion of
Hardware
Requirements.
Phone
Formal
discussion
or email
presentatio
n between
Project
Manager
and
Hardware
Supplier
when
deliverables
are
available.
Mediu
m
Software
Suppliers
Software
System
Supplier
-Email Address
-Phone Number
Email & Phone

discussion of
Software
Requirements.
Phone
Formal
discussion
or email
presentatio
n between
Project
Manager
and
Software
Supplier
when
deliverables
are
available.
Mediu
m
Project
Manager
ABC
System
Project
-Office Address
-Email Address
-Phone Number
Face to face
Weekly
meeting for
meeting
presentation and between
Casual
High
Project Team
Manager
-Office Hours
approval of all
documentation.
Project
Manager
and Project
Team.
ABC
System
Developer
-Office
Addresses
-Mass Email
Address
-Phone
Numbers
-Office Hours
Face to face
meeting for
discussion of
any changes to
Project Plan,
Hardware
Requirements,
Software
Requirements,
Changelogs/Rel
ease Notes,
Data Centre
Requirements.
Weekly
meeting
presenting
changes by
Project
Manager to
Project
Team.
Stakeholder Influence/Impact Grid
A.
B.
C.
D.
E.
Hardware
CEO
Tech support
ABC Employees/System users
Technical Training
Casual
High
F.
G.
H.
Developers
Software suppliers
Project Manager
The Influence/Impact grid, also known as the Influence/Impact matrix, is a tool that involves
focusing on the key set of project stakeholders in order to prioritize stakeholders requests,
spend time as per influence and impact stakeholders have, and lead the project to a success
without stakeholder conflicts.
2 Project Scope Statement

Revision History
Date
Ver.
Author
Addition/Alteration
20/08/14
1.0
Isaac Hoban
Completed scope description.
21/08/14
1.1
Kirk Roberts
Completed deliverables table.
14/09/14
2.0
Isaac Hoban
Edited scope description.
15/09/14
2.1
Kirk Roberts
Edited product deliverables.
2.1 Product Scope Description

FR ID
No.
Functional Requirement
Priority
Priority
Rating
FR001
The system hardware management

tool interface will be easy to
navigate.
FR002
The management system will store

hardware and server activity logs.
FR003
The management system will store

information of system users and their
activity throughout the software.
FR004
The system will store information

regarding user accounts including ID
number, usage data and permission
levels.
FR005
The system will provide a user

interface allowing users to view
system logs and real time

information.
FR006
The system will provide an

Administrator interface that allows
the creation, editing and deletion of
user accounts.
FR007
The system will store real time

information of active and inactive
servers and applications.
FR008
The system will display real time

FR009
The system will be able to generate

reminders and notifications regarding
the inactivity of any servers and
applications.
FR010
The system will allow a user to gain

access through the use of an ID
number and password input.
FR011
The system will allow for

administrators to view all users and
respective access rights and
privileges in database format.
FR012
The system will allow the user to

search, retrieve, and display recorded
logs.
TR ID
No.
Technical Requirement
Priority
Priority
Rating
TR001
The system with interface with Server

Hardware (x86 Architecture) and associated
system management tools.
TR002
The system will run on an industry standard

Operating Systems that currently has
mainstream support by the Operating System
vendor.
TR003
The system will integrate with industry standard

Active Directory (AD) for Authentication and
Authorisation for all user, maintenance and
system accounts.
TR004
The system will run and continuously operate

with industry approved antivirus systems.
TR005
The system will be able to be patched for

system problems and security vulnerabilities as
security issues are identified.
TR006
The system will use data formats such as

Extensible Markup Language (XML) for
message exchange and system configuration.
TR007
The system will use rich Application

Programming Interfaces (APIs) or data
exchange interfaces based on open industry
standards such as Web Services and XMLbased data formats.
TR008
The system will run on industry standard

network protocols and will not interfere with
network operations.
PriorityMandatory (M), Optional (O), Desirable (D).

Priority RatingHigh (H), Medium (M), Low (L).
2.2 Product Deliverables

Deliverable
Description
For
Hardware
Servers and all related physical

hardware.
ABC Employees,
Tech Support
Engineer/ Technical
Trainer
Software
System management tools.
ABC Employees,
Tech Support
Engineer/ Technical
Trainer
Project Plan
A plan that holds the scope
Project Manager,
Project Team, Tech
Support Engineer/
Technical Trainer,
CEO(Chief Executive
Officer)
Budget
A budget stating all costs required to
Project Manager,
complete the project.
CEO(Chief Executive
Officer)
Project Updates
Updates of project progress and

news/updates.
Project Manager,
Project Team, ABC
Employees, Tech
Support Engineer/
Technical Trainer,
CEO(Chief Executive
Officer)
Hardware
Requirements
List of all required hardware. Specific

models and prices will be included.
Project Manager,
Project Team,
Hardware Suppliers,
Tech Support
Engineer/ Technical
Trainer
Software
Requirements
What software will be needed for the

system.
Project Manager,
Project Team,
Software
Suppliers, Tech
Support Engineer/
Technical Trainer
Hardware
Manuals
Manuals explaining how delivered

hardware and software will operate,
troubleshooting and other helpful
information.
Project Manager,
ABC Employees,
Tech Support
Engineer/ Technical
Trainer
Meeting Minutes
Notes taken during meetings, will

include: people present for meeting, time
and location.
Project Manager
Changelogs/Rele
ase Notes
Logs of what has been changed and

updated with the system.
Project Manager,
ABC Employees,
Tech Support
Engineer/ Technical
Trainer
Operating Guides A guide that explains how to operate the

system.
Project Manager,
ABC Employees,
Tech Support
Engineer/ Technical
Trainer
Installation
Guides
Project Manager,
Tech Support
Engineer/ Technical
Instructions on how to install the system.
Trainer
Data Centre
Requirements;
cooling power,
space and floor
load
Requirement specifications for what we

will need from the Data Centre, including:
bandwidth, uptime, 24/7 support,
security and backup requirements.
Project Manager,
Project Team, Tech
Support Engineer/
Technical Trainer
Support Guides
A manual that has information to help a

user troubleshoot. Will include: common
problems, glossary of key terms and
support contact details.
Project Manager,
ABC Employees,
Tech Support
Engineer/ Technical
Trainer
Third Party
Certifications
Certifications that verify the legitimacy of

hardware and software.
Project Manager,
Tech Support
Engineer/ Technical
Trainer
Standards
Documentation
and Compliance
with Standards
Certifications that show the compliance

within requirements and guidelines.
Project Manager,
Tech Support
Engineer/ Technical
Trainer
Administration
Manuals
Information regarding administration

staff using the system, including: login
details and procedures.
Project Manager,
ABC Employees,
Tech Support
Engineer/ Technical
Trainer
Systems Manuals
Manual that includes information about

the system operates and how to
complete specific tasks.
Project Manager,
ABC Employees,Tech
Support Engineer/
Technical Trainer
Best Practice
Guides
Guides that include the common

suggested practices.
Project Manager,
ABC Employees,
Tech Support
Engineer/ Technical
Trainer
User Manuals
A manual for general staff that will be

using the system, including: login details
and procedures.
Project Manager,
ABC Employees,
Tech Support
Engineer/ Technical
Trainer
3 Work Breakdown Structure

Revision History
Date
Ver.
Author
Addition/Alteration
22/08/14
1.0
Francis Fernandez
Began wbs tree
25/08/14
1.1
Francis Fernandez
Completed work breakdown structure

tree
26/08/14
1.2
Francis Fernandez
Completed work breakdown structure

table
3.1 WBS Tree
3.2 WBS Table

ID
Task Name
Duration
Predecessor
1.
Planning of the Project
1.1.
Develop a Project Charter
1.1.1.
Define the Scope
2 days
1.1.2.
Define the Deliverable
2 days
1.1.3.
Define the Project Budget
3 days
1.2.
3 days
1.1
1.3.
Develop a Communication Strategy
2 days
1.1
1.4.
Finalize the Project Charter and gain

approvals
1 day
1.1, 1.2, 1.3
2.
Analysis of the Project
2.1.
Develop Work Breakdown Structure
3 days
2.1.1
2.1.1.
Develop Staff Training Plan
2 days
1.4
2.2.
Develop Risk Management Plan
2 days
1.1
2.3.
Develop Project Schedule
2 days
2.1
2.4.
Develop Change Management Plan
2 days
2.1
2.5.
Prepare Procurement Strategy
2 days
1.4
2.6.
Finalize all plans and gain approval
1 day
1.4,
2.1,2.2,2.3,2.4,2.5
3.
Service Provider Selection
3.1.
Evaluation of Responses
6 days
2.5
3.2.
Negotiate and Award Contract
2 days
2.5,3.1
3.3.
Conduct Negotiation
1 day
3.2
4.
Contract Management
4.1.
Contract Transition
4 days
3.3
4.2.
Manage Agency Performance
2 days
4.1
1.4
2.5
3.3
5.
Maintenance of the Project
5.1.
Assess Service Provider
6.
Closing of the Project
6.1.
6.2.
4.2
2 days
3.1,4.1,4.2
Conduct Post Project Review
3 days
2.6,3.3,4.2,5.1
Celebrate
1 day
4 Estimation
Revision History
Date
Ver.
Author
Addition/Alteration
15/09/14
1.0
Isaac Hoban
Began project estimation.
19/09/14
1.1
Isaac Hoban
Completed project estimation.
10/10/14
2.0
Isaac Hoban
Edited technique and justification.
10/10/14
2.1
Isaac Hoban
Added complexity level tables.
4.1 Choice of Technique

The technique chosen in order to estimate aspects of this project is known as Count, Compute,
Judge- Count if at all possible. Compute when you cant count. Use judgement alone only as a
last resort. This is the most accurate and comprehensive approach for the Waterfall software
development life cycle. Function point counting one such version of this technique used to
estimate a level of complexity for a product, based on the functionality that it will deliver.
Other estimation techniques to be used include the software estimation tool Cocomo II. The
Constructive Cost Model II (COCOMO II) is a model that allows one to estimate the cost,
effort, and schedule when planning a new software development activity. Combining function
point counting with this software tool provides an accurate estimation of the project team, cost
and time required to complete the client software.
4.2 Justification
This technique was chosen as most appropriate for the Waterfall life cycle approach. To
estimate you need to classify each type of function that you are developing, and then count the
appropriate data elements according to function type. Function Point tables are used to convert
these counts into complexity, and the complexity into a function point number. This can be done
at the beginning of each phase of the waterfall structure and allows a better understanding of
the time and resources required during each phase.
4.3 Estimation
Term
Acrony Definitions
m
Function Types
(functions that the product performs):
Internal Logical Files
ILF
Files of information that are stored and modified within

the system (ie, a personnel file for a payroll system)
External Interface
Files
EIF
External files of information that are used by the

system (ie, tax information from the ATO that the
payroll system might use)
External Inputs
EI
Information that is provided to the system (eg add, edit

and delete a person)
External Output
EO
Complex information from the system (the function

involves some manipulation of stored data)
External Inquiry
EQ
Simple information from the system (the function simply

displays stored information)
Element Types
(individual files or pieces of data that

the functions use)
Data Element Type
DET
Non-repeated fields or attributes
Record Element Type
RET
Groups of data within an ILF or EIF
File Types
Referenced
FTR
The ILF or EIF that is used or maintained by the

function
Complexity of EIF and ILF

RET
1-19 DET
20-50 DET
51+ DET
Low
Low
Avg
2-5
Low
Avg
High
6+
Avg
High
High
Complexity of EI
FTR
1-4 DET
5-15 DET
16+ DET
0-1
Low
Low
Avg
Low
Avg
High
3+
Avg
High
High
Complexity of EO and EQ
FTR
1-5 DET
6-19 DET
20+ DET
0-1
Low
Low
Avg
2-3
Low
Avg
High
4+
Avg
High
High
Final Function Point Count based on each Complexity Level

FP Type
Low
Avg
High
EI
EO
EQ
ILF
10
15
EIF
10
Functionality
Type
Complexity
FP
The management system will

store hardware and server activity
logs.
ILF
RETs - 2
DETs - 10
= LOW complexity
The management system will

store information of system users
and their activity throughout the
software.
ILF
RETs - 2
DETs - 15
= LOW complexity
The system will store information

regarding user accounts including
ID number, usage data and
ILF
RETs - 2
DETs - 12
= LOW complexity
permission levels.
The system will provide a user
interface allowing users to view
system logs and real time
information.
EQ
FTRs - 1
DETs - 10
= LOW complexity
The system will provide an

Administrator interface that allows
the creation, editing and deletion
of user accounts.
EI
FTRs - 1
DETs - 15
= LOW complexity
The system will store real time

ILF
RETs - 2
DETs - 20
= AVG complexity
10
The system will display real time

EQ
FTRs - 1
DETs - 20
= AVG complexity
The system will be able to

generate reminders and
notifications regarding the
inactivity of any servers and
applications.
EO
FTRs - 1
DETs - 20
= AVG complexity
The system will allow a user to

gain access through the use of an
ID number and password input.
EI
FTRs - 1
DETs - 15
= LOW complexity
The system will allow for

administrators to view all users
and respective access rights and
privileges in database format.
EQ
FTRs - 1
DETs - 12
= LOW complexity
The system will allow the user to

search, retrieve, and display
recorded logs.
EQ
FTRs - 1
DETs - 10
= LOW complexity
TOTAL
55
COCOMO II - Constructive Cost Model

Using the Cocomo II estimation software with a Total Function Point value of 55, assuming a
high Team Cohesion and high Team Experience results in the following distributions of staff and
effort-
Software Development (Elaboration and Construction)

Effort = 4.6 Person-months
Schedule = 6.1 Months
Total Equivalent Size = 2915 SLOC
Acquisition Phase Distribution
Phase
Effort (Personmonths)
Schedule
(Months)
Average Staff
Inception
0.3
0.8
0.4
Elaboration
1.1
2.3
0.5
Construction
3.5
3.8
0.9
Transition
0.6
0.8
0.7
Software Effort Distribution for RUP/MBASE (Person-Months)

Phase/Activity
Inception Elaboration
Construction
Transition
Management
0.0
0.1
0.4
0.1
Environment/CM
0.0
0.1
0.2
0.0
Requirements
0.1
0.2
0.3
0.0
Design
0.1
0.4
0.6
0.0
Implementation
0.0
0.1
1.2
0.1
Assessment
0.0
0.1
0.8
0.1
Deployment
0.0
0.0
0.1
0.2
The person month is the average productive (i.e. excluding sickness, courses, vacations, etc)
hours per month per person (full-time) for the organisation (usually about 140 hours).
These results indicate that the estimated time required to build this software would be just over
6 months which is above the timeframe of the project. This may mean that extra effort or
manpower is required to complete the software within an acceptable timeframe. To build this
application in the Java language will take an estimated 2915 lines of code, and most of the effort
and staff available will need to be distributed to the construction of the application.
At the end of each project phase, the estimations will be re-evaluated and updates will be made
if necessary. This will be completed by using the same technique used here with the same
metrics. This will determine if everyone involved in the project understands whether each point
of functionality will require more or less time, effort or resources to complete.
5 Schedule
Revision History
Date
Ver.
Author
Addition/Alteration
12/09/14
1.0
Francis Fernandez
Began Schedule, Gantt Chart
19/09/14
1.1
Francis Fernandez
Added network diagram, critical path
20/09/14
1.2
Francis Fernandez
Finalized schedule and diagrams
The project schedule is a detailed plan of major project phases, milestones, activities, tasks,
and the planned start and end date for each task, and the resources allocated to each task.
ID
Task Name
Start Date
Finish Date
Resources
1.
Planning of the Project
1.1.
Develop a Project Charter
28/07/14
04/08/14
PM, Core Team
1.1.1.
Define the Scope
28/07/14
31/07/14
PM, Core Team
1.1.2.
Define the Deliverable
28/07/14
31/07/14
PM, Core Team
1.1.3.
Define the Project Budget
28/07/14
04/08/14
PM
1.2.
07/08/14
14/08/14
PM
1.3.
Develop a Communication
Strategy
07/08/14
11/08/14
PM
1.4.
Finalize the Project Charter and

gain approvals
14/08/14
14/08/14
PM
2.
Analysis of the Project
2.1.
Develop Work Breakdown

Structure
18/08/14
21/08/14
PM
2.1.1.
Develop Staff Training Plan
18/08/14
21/08/14
PM
2.2.
Develop Risk Management Plan
18/08/14
21/08/14
PM
2.3.
Develop Project Schedule
25/08/14
28/08/14
PM
2.4.
Develop Change Management

Plan
25/08/14
28/08/14
PM
2.5.
Prepare Procurement Strategy
18/08/14
21/08/14
PM, Core Team
2.6.
Finalize all plans and gain

approval
01/09/14
01/09/14
PM
3.
Service Provider Selection
3.1.
Evaluation of Responses
04/09/14
22/09/14
PM, Core Team
3.2.
Negotiate and Award Contract
25/09/14
29/09/14
PM, Core Team
3.3.
Conduct Negotiation
02/10/14
02/10/14
PM
4.
Contract Management
4.1.
Contract Transition
06/10/14
16/10/14
External
4.2.
Manage Agency Performance
20/10/14
23/10/14
Review Team
5.
Maintenance of the Project
5.1.
Assess Service Provider
27/10/14
30/10/14
Review Team
6.
Closing of the Project
6.1.
Conduct Post Project Review
03/11/14
10/11/14
Review Team
6.2.
Celebrate
13/11/14
13/11/14
Gantt Chart
A Gantt Chart graphically represents a project by showing each task as a horizontal bar whose
length is the time needed to complete the task.
Network diagram
Below shows a simple network diagram for this project. The diagram shows the name of the task and its
estimated time of finish. Time estimates are shown in day(s). Please note that not all activities are
included on the diagram as most of it is very direct and linear. The red boxes and line displays the critical
path.
6 Change Management Plan

Revision History
Date
Ver.
Author
Addition/Alteration
19/09/2014
1.0
Lorenzo Lim
Started Configuration Items
23/09/2014
1.1
Lorenzo Lim
Continued Configuration Items and

started Configuration Management
System
25/09/2014
1.2
Kirk Roberts
Begun change management
26/09/2014
1.3
Lorenzo Lim
Finished Configuration Items and

Change Management System
26/09/2014
1.4
Kirk Roberts
Completed change management
10/10/2014
2.0
Kirk Roberts
Fixed changes to Change Control

Procedure and Audits and Review
6.1 Change Management

6.1.1 Change management approach
During the project we will be following a Change Life Cycle Framework to manage our changes.
This framework consists of five states, formulate change, plan change, implement change,
manage transition and sustain change. However, these steps are not required to be completed
in the order listed, they can be done when most convenient. The Change Lifecycle Framework
is the most appropriate approach to change management for our project as it is very thorough
and iterative, this process can be followed whether the change is as small as a change to the
documentation or as drastic as changing the system to a cloud based system.
The hierarchy of control for this project can be found below:
The ABC has two committees, the Audit and Risk Committee and the Finance Committee.
These committees oversee changes, provide a communication link between ABC executives,
senior management and auditors and monitor compliance with standards. These committees
have the ABCs best intentions at heart. The objective of the Audit and Risk Committee (which
can be found in their charter) includes The objective of the Committee is to provide
independent assistance to the ABC Board on the Corporations risk, control and compliance
framework, and its external accountability responsibilities.
If the project team or the ABC employees have a concern or opportunity for change they can
bring the change to the attention of the project manager (Lorenzo Lim). The project manager
would then seek the advice of the technical support engineers regarding the feasibility of the
change and the pros and cons. If the change impacts the project greatly then the change will be
presented to the appropriate committee for approval.
6.1.2 Change control procedure
Change Request
Submittal
When someone thinks a change should be made they should bring

it up with the project manager as they have the most knowledge of
the project. The project manager has technical knowledge,
business knowledge, project knowledge and also has access to
contact all stakeholders. A change request form will be submitted
when a change is requested. This form will be given to the project
manager.
Change Request
Tracking
Throughout the process, a changelog must be updated by the

project manager. This shows a list of changes, important dates,
what is impacted and whether or not the change has been
approved.
Change Request Review
When a change is suggested a change control meeting is held

with the project manager and the technical support engineers/
trainers, if they deem the change as necessary and the change is
big enough then the appropriate committee will presented with the
change request.
Change Request
Disposition
If the change is given a go ahead then the change log will be

updated and the change will be implemented. If the change will
result in downtime, the implementation will occur outside of
business hours. When possible the new change will be
implemented softly, therefore the new change and old change will
be running side-by-side if there is problems with the new change
there is a fallback. If the change impacts the scope, budget, project
plan or other important documentation then they will be updated.
New changes to these documents will be brought up to relevant
stakeholders at the next meeting or if it is important, immediately.
6.1.3 Audits and review

As mentioned in 1.3 Communication Strategy, the project manager (Lorenzo Lim) will be holding
weekly meetings with the project team to ensure the project progress is up to schedule. In these
meetings a number of topics will be discussed, such as: discussing issues, making proposals
and approving or rejecting offers. The project manager will check whether or not parts of the
project have been completed to the project plan and specifications, if something is not
completed to satisfaction it will be re-done. There will also be a group member recording
minutes so the information discussed in the meetings can be brought up at a later date. If a
change occurs then the change log will also be updated.
The Audit and Risk Committee and the Finance Committee review change requests regarding
the ABC, they weigh the positives and negatives of a change and make decisions with ABCs
best intentions.
6.2 Configuration Management

6.2.1 Configuration items
Configuration
Item
Baselines
Risk Register
The first version of this baseline(Version 1.0) was established during the
Risk Management portion of the module in the Project Management
Increment.
Would be re-baselined if new risks would appear or be discovered during
the project depending on the size of risk.
Budget
Project Estimation portion in the Project Management Increment.
If changes are made to the budget or there is a budget request then the
budget would need to be re-baselined.
Scope
Statement
Document
Scope Management portion in the Project Management Increment.
If key stakeholders decide and agree to make changes to the Scope, the
Scope Statement will be re-baselined.
Stakeholder
Register
Stakeholder Management portion in the Project Management Increment.
The stakeholder register will be re-baselined whenever there are changes to
stakeholders of the project.
Work
Breakdown
Structure
The Work Breakdown Structure will need to be re-baselined whenever there
are any changes that will affect the tasks that need to be completed.
Statement of
User
Requirements
Identify Objectives portion in the Project Management Increment.

The statement of the user requirements will need to be altered if any
features are added or removed and the deliverables have been altered.
Project
Schedule
The schedule will need to be re-baselined if there are any alterations to the
schedule, whether it was increased or decreased.
Project
Acceptance
Criteria
Project Closure portion in the Project Management Increment.
The Project Acceptance Criteria will need to be re-baseline when the scope
of the project would altered. The acceptance criteria for the project may also
be altered when the scope is altered.
Product
Requirement
Documentation
The first version of the product requirement documentation(Version 1.0) is

produced during the requirements portion during each Project Increment.
This document will need to be re-baselined if the product changed and the
requirements are different.
Product
Acceptance
Reports
Project Closure portion in the Project Management Increment.
The Project Acceptance Reports will need to be re-baselined if the scope of
the project would be altered. The acceptance criteria for the project may
also be altered if the scope should be altered.
Change Log
Change Management portion in the Project Management Increment.
The changelog would require to be re-baselined every time something
would be altered in the project or a change would be made.
Estimation
Document
Estimation portion in the Project Management Increment.
The document will need to be re-baselined if the estimation need to be
altered or modified
6.2.2 Configuration Management System
Figure 6.2.2.1
Figure 6.2.2.2
Configuration Control Board

In figure 6.2.2.1, it shows how the Configuration Control Board interacts with the Configuration
Management System. The Configuration Control Board is a group of stakeholders that are
responsible for evaluation and approving or disapproving proposed changes to the system.
This project will create a configuration management database software for tracking configuration
items and baselines. This database will store documents, code and and will include version
control.
A configuration control board (CCB) will be created and the members of the CCB will be
responsible for managing requested changes to the configuration baselines. The Configuration
Control Board will be active for the duration of this project and a meeting will be held every
fortnight to discuss alterations to the baseline that have been requested.
The Configuration Control Board will be comprised of key stakeholders and key project
members. They will be responsible for the following:
Discussing alterations and changes to the project and approving or disapproving said changes.
Prioritizing the incorporation of approved changes.
Scheduling the changes for forthcoming release.
As shown in the configuration item list, during an appropriate phase of the project the items are
baselined when they are first released. Once they have been baselined, requests to change
them will need to follow the correct CCB processes. The process for the CCB are the same as
for CAB (see figure 6.2.2.2), except they are specifically for the configuration items. If a
baseline change is successfully passed through CCB then the changes can be made. Likewise
if a baseline change request is denied, the requester could update their request and apply for
the next CCM meeting.
Re-baselining Configuration Items
When there is a change request for a configuration item, it is the obligation of the requestor to
action the change to the configuration item. This may be accomplished by the requestor or
another team member. The version number must be recorded in order to specify which version
was the original and the number will also keep track of all subsequent changes. The format of
the version number is as follows:
Alterations will be recorded in decimal increments: ie. 0.1,0.2 etc
When baselined, the item will be defined as 1.0
Subsequent alterations will be recorded as decimal increments:ie.1.1, 1.2
When re-baselined, the item will be defined as 2.0
The Version records will need to have the date and the person making the entry recorded. All
versions of the configuration items must be recorded in case a previous version needs to be
given to the project manager for reference at meetings.
7 Risk Management Plan

Revision History
Date
Ver.
Author
Addition/Alteration
10/10/14
1.0
Isaac Hoban
Began Risk Management Plan.
11/10/14
1.1
Isaac Hoban
Completed Risk Management Strategy.
12/10/14
1.2
Isaac Hoban
Completed Risk Monitoring Strategy.
13/10/14
1.3
Kirk Roberts
Began Risk Register.
14/10/14
1.4
Isaac Hoban
Added to Risk Register.
14/10/14
1.5
Kirk Roberts
Completed Risk Register.
7.1 Risk Management Strategy

The project sponsors and the project manager have expressed a high tolerance for the following
risk areas. All agree that steady progress toward the improvement of project management
practices is important and any delays that might be caused by challenges to the project or
project team are offset by a continued interest to make gradual improvements and a clear
objective for the project to be managed toward that end.
Risk Identification
There are a range of common issues that should always be considered within risk management
when attempting any project. Schedule and progress of a project often struggle and should
be checked at milestone achievement or major events. Resources and costs within the project
can cause issues with expenditure on people and materials. The nature of software functions
and structure of code, and changes to these can create issues to the growth and stability of a
project. Product quality, technical adequacy and development performance must also be
monitored for issues as the development process can vary in terms of efficiency and
performance.
These risks may affect the project in some way and will need to be identified and documented in
order to complete a successful project. Risks will be identified using the three techniques,
documentation review, information gathering and SWOT analysis, and then documented within
the risk register. To ensure that risks are identified throughout the project life cycle these
techniques may be used during each phase.
Documentation ReviewThe project planning documents created will be reviewed at the end of the planning phase, and
again after any subsequent updates or modifications are made. This will give the project team a
greater indicator of risk in the project, as the reviews will assess the quality and completeness of
the documentation.
Information GatheringThis technique will involve two sub-techniques, brainstorming and the Delphi technique.
Brainstorming will be used to help develop a comprehensive list of possible risks with the
assistance of many project team members. Brainstorming will occur early in the planning stage
of the project. This will allow a comprehensive initial list of risks to be produced before
development starts.
The Delphi technique is where ideas about project risk can be raised anonymously through
questionnaires. Once all functionality and requirements of the system are known and confirmed,
the Delphi technique will be used to source information from project team members once the
specific details of the project are known. This should allow for greater risk identification as team
members and stakeholders are able to comment on risks anonymously; this should result in
more truthful and critical analysis of the possible risks the project could face.
SWOT AnalysisThis technique will be performed after the Delphi technique, late in the planning phase, when
the specifics of the project are known. A group of team members will collaborate to identify the
strengths, weaknesses, opportunities and threats of the project. Using this information, steps
will be taken to ensure the strengths are retained and the opportunities are exploited.
Risk Classification
Risk TaxonomyRisks will be categorised into the following different categories that reflect what type of risk they
are, and help identify the people and resources required to solve said risk.
Usability- risks involving the end user experience of software provided.
Technical- risks that could affect the hardware or the integration of hardware.
Functional- risks that could affect management software provided.
Financial- risks caused by, or that affect project costs and budgeting.
Organisational- risks caused by, or that affect project stakeholders.
Management- risks propagated by time management, or lack thereof.
Market- risks regarding the supply of project hardware and software.
Other- unknown risks that may appear during the project.
Qualitative Risk AnalysisOnce risks have been placed into the risk register under their respective risk categories, as
outlined above, qualitative risk analysis is performed to further differentiate, classify and assign
values to each risk in the register. In order to perform qualitative risk analysis the risk probability
and impact assessment method is used in order to determine the priority in which to allocate
resources to mitigate risks, assesses the probability of occurrence, impact, time-frame, and the
causes and interrelationships of risks. The risk impact matrix is then used to visually display and
analyse risk information as shown in the example below. Risks will be classified according to
this scale.
Risk Impact Matrix

Quantitative Risk AnalysisIf the project manager is not fully satisfied with the results of qualitative risk analysis, then they
will elect that quantitative risk analysis is also performed. However, as this project is not overly
complex or using cutting edge technologies, and several techniques are used in qualitative
analysis, quantitative risk analysis should not be required. To perform quantitative risk analysis,
if required, the methods of data gathering and representation techniques are undertaken, which
uses interviewing to assess experience and historical data, will be used to quantify risk
decisions.
Addressing Risks
Once risks have been identified and classified in the risk register, plans will be developed to
address, mitigate and manage them. Risks will either be mitigated, accepted, or avoided
entirely. The avoidance strategy eliminates the possible deviation by changing the project
deliverables against which the deviation is defined. The mitigation strategy sets out to alter the
likelihood or the impact of the risk. The acceptance strategy merely acknowledges the risk, but
does not specify any action to take in response to the risk.
Techniques that will be used to address risks include strategies for negative risks or threats,
strategies for positive risks or threats, and contingent response strategies. Negative risks are
those that hinder the project and its objectives. Negative risks will either be avoided, mitigated
or accepted. Positive risks are those that are beneficial to the projects objectives. Acceptance
can also be used as a method in this technique.
In the event that a risk cannot be prevented there are response strategies that are developed for
specific risks and situations, and as contingency or fall-back plans. The risks under this
technique are carefully tracked and monitored, and the strategies are only executed under
specific pre-defined conditions.
The risk manager role is assigned to the project manager, who is responsible for evaluating and
adjusting the risk register periodically, monitoring the project and recognizing the occurrence of
factors that result in realized risks. They must also track and facilitate the timely response to
realized risks, communicate realized risks to the project team and report risk management
activity according to communications plan.
The risk response decision makers role is assigned to the project sponsors, who are
responsible for approval of responses to realized risks and requesting further evaluation if
insufficient information is available to support the decision.
7.2 Risk Monitoring Strategy

The project will use software management practices to monitor and track risks which comprises
of risk assessment, review and scheduling.
Risk Assessment
The project team will assess risks with a variety of techniques which monitor and track activities
for risk. Some of these activities include performing qualitative and quantitative risk analysis and
the creation of a probability/impact matrix.
When performing qualitative risk analysis, identified risks are ranked on their probability of
occurring and potential impact on the project and then updated in the risk register. Qualitative
risk analysis occurs at the beginning of every phase, however the Project Manager may initiate
qualitative risk analysis at any time throughout the life of the project. By monitoring and tracking
risks in this way the project will benefit from improved risk assessment and control.
Risk Review
To ensure that risks are kept current and relevant to the project, the risk owner is responsible for
reviewing risks identified in the risk register through a variety of tools and techniques. Some of
these techniques has been previously mentioned with quantitative risk analysis and qualitative
risk analysis, however other techniques include:
Top Ten Risk Item TrackingThe top ten risk item tracking is a tool that is derived from the output of qualitative risk analysis.
Top ten risk item tracking is reviewed any time there is a change to any risk on this list. This tool
is used to identify the ten top risks which are then placed on a list which aid in the monitoring
and tracking of risks. It is also used as an awareness tool for the risk owner which can then be
used to update stakeholders throughout the life of the project.
Identify New Risks / Retire old RisksOnce a week the project manager will call a meeting with the project team giving them the
opportunity to identify any new risks to the project. During this meeting old risks are reviewed
and retired if no longer relevant.
Risk Scheduling
Scheduling the review of risk monitoring activities is important in any project so that risks are
kept current and risk responses are relevant. Below is a table that outlines previously discussed
monitored risk activities and their frequency.
Qualitative risk analysis is applied at the beginning of each phase or when the Project Manager
deems it to be necessary. The probability/impact matrix can be used any time a new risk is
identified or an old risk changes, and quantitative risk analysis is required when more
clarification is needed on identified risks.
7.3 Risk Register

ID
Event
or Risk
Classificati
on
Positive
or
Negative
Probabilit Consequ Impact Preventative

y
ence
steps
Response
R1
Develop
ment/Har
dware
late
Management
Negative
Moderate
Major
High
MitigationBetter
scheduling
Adjust
schedule,
communicate
with project
sponsor
R2
Over
budget
Financial
Negative
Moderate
Major
High
AvoidanceUpdate budget
When a
change is
made update
the budget
immediately
R3
Over
time
frame
Management
Negative
Moderate
Major
High
AvoidanceMeet
deadlines
Update gantt
chart and
meet
deadlines
Technical
Negative
Likely
Moderate
Signific
ant
MitigationFollow
manuals and
seek help
A subject
matter expert
may assist
with complex
problems
Market
Negative
Unlikely
Moderate
Modera
te
AvoidanceFind new
supplier
Try to fix the

problem with
the supplier or
seek a new
supplier
R4
Hardwar
e does
not work
R5
Hardwar
e does
not meet
needs
R6
Technical
Negative
Rare
Major
Signific
ant
MitigationPurchas latest
hardware and
software
Make sure
hardware and
software
current with
the times
before
purchasing
Technical
change
impacts
project
(Innovati
on)
R7
Does not
meet
scope
Management
Negative
Moderate
Catastrop
hic
High
AvoidancePlanning
Ensure
scope is
defined
specifically,
what will and
will not be
completed.
R8
Integratio
n is not
smooth
Technical
Negative
Likely
Moderate
Signific
ant
MitigationChose an
appropriate
time to
implement
system
Integrate
system when
not in office
hours to
create least
amount of
downtime.
R9
System
has
security
vulnerabi
lities
Technical
Negative
Moderate
Major
High
MitigationFollow safety
Follow security practices for
guidelines
both physical
and electronic
systems
R10
Users
are not
trained to
use
system
Usability
Negative
Almost
Certain
Moderate
High
AcceptanceStaff must be
trained to use
the system
Have training
for staff and
keep manuals
easily
accessible
R11
Commun
ication
problems
between
stakehol
ders
Organisationa
l
Negative
Moderate
Moderate
Signific
ant
MitigationHold regular
meetings with
stakeholders
Encourage
stakeholders
to voice their
opinions
during
meetings
R12
Stakehol
ders stop
supportin
Negative
Unlikely
Catastrop
hic
High
AcceptanceSpeak with the

stakeholders
Address
stakeholders
concerns
Organisationa
l
g the
project
R13
A lot of
changes
occur
Organisationa
l
Positive/N
egative
Moderate
Minor
Modera
te
AcceptanceChange can
be good
Follow
change
management
protocol
R14
System
becomes
broken/
unusable
Other
Negative
Unlikely
Catastrop
hic
High
MitigationEnsure
enough time is
allocated for
system
integration
testing.
Implement
previously
working
iteration of
system and
investigate
where
problems
have
occurred.
R15
Users
dont
engage
with the
manage
ment
software.
Usability
Negative
Unlikely
Major
Signific
ant
MitigationPrior to
release ensure
all users are
kept informed
of the project
and trial user
tests.
Provide
questionnaire
s for user
feedback, and
act upon that
feedback to
improve
system.
R16
Administr
ator does
not
engage
with the
manage
ment
system.
Usability
Negative
Unlikely
Major
Signific
ant
AvoidanceProvide more
Ensure
training.
training is
provided to the
administrator/s
prior to roll
out.
R17
The
successf
ul project
plan
could be
used as
a
template
Other
Positive
Moderate
Moderate
Signific
ant
AcceptanceEnsure project
plan is
followed 100%
and system is
implemented
without any
major issues.
Mitigate any
shortcomings
as much as
possible
for other
server
projects.
R18
Failure to Market
adequate
ly
address
enquiries
from
tenderers
Negative
Moderate
Major
Signific
ant
MitigationImplement
standardised
procedures for
responding
to enquiries
Provide staff
with
appropriate
tender
management
training and
experience
R19
No
response
from
known
quality
suppliers
Market
Negative
Unlikely
Moderate
Modera
te
MitigationEnsure
accurate
tender
documentation
and
specifications
and allow
sufficient time
for
tenderers to
respond
Improve
market
knowledge.
Review
specifications
or
conditions
R20
Loss or
damage
to goods
in transit
Other
Negative
Unlikely
Major
Signific
ant
MitigationInclude
appropriate
packaging
instructions in
specification.
Agree on
insurance
cover
for supplier to
provide
Accept
delivery only
after
inspection.
Know when
title of goods
is
transferred to
buyer.
8.0 Project Review

Revision History
Date
Ver.
Author
Addition/Alteration
16/10/14
1.0
Isaac Hoban
Began Project Review.
16/10/14
1.1
Isaac Hoban
Added project review criteria.
18/10/14
1.2
Kirk Roberts
Finalised project review.
18/10/14
1.3
Lorenzo Lim
18/10/14
1.4
Isaac Hoban
18/10/14
1.5
Francis Fernandez
8.1 Success criteria

Before we began any of the workbooks we decided upon some goals to achieve as a
group, the goals are as follows:
Workload - We will aim to try and split the amount of work evenly between all
group members, to ensure we all get the mark we want.
Due date - We will aim to have everyone's sections completed five hours before
the due date incase of any technical problems with the upload.
Quality - We will aim to create the best possible workbook we can, this can be done
by asking group members for help when you have a problem.
Meetings - We will try to make time to meet up on campus when possible.
Catch-up - If a group member misses a workshop we will fill them in if they missed
something important.
By following the above criteria we should produce a good workbook, gain knowledge
and understanding and recieve a good grade.
8.2 Project Achievements

Workload - The workload required to complete the project sections has been split
evenly among team members, which is attested to by the Time Sheets shown in
section 9.3. Each member has attributed over fifteen hours of project work, with
some increasing due to some tasks requiring changes or a higher workload, in which
multiple members worked on to alleviate overload.
Due date - All sections were completed before or on the due date set according to
the Task List in Section 9.2. Some sections were over the estimated time required,
but proper scheduling helped avoid non-submittal.
Quality - The workbook content has been accurate owing to the original feedback
given during Audit 1. The project was given a score of 77%. Points were taken off in
areas of stakeholder analysis and deliverables, but all inaccurate content was
worked on until positive feedback was received. Audit 2 gave a score of 81% and
previous inaccuracies were marked as rectified showing an improvment in quality.
Meetings - A weekly meeting was held every week after the project management
workshop to discuss new work and any problems each team member had. This
helped solve many issues that arose throughout the project.
Catch-up - The group came together via phone, email or in person to discuss all
aspects of the project when any member was unable to attend a group meeting or
workshop to ensure a complete group learning experience throughout the project.
8.3 Schedule reporting

Section 1- Project Charter
The section was required to be completed by the whole group as it consisted mainly
of defining information about the charter. It was also a core component that needed
to be finished in order to continue with the next section. We estimated this section
would take us 20 hours, and would need to be completed by week 5. In reality it
took us 21 hours, and was completed by week 5.
Section 2- Project Scope
This section was completed by Isaac and Kirk. We estimated that it would take us 10
hours to complete. However it only took us 6 hours to complete and a further 2
hours to fix up at a later date. This section was fairly straightforward and simple
which is why it was completed quickly.
Section 3- Work Breakdown Structure
This section was completed by Francis. It was planned in the beginning that total
work on the work breakdown structure will take approximately 8 hours. Readings
from the online workbook and samples provided by the class instructor has made
this section fairly easy to accomplish. Finishing an hour early from planned deadline,
this extra hour was used to further study for the next step on the project which is
Schedule.
Section 4- Schedule
This section was completed by Francis. Preparation for this section was initially
planned to take around 7 hours to complete. Even after having the required inputs
such Work Breakdown Structure, Scope Analysis and an extra hour slack time from
the preceding task, this section took 9 hours to finish. Time was wasted in
presenting the Gantt chart using a third-party, open-license program the Gantt
Project. The program provides same services like Microsoft Project. Time was
needed to understand its use and training for this program was not planned initially.
Section 5- Estimation
This section was completed by Isaac. It was estimated that it would take 10 hours to
complete. However it only took 7 hours to complete with the help of the Cocomo II
software, and a further 3 hours to edit at a later date for better accuracy. This
section was straightforward once a software system plan was developed and was
completed well within the time limit.
Section 6- Change Management
This section was completed by Kirk and Lorenzo. We estimated it would take roughly
10-15 hours to complete. After working on this section for a couple of hours, it was
roughly estimated that in total it took 12 hours to complete. We completed this
section rather easily with a little research and information from the workshop.
Section 7- Risk Management
This section was completed by Isaac and Kirk. This section was estimated to take
10-15 hours. It actually took us 11 hours. Which is right between what we thought it
would take.
8.4 Review of Techniques

Technique
Evaluation
Google Docs
Great for group work, allows for all group members to edit in realtime and saves to the cloud (Google Drive).
Face-to-face
A lot easier to discuss the project however not always easy to

schedule a time to meet, especially with people working and
other classes. We found that the best time to meet was directly
after our workshop on Monday.
Text
messages
Instant form of communication, more and more people are getting

unlimited texts recently. However text messages are only personto-person and not group. Group text messages exist however are
fairly costly.
Phone call
Phone calls were very useful when trying to locate each other
when meeting on campus for group meetings.
Email
Email was used to send copies of feedback and relevant

information to one another. This was great because you can
attach files to the emails and emails are very widely used by
many people and is very convenient.
8.5 Lessons Learned

Software Development Life Cycle is the process of planning, creating, testing
and developing a system. SDLCs are a great way to plan the path of a project.
Some notable SDLCs include (Waterfall, Agile, Spiral, V-Shaped and Prototyping.
Budget We used the PERT estimate it was useful and helped us represent the
project cost greatly it is also very easy to understand.
Onion Diagram, great for visually categorising stakeholders into groups. Shows
dependencies among stakeholders. Each outer ring depends on its inner rings.
Identify Deliverables, we identified deliverable by listing them in a table.
However we lacked a table to identify who the deliverables were intended for. This
was changed in the next submission.
WBS table displays detailed list of all the things that need to be delivered and
activities to be carried out to complete the project. It helped visualise all activities
and each dependencies.
Function point counting makes for an easy way to categorise the work needed to
complete a software project. With the use of the Cocomo II estimation software it
can also be a great way to graphically display timelines and workloads, and makes
the software development process much easier to understand.
Network Diagram is a tool that charts the flow of activity between separate tasks.
It graphically displays interdependent relationships between groups, tasks and steps
as they all impact the project. This technique helped recognize tasks that are
interdependent to other tasks. It assisted in getting a more accurate Critical Path
Analysis.
Critical Path Analysis is a widely-used project management technique for
scheduling projects. The most useful benefit in using CPA is that it helped me
identify the minimum or least time to complete the project.
Change management explains how the project configuration management can
handle certain changes. Baselines are established at the beginning of the project
and with every change to the project, the initial baseline will be re-baselined
creating new versions. This part of the workbook helped me better understand how
change is handled in a project.
Risk management brings attention to any problems that could have a major
impact on the project in an easily displayed, updateable process, making it very
necessary for any project.
9.0 Project Management

9.1 Status Summary
The team has worked well together, each section was split between members evenly,
ensuring an equal amount of work and, by extension, the time spent in order to
complete that work. All sections have been completed satisfactorily. Multiple meetings
were held to discuss what needed to be done and by when those tasks should be
accomplished. Team members supported other members with their section when they
struggled to come up with ideas or complete on time. Overall this project has been
successful due to the effort put in by each individual member of our team.
9.2 Task List

Task
Allocated
to
Due Date
Status
Comments (include
who finished task, date
complete)
Business
experience and
project
description
written.
Lorenzo Lim
28/7/2014
Complete
Completed by assignee on
28/7/2014
Project
objectives,
success criteria
and project
approach listed.
Isaac Hoban
4/8/2014
Complete
4/8/2014
11/8/2014
Complete
11/8/2014
Identify Primary
Kirk Roberts
stakeholders and
complete Onion
Diagram.
Calculate budget
estimate.
Lorenzo Lim
11/8/2014
Complete
11/8/2014
Design
stakeholder
analysis and
communication
strategy
Francis
Fernandez
15/08/14
Complete
15/08/14
Complete
stakeholder
analysis.
Kirk Roberts
18/08/14
Complete
18/08/14
Complete
communication
strategy and
stakeholder
influence grid.
Isaac Hoban
18/08/14
Complete
18/08/14
Complete scope
description.
Isaac Hoban
20/08/14
Complete
20/08/14
Complete
deliverables
table.
Kirk Roberts
21/08/14
Complete
21/08/14
Begin work
breakdown
structure tree.
Francis
Fernandez
22/08/14
Complete
22/08/14
Complete work
breakdown
structure tree.
Francis
Fernandez
25/08/14
Complete
25/08/14
Complete work
breakdown
structure table.
Francis
Fernandez
26/08/14
Complete
26/08/14
Edit stakeholder
analysis.
Isaac Hoban
12/09/14
Complete
12/09/14
Edit
Isaac Hoban
13/09/14
Complete
communication
strategy.
13/09/14
Edit scope
description.
Isaac Hoban
14/09/14
Complete
14/09/14
Edit product
deliverables.
Kirk Roberts
15/09/14
Complete
15/09/14
Begin project
estimation.
Isaac Hoban
15/09/14
Complete
15/09/14
Complete project Isaac Hoban

estimation.
19/09/14
Complete
19/09/14
Begin Schedule
Francis
and Gantt Chart Fernandez
19/09/14
Complete
19/09/2014
Add network
diagram and
critical path
Francis
Fernandez
19/09/14
Complete
19/09/2014
Complete
schedule and
diagrams
Francis
Fernandez
20/09/14
Complete
20/09/2014
Start
Configuration
Items
Lorenzo Lim
20/09/2014
Complete
20/09/2014
Continue
Configuration
Items and start
Configuration
Management
System
Lorenzo Lim
23/09/2014
Complete
23/09/2014
Begin change
management
Kirk Roberts
25/09/2014
Complete
25/09/2014
Complete
Configuration
Items and
Change
Management
System
Lorenzo Lim
26/09/2014
Complete
26/09/2014
Complete
Kirk Roberts
26/09/2014
Complete
change
management
26/09/2014
Edited technique Isaac Hoban

and justification.
10/10/14
Complete
10/10/14
Added
complexity level
tables.
10/10/14
Complete
10/10/14
Fixed changes to Kirk Roberts

Change Control
Procedure and
Audits and
Review
10/10/14
Complete
10/10/14
Began Risk
Management
Plan.
Isaac Hoban
10/10/14
Complete
10/10/14
Completed Risk
Management
Strategy.
Isaac Hoban
11/10/14
Complete
11/10/14
Completed Risk
Monitoring
Strategy.
Isaac Hoban
12/10/14
Complete
12/10/14
Began Risk
Register.
Kirk Roberts
13/10/14
Complete
13/10/14
Added to Risk
Register.
Isaac Hoban
14/10/14
Complete
14/10/14
Completed Risk
Register.
Kirk Roberts
14/10/14
Complete
14/10/14
Began Project
Review.
Isaac Hoban
16/10/14
Complete
16/10/14
Added project
review criteria.
Isaac Hoban
16/10/14
Complete
16/10/14
Finalised project Kirk Roberts

review.
18/10/14
Complete
18/10/14
Finalised project Lorenzo Lim

review.
18/10/14
Complete
18/10/14
Isaac Hoban
Finalised project Isaac Hoban

review.
18/10/14
Complete
18/10/14
Finalised project Francis

review.
Fernandez
18/10/14
Complete
18/10/14
9.3 Time Sheets

Name: Kirk Roberts
Date
Time spent
Task
11/08/14
3 Hours
Identified Primary stakeholders and

completed Onion Diagram.
18/08/14
2 Hours
Completed stakeholder analysis.
21/08/14
2 Hours
Completed deliverables table.
25/09/14
2 Hours
Updated deliverables table.
26/09/14
7 Hours
Completed change management.
10/10/2014 1 Hour
Fixed changes to Change Control

Procedure and Audits and Review
13/10/14
2 Hours
Began Risk Register.
14/10/14
2 Hours
Completed Risk Register.
18/10/14
3 Hours
Comments
Added for column
Name: Isaac Hoban

Date
Time spent
Task
4/8/2014
2 Hour
Completed project objectives,

success criteria and project
approach.
18/08/14
3 Hours
Completed communication strategy

and completed stakeholder influence
grid.
20/08/14
2 Hours
Completed scope description.
12/09/14
2 Hour
Edited stakeholder analysis.
Comments
Added influence and
interest columns.
13/09/14
1 Hour
Edited communication strategy.
Added further method

information.
14/09/14
2 Hours
Edited scope description.
Added more functional

requirements.
15/09/14
3 Hours
Began project estimation.
19/09/14
4 Hours
Completed project estimation.
10/10/14
2 Hours
Edited estimation.
10/10/14
1 Hour
Added complexity level tables.
10/10/14
1 Hour
Began Risk Management Plan.
11/10/14
4 Hours
Completed Risk Management

Strategy.
12/10/14
3 Hours
Completed Risk Monitoring Strategy.
14/10/14
1 Hour
Edited Risk Register.
16/10/14
1 Hour
Began Project Review.
16/10/14
1 Hour
Added project review criteria.
18/10/14
1 Hour
Edited technique and

justification.
Added Risks.
Name: Lorenzo Lim

Date
Time spent
Task
11/8/2014
2 Hours
Completed business experience

and project description.
14/8/2014
2 Hours
Researching hardware prices and

comparing options.
19/8/2014
3 Hours
Completing project budget. Started

Configuration Items
16/09/2014
2 Hours
Researched necessary approaches

and started configuration
Comments
management.
23/09/2014
2 Hours
Continued Configuration Items and

started Configuration Management
System.
26/09/2014
3 Hours
Completed Change Management

Plan, Configuration Items and
Configuration Management
System.
18/10/14
2 Hours
18/10/14
4 Hours
Finalised 8.5 lessons learned.
Name: Francis Fernandez

Date
Time spent
Task
22/08/14
2 Hours
Began wbs tree
25/08/14
3 Hours
Completed work breakdown

structure tree
26/08/14
2 Hours
Completed work breakdown

structure table
19/09/14
3 hours
Began schedule and Gantt chart
19/09/14
3 hours
Added network diagram and critical

path
20/09/14
3 hours
Completed Scheduling section
18/10/14
3 hours
Comments

Projectmanagement 2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Projectmanagement 2

Uploaded by

Copyright:

Available Formats

2001ICT Project Management

School of Information & Communication

Completed business experience, project

Completed project objectives, success

Identified Primary stakeholders and

Completed budget estimate.

Began stakeholder analysis and

Completed stakeholder analysis.

Completed communication strategy and

Edited stakeholder analysis.

Edited communication strategy.

1.1 Company Information

Project Objectives and Success criteria:

All functional and

Project completed within

Blade Server Slots

Cisco Network Switches

Brocade 8GB SAN Switches

Full redundancy for all enclosure components

Total cost for configuration 1:

(24,000 + 4 x 28,048 + 50,000)

1.2 Stakeholder Analysis

Very High - The

Very High - Project

Very High - Project

Very High - The

Very High - The

News/Televisio Moderate - The

Very High Interested in the

Very High - All Critical

Very High Interested in the

1.3 Communication Strategy

Email & Phone

Email & Phone

Stakeholder Influence/Impact Grid

2 Project Scope Statement

Completed scope description.

Completed deliverables table.

Edited scope description.

Edited product deliverables.

2.1 Product Scope Description

The system hardware management

The management system will store

The management system will store

The system will store information

The system will provide a user

system logs and real time

The system will provide an

The system will store real time

The system will display real time

The system will be able to generate

The system will allow a user to gain

The system will allow for

The system will allow the user to

The system with interface with Server

The system will run on an industry standard

The system will integrate with industry standard

The system will run and continuously operate

The system will be able to be patched for

The system will use data formats such as

The system will use rich Application

The system will run on industry standard