Project Charter - datsyle.files.wordpress.com · Web view, the project team has devised weekly meetings to review the project’s documentation and progression, assessing all changes

1. Project CharterRevision History

Date Ver. Author Addition/Alteration

10/8/2016 1.1 All members Added Project Title, Project Manager, Company Name, Team members

15/8/2016 1.2 Sukhneet Singh Added project Objectives

20/08/2016 1.3 Nathaniel Pather Added Business Experience

20/8/2016 1.4 Sukhneet Singh Added Project Success Criteria

22/8/2016 1.5 Sy Le Complete Table of Stakeholder List

24/8/2016 1.6 Sy Le Updated Table with New Stakeholders

25/08/2016 1.7 Nathaniel Pather Added Overall Budget

26/8/2016 2.1 Sy Le Re-evaluated Stakeholders and Final Adjustments

22/09/2016 2.2 Sukhneet Singh Updated Project Success Criteria

24/09/2016 2.3 Nathaniel Pather Updated Overall Budget, updated approach.

1.1 Company Information

Project Title: Biometrics Identification Services

Project Manager: Nathaniel Pather

Company Name: Biometric Solutions

Team Members: Nathan Pather (s2924903), Jaspreet Singh (s2970544), Sy Le (s5017252), Clayton McShane (s5009126), Sukhneet Singh Hanjrah (s2969612).

Business: As students at Griffith University the group came together for a group assignment for their Software Engineering course. Realising their talent and strong interest in the development of biometric solutions the group decided to form a start-up company. In 1987 the group was officially known as Biometric solutions.

Their first major project was the development of a biometric access system for Griffith University. With an increasing reputation, Biometric Solutions got offers all around Australia.

At the time the NAFIS was also recently deployed, and Biometric solutions were contracted to maintain the system in selected locations.

In 2015 Biometric Solutions employed approximately 340 direct personnel. Biometric Solutions provides services to and supports approximately 20,000 law enforcement users all across the country.

Project Description: The objective of the project is to design and develop forensic technology that is capable for accessing and storing the identification of recorded criminals across all Australian states, utilising Biometric mode of fingerprint, including palm print and footprint to identify them.

Project Objectives and Success criteria: Federal Government agency CrimTrac requires an integration of their National Automated Fingerprint Identification System (NAFIS). The solution system will be used by relevant authorities all across Australia, and provide and receive relevant third party information.

The solution system requires up to date Biometric Identification Services. The data generated by the system should possess the ability to be placed in multiple datasets. Further data should be enrolled by the system if need be. Matching services of the data will also be required. The solution system must also be flexible to allow users to customize their own Business workflows, as well as allow further implementation to the system in the future.

Project Objectives and Success criteria:

Project Objectives Success Criteria Person Approving

Scope:

To successfully install the Biometric Mode of identification services in 6 states across Australia.

Different type of recognition devices were Successfully installed with more superior technology and up to date records with capability of storing and fetching data from previous records

Sukhneet Singh

All parts of biometric recognition devices placed across the country were working in great condition, acquiring a high success rate of 90% in usage of this services.

Clayton Mcshane

To successfully keep track at all the information coming from face recognition, fingerprints etc.

All the information coming from different places was secured which give us acceptance rate of 90% from users

Sukhneet Singh

Fingerprinting scanning provided 90% of satisfaction rate from users.

Nathaniel Pather

Provide Manuals and DVD’s for the devices installed for a better understanding of the newly introduced technology

All the important stuff like manuals and DVD’s were successfully provided to companies in which this technology was introduced

Sy le

The documents provided covers 100% of the important information required to understand the working of technology

Sy le Jaspreet Singh

The document provided to different companies and sectors achieved a minimum of 95% acceptance rate

Clayton mcshane

Time:

Objective to complete the project within 4 years

All components of the project were successfully installed before the deadline of given 4

Jaspreet Singh

yearsCommencement of Project – September 20

Agenda to complete the project within given time commenced during September 10

Jaspreet Singh

Cost:

To successfully finish the project within the estimated budget planned

All of the services and the systems were victoriously installed at an expense equal to AUD $50 million

Nathaniel Pather

To keep record of the of the money used in different sectors of the project

A money register to be used for cost management

Nathaniel Pather

Approach: CrimTrac requires a flexible and agile system to support future functions to be added over time. The tenderer will also be responsible for ongoing support and maintenance of the system and services. There is also a potential for change within the project. Agile software development supports many of these needs. It is flexible in its techniques and practices, and excellent in responding to change. Because the system is intended to be used by multiple organisations, early feedback provides CrimTrac enough time to approve the work completed with the other organisations. Agile provides this early feedback, and is also better suited for small co-located teams. With a team size of five members, Biometric Solutions believe an agile software development life cycle best suits this project.

Because of this, Biometric Solutions believe an agile approach is best suited for this project.

Stakeholders: The primary stake holders of the project have been identified. Please refer to section 1.2 Stakeholder Analysis. The key stakeholders of the project are CrimTrac’s Chief Executive Officer, Chief Operating Officer and Chief Information Officer.

Start and Finish: 26/07/2016 – 14/10/2016

Budget:

Item TotalProject Plan $18,486.99Data Capture and Storage $89,433.11Enrolment Matching and Database Management $212,251.53Data Application $285,216.59Service Additions $148,541.78Technical Training 6,870,857.59Total Project Budget $7,535,443.91

1.2 Stakeholder Analysis

Name of Client Liaison: Sy Le

Stakeholder Analysis

Internal Stakeholders – Biometric SolutionsEach stakeholder here have been assigned roles in the construction of the Project.Project Manager & Project Cost Management Nathaniel PatherProject Time Management Jaspreet SinghProject Scope Management Clayton McShaneProject Quality Management Sukhneet Sigh HanjrahProject Communications Management & Project Stakeholder Management

Sy Le

External Stakeholders – CrimTrac Each stakeholder will be listed by their importance within CrimTrac, regarding their overall position, influence and authority. Chief Executive Officer (CrimTrac)

Highest-ranking executive in the company – Responsibilities include overall management of operations and resources within the company, strategic thinking when developing high-level strategies, sound judgement when initiating major corporate decisions, and acting as a figure of authority when negotiating between the board of directors and the corporate operations.

Oversees: Chief of staff Transition and Change

Ms Nicole Rose

Chief Operating Officer (CrimTrac)

2nd Highest-ranking executive in the company – Second in Command – Corporate executive who oversees ongoing business operations within CrimTrac - Responsibilities include the development of strategic objectives and long-term planning activities, and the management

Ms Nicole Mayo

of corporate services that underpin the agency.

Oversees: Corporate Services and Assurance Finance Legal and Commercial Business Engagement, Strategy and Performance Communications and Secretariat People and Integrity

Chief Information Officer (CrimTrac)

Senior Executive - Accountable for the overall management of an organisations information and communication technology services. Responsibilities include the delivery of information service functions to CrimTrac’s key business stakeholders along with the delivery of national information sharing services to Australia’s stake and territory.

Oversees: Program Management Office Project Delivery - Firearms Project Delivery – Persons Chief Architect Service Delivery and Security Chief Technology Officer National Police Checking

Mr Lee Walton

Director of Communications and Secretariat (CrimTrac)

Reports directly to the CEO of CrimTrac – Oversees secretarial duties – Manages and directs an organisations internal and external communications - Responsibilities include supporting the work of the Secretariat team, general management of the provision of logistical support to committees and boards, delivery of secretarial services to a range of committees, Enforcement on the provision of secretariat services for CrimTrac’s key governance, and ensuring meetings are properly coordinated, with agendas, papers, and minutes delivered to timeliness and quality standards.

Oversees: Public relations staff Secretariat team

Mr Nick Page

External Stakeholders – CrimTrac (ACIC) board partnered agenciesEach stakeholder will be listed by their importance by their public relations to CrimTrac, regarding their overall position, influence and authority.Chairperson Australian Securities and Investments CommissionsSecretary Australian Government Attorney-General’s DepartmentDirector General of Security Australian Security Intelligence OrganisationChief Police Officer Australian Capital Territory Police

Chief Executive Officer Australian Criminal Intelligence Commission (non-voting member)

Chief Executive Officer AUSTRAC (non-voting observer)Chief Commissioner Victoria PoliceCommissioner of Taxation Australian Taxation OfficeCommissioner Australian Federal Police (Chair)Commissioner Australian Border ForceCommissioner New South Wales Police ForceCommissioner Queensland Police ServiceCommissioner South Australia PoliceCommissioner Western Australia PoliceCommissioner Tasmania PoliceCommissioner Northern Territory Police

Stakeholder table analysis

STAKEHOLDER STAKEHOLDER’S INTEREST IN THE PROJECT

CRITICAL INFORMATION NEEDED

METHOD OF COMMUNICATION / WORK PRODUCTS

PROJECT MANAGER Cost of funding

Revenue Feasibility Benefits &

drawbacks

Major Milestones

Feasibility reports

Status updates

Funding cost

Email updates Approval from

Policing Agencies

Executive meetings

PROJECT TIME MANAGEMENT Time Management

Feasibility

Time frames

Status updates

Deadlines

Executive meetings

On-site supervision

PROJECT SCOPE MANAGEMENT

Feasibility Revenue Success

criteria

Time frames

Status updates

Deadlines

Executive meetings

Project report

PROJECT QUALITY MANAGEMENT

Feasibility Quality Success

criteria

Time frames

Status updates

Deadlines

Executive meetings

Project report

PROJECT COMMUNICATIONS MANAGEMENT

Feasibility Cost of

Funding Revenue

Feasibility reports

Cost breakdown

Asset

Executive meetings

CHIEF EXECUTIVE OFFICER OF CRIMTRAC

Cost of funding

Revenue Feasibility Benefits &

drawbacks

Major Milestones

Feasibility reports

Status updates

Email updates Approval from

Policing Agencies

Executive

Funding cost

meetings

CHIEF OPERATING OFFICER OF CRIMTRAC

Financial benefits

Corporate services

Success criteria

Milestones Feasibility

reports Daily

updates Funding

cost

Project report On-site

meetings

CHIEF INFORMATION OFFICER OF CRIMTRAC

Success criteria

Feasibility Project

delivery

Time frames

Milestones Updates Project

status

Project Report Email updates

CHAIRPERSON - AUSTRALIAN SECURITIES AND INVESTMENTS COMMISSIONS

Project delivery

Benefits Effectiveness

Project status

Milestones Time frame

Project Report Formal meeting

SECRETARY – AUSTRALIAN GOVERNMENT ATTORNEY-GENERAL’S DEPARTMENT

Project delivery


Major Milestones

Time frame


DIRECTOR GENERAL OF SECURITY - AUSTRALIAN SECURITY INTELLIGENCE ORGANISATION

Project delivery


Feasibility Daily

updates Project

status Funding

cost


CHIEF POLICE OFFICER – AUSTRALIAN CAPITAL TERRITORY POLICE

Project delivery


Feasibility Daily

updates Project

status Funding

cost


NIFS (NATIONAL INSTITUTE OF FORENSIC SCIENCE – DIRECTOR – MR ALASTAIR

Project delivery

Financial

Feasibility Production

cost

Project report Email reports

ROSS gains Effectiveness Production

costs

Major Milestones

Time frame

AUSTRALIAN INSTITUTE OF CRIMINOLOGY

Project delivery


Feasibility Milestones Project

status

Project report Formal meeting

POLICING AGENCIES Project delivery


Feasibility Milestones Daily

updates


1.3 Communication Strategy

Strategy for meeting the information needs of the stakeholders

STAKEHOLDER WHAT THEY NEED HOW WHEN FORMALITY PROJECT MANAGER Cost breakdown

Feasibility documentation and production cost

Project report and status

Financial statements

Meetings for confirmation of projects, email and phone updates, reports

During the project

High-formal

PROJECT TIME MANAGER

Feasibility documentation


Time frames


During the project

High-formality

PROJECT SCOPE MANAGER

Feasibility documentation and production cost


Blue prints


During the project

High-formality

PROJECT QUALITY MANAGER



Blue prints Time frames


During the project

High-formality

PROJECT COMMUNICATION MANAGER



Cost breakdown


During the project

High-formality

CHIEF EXECUTIVE OFFICER OF CRIMTRAC

Cost breakdown Feasibility

documentation and production cost




During the project

High-formality

CHIEF OPERATING OFFICER OF CRIMTRAC


documentation and production cost



During the project

High-formality

CHIEF INFORMATION OFFICIER OF CRIMTRAC


documentation production cost



During the project

High-formality

CHAIRPERSON - AUSTRALIAN SECURITIES AND INVESTMENTS COMMISSIONS


Project report


Start, middle and end of project, critical event milestones

High-formality

SECRETARY – Financial Phone and Start and High-

AUSTRALIAN GOVERNMENT ATTORNEY-GENERAL’S DEPARTMENT

statements Project report

email for updates

end of project

formality

DIRECTOR GENERAL OF SECURITY - AUSTRALIAN SECURITY INTELLIGENCE ORGANISATION


Project report

Phone and email for updates

At the end of project

High-formality

CHIEF POLICE OFFICER – AUSTRALIAN CAPITAL TERRITORY POLICE



Email updates for project status reports

During the project

High-formality

NIFS (NATIONAL INSTITUTE OF FORENSIC SCIENCE – DIRECTOR – MR ALASTAIR ROSS


documentation production cost



Meetings, email and phone updates, reports

During the project

High-formality

AUSTRALIAN INSTITUTE OF CRIMINOLOGY


Project report Production cost

Phone and email for updates

At the end of project

High-formality

POLICING AGENCIES Financial statements

Project report Production cost

Mail updates for project status reports

During the project

High-formality

2 Project Scope StatementRevision History


24/08/2016 1.1 Clayton McShane Finalising draft copy

25/08/2016 1.2 Clayton McShane Editing draft, finished first copy for stage one

2.1 Product Scope DescriptionThe system must allow for users to search and enrol (upload) data from any workstation (such as a desktop computer, laptop and potentially mobile devices). The system must be able to compare facial images, and fingerprints (including palm prints, foot prints, any and all finger prints, and the friction ridges in the hand).

It is required for the entirety of the system to be built from the ground up, as this can prevent issues with building on legacy technology. This allows the development team the opportunity for the system to be built in a way that it is easily maintainable and upgradeable. This means that the system can be improved upon to, for example, implement new biometric modes, or altered to meet future legislative changes.

In addition, a requirement laid out by the tender includes the building of the ground-work capability to build a portable version of the system in future, as an application that works on mobile hand held devices. This application must be able to fulfil the same objectives as the computer application.

The search function must include the use of search filters and unique identifiers. This includes the ability to support matching of one-to-one, and one-to-many for all biometric modes. Data from the system will be stored in a manner that is consistent with government security and privacy requirements, and will allow the users to interact with the database system when connected to the internet. This will require a form of user authentication, such as the use of user ID’s and passwords, to prevent intruders from accessing and modifying sensitive data.

The login system must be able to integrate with existing systems for different departments, and must allow users to communicate to users from these different departments. This provides a global platform for agencies to exchange data with ease.

Functional Product Requirements

Requirement Priority Priority Rating

Biometric database physical components and related software

Mandatory High

Database for user login details Mandatory High

Software infrastructure for the biometric program

Mandatory High

Ground work capability for a portable/hand held version of the system to be built

Desirable Low

Software documentation for the program Mandatory Medium

Manuals for users, system administrators and support teams

Mandatory Low

User Stories

Requirement User Story

Train regular staff members to use the new program

As a user, I need to be trained to effectively use the system.

Train support teams to assist users with any issues that arise with the program or database

As a support member, I need to be trained to learn how the system works to assist the primary users with any complications during use of the system.

2.2 Product DeliverablesThe primary component of the system is a data centre that stores and maintains use of all the current and future biometric information, along with authenticated user profiles. Due to the nature of this sensitive data, the development team will need to account for backup copies of the information, such that there is little chance of loss of data in any circumstances. This will entail the use of several data centres across the country with similar specifications, and each will require a team for maintenance and upgrades as necessary.

Another primary component for the new system is the rollout of a new computer program which allows the user to upload and search for fingerprints, DNA, facial prints, foot prints. When searching for prints, the program connects via an internet connection to the system’s database, analyses the input against available records and returns a result if found. When enrolling prints to the database, the user must attach electronic files of the prints to a form, filled out with details, including names and age. Upon submission, the enrolment form is automatically parsed and uploaded to the databases online.

Throughout the construction of the software applications the developers will build documentation outlining the requirements, an overview of the software components, including code, algorithms,

interfaces and APIs. The documentation also includes manuals for users, system administrators and support teams.

Deliverable DescriptionProject Reports Work Breakdown Structure (WBS)

Budget Schedule

Hardware Server infrastructure to maintain the databases

Software Source code for the program Biometric information database Ground-work for a mobile variant of the program

Documentation Manuals for Users/System Administrators/Support members

Software infrastructure guides, APIs, for use by future developers

Operational use and installation guidesTraining Provide training for system administrators and support

team such that they can use the system and provide support to regular users

Provide some training for regular users such that they can use the system

3 Work Breakdown StructureRevision History


05/08/16 1.1 Jaspreet Singh Construction according to waterfall model.

10/08/16 1.2 Jaspreet Singh Reconsidered waterfall to agile and reconstruction begins

15/08/16 1.3 Jaspreet Singh Design of phases and customer service

24/08/16 1.4 Jaspreet Singh Tutor’s informal review of the WBS table and the tree

25/08/16 1.5 Jaspreet Singh

Sukhneet Singh

Adding Precedence of Elements and durations

3.1 WBS Tree Due to Size of the W.B.S. the file has been made into broken pictures and uploaded.

Please refer to 11.1 Appendices, WBS Tree for the whole XML file.

3.2 WBS TableA table showing the next level of detail:

1 Biometric System Description: The whole deliverable system

Duration: 275 days

Precedence: None

Start date:20/09/2016 End Date:9/10/2017

1.1 Project Plan Description: Plan for successful project completion.

Duration: 36 days

Precedence: None


1.1.1 Initialising Description: setup

Duration: 6 days

Precedence: None


1.1.1.1 Set Up Team Description: making of team

Duration: 2 days

Precedence:None


1.1.1.2 Decide Office Holders Description: Select team members for positons

Duration: 2 days

Precedence: 1.1.1.1


1.1.1.3 Arrange Tender Documents Description: Making the tender documents available to the team

Duration: 2 days

Precedence: 1.1.1.1, 1.1.1.2


1.1.1.4 Team Meetings Description: Team Interactions for project.

Duration: 2 days

Precedence:1.1.1.2


1.1.1.5 Client Meetings Description: Meeting the client for further tender clearance and negotiations

Duration: 2 days

Precedence:1.1.1.2


1.1.2 Project Analysis Description: Understanding and evaluating the project.

Duration: 10 days

Precedence:1.1.1


1.1.2.1 Analysing Tender Requirements Description: Understanding and evaluating the needs of tender

Duration: 10 days

Precedence:1.1.1.3


1.1.2.2 Analysing Software and Hardware Requirements

Description: understand the software and hardware needs

Duration: 4 days

Precedence: 1.1.1.3


1.1.3 Stakeholder Management Description: Plan to deal with stakeholders

Duration: 5 days

Precedence: 1.1.1.5


1.1.4 Communication Management Description: Plan for interaction between employs and stakeholders

Duration: 4 days

Precedence:1.1.1.1


1.1.5 Scope Management Description: Looking for the things the project will cover

Duration: 20 days

Precedence: 1.1.2


1.1.5.1 Project Scope Description Description: Describing the umbrella of the project

Duration: 5 days

Precedence: None


1.1.5.2 W.B.S. Tree Description: Work Breakdown Structure tree

Duration: 10 days

Precedence: None


1.1.5.3 W.B.S. Table Description: Work Breakdown Structure table

Duration: 10 days

Precedence:1.1.5.2


1.1.6 Time Management Description: Scheduling and estimation plan

Duration: 15 days

Precedence: None


1.1.7 Cost Management Description: Managing the budget plan

Duration: 10 days

Precedence: None


1.1.8 Integration Management Description: Plan to join different parts of Project

Duration: 10 days

Precedence: None


1.1.9 Procurement Management Description: Managing the resources and services from different firms and organisations

Duration: 5 days

Precedence: None


1.1.10 Update Management Description: documenting and planning the updates of the project

Duration: 5 days

Precedence: None


1.1.11 Quality Management Description: Plan for quality deliverable

Duration: 10 days

Precedence: None


1.1.12 Risk Management Description: Managing and planning the risks of the and for the plan

Duration: 10 days

Precedence: None


1.1.13 HR Management Description: Managing the human resouces

Duration: 10 days

Precedence: None


1.2 Phase 1: Data Capture and Storage Description: First deliverable of agile project

Duration: 58 days

Precedence: None


1.2.1 Design Description: design of first deliverable

Duration: 10 days

Precedence: None


1.2.1.1 Data Capture Design Description: design for the feature of capturing data

Duration: 10 days

Precedence: None


1.2.1.2 Data Storage Design Description: Designing the storage for the data

Duration: 10 days

Precedence: None


1.2.1.3 U.M.L.'s Description: Unified Modelling Language diagrams to visualise the design

Duration: 3 days

Precedence: None


1.2.1.4 R.B.T.'s Description: Requirement behaviour trees to understand the requirements of tender

Duration: 5 days

Precedence: None


1.2.1.5 I.B.T.'s Description: Integrated Behaviour trees

Duration: 2 days

Precedence: 1.2.1.4


1.2.2 Implementation Description: Applying the designs to practice

Duration: 10 days

Precedence: 1.2.1


1.2.2.1 Capture Service Development Description: implementing the feature of capturing data.

Duration: 10 days

Precedence:1.2.1.1


1.2.2.1.1 Development of capture service for Desktop

Description: implementing the feature of capturing data for desktop computers.

Duration: 10 days

Precedence:1.2.1.1


1.2.2.1.2 Implementation of Mobile Application of Service

Description: implementing the feature of capturing data for mobile and tablet devices.

Duration: 10 days

Precedence: 1.2.1.1


1.2.2.2 Implementing Data Storage Service Description: Implementing the service to store data in real time.

Duration: 20 days

Precedence: 1.2.1.2


1.2.2.2.1 Associating Data with Events Description: Making relations between data and events

Duration: 20 days

Precedence: None


1.2.3 Integration Description: joining the feature of first stage deliverable together

Duration: 10 days

Precedence: 1.2.2.2.1, 1.2.2.1.2


1.2.3.1 Integrating Capture Service and Storage Services

Description: joining the capture service and data storage service to work in coordination to each other.

Duration: 10 days

Precedence: 1.2.2.2.1, 1.2.2.1.2


1.2.4 Testing Description: testing the stage one deliverables

Duration: 8 days

Precedence: 1.2.3.1


1.2.4.1 Unit Testing Description: Testing each part of the deliverable system individually

Duration: 5 days

Precedence: 1.2.3.1


1.2.4.2 Hardware Testing Description: Testing the hardware for software to work on it.

Duration: 2 days

Precedence: None


1.2.4.3 Software testing Description: testing the software system

Duration: 5 days

Precedence: 1.2.3.1


1.2.4.4 Integration Testing Description: Testing of the units together with respect to each other

Duration: 2 days

Precedence: 1.2.4.2, 1.2.4.3


1.2.4.5 Feedbacks Description: feedbacks of testing team

Duration: 1 day

Precedence: 1.2.4.4, 1.2.4.3, 1.2.4.2, 1.2.4.1


1.2.5 Approvals Description: getting yes for proceeding to next step

Duration: 10 days

Precedence:1.2.4.5


1.2.5.1 Project Manager Approval Description: Seeking yes from project manager to proceed to next step.

Duration: 2 days

Precedence: 1.2.4.5


1.2.5.2 Client Approval Description: Seeking yes from client to proceed to next step.

Duration: 4 days

Precedence:1.2.5.3


1.2.5.3 Expert Approval Description: approval from expert advisors.

Duration: 4 days

Precedence: 1.2.5.1


1.3 Phase 2: Enrolment Matching and Database Management

Description: Second having a design plan for second deliverable of agile project

Duration: 66 days

Precedence: 1.2


1.3.1 Design Description: designing the deliverables of stage 2.

Duration: 25 days

Precedence: None


1.3.1.1 Design Phase 1 Feedbacks Update Description: design of the updates required after the feedback of stage 1.

Duration: 10 days

Precedence:1.2.4.5


1.3.1.2 Database Management Design Description: Designing the management of database

Duration: 10 days

Precedence: 1.3.1.1


1.3.1.3 Enrolment Service Design Description: Designing how the data will be enrolled.

Duration: 15 days

Precedence: 1.3.1.1


1.3.1.4 Design Data Matching Feature Description: designing of the feature which compares various data packets

Duration: 10 days

Precedence:1.3.1.1


1.3.2 Implementation Description: implying the design of the phase 2.

Duration: 20 days

Precedence: 1.3.1


1.3.2.1 Implementing Phase 1 Feedback Description: implementing the phase 1 feedback design for updating

Duration: 15 days

Precedence: 1.3.1.1


1.3.2.2 Implement Data Management practice Description Implying the data management

Duration: 12 days

Precedence


1.3.2.3 Development of Enrolment service Description: Coding the enrolment service

Duration: 20 days

Precedence:1.3.1.3


1.3.2.4 Implementing Biometric Data Matching Service

Description: Creating the feature to match the biometric data.

Duration: 10 days

Precedence: 1.3.1.4


1.3.3 Integration Description: integrating the bits and pieces together to work

Duration: 5 days

Precedence: 1.3.2


1.3.3.1 Integrating Phase 1 Update and Phase 2 additions

Description: integrating the update after the feedbacks and new features added in the phase

Duration: 5 days

Precedence;1.3.2


1.3.4 Testing Description: testing phase 2

Duration: 6 days

Precedence: 1.3.3


1.3.4.1 Testing Phase 1 Update Description: testing the updates of phase 1 after feedback.

Duration: 2 days

Precedence: 1.3.1.1


1.3.4.2 Testing Hardware Compatibility Description: Testing if the updates work correctly on the hardware available.

Duration: 1 day

Precedence:1.3.3


1.3.4.3 Testing Software Compatibility Description: Testing the software if it works on terminals good.

Duration: 4 days

Precedence:1.3.3


1.3.4.4 Testing Integration of Parts Description: Testing if the units of software are working fine with each other.

Duration: 2 days

Precedence: 1.3.3


1.3.4.5 Feedbacks Description: Tester reviews on the software produced at level 2

Duration: 2 days

Precedence: 1.3.4.1, 1.3.4.2, 1.3.4.3, 1.3.4.4


1.3.5 Approvals Description: Get assurance if the part meets the success criteria.

Duration: 10 days

Precedence: 1.3.4


1.3.5.1 Project Manager Approval Description: Getting approved from project manager.

Duration: 2 days

Precedence: 1.3.4


1.3.5.2 Client Approval Description: getting the approval from client

Duration: 4 days

Precedence: 1.3.5.3


1.3.5.3 Expert Approval Description: getting approval from expert consultants.

Duration: 4 days

Precedence: 1.3.5.1


1.4 Phase 3: Data application Description: Developing data applications

Duration: 53 days

Precedence:1.3


1.4.1 Design Description: Designing the phase 3

Duration: 20 days

Precedence: 1.3


1.4.1.1 Design Update Phase 2 Feedbacks Description: Designing the updates required after phase 2 feedbacks.

Duration: 10 days

Precedence: 1.3, 1.3.4.5


1.4.1.2 Designing Forensic Information system Description: Design for the system for forensic processing of information

Duration: 10 days

Precedence: 1.3


1.4.1.3 Dashboard Service Design Description: design for features like dash board services

Duration: 10 days

Precedence: 1.3

Start date13/03/2017 End Date:24/03/2017

1.4.1.4 Data Exchange Service design Description: design on how the data will be exchanged and will be considered.

Duration: 10 days

Precedence: 1.3


1.4.1.5 Identity Report Service Design Description: design on how to make reports of identities of inputs.

Duration: 5 days

Precedence: 1.3


1.4.1.6 Designing Identification Management System

Description: designing the feature to manage identifications

Duration: 5 days

Precedence: 1.3


1.4.2 Implement Description: implementing the design of phase 3

Duration: 20 days

Precedence:1.4.1


1.4.2.1 Implementing Phase 2 Updates Description: implementing the design of feedback updates of phase 2.

Duration: 15 days

Precedence:1.4.1, 1.4.1.1


1.4.2.2 Implement Forensic Information Service

Description: Implying the design of forensic information system.

Duration: 15 days

Precedence: 1.4.1, 1.4.1.2


1.4.2.3 Implement Dashboard Services Description: programming the features of dashboard services.

Duration: 15 days



1.4.2.4 Develop Data Exchange Services Description: Implying the service of exchanging data

Duration: 20 days

Precedence: 1.4.1, 1.4.1.4


1.4.2.5 Implement Identity Report Service Design

Description: developing the feature of identity report service design

Duration: 5 days



1.4.2.6 Develop Identity Management Service Description: Developing management system for identity reports.

Duration: 5 days



1.4.3 Integration Description: Joining the different feature to work in compatibility.

Duration: 5 days

Precedence:1.4.2, 1.4.2.1, 1.4.2.2, 1.4.2.3, 1.4.2.4, 1.4.2.5, 1.4.2.6


1.4.3.1 Integrating Phase 2 with Feedback Update

Description: joining the updated phase 2

Duration: 5 days

Precedence: 1.4.2.1


1.4.3.2 Integrating Updated Version with New Additions

Description: adding the updates to new features.

Duration: 2 days

Precedence: 1.4.2.1, 1.4.2.2, 1.4.2.3, 1.4.2.4, 1.4.2.5, 1.4.2.6


1.4.4 Testing Description: testing phase 2 of system

Duration: 8 days

Precedence: 1.4.1, 1.4.2, 1.4.3


1.4.4.1 Testing Updated Phase 2 Description: testing the phase 2 after the feedback updates.

Duration: 4 days

Precedence: 1.4.2.1


1.4.4.2 Test Data Mapping Description: testing the feature of data mapping

Duration: 5 days

Precedence:1.4.2.2


1.4.4.3 Test durability Description: testing the durability of the software system.

Duration: 5 days

Precedence: 1.4.2


1.4.4.4 Test Data Integrity Description: testing the feature of joining or integrating data.

Duration: 6 days

Precedence: 1.4.2


1.4.4.5 Feedbacks Description: feedbacks on phase 3

Duration: 2 days

Precedence: 1.4.4.1, 1.4.4.2, 1.4.4.3, 1.4.4.4


1.4.5 Approvals Description: Getting yes from office holders

Duration: 10 days

Precedence: 1.4.4


1.4.5.1 Project Manager Approval Description: Getting project managers yes if the phase 3 development makes project closer to success.

Duration: 2 days

Precedence: 1.4.4


1.4.5.2 Expert Approval Description: Getting yes from the board of expert advisors.

Duration: 4 days

Precedence: 1.4.5.1


1.4.5.3 Client Approval Description: Getting yes from the client if the deliverable meets his requirements.

Duration: 4 days

Precedence:1.4.5.2


1.5 Final Phase 4: Service Additions Description: Leading the project to the final phase of adding all the service additions

Duration: 73 days

Precedence:1.4


1.5.1 Design Description: Design of phase 4 and how will it be created.

Duration: 10 days

Precedence: 1.4


1.5.1.1 Design phase 3 Feedback Update Description: Design of update after feedback of phase 3.

Duration: 5 days

Precedence: 1.4, 1.4.4.5


1.5.1.2 Change Management Service Design Description: Designing change management service design.

Duration: 10 days

Precedence: 1.4


1.5.1.3 Design for Portable Version Description: Design for creating the portable version of the system.

Duration: 7 days

Precedence: 1.4


1.5.1.4 Expert Sharing Service Design Description: Design for sharing service design.

Duration: 10 days

Precedence: 1.4


1.5.1.5 Design for System Integrated Service Description: Integrated service for making integrated system service plan.

Duration: 10 days

Precedence: 1.4


1.5.1.6 Support service Design Description: Designing the support system to create the support service design.

Duration: 5 days

Precedence: 1.4


1.5.2 Implementation Description: Implementation of design of phase 4.

Duration: 20 days

Precedence:1.5.1


1.5.2.1 Implementing Support Service Description: Implementing the support service of system

Duration: 20 days

Precedence:1.5.1


1.5.2.1.1 Implementing Service Management services

Description: Developing Service management.

Duration: 10 days

Precedence:None


1.5.2.1.2 Implement BAU Support Description: developing BAU support

Duration: 20 days

Precedence: None


1.5.2.1.3 Implement Performance Monitoring Services

Description: implying performance monitoring for system

Duration: 10 days

Precedence: None


1.5.2.2 Implementing Phase 3 Update Description: Implying the updates of Phase 3.

Duration: 10 days

Precedence: 1.5.1.1


1.5.2.3 Implementing the Portable Version Description: Portable Version development.

Duration: 5 days

Precedence:1.5.1.3

Start date:8/06/2017 End Date14/06/2017

1.5.2.4 Implementation Sharing Service Design Description: Development of Sharing Service in

the system.

Duration: 10 days

Precedence:1.5.1.4


1.5.2.5 Implementing System Integrated Service

Description: Programming the system Integrated Service.

Duration: 5 days

Precedence:1.5.1.5


1.5.2.5.1 Integrating System with Other Agencies Systems

Description: Development of service to integrate system with other agencies.

Duration: 5 days

Precedence: 1.5.1.5


1.5.2.6 Implement Change Management Service

Description: Develop change management system.

Duration: 5 days

Precedence: 1.5.1.5


1.5.3 Integration Description:

Duration: 5 days

Precedence:1.5.2


1.5.3.1 Integration Phase 3 with Feedback Update

Description: Joining the phase 3 with updates

Duration: 5 days

Precedence:None


1.5.3.2 Integrate Updated Version with Phase 4 Additions

Description: integrate updated phase 3 with newer units added.

Duration: 1 day

Precedence: None


1.5.4 Testing Description: Testing the final stage of the system.

Duration: 10 days

Precedence:1.5.3


1.5.4.1 Testing Updated Phase 3 Design Description: Testing update of Phase 3

Duration: 4 days

Precedence: 1.5.2.2


1.5.4.2 Perform Unit Testing Description: Performing tests for every unit before final delivery.

Duration: 10 days

Precedence:1.5.3


1.5.4.3 Implement Performance Testing Description: Developing the testing of system Performance.

Duration: 10 days

Precedence:1.5.3


1.5.4.4 Perform Integration Testing Description: Performing tests to check the integration of the units of system.

Duration: 10 days

Precedence: 1.5.3


1.5.4.5 Perform system Testing Description: Perform the test to see the working of the whole service.

Duration: 10 days

Precedence:1.5.3


1.5.4.6 Conduct User Acceptance Testing Description: Test if the User Acceptance.

Duration: 5 days

Precedence:1.5.3


1.5.5 Approvals Description: Getting Approval of the Stakeholders and Officeholders.

Duration: 28 days

Precedence: None


1.5.5.1 Project Manager Approval Description: Getting yes from the Project Manager.

Duration: 4 days

Precedence: 1.5.4


1.5.5.2 Expert approval Description: Getting Approval from the advisors of specialisation

Duration: 8 days

Precedence: 1.5.4


1.5.5.3 Client Approval Description: Getting the approval of clients

Duration: 8 days

Precedence: 1.5.5.2


1.5.5.4 International Standard Organisation Approval

Description: Getting the Approval of international Standard Organisation.

Duration: 20 days

Precedence: 1.5.5.2


1.6 Technical Training Description: technical knowledge of the system to be given.

Duration: 25 days

Precedence:1.5.5


1.6.1 Project Presentation Description: Presenting the project to the client

Duration: 2 days

Precedence:1.5.5


1.6.2 Deployment Description: Delivery of the project/ system

Duration: 10 days

Precedence: 1.5.5


1.6.3 User Training Description: Technique to use the system to be provided to the users

Duration: 14 days

Precedence: 1.5.5


1.6.4 User Manual Description: Document the required information for the usage of system

Duration: 5 days

Precedence:1.5.5


1.6.5 User Feedback Surveys Description: Get the feedbacks of people using it for further references

Duration: 2 days

Precedence: 1.5.5


1.6.6 System Maintenance Description: Maintaining the system throughout the tender lifetime.

Duration: 25 days

Precedence: 1.5.5


4 EstimationRevision History


20/08/2016 1.1 Nathaniel Pather Added Choice of Technique

22/08/2016 1.2 Nathaniel Pather Added Justification (Expert, Analogous, Bottom Up)

22/08/2016 1.3 Nathaniel Pather Updated Justification (Three-Point Estimating, Group Decision-Making)

20/08/2016 1.4 Nathaniel Pather Added Estimation (Hardware, Software, Training)

07/09/2016 2.1 Clayton McShane Added choice of technique, initial stages of the user story point

09/09/2016 2.2 Clayton McShane Initial stages of justification, expanded user story points

14/09/2016 2.3 Clayton McShane Added more to justification, added metrics for user stories

20/09/2016 2.4 Clayton McShane Finalised story points, added more to justification

22/09/2016 2.5 Clayton McShane Tweaks to sections.

4.1 Choice of Technique Several techniques were chosen to accurately estimate the schedule and budget requirements of the project. These techniques include: Expert Judgement, Analogous Estimation, Bottom-Up Estimating, Three-Point Estimating, and Group Decision-Making Techniques.

Agile story point counting has been used to sample user stories and allocate values for various metrics.

4.2 JustificationExpert Judgement

The Biometric Vulnerability Assessment Expert Group (BVAEG) was established in 2010 to share knowledge and experience about biometric development. Areas they provide assistance in include cost assessment, and vulnerability assessment. Raul Sanchez-Reillo, from University Carlos III of Madrid, will assist us in these areas. By doing so we are ensured reliable information, as well as further insight into combining estimation techniques.

Analogous Estimation

The National Automated Fingerprint Identification System (NAFIS) was established in 1986 to provide fingerprint matching methods for law enforcement agencies in Australia. The system was updated in 2001 and Tendered by CrimTrac. CrimTrac will provide assistance in cost assessment by providing previous historical data from the development of NAFIS. By using this method we potentially save costs and time that other techniques can use more of. Doing so however can also be less accurate. Due to NAFIS being quite similar to the current project, and with the assistance of the previous Tenderer, this technique increases in reliability.

Bottom-Up Estimating

CrimTrac has a provided a detailed tender specifying the functionality of the proposed system. By breaking the functionality into core components we are presented with generic system components that the proposed system will require. We can also determine the level of effort required to implement the functionality depending on their complexity. By using these system components and their effort required we can estimate specific details of the proposed system. These specific estimates can then be summarised for further reporting and tracking.

Three-Point Estimating

Three-Point Estimation is an analogous estimation technique where ‘optimistic’, ‘pessimistic’, ‘and ‘most likely’ values are used to determine a final ‘expected’ estimate. By working with several other analogous techniques providing historical data, Three-Point Estimation works well in conjunction with the aforementioned estimation techniques. Three-Point Estimation also clarifies a range of uncertainty that other techniques do not provide.

The expected estimates will be calculated using the ‘Triangular Distribution’ Three-Point Estimation formula, which is as follows:

Estimate = Optimistic + Most Likely + Pessimistic) / 3

Group Decision-Making Techniques

Team based approaches, such as brainstorming, or nominal group techniques, are useful for engaging team members to improve estimate accuracy and commitment to meeting the resulting estimates. Due to the size of our development team, as well as all team members closely related to the technical execution of the project, additional information is gained and more accurate estimates are obtained.

Agile Story Point Counting

The agile story point counting technique was chosen for this project, as the software development lifecycle being used is also the agile method. Story point counting allows for an accurate measurement of time, money and resources that is to be used. It gathers the knowledge of the developers and project runners involved to determine accurate estimates based on past experience.

Agile story point counting also allows for the project team to adjust the story points in later iterations as progress continues.

4.3 Estimation Hardware Procurement

The estimates for hardware procurement were produced using a combination of Expert Judgement, Analogous Estimation, Bottom-Up Estimation, Three-Point Estimation, and Group Decision-Making Techniques. As a result of our research into hardware procurement, a total of 4 data sources were compiled – a list of which can be found in Appendix A:1.0 – Hardware Procurement Industry Data. From these estimation techniques estimates were calculated using the ‘Triangular Distribution’ Three-Point Estimation technique.

Budget (per server)

Most Likely: AUD $5,000.00

Optimistic: AUD $4,000.00

Pessimistic: AUD $8,000.00

Expected = (Optimistic + Most Likely + Pessimistic) / 3

Expected = (4000 + 5000 + 8000) / 3

Expected = AUD $5666.67 per server

Hardware Installation

The estimates for hardware installation were produced using a combination of Expert Judgement, Analogous Estimation, Bottom-Up Estimation, Three-Point Estimation, and Group Decision-Making Techniques. As a result of our research into hardware procurement, a total of 4 data sources were compiled – a list of which can be found in Appendix A:1.0 – Hardware Installation Industry Data. From these estimation techniques estimates were calculated using the ‘Triangular Distribution’ Three-Point Estimation technique.

Budget (per server)

Most Likely: AUD $560.00

Optimistic: AUD $489.00

Pessimistic: AUD $659.00


Expected = (489 + 560 + 659) / 3

Expected = AUD $569.64 per server

Software Estimation

The estimates for biometric software development kits were produced using a combination of Expert Judgement, Analogous Estimation, Bottom-Up Estimation, Three-Point Estimation, and Group Decision-Making Techniques. As a result of our research into hardware procurement, a total of 4 data sources were compiled – a list of which can be found in Appendix A:1.0 – Biometric Software Development Kits Industry Data. From these estimation techniques estimates were calculated using the ‘Triangular Distribution’ Three-Point Estimation technique.

Budget (per licence)


Optimistic: AUD $2,000.00



Expected = (2000 + 2875 + 3500) / 3

Expected = AUD $2791.67 per licence

Training Estimation

The estimates for staff training were produced using a combination of Expert Judgement, Analogous Estimation, Bottom-Up Estimation, Three-Point Estimation, and Group Decision-Making Techniques. As a result of our research into staff training, a total of 4 data sources were compiled – a list of which can be found in Appendix A:1.0 – Staff Training Industry Data. From these estimation techniques estimates were calculated using the ‘Triangular Distribution’ Three-Point Estimation technique.

Budget (per staff member)


Optimistic: AUD $659.00



Expected = (659+ 1041 + $1,469) / 3

Expected = AUD $1,156.34 per staff member

Metrics

- Time – How long it will take to complete an objective.- Effort – How many people it will require to complete the task.- Risk – The likeliness of something going wrong and hindering progress on the task, and the

project.- Resources – How much resources, such as hardware, software and equipment, will be

needed to complete the task.

MetricsValues Time Effort Risk Resources1 < 1 Month Very Low Very Low Very Low2 < 3 Months Low Low Low3 < 6 Months Medium Medium Medium4 < 12 Months High High High5 > 12 Months Very High Very High Very High

PriorityM MandatoryO OptionalD Desirable

Story Points

ID User Story Priority Time Effort Risk Resources TotalUS01 As a User, I want to be able to

access the Biometric Identification service to view, search and enrol data.

M 1 2 1 3 7

US02 As a System Administrator, I need full access to the Biometric Identification services and database.

M 1 2 1 2 6

US03 As a User, I want 24/7 support services to be easily accessible.

M 1 4 1 3 9

US04 As a System, I want to store information pertaining to enrolled person’s details and biometric information, including DNA, eye prints, facial prints, hand and foot prints.

M 4 4 3 4 15

US05 As a Support Team member, I want the training to be able to provide technical support for all aspects of the system.

M 1 3 1 3 8

US06 As a System, I want to be accessible by users at all times, and be able to provide biometric information of all available types.

M 4 5 3 4 16

US07 As a System Administrator, I need to be trained in all aspects of maintaining and using the system, and be able to provide support when necessary.

M 4 4 3 4 15

Total 76

Estimation User Story Explanation

The purpose of the User Story Points table is to define in a clear manner some of the tasks that require attention throughout the project development. The table defines the ID for each user story and a description of the user story. Each user story is given a value for their priority, time, effort, risk and resources, in order to describe how much attention is required for each user story. These values are tallied and thus can be ordered to show tasks which require more attention, and need to be a priority.

In this instance, the three major user stories are US04, US06 and US07, as these user stories define the requirements for the main component of the system. As such, they have large time, effort, risk and resource requirements. In comparison, US02 requires very little resources because the bulk of the requirements for this user story will be completed with the main system.

5 ScheduleRevision History


10/09/2016 2.1 Jaspreet Singh Plan for Gantt Chart

15/09/2016 2.2 Jaspreet Singh Implementation of Gantt Chart

17/09/2016 2.3 Jaspreet Singh Plan for Network Diagram

19/09/2016 2.4 Jaspreet Singh Implementation of Network Diagram

22/09/2016 2.5 Jaspreet Singh Doing Critical Path and Stuff

14/09/2016 2.6 Jaspreet Singh Updating network Diagram after the feedback

5.1 Gantt Chart

A Gantt chart of schedule based on the W.B.S. Tree and Table. The Gantt Chart depicts the following:

Task Name Start Date Finish Date Late Start Late Finish Free Slack Total Slack Critical Path Late Tasks

Following Keys belong to the Gantt chart:

The red highlighted strip in Gantt chart depicts critical path.

The Blue Slim line tells the Slack in the Project.

The dark grey part tells the late tasks of the schedule.

5.1.1.1: Above is an overall Gantt Chart of the project.

The following is the detailed Gantt Chart:

s

Refer To Appendix 11.4 for detailed Gantt Chart.

5.2 Network Diagram

The following is the network diagram of the project. The red boxes Are Part of critical Path. It depicts the following:

Name Of Task Duration Start Finish Late Start Late Finish If the file is a Part of Critical Path or not.

Network diagram Whole Diagram Part One for reference Actual file attached in the end of section and Appendix

Network diagram Whole Diagram Part Two for reference Actual file attached in the end of section and Appendix

This is Photo Of initial stage at no bifurcation. More Readable Link Is provided in the End Of Section and Appendix.

Now more detailed shots are provided which will Be supported By a attached file at the end

Please refer to Appendix 11.5 for detail Network Diagram.

6 Budget & ProcurementRevision History


20/08/2016 1.1 Nathaniel Pather Added Panned Budget (Hardware, Software, Training)

20/08/2016 1.2 Nathaniel Pather Added Overall Low Level Budget

21/09/2016 2.1 Nathaniel Pather Added Overall High Level Budget

22/09/2016 2.2 Nathaniel Pather Added Cost Management

22/09/2016 2.3 Nathaniel Pather Added Procurement Management

6.1 Budget 6.1.1 Planned Low-Level BudgetA low level budget has been created for the initial stages of the project.

Hardware Budget

The unit costs for each hardware item were calculated using the estimation processes outlined in section 4.3 – Hardware Estimation.

Item Unit Cost Qty TotalServer Hardware ProcurementSee: 4.3 Hardware Procurement

5,666.67 297 $1,683,000.99

Total Hardware Budget AUD $1,683,000.99

Software Budget

The licensing and development costs used for each software item were calculated using the estimation process outlined in section 4.3 – Software Estimation.

Item Unit Cost Qty TotalBiometric SDK LicencingSee: 4.3 Software Estimation

$2,791.67 5 $13,958.35

Total Software Budget AUD $13,958.35

Installation Budget

The unit costs for installing each system at required locations were calculated using the estimation processes outlined in section 4.3 – Staff Training

Item Unit Cost Qty TotalServer Hardware InstallationSee: 4.3 Hardware Installation

$569.64 297 $169,183.08

Total Installation Budget AUD $169,183.08

Training Budget

The unit costs for training each staff member were calculated using the estimation processes outlined in section 4.3 – Staff Training

Item Unit Cost Qty TotalStaff TrainingSee: 4.3 Staff Training

$1,156.34 5940 $6,868,659.60

Total Training Budget AUD $6,868,659.60

Overall Project Budget

Item TotalHardwareSee: 6.1.1 Hardware Budget

1,683,000.99

SoftwareSee: 6.1.1 Software Budget

13,958.35

InstallationSee: 6.1.1 Installation Budget

169,183.08

TrainingSee: 6.1.1 Training Budget

6,868,659.60

Total Project Budget $8,565,788.12

6.1.2 Planned High-Level BudgetA high level budget has been created for the remaining duration of the project. Using the project scope, WBS, and estimation used in the low-level budget, an in depth estimation was designed.

Project Plan

Initialising Costs

Tasks CostsSet up Team $3,000.00Decide Office Holders $200.00Arrange Tender Documents $500.00Team Meetings $100.00

Client Meetings $100.00Total 3,900.00

Project Analysis

Tasks CostsAnalysing Tender Requirements $500.00Analysing Software and Hardware Requirements

$799.00

Total 1,299.00

Scope Management

Tasks CostsProject Scope Description $4,965.00WBS Tree $4,162.99WBS Table $4160.00Total $13,287.99

Total Project Plan Cost: $18,486.99

Data Capture and Storage

Design

Tasks CostsData Capture Design $3999.00Data Storage Design $5,999.00UMLS $1,000.00RBTS $1,000.00IBTS $1,000.00Total $11,998.00

Implementation

Capture Service Development

Tasks CostsDevelopment of Capture service for Desktop $14,162.59Implementation of Mobile Application Service $16,186.93Total $30,349.52

Implementing Data Storage Service

Tasks CostsAssociating Data with Events $3,000.00Total $3,000.00

Integration

Tasks Costs

Integrating Phase 1: Update $6,000.00Integrating Phase 2: Additions $12,000.00Total $18,000.00

Testing

Tasks CostsTesting Phase 1: Update $6,000.00Testing Hardware Compatibility $4,160.00Testing Software Compatibility $4,160.00Testing Integration of Parts $10,000.00Feedbacks $1,499.00Total $25,819.00

Approvals

Tasks CostsProject Manager Approval $50.00Client Approval NilExpert Approval $216.59Total $266.59

Total Data Capture Storage Cost: $89,433.11

Phase 2: Enrolment Matching and Database Management

Design

Tasks CostsDesign Phase 1: Feedback Update $2,000.00Database Management Design $15,000.00Enrollment Service Design $6,000.00Design Data matching feature $33,500.00Total $56,500.00

Implementation

Tasks CostsImplementing Phase 1: Feedback $2,000.00Implement Data Management Practice $999.99Development of Enrollment Service $12,000.00Implementing Biometric Data Matching Service $96,665.95Total $111,665.94

Integrating

Tasks CostsIntegrating Phase 1: Update $6,000.00Phase 2: Additions $12,000.00Total $18,000.00

Testing

Tasks CostsTesting Phase 1: Update $6,000.00Testing Hardware Compatibility $4,160.00Testing Software Compatibility $4,160.00Testing Integration of Parts $10,000.00Feedbacks $1,499.00Total $25,819.00

Approvals

Tasks CostsProject Manager Approval $50.00Client Approval NilExpert Approval $216.59Total $266.59

Total Enrolment Matching and Database Management Cost: $212,251.53

Phase 3: Data Application

Design

Tasks CostsDesign Update Phase 2: Feedbacks $2,000.00Designing Forensic Information System $39,000.00Dashboard Service Design $12,000.00Data Exchange Service design $29,000.00Identity Report Service Design $34,000.00Designing Identification Management System $20,000.00Total $136,000.00

Implementation

Tasks CostsImplementing Phase 2: Updates $2,000.00Implement Forensic Information Service $14,000.00Implement Dashboard Services $12,000.00Develop Data Exchange Services $19,000.00Implement Identity Report Service Design $26,000.00Develop Identity Management Service $39,000.00Total $112,000.00

Integration

Tasks CostsIntegrating Phase 2: Feedback Update $10,000.00Integrating Updated Version $12,000.00Total $22,000.00

Testing

Tasks CostsTesting Updated Phase 2 $4,000.00Test Data Mapping $3,000.00Test durability $3,000.00Test Data Integrity $3,000.00Feedbacks $2,000.00Total $15,000.00

Approvals

Tasks CostsProject Manager Approval $50.00Expert Approval $216.59Client Approval NilTotal $216.59

Total Phase 3: Data Application cost: $285,216.59

Final Phase 4: Service Additions

Design

Tasks CostsDesign Phase 3: Feedback Update $6,000.00Change Management Service Design $1,000.00Design for Portable Version $7,959.55Expert Sharing Service Design $3,000.00Design for System Integrated Service $15,000,00Support service Design $3,000.00Total $89,959.55

Implementation

Implementing Support Service

Tasks CostsImplementing Service Management Services $2,965.99Implement BAU Support $1,499.99Implement Performance Monitoring Services $699.67Total $5,165.65

Implementing System Integrated Service

Tasks CostsIntegrating System with Other Agencies Systems

$22,000

Total $22,000

Integration

Tasks CostsIntegration Phase 3: Feedback Updates $6,000.00Integrate Updated version with Phase 4: Additions

$12,000.00

Total $18,000.00

Testing

Tasks CostsTesting Updated Phase 3: Design $10,000.00Perform Unit Testing $600.00Implement Performance Testing $600.00Perform Integration Testing $600.00Perform System Testing $600.00Conduct User Acceptance Testing $600.00Total $13,000.00

Approvals

Tasks CostsProject Manager Approval $50.00Expert Approval $216.59Client Approval NilInternational Standard Organisation Approval $149.99Total $416.58

Total Final Phase 4: Service Additions Cost: $148,541.78

Technical Training

Tasks CostsProject Presentation $200.00Deployment $500.00User Training $6,868,659.60User Manual $675.00User Feedback Surveys $445.99System Maintenance $367.00Total $6,870,847.59

Total Technical Training Cost: $6,870,857.59

Total Project CostTotal Project Cost: $7,535,443.91

Overall Project Budget

Item TotalProject Plan $18,486.99Data Capture and Storage $89,433.11Enrolment Matching and Database Management

$212,251.53

Data Application $285,216.59Service Additions $148,541.78Technical Training 6,870,857.59Total Project Budget $7,535,443.91

6.1.4 Cost Management

The cost estimates identified in sections 4.3, 6.1.1, and 6.1.2 will be used as cost assessment criteria and compared against the actuals costs. The cost estimates will also determine the cost of low level elements in the work breakdown structure and project schedule. These low level element costs will then be used to determine high level element costs. The overall planned budget will become the cost baseline for the project. With the use of Microsoft Project the actual costs will be tracked and compared against the cost baseline throughout the project.

6.2 Procurement6.2.1 Procurement Management

Contract Administration

1. When undergoing procurement contract requests in the project, a formal procedure is carried out where the procurement administrators from each company meet to discuss contractual obligations and legal rights.

2. The documentation identifies and records the contracts into a table of contracts, known as the “Contract Log”, and stores the discussed information.

3. For suppliers, a quality control assessment is conducted to ensure the product is up to standard.

4. The procurement administrators from each company finalise the contract which is to be approved by the project manager from each company.

5. Procurement Reviews may occur during the project to ensure the supplier is meeting contractual obligations and legal rights. The information gained may also determine the competency of the supplier for future projects.

6. Any changes to the contract must go through a “Change Request Form” (see section 7.1.2).

7. The contract may be closed in advance due to mutual agreement from each company.

Resource Purchase Authorisation

The procurement administrator has the authority to purchase resources for the project under a given amount. The amount specified is $25,000.00. Any purchases above this amount must be forwarded to a board of executives, consisting of CrimTrac and Biometric Solution Managers. This prevents any unnecessary spending of large amounts of money, while also saving time when purchasing low cost resources.

7 Change Control PlanRevision History


10/09/2016 1.1 Nathaniel Pather Added change control approach, control heirachy diagram, change control procedure (all drafts).

11/09/2016 2.1 Sy Le 7.1.1, 7.1.2 Updated the change control approach & change control procedure with information, and corrected punctuation.

19/09/2016 2.2 Sy Le 7.1.1, 7.1.2 Updated control hierarchy diagram, added flow chart for change request.

20/09/2016 2.3 Sy Le 7.1.1, 7.1.2, Updated change control approach and change control procedure. Added content to 7.1.3 reviews and audit.

21/09/2016 2.4 Sy Le 7.1.1 7.1.2 Got peer feedback, Updated change control approach and change control procedure.

21/09/2016 2.5 Sy Le 7.1.3 Got peer feedback, Updated Audit and reviews

22/09/2016 2.6 Sy Le 7.1.1, 7.1.2 Finalised change control approach and change control procedure, Updated 7.1.3 audit and reviews

23/09/2016 2.7 Sy Le 7.1.3 Updated Audit with more corrections

23/09/2016 2.8 Sy Le 7.1.4 Finalised Audit and reviews

25/09/2016 3 Sukhneet Singh Hanjrah 7.2 Completed all of Configuration Management

7.1 Change Control 7.1.1 Change Control approach

Controlling change within the project involves a set of control processes to evaluate and manage each change. All change request will be assessed accordingly by figures with authority; where the project manager governing with the highest authority in the project will determine whether the change is appropriate. The project manager will regulate each change in the project by their level of importance, and will forward all change requests that will impact the project’s scope, scheduling and requirements to CrimTrac for further apprehending and approval. Once CrimTrac has authorized or rejected the change requests, the project manager will inform the project team and will allocate the communications manager to inform all stakeholders regarding the change, and begin implementation.

The control hierarchy diagram is displayed below. The project manager is the link between CrimTrac and other stakeholders.

Figure 1: Control Hierarchy Diagram

7.1.2 Change control procedureThe procedure for handling change in the project

1. When undergoing change requests in the project, a formal procedure is carried out where the change is issued through a documented process known as the “Change Request Form” (Refer to Appendix 11.3 – Change Request Form).

2. The documentation identifies and records the changes into a table of requests, known as the “Change Log”, and stores the information for monetarisation purposes throughout the project.

3. Minor changes that only format grammatical errors can be alerted to the team, and may not necessary be recorded, however changes regarding information processes are required to be documented for apprehension.

4. Each change is then assessed against set change criteria, to confirm implementation of the Change Request.

5. The Change Requests are then prioritised based on their importance and required resources, then to be approved by the project manager who apprehends each requests against the change request criteria assessment.

6. After assessing all the change requests, the project manager will forward them to CrimTrac for final approval.

7. The final decision is documented, and approved changes are implemented and traced. 8. All stakeholders will be informed of the Change Request status through the project

communication manager. 9. The Change Request is then closed.

Figure 2: Flow Chart for Change Requests

7.1.3 Audits and reviewIn the development phase/cycle of any project, many developer teams face the common problem of being unable to meet the specifications set by the client, thus resulting into the overall failure of the project’s system. To ensure that our team’s project scope meets with the client’s requirements, we have implemented a set success criteria that evaluates all forms of information system failure within the project, known as Lyytuben & Hirschheim’s theory. This theory states that, “systems do not fail primarily because of technical shortcomings, but because those involved in & affected by the system are not adequately considered”, meaning that systems fail for people reasons primarily, not technical reasons. Our project progression will be assessed against the four categorises of information systems failure:

Correspondence failure – the failure of being unable to meet the requirements set in advance

Process failure – the failure of a system unable to be produced within given budget or time Interaction failure – the failure of the system not being used or under-used by target Expectation failure – the failure to meet the user’s expectations

Having our project assessed against this set criteria serves as a countermeasure to prevent the final product from resulting into any of the four information system failures, and thus acts a tool for reviewing the projects progression to ensure our project regulation is complying with the terms of the stakeholders.

To handle correspondence failure, the project team has devised weekly meetings to review the project’s documentation and progression, assessing all changes done to the project. Anomalies detected during the revision will be recorded into the change request log, to be apprehended by the project team, and informed to the Project Manager to ensure that the projects progression meets with the project scope specifications. Our project scheduling will be followed accordingly, taking into consideration of changes that will the impact project scope, budget, task allocation and staff, which inevitably will result in the rescheduling of the projects deadline, activities and potentially affecting stakeholder requirements. Upholding the deadlines set through scheduling as well as having an understanding of the projects budget (Refer section 6.1) is key to overcoming process failure, and will contribute to the success of the overall project. Our system is to be developed accordingly to the requirements set by CrimTrac, hence what we deliver will be utilised by the External Stakeholders: CrimTrac (ACIC) board partnered agencies (Refer section 1.2). As per requested by CrimTrac, interaction failure is not a problem to our project since our final product is a system that is developed with the intent for utilisation by respective stakeholders. However it is necessary to keep in mind that our final product will be required to present itself as the complete system to the client, following the scope and client’s specifications. Unable to uphold these requirements will lead to expectation failure; not meeting with the expectations of the user. The project team will continue to review the work through this criteria to ensure our scope is consistent and will comply with the client’s specifications.

7.2 Configuration Management7.2.1 Configuration items

Configuration Item Baselines

Project Charter Version 1.0 baselined during Establishing Company Information and stakeholder analysis module in Project Management Increment

Re-baselined if any changes are made in company’s information, project objectives and any change related to stakeholders discovered during project

Project Scope Statement

Version 1.0 baselined during Scope Management module in Project Management Increment

If there are any changes made in the functional requirements for products or related to product deliverables then the scope management than the scope management will be re-baselined.

Work Breakdown Structure

Version 1.0 baselined during Work Breakdown structure phase in Project Management Increment

Any type of changes that will be made to Work breakdown structure or WBS table by any team member needs to be re-baselined

Estimation Version 1.0 baselined during Estimation Process in Project Management Increment

If any new proposal related to estimation of different sectors are introduced than there will be need to re-baseline Estimation

Schedule Version 1.0 baselined during the scheduling phase in Project Management Increment

Any changes made related to the scheduling by any of the team member or anyone else there will a need to re- baseline the schedule.

Budget Version 1.0 baselined during Budget Making process in Project Management Increment

If there will be any changes made in the budget for different sectors than there will be need to re-baseline the budget section.

Procurement Version 1.0 baselined during Budget and procurement phase in Project Management Increment.

Procurement will be re-baselined if there are any Changes made in the process of choosing products or services from outside our organisation

Change Control Plan Version 1.0 baselined during the Change Control phase in Project Management Increment.

Any changes which will be made in the procedure of control change by any of the team member or any other assigned person needs to be re-baselined

Stakeholders Version 1.0 baselined during the process of stakeholder analysis phase

in project increment. If a new stakeholder is introduced or removed from the project or

information regarding any stakeholder is updated than there is a need to re-baseline stakeholder analysis

Training Version 1.0 baselined during estimation phase in Project Management Increment.

If there are any new training methods introduced for the staff that will be added later on then there is a need to re-baseline Training estimation

Software development and testing

Version 1.0 of the Testing part will be baselined before installation process of machines in Project management increment

If there are any changes that will be made in the software for the machines than there is a need to re-baseline

Hardware Installation

Version 1.0 of the Hardware installation will be baselined during the estimation phase in the project management increment.

If there is a need to change the estimation related to hardware installation than estimation needs to be re-baselined

Risk Monitoring Strategy

Version 1.0 baselined during Risk Management Plan in Project Management increment

Any new strategy that will be introduced or a strategy that will not be used anymore in the ways of monitoring the ways of risk needs to be re-baselined

7.2.2 Configuration Management System

Configuration Control Board

There is vast variety of ways in which a project configuration can be managed and our team have decided to use a software which will create a configuration database which will responsible for storing and tracking all the important information regarding configuration items and their baselines. This database will be made using really high and advanced level of coding which will be 100% secure and only key members which will include important team members and stakeholders will be allowed to use the information recorded in the database.

The working to keep everything on track will be that if any information is added or or any pre-existed information is changed in the configuration items that will be stored in the database and then it will ask confirmation from all the key members of the team to decide whether to approve the changes made or not. Their job will be to check whether there is a need to make any change or not and scheduling all the important changes that have been made and checking if those are working fine. Their job will be to check if the request for a particular change is coming again and then doing a meeting with that person for a better understanding and valid reasons for implementing that change.

Re-Baselining Configuration Items

After a change request have been successfully accepted and implemented, than there will be a need to re-baseline the respective configuration item and based on the meetings done related to that change, the task for updating baseline can be assigned to any team member decided by team or the person who requested the change can update the baselines.

The current version of baselines for every configuration item is currently 1.0 and if any new changes will be made to baselines their version no. should be changed in correct format as decimal increments i.e. 0.1, 0.2. So, If a new change is made to a baseline then the new version number for that particular item will change to 1.1, 1.2 and so on

The person who made changes to the baselines is responsible of recording the date and time on which the changes were made and should store the changes made in the database as well in a log file as well as should prepare a file in which all the information regarding the changes made will be stored and should give that to project manager so those changes can be verified and discussed in the group meetings.

8 Risk Management PlanRevision History


14/10/16 0.1 Sy Le Added Stakeholder Risk Tolerance Table

15/10/16 0.2 Sy Le Updated the Stakeholder Risk Tolerance Table

16/10/16 0.3 Jaspreet Singh Updating Risk Address

15/10/16 0.4 Nathaniel Pather Added Budget Risk Management and Top Ten Risks

8.1 Risk Management Strategy

During the development of any project, the project team will need to account for the possibility of things going wrong. Some things may be out of the team’s control, whereas some other things may be manageable and therefore the chances of the risk arising can be mitigated by the team and stakeholders involved.

There are three processes to the Risk Management Strategy:

- Risk Identification is the process that determines what risks could affect the project.

- Risk Analysis is the process of analysing the risks identified, and how much they could affect the project.

- Addressing Risks is the process of determining solutions to mitigate, avoid or exploit these risks from having a negative effect on the project.

Throughout the projects life cycle, it is important that all known risks are overseen and managed, as well as being able to identify and log currently unknown risks in the future. Refer to the risk monitoring section for further information.

8.1.1 Risk Identification

Through the use of the Project Management Body of Knowledge (PMBOK), the project team will use a series of tools and techniques provided to identify potential risks that could affect the project.

- The project team will collaborate with industry experts and stakeholders throughout development to determine potential risks. These risks, when identified, will be added to a risk registry so they can be analysed and discussed at a later date. New risks may arise or become clearer throughout development, so the risk management team must be available to document these changes, and formulate strategies to combat the chances of the risk occurring or the damage they may cause.

- Through prior experience, some team members or stakeholders may be able to identify potential risks and methods to mitigate the chance of these risks occurring.

- Upon nearing the completion of the project, assumption analysis requires assessing any assumptions made to identify any risks from inaccuracies, instabilities, inconsistencies, or incompleteness.

- The SWOT analysis method can be used to identify strengths, weaknesses, opportunities and threats for the project, which can in turn be used to create a risk analysis.

When risks are identified and assessed, they will be logged in a risk register, which contains details about the risks including a description, category, the impact if the risk should occur, and strategies to avoid or mitigate the risk.

8.1.2Risk Analysis

The identification, classification and allocation of potential risks willed be addressed using Qualitative risk analysis; to analyse the potential impact of each risk in the project, where the project development team will utilise the method of expert judgement to rank each of the risk based on severity of impact. Reasons for using this method is due to how agile and effective it is.

The Project Team will assess the impact of each risk depending on the severity of the risk, and the probability of the risk occurring.

The accuracy of the results will be determined through each project team member’s individual input; giving their opinion on the severity and probability of the risk and rating it on a risk matrix. Their input will then be compared with other members to find an average result. Outlier scores will be re-evaluated for further assessing. The average results will then be analysed and reassessed to determine the ranking of each risk, based on severity and probability. The list of risks will then be monitored throughout the project to ensure what necessary cautions are required to take place in performing certain tasks, to assure that we have an understanding the severity of impact to the project it has. Throughout the project life cycle, the risks will decline in number, but may also arise for new potential risks that have yet to be uncovered. New risks will be added to the risk register.

8.1.3 Addressing Risks

Followed by the identification of the risks in risk register and updating their Impact and probability ranks the risk management team will develop strategies to deal with the risks. The following is a list of five risk conducts in which for the most part one out of the five will be utilized to treat every Risk:

1: Accept – If the risk doesn’t make much difference to the project then we accept it in that scenario

2: Transfer- I this case risk is transfer from one party to third party like a contract is made on fixed requirements and quotes.

3: Mitigate – Impact of risk is reduced by having a backup plan or another method or added features.

4: Avoid – Making Changes to the project so that a particular risk doesn’t comes up.

5: Exploit – manipulating the risk to get benefits out of it.

To Address Risks strategies for negative risks, positive risks and contingent response strategies are there:

Negative Risk Strategies: These are the risks harmful for the project they are treated with one of the top four Risk Treatments. The further decision depends on the risk type and impact and probability.

Positive Risk strategies: These risks are exploited to get benefit out of them for project objective. Exploit Treatment is used for these types of risk. This type of risk helps in boosting the project.

contingent response strategies: Highly complex risks which doesn’t falls under above two categories are considered belonging to this category.

Unidentified Risks: Some Risks are not spotted initially, but they come across during the project lifecycle. These risks are identified, analysed, categorised, and addressed, as detailed below:

1: Unidentified Risks That Haven't Impacted the Project: This type of risk does not have an impact on the project and are identified at a later stage and are recorded into the risk register.

2: For unidentified risks that have impacted the Project: This Type of risk has an impact on the project and is not identified before. It has to be treated on high priority to reduce the effect to the project

8.2 Risk Monitoring Strategy

8.2.1 Risk Monitor and Controlling

Risk Management Tracking is defined as the process of tracking and evaluating the effectiveness of risk mitigation methods used, and develops further risk mitigation options based on this feedback. Risk management tracking activities include: communicating risks to affected stakeholders, monitoring the success of risk mitigation plans, reviewing status updates, tracking the status of risks within a Risk Reporting Matrix, and alerting the person in charge of a risk when mitigation plans should be adjusted or reviewed.

8.2.2 Risk Identification and Risk Reassessment

The main aim of the risk identification process is to identify all the precarious risks that may affect the projects main outcomes and can disturb all the way in which that system was meant to work. Even after putting all the efforts, sometimes it’s hard to find all the potential risks which may affect the project objectives and to identify those risks information gathering and brainstorming techniques will be used, which will be a great way to keep the project going in a correct manner, but however as the project will will keep moving in further stages, even the risks may increase with that, so, to keep the project free from risks, risk assessment will be done.

Risk assessment will be done periodically after completion of every section or milestone. Every single risk that can affect that phase will be tested and if any new risk gets identified that will be added to the risk register and go throw risk assessment. Other than that any changes gets made to any section and due to that change a new risk arises than that will be recorded and a group person will be assigned as a risk owner for that particular risk as well as that a daily review will be undertaken by risk owners for their respective risk’s.

8.2.3 Risk Scheduling

It describes on what frequency and when risk monitoring activities should be done.

Risk Monitoring activities Revision Frequency

Project risk assessment Start of Project and Each Phase.

Risk probability/ Impact matrix Performed followed by any update in risk Plan or project and requirement changes and updates.

Independent Risk Review Performed after every Unit and every phase by the owner of risk assigned

Top ten risk item tracking When a Top 10 risk changes following any risk reassessment, independent review or identification process

Risk Audit After every phase or any failure at any stage or mile stone or any update in project status

Risk reassessment After any Milestone completion, Update , Phase Completion or when project manager feels it needs to be done

Identify new risk/ Retire old risk Once a week in allocated time and meeting

Qualitative Risk Analysis Start of Each Phase and major milestones

Quantitative Risk Analysis After qualitative risk analysis when more deep Analysis are required

At the end, when finalising the project, project manager will make sure that a proper risk description is identified at the end of each risk founded within the risk register, which will make the analysis part of each risk easier and should check if risk audits are performed correctly and the results are stored or not. Other than that the manager should make sure that the right identification methods are being used to identify every risk. At last for the future project improvements all the identification techniques and resources used will be reviewed for effectiveness in the risk management process

8.2.4 Risk Probability/ Impact Matrix

Probability Threats

5 R13

4 R18 R9, R10

R21

3 R6, R16

R1, R14

R8, R17

2 R4, R5, R23

R2, R3, R23

R12, R15, R19, R25

1 R7 R11, R24

R20 R22

1 2 3 4 5

8.4 Top Ten Risk Item TrackingTop ten risk item tracking is a method used monitoring the most impactful and likely to occur risks throughout a projects lifecycle. The Top 10 Risk Item Tracking contains a select list of the highest ranking risks identified in the risk register, and is made available for reference for all team members and project stakeholders. The specified items will be reviewed and re-established continually for the duration of the project, either depending on the current circumstances or in the event of risk register reassessment.

Risk ID

Category Risk Description Probability Impact Avoidance Strategies

Risk Rank

Person in Charge

Threat or Opportunity

Trigger Conditions

R8 User Acceptance

Correspondence Failure – Unable to meet the requirements set in advance

High Project Specification and requirements

Devised weekly meetings to review all work done

7 Project Scope Management and Project Time Management

Threat Poor stakeholder analysis, less feedback from stakeholders, lack of QA testing

R9 Budget Process Failure – Unable to be produced within given budget

High Cost Inflation, Loss Of financers, Bad Relations With stakeholder

Uphold deadlines set through budgeting

8 Project Cost Management

Threat Process Failure – Unable to be produced within given budget or time

R10 Schedule Process Failure – Unable to be produced within given Time

High Cost Inflation, , Bad Relations With stakeholders, Deadline Overdue

Uphold deadlines set through scheduling

8 Project Schedule Management

Threat Process Failure – Unable to be produced within given time

R13 Human Team High Delay In Surplus Human 9 Human Threat Insufficient

Resource Member Illness

Project, Loss Of Skill Resource, Project Cost

Resource, Slack In Work Tasks, Ensure Damage Control Budget

Resource Manager

Team Member, Lack Of Replacement staff, Overloading Employees With Work Load

R17 Testing Failed QA systems

High Extended project schedule, extended costs

White box testing, outsource testers, debugging

8 Testing Manager Threat Less testing, inefficient team, poor coding

R18 Communication Customer Perception

High Unsatisfied Stakeholders, bad user feedback, project failure

More meetings, better stakeholder analysis, regular user feedback

7 Communication Manager

Threat Poor communication, inconsistent feedback

R21 Technical Under performance of software

High Discontented stakeholders, legal implications, project failure

Strong analysis, strong design, strong implementation

9 Project Manager Threat Poor analysis, poor design, poor implementation

R1 Security Breach of user account

Medium Potential unauthorised user can access sensitive information

Hefty password requirements (passwords must contain at least 8 characters, with at least 1 upper case, number and symbol)

6 Security Head Threat Weak password, unattended login sessions, unsecure login environment, low security database

R6 Project Management

Accidental mislabelling of biometric identification information

Medium Invalid biometric information leading to incorrect information about a person

Automatic audits by the system, manual audits by system administrators

5 Project Manager

Threat Inefficient human resources, unskilled workers, lack testing

R12 Technical Hardware Failure

Medium Loss Of Data, Software failure, Extended Costs or maintenance

Check Hardware Compatibility, Environment Analysis, stakeholder Meetings

6 Procurement Manager

Threat Lack Of Hardware Testing , Lack Of Integration Testing , Lack Of Implementation Environment Knowledge

8.2.5 Result Audits and reports

Risk management reports will be prepared according to the deadline decided after the completion of every section as decided in group meetings. The risk report will be summarised and will be distributed to all the key stakeholders, by distributing it will insure that all the members of group and key stakeholders remain aware of the occurrence of all the identified risks that are in the project and how the group is handling those risks.

In addition to the reports, risk audits will be prepared periodically with that, which will determine all the main points, strengths and weaknesses of the current risk monitoring and controlling strategy of the current risk which are identified in the project.

8.3Stakeholder Risk Tolerance

Stakeholder Risk ToleranceListed below are the stakeholders involved in the project and their different approaches for risk tolerance. Internal Stakeholders:

Project Manager & Project Cost Management Project Time Management Project Scope Management Project Quality Management Project Communications Management & Project

Stakeholder Management

The project team utilises the agile approach to mitigate risk, where they would build software incrementally from the start of the project, instead of trying to deliver it all at once near the end. In doing so, the team minimizes the treat of having to deal with major disruptions or faults that become unexpectedly apparent in the final stages of the project, and are able to subdue them in the early stages of development. The Project team objective is to produce the product set by the CrimTrac Tenderer, which meets the requirements of the project scope and the expectations of the external stakeholders. The success of the project is dependent on how the project team is able to develop the final project, while being able to apprehend all forms of risks, and in doing so, produce a functional system that meets the requirements of CrimTrac.

External Stakeholders – CrimTrac:

Chief Executive Officer Chief Operating Officer Chief Information Officer Director of Communications and Secretariat

The External Stakeholders – CrimTrac are strict with the management of risks revolving around the project, where each risk involved may potentially hinder the development of the project thus affecting the overall success of the project. The Stakeholders of CrimTrac want the best out of the project, at the expense of minimal drawback, and are after for the successful implementation of the project: the final product. CrimTrac is after for an effective biometric system, and has placed specifications on what is expected to be in the system for the development team. By having the project team meet these requirements, then the project will be an overall success.

External Stakeholders – CrimTrac (ACIC) board partnered agencies

Chair person Secretary Director General of Security Chief Police Officer Chief Executive Officer Chief Commissioner Commissioner of Taxation Commissioner (8)

The External Stakeholders – CrimTrac (ACIC) board partnered agencies are affiliated with the results of the project, and are concerned with how beneficial it would be to them. Each stakeholder will utilise the final product for their individual needs, and are more lenient to the risks involved, as long as the product serves its intended purpose. If however there are risks that affected the progression of the project, delaying the released date of the product, then these stakeholders are to wait until further updates of the release date. The External stakeholders are tolerant with the risks involved with the project and would want the implementation of the final product to be successful.

8.4 Risk Register

Risk ID

Category Risk Description Probability Impact Avoidance Strategies

Risk Rank

Person in Charge

R1 Security Breach of user account

Medium Potential unauthorised user can access sensitive information

Hefty password requirements (passwords must contain at least 8 characters, with at least 1 upper case, number and symbol)

6 Security Head

R2 Security Database security breach

Low Unauthorised user can access sensitive information

Firewall, antivirus software, data encryption, access control

5 Security Head

R3 Technical Database crash Low Loss of data Scheduled, automatic backups to multiple databases

5 Database Manager

R4 Security SQL Injection Attack Low Spoofed data, existing data manipulation including alteration and deletion

Use of escape strings, parameterized statements

4 Database Manager

R5 Security Intentional tampering of biometric identification information

Low Invalid biometric information leading to incorrect information about a person


4 Security Head


Accidental mislabelling of biometric identification information

Medium Invalid biometric information leading to incorrect information about a person


5 Project Manager

R7 Communication

External Stakeholders irresponsive

Low Delayed scheduling, less information

Form regular meeting with the stakeholder

3 Project Communications Manager

R8 User Acceptance

Correspondence Failure – Unable to meet the requirements set in

High Project Specification and requirements

Devised weekly meetings to review all work done

7 Project Scope Management

advance and Project Time Management

R9 Budget Process Failure – Unable to be produced within given budget

High Cost Inflation, Loss Of financers, Bad Relations With stakeholder

Uphold deadlines set through budgeting

8 Project Cost Management

R10 Schedule Process Failure – Unable to be produced within given Time

High Cost Inflation, , Bad Relations With

stakeholders, Deadline Overdue

Uphold deadlines set through scheduling

8 Project Schedule Management

R11 Scope Interaction Failure – not being used or underused by target

Low Unsatisfied Stakeholders, Project Failure.

Present final product as the complete system

4 Project Quality Management

R12 Technical Hardware Failure Medium Loss Of Data, Software failure, Extended Costs or maintenance

Check Hardware Compatibility, Environment Analysis, stakeholder Meetings


R13 Human Resource

Team Member Illness

High Delay In Project, Loss Of Skill Resource, Project Cost

Surplus Human Resource, Slack In Work Tasks, Ensure Damage Control Budget

9 Human Resource Manager

R14 Schedule Production of final product delayed

Medium Project Scheduling Delay, System Delay , Cost Inflation, Bad Stakeholder Relation

Uphold the designated deadlines

6 Project Manager, Project Scope Management

R15 Technical Missing or erased coding

Medium System Crash, System Not Executing, Legal Implication

Devised Weekly meeting to review work

6 Project Manager

R16Technical

Underdeveloped system

Medium System Inabilities, System crash , Legal Implications

Revise work to ensure section is completed.

5 Project Time Management

R17 Testing Failed QA systems High Extended project schedule, extended

White box testing, outsource

8 Testing Manager

costs testers, debugging

R18 Communication

Customer Perception

High Unsatisfied Stakeholders, bad user feedback, project failure

More meetings, better stakeholder analysis, regular user feedback

7 Communication Manager

R19 Change Control

Inefficiency of change control board

Medium Unsatisfied stakeholders, inflexible software

Better change control plan, flexible software, reusable and updatable design

5 Change Control Manager

R20 Procurement

Resource conflict low Inflation of cost, project delay, lack of information

Strong procurement management, identified procurement procedure


R21 Technical Under performance of software

High Discontented stakeholders, legal implications, project failure

Strong analysis, strong design, strong implementation

9 Project Manager


Errors in project management process

Low Project Delay, Cost inflation, scope failure

Strong analysis, strong design, regular stakeholder meetings

6 Project Manager

R23 Budget Gold plating Low Increased budget, increased scope, increased complexity

Project Scheduling, Only working on authorised tasks

5 Budget Manager

R24 Change Control Manager

Scope Creep Medium Increased budget Stricter change control procedure

4 Change Control Manager

R25 Design Design lack flexibility and feasibility

Medium The whole project Design reviews, QA testing, stakeholder meetings, business need compatible design

6 Design Manager

9.0 Project ReviewRevision History


2/08/2016 1.1 All members Added Success Criteria

25/09/2016 2.1 Clayton McShane Added table to Project Achievements, added table to Review of Techniques, added stage 1 review to Lessons Learned section.

17/10/2016 3.1 Sy Le Completed 9.4 Review of techniques

17/10/2016 3.2 Jaspreet Singh Schedule update.

Conduct this review against your progress as a team with the workbook this semester - the workbook is your project for this section, NOT the tender or project idea you have used for sections 1-7.

9.1 Success criteriaA variety of success criteria has been defined for this workbook. Learning key elements of knowledge to solve realistic problems from the course, and applying them to this workbook will support us throughout our careers. Building strong and professional relationships with project members not only enables success of the workbook, but builds connections in our future industry, as well as long lasting friendships. Along with building relationships, learning how to work effectively as a group is a skill that transitions to all careers. Learning a variety of approaches for different types of IT projects will also be extremely beneficial.

9.2 Project Achievements

Detail your project achievements against your success criteria. Provide quantitative details as well as a qualitative discussion of your work

Project Achievements Success CriteriaComplete section 1 Provide information about the company, the project, an

analysis on the stakeholders and the strategy for communicating with the stakeholders.

Complete section 2 Provide a description for the product, including functional product requirements and define the scope of the project. Include a list of the project deliverables.

Complete section 3 Provide a draft work-breakdown structure tree diagram.Complete section 4 Provide estimations on the cost for the project.

Complete section 5 Provide a schedule for the project that builds off of the work-breakdown structure.

Complete section 6 Provide details about the budget for the project.Complete section 7 Provide details on how the team will deal with major

changes to the project.Complete section 8 Provide a description that analyses the risk management

strategy, the risk monitoring strategy and complete the risk register table.

Complete section 9 Provide a review on how the team performed throughout development of the project.

Complete section 10 Provide details on how the project was managed.

9.3 Schedule reporting

Deliverable Planned Deadline

Actual Deadline

Planned / Actual Time Estimation

Quantitative/Qualitative Details

Company information

16/08/16 16/08/16 1 hours/1 hours The task was accomplished as planned and met deadline

Project description 13/08/16 13/08/16 1.5 hours/1.5 hours

The task was accomplished as planned and met deadline

Project objectives and success criteria

17/08/16 17/08/16 2 hours/ 2 hours


Approach 17/08/16 17/08/16 2 hours/ 2hours The task was accomplished as planned and met deadline

Stakeholders 19/08/16 19/08/16 3 hours/ 3 hours


Start and Finish dates and Budget

18/08/16 1/08/16 3 hours/ 2.5hours



18/08/16 18/08/16 3 hours/1.5 hours


Communication Strategies

18/08/16 20/08/16 3 hours/ 7 hours

The task didn’t meet the deadline because of disagreement in the group.

Product Scope Description

19/08/16 19/08/16 3 hours/ 4 hours


Acceptance Criteria

22/08/16 22/08/16 3 hours/ 3 hours


Product Deliverables

26/08/16 26/08/16 3 hours/ 3 hours


Scope Exclusion 25/08/16 25/08/16 3 hours/ 3hours The task was accomplished as planned and met deadline

Work breakdown structure tree

27/08/16 28/08/16 3 hours/8.5 hours

The task didn’t meet the deadline because it was bigger than expected

Work breakdown structure table

27/08/16 27/08/16 3 hours/ 2hours The task was accomplished as planned and met deadline

Choice of estimation technique

08/09/16 09/09/16 3 hours/ 7 hours

The task didn’t meet the deadline due to disagreement in group

Justification of technique

10/09/16 11/09/16 3 hours/ 6.5 hours


Estimation 16/09/16 17/09/16 3 hours/ 8.5 hours

The task was delayed as it was critical and required more effort than expected

Gantt charts 18/09/16 18/09/16 4hours/ 4hours The task was accomplished as planned and met deadline

Network diagram 19/09/16 18/09/16 3 hours/1.5 hours

The task was done prior to the deadline as it was easier than expected.

Budget Management

25/09/16 26/09/16 3 hours/ 7 hours

The task didn’t meet the deadline as it was bigger than expected

Procurement Management

15/10/16 16/10/16 3 hours/ 4 hours

The deadline was not met because inability of a team member to do the task

Change management

22/09/16 22/09/16 3 hours/ 3 hours


Configuration Management

27/09/16 27/09/16 3 hours/ 2.5hours


Risk management 15/10/16 16/10/16 3 hours/ 5 hours

The task got late due to less expertise of group members in the task

Risk Monitoring Strategy

15/10/16 16/10/16 3 hours/ 5 hours

The task didn’t meet the deadline because of lack of proper communication between group members.

Risk Register 15/10/16 16/10/16 3 hours/ 4 The task didn’t meet the

hours deadline because of lack of proper communication between group members.

9.4 Review of Techniques

Technique EvaluationGoogle Docs Allows for every group member to work on the document at the

same time, supports version control and is stored online with a very unlikely chance of data loss. However, through utilising Google Docs, we then countered compatibility issues when copying work from Microsoft Word documents to Google Docs.

Online Communication

Instant messaging services allowed the team to communicate with any member of the team with ease. The group members would not always see messages via social media on time, resulting in One member’s internet was unavailable in the final few days before submission stage 2, preventing reliable communication.

Scheduled Meetings The group had scheduled weekly meetings to discuss progression and problems encountered. In doing so, the meetings acted as a makeshift audit for the project, to insure that the group members were up to date with the assigned workload. It also encouraged a friendly environment for group discussion about the overall project, and how to approach our specific tasks.

Student Examples Helped assure that the development of the workbook was up to standards with the provided student example. It also provided us insight of the expectation required in order to develop a successful workbook, as well with assisted us in creating our own version of the workbook.

Tutor Assistance If the group members are uncertain with specific sections regarding their assigned workload, they would request for clarification from the class tutor who would define what the question is after. In doing so, the group member now has the understanding of what the question is after and is able to progress further with the project knowing what explanation is needed.

9.5 Lessons Learned

Provide a detailed review of the lessons you learned producing this workbook – what worked for you, and what didn’t work? What did you learn from this? What would you do again, and what would you change on your next project/assignment?

- Google Docs is a useful tool for managing and working on a document involving a team of people, however it faces compatibility issues when copying from Microsoft Word.

- Instant messaging platforms such as Facebook, while useful in most circumstances, are not always the best option when working in a team. For instance, some team members may not be able to stay connected at all times, which could lead to them being left behind or out of the loop.

- The use of repeating scheduled meetings to discuss progress and talk about issues regarding the project helped the team feel more confident in the work being produced, given the consistent feedback providing improvements with each weekly iteration.

- Laissez-Faire leadership was mostly effective due to the dynamic of the group members; we worked well under our own guidance and were able to meet the deadlines for each work stage. Unlike other leadership styles where some micromanagement is a necessity, Laissez-Faire allowed the project leader more time to focus on working on the project, instead of requiring some spare time to review everyone’s work and provide feedback to each individual. In addition, the team members were able to assist each other with helping to solve issues that anyone was having.

10.0 Project Management10.1 Status Summary

Stage 1

As of the 26/08/2016, the following sections have been completed: Budget, Estimation (costs), WBS Tree, WBS Table, Product Scope Description, Product Deliverables, Communication Strategy, Stakeholder Analysis, Primary Stakeholder Identification, and Success Criteria.

A few hours each week are spent completing appointed sections, as well as weekly meetings discussing progress and problems. Everyone goes about completing their appointed sections in their own time and at their own speed.

A laissez-faire leadership is currently working well in conjunction with an initial leadership style developing workloads.

There have been a few problems regarding communication. During the start of the project a group member wasn’t receiving message notifications; however this was resolved after about a day. Towards the middle and end of the first stage of the project, a few members also started to miss message notifications. Alternative messaging systems are currently being investigated.

All members are passionate and dedicated, resulting in the workbook being up to date. In future content related to change control plan and risk management will be implemented.

Stage 2

As of the 25th of September, all the required sections for the submission stage have been completed, and the introduction section, which required revising, has been edited to better describe the project success criteria, the project management approach, and the stakeholder identification.

The group has continued the trend of allocating the workload fairly among each other, allowing each member to work at their own speed. This was done during a group meeting the week following the submission of stage 1. Group meetings were scheduled every week, such that the team could discuss progress and work to solve any issues that were encountered.

On the due date, a few major issues arose which required the team to regroup and buckle down to complete the tasks. One group member lost access to the internet and was unable to send or receive messages easily. He had to travel to the university so that he could use the computers and internet available there. Another group member was late submitting part of their section of work to the draft copy, and was not responding to instant messages. In addition, another group member who had anticipated stage 2 would be finished by our estimated completion date, was unavailable for a portion of the weekend.

Stage 3

As of the 17/10/2016, the following sections have been completed: Project Charter, Project Scope Statement, Work Breakdown Structure, Estimation, Schedule, Budget, Change Control Plan

A few hours each week are spent completing appointed sections, as well as weekly meetings discussing progress and problems. Everyone goes about completing their appointed sections in their own time and at their own speed.

A laissez-faire leadership is currently working well in conjunction with an initial leadership style developing workloads.

There have been a few problems regarding communication. During the start of the project a group member wasn’t receiving message notifications; however this was resolved after about a day. Towards the middle and end of the first stage of the project, a few members also started to miss message notifications. Alternative messaging systems are currently being investigated.

All members are passionate and dedicated, resulting in the workbook being up to date. In future content related to change control plan and risk management will be implemented.

10.2 Task List

Task Allocated to

Due Date Status Comments (include who finished task, date complete)

Budget Nathaniel Pather

26/08/2016 Completed Completed - Nathaniel Pather 26/08/2016

Estimation Nathaniel Pather

26/08/2016 Partially Completed

Completed Budget Estimations - Nathaniel Pather 26/08/2016

WBS Tree Jaspreet Singh


Completed WBS Tree Draft - Jaspreet Singh 23/08/2016

WBS Table Jaspreet Singh


Completed WBS Table Draft - Jaspreet Singh 23/08/2016

Product Scope Description

Clayton McShane

26/08/2016 Completed Completed Product Scope Description – Clayton McShane 24/08/2016

Product Deliverables

Clayton McShane

26/08/2016 Completed Completed Product Deliverables – Clayton McShane 24/08/2016

Communication Strategy

Sy Le 26/08/2016 Completed Completed Communication Strategy – Sy Le 24/08/2016


Sy Le 26/08/2016 Completed Completed Stakeholder Analysis – Sy Le 24/08/2016

Primary Stakeholder Identification

Sy Le 26/08/2016 Completed Completed Primary Stakeholder Identification – Sy Le 24/08/2016

Success Criteria Sukhneet 26/08/2016 Completed Completed Success Criteria –

Singh Hanjrah

Sukhneet Singh Hanjrah 24/08/2016

Status Summary Sukhneet Singh Hanjrah

26/08/2016 Completed Completed Status Summary – Sukhneet Singh Hanjrah 24/08/2016

Change Control Approach and Procedure

Nathaniel Pather

16/09/2016 In Progress Partially completed status summary – Nathaniel Pather 10/09/2016

Change Control Approach

Sy Le 26/09/2016 Completed Completed Change Control Approach – Sy Le 23/09/2016

Change Control Procedure

Sy Le 26/09/2016 Completed Completed Change Control Procedure – Sy Le 24/09/2016

Reviews and Audit

Sy Le 26/09/2016 Completed Completed Reviews and Audit – Sy Le 24/09/2016

Scheduling Section

Jaspreet Singh

25/08/2016 Completed Completed and Review By Jaspreet Singh: 20/09/2016

Approach Nathaniel Pather

24/09/2016 Completed Updated Project Approach - Nathaniel Pather 26/08/2016

Overall High Level Budget

Nathaniel Pather

21/09/2016 Completed Completed High Level Budget - Nathaniel Pather 26/08/2016

Cost Management

Nathaniel Pather

22/09/2016 Completed Completed Cost Management - Nathaniel Pather 26/08/2016

Procurement Management

Nathaniel Pather

22/09/2016 In Progress Completed some Procurement Management - Nathaniel Pather 26/08/2016

Wbs table Sukhneet Singh

22/09/2016 Completed Completed Wbs table22/09/2016


Sukhneet Singh

23/09/2016 Completed Completed Configuration items23/09/2016


Sukhneet Singh

23/09/2016 Completed Completed Configuration Management system 23/09/2016

Success criteria Sukhneet Singh

25/09/2016 Completed Updated success criteria25/09/2016

schedule Reporting

Jaspreet Singh

14/10/2016 Completed Completed on time. Jaspreet Singh 16/10/16

Risk Management strategy

Jaspreet Singh

15/10/16 completed Completed on time. Jaspreet Singh 16/10/2016

10.3 Time SheetsName: Clayton McShane

Date Time spent Task Comments24/08/2016

3 2.1 Product Scope Description, 2.2 Product Deliverables

Draft of section 2

25/08/2016

4 2.1 Product Scope Description, 2.2 Product Deliverables

Edits made to draft, completed

07/09/201 0.5 4.1, 4.2

609/09/2016

1 4.2, 4.3

14/09/2016

2 4.2, 4.3

20/09/2016

2 4.2, 4.3 Finalised story points

22/09/2016

0.5 4.1, 4.2, 4.3 Adjustments to match the layout done by Nathaniel.

25/09/2016

3 9.2, 9.4, 9.5, 10.1 Added ‘Stage 2’ portion to 10.1, added 9.2, 9.4, 9.5

Name: Jaspreet Singh

Date Time spent Task Comments2/08/2016 2 1.1, 9.14/08/2016 4 3.1 Design and deep

analysis of tender a were don in order to start the construction of W.B.S. tree

08/08/2016

2 3.1 Waterfall model W.B.S. begins

10/08/2016

1 3.1 Reconsidering the model to change the approach to the agile model

15/08/2016

6 3.1,3.2 Construction of tree and the table

20/08/2016

8 3.2 Completion Of W.B.S.

05/09/2016

8 5.1 Gantt Chart

10/09/2016

5 5.2 Network Diagram

20/09/2016

4 5.1,5.2 Critical path

10/10/2016

6 8.1 Risk

15/10/2016

8 9.3 Project Review

Name: Sy Le

Date Time spent Task Comments2/08/2016 2 1.1, 9.15/08/2016 3 1.2, 1.3 Researched

stakeholders10/08/2016

3 1.2, 1.3 Began to analyse each stakeholder, and their interest in the project

14/08/2016

3 1.2, 1.3 Created a table of stakeholders

25/08/2016

2 1.2, 1.3 Update list of table, add new stakeholders

25/09/2016

4 7.1.1 Completed Change Control approach

25/09/2016

4 7.1.2 Completed Change Control procedure

25/09/2016

4 7.1.3 Completed Audits and Review

17/10/2016

3 8.1 Completed Stakeholder Tolerance

17/10/2016

3 8.1 Completed Risk Analysis

17/10/2016

3 9.4 Completed Review of Techniques

Name: Sukhneet Singh Hanjrah

Date Time spent Task Comments2/08/2016 2 1.1, 9.116/08/2016

2 1.1 Researched Project Success Criteria

20/08/2016

2 1.1 Completed Project Success Criteria

25/08/2016

1 10.1 Added Status Summary

21/09/2016

3 3.2 Completed WBS table

22/09/2016

3 7.2.1 Completed Configuration Items

22/09/2016

2 7.2.2 Completed Configuration Management System

25/09/2016

1 1.1 Updated Success Criteria

Name: Nathaniel Pather

Date Time spent Task Comments2/08/2016 2 1.1, 9.15/08/2016 1 1.1 Added Company

History10/08/2016

1 4.1 Researched Estimation Techniques

12/08/2016

1 4.1 Researched industry data for biometric system costs

13/08/2016

1 4.1 Researched industry data for police stations in Australia

15/08/2016

2 4.1 Added Justification for each technique

16/08/2016

2 4.1 Calculated Estimation Costs

17/08/2016

1 6.1 Calculated Planned Budget

18/08/2016

0.5 6.1, 1.1 Added Overall Budget Table

18/08/2016

0.5 11.0 Added Appendices

26/08/2016

1 10.1 Reviewed Status Summary

26/08/2016

2 All sections – Fix formatting

10/09/2016

1 7.1.1, 7.1.2 Added change control approach, approach diagram (draft) and change control procedure

124/09/2016

3 6.1.2 Added high level budget

22/09/2016

0.5 6.1.4 Added Cost Management

22/09/2016

2 6.2.2 Added parts of Procurement Management

11.0 Appendices11.1 WBS TreeThe entire WBS Tree has been uploaded as an XML file and the details to open the file are as follow:

1. Download the WBS Tree file from learning at Griffith, or alternatively https://www.mediafire.com/?9dzg9xsrn49r9vn

2. Open www.wbstool.com3. Select “Use Without Login”.4. Select “Import MS Project XML” (top left, third option).5. Open the WBS Tree file.

11.2 Industry DataBiometrics Hardware and Software Costs:

http://www.fulcrumbiometrics.com/Biometric-Fingerprint-Scanners-s/34.htm?searching=Y&sort=2&cat=34&show=10&page=1

Training Budget Costs:

http://smallbusiness.chron.com/elements-good-training-budget-44855.html

Number of Police Stations in Australia:

Research conducted in Google maps.

Number of Police Stations in AustraliaState Number of StationsQueensland 40Northern Territory 7Western Australia 50South Australia Unknown, Estimated to be 45Victoria 47New South Wales 108Total 297

Number of Sworn Police Officers Data:

http://www.abs.gov.au/ausstats/[email protected]/0/712FAED4666FABD2CA256B35001967CE?opendocument

11.3 Change Control Form

Change Request Form

Project Name: Stakeholder (contact info): Date Request Submitted:

Change Order Number: Change Request Title: Change Category:

Description of change requested: _______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

On a scale of 1 to 5, how urgent is the change? (tick the box)

(1 being minor, and 5 being major)

5

4

3

2

1

Explain the importance of the change, and why is it necessary:

_________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Justify how the change will contribute to the success of the project:



http://smallbusiness.chron.com/elements-good-training-budget-44855.html



http://www.wbstool.com/

https://www.mediafire.com/?9dzg9xsrn49r9vn

_______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Listed below, describe the impact of the proposed change to the following:

Project Scope:

Project Schedule:

Project Cost:

Staff members:

Risk management:

Other:

11.4 Gantt ChartThe following are the links for Gantt Chart

1. Ms Project Link: https://drive.google.com/open?id=0B0tdHPVnj_E2c3NZMkwyNVk1dWM

2. Pdf Link https://drive.google.com/open?id=0B0tdHPVnj_E2aVpibTluRE9XVUU

*note the PDF could give a distorted image in some cases please prefer Ms Project then.

11.5 Network Chart1. Pdf Link http://www.mediafire.com/file/18csr2lxx6gcnl4/network-diagram-critical-path.mpp2. Video Link http://www.mediafire.com/file/59gc7d0skgsnbp6/Video.mp4

http://www.mediafire.com/file/59gc7d0skgsnbp6/Video.mp4

http://www.mediafire.com/file/18csr2lxx6gcnl4/network-diagram-critical-path.mpp

https://l.facebook.com/l.php?u=https%3A%2F%2Fdrive.google.com%2Fopen%3Fid%3D0B0tdHPVnj_E2aVpibTluRE9XVUU&h=WAQGVZfCG

https://l.facebook.com/l.php?u=https%3A%2F%2Fdrive.google.com%2Fopen%3Fid%3D0B0tdHPVnj_E2c3NZMkwyNVk1dWM&h=WAQGVZfCG