Responsetotenderv 3

Project Management Assignment
Response to CrimTrac Tender

Lecturer: Dr Leigh-Ellen Potter
Project Manager: Brenton Millers
Group Members: Benjamin Ivarsson, David Ley,
Samantha OSullivan.
Ace System Solutions Response to CrimTrac Tender V3.0 2015
Page 1
Table of Contents
Table of Contents
1. Project Charter
1.1 Company Information
1.1.2 Project Description
1.1.3 Project Objectives and Success Criteria
Scope
Time
Budget
1.1.4 Approach
1.1.5 Primary Stakeholders:
1.1.6 Start and Finish
1.1.7 Budget
1.2 Stakeholder Analysis
1.3 Communication Strategy
1.3.1 Managing and Resolving Breakdowns in Communication
1.3.2 Team Communication Strategies
1.3.3 Communicating Amongst A Distributed Team
2. Project Scope Statement
2.1 Project Justification
2.2 Product Scope Description
2.2.1 Hardware Requirements
2.2.2 Software Requirements
2.2.3 Quality Requirements
2.2.4 Integration Requirements
2.2.5 Support Requirements
2.2.6 Vendor Compliance Requirements
2.2.7 Documentation Requirements
2.3 Product Deliverables
2.3.1 Hardware Deliverables
2.3.2 Software Deliverables
2.3.3 Documentation Deliverables
2.3.4 Services Deliverables
2.3.5 Project Management Deliverables
3. Work Breakdown Structure
3.1 WBS Tree
3.2 WBS Table
4. Estimation
4.1 Choice of Technique
4.2 Justification
4.2.1 Function Point Counting
Page 2
4.2.2 Function Point Adjustment

4.2.3 Industry Data
4.2.4 Three Point Estimating
4.3 Estimation
4.3.1 Software and Firmware Estimation
4.3.1.1 Hardware Procurement
Budget (for scanners)
4.3.2 Software Estimation
4.3.1.1 NAFIS Replacement System
4.3.1.2 Software Function Point Counting
4.3.1.3 Value Adjustment Factor
4.3.1.4 Function Point Adjustment
4.3.1.5 Converting Function Points to Meaningful Metrics
5. Schedule
6 Budget & Procurement
6.1 Budget
6.1.1 Planned Budget
6.1.1.1 Hardware Budget
6.1.1.2 Software Budget
6.1.1.3 Miscellaneous Budget
6.1.1.4 Installation Budget
6.1.1.5 Training Budget
6.1.1.6 Project Management and Support Team
6.1.2 Cost Management
6.1.2.6 Project Management and Support Team Budget
6.1.2.7 Overall Project Budget
6.1.2.8 Budget Estimation
6.1.2.9 Changes to the Budget
6.1.2.10 Expenditure Reports and Cost Tracking
6.1.2.11 Managing Cost Variances
6.1.2.12 Cost Control
6.1.2.13 Work Performance Information
6.1.2.14 Cost Forecasts
6.2 Procurement
6.2.1 Planned Procurements
Hardware Procurement
Software Procurement
Contracted Work
6.3 Procurement Management
Page 3
6.3.1 Establishing Procurement

6.3.2 Managing Procurement
6.3.3 Finalizing Procurement
7. Change Control Plan
7.1 Change Control
7.1.1 Change Control approach
7.1.2 Change control procedure
7.1.3 Audits and review
7.2 Configuration Management
7.2.1 Configuration items
7.2.2 Configuration Management System
Change Control Board (CCB)
Configuration Control
The Configuration Management Database (CMDB)
Verification and Audits
8. Risk Management Plan
8.1 Risk Management Strategy
8.1.1 Risk Identification
8.1.2 Risk Classification
8.1.2.1 Risk Taxonomy
8.1.2.2 Qualitive Risk Analysis
8.1.2.3 Quantitative Risk Analysis
8.1.3 Addressing Risk
8.1.4 Unidentified Risks
8.2 Risk Monitoring Strategy
8.2.1 Risk Assessment
8.2.2 Risk Review
8.2.3 Top 10 Risks
8.2.4 Risk Management Review
8.2.5 Identification of New Risks/Retirement of Old Risks
8.2.6 Risk Scheduling
8.3 Risk Register
9.0 Project Review
9.1 Success Criteria
9.2 Project Achievements
Workbook 1
Workbook 2
Workbook 3
9.3 Schedule reporting
9.4 Review of Techniques
9.5 Lessons Learned
10.0 Project Management
10.1 Status Summary
10.1.1 Workbook 1
Page 4
10.1.2 Workbook 2
10.1.3 Workbook 3
10.2 Task List
Submission 1
Submission 2
Submission 3
10.3 TimeSheets
11. Appendixes
11.1 Appendix A - Sample Change Request Form
PROJECT CHANGE REQUEST FORM
1. PROJECT DETAILS
Name of Project
Project Identification #
Page 5
1. Project Charter
Revision History
Date
Ver.
Author
Addition/Alteration
10/08/2015
1.1
All
Group was established, the document template was set up, sections
1.1 was worked on as a group outlining what roughly went on under
each heading and the SDLC was chosen.
12/08/2015
1.1
All
Met up and discussed and read through entirety of current document,

updating as required.
14/08/2015
1.1
All
Company Information was written by all of us.
14/08/2015
1.1
David Ley
Approach
14/08/2015
1.1
Samantha OSullivan
Started work on the stakeholders table
14/08/2015
1.1
Brenton Millers
Started working on the budget outline.
14/08/2015
1.1
Samantha OSullivan
Stakeholder Analysis
14/08/2015
1.1
David Ley
Finished Approach
14/08/2015
1.1
Samantha OSullivan
1.1.5 -1.3 Managing and Resolving Breakdowns in Communication and

Team Strategies.
16/08/2015
1.1
Benjamin Ivarsson
Further elaborated on the Company Information / added affiliates and

other solutions provided. Section 1.1
16/08/2015
1.1
Benjamin Ivarsson
Continued working on section 1.1.2-1.1.5
17/08/2015
1.1
David Ley
Sketched out some ideas for Risk Assessment
19/08/2015
1.1
David Ley
Started work on Communications Strategy Table
24/08/2015
1.1
David Ley
Continued work on Communications Strategy Table
26/08/2015
1.1
All
Worked on budget and reviewed document so far
27/08/2015
1.1
Samantha OSullivan
Worked on Stakeholder Analysis
28/08/2015
1.1
Samantha OSullivan
Worked on Communication Strategy
28/08/2015
1.2
Benjamin Ivarsson
Rewrote and aligned document with marking criterias. Updated Key

Stakeholder Table for clarity and detail
Project objectives & success criteria
29/08/2015
1.2
David Ley
Finished Communications Strategy Table
29/08/2015
1.2
Samantha OSullivan
Stakeholder Analysis and Communication Strategy
30/08/2015
1.3
Benjamin Ivarsson
Worked latenight/day on final submission document. Touched up to
Page 6
match document standards. Sections 1-3.

In response to comments from Lewis Carter: All of the entire
document. Revision before workbook 1 submission.
30/08/2015
1.3
Brenton Millers
Updated budget, start and finish dates.
30/08/2015
1.3
Samantha OSullivan
Updated budget and finished any work.
30/08/2015
1.3
David Ley
Added Draft WBS Tree and Filled out Table
25/09/2015
2.1
Benjamin Ivarsson
Revised section 1.1.4 (Approach) to define an incremental approach

with waterfall increments.
Revised section 1.1.3 and 1.1.6
1.1 Company Information

Project Title: Response to CrimTrac Biometrics Tender.
Project Manager: Brenton Millers.
Team Members: Benjamin Ivarsson, David Ley, Brenton Millers, Samantha OSullivan.
Company Name: Ace System Solutions.
Business Experience: Ace Systems Solutions (ASS) was established in 1999 and originally
developed security solutions for small businesses. In the past 5 years, ASS has expanded
globally, with offices in Beijing, Los Angeles, Oslo and Brisbane, and become a leader within the
biometric identification and security industry.
Ace System Solutions have recently been involved in following projects:
Implementation of OrgSys at Griffith University in 2015
Implementation of Door Identification Systems for Ecophon AB, Sweden 2014
Implementation of Retinal Scanning Software for Kemira 2010
Other solutions provided:
Secure solutions of data storage
Door entry systems
Biometric logarithms
Encryption/Decryption of data
Affiliates:
Project Management Institute (PMI)
Project Management Alliance Company (PMA)
Griffith University (GU)
Page 7
1.1.2 Project Description

The government executive agency CrimTrac has requested tenders for the supplying of new
biometric identification services which may be used across partnered national policing agencies.
CrimTrac currently has a National Automated Fingerprint Identification System (NAFIS) in place
which consolidates all state, territory and Commonwealth fingerprinting capabilities into one
national system. The system itself currently supports fingerprint and palm print comparison and
matching within their current database.
In the requested tender, CrimTrac requires responding tenderers to provide a Biometric
Identification solution for fingerprint (including palm print and foot print), Facial recognition,
matching and identification. This is to be attached with individual projected cost estimates for
each function implemented. The software should also allow the capability to expand into future
additional Biometric Modes over time. Implemented system will either modify current NAFIS
system used by CrimTrac, or replace the current system.
The system needs to support mobile solutions, such as handheld biometric scanners. System
also needs to allow additional source data to be added from new information providers. The
system implemented will have to be able to store up to 12 million facial images from within
CrimTracs database.
Additionally, the responding tenderer is to provide a biometric identification and comparison
algorithm which could be implemented into CrimTracs current system (NAFIS); the algorithm
used in the software should be compliant with international standards of Biometric Data, and
falls under Commonwealth Law, and be able to compare and match Facial Images, Fingerprint,
Footprint and Palm Print from the CrimTrac database.
Responding tenderer does not have to provide servers, database storage or network
environments.
Page 8
1.1.3 Project Objectives and Success Criteria

In response to CrimTrac Tender RFT 2A, Ace System Solutions identified a set of key
deliverables for the projected tender as follows:
A system solution for Fingerprint, Palm Print and Foot Print identification, with Individual
estimated cost for each identification mode
A system solution for Facial Recognition used for identification, with Individual estimated
cost
A combined budget assessment for both deliverable parts
To develop a system which is fully modular for future system additions which can
replace current NAFIS system used by Australian Law Enforcement Agencies
To follow all rules, laws and standards set by Government agencies (under the
obligations of IGA for Biometric Requirements)
Continues to deliver benefits and increases value of current NAFIS standard
Meets the requirements of CrimTrac Strategic Plan (CrimTrac ICT Blueprint) for National
Police Information Sharing (2014/2018); Current set standards for sharing of Biometric
Data
With this project, ASS is developing a BioMetrics System which can replace current NAFIS
system used by Law Enforcement Agencies nationally.
If the responding tenderer is to succeed they must provide the following:
Scope
Project Objectives
Success Criteria
Approved by
Deliver a standalone or NAFIS integrated

system for finger-, palm- and footprint
identification and matching.
The system has to be able to access and

read/write to CrimTracs current or future
databases with 100% efficiency.
Brenton Millers
Matching and identification must be over

95% accurate with any given biometric
data
Database access for the system must
abide CrimTrac Strategic Plan (CrimTrac
ICT Blueprint) for National Police
Information Sharing (2014/2018)
Page 9
Project Objectives
Success Criteria
Approved by
Deliver a standalone or NAFIS integrated

system for Facial Recognition,
identification and matching.
The system has to be able to access and

read/write to CrimTracs current or future
databases with 100% efficiency.
Brenton Millers
Matching and identification must be over

95% accurate with any given biometric
data.
Database access for the system must

abide CrimTrac Strategic Plan (CrimTrac
ICT Blueprint) for National Police
Information Sharing (2014/2018)
Develop or procure an identification and
matching algorithm for facial recognition
and identification to be implemented into
CrimTracs current system.
Algorithm accurately matches 100% of

the input Biometric data scans with
corresponding data from CrimTracs
database.
Brenton Millers
Project Objectives
Success Criteria
Approved by
Project to be completed within a 1 year

period, from January 2016
commencement to April 2017 system
delivery.
All phases of the project (Facial

Recognition, Finger- Palm- and Foot
Print, Identification Algorithm) all
developed and successfully implemented
by April, 2017.
Brenton Millers
Time
NAFIS fully replaced by April 2017.
Commence Contract by January 2016
Previous NAFIS System has been 100%

replaced by April, 2017.
Contract fulfilled to 100% satisfaction by
May, 2017.
Brenton Millers
Project Objectives
Success Criteria
Approved by
Complete the project within estimated

budget for the development and
deployment of the proposed system
outlined in this document.
All phases of the project were completed

at or under the budget of $1,684,122.00
AUD.
Brenton Millers
Monitor the costs over project
Accurately logged, monitored and
Brenton Millers
Budget
Page 10
development; Control costs without the

quality suffering.
controlled the expenses over the

duration of the project development.
Deliver expected quality of product by
the contract fulfillment date in May, 2017.
1.1.4 Approach
The project will be produced using an Incremental Approach with waterfall development in each
increment. The project is broken down into its initial requirements and then prioritised to develop
a project plan. Each increment will add new functionality to the developing system, and
depending on project requirements, each incremental step can use a different development life
cycle.
By using an Incremental approach with waterfall increments, ASS guarantees stable releases of
each increment. This is supported by the incremental approach, which provides a range of
benefits including operational feedback from an early stage, issues with requirements or
functionality can be seen and rectified early as the system is developed and the returns on
investment comes earlier. By using waterfall in each developed increment, an increment can be
formally documented and fully developed before replacing current NAFIS systems.
This also enables ASS to fully develop two or more increment modules (such as fingerprint and
palmprint simultaneously developed) before releasing the increments for implementation into
the NAFIS system.
ASS has chosen this approach because
- The system has a large detailed list of requirements.
- To minimize costs should the scope of the project change
- For quick deployment of each system increment
- Each requirement is its own increment of the project
By using an incremental approach for this project, ASS can make use of several software
development life cycles (SDLC) depending on the requirements for each project increment. With
the incremental approach, the development team can fluidly move from a waterfall SDLC in
each that will be incrementally added to the subsystem replacing NAFIS.
Page 11
1.1.5 Primary Stakeholders:
Key Stakeholders
CrimTrac Board of Directors

Doug Smith - Chief Executive Officer
Nicole Rose - Chief Executive Officer
Steven Lee - Director Governance
Nicole Mayo - Chief Operating Officer
Lee Walton - Chief Information Officer
Carolyn Nixon - Chief of Staff
Ace Systems Solutions Customer Liaison Officer
Leigh-Ellen Potter
Ace Systems Solutions Project Manager
Brenton Millers
Ace Systems Solutions Project Team
Benjamin Ivarsson, System Analyst
Brenton Millers, Project Manager/Head
Engineer
David Ley, Lead Programmer
Samantha OSullivan, Business Analyst
Federal Police Agencies
Stakeholders
CrimTrac Technical Staff

CrimTrac Procurement Officer
Contracted Hardware Vendors
Database Staff
State Government Agencies and Law Enforcement
Queensland Police
New South Wales Police Force
Victoria Police
Western Australia Police
Northern Territory Police
South Australia Police
Tasmania Police
System Training Facilitators
CrimTrac Training Facilitators
Ace Systems Solutions Training
Facilitators
Police Agency Training Facilitators

Commencement Date: 11th of January, 2016
System Delivery Date: 5th of April 2017
The commencement date of development has been outlined within the CrimTrac tender. Ace
System Solutions have projected a commencement date which reflects that which is outlined in
CrimTracs tender.
No
Phase
Duration
1.
Project Management Phase
1 month (January - February)
2.
Underlying System Services

Development Phase
3 month (February - May)
3.
System Component Development Phase
6 month (May - November)
4.
System Enhancement Development

Phase
4 months (November - March)
5.
Project Finalisation Phase
2 Weeks (April)
Page 12
1.1.7 Budget
The required budget to complete every required component from the tender is estimated to a
total of $1,684,122.00 AUD.
Item
Total
Hardware
$85,000.00
Software
$7,500.00
Infrastructure
$50,000.00
Project Management & Support Staff
$1,388,520.00
Subtotal
$1,531,020.00
GST (10% Tax)

Total Project Budget
$153,102.00
$1,684,122.00
1.2 Stakeholder Analysis

Name of Client Liaison: Leigh-Ellen Potter
This project has many stakeholders with a great diversity of requirements. The project
description clearly states the requirements that are needed and the areas that will need to be
analysed to discover whom it will affect. In order to understand the list of stakeholders a
synopsis must be done.
A three tier approach will be taken to help categorize the stakeholders of the project and how it
affects each individual stakeholder. Each tier will have a risk that could end the project
altogether, although this may happen no tier should be considered less important than any other
stakeholder within the project. Therefore the approach for this should coordinate all the
stakeholders interests and produces a solution that satisfies all parties.
The tiered approach to each stakeholder party is detailed in the table below, and their role within
the projects development.
Page 13
Name
Position
Internal/
External
Contact Information
Type
Nicole Rose
Chief Executive
Officer
Director Governance
Chief Operating
Officer
Chief Information
Officer
Chief of Staff &
Executive Director
Transition and
Change
Chief Architect
Project Manager
Senior Business
Analyst
Lead Programmer
Database Specialist
Server Specialist
Client Liaison Officer
Internal
n.rose@crimtrac.gov.au
Leading
Internal
Internal
s.lee@crimtrac.gov.au
n.mayo@crimtrac.gov.au
Leading
Leading
Internal
l.walton@crimtrac.gov.au
Leading
Internal
c.nixon@crimtrac.gov.au
Supporting
Internal
External
External
c.nixon@crimtrac.gov.au
brenton.millers@griffithuni.edu.au
sam.osullivan@grffithuni.edu.au
Supporting
Leading
Supporting
External
External
Internal
External
david.ley@griffithuni.edu.au
john.ivarsson@griffithuni.edu.au
c.geeves@crimtrac.com.au
l.potter@griffith.edu.au
Supporting
Supporting
Supporting
Supporting
The Actual Users of

the New System
External
N/A
Supporting
Steven Lee
Nicole Mayo
Lee Walton
Carolyn Nixon
Carolyn Nixon
Brenton Millers
Sam OSullivan
David Ley
Ben Ivarsson
Callum Geeves
Leigh-Ellen
Potter
End Users
The stakeholder register has a massive influence of the project and the impact that each
stakeholder will have, and how they will affect the project. Each level of stakeholders will have a
different influence on the project. An example of this is the priority tier which consists of
stakeholders that are generally in charge of these areas. The three tiers are put into priorities
and are done by level of importance over the crucial assignment.
These stakeholders require a high amount of influence over the project and are crucial to the
success of the project. The second tier does not contain as much power over the project as they
may not change the outcome of the project. Although these stakeholders in this instance are still
primary stakeholders. The third tier are considered the clients that will be using the new product.
They will have specific requirements when looking into the new product. The clients will know
they are after and what will work for their situation and what will not work for their situation. This
tier does not influence the product but are extremely important to the success of the new
product. It is important that this tier is not forgotten about. Each tier has been carefully planned
to communicate with the stakeholders. The tiering system is used because the project affects all
the stakeholders at different levels.
Page 14
1.3 Communication Strategy

Stakeholder
Information Needs
Frequency
Methods
Formality
CrimTrac Board of
Directors
- Progress Reports
- Budgetary Concerns
- Once Monthly
- Meetings with Executive

Committee
High
- Professional
- Formal
CrimTrac Executive
Committee
- Progress reports from the

Project Manager
- Meetings once fortnightly with

Board of Directors
- Meeting once a week with
Project Manager
- Telephone and Email only when
required
- Meetings with the Board of

Directors
- Meetings with Project
Manager
- Email (only for minor
things)
- Phone (only to be used if it
is absolutely necessary )
High
- Formal
CrimTrac Technical Staff
- When the new system will be

installed and features of the
system
- Only need to be told at the start

and the end of the project
- Email as it the best way to

get the information to them
High
- Professional
CrimTrac Procurement
Officers
- What software tools are

required
- Daily contact with the Lead

Programmer
- When required
- Face to Face
- Email
- Phone
High
- Social with the Lead
Programmer
Federal Police Agencies

system


High
- Professional
State Government
Agencies and Law
Enforcement

system


High
- Professional
Contracted Hardware
Vendors
- When the necessary testing

hardware is to be delivered by
- Only at the start of the project

High
- Professional
Database Staff
- Any relevant information

regarding the database Schema
- Once weekly meetings with

Project Management Team

Team
- Face to Face
- Email
- Phone
Medium
- Social within the Project
Team
System Training
Facilitators
- All Information in regards to

the training of end users of the
project
- Only when the documentation

relating to the training of staff has
been developed
- Email
- Phone
Medium
Team
Leigh-Ellen Potter
Customer Liaison Officer
- All Operations relating to

Project
- Any and all Updates Relating
to the Project
- Any and all Feedback from the
Executive Stakeholders
regarding the Project
- Daily Project updates from the

Management Team
- Meetings to be held once a week
with Project Team Leaders
- Once a week meetings with
CrimTrac Executive Committee

Management Team
- Face to Face
- Email
- Phone
Medium
- Social within Project
Team
- Formal with all
interactions with CrimTrac
Page 15
Brenton Millers
Project Manager
- All Operations relating to

Project
- Any and all Updates Relating
to the Project
- Any and all Feedback from the
Executive Stakeholders
regarding the Project
- Daily Project updates from the

Management Team
- Meetings to be held once a week
with Project Team Leaders
- Once a week meetings with
CrimTrac Executive Committee
- Face to face with members

of the Project Team
- Meetings with the
CrimTrac Ecutive
Committee
- Email
Phone
Medium
Team
- Formal with all
Samantha OSullivan
Business Analyst
- All changes made

- All information relating to the
project and progress
- Daily with members of Project

Team
- Once a fortnight usability testing
with CrimTrac staff
- Frequent communication with
relevant stakeholders

Management Team
- Face to Face
- Email
- Phone
Medium
- Social within Project
Team
- Formal with all
David Ley
Lead Programmer

Software requirements
- Once weekly meetings with

Project Management Team
- Daily with CrimTrac Procurement
Officers

Team
- Face to Face
- Email
- Phone
Medium
Team
- Formal with CrimTrac
Procurement Officer
Benjamin Ivarsson
Systems Analyst

architecture of the system
- Once weekly meeting with

Project Team
- Daily communication with Lead
Programmer
- Daily communication with
CrimTrac Procurement Officer
- Meeting with Project Team

- Face to Face
- Email
- Phone
Medium
Team
- Formal with the CrimTrac
Procurement Officer
1.3.1 Managing and Resolving Breakdowns in Communication

With a breakdown communication, procedures will clearly be followed:
All stakeholders will be in a tier and be identified.
Investigated and identified breakdown of each stakeholders.
Corrective action will be taken for the breakdown
Follow up on all communication.
If any errors occurred once resolved prevention methods will be available to stop any
similar breakdowns.
1.3.2 Team Communication Strategies

The environment will be open and collaborative and an easy environment for team members to
communicate so each member can place an idea and have it documented. By doing so this
allows room for excellent communication to take place and stop unorganised communication
approaches such as email.
Tasks, responsibilities, milestones and schedules will be communicated via an ongoing Instant
Messaging conversation and weekly meetings.
Page 16
1.3.3 Communicating Amongst A Distributed Team

In order to communicate well within the team with different shareholders and stakeholders. The
environment of production is extremely important so that everyone can be cultivate ideas and
collaborate:
Communication between the stakeholders and the project team will be via email to all
concerned parties.
Meetings will be arranged face to face when required and the initial meeting with all
relevant stakeholders.
All team members will be kept up to date with all relevant information that is important to
their part of the development of the project.
Development meetings will be arranged with the team members at the beginning of each
development stage.
There will also be individual increment at the end, and these meetings will be when the
necessity arises.
All email communication will will be kept short and concise only relating to one topic,
unless a necessity to refer to another topic.
If there is a lot of information an email will be sent to organise a face to face meeting
between any relevant stakeholders.
Page 17
2. Project Scope Statement

Revision History
Date
Ver.
Author
Addition/Alteration
10/08/2015
1.1
All
The group during a group meeting discussed how the system will
function and agreed on what we will be developing for the system
17/08/2015
1.1
Brenton Millers
Jotting down notes for product scope description and product

deliverables.
21/08/2015
1.1
Brenton Millers
Aligning to meeting with Leigh-Ellen
22/08/2015
1.1
Brenton Millers
Deconstructed CrimTrac tender for requirements and required

deliverables
23/08/2015
1.1
Brenton Millers
Setup tables for the requirements and deliverables.
26/08/2015
1.2
Brenton Millers
Added requirements to the product scope description.
27/08/2015
1.2
Brenton Millers
Added requirements to the product scope description.
28/08/2015
1.2
Brenton Millers
Continued adding requirements. Started deliverables.
29/08/2015
1.3
Brenton Millers
Finished deliverables, requirements and wrote the project justification.
30/08/2015
1.3
Brenton Millers
Updated due dates to reflect project time and start dates.
07/09/2015
1.4
Brenton Millers
Added risk management to the deliverables.

CrimTrac is looking to upgrade the National Automated Fingerprint Identification System
(NAFIS). NAFIS allows police to upload and search fingerprint data obtained from a crime scene
or from an arrest in real time. This assists police in the correct identification of a person of
interest and can link them to existing warnings, warrants, or other criminal activities.
CrimTrac are looking to align the NAFIS system with new identification technologies (the ability
to store and search footprint and facial biometric data). This will enable law enforcement
agencies to have a much greater chance of finding and catching criminals.
The developed system will be a new system to replace NAFIS, and the system will be
incorporating all of the latest technologies for biometric analysis and matching. All TenPrint and
Latent data from the previous system will be migrated into the new system.
CrimTrac will also be provided a mobile solution for access to the new system allowing
enforcement agencies even faster access to results.
Page 18
2.2 Product Scope Description

The requirements outlined in the project have been categorised using the following guidelines.
Each requirement is given a Priority level and a Priority Rating. The priority represents
whether the requirement is Mandatory, Desirable or Optional. The priority rating provides
each requirement an urgency level. High being at the top, Low at the bottom and Medium
for the median.
2.2.1 Hardware Requirements

R No.
Requirement
Priority
Priority
Rating
R 1.01
Fingerprint Scanner which will facilitate the capture of Biometric Data to

be stored within the system.
Desirable
High
R 1.02
Palm and Footprint Scanner which will facilitate the capture of Biometric
Data to be stored within the system.
Desirable
High
R 1.03
High quality digital camera for Facial Recognition, which will facilitate the
capture of Biometric Data to be stored within the system.
Desirable
High
R 1.04
Custom Firmware for Fingerprint Scanner for standardisation within the

system. (All devices look and run the same; Data being sent from the
device is to a standard read directly into the system).
Desirable
Medium
R 1.05
Custom Firmware for Palm Print Scanner for standardisation within the
system. (All devices look and run the same; Data being sent from the
device is to a standard read directly into the system).
Desirable
Medium
2.2.2 Software Requirements

R No.
Functional Requirement
Priority
Priority
Rating
FR 2.01
The system will have Fingerprint Capture Service which will enable users
to capture and transmit Biometric Data (Fingerprint, Palm Print, Footprint,
Demographic Data) and associated data using user provided devices
(Tablet, Desktop, Mobile Phone).
Mandatory
High
FR 2.02
The system will have Fingerprint Storage Service which will facilitate the
automated storage of biometric data (Fingerprint, Palm Print, Footprint)
and management of its associated data (Capture events, history, retention
and deletion).
Mandatory
High
FR 2.03
The system will have Fingerprint Datasets Service to allow the creation of
subsets of Fingerprint, Palm Print and Foot Print database in discrete
datasets for various applications.
Mandatory
Medium
FR 2.04
The system will have Fingerprint Enrollment Service to facilitate the
Mandatory
High
Page 19
enrolment of a new set of Fingerprint, Palm Print and Foot Prints with an
image file and any meta data.
FR 2.05
The system will have Fingerprint Matching Service to compare a provided

Fingerprint, Footprint or Palm Print with all corresponding data stored
within the system.
Mandatory
High
FR 2.06
The system will have Facial Capture Service which will enable users to
capture and transmit Biometric Data (Facial Images, Demographic Data)
and associated data using user provided devices (Tablet, Desktop, Mobile
Phone).
Mandatory
High
FR 2.07
The system will have Facial Storage Service which will facilitate the
automated storage of biometric data (Facial Images) and management of
its associated data (Capture events, history, retention and deletion).
Mandatory
High
FR 2.08
The system will have Facial Datasets Service to allow the creation of
subsets of Facial Image database in discrete datasets for various
applications.
Mandatory
Medium
FR 2.09
The system will have Facial Enrolment Service to facilitate the enrolment
of Facial Images with metadata.
Mandatory
High
FR 2.10
The system will have Facial Quality Checking Service checks the quality
of the images provided during enrollment.
Mandatory
Medium
FR 2.11
The system will have Facial Matching Service to compare a provided

Facial Image with all corresponding data stored within the system.
Mandatory
High
FR 2.12
The system will have Demographic Data Storage Service will allow for the
storage and management of Demographic Data associated with the
biometric data. It will also provide means for users to directly input data
and upload data.
Mandatory
Medium
FR 2.13
The system will have Identity Management Service will link the Biometric
Data to an Identity Record.
Mandatory
Medium
FR 2.14
The system will have Forensic Information Service which provides the
ability to search, view and extract information from multiple data sources
accessible by the new system.
Mandatory
Medium
FR 2.15
The system will have Dashboard Service that will provide a user
accessible interface to monitor a range of information (real-time
monitoring of matching status, workload stats, matching outcomes, job
scheduling, system availability, system performance). It will house a range
of user configurable fields based on the user's role.
Mandatory
High
FR 2.16
The system will have Data Exchange Service which allows for the
conversion and exchange of data between users and with agencies
external to the stakeholders.
Mandatory
High
FR 2.17
The system will have Identity Report Service which will provide a series
of reports for users to generate. This includes reports for (Demographic
Details, Biometric Data, Fingerprints, Palm Prints, Face Images,
Enrolment Data Records) and user reports.
Mandatory
Medium
FR 2.18
The system will have Support Service which will provide support
technicians with tools and information required for maintaining the system.
Mandatory
Medium
Page 20
FR 2.19
The system will have Change Management Service which will provide
provision training and the associated materials for the system and its
services; list the new functionalities and services to the system; list
changes to existing and specialist services to support business
Mandatory
Low
FR 2.20
The system will have Biometric in a Box software that enable the system
for portable operations as required.
Mandatory
Medium
FR 2.21
The system will have Expert Shared Service to allow a shared pool of
Fingerprint and Facial experts.
Mandatory
Medium
FR 2.22
The system will have Service Integration Service which will allow
integration to systems external to the system (within and externally to
CrimTrac)
Mandatory
Medium
FR 2.23
The system will have Business Workflow Service that will enable users to
customise their Business Workflows within the system (alerts, set
business rules, progress work).
Mandatory
Low
FR 2.24
The system will have Device Procurement Service which will allow the
users to acquire capture devices for use with the system.
Mandatory
Medium
FR 2.25
The system will have the ability for the system to source data from new
information providers.
Mandatory
Low
FR 2.26
The system will have streamlined user interface which will allow access
to all features of the system based on user access levels (access
information, start search, compare previous searches, access reports).
Mandatory
High
FR 2.27
The system will have User Access Control component controlling the
levels of access each user to the system and the data they can retrieve
from the system.
Mandatory
Medium
FR 2.28
The system will have the ability to install additional capabilities (Retinal,
Voice, DNA) as new technology emerges.
Mandatory
Medium
FR 2.29
The system will have an application written for a mobile device which
allows complete access to the system and its features remotely.
Desirable
High
FR 2.30
The system will use disaster recovery capability that does not involve
outages of the system with immediate recovery time.
Mandatory
High
FR 2.31
The system will have a Change Management Database
Desirable
Medium
R No.
Technical Requirement
Priority
Priority
Rating
TR 2.01
Software will be compatible and run on CrimTracs current servers and

system software.
Mandatory
High
TR 2.02
Software will conform to CrimTracs ICT Blueprint.
Mandatory
High
TR 2.03
Software will conform to CrimTracs conceptual solution model.
Desired
High
TR 2.04
Software will be written in a module form.
Desired
High
TR 2.05
Ability for additional modules to be added into the system.
Mandatory
High
Page 21
TR 2.06
Interface runs in all of the major web browsers (Chrome, Firefox, Edge,
Internet Explorer).
Desired
Medium
TR 2.07
Mobile applications are written for all the major mobile operating systems
(iOS, Android, Windows).
Optional
Low
TR 2.08
System supports information exchange using the National Information

Exchange Model.
Mandatory
High
TR 2.09
System supports matching of One to Many, One to One, One to Few for
all implemented biometric modalities.
Mandatory
High
2.2.3 Quality Requirements

R No.
Requirement
Priority
Priority
Rating
R 3.01
Accuracy of comparisons performed on biometric data is equal or above

industry standards.
Desirable
High
R 3.02
Software is written to ISO and IEEE standards.
Optional
Medium
R 3.03
Hardware is compliant to ISO and IEEE standards.
Optional
Medium
2.2.4 Integration Requirements

R No.
Requirement
Priority
Priority
Rating
R 4.01
Integration of existing data from current NAFIS system.
Mandatory
High
R 4.02
Integration of existing data from current facial recognition systems.
Mandatory
High
R 4.03
Integration of metadata for current known results.
Mandatory
High
2.2.5 Support Requirements

R No.
Requirement
Priority
Priority
Rating
R 5.01
Service management services
Mandatory
Medium
R 5.02
Service desk & technical support for the system and services
Mandatory
Medium
R 5.03
Performance monitoring services
Mandatory
Medium
Page 22
R 5.04
Support available 24/7 365 days for all users of the system.
Mandatory
High
2.2.6 Vendor Compliance Requirements

R No.
Requirement
Priority
Priority
Rating
R 6.01
All data must be stored securely and on a secure site.
Mandatory
High
R 6.02
Information that is shared is compliant with levels of access.
Mandatory
High
R 6.03
System complies with all MOU and SLAs between all Stakeholders.
Mandatory
High
R 6.04
All data transmitted must be sent via a secure connection.
Desirable
High
2.2.7 Documentation Requirements

R No.
Requirement
Priority
Priority
Rating
R 7.01
Processes and Procedures regarding the hardware requirements, setup,

installation the standalone portable version of the system. (Biometric in a
Box).
Mandatory
High
R 7.02
Documentation detailing all products and services that are used by the
system and how it is all linked.
Optional
Medium
R 7.03
Documentation will conform to industry standards.
Desirable
Medium
R 7.04
Documentation regarding the use and operations of procurement

hardware.
Desirable
Low
Page 23
2.3 Product Deliverables

2.3.1 Hardware Deliverables
D No.
Deliverable
Description
Due Date
D 1.0
Fingerprint Scanner Firmware
Custom firmware written for Fingerprint scanning

hardware.
24/06/2016
D 1.1
Palm and Foot Print Scanner

Firmware
Custom firmware written for Palm and Foot Print

scanning hardware.
08/07/2016
2.3.2 Software Deliverables

D No.
Deliverable
Description
Due Date
D 2.0
NAFIS System
The completed system containing all the modules

(Fingerprint, Foot Print, Palm Print, Facial) and
services required for the system to perform storage,
comparisons and integrations with internal/external
systems and services.
24/03/2017
D 2.0.1
NAFIS User Interface
A user interface for users to control, monitor and use

the system.
11/07/2016
D 2.0.2
Fingerprint Module
Controls the capture, storage, analysis and sharing of

Fingerprint biometric data.
08/07/2016
D 2.0.3
Palm Print Module

Palm Print biometric data.
05/07/2016
D 2.0.4
Foot Print Module

Foot Print biometric data.
02/09/2016
D 2.0.5
Facial Module

Facial biometric data.
04/11/2016
D 2.1
Biometrics in a Box
A portable, shrunk down version of NAFIS for

standalone use in the field.
25/11/2016
D 2.2
Mobile Application
A mobile solution for remote access to the system.
02/12/2016
2.3.3 Documentation Deliverables

D No.
Deliverable
Description
Due Date
Page 24
D 3.00
User Interface Design Brief
Design brief for the user interface of the NAFIS

system.
06/05/2016
D 3.01
NAFIS Installation Manual
Installation instructions for the complete setup of

NAFIS.
17/02/2017
D 3.02
NAFIS User Manual
User manual for the use of the NAFIS interface and

its features.
17/02/2017
D 3.03
NAFIS Administrator's Manual
User manual containing information on how to

administer the system (user account creation, access
levels, reading system reports, database
administration, system maintenance) and detailed
information sharing policies.
24/02/2017
D 3.04
Hardware Documentation
Documentation for using the hardware provided by

the Device Procurements Service.
11/11/2016
D 3.05
Mobile Software Manual
User manual for the installation and use of the mobile

application for NAFIS.
02/12/2016
D 3.06
Biometrics in a Box
Documentation
Installation and operating procedures for the portable

version of NAFIS
24/02/2017
D 3.07
Final System Design
Documentation outlining the implementation and the

inner workings of the system.
20/02/2017
D 3.08
Matching Algorithm
Documentation
Documentation explaining the algorithms used within

the system.
13/05/2016
D 3.09
Term of Use Policies
Documentation for users regarding the use of the

software and information sharing policies.
18/03/2016
D 3.10
Support Documentation
How to and troubleshooting documentation for

support staff.
03/03/2017
D 3.11
Standards Documentation
Standards compliance documentation (protocols,

data-structures, methods).
10/06/2016
2.3.4 Services Deliverables

D No.
Deliverable
Description
Due Date
D 4.0
Ongoing support.
Providing ongoing support and maintenance for

NAFIS as requested by the Tender.
April 2017
D 4.1
Device Procurement Service
Facility for users of the system to purchase hardware

compatible with the system and preloaded with
custom firmware. (Fingerprint Reader, Palm/Foot
Print Reader, high quality digital camera).
April 2017
Page 25
2.3.5 Project Management Deliverables

D No.
Deliverable
Description
Due Date
D 5.0
Software Integration Plan
A plan detailing how the old version of NAFIS will be

replaced.
03/02/2017
D 5.1
System Handover
Official handover of the developed system including

deliverable documentation.
27/03/2017
D 5.2
Cost Management Report
A report detailing the approach of controlling project

budget and costs.
20/05/2016
D 5.3
Change Management Plan
A report provided on how changes during the

planning, development and implementation phases
will be managed.
20/05/2016
D 5.4
Change Report
A catalog of system changes, document changes,

vision changes, requirement changes made through
the development of the system.
24/03/2017
D 5.5
Risk Management Plan
A report detailing risks applicable to the development

and implementation of the replacement NAFIS
System.
24/03/2016
Page 26
3. Work Breakdown Structure

Revision History
Date
Ver.
Author
Addition/Alteration
30/8/2015
1.3
David Ley
Added Draft WBS Tree and Filled out Table
10/09/2015
2.1
Brenton Millers
Created WBS Tree
21/09/2015
2.1
Brenton Millers
Modified WBS Tree
22/09/2015
2.1
Brenton Millers
Modified WBS Tree to Leigh-Ellens advice
23/09/2015
2.1
Brenton Millers
Created Filled in table and made further adjustments..
24/09/2015
2.1
Brenton Millers
Continued adding things to the WBS and made an ID collumn
25/09/2015
2.2
Brenton Millers
Finalised everything and verified accuracy.
25/09/2015
2.2
David Ley
Created and added WBS Tree
16/10/2015
3.0
Benjamin Ivarsson
Revised where able to; unable to revise picture submission and

attached documentation -> Project Manager responsible that all files
present and in high quality on submission
Fixed the page 39 blankpage, went through the WBS table.
Added a conventions used segment to the WBS breakdown to explain
reasoning behind double ID.
Page 27
3.1 WBS Tree

Please see attached JPEG File WBS Tree for higher quality image.
Page 28
3.2 WBS Table

Conventions used: ID indicates the ID for the developed increment used to establish the most
critical path. It indicates a reference ID for preceding increments and dependencies in the
project.
Section numbers are used to identify the sections from the WBS above, and the documentation
for each corresponding section ID.
Phase 1 - Project Management Phase

1.0 Project Management Phase - 1 Month Monday 11 Jan
Duration
Predecessors
(References ID)
ID
Section
Task name
1.1
Identify the Project
1.1.1
Identify Stakeholders
4 days
1.1.2
Research existing NAFIS System
3 days
1.1.2.1
Consult stakeholders of existing system
1 days
1.1.2.2
Identify existing business processes
1 days
1.1.2.3
Identify hardware and system constraints
1 days
1.1.3
Pitch ideas with stakeholders
1 days
1.2
Requirements & Scope
10
1.2.1
Identify requirements of replacement NAFIS System
2 days
11
1.2.2
Define Project Scope
0.5 days
10
12
1.2.3
Develop Acceptance Criteria
0.5 days
11
13
1.3
Stakeholder Management
14
1.3.1
Develop stakeholder management strategy
0.5 days
12
15
1.3.2
Develop stakeholder communication plan
0.5 days
14
16
1.3.2.1
Communication Breakdown Management
0.2 days
17
1.3.2.2
Team Communication Strategies
0.2 days
16
18
1.3.2.3
Distributed Team Communication
0.1 days
17
Page 29
19
1.4
Scope Management
13
20
1.4.1
Structure the Work Breakdown Structure
2 days
18
21
1.4.2
Develop Scope Validation Plan
1 days
20
22
1.4.3
Develop Scope Control Plan
1.5 days
21
23
1.5
Estimations
3 days
19
24
1.5.1
Determine Project Budget
3 days
22
25
1.5.1.1
Perform Function Point Counting
2 days
26
1.5.1.2
Estimate Budget
1 days
27
1.6
Change Management
28
1.6.1
Establish Change Control Approach
1 days
26
29
1.6.2
Establish Change Control Procedure
1 days
28
30
1.6.3
Define Audits and Reviews Procedure
1 days
29
31
1.7
Device Procurement
32
1.7.1
Establish Hardware Standard
3 days
30
33
1.7.2
Establish Procurement Procedures with Supplier
2 days
32
25
23
27
Phase 2 - Underlying System Services Development Phase

2.0 Underlying System Services Development Phase
ID
Section
Task name
Duration
Predecessors
34
2.1
NAFIS Subsystem
35
2.1.1
Analysis
36
2.1.1.1
Analyse NAFIS Subsystem Functional/Technical

Requirements.
37
2.1.2
Design
38
2.1.2.1
Develop Strategic Development Plan
1 days
39
2.1.2.2
Develop UI Design Brief for NAFIS User Interface
3 days
38
40
2.1.2.3
Develop NAFIS Module Standards Documentation
3 days
39
2 days
10
36
Page 30
41
2.1.3.4
Develop NAFIS External Data Input Standards
3 days
40
42
2.1.2.5
Develop Technical Documentation
3 days
41
43
2.1.2.6
User Access Control Documentation
2 days
42
44
2.1.3
Implementation
45
2.1.3.1
Write Software Code
20 days
46
2.1.3.2
Develop User Interface
3 days
45
47
2.1.3.3
Build Administration/Support Components
5 days
46
48
2.1.3.4
Develop Installation/User Manual
3 days
47,45,46
49
2.1.4
Testing
50
2.1.4.1
Workload Testing
5 days
51
2.1.4.2
Security Testing
5 days
52
2.1.4.3
User Interface Testing
5 days
53
2.1.4.4
CrimTrac Integration Testing
5 days
54
2.1.5
Increment Release
55
2.1.5.1
Acceptance Process
3 days
56
2.1.5.2
Increment Acceptance Report
1 days
55
57
2.1.5.3
Increment Handover
1 days
56
58
2.1.5.4
Documentation Handover
1 days
56
37
44
49
Phase 3 - System Component Development Phase

3.0 System Component Development Phase
ID
Section
Task name
Duration
59
3.1
Fingerprint Module
60
3.1.1
Analysis
61
3.1.1.1
Source testing hardware from supplier
3 days
62
3.1.1.2
Analyse Fingerprint Module Functional/Technical

Requirements
1 days
Predecessors
34
10
Page 31
63
3.1.1.3
Analyse NAFIS Module Standards Documentation
1 days
40
64
3.1.1.4
Source Matching Algorithm
3 days
65
3.1.2
Design
66
3.1.2.1
3 days
67
3.1.2.2
Design Database
2 days
66
68
3.1.2.3
Design Capture System
2 days
67
69
3.1.2.4
Design Storage System
2 days
68
70
3.1.2.5
Design Information Sharing System
2 days
69
71
3.1.2.6
3 days
70,67,68,69
72
3.1.3
Implementation
73
3.1.3.1
Create Database
3 days
67
74
3.1.3.2
Write Software Code
15 days
73
75
3.1.3.3
Develop Support Documentation
3 days
74,73
76
3.1.3.4
Develop Fingerprint Module Installation/User Manual
3 days
74,73
77
3.1.4
Testing
78
3.1.4.1
Database Testing
5 days
79
3.1.4.2
Biometric Data Matching Tests
5 days
80
3.1.4.3
Workload Testing
5 days
81
3.1.4.4
Security Testing
5 days
82
3.1.4.5
5 days
83
3.1.4.6
5 days
84
3.1.5
Increment Release
85
3.1.5.1
Acceptance Process
3 days
86
3.1.5.2
Fingerprint Module Acceptance Report
1 days
85
87
3.1.5.3
Fingerprint Module Handover
1 days
86
88
3.1.5.4
1 days
86
89
3.2
Palm Print Module
60
65
72
77
34
Page 32
90
3.2.1
Analysis
60
91
3.2.1.1
3 days
92
3.2.1.2
Analyse Palm Print Module Functional/Technical

Requirements
1 days
10
93
3.2.1.3
1 days
40
94
3.2.1.4
3 days
95
3.2.2
Design
96
3.2.2.1
3 days
97
3.2.2.2
Design Database
2 days
96
98
3.2.2.3
2 days
97
99
3.2.2.4
2 days
98
100
3.2.2.5
2 days
99
101
3.2.2.6
3 days
100,97,98,99
102
3.2.3
Implementation
103
3.2.3.1
Create Database
3 days
97
104
3.2.3.2
Write Software Code
15 days
103
105
3.2.3.3
3 days
103,104
106
3.2.3.4
Develop Palm Print Module Installation/User Manual
3 days
103,104
107
3.2.4
Testing
108
3.2.4.1
Database Testing
5 days
109
3.2.4.2
5 days
110
3.2.4.3
Workload Testing
5 days
111
3.2.4.4
Security Testing
5 days
112
3.2.4.5
5 days
113
3.2.4.6
5 days
114
3.2.5
Increment Release
115
3.2.5.1
Acceptance Process
90,65
95,72
102,77
107
3 days
Page 33
116
3.2.5.2
Palm Print Module Acceptance Report
1 days
115
117
3.2.5.3
Palm Print Module Handover
1 days
116
118
3.2.5.4
1 days
116
119
3.3
Foot Print Module
34
120
3.3.1
Analysis
90
121
3.3.1.1
3 days
122
3.3.1.2
Analyse Foot Print Module Functional/Technical

Requirements
1 days
10
123
3.3.1.3
1 days
40
124
3.3.1.4
3 days
125
3.3.2
Design
126
3.3.2.1
3 days
127
3.3.2.2
Design Database
2 days
126
128
3.3.2.3
2 days
127
129
3.3.2.4
2 days
128
130
3.3.2.5
2 days
129
131
3.3.2.6
3 days
127,128,129,130
132
3.3.3
Implementation
133
3.3.3.1
Create Database
3 days
127
134
3.3.3.2
Write Software Code
15 days
133
135
3.3.3.3
3 days
133,134
136
3.3.3.4
Develop Footprint Module Installation/User Manual
3 days
133,134
137
3.3.4
Testing
138
3.3.4.1
Database Testing
5 days
139
3.3.4.2
5 days
140
3.3.4.3
Workload Testing
5 days
141
3.3.4.4
Security Testing
5 days
142
3.3.4.5
5 days
120,95
125,102
132,107
Page 34
143
3.3.4.6
5 days
144
3.3.5
Increment Release
145
3.3.5.1
Acceptance Process
3 days
146
3.3.5.2
Foot Print Module Acceptance Report
1 days
145
147
3.3.5.3
Foot Print Module Handover
1 days
146
148
3.3.5.4
1 days
146
149
3.4
Facial Recognition Module
34
150
3.4.1
Analysis
120
151
3.4.1.1
3 days
152
3.4.1.2
Analyse Facial Recognition Module

Functional/Technical Requirements
1 days
151
153
3.4.1.3
1 days
152
154
3.4.1.4
3 days
155
3.4.2
Design
156
3.4.2.1
3 days
157
3.4.2.2
Design Database
2 days
156
158
3.4.2.3
2 days
157
159
3.4.2.4
2 days
158
160
3.4.2.5
2 days
159
161
3.4.2.6
3 days
157,158,159,160
162
3.4.3
Implementation
163
3.4.3.1
Create Database
3 days
157
164
3.4.3.2
Write Software Code
15 days
163
165
3.4.3.3
3 days
164,163
166
3.4.3.4
Develop Facial Recognition Module Installation/User

Manual
3 days
164,163
167
3.4.4
Testing
168
3.4.4.1
Database Testing
137
125,150
155,132
137,162
5 days
Page 35
169
3.4.4.2
5 days
170
3.4.4.3
Workload Testing
5 days
171
3.4.4.4
Security Testing
5 days
172
3.4.4.5
5 days
173
3.4.4.6
5 days
174
3.4.5
Increment Release
175
3.4.5.1
Acceptance Process
3 days
176
3.4.5.2
Facial Recognition Module Acceptance Report
1 days
175
177
3.4.5.3
Facial Recognition Module Handover
1 days
176
178
3.4.5.4
1 days
176
167
Phase 4 - System Enhancement Development Phase

4.0 System Enhancement Development Phase
ID
Section
Task name
Duration
Predecessors
179
4.1
Fingerprint Scanner Firmware
180
4.1.1
Analysis
181
4.1.1.1
Analyse Fingerprint Firmware Functional/Technical

Requirements
1 days
182
4.1.1.2
1 days
181
183
4.1.1.3
Analyse Hardware Procurement Documentation
1 days
182
184
4.1.2
Design
185
4.1.2.1
3 days
186
4.1.2.2
3 days
187
4.1.3
Implementation
188
4.1.3.1
Write Software Code
15 days
189
4.1.3.2
3 days
59,89,119,149
180
185
184
188
Page 36
190
4.1.3.3
Develop Firmware Installation/Technical

Documentation for Manufacturer.
191
4.1.4
Testing
192
4.1.4.1
Test Firmware Installation
5 days
193
4.1.4.2
Test Compatibility with NAFIS System
5 days
194
4.1.4.3
Test Output Data Quality
5 days
195
4.1.5
Increment Release
196
4.1.5.1
Acceptance Process
3 days
197
4.1.5.2
Fingerprint Scanner Firmware Acceptance Report
1 days
196
198
4.1.5.3
Fingerprint Scanner Firmware Handover
1 days
197
199
4.1.5.4
1 days
197
200
4.2
Foot/Palm Print Scanner Firmware
59,89,119,149
201
4.2.1
Analysis
180
202
4.2.1.1
Analyse Fingerprint Firmware Functional/Technical

Requirements
1 days
203
4.2.1.2
1 days
202
204
4.2.1.3
Analyse Hardware Procurement Documentation
1 days
203
205
4.2.2
Design
206
4.2.2.1
3 days
207
4.2.2.2
3 days
208
4.2.3
Implementation
209
4.2.3.1
Write Software Code
15 days
210
4.2.3.2
3 days
201
211
4.2.3.3
Develop Firmware Installation/Technical

Documentation for Manufacturer.
3 days
210
212
4.2.4
Testing
213
4.2.4.1
Test Firmware Installation
5 days
214
4.2.4.2
Test Compatibility with NAFIS System
5 days
3 days
189
187
191
201,184
206
205,184
208,191
Page 37
215
4.2.4.3
Test Output Data Quality
5 days
216
4.2.5
Increment Release
217
4.2.5.1
Acceptance Process
3 days
218
4.2.5.2
Palm/Foot Print Scanner Firmware Acceptance

Report
1 days
217
219
4.2.5.3
Palm/Foot Print Scanner Firmware Handover
1 days
218
220
4.2.5.4
1 days
218
221
4.3
Biometrics in a Box
59,89,119,149
222
4.3.1
Analysis
180
223
4.3.1.1
Analyse Biometrics in a Box Functional/Technical

Requirements
1 days
224
4.3.1.2
1 days
223
225
4.3.1.3
Analyse NAFIS External Data Input Standards
1 days
224
226
4.3.2
Design
227
4.3.2.1
Design External Database
5 days
228
4.3.2.2
3 days
227
229
4.3.2.3
3 days
228
230
4.3.3
Implementation
231
4.3.3.1
Create External Database
5 days
232
4.3.3.2
Write Software Code
20 days
231
233
4.3.3.3
3 days
232
234
4.3.3.4
Develop Biometrics in a Box Installation/User Manual
3 days
233
235
4.3.4
Testing
236
4.3.4.1
Database Testing
10 days
237
4.3.4.2
10 days
238
4.3.4.3
Workload Testing
10 days
239
4.3.4.4
Network Communication Testing (Between BIAB and

NAFIS)
10 days
212
222,205
226,208
212,230
Page 38
240
4.3.4.5
Security Testing
10 days
241
4.3.4.6
10 days
242
4.3.5
Increment Release
243
4.3.5.1
Acceptance Process
3 days
244
4.3.5.2
Biometrics in a Box Acceptance Report
1 days
243
245
4.3.5.3
Biometrics in a Box Handover
1 days
244
246
4.3.5.4
1 days
244
247
4.4
Mobile Application
59,89,119,149
248
4.4.1
Analysis
222
249
4.4.1.1
3 days
250
4.4.1.2
Analyse Mobile Application Functional/Technical

Requirements
1 days
249
251
4.4.1.3
1 days
250
252
4.4.1.4
Analyse NAFIS External Data Input Standards
1 days
251
253
4.4.2
Design
254
4.4.2.1
5 days
255
4.4.2.2
3 days
254
256
4.4.2.3
UI Design Brief for Mobile Application
3 days
255
257
4.4.3
Implementation
258
4.4.3.1
Write Software Code
20 days
259
4.4.3.2
3 days
258
260
4.4.3.3
Develop Mobile Application Installation/User Manual
3 days
259
261
4.4.4
Testing
262
4.4.4.1
Workload Testing
5 days
263
4.4.4.2
Network Communication Testing (Between App and

NAFIS)
5 days
264
4.4.4.3
Security Testing
5 days
265
4.4.4.4
5 days
235
248,226
253,230
257,235
Page 39
266
4.4.5
Increment Release
261
267
4.4.5.1
Acceptance Process
3 days
268
4.4.5.2
Mobile Application Acceptance Report
1 days
267
269
4.4.5.3
Mobile Application Handover
1 days
268
270
4.4.5.4
1 days
268
Duration
Predecessors
Phase 5 - Project Finalisation Phase

5.0 Project Finalisation Phase
ID
Section
Task name
271
5.1
System Handover
272
5.1.1
Final System Handover
273
5.2
Project Review
274
5.2.1
Finalise Documentation
3 days
272
275
5.2.2
Archive Documentation for Referencing
2 days
274
179,200,221,247
1 days
271
Page 40
4. Estimation
Revision History
Date
Ver.
Author
Addition/Alteration
10/09/2015
2.1
Benjamin Ivarsson
Section 4.1 Drafted. Awaiting team response and further discussion.
25/09/2015
2.1
David Ley
Changed Parts of 4.1 and finalised, Completed sections 4.2 and 4.3
16/10/2015
3.0
Benjamin Ivarsson
Revised section 4.2; just a simple justification, need further reiterations

on the justification from the team.
4.1 Choice of Technique

To condense the high level of detail from requirements of this project, and to accurately
estimate budget and schedule requirements for this project, we have chosen to make use of the
following techniques:
Function Point Counting, to accurately represent estimated budget and schedule
Value Adjustment Factor, to rate the project's characteristics according to 14 general
system characteristics and determine their influence on the project
Function Point Adjustment, counting the expected complexity of project
Industry Data, to use industry data from similar projects to formulate an estimate.
Three Point Estimating, a technique used with optimistic, pessimistic and most likely
then using a calculated stated below to find an answer.
Page 41
4.2 Justification
4.2.1 Function Point Counting
ASS has chosen to make use of Function Point Counting, as it will give us the ability to
accurately estimate our software project, establish its complexity and size of the proposed
system, solely based on the requirements established in our scope. Function Point Counting
has been proven to be an extremely accurate and effective method to determine a meaningful
unit of measure that can be used to help in the estimation of the time and needed to complete a
software project.
As the technique is recognized by the ISO in ISO/IEC 20968:2002, as the standard best suited
for estimating time and cost on large-scale software projects, it will allow ASS to give CrimTrac
the best possible, worst possible and just right estimation of the project. Once the Function
Point Count has been calculated from analysing the functional requirements of the project, the
calculated result can then be estimated using the COCOMO II algorithmic software cost
estimation model, to then convert the result into meaningful metrics which can then be used as
a baseline to use for the time and approximate cost for our project.
4.2.2 Function Point Adjustment

Function Point Counting only takes into account any functional requirements of a system, so to
get a more accurate representation of the technical requirements of the project, ASS will use an
adjustment to the Function Point Count (FPC) total to allow for more accurate estimation of the
time and cost of the project. ASS will then apply Value Adjustment Factor (VAF) to the Function
Point Total.
The VAF is calculated by comparing the potential system to 14 general system characteristics
that rate the general functionality of the application being counted. Each characteristic has
associated descriptions to determine the degrees of influence. These degrees of influence are
on a scale of 0 to 5, with five being strong influence and 0 being no influence. Once the
degrees of influence have been determined the result is then added together and then has the
following formula applied to it: VAF = (Total Degrees of Influence * 0.01) + 0.65.
The result is the VAF and can then be applied to the the original FPC using the following
formula: FPC * VAF. Once this has occurred the new FPC figure better represents the
estimated time and cost of a project as it now incorporates both functional and technical
requirements of the potential system. This will then provide both ASS and CrimTrac with a
realistic estimation of cost and time for the proposed project.
Page 42
4.2.3 Industry Data

This estimation technique shows industry data from similar projects in order to generate an
estimate. The Industry Data will be used in combination with the Three Point Estimating
technique in order to estimate the schedule and the budget for all non-software development
sections of developing the project. This estimation technique is chosen because the availability
of relevant data is in abundance and provides insight into similar projects. This also helps
improve the management risks and helps improve management risks of the current project.
Numerous Data Points A variety of industry projects available.

Highly Relevant Data Majority of data is current information
Specific Data Exact Values and Time required.
4.2.4 Three Point Estimating

Three Point Estimating is a technique that is used optimistic, pessimistic and most likely to
calculate a final value. It was founded to provide a realistic and expansive presentation of many
features that cannot be addressed using other procedures.
Adding a certainty of clarity to the estimation
Normalize the variety of data

Regulate any overly optimistic Data.
The formula is listed below:
Expected = (Optimistic + 4 x Most Likely + Pessimistic) / 6
Page 43
4.3 Estimation
4.3.1 Software and Firmware Estimation
4.3.1.1 Hardware Procurement

The estimation of this section of the hardware procurement was produced using Industry Data and
Three Point Estimating techniques including market research. This result had a total of 6 sources.
Budget (for scanners)

Most Likely
AUD $77,000.00
Optimistic
AUD $56,000.00
Pessimistic
AUD $98,000.00
Expected = AUD $77,000.00
4.3.2 Software Estimation

4.3.2.1 ASS Server Management Software Licensing
The required software licensing for software was produced by Industry Data and Three Point
Techniques. 5 sources were compiled. This includes the Server Management Software Licensing,
Operating System Licensing and the ASS Customization.
Most Likely
AUD $274,200.00
Optimistic
AUD $156,000.00
Pessimistic
AUD $350,000.00
Page 44
4.3.1.1 NAFIS Replacement System

To best estimate the overall cost and time required to implement the system to CrimTracs
requirements the Function Point Counting, Value Adjustment Factor, and Function Point
Adjustment techniques were applied. By analysing the Software Functional Requirements (See
section 2.2.2) following tables was produced. As the project team is tasked with only delivering
the software application and the firmware for Crimtrac, it was only necessary to do estimation in
regards to the software and the firmware.
4.3.1.2 Software Function Point Counting
ID
Functionality
Type
Complexity
FP
FPC1
Software will be able to store, and transmit data (First Name,

Last Name, Drivers Licence Number, Fingerprint Scan,
Palmprint Scan, Footprint Scan, Facial Recognition Photo, and
Demographic Data) between all user devices within the system.
ILF
5 RETs
8 DETs
= Low Complexity
5 Expected RETs (Personal Details, Fingerprint Data, Palmprint

Data, Footprint Data, and Facial Recognition Data)
8 Expected DETs (First Name, Last Name, Drivers Licence
Number, Fingerprint Scan, Palmprint Scan, Footprint Scan,
Facial Recognition Photo, and Demographic Data)
FPC2
Software will be able to handle the creation of new data entries,

as well as editing of existing entries and then transmit it to the
database.
EI
5 FTRs
8 DETs
5 Expected FTRs (Personal Details, Fingerprint Data, Palmprint

= High Complexity
8 Expected DETs (Uses same DETs from FCP1)

FPC3
Software will be able to compare a subset of Biometric data with

a supplied piece of Biometric data, and return a match, and all
of its relevant details, if found.
EO

5 FTRs
8 DETs
= High Complexity
Page 45
FCP4
Software will be able to communicate with other relevant

external parties and link appropriately with Identity Records
within in them
EIF
6 FTRs
8 DETs
6 Expected RETs (Personal Details, Fingerprint Data, Palmprint

Data, Footprint Data, Facial Recognition Data, and Identity
Record)
= Average Complexity
FCP5
All records that are stored within the system will have the ability
to be searched, viewed, and extracted by all devices that are
connected to the system.
EQ
5 FTRs
8 DETs

= High Complexity

FCP6
A Dashboard Service on mobile devices will provide the user

with real time monitoring of the status of system processes and
performance
EQ
6 Expected FTRs (Real-time Monitoring of Matching Status,

Workload Stats, Matching Outcomes, Job Scheduling, System
Availability, System Performance)
6 FTRs
17 DETs
= High Complexity
13 Expected DETs (Person's Name being Matched, Drivers

License Number of the Person being Matched, Biometric Data
that is being checked, Current Data the Biometric Data is being
checked against, Status of Search, Time Search has being run,
Total Number of searches that being Performed across the
Whole System, Number of Completed Searches the System
has Performed, Number of Searches in the Backlog, Queued
Searches, Percentage of System Capacity Available, Estimated
Time of Completion of a New Search, Average Speed to
Complete Search)
FCP7
Software will be able to use a Data Exchange Service to convert EO

and exchange data between users and external agencies
6 FTRs
8 DETs
Data, Footprint Data, Facial Recognition Data, and Destination
= High Complexity
Page 46
Database)
FCP8
Software will be able to generate reports at the user's request.

Types of reports include: Demographic Details, Biometric Data,
Fingerprints, Palm Prints, Face Images, Enrolment Data
Records, and User Reports
EO
7 FTRs
16 DETs
= High Complexity

Data, Footprint Data, Facial Recognition Data, User Details, and
Enrolment Data Records)
16 Expected DETs (Uses same DETs from FCP1 as well as
User Name, User ID Number, Searches Requested, Searches
Completed, Number of Entries Added, and Number of Entries
Edited)
FCP9
Firmware will allow standardisation of input to allow for the data

to be of a standard to be read straight into the system
EI
5 FTRs
8 DETs
= High Complexity
8 Expected DETs (Same DETs as FCP1)

Total
58
4.3.1.3 Value Adjustment Factor
No.
Characteristic
Value
Comment
Data Communications
As there are multiple outside agencies

that transfer and exchange stored
information this is a strong influence on
the operation of the system.
Distributed Data Processing
As the system is going to be installed on

central servers and then accessed over
long distances, processing functions will
be handled by use of the spreading it over
the whole network.
Page 47
Performance
The user needs the system to be

performing at its as fast as possible to
allow for quick processing of searches, it
imperative that response time is a quick
as possible.
Heavily Used Configuration
The current platform is heavily used as it

the central location of the data being used
as such, the new system will need to be
able to cope and exceed expectations to
achieve results. The new system will be
accessed from multiple sites and will
need the support to function correctly.
Transaction Rate
This part of the system may vary but it is

expected that use of the system will be
next to constant and as such will need to
be able to cope with multiple transaction
occurring at the same time.
Online Data Entry
Most of the data that is being added to

the system will come from sites that are
external to the central server and as such
will need to be updated with new data as
it is obtained.
End User Efficiency
The system is designed with both ease of

use and efficiency in mind for the end
user as it needs to be quick and easy to
use for swift data collection and
comparison with other Biometric data
stored within the system.
Online Update
As stated above in Online Data Entry,

most data will be entered Online and will
then be transmitted back to the central
servers for storage.
Complex Processing
The Application will need to perform a

variety of complex operations, including
but not limited to the comparisons
between two Biometric samples to
determine whether they are a match,
processing externally supplied data sets
etc.
10
Reusability
As this system on a whole was

specifically design for the use of CrimTrac
and its partners, it will not be able to be
reused for future projects.
Page 48
11
Installation Case
As the servers will be a central location

there will be no need for any hardware to
be installed at any of the locations the
System will be used, but the application
itself will need to be installed in all
locations the system will be used.
12
Operational Case
All backup operations will be automated

to occur twice a day to ensure that as
much data is stored correctly, and is able
to ensure that recovery operations are as
comprehensive as possible
13
Multiple Sites
The application will need to be installed in

as many locations that CrimTrac
determines to be appropriate, estimated
to be in hundreds, if not thousands.
14
Facilitate Change
As the requirements have been

comprehensively documented by
CrimTrac and the project team, the
possibility of any change to them is
minute.
Total Degrees of Influence (TDI)
56
Value Adjustment Factor = (TDI * 0.01) + 0.65

Value Adjustment Factor = (56 * 0.01) + 0.65
Value Adjustment Factor = 1.21
4.3.1.4 Function Point Adjustment
Incorporation of the Value Adjustment Factor
The Function Point Count result calculated in 4.3.1.2 only took into account the functional
requirements laid out in 2.2.2 for the software, and not any other requirements. As such it is
necessary to incorporate the Value Adjustment Factor that was calculated in 4.3.1.3 to better
represent the effort necessary to complete the project.
Adjusted Function Point Count = Function Point Count * Value Adjustment Factor
Adjusted Function Point Count = 58 * 1.21
Adjusted Function Point Count = 70.18
Page 49
4.3.1.5 Converting Function Points to Meaningful Metrics

Once the Function Point Adjustment has being completed to accurately represent the effort of
creating the the new system for CrimTrac, the COCOMO II estimation tool was then utilised to
produce the following meaningful metrics:
Effort: 14.8 Person-Months

Schedule: 14.3 Months
Page 50
5. Schedule
Revision History
Date
Ver.
Author
Addition/Alteration
22/09/2015
2.2
Brenton Millers
Created Gantt Chart
23/09/2015
2.2
Brenton Millers
Continued adding items to Gantt Chart
24/09/2015
2.2
Brenton Millers
Continued adding items to Gantt Chart
25/09/2015
2.2
Brenton Millers
Added all the predecessors to the document.
16/10/2015
3.2
Brenton Millers
Fix predecessors in the Gantt Chart for network diagram.
Both the GANTT Chart and Network Diagram are within the file called
NAFIS_Replacement_GANTT_CHART_Updated.mpp
This file must be opened within Microsoft Project.
PLEASE NOTE: As per conversation with Leigh-Ellen, the network diagram generated within
Microsoft Project is sufficient for submission.
Page 51
Page 52
6 Budget & Procurement

Revision History
Date
Ver.
Author
Addition/Alteration
22.09.15
Sam OSullivan
Original breakdown of the budget.
15/10/2015
3.0
Benjamin Ivarsson
Drafted initial procurement plan; need Brentons assistance on

establishing what were actually procuring.
17/10/2015
3.0
Benjamin Ivarsson
Wrote the Procurement Plan, section 6.2 - 6.3; awaiting approval.
16/10/2015
3.1
Brenton Millers
Made adjustments to 6.2.1 to align better with rest of document and

project vision.
18/10/2015
3.1
Samantha OSullivan
Integrated Budget
18/10/2015
3.1
Samantha OSullivan
Final Adjustments to budget
6.1 Budget
The unit costs used for each hardware item was estimated from market research.
Item
Cost
Quantity
Total
Finger Print Scanner - Suprema

RealScan - F Live Scan
$7900.00
$15,800.00
Palm Print Scanner - Suprema

RealScan - F Live Scan
$7900.00
$15,800.00
Foot Print Scanner - Scan 500P

Live Scan Footprint, 10 Ties and
Footprinting
$8600.00
$17,200.00
Facial Recognition - Sensorg I900

Live Scan Facial Recognition and
Retina Scanning
$9000.00
$18,000.00
Camera - Sony Alpha Black A1000
$9900.00
$9,900.00
Total Hardware Budget
$76,700.00
Page 53

The required software licensing for software was produced by Industry Data and Three Point
Techniques. 5 sources were compiled. This includes the Server Management Software Licensing,
Operating System Licensing and the ASS Customization.
Most Likely
AUD $274,200.00
Optimistic
AUD $156,000.00
Pessimistic
AUD $350,000.00

The Miscellaneous Budget was designed using Three Point Estimation and there are 7
resources found.
Most Likely
AUD $50,000.00
Optimistic
AUD $32,700.00
Pessimistic
AUD $92,300.00

The estimation for the software installation and scheduling were produced using a combination
of Industry Data and Three Point Estimating techniques. This also included using information
from the Australian Government Fair Pay Agreement. Including AGFP 20 sources were used to
find the results.
Schedule (per staff member)
Most Likely
AUD $79,488.00
Optimistic
AUD $60,434.00
Pessimistic
AUD $98,040.00
Page 54

The estimate for the budget and scheduling for staff training were produced using a combination
of Industry Data and Three Point Estimating techniques. Although 92 Staff Members. As a result
of research a total of 22 resources were found. The findings are estimated below.
Schedule (per staff member)
Most Likely
AUD $2,024,000.00
Optimistic
AUD $1,500,045.00
Pessimistic
AUD $4,546,091.00
Expected = AUD $1,345,022.67

6.1.1.6 Project Management and Support Team
The estimates for the Project Management and Support Team were produced using a
combination of Industry Three Point Estimation. All job roles were broken down into three point
estimations (see appendix A) then added together.
Quantity
Job Role
Single Salary
Subtotal
Senior Programmers
$120,000.00
$1,200,000.00
Junior Programmers
$80,000.00
$400,000.00
Senior Database
Administrator
$160,000.00
$400,000.00
Cryptographs
$60,000.00
$150,000.00
Project Manager
$252,000.00
$315000.00
Business Analyst
$90,000.00
$112,500.00
Expected = AUD 2,577,500.00
Page 55
6.1.2 Cost Management

The unit costs used for each hardware item was calculated using the estimation process
outlined in section 4.2 Hardware Estimation
Item
Unit Cost
Quantity
Total
11
$7,000.00
$77,000.00

$77,000.00
The unit costs used for each hardware item was calculated using the estimation process
outlined in section 4.3.2 Software Estimation
Item
Unit Cost
Quantity
Total
Software
11
$7,000.00
$77,000.00

$77,000.00

The unit cost for the Miscellaneous Budget items was calculated using the process outlined
section 4.3.3 Miscellaneous Budget.
Item
Unit Cost
Quantity
Total
Miscellaneous Budget
11
$7,000.00
$77,000.00
$77,000.00
Page 56

The unit cost for the Installation Budget was calculated using the estimation process outlined in
section 4.3.4 Installation Budget
Item
Unit Cost
Quantity
Total
Installation Budget
11
$7,000.00
$77,000.00

$77,000.00

The unit cost for the Training Budget was calculated using the estimation process outlined in
section 4.3.5 Training Budget
Item
Unit Cost
Quantity
Total
Training Budget
11
$7,000.00
$77,000.00

$77,000.00
6.1.2.6 Project Management and Support Team Budget

The unit cost for the Project Management and Support Team Budget
was calculated using the estimation process outlined in section 4.3.4 Installation Budget
Item
Unit Cost
Quantity
Total
Project Management and Support Team

Budget
11
$7,000.00
$77,000.00

$77,000.00
Page 57
6.1.2.7 Overall Project Budget
Item
Total
Hardware
See: 6.1.1.1 Hardware Budget
$77,000.00
Software
See: 6.1.1.2 Software Budget
$130,034.00
Miscellaneous
See: 6.1.1.3 Miscellaneous Budget
$29,167.34
Installation
See: 6.1.1.4 Installation Budget
$79,404.34
Training
See: 6.1.1.5 Training Budget
$1,345.022.67
Project Management & Supporting Team

6.1.1.6 Project Management Budget
$2,577,500.00
Total Project Budget
$4,238,128.35
6.1.2.8 Budget Estimation

The estimation techniques that were used include Function Point Counting, Function Point
Value Adjustment, Industry Data, and Three Point Estimating. For more information about any
modifications made refer to section 4.
6.1.2.9 Changes to the Budget

All modifications of the budget will be performed through the correct process and any changes
that must be changed will be accompanied by a Budget Change Proposal. Each month the
Project Manager and the Business Analyst will conduct a budget meeting, after analyzing the
new budget it will be analyzed by the Project Manager and the checked over by the
Stakeholders.
Page 58
6.1.2.10 Expenditure Reports and Cost Tracking

-
Each month a report will be generated to track expenditures.

Consultants and contractors will be required to submit timesheets detailing the hours
worked and tasks performed. A work breakdown structure will be converted to expenses
to assist in the cost of the whole project.
6.1.2.11 Managing Cost Variances

Cost performance will be monitored under a 5% baseline estimate. If there is a massive
threshold variance, a justification report is to be written and documented. The project manager
will need to access the variance. If the variance does not affect the cost baseline, then no
further action is no required. If there is a massive variance than stakeholders will need to be
involved.
6.1.2.12 Cost Control

All controlled costs will measure the progress against the budget the earned value management
will also be applied throughout the course of the project.
6.1.2.13 Work Performance Information

Whilst watching the costs and measuring performance throughout the documentation the team
manager will show and calculate the Cost Variance, Schedule Variance, WBS item ect. These
measures of performance will be measured and review to stakeholders.
6.1.2.14 Cost Forecasts

At the each project milestone the performance of the project will be given to the project
manager. With an overall expected costs to finish the project, each month. Overall this
procedure aims to control any major influxes in the budget.
Page 59
6.2 Procurement
6.2.1 Planned Procurements
To fulfill the requirements of the project, ASS will be procuring hardware and software; hardware
will be sourced from contractors outside of the organisation, while all software and firmware will
be developed by ASS, ensuring the security of the project.
As the project will affect law enforcement agencies and organisations across all of Australia, the
contracted hardware vendors must be reputable companies who deliver safe, secure and
reliable components. It is critical that the necessary security for delivered hardware align with
the requirements of the project, as to not endanger the project.
ASS will procure the following for CrimTrac, with associated costs detailed in section 6.1
Finger Print Scanner - Suprema RealScan - F Live Scan

Fingerprint Firmware
Palm Print Scanner - Suprema RealScan - F Live Scan
Palmprint Firmware
Foot Print Scanner - Scan 500P Live Scan Footprint
Footprint Firmware
Facial Recognition - Sensorg I900 Live Scan Facial Recognition and Retina Scanning
Facial Recognition firmware
Retina Scanning Firmware
Camera - Sony Alpha Black A1000 for Facial Recognition Use
Page 60
Software Procurement
NAFIS System
Web-Based UI
Fingerprint Module
Palmprint Module
Footprint Module
Biometrics in a Box
Mobile Application
Matching Algorithm
NAFIS Administration Console Software
Biometric Scanning Firmware (shipped with hardware)
Change Management Database
Contracted Work
NAFIS System Replacement Installations

Web-Based UI
Fingerprint Module
Palmprint Module
Footprint Module
Change Management Database
Matching Algorithm Implementation
Mobile Application
System Training
Scanner Hardware Training for End-Users
System Training for System Administrators
System Maintenance Training
System Use Training for System End-Users
Page 61
6.3 Procurement Management

Procurement management is controlled by the Project Team as well as an appointed Contract
Manager. The Contract Manager is responsible for ensuring a high quality of product or service
being contracted, and ensures that requirements are stated and met for each contract.
6.3.1 Establishing Procurement

For the procurement of hardware, software and contractors, ASS will approach multiple vendors
whom are judged reputable and leading in the field. These contractors has to deliver a high level
of service and go through a formal evaluation of their products and/or services.
All proposals will then be assessed by the Project Team, at the discretion of the Contract
Manager. If found acceptable, the successful vendor will undergo further evaluation nd trial
before they can be awarded a contract. This will ensure a high quality of hardware and software,
as well as services delivered.
Tasks not outlined in the projects WBS and which stray from the critical path of the project will
attract penalties to the contractor. Completion of the task on time and to a high standard will
incur bonuses. These incentives are to ensure a timely delivery of services and products so the
project remains on schedule.
A budgetary limit will be set on contractors as to not overspend on the budget. ASS will be
developing most of the software in house to reduce expenditure.
6.3.2 Managing Procurement

Contracts for procurement are managed by the Contract Manager, ensuring all contracted work
is completely listed in each contract ASS employs. For each contract, the Contract Manager is
required to do performance reviews and audits, to ensure a high quality standard of work is met.
The Contract Manager is also responsible of ensuring that contracts are completed on time and
according to budget.
Work cannot be completed unless listed in the contract; as such, independent contractors
cannot have innovative freedom with any contracted work. Work required which is not listed in
the contract has to be added by lodging a change order with the Contract Manager, signed by
both the contractor and the Change Manager.
This process can only go through the Change Control procedure (established in section 7.1.2),
and cannot be modified unless issued following this procedure.
Page 62
If too many changes to the contract are required (baselined to 40% of the original contract, or as
determined by the Contract Manager), the contract will be cancelled and a new one can be
issued.
Any and all correspondence between contractors, vendors and ASS will be documented and
logged by the Contract Manager, archived in the Change Management Database. This ensures
a record of changes which can be obtained and tracked through the project development.
6.3.3 Finalizing Procurement

Upon the completion of a contractor or vendor contract, the Project Team and the Contract
Manager will integrate the completed contract into the project.
Any finalized projects will be documented by the Contract Manager, recorded into the change
management database. This serves to record and archive any changes made outside of the
ASS project team.
The Contract Manager will then write a review of the contract results, archiving the contract and
its results for future use and for end-of-project review.
Page 63
7. Change Control Plan

Revision History
Date
Ver.
Author
Addition/Alteration
22/09/2015
2.1
Benjamin Ivarsson
Wrote section 7.1.1
22/09/2015
2.1
Benjamin Ivarsson
Made Hierarchy Chart Diagram
22/09/2015
2.1
Benjamin Ivarsson
Wrote Section 7.1.2 and added diagram
22/09/2015
2.1
Benjamin Ivarsson
Wrote Change Request Form template and Change Request Log

template
24/09/2015
2.1
Benjamin Ivarsson
Wrote Audits and Reviews (section 7.1.3)

Wrote section 7.2 (Configuration items)
16/10/2015
3.0
Benjamin Ivarsson
Went through revision for section 7.1-7.2; did not change the diagram.
Did not change change feasibility as it is elaborated upon in the audits
and reviews (section 7.1.3).
Change Request form was made and has been in the drive since start
of project; Brenton just forgot to upload it with the submission.
7.2 revised; couldnt find further phases established and no response
from Brenton about phases
7.1 Change Control

7.1.1 Change Control approach
For approaching changes in the project, ASS and CrimTrac will establish a joint Change
Advisory Board which will assess the necessity of a change and then approve or reject the
change. Any changes to the project will be logged by the Project Manager as either approved or
rejected.
To approach change of the project, any requests for changes from either the Project Team or
Direct Stakeholders has to be assessed by the Project Manager. If the Project Manager finds
the changes to be possible or necessary, the Project Manager will request approval Project
Sponsors and Change Advisory Board. The Project Manager acts as an intermediary between
ASS and Change Advisory Board. Changes has to follow by the change control hierarchy
structure below.
Page 64
If the Change Advisory Board approves or rejects a proposed change, the Project Manager will
go through the Change Control Procedure (7.1.2) to notify the initial change proposer.
7.1.2 Change control procedure
How to Raise Changes

To raise a request for change, direct stakeholders has to fill out and lodge a Change Request
Form (see Appendix A) with the Project Manager. If the Project Manager finds the change
request feasible, the change request will be put forward for project team review. Reviewed
changes has to be approved or rejected by project sponsors and Change Advisory Board
established with CrimTrac.
Page 65
The Project Manager is required to review any submitted Change Request Forms (see attached
documents) as soon as possible for the change request to be available before each team
meeting. This is to assess whether the change is possible for the project team to implement
before the change is put forward to the Change Advisory Board.
If the project team detects any changes which needs to be made, these changes has to be
raised to the Project Managers attention at the next team meeting. The project manager has to
be immediately notified if any critical changes are made to the project.
Indirect stakeholders, such as users of the system, system testers and staff may put forward
feedback and suggestions to the project team for review.
Change documentation and tracking

Every change proposed by direct stakeholders has to be documented through lodged Change
Request forms, dated and ordered into online cloud storage.
Document and project changes by the Project Team are documented and tracked through
revision history for each segment changed.
The project manager must also manage all change requests by keeping an up to date log for
each request. The change request log records changes requesting information about who
submitted the request, what the request was, evaluation of the request, if the request was
approved or rejected and which stakeholders has been notified about the request status. By
doing this, the project manager can keep track of which changes has yet to be approved by the
CrimTrac board of directors, and knows which changes to review and put forward to CrimTrac
for approval.
To ensure the maintenance of the Change Request Log, the project manager is solely
responsible for the Change Request Log being up to date and requests arent missed.
For the Change Request Log, the Project Manager requires a numbered list of changes to be
processed, date when change request was lodged, who requested the change, a description of
the changed used for feasibility analysis, a status indicator (Approved/Rejected) and a date of
when affected stakeholders were notified about the change status.
Below is an example of the Change Request log used by the Project Manager.
CHANGE APPROVAL RESPONSE DETAILS

(To be completed by Management/Project Manager according to project governance)
Approved (Yes/No)
Decision date
Decision made by
Decision reason
Resulting Action
Page 66
Change Request Evaluation

Change requests are evaluated to assess if the changes are within the project scope, and the
Project Manager will assess if the changes are necessary and possible.
Any changes outside the project scope, the Project Manager and the Project team must assess
if the change is feasible. Once a decision is made, the change has to be approved by
CrimTracs board of directors before any changes can be implemented.
Minor changes, such as documents being extended or updated does not require the approval of
CrimTracs board of directors.
Page 67
Assessing change feasibility
Is the change within project scope

Is the change optional or required for project completion
What are the change benefits
How much will the change cost and affect the project budget
How much time will it take to implement the change and how will it affect the project
schedule
How is the risk assessment altered by the change, or will the change create new risks
7.1.3 Audits and review
For this project, it is required of the Project Manager to hold continuous, weekly review meetings
with the Project Team. During these meetings, Team members will discuss the progress of the
project and review what has been done during the week. This will enable the Project Manager to
confirm with the Project Team that required functionalities are being implemented, and that the
project is developed according to the project scope.
When an increment has been completed, the Project Team will demonstrate how the developed
modules work for the Project Manager to establish full functionality according to project
requirements.
Additionally, the project progress has to be documented at each Team Meeting, and then added
into the project status report by the end of each meeting. This is to make sure that every
meeting is recorded and that variations from defined scope can be dated. By doing this, any
variations in increments can be dated to a set increment meeting, and can meet with
responsible Team members. By doing this, any anomalies in development can be corrected
before any critical errors affect the project.
Before each meeting, developed increments has to be internally tested by responsible
developers as well, so that they may be demonstrated in the weekly meeting. These tests has to
conform to the requirements of the project, and can only be assessed as complete by the
Project Manager and Change Advisory Board.
Page 68
7.2 Configuration Management

7.2.1 Configuration items
Documents
ID
D1
Configuration Item
Project Charter/Project
Document Outline
Baselines
Version(s) 1.0, 2.0, 3.0
+
+
D2
Project Scope Statement
Version(s) 1.0, 2.0, 3.0

+
+
D3
Project Work Breakdown

Structure
Project Estimation
Project Schedule
+
+
Project Budget
Increment version 1.0 baselined in Project

Planning, Phase 1
Changes to Project Estimation will require reevaluation or re-baselining
Version(s) 1.0, 2.0, 3.0

+
D6

Planning, Phase 1
Affected task changes which need to be
completed will require the Work Breakdown
Structure to be re-baselined
Changes to previously completed tasks from the
Work Breakdown Structure will require approval
from Change Advisory Board: if approved, the
Work Breakdown Structure will require rebaselining and to be re-established
Version(s) 1.0, 2.0, 3.0

+
D5

Planning, Phase 1
Changes to Project Scope has to be approved by
Change Advisory Board; changes to Project
Scope will result in Project Scope being reestablished
Version(s) 1.0, 2.0, 3.0
D4

Planning, Phase 1
Changes has to be approved by Change Advisory
Board; any critical changes will lead to project
outline being re-established and re-baselined

Planning, Phase 1
Any changes to schedule will require Project
Schedule to be re-baselined
Critical changes to schedule will require the
Project Schedule to be re-established
Version(s) 1.0, 2.0, 3.0

+

Planning, Phase 1
Page 69
D7
Project Change
Management Plan
Version(s) 1.0, 2.0, 3.0

+
+
D8
Project Change Control

Plan
Project Change
Request/Log Documents
Project Risk Management

Plan
System & Hardware

Testing plans
System & Hardware User

Testing plans
User/Administration
Supporting Documents

Planning, Phase 1
Changes to System & Hardware Testing plans will
require re-baselining
Version(s) 1.0, 2.0, 3.0

+
+
D11

Planning, Phase 1
Risk Management is assessed before and after
each increment added onto project; if necessary
changes are identified, it will be re-baselined
Version(s) 1.0, 2.0, 3.0
D10.A

Planning, Phase 1
Changes to Change Request/Log Documents
require re-baselining
Critical changes will be assessed by Project
Manager; if necessary, pass change requests to
Change Advisory Board for approval
Approved Critical Changes requires Rebaselining and re-establishing of Project Change
Request/Log Documents
Version(s) 1.0, 2.0, 3.0
D10

Planning, Phase 1
Changes to Project Change Control Plan needs to
be approved by Change Advisory Board; if
approved, re-baseline
Minor Changes can be approved by Project
Manager; changes will require re-baseline
Version(s) 1.0, 2.0, 3.0
D9

Planning, Phase 1
Major Changes to Project Management Plan
requires re-baselining
Version(s) 1.0, 2.0, 3.0
D8.A
Changes to project Budget needs to be approved

by Project Sponsors and Change Advisory
Board; If approved, Project Budget will be reestablished
If Project Manager assesses the changes to be
minor, Budget will be re-baselined

Planning, Phase 1
Changes to System & Hardware User Testing
plans will require re-baselining
Version(s) 1.0, 2.0, 3.0

+
+

Planning, Phase 1
Requires re-evaluation and re-baselining after
Page 70
user testing
D11.A
System & Hardware

Maintenance Documents
Version(s) 1.0, 2.0, 3.0

+
+

Planning, Phase 1
Changes to system and hardware requires
Maintenance Documents to be re-evaluated and
re-baselined
Reports
ID
R1
Configuration Item
Configuration Audits and
Reviews
Baselines
Version(s) 1.0, 2.0, 3.0
+
R2
R3

Planning, Phase 1, further baselines as
development progresses through phases (after
each increment test)
Following project review audits have been
approved, re-baseline
Implementation Success
Analysis
Version(s) 1.0, 2.0, 3.0
System & Hardware Test

Results
Version(s) 1.0, 2.0, 3.0
+
+


Changes following results from System &
Hardware Testing will require re-baselining
Critical changes following results from System &
Hardware Testing will require approval from
Change Advisory Board before re-baselining
affected functions
Hardware and Systems

ID
Configuration Item
HS1
System and Database

Design
Baselines
Version(s) 1.0, 2.0, 3.0
+
+

Implementation, Phase 4
Changes to the system or database will need to
Page 71
be approved by Change Advisory Board; changes

requires re-baselining
HS1.A
Module Software/System
Components and Mobile
Applications
Version(s) 1.0, 2.0, 3.0

+
+
+
HS2
Hardware Configuration
Version(s) 1.0, 2.0, 3.0

+
+
+
HS2
Firmware

Changes require re-evaluation and re-baselining
Critical Changes and new rollovers requires
approval from Change Advisory Board

Changes to hardware requires re-baselining
Changes which affect more than hardware
(Budget, schedule etc.) requires prior approval
from Change Advisory Board; changes will
require re-baselining as well as conform to
baselines for other affected Configuration Items
Version(s) 1.0, 2.0, 3.0

+
+

Changes to firmware requires testing and
approval from Change Advisory Board; changes
then require re-baselining
Contracts
ID
Configuration Item
C1
Tender Contract
Baselines
Version(s) 1.0, 2.0, 3.0
+
+
C2
Vendors and Suppliers
Version(s) 1.0, 2.0, 3.0

+
+
C3
Subcontractor Contracts
CrimTrac Contracting
Agencies/Affiliates

Planning, Phase 1
Changes to Vendor and Supplier contracts
require a re-baselining of the contract
Version(s) 1.0, 2.0, 3.0

+
C3.A

Planning, Phase 1
Changes to Tender Contract requires rebaselining and re-establishment of Tender
Contract

Planning, Phase 1
Changes to Subcontractor contracts requires rebaselining of contracts
Version(s) 1.0, 2.0, 3.0

+
Page 72
Planning, Phase 1
Requires approval from Change Advisory Board;
any changes to contracted Agencies and
Affiliates requires re-establishing of contracts
Configuration items connected to this item
requires re-baselining and follow configuration
management regulations for affected items
7.2.2 Configuration Management System

Change Control Board (CCB)
As the tender requires an extensive amount of work, a CCB will be established to oversee the
configuration management. This board will consist of (a) the Project Manager, (b) the
Configuration Manager, (c) a CrimTrac Audit and a CrimTrac Risk Committee representative,
(d) a CrimTrac Finance Committee representative, (e) the individual(s) responsible for the
configuration item being re-evaluated and finally (f) the individual(s) responsible for proposed
change. This will be a manual process which requires regular meetings to work through
proposed changes.
ASS are proposing meetings with the CCB on a fortnightly basis to ensure consistency through
the project development, with additional meetings organized as required. A meeting is required
when the Project Manager and the Change Advisory Board deems it necessary.
Any logging will be supported through encrypted database storage provided by ASS and
managed by the Project Manager and the Configuration Manager.
The CCB will be responsible for:
Review of Configuration Change Requests, in response to Change Request Forms

Approving or rejecting change requests
Ensuring an accurate change control log is established and maintained, recording
proposed changes and their change status
Ensures change control documentation is stored on configuration management
database (CMDB) established by ASS for the use by CCB
The appointed Configuration manager will be responsible for:
Management of the CMDB provided by ASS

Identifying and monitoring configuration items
Additionally, the Project Manager will be responsible for all project related configuration. The
Project manager also has to identify and monitor any configuration items, establish meetings
with the CCB, in accordance to section 7.1.
Any re-baselining is performed by the Project Manager, together with the responsible project
Page 73
team. This is to ensure that the baseline compliance remains cohesive through the project
increments.
Configuration Control
Identified configuration items (CIs) will be assigned with a unique ID and a CI name and be
stored by the configuration manager on provided CMDB. With each approved configuration
item, the individual(s) responsible for the change identification is recorded with the CI. The CI
will then be marked for change implementation.
Change requests follow the process in section 7.1 and shown in the section 7.1 diagrams. Any
request has to be verified, evaluated and reviewed. Reviewed changes are then passed to the
Change Advisory Board for approval; if approved the changes are then re-baselined and
implemented. This process is not necessary for low risk, in-scope and budget changes, where
the project manager has the authority to approve or reject the change based on the project
managers own judgement. The Project manager may decide to involve the project team
members in collaboration on the decision, however the project team has no power to rule on a
change. If the change request was submitted by a stakeholder they are required to be kept
informed on the change request submission and outcome.
Medium- to High-risk changes needs prior approval from the CCB and CAB before any change
can be implemented. The CCB and CAB will evaluate whether the change is feasible, and if
approved the corresponding CI will be re-baselined before it is implemented. Stakeholders
impacted by evaluation and review, or whom submitted the change request of Medium- to Highrisk CIs is required to be notified and informed about the change request outcome.
The Configuration Management Database (CMDB)

To provide a secure storage location for any changes to configuration items for both the project
team and involved stakeholders, ASS will provide a centralized Configuration Management
Database. This database will be used to store, access and provide version control of CIs and
project specific information (such as Change Request Forms, Change Logs and
Documentation). This will ensure consistent access to most recent and latest versions of
developed documentation, softwares and system modules.
The provided CMDB will have three distinct storages which are organized into Documents,
Reports and Contracts. These storages may be accessed by the Configuration Manager, the
Project Manager and the Project Team. The access is limited to read/write access to ensure
Page 74
those which have the correct authority or permissions can access the storage. The system is
shown in below diagram.
Verification and Audits

To verify that configuration management goals are achieved, actual project process will be
compared to documented process. Project deliverables, functional and physical requirements
are compared with initial, interim and final testing results. Project increments will be
demonstrated and reviewed by the CCB. Results and increments will then be measured against
established success criteria and assessed if the criterion has been met.
Configuration management will perform audits at all medium- to high-risk project changes as
well as project critical points. The configuration manager will be responsible for these processes
and the outcome of these processes being consistent with the project constraints. Additionally,
the configuration manager will be responsible for the verification and auditing process to
determine whether the project activities shall continue.
Page 75
Configuration Manager Responsibilities and requirements:
Ensure CI version are correctly numbered and correct version control is in place
Analyze previous versions of documents and software
Comparison of current versions to expected results and success criteria
Report information and results from the auditing process
For each review, two audits can be performed; a Functional and a Physical Configuration Audit
(FCA and PCA respectively). Both audits are required to be provided for the appropriate
involved stakeholders.
Page 76
8. Risk Management Plan

Revision History
Date
Ver.
Author
Addition/Alteration
15/10/2015
3.1
David Ley & Samantha

OSullivan
Added information to the Risk Register
15/10/2015
3.1
Samantha OSullivan
Added information to sections 8.1, 8.1.1
15/102015
3.1
David Ley
Added information to sections 8.1.2
18/10/2015
3.1
David Ley
Added Probability/Impact Matrix and add information to 8.1.2.3,
18/10/2015
3.1
Samantha OSullivan
Risk Identification
18/10/2015
3.1
Samantha OSullivan
Qualitative Risk Analysis
18/10/2015
3.1
Samantha OSullivan
Addressing Risks
18/10/2015
3.1
Samantha OSullivan
Risk Assessment
18/10/2015
3.1
Samantha OSullivan
Risk Management Review
18/10/2015
3.1
Samantha OSullivan
Identifying New Risks
18/102015
3.1
David Ley
Risk Classification
18/102015
3.1
David Ley
Quantitative Risk Analysis
18/102015
3.1
David Ley
Top 10 Risks
18/102015
3.1
David Ley
Risk Scheduling
8.1 Risk Management Strategy

Risk management follows a basic three step approach including: risk identification, risk
clarification and addressing risks. It also identifies what actions will need to be taken if identified
risks happen.
8.1.1 Risk Identification

Identification of the problems that may occur is important, this project holds risks such as: cost,
schedule, effort, resource and technical risks, that may affect the project in someway. These
risks need to be identified and documented. The main concerns and risks that need to be
identified with the project are business risk, technical risk and the overall project risk. Risks
needed to be identified and then analyzed using the three techniques: documentation review,
Page 77
information gathering and SWOT analysis alongside the risk register. This will ensure that the
risks are identified quickly and continuously ensure a comprehensive identification of the risks,
in conjunction with this process a mitigation plan will need to be developed in the event of error.
Documentation Review
- The overall planning documentation will be reviewed by the project manager at
the end of the planning phase, after the project manager has checked the
documentation any subsequent updates or modifications are made. This gives
the leader a great indicator of the risks involved in the project and the technical
risks and any risks that may affect the budget or timing constraints. Major
technical risks include the old system crashing when the integration of the new
system with the old system. For preventative measures this project will use
multiple techniques.
SWOT Analysis
- The SWOT analysis is performed late in the planning phase of the project when
the specifications of the project is known. A collaboration will be done to identify
the strengths and weaknesses, opportunities and the threats to the project. With
this information being available it allows the team to use the strengths and
opportunities. To ensure steps are taken to rectify the weaknesses and prevent
threats.
- Information Gathering
This technique is revolved around four sub-techniques including the Delphi technique,
brainstorming, interviewing and root cause analysis.
- Brainstorming will be used to develop a list of possible errors that may occur with
a risks analysis: with the assistance of team members. This will allow the team to
produce a comprehensive list before the development stage of the project
begins.
- The Delphi technique is where ideas about the project can be raised
anonymously from all areas of the project through questionnaires. Once all
functionality and the requirements of the system are known through the
technique the project team members will be able to analyze for specifications in
detail. This should allow for a greater risk identification as team members and
stakeholders are able to comment on the risks anonymously: this will full honesty
and a detailed critical analysis of any potential errors that the project could face.
- Interviews: A team member will talk to the project stakeholders to determine what
they believe the risks that may encounter. This interviewing technique will also
allow for a direct discussion with related parties about the project and a more
engaged and comprehensive discussion of possible threats and issues. With
development well under way there will be a greater understanding for the project
and the project team.
Page 78
The final technique is to develop preventative measures by specifically looking

for any problems after analysing the situation. Root cause analysis will be
undertaken as part of the final stage. A team member will brainstorm as many
possible errors and problem situations that may occur. Using this, the team will
analyse the situation to determine the percentage of the error occurring. The
team will then analyse each situation to determine the source of the problem and
what resolution can be made for the errors. The team will develop
documentations and implementations methods as a preventative method (for any
errors that may occur).
8.1.2 Risk Classification

The Risk Taxonomy is outlined once all risks have been evaluated. The risks will be assigned to
the correct category and been outlined in the Risk Taxonomy. Once this has been achieved any
further classification of risks need to to be ascertain to their probability of occurring and how
much of an impact the risks may have on the whole project.
8.1.2.1 Risk Taxonomy
The risks are outlined into different categories that best suits the attributes of the risks. These
risks are listed below and include:
Security
Ease of Use
Hardware
Software
Budgetary
Administerial/Managerial
Disaster
Information Technology
Financial Management
Communications
Business Process
HR Management
Legal
Privacy
Resource Management
Other/Miscellaneous
8.1.2.2 Qualitive Risk Analysis
Page 79
The risks will be placed into a register and there will be respective risk categories. In order to
perform qualitative risk analysis, the following methods will need to utilised. The impact
assessment method to determine what priority to allocate resources to mitigate risks, probability
of occurrence, impact, time-frame and the causes of risks. The matrix is than used to visually
display and analyse risk information as demonstrated below on the classification accordance to
this scale.
Probability/Impact Matrix Diagram
The data quality assessment method is performed to the quality of the information held in
relation to risks and how the information can be helpful, accurate and reliable. The classification
and categorisation of the risks refer back to four areas. Risk source which identifies the source
of the root. The root causes seeks to find and assess the underlying cause of the risk. The
project phase refers to the project alongside the testing. The last section of the project area is
affected to the aspect of the project that is affected (project scope). The most important risk
management technique is the risk urgency assessment method that identifies which risks are
most important with their indicators and the risks in the risk register.
Page 80
8.1.2.3 Quantitative Risk Analysis

The Project Manager has to approve any major decisions, although if the project manager is not
convinced that the qualitative risk is the best approach in the project, the next step is to carry
out a quantitative risk analysis. This technique can allow the gathering of additional information
for the risk analysis in the process of numerically analysing the effect of the overall project
objectives. For a large scale, security oriented project, the activity of carrying out a quantitative
risk analysis can be a large advantage, as the outputs of this process include:
Probabilistic analysis of the project

Probability of achieving cost and time objectives
Prioritised list of quantified risks
To achieve these outputs you can use a variety of different methods, these include:
Data Gathering and Representation Techniques: these include interviewing and using
expert judgement
Expected Monetary Value Analysis: this method is a statistical concept that calculates
the average outcome when the future includes scenarios of things that may or may not
happen.
8.1.3 Addressing Risk

Identified and classified risks in the register will be planned to the development of the
addresses, that mitigate and manage the risks. Risks will either be passively accepted, actively
accepted, transferred, or avoided. The techniques will be used to address different risk
strategies. The method chosen will depend on the specific risk, the assessment of the risk and
the situation and what action can be taken. To avoid a lot of risks it is recommended that
changes should be minimal. Mitigation refers to a process of reducing the risk to an acceptable
and tolerable level. Lastly the acceptance needs to be developed so that it can be executed if a
risk occurs. Techniques that will be used to address the risks included strategies for positive
and negatives risks or threats and contingent response strategies. An overall general mitigation
strategy for risks and strategies is outlined in the table below.
Technical Risks
Maximum team support to
avoid any stand-alone
structure of the project.
Communication is extremely
vital in the project between
the team and stakeholders
Cost Risks
Communication,
understanding the goals from
the stakeholders.
Schedule Risks
Discuss with the project

manager
Page 81
Project Manager Authority Only *

* If errors become highly catastrophic to the project or cause serious issues than only the
project manager can make the decision on what needs to happen.
-
Positive risks are those in which are beneficial to the project and project's objectives.
Acceptance can also be used as a method in this technique. Positive risks will either be
shared or enhanced. It is beneficial to the organisation that sharing any positives risks to
a third party who is able to make sure the risk will benefit the organisation in some way.
It enhances the capitalisation on the key factors that will influence the positive risk. This
method ultimately depends on the risk and situation of the team's capabilities.
Contingent Response Strategies are predeveloped tasks for specific risks and situations
also referred to as backup plan. The risks under this header are carefully monitored and
these strategies are only executed under specific predefined conditions. This technique
is only used for majorly unstable and highly complex risks that would not be served well
by the positive factor. The project manager is the only person who will be able to make
an assessment of the risk to determine whether a contingent response is required.
Generally, if it has a high impact on the matrix, there will be a contingent response
developed.
8.1.4 Unidentified Risks

Identifications of risks have been carefully analysed and strategized, with some potential risks
not being identified. In the event an unidentified risks occurs there will be an organised strategy
for the risk to be handled and solved. The risks identify into two categories listed below:
Unidentified risks that are yet to impact the project: These risks are discovered at a
later date than the risks that are identified in the Risk Register. These risks need to be
fully explored as what effect they have on the project, how they will be dealt with, and
the probability of them occurring. Once this has been achieved the newly identified risks
must added to the Risk Register as to ensure that is kept up to date.
Unidentified risks that have already impacted the project: These risks are the most
important to minimise any potential effect they have on the project. Steps must be taken
immediately to ensure they are properly identified and then dealt with, with as little
impact onto the project as possible. If this were to occur the Project Manager would
seek the assistance of senior Project Team members in order to deal with the
unidentified risk by allocating as many resources as needed in order to mitigate the
unidentified risk as much as possible. Methods to achieve this include brainstorming, as
it allows for the quick realisation of ideas to alleviate the risks impact on the project.
Once a plan of action has been identified it can then be implemented as quickly as
Page 82
possible to solve the problem. After this has occurred the Project Manager can then
formal identify the risk and then enter its details into the Risk Register.
8.2 Risk Monitoring Strategy

8.2.1 Risk Assessment
The project team will assess the risks with a different variety of techniques and monitor and
track risks for events. These activities such as the ones mentioned above include performing
qualitative and quantitative risk analysis with a probability matrix.
When performing the qualitative risk analysis, identified the risks are evaluated on the
probability of occurring and the potential impact it may have on the project and updated via the
risk register. By monitoring and tracking risks the project will benefit from assessment and
control and will minimize risks.
Quantitative risk analysis techniques are crucial to the project and the implementation of the
project including the collection of data, and the various modelling approaches and the
judgement by the risk owner. Quantitative risk analysis benefits the project by aiding the risks
which extends to assessing new risks throughout the project and the subsequent score and
revising the risk rank when it is needed when required.
8.2.2 Risk Review

For the development of the project it is to the project manager who is responsible for reviewing
risks and identifying the register through a variety of tools and techniques and strategies such
as the strategies above.
8.2.3 Top 10 Risks

This methodology is derived from the output of a qualitative risk analysis. The top ten risk item
tracking is reviewed any time there is a change to a risk. This identifies the top ten risks for the
risk management which can be used to update stakeholders of risks throughout the project.
ID
Rank
Event or
Risk
Risk
Taxonomy
Threat
or
Opportunity
Probability
Impact
Score
(P x I)
Risk
Strategy
Status
R11
Key
Stakeholders
are not
Communic
ations
Threat
10
50
Risk
Avoidance
Active
High
Page 83
impressed with
systems
performance
Priority
R7
Requirements
change during
development
Communic
ations
Threat
40
Risk
Mitigation
Active
High
Priority
R16
System servers
are hacked
Security
Threat
10
40
Risk
Avoidance
Active
R10
The security of
the system data Security
is not secure
Threat
36
Risk
Mitigation
Active
R23
Loss or
corruption of
project files
Software
Threat
10
30
Risk
Avoidance
Active
Government
body makes
changes to
legislation
regarding the
storing of
biometric data
Privacy
Threat
10
30
Risk
Acceptanc
e
Active
Project goes
over budget
during
development
Budgetary
Threat
28
Risk
Mitigation
External
devices
connected to
the system
arent updating
data
Information
Technolog Threat
y
24
Risk
Mitigation
Active
R13
External
devices
connected to
the system
arent
downloading
data
Information
Technolog Threat
y
24
Risk
Mitigation
Active
R1
10
The project
breaks a time
constraint and
Business
Process
21
Risk
Mitigation
Active
R25
R26
R12
Threat
Active
Page 84
is not ready for

the
implementation
on the due
date.
8.2.4 Risk Management Review

It is crucial to the project that the implementation of risk management review is beneficial by
achieving set objectives. These objectives are important by keeping awareness of the project
development by informing stakeholders about potential impacts that are able to affect the
project positively or negatively. The team needs to be aware of the strategies to minimise any
risks to the project. The review gives the stakeholders and overall review on outlined and
identified risks, strategies for dealing with the identified risks and risk strategies that are
currently being employed by the project team.
8.2.5 Identification of New Risks/Retirement of Old Risks

Once the project manager calls a meeting with the project team it allows the team to discuss
and identify any new risks to the project, during this time the other risks are reviewed and retired
if no longer relevant. Risks that are identified outside of this weekly meeting will be handled
according to the unidentified risk approach.
8.2.6 Risk Scheduling

While developing this project, the utmost importance of scheduling risk tracking activities has
been taken into account, so that risks are kept only as long as they are relevant and once they
are no longer relevant they are retired. The following table represents the previously discussed
monitored risk exercises and how frequently they are to be performed:
Monitored Risk Exercises
Review Frequency
Qualitative Risk Analysis
At the beginning of an increment, or is

deemed necessary by the Project Manager.
Probability/Impact Matrix
When old risks are retired and/or new risks

are identified.
Quantitative Risk Analysis
When deemed necessary by the Project

Manager.
Top 10 Risk Monitoring
When risks from the list are retired, other
Page 85
identified risks will take their place.

Risk Management Review
At the beginning of each increment.
Risk Register
Whenever a new risk is fully identified.
Identification of new risks/Retirement of old

risks
Weekly team meeting.
Page 86
8.3 Risk Register

During the development of the Risk Register, Probability and Impacts were estimated on a 1 to
10 scale (1 being Very Low Impact/Not Very Likely and 10 being Extreme Impact/Almost
Definite), through doing this it was able to be determined how likely and how large an impact a
risk may have if it were to occur.
Rank
Event or Risk
Risk Taxonomy
Threat
or
Opportunity
10
The project
breaks a time
constraint and is
not ready for the
implementation
on the due date.
Business
Process
Threat
21
Risk
Mitigation
Active
R2
16
Current system
crashes whilst
implementing
the new system
Information
Technology
Threat
12
Risk
Avoidance
Not
Active
R3
18
Users do not
engage with the
system
HR Management Threat
Risk
Mitigation
Not
Active
R4
11
If the hardware
is of poor quality
Hardware
Threat
21
Risk
Mitigation
Active
22
If the hardware
components are
faster than
expected
Hardware
Opportunity
24
Risk
Exploitation
Not
Active
R6
19
System
maintenance
interferes with
schedule of
implementation
Software
Threat
Risk
Avoidance
Not
Active
R7
Requirements
change during
development
Communications
Threat
40
Risk
Mitigation
Active
High
Priority
ID
R1
R5
Probability
Impact
Score
(P x I)
Risk
Strategy
Status
Page 87
12
Database
doesnt store
information
correctly
Information
Technology
Threat
21
Risk
Mitigation
Active
R9
13
The system
suffers from
constant
crashes due to
code defects
Software
Threat
10
20
Risk
Mitigation
Active
R10
The security of
the system data
is not secure
Security
Threat
36
Risk
Mitigation
Active
Key
Stakeholders
are not
impressed with
systems
performance
Communications
Threat
10
50
Risk
Avoidance
Active
High
Priority
External devices
connected to the Information
system arent
Technology
updating data
Threat
24
Risk
Mitigation
Active
External devices
connected to the Information
system arent
Technology
downloading
data
Threat
24
Risk
Mitigation
Active
23
No internet
connection for
external devices
to connect to
Information
Technology
Threat
27
Risk
Acceptance
Not
Active
R15
14
Supplied
biometric data
incorrectly
matched to
database
biometric data
Software
Threat
10
20
Risk
Mitigation
Active
R16
System servers
are hacked
Security
Threat
10
40
Risk
Avoidance
Active
R17
15
User manual not

Ease of Use
adequately
written
Threat
16
Risk
Mitigation
Active
R8
R11
R12
R13
R14
Page 88
24
Network
coverage not
able to transmit
data to and from
central servers
efficiently
enough
Information
Technology
Threat
27
Risk
Acceptance
Active
R19
25
Interference
from electrical
storms slowing
down data
transfer
Information
Technology
Threat
27
Risk
Acceptance
Active
R20
20
Project team
member get
pregnant
Risk
Acceptance
Not
Active
R21
21
Project team
member
diagnosed with
terminal illness
Risk
Acceptance
Not
Active
R22
26
Project team
member catches HR Management Threat
debilitating cold
25
Risk
Mitigation
Active
R23
Loss or
corruption of
project files
Software
Threat
10
30
Risk
Avoidance
Active
R24
17
Client goes
bankrupt
Legal
Threat
10
10
Risk
Acceptance
Not
Active
Government
body makes
changes to
legislation
regarding the
storing of
biometric data
Privacy
Threat
10
30
Risk
Acceptance
Active
R26
Project goes
over budget
during
development
Budgetary
Threat
28
Risk
Mitigation
R27
27
The Empire use

the Deathstar to
blow up Earth
Disaster
Threat
10
10
Risk
Acceptance
R18
R25
Page 89
Active
Not
Active
R28
28
Zombie
Apocalypse
Disaster
Threat
10
10
Risk
Mitigation
Not
Active
R29
29
Y2K bug strikes

late
Information
Technology
Threat
Risk
Acceptance
Not
Active
30
Brenton
accidentally
overrides all
project data with
Taylor Swift
songs
Information
Technology
Threat
10
10
Risk
Avoidance
Active
10
10
Risk
Acceptance
Active
R30
R31
31
Team-member
ruptures
something
(again) and has
to defer
Page 90
9.0 Project Review

Revision History
Date
Ver.
Author
Addition/Alteration
12/08/2015
1.1
Benjamin Ivarsson
Took notes for section 9.1
14/08/2015
1.1
Benjamin Ivarsson
Wrote section 9.1
16/08/2015
1.1
Benjamin Ivarsson
Outlined Section 9.3
28/08/2015
1.2
Benjamin Ivarsson
Adjusted Section 9.3 to match Lewis Carrols recommendations.
21/09/2015
2.1
Benjamin Ivarsson
Updated the Scheduled Reporting with additional deliverables
15/10/2015
3.1
Benjamin Ivarsson
Revised and updated section 9.3,

Added my statement to 9.5
18/10/2015
3.2
Benjamin Ivarsson
Revised 9.1
9.2, Project Achievements
17/10/2015
3.2
Brenton Millers
Added Items into section 9.4
18/10/2015
3.2
Brenton Millers
Added my input into section 9.5
Page 91

For the success of this workbook, all members of the team joined together based on the
common goal; we all strive to excel in this degree and this course. This will lay a foundation for
our future careers, giving us an edge against other competing graduates in our field.
Thus, our success criterias are to:
Individually receive at least a 6(80%) on the first submission (Workbook 1); if lower than
6, work to improve for second submission (workbook 2) to get at least a 6; if 6 or higher,
strive to excel for next submission (workbook 2) and get a 7(90%), which well then
attempt to keep for the final submission (workbook 3) of the workbook.
To excel in the course and become knowledgeable in our field.
Gaining a solid, usable experience with the tools of the industry
Properly applying industry tools and standards into our workbook, so that we can in the
future use these tools in our field
To gain simulated real world experience of how the IT industry actually work so that we
are prepared for not just future courses but our future careers.
Page 92
9.2 Project Achievements

Workbook 1
Success Criterias
Criteria Met
Discussion
A team average of a GP
6(>80% mark) or above on
Workbook 1; Individual
scores reaching a 6 GPA.
Team Criteria not met.
Although we were aiming for

a mark above 80%, the team
did perform well and
achieved 79%, which was
very close to our set criterias.
Individual Criteria met by

Brenton Millers.
Each individual team member

receiving a >80% mark on the
workbook.
Team Excelling in
Submission, receiving a GPA
of 7(>90%).
As we knew we were close to

meeting our own success
criteria, more work was put in
for submission of workbook 2.
N/A

Brenton Millers.
Individual GPA of 7(>90%)

achieved.
Familiarity with tools
discussed for workbook 1 (A
project Managers skills,
Stakeholder Management,
Communication
Management) modules.
Attended the tutorials

discussing the tools used in
our Workbook 1 submission.
Tools applied when
developing Workbook 1 to a
satisfactory level.
Workbook 1 was when our

team cooperated at our best;
we all attended tutorials, we
all had time for meetings and
the tools were simple and
straightforward.
Correctly applied the tools for

the submission of workbook
1.
Page 93
Workbook 2
Success Criterias
Criteria Met
Discussion
A team average of a GPA

scores reaching a 6 GPA.
Again, we were close to the

overall team success criteria,
scoring a 79.5 mark on
workbook 2. Although
infuriating on its own, we
were pleased with our
individual marks.

Benjamin Ivarsson, Brenton
Millers and David Ley.

workbook.
For our individual marks,

every participating member
met the success criteria,
achieving from 80% up to
89% on the second
submission. However, we did
suffer a casualty, when
Samantha OSullivan had to
defer due to surgery.
For the submission of
workbook 3, each member bit
the bullet and vowed to really
up the quality of work.
Team Excelling in
Submission, receiving a GP
of 7(>90%).
N/A
Individual Criteria not met.
Individual GP of 7(>90%)
achieved.
discussed for workbook 2
(Scope Management,
Estimation, Time
Management, Integration
Management, Change
2.

Tools applied when
satisfactory level.
In workbook 2, the tools

became more advanced; as
such, the team split slightly,
when someone struggled
applying a tool, the team
would lose out on forward
development, converging on
the one section where the
tool had to be used.
An example of this was the
work breakdown structure,
Page 94
which Brenton Millers

became unsure about on
several occasions, and as
such could not complete to
his own standard until the
final week of the submission.
Workbook 3
Success Criterias
Criteria Met
Discussion
A team average of a GP
scores reaching a 6GPA.
TBA
TBA
TBA
TBA

TBA (Will know if

satisfactory when
submission marked)

workbook.
Team Excelling in
Submission, receiving a GP
of 7(>90%).
Individual GP of 7(>90%)
achieved.
discussed for workbook 3
(Risk Management, Quality
Management, Procurement
3.
Tools applied when

satisfactory level.
Page 95
9.3 Schedule reporting

Our team schedule works as follows:
Deliverables
Workbook 1
Group
established,
15%
The template
set up, 15%
Section 1
Complete,
20%
Section 2
Complete,
30%
Work
Breakdown
Structure
drafted 10%
Sections 9.1
and 10 Up to
Date, 10%
Deadline
Section 1 done week 4

- August 17th
Section 2 done Week 5
- August 28th.
Work Breakdown
Structure Drafted by
end of Week 5 August 30th
Workbook done Week
5 - August 28th
Time Spent
Agenda
Discussion
Two meetings every

week (Monday and
Wednesday night,
6pm).
Everything delivered
on time, as we stuck to
the set deadlines and
schedule.
On Mondays we talk
and discuss what work
we did the week
before, how we can
improve on the work
weve put in towards
the assignment and
what weve learnt.
The task list remained

consistent and
everyone could deliver
on time.

WBS done Week 5
Workbook delivered
end of Week 5 - 30th of
August
On Wednesdays, we
apply what weve learnt
and work cooperatively
to improve and write
each section of the
deliverable, while
setting deadlines for
our next development
sprint of the
assignment.
Days between these
meetings, we work
individually in a shared
Google Document,
where the assignment
is incrementally added
to.
Workbook 2
Workbook 1
Completely
Revised, 5%
Section 3
(WBS)
complete,
30%
Section 4,
Estimation is
complete,
technique
stated and
justified, 30%
Week 9 - September
25th
All sections completed

week 9
Individual time spent
on each section can be
found in revision
history(above each
section) and
timesheets (see
section 10).
Same agenda as
above with some
modifications.
Due to increased
intensity of project
deliverables, meetings
has been rescheduled
to near every evening
of the week.
For Workbook 2, we
scheduled more
meetings, but as it
started interfering with
individual members
work schedules, we
were never a full team
present.
Samantha also had to
undergo surgery for
her tonsils, and as
such, her tasks were
deferred to workbook 3
Page 96
Section 5,
Schedule is
complete
and
consistent
with WBS,
20%
Section 7 is
complete
with attached
forms, 10%
Section 10 is
complete,
timesheets
and task
allocations
fulfilled, 5%
Workbook 3
Section 6,
Budget and
Procurement
complete,
20%
Section 8,
Risk
Assessment,
complete,
20%
Section 9,
Project
Review,
complete,
20%
Section 10,
Project
Management
, complete,
20%
All revisions
from
Workbook 1
and 2
complete,
20%
submission.
Week 11 - October
18th
All revisions and

sections completed by
the 18th of October,
week 11
Individual time spent
on each section can be
found in revision
history(above each
section) and
timesheets (see
section 10).
Fewer meetings, more

reviews of previous
sections.
Team-members
organize meetings as
necessary to discuss
their assigned
sections.
Individual work is
optimal as the
workload for each
tasked section is
manageable by each
individual.
Team worked
independently during
the weeks leading up
to the submission,
having just come out of
a university holiday
and everyone having
other assignments to
do.
Team met on Sunday,
18th of October to
review the assignment
before submission.
Deadline set to Week

11, October 18th as of
Project Team having
individual assignments
to complete as well
with deadlines before
workbook 3 is due.
Page 97
9.4 Review of Techniques

For the development of our workbook, we decided to work out the assignment through in-person
meetings at least twice, weekly. This strategy worked well for the first submission, but then other
commitments started getting in the way. As such, we adapted and began developing increments
of the workbooks individually, communicating through instant messaging and meetings running
up to each deadline. This strategy and the adaption became easy to manage, as it flowed
around the teams university and work schedules more fluidly.
At the beginning of the semester, the project manager was able to have meetings with LeighEllen to ask questions about direction on the assessment and for any help regarding the content
required in the workbook. However as the semester progressed, it became increasingly not
possible to visit her as she was busy. This made completing sections increasingly harder.
During the development of the workbook, we implemented a peer assessment process. All
sections of the assignment were reviewed by another member of the group. This turned out to
be a great way of refining work to a higher standard.
The use of N44 2.34 as a meeting room was a great choice. There was a projector, couches, a
whiteboard to draw on. It was also right next door to the marker of this assignment, so we could
annoy him and ask him questions.
9.5 Lessons Learned

Benjamin: From this assignment, Ive learned the underlying techniques of Project
Management; the course overall has provided me with tools which are used in the industry of
today. It has also given me a perspective of what it takes to manage a successful project;
especially the need for a structure, task allocation and regular, scheduled meetings. What made
me realize this was how our original plan for weekly meetings fell short, often due to
circumstances we couldve worked around had it been better planned; personally, I wasnt
available enough for meetings due to work. Although our project team meetings were organized
to the best of the teams availability, Id not know my roster until the last shift of the week, and
as such I couldnt always attend meetings we had planned beforehand.
This really made me think about the value of a clear process and scheduling, even outside of
university. For a project like this, the possibility to dedicate all your attention to it wouldve been
the ideal, while not having no time at all would be the least. As such, I believe the team worked
well together, and even though we had our struggles, we got it just right.
Ive also been introduced and gained an understanding of the tools of project management, the
frameworks of the IT industry and how to properly assess risks, quality, functions and
requirements.
David: During the course of this assignment i have learnt many things about how Project
Management is carried out during the development of a project. When i started this course I
Page 98
only knew vaguely the types of work that have to be undertaken for a project to succeed, but
have since been shown that there is a lot of different aspects to managing a project, from
ensuring that all requirements are outlined correctly and contain all of the needed elements of
the clients needs, to how estimation is much needed skill in the world of IT to ensure that
projects dont blow out their budget or time schedule, to even seeing how potential risks can be
analysed, categorised, and then prioritised to ensure that they dont affect the project, and if
they do the impact is limited. I started this course knowing that the area i wanted to most work
in was Project Management, and having completed this assignment, and (hopefully) the course
my goal for my career has not changed at all. In fact it has only strengthened my resolve to
strive for this career choice, as I feel that I would really enjoy the fast pace that is the
management of projects. There were hard times during the development of this assignment but
as a group we pushed through them and still remain friends at the end of the process (a rarity i
have been told). In conclusion I would recommend this course to anyone who would like to see
how a software project team has to perform in the real world, and produce a finished product to
a customer.
Sam: During this course I have learnt many tools that will be helpful in the industry and has
helped me grow in my area of study. I found being sick for a lot of the semester hard to keep up
with course content. The project management side of things has really made me consider a lot
of time management not with just university but work as well.I also had the problem of working
and it made things extremely difficult when not knowing my shifts. Although these issues
wouldn't be a problem in the real world it was because we all had other commitments. This
semester and this subject have ideally made me decide on what i am interested in doing for a
career. I also feel like I have gained more information and gathered an understand on how
things like project management work in the industry.
Brenton: As the project manager of this project I have learnt quite a lot. Trying to manage 3
other people with different commitments has taught me how to manage the short amount of time
we had as a group. It has also taught me conflict resolution regarding timetabling. Other than
that, task allocation was done based around the strengths of the group members and their
confidence in their abilities to do said sections. Nothing was ever forced upon anyone.
Lessons I have learnt regarding this assignment is to make sure you read the module books
before attempting the section. I had to redo a large chunk of WBS because we didn't
understand how to make a tree diagram based on our SDLC. This took 3 Meetings to fix with
Leigh-Ellen.
The group meetings for me worked quite well. It allowed all the group members to make sure
they were always on the same page. It also allowed for more discussion regarding topics as
there are 4 minds on the same task vs one when working individually. This unfortunately
towards the end became too difficult to organise with everyone having work commitments.
Page 99
The only thing I can pick at, that didnt work particularly well was google docs. The website is
particularly painful to use, it lacks features and has compatibility issues when printing to pdf.
The use of google drive however was fantastic.
There was not a section in this assignment that I didnt learn something from. In particular,
creating the WBS was quite a challenge. Additionally deconstructing the requirements from the
tender was quite a challenge. The things I have learnt will help me come the end of the year
with the startup of my company. It will also come in handy with Industry Project next year.
I would gladly do this whole assignment again. The content is great and well written, and with
the support of two fantastic staff members (Leigh-Ellen and Lewis) it makes the subject really
enjoyable. My hat is off to both of you and I appreciate all the time and help you have provided
me throughout the semester.
For my next assignment I will take the lessons I have learnt and apply them. The group
meetings works really well and I will be using them again. I also wont have as much work
commitments next project/assignment, That was killer.
Page
100
10.0 Project Management

Revision History
Date
Ver.
Author
Addition/Alteration
15/09/2015
2.1
Benjamin Ivarsson
Section 10.1.1, Workbook 1 added and submitted with Workbook 2

10.1.2, Workbook 2 status summary written
15/09/2015
3.0
Benjamin Ivarsson
Section 10.1.3, Workbook 3 status summary written, awaiting approval
10.1 Status Summary

10.1.1 Workbook 1
Initialization of the project began with establishing team goals and the suggestion from LeighEllen Potter that Benjamin Ivarsson and Brenton Millers would work well together on a team due
to similar ambitions. After establishing team goals, suitable days for team meetings were
established, and project tasks were identified and assigned. A slight misjudgement were made
when section 8 (risk management) was assigned to David Ley without being an actual
requirement for the first section.
For the first two weeks, the project team met up every scheduled meeting to discuss and iterate
on the project, each completing assigned tasks before deadline. Benjamin Ivarsson and David
Ley quickly finished their assigned tasks to satisfactory levels. Quality was assured by Brenton
Millers, whom also pointed out improvements they could make to their sections. Brenton Also
met with Leigh-Ellen Potter to assure the team were on the right track with their work.
Towards the finalization of the first workbook, every team-member had delivered their assigned
tasks. Most detailed was the work of Samantha OSullivan and Brenton Millers, whom had both
gone above and beyond to make a difference for the final submission. On average, the team
spent 8 hours a week on individual work for the project, as well as an additional 4 hours of work
during team meetings, discussing and developing the project document.
The week of the deadline, Benjamin Ivarsson was unable to attend team meetings, but had also
completed his assigned tasks ahead of time. However, Brenton Millers and Benjamin had
Page
101
individual meetings for the final submission to run through and review the document before
submission.
Overall, the project development for workbook 1 progressed on track, with progress being made
iteratively each week.
Changes proposed for next workbook are mostly related to time management and meeting
schedules. For each meeting, suggestions of an agenda has been put forward, so that
discussed topics can be documented for future re-evaluation. Team works well together and
each member agree with the goals set forward for the project.
10.1.2 Workbook 2
Initial week for workbook 2, no meetings were had due to entire team being indisposed for
individual reasons (sickness, work obligations, home issues, travel etc.). However, the team ( Samantha OSullivan due to surgery) met for a tutorial meeting to get an understanding of
proper estimation techniques. Discussions were also initiated about changing the weekly
meeting times, so to allow for more work being done.
During the second week, task list was updated for the team by Brenton Millers and David Ley,
so that individual work could be drafted for the next team meeting and then iterated upon.
Benjamin Ivarsson and Samantha OSullivan were both unavailable for the team meetings due
to work obligations and health concerns respectively. Team members met up again on
Thursday for brief discussion about new task allocations and establishing a method of schedule
estimation (with Gantt chart practice). Following this meeting, Benjamin Ivarsson completed his
sections fully by 22/09/2015, but didnt receive approval on his work by the project manager
(Brenton).
Throughout the submission for workbook 2, team members were scattered and few meetings
were had until the final submission week. No sections were really being done on time, and as
such, the team struggled to catch up. Towards and during the final week before submission,
meetings were had every night up until submission date to attempt and complete the workbook
on time.
A lot of the difficulties in delivering on time can be attributed to the work breakdown structure
section which was tasked to Brenton Millers, and as such David Ley struggled completing his
sections on time. Much of the delayed work also derived of Samantha OSullivan having surgery
for tonsillitis. However, the team collaborated and worked hard up until the submission date to
finalize their sections and make up for lost time. Due to Samanthas tonsillitis, she has opted out
from the final submission, having been unable to deliver her assigned sections. She has also
provided medical certificates for this.
Page
102
10.1.3 Workbook 3
Coming into this assignment at the beginning of a university holiday, followed by two weeks of
additional work, the development of workbook 3 slowed down drastically. An increased
workload for all members of the team in separate areas has drained the team of available
timeslots to collectively work on the final submission.
Instead, it was put off by all involved until the final weekend for submission. However, the
motivation of the team didnt decline; I, Benjamin, am not able to discern whether this motivation
came from stress to meet a deadline, or from actual dedication and ambition to produce a high
quality assignment. Id like to think that it was a good blend.
Thursday night, Samantha and David met up and finished their assigned sections; by Friday
night, Benjamin had his sections complete so that Brenton Millers could finish his section. Team
could use the approval of each other on sections and help proof reading/discussing, but with the
end of a semester and an increase in finishing assignments on a nested due-date, less
constructive criticism between the team-members was available. This came to show the value
of a well-established communication strategy, which we shouldve stuck to.
Towards the final submission, each member of the team were independently working on their
tasked sections, as to complete the third workbook before it was due.
Page
103
10.2 Task List

Submission 1
Task
Allocated To
Due
Date
Status
Comments (include who

finished task, date complete)
Google Docs share

folder
Brenton Millers
10/08/2015
Done
Setup the google drive and allow access for

Sam, Ben and David. Task was completed by
Brenton on the 10/08/2015
Document Template
Setup
Brenton Millers
10/08/2015
Done
Move template from word to google docs file.

Set Up headings, fonts, tables etc. Task was
finished by Brenton on the 10/08/2015
10.2 Task List Setup
Brenton Millers
12/08/2015
Done
Assigned tasks to everybody. Choices of

sections were made on group members
strengths.
This was completed on the 12/08/2015 by
Brenton with Benjamins assistance.
1.1 Company
Information
Team meeting
30/08/2015
Done
All of section 1 was completed during group

meeting on 10/08/2015.
1.1.2 Project
Description
Benjamin Ivarsson
30/08/2015
Done
Need to cover what CrimTrac are looking for in

their tender. This was completed by Benjamin
on 28/08/2015
1.1.3 Project Objectives

and Success Criteria
Benjamin Ivarsson
30/08/2015
Done
The group came up with ideas how we could

measure success of the project. This is under
the heading in the template.
This was completed by Benjamin on
28/08/2015
1.1.4 Approach
David Ley
30/08/2015
Done
We will be using the Incremental SDLC.

This was completed by David on the
27/08/2015
1.1.5 Primary
Stakeholders
Samantha OSullivan
30/08/2015
Done
This was completed by Samantha on

20/08/2015
Benjamin Ivarsson
30/08/2015
Done
This was completed by Benjamin on

24/08/2015.
The dates were modified by Brenton on
30/08/2015 to better align with tender.
1.1.7 Budget
Brenton Millers
30/08/2015
Done
This was completed by Brenton on 30/08/2015

with Samanthas assistance.
1.2 Stakeholder
Analysis
Samantha OSullivan
30/08/2015
Done
This section was completed by Samantha on

20/08/2015
Page
104
1.3 Communication
Strategy (Table)
David Ley
30/08/2015
Done
This section was completed by David on

24/08/2015
1.3.1 Managing and

Resolving Breakdowns
in Communication
Samantha OSullivan
30/08/2015
Done

20/08/2015
1.3.2 Team
Communication
Strategies
Samantha OSullivan
30/08/2015
Done
Outline the strategy used to communicate with

stakeholders.
20/08/2015
1.3.3 Communicating
Amongst A Distributed
Team
Samantha OSullivan
30/08/2015
Done

20/08/2015
Brenton Millers
30/08/2015
Done
Outline the reason CrimTrac is requesting this

new software.
This section was completed by Brenton on
29/08/2015
2.2 Product Scope

Description
Brenton Millers
30/08/2015
Done
Outline all the requirements for the project.

29/08/2015
2.3 Product
Deliverables
Brenton Millers
30/08/2015
Done
Outline all the deliverables for the project.

29/08/2015
3.1 WBS Tree (Draft)
David Ley
30/08/2015
Done
This section was drafted by David on

29/08/2015
3.2 WBS Table (Draft)
David Ley
30/08/2015
Done
This section was drafted by David on

29/08/2015
Benjamin Ivarsson
30/08/2015
Done
This section was drafted by Benjamin on

28/08/2015
9.3 Schedule Reporting
Benjamin Ivarsson
30/08/2015
Done
This section was drafted by Benjamin on

28/08/2015
Task
Allocated To
Due
Date
Status

3.1 WBS Tree
David Ley/Brenton
Millers
11/09/2015
Done
This section was completed by David and

Brenton on 25/09/2015
3.2 WBS Table
Brenton Millers
15/09/2015
Done
This must be complete in order to do Section 4

and 5
Submission 2
Page
105
4.1 Choice of
Technique
Benjamin
Ivarsson/David Ley
15/09/2015
Done
This section was completed by David and Ben

on 25/09/2015
4.2 Justification
David Ley
15/09/2015
Done

25/09/2015
4.3 Estimation
David Ley
18/09/2015
Done

25/09/2015
5.0 Schedule
Brenton Millers
23/09/2015
Done

25/09/2015
Samantha
OSullivan/Brenton
Millers
25/09/2015
Done

02/10/2015
6.1.2 Cost
Management
Samantha
OSullivan/Brenton
Millers
25/09/2015
Done

02/10/2015
7.1.1 Change Control

Approach
Benjamin Ivarsson
25/09/2015
Done
This section was completed by Ben on

24/09/2015
7.1.2 Change Control

Procedure
Benjamin Ivarsson
25/09/2015
Done

24/09/2015
7.1.3 Audits and

Review
Brenton
Millers/Benjamin
Ivarsson
25/09/2015
Done

24/09/2015
7.2.1 Configuration
Items
Brenton
Millers/Benjamin
Ivarsson
25/09/2015
Done

24/09/2015
7.2.2 Configuration
Management System
Brenton
Millers/Benjamin
Ivarsson
25/09/2015
Done

24/09/2015
10.1 Status Summary

(First Submission)
Benjamin Ivarsson
15/09/2015
Done
Benjamin Ivarsson wrote this before

15/09/2015 but was left out of last submission
10.1 Status Summary

(Second Submission)
Benjamin Ivarsson
15/09/2015
Done

24/09/2015
Workbook 1 Revision
Section 1.1
Section 1.2
Section 1.3
Section 2
Section 3
Section 9
Section 10.1
Team Collaboration
25/09/2015
Done
Section 1.1-1.1.4 Revised by Benjamin

Ivarsson, 22/09/2015
Section 1.1.5-1.3 needs
Stakeholders/Communication Strategy Revised
HEAVILY
Section 10.1 has been revised accordingly (see
above tasks).
Page
106
Submission 3
Task
Allocated To
Due
Date
Status

6.2.1 Planned
Procurement
Brenton
Millers/Benjamin
Ivarsson
18/10/2015
Done
Benjamin: I have a drafted section on my

computer, I just need to add it, but wi-fi acting
up and things arent saving to drive.
Added some of the drafted sections; cant add
rest as I realize itll probably be inaccurate.
Benjamin and Brenton finished the section on
18/10/2015
6.2.2 Procurement
Management
Brenton
Millers/Benjamin
Ivarsson
18/10/2015
Done
Benjamin: I have a basic idea of what wed do

here, but I wanna meet with Brenton before
putting it in.
Benjamin and Brenton finished the section on
18/10/2015
8.1 Risk Management

Strategy
David Ley/Samantha
OSullivan
18/10/2015
Done
Completed by Samantha OSullivan and David

Ley on 18/10/2015.
Reviewed by Samantha OSullivan on 18/10/15
8.2 Risk Monitoring

Strategy
David Ley/Samantha
OSullivan
18/10/2015
Done

Ley on 18/10/2015.
8.3 Risk Register
David Ley/Samantha
OSullivan
18/10/2015
Done

Ley on 18/10/2015.
Benjamin Ivarsson
15/10/2015
Done
Done by Benjamin Ivarsson. Reviewed/edited

by Brenton Millers on 18/10/2015
9.2 Project
Achievements
Benjamin Ivarsson
18/10/2015
Done
Done by Benjamin Ivarsson. Edited/reviewed

9.3 Schedule Reporting
Benjamin Ivarsson
15/10/2015
Done
Done by Benjamin Ivarsson. Edited/Reviewed

9.4 Review Techniques
All
18/10/2015
Done
Benjamin: Added a brief statement to

techniques.
Brenton: Added the rest of the techniques used
in the assignment.
9.5 Lessons Learned
All
18/10/2015
Done
Benjamin: Done my part 16/10/2015.

Brenton: Done my part 18/10/2015
David: Done my part 18/10/2015
Sam: Done my part 18/10/2015
Page
107
10.1 Project Summary
Benjamin Ivarsson
15/10/2015
Done
Completed by Benjamin on 15/10/2015
10.2 Task Allocation
Brenton Millers
4/10/2015
Done
Task allocations have been done throughout

the project. The final additions were made on
the 4/10/2015
10.3 Timesheets
All
18/10/2015
Done
Workbook 2 revision
All
16/10/2015
Done
Benjamin: Ive worked my way through the

comments and done what I can. Would
appreciate some input from team on the
revision, possibly if you could revise your own
sections a bit more elaborately.
Brenton: Made revisions based on notes from
Lewis. Fixed Gantt Chart based on meeting
with Leigh-Ellen.
Sam: The budget was edited for the integration
of the document.
Page
108
10.3 TimeSheets
Each member of the team should complete a timesheet showing their work for the workbook.
This should build progressively across the entire semester. Add more rows as required
Name: Benjamin Ivarsson s2909727
Date:
Time Spent
Task
Comments
10/08/2015
3 Hours (6-9pm)
Section 1; Team
collaboration, project charter
outlined and worked out
through group discussion and
added onto iteratively.
Worked as a team to outline

what CrimTrac is requiring
from us for the tender.
12/08/2015
1 Hour (7-8pm)
Section 10.2 and 10.3;

Sketched out Timesheets and
Task list to assist Brenton.
Project Objectives and
Success Criteria; Updated dot
points and added key
deliverables
Project Description; Rewritten
Brenton is to speak with Leigh

Ellen about the time sheets
and section tables.
14/08/2015
2 hours (6-8pm).
Section 1.1 Complete

Section 9 Complete
Completed section 1.1 Friday;

rewrote Sunday as ethernet
connection been down most
of the weekend and havent
even realized.
Section 9 in continuous
development for the duration
of the project.
16/08/2015
2 hours (10am-12pm)
Worked on Approach; to be
rewritten after team
discussions
Team discussions on
Approach
28/08/2015
3 hours (3pm - 6pm)
Rewrote entirety of section

1.1 and up to section 1.2
Met up with Brenton at 4pm to

walk through
Scope/Stakeholders/Approac
h.
Discussed some of his
meeting with Leigh-Ellen
Potter, Client Liason.
Updated all tables, tidied up

sections.
Aligned document with
marking criterias.
30/08/2015
2 hours (12am-2am)
Met up with Brenton and

discussed the finalisation of
the document; rewrote and
fixed document for
Leaving it to the last minute to

proofread and fix the
document.
Page
109
submission.
Readjusted Tables.
Clarified details.
Worked an additional hour on
fixing sections which Brenton
identified needed fixing.
30/08/2015
1 hours(12pm-1.30pm)
Finalizing the document for

submission. Touching up
changes based on comments
and team identified issues
within the sections.
N/A
10/09/2015
3 hours (8pm-11pm)
Started section 4.1, 10.2
Unable to fully complete until

assessed complete by Project
Manager.
14/09/2015
3 hours and 30 minutes (7pm10.30pm)
Worked on the WBS with

Brenton Millers and David Ley
Revision of Workbook 1.
Team collectively worked to

complete 3.1 and 3.2
21/09/2015
1 hour (7pm-8pm)
Revision of section 10.
Only worked an hour due to

fever.
22/09/2015
2 hours (10am-12.30pm)
Section 7.1.1 started, diagram

for 7.1.1 complete
Lunchbreak at 12.30
22/09/2015
3 hours (1pm-4pm)
Section 7.1.2 Almost

completed; Change Request
Forms and Change Request
Logs drafted/provided.
Drawing Diagram and need it

approved by Project Manager
Started revision based on

previous workbook
submission.
Revised Sections 1-1.1.4
23/09/2015
3 hours (9pm-12am)
Assisted Brenton and

Samantha writing the WBS
for final submission
Provided input and

discussion, but did not write
any content, only drafted
WBS with team members.
24/09/2015
12 hours (12pm-12.30am)
Re-wrote Section 7.
Revised previous document
version.
Established baselining.
Mocked up a theoretical
CMDB.
Timesheets are probably

incorrect as Ive forgotten to
update the timesheets as I
go. Final week is rough
estimates of time/dates.
25/09/2015
59 minutes (11pm-11.59pm)
Final edits before submission.

Revised entire document
based on comments from
Lewis Carter from previous
document submission.
Called in by Brenton Millers to

revise sections until
submission.
15/10/2015
1 hours (9.30am-11am) and

project review (Typos and
Section 10.1, Project revision
Also added to this section on

the 16th.
Page
110
obvious flaws)
16/10/2015
18/10/2015
4 hours (9pm-1.30am)
6 hours (10am-4pm )
Section 9.1, 9.5, 10.1,

Additional revision of sections
3.1
3.2
page 39
4.2
7.1-7.2
Did my part on section 9.5,

wrote first part of 10.1. Would
appreciate team to add to
these sections as well.
Section 6.2, Procurement

Section 9.2, Project
Achievements
Offline drafted section added

to the online document;
edited and finalised for
submission.
Wrote section 9.2
Drafted Procurement section

6.2; unable to save, Wi-Fi
dead and cant continue
editing on phone
Name: Brenton Millers s2941834

Date
Time Spent
Task
Comments
10/08/2015
4 Hours (6-10pm)
Group Meeting
Setup Google Drive,

document template,
discussed Company
Information and what we're
doing in the assignment.
12/08/2015
3 Hours (6:30-9:30pm)
Group Meeting
Assigned tasks to group

members, jotted notes under
each section. Worked on
Vision of the project (what we
wanted to build)
17/08/2015
4 Hours (6-10pm)
Group Meeting
Worked on Budget with

group. Worked on Vision of
the project (what we wanted
to build)
19/08/2015
4 Hours (6-10pm)
Group Meeting
Began outlining requirements

and deliverables.
20/08/2015
4 Hours (8pm -12am)
Note taking
Took notes attempting to

gather all the requirements
from the tender.
21/08/2015
0.5 Hours (2-2:30pm)
Meeting with Leigh-Ellen
Went through assignment.

Recorded meeting.
22/08/2015
3 Hours (7pm-10pm)
Note taking
Finished taking notes of

requirements.
23/08/2015
4 Hours (6 - 10pm)
Section 2.2
Setup tables, started listing
Page
111
requirements and describing

them.
24/08/2015
3 Hours (6-9pm)
Group Meeting
Finalised what everyone had

to do. Listened to recording
from meeting with Leigh-Ellen
26/08/2015
3 Hours (6-9pm)
Group Meeting

done. Proofread the
document.
27/08/2015
2 Hours (8-10pm)
Section 2.2
Added more requirements.
28/08/2015
6 Hours (1-5:30pm)
Section 2.2, 2.3
Finished requirements and
29/08/2015
12 Hours(1pm-1am)
Section 2
Finished all of section 2.

Edited various other sections.
Fixed table formatting.
30/08/2015
10.5 Hours (1-11:30pm)
Whole document check.
Editing document ready for

submission. Putting final
touches and making final
adjustments. Fixed up time
tables.
07/09/2015
4 Hours (6-10pm)
Work Breakdown Structure

Section 3.1
Found work breakdown

structure diagram on the
internet. Began work on the
tasks in the work breakdown
structure.
09/09/2015
4 Hours (6-10pm)

Section 3.1
Finalised work breakdown

Structure. Allocated tasks for
the group.
14/09/2015
3 Hours (7-10pm)

Section 3.1 and Work
Breakdown Table Section 3.2
Made small modification to

3.1 and setup table for 3.2
20/09/2015
5 Hours (9-2pm)
WBS table.
Began work on WBS Table,

added a number of headings
and began filling table.
21/09/2015
6 Hours (3-9pm)
WBS table.
Continued adding items to

WBS Table
22/09/2015
3 Hours (12-3pm)
WBS table.
Finalised Diagram of the

WBS.
23/09/2015
12 Hours (12pm-12am)
Gantt Chart work
Setup gantt chart file, learnt

how to use project, started
adding tasks.
24/09/2015
13 Hours (11am-12am)
Gantt Chart work
Continued adding tasks to

gantt chart
25/09/2015
13 Hours (11am-12am)
Gantt Chart work
Finalised tasks in gantt chart,

linked all the predecessors,
migrated table to document.
Page
112
15/10/2015
30 Mins (2-2:30pm)
Meeting with Leigh-Ellen
Discussed Gantt Chart and a

few other sections and what
was required.
16/10/2015
2 Hours (4-6pm)
Gantt Chart work
Performed some adjustments

to the Gantt Chart to fix
missing links in the network
diagram.
17/10/2015
4 Hours (2-6pm)
Procurement Section
Worked on Procurement with

Ben.
18/10/2015
7 Hours (4-11pm)
Revision of Procurement, and

rest of document, Sections
9.4, 9.5,
Finalised everything in the

document and finished up my
sections of the assignment.
Name: David Ley s2941698

Date
Time Spent
Task
Comments
10/08/2015
4 Hours (6-10pm)
Group Meeting
Initial meeting to discuss the

project and set up google
doc.
10/08/2015
4 Hours (6-10pm)
Worked on 1.1
As a group we all worked on

this to get the details of the
company and project.
12/08/2015
4 Hours (6-10pm)
Group Meeting
Was assigned tasks to

complete for the first
submission.
14/08/2015
3 Hours (6.30-9.30pm)
Worked on the Approach
Started on how we were

going to do the project and
selected a SDLC.
17/08/2015
4 Hours (6-10pm)
Group Meeting
Worked on the budget of the

project.
17/08/2015
4 Hours (6-10pm)
Started sketching out ideas

for risk assessment
Read the Risk assessment

section of the PMBOK and
identified some aspects that
are required.
19/082015
4 Hours (6-10pm)
Group Meeting
Began outlining the

requirements and
deliverables.
19/08/2015
4 Hours (6-10pm)
Started to work on 1.3 Table
started to outline the

stakeholders and how they
should be contacted for
updates etc relating to the
project.
24/08/2015
4 Hours (6-10pm)
Group Meeting
Finalised the sections that
Page
113
needed to be completed and

listened to the recording from
Brentons meet.ing with
Leigh-Ellen
24/08/2015
4 Hours (6-10pm))
Continued work on 1.3 Table
Continued outlining
stakeholders various ways of
communication between
project team members.
26/08/2015
4 Hours (6-10pm)
Group Meeting
Proofread the document with

Project Manager and rest of
team.
26/08/2015
4 Hours (6-10pm)
Worked as a team on Budget
Proofread the document with

Project Manager and rest of
team.
Reviewed document with

Project Manager
29/08/2015
2 Hours (7-9am)
Completed 1.3 Table
Finalised all communication

methods for stakeholders
30/8/2015
4 Hours
Completed 3.1 and 3.2
Worked on, and finished the

draft WBS tree and WBS
table.
07/09/2015
4 Hours (6-10pm)

Section 3.1
Group Meeting
Found work breakdown

structure diagram on the
internet. Began work on the
tasks in the work breakdown
structure.
09/09/2015
4 Hours (6-10pm)

Section 3.1 & 3.2
Group Meeting
Continued work on WBS
14/09/2015
3 Hours (7-10pm)

Section 3.1 and Work
Breakdown Table Section 3.2
Group Meeting
Continued Work on WBS
16/09/2015
4 Hours (6-10pm)
WBS Section 3.1 & 3.2

Group Meeting
21/09/2015
4 Hours (6-10pm)
WBS Section 3.1& 3.2

Group Meeting
22/092015
4 Hours (6-10pm)

Group Meeting
24/092015
4 Hours (6-10pm)

Group Meeting
25/092015
9 Hours (3-12)
Estimation Section 4
Finalised Section 3.1
Group Meeting
Worked on and completed

section 4, also created the
WBS Tree
15/10/2015
2 Hours
Group Meeting
Outlined Risks for the Risk

Register and entered all
Page
114
relevant details, worked on

Risk Classification
18/10/2015
6 Hours
Worked on sections: 8.1.2.2

Probabilty/Impact Matrix,
8.1.2.3, 8.1.4, 8.2.3, 8.2.6,
added screeshot of
COCOMO II to 4.3.4.5
Started and finished all

assigned sections
Name: Samantha OSullivan s2942816

Date
Time Spent
Task
Comments
10/08/2015
4 Hours (6-10pm)
Section 1; Team
collaboration, project charter
outlined and worked out
through group discussion and
added onto iteratively.
Worked as a team to outline

what CrimTrac is requiring
from us for the tender.
All of section 1 was
completed during group
meeting on 10/08/2015.
12/08/2015
2 Hours (6:30-8:30pm)
Group Meeting
Assigned tasks to group

members, jotted notes under
each section. Worked on
Vision of the project (what we
wanted to build)
17/08/2015
4 Hours (6-10pm)
Group Meeting
Worked on Budget with

group. Worked on Vision of
the project (what we wanted
to build)
24/08/2015
4 Hours (6-10pm)
Group Meeting
Began outlining requirements

and deliverables.
26/08/2015
4 Hours (6-10pm)
Group Meeting

done. Proofread the
document.
27/08/2015
5 Hours (1am-6am)
Individual Work
Worked on Stakeholder
Analysis
28/08/2015
3 Hours (9pm-12am)
Individual Work
Worked on Communication
Strategy
29/08/2015
3 Hours (2pm-5pm)
Individual Work
Edited and Completed

Stakeholder Analysis and
Communication Strategy
30/08/2015
6 Hours (1pm-3pm, 6pm10pm)
Whole document check.
Editing document ready for

submission. Putting final
Page
115
touches and making final

adjustments. Fixed up time
tables.
25/092015
9 Hours (3-12)
Estimation Section 4
Finalised Section 3.1
Group Meeting
Worked on and completed

section 4, also created the
WBS Tree
30/09/2015
10 Hours (12pm- 10pm)
Budget
All of section 4 was redone to

complete the budget.
31/09/2015
10 Hours (12pm- 10pm)
Budget
All of section 4 was redone to

complete the budget.
15/10/2015
2 Hours
Group Meeting
Outlined Risks for the Risk

Register and entered all
relevant details, worked on
Risk Classification
18/10/2015
6 Hours
Worked on sections: 8.1.2.2

Probabilty/Impact Matrix,
8.1.2.3, 8.1.4, 8.2.3, 8.2.6,
Started and finished all

assigned sections
18/10/2015
2 Hours
Integrated Budget to
document
Finished the Integration of the

budget
18/10/2015
3 Hours
Editted all of section 8.
Completed Editing of Section

8
18/10/2015
2 Hours
Editted all of section 4 and 6.
Completed any adjustments

to sections 4,6 & 8.
11. Appendixes
Revision History
Date
Ver.
Author
Addition/Alteration
15/10/2015
3.1
Benjamin Ivarsson
Added the Appendixes section
11.1 Appendix A - Sample Change Request Form
Page
116
PROJECT CHANGE REQUEST FORM
This Project Change Request form has to be completed for requesting changes to
approved requirements of Ace System Solutions original Project Plan. This for is
assessed by Ace System Solutions Project Manager.
Please attach any supporting documentation which will be helpful to the approval
process. Form is submitted to Ace System Solutions Project Manager, to be reviewed
by the affected Project Team.
1. PROJECT DETAILS
Name of Project
Project Identification #
2.
REQUEST DETAILS
Request No.
Date of Request
Name of Requestor
Position/Role
Page
117
3.
CHANGE DETAILS
Project Category
Proposed Change
Reason for Variance
Scope
Time
Cost
Quality
Risk Management
Communications
Other
4.
CHANGE JUSTIFICATION
Priority
Immediate
Essential
Urgent
High
Medium
Low
Intended outcome(s)
Expected benefit(s)
5.
IMPACT OF CHANGE
List any important impact of the change(s) on the Project deliverables
6. SUPPORTING DOCUMENTATION
Page
118

Responsetotenderv 3

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

Responsetotenderv 3

Uploaded by

Copyright:

Available Formats

Project Management Assignment

Response to CrimTrac Tender

Ace System Solutions Response to CrimTrac Tender V3.0 2015

4.2.2 Function Point Adjustment

Ace System Solutions Response to CrimTrac Tender V3.0 2015

6.3.1 Establishing Procurement

Ace System Solutions Response to CrimTrac Tender V3.0 2015

Ace System Solutions Response to CrimTrac Tender V3.0 2015

Met up and discussed and read through entirety of current document,

Company Information was written by all of us.

Started work on the stakeholders table

Started working on the budget outline.

1.1.5 -1.3 Managing and Resolving Breakdowns in Communication and

Further elaborated on the Company Information / added affiliates and

Continued working on section 1.1.2-1.1.5

Sketched out some ideas for Risk Assessment

Started work on Communications Strategy Table

Continued work on Communications Strategy Table

Worked on budget and reviewed document so far

Worked on Stakeholder Analysis

Worked on Communication Strategy

Rewrote and aligned document with marking criterias. Updated Key

Finished Communications Strategy Table

Stakeholder Analysis and Communication Strategy

Worked latenight/day on final submission document. Touched up to

Ace System Solutions Response to CrimTrac Tender V3.0 2015

match document standards. Sections 1-3.

Updated budget, start and finish dates.

Updated budget and finished any work.

Added Draft WBS Tree and Filled out Table

Revised section 1.1.4 (Approach) to define an incremental approach

1.1 Company Information

Ace System Solutions Response to CrimTrac Tender V3.0 2015

1.1.2 Project Description

Ace System Solutions Response to CrimTrac Tender V3.0 2015

1.1.3 Project Objectives and Success Criteria

Deliver a standalone or NAFIS integrated

The system has to be able to access and

Matching and identification must be over

Ace System Solutions Response to CrimTrac Tender V3.0 2015

Deliver a standalone or NAFIS integrated

The system has to be able to access and

Matching and identification must be over

Database access for the system must

Algorithm accurately matches 100% of

Project to be completed within a 1 year

All phases of the project (Facial

NAFIS fully replaced by April 2017.

Commence Contract by January 2016

Previous NAFIS System has been 100%

Complete the project within estimated

All phases of the project were completed

Monitor the costs over project

Accurately logged, monitored and

Ace System Solutions Response to CrimTrac Tender V3.0 2015

development; Control costs without the

controlled the expenses over the

Ace System Solutions Response to CrimTrac Tender V3.0 2015

1.1.5 Primary Stakeholders:

CrimTrac Board of Directors

CrimTrac Technical Staff

1.1.6 Start and Finish