Appendix A Tryon and Associates Project Charter Template ... · PDF fileCreated by Tryon and Associates 34 Project Organization A Project Owner is required for each project. This role

Created by Tryon and Associates 31

Appendix A Tryon and Associates Project Charter Template

PROJECT NAME HERE

Project Charter

Date here Version 1.0

Prepared for: Customer’s Name

Customer’s Organization

Prepared by: Author’s Name

Author’s Organization

The Project Charter is a formal agreement between the creators and consumers of project deliverables that establishes the purpose, participants and direction for a project. The Project Charter will be used as the basis for Project Plans and Change Management. It is a living document and will be updated throughout the life of the project. The components of the Project Charter are: Project Overview, Opportunity Statement, Impact Statement, Constraints and Assumptions, Project Scope, Project Objectives, Project Approach and Project Organization. The Project Charter does not include the Project Plan. Plans should be published separately. Copyright Tryon and Associates: www.tryonassoc.com


Project Overview

Place Project Overview text here.

Opportunity Statement

Place Opportunity Statement text here.

Impact Statement

Place Impact Statement text here.

Constraints and Assumptions

Place Constraints and Assumptions text here.

The Project Overview provides a brief summary of the entire Project Charter. It may provide a brief history of the events that led to the project, an explanation of why the project was initiated, a description of project intent and identifies the original Project Owner.

The Opportunity Statement identifies the most significant business reasons for performing a project. This may include a vision for future project deliverables, a list of anticipated features, a list of expected advantages and the identification of the intended customers for project deliverables.

Impact Statement identifies the influence the project may have on the business, operations, schedule, other projects, current technology and other applications

Constraints and Assumptions identify any deliberate or implied limitations or restrictions placed on the project along with any current or future environment the project must accommodate. These factors will influence many project decisions and strategies. The potential impact of each constraint or assumptions should be identified here.


Project Scope

Place Project Scope text here.

Project Objectives

Place Project Objectives text here.

Project Justification

Place Project Justification text here.

Project Approach

Place Project Approach text here.

Project Scope identifies the boundaries for the project. Specific scope components are the business areas or functions to be examined by the project (Domain of Study) and the work that will be performed (Domain of Effort). The Project Scope should identify what is in scope and what is not in scope.

Project Objectives identify measurable criteria that must be satisfied before the project is considered complete.

Project Justifications provide a recap of known cost and benefits from performing the project. These factors may be more fully defined in a Project Cost/Benefit Worksheet. The project financials must be reforecast during the life of the project and should be compared to actuals at the conclusion of the effort. Some of the listed items are tangible (priced) and others intangible (unpriced).

Project Approach identifies the general strategy for completing the project and explains any methods or processes that will be used during the project..


Project Organization

A Project Owner is required for each project. This role must be filled by one or more individuals who are the fiscal trustee for the project to the larger corporate organization. This function considers the global impact of the project and deems it worthy of the required expenditure of money and time. The Project Owner communicates the vision for the effort and certifies the initial Project Charter and Project Plan. Should changes be required, the Project Owner confirms these changes and their influence on the Project Charter and Project Plan. When project decisions cannot be made at the team level, the Project Owner must resolve these issues. The Project Owner must play an active role throughout their project, especially insuring that needed resources have been committed to the project and remain available. The Project Owner for this project is ______________________________. A Project Manager is also required for each project. This person is responsible for initiating, planning, executing and controlling the total project effort. Members of the Project Team report to the Project Manager for project assignments and are accountable to the Project Manager for the completion of their assigned work. The Project Manager for this project is __________________________. A Project Team is assembled for each effort to perform the actual work of the project. This team represents a collection of skills and opinions that are considered significant to the success of the project. Team members are commonly selected from many internal and external organizations. The core Project Team members for this project are...

_______________________________ _______________________________

_______________________________ _______________________________

_______________________________ _______________________________

_______________________________ _______________________________

The Project Organization identifies the roles and responsibilities needed to create a meaningful and responsive structure that enables the project to be successful. This Project Organization must identify the people who will play each assigned role.


Project Charter Acceptance

The signatures affixed below indicate that the undersigned…

• Have read the Project Charter • Have formally voiced any concerns to the Project Manager • Certify that the Project Charter accurately represents their expectations and

conditions required for the project • Are unaware of any conditions that prevent this agreement from being

followed

When a formal confirmation of Project Charter review and validation is needed, a Project Charter Acceptance section should be included. This section should include approval from the Project Owner. It may also include locations for approvals from any corporately designated funding agents and service provider management who are corporately charged with certifying the project.

_________________________________________________ _______________ Project Participant’s Name Date Project Participant’s Role/Title _________________________________________________ _______________ Project Participant’s Name Date Project Participant’s Role/Title _________________________________________________ _______________ Project Participant’s Name Date Project Participant’s Role/Title

36

Appendix B RML Turnaround Time System Project Charter

RML TURNAROUND TIME

SYSTEM

Project Charter 4/10/98

Version 1.2

Prepared for: Regional Medical Laboratory, Inc

Prepared by: Diane Hayes

Infometric Systems Corporation Copyright St John Medical Center

37

Project Overview Regional Medical Laboratory has distributed inpatient turnaround time (TAT) reports to senior management for over 8 years in order to track one aspect of service quality. It has been decided that the system needs to be upgraded and expanded at this time in order to be better positioned to respond to RML business needs. Turnaround time is defined as the time elapsed from the arrival of the specimen at any measurable point into the RML system to the time when the final test result is available to the physician or his staff. The project is intended to provide a turnaround time system that can be used by senior management at all RML facilities, laboratories, drawing sites, and sections to track the time it takes from test request or specimen collection to result verification or distribution, as appropriate. Such tracking will include both inpatient and outreach specimens from all entities. The Project Owners are Dr. Dolan and Mary Hydrick.

Opportunity Statement An effective turnaround time system will provide a means of measuring laboratory response time to a test request. The TAT results provided by such a system will be used by senior management to determine how often RML is effectively meeting a specified target TAT. Measurements will be taken at all measurable points in a specimen’s life cycle and the TAT calculated. This information at specific points in the process will allow senior management to identify where response time is consistent and adequate, determine where possible bottlenecks are occurring, determine if the target TAT is satisfactory, and provide information for basing process improvement decisions.

Impact Statement Providing detailed information on all measurable phases of response to a clinical lab test request will enhance RML’s ability to directly measure the outcome of current operational and technical procedures. Based on results displayed via the TAT system, changes may occur in specimen transport, test ordering, specimen processing, clinical testing, staffing, instrumentation, test schedules, result distribution, and client communication in order to optimize turnaround time and improve service to the client and patient. Additionally, this information may be provided to clients as necessary, directly affecting their perception of laboratory service.

38

Constraints and Assumptions Assumptions: The target audience is RML senior management. All users will have a PC available to access the system. Users are familiar with terminology used in the system: reporting and ordering

priorities, section names, drawing sites, locations, facilities in the RML system. Viewing data via the CRT is the distribution medium of choice. A system can be developed to easily accommodate user maintenance and support via

table entries and deletions. User maintenance and support will be accommodated in an efficient and timely

manner. (This responsibility may be most efficient if formally assigned.) System access privileges assigned at the data base level will adequately provide

system security. The completed time (group level) rather than verified time (detail level) will be used

to calculate TAT for group tests. Constraints: Weekends and holidays are handled the same as weekdays for general laboratory

TAT calculations. Process parameter dates and times used for calculations (order / request / drawn /

logged / verified) will be limited to those defined and residing on the Cerner PathNet system.

Fax time used for calculation will be limited to that information that can be obtained from the RightFAX system.

TAT target values used for comparisons will be limited to those defined and residing on the PathNet system. Target times are entered for a particular test name and workcenter/testing site.

Items/questions needing further consideration, answers and/or resolution: A satisfactory means of calculating TAT has not been devised for handling tests

added-on to a previous accession number later in the process. Does downtime have to be registered on the PathNet system to accommodate a range

of data exclusions, or can date and times of exclusions be entered from outside the PathNet system for reasons other than actual system downtime?

Is it possible to omit stat test results that have been footnoted from the TAT report?

39

Project Scope & Objectives • Provide a standard user interface to allow senior management to gain access to all

information necessary to investigate turnaround time results while eliminating the need to understand specific application commands.

• Support up to 25 concurrent users. • Develop as year 2000 compliant. • Minimize programmer need to support/maintain/update; give users control of

additions and deletions to the system wherever possible. • Provide user control of the following parameters for viewing at the time of inquiry:

- View definition: by testing location, by ordering location, by client - Date range - Time/shift/hour range - Collection and/or ordering priorities to be viewed - Tests to be included and/or excluded - View all report results, whether or not target is met 90% of time - Exception report only for tests not meeting target 90% of time - Sort order

• Allow user to customize and save personal views for subsequent use. • Accommodate view of the following parameters: percent meeting 90% target, the

90% value, and the volume of tests. • Accommodate view of last 3 months, with 6 month and 12 month comparisons. • Accommodate periods of data exclusion from the system to account for occurrences

that adversely affect turnaround time such as computer downtime. • Allow user to view the dates, times, and reasons for any data exclusion periods. • Accommodate TAT reporting for sections with special needs as previously

developed: - Anatomic Pathology – accommodate weekends and holidays in

calculations - Referred – tracks 6 months; flags tests with average # days > expected +

24 hrs - Microbiology - Drug Screens

40

• On-demand capability to group data as follows:

By RML Testing Location RML Tulsa

• By technical section number - 010 – Hematology - 020 – Chemistry - 026 – Toxicology - ….etc

• By workcenter/testing site - 100/100 – Stat Lab - 110/250 – Stat Lab Gases - 160/410 – Therapeutic Drugs - ….etc

• By individual test name

RML Bartlesville

• By workcenter/testing site • By individual test name

RML Sapulpa • By workcenter/testing site • By individual test name

RML Stillwater

• By workcenter/testing site • By individual test name

RML Drawing Sites • By workcenter/testing site • By individual test name

41

By Ordering Location Hospital nursing unit/service

• SJMC – (0000) • JPMC – (0640) • BMMC – (0412)

RML Drawing Site RML Client Site

By Client

Project Approach Expected steps include: Define system requirements via user meetings. Agree on Project Charter, giving particular attention to the area of project scope and

objectives. Begin systems analysis. Review results of systems analysis with project team. Perform system prototyping. Review prototype with project team. Agree on modifications to be made with Project Owners. Continue system development. Test system with project team as appropriate. Develop modifications within scope based on test results. Continue cycle of prototyping and testing until complete. Review system with Project Team. Agree with Project Owners that deliverables fulfill objectives and requirements. System training and roll-out.

42

Project Organization Dr. C. T. Dolan – Project Owner Mary Hydrick – Project Owner Cheryl More – Project User Liaison Diane Hayes – ISC Project Manager Charles Rowden – ISC Deliverables Manager Steve Rowden – ISC Chief Systems Engineer Debbie Shackleford – ISC Systems Analyst

Project Charter Acceptance The signatures affixed below indicate that the undersigned…

• Have read the Project Charter • Have formally voiced any concerns to the Project Manager • Certify that the Project Charter accurately represents their expectations and

conditions required for the project • Are unaware of any conditions that prevent this agreement from being

followed

_________________________________________________ _______________ Dr. C. T. Dolan, RML President Date Project Owner _________________________________________________ _______________ Mary Hydrick, RML Vice-President Date Project Owner _________________________________________________ _______________ Cheryl More, RML Director Date Project User Liaison

PROJECT CHARTER

WHOLE OF GOVERNMENT INTRANET

Version 1.3 Project Manager: Greg Holden January 1998 Project Sponsor: Peter Fowler

- i -

Confidentiality

This document has been distributed within the South Australian Public Service as an internal document. It is to be considered as commercial in confidence and must not be used for any purpose other than for planning purposes within the South Australian Government. Information in this document is subject to change without notice. No part of this document may be quoted, reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Information Industries SA

- ii -

Purpose of this Document

The Project Charter document is an integral component of the approval and conduct of the project. It consists of all of the information relevant to planning of the project. The Project Charter is a formal agreement between the Project Manager, Project Sponsor and Stakeholders regarding the project:

• Scope • Conduct • Deliverables

As such is an expression of the “common vision” and expectations of the project. It also requires the endorsement of the Strategic Planning and Policy branch to ensure that the project scope is in accordance with and delivers the functions identified within the Business Opportunity assessment. In effect it represents a ‘contract’ between the Project Manager and the Project Sponsor, and between the Project Sponsor and the General Manager, Strategic Planning and Policy. The Project Charter is a dynamic document. It represents the product of the planning process at the commencement of the project. The figures and plans presented at the commencement of the project will be subject to revision during the conduct of the project, as circumstances change and further experience is gained. The Project Charter provides the basis for all change control. When changes are required to the scope and operational guidelines of the project, they must be formally agreed and incorporated into the revised Project Charter. At all times this document should accurately reflect the common agreement of project scope, conduct and deliverables.

Intended Audience

All stakeholders and agency staff involved in the development and agreement of the scope, conduct and deliverables of the project.

- iii -

Distribution Matrix

Services SA: Anne-Marie Bishop

OCPE: Anton Lugna Karen Morley

SAHC: Chris Miller Don Richards Greg Hodgson Zoran Lustica

DTF: Frank McGuiness

TSA: Frank Nicholas Miro Dabek

DETAFE: Jenny Hondow

SA Water: Keetza Lambert

DECS: Kevin Richardson

DPC: Margie Caust Tony Nelson Robert Debelle

DENR: Peter Croft

DIT: Peter Murchland

MFPDC: Tom Gordon

ETSA: Robert Spencer-Kerr (ETSA)

DAIS: Peter Fowler Alan Cunningham Greg Holden (previously DITS) Daryl Keen Brett Morris Sponsor Sign off: Approved: Peter Fowler Program Director access.sa (DAIS)

- iv -

TABLE OF CONTENTS

1.0 Background ..................................................................................................1 2.0 Objectives ....................................................................................................1 3.0 Strategic Issues............................................................................................2 4.0 Technology Issues .......................................................................................2 5.0 Legislation/Policy Issues ..............................................................................3 6.0 Workforce Impact .........................................................................................3 7.0 Project Scope...............................................................................................4

7.1 In Scope....................................................................................................4 7.2 Related Projects........................................................................................4 7.3 Boundary Issues .......................................................................................5 7.4 Dependant Projects ..................................................................................5 7.5 Constraints................................................................................................5 7.6 Project Scope Exclusions..........................................................................5

8.0 Project Strategy...........................................................................................6 9.0 Strategic Project Risk Assessment...............................................................7

9.1 Risk Assessment ......................................................................................7 9.2 Risk Reduction Strategies.........................................................................8

9.2.1 Pilot Implementation ...........................................................................8 9.2.2 User Training ......................................................................................8 9.2.3 Documented Policies, Procedures and Standards..............................9

10.0 Project Deliverables ...................................................................................9 11.0 Project Staffing.........................................................................................10 12.0 Project Plan..............................................................................................10

12.1 Minimum Deliverables...........................................................................10 12.2 Project Schedule...................................................................................10

13.0 Project Returns ........................................................................................11 14.0 Project Benefits Realisation Plan .............................................................12 15.0 Project Costs............................................................................................13 16.0 Project Agreements..................................................................................14 17.0 Sponsor....................................................................................................14 18.0 Stakeholders ............................................................................................14 19.0 Project Change Control Procedures.........................................................14

Project Charter: Whole of Government Intranet

Version 1.3 January 1998 Page 1

1.0 BACKGROUND

One of the primary objectives of access.sa is “to improve existing services and develop new services to the community by providing information technology reform, leadership, regulation and services to the public sector”.

This project is the first in a number of projects in a program focussing on the transformation of administrative processes by encouraging the move from a culture based on paper to a culture which places an increasing emphasis on the electronic desktop and the electronic availability of information.

A number of agencies have progressed with intra-agency Intranets and access.sa, with the objective of improving existing government services, through this project will provide the leadership to coordinate the rapid implementation of a SA Government Intranet.

2.0 OBJECTIVES

The overriding objective of this project is to provide the mechanism whereby all government employees will increasing look to their electronic desktop to store, retrieve and communicate information. It is an objective which will add to the momentum of a significant cultural change in the workplace.

As its contribution to the attainment of this objective, this project will provide the infrastructure to share information at a Whole of Government level. This infrastructure will be based on internet/world wide web style technology.

Three levels of information sharing have been identified: 1. agency specific information disseminated within individual agencies such

as policies and procedures; day-to-day operational and housekeeping matters unique to each agency;

2. whole-of-government information such as Central Agency circulars, policies and instructions; agency organisational charts; OCPE notice of vacancies;

3. government information available in the public domain such as Ministerial media releases and speeches; annual reports; legislation; Hansard; agency mission statements, objectives and contact points.

This project will provide the mechanism for the dissemination of the middle level of information only, fund the initial implementation of information, encourage additional implementations of data and applications from all agencies and campaign to heighten awareness of this alternative to the paper flow.

In addition to the installation of infrastructure, this project will also embark on an awareness and education campaign to ensure a high level of acceptance of this medium for accessing and sharing information.



3.0 STRATEGIC ISSUES

Sharing data electronically assumes some level of network connectivity, and for the SA Government Intranet, connectivity will be via StateNet - the government wide area network. Unfortunately at this time, not all agencies, and not all agency locations, are connected to or have access to StateNet. The reasons for non-connection can be the lack of a cost justification, the absence of a business need or an agency location outside StateNet’s coverage, generally remote areas.

Until there is universal agency connectivity to StateNet, the benefits which will flow from this project could be constrained. This project in itself will provide the justification for some agencies to connect, while others will remain isolated until StateNet provides coverage throughout the entire state.

Efficiency of operation within agencies will increasingly depend on an efficient and effective communications network. More and more inter- and intra-agency projects will demand connection to such a network.

4.0 TECHNOLOGY ISSUES

Various alternative models and implementations for sharing whole of government information have been investigated. The choice of a world wide web style implementation is based on industry trends in information sharing as well as its cost effectiveness, simplicity of management and ease of use.

This project will be implementing tried and proven technology. Many agencies already have operational intranets. As such the technology risk is minimal.

Existing hardware and software will be used during the pilot, allowing a careful assessment of future requirements. This will minimise the financial risk of over- or under-investment in infrastructure.

As with all internet development, it is important to recognise that not all browsers are functionally compatible. In particular, significant advances have been made in the features offered to web-developers and web-browses in the latest generation of browsers which cannot be recognised by earlier generation browsers. With the development to be undertaken for this project, a decision will be made on the base level of functionality which can be used in web-pages. In order to access the information provided by the SA Government Intranet, users will have to ensure that their browsers support the basic level of functionality agreed upon, or else upgrade to a suitable browser release level.



5.0 LEGISLATION/POLICY ISSUES

This project is not the subject of any specific enabling legislation.

However, the information stored on the SA Government Intranet, as a result of this specific project, will be subject to the laws of publication, freedom of information, confidentiality, privacy and copyright, to which both authors and readers must be aware.

Future projects within this program may be governed by legislation or policy in relation to the provision of specific services utilising the installed infrastructure, and will be addressed on a case by case basis.

6.0 WORKFORCE IMPACT

The key outcome from this project is to provide essential government information in a readily accessible desktop format. It is intended to enhance productivity and make information more available rather than change the nature of an individual’s job and work practice.

The cultural evolution from a paper-based workplace to an electronic desktop workplace will generally involve a change in the skill set of most government employees. A greater PC literacy, with a particular emphasis on web-browsing tools and concepts, will become a fundamental workplace requirement. This will become more apparent as further applications and services are added to the Whole of Government intranet, being the outcome of future sub-projects within this program.

Some existing methods of dissemination of information will change, which will change the work of some employees. It is possible that a higher skill set may be needed for the staff in those agencies responsible for maintaining information on the intranet. However, it will be the responsibility of those agencies to address those staff issues and job changes.



7.0 PROJECT SCOPE

7.1 In Scope The scope of this project is to provide a Whole of Government Intranet for the primary purpose of sharing information. To achieve this the project must provide:

• the infrastructure to support the SA Government Intranet using web-based technology, namely suitable “intranet” servers to support the expected data storage requirements and usage demands;

• access to the SA Government Intranet for all government agencies via the SA government’s wide area network (StateNet);

• general acceptance of the concept of a whole of government intranet and widespread use of the facility across the SA government agencies generated by a marketing campaign to “sell” the concept and ensure awareness of its availability;

• a management plan for the ongoing support of the service beyond the life of this project, and the actual handover to the body ultimately chosen to provide that support;

• funding for the nominated initial source of shared information and guidance to other agencies contributing information for the pilot;

• appropriate standards and guidelines for storing, managing and accessing shared data on the SA Government Intranet;

• encouragement to agencies to search out and implement additional applications and information sharing on the intranet.

A pilot period will be used to assess the hardware and network capacity requirements and the suitability of concept and information presentation styles.

7.2 Related Projects There are no other projects which will impact this project. However, this project will remain cognisant of other projects in the internet domain, specifically Internet Publishing and Services, to ensure that evolving Government standards and guidelines are consistent and complied with where applicable.

The Whole of Government Wide Area Network (WAN) project will have flow on benefits to this project by expanding the user-base which can access the intranet. However, its project schedule will not impact the schedule of this project.



7.3 Boundary Issues This project will have no impact on existing or planned agency intranets. The information presentation standards and guidelines developed for the WofG Intranet will not impact existing or new agency intranets, but will be made available for all agencies to use, or adapt, for their own agency-specific intranets where appropriate.

7.4 Dependant Projects There are no other projects, at this time, which have timing or resource dependencies based on this project, but there are other projects dependent on the deliverables of this project.

Several other projects have already commenced, or are in the early stages of assessment, which will assume the availability of an operational whole of government intranet. These projects are:

• Parliamentary IT

• Electronic Commerce for Procurement

• Strategic Asset Management

• Office Accommodation

• Masterpiece/Net

Each of these projects will use the whole of government intranet to deliver their services to all agencies. Their success is dependent upon the success of this project.

7.5 Constraints There are no constraints which will impact the progress of this project.

7.6 Project Scope Exclusions This project will provide the intranet infrastructure only. It will not provide desktop browsers to enable access to the intranet. Provision of browsers will be the responsibility of individual agencies. Because Microsoft Internet Explorer is free, this policy will have no budgetary impact for agencies.

Connections to StateNet in order to gain access to the SA Government Intranet will also be the responsibility of individual agencies.



Information-originating agencies will retain ownership of their information available on the SA Government Intranet and will at all times remain responsible for the management and the maintenance of that information in accordance with the defined standards and guidelines. The project team and subsequently the support team will not be responsible for the accuracy or timeliness of the information.

8.0 PROJECT STRATEGY

The project will be undertaken in two stages; a pilot implementation followed by a full implementation.

The pilot implementation will enable a rapid deployment of the facility, without bells and whistles, as “proof of concept”. The Central Agencies will provide their circulars, policies and instructions as the first example of shared information and a number of (yet to be determined) agencies will be asked to participate in the pilot.

The pilot will use the existing DITS Online intranet server, at no cost to the project, courtesy of Network Services. This server is already configured to support a whole-of-government intranet with all of the necessary security and monitoring tools.

During the pilot period, system usage will be monitored and feedback will be sought from all staff in the participating agencies to assess their acceptance of the concept. This period will also be used to develop information guidelines and presentation standards, in consultation with the participating agencies; consult with agencies on additional applications and information sources which could be made available; assess the hardware requirements necessary for the full implementation; and undertake an Intranet awareness campaign across all agencies.

Following the pilot period, feedback will be analysed, remedial action (where necessary) will be taken and the appropriate hardware will be installed to support the full implementation. Also, the business case/cost benefit analysis will be reviewed and resubmitted before final approval is sought to proceed with the full implementation.



9.0 STRATEGIC PROJECT RISK ASSESSMENT

9.1 Risk Assessment RISK CATEGORY/DESCRIPTION INHERENT RISK ASSESSED RISK

L C TOT L C TOT

TECHNICAL RISK Infrastructure risk: infrastructure will be insufficient to develop a

whole of government intranet 3 4 7 2 2 4

Obsolescence due to new technology: new technology may make the use of an intranet obsolete

3 2 5 2 2 4

System Downtime: the intranet system may not be accessible for long periods of time which will deter people from using it

4 4 8 2 2 4

Up to date information: the information available on the intranet will be irrelevant, late or out of date

4 4 8 3 3 6

Capacity: the capacity of the infrastructure will not deliver an acceptable level of performance to the end-users

3 2 5 3 2 5

Access: inadequate access to desktop facilities or network connections will limit the number of people/agencies using the intranet

3 4 7 2 3 5

PROJECT MANAGEMENT RISK Project risk: factors which may impinge on the management of

the project resulting in time delay or budget overrun 3 2 5 3 2 5

PROJECT OUTCOMES RISK Project outcomes: the project fails to deliver its expected

objectives and proposed benefits 3 4 7 3 2 5

POLITICAL RISK Political risk: legislative or government strategy changes which

may influence other sources of risk 2 2 4 2 2 4

MANAGEMENT RISK Executive Management Support: a lack of management support

to maximise opportunities 3 4 7 2 2 4

OPERATIONS RISK Acceptance of technology: the technology will not be accepted

and therefore will not be used 2 5 7 2 3 5

‘Take up’ by agencies: inadequate ‘take up’ by agencies resulting in benefits not being maximised or even achieved

3 4 7 2 2 4

Ownership/Security of Information 2 2 4 2 2 4 Version control 3 3 6 1 1 2 Viruses: increased exposure to viruses transmitted via the

intranet to all users 3 5 8 1 3 4

FINANCIAL RISK Achievement of cost savings: expected savings will not be

achieved 3 4 7 2 2 4

Intellectual property: claims arising from the improper management of intellectual property

2 4 6 2 2 4

COMMERCIAL RISK Legal risk: possibility for legal challenges based on information

which has been published on the intranet 2 4 6 2 2 4

Likelihood Consequence

1 Rare Insignificant 2 Unlikely Minor 3 Moderate Moderate 4 Likely Major 5 Almost Certain Catastrophic



9.2 Risk Reduction Strategies The three key strategies to be employed in the management and reduction of project risks will be:

• pilot implementation, • user training, • documented policies, procedures and standards.

A detailed explanation of each strategy follows.

9.2.1 Pilot Implementation The project will be implemented as a limited-content pilot initially. This procedure offers the following opportunities:

• “Proof of concept” before embarking on more ambitious feature and function rich implementation. The pilot will highlight any technical or operational hurdles to a WofG Intranet, the consequences of which can be contained within the scope of the pilot. Remedial action can be taken as part of the pilot thereby managing the risk in the bigger picture.

• Measurement of the infrastructure’s capacity and performance under a reduced workload and in a non-critical situation. This will enable more a accurate estimation of infrastructure growth requirements.

• Monitoring the level of usage and user acceptance of the concept. This is vital to ensure that the objectives and long term benefits of the project are achieved. User feedback will be sought to gauge the level of acceptance and corrective action taken where applicable.

• Detailed project planning and the monitoring of progress will be carried out to track costs and performance against budget and timetable.

• A marketing and awareness campaign to ensure all participants are kept abreast of the project’s progress and their responsibilities. This campaign will employ a variety of means to communicate its message.

9.2.2 User Training

User training will be an essential aspect to achieving the highest level of user acceptance of the concept, as well as ongoing executive management support for the project. Training will be viewed on two planes:

1. the end-users accessing information on the intranet, and 2. the “backroom” users who create and manage the information.

User training in the basic intranet access tool, the web browser, will be the responsibility of the agencies using the system and will be monitored by the project team to ensure a suitable standard of training is available. Guidelines and assistance will be provided by the project team.



Training in the use of the tools to present and manage the information will be the responsibility of the project team for the purpose of the pilot. The ongoing provision of this training will be addressed as a task during pilot. Guidelines and assistance will be provided by the project team.

9.2.3 Documented Policies, Procedures and Standards The ongoing success of the project will rely heavily on the availability of suitable documentation detailing best practices for using and managing the system. The pilot will provide the opportunity to prove this documentation in a live, but contained, situation and refine it as required.

The documentation will address the key topics of content and visual standards as well as the procedural and management practices of information ownership, responsibility for accuracy, currency and integrity of information and the security issues of who can store information on the intranet and who can change it once it is there.

10.0 PROJECT DELIVERABLES

The project will deliver:

• an operational SA Government Intranet, providing access, in the first instance, to Central Agency circulars, policies and instructions. Subsequent to the initial pilot, further information and services will be added as new initiatives are identified and implemented;

• an increased awareness and confidence amongst agency staff in the use of browsers as a fundamental desktop tool for accessing intra-agency information and services - a key element in the transformation process;

• a basic level of competency for document authors and publishers in the use of intranet publishing tools;

• a document outlining information presentation standards and guidelines will be available for all agencies contributing to the SA Government Intranet;

• an ongoing management plan for the infrastructure, and its day-to-day operation will be developed;

• a list of potential applications which could use the SA Government Intranet as the medium through which they can deliver their service across the whole of government.



11.0 PROJECT STAFFING

Staffing requirements for the project must be considered separately for the two phases:

• during the Pilot phase of the project, the project team will consist of the project manager plus two team members. One of the team members will require some skills in web page development; the other will play a more administrative role, documenting standards, assisting users and monitoring and analysing feedback during the pilot.

• the makeup of the on-going support team, post-pilot, will be the subject of the ongoing management plan to be prepared during the pilot.

12.0 PROJECT PLAN

12.1 Minimum Deliverables The pilot will be considered a success if the identified shared information can be accessed by the staff of the agencies participating in the pilot. The nominated information must reside on both the central intranet server, and a number of different agency-specific intranet servers. The Central Agency documents will reside on the central server, and other agency-resident information will be identified and made available.

The overall project will be considered a success if staff can readily access shared information in a timely and efficient manner.

12.2 Project Schedule On the assumption that approval to proceed is granted, preparation for the pilot should commence in February, the pilot operational by March and a full implementation completed by the first week of June.

Jan Feb Mar Apr May Jun

Pilot PreparationPilot

Implementation PreparationFull Implementation



A detailed project plan will be maintained by the project manager and distributed on a regular basis to the stakeholders.

13.0 PROJECT RETURNS

The benefits flowing from the successful installation of the actual infrastructure are largely intangible. But there are clearly tangible and quantifiable benefits flowing from each application implemented using the infrastructure.

The installation of a whole of government intranet will provide the infrastructure for a more cohesive, information-sharing environment - conducive with the objectives of the State’s IT2000 Vision.

The pilot intranet application, the Central Agency circulars, instructions and guidelines, will significantly reduce the costs of printing, publishing and distribution of these documents. These costs are currently in the range of $5M to $10M per annum across the whole of government1. If an effective marketing campaign can achieve a high level of user acceptance of the intranet-based electronic alternatives to the paper-based documents, annual cost savings of less than 10% will justify the entire infrastructure. This is a very conservative cost reduction, but is considered realistic initially, until universal government access to the intranet can be achieved.

On the basis of this return alone, the entire project can be justified. Subsequent applications implemented on the infrastructure installed with this project will reap their returns with minimal if any infrastructure costs.

The full business case for the project, prepared by the Commercial Management Group, is presented as a separate paper.

1 Refer Arthur Andersen’s Feasibility Report for a Whole of Government Intranet, September 1997, Section 7 - Business Case for a Whole of Government Intranet



14.0 PROJECT BENEFITS REALISATION PLAN

The benefits to be realised from this project will flow from the reduction in printing and distribution costs. These costs are essentially spread throughout all agencies where the mass copying and distribution of circulars occurs.

The benefits will be realised through an effective marketing campaign to change the paper culture within government. Electronic access to documents will eliminate the need for paper copies. Staff must be convinced that an electronic copy can be readily located, is current and is the quickest and most effective means of distribution.



15.0 PROJECT COSTS

The following project costs are a direct extract from the Arthur Andersen Feasibility Report for a Whole of Government Intranet (Minor discrepancies in the total fields due presumably to rounding have not been corrected). The project budget has been based on these figures, so it is appropriate to use them at this time.

The full business case for the project, prepared by the Commercial Management Group, is presented as a separate paper.

Year 1 Year 2 Year 3 Year 4 Year 5

$,000 Low High Low High Low High Low High Low High

PILOT

Server Setup 3 5

Web Development 5 10

Software 1 3

SETUP

Server Setup 3 5 0 5 3 5 0 5

Software 10 30

WEB DEVELOPMENT

Design 10 30

Index 10 10

WofGI Search Engine 30 50

Govt Yellow Pages 40 70

CONSULTING

Standards and Guidelines 40 60

Setup of WofGI 30 50

Setup of IMU 30 50

Project Management 50 100 25 50 25 50

ONGOING

Marketing 5 10 5 10 5 10 5 10 5 10

Training Coordination 10 15 5 10 5 10 5 10 5 10

Server Rental 15 20 15 40 30 60 30 80 30 80

Software Maintenance (15%) 2 5 2 5 2 5 2 5 2 5

Project Administration 80 100 80 150 80 150 80 150 80 150

Project Management 60 70 70 80 75 85 85 90 95 100

TOTAL 395 620 242 420 225 375 205 350 215 355



16.0 PROJECT AGREEMENTS

Nil - currently

17.0 SPONSOR

The Program Director sponsoring this project is Peter Fowler.

18.0 STAKEHOLDERS

The stakeholders for this project can be divided into two categories; those providing the service and those using the service.

The stakeholders providing the services are:

• The Central Agencies being Department of Premier and Cabinet, Treasury and Finance, Office for the Commissioner of Public Employment and State Supply.

• Quoin Technology who have been engaged by the Central Agencies to review identify the opportunities to improve the useability of the documentation developed and distributed by those agencies.

Margie Caust (Premier and Cabinet) is coordinating the work from the Central Agencies.

The stakeholders using the service will be all other SA government agencies. These stakeholders will benefit from the cost savings to be achieved through the reduction of printing within their agencies. For the purpose of the pilot, selected agencies will be asked to contribute feedback to the process but no restrictions will be placed on other agencies accessing the information.

19.0 PROJECT CHANGE CONTROL PROCEDURES

A change to the Project Charter will require the approval of the Project Sponsor.

Documents

Appendix A Tryon and Associates Project Charter Template ... · PDF fileCreated by Tryon and Associates 34 Project Organization A Project Owner is required for each project. This role