Using the Document

Using the Document This document provides a set of templates for the Project Management Workbook to be submitted as Assessment for 2001ICT.

The content is based upon the appropriate International Standards for Software Project Management Documents.

These templates should be considered the minimum level of detail required for the Workbook. It is expected that you would conduct further research into relevant material that may be required in each section.

Items that are intended to stay in as part of your final document are in bold; italic text is used for explanatory information that should be removed when the template is used.

At the top of each workbook section is a table. This table records who has worked on each section, and the work that they have contributed. This table must be kept up to date as the sections are completed, and the entire team must agree to the content of the table.

Sections 1-7 are planning documents that you complete based on the project you have chosen. Section 8 of the workbook is a post project review based on your work over the semester, and this section of the workbook refers to the development of the workbook itself, NOT the project you chose. In order to complete this section you will need details relating to how your team conducted themselves in building the workbook, as well as the planning material from section 9. Treat the workbook development as a project.

Section 9 covers the project planning for your workbook. Each team member needs to keep a weekly timesheet detailing time spent and tasks completed in this section. This is where tasks may be allocated and tracked, and individuals can enter timesheet information. This section must be maintained from the beginning of the project

1 1. Project Charter Revision History

Date Ver. Author Addition/Alteration

13/07/17 Jake Ward

1.1 Company Information Company Name: DataCloud Consulting

Team Members: Luke Nicholls, Jake Ward, Benedict Noh, Rakesh Piryani & Yasin Cakar

Head Office Address: 15/96 Mary St, Brisbane, Queensland 4000

Website: http://www.datacloud.com.au/

Business Experience: DataCloud Consulting is an Australian owned business, with headquarters situated in Queensland’s capital Brisbane. We have been in operation within Australia for 25 years, and internationally in the Asia-Pacific region for 11 years.

Recent projects include:

• IT Service Transformation for Goldman Sachs Australia in 2004

• Database implementation for Queensland Department of Health in 2006

• System re-design for Nine Entertainment Co. and Fairfax Media

Other services provided:

· Data Analytics Software Management

· Hardware procurement Management

· ICT Modernisation & Change Management

· Staff Specialty Training Services

Affiliates:

· International Project Management Association (IPMA)

· Project Management Institute (PMI)

· Project Management Alliance Company (PMA)

· The International Association of Project and Program (IAPPM)

· Australian Information Security Association (AISA)

· Engineers Australia

Project Description: Brief description of the project as you see it

Project Objectives and Success criteria:

List the primary objectives for the project, These should be a high level description of what the tender asks you to achieve. Include the success criteria for these. Each should be quantifiable – at the end of the project, you would be able to measure and test against your outcomes.

3 Project Objectives Success Criteria Person Approving

Scope:

Other:

Approach: Describe your (preliminary) approach for this project. State which SDLC you will follow – include modifications to the model as relevant. Justify your choice of SDLC.

Stakeholders: Identify primary project stakeholders – you can use a table

Start and Finish: Identify your start and finish dates

Budget: Establish a top level budgetary estimate

1.2 Stakeholder Analysis

Name of Client Liaison:

Stakeholder Analysis

Provide a stakeholder analysis: List your key stakeholders, their interest in the project, the information they’ll need, and how they prefer to receive communication (modes and priority).

1.3 Communication Strategy

Provide a strategy for meeting the information needs of the stakeholders

- Identify the information/documents that will be provided to each stakeholder

- Describe conduct of Stakeholder communications – how, when, level of formality

4 2 Project Scope Statement Revision History

20/07/17 1.2.1 Luke Nicholls Tables laid out for each section of requirements. A basic series of requirements have been filled into each table.

1/08/17 1.2.2 Luke Nicholls Tables laid out for each section of deliverables. A basic series of requirements have been filled into each table.

4/08/17 1.2.3 Luke Nicholls

2.1 Product Scope Description

All requirements (functional & non-functional) are outlined below in a series of tables. Priority determines the necessity/importance of the listed requirement, ranging from mandatory to optional.

2.1.1 Hardware Requirements

No Requirement Priority Priority Rating . 1 Storage hardware capable of adequately storing existing biometrics MANDATORY HIGH data, as well as accounting for the storage needs required for further data collection modes. Format of drives should each be of the same standard file system, as well as being expandable if more storage is required. 2 A server capable of adequate transfer rates for rapid access of MANDATORY HIGH biometrics data as required. 3 A detached, offline backup system which routinely has it’s data MANDATORY HIGH updated. Used in the case of security issues where data in the main storage system may be considered corrupt and/or unreliable.

2.1.2 Software Requirements

No FUNCTIONAL Requirement Priority Priority Rating . 1 Software package capable of storing print data, including finger, palm MANDATORY HIGH and foot

5 2 Software package package capable of storing facial data MANDATORY HIGH 3 All data able to be searched and compared by the user MANDATORY HIGH 4 All software will be open to further development in the case of future MANDATORY HIGH security vulnerabilities, functional issues, or the addition of more biometrics services. 5 All stored data will be retained in the current government required MANDATORY HIGH standard for biometrical information 6 All access to stored biometrics data via the interface should be MANDATORY HIGH restricted and password protected 7 Application should have a clear efficient UI enabling users to effectively DESIRABLE MEDIUM search, retrieve, store, and update stored biometric information 8 Provided it does not produce any vulnerability in the system, the final DESIRABLE MEDIUM software solution should be designed to work on a range of platforms including desktop machines (MacOS and Windows), and mobile (iOS and Android).

2.1.3 Training Requirements

No Requirement Priority Priority Rating . 1 All potential users will be provided an entry-level course on how to MANDATORY MED effectively create, view, and manage biometrics system with the new software solution 2 Training will be conducted over the span of a couple days in an DESIRABLE MED intensive in-person course 3 All potential users shall be provided a detailed manual and/or reference DESIRABLE MED guide in regard to using the new system

2.1.4 Documentation Requirements

No Requirement Priority Priority Rating . 1 Documentation will be readily available digitally to all authorised Mandatory Med stakeholders. 2 Documentation will include: MANDATORY High

- installation/maintenance guides - power requirements for server/storage/backup systems - certifications and/or authorisation of software/hardware provided by a third party - all maintenance/update logs regarding both hardware and software components

2.1.5 Installation Requirements

No Requirement Priority Priority Rating . 6 1 Installation shall occur in one of the following formats: Mandatory High

- all current systems shall be deactivated, and all new services shall be rapidly put in place and made available with 5 working days (Mon-Fri)

- the new system will be integrated in iterations in the space of 2-3 weeks, with new services and software being activated before current services are replaced to reduce impact on stakeholders 2 Access to installation site will be highly exclusive, to protect the MANDATORY high integrity or existing data being moved across to the new system, and to avoid interference that may impact the quality of the new system 3 All parties on site during installation shall have appropriate MANDATORY HIGH identification that recognises their authority to be present during installation.

2.2 Product Deliverables

2.2.1 Hardware Deliverables

No. Deliverable Description Due Date SH Tier D1.01 Report on current A detailed report outlining the current storage/server 1/08 hardware infrastructure infrastructure will be provided to determine if the existing infrastructure (currently used for the existing NAFIS) or components thereof may be suitable for expansion or reuse. D1.02 Hardware pricing A bill of hardware materials including a series of rack 5/08 mounted hard disks and appropriate server equipment D1.03 Installation Plan Written plan (soft copy) detailing installation and 12/08 implementation of hardware components. D1.04 Required Storage and Installation of all required hardware, adhering to the Server Hardware detailed plan provided. Components D1.05 Installation/Test Report Detailed reports covering both the installation process, and the testing of all installed hardware components. D1.06 Hardware Activation New hardware system is activated and prepped for implementation of biometrics functionality.

2.2.2 Software Deliverables

No. Deliverable Description Due SH Tier D2.01 Software Pricing Quote regarding the pricing of required software 7/08 packages (system for prints and facial recognition, as well as a sophisticated UI to contain both functionalities) will be provided. D2.02 Software Implementation Written plan (soft copy) regarding the implementation 12/08 Plan strategy of developed software solution (Whether installation of functionalities will be incremental over a longer period of time or done in a shorter time all in one go) D2.03 Software Licenses Third party licences for software packages or as obtained 7 components (if required). D2.04 Test Reports Test reports of developed solution 1/10 D2.05 Practical Demonstration of Demo of functionality to key stakeholders System D2.06 Approval to install software Confirmation of successful hardware installation and solution statement detailing the installation timeframe. D2.07 System Activation Integration/official activation of new system

2.2.3 Training Deliverables

No. Deliverable Description Due Date SH Tier D3.01 Discussion and detailed Meeting with major stakeholders outlining the format formation of training and proposed execution of training course for system program users. D3.02 Final training Document containing the final plan/curriculum for plan/curriculum system use course (sent in soft copy to all stakeholders including state police services) D3.03 Online training resources Provide online resources/reference guide for application to all potential users D3.04 User training Provide in-person training course for all users.

2.2.4 Documentation Deliverables

No Deliverable Description Due Date SH Tier . D4.0 Software Licenses All relevant licenses for software developed 1 (particularly important in the case of 3rd party developers). D4.0 Hardware Troubleshooting Troubleshooting guide for routine maintenance and 2 Guide inspection of hardware system. D4.0 Hardware Licenses All relevant licenses for hardware developed 3 (particularly important in the case of 3rd party suppliers). D4.0 Guide to optimal operation Documentation detailing power and environmental 4 of hardware requirements of all hardware components (e.g approximate consumption, ideal temperature). D4.0 Hardware Maintenance Guide for hardware maintenance enabling longest life 5 Guide span and highest performances of all components. D4.0 General user manual for User manual and reference guide for final application 6 software use/interaction used by police services.

2.2.5 Project Management Deliverables

No Deliverable Description Due Date SH Tier . D5.0 Cost Management 1 D5.0 Project Management Plan 2 D5.0 Meeting Minutes 3 D5.0 Change logs 4 Communication Strategies

8 3 Work Breakdown Structure //Rakesh Piryani

Revision History

A work breakdown structure(WBS) must be documented, and task dependencies must be shown clearly. The WBS must be based upon and derived from your selected life cycle model. The life cycle model should be tailored as required.

9 The WBS should be presented in two parts:

3.1 WBS Tree

3.2 WBS Table A table showing the next level of detail:

ID Task Name Duration Predecessors unique id Description in days dependent tasks

4 Estimation Revision History

Complete a full estimation for your project. This estimation is then used to determine overall size and timing, which in turn feeds into your schedule and staffing allocations.

10 4.1 Choice of Technique

State which estimation technique/s you will use. Reference source of technique

4.2 Justification

Justify your choice of technique – why is this the best choice for your project?

4.3 Estimation

Detail your estimation. You should include all working for your estimation, not just the final figures.

11 5 Schedule Revision History

The Schedule should show, in graphical or textual form, the planned starting and finishing dates of each task listed. The critical path showing the minimal set of tasks for successful project completion should be clearly shown. There must be provision for the schedule to be updated following changes to the Plan.

The Schedule builds on the detailed WBS table, but should not be identical - in scheduling, you are looking to see how you can optimise your schedule based on your WBS.

You may attach an external document for your schedule. Please make sure this is in a format that is readable

12 6 Change Control Plan Revision History

6.1 Change Control 6.1.1 Change control approach Describe the overall approach to change control that this project will need. What are the lines of authority, responsibility, and decision making? How will your plan be implemented? 6.1.2 Change control procedure What is the procedure for raising, approving/rejecting, montoring, tracking, and closing change requests? Define the tracking and control procedures for the actual changes in this section. Include templates where necessary.

Change Request Submittal

Change Request Tracking

Change Request Review

Change Request Disposition

6.1.3 Audits and review Describes the procedures used to verify that the product matches the client’s requirements from the specifications, and that the product being reviewed is complete. The audit is a way to check that the developers have done their job completely and in a way that will satisfy external obligations. Anomalies detected during the audit must be fixed, and the cause of the anomaly detected and fixed to avoid the problem from recurring. Describe this process.

13 6.2 Configuration Management 6.2.1 Configuration items List the configuration items for this project, and define baselines 6.2.2 Configuration Management System How will you manage configuration for this project? Will you do this manually, or use software? What actual steps/procedures will you follow?

14 7 Risk Management Plan Revision History

7.1 Risk Management Strategy

Describe your strategy for identifying, classifying, and addressing risk in your project. This should cover identification of the risk factors and assessment of the possible impact and likelihood of the risks. What is the risk tolerance of your stakeholders? What approach are you taking to identifying risk? What roles and responsibilities for risk are assigned in your project? How will you define and assess potential risk impact and likelihood? Detail your risk taxonomy - how will you categorise your risks? Do you have an overall and general strategy for addressing risk? You need to outline this in steps, and it's your fall back position for any risks that might occur that you didn't identify ahead of time.

7.2 Risk Monitoring Strategy

How will you monitor and track your risks? Include Risk Assessment, Review, and Scheduling. What are your monitoring activities for risk? Do these occur at regular intervals (ie, to a schedule)? What about ongoing assessment and review of risks - looking for new risks that might be identified, or older risks that can now be 'retired' as no longer relevant?

15 7.3 Risk Register

P r o b a ID Event or Risk Impact Preventative steps b il i t y R1 Development/Hardware late M High Order on signing of e project d i Pay a priority fee u m

16 8.0 Project Review Revision History

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. 8.1 Success criteria

For Audit 1

Section 1.1: complete to a sufficient standard Section 1.2: complete to a sufficient standard Section 1.3: complete to a sufficient standard Section 2: complete to a sufficient standard Section 3: the WBS outline has been drafted 8.2 Project Achievements Detail your project achievements against your success criteria. Provide quantitative details as well as a qualitative discussion of your work 8.3 Schedule reporting List your planned and actual deadlines for each deliverable in the workbook, as outlined in section 9. List your planned and actual size estimates for each deliverable in the workbook. Provide quantitative details as well as a qualitative discussion of your work. Why did or didn’t you meet your deadlines and estimates? 8.4 Review of Techniques List the techniques you used in developing your workbook. Evaluate the techniques.

17 8.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?

18 9.0 Project Management Document the project management tasks used in developing your workbook. Each team member should complete a weekly timesheet showing their work. The team should produce a task list for each section of the workbook showing task breakdown, the person assigned to each task, task status, and who completed each task. A status summary should be provided for each assessment point. 9.1 Status Summary Complete this summary at the end of each set of assessment as a minimum (you can complete this weekly if you prefer) – you will have at least 3 summaries on completion. Update as required.

Describe the current status of your workbook development – are you on track? How much time is being spent? How much progress is being made? What is working well? What is not working well? What changes will you need to implement – either to content, or to the processes you are using to complete your work?

9.2 Task List Complete this table at the beginning of each set of assessment. Update as required. Add more rows as needed.

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

1.1 Project Jake Ward August 1 In progress Objectives

1.2 Stakeholder Yasin Cakar August 2 In Progress Analysis

1.3 Benedict August 4 Communication Noh Strategy

2 Luke August 5 In Progress Nicholls

3.1 & 3.2 Rakesh August 5 Piryani

Formatting and Luke August 6 minor Nicholls corrections prior to submission of

19 audit 1

9.3 Time Sheets Each member of the team should complete a timesheet showing their work for the workbook. This should build progressively across the entire semester. Add more rows as required

Name: Luke Nicholls

Date Time spent Task Comments

20/07/17 40 minutes section2

Name: Jake Ward

Name: Benedict Noh

Name: Rakesh Piryani

20 Name: Yasin Cakar