Copy: Issued To:

Liquor and Gaming Information System Project Execution Plan

Revenue, Gaming and Licensing Division DEPARTMENT OF TREASURY & FINANCE

Version 1.0 (25 August 2004)

Acknowledgements This document has been derived from a template prepared by the Department of Premier and Cabinet, Tasmania. The structure is based on a number of methodologies including the Tasmanian Governments Project Management Guidelines, Rob Thomsetts project management methodologies as described in Third Wave Project Management: a handbook for managing the complex information systems of the 1990s. Rob Thomsett. Prentice-Hall, Inc. 1993 and John Smyrks ITO methodology as outlined in his Business Case Development and Project Management workshops.

LGIS: Project Execution Plan Version 1.0

Page i of v

DOCUMENT ACCEPTANCE and RELEASE NOTICE

This is version 1.0 of the Liquor and Gaming Information System (LGIS) Project Execution Plan. The Project Execution Plan is a managed document. For identification of amendments each page contains a release number and a page number. Changes will only be issued as complete replacement. Recipients should remove superseded versions from circulation. This document is authorised for release once all signatures have been obtained.

PREPARED: (for acceptance)

DATE:___/___/___ (Marita Holding, LGIS Project Manager)

ACCEPTED: (for release)

DATE:___/___/___ (Project Sponsor, Peter Coe, Executive Director)

LGIS: Project Execution Plan Version 1.0

Page ii of v

1.

BUILD STATUS:

Version 1.0

Date 25/8/04

Author

Reason First release

Sections

2.

AMENDMENTS IN THIS RELEASE:

Section Title Section Number Amendment Summary This is the first release of this document.

3.

DISTRIBUTION:
Copy No 1 2 3 Version 1.0 1.0 1.0 Issue Date 25 August 2004 25 August 2004 25 August 2004 Issued To Marita Holding Mervyn Feltham Michele Mason (DPAC)

LGIS: Project Execution Plan Version 1.0

Page iii of v

Table of Contents
1 Introduction..................................................................................................................1 1.1 1.2 1.3 1.4 2 Document Purpose .............................................................................................1 Outcomes ...........................................................................................................1 Project Outputs...................................................................................................1 Scope of Work ...................................................................................................2

Management Plan ........................................................................................................4 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Management.......................................................................................................4 Status Reporting.................................................................................................4 Stakeholder Management...................................................................................4 Risk Management ..............................................................................................5 Provision of Facilities ........................................................................................7 Skills and Resource Requirements.....................................................................7 Configuration Management ...............................................................................9 Confidentiality .................................................................................................10 Updating this Plan............................................................................................10

Quality Plan................................................................................................................11 3.1 3.2 3.3 3.4 Introduction......................................................................................................11 Methodologies and Standards ..........................................................................11 Development and Production Environment.....................................................12 Records ............................................................................................................13

Purchasing Plan .........................................................................................................14 4.1 4.2 4.3 Purchasing Specification..................................................................................14 Selection of Suppliers ......................................................................................14 Contractor Management...................................................................................14

Development Plan ......................................................................................................15 5.1 5.2 Output Design and Development Activities ....................................................15 Output Review and Acceptance.......................................................................17

Test Plan .....................................................................................................................18 6.1 6.2 6.3 Introduction......................................................................................................18 Unit Testing .....................................................................................................19 Integration and System Testing .......................................................................19

LGIS: Project Execution Plan Version 1.0

Page iv of v

6.4 7

Acceptance Testing..........................................................................................19

Implementation and Delivery Plan...........................................................................21 7.1 Implementation ................................................................................................21

Outcome Realisation Plan .........................................................................................23 8.1 Monitoring and Reporting................................................................................23

Output Management Plan.........................................................................................24 9.1 9.2 Output Register ................................................................................................24 Version Control................................................................................................24

10 11

Maintenance Plan.......................................................................................................25 Project Plan ................................................................................................................25 11.1 Overall Project Plan .........................................................................................25

11

Appendices..................................................................................................................26

LGIS: Project Execution Plan Version 1.0

Page v of v

1
1.1

Introduction
Document Purpose
The Project Execution Plan (PEP) is the operational document for the project. It is owned, maintained and utilised by the Project Manager and Project Team to support the delivery of the agreed project outputs. The PEP is the responsibility of the Project Manager and is the road map enabling the effective day-to-day (operational) management and control of the project. The PEP expands on the Project Business Plan which is the approved plan describing what will happen in the project. The PEP details how the Project Team will carry out their tasks/activities to ensure that the what will occur.

1.2

Outcomes
The LGIS Project will deliver the following outcome: Improved access and quality of liquor and gaming information by: Reducing the lead time to access management information. Increasing the number of hours that information can be accessed in a 24 hour period. Reducing the number of locations where data is stored. Reducing the risk of data integrity, confidentiality and privacy issues. Reducing the number of systems that present a risk to the Department.

1.3

Project Outputs
The following outputs will be delivered to support the achievement of project outcomes and provide required system functionality to the Branch: A new information system which: o provides access to an integrated set of data from the current GRS and LLS; o is easily accessible and provides a good level of performance for staff at any location throughout the State;

LGIS Project Execution Plan Version 1.0

Page 1 of 26

o is easy to use and allows staff to work efficiently by supporting redesigned business processes and generating template letters to be sent to clients; o is an efficient processing system for the Branchs activities; o allows easy entry, amendment and extraction of data; o has import and export facilities; o is secure and only allows authorised personnel access to client information; o conforms to Departmental standards; o is able to be readily supported, enhanced and maintained by the Information Systems Branch; o provides effective audit trails. A re-designed set of branch business processes. A de-commissioned Liquor Licence System. A Staff Training Manual. A System User Guide. A System Administrator Operations Guide. A Developer Technical and Maintenance Guide.

1.4

Scope of Work
LGIS Project Scope of Work Part of the Project (Inside Scope) Delivery of outputs and outcomes. Review of business processes Not Part of the Project (Outside Scope) Delivery of the branch amalgamation outcomes. Review and possible amalgamation of external information web sites will be progressed by the LGB. Conversion of GRS database to Oracle. This will be completed as part of the Database Migration Project run by ISB. Development and implementation of data synchronisation functionality required for mobile PDA deployment. This functionality will be designed in the new system, but will be developed

All business processes currently supported by the existing GRS and LLS. Automated transfer of data to external stakeholders

LGIS: Project Execution Plan Version 1.0

Page 2 of 26

at a later stage. Review of data prior to migration Review / upgrade of information systems used by external stakeholders. Any upgrade to external gaming system such as those used by Wrest Point Casino need to be negotiated by the Branch. Provision of direct interface to LGIS for Service Tasmania staff. Progressing any legislative changes that may arise from the business process review work. This would be a separate project for the LGB. Upgrade of the Receipting system (GRL) is a project being progressed by the Revenue Operations section of the RGLD. Implementation of electronic receipting functionality at Henty House. In the Interim, Service Tasmania can be used to receipt payment until GRL is implemented. Implementation of other sub-projects associated with the branch amalgamation such as the development of an enforcement and communication strategy. Review of delivery and coordination of Responsible Serving of Alcohol training. This will be managed by the LGB as another project. Inclusion of Casino audit functionality into the system. This will remain in Microsoft Excel and a review will be undertaken by the Branch in the future to ascertain the scope of audit work required. Training of staff to be cross-skilled in both licensing and gaming matters. This is the responsibility of the branch amalgamation project.

Collection of gaming and licensing revenue by Service Tasmania or another suitable provider Review of all letters and forms

Review of all reports to be extracted from system

Receipting of payments into the new system

Data migration

Documentation of business rules

Definition of a common language between licensing and gaming terms

Training of staff in the new system to be able to process either licensing or gaming application (depending on the current nature of their work) Preparation of technical documentation and user manuals on the new system

LGIS: Project Execution Plan Version 1.0

Page 3 of 26

2
2.1

Management Plan
Management
The project manager for the LGIS Project is Marita Holding. The Project Manager is responsible to the Project Sponsor for the delivery of the agreed project outputs. The project governance structure, management roles, functions and responsibilities are defined within Section 3 of the current Project Business Plan.

2.2

Status Reporting
The Project Manager will provide a status report at the monthly Steering Committee meetings that will include the following information: Progress details; The status of high priority issues; The status of high priority risks; Change register (during phase 3) Short term work plans; Milestone history monitor; Progress summary; and Budget.

2.3

Stakeholder Management
The Business Plan details: The project stakeholders (who needs to be informed and / or involved). Key messages. Appendix B provides an analysis of each internal and external stakeholder in terms of their role, the communication outcome required and the tools to be used.

LGIS: Project Execution Plan Version 1.0

Page 4 of 26

2.4
2.4.1

Risk Management
Risk Assessment The Project Manager is responsible for: Scheduling and performing risk assessments and developing strategies to manage those risks for each stage of the project as identified within the Project Plan. Providing a risk review within status reports to the Steering Committee, which will specify any changes to the risks identified during each phase of the project and the strategies adopted to manage them.

The Project Manager will maintain a risk register. The Risk Register will contain the following information relating to the risk: Unique identifier for each risk Description of risk; Rating of likelihood of risk occurring; Rating of seriousness if risk occurs; Overall grade of risk based on likelihood and seriousness; If risk has changed since previous assessment; Action required to minimise the risk; Nominated officer; Progress status; The Project Manager will review the risk register each fortnight and will seek input and advice from key stakeholders, as required, to assess any changes to the level and type of risks to the project. Significant changes to the status of risks or any new risks identified will be reported to the Steering Committee. Any risk that is classified as an A or B grade risk is to have pre-emptive actions and contingency actions identified. Pre-emptive actions are to be included in the work breakdown structure and tracked as part of the on-going progress and monitoring of the project. The Project Manager is to provide updated information on the status of significant risks in status reports to the Steering Committee meeting.

LGIS: Project Execution Plan Version 1.0

Page 5 of 26

2.4.2

Failure to Deliver In the event of the project suffering slippage of greater than two weeks for tasks on the critical path, the project schedule shall be reviewed by the Project Manager and recommendations made to the Steering Committee. Agreement on how to proceed shall be negotiated by the Project Manager and Steering Committee. Once new dates for delivery have been agreed, the planned start and finish dates on the project plan are to be updated to reflect the changes. The Project Manager will then track progress against the revised dates.

2.4.3

Acceptance and Review Periods All review and acceptances shall be completed within the agreed time negotiated between the Project Manager and relevant parties. Should any agreed review period not be met and, in the opinion of the Project Manager, the project is unable to proceed and deliver remaining outputs on time, the schedule shall be revisited. The Project Manager will negotiate any adjustments for the time lost with all affected parties and the recommendations reported to the Steering Committee.

2.4.4

Non-availability of Resources Should any agreed resource not be made available as scheduled in the Project Plan (Refer Appendix D) and, in the opinion of the Project Manager, the project is unable to proceed and deliver remaining outputs on time, the schedule shall be revisited. The Project Manager should negotiate any adjustments for the time lost with all affected parties and the recommendations reported to the Steering Committee.

2.4.5

Issue Management An issue can be defined as a concern that may impede the progress of the project if not resolved. It is the responsibility of the Project Manager to monitor, review and address issues or concerns as they arise through the life of a project. The Project Manager will maintain an Issues Register. The Issues Register will contain the following information relating to the issue: Unique identifier for each issue; Description of the issue; Who the issue was raised by; Date the issue was raised; Who is responsible for progressing the issue;

LGIS: Project Execution Plan Version 1.0

Page 6 of 26

 Priority of the issue; Action and progress notes; Status of the issue (ie open. closed or pending); Date the issue was closed. When a new issue is raised, it will be documented in the Issues register and the Project Manager will determine the appropriate action to be taken (with assistance from the Steering Committee if required). The issue will be progressed and monitored by the Project Manager until satisfactorily resolved. The status of high priority issues will be documented in the status report provided to the Steering Committee. It is the responsibility of the Steering Committee to ensure that any issue that has major implications for the project is appropriately addressed.

2.5

Provision of Facilities
The Liquor and Gaming Branch is to provide appropriate project team (including contractors) facilities including: Office accommodation and stationary; Computer hardware and software for development and testing; Computer hardware and software for word processing, spread sheets etc; and Access to development and test environments for the GRS module of TRACS.

2.6
2.6.1

Skills and Resource Requirements

Skills and Resources The following are the skills and resources that will be used throughout the project: Full time Project Manager; Full time representatives from the Liquor and Gaming Branch; Quality Review Consultant; Access to Information Systems Branch staff; Access to Liquor and Gaming Branch staff for consultation, review and to provide assistance with the Project as required; and

LGIS: Project Execution Plan Version 1.0

Page 7 of 26

 Consultants skilled in the technical delivery of information systems. The full time representatives from the Liquor and Gaming Branch will be taken off-line until the completion of the project and their substantive positions back-filled. This will be planned early in advance with the identification of the staff members, and the advertisement of their temporary replacements. A two-week handover period will be allowed to enable the back-filling arrangement to be a smooth transition. Once the project outputs have been delivered, there will be a period of time (approximately one month) when the business representatives will be working on both the project, to ensure the smooth implementation, and taking on responsibilities of their previous position to assist in the handover from the previous acting arrangement. 2.6.2 Training A detailed staff-training plan will be prepared by the Project Manager which details: Training needs analysis; Format for delivery of training; Training material required; and Evaluation strategy.

It is the responsibility of the Project Manager to monitor the progress of staff training activities as outlined in the task list and ensure resources are available and milestones met. 2.6.3 Support The Project Manager will prepare detailed documentation on post implementation support arrangements which details: The scope of support requirements; Roles and responsibilities; Support procedures; and Linkages with warranty requirements.

It is the responsibility of the Project Manager to monitor support requirements and liaise with staff to ensure adequate support is being provided.

LGIS: Project Execution Plan Version 1.0

Page 8 of 26

2.7
2.7.1

Configuration Management
Change Management The Project Manager will use change management practices. This process will provide the means of addressing the following: Facilitating the introduction of specific project change; Allowing the impact of the change to be assessed; Providing a method of authorising change; and Providing an audit trail of change. All changes are to be authorised by the Project Sponsor. Significant changes that have the potential to impact the budget and milestones of the project are to be approved by the Steering Committee.

2.7.2

Change Reporting In the event that additional or changed functionality of the LGIS is identified (once the Functional Requirements Specification has been signed off), a change request will need to be raised and approved before the change is to proceed. The following procedures are to apply if a change request is received or deemed necessary: The Project Manager is to use the Change Request form to document the name of the officer requesting the change, the date and the change requested. The Project Sponsor is to authorise the change by signing the form (if the change is deemed appropriate). The Contractor is to undertake an impact assessment detailing the work required and a quotation. The Project Sponsor is to review the cost impact assessment and if appropriate authorise the implementation of the change. In the case of changes above $5000, the approval of the Steering Committee is to be requested. The Contractor is to sign the form once the change has been implemented. A Change Register will be maintained by the Project Manager, summarising the following details relating to each change request: Date of request

LGIS: Project Execution Plan Version 1.0

Page 9 of 26

 Who has requested the change Description of change Reason for change Impact of change Cost to the system Resolution Date closed The Change Register will be included in the status report to the Steering Committee. To ensure system testing does not run over-time, a change freeze milestone will be added to the plan and communicated to all testers. Once this milestone has been reached, no further changes, except those judged as critical to the operation of the system, will be implemented as part of the version one implementation. Any changes identified after the commencement of the change freeze milestone will be recorded and subsequently assessed and implemented as part of future enhancements and version releases of the system.

2.8

Confidentiality
All project members, agents, contractors and subcontractors shall respect the confidentiality of each others business and technology and shall not reveal any information concerning the other party without the written permission of the other party. All agreements and contracts entered into require inclusion of a confidentiality clause.

2.9

Updating this Plan

This plan shall be updated if any changes are made to procedures and other information specifically documented in this plan. The updated plan shall be reviewed in accordance with the Development Plan and accepted and issued. The update process includes acceptance by the Project Sponsor. This shall be a new release in accordance with Output management (Refer Section 8). Day to day project plans shall be maintained outside of this plan to reduce the frequency of change. For the project, this document contains only the broad phase plans.

LGIS: Project Execution Plan Version 1.0

Page 10 of 26

3
3.1

Quality Plan
Introduction
The quality process is based on the following components as outlined in the Business Plan: Effective change/issue/problem management; Use of technical experts; Review and acceptance procedures; Appropriate documentation and record keeping; Proven methodologies and standards; and Effective monitoring of procedures.

3.2

Methodologies and Standards

The LGIS Project will utilise where appropriate: The Tasmanian Governments Project Management Guidelines version 5.0, February 2002; The Department of Treasury and Finance: Records Management Procedures; Handbook for Government Procurement; Information System Application Development Standards; and Web publishing standards.

If any of the above guidelines are revised prior to the completion of the project, an assessment will be made as to the appropriateness of adopting the revised standard and updating any relevant documentation and processes. If project documentation is updated, project change control procedures will be used.

LGIS: Project Execution Plan Version 1.0

Page 11 of 26

3.3

Development and Production Environment

The development and production environments are listed below. Any changes to the development or production environment are subject to change control.

3.3.1

Hardware Production File Server Test Server Development Server Desktop Computers SunV240 running Solaris 9 and Oracle 9i SunV240 running Solaris 9 and Oracle 9i PC running Oracle 9i Windows based Pentium PCs

3.3.2

User Interface Unix Terminal Emulation Package Reflections Development environment Graphical User Interface Windows Web browser

3.3.3

Applications Development Languages J2EE with Oracle 9i (Web)

3.3.4

Data Management Database Management System Case Development Facility Query Language Oracle System Architect SQL

3.3.5

Operating System Application Server OS Desktop OS Network Operating System Solaris Windows 2000 service pack 3 Novell Netware v5.1

LGIS: Project Execution Plan Version 1.0

Page 12 of 26

3.4
3.4.1

Records
Record Keeping The following records will be generated by the project team and filed in the Departments Records Management system: Business Case; Project Execution Plan; Business Plan; Change Requests; Change Request Register; Issue Register; Problem Report Register; Risk Register; Quality Assurance records; Training material; Contractor engagement; Business Process Review work; Functional Requirements Specification; System Design Report; Acceptance test plan; Project hand over documentation; and Steering Committee papers.

3.4.2

Retention of Records Records shall be retained in accordance with the Department of Treasury and Finance records disposal schedule, as approved by the State Archivist. The Project Sponsor may identify additional retention or access requirements.

LGIS: Project Execution Plan Version 1.0

Page 13 of 26

4
4.1

Purchasing Plan
Purchasing Specification
Consultancy and contractor services will be required for the: Functional Requirements Specification; System Design Report and software development; and Technical quality assurance of outputs.

Consultants and Contractors will be engaged through either a selective Request for Quotation or Open Request for Tender process, depending on the value of the contract. The Steering Committee will need to approve the scope and list of potential consultants (RFQ only) and documentation (RFT only) prior to issue. In accordance with the Governments procurement guidelines, approval will be requested from the Secretary prior to the release of a consultant or contractor request. At the completion of each evaluation stage, a purchase order will be completed and approval requested from the Secretary.

4.2

Selection of Suppliers
All consultancy selection processes will adhere to the guidelines outlined in the Handbook for Government Procurement. The evaluation criteria for the selection of preferred suppliers will be detailed in either the Evaluation section of the Request for Quotation or the conditions of tender section in the Request for Tender documentation. In each case, an evaluation panel will be established to review and recommend the preferred contractor to the Secretary for approval.

4.3

Contractor Management
A Government Information Technology Contract (GITC) or Contract for Service agreement will be entered into prior to a contractor commencing work. The agreement will detail specific requirements and conditions of the service such as resources, warranty provisions (in the case of software development) and deliverables required. Depending on the nature of the work, the Contractor may be required to prepare a Project Execution Plan detailing how they will deliver the outputs to meet agreed time frames. The contractor may also be required to prepare a written report and meet weekly with the Project Manager to discuss:

LGIS: Project Execution Plan Version 1.0

Page 14 of 26

The status of the project and ensure contractor and client project plans are synchronised; Any slippage to the progress of the project, along with appropriate recovery action; and Any issues or escalation of risks.

In the case of a shorter term contract, such as a technical quality assurance service, the consultant will provide periodic verbal reports relating to progress and any issues identified.

5
5.1
5.1.1

Development Plan
Output Design and Development Activities
Functional Requirements The Business Process Review report will be used as a starting point for the development of the Functional Requirements Specifications (FRS). The FRS will be developed by the contractor in close consultation with staff and a representative sample of stakeholders. The Project Manager will coordinate interview times between the Contractor and stakeholders.

5.1.2

System Design The System Design report will be developed by the contractor based on the FRS version 1.0. The Contractor will liaise closely with staff to clarify and gain further detail regarding aspects of the functional requirements and design elements.

5.1.3 5.1.3.1

Acceptance Testing Acceptance Test Methodology A document will be prepared by the Project Manager outlining the acceptance test methodology including: Testing elements Testing approach Resources required

It is the responsibility of the Project Manager to prepare a detailed test schedule based on the acceptance test methodology and monitor resources and track progress.

LGIS: Project Execution Plan Version 1.0

Page 15 of 26

5.1.3.2

Acceptance Test Plans The acceptance test plans will be based on the FRS and System Design report. The Acceptance Test Plans will contain the following types of information: Test number; Test name; Test details Expected result; Actual result; and Comments. The acceptance test plans will be developed after the acceptance of the system design report. Staff will be taken off-line to prepare the test plan.

5.1.4

Programming Programming will be performed in accordance with industry standards. Programs shall be peer tested by the development team before being reviewed by staff. Staff from the Information Systems Branch will be part of the development team to ensure skills transfer. Software code shall be reviewed by an external consultant for compliance with industry standards and for conformance with the specifications. Software code will be provided to an external consultant in two instalments: at the early stage of development and toward the end. Once accepted, programs shall be subject to the Departments ISB change management processes

5.1.5 5.1.5.1

Manuals System User Manual A System User manual will be prepared by Liquor and Gaming Branch staff which will document how to use the Liquor and Gaming Information System. The manual will be drafted initially by using the FRS and system design document and then refined during unit testing and acceptance testing. Any change to the system raised through a formal change request process will need to be incorporated into the draft system user manual.

LGIS: Project Execution Plan Version 1.0

Page 16 of 26

5.1.5.2

Technical and Maintenance Guide The Technical and Maintenance Guide will be prepared by the contractor for use by the Information Systems Branch staff.

5.1.5.3

System Administrator Operations Guide The System Administrator Operations Guide will be prepared by the contractor for use by the LGIS System Administrator.

5.2

Output Review and Acceptance

The following process will apply for the review and acceptance of the following outputs: Output Functional Requirements Specification (FRS) and System Design Report (SD) Review Acceptance

The Business Reference The Steering Group will review the Committee will receive FRS and SD document. a summary of the outcome of the The Contractor will be development and required to attend review of the outputs, review meetings to together with the formal address questions or sign off from all uncertainties and to Business Reference note changes required. Group members. The Project Manager will also record all changes required to the documents. External Technical QA will also review the FRS and SD.

Acceptance Test Methodology

The Information Systems Branch will review the acceptance test methodology document. Representative from the Liquor and Gaming Branch will unit test and acceptance test the LGIS.

The Project Manager will request approval of the acceptance test methodology from the Steering Committee. The Business Reference Group will formally accept the LGIS. The Information Systems Branch will be required to sign a system acceptance form prior to live

Developed software (LGIS)

LGIS: Project Execution Plan Version 1.0

Page 17 of 26

System User Manual

implementation. The Business Reference The Business Reference group will review the Group will formally System User Manual. accept the System User by providing the Project Manager with a sign off form. The Information Systems Branch will review the Technical Maintenance Guide. The Information System Branch will accept the Technical Maintenance Guide by providing the Project Manager with a sign off form. The Information System Branch and System Administrator(s) will accept the Systems Administrator Operations Guide by providing the Project Manager with a sign off form. The Business Reference Group will formally accept the Training and Support Plan and material by providing the Project Manager with a sign off form.

Technical Maintenance Guide

System Administrator Operations Guide

The Information Systems Branch and System Administrator(s) will review the Technical Maintenance Guide.

Training and Support Plan and material.

The Business Reference group will review the Training and Support plan and material.

Acceptance time frames will comply with the current Project Plan. In each case, it is the responsibility of the Project Manager to schedule and coordinate review meetings.

6
6.1

Test Plan
Introduction
The Liquor and Gaming system shall be subject to the following testing: Unit testing;

LGIS: Project Execution Plan Version 1.0

Page 18 of 26

System and integration testing; and Acceptance testing.

All testing shall show the version of the output being tested, the version of the test specifications being used and, for acceptance testing, the version of the design specification being tested against.

6.2

Unit Testing
The programmer shall test each unit of programming for conformance to the design by applying tests and recording the results of the tests. Each page used to record testing shall identify the unit of programming tested including the version, such as data and time stamp of the load module, and a page number within the set of tests applied to the unit of programming. Once the programmer and undergone peer review have tested each functional unit, the program is to be tested by LGB staff. LGB staff will run a number of test cases on the screens and document test results. The Project Manager is responsible for allocating unit testing to LGB staff and ensuring problem reports are rectified and re-tested.

6.3
6.3.1

Integration and System Testing

Approach System and Integration testing shall be performed by the contractor using the system test specifications to ensure that the programming works as a homogenous unit before the acceptance test specifications are applied. Each test specification shall be annotated with the results of the test. Where the output fails to pass testing a Problem Report shall be raised. Incident Reports may be used to identify individual failures for later consolidation under a single Problem Report.

6.3.2

Review When the tests have been successfully completed the results of testing shall be reviewed generally as defined in the Development Plan.

6.4

Acceptance Testing
The Project Manager is responsible for coordinating acceptance testing, and for ensuring that acceptance tests are completed to the project schedule, and also according to the Acceptance Test Plan to be prepared during acceptance test development.

LGIS: Project Execution Plan Version 1.0

Page 19 of 26

The Project Manager will delegate testing responsibilities to LGB staff. Test failures (where the system does not perform according to the specifications) shall be formally recorded in a problem report. The problem report will contain the following information: Problem report number Name of officer raising problem report; Date; Screen name; Detailed description of problem; and Any relevant attachment such as a screen dump. A summary of all problem reports will be listed in the problem report register. The problem report register will contain the following details: Problem number Test number Name of tester Nature of problem Severity Date sent Date sent back Date closed Comments

The Project Manager shall prepare a written acceptance of the system passing acceptance tests for signature.

LGIS: Project Execution Plan Version 1.0

Page 20 of 26

7
7.1
7.1.1

Implementation and Delivery Plan

Implementation
Outputs The contractor will prepare an implementation plan for the LGIS that documents: Implementation steps including tasks and contingency plans; and Implementation responsibilities.

7.1.2

Handover Plan The Project Manager is responsible for preparing the Handover Plan which formalises the transfer of responsibility of the project from the Project Manager to the Business Owner. The Handover Plan will document the status of the project against the agreed project outputs. This will include: An assessment of the project against agreed outputs; The status of any outstanding tasks and issues; The responsibilities of the Business Owner; Procedures for problem reporting and change reporting; Location of electronic and paper files; and Warranty and maintenance of project outputs.

7.1.3

Project Closure Project closure will be initiated once the project outcomes have been delivered. There will be a period of 6-8 weeks following live implementation where project staff will complete any outstanding tasks, support staff in the use of the new system and address any problems raised. The Project Manager will formally handover responsibility to the Business Owner, via the HandOver Plan, after this period. It is the responsibility of the Business Owner to deliver project outcomes.

LGIS: Project Execution Plan Version 1.0

Page 21 of 26

The Steering Committee will need to be satisfied that the project has achieved all planned outcomes and the post implementation review has been completed, prior to approval being given to close the project. It is the responsibility of the Business Owner to contract a consultant to undertake a post implementation review of the project. It is the responsibility of the Business Owner to review the report from the consultant, discuss any issues with the Project Sponsor and identify any further action required. The project is only to be formally closed and the Steering Committee disbanded after all issues from the report have been dealt with. This may include the establishment of another project, or the provision of additional resources to the Business Owner.

LGIS: Project Execution Plan Version 1.0

Page 22 of 26

Outcome Realisation Plan

Once the LGIS project delivers outputs to the Business Owner, they will be utilised by the Liquor and Gaming Branch staff to enable the projects outcomes to be realised.

8.1

Monitoring and Reporting

The Business Owner will monitor the performance of each outcome measure and will report on the progress to the Steering Committee:
Defining Success Improved access and quality of liquor and gaming information. Measuring Performance Reducing the lead time to access management information A qualitative assessment will be made by Liquor and Gaming staff relating to the ease of extracting management information. Increasing the number of hours that information can be accessed ISB will provide notification as to when scheduled backups commence. TMD will provide information from their system log files relating to when the system completes all backups and scheduled runs. Reducing the number of data locations TMD will provide notification of when the LLS and GRS have been de-commissioned. ISB will provide notification of how many different data inputs (excel spreadsheets) were migrated into the new system. Reducing the risk of data integrity, confidentiality and privacy issues. The System Administrator user maintenance screens will be checked to confirm all users have been assigned to appropriate roles. Audit logs will be checked by the Business Owner to ensure that when a record is updated or viewed, the date, time and user accessing the information is recorded. Reducing the number of systems that present a risk to the Department. TMD will provide notification when the LLS is decommissioned.

LGIS: Project Execution Plan Version 1.0

Page 23 of 26

Output Management Plan

Outputs will be identified and managed to ensure that all interested parties know that they have the correct version and can be advised of any changes and/or deficiencies.

9.1

Output Register
An Output Register will be maintained containing the following details: Version; Status; Status date; Description; and Distribution.

9.2

Version Control
Outputs for release shall be identified by a release number starting at one and increasing by one for each release. Outputs can be identified as follows: all will have a release number (and a revision letter if in draft); the original draft will be Release 0.A; subsequent drafts will be Release 0.B, Release 0.C etc; the accepted and issued document is Release 1.0; subsequent changes in draft form become Release 1.0A, 1.0B etc; and the accepted and issued second version becomes Release 1.1 or Release 2.0, as determined by the Project Manager.

LGIS: Project Execution Plan Version 1.0

Page 24 of 26

10

Maintenance Plan
The contractor will be required to support the application in accordance with the scope and procedures outlined in the GITC. Once the warranty period has expired, the Information Systems Branch will be responsible for the maintenance of the Liquor and Gaming system including resolution of problem reports and actioning of change requests.

11
11.1

Project Plan
Overall Project Plan
The Project Plan is attached at Appendix D. The Appendix is the baseline Project Plan for the project. The working copy of the day-to-day project plan will be maintained by the Project Manager to reduce the frequency of change to this document.

LGIS: Project Execution Plan Version 1.0

Page 25 of 26

11

Appendices
Definitions Stakeholder Analysis Provides explanations of terms and concepts used within the Project Execution Plan. Provides a summary of each stakeholder for the project, the reason for their identification and the communication outcomes required. Provides snapshot details of the current risk assessment and risk management strategies. A snapshot of the Gantt Chart of major project phases, milestones, processes and tasks. Provides snapshot details of the current status of the projects budget and expenditure.

Risk Analysis

Project Plan

Budget and Expenditure

LGIS: Project Execution Plan Version 1.0

Page 26 of 26

Appendix A: Definitions

LGIS Project Execution Plan Version 1.0

Page 1 of 4

Accepted The recorded decision that a product or part of a product has satisfied the requirements and may be used in the next part of the process. Approved The recorded decision that a Product or part of a Product has satisfied the quality standards. Authorised The recorded decision that a record or Product has been cleared for use or action. Contract The Contract, agreement or understanding between a contractor and the Department to develop or maintain a Product. Change Request. Product changes are notified using a Change Request. Development All activities to be performed to create a Product. It includes specification, design, programming, testing and installation. Issued A released Product or part of a Product is issued when the original or (more usually) copies of the Product are provided to a person or organisation. Product Any report, manual, specification, programming or other output developed as part of a Contract. Product includes computer based files such as data, code (programming) and computer control instructions. Released Product An approved (quality inspected) Product or part of a Product is released when it is made available for issue to the next phase of development or for end use. Software The programs, procedures and any associated documentation pertaining to the operation of a data processing system. Software is an intellectual creation that is independent of the medium on which it is recorded. Test Plan A management document which addresses all aspects related to the test. It should include test scenarios, the test schedule and define any necessary support tools.

LGIS: Project Execution Plan Version 1.0

Page 2 of 4

Testing The process of exercising or evaluating a system or system component by manual or automated means to confirm that it satisfies specified requirements, or to identify differences between expected and actual results. Test Specification Describes the test criteria and the methods to be used in a specific test to assure the performance and design specifications have been satisfied. The test specification identifies the capabilities or program functions to be tested and identifies the test environment. It may include test data to support identified test scenarios.

LGIS: Project Execution Plan Version 1.0

Page 3 of 4

Appendix B: Stakeholder Analysis

LGIS: Project Execution Plan Version 1.0

Page 4 of 4

Stakeholder INTERNAL STAKEHOLDERS Executive Committee The Executive Committee monitors the overall activities of the Department, sets corporate goals and objectives and approves funding for initiative projects such as LGIS.

Communication Outcome Awareness of project progress and status. Sign off on key issues when required. On-going support and funding is maintained.

Communication Tool Minutes of Steering Committee meetings Memos on any funding requests. Executive Director, Revenue, Gaming and Licensing to answer any questions raised. Presentations/papers on major approvals/stages of project.

Frequency Monthly

Responsibility Project Manager / Project Sponsor and Business Owner.

Ad-hoc

Ad-hoc

Corporate Management Group The Corporate Management Group (CMG) is responsible for addressing the business needs and issues of the Department and monitoring progress of initiative projects, such as the LGIS Project. Project Steering Committee The LGIS Steering Committee is responsible for ensuring the appropriate management of the Project as outlined in the Project Business Plan.

Awareness of project progress against agreed milestones.

Ad-hoc

Project Manager / Business Owner.

Awareness of project progress and status. Ensure project issues and risks are adequately dealt with. Ensure scope of project is managed. Sign off on key project documentation. Awareness of project progress and status. Informed decision making for out-of-session approvals. Availability of adequate resources. Effective stakeholder management.

Briefings and Status Reports. Papers on the development and review of project outputs.

Monthly

Project Manager

Ad-hoc

Project Sponsor (Executive Director, RGLD) The Project Sponsor has the delegated authority of the Steering Committee to assist with project and business management issues that arise outside the formal business of the Steering Committee.

Meetings Email

Ad-hoc

Project Manager

LGIS Project Execution Plan Version 1.0

Page 1 of 4

Stakeholder Business Owner (Director Liquor and Gaming Branch) The Business Owner is responsible for utilising the project outputs to achieve the agreed project outcomes. Liquor and Gaming Branch staff The Liquor and Gaming Branch staff will be the primary users of the LGIS. The success of the project is very much dependent on the staff accepting and using the new system and being satisfied their business requirements have been met. All resources for detailed knowledge of operational procedures and issues are located in this section.

Communication Outcome Awareness of progress of the project. Availability of adequate resources. Effective stakeholder management Commitment of staff to undertake project work to a high level and to meet the project time frames. Awareness of project status and benefits. LGIS meets the business requirements of the branch. Sufficient data is collected by LGIS for Departmental reporting requirements.

Communication Tool Meetings Email

Frequency Regular

Responsibility Project Manager

Branch internal Bulletin publication articles Branch Management meetings Branch meetings.

Monthly

Project Manager

Monthly

Project Manager / Business Owner Project Officers / Business Owner / Project Manager Project Manager

Monthly

Business Reference Group meetings. Information /issue papers Reports against QA milestones. Project QA reports to QAC meetings.

Ad-hoc

Treasury Quality Assurance Committee The Treasury Quality Assurance Committee (QAC) provides advice to the Secretary on the management of risks in the Department.

Awareness of status of project and progress against CMG milestones. Awareness of any project management issues and that appropriate project methodology is being utilised. Confirmation that any identified risks are appropriately managed.

Ad-hoc Every 6 weeks (QAC meetings).

Project Manager Project Manager

Information System Branch Staff ISB staff are responsible for supporting the system once the warranty period has expired. ISB staff will provide development resources to assist the out-sourced service provider.

Commitment of staff to undertake project work to a high level and to meet project time frames. Awareness of project status and benefits. Technically compliant specifications.

Business Reference Group meetings (Manager Application Support to be a member) ISB management meetings

Ad-hoc

Project Manager and Director, ISB

Fortnightly

LGIS: Project Execution Plan Version 1.0

Page 2 of 4

Stakeholder

Communication Outcome Availability of adequate resources.

Communication Tool One-on-one communication with Manager Application Support and Director Information Systems.

Frequency

Responsibility

Regular

EXTERNAL STAKEHOLDERS Treasurys Internal Auditor KPMG are currently engaged as Treasurys internal auditor. The internal audit focuses on aspects of security, auditing and procedures. Quality Review Consultants Quality review consultants are engaged to review project outputs or processes. Contractors / Consultants Contractor and consultants will be required to deliver key project outputs. Service Tasmania Service Tasmania provides over the counter services for the Liquor and Gaming Branch to collect fees and process applications. Tourism Tasmania Tourism Tasmania receives information on liquor licences for the purpose of marketing vineyards. In particular Tourism need to know which vineyards have Cellar door sales and when a licence has been approved, transferred or cancelled. Tasmania Police Tasmania Police are responsible for enforcing the provisions of the Liquor and Accommodation Act 1990. They ensure that operations are carried out in line with legislation and the licence and permit conditions pertaining to the establishment. Network gaming

Ensure functional requirements and design of new system conform to auditing standards. Ensure methodologies are adhered to and outputs are technically sound.

Meetings Email

Ad-hoc

Project Manager/ Business Owner

Meetings Briefing papers Emails Quotation requests Contracts Meetings Email Meetings Briefing papers Email Meetings Email

Regular

Project Manager/ Business Owner

Ensure outputs delivered meet the required quality standards.

Regular

Project Manager/ Business Owner

Ensure any changes to procedures or services required are discussed and accommodated. Ensure the data extracted meets information requirements. Ensure the mechanism for receiving information is appropriate to the relative need for data to be current. Information is provided in a format that best supports liquor licensing enforcement.

Ad-hoc

Project Manager/ Business Owner

Ad-hoc

Project Manager/ Business Owner

Meetings Email

Ad-hoc

Project Manager / Business Owner

Information is provided in a format that

Meetings

Ad-hoc

Project Manager/

LGIS: Project Execution Plan Version 1.0

Page 3 of 4

Stakeholder Network Gaming is the main gaming operator in the State and is responsible for ensuring keno and gaming machines are not operated outside the hours of the liquor licence. Tasmanian Fire Service The Tasmanian Fire Service is responsible for ensuring that Licensed premises conform to fire safety standards.

Communication Outcome minimises the risk of illegal use of gaming and keno machines.

Communication Tool Email

Frequency

Responsibility Business Owner

Ensure the data extracted meets information requirements. Ensure the mechanism for receiving information is appropriate to the relative need for data to be current. Ensure the data extracted meets information requirements. Ensure the mechanism for receiving information is appropriate to the relative need for data to be current.

Meetings Email

Ad-hoc

Project Manager/ Business Owner

Department of Primary Industry Water and Environment (DPIWE) DPIWE is responsible for maintaining the Land Information System Tasmania (LIST) and for producing the Tasmanian Towns Street Atlas. One of the components of the Street Atlas and one of the layers on the list is the community facilities, which includes licensed premises. Australian Hotels Association (AHA) The AHA is responsible for promoting and protecting the rights and interests of a licensed hotelier.

Meetings Email

Ad-hoc

Project Manager/ Business Owner

Ensure the data extracted meets information requirements. Ensure the mechanism for receiving information is appropriate to the relative need for data to be current.

Meetings Email

Ad-hoc

Project Manager/ Business Owner

LGIS: Project Execution Plan Version 1.0

Page 4 of 3

Appendix C: Risk Analysis

LGIS Project Execution Plan Version 1.0

Page 1 of 1

LGIS Project Execution Plan Version 1.0

Page 1 of 1

Appendix D: Project Plan

LGIS Project Execution Plan Version 1.0

Page 1 of 2

Appendix E: Budget and Expenditure