Liquor and Gaming Information System Project Execution Plan

8/6/2019 Liquor and Gaming Information System Project Execution Plan

http://slidepdf.com/reader/full/liquor-and-gaming-information-system-project-execution-plan 1/44

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 andCabinet, Tasmania. The structure is based on a number of methodologies including the

Tasmanian Government’s Project Management Guidelines, Rob Thomsett’s projectmanagement methodologies as described in Third Wave Project Management: a handbook

for managing the complex information systems of the 1990’s. Rob Thomsett. Prentice-Hall,Inc. 1993 and John Smyrk’s 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 ExecutionPlan.

The Project Execution Plan is a managed document. For identification of amendments eachpage contains a release number and a page number. Changes will only be issued as completereplacement. Recipients should remove superseded versions from circulation. Thisdocument is authorised for release once all signatures have been obtained.

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

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

LGIS: Project Execution Plan – Version 1.0 Page ii of v



1. BUILD STATUS:

Version Date Author Reason Sections

1.0 25/8/04 First release

2. AMENDMENTS IN THIS RELEASE:

Section Title Section

Number

Amendment Summary

This is the first release of this document.

3. DISTRIBUTION:

Copy No Version Issue Date Issued To

1 1.0 25 August 2004 Marita Holding

2 1.0 25 August 2004 Mervyn Feltham

3 1.0 25 August 2004 Michele Mason (DPAC)

LGIS: Project Execution Plan – Version 1.0 Page iii of v



Table of Contents

1 Introduction..................................................................................................................1

1.1 Document Purpose .............................................................................................11.2 Outcomes ...........................................................................................................1

1.3 Project Outputs...................................................................................................1

1.4 Scope of Work ...................................................................................................2

2 Management Plan ........................................................................................................4

2.1 Management.......................................................................................................4

2.2 Status Reporting.................................................................................................4

2.3 Stakeholder Management...................................................................................42.4 Risk Management ..............................................................................................5

2.5 Provision of Facilities ........................................................................................7

2.6 Skills and Resource Requirements.....................................................................7

2.7 Configuration Management ...............................................................................9

2.8 Confidentiality .................................................................................................10

2.9 Updating this Plan............................................................................................10

3 Quality Plan................................................................................................................11

3.1 Introduction......................................................................................................11

3.2 Methodologies and Standards ..........................................................................11

3.3 Development and Production Environment.....................................................12

3.4 Records ............................................................................................................13

4 Purchasing Plan .........................................................................................................14

4.1 Purchasing Specification..................................................................................14

4.2 Selection of Suppliers ......................................................................................14

4.3 Contractor Management...................................................................................14

5 Development Plan ......................................................................................................15

5.1 Output Design and Development Activities ....................................................15

5.2 Output Review and Acceptance.......................................................................17

6 Test Plan .....................................................................................................................18

6.1 Introduction......................................................................................................18

6.2 Unit Testing .....................................................................................................19

6.3 Integration and System Testing .......................................................................19

LGIS: Project Execution Plan – Version 1.0 Page iv of v



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

7 Implementation and Delivery Plan...........................................................................21

7.1 Implementation ................................................................................................21

8 Outcome Realisation Plan .........................................................................................23

8.1 Monitoring and Reporting................................................................................23

9 Output Management Plan.........................................................................................24

9.1 Output Register ................................................................................................24

9.2 Version Control................................................................................................24

10 Maintenance Plan.......................................................................................................25

11 Project Plan ................................................................................................................25

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

11 Appendices..................................................................................................................26

LGIS: Project Execution Plan – Version 1.0 Page v of v



1 Introduction

1.1 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 Teamto 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 theproject.

The PEP expands on the Project Business Plan which is the approved plan

describing “what” will happen in the project. The PEP details “how” theProject Team will carry out their tasks/activities to ensure that the “what” willoccur.

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 a24 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 projectoutcomes 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 GRSand LLS;

o is easily accessible and provides a good level of performance forstaff 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 re-designed business processes and generating template letters to besent to clients;

o is an efficient processing system for the Branch’s 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 clientinformation;

o conforms to Departmental standards;

o is able to be readily supported, enhanced and maintained by theInformation 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)

Not Part of the Project

(Outside Scope)

Delivery of outputs and outcomes. Delivery of the branch amalgamationoutcomes.

Review of business processes Review and possible amalgamation of external information web sites will beprogressed by the LGB.

All business processes currentlysupported by the existing GRS andLLS.

Conversion of GRS database to Oracle.This will be completed as part of theDatabase Migration Project run by ISB.

Automated transfer of data to externalstakeholders

Development and implementation of data synchronisation functionalityrequired for mobile PDA deployment.

This functionality will be designed inthe new system, but will be developed

LGIS: Project Execution Plan – Version 1.0 Page 2 of 26



at a later stage.

Review of data prior to migration Review / upgrade of informationsystems used by external stakeholders.Any upgrade to external gamingsystem such as those used by WrestPoint Casino need to be negotiated bythe Branch.

Collection of gaming and licensingrevenue by Service Tasmania oranother suitable provider

Provision of direct interface to LGISfor Service Tasmania staff.

Review of all letters and forms Progressing any legislative changesthat may arise from the businessprocess review work. This would be aseparate project for the LGB.

Review of all reports to be extractedfrom system

Upgrade of the Receipting system(GRL) is a project being progressed bythe Revenue Operations section of the

RGLD.

Receipting of payments into the newsystem

Implementation of electronic receiptingfunctionality at Henty House. In theInterim, Service Tasmania can be usedto receipt payment until GRL isimplemented.

Data migration Implementation of other sub-projectsassociated with the branchamalgamation such as the developmentof an enforcement and communicationstrategy.

Documentation of business rules Review of delivery and coordination of Responsible Serving of Alcoholtraining. This will be managed by theLGB as another project.

Definition of a common languagebetween licensing and gaming terms

Inclusion of Casino audit functionalityinto the system. This will remain inMicrosoft Excel and a review will beundertaken by the Branch in the futureto ascertain the scope of audit work required.

Training of staff in the new system tobe able to process either licensing or

gaming application (depending on thecurrent nature of their work)

Training of staff to be cross-skilled inboth licensing and gaming matters.

This is the responsibility of the branchamalgamation project.

Preparation of technical documentationand user manuals on the new system




2 Management Plan

2.1 Management

The project manager for the LGIS Project is Marita Holding. The ProjectManager is responsible to the Project Sponsor for the delivery of the agreedproject outputs.

The project governance structure, management roles, functions andresponsibilities are defined within Section 3 of the current Project BusinessPlan.

2.2 Status Reporting

The Project Manager will provide a status report at the monthly SteeringCommittee 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 interms of their role, the communication outcome required and the tools to beused.




2.4 Risk Management

2.4.1 Risk Assessment

The Project Manager is responsible for:

• Scheduling and performing risk assessments and developing strategies tomanage those risks for each stage of the project as identified within theProject 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 willcontain 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-emptiveactions and contingency actions identified. Pre-emptive actions are to beincluded in the work breakdown structure and tracked as part of the on-goingprogress 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.




2.4.2 Failure to Deliver

In the event of the project suffering slippage of greater than two weeks fortasks on the critical path, the project schedule shall be reviewed by the ProjectManager and recommendations made to the Steering Committee. Agreement

on how to proceed shall be negotiated by the Project Manager and SteeringCommittee.

Once new dates for delivery have been agreed, the planned start and finishdates on the project plan are to be updated to reflect the changes. The ProjectManager 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 timenegotiated between the Project Manager and relevant parties.

Should any agreed review period not be met and, in the opinion of the ProjectManager, the project is unable to proceed and deliver remaining outputs ontime, the schedule shall be revisited. The Project Manager will negotiate anyadjustments for the time lost with all affected parties and the recommendationsreported to the Steering Committee.

2.4.4 Non-availability of Resources

Should any agreed resource not be made available as scheduled in the ProjectPlan (Refer Appendix D) and, in the opinion of the Project Manager, theproject is unable to proceed and deliver remaining outputs on time, theschedule shall be revisited. The Project Manager should negotiate anyadjustments for the time lost with all affected parties and the recommendationsreported to the Steering Committee.

2.4.5 Issue Management

An issue can be defined as a concern that may impede the progress of theproject if not resolved. It is the responsibility of the Project Manager tomonitor, 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 Registerwill 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;




• 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 theProject Manager will determine the appropriate action to be taken (withassistance from the Steering Committee if required). The issue will beprogressed and monitored by the Project Manager until satisfactorily resolved.

The status of high priority issues will be documented in the status reportprovided to the Steering Committee. It is the responsibility of the SteeringCommittee 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 sheetsetc; and

• Access to development and test environments for the GRS moduleof TRACS.

2.6 Skills and Resource Requirements

2.6.1 Skills and Resources

The following are the skills and resources that will be used throughout theproject:

• 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, reviewand to provide assistance with the Project as required; and




• Consultants skilled in the technical delivery of information systems.

The full time representatives from the Liquor and Gaming Branch will betaken off-line until the completion of the project and their substantive positionsback-filled. This will be planned early in advance with the identification of

the staff members, and the advertisement of their temporary replacements. Atwo-week handover period will be allowed to enable the back-fillingarrangement 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 workingon both the project, to ensure the smooth implementation, and taking onresponsibilities of their previous position to assist in the handover from theprevious acting arrangement.

2.6.2 Training

A detailed staff-training plan will be prepared by the Project Manager whichdetails:

• 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 availableand milestones met.

2.6.3 Support

The Project Manager will prepare detailed documentation on postimplementation 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 requirementsand liaise with staff to ensure adequate support is being provided.




2.7 Configuration Management

2.7.1 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 tobe 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), achange request will need to be raised and approved before the change is toproceed.

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 todocument the name of the officer requesting the change, the dateand 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 thework 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 caseof changes above $5000, the approval of the Steering Committee isto be requested.

• The Contractor is to sign the form once the change has beenimplemented.

A Change Register will be maintained by the Project Manager, summarisingthe following details relating to each change request:

• Date of request




• 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 SteeringCommittee.

To ensure system testing does not run over-time, a ‘change freeze’ milestonewill be added to the plan and communicated to all testers. Once this milestonehas been reached, no further changes, except those judged as critical to theoperation of the system, will be implemented as part of the version oneimplementation. Any changes identified after the commencement of the‘change freeze’ milestone will be recorded and subsequently assessed andimplemented as part of future enhancements and version releases of thesystem.

2.8 Confidentiality

All project members, agents, contractors and subcontractors shall respect theconfidentiality of each other’s business and technology and shall not revealany information concerning the other party without the written permission of the other party.

All agreements and contracts entered into require inclusion of a confidentialityclause.

2.9 Updating this Plan

This plan shall be updated if any changes are made to procedures and otherinformation specifically documented in this plan.

The updated plan shall be reviewed in accordance with the Development Planand accepted and issued. The update process includes acceptance by theProject Sponsor. This shall be a new release in accordance with Outputmanagement (Refer Section 8).

Day to day project plans shall be maintained outside of this plan to reduce thefrequency of change. For the project, this document contains only the broadphase plans.




3 Quality Plan

3.1 Introduction

The quality process is based on the following components as outlined in theBusiness 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 Government’s 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 theproject, an assessment will be made as to the appropriateness of adopting therevised standard and updating any relevant documentation and processes.

If project documentation is updated, project change control procedures will beused.




3.3 Development and Production Environment

The development and production environments are listed below.

Any changes to the development or production environment are subject tochange control.

3.3.1 Hardware

Production File Server SunV240 running Solaris 9 andOracle 9i

Test Server SunV240 running Solaris 9 andOracle 9i

Development Server PC running Oracle 9i

Desktop Computers Windows based Pentium PC’s

3.3.2 User Interface

Unix Terminal Emulation Package Reflections

Development environment Windows

Graphical User Interface Web browser

3.3.3 Applications

Development Languages J2EE with Oracle 9i (Web)

3.3.4 Data Management

Database Management System Oracle

Case Development Facility System Architect

Query Language SQL

3.3.5 Operating System

Application Server OS Solaris

Desktop OS Windows 2000 service pack 3

Network Operating System Novell Netware v5.1




3.4 Records

3.4.1 Record Keeping

The following records will be generated by the project team and filed in theDepartment’s 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 andFinance records disposal schedule, as approved by the State Archivist. TheProject Sponsor may identify additional retention or access requirements.




4 Purchasing Plan

4.1 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 selectiveRequest for Quotation or Open Request for Tender process, depending on thevalue 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 Government’s procurement guidelines, approval willbe requested from the Secretary prior to the release of a consultant orcontractor request.

At the completion of each evaluation stage, a purchase order will becompleted and approval requested from the Secretary.

4.2 Selection of Suppliers

All consultancy selection processes will adhere to the guidelines outlined inthe Handbook for Government Procurement.

The evaluation criteria for the selection of preferred suppliers will be detailedin 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 recommendthe preferred contractor to the Secretary for approval.

4.3 Contractor Management

A Government Information Technology Contract (GITC) or Contract forService agreement will be entered into prior to a contractor commencing work.The agreement will detail specific requirements and conditions of the servicesuch 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 toprepare a Project Execution Plan detailing how they will deliver the outputs tomeet agreed time frames. The contractor may also be required to prepare awritten report and meet weekly with the Project Manager to discuss:




• The status of the project and ensure contractor and client projectplans are synchronised;

• Any slippage to the progress of the project, along with appropriaterecovery action; and

• Any issues or escalation of risks.

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

5 Development Plan

5.1 Output Design and Development Activities

5.1.1 Functional Requirements

The Business Process Review report will be used as a starting point for thedevelopment 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 willcoordinate interview times between the Contractor and stakeholders.

5.1.2 System Design

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

5.1.3 Acceptance Testing

5.1.3.1 Acceptance Test Methodology

A document will be prepared by the Project Manager outlining the acceptancetest methodology including:

• Testing elements

• Testing approach

• Resources required

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




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 systemdesign 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 reviewedby 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 withindustry standards and for conformance with the specifications. Software codewill be provided to an external consultant in two instalments: at the early stageof development and toward the end.

Once accepted, programs shall be subject to the Department’s ISB changemanagement processes

5.1.5 Manuals

5.1.5.1 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 designdocument and then refined during unit testing and acceptance testing.

Any change to the system raised through a formal change request process willneed to be incorporated into the draft system user manual.




5.1.5.2 Technical and Maintenance Guide

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

5.1.5.3 System Administrator Operations Guide

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

5.2 Output Review and Acceptance

The following process will apply for the review and acceptance of thefollowing outputs:

Output Review Acceptance

FunctionalRequirementsSpecification (FRS) andSystem Design Report(SD)

The Business ReferenceGroup will review theFRS and SD document.

The Contractor will berequired to attendreview meetings toaddress questions oruncertainties and tonote changes required.

The Project Managerwill also record allchanges required to thedocuments.

External Technical QAwill also review theFRS and SD.

The SteeringCommittee will receivea summary of theoutcome of thedevelopment andreview of the outputs,together with the formalsign off from allBusiness ReferenceGroup members.

Acceptance Test

Methodology

The Information

Systems Branch willreview the acceptancetest methodologydocument.

The Project Manager

will request approval of the acceptance testmethodology from theSteering Committee.

Developed software(LGIS)

Representative from theLiquor and GamingBranch will unit testand acceptance test theLGIS.

The Business ReferenceGroup will formallyaccept the LGIS.

The InformationSystems Branch will berequired to sign a

system acceptance formprior to live




implementation.

System User Manual The Business Referencegroup will review theSystem User Manual.

The Business ReferenceGroup will formallyaccept the System Userby providing the Project

Manager with a sign off form.

Technical MaintenanceGuide

The InformationSystems Branch willreview the TechnicalMaintenance Guide.

The InformationSystem Branch willaccept the TechnicalMaintenance Guide byproviding the ProjectManager with a sign off form.

System AdministratorOperations Guide

The InformationSystems Branch andSystemAdministrator(s) willreview the TechnicalMaintenance Guide.

The InformationSystem Branch andSystemAdministrator(s) willaccept the SystemsAdministratorOperations Guide byproviding the ProjectManager with a sign off form.

Training and SupportPlan and material.

The Business Referencegroup will review theTraining and Supportplan and material.

The Business ReferenceGroup will formallyaccept the Training andSupport Plan andmaterial by providingthe Project Managerwith a sign off form.

Acceptance time frames will comply with the current Project Plan. In each

case, it is the responsibility of the Project Manager to schedule and coordinatereview meetings.

6 Test Plan

6.1 Introduction

The Liquor and Gaming system shall be subject to the following testing:

• Unit testing;




• 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 thedesign specification being tested against.

6.2 Unit Testing

The programmer shall test each unit of programming for conformance to thedesign by applying tests and recording the results of the tests.

Each page used to record testing shall identify the unit of programming testedincluding 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 functionalunit, 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 isresponsible for allocating unit testing to LGB staff and ensuring problemreports are rectified and re-tested.

6.3 Integration and System Testing

6.3.1 Approach

System and Integration testing shall be performed by the contractor using thesystem test specifications to ensure that the programming works as ahomogenous 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 laterconsolidation under a single Problem Report.

6.3.2 Review

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

6.4 Acceptance Testing

The Project Manager is responsible for coordinating acceptance testing, andfor ensuring that acceptance tests are completed to the project schedule, andalso according to the Acceptance Test Plan to be prepared during acceptance

test development.




The Project Manager will delegate testing responsibilities to LGB staff.

Test failures (where the system does not perform according to thespecifications) shall be formally recorded in a problem report. The problemreport 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 passingacceptance tests for signature.




7 Implementation and Delivery

Plan

7.1 Implementation

7.1.1 Outputs

The contractor will prepare an implementation plan for the LGIS thatdocuments:

• 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 whichformalises the transfer of responsibility of the project from the ProjectManager to the Business Owner.

The Handover Plan will document the status of the project against the agreedproject 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 beendelivered. There will be a period of 6-8 weeks following live implementationwhere project staff will complete any outstanding tasks, support staff in theuse of the new system and address any problems raised. The Project Managerwill formally handover responsibility to the Business Owner, via the Hand-Over Plan, after this period.

It is the responsibility of the Business Owner to deliver project outcomes.




The Steering Committee will need to be satisfied that the project has achievedall 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 theconsultant, discuss any issues with the Project Sponsor and identify anyfurther action required. The project is only to be formally closed and theSteering Committee disbanded after all issues from the report have been dealtwith. This may include the establishment of another project, or the provisionof additional resources to the Business Owner.




8 Outcome Realisation Plan

Once the LGIS project delivers outputs to the Business Owner, they will beutilised by the Liquor and Gaming Branch staff to enable the project’soutcomes to be realised.

8.1 Monitoring and Reporting

The Business Owner will monitor the performance of each outcome measureand will report on the progress to the Steering Committee:

Defining Success Measuring Performance

Improved access andquality of liquor andgaming information.

Reducing the lead time to access management informationA qualitative assessment will be made by Liquor and Gamingstaff 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 backupscommence. TMD will provide information from their systemlog files relating to when the system completes all backups andscheduled runs.

Reducing the number of data locations

TMD will provide notification of when the LLS and GRS havebeen de-commissioned. ISB will provide notification of howmany different data inputs (excel spreadsheets) were migratedinto the new system.

Reducing the risk of data integrity, confidentiality and

privacy issues.

The System Administrator user maintenance screens will bechecked to confirm all users have been assigned to appropriateroles. Audit logs will be checked by the Business Owner toensure that when a record is updated or viewed, the date, timeand user accessing the information is recorded.

Reducing the number of systems that present a risk to theDepartment. TMD will provide notification when the LLS is de-commissioned.




9 Output Management Plan

Outputs will be identified and managed to ensure that all interested partiesknow that they have the correct version and can be advised of any changesand/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 andincreasing 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 Release2.0, as determined by the Project Manager.




10 Maintenance PlanThe contractor will be required to support the application in accordance withthe scope and procedures outlined in the GITC.

Once the warranty period has expired, the Information Systems Branch will beresponsible for the maintenance of the Liquor and Gaming system includingresolution of problem reports and actioning of change requests.

11 Project Plan

11.1 Overall Project Plan

The Project Plan is attached at Appendix D. The Appendix is the baselineProject Plan for the project. The working copy of the day-to-day project planwill be maintained by the Project Manager to reduce the frequency of changeto this document.




11 Appendices

Definitions Provides explanations of terms and concepts

used within the Project Execution Plan.

Stakeholder Analysis Provides a summary of each stakeholder for

the project, the reason for their

identification and the communication

outcomes required.

Risk Analysis Provides ‘snapshot’ details of the current

risk assessment and risk management

strategies.

Project Plan A ‘snapshot’ of the Gantt Chart of major

project phases, milestones, processes and

tasks.

Budget and Expenditure Provides ‘snapshot’ details of the current

status of the project’s budget and

expenditure.




Appendix A: Definitions




Accepted

The recorded decision that a product or part of a product has satisfied therequirements 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 qualitystandards.

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 Departmentto 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 aContract. 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 ismade available for issue to the next phase of development or for end use.

Software

The programs, procedures and any associated documentation pertaining to theoperation of a data processing system. Software is an intellectual creation that isindependent of the medium on which it is recorded.

Test Plan

A management document which addresses all aspects related to the test. It shouldinclude test scenarios, the test schedule and define any necessary support tools.




Testing

The process of exercising or evaluating a system or system component by manual orautomated means to confirm that it satisfies specified requirements, or to identifydifferences between expected and actual results.

Test Specification

Describes the test criteria and the methods to be used in a specific test to assure theperformance and design specifications have been satisfied. The test specificationidentifies the capabilities or program functions to be tested and identifies the testenvironment. It may include test data to support identified test scenarios.




Appendix B: Stakeholder Analysis




Stakeholder Communication Outcome Communication Tool Fr

INTERNAL STAKEHOLDERS

Executive CommitteeThe Executive Committee monitors theoverall activities of the Department, setscorporate goals and objectives and approves

funding for initiative projects such as LGIS.

Awareness of project progress and status.

Sign off on key issues when required.

On-going support and funding is maintained.

Minutes of SteeringCommittee meetings

Memos on any funding

requests.

Executive Director,Revenue, Gaming andLicensing to answer anyquestions raised.

M

A

A

Corporate Management GroupThe Corporate Management Group (CMG) isresponsible for addressing the business needsand issues of the Department and monitoringprogress of initiative projects, such as theLGIS Project.

Awareness of project progress against agreedmilestones.

Presentations/papers onmajor approvals/stages of project.

A

Project Steering Committee

The LGIS Steering Committee is responsiblefor ensuring the appropriate management of the Project as outlined in the Project Business

Plan.


Ensure project issues and risks areadequately dealt with.

Ensure scope of project is managed.

Sign off on key project documentation.

Briefings and Status

Reports.

Papers on the developmentand review of projectoutputs.

M

A

Project Sponsor (Executive Director, RGLD)The Project Sponsor has the delegatedauthority of the Steering Committee to assistwith project and business management issuesthat arise outside the formal business of the

Steering Committee.


Informed decision making for out-of-sessionapprovals.

Availability of adequate resources.

Effective stakeholder management.

MeetingsEmail

A





Business Owner (Director Liquor and GamingBranch)The Business Owner is responsible forutilising the project outputs to achieve the

agreed project outcomes.

Awareness of progress of the project.

Availability of adequate resources.

Effective stakeholder management

MeetingsEmail

Re

Liquor and Gaming Branch staff The Liquor and Gaming Branch staff will bethe primary users of the LGIS. The successof the project is very much dependent on thestaff accepting and using the new system andbeing satisfied their business requirementshave been met.

All resources for detailed knowledge of operational procedures and issues are locatedin this section.

Commitment of staff to undertake projectwork to a high level and to meet the projecttime frames.

Awareness of project status and benefits.

LGIS meets the business requirements of thebranch.

Sufficient data is collected by LGIS forDepartmental reporting requirements.

Branch internal Bulletinpublication articles

Branch Managementmeetings

Branch meetings.

Business Reference Groupmeetings.

Information /issue papers

M

M

M

A

A

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

Awareness of status of project and progressagainst CMG milestones.

Awareness of any project managementissues and that appropriate projectmethodology is being utilised.

Confirmation that any identified risks areappropriately managed.

Reports against QAmilestones.

Project QA reports to QACmeetings.

Evm

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

Commitment of staff to undertake projectwork to a high level and to meet project timeframes.

Awareness of project status and benefits.Technically compliant specifications.

Business Reference Groupmeetings (ManagerApplication Support to be amember)

ISB management meetings

A

Fo





Availability of adequate resources.One-on-one communicationwith Manager ApplicationSupport and DirectorInformation Systems.

Re

EXTERNAL STAKEHOLDERSTreasury’s Internal AuditorKPMG are currently engaged as Treasury’sinternal auditor. The internal audit focuses onaspects of security, auditing and procedures.

Ensure functional requirements and designof new system conform to auditingstandards.

MeetingsEmail

A

Quality Review ConsultantsQuality review consultants are engaged toreview project outputs or processes.

Ensure methodologies are adhered to andoutputs are technically sound.

MeetingsBriefing papersEmails

Re

Contractors / ConsultantsContractor and consultants will be required todeliver key project outputs.

Ensure outputs delivered meet the requiredquality standards.

Quotation requestsContractsMeetingsEmail

Re

Service TasmaniaService Tasmania provides over the counterservices for the Liquor and Gaming Branch tocollect fees and process applications.

Ensure any changes to procedures orservices required are discussed andaccommodated.

MeetingsBriefing papersEmail

A

Tourism TasmaniaTourism Tasmania receives information onliquor licences for the purpose of marketingvineyards. In particular Tourism need toknow which vineyards have Cellar door salesand when a licence has been approved,transferred or cancelled.

Ensure the data extracted meets informationrequirements.

Ensure the mechanism for receivinginformation is appropriate to the relativeneed for data to be current.

MeetingsEmail

A

Tasmania Police

Tasmania Police are responsible for enforcingthe provisions of the Liquor and

Accommodation Act 1990. They ensure thatoperations are carried out in line withlegislation and the licence and permitconditions pertaining to the establishment.

Information is provided in a format that best

supports liquor licensing enforcement.

Meetings

Email

A

Network gaming Information is provided in a format that Meetings A





Network Gaming is the main gaming operatorin the State and is responsible for ensuringkeno and gaming machines are not operatedoutside the hours of the liquor licence.

minimises the risk of illegal use of gamingand keno machines.

Email

Tasmanian Fire Service

The Tasmanian Fire Service is responsible forensuring that Licensed premises conform tofire safety standards.

Ensure the data extracted meets information

requirements.


Meetings

Email

A

Department of Primary Industry Water andEnvironment (DPIWE)DPIWE is responsible for maintaining theLand Information System Tasmania (LIST)and for producing the Tasmanian TownsStreet Atlas. One of the components of theStreet Atlas and one of the layers on the list isthe community facilities, which includeslicensed premises.



MeetingsEmail

A

Australian Hotels Association (AHA)The AHA is responsible for promoting andprotecting the rights and interests of alicensed hotelier.



MeetingsEmail

A




Appendix C: Risk Analysis







Appendix D: Project Plan




Appendix E: Budget and Expenditure

Liquor and Gaming Information System Project Execution Plan

Documents