Planning and Approving Projects BPG

Planning and Approving Projects an Executive Perspective
SettinG the foundation for reSultS
Better Practice Guide
June 2010
ISBN No. 0 642 81123 7 Commonwealth of Australia 2010 COPYRIGHT INFORMATION This work is copyright. Apart from any use as permitted under the Copyright Act 1968, no part may be reproduced by any process without prior written permission from the Commonwealth. Requests and inquiries concerning reproduction and rights should be addressed to the Commonwealth Copyright Administration, Attorney Generals Department, 3-5 National Circuit, Barton ACT 2600 http://www.ag.gov.au/cca. Questions or comments on the Guide may be referred to the ANAO at the address below. The Publications Manager Australian National Audit Office GPO Box 707 Canberra ACT 2601 Email: webmaster@anao.gov.au Website: http://www.anao.gov.au
Foreword
The successful delivery of government programs requires the projects that underpin their implementation to be well-managed from the point of inception through to full implementation.
This Guide focuses on the key issues that will assist senior executives in the planning and approval of such projects. The increasing expectation by governments and the community that the public sector will provide services in a more integrated and efficient manner means that the success of program delivery and business projects will continue to be a high priority for many senior executives. For such projects to be successful, public sector entities1 need to ensure that: individual project objectives are aligned with the goals of government and the entity; good governance arrangements are in place; the right people are assigned to oversee and approve projects; and there is compliance with legislative and government requirements.
Senior executives responsible for the approval or oversight of projects have a pivotal role in ensuring that: individual project objectives and service delivery strategies reflect the requirements of key stakeholders, including Ministers; expected project benefits are realistic and achievable and are based on fully tested assumptions; project risks are identified and managed appropriately; and arrangements are in place for the effective oversight of each projects implementation, and subsequent evaluation.
Senior executives are also increasingly required to look beyond entity boundaries for opportunities to partner with, and take advantage of, developments occurring in other entities and jurisdictions, as well as the private sector. Proposed project solutions are also expected to support governments commitment to better meeting the needs and expectations of citizens. This Guide has been prepared as a reference document to assist those senior executives who are responsible for the planning, approval and subsequent implementation of projects. The Guide is also likely to assist those staff who are involved in supporting senior executives to meet these responsibilities. The Guide provides insights and better practices that are supplemented by check lists and examples that we encourage senior executives to use when they oversight projects that are underpinned by a significant ICT component. The Guide has benefited from input and feedback from a range of entities and individuals and I wish to thank all those involved for their contribution.
Ian McPhee Auditor-General June 2010
1 In this Guide, the term entities applies to all organisations subject to the Financial Management and Accountability Act 1997 (FMA Act) and the Commonwealth Authorities and Companies Act 1997 (CAC Act).
SECTION
ii
Planning and Approving Projects Better Practice Guide
Table of contents
FOREWORD INTRODUCTION 1: PUTTING PROJECTS IN CONTEXT 1.1 THE IMPORTANCE OF PROJECTS IN DELIVERING GOVERNMENT PROGRAMS 1.2 THE PROJECT LIFECYCLE 1.3 ARRANGEMENTS SHOULD BE FIT FOR PURPOSE 2: ENTITY ARRANGEMENTS 2.1 PROMOTING STRATEGIC ALIGNMENT 2.2 HAVING THE RIGHT PEOPLE AND CULTURE 2.3 HAVING EFFECTIVE GOVERNANCE ARRANGEMENTS 2.4 ADDRESSING COMMON APS REQUIREMENTS KEY BETTER PRACTICE SUMMARY 3: INDIVIDUAL PROJECT PROPOSALS 3.1 CLARIFYING THE CONCEPT 3.2 ENSURING FEASIBILITY: THE BUSINESS CASE 3.3 APPROVING THE PROJECT KEY BETTER PRACTICE SUMMARY 4: OVERVIEW OF PROJECT IMPLEMENTATION 4.1 PROJECT SPONSORS ROLE DURING IMPLEMENTATION 4.2 TYPICAL PROJECT IMPLEMENTATION PHASES 4.3 CONCLUDING REMARKS APPENDICES A GLOSSARY, ACRONYMS AND ABBREVIATIONS B RELATED GOVERNMENT POLICIES C SAMPLE PROJECT CONCEPT D CATEGORIES AND EXAMPLES OF REQUIREMENTS E SAMPLE KEY CONTROLS FOR PROJECT APPROVAL F QUESTIONS FOR EXECUTIVE REVIEW OF PROJECT PROPOSALS G TYPES OF TESTING H ADDITIONAL SOURCES OF INFORMATION INDEX i iv 1 3 4 8 9 11 17 23 38 41 43 45 54 78 82 87 88 90 98 99 99 102 104 106 107 110 114 115 117
SECTION
iii
Introduction
The focus of this Guide
this Guide provides an executive perspective of the planning and approval stage of projects for australian Government entities. the Guide focuses on the most common types of projects those aimed at program delivery, and on internal business operations. as these projects often involve an information Communications and technology (iCt) component, the Guide includes information and examples of issues that arise when iCt is a substantive part of a project. the Guide focuses on issues of interest to senior executives in the public sector and complements the detailed advice available on project planning generally. the Guide provides advice on planning projects. there are additional considerations for the effective planning of programs of projects.2
There are a number of APS processes relevant to project planning, such as: the annual Budget process, where entities may seek funding for projects; the ICT Investment Framework; the ICT Two Pass Review process which applies to large or risky ICT-enabled projects; arrangements for agencies to assess their organisational capability, including their capability for project management; monitoring and reporting arrangements of the Cabinet Implementation Unit; and the Gateway Review process which applies to complex projects that meet certain financial and risk thresholds, and provides independent assurance to entities on projects from conception through to implementation.
The Guide aims to provide practical advice to assist executives to improve the quality of project proposals which may be subject to these APS processes, but does not go into detail on the processes themselves. References for these processes are provided in Appendix B Related government policies, at page 102. The Guide focuses on broader issues for executive attention in typical APS projects, including during development of the project concept and business case. The Guide does not cover in detail every element of a business case. This information is available in publications such as Finances ICT business case guide. The Guide also does not cover the special issues associated with very large projects, or projects focused on capital works, or specialised categories such as military acquisition projects.
2 The distinction between projects and programs of projects is discussed at page 33.
iv
The structure of this Guide
1: Putting projects in context:

Discusses the importance and challenges of projects; the role of executives in project planning and approval; and typical elements of the project lifecycle.
2: Entity arrangements:
Describes better practices in the overall arrangements of an entity for the planning and approval of projects. These include aspects of strategic planning, people and culture, and governance.
4: Overview of project implementation:

Provides an overview of implementation issues for projects.
3: Individual project proposals:

Describes better practices for senior executives in the planning and approval of individual projects, including clarifying the project concept, preparing a business case and project approval.
Appendices:
Explains the specialist words and phrases used in this guide, and provides additional detailed examples and references.
Checklists and review questions

Entity arrangements checklist: Individual project proposals checklist: Individual project review questions: Page 41 Page 82 Page 110
SECTION
vi
this chapter discusses: the importance of projects; the role of executives in project planning and approval; and typical elements in the project lifecycle.
Contents:
the importance of projectsCONTEXT PUTTING PROJECTS IN
1.1 The importance of projects in delivering government programs (page 3) 1.2 The project lifecycle (page 4) 1.3 Arrangements should be fit for purpose (page 8)
executives in project planning and approval
project lifecycle
viii
Planning and Approving Projects Better Practice Guide back of chapter 1 divider
1: Putting projects in context

Continued improvements are expected in APS program delivery and internal efficiency. These improvements are frequently achieved through projects in many cases with a component of ICT.
Executives have important roles in: creating a supportive environment in an entity for planning projects; developing and sponsoring projects; and assessing and approving projects.
The involvement of executives in project planning is particularly important due to the management challenges in successfully completing projects, particularly those of the complexity which often applies in the public sector. This Guide aims to assist executives to meet their responsibilities for project planning and approval. This chapter sets out project concepts and terminology used throughout the Guide.
PROJECTS IN CONTEXT
SECTION
1
1
The increasing expectation by governments and the community that the public sector will provide services in a more integrated and efficient manner means that the success of program delivery and business projects will continue to be a high priority for many senior executives.
Ian McPhee, Auditor-General, from the Foreword.
Planning and Approving Projects Better Practice Guide | Chapter 1
1.1 The importance of projects in delivering government programs

The Parliament, government, and the public expect continued improvements in the public sector, including in aspects such as:
improving the ease of access for Australians to government services and programs, which often involves working across organisational boundaries; increasing the focus on realising a broad vision or achieving specified outcomes and benefits, rather than simply administering programs; increasing the speed and reliability of new policy implementation; reducing the regulatory burden on business, by simplifying and harmonising requirements across entities and jurisdictions; and improving the quality of, and reducing the cost of, public sector operations.
In addition, global competition in the supply of goods and services necessitates continued improvement in the efficiency of the Australian economy, including the public sector. Another factor is continued developments in ICT capabilities such as high capacity Internet communications, and the increased sophistication of processing systems which provide opportunities for innovative approaches to program delivery. Improvements in public sector program delivery and operations are usually accomplished using a specific project. For example, projects to: implement a new government policy; introduce a more convenient method for the public to lodge claims; and introduce a more efficient financial system in an entity.
PROJECTS IN CONTEXT
In short, the effective and timely completion of projects is fundamental to improvements in program delivery. There are challenges to the successful planning and delivery of projects in the public sector. These challenges arise from such factors as the difficulty in defining and measuring success, the involvement of many different groups of people, the use of new technology, the complexity of integrating new projects with existing arrangements, and possible constraints in timeframe, funding and capability. This Guide focuses on the initial planning and approval of projects, as this strongly influences the successful completion of the project. The Guide focuses on projects to deliver government programs, or to make internal improvement to entity operations, particularly for projects which involve the use of ICT. Executives are well placed to contribute to project planning and approval because they: have key relationships with stakeholders, which positions them well to provide guidance on priorities; have the knowledge and experience to help improve the quality of project proposals; and have authority for allocating and managing resources including the approval of projects, and the adequacy of resources provided for planning.
This Guide aims to provide practical support and advice to executives to help improve the quality of the planning and approval of projects. To assist the reader, the major concepts and terminology of project planning which are used in this Guide are described below.
SECTION
1
3
1.2 The project lifecycle

Major elements of a project Projects are time limited initiatives to deliver a project product for example, a new payments system. The project products may include physical objects, services or information.
The project products will then be used to achieve business outcomes for example, making payments to eligible Australians. These business outcomes are generally the reason for funding the project, rather than the project products by themselves. These business outcomes will in turn contribute to longer term or broader benefits for example, improved employment prospects for those who received payments. The project products will often need operational inputs for their use for example, data and staff. To achieve the desired business outcomes, those involved in project planning and approval should keep in mind the above factors, and how the project products will be developed and delivered during project implementation. Important roles in project planning and approval include: the decision-maker the person or body which decides whether a project will proceed; the project sponsor the person who proposes a project, and who will be responsible for its successful delivery; and the operational manager the person responsible for using the products of the project to deliver business outcomes.
Other important roles in the project lifecycle include: the product suppliers the people who will develop the project products; and the end users those affected by the project products, such as the members of the public who receive services and the staff using the project products to provide services.
In practice the same person may not occupy a role for the duration of the planning and completion of a project, and one person may have more than one role. Nevertheless, the responsibilities of each of these roles still need to be fulfilled. If a person is both sponsor and decision-maker, it is prudent to consider independent advice to improve the quality and transparency of decision-making. The fact that business outcomes are achieved during the ongoing use of the new capabilities means that the real success of the investment in the project may only be assessed well after project implementation, and the business outcomes may be realised by parties who were not involved in the project. This makes it important that the planning and approval stage clearly defines the intended outcomes, and allocates accountability for achieving them.
The typical steps of project planning are: 1. development by, or on behalf of, the project sponsor of a project concept plan to explore the possibilities and clarify the broad nature of the project; 2. development by, or on behalf of, the project sponsor of a more comprehensive project business case with details of the proposed outcomes, product requirements and firm costing; and 3. consideration and approval by the decision-maker of the project business case. In many cases, there will be subsequent consideration and approval of a more detailed implementation plan, and further approvals at key points during the project. Effective project planning and approval will also be assisted by having effective support arrangements at the entity level such as promoting strategic alignment, having the right people and culture, and having effective governance arrangements. This is the responsibility of the chief executive, normally assisted by the Senior Executive team. The elements discussed above and their relationships are illustrated in the following diagram.
roleS and reSPonSiBilitieS
PROJECTS IN CONTEXT
Project products
operational manager
Operational inputs
When used, achieve business outcomes
Business outcomes
Long term benefits
Project
Project sponsor When implemented, delivers a product
decision-maker
Approval
Project sponsor
Business case Project concept plan
Project sponsor
Planning and approval stage: a foundation of project success, and the focus of this guide
Chief executive and Senior executive team
Entity arrangements to support project planning and approval
SECTION
1
5
The objectives of the steps in planning and approval are shown in the table below. STEPS: 1. Project concept plan OBJECTIVES OF STEP: 3 Clarify and agree the need or problem to be solved Clarify and agree business outcomes ensure the project concept is sufficient to achieve outcomes explore broad options and substantiate proposed approach Start building support with interested parties 2. Business case Specify project deliverables and scope estimate costs and resource needs assess related options and justify proposed option assure feasibility of implementation develop support of key stakeholders 3. Approval decision to proceed or not often in comparison with other proposals authorise significant work and expenditure Set key controls to aid executive oversight, particularly for implementation, progress to business outcomes and arrangements for handover to operations formalise roles and commitments
Executives add value early

A key reason for having a distinct step for developing the project concept is to help executives focus on the key issues for the project. Developing the business case is a task the executive manages and is accountable for. However, the business case has detailed information that is often the subject of vigorous debate, which may distract from considering the fundamentals. The concept stage is about the big picture deciding what you want to achieve, and which levers will actually work. This is the time when executives can really add value: early. Agency planning executive.
3 Note: This table lists the objectives of each step in planning. Chapter 3 of this guide focuses on issues of particular relevance to executives when these steps are being undertaken.
Related APS planning steps

The following table shows the terminology used for associated APS processes in relation to the language used in this Guide. While terminology may differ, the essence of the steps in effective planning is similar, as are the key issues for executive attention. THIS GUIDE Project concept plan ICT TWO PASS REVIEW Signal intentions to finance; gain agreement to develop a first pass business case develop a first pass business case, at moderate level of detail; gain agreement to continue; develop a more detailed second pass business case approval GATEWAY REVIEW Gate 0 Business need
Business case
Gate 1 Business case
Approval
approval4
Project implementation
Gate 2 Procurement Strategy5 Gate 3 investment decision Gate 4 readiness for Service
PROJECTS IN CONTEXT
Different types of projects

There are many different types of projects undertaken by government entities, which vary according to their rationale, approach to implementation, and measures of success. Some examples are projects focused on: implementation of a new government policy with indicative success measures of timeliness, cost, and accuracy of implementation, and with long-term benefits of the policy usually assessed by separate policy evaluation; entity internal operational improvements with indicative success measures of reduced unit costs and increased regulatory compliance; improved entity capability with an indicative success measure being the ability to implement new government requirements more quickly or more cheaply; and research with indicative success measures of the amount of relevant evidence collected and the reduction of uncertainty on an issue.
The implication of these differences is that there is not a simple, mechanical method of comparing and assessing projects. Allowances need to be made for their different characteristics, and different underlying objectives. 45
4 The Gateway Review process provides independent advice to the decision-maker at key stages. The actual approval is by the decision-makers and is not part of the Gateway process as such. 5 The Gateway Review process refers to a procurement strategy. Some entities have a substantial internal development capability, with many project products being developed in-house rather than being obtained through a procurement process. In these cases there are logically equivalent assessments to the Gateway procurement strategy review such as assuring that the project is sufficiently well defined to allow firm costing, and that resources are available.
SECTION
1
7
Variations in focus during planning and approval

The steps in project planning and approval and the focus of review may vary depending on the project. For example: An entity may develop a business case for a project aimed at internal cost reductions, and then provide a business case to seek government approval and funding. A particular focus would be on the feasibility of the project and its expected rate of return on investment. As part of the annual Budget process, entities develop new policy proposals. At this stage, the main criteria for assessment will be the overall program policy and cost priorities. If a new policy is agreed, the focus for reviewing the policy implementation project is that it will be able to deliver the policy requirements within the agreed implementation budget and timeframe.6 The Government may agree to a project concept and budget and direct an entity to implement the project. In such cases the focus of planning and review will be refining the scope of the project, in consultation with the relevant Minister, to fulfill the announced concept within the budget and timeframe.
1.3 Arrangements should be fit for purpose

Planning is bringing the future into the present so that you can do something about it now. alan lakein.
Australian government entities vary widely in their size and responsibilities, and in their current level of capability to plan and implement projects. Individual projects can vary in their size, complexity, risk and impact.
This Guide describes better practices in the broader management arrangements of entities to support project planning and approval. Entities should tailor these arrangements to their own circumstances. This may include assessing both their capability and requirements. If improvements are needed, it is prudent to aim at a practical pace of change or to seek external assistance if increased capability is needed more quickly. The Guide describes important steps in the planning and approval of individual projects that should be undertaken to improve the prospects of project success, and to meet accountability requirements. The effort devoted to planning and review at each step should be fit for purpose tailored to the circumstances of the entity and the characteristics of each project. This may include, for example, arrangements to allow faster consideration of urgent projects while still achieving appropriate review and accountability; additional planning steps for larger, higher risk or higher impact projects; and a streamlined approach for projects of low cost and low risk.
6 It is useful to reinforce that even where the policy is approved, the implementation project still warrants thorough review. The review of implementation is not a review of the policy decision. However, on occasion information is found during implementation planning which is relevant to the policy decision, and this information should be drawn to the attention of the policy decision-makers. If it appears that the desired outcomes may not be able to be achieved in the approved budget and timeframe it is good practice to offer options to the decision-maker, for example options with limited outcomes that can be achieved within the proposed timeframe and budget, and with the budget and timeframe that would be needed for the desired outcomes. Any risks associated with the options should be appropriately identified.
this chapter describes better practices in the overall arrangements of an entity for the planning and approval of projects. these include aspects of strategic planning, people and culture, and governance..
Contents:
strategic alignment ENTITY ARRANGEMENTS effective governance
2.1 Promoting strategic alignment (page 11) 2.2 Having the right people and culture (page 17) 2.3 Having effective governance arrangements (page 23) 2.4 Addressing common APS requirements (page 38) Key better practice summary (page 41)
people and culture
common requirements
10
2: Entity arrangements
Entities may have responsibilities for delivering new programs, improving delivery of existing programs, improving efficiency, and developing capabilities for the future. Progress in these areas will often be achieved by implementing specific projects time-limited activities with a specific goal. Having the right environment and support for the planning and approval of projects helps provide confidence that project resources are being applied in the right areas, with reasonable prospects of success, and at reasonable cost.
The right environment for planning and approval of projects is not simply a matter of having the right procedures and templates. The right environment also involves the entitys senior leadership group in such matters as: setting strategic goals and then actively working with the entire executive team on understanding and striving toward these goals; encouraging, through their own behaviour, an open approach to understanding and then overcoming the risks inherent in complex projects; and
ENTITY ARRANGEMENTS
allocating resources to improving their entitys project planning and project management capabilities.
This chapter outlines elements of better practice at the entity level for planning and approving projects.7 These better practices will usually be the responsibility of executives with entity wide roles for corporate planning, ICT and business strategy, human resources strategy, and governance. Individual executives have a role in contributing to the formulation of corporate policies, and a responsibility to comply as appropriate. Entities will typically have all, or the majority, of these better practice elements in place and are encouraged to assess their existing arrangements against the elements listed to identify any opportunities for improvement. These better practices should be applied by entities as appropriate to their circumstances, such as their size, complexity, and the nature of their responsibilities.
7 This is not an exhaustive list of management and agency planning practices. This Guide focuses on practices particularly relevant to project planning and approval.
SECTION
2
9
Structure of this chapter:
2.1 Promoting strategic alignment

Alignment with corporate goals Understanding of ICT strategy Alignment with government-wide policies
2.2 Having the right people and culture

Executive skills for project oversight Engaging with risk and uncertainty
Understanding of approval processes and concepts
Skills for project planning
Support for independent assurance
2.3 Having effective governance arrangements

Approval roles and processes Project priorities
Accountability and authority
Data stewardship
Financial management
Monitoring and reporting
2.4 Addressing common APS requirements

Common APS requirements, such as those for procurement, ethics and probity, and recordkeeping, are important contributors to project success and to proper accountability.
Key better practice summary

A checklist-style summary of better practices described in this chapter.
10

Creating the right environment for planning takes the personal involvement of the agencys senior executives. It takes their experience and skills in setting directions, their perseverance in promoting those directions, and their constant and visible support for the value of professional and pragmatic project planning. agency planning coordinator.
Use of project products, leading to business outcomes
Project
Entity arrangements to support project planning and approval Promoting strategic alignment Right people and culture Addressing common requirements Governance arrangements
An entitys goals and strategies are usually expressed in a corporate or strategic plan covering a planning period of several years.
Progress towards an agencys goals will be aided by individual projects being aligned with them. That is, the projects contribute to one or more goals, appropriately complement other projects and initiatives, and are consistent with agency policies and standards. More effective alignment will be achieved if an agency promotes an active understanding of strategic issues in the executives and staff involved in project planning. This understanding will foster more effective consideration by those developing project proposals of their projects potential contribution to agency goals, rather than minimal conformity. Progress toward agency goals will be further supported by making it as straightforward as possible for projects to demonstrate their specific contribution to these goals. Important areas for consideration in project planning include alignment with agency corporate goals, alignment with the entitys ICT strategy, and alignment with government policies generally.
ENTITY ARRANGEMENTS
SECTION
2
11
Alignment with corporate goals

Better Practice results: Project proposals contribute to the entitys corporate goals and program delivery strategies.
An important aspect of corporate planning is defining an entitys program delivery strategy. For example, this could involve deciding: whether programs will be provided in-house or contracted out, and whether they will be delivered via counter service, by phone, mail, or the Internet; the standards and goals for program delivery such as decision-making times, or avoiding the need for clients to provide information which they have previously provided; and the standards and goals for internal service delivery, which enable staff to carry out their program delivery roles such as providing staff access to an online information portal covering client information, program information, and staff information.
The value of alignment:

A thousand drops of rain falling in one place will wear away the hardest stone. A thousand drops of rain falling by chance are simply pitter-patter. Proverb.
Strategy briefings
Each year we hold a half day session at the start of the project planning cycle to explain the process, our templates and terminology. We also update everyone on coming changes in emphasis in our program delivery strategy so we encourage line areas to develop proposals that fit in. agency planning branch head.
Progress toward achieving the program delivery strategy will be assisted if project proposals are developed with the strategy in mind. It is better practice that entities promote an understanding in executives and those involved in developing project proposals of the practical implications of their program delivery strategy and other relevant policies. Projects also need to align with a range of other entity and government strategies. Some of these alignments are illustrated below.
Government-wide policies
ICT policies
Program delivery policies
entity-level plans
Goals: desired state of affairs Strategies: means of achieving goals
ICT capability goals + strategies
Program delivery goals + strategies
Work unit and project plans
Project plans
Work unit plans
agency plans will also align with their Portfolio Budget Statement
12
Case study: New delivery strategy drives new projects

a national agency with security responsibilities had always worked cooperatively with other jurisdictions. however, changes in the external environment meant that a very significant increase in cross-jurisdictional cooperation, in particular in joint taskforces, would be used in the future. Supporting this change while maintaining proper management control and accountability would require many changes to internal systems and work practices. to support this, there were changes to the iCt strategy and projects for increased iCt storage capacity, specialist data analysis software and training, and changes to accounting and personnel systems.
A project can demonstrate its alignment with corporate goals more easily and more usefully for decision-makers if corporate goals include relevant and tangible indicators. These tangible indicators allow projects to specify their measureable contribution to corporate goals, on a consistent basis to other projects. For example, consider a common, and desirable, high-level goal of Improved client service. Many projects could assert alignment with this goal. However, assessing the degree of contribution and hence relative merit of a project to a broadly phrased goal is uncertain. This uncertainty can be reduced if the high-level goal is supplemented by measurable indicators and targets, such as: Reduce average decision-making time from 4 days to 1 day.
ENTITY ARRANGEMENTS
An example of two projects demonstrating their specific contribution to tangible improvement targets for a corporate goal is provided below.8
Goal: Improved Client Service
Sub-goal: Faster decision-making
Sub-goal: More information online
Sub-goal: Less phone waiting
Target: 3 days faster
Target: 20% more
Target: 20 minutes less
1 day
20%
5 min
15 min
the boxes above indicate the specific contributions to targets of the respective projects. note that the target for faster decision-making is not fully met by these projects, which may prompt additional proposals.
Project: Put archived payments online
Project: Call centre overflow system
8 In practice, setting useful targets for goals generally involves clearly defining an indicator (sometimes called a metric) for the goal, measuring current performance of that indicator, and setting a specific improvement target for a nominated time period. These steps then allow confidence in the assessment of performance improvements.
SECTION
2
13
Understanding of ICT strategy

Better Practice results: Senior executives use the entitys ICT strategy as a factor in developing and assessing projects, which assists in building the entitys ICT capability.
An entitys ICT strategic plan will typically: assess the current adequacy of ICT to support current and future business needs in particular the entitys program delivery strategy; identify a required or desired future state of ICT, including the preferred ICT architecture (that is, key processes, data stores, technologies and their relationships); and identify how to move from the current to preferred state of ICT capability.
Making progress toward the preferred state of ICT capability is important in helping an entity improve service quality and reliability, manage costs, and increase its ability to respond to future government requirements. Many aspects of an entitys ICT strategic plan will have a technical focus and will be used by an entitys Chief Information Officer to help plan and manage the entitys ICT infrastructure. However, having a shared understanding between executives, business sponsors and ICT specialists on key, business-oriented aspects of the entitys ICT strategy will aid the development of proposals that will contribute to that ICT strategy. It is better practice for entities to promote a high-level understanding of the entitys ICT strategy among its senior executives and those developing project proposals that have a significant ICT component. For example, an important element of an ICT strategy is an entitys ICT architecture. It is useful for the ICT architecture document to contain a section suited to executives. The diagram on the next page shows a simplified high-level ICT architecture, combining data, business processes and communications. Other practical steps to develop an informed understanding by entity executives of the ICT strategy include: preparing plain-English versions of the business perspective on ICT strategies, including case studies and examples of how elements of the ICT strategy contribute to the entitys business strategies and goals; regular briefings on the progress of the ICT strategy and its practical implications to senior executive forums; targeted briefings to executives with a common role such as regional managers, or program delivery managers; and site visits to show examples of the entitys planned future ICT capabilities already in operation elsewhere.
14
Example: Executive view of ICT architecture

It is important for executives involved with developing or approving project proposals that have a significant ICT component to have a high-level understanding of the entitys ICT strategy, including an executive perspective of the entitys ICT architecture. This will assist them to make informed judgements on high-level ICT aspects of proposals. Core business processes Ministerial support
Develop policy
Data analysis
Manage agency
Core data
Ministerial
Research
HR, Finance
Clients
Services
Providers
ENTITY ARRANGEMENTS
Core access methods Counter Client processes Register Receive Service Manage/ close Call centre Mail / OCR Web Inter-agency
Provider processes Engage Provide Service Manage/ close
Current status:
no label: Satisfactory
: Scope to improve
: Priority to improve
diagram legend:
Access channel
Process
Data store
This example of an ICT architecture summary is simplified. For practical use it would be expanded to A4 or A3 size, and show the key agency-specific features of its architecture. For example, there would likely be more detail on key business processes, and an indication of application systems. The specific detail would depend on the agencys circumstances and which architectural issues were important to executive consideration.
Usage tip: a project proposal can overlay on this diagram the elements of the
architecture it utilises or develops. it can also highlight exceptions or external linkages that may be a source of risk. this would help place proposals into context.
SECTION
2
15
Alignment with government-wide policies

Better Practice results: Proposals are consistent with government program delivery and ICT strategies prior to submission to government helping project approval and, after implementation helping improve the overall service experience of citizens.
Citizens and business expect continued improvements in program delivery, and increasing access to government information and programs using such mechanisms as online and electronic communications. To help address these expectations, the Government has developed policies for program delivery and the use of ICT, such as the Australian Government Architecture, the National Government Information Sharing Strategy, the National e-Authentication Framework, and policies on the use of off the shelf software. The Government has also adopted assurance processes such as the ICT Investment Principles, the ICT Two Pass Review process, the Gateway Review process, and the requirements for implementation plans administered by the Cabinet Implementation Unit. A summary of these is provided in the appendices at page 102. Better practices for entities to achieve alignment with these requirements are: Entities keep themselves well-informed about government-wide program delivery and ICT developments. Entity guidelines and processes for the planning and approval of projects include checks for conformance with government-wide policies and strategies. If a potential difficulty with conformance with a new policy is identified, for example due to a large prior investment in another technology, better practice is that the entity document and discuss this with the relevant central agency, with a view to reaching an agreed approach. Entity processes include checks for the application of government-wide assurance and approval processes, such as the financial and risk thresholds for the application of the ICT Two Pass Review process and the Gateway Review process. Entities promote an understanding in executives and staff involved in project planning about the practical implications for the entity of government-wide policies. Possible actions are periodic briefings to executives, and including a plain-English explanation in the entitys program delivery and ICT strategy documents of their linkages with wholeof-government policies. Entities being actively involved with central agencies in the development of governmentwide strategies. This helps assure that strategies can be readily conformed to, or central agencies are aware of potential implementation issues for entities.
There are also a wider range of policies and guidelines relevant to the planning and implementation of projects. A few illustrative examples are: the Commonwealth Procurement Guidelines, which provide the framework for undertaking the procurement activities associated with many projects; Financial Management Guidance No.23 Commonwealth Grant Guidelines, which will be relevant to projects associated with implementing grants programs; and Financial Management Guidance No.17 Public Private Partnerships: Business Case Development.
As part of their broader management arrangements, entities should maintain an awareness of these policies and associated guidance, and their potential application to individual projects.
16
Project
The planning and approval of projects can be more effective if there is a pool of executives with appropriate skills to provide leadership and informed feedback to staff undertaking planning. The quality of planning advice will be greater in an environment that deals maturely with risk and uncertainty, where relevant specialist skills are available, and where there is a shared understanding of key concepts and planning processes among the people involved. An environment that promotes openness to independent review and assurance will further improve the quality of project plans.
ENTITY ARRANGEMENTS
Executive skills for project oversight

Better Practice results: Those with oversight roles for projects achieve, at the planning stage, a clear definition of the projects business outcomes and an appropriate assurance on project feasibility. This sets the foundation for successful implementation.
As part of their responsibilities, many senior executives oversee a number of projects. This oversight role can encompass the initial planning and approval of projects, through to implementation and handover to ongoing operation. The detailed planning and subsequent implementation of individual projects are often undertaken by separate individuals, leaving the executive as an important point of continuity. An important responsibility for those with an oversight role is to gain appropriate assurance on the feasibility of the project generally through review of key planning documents and by forming a view on the quality of advice from those undertaking detailed planning and implementation roles. These executives also have a responsibility to retain a focus on the initially approved business outcomes during the life of the project, to help reduce the risk that the project unintentionally diverges from its agreed objectives. Achieving a clear definition of business outcomes can be difficult, as project proposals are often presented in great detail and, for those projects with an ICT component, with a focus on ICT implementation technicalities. Some executives with oversight responsibility may find it daunting to penetrate these technicalities, due to competing priorities, and natural variations in aptitude and experience.
SECTION
2
17
In addition, it takes time to develop the experience and judgement needed to effectively establish an appropriate level of assurance on project proposals, and this experience may vary across an entitys senior executive group. It is therefore better practice for entities to identify, or develop, a pool of executives with aptitude for the oversight of projects. Useful characteristics for executives in project oversight roles include: an effective relationship with key stakeholders to assist with formulating and clarifying the projects business outcomes, including the Ministers office where appropriate; an understanding of the perspective of central entities on program delivery and ICT strategy; a consistent focus on business outcomes, including ensuring business outcomes are well defined and maintaining a focus on achieving them; sound judgement regarding the technical issues that are likely to be important (often ICT and legal issues), and a firm resolve to understand them which can involve requiring specialists to clarify the business implications of technical issues and identify those issues requiring executive attention; and having a network of suitable contacts to help provide an independent reality check on key aspects of proposals both business and ICT elements.
The number of executives within an entity with appropriate skills and experience for project oversight can be increased by development activities such as mentoring of executives when initially undertaking an oversight role, and by gradually increasing the number and complexity of projects for which an executive has oversight responsibility. Another avenue to access suitably skilled executives, which may be appropriate for major initiatives, is to look to transfers within the broader pool of APS executives or externally for example from organisations with relevant experience. One approach is to consider a timelimited arrangement with a focus on transferring skills into the entity. There can also be advantages in recognising the variety of skills needed across an entity and consciously focusing project oversight roles on a sub-set of the executive team with relevant aptitude and skills, with other executives focusing on other essential responsibilities in the entity. In some cases, there may be value in having dedicated roles for project oversight.
Engaging with risk and uncertainty

Leadership and risk
An important leadership responsibility for executives is to foster a culture of effective engagement with risk.
Better Practice results: Higher success rate on delivering projects within announced time, budget and scope due to risks and uncertainty being effectively addressed.
Risk
Many, if not all, entities have well-documented risk management frameworks based on sound risk management principles, and prepare risk plans as an integral element of project proposals. Despite this attention to risk, there are still projects which are significantly late, over budget, or have shortfalls in planned outcomes due to reasonably foreseeable risks not being identified and addressed appropriately. Some of the causes of these shortfalls are best addressed at the entity level, by executives with corporate responsibilities.
18
Factors that may cause entities to not effectively address risk during project planning include: a lack of skill in reliably identifying and mitigating risks; insufficient support in entity operational arrangements for managing contingency funds and contingency time allowances; a lack of clarity on the level of risk the entity is prepared to accept (also known as the entitys risk appetite); insufficient openness to the identification of risks; and high-risk objectives for projects, arising from legitimate expectations on the public sector for solutions to difficult problems.
Risk management issues following project planning, such as risk monitoring and effective response to adverse events, are discussed in Chapter 4. The first two factors skill and supportive operational arrangements can generally be addressed through internal management improvement initiatives. For example: training programs in risk management; allocating time to monitoring actual risk events and using the findings to improve future risk identification and mitigation; developing an agency-specific list of risk categories (such as legislative, benefits realisation, implementation, public reputation); and developing protocols and organisational culture to have contingency allowances provided and to operate as intended. The third factor lack of clarity by the entity on an acceptable level of risk leaves project risk to be addressed by approval committees on an ad hoc basis. This can increase the risk that there will be an unexpectedly high rate of project failure. Clarity on preferred risk levels can be improved by considering the categories of projects undertaken by the entity, and then nominating a preferred maximum residual risk for each category. This will provide a thoughtful, entity-wide approach to risk thresholds, which can be used as part of the screening of project proposals (as discussed on page 29). For example, an entity may decide that it will accept a high or medium level of risk for small pilot projects for innovative ideas, and will only accept a low level of risk for projects affecting service delivery to the broader public. The fourth factor insufficient openness to risk identification can be more difficult to assess and address. Advice from a trusted independent adviser can be a useful first step in assessing whether this is an issue, and if so, identifying any underlying causes and possible remedial actions. More generally, an important leadership responsibility for executives is to foster a culture of effective engagement with risk. The desired outcome is a balanced approach, where: executives take responsibility for either accepting risks or resourcing their mitigation, and executives acknowledge the benefits of being made aware of risks; and line staff make mature judgements on risks, deal with issues within their control or which are routine, and put forward risks for executive attention that are based on a realistic assessment and are accompanied by achievable mitigation measures.
ENTITY ARRANGEMENTS
Realistic expectations
Our close relationship with the Ministers office and central agencies keeps paying off. For example on one high-profile project we worked together on the wording of the public announcement. Promising a significant increase in information available within 6 months met public expectations and was practical. We delivered it. But without a close relationship there could easily have been expectations set that we simply could not deliver.
The fifth factor higher risk projects arising from high expectations requires sensitive management. It is only natural that there are high expectations of publicly funded projects, and that there will be pressures from many sources to set ambitious goals. Accordingly, many risk management activities for this factor will be most usefully taken in advance, for example: Developing an effective relationship with the Ministers office and central agencies, to provide a basis for discussions of potential project announcements and help reduce the risk of shortfalls in project delivery.
SECTION
2
19
Project sponsor.
Managing uncertainty takes trust

The entity that I worked at with the best record for delivering projects on time and on budget handled the uncertainty in estimates professionally. But that took mutual trust, developed over some years. I could say that project will take between three and six months, and I will be able to narrow that down after one month and I could trust that management would not tell the Secretary it would be done in the most optimistic time, and management could trust that I would narrow the estimate down when promised. Project team leader.
Developing a pool of skilled staff that can develop project modules or phases that realistically balance technical feasibility with the need to provide a stream of benefits quickly. Assessing potential areas for ambitious projects and collecting information to aid in project planning and estimation in those areas for example though consulting entities with relevant experience, tailoring of current work to explore areas of interest, or conducting pilot projects. This will assist informed decision-making before details of projects are made public.
Uncertainty of estimates
The reliability of estimates of the cost and timeframe for a project is influenced by a number of factors. These include the reliability and level of detail of the description of the projects scope and deliverables, the degree of innovation in the project, and the skills and experience of those making the estimate. The first two factors mean that estimates of project cost and timeframe at early stages of planning are likely to be inherently uncertain. It is better practice for entities to acknowledge this uncertainty in project estimation and have a culture and planning processes that: make clear to decision-makers the inherent uncertainty of early estimates; help decision-makers express their preference as to how this inherent uncertainty is to be managed for example by refining the project scope as needed to remain within a preferred timeframe, refining the budget for a preferred project scope, or some other combination of timeframe, budget and scope; assist decision-makers by expressing estimates as a likely range; and indicate the effort and activities to be undertaken to provide greater certainty of estimates as the project progresses.
Skills for project planning

Better Practice results: Advice from relevant specialists during planning is reliable and is available when needed during the planning cycle. This improves the usefulness of information provided to decision-makers.
To help ensure that decision-makers have reliable and timely advice, it is better practice for an entity to develop and maintain access to a pool of people with the skills and knowledge to develop project proposals. In many entities, the relevant skills would be spread over a number of staff and organisational units, and would not be a full-time role for the staff involved. Larger entities may maintain a central area of project planning expertise. Some skills may be contracted in, on a continuing or ad hoc basis as required. Relevant skills and knowledge for entities to have readily available include: business analysis (in particular to help with early concept development); operational knowledge, drawn from the area of the entity responsible for delivering the business outcomes;
20
ICT covering both the technical subject matter itself, and just as importantly, the ability to translate technical issues into business terms; legal, for projects involving the drafting of legislation, regulations and contracts; experience in implementing business change; an understanding of central agency processes for projects (including ICT project processes); ICT and general procurement; and project costing and estimation.
Talent makes a difference:

People who can develop really good statements of business outcomes are hard to find. It seems to be as much art as science. We were lucky that we had a good business analyst who understood our organisation and had a magic touch. She was able to separate the wheat from the chaff in all the detail from the project team, and develop business outcome statements that went to the heart of the initiative, were measurable, and were meaningful to our stakeholders. agency business manager.
Such specialist skills will usually supplement the skills and knowledge of the responsible business area. The business area typically has detailed subject matter knowledge and relationships with important project stakeholders. The availability of people with relevant skills to best assist decision-makers can be assessed though a review of the quality and timeliness of projects, by interviews with project sponsors, and by discussion and comparison with similar entities. Any shortfalls identified can be addressed by actions such as: setting up or enhancing a central specialist team to make best use of scarce skills; targeted training particularly focusing on elements of work about to be done in an entitys planning cycle (in contrast with general project management training); secondments of experienced staff from lines areas to assist during the project planning cycle; and the use of external expertise in training, mentoring and preparing project proposals.
ENTITY ARRANGEMENTS
Understanding of approval processes and concepts

Better Practice results: Project proposals are more effectively assessed and compared because they are described on a consistent basis.
The approval of projects will be improved if there is a wide understanding of entity planning processes among the staff who generate new project proposals. This understanding helps ensure proposals are available at the right time and in the right format for a coordinated assessment by decision-makers. The proposals themselves will be more effective if staff have a shared understanding of specific project planning concepts. There are a common set of concepts used to effectively and incisively describe projects such as scope, deliverables, functional requirements, nonfunctional requirements, and business outcomes.9 Gaining this shared understanding across the staff involved in projects will benefit not only the assessment and approval of projects, but also their subsequent development, implementation and operation.
9 See Appendix Project planning and approval terms at page 100 for definitions of concepts associated with defining a project.
SECTION
2
21
Common language pays off:

Getting a shared understanding of basic project concepts, such as deliverables and requirements, sounds easy and unimportant. In fact, getting all players using them consistently was hard, but worth it. It took two years. We provided local agency examples, and had a centrally-funded business analyst to help sponsors. For example, previously a proposal might describe its major benefit as a modern, scalable payments system with real-time data transfer. It sounds superficially plausible but it is really just a stew of words that did not help the investment committee make decisions. Now we talk the same language. For example: a payments system is a deliverable; and ability to increase from 5 to 30 million payments is a non-functional requirement that explains what was really meant by scalable. This shared understanding of concepts helps people across the agency describe what they want more quickly and reliably, and then get what they want. agency Chief information officer.
Support for independent assurance

Better Practice results: Independent assurance increases the reliability of information for decision-makers, which in turn contributes to a higher project success rate.
Start small
We rolled out an ambitious project management program. In hindsight it was too much, too quickly. I now recommend a more graduated approach. The first point of leverage is to get shared understanding of the what and why of projects: the definition of deliverables and benefits. agency planning coordinator.
A common cause of shortfalls in projects is over-optimism on the likely time, cost and benefits. A related factor is insufficient review of important assumptions. These issues arise, in part, because there can be a tendency to accept some elements of a proposal as given (for example, because they are commonly accepted, or because it is incorrectly believed there has been competent review of the element). To help address the risk of some planning elements not receiving sufficient review, it is useful for executives with responsibility for projects to periodically obtain independent assurance on the information being provided to them. To help support independent assurance, it is better practice for entities to foster an environment where independent reviews are valued, conducted openly and sensitively, and are undertaken promptly at the right decision points. Independent assurance activities can usefully be considered as one element in the spectrum of quality assurance processes for project planning and entity management. The basic steps of quality assurance include processes for internal review and clearance within the planning team. This internal review will usually then be supplemented by reviews and checking by other areas of the entity, such as the Finance, ICT, or Budget area. Another layer of quality assurance can be provided by entity processes such as internal audit and program evaluation activities. Assurance activities can be arranged in a more timely way if an entity is able to quickly identify and engage suitable resources. One approach is a structured arrangement such as a panel of suitable consultants and pre-prepared contract arrangements. Alternatively the entity could maintain a network of contacts in other entities, and externally, that would allow a suitable resource to be quickly located. In addition, including project assurance activities in the entitys internal audit work program will allow these activities to be undertaken in a timely manner.
22
Project
By their nature projects are time-limited activities. This means that they can be more complex to govern, as they may fall outside the normal governance arrangements of an entity. The planning and approval of projects is likely to be assisted by having governance arrangements suited to all stages of the project lifecycle discussed in Chapter 1 planning, approval, implementation and operations. Relevant issues include:
approval roles and processes being appropriately defined, and involving suitably broad representation, to provide effective assurance and accountability during assessment and decision-making; project priority-setting, to help make decisions including between different projects in the context of limited resources; accountability and authority arrangements for projects; data stewardship arrangements to protect and make good use of this important asset; support for projects in the entitys financial management arrangements; and entity arrangements for monitoring and reporting of projects.
ENTITY ARRANGEMENTS
Approval roles and processes

Better Practice results: All elements of project proposals undergo competent review, and there is clear accountability for review and decision-making. Both of these contribute to subsequent implementation success.
Roles
An entitys planning, review and decision-making arrangements relevant to approving projects can involve four broad roles: Strategic advising the entity head on strategic program delivery and ICT issues. This includes approving the program delivery strategy and the ICT strategy, and recommending aggregate annual spending in different areas, such as improvements to program delivery, to internal efficiency, shared infrastructure, and support of business-as-usual activities.
SECTION
2
23
Resource allocation making decisions on resource allocation, including investment decisions on project proposals. Planning support coordinating the preparation of strategies, assessing project proposals on their technical and business merits, and providing advice to support strategic consideration. Technical using specialist skills and knowledge to provide advice on technological directions for the entity, assisting project sponsors through specialist advice, and assessing proposals for technical feasibility and compliance with entity standards.
These roles are often carried out by committees, to provide a breadth of viewpoints, and develop a shared commitment to decisions. In larger entities there may be one, or more, committees covering each role. In smaller entities several roles may be combined. The technical role is usually separate, due to the specialist skills, and detailed discussions involved. Elements of better practice for committee arrangements, relating to the effective review of project proposals, include: Separating roles involving technical review from decision-making. This allows detailed matters, such as detailed ICT costing, ICT feasibility, and ICT architecture issues to be considered by relevant experts, leaving the decision-making body to focus on balancing priorities and assessing value-for-money based on reliable advice. Advisory and decision-making roles are clearly articulated. This is important to provide clear accountability, particularly given that project proposals can be reviewed by several committees. Clarifying the nature of the assessment or endorsement to be provided by each committee will help focus each committee on the issues and help provide the decision-maker with a clear understanding of the scope of advice they are using, and any limitations or provisos on that advice.
Processes to review project proposals

The roles mentioned above are generally elements of an assessment process, where particular issues are considered from various perspectives. Characteristics of effective assessment processes are that they: are clearly described, and promulgated to staff; make clear the decision points, and the prerequisites for advancing through the process; and are fit for purpose that is, they are adapted to the needs and circumstances of the entity, based on consideration of such factors as the size and complexity of projects, the risks and potential impacts of projects, and the entitys capability in planning and managing projects.
An example process for developing and assessing proposals is described briefly in the following table. This example process has two main stages developing a project concept plan, and then a comprehensive business case. There can be many workable variations on these processes, depending on the size and responsibilities of the entity.
24
STEP IN PROCESS Concept stage 1. Project concept developed in business area
VALUE ADDED DURING STEP
identification of need and opportunity; clarification of specific outcomes to be achieved; testing of underlying logic at a broad level.
2. Endorsement 3. Specialist assessment
Confirms support of project sponsor. Specialist advice on broad policy and iCt alignment, possibly indicative cost. agreement within the entity that the approved concept proposal targets an area of need and the cost of developing a business case is warranted.
4. Clearance to proceed to business case
Business case stage10 1. Prepare business case
reliable outcome and cost estimates11; assurance of feasibility; implementation and governance arrangements. Confirms support of project sponsor and relevant stakeholders. assurance to decision-makers on specialist aspects (including technical and policy compliance / alignment, costing analysis). Confirms the project as feasible and a worthy use of available funds; a clear decision point.
ENTITY ARRANGEMENTS
2. Endorsement 3. Specialist assessments
4. Funding decision
Note: Additional approvals will generally be needed prior to significant expenditure.
For larger projects, there may be a significant cost in preparing a reliable business case. In such cases there may be additional stages in the approval process. For example, a proposal taking a few weeks of effort to prepare may gain approval to develop a more detailed business case that takes (say) nine months to prepare. This more detailed business case would be of sufficient reliability to allow a decision on a significant investment.
10 Note: in some cases, having identified a broad concept an agency may go to the market to seek proposals for solutions. The responses may then be used as options within a business case, or the preferred response may be used as the basis for a business case. 11 The degree of uncertainty in costing will have been reduced since the concept stage. While some uncertainty may remain, the key point is that the estimates should be sufficiently reliable to support the action being proposed in the business case.
SECTION
2
25
Elements of better practice for the review and approval processes for project proposals, include: Process for managing many proposals larger entities may consider a large number of proposals each year, and will benefit from having specifically designed and supported processes. useful support for assessing many projects includes quality control of the supporting business cases, standardisation of key points of comparison for executive review, and streaming of similar projects to specific evaluation processes. Some projects may be approved for funding outside the entity with some parameters only broadly defined for example a project implementing a policy change, where the main focus has been on the policy aspects. although the projects are funded, they will still benefit from review by the entity to refine project parameters and scheduling details. having a defined exception process for urgent projects helps assure they still have appropriate review while being considered in a timely fashion. the exception process should also provide for appropriate recordkeeping for accountability purposes. low-value and low-risk projects may be approved more efficiently by a single stage of review. large and high-risk projects may benefit from being approved using a series of proposals of gradually increasing size, or by being divided into smaller sub-projects to better manage risk.12
Projects with funding approved external to the entity (for example, in the Budget) have a process to review and refine project parameters
Urgent projects are catered for
Very small, and very large, projects are catered for
Having defined the relevant approval roles and processes, the next issue is selecting the people to be involved.
12 Implementation approaches are further discussed at page 72.
26
Broad representation
Better Practice results: Improved reliability of information to decision-makers and improved cooperation from stakeholders during implementation.
The quality of the identification, assessment and implementation of project proposals will generally be improved by broad representation in the project planning and approval process.13 Having the right representation is important in both: developing project proposals where the right involvement helps to clarify the objectives and implementation issues; and reviewing and approving projects to provide specialist knowledge where needed and have the right people involved in decision-making.
Early representation pays

I found the best part of our project planning was how we involved all the states in developing the system requirements. Implementation then went so much faster. iCt executive involved with award-winning crossjurisdictional project.
Operational inputs
Project products implementation
Business outcomes
Long-term benefits
ENTITY ARRANGEMENTS
Approval Business case Concept plan
Broad representation in Approval e.g. strategy, policy, fresh perspectives Planning e.g. subject matter experts, stakeholders, line staff
It is good practice that entity guidelines on representation in the planning of individual projects: encourage the right breadth of involvement across the entity, including representation across functional areas, such as policy, program delivery, and corporate, and also across levels, so that staff at the working level with practical experience are represented; encourage appropriate representation from outside the entity, such as with central entities, partner entities, and customers, users, industry and service providers as appropriate; and clarify the different representative roles during project planning such as being consulted or having an approval role on project requirements and the protocols for confidentiality.
Confidentiality may limit representation

for some projects, confidentiality or security reasons will limit representation in the planning process. for example, developing a proposal for a policy implementation project may involve consideration of delivery options with an industry sector. Premature publicity of options based on unreliable costings is likely to be counterproductive. issues of confidentiality or security can be addressed by: entering into an appropriate confidentiality agreement with those being involved in early planning; or by recognising that some stakeholders are not able to be involved prior to an announcement, and making a suitable allowance in the projects time and cost for potential changes arising from subsequent consultations.
13 For some projects, confidentiality or security reasons will limit representation in the planning process.
SECTION
2
27
It is good practice when appointing individuals to committees that are responsible for approving projects to: have the right breadth of membership, including representation, as relevant, from policy development, program delivery, regional network, financial, staff perspective, audit, ICT, and an independent perspective; and periodically reflect on whether these different perspectives are being effectively brought to bear on proposals.
Client involvement in decision-making

Generally clients, or their representatives, are not directly involved in decision-making roles. however, it is important that the perspectives, concerns and experiences of clients be considered and be a factor in decision-making, given that their satisfaction is generally one of the projects objectives. for example, potential clients may be asked to give their views on the relative merit of different options, or the relative importance of different requirements.
Project priorities
Telling advice
In practice, the most telling questions during Investment Committee meetings came from our independent expert. She had the time to read and think about the proposals; the background to have insights; and the willingness to share them. Chief operating officer.
Better Practice results: The cumulative effect of projects given priority is steady progress toward entity goals; proposals are prepared in a costeffective manner due to widely understood guidance on the criteria for assessing projects.
The assessment and approval of project proposals will usually involve two types of decisions: screening decisions relating to whether a proposal meets a preset standard required for consideration; and prioritising decisions assigning priority to a proposal to help choose those proposals that make best use of limited resources, such as capital and skills.
For some project proposals, the main screening and prioritising process will include the Budget process. The Department of Finance and Deregulation advises entities of relevant criteria each year as part of the Budget process. Nevertheless, many project proposals will be assessed primarily within an entity. It is better practice for an entity to define and document their approach to screening and prioritising of project proposals, and to publicise this approach to staff involved in preparing proposals. Having the approach widely understood will help staff prepare proposals that are well-targeted and do not need re-working to meet the screening criteria. To be most effective, the approach to screening and prioritising should address both the feasibility of projects, and their contribution to achieving progress on entity goals and priorities. These goals and priorities often involve meeting a combination of immediate program delivery needs, internal efficiency improvements, and investments in future capability, with the proportions in each area varying according to circumstances.
28
Screening
Typical criteria used for screening project proposals are listed in the table below. As noted in the following discussion, there may be exceptions to the screening process this allows some practical flexibility while providing the efficiency and focus of screening for most proposals. SCREENING CRITERIA Alignment to broader goals COMMENT the project can demonstrate alignment with, and preferably a specific contribution to, corporate goals of the entity, and to relevant government goals, strategies and policy priorities. using the level of risk as a screening factor helps focus project proponents on developing proposals within the entitys preferred risk profile, and simplifies the subsequent assessment of projects. different entities will have different risk preferences, depending on their role and circumstances. one option is to set different risk thresholds for different categories of projects, for example by size, or by who will be affected by the project. Some entities may set a general requirement of low residual risk, with exceptions on a case by case basis.
Risk (including identifying all risks, mitigating as appropriate, and the resulting chance of project success).
ENTITY ARRANGEMENTS
Rate of return
for projects where the main objective is an internal cost reduction, a minimum rate of return on the investment can be set at the entity level. entities may wish to consider a relatively high rate of return for example 20% or more to offset the risk of not achieving targeted savings. an entity may wish to specify a maximum duration for example 18 months for a project to deliver a useful product. larger initiatives would be required to be packaged as a program of smaller, individually approved projects. new systems and business processes should meet relevant legislative requirements, such as the Privacy act, and security policies. any associated effort should be identified and included in the project budget. iCt elements of projects should comply with the entitys preferred iCt architecture. any areas of non-compliance (for example, for reasons of urgency) should be identified and the cost of subsequent remediation included in the project lifecycle costing. the proposal has been endorsed by nominated parties, for example the project sponsor and affected operational areas.
Duration
Legislative and policy compliance
ICT standards compliance
Endorsement
Completeness and presentation
the proposal provides the information needed for assessment and is presented in the entitys standard format. this assists review and comparison.
The above list is intended as an indication of the range of issues which are commonly used as screening criteria. Each entity should consider which criteria are most appropriate to their circumstances.
SECTION
2
29
Giving preference to shorter duration projects

One of the biggest things I learnt from working on a five-year project was that you have to break it down into a program of much smaller projects. I now firmly believe that individual projects should be of no more than 9 15 months duration, with a useful, stand-alone deliverable at the end of it. agency division head.
In general, proposals which do not meet the screening criteria would not proceed to further consideration. Either the area preparing the proposal would ensure it met the criteria prior to submission, or a difficulty would be identified by a committee secretariat who would then assist the proponent to resolve the issue. There may be occasions where proposals fail the screening criteria but are still worth further consideration. For example, a project might involve more risk than would normally be acceptable but no other alternatives to address the problem have been identified. In such cases it is better practice to document the reasons for proceeding and make the issue visible to decision-makers.
Reducing the residual risk

an agency setting a low risk threshold for screening projects for funding does not mean that initiatives with a higher degree of risk should not be contemplated. instead, initiatives with higher risk should either: have sufficient mitigation measures included in the project plan so that the residual risk is low (example 1 below); or be structured into smaller projects, so that areas of risk are explored early at low cost, with an option of not proceeding with later, more costly, projects in the initiative if the risks eventuate (example 2 below). Example 1: a project with a high dependence on the performance of external suppliers could mitigate that risk by using more than one supplier. the project budget would need to allow for the added cost of managing two suppliers. the added cost of any mitigation measures would reduce the nominal cost-benefit ratio of the project, while increasing the likelihood of project success. Example 2: the main goal of a project proposal for a new computer system is time saving for staff, but there is currently no firm evidence on the likely savings in the specific environment of the agency. this lack of agency-specific evidence is a significant risk factor. the overall project could be divided into a smaller pilot project which would assess the savings, followed by a larger implementation project which is contingent on satisfactory results from the pilot project. the objective of the pilot project is to provide reliable information about the degree of savings. it is relatively straightforward to design a pilot project that will provide this information at low risk, and thus address the screening test. the cost of the pilot project should be in proportion to the likelihood and size of the savings of the major project being contemplated.
30
Prioritising
In principle, project proposals can be prioritised by the extent to which they provide value for money. In practice, defining a common notion of value across many different types of projects can be difficult. In addition, the likely uncertainty in cost and value estimates suggests caution in relying solely on numerical methods. A practical approach to prioritising proposals, to assist decisions on funding, could involve the following elements: Group projects by outcome focus, to allow like-with-like comparisons entities will typically have project proposals focusing on distinct areas, such as improved customer service, internal efficiency, program implementation, or maintenance of business-as-usual activities. Grouping similar projects will allow a specific measure of value to be used to compare projects within that group. for example: client service improvements could be measured by the number of clients affected and the degree of improvement; internal efficiency projects measured by the net present value of reductions agreed to future budgets; and program implementation options measured by the implementation cost needed to meet the requested timeframe at low risk. focusing effort on improving the reliability of a common, well-chosen measure for a group of projects is often of more value to decision-makers than the same effort devoted to more complex comparisons of multiple measures. top-down guidance for example, from the entity executive as part of annual strategic planning on the project funding preferred for each outcome area will allow approval decisions in each area to be made by comparing projects on a common basis. the available funds can be allocated to the highest prioritised projects in each area. it is also useful to have top-down guidance on the funding balance between current needs and longer term investments. When there are many projects, it may be useful to score each project on a set of criteria, such as internal savings, savings to clients of time and money, improvements to flexibility, and utilisation of existing assets (such as software components, equipment or property). this type of analysis is often used in procurement evaluation. this scoring can be used to highlight aspects of projects which are of importance to the entity, and help inform judgements on the relative merits of proposals. for example, it may help identify that of three projects with a similar financial cost/benefit, one project has several desirable characteristics not present in the others. it is also possible to assign weightings to each of the criteria and then calculate a single composite score for each project. Such composite measures of project value are, necessarily, a simplification of the issues, and may be more useful in indicating projects of broadly lower value than in making distinctions between higher value projects. Use resource availability such as skills and capital as a fine-tuning factor
ENTITY ARRANGEMENTS
Provide top-down guidance on overall funding preferred for different outcome areas
Using multiple criteria analysis
in practice, approving proposals solely on the basis of their relative priority may not be feasible, due to various resource constraints. accordingly it is good practice to fine-tune project approvals to take into account the availability of limited resources, such as capital and recurrent funding, and scarce skills, such as staff needed for iCt development and testing, and the development of legislation and regulations.
SECTION
2
31
Accountability and authority

Better Practice results: Having effective arrangements for project accountability aids in the implementation of projects as planned particularly for projects using resources from across organisational boundaries and increases the prospect of expected business outcomes being achieved.
Achieving planned project results is assisted by: having an appropriate coverage of accountability across organisational boundaries, over programs of related projects, and over both project products and expected business outcomes; and properly matching accountability with authority over the necessary resources.
Managing project responsibility across boundaries

Projects will often require the cooperation of different business units within an entity, as well as external parties. For example: business units with national responsibility for programs; regional office networks; call centre operations; ministerial task forces; inter-departmental committees; and areas responsible for ICT development, ICT infrastructure operations, and ICT strategy. However, an entitys accountability arrangements may focus on accountability within the units of the organisational hierarchy, with less attention on the management of projects which need to operate across unit boundaries including projects involving parties outside the organisation. It is better practice for entities to have established an organisational culture and principles that support the effective allocation of responsibility and authority for cross-unit projects. In addition, for entities who often undertake projects involving new partners, it is helpful to provide them with practical support on accountability arrangements, such as an induction booklet, and a standard format for an induction briefing. If an entity does not have preestablished arrangements, then time and effort will be needed to establish project-specific arrangements for cross-organisational coordination. This would need to be taken into account in the timeframe, costs, and risk profile of project proposals.
Example: Entity accountability principles for cross-business unit projects

following is an abbreviated example of entity-level accountability principles. the standard mechanism of accountability in the entity is through the management hierarchy and business unit plans. Consistent with this approach, for projects operating across business unit boundaries: The project, and its overall budget, will be approved by the executive committee. A senior responsible officer will be appointed, and the project objectives reflected in their units business plan. The senior responsible officer has authority, following consultation, to negotiate and document work to be undertaken by other business units, together with completion criteria and monitoring arrangements. The senior responsible officer has authority to apportion the project budget between business units, in consultation with the Chief financial officer. this can be fee for service (typically operations staff billing time to the project for analysis, testing and training; and Corporate Services billing for publications and legal costs), or by an earmarked allocation to a partner business unit (typically the iCt development Branch).
32
for projects involving services to be provided through regional office operations, the senior responsible officer will: include an appointee of the Regional Office Committee on the project board; and agree with the Regional Office appointee the criteria for hand-over to ongoing operations.
Arrangements for programs of projects

Significant initiatives will generally be delivered though undertaking a program of individual projects, which collectively will achieve a desired outcome. This Guide focuses on the approval of individual projects. Developing, approving and managing programs of projects is a more complex issue, best built on the foundation of a sound capability with individual projects. When entities are moving to a program management14 approach, it is suggested that this be done in a conscious and methodical way. Useful first steps include: providing training for relevant senior executives on program management issues; conducting a pilot or trial of program management, possibly using external expertise, to help develop the skills and practical experience of the relevant executives and staff in support roles; and pre-preparing committee charters setting out the responsibilities of a program management board. THE DISTINCTION BETWEEN PROGRAM AND PROJECT MANAGEMENT it is often more manageable to treat complex or large undertakings as a program of projects. for example, an entity may undertake an initiative aimed at allowing service recipients access to information on all of their dealings with the entity, regardless of the legislative basis of service provision. this may be treated as a program over several years, with individual projects for each area of legislation. the distinction between programs and projects is not absolute, and will be partly based on what will work well for an entity. Broad distinctions are: Projects Time-limited. Focus on more narrowly defined products. For example, a new payments system. Generally smaller. Scope tends to be fixed, and more specifically defined. Programs of projects of longer duration, possibly ongoing. focus on broader outcomes, which require the coordination of multiple projects over a longer timeframe. Generally larger. Greater flexibility in scope, as the nature and number of individual projects may be adjusted to better achieve broader outcomes.
ENTITY ARRANGEMENTS
Program management focuses on the coordination of a suite of projects, and ensuring that they collectively contribute to the desired broader outcome. this may involve redefining or cancelling current projects, and identifying new projects to better achieve the program goals. in contrast, project management focuses more on the achievement of the stated project objective within time and budget.
14 In this Guide we use the phrase program management to mean managing a program of projects, rather than the alternative sense of managing delivery of a government policy program.
SECTION
2
33
Accountability for project products and business outcomes Unknown outcomes

The audit of 60 business system projects found that most had not measured whether planned business outcomes had been achieved. anao. Program delivery and business projects generally have well defined products, such as a new ICT system, new legislation and guidelines, and trained staff. Allocating accountability for these project products is important and is usually clear. These products will then be used to generate the planned business outcomes, such as improved public access to information, reduced costs, or a new program being provided to agreed service levels. Given that these business outcomes are the real reason for funding the project, it is better practice to also allocate, and document, responsibility for achieving the planned business outcomes.
Example: Accountability for business outcomes

a project has been approved to develop a data matching system which will ensure that payments are being made in accordance with legal entitlements. the project product, or deliverable, is the data matching system which will compare information from several entities (such as payments made to, and declarations of assets by, individuals). the cost of the project has been justified on the basis of expected reductions in incorrect payments. this reduction is the expected business outcome of the project. elements of good practice in accountability for the project include: The project proposal allocates accountability for the business outcome, of reduced program payments, to the Branch head responsible for the program. responsibility for delivery of the system was assigned to the iCt development Branch. The business case includes a measurement methodology to attribute any changes to the value of incorrect payments to the data matching system, and separate that effect, to a reasonable degree of confidence, from other factors such as changes in client numbers and changes to entitlement criteria. The entitys financial and budgeting system makes provision for recording the anticipated reduction in program expenditure.
Arrangements are needed for accountability of both the project products and the business outcomes.
Operational inputs. e.g. Data from various agencies
Data matching system
Reduced program payments (business outcome)
Long- term benefit
Project to deliver the product a data matching system
34
Delegated authority matches responsibility

In addition to descriptions of responsibilities in business plans, project charters and duty statements, entities provide legal delegations of authority for such matters as the commitment and expenditure of public money, and entering into contracts. On occasion there may be a mismatch between the responsibilities assigned to officers responsible for projects and their delegated authority. For example, this can happen because resources and funds are being drawn from many parts of an entity with no single authority to access these resources, or because positions have been created on a project-specific basis and default delegations for the position are not aligned to the requirements. Any mismatch of responsibility and authority has the potential to delay projects, or to weaken accountability. It is better practice to match responsibility and authority, while providing appropriate segregation of duties (for example, to provide checks and balances on expenditure). If necessary, resolving any mismatching as part of the entitys general arrangements for financial delegations will help set a foundation for improved project implementation.
Data stewardship
Better Practice results: Reduced incidence of data integrity and ownership problems; successful retirement of, or integration with, legacy data stores.
ENTITY ARRANGEMENTS
Most program delivery and business projects involve the processing of data. The data may be stored and used for many years. It may be initially captured and stored for one purpose, but subsequently be of interest for other purposes. As a result, there are often complex issues surrounding data ownership, privacy and definition. More generally, data is a valuable organisational asset which requires protection, and control over its quality. Subject to consideration of data ownership and privacy, an entitys collective data holdings may provide opportunities to better inform policy making and improve program delivery and client service. In that context, an important contributor to effective planning and approval of individual projects is that an entity has effective governance arrangements for the data it uses both the data held by the entity and the data it needs that is held by other parties. It is better practice that: there are corporate policies to assure that data requirements are identified, and any restrictions on data use are specified; responsibilities for entity-level oversight of the collection, management and maintenance of data are allocated; and planning processes for projects involve those responsible for the data being used by the project, and include consideration of the potential usage, updating, protection, and archiving of the data.
As well as shared data, some entities have business processes used by more than one program or business function, such as making payments, receiving grant applications, and registering a client. Particularly for larger entities, explicit governance of shared business processes helps contribute to the effective planning and approval of projects.
SECTION
2
35
Financial management
Better Practice results: Executives are aware of the full cost of projects as they are implemented; full cost information of previous projects is available to inform preparation of new project proposals.
Projects often use resources from many parts of an entity, and also externally. Good practice is that all these costs are reflected in the project cost-benefit analysis included in the project proposal. For example, there may be costs associated with entity staff from several business areas and from ICT development; as well as payments to suppliers to the project. In addition, financial benefits for a project may be reflected in several parts of the entitys forward budget such as changes to staffing costs in different business units or changes to program expenditures. The potential complexity of properly tracking all these costs and benefits means there is a risk that the project sponsor is not able to measure actual performance on the same basis as the project business case. It is better practice that there are sound arrangements and systems to estimate and measure the costs and benefits of projects, over the full duration of the projects. This will usually take the form of: an accounting system, that will allow budgeting and costing to both organisational units and to project codes; advice and assistance from the entitys Chief Financial Officer and finance team; accounting rules; and associated training and monitoring to help ensure appropriate data entry on projectoriented data.
Preferably the accounting system will allow these planned costs and benefits to be accounted for over the life of the project, and for actual costs to be allocated accordingly. As well as allowing effective monitoring of current projects against their plans, accurately recording actual project costs will assist in estimating costs of future projects. Accounting rules relevant to projects include properly accounting for any assets created by the project (including capitalisation of software and other intangible assets), and arrangements for internal charging of support and services which are project-related. In addition to providing support at the entity level, there are financial management aspects to setting up individual projects particularly cross-boundary projects which are discussed at page 77 in Chapter 3.
36
Monitoring and reporting

Better Practice results: Project proposals are developed to aid their subsequent monitoring, which contributes to effective control and improved project success rates.
Entities generally have arrangements for monitoring and reporting on the performance of organisational units. Similarly, it is better practice for entities to have established arrangements for the effective monitoring and reporting of projects. Having such arrangements established at the entity level assists in the effective approval of projects by providing a framework for performance reporting which can be incorporated into project proposals.
Operational inputs
Project products
Business outcomes
Long-term benefits
Implementation Approval Business case Monitoring and governance arrangements for the implementation stage should be documented in the business case for approval
ENTITY ARRANGEMENTS
Concept plan
Elements to consider for inclusion in an entitys project monitoring framework, taking into account the importance and degree of risk of projects to the entity, include: A standard reporting format for individual projects preferably with a standard cover sheet highlighting key issues for management information and decision-making. Common reporting elements include whether the project is on track to achieve intended outcomes, progress on deliverables in relation to time and cost, any risks that have eventuated and the response, requests for scope variations, and indicators for quality, stakeholder relations, project team availability and morale. Standard terms of reference for project boards, including related practices such as project monitoring arrangements. Guidelines for escalating issues to appropriate levels of management. Where relevant, arrangements for reporting on programs of projects. Arrangements for appropriate quality assurance of project reporting information. In many cases straightforward internal review is sufficient (for example, having financial data come from the central financial system, or having system testing results agreed by the ICT and user area). For large or high-risk projects, periodic independent assurance may be warranted. Arrangements to identify which projects, or programs of projects, should be regularly reported to the entitys executive, and the method of reporting.
For larger entities, a central Project Management Office can assist project sponsors, project leaders, and senior management with the coordination of project reports. References for more detailed advice on better practice arrangements for project management are provided in Appendix H Additional sources of information at page 115.
SECTION
2
37
2.4 Addressing common APS requirements
Project
Common APS requirements, such as those for procurement, ethics and probity, and recordkeeping, are important contributors to project success and to proper accountability. Procurement specialists a valuable partner:
I talked with our central procurement team as we were developing the business case. They were very helpful in setting up the timelines for procuring equipment and systems, and told me about some services that were already available on a panel. Later, implementation went smoothly too, because the procurement area already knew about our needs and had included us in their own work plan. Project team leader.
Procurement
Better Practice results: Project-related procurement provides the required goods and services as needed, and in accordance with legislative accountability requirements.
Many projects will involve procurement activity, which needs to be carried out in accordance with the Commonwealth Procurement Guidelines (CPGs). Compliance with the CPGs can be assisted by entity project planning guidelines reminding project proponents of the circumstances where open tender should be used, and the procedures to be used. Such reminders will help project planners include the timeframe and budget for the appropriate procurement method, and to schedule the preparation of procurement documentation. Specific procurement issues are mentioned at relevant points in Chapter 3, on developing individual project proposals.
38
Behaving ethically
Better Practice results: Increased confidence in the reliability of advice provided to decision-makers; projects are not delayed due to ethical lapses.
All those involved in the project planning and approval process have a responsibility to behave ethically at all times. Ethical behaviour supports openness and accountability in a decision-making process, which increases the confidence of stakeholders in the probity and effectiveness of the decision. Ethical behaviour can also reduce the cost of managing risks associated with fraud, theft, corruption, and other improper behaviour, and can also enhance confidence in public administration. For those staff employed in entities subject to the Public Service Act 1999, the standards of conduct required are contained in the APS Values and the APS Code of Conduct. Entities are encouraged to have general arrangements to assist in managing issues ethically, such as declaration of pecuniary interests by executives, and including conflict of interest clauses in standard contracts for engaging advisers. In addition those involved with planning, recommending and approving projects should be alert to issues and situations that involve judgements about ethical behaviour and practices. Some ethics-related issues in planning and approving projects are listed in the following table. ISSUE Potential conflicts of interest for expert advisers POTENTIAL TREATMENT(S) review standard contracts for appointment of advisers to ensure the contracts require actual and potential conflicts of interest to be declared; guidelines to specify a declaration concerning potential conflicts of interest be provided with each new project. Committee terms of reference and letters of appointment clarify roles, for example whether members are representing a sectional interest, or providing their own professional opinion. education of team involved in preparing proposals on aPS values and on the Commonwealth Procurement Principles, including a non-discriminatory approach so all potential suppliers have the same opportunities; use of independent assurance at key stages of proposal development. develop entity protocols and relationships with representative bodies to undertake consultation ethically.
ENTITY ARRANGEMENTS
Lack of clarity of role for members of committees
Solution shaped inappropriately to favour a particular supplier or approach
Those involved in confidential consultation may feel this has led to a potential conflict of interest with their stakeholders
SECTION
2
39
Keeping records
Better Practice results: Records of approvals, project specifications, and agreements with other parties are available to provide clear authority and direction for the project, and to meet accountability requirements.
Records that are created and received in the planning and approval process, whether paperbased or electronic, should be captured in an entitys recordkeeping system(s) in accordance with the entitys general recordkeeping policies and procedures. A systematic approach to recordkeeping at the beginning of a planning process and throughout the contracting cycle will assist an entity to: provide evidence of business conducted and decisions made; manage legal and other risks; and meet its accountability obligations.
Keeping good records should be seen as an integral part of, rather than incidental to, the planning process. A particular issue for attention is recording decisions to approve projects. It is better practice for entities to have arrangements for recording the scope of the project approved, any caveats to the approval,15 and who gave the approval. The ready availability of this information is of importance to those implementing and monitoring the project, and to any subsequent evaluation. For accountability and audit purposes it is also important to retain the information used as the basis of decisions. For many projects, key planning documents such as the project plan and project specifications may change during the life of the project. It is better practice for entities to have a document change control system and work practices that provide for version numbered documents, and arrangements to record the approval of changes from one version to the next.
15 The recording of project approvals is discussed, in the context of individual projects at page 81, and an example of a project approval statement given in the appendices at page 107.
40

The following better practices focus on specific elements of entity management that have a direct bearing on the effectiveness of project planning and approval. They are not an exhaustive list of management and entity planning practices. This Guide assumes a basic level of corporate and business planning is in place.
n n n n
The entity promotes understanding in executives and staff of the practical implications of the entitys business strategy, which informs the development of project proposals. (page 12) Relevant corporate goals have tangible indicators, which allow the potential contribution of projects to be clearly established. (page 13) Senior executives understand the key elements of the entitys ICT strategy and architecture. (page 14) The entity promotes an understanding by executives of government-wide ICT and program delivery policies and the implications for the entity. (page 16)
ENTITY ARRANGEMENTS
n n n n n n
There is a pool of executives with strong aptitude for oversight of projects, including those with significant ICT components. (page 17) Entity executives foster a culture of mature engagement with risk: candid identification, effective mitigation or responsible acceptance, and regular monitoring. (page 18) The entity has the culture and arrangements to deal effectively with the inherent uncertainty of project estimates at the early stage of planning. (page 20) The entity has a sufficient pool of people with the skills to effectively plan and assess the feasibility of projects. (page 20) Entity staff involved in project planning have a shared understanding of the concepts used to define projects, such as project deliverables and products, scope, business outcomes, and long-term benefits. (page 21) The entity culture is open to independent assurance at key project stages, and there is practical support for such activities. (page 22)
SECTION
2
41
n n n n n n n n n n n
Committees and processes are designed to give all elements of a project proposal competent review, with a clear definition of advisory and decision-making roles. (page 23) There is sufficiently broad representation in planning and approval processes. (page 27) There is an effective approach for the screening and prioritising of project proposals, which is understood by those preparing project proposals. (page 28) There are accountability mechanisms for cross business unit and cross entity projects. (page 32) There are mechanisms, where relevant, for managing programs of projects. (page 33) There are accountability mechanisms for delivery of the products of the project. (page 34) There are accountability mechanisms for achieving business outcomes expected from the use of the products of the project. (page 34) Key project roles have powers appropriate to their responsibilities. (page 35) The entity has allocated responsibility for stewardship of its own and shared data. (page 35) Financial management arrangements and systems provide sound support for estimating and reporting the costs and benefits of projects. (page 36) There are arrangements for the effective monitoring and reporting of projects. (page 37)
2.4 Addressing common administrative requirements
n n n
There are established entity arrangements to provide procurement advice to those preparing project proposals. (page 38) There are established entity arrangements for identifying and managing potential conflicts of interest in decision-making and in advice provided. (page 39) There are arrangements for appropriate recordkeeping, including recording the scope of the project approved, of any caveats to the approval, who gave the approval, and any subsequent approvals of variations. (page 40)
42
this chapter describes better practices for executives when involved in developing project proposals and in approving projects.
Contents:
3.1 Clarifying the concept (page 45)
developing project PROPOSALS INDIVIDUAL PROJECT proposals

approving projects
3.2 Ensuring feasibility: the business case (page 54) 3.3 Approving the project (page 78) Key better practice summary (page 82) Appendix F Questions for executive review of project proposals (page 110)
44
3: Individual project proposals

The previous chapter described better practices at the entity level to support the planning and approval of projects. This chapter sets out better practice for: project sponsors, in developing a project concept, and then developing a project business case; and executives involved in project approval: the decision-maker, and members of assessment committees.
Much of the detailed work of project planning and review is done by non-executive staff. The important role of executives in planning and approving projects encompasses setting directions, reviewing and confirming important aspects of the proposal, applying their strategic perspective and leveraging their relationships with stakeholders. The project sponsor is responsible for the quality of the proposals they endorse, and will normally be accountable for delivering the planned outcomes if the project is approved.
PROJECT PROPOSALS
The decision-maker is responsible for effective consideration of proposals, and the approval of projects so they make an effective and efficient use of resources. The better practices described in this chapter should be applied by executives as appropriate to the size, complexity, risks and potential impacts of the projects they are planning and considering for approval.
SECTION
3
43
Structure of this chapter:
3.1 Clarifying the concept

Broad planning context Business outcomes High-level requirements
Checking the concept plan
3.2 Ensuring feasibility: the business case

Important aspects of the business case Oversight of business case preparation Outcome and cost Project requirements
Options
Risk and assumptions
Operational requirements
Communication
Implementation approach
Project governance and control
Issues for cross-boundary projects
3.3 Approving the project

Informed decision-making Key project controls

A checklist-style summary of better practices described in this chapter.
44
3.1 Clarifying the concept
Operational inputs
Project products
Business outcomes
Long-term benefits
Implementation Approval Business case
Concept plan
The concept plan helps clarify, test and define the intent of the project
Given the relatively high cost of preparing business cases with firm costings and timeframes, it is generally preferable to prepare proposals for projects on a progressive basis that is, in a series of proposals of increasing detail.
The first step in progressive planning is a short project concept plan. The concept plan can be brief one page, or a few pages. The brevity of the plan helps focus attention on its central issues. The concept plan helps to establish that: the project is developed taking account of the broader context, and contributes as much as practicable to entity and government objectives; the key business outcomes of the project are clearly articulated; and the project deliverables are necessary and sufficient to lead to the desired business outcomes.
PROJECT PROPOSALS
The concept plan may also be useful in explaining the concept to stakeholders and gaining their views of the proposal. At the entity level, the preparation and circulation of project concept plans helps provide early notice of projects and assists the entity in coordinating all its projects and resources. An example of a concept plan is provided in Appendix C Sample project concept at page 104.
SECTION
3
45
Broad planning context

A broader perspective gives broader opportunities
Adopting a fresh and broader perspective is the easiest way to identify innovative opportunities when planning a change to your business. For example, consider how your usual approach looks if you stand in the shoes of your customers or in the shoes of your competitors. Business adviser.
Better Practice results: At an early stage, project planning addresses the potential contribution of projects to broader entity strategies, takes account of emerging technical opportunities, and is consistent with broader government directions.
Most major projects aim to achieve enduring and significant change to program delivery and entity operations; and most leave an enduring legacy of data, systems and regulations. This suggests it is prudent to prepare project proposals within a broad context. Doing so will help ensure that projects fit well with the broader APS environment, and are contributing to entity goals. Better practices for project sponsors, to encourage effective planning in a broad context include: making themselves available to project teams for planning sessions of potential projects; bringing to bear their broader knowledge of policy directions and program delivery strategies including cross-entity delivery models; encouraging a sufficiently broad scope for the project for example including policy changes, new legislation, and associated ICT work; discussing with relevant experts the opportunities, and risks, of emerging technologies so that concept planning can consider a degree of innovation; and identifying, and then actively maintaining, external relationships relevant to the project so their perspectives can be addressed during early planning.
Senior involvement pays dividends

The Deputy Secretary coming for two hours to our planning day for new policy was really useful. She helped us broaden our thinking, and brought us up-to-date on the perspective of central agencies. In particular we made a major change to one proposal so the ICT system could be shared with another agency. Policy branch head.
As discussed earlier, it is important that project sponsors have a high-level understanding of their entitys ICT architecture and strategy, and use this to place project proposals that have a significant ICT component in that context. This may suggest useful ways to describe major project deliverables, or ways in which the project could contribute to broader strategies. Practical steps to help broaden and clarify the planning context include:16 clarifying the need, problem or opportunity so issues can be framed in the proper context; bringing together the best available evidence base; developing insights from fresh consideration of the basic questions of: Where are we now? What is the desired end-point? How do we get there?; and undertaking early and active engagement with citizens, clients and stakeholders, to provide new ideas and perspectives.
Many projects are tactical and thats okay

In practice, I find it best to be selective in advancing strategic goals. I accept that most projects deliver useful, specific outcomes which are consistent with, or maintain, corporate goals. I then look for a few projects that help advance new strategic capabilities. agency Chief information officer.
16 Adapted from Chapter 4 of the Better Practice Guide Innovation in the Public Sector, Australian National Audit Office 2009.
46
Business outcomes
Better Practice results: No misunderstandings with stakeholders, including the Minister, on the intended business outcomes of proposals; improved ability of senior executives to manage their portfolio of projects, due to clarity of outcomes for individual projects.
The business outcomes of a project justify the commitment of resources and provide a key focus for project design and delivery. As such, an important area for attention by the project sponsor is ensuring that the proposed business outcomes are: clearly described in business-oriented terms, indicating who will benefit for communication to the project funder and other stakeholders; able to be measured or assessed and indicate the intended extent of improvement or target level of performance; few in number to help focus attention on the most important outcomes; and realistically able to be achieved by the project.
Focusing on key outcomes

Previously, our project proposals had long lists of outcomes including many generic outcomes such as efficiency, compliance, and scalability. It happened partly because we adapted new proposals from ones approved in the past. However, the new Deputy Secretary bounced a proposal, saying Put the two or three key business outcomes on the cover these are the reason the Minister should support the project. Put the standard outcomes at the end. The Minister is entitled to think we do them as a matter of course. Giving clear prominence to the outcomes of interest to the Minister forced us to tighten up our thinking. Our proposals are much better for it.
To help develop business outcomes with these characteristics, it is useful for the project sponsor to: maintain awareness of possible areas of difficulty in developing business outcomes; explore and confirm the underlying reasoning such as the flow of cause and effect associated with the project; use an understanding of the flow of cause and effect between project elements to identify important and realistic outcomes for the project; and make a strong personal contribution to the process.
These issues are discussed below.
Program delivery branch head.
PROJECT PROPOSALS
Possible areas of difficulty in developing business outcomes

As discussed earlier, in this Guide we use the term business outcomes to refer to the reasonably attributable outcomes from the use of the products of the project. For example, the desired business outcome from a new ICT system might be reduced operational costs, or improved client service. Although achieving clarity of the desired business outcomes may appear straightforward, in practice difficulties can arise from: Different values different stakeholders may value outcomes differently. For example, one stakeholder may consider the priority outcome for a project is improved customer service, while another may give priority to reduced entity costs. Different terminology or perspective different people may apply different descriptions to the same idea or feature. For example, the making of payments might be considered by one person as an outcome of a new payments system; another person might consider making payments as an input to a desired outcome of changed behaviour by the recipients of the payments. Indeed, choosing to expand or reduce the scope of a project can change the terminology applied to the same idea or feature. Ambiguity of expression a desired outcome may not be expressed clearly enough to give the same understanding to different people.
SECTION
3
47
Exploring the reasoning of the project The best outcome description may evolve slowly
At the concept stage getting outcome clarity is important. Be patient in a complex project it may take some time to evolve a crisp definition. For each project we prepared draft business outcomes and then debated each one until we had informed agreement from all agencies. executive director, program of cross-agency projects. At its simplest, a project delivers a product which, when used, leads to a desired outcome. In practice, the chain of reasoning is more complex, involving intermediate steps, uncertainty on the strength of cause-and-effect between these steps, and with a number of options to consider. Accordingly, the concept stage is an opportune time to make explicit the underlying reasoning or logic of the elements of the project. Making explicit the underlying reasoning helps to achieve a shared understanding among stakeholders, and to clarify the business outcomes. At the concept stage, the focus is exploration of broad outcomes and their enablers. It is useful to consider alternative perspectives on the desired outcomes, and innovative approaches to reaching them. More detailed consideration of specific solutions is best undertaken at the business case stage. By way of example, consider a project to implement a new policy initiative which will make payments to assist individuals, with social benefits being the ultimate goal. The diagram at left shows the central reasoning behind the design of the initiative for this example. The first step of the chain is that awareness of the new scheme is created in order to encourage eligible people to make claims. The chain of reasoning proceeds to a social benefit such as reduced welfare dependency. A benefit of exploring the chains of reasoning associated with a concept is that it encourages questioning of the reliability of the reasoning for example: Is awareness of a scheme really the main determinant of the number of claims? How important is the ease of making claims? In turn, this questioning often opens up new possibilities for discussion, and may add new segments to chains of reasoning. In many cases a high-level goal will have been identified such as reducing administrative costs and the task at the concept stage is to clarify what that means and how to achieve it. This will involve working backwards from the desired outcomes to describe the underlying logic of the concept. In some cases, such as a policy implementation project, a relatively complete underlying logic will have been described, and the task at concept stage is to clarify the scope of the project. Finally, in some cases major elements of a project may be determined by circumstances, such as the end of an accommodation lease. In these cases there is often an opportunity to explore which of several possible outcomes might be emphasised. This will involve working forwards from the known activities to the potential outcomes. For example, a project to move to new accommodation at the end of a lease could be seen primarily as an opportunity to reduce costs, to improve customer service, or to be a more attractive employer. While all these outcomes are desirable, in practice the business context for the entity is likely to give emphasis to one of them.
A reasoning chain for a program delivery project: 1. Awareness created
2. Claims made
3. Claims assessed
4. Payments made
5. Behaviour changed e.g. increase education
6. Social benefits e.g. reduced dependency
48
Identifying important and realistic outcomes

Having established the broad logic of the concept, the next step is clarifying the scope of the project. That is: what point along the chain of reasoning should be considered the business outcome of the project? In the previous program delivery example, one scope could limit the project to the processing of claims; an expanded project scope could also include creating awareness about the scheme. Selecting a project scope may involve a fine judgement. The decision-maker will often prefer to set an outcome that is of direct value to them such as reduced costs, rather than an outcome that simply makes that possible such as a new computer system. On the other hand, some items along the reasoning chain may only be partly attributable to the project, because they are affected or controlled by other factors. This is illustrated in the following diagram.
More attributable to project activities
less attributable even if not in scope, it is important to keep sight of the underlying policy objective when planning the project.
A useful business outcome is the last step along the reasoning chain that is clearly attributable to the project.
External factor e.g. demand for exports
New legislation
Number of payments
PROJECT PROPOSALS
New ICT system
Increased employment rate
Greater self reliance
Useful business outcome: attributable to controllable factors, measurable, reasonable value to decision-maker
Less useful business outcome, as affected by an external factor
Reasoning chain and possible business outcomes for a project In many cases, a useful business outcome is the last step along the reasoning chain that is reasonably attributable to the project.17 Choosing a point further away from a high-level goal as an outcome increases the risk for the project funder that their goal is not achieved due to some necessary step not being part of the project. Choosing a point beyond the limit of reasonable attribution to the project as an outcome creates a situation where the project sponsor is being held responsible for an outcome beyond their control. In addition, the project funder will be disappointed if external factors result in the outcome not being achieved.
17 In some cases, additional elements along the reasoning chain may be identified as required business outcomes for sub-projects of the overall project. These are useful as early indicators of progress.
SECTION
3
49
Possible business outcomes in the reasoning chain for a program delivery project:
Continuing the previous example of a program delivery project, choosing the new payments system as the business outcome is overly narrow as it focuses on a project product which provides value only through its usage. Alternatively, nominating the business outcome as increased economic independence of the target group is overly broad. While this social benefit may be the ultimate reason for approving the policy it is likely to be affected by other causes, and it would be unreasonable to hold the project accountable for achieving it. In any event the social benefits arise primarily from the program expenditure and not from the expenditure on the project itself. A reasonable business outcome for this example is along the lines of Prompt and accurate assessment of claims and payment of entitlements to the eligible target group.
1. Awareness created
2. Claims made
3. Claims assessed too narrow
Project sponsor responsibilities

Given their responsibility for proposed business outcomes, it is better practice for project sponsors to: make themselves available to participate in concept planning discussions; encourage a degree of questioning and innovation in exploring what business outcomes will be most useful for the project concept; understand, and be able to explain to stakeholders, the business outcomes of the project in particular, this includes being able to distinguish between the accountable business outcomes of the project, and the anticipated consequential effects which are also of interest to stakeholders so as to avoid possible confusion and unrealised expectations; and use their broader knowledge to help align the outcomes to the goals of government and stakeholders, and assist the project team focus the proposal on these issues.
4. Payments made attributable, valuable
5. Behaviour changed e.g. increase education
6. Social benefits e.g. reduced dependency too broad
Clarifying business outcomes may seem simple, but can be subtle and time-consuming. However, with a skilled adviser and the right people involved, a useful set of business outcomes can be identified in a reasonably short time.18
18 There are many related methods which help explore the underlying reasoning for projects, such as the Outcome Relationship Model of MSP, and the Investment Logic map used in the Victorian Government Investment Management Standard. See Appendix H Additional sources of information at page 115.
50
High-level requirements
Better Practice results: Confirming that the project requirements are sufficient to achieve the planned outcomes avoids wasted planning effort on proposals which turn out not to be feasible; and reduces the risk of unrealised expectations among stakeholders.
Having achieved clarity on the intended business outcomes, the next step is to identify, at a conceptual level, the major project requirements. Project requirements describe what needs to be achieved. In the business case, project deliverables will be specified that are needed to fulfill the requirements. For example, if an expected project outcome is a significant reduction in the time taken to reply to ministerial correspondence, the high-level project requirements could be a method to speed the drafting of replies (potentially, a system allowing access to previous replies), and a method to speed the approval of replies (potentially, a system for electronically transferring replies for approval). It is important to gain confidence that the proposed requirements for the project are both necessary and sufficient to deliver the outcomes: Focusing early on requirements, and not project deliverables, helps avoid the trap of approving a solution that is in search of a problem. ... Chair, investment committee.
CHECKING NECESSITY Why: Helps avoid unnecessary cost. How: For each project requirement, ask To which business outcomes does this requirement substantially contribute? Tips: Take a stringent view on the extent of contribution. During discussion, it can be helpful to identify the particular way in which the contribution is made, and the particular stakeholder involved. For example: The new database search system (project requirement) will be used by call centre staff to answer queries about any client and any program (desired business outcome).
CHECKING SUFFICIENCY Why: Helps assure outcomes achieved. How: For each business outcome ask Are the identified project requirements sufficient to fully realise the outcome? Tip: It is sometimes easier to consider what the prerequisites for the outcome are, and see if they are covered by the requirements. For example: The prerequisites for being able to answer queries about any client and any program (business outcome) are a new database system, staff training, and new privacy protection mechanisms (needed project requirements).
PROJECT PROPOSALS
At this concept stage, both the requirements and outcomes will be described at a summary level and the assessment of necessity and sufficiency will involve a degree of judgement. The objective is to gain confidence in the underlying logic and scope of the proposal, before proceeding to more detailed solution design. A key responsibility of project sponsors is to have confidence that planned project requirements are both necessary and sufficient for the outcomes. They can help gain this confidence by: contributing their own ideas for, and reviewing the completeness of, the proposed project requirements to achieve the planned outcomes; encouraging broad involvement in planning sessions, and considering the use of independent facilitation and input; and keeping the project team focused at a concept level at this early stage, to avoid premature consideration of detail.
SECTION
3
51
Example: Project requirements at concept stage

the diagram below shows a simplified set of high-level outcomes and associated requirements for a project aimed at improved document management and recordkeeping. the arrows indicate a strong contribution from a requirement to an outcome. Such a diagram can be used to check that proposed requirements are necessary and sufficient. a table format can also be used, with requirements and outcomes used to label the rows and columns, and the contribution of a requirement to an outcome shown in the corresponding cell.
High-level project requirements
High-level project outcomes
A. Staff awareness of recordkeeping rules
1. Improved compliance with recordkeeping
B. Compliant storage system
C. High ease of use
2. Improved quality of work, such as submissions
D. Reliable search function system
E. Limit on purchase and operational costs
3. Cost neutrality (over five years)
52
Checking the concept plan

The final step is for the project sponsor to review and approve that the concept plan is of sufficient quality to proceed. Useful points for review are that the plan: indicates how the project contributes to broader entity goals for example client satisfaction, entity flexibility and capability, cost control, and enabling staff; communicates accurately and effectively the high-level business outcomes and associated project requirements; has support, as appropriate, from stakeholders; and has a sound underlying logic that is, the project requirements, at the current summary level, will reliably lead to the desired outcomes.
In addition, if during the concept planning process any significant assumptions, risks or constraints have been identified these should be recorded in the concept plan.
Executive check of concept plan Logic the requirements will deliver the outcomes Contribution of outcomes to broader goals
PROJECT PROPOSALS
Operational inputs
Project products in operation further planning and approval; project implementation
Business outcomes
Long-term benefits
high-level project requirements in concept plan
Clarity of expression Support from stakeholders and decision-makers of the high-level outcomes and requirements
With informed support and understanding of the concept, the next step is preparation of a business case seeking funding. Depending on the entitys internal processes, the decision to invest effort in a business case may be taken by the project sponsor, or may require approval centrally within the entity.
SECTION
3
53
3.2 Ensuring feasibility: the business case
Operational inputs
Project products
Business outcomes
Long-term benefits
Implementation Approval Business case The business case seeks approval to proceed to implementation and the delivery of new capabilities or products which will reliably lead to the desired business outcomes.
Concept plan
The project sponsor uses the business case to present clear, concise and compelling reasons to the decision-maker for funding of a project.
A business case, particularly for a large project, typically has a great deal of information, such as project background, purpose, scope, assumptions and costs. From a senior management perspective, there are four major logical components of a business case: The reason for the project, to assist in judging the relative priority of the project against other organisational objectives, and to focus the project team during implementation. Preferably, the concept planning stage has already clarified the underlying reason. The specification of the project, which clearly and completely describes what is to be delivered, the overall time and cost limits, and the business outcomes those deliverables enable. Validation of the project specification and implementation plan: that is, checking that the specific plan put forward is the most appropriate. This includes assessment of options and their relative merits, risks and their management and mitigation, and additional detail and justification of the proposed cost and timeframe. The implementation approach, described in sufficient detail to provide confidence that the project is in fact achievable, and to set a means for assessing and monitoring implementation progress.
The project sponsor is accountable for the business cases they endorse. Given the complexity of many business cases, the responsibility of the project sponsor during this stage is generally focused on: the appointment of competent staff to develop the business case, and oversight of the development process (discussed in the next sub section); and advising on, and approving, important aspects of the business case (discussed in the subsequent sub-sections).
54
Oversight of business case preparation

Better Practice results: Effective oversight by the project sponsor of the development of the business case helps target the project more precisely, enhances the reliability of the business case, and builds stakeholder interest and support.
The project concept plan, as described in Section 3.1 of this Guide, will have established the broad business outcomes and requirements for the project, and confirmed the underlying logic of the concept. However, the costs and benefits will not be accurately quantified. The business case will develop cost and benefit estimates of sufficient reliability to inform the project sponsor and decision-maker. This involves preparing more detailed descriptions of the project requirements, developing options for specific deliverables to fulfill the project requirements, assessing and managing risks, and considering how to manage and control implementation. The business case should be fit for purpose the level of detail and effort involved should be in proportion to the size, complexity, risks and potential impacts of the project. The project sponsor has responsibilities: at the commencement of developing the business case; for specific contributions and oversight of the process during development; for gaining appropriate assurance on the project proposal; and for endorsing the business case for consideration by the decision-maker.
Specialist skills count
Commencement of business case development

Typical steps for the project sponsor at the commencement of developing the business case are to: Confirm the broad concept and scope of the project. Appoint a person with responsibility for developing the business case. This would generally be a person from the business area who may engage specialist resources to assist. Consider which stakeholder groups should be involved in developing the plan, and commence engaging them. Agree with the business case developer the issues on which the sponsor will be personally involved. This will vary depending on the project. Common issues for sponsor involvement are discussed in the next sub section. Agree with the business case developer which specialist skills may be needed to provide confidence that the content of the business case is reliable. Assess the possible application of approval requirements from outside the entity, such as application of the ICT Two Pass Review process or Gateway Review process. These are discussed in Appendix B Related government policies (page 102). Gain an understanding of the entitys procedural requirements for the business case, including timetable, format, and involvement of third-parties in quality assurance. Gain confidence that arrangements are in place to meet common administrative requirements such as probity and recordkeeping.
We had been asked at very short notice to pull together the business case to deliver a new program. We had not previously delivered a program like this before, but we otherwise had the right infrastructure to be the delivery agency. We approached an agency that had run a program with similar features before, that provided one of their business process specialists to work on our business-case team. He identified some important business requirements that we had not thought of, and helped with estimating the time and cost to meet those needs. That was a major contribution to our successful implementation in a very short timeframe.
PROJECT PROPOSALS
Program branch head.
SECTION
3
55
Inefficient planning effort

The team spent $200 000 preparing the business case. It was detailed and well argued. They had undertaken a lot of research and effort on refining the costs and benefits. However, it was mostly wasted effort. Even on their early rough figures it would have been plain that we would not be able to fund the project. The executive in charge would have been wise to bring those rough figures to the Investment Committee as soon as they were available. agency Chief operating officer.
Project sponsor involvement during preparation of the business case

The processes followed in preparing the business case will vary depending on the size and complexity of the project. For a small or straightforward project, it may be a matter of undertaking the necessary work of documenting the project objective, background and assumptions, adding a level of detail to the requirements and project deliverables, assessing and responding to risks, and undertaking cost-benefit analysis for the status quo and the proposed solution. In other cases, there may need to be considerable exploration, including variations of the project requirements and delivery approaches. The advantages and disadvantages of a range of different project structures may need to be assessed to identify a project definition that has the best balance of cost-benefit, risk, and delivery timetable. This exploration process can mean that the various elements of the business case are developed in an iterative manner,19 rather than linearly. In short, the clear logic of the final business case may be arrived at by a much more complex, exploratory process. In this context, common areas for project sponsor involvement during development of the business case are: providing enough time and resources for the business case to be of the quality and accuracy appropriate to the size and risk of the project to be effective and efficient the planning effort should be targeted at the issues most relevant to project approval; reviewing status and progress in particular, if it emerges that preparing a detailed business case will be expensive it may be preferable to prepare a more limited business case, to gain approval of the expenditure to prepare a more accurate proposal; maintaining a close relationship with senior stakeholders typically to help clarify priorities, major requirements and constraints, and to remain aware of their degree of commitment to the project; and being readily accessible to the planning team, for example to provide guidance on: project requirements, as they can significantly affect cost; constraints; options to be developed; risks and assumptions at a strategic level such as the policy environment and organisational directions; external relations and communication issues; and implementation priorities (see more detailed discussion of these issues in the following pages).
19 This iterative approach is also a result of many elements of the business case being interdependent. To aid the reader the following sections include cross-references between related elements of the business case.
56
Gaining assurance
As discussed in Chapter 2, common causes of shortfalls in projects are over-optimism on the likely time, cost and benefits, and insufficient testing of project risks and assumptions. To help address the risk of some planning elements in the business case not receiving sufficient review, it is useful for the project sponsor to consider the potential benefit of seeking independent assurance or advice on the information being included in the draft business case. The extent of any independent review should be suited to the size, costs and risks of the project. Undertaking independent assurance activities during project planning allows any such issues to be addressed early by the planning team. Some elements of a business case may require specialist knowledge to gain reasonable assurance, or may represent a major area of risk. These elements may benefit from targeted assurance activities. Such elements include: project costing, ICT development feasibility and timetable, legal and legislative drafting aspects, security and privacy issues, the adequacy of risk identification and inclusion of risk mitigation activities and allowances, the breadth of implementation options, and identification of and response to likely stakeholder issues. An independent review may also assist the project sponsor to decide whether a project business case is sufficiently well developed to be submitted for funding consideration. Such independent assurance can be obtained from a number of sources: an external consultant; an entitys Internal Audit area; a person from another part of the entity, or another entity, who is independent of the project; or use of the Gateway Review process.20
Independent review helps project sponsor

Some of my colleagues are nervous about independent reviews, such as the Gateway process. But having done several I now think they are an essential quality assurance step for me as project sponsor. I know my team have given me their best advice, but a fresh set of eyes often finds something we have not been focusing on, or settles the importance of some nagging concern. The main thing is that I want to know any bad news now when it is easier to address and not later. agency Chief technology officer.
PROJECT PROPOSALS
20 The Gateway Review process is required for certain large APS projects. The process is described in Appendix B Related government policies at page 103.
SECTION
3
57
Tips for conducting independent assurance activities

Be clear about the scope of the assurance activity for example, to assess whether a business case is sufficiently sound to be submitted for consideration, or the feasibility of a particular technical aspect of a proposal. Promote a learning perspective on the activity, where the focus is identifying opportunities to improve the current project proposal, and also to learn lessons for developing future proposals. avoid actions such as a focus on blame for any issues uncovered that may reduce the willingness of team members to participate constructively in future assurance activities. Determine in advance the intended circulation of the assurance report. In many cases the most useful result will be achieved if the report is provided jointly to the project team and the project sponsor requesting the review, but is not issued more widely. Wider circulation may detract from a learning perspective for those involved. Set a short but realistic timeframe, to allow decisions to be taken and for any corrective actions to be done in a timely manner. for example, for a Gateway review, an opinion is provided to the project sponsor within a week.
Endorsing the business case The compelling reason

Hiding inside every 50 page business case is a 50 word promise. It should be on the cover. Chair of investment committee. The project sponsor is typically required to endorse the business case prior to consideration by decision-makers. The business case needs to explain why the project is needed, and should clearly set out what will be delivered, and at what cost and timeframe. These fundamental points are best supported by information that gives confidence in the ability of the project to be delivered as proposed. In addition to the normal clearance process of reading and reviewing the document, considering the following questions may provide fresh perspectives on the business case.
58
QUESTION Does the executive summary make a realistic and engaging case?
COMMENT as decision-makers may focus on the executive summary of the business case, it is important that the summary provides an accurate, balanced overview of the proposal and is well argued. the absence of single individual giving assurance of the feasibility of the project described in the business case may indicate there has been piecemeal assurance, with the risk that the overall project is not feasible. Business cases will generally be prepared according to a particular set of requirements, covering the content and format of the document. having a review by an experienced person of the full business case against the requirements can help identity missing or inadequate content. Professional advice on project feasibility will usually include provisos on the opinion (for example: We have assumed new legislation will be passed as planned). it is prudent for project sponsors to be aware of any provisos and decide whether they need to be made prominent, or be re-visited. in many cases, the business case will have involved other parties, such as staff from iCt and finance areas, and external advisers. it can be informative to ascertain their view on the robustness and relative merit of the business case. Consider whether, if the plan is approved, the entity has the capability to implement the plan according to the indicated timeframe. the time taken to acquire resources at project start-up is a common cause of project delay.
Is there an appropriate individual whose professional advice is that the whole project is feasible?
Has there been an independent review of the full business case against the format and content requirements?
Are there any provisos on the assurance of feasibility?
PROJECT PROPOSALS
Do other parties involved with the business case have any reservations?
Does the entity have the capability to implement the plan?
More detailed and specific questions on reviewing a business case from an executive perspective are listed in the better practice summaries at the end of this chapter (page 84), and in Appendix F, part 2. Business case executive review questions (page 111). The following sections discuss particular aspects of the business case being developed. Following development of the business case, the project sponsor will decide whether it is ready to be endorsed, as discussed above.
SECTION
3
59
Important aspects of the business case

The diagram below indicates aspects of a business case of particular importance for executive involvement.21 As indicated in the previous sub-section (page 56), there are strong interdependencies between these aspects. This interdependence means that, to a large extent, the business case needs to be developed as a whole, and that there may be iterative adjustments to the business case as new information or ideas in one area lead to consequential changes in other areas of the business case. Some examples of such interdependencies are: mitigation of identified risks is likely to change the scope or requirements statement; data issues may represent a risk, or require expanded governance arrangements; and the requirements need to correspond with the quantified costs and benefits.
describes the reason for approving the project.
Outcomes and cost
Gives a specification of what is needed to achieve the outcomes.
Project requirements statement
Provides validation of the proposal, for example that risks are addressed and the recommended approach is better than alternatives.
Options
Risks and assumptions
Provides confidence in implementation that the project can be effectively managed and delivered.
Communication
the arrows are intended to illustrate the interdependence of the various elements. in practice there are potential links between all the items particularly those in the lower part of the diagram.
These elements of the business case are discussed in the following sub-sections. A small version of the above diagram, with the current element shown distinctively, is included in the margin of each sub-section as a reminder of the context.
21 This Guide highlights areas for executive attention. The Guide is intended to complement detailed advice on preparation of business cases aimed at action officers, such as the ICT Business Case Guide issued by the Department of Finance and Deregulation. Agencies may use a structure for business cases which varies from that listed here.
60
Outcomes and cost

Better Practice results: Executive involvement improves the relevance to decision-makers of the statement of outcomes and costs, and their reliability.
The statement of proposed outcomes and costs for the project is the heart of the case being put to the decision-maker. The main reason for the detailed work in developing the business case such as requirements analysis and risk analysis is to support a clear and definite statement of the planned outcomes and costs. It is important that the project sponsor ensures that the statement of outcomes, timeframe and costs in the business case: focuses on outcomes and costs of interest to the decision-maker;22 is internally consistent that is, the timeframe and costs are appropriate to the outcomes described; allocates responsibility for expenditure and delivery of outcomes;23 and is at a level of accuracy that is appropriate to allow a prudent investment decision to be made. At its most basic, in the business case the project sponsor is saying to the decision-maker: If you give me these resources, I will deliver these outcomes. You want to make that kind of offer as clearly and as correctly as you can. Project sponsor.
PROJECT PROPOSALS
Providing a description of outcomes appropriate to justifying an investment implies having measureable, or assessable, indicators for the outcomes. In cases where outcomes are difficult to measure accurately, it is a reasonable expectation of decision-makers that suitable proxy measures of success be identified, particularly for more costly projects. To help justify the expenditure, and to evaluate success later, it is good practice to indicate the extent of improvement in the outcomes, or associated performance indicators, expected to be due to the project, and to arrange appropriate measurement before and after implementation. The outcomes and cost of a project are directly related to each other. A particular set of outcomes will involve a particular set of costs. This interrelationship means the outcomes and costs will be developed together, based on a detailed study of the associated project requirements, risks and other relevant factors. Where a progressive planning approach has been adopted, as suggested in the preceding section 3.1 of this Guide, developing the business case will involve building on the work already done in preparing, and gaining approval of, a project concept plan. This additional work may result in a greater understanding of the work involved, and provide fresh perspective on the project. Project sponsors can assist the development of a statement of outcomes in the business case by: Identifying the business outcomes of most relevance to decision-makers (see earlier discussion at page 47). For many projects, a relatively small number of outcomes are of central interest to decision-makers. Reviewing the proposed scope of the project in particular using their broader perspective and experience to identify outcomes that may be too ambitious, or which may be missing; Identifying related outcomes which are of interest to decision-makers which will not be delivered by the project, and arranging that their exclusion is mentioned in the business case summary, to help reduce the risk of incorrect expectations.
22 Decision-makers will also be interested in any relevant non-financial requirements for the project. 23 By default, the project sponsor is responsible for delivering the project products. Given the possible involvement of different parties in a project, it is useful to clarify responsibility for the project outcomes and all the elements of expenditure needed to achieve those outcomes.
SECTION
3
61
To support accurate and informative costing of project proposals for decision-makers, the project sponsor should give particular attention to: The use of appropriately skilled staff to undertake the costing. Reliably estimating the cost of projects particularly those with ICT elements can be complex. The parameters used as the basis of financial assessments. For example, the net present value of a project depends strongly on the timing of the benefits and costs, and the expected life of assets. It is prudent for the project sponsor to have such parameters identified and to make a judgement on their appropriateness. Some parameters which affect financial assessments may also be included in other sections of a business case, such as the assumptions section for example, unit costs or client numbers, and the requirements section for example, the expected life of a system. The cost estimates being sufficient to achieve the proposed outcomes. As discussed in the following section, this is generally achieved by developing a complete set of the requirements, and costing those requirements to estimate the cost of developing the project products. The full cost will also need to include the rollout and handover stages, and any operational costs needed to achieve the proposed outcomes. A useful crosscheck is to have an independent review of the costing. The cost estimates including a contingency allowance, and that the amount is appropriate to the risks identified. Financial management arrangements such as to whom project funds need to be allocated and how resultant savings or income will be managed. Identifying non-financial resources required and making relevant information visible to decision-makers as issues needing to be taken into account. For example, some projects may require the allocation of scarce internal facilities or specialist staff. The correct accounting treatment of expenditure, in particular the distinction between capital and operational expenditure.
62
Project requirements statement

Better Practice results: The accurate definition of requirements improves the accuracy of estimates of project benefits and costs, aids implementation and subsequent stakeholder satisfaction.
The project requirements statement defines the capability and performance that the project will provide. The requirements are used to guide the design of specific project deliverables, and to assess whether those deliverables are satisfactory24 for the intended purpose. The project requirements describe what is needed; the deliverables are how that is accomplished; and the outcomes describe why the project is worthwhile. Important issues for attention by the project sponsor are: the completeness of requirements for example, as well as requirements for developing an ICT system, there may be requirements for legislative change, and staff training; the adequacy of consultation in developing the requirements such as with end users, and understanding the perspective of potential suppliers; and the relative importance of different requirements. One factor present in successful projects, and absent in failed projects, is paying sufficient attention to the requirements. Project management consultant.
In addition, given the central role of the intended operational manager in using the project products to deliver business outcomes, it is important to gain the operational managers agreement:25 on the requirements that will serve as the operational acceptance criteria for the project products; and that the proposed business outcomes will be achievable with those products.
PROJECT PROPOSALS
An example of a high-level project requirement is the ability to register and assess 20 000 grant applications per year. This requirement could be met by a range of options, including a completely manual processing approach, or a fully automated Internet-based computer system. To be implemented, this high-level requirement needs to be expanded, for example, to explain the specific requirements for correctly assessing a grant application. A component of the business case closely related to requirements is constraints, or not negotiable elements. Some constraints may be set by the project funder or sponsor for example, the project should finish by a certain date, or have a limit on its budget. In some cases it may be convenient to include these with requirements the most important point is that they be clearly identified. Other constraints may involve the need to meet standards, or to use specific resources. Project constraints will also influence the design of options for the project. Defining project requirements is a prerequisite for designing potential solutions. Each solution identified is an option that can be assessed on a cost-benefit basis: In many cases, the benefits of a project can be derived from the requirements statement. For example, meeting a requirement that an applicants claim history be available online to assessment staff can allow the calculation of a cost-saving benefit by comparison with the current cost of obtaining the information manually.
24 As the requirements are used to assess the fitness-for-purpose of the deliverables, a high-level description of the requirements can be used as part of a statement of success for a project. This approach is used in the ICT Business Case Guide issued by the Department of Finance and Deregulation. 25 Even in cases where the sponsor and operational manager are the same person, it is valuable to separately consider the respective responsibilities of those roles.
SECTION
3
63
While costs can sometimes be estimated directly from the requirements, more reliable costings can be obtained by estimating the cost of a particular set of project deliverables which fulfill the requirements. The costs can then be used to assess the cost-benefit of that set of deliverables.
These interrelationships are shown in the following diagram:
used to design and assess deliverables
Requirements statement
Option A Option B
Deliverables
allows the estimation of
Deliverables
Costs
Costs
outcomes and benefits

used to estimate cost-benefit
Cost-benefit
Cost-benefit
Requirements can be described in varying degrees of detail. For example, a business case for a $100 000 project may summarise the requirements in a few pages. On the other hand, the requirements documentation to accurately cost the development of a major computer system may be quite lengthy. In my experience, a key requirement to focus on is the quality of the user experience how do people feel when they use the products of the project. Program delivery branch head. The requirements statement should be developed to a degree of detail appropriate to the use to which it will be put that is, it must be fit for purpose. One benefit of progressive approval, such as the ICT Two Pass Review process, is that it allows an assessment of whether the cost of detailed requirements analysis is justified. For example, a requirements process costing $20 000 may be part of a first pass business case which obtains approval to spend $200 000 preparing a detailed requirements statement and second pass business case for a $30 million project.
Case study ease of use requirement

an agency was preparing a business case for a project to facilitate secure communications between specialists across australia during a public emergency. as an emergency system, it would be used only occasionally by most users but needed to be used very effectively on those occasions. to meet these needs, the requirements specifically covered ease of use, for example: Users should be able to use basic functions of the system with less than 5 minutes training. User authentication should be easy and reliable for users who may only use the system once a year. the user authentication requirement suggested that a password-based solution to user authentication was unlikely to be suitable, whereas a biometric solution may be suitable. note that the requirement is nonetheless stated in terms of the underlying need, rather than a specific solution.
64
The requirements statement for a project will usually be developed by the project planning team, and then reviewed by the project sponsor. Decision-makers are often more focused on costs and business outcomes than the detail of requirements. However, given that costs and benefits can often only be assessed from requirements, it is better practice for the project sponsor to assure themselves that the requirements statement is complete and is appropriate to the projects objectives. Important issues for attention by the project sponsor in reviewing the requirements statement in a business case are set out in the following table.
ISSUE Completeness of requirements
COMMENT for practical reasons, the business case will describe the requirements in summary. nevertheless they are the basis of project costings, and need to be complete in the breadth of matters covered. requirements also need to be expressed with sufficient clarity to allow their use in developing options. the quality and completeness of the requirements is likely to be affected by the extent of consultation and the extent of agreement obtained.
Adequacy of consultation
PROJECT PROPOSALS
Avoiding unnecessarily expensive requirements
an apparently small change to the requirements can dramatically change the cost of a project. for example, a system rated with a higher security classification may cost twice as much; a system with a onesecond response time may cost twice as much as one with a foursecond response time. accordingly it is prudent to gain advice (either from the business case team, or independently) as to whether the cost is particularly sensitive to any specific requirement, and assess whether that requirement could be reduced without detriment to the overall project objective. there can be a set of options to provide a given set of project requirements (with a given level of benefit). it can also be useful to consider options that vary the requirements (and also have varied benefits). for example, one project option may only include the business requirement of accepting grant applications, and another option would also automatically assess applications. on occasion an entire category of requirements may not be mentioned in the business case perhaps because the requirements are assumed to be understood. it is prudent to check that each category of requirements is covered in the business case. Misunderstandings on issues such as capacity, usability, security, business continuity, and audit requirements can lead to substantial cost increases and delays as the project progresses. (See appendix d Categories and examples of requirements at page 106.)
Project options with variations of the requirements
Omission of one or more categories of requirements
SECTION
3
65
Options
Better Practice results: Options are provided that justify the broad investment, and provide opportunities for fine-tuning by decision-makers of that investment.
Decision-makers initially need to consider whether an investment, of some estimated cost, is warranted. This initial decision is aided by comparing the preferred scope of the project with the status quo. If there is general merit in an investment, the next issue for decision-makers is whether some variation of the proposal might obtain a better overall result, taking into account practical constraints, other objectives such as moving toward a preferred delivery model, and the opportunities offered by other projects. This more nuanced decision is aided by comparing variations of the preferred scope of the project. To assist decision-makers to make these judgements, important issues for attention by the project sponsor in relation to options are:
Options should provide decision-makers with real choice

The best business cases provided several options that would make real progress on the issue, but with a range of costs and benefits. The least useful business cases simply gave an unacceptable status-quo, an unaffordable utopia, and the sponsors preferred project. That style of all or nothing business case makes it harder for us to juggle our available capital across the priorities of the agency. . Member, agency project review committee.
thinking broadly about possible approaches to meeting the requirements, to increase confidence that the recommended approach is indeed the best value-for-money including: alternative delivery approaches, such as through other entities or by outsourcing; and considering whether there may be innovative options worth exploring;
involving stakeholders and alternative perspectives in identifying options; and focusing the options presented in the business case so the most useful alternatives are visible to decision-makers.26
In addition, the sponsor can help reduce the cost of preparing and assessing a large number of options by providing guidance to the project planning team on: relative priorities of different project requirements; priorities for delivery approaches to be explored; and constraints that may rule out particular options, such as availability of capital or operating funds, and timeframe constraints.
26 It is usually most useful for decision-makers to consider a relatively small number of options. For significant projects, it is usual to provide an attachment discussing a larger number of options. These may be reviewed by advisers to the decision-makers.
66
Generating options
Options can be generated on at least two dimensions: Requirements: using various combinations of requirements, such as varying performance levels, functions available and so on. As discussed in the previous section, each set of requirements will provide different benefits. Solutions: for a given set of requirements, there can be various solutions, such as automated or not, outsourced or in-house, and so on.
One dimensional options

What concerned me about the business case for a new data warehouse was the options were all for different technical implementations with relatively similar costs but varying risks and ICT features. No options were provided for varying the data coverage of the project, the types of analytical capabilities, or the phasing of implementation. Those options were the ones that would have varied significantly in cost and benefits. The business case was sent back for re-work. Member, agency project review committee.
In addition, for a given set of requirements and type of solution, there can be additional sub-options for the implementation approach, as discussed on page 72.
Comparing options
Once options are generated, the next step is to compare them on a common basis. To assist this comparison, guidance material for preparing business cases usually sets out information to be provided for each option, such as:27 high-level benefits, objectives, costs and risks; functions performed; capacity to integrate with the existing system; potential constraints / limitations on the option; markets ability to deliver the required products or services; any critical organisational or business environment assumptions / impacts; high-level comparison to the status quo; high-level impacts on stakeholders; and expected performance over time for key performance indicators.
PROJECT PROPOSALS
Generally, the project planning team will prepare comparisons of options. The opportunity for the project sponsor to contribute is mainly around providing guidance as to which options are most useful to explore.
27 Adapted from ICT Business Case Guide, Department of Finance and Deregulation.
SECTION
3
67
Risks and assumptions

Better Practice results: Risks and assumptions particularly at a strategic level are accurately identified and made visible to decisionmakers, allowing them to bring their experience to bear on the feasibility of the project.
Two common causes of shortfalls in projects are assumptions which turn out to be unrealistic, and reasonably foreseeable risks not being addressed during planning.28 So that the business case provides a reliable basis for decision-making, it is better practice for the project sponsor to: provide guidance to the business case team on risks and assumptions at a strategic level (such as the policy environment, and organisational directions); gain assurance on the identification of risks and assumptions (see the table of review questions at the end of this sub-section); gain assurance that ongoing monitoring and adequate responses to identified risks and assumptions are included in the costing and activities in the business case; and help identify those significant risks and assumptions that should be made visible to decision-makers (including any important residual risk, as discussed at page 79).
Most people can develop a business case logically from its assumptions. So the greatest cause of project failure is untested assumptions. . Business leader.
Risks and assumptions are closely related concepts: Risks are uncertain events which may have an impact on the project. For example, the uncertain event may be the unexpected absence of specialist staff, and the impact if this happened would be a delay to the project. Assumptions are expectations about the future which, if not fulfilled, will have an impact on the project. For example, an assumption may be that the entity will have a single service provider in each region. If this changes, the impact may be the need to add additional functions to the ICT system which manages service delivery. There may also be assumptions underlying a project on issues of cause and effect. For example, an assumption that savings achieved will be similar to a project undertaken several years earlier.
Risks and assumptions can be assigned a relative importance by considering the potential impact and its likelihood. Generally, the more important risks and assumptions will be included in the body of the business case for management attention, with the details of all the identified risks and assumptions held separately, or provided as attachments. The term assumption is sometime used to refer to parameters which affect cost and benefit analysis, such as the number of clients and discount rates. While there is no definitive answer to such variations in terminology, it is useful to have consistency of approach within an entity. Grouping types of assumptions on a like-with-like basis in the business case makes analysis easier and more reliable. For example, it would be useful to group together assumptions which affect the design of solutions such as number of clients to be handled, or required unit operating costs as part of the requirements statement. Some of these requirements will also be used for cost calculations.
28 A related issue, a lack of responsiveness to risks which occur, is covered in Chapter 4: An overview of implementation.
68
Identifying risks and assumptions in distinct categories will help increase confidence in the completeness of the analysis. Common categories are: policy environment; organisational direction and priorities; project environment for example stakeholders, suppliers, and ICT; basis of cost estimation for example, relevance of prior experience; and resources technical, financial and human, including: the likely availability of resources not currently on hand; and the potential loss of current resources particularly key people with uncommon knowledge and skills. The following table provides some questions that project sponsors can use to help review29 the risks and assumptions in a proposed business case. EXECUTIVE REVIEW QUESTIONS FOR RISKS AND ASSUMPTIONS
PROJECT PROPOSALS
Novelty: Which parts of the project involve activities that the entity has not successfully done before? Are there elements new in Australia, or internationally? Impact: Which assumptions have the greatest impact on the design of project products such as an ICT system?
if part or all of the project is breaking new ground, this deserves to be made visible. the goal is not to avoid innovation, but to undertake novel approaches in a thoughtful way, and for the decision-makers to be aware of the extent of any risk involved.
in most cases, business cases have been developed logically from their assumptions. So a common risk to project success is untested assumptions. it is useful for project sponsors to be aware of the assumptions with the greatest potential impact so they can assess them using their own perspective on policy directions, program delivery strategy and organisational arrangements. Sometimes known risks are neglected during planning. Perhaps the risk has been assumed to be covered, or there may be reluctance to discuss and deal with the risk. By fostering an environment where risks can be openly discussed and dealt with, project sponsors can increase the prospects of successful implementation. Given the risk of inadvertent oversight by even the most attentive planning team, it is often useful to have an independent review particularly of whether the business case adequately identifies and responds to risks and assumptions. Check that generic risks, like staff loss, are considered specifically to the project in their likelihood, impact, and realistic mitigation.
History: Which risks have most impacted on similar projects? Why wont they have a similar effect on this project?
Scrutiny: Who has independently reviewed the risks and assumptions?
Tailoring: Have generic risks been made project specific?
29 These review questions selectively test issues of relevance to senior executives. Comprehensive assessment questions for business cases are available, for example, in the Gateway Reviewers Handbook.
SECTION
3
69
Better Practice results: Project implementation and subsequent operations are not adversely affected or delayed by issues with operational requirements particularly data and staffing issues; the important asset of data is subsequently well-managed and kept up-to-date.
To achieve the intended business outcomes, the project products generally need to be put to operational use. To provide confidence that the outcomes will be achieved, it is important to plan and budget for the required operational inputs to operate or use the project products. Typical operational inputs include: staff including business and technical staff; accommodation; data; and expected support services.
Data access problem

We were half way through implementing a new public information web site when I was told by the project team that some important data would not be readily available. The data was held by third parties who had not been consulted in early planning, and were now raising concerns about the commercial implications of releasing the data. The issue added six months to the timetable. I now pay close attention to the source of any data at the project planning stage. Program delivery branch head.
As discussed on page 35, for many APS projects effective data management is important to project and organisational success. Data often gives rise to long-term responsibilities and costs; there may later be interest in additional uses of the data; and difficulties with data access are sometimes a cause of project delays. It is better practice that when reviewing business cases, project sponsors assure themselves that: any operational requirements for staff are identified and budgeted for including the numbers and skills needed, and allowing for possible training time and recruitment delays; any operational requirements for accommodation and support services are identified and budgeted for taking into account the time needed to obtain such requirements; data requirements are identified and restrictions on data use are specified; any risks to data availability such as the need to gain agreements from third parties, or to develop data definitions and standards are visible and reasonably allowed for in the budget and timeframe; and responsibilities for collecting and maintaining data are defined, agreed and documented.
Case study: Legal differences derail Feds database

as part of a major Commonwealth initiative, a new system was meant to hold data that would be shared by Commonwealth and State agencies to improve services to individuals. the project has now been held up because revised privacy laws in all jurisdictions have not yet been introduced. newspaper article.
70
Communication
Better Practice results: Increased confidence in decision-makers that affected parties will regard the project positively, and thus contribute to the projects success.
The business case prepared by the project team will normally provide information on the proposed communication strategy, covering issues such as: identifying key groups to be communicated with, and their interests; identifying the objectives of communicating with each group, for example preparing affected parties for changes, building support, or providing detailed training in using new facilities; and responsibilities for different aspects and channels of communication. The greater the impact of a project, the greater the need for clear communication about the rationale behind it. ... PM&C guidance.
Given the importance of effective communications to successful implementation, it is better practice for the project sponsor to consider the following issues when reviewing the communication strategy: Consultation during planning have the right people been involved in helping identify communication issues? are there more senior stakeholders that the sponsor should discuss the communication approach with, such as the entity executive or the Ministers office? are communication issues covered for all project stages, such as initial announcement, development, implementation and operation? do project activities or announcements occur when there may be heightened interest or impact? if there is targeting of communication to different audiences, is there appropriate consistency in the underlying message and facts? is there a need to coordinate any of the planned communication activities within the entity or on a government wide basis? if so, has sufficient time been allowed to gain agreement when needed? are communication activities, costs and staffing properly included in the project plans and budget?
PROJECT PROPOSALS
Timing
Consistency
Coordination
Incorporation
Case study: Project with wide impact
We knew communications would be important because the project would affect groups across australia. the real benefit came from the effort we put into the communication planning. We involved some regional office staff, and an adviser from the Ministers office. We decided we needed a tailored communication approach, including face-to-face briefings for some groups, and effective feedback arrangements from clients during design, testing and implementation. there were significant changes to the activity plan, budget, staffing and timetable to cover the communications issues. the added communication effort meant the implementation went very smoothly.
Program management branch head.
SECTION
3
71
Better Practice results: Well-structured phasing reduces many common risks to project success, allows earlier delivery of outcomes, and can be more responsive to the priorities of government.
Executive involvement improves the balance between technical issues and government priorities in project phasing.
Planning a project as a series of linked but independent modules or phases, with each phase providing a particular capability or outcomes, can have many benefits. However, there is a risk that the structure of project phases will be guided by the perspective of those undertaking the detailed planning. To help achieve an appropriate balance between technical requirements and government priorities, it is better practice for the project sponsor to: understand the major constraints imposed by logical dependencies between different project components for example, a new database may be needed before any applications can be received; provide guidance to the project planning team on the importance of different factors, such as risk reduction or timeframe, to use when comparing alternative implementation approaches taking into account the views of key stakeholders; and review and agree to the proposed implementation approach.
Example of implementation approach: A move to standardised internal processes

the objective of a project is to implement a new agency-wide process for managing service providers, using the same iCt system for all business units of the agency. the business units currently use many different systems. functions to be standardised include: allocating work to a provider; and obtaining reports on work done. Broad implementation approaches include: introduce all functions to all units at the same time; introduce all functions to one unit, then another unit, and so on; and introduce a single function to all units, then another function to all units, and so on. each of these ways of packaging the work has different advantages and disadvantages, which vary according to stakeholders perspectives. for example, in terms of sequencing functions, the function for allocating work to providers may have the potential to significantly improve direct client service so clients would prefer this function implemented early. on the other hand, the function for reporting on work done may result in cost savings in both the agency and service providers. alternatively, if the overall project focus is reducing the cost and complexity of multiple systems, an approach of introducing all the functions to one business unit at a time may be attractive. this sequence would allow the existing systems to be progressively decommissioned (or provide early warning of any problems with decommissioning).
72
ing the d
Some issues for the project sponsor to consider in assessing and comparing implementation approaches are listed in the following table. ISSUE Reducing risk and uncertainty POTENTIAL CONSIDERATION FOR IMPLEMENTATION APPROACH ability to test uncertainties early; or allow risks to be identified and resolved with a lower impact. Providing some functions earlier than otherwise. relative priority to give to benefits accruing to different stakeholders. By packaging work to provide points for possible project exit or change of direction that would minimise wasted effort and provide some ongoing value of products delivered to that point. Packaging work taking account of who is involved to avoid impact on areas with other responsibilities, such as a peak work load for businessas-usual activities and other possible projects.
Timing of benefits Recipient of benefits
Increasing flexibility or reducing possible losses
Resource impact
PROJECT PROPOSALS
Management control
Packaging work so that progress can be reported in terms of a series of completed and independently useful project phases provides reliable status information, and useful choices on the value of further funding. (in contrast to a series of parallel, interdependent phases which may be 80% complete but with no delivered value, which limits the choice of further funding to all or nothing).
Where different implementation approaches offer significant variations in the timing of benefits to different stakeholders, or the effectiveness of project control, it is good practice to provide these as options in the business case, which are analysed and compared with other types of options such as different solution approaches. Any significant information about the implementation approach should be included in the executive summary, for the information of decision-makers. In addition to considering and deciding the overall approach to implementation, as discussed above, it is important for the project sponsor to consider the work needed to effectively develop or acquire the project products, and to introduce the project products into effective use. Chapter 4: Overview of project implementation at page 87 provides an overview of the typical activities during project implementation. This is useful background for considering the implementation activities which will need to be budgeted for in the business case.
Modular implementation reduces risk
Public sector budgeting systems can encourage the funding of large and highly visible it projects. this is unfortunate, since the risk of failure is proportional to the size of the project. Very large projects, i.e. expensive long-term and complex initiatives, often fail. Where big projects are unavoidable, they should be divided up into self-contained modules that can be adjusted to changes in circumstances, technology and requirements.30
OECD Policy brief.

30 OECD, PUMA Policy Brief No.8 The Hidden threat to E-Government, 2001.
SECTION
3
73

Better Practice results: Increased confidence in decision-makers that the project implementation will be well-managed and that project status updates provided to the decision-makers will be timely, accurate and useful.
Business cases normally provide information on proposed governance arrangements, covering issues such as the arrangements for: oversight and control of the project often using a project board; the day-to-day management of the project; and reporting to the decision-maker on progress, problems, and review points.
A well-governed project can overcome numerous unforeseen and dire obstacles and still deliver. A poorly governed project can just keep spending but never deliver. For that reason, I dont approve business cases where I have doubts on the governance. Chair, investment committee.
Given the importance of sound governance to subsequent implementation success, it is an important consideration for project sponsors and decision-makers when considering a project. Accordingly, is better practice for the project sponsor to: describe their own role in governance for example, chairing the project board; consult with parties who will represented on the governance body to gain commitment to specific people or positions being involved; tailor the governance arrangements and reporting milestones to the importance, complexity, cost and level of risk for the project; identify key milestones and triggers for reconsidering the continuation of the project; and make a judgement on whether there is adequate internal capability to effectively govern the project.
The governance approach may be affected by options being considered for the project. For example, a different governance approach may be used for an option involving partner entities, compared to options being delivered within the entity. This means that governance aspects of the business case need to be considered jointly with other aspects of the business case.
Project governance committee

Useful principles in the design of the governance committee (or project board) are: Include representatives of the business area who will use the products of the project. Include representatives of the proposed suppliers or developers. Consider inclusion of those more indirectly affected, such as clients. Be clear on the powers of the committee. To maintain clear accountability, a common arrangement is that the committee will advise the project sponsor, who chairs the committee and is the decision-maker. However, in some circumstances it may be appropriate for the committee to have decision-making power. Make arrangements to manage potential conflicts of interest. Wide representation on the project board provides definite benefits in identifying and resolving issues, but may result in actual or potential conflicts of interest.
74
There are particular issues in setting up governance arrangements for cross-entity projects, which are discussed in the next section.
Milestones
Of particular interest to decision-makers are the key reporting milestones and points for review identified in the business case. These will usually include: the completion of any significant procurement activity; the completion of major project phases (see page 72 for a discussion of implementation approach and project phases); when significant variations of cost, time or deliverables become apparent; and the reaching of milestones where it is prudent to reassess the viability of the project that is, potential exit points for the project. Depending on the degree of uncertainty in the project, these can be defined as either a point where specific approval is required to continue, or where approval to continue is granted subject to defined benchmarks having been achieved.
Tailored governance builds confidence

I found that the governance sections of most business cases were the same: a description of the standard project board, and the standard reporting milestones. I was more confident giving approval to those business cases where particular features of the project were reflected in the governance plan. independent member of agency project approval committee.
Governance capability
Finally, it is important for the project sponsor to consider whether their area has the experience and track record to effectively govern the project. If a business area is still developing its project governance capability, it is preferable to acknowledge this in the governance section of the business case and explain the additional steps that will be taken to fulfill the governance plan. For example, project management and secretariat services to the governance committee may be contracted to specialist providers.
PROJECT PROPOSALS
Using a RACI matrix to clarify roles: a raCi matrix typically shows tasks (or project deliverables) in the left hand column, and people (or roles) along the top row. each cell in the matrix is marked to indicate the involvement of that person in that task, as being one of: Responsible - those who do the work to achieve the task; Accountable - those who are ultimately accountable for the proper completion of the task. there should only be one person accountable for each task; Consulted Informed - those whose opinions are sought (i.e. two-way communication); and - those who are kept informed of progress (i.e. one-way communication).
a raCi matrix can be a simple and concise way for the project sponsor to clarify and agree responsibilities. using such a matrix helps to quickly identify potential gaps in responsibility and areas of possible overlap and conflict.
SECTION
3
75
Issues for cross-boundary projects

Better Practice results: Improved delivery of cross-boundary projects and associated public benefits, arising from an early shared commitment to defined project outcomes, timeframes and financial arrangements.
Increasingly, the delivery of government programs requires the involvement of multiple parties, whether they are different business areas within an entity, different entities, or from multiple jurisdictions. Implementing such programs will involve a project which will use resources from different areas a cross boundary project. This section identifies important issues for attention for cross boundary projects. The major steps in preparing a business case, such as defining the outcomes and establishing the cost, are no different for cross boundary projects. However, the process can be much more complex than for a project involving a single entity. Important areas requiring the attention of executives involved in cross-boundary projects are: managing the process of developing the business case, which is likely to be more complex; setting up governance arrangements for managing the project; and getting budget arrangements and expenditure controls right.
Extra time to define project

There is a natural gestation period for a project, where key people talk, consider problems and opportunities, and converge to a project definition. That gestation period can often be longer in a cross agency project. Cross-agency program director.
Managing the process of developing the business case

Developing the business case for a cross-boundary project can pose particular challenges, arising from the need to obtain agreement of the various parties to the projects goals and objectives. The potential different priorities of each party also need to be taken into consideration. It is important that the project sponsor is aware of the risks in developing a business case across boundaries, and takes appropriate mitigating actions. Useful initial questions for crossboundary projects are: What other parties will need to be involved in the project? This might involve other Australian Government entities, entities of state, territory or local governments, overseas governments, private sector and not-for-profit entities or representative groups of clients and providers. In terms of defining the project, which parties have responsibility for outcomes, which have decision-making roles, and which need to be consulted? What roles will the parties have in implementing the project?
Understanding is personal
Face-to-face conversation is needed for true understanding not just sharing documents. Cross-agency program director.
Once the parties to be involved in planning have been identified, important issues for the project sponsor include: gaining agreement to coordination and clearance arrangements for the business case; and obtaining from each party an appropriate commitment of resources to develop the business case.
76
Governance arrangements for the project

Inadequate project governance is a common risk to the effective implementation of projects. This risk is even greater for projects which span organisational or jurisdictional boundaries, and accordingly warrants particular attention at the planning stage. When developing governance arrangements for inclusion in the business case, issues to be considered for cross-boundary projects include: the broad governance model for example a lead entity acting as purchaser; a lead entity with cooperative support; or a new entity managed by a board with representatives from relevant entities; project monitoring arrangements including key milestones, resourcing of monitoring, quality assurance, and arrangements for dissemination of status reports; and responsibilities and authority for project communications to stakeholders and, if relevant, to the wider public.
Singular governance
Although there are many agencies involved, we have agreed to a principle of singular governance. We have defined roles for decisionmaking, with strategic decisions made by the program board, and operational decisions taken by the relevant program manager. For example, design decisions for the overall program are taken by a nominated person. Crucially, we have focused on having a single process for status reporting the senior responsible officer in every partner agency gets the same status report. Cross-agency program director.
Getting financial estimates and controls right

All projects face a challenge in estimating the amount and timing of expenditure. Crossboundary projects face additional challenges such as possible multiple sources of funding, and the need to monitor and control expenditure in different entities. When developing financial arrangements for inclusion in the business case, issues to be considered for cross-boundary projects include: the source(s) of funds; how funds will be allocated for example to a single project budget, or held separately by the parties providing the funds; how funds will be controlled for example payment for activities (input basis), payment for results (output basis), or provision of a general budget supplement; and how expenditure will be reliably monitored across entities.
PROJECT PROPOSALS
Budgeting cross-agency projects is hard

There was a lot of work getting the finances sorted out. In comparison to a single agency project, we had to not only get the overall budget right, but the allocation to different agencies, with the conditions for the use of the money, and the split between capital and operational.
In addition to project costs, there may be expected financial benefits or savings from the project. These will also need to be allocated. This may involve setting out the proposed process and rules for measuring the baseline of costs and for harvesting either actual or promised savings from entities. Clarifying these issues will assist all parties involved when considering the business case for approval.
Cross agency program director.
SECTION
3
77
3.3 Approving the project
Operational inputs
Project products
Business outcomes
Long-term benefits
Implementation Approval Business case The approval stage involves: A well-informed decision Setting controls for implementation
Concept plan
Having developed and endorsed a business case, the project sponsor will submit it for consideration within the entity. For some projects, this may be followed by external consideration, for example as part of Budget processes.
Important factors in setting a good foundation for achieving project outcomes are: informed consideration by decision-makers taking into account the merits, cost and risks of the individual project, and also the cumulative effect and interactions of projects under consideration; and for approved projects, setting key project controls to support effective oversight by the entity and the project sponsor.
Informed decision-making
Better Practice results: The proposed project meets the test of value-formoney, and required legal and accountability requirements are fulfilled.
In deciding whether to approve a project business case, it is important that the decision-maker: is confident the expenditure is an appropriate use of resources which for FMA Act agencies means that the project represents an efficient and effective use of the public money; and is in accordance with the policies of the Commonwealth;31 has reasonable assurance that the project complies with entity policies, in particular business strategies and ICT architecture, and is consistent with relevant whole-ofgovernment priorities and directions; is confident, in cases where the project is being chosen in comparison with other projects, that the project will make more effective use of resources than alternative projects; and has reasonable assurance that the project can be completed as planned, in particular that the relevant capabilities are available, that risks have been properly identified and responded to, and that the governance and control arrangements are appropriate.
31 While many elements of project expenditure, such as procurement, will involve specific approval by a delegate under the FMA Act, there is likely to be significant expenditure, such as staff effort, where the authority is approval of the project business case.
78
The earlier discussion on entity arrangements for screening and comparing projects (page 28) provides useful considerations for decision-makers. To help meet accountability requirements, better practice entities will ensure that: there is clarity on who endorsed the business case being approved, as the business case will be a major factor in the decision; there is clarity on who took the approval decision this will often be an individual officer, acting on the advice of an investment or project approval committee or board; responsibility is allocated for both delivery of the project products, and achieving planned business outcomes; any limits or conditions on the approval are made clear and fully documented for example, the approval may be limited to preparing detailed specifications and cost estimates for reconsideration by the decision-maker; or contingent on independent assurance of costing or on the agreement of a stakeholder to the specifications; any important residual risks (that is, project risks for which mitigation has not been funded or may not be effective) are minuted, and are drawn to the attention of the relevant senior executive for acceptance or action as appropriate; and the approval decision is documented and retained in the entitys recordkeeping system.
Managing residual risk of a project

I was involved in a decision on a major investment proposal, covering computer systems and all the computer equipment needed to run them. The business case was well put together, and explained performance levels and risks. The interesting point was the residual risk. The project sponsor was aware of the level of funds likely to be available and had fit the degree of equipment redundancy into that budget. This left a chance albeit small of service failure, which was explained in the business case for the attention of the investment committee. We decided the risk was significant enough that it should be drawn to the attention of the Chief Executive, either for acceptance of the residual risk, or for a larger budget. Following an independent review to confirm the facts, the Chief Executive decided to seek an increase in the agencys capital budget.
PROJECT PROPOSALS
Good practices for decision-makers and members of committees are outlined below.
independent member, investment committee.
I enjoyed being on the investment committee. I learnt a lot about the department overall, and reading other peoples submissions gave me a crash course in improving my own project planning. ... Program branch head.
SECTION
3
79
Better practices for decision-makers and committee chairs

decision-makers who approve projects have a significant responsibility for authorising, or recommending, significant public expenditure. relevant better practices are: remaining focused on the central elements of project proposals relevant to approval (such as their outcomes, costs, feasibility and risks, and broader contribution to agency goals); considering the overall effect of projects under consideration, by paying attention to opportunities or difficulties arising from the impact of one project on another, or their effect on businessasusual activities; keeping in mind the option of conditional or staged approvals to help the agency better manage projects risks; arranging for reports on the progress of approved projects and using this to inform future decisionmaking; and considering the applicability to the agency of the better practices for governance of approval described in Chapter 2 of this Guide; for executives who chair project approval committees, better practices include: awareness of, and clarity about, the scope of their decision-making role this should be in the committee terms of reference; consideration of the representation, skills and knowledge on the committee and taking action on any improvements needed; consideration of the resourcing and capabilities of the committee secretariat this is often of great importance given the volume and complexity of documentation typically presented to project approval committees; encouraging a strong continuity of attendance by members which contributes to the quality of review and to clear accountability; and encouraging an environment of open and honest discussion.
Better practices for the members of approval committees

important better practices for members of project approval committees are: awareness of the scope of their responsibilities as committee members; developing a knowledge of agency goals, including program delivery and iCt strategies, and of project planning principles; contributing the perspective of their own area of expertise for example particular knowledge of a service sector, an area of technology, or of the organisation in assessing and commenting on proposals; and drawing attention to any aspects of committee processes (for example, the format or size of submissions, or the nature of summaries or advice from the secretariat) that could be improved.
80
Key project controls

Better Practice results: Senior managers are aware of project status in terms relevant to external relations and internal coordination; senior management is alerted early to issues needing their action.
At the time of approving a project, the decision-maker also establishes the key controls that will help them understand the rate of progress and identify triggers for possible intervention. This requires striking a sound balance in gaining the right information for effective management, while avoiding information overload. Characteristics of effective key controls for a project, from a senior management perspective, include: Focus on key issues: there are a small number of key controls for senior management, with increasingly detailed controls for the project sponsor and project manager. Business focus: the controls include a focus on business issues such as delivering the ability to assess a specific application for payment, rather than focusing on all the underlying details of project implementation such as installing a database component. Progressive testing and assurance: there are measures which provide early indications of business outcomes, rather than needing to wait until near completion for any business capability. Review points and exit options: linked to progressive assurance is the identification of points for review of progress and decision on continued funding (sometimes called stage gates, or go / no go points). This can include identifying possible exit or fallback options, or redefining subsequent phases based on what has been learnt so far in the project. Coordination issues: there is information to assist senior management in their coordination of multiple projects such as how projects impact upon one another. Exception reporting: appropriate thresholds are specified for exception information such as budget, timeframe and risk.
The value of Plain English status reporting:

The Project Managers story: Previously we reported up the line based on our systems development methodology, and our internal batching of work. So management reports would say, for example, that Release 6 was 80% complete. Another report explained what was planned for Release 6. Our management said they wanted more informative status reports. Our next project was to allow people to make claims at shopping centres, using shopping chains as agents. So, for each national agent we simply reported to senior management whether the relevant contracts had been signed and the percentage of that agents outlets where claims could now be made. Interestingly, this report focused us on early testing at shopping centres, and we found a data transfer problem with one agent we were able to fix without affecting the overall timetable.
PROJECT PROPOSALS
An example of a project approval statement with the above characteristics is provided in the appendices (page 107).
The Senior Managers view: By defining this way of reporting at the start, I felt I always knew where we up to, in the language I could talk to stakeholders. It was plain English, in a half-page table.
SECTION
3
81

Better practices for senior executives responsible for the planning and approval of projects are listed on the following pages. The practices are grouped under the main sections of this chapter: concept plan, business case, and approval. For each section the practices are listed in two groups:
Practices undertaken personally by the executive, for example maintaining a close relationship with stakeholders; and Review questions for use by executives to help check important aspects of the concept plan and business case, such as whether the costings are accurate. A version of these questions, arranged for convenient use in the review of a particular project is provided in Appendix F Questions for executive review of project proposals at page 110.
There is some commonality between issues to be considered at each stage. Where there is substantive additional material in the guide, page numbers are provided which refer to the start of the sub-section containing the material.
82
3.1 Concept Plan

BETTER PRACTICES FOR THE PROJECT SPONSOR
n n n n n n n n n n n n n n n
Be available to planning teams to discuss possible projects and entity priorities. (page 46) Maintain a strategic awareness of policy directions, and the opportunities and risks of emerging technologies and alternative delivery approaches. (page 46) Encourage a degree of questioning and innovation. (page 46) Maintain active external relationships and involve fresh perspectives early. (page 46) Keep the planning team focused at a concept level at this early stage, so as to avoid premature consideration of detail or specific solutions. (page 51)
POINTS OF EXECUTIVE REVIEW FOR A BUSINESS CASE The project concept has been developed in a broad context taking account of the entitys strategic goals and the broader environment. (page 46)
PROJECT PROPOSALS
Business outcomes are clearly expressed. (page 47) The extent of improvement or performance for business outcomes is indicated. (page 47) The business outcomes of the project are largely independent of factors external to the project scope. (pages 47, 49) The focus is on business outcomes that are important to decision-makers and key stakeholders. (page 47) There is a reliable chain of reasoning underpinning the key elements of the project. (pages 48, 49) The broad project requirements that are necessary and sufficient to achieve the outcomes are listed. (page 51) There is a definite contribution to broader entity goals for example client satisfaction, entity flexibility and capability, cost control, and enabling staff. (page 53) Any important assumptions, risks or constraints are identified. (page 53) Overall, the project concept offers achievable and tangible business results, supported by a reasonable logic for the major project requirements.
Once a concept plan meets the above criteria, its potential value, and its relative merits in relation to other concept plans, should be considered before making the investment needed to develop a more detailed business case. (page 53)
SECTION
3
83
3.2 The business case

This checklist assumes the business case is being prepared based on a project concept plan which meets the criteria listed on the previous page.
BETTER PRACTICES FOR THE PROJECT SPONSOR
n n n n n n n n n n
At the start of detailed planning: confirm the broad concept, appoint an appropriate person or team to develop the business case, consider whether specialist assistance will be useful, and engage with stakeholders. (page 55) Consider procedural requirements, including possible application of Gateway Review or the ICT Two Pass Review process. (page 55) Gain assurance that common administrative requirements, such as probity and recordkeeping, will be addressed. (page 55) During the planning process, provide enough time and resources so the business case is of a quality suited to the projects size and risk. (page 56) Keep watch on the direction and cost of planning. If planning is likely to be costly, consider a smaller proposal to justify the cost of a more comprehensive business case. (page 56) Maintain a close relationship with senior stakeholders to help clarify requirements and constraints and to remain aware of their commitment to the project. (page 56) Be readily accessible to the planning team, to provide guidance on strategic issues. (page 56) Consider seeking independent assurance on the information in the draft business case. (page 57) Assess realistically whether there is adequate internal capability to effectively govern and deliver the project. (page 58) Consider which information is of most interest and relevance to decision-makers and stakeholders. Make it clearly visible for them in the business case, including outcomes which will not be delivered by the project. (page 61)
POINTS OF EXECUTIVE REVIEW FOR A BUSINESS CASE Reason and specification: why the project is desirable, what is needed, when by, and at what cost
n n n n n n n
84
The projects business outcomes, costing and timeframe are clearly described and are sufficiently reliable to inform a decision. (page 61) Responsibility is allocated for all project products and expenditure and the delivery of the business outcomes. (page 61) The business outcomes will be measured before rollout, and subsequently. (page 61) The project requirements, or product description, are complete (covering, for example functionality, quality, volume, security). (page 63) The right people have been consulted on project requirements. (page 63) The proposed operational manager agrees the acceptance criteria for the project products. (page 63) The proposed operational manager agrees the business outcomes are achievable with those products. (page 63)
Validation: that the approach is better than alternatives and is feasible
n n n n n n n n
Options have been thoroughly considered. (page 66) The range of options provides a real choice to decision-makers on the level of investment. (page 66) Risks have been reliably identified and assessed. (page 68) Any significant residual risks from the project have been identified, and the relevant person is willing to accept them. (pages 68, 79) Ongoing monitoring of risks and appropriate risk mitigation is included in the budget and activity plans. (page 68) Assumptions particularly high-impact assumptions have been identified and are either considered reliable or treated as a risk for monitoring and mitigation actions. (page 68) Operational requirements (such as staff and accommodation) have been identified and budgeted for. (page 70) Data issues are addressed: requirements, availability, security and privacy aspects, and ongoing data management. (page 70)
PROJECT PROPOSALS
Implementation: gain confidence the project can be effectively managed and delivered
n n n n n n n n n
The communications and stakeholder relationship approach is appropriate in concept and in resourcing to the size, risks and impact of the project. (page 71) The project is compatible with other projects and workloads. (page 73) The staging of the project takes account of the relative priority of the various business outcomes and related benefits. (page 73) The staging of the project includes review and exit points that sensibly manage exposure to loss if problems occur. (page 73) The entity has the capability to develop or procure the products. (page 73) The resources are available or budgeted for product rollout and handover to operations. (page 73) The roles, availability, skills and decisiveness of the project governance team are appropriate to the risks of the project. (page 74) For cross-boundary projects, there is a shared understanding of, and commitment to, the project by the parties. (page 76)
Overall, the business case puts forward business outcomes that are realistically achievable within the proposed timeframe and cost, with appropriate risk mitigation, risk responses and fall-back options.
The next step is for a business case to be considered for approval by the decision-maker. This will usually involve a screening and priority assessment process. (page 28)
SECTION
3
85
3.3 Approval
See pages 78 81 for supporting material. BETTER PRACTICES FOR DECISION-MAKERS
n n n n n n
Be clear about scope of roles as a decision-maker or adviser. Encourage an environment of open and honest discussion, and of continuity of attendance by committee members. Focus on the central elements of project proposals relevant to approval (such as outcomes, costs, timeframe, feasibility, risks, and contribution to goals). Consider the overall effect of projects under consideration, including opportunities or difficulties arising from the impact of one project on another, or their effect on businessasusual activities. Keep in mind the option of conditional or staged approvals to help the agency better manage projects risks. Regularly consider opportunities to improve the assessment process (for example, the format of submissions, role and resourcing of support).
POINTS OF EXECUTIVE REVIEW WHEN CONSIDERING A PROPOSAL FOR APPROVAL Decision-makers should review and make their own judgement on important aspects of the business case, taking into account the broader context of government and entity priorities, resource availability, and other projects under consideration.
n n n n n n n n n n n n
86
The relative importance of the proposed outcomes and contribution to entity and government goals. The likelihood the project can be completed within the planned timeframe and costs. The allocation of responsibility for delivery of the project products and achieving planned business outcomes. The selection of the project option providing the most appropriate level of investment. The appropriateness of acceptance or action on significant residual risks. The appropriateness of project review and exit points to sensibly manage exposure to loss if problems occur. The appropriateness of the roles, availability, skills and decisiveness of the project governance team to the risks of the project. That the project complies with entity and APS policies, such as business strategies, ICT architecture and procedural requirements. That the project is compatible with other projects and workloads. The setting of specific controls at project commencement to provide senior management with the information needed for external liaison, to monitor progress and initiate any corrective action. Overall the project is an appropriate use of resources, taking into account the outcomes, costs, risks and alternative uses of funds. Following the decision, make a clear record of who made the decision, and the advice used as the basis of the decision.
this chapter provides an overview of implementation issues for program delivery and business projects. rojects.
Contents:
program delivery
4.1 Project sponsors role during implementation (page 88) 4.2 Typical project implementation phases (page 90) 4.3 Concluding remarks (page 98)
business projects
OVERVIEW OF PROJECT IMPLEMENTATION
88
4: Overview of project implementation

Operational inputs Project products Business outcomes Long-term benefits
Implementation Approval Business case
Concept plan
PROJECT IMPLEMENTATION
This chapter indicates how elements of the business case such as the outcomes, requirements, communications strategy and governance arrangements are applied during implementation to help achieve the planned business outcomes.
The previous chapter discussed the progress of a project to the point where: there is a clear definition of realistic business outcomes; project implementation for a nominated cost and timeframe has been assessed as feasible; and the project has been considered by the decision-maker; and if approved has effective controls defined.
These are important steps toward achieving the intended business outcomes. The next step is effective implementation. In many cases more detailed implementation planning is warranted prior to the commitment of significant resources. It is also important for executives to understand the activities undertaken during implementation, so these activities can be correctly included in the project work plan, budget and timeframe contained in the business case. Given the focus of this Guide on the planning stage, this chapter provides a high level overview of project implementation, and does not provide the same level of detail as in Chapters 2 and 3.32
32 More detailed guidance for executives on implementation is available in the Better Practice Guide Implementation of Programme and Policy Initiatives, 2006, ANAO and the Department of Prime Minister and Cabinet, and through the web site of the Cabinet Implementation Unit.
SECTION
4
87
4.1 Project sponsors role during implementation

During implementation, the role of the project sponsor33 involves two broad perspectives. These involve being outward-looking liaison and stakeholder engagement, and inward-looking oversight of the project. In most cases, the actual work of the project will be done by the project team, with the project sponsor providing leadership and oversight. The project business case will have described these roles, for example in sections dealing with communication, and governance and control.
Liaison and stakeholder engagement

The project sponsor has a responsibility to maintain effective liaison and engagement, at a senior level, with those parties interested in, or affected by, the project. These stakeholders may include: the Minister and the entity executive; the project board; the project team; partners and suppliers; users and beneficiaries of the project; and community or industry groups.
Effective relationships are crucial.
Effective relationships with stakeholders are crucial to successful implementation of projects. An effective relationship: helps in gaining an accurate and useful understanding of the needs and expectations of the parties; provides a sound basis for the commitment of resources needed for successful implementation; provides a basis for open discussion about any changes to expectations that may be forced by circumstances as implementation proceeds; and assists in a productive approach to solving difficulties that may emerge during implementation, or in resolving differences of opinion about directions of the project.
Interviews with experienced senior executives indicated the benefits of: face to face meetings with stakeholders; the continuity of people involved, particularly on the project board; developing strong relationships between all the members of the project board, and a culture in project board meetings of active involvement, openness to hearing of problems, and decisiveness in responding to them; clarifying liaison and communication responsibilities between the project sponsor and the project team, to avoid any overlaps or gaps; and getting specialist assistance with developing, implementing and monitoring the effectiveness of a communication strategy.
33 If the project sponsor delegates aspects of the management of the project, the allocation of the responsibilities described in this chapter between the sponsor and their delegate(s) should be made clear.
88
Oversight of the project

The project sponsor often supported by a project board - has responsibility for effective oversight of the progress of implementation. Matters requiring attention include whether: product delivery occurs as scheduled to the appropriate quality; business outcomes remain on track to be delivered by the project products; finances expenditure and savings are according to plan; staffing project staff numbers, capability, turnover and morale are satisfactory; risks and assumptions are regularly reviewed; variations from plan and risk events are identified promptly and responded to effectively; and sound administrative practices such as requirements for procurement, probity and recordkeeping are being followed. Continuity of purpose: keep a helicopter view on whether the project is on track for the outcomes approved in the business case.
Interviews with experienced senior executives indicated the benefits of: independent assurance of status reporting, to help counter: the natural optimism of project teams in reporting; the technical jargon and complexities of ICT; and the risk of an unbalanced focus on some parts of the project; commencing corrective actions to difficulties quickly when they may be less expensive to fix and before problems begin to proliferate; fostering an environment of first solving difficulties, and then learning from them to make it easy for the project team to provide early warning of issues; keeping key stakeholders, including the Minister where relevant, informed in a timely and relevant way of any emerging risks to project delivery; and a focus on continuity of purpose for the project sponsor and project board to take a helicopter view of how well the project is tracking toward the business outcomes in the approved business case.
Monitoring: Green, green, green, RED!

My greatest learning as a member of a major project board was gained, as most lessons are, the hard way. We had an apparently wonderful system of monitoring, with a summary traffic light report on key aspects of the project. Month after month, the status reports to the board showed green lights not even an amber light. Then, the status report went red all over. The problem was that some hard things had been scheduled late in the project. All the easy things had gone well, but now quite late in the timetable the whole approach was in question.
The crucial learning for me was the importance of arranging the monitoring and sequence of activities to give maximum early warning on more risky parts of the project. These risky parts might be some individual component, or an integration issue, an end-to-end processing issue, or about user preferences. Finding and scheduling the risky parts as early as practical will take careful thought by the project team. But it is worth asking for, otherwise you may be in for a big surprise. agency division head.
SECTION
4
89
4.2 Typical project implementation phases

Typical project implementation phases are:
Having approved the right project, and having approved it the right way, to get benefits the project needs to be done right. agency planning guideline.
project initiation and appointments; detailed planning, such as more detail on requirements and implementation activities; acquire resources (including procurement); development (to fulfill business and ICT requirements, including testing);
Growing talent
Theres never enough experienced people to go round. I have one experienced person who is sharp-eyed on ICT and policy implementation, and who has the gumption to call a spade a spade. So Ive taken them off-line and appointed them to the project boards for all five of our new policy implementations. Theyre in a part mentoring, part monitoring role. That is sometimes delicate, but it helps develop the next generation of program branch heads and increase my confidence about how things are going. Deputy Secretary.
rollout the initial transfer of the project products into operational use; and handover to ongoing operation.
These phases will have been described in the project business case, for example in the project work plan, timeframe and budget. The phases are discussed below.
Project initiation and appointments

Following project approval, important contributors to success are formally initiating the project, and making key appointments. The formal project initiation involves having recorded agreement to key project parameters such as budget, timeframe, outcomes, and communication strategy to provide a firm basis for action.34 The appointment of people to the project governance arrangements documented in the business case, and to project leadership and project management roles is a key responsibility of the executive sponsor of the project.35 When making appointments to project management and advisory roles it is useful for the project sponsor to give consideration to the ability of individuals to: effectively communicate with, and on behalf of, any groups they represent; promptly identify current or impending difficulties during the project; and respond decisively to any difficulties so as to best achieve the planned business outcomes.
Given the large number of program implementation and business projects undertaken by some entities, there can be a shortage of people with relevant skills. Accordingly the appointments to key roles are also a valuable opportunity to develop the skills of entity staff.
34 This could be based on the project controls described earlier in section 3.3 of this Guide. There is a more detailed description in the PRINCE2 methodology process initiating a project. 35 The project business case should have described project governance arrangements such as role descriptions and committee arrangements. For some projects, appointments may have already been made to oversight preparation of the business case. In other cases, many of those who developed the business case may have moved to other roles, and most appointments will be made once the project is approved.
90
Useful activities for the project sponsor to consider at project initiation include: arranging a project launch activity to introduce key people to each other and gain an understanding of, and commitment to, the projects goals; ensuring those involved in various roles such as members of the project board are aware of their roles and responsibilities; reviewing the representation in governance processes previously agreed in the business case, and making any adjustments warranted in light of circumstances; and arranging independent assurance, particularly for large or higher risk projects. The project launch is a great time to get everyone familiar with the heart of the business case: why we are doing the project, and what and when we will deliver. Project sponsor.
Case study: Major project appoints independent assurer

an agency undertaking an overhaul of its core iCt systems in a four-year project appointed an independent firm to provide assurance as part of the overall project governance. the assurer provided advice directly to the deputy Secretary, giving an independent assessment of progress, of risks to the project delivery, and of the project teams response to any difficulties. the agency included this extra level of governance because of the size and importance of the project.
Detailed planning
Generally, agreement to a project is given based on a description of the project requirements in the business case that is sufficiently detailed to develop a reasonable estimate of the projects costs, business outcomes and timeframe, but which may not be sufficiently detailed to actually implement the project or to seek firm proposals from a procurement process. In this context, the next major activity is often developing a more detailed description of the project requirements.36 The detailed description of requirements may be used as the basis for procurement activity for example, as part of the tender documentation. It will also, where applicable, be used to prepare detailed implementation work plans for internal staff which can in turn be used to prepare more accurate estimates of the project cost, timeframe and resource needs. When undertaken, the more detailed project requirements will expand the project requirements provided in the approved business case and, as appropriate, indicate particular project products needed to fulfill these requirements. In other cases there may be advantages in approaching the market for solutions based on the broad definition of the requirements already provided in the business case. Specific products may not be described for those requirements to be fulfilled by procurement action. It can be preferable to allow tenderers to offer innovative solutions to meet the requirements. Even when external providers are being used for much of the project, there are usually many activities involving in house staff that will need detailed planning such as rollout and preparation for transfer into ongoing operation. Important activities for the project sponsor during this phase are liaison with key stakeholders who will be affected by the projects implementation, and management of the project team
36 In the Gateway Review process this level of detailed planning is equivalent to Phase 3 Develop Procurement Strategy, followed by Gate 2 Procurement Strategy. In the ICT Two Pass process, and depending on the project, this work would be undertaken between first pass approval and second pass consideration.
SECTION
4
91
undertaking the detailed planning. In many cases the detailed planning will be done by the team which prepared the business case. However, in other cases there may be a delay between preparing the business case and approval, and the business case team may have moved to other work. In these cases, time and effort will be needed to select and brief a new team. Detailed project planning will provide additional information about the feasibility, cost and benefits of the project. Before proceeding to the next phase acquire resources the project sponsor should assure themselves that: the project remains feasible, and that the necessary resources are likely to be available internally or in the market-place; the projects benefits, cost, and timeframe remain consistent with those on which project approval was based; the detailed requirements have been cleared with relevant stakeholders including user representatives for any new ICT systems; risks and assumptions have been reviewed and remain appropriate; the project business case has been reviewed and updated to reflect any new information including as a result of any policy adjustments or changed priorities since the approval was first given; and appropriate probity and recordkeeping practices are in place.
Where new information is inconsistent with information provided previously to decisionmakers, a judgement will need to be made about whether to seek approval for a variation to, or in extreme cases, cancellation of, the project.
Just-in-time planning
for some projects generally those which are smaller in size, of lower complexity, or where the requirements are uncertain one option is to reduce the amount of initial detailed planning and instead focus on incrementally developing the products of the project. With an incremental approach some basic requirements are delivered early, and other requirements then evolve in the context of a useful and workable product albeit a small product with only the most important features. to be successful, such agile approaches need to compensate for relaxation of the discipline of initial detailed planning by strengthened discipline in the areas of priority setting for requirements, testing, working cooperatively with stakeholders, management of product delivery, and cost control.
Acquire resources
Having undertaken detailed planning, and confirmed the project remains consistent with the approved business case, the next phase is to acquire the resources needed to implement the project.37 Typically these resources will provide capabilities associated with the actual work of the project, and for direct project management, probity advice and independent assurance. Where practical, it is useful to undertake forward planning and to pre-commit resources. However, in some cases the nature of resources needed may not be known until detailed planning is well underway.
37 In the Gateway process this phase of resource acquisition is covered by Phase 4 Competitive Procurement, followed by Gate 3 Investment Decision.
92
Resources may be provided by: internal staff and existing contractor resources; partner entities; or capabilities obtained through a procurement process.
For smaller projects, the project sponsor may have a personal role in acquiring project resources. For larger projects there may be a significant amount of work, and the project sponsor will appoint a person or team to acquire the project resources. Important activities for the project sponsor during this phase are: management oversight of resource acquisition with a particular focus on key governance, procurement and project management roles; and investment decisions, that is, whether significant project expenditure and deployment of resources should proceed.
The resource acquisition phase will provide additional information about the availability of resources and hence the project timeframe, and the likely cost particularly for capabilities for which a procurement process has been undertaken. Before proceeding to the next phase, the project sponsor should assure themselves that:
the planned resources, including those identified through procurement action, are sufficient to deliver the planned outcomes; the planned project management arrangements will provide them with reliable information on the progress of the project; important stakeholders remain committed to the projects objectives and its priority; and risk mitigation activities identified in the business case are being undertaken and there are reliable arrangements to manage risk during project implementation.
Before committing resources to undertake the development work of the project, including the signing of contracts following procurement action, it is good practice for the project sponsor to meet with the relevant project governance group, to gain assurance on the value and feasibility of the project and document the reasons for proceeding, or not, with the project. For major projects, the entity chief executive, the Minister, or central agencies may need to be involved in the investment decision to commit funds.
Development
With resources available, the next step is the development phase that is, creating the products of the project.38 Even in those cases where the products are being obtained though a procurement process, it is prudent for the project sponsor to closely monitor the development stage. Important issues for the project sponsor during the development phase are: monitoring progress including being alert to possible difficulties or timeframe slippages, or the occurrence of any triggers for reference to the decision-maker on possible project exit; and
38 In the Gateway process this phase of resource acquisition is covered by Phase 5 Award and Implement Contract, followed by Gate 4 Readiness for Service.
SECTION
4
93
focusing on the active involvement of all stakeholders this will help ensure the details of development are in accordance with stakeholder expectations and that testing is thorough and at a practical level.
Design principles save time and money

I find it very valuable to work with the project board and agree a set of design or architectural principles to help guide development. No matter how detailed the specifications are, there are always many choices to be made by the development team. Having these choices guided by a set of principles which have been debated and approved by the project board saves time and money, and keeps the deliverables consistent with our vision. Project sponsor.
For many common APS projects, the development phase will include the two major strands of work: business-oriented project products requiring development including detailed policy (for example, expanding on broad policy agreed by government), associated legislation and regulations, and training for staff and other affected groups. ICT development work that may involve developing project-specific software, tailoring of off-the-shelf software packages, integration of new software with existing software, developing databases, and populating them with information. There may also be associated acquisition of ICT equipment, either for use in a data centre or for wide deployment (such as data input devices in public spaces).
Where the project involves two or more strands of work, it is important for the project sponsor to ensure there are arrangements to coordinate these activities. From a senior executive perspective, it is useful to observe that development of the full range of products for a particular project may involve concepts and language that are specialised and unfamiliar to the executive. Gaining an understanding of these concepts, or obtaining advice from an independent adviser, is important in helping the executive fully understand project status reports and the implications of any project difficulties. Achieving the right quality, of the right products, in a timely manner will be assisted by the project sponsor giving attention to: oversight of product testing; managing requests for changes to the project; and a pre-rollout review.
The planning payoff

"I find the development stage is when a lot of the hard work in formulating the business case pays off. I chair the project board defined in the governance section, as we monitor the key milestones from the implementation section, while keeping an eye on risks and costs. And because of the consultation during planning there is commitment during development. Project sponsor.
Oversight of product testing

Testing involves gaining assurance that the products being developed meet their specification and work effectively. Testing of some sort is applicable to most project products, including for example, publications, computer systems, legislation or new call centres. Testing can be applied at different levels, such as at the level of individual parts or components, and at the level of the system or all parts working together as an integrated product. It is possible that the components of a project will successfully pass acceptance tests but that the overall system or product does not work as intended. Effective testing will use several approaches. For example, component level testing is quick and cheap but narrowly focused; while system testing is more expensive but provides overall assurance that all the components work properly together (see Appendix G Types of testing on page 114 for more details). In particular, testing of any new system or product can be expected to be more effective if it includes representatives of the proposed users of the system or product.
94
To help provide effective testing, the project sponsor should gain assurance that: the range of tests planned and undertaken are appropriate for the size, complexity and importance of the project; reports of testing to governance committees focus on business implications and user perspectives (rather than technical aspects), and include the type and scope of tests; and there are arrangements to track and resolve problems identified by testing.
Managing requests for changes to the project

During the development stage, it is common for requests to be made for additional features or for new requirements to be met. To rule out any additional requests may mean that important lessons from the development process are ignored. Conversely, to allow many requests, resulting in what project managers call scope creep, can significantly increase the cost and duration of a project. An important principle for managing such requests is to make a robust assessment of the value of the proposed change in relation to its cost. In this context it is worth noting that some apparently small changes may have a disproportionate cost due to the need to make adjustments to other parts of the project. In addition, there can be a significant cost in simply assessing requests for changes.39 Another important issue in assessing change requests is maintaining a focus on the approved business outcomes to reduce the risk of any inadvertent shift in emphasis away from those outcomes. Finally, a large number of change requests during implementation may indicate shortfalls in the identification of project requirements. If these change requests are a sign that the approved timeframe and budget will not be sufficient, then the project sponsor needs to consider whether to reduce the scope of the project, or to seek an increase in the timeframe and/or budget.
Pre-rollout review
Following a successful development phase and before implementation or rollout of the project products, the project sponsor should assure themselves that: the products meet the full range of project requirements, such as functionality, reliability, and operating cost; key stakeholders support a move to implementation and remain committed to their role; there is a pre-implementation measurement (the baseline) of the business outcomes and associated performance indicators; plans and resources for an effective rollout are in place; where a procurement process has been used, there is appropriate protection of the Commonwealths position as the work is coming to an end (for example, ensuring all operational testing is completed in accordance with the contract prior to final payments or lapsing of guarantees and indemnities); and where there have been changes to the original project scope (such as added features, or deferral of features) relevant stakeholders are aware of the changes and their implications, and communications strategies are amended as appropriate.
39 If many variation requests are expected, it may be preferable to adopt one of the agile project management methodologies, which focus on reducing the cost of assessing whether suggested new requirements should be included in the work plan.
SECTION
4
95
Project rollout
Having developed the products required to fulfill the requirements of the project, the products need to be put to use. This is usually treated as a distinct project phase, covering such activities as: measuring performance indicators immediately prior to introduction of new project products (to help assess the specific impact of the project); installation of equipment and software, as needed; training for those who will use the new products in their work; publicity or communication to those who will be affected by the project; transferring data from obsolete or legacy systems to new systems; ceasing use of previous products; and monitoring and responding to difficulties during implementation.
Communications
My main focus personally during rollout is communications; the project team is doing the actual delivery. I have found it best to update the communications strategy from the business case toward the end of development, so it takes into account any new issues and people and is ready to use when I need it. Project sponsor.
Include a warranty period

I find it useful to specifically identify a period during rollout where the development team and the operational team overlap a bit like a warranty period. Lots of practical problems often emerge in the first few months of operations, and it is important to ensure that a sufficient number of the development team remain to immediately work on these problems. Program delivery branch head.
These activities can take significant resources, and require detailed planning to avoid disruption or inconvenience. During this phase, it is likely that many people with little or no experience of the project will become involved or will be affected. Reflecting this, two main priorities during implementation are ensuring that the project products perform as expected when used in real life, and assisting people affected by the changes introduced by the project. Important areas for involvement by the project sponsor immediately before and during the project rollout phase are: Being confident that the project team has the resources and detailed plans for a smooth implementation. This includes providing guidance to the project team on the expected performance levels and the limit for any disruption during implementation. Given the cost implications of setting very high expectations, it is reasonable that different projects may use different resource levels to support rollout, depending on the risks and nature of potential impacts. Reviewing the expectations of those who approved the project in comparison with the likely short-term results, and providing appropriate briefings to avoid any surprises. These expectations can relate to the expected direct benefits of the project and to the manner of implementation. Reviewing implementation risks, and allocating sufficient resources to provide appropriate mitigation, including the availability of options to pause or roll back the implementation elements of the project if serious difficulties emerge. Managing senior-level relationships with any additional groups of people who become involved in the project following its implementation. These additional groups may be those who will use the project products, those who will benefit from the project, and additional resources engaged to support implementation. Close monitoring of the progress of the rollout, with prompt responses to any serious issues and a methodical approach to recording issues for less urgent resolution. Active oversight of the communications strategy, including the timely provision of welltargeted information to those affected by the project, and effective feedback arrangements so the sponsor is aware of any issues or concerns.
96
Following a successful implementation / rollout phase, before closing the project and transferring the products to ongoing operational use the project sponsor should assure themselves that: the products, in the context of full operational use, meet the full range of project requirements, such as functionality, reliability, and operating cost; any issues identified during implementation have been resolved, or have had responsibility for resolution transferred appropriately; and legal and contractual matters for the project are properly completed.
Project closure and handover

The completion of the project rollout brings the project to the point of closure. In most cases there are project products such as ICT systems, program guidelines and legislation which will be transferred to ongoing operations. Important areas for attention by the project sponsor during the handover stage are: arranging the transfer or allocation of responsibility for achieving the ongoing business outcomes which were agreed at the time of project approval; The project completion report compares the actual results to the approved business case.
assisting with setting budgets for ongoing operations and maintenance using information from the development and rollout stages; establishing performance measurement arrangements, to support ongoing management and, as appropriate, post-implementation evaluation of the project; transferring any residual work, for example, disposal of surplus assets; providing a completion report on the project to the decision-maker, including the results, time and costs of the project in comparison to the approved business case; and project closure, including both administrative requirements, and taking the opportunity to celebrate the achievements of the project team.
For more complex projects or for programs of projects, there may be important benefits which arise from the interaction of the products of several projects. It may not be practical or appropriate to nominate the operational manager of a particular product as being responsible for these broader benefits. In such cases it is good practice to assign to an appropriate executive the responsibility and necessary authority to realise these broader benefits.40 After a period of use of the project products, it is good practice to conduct a post-implementation review of the extent to which planned business outcomes and other benefits have been achieved.41
40 There is a wide literature on benefits realisation. See for example: Office of Government Commerce, Managing Successful Programmes, 2007. 41 For projects using the Gateway Review process, this is Gate 5 Benefits Realisation review.
SECTION
4
97
4.3 Concluding remarks

Reflections of a project sponsor and decision-maker
Some of the proudest and most enjoyable times of my career have been major APS policy implementations for which I was project sponsor, such as implementing a new national program that affected the lives of millions of Australians. The best of these projects started from a firm foundation of project planning, with clear objectives and an appropriate timetable and budget. On the other hand, some of the more difficult times were projects that lacked a foundation of proper project planning. When I was first promoted to the Senior Executive Service, I found that a huge volume of material went through my hands so I had to learn how to focus on the most important things, and delegate the detail. I was now responsible for major decisions. To assist, staff provided me pages of detail, including alerting me to all the ifs, buts and maybes. Then I had to balance all the shades of grey, and crystallise them into yes, or no. The relevance of that to my later role as a decision-maker on many projects across the Division was that I needed to work out the most important things to focus on in a project concept planning session or in a draft project business case, to help make that yes or no call. Over time, I privately boiled it down to four questions and two habits. The four questions (with variations) are: Do I understand the project outcomes? What are the tangible measures? What exactly do we get for the money? Who cares about the outcomes? How important are the outcomes to the department or Minister? Will partners work on the project enthusiastically? Do I believe the time and cost? Who costed it; what is their track record; have they allowed for the inevitable problems? Will that money really deliver the outcomes? What are the fallbacks? If along the way a show stopper appears, is there a graceful exit or tolerable fallback? The two habits are: Make time for planning a calm day of planning now is far preferable to a hectic week of problems later. I made time for stakeholders, guidance and review, and I allowed staff enough time for planning. Pursue doubts I found that if I had a hunch there was a weak spot in a business case, when it was looked into there often was a problem. So, if you are making the decision listen to your inner voice. Better to ask the question and have it settled, than decide with a nagging doubt. Senior Executive, program delivery role.
This Guide has been prepared to assist executives with the challenges in planning and approving successful projects. There is guidance on supportive arrangements for planning at the entity level, and a structured approach to individual project planning and approval. The Guide provides practical support for the issues mentioned conversationally in the above case study: clarifying the purpose and value of the project, obtaining a robust assessment of its cost and feasibility, and setting the controls and governance for subsequent implementation. The successful planning, approval, and implementation of projects contributes to the quality and efficiency of program delivery by government entities, and positions the executives involved for even more challenging projects in the future.
98
Contents:
A Glossary, acronyms and abbreviations (page 99)
glossary
acronyms & abbreviations
B Related government policies (page 102) C Sample project concept (page 104) D Categories and examples of requirements (page 106) E Sample key controls for project approval (page 107) F Questions for executive review of project proposals (page 110) G Types of testing (page 114) H Additional sources of information (page 115)
related government policies

APPENDICES
Questions
100
Planning and Approving Projects Better Practice Guide back of appendices divider
Appendices
A Glossary, acronyms and abbreviations
AGIMO ANAO APS Business case australian Government information Management office australian national audit office australian Public Service a document that provides a decision-maker with the information they need to make a fully informed decision on whether a project investment should proceed. Cabinet implementation unit an organisation subject to the Financial Management and Accountability Act 1997 (fMa act) or the Commonwealth Authorities and Companies Act 1997 (CaC act). department of finance and deregulation a project assurance methodology that involves short, intensive reviews at critical points in the project's lifecycle by a team of reviewers not associated with the project. information and Communications technology a process in the australian Government whereby certain projects provide an initial business case, to seek approval to prepare a more comprehensive business case. Managing Successful Programmes a program management methodology of the uK Governments office of Government Commerce. the department of Prime Minister and Cabinet Portfolio, Programme, and Project Management Maturity Model (P3M3) is a framework with which organisations can assess their current performance and put in place improvement plans. P3M3 is owned by the uK Governments office of Government Commerce. the risk remaining after management takes action to reduce the impact and likelihood of an adverse event, including control activities in responding to a risk. the level of risk that an organisation is willing to accept.
CIU Entity
Finance Gateway Review Process
ICT ICT Two Pass Review Process MSP
APPENDICES
PM&C P3M3
Residual risk
Risk appetite
There is a glossary (on the following pages) of terms particularly relevant to the planning and approval of projects. This is intended to assist readers of this Guide, and to provide a sample of guidance that entities could issue to help build a shared understanding among staff involved in project planning of relevant planning concepts and terminology.
SECTION
99
Project planning and approval terms

Note: the following sample glossary is of terms related to project planning and approval terms as used in this Guide. It is not a full project management glossary; it focuses on concepts relevant to obtaining a clear definition of the project. There are many additional project management terms relevant to detailed planning, such as those associated with risk management, progress reporting, defining and scheduling individual tasks, and with subsequent management of the project. A brief, targeted glossary such as this may be useful to staff whose main focus is describing projects, during planning. Entities are encouraged to adapt this glossary to their particular circumstances and preferred usage. ROLES AND PROJECT GOVERNANCE Project sponsor the executive promoting the project proposal, and accountable for the business outcomes used to justify the expenditure. in practice the sponsor may delegate running the project to a project executive. depending on the nature of the project, when acceptance criteria are satisfied the sponsor may transfer responsibility for business outcomes to an operational manager. the person (or body) who approves the project. there may be preliminary clearances (for example of technical feasibility), and subsequent expenditure approvals, but it is important to be clear who approved the project. represents the interest of the people who will use or operate the project products. also called senior user(s). represents the interests of the major suppliers who will provide or develop the project products. a person, or group, affected by or with an interest in the project. for example, potential beneficiaries or users of the products delivered by the project. a committee established to assist the project sponsor (or their delegated project leader) in the management of the project. often includes the senior supplier, operational manager, and relevant stakeholders.
Decision-maker
Operational manager
Senior supplier(s)
Stakeholder
Project board
TERMS USED TO HELP DESCRIBE, OR DEFINE, A PROJECT Acceptance criteria Criteria to help decide whether the products delivered are fit for purpose. for example, a computer system may need to correctly assess applications in accordance with legislation. Similar to requirements, but written in a way to assist acceptance testing. any assumptions about the availability of resources or other dependencies needed for the project (such as services, facilities, and staffing) which should be made visible for review during planning. if these are not in fact available they will affect project completion and the issue will need to be addressed. expected improvements as a result of a project. See Business outcomes.
Assumptions on resources and dependencies
Benefits
100
Planning and Approving Projects Better Practice Guide | Appendices
Business outcomes
the specific business results of interest that will be achieved through the use of the project products for example 20 000 applications assessed per month. this Guide generally uses this term, to help focus the attention of the project sponsor and decision-makers on specific, accountable business results of the project, and to help avoid any confusion over broader consequential benefits for which accountability may not be assigned. not negotiable elements, such as the project should finish by a certain date, or have a limit on its budget, or meet a defined standard. Some issues could be described as a constraint or a requirement the most important thing is that they are identified, so they can be taken into account in planning. another term for a project product. a milestone where progress is assessed, and if any difficulties cannot be resolved, could serve as the end of the project. often useful to consider and define potential exit points during planning. describe the tasks and actions that need to be accomplished. for example: assess an application against specified criteria; make a payment; and prepare a specified report. Significant completion points in time. used to track progress or specify preferred or required completion times. May not necessarily have any associated delivery of products. describe criteria used to judge the overall quality of a system or product, rather than its specific behaviours. for example, factors such as capacity, usability, security and performance. a short description of the main reason for the project. an item that will not be delivered by the project (e.g. creating a web site is in scope, but the updating of content is out of scope). Providing a list of out of scope items, particularly items that stakeholders may have thought would be provided, helps avoid confusion or disappointment. Group of related tasks designed to achieve a specific milestone and usually an interim deliverable, which adds to the successful delivery of the project's final deliverables. the specific outputs of the project as a result of work carried out. the project products should fulfill the project requirements. Sometimes called deliverables. a time limited endeavour undertaken to create a unique product or service. every project has an end. a description of what the project products will achieve. often categorised as functional and non functional requirements. the same requirements may be able to be fulfilled by different products hence it is useful to be clear on the requirements first, before settling on the exact products. the boundary or limits of the project. May be defined conveniently by a list of descriptive phrases (e.g. the scope includes a new iCt system, data upload, staff training and drafting legislation). defined more exactly by the list of requirements and / or list of products.
Constraint
Deliverable Exit points
Functional requirements Milestones
Non-functional requirements
APPENDICES
Objectives Out of scope
Phase
Products
Project
Requirement
Scope
SECTION
101
B Related government policies

The following procedural requirements relevant to certain project proposals are intended to improve the quality of proposals, to support well-informed investment decisions and to check that proposals are aligned with Government strategies. These requirements are periodically updated; the most current details are available through the web sites for the Department of Finance and Deregulation (Finance), and the Department of Prime Minister and Cabinet.
The ICT Investment Framework

Finance provides information on the ICT investment framework at <http://www.finance.gov.au/budget/ict-investmentframework/index.html>. Advice on any recent enhancements and on the detailed operation of the Framework is available by contacting the Department. Three elements of that framework are the ICT investment principles, the ICT Two Pass Review process and organisational capability.
ICT Investment Principles

Principle 1: Government should be provided with sufficient information from an agency and whole-of-government perspective to enable appropriate assessment of allocation of funds for ICT-enabled business change programs and projects. Principle 2: Agencies are responsible for the effective, efficient and ethical use of resources to deliver the Governments requirements (section 44 of the FMA Act). Agencies will ensure they have adequate governance and monitoring processes in place to achieve this. Principle 3: Investments in new business capability involving ICT should be justified by and measured against costs and benefits. Principle 4: Agencies are responsible for measuring the outcomes achieved by ICT and the return on the investment in ICT and for sharing learnings across government at key points in each projects lifecycle. Principle 5: Finance is responsible for developing, in consultation with agencies, the Frameworks that assist agencies to achieve the efficient and effective use of ICT by the Australian Government. Finance will do this through: facilitating reuse, interoperability, sharing and collaboration; encouraging use of standards; and strategic guidance to agencies and advice to Government on ICT investment. Principle 6: Central agencies will support agencies to enhance skills in managing ICT investments, by co-ordinating the provision of information, tools and training.
ICT Two Pass Review

The ICT Two Pass Review process helps obtain better information to support Government decisions on major investments in ICT-enabled proposals, and also better positions agencies for the Budget and Gateway Review processes. Proposals are subject to the ICT Two Pass Review process if they: are ICT-enabled (that is, the policy or service delivery outcomes are highly dependent on the underpinning ICT system); have a total cost estimated to be $30 million or more, including ICT costs of at least $10 million; and involve high risk in terms of cost, technical complexity, workforce capacity or schedule.
The Government may also apply the process to other proposals where it considers the proposal would benefit from the review. The process does not apply to proposals from the Department of Defence, which has its own two pass review process.
102
Organisational Capability (P3M3)

Agencies subject to the Financial Management and Accountability Act 1997 (FMA Act agencies) are implementing the Portfolio, Programme and Project Management Maturity Model (P3M3) as a common methodology for assessing their organisational capability to commission, manage and realise benefits from ICT-enabled investments. This initiative commenced in 2009 as part of the Governments response to the recommendations of the Review of the Australian Governments Use of ICT and aims to strengthen governance of the lifecycle of ICT investment including business domain activities such as requirements definition and benefits realisation.
The Gateway Review Process

The Australian Government has introduced the Gateway Review Process42 to support the on-time and on-budget delivery of major projects undertaken by Financial Management and Accountability Act 1997 (FMA Act) agencies. The arrangements are coordinated by the Gateway and Training Branch, within Finance. Gateway is a project assurance methodology that involves short, intensive reviews at critical points in a projects lifecycle by a team of independent reviewers (the Gateway Review Team). The Gateway methodology consists of six defined stages (Gates), which are aligned with a projects lifecycle. The gates are: 0 Business Need, 1 Business Case, 2 Procurement Strategy, 3 Investment Decision, 4 Readiness for Service and 5 Benefits Realisation. Gateway reviewers are experts in their field, who have extensive relevant experience and have been accredited by the Gateway and Training Branch. The appointment of members to the Gateway Review Team for a project is based on the risk level identified through the Gateway Risk Assessment Tool an Excel-based tool used to assess the inherent risk of projects, available from <www.finance.gov.au/gateway/gateway-risk-assessment-tool.html>. A Gateway Risk Assessment must be completed and submitted to the Gateway and Training Branch for all project and procurement proposals where the project: is to be considered by the Australian Government; will be managed by an agency that is subject to the FMA Act; and is costed at or above the relevant Gateway cost threshold of $10 million for information technology projects and $20 million for other procurement and infrastructure projects.
APPENDICES
The Government may agree to apply Gateway to projects that meet the financial threshold and are assessed as high risk after completion of the Gateway Risk Assessment Tool. Further information is available from <http://www.finance.gov. au/gateway/index.html>.
Implementation requirements administered by the CIU

New Policy Proposals are required to include an implementation statement. The Cabinet Implementation Unit (CIU) will request implementation plans from agencies where the initiative is a key government strategic policy that the CIU is monitoring. The CIU is part of the Department of the Prime Minister and Cabinet. The CIU helps the Prime Minister and the Government manage and deliver the Governments strategic reform priorities, including reporting to the Prime Minister on progress with the delivery of these priorities across the Australian Public Service. A range of project management and implementation resources is available on the CIUs website, <http://www.dpmc.gov.au/implementation/index.cfm>. These include: Guidelines for Cabinet Submissions and New Policy Proposals; Implementation Plan Guidelines; Program and Project Management Support; and Further resources across the Australian Government, states and territories, international, and other networks and contacts.
42 Department of Finance and Deregulation, Financial Management Guidance No. 20 Guidance on the Gateway Review Process A Project Assurance Methodology for the Australian Government.
SECTION
103
C Sample project concept

This appendix provides an example of a project concept document, showing high high-level outcomes and requirements. Project concept planning is discussed in Section 3.1 (page 45). The issues described are basic. Identifying and resolving basic issues early is a strong contributor to the success of projects. This example uses headings that are generally useful. However, depending on the purpose of an entitys project concept document for example promoting discussion, or as part of a process of comparing project concepts other headings may be more appropriate. Entities should adopt an approach and format that fits in with their own broader planning processes.
PROJECT OBJECTIVE: REPLACE SIX ADMINISTRATIVE SYSTEMS WITH A SINGLE SYSTEM Background: The six systems to be replaced are 10-15 years old, and are used by most staff. These systems consolidate data from program-specific systems. There is duplication of functions, as systems were developed by business units when they were parts of other entities. Many providers and clients have different identifiers in different systems, which makes consolidated reporting slow and expensive. Relevant internal policies: The solution will be a commercial off the shelf system; it could be externally hosted. The entity will adopt the business processes of the purchased solution. (This is to reduce future costs of maintenance, and attain consistent business processes across the entity). Business Outcomes: (expectations of a successful project) O1: ICT Savings $5m p.a. O2: Central, accurate data reduction of current iCt system costs from $10m p.a. to $5m p.a. a single, easily accessed source of administrative data, to inform Minister and entity executive. data issues (duplications / errors / definitional problems) resolved prior to data transfer to new system. no net increase in time for line staff to do administrative tasks (accepting there may be changes for individual staff). Preferably a decrease.
O3: Capped staff administrative effort
Key Requirements R1: Functional equivalence all current business activities supported (noting that the detail of some business processes will change). expected system and support lifespan: at least 5 years. existing systems decommissioned within 2 years, so can harvest savings. arrangements to ensure any data in new system meets new agreed definitions and is accurate. Staff properly trained in new administrative processes. the combination of time per data screen, and number of screens per business transaction should be at least as fast as at present.
R2: Longevity of replacement R3: Timely decommissioning R4: Data cleansing process
R5: Staff training R6: Efficient transactions
104
Non-functional requirements: Standard entity requirements for security, usability, data backup, and disaster recovery. Availability: high. Outages of more than 1 day per year would be serious. Users: 2,000 approximately. Data: approx 3 Terabytes, for 2 million clients and 10 000 service providers. Constraints: Switchover of systems should occur in January when workloads are less. Key Risks: Undocumented special functionality in old systems may delay or derail project. Cost Range: $5m $10m.
Alignment
Diagram: Showing important contributions of project requirements to project outcomes, and of project outcomes to corporate goals.
Project requirements
Business outcomes
Corporate goals
R1: Functional equivalence R2: Longevity of replacement R3: Timely Decommissioning R4: Data cleansing process R5: Staff training O3: Capped staff administrative effort R6: Efficient transactions Employer of choice O1: ICT Savings $5m pa Client service
APPENDICES
Support Minister
O2: Central, accurate data
Internal Efficiency
Discussion of above sample project concept

1. describing requirements and outcomes with a short phrase coupled with a succinct definition often provides a useful balance of convenience of discussion and clarity of meaning. 2. there can be debate on the categorisation of an issue as an outcome, requirement, or constraint. in this example, the group developing the concept plan considered that it was important to give equal prominence to the workload for staff not increasing as to the financial savings, so both are shown as desired business outcomes. the best approach will depend on individual circumstances and entity priorities. 3. in this sample format, all the entitys corporate goals are listed, whether or not a project contributes to them. this helps remind project sponsors of the goals. naturally, many projects will make a strong contribution to a sub-set of these goals.
SECTION
105
D Categories and examples of requirements

It is useful for executives to be familiar with the common categories of requirements, to assist them in assessing the completeness of the requirements listed in the business case. Requirements at the concept stage are discussed from page 51, and at the business case stage from page 63. Functional requirements
Functional requirements describe the tasks and actions that need to be accomplished. For example: assess an application against specified criteria; make a payment; and prepare a specified report. Generally actions are taken in relation to data, so it is common to also identify data requirements as part of the functional requirements. Functional requirements are specific to the subject area. Identifying which functional requirements may be relevant to a proposed project can take considerable effort. If a project planning team does not have experience with a particular subject area, it is good practice for the project sponsor to encourage them to seek examples of functional requirements from colleagues or specialist advisers, to increase confidence that the relevant functions have been identified.
Non-functional requirements
Non-functional requirements describe criteria used to judge the overall quality of a system or product, rather than its specific behaviours. For example, factors such as usability, security and performance. Some examples of non-functional requirements are: Usability look-and-feel, ease of use, ease of learning, accessibility requirements, personalisation, and internationalisation. Performance requirements speed, reliability and availability, safety, and fault tolerance. Capacity requirements number of transactions, number of users, data storage volume, and data transfer capacity. Adaptability requirements ease of catering to greater capacity needs, ease of adding or changing functionality, ease of integration with other systems, and ease of transferring the system to other environments. Operational requirements compatibility with planned operating environment, ease of support and maintenance, and operating costs. Security and privacy requirements access control, security classification, privacy, and data and system integrity. Business continuity data archiving, data backup and data recovery. Audit requirements audit access arrangements, data retention, and event logging. Legal requirements compliance with legislation and relevant standards.
106
E Sample key controls for project approval

The project approval statement, as mentioned on page 81, is intended to help focus the attention of executives on the important high-level elements of a proposal and provide a concise formal record of the decision. As discussed in the Guide, characteristics of effective key controls for a project, from an executive perspective, include:
focus on key issues to avoid information overload on executives; business focus not technical detail; progressive testing and assurance to provide early indications of business outcomes; review points and exit options linked to progressive testing and assurance; coordination issues made visible to assist executive management of multiple projects; and exception reporting appropriate thresholds are specified.
The following example is for an illustrative project and demonstrates the above characteristics, as well as elements to provide for clear accountability as discussed on page 79. The extent to which entities adopt this sample format, including the emphasis given to each component, will depend on their individual circumstances.
Approval Statement for Project: Online Approval of Client Services
APPENDICES
A. Business outcomes: (1) Reduce the rate of overpayments to clients, from 6 per cent of payments to 0.5 per cent. (2) Reduce departmental costs by net $2.5 million per year ($3.2m staff saving in the Overpayments Recovery Section, offset by $0.7m operating costs for the new system). B. Project product: A computer system to allow contracted service providers to approve the delivery of service to an individual client in real time, including entitlement checking. In particular, this will avoid the delivery of services in excess of entitlements which currently occurs. C. Contribution to corporate goals (ICT Capability): This project will, among other modules, develop and deliver the new Provider Authentication Module, which will be used in all future provider related systems. D. Expected flow on benefit: Savings in program funds of $16 million a year (through avoidance of written-off debts). The exact saving depends on client eligibility criteria and entitlement rates. These are not within the control of the project so the saving of program funds is not a business outcome. E. Key operational targets following implementation (1 July 2012)
MEASURE Elapsed time for providers to obtain approval (data entry and system response time) Time to train a new provider in the system System capacity
TARGET 80% < 30 secs 98% < 60 secs 4 hours or less 2 500 providers, nationwide
SECTION
107
F. Key targets during implementation (to be reported to Investment Committee) JUL 2010 No. of module designs approved No. of modules coded and tested % providers signed up % providers connected 3 0 0 0 SEP 2010 10 0 0 0 NOV 2010 15 8 40% 20% FEB 2011 15 15 100% 60% APR 2011 15 15 100% 100%
Go-live date 1 July 2011 to coincide with issue of new annual entitlements rates. G. Review / possible exit points By 1 October 2010, report on end-to-end proof-of-concept testing, to confirm whether or not it is prudent to commence signing up providers. By 1 Feb 2011, report on tests of provider-related targets (i.e. approval processing and training times). Given concerns raised by peak bodies that the new system may increase costs for service providers, this is a critical requirement to be settled well before the planned go-live date. H. Project Financial Schedule ($m) 2010-11 Capital (development) Ongoing system costs Implementation costs Gross administrative savings Total internal funding I. Business Plan impact The elements of the funding schedule for this project will be shown as separate line items in business plans. Client Services Branch will have an additional $4.0 million in 2010-11 to undertake the project. Development and ongoing funding will be held by Client Services Branch and paid to IT Services Branch on a user-pays basis. From 2011-12 onwards, Client Services Branch will have its ongoing funding reduced by $2.5 million a year (to, in effect, repay the initial project funding from the Investment Reserve, and subsequently in support of broader cost reduction targets). J. Supporting sign-offs This project approval has been given based on the following assurances and recommendations related to the above deliverables and targets, based on project plan Online Approval Plan version 1.2: The implementation activities ($1.8m) and system specification in the project plan are necessary and sufficient to achieve the business objective. If the system operates as specified the $3.2m p.a. saving in Overpayments Recovery Section can be achieved. I am confident the project assumptions are realistic, and the risks are manageable within the time and budget. {signed} A.S. Client Service Branch (Project Sponsor, and future Operational Manager) The system specification in the project plan can be developed within 14 months of approval, at a development cost of $2.2 million and ongoing cost for infrastructure and maintenance $0.7 million a year. {signed} A.S. IT Services Branch (Senior Supplier) 2.2 0.0 1.8 0.0 4.0 2011-12 0.0 0.7 0.0 -3.2 -2.5 2012-13 0.0 0.7 0.0 -3.2 -2.5
108
The design in the project plan conforms to our IT architecture. The Provider Authentication Module must be developed to meet new security guidelines, even if this project is not approved. {signed} Director, IT Architecture The Investment Committee has reviewed this proposal and considers that the indicated costs and timeframe are realistic, that the proposed governance arrangements are appropriate, and in the context of all other proposals in this business planning cycle, recommends the project for funding. {signed} Chair Investment Committee (Reviewing body)
K. Project Approval The above high-level project parameters and funding are approved. The Project Owner should prepare detailed plans consistent with this approval and in accordance with the department's project management methodology, for detailed approval and monitoring through the branch business plan. Approved by {signed} Authorised Delegate. (Decision-maker)
Comments on the above sample of key controls for project approval:

Note the initial letter of each comment below refers to the letters of the section headings above. a. Business outcomes are the accountable results from using the products of the project. B. Project products are what the project will deliver. e. Key requirements of interest to the decision-makers. additional requirements will be in the business case. together with business outcomes, and product description, this provides a concise view of what the decision-maker receives for the investment. f. implementation targets help provide key control points to allow an executive perspective on progress during implementation. the key issue is choosing the most effective measures of progress. G. Possible exit points signal points where the decision-maker is informed of progress and has an opportunity to reconsider the project. identifying these points as part of approval helps ensure that such points are identified and reported on. i. including the flow on effects of approving the project to other entity controls, such as unit business plans, helps ensure effective overall management. J. obtaining and recording the key sign-offs that support the proposal helps improve the quality of the decision, because it reduces the risk that a critical part of assurance has been missed. it also provides clarity in the accountability of the various areas of advice used as the basis of the decision. Some elements, such as the sign off by the intended operational manager, are important to achieving the planned business outcomes.
APPENDICES
SECTION
109
F Questions for executive review of project proposals

1. Concept stage executive review questions
These questions are intended to assist executives to form judgements about a project proposal. Consideration of these high level questions should be complemented by appropriate quality assurance of project proposals being provided to executives. These questions may need to be tailored to take account of a specific entitys circumstances. Project name: Source document(s) reviewed: Reviewers name:
ISSUE The project has been developed in a broad context. Business outcomes are clearly expressed. Business outcomes have the extent of improvement or performance indicated. The business outcomes of the project are largely independent of factors external to the project scope. The focus is on business outcomes that are important to decision-makers and key stakeholders. There is a reliable chain of reasoning underpinning the key elements of the project. The broad project requirements which are necessary and sufficient to achieve the outcomes are listed. There is a definite contribution to one or more of the broader entity goals, such as: Client satisfaction Entity flexibility and capability Cost control Enabling staff Other Any important assumptions, risks or constraints are identified. Overall, there are achievable and tangible business results, supported by a reasonable logic for the major project requirements.
N.A.
COMMENTS (1)
n n n n
n n n n
n n n n
n n n n n n n n n n n n n n n n n n n n n n n n n n n
n n n
(1) For example, date reviewed, location of evidence to support response, and explanation of any N.A. responses. Legend: N.A. not applicable; Y Yes; N No. Definitions. Project products: what the project will deliver for example a payment system. Business outcomes: specific results, in business terms that will arise from the use of the project products for example, 100,000 payments per year.
110
2. Business case executive review questions
These questions are intended to assist executives to form judgements about a project proposal. Consideration of these high level questions should be complemented by appropriate quality assurance of project proposals being provided to executives. These questions may need to be tailored to take account of a specific entitys circumstances. Project name: Source document(s) reviewed: Reviewers name:
ISSUE
N.A.
COMMENTS (1)
Reason and specification: why the project is desirable, what is needed, when by, and at what cost The projects business outcomes, costing and timeframe are clearly described and are sufficiently reliable to inform a decision. Responsibility is allocated for all project products and expenditure and the delivery of the business outcomes. The business outcomes will be measured before rollout, and subsequently. The project requirements, or product description, are complete (covering, for example functionality, quality, volume, security). The right people have been consulted on project requirements. The proposed operational manager agrees the acceptance criteria for the project products. The proposed operational manager agrees the business outcomes are achievable with those products. Validation: that the approach is better than alternatives and is feasible Options have been thoroughly considered. The range of options provides a real choice to decision-makers on the level of investment. Risks have been reliably identified and assessed. Any significant residual risks from the project have been identified, and the relevant person is willing to accept them. Ongoing monitoring of risks and appropriate risk mitigation is included in the budget and activity plans. Assumptions particularly high impact assumptions have been identified and are either considered reliable or treated as a risk for monitoring and mitigation actions.
APPENDICES
n n n
SECTION
111
ISSUE Operational requirements (such as staff and accommodation) have been identified and budgeted for. Data issues are addressed: requirements, availability, security and privacy aspects, and ongoing data management.
N.A.
COMMENTS (1)
n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n
Implementation: gain confidence the project can be effectively managed and delivered The communications and stakeholder relationship approach is appropriate in concept and in resourcing to the size, risks and impact of the project. The project is compatible with other projects and workloads. The staging of the project takes account of the relative priority of the various business outcomes and related benefits. The staging of the project includes review and exit points that sensibly manage exposure to loss if problems occur. The entity has the capability to develop or procure the products. The resources are available or budgeted for product rollout and handover to operations. The roles, availability, skills and decisiveness of the project governance team are appropriate to the risks of the project. For cross-boundary projects, there is a shared understanding of, and commitment to, the project by the parties. Overall, the business case puts forward business outcomes that are realistically achievable within the proposed timeframe and cost, with appropriate risk mitigation, risk responses and fall-back options.
112
3. Consideration for approval useful executive questions

These questions are intended to assist executives to form judgements about a project proposal. Consideration of these high level questions should be complemented by appropriate quality assurance of project proposals being provided to executives. These questions may need to be tailored to take account of a specific entitys circumstances.
Project name: Source document(s) reviewed:
Reviewers name:
ISSUE The relative importance of the proposed outcomes and contribution to entity and government goals. The likelihood the project can be completed within the planned timeframe and costs. The allocation of responsibility for delivery of the project products and achieving planned business outcomes. The selection of the project option providing the most appropriate level of investment. The appropriateness of acceptance or action on significant residual risks. The appropriateness of project review and exit points to sensibly manage exposure to loss if problems occur. The appropriateness of the roles, availability, skills and decisiveness of the project governance team to the risks of the project. That the project complies with entity and APS policies, such as business strategies, ICT architecture and procedural requirements. That the project is compatible with other projects and workloads. The setting of specific controls at project commencement to provide senior management with the information needed for external liaison, to monitor progress and initiate any corrective action. Overall the project is an appropriate use of resources, taking into account the outcomes, costs, risks and alternative uses of funds.
N.A.
COMMENTS (1)
n n n n n n n n n
n n n n n n n n n
n n n n n n n n n
APPENDICES
n n n n n n
SECTION
113
G Types of testing
It is useful for executives involved with the development phase (such as the sponsor and members of the project board) to be familiar with the various types of testing, so they can make an informed judgement on the extent and results of testing proposed during development work. Testing of some sort is applicable to most project products, including for example, publications, computer systems, legislation or new call centres. The extent of testing significantly affects the quality and reliability of the product. Testing is discussed at page 94.
Types of tests, which can overlap, include: component level or unit testing of some small element of the project, such as a single ICT transaction or screen, or a single piece of equipment, or section of legislation; module testing of a group of components working together; system testing for all the components working together to achieve the desired effect or outcomes; logical or function testing that ICT or legislative components provide the results that are intended for each relevant set of circumstances; volume or stress testing that the products will handle the volume of work intended; user experience testing what the experience of using the product is like for clients and users, encompassing the full range of project products; end-to-end testing following the full path of possible usage of the project products. For example, from the application by a person for a payment, through to receipt of that payment by them. It is sensible to conduct end-to-end testing early possibly with a limited set of functions to help uncover any potential difficulties; configuration testing many commercial products require configuration to the particular needs of an agency. The basic configuration (for example, to an agencys ICT infrastructure), and possibly different configurations for different business units, need to be fully tested; usage scenario testing where the application of the project products to a set of business scenarios is tested. For example, a scenario where an application for a payment is refused with a subsequent appeal and complaint could help test, among other things, an application form, staff training, and the drafting of legislation and regulations; security, audit and recordkeeping testing to provide specific assurance that these aspects of the requirements are properly met; and pilot testing using the project products in a real-world situation but with a limited number of users, to help discover any issues prior to full-scale implementation.
114
H Additional sources of information

Note that references for Australian Government processes related to project planning such as the Gateway Review process, the ICT Investment Framework and the Cabinet Implementation Unit are provided in Appendix B Related government policies at page 102. Australian National Audit Office and Department of Prime Minister and Cabinet, Implementation of Programme and Policy Initiatives, 2006. This Better Practice Guide is intended for public sector chief executives and senior officers responsible for overseeing the implementation of an initiative. The focus is on overarching principles for effective implementation, drawing on the experience of agencies to date, as well as lessons from overseas. The aim is to assist senior executives to obtain assurance that appropriate approaches and methodologies are being followed. Available from <http://www.anao.gov.au>. Australian National Audit Office, Innovation in the Public Sector, 2009. The Innovation Guide provides a framework for understanding the processes that underpin innovation in the public sector and provides practical insights and a resource for practitioners. The Guide covers the full innovation process: developing options in response to need, implementing changes, and evaluating and adjusting those changes. The Guide also discusses the essential pre-conditions for innovation in an organisation. The Innovation Guide complements this Guide on Planning and Approving Projects, in particular through the Innovation Guides coverage of the generation of potential projects and the subsequent monitoring and adjustment of change initiatives. Available from <http://www.anao.gov.au>. Management Advisory Committee, Report No. 4 Connecting Government: Whole of Government Responses to Australias Priority Challenges, 2004. Connecting Government goes beneath the surface of the coordination that the APS strives to achieve. It examines the many different and sometimes competing imperatives that contribute to successful whole-of-government work and seeks to learn from our successes and failures. This report is available from <http://www.apsc.gov.au/mac/ connectinggovernment.htm>. Office of Government Commerce, Directing Successful Projects with Prince2, 2009, Stationery Office Books. This publication has been designed to be a role-specific handbook for senior managers and project board members, which describes how to oversee projects being managed using PRINCE2. The guide sets PRINCE2 in the wider context of project management and describes or cross-references techniques which support the PRINCE2 method.
APPENDICES
SECTION
115
Office of Government Commerce, For Successful Programme Management: Think MSP, 2007, Stationery Office Books. A short, clearly written introduction and practical guide to the Managing Successful Programmes (MSP) approach. It introduces the principles of MSP, and includes practical examples of MSP in action. Office of Government Commerce, Managing Successful Programmes (MSP), 2007, Stationery Office Books. This guide provides an adaptable route map for programme management, bringing together key principles, governance themes and a set of inter-related processes to facilitate the flow of business transformation. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 2008. State Government of Tasmania, Department of Premier and Cabinet, Tasmanian Government Project Management Guidelines, 2005. The Guidelines identify the key elements that should be applied in all projects, no matter what the size and complexity. The Guidelines focus on the management of individual projects. The Guidelines and a range of associated checklists and helpful project management tools are available from <http://www.egovernment.tas.gov.au/project_management>. State Government of Victoria, Auditor-Generals Office, Investing Smarter in Public Sector ICT: Turning principles into practice, 2008. This guide and its associated checklists have been designed to assist public sector chief executive officers (CEOs) and senior responsible officers (SROs) to question and assess whether their investments are delivering their intended benefits, resulting in better business and financial value for government and the public. Available from <http://www.audit.vic. gov.au/reports__publications/reports_by_year/2008/20080730_ict_bpg.aspx>. State Government of Victoria, Department of Treasury and Finance, Investment Management Standard, 2010. Investment management establishes a set of simple practices that allow an investor to clearly define the need for an investment, shape the solution and track the delivery of benefits throughout the investment lifecycle. The adoption of these practices has been shown to drive investments that are more effective at implementing policy and reducing the risk of investment failure. One of the approaches is an Investment Logic Map, to help describe and check the underlying reason for a project. Available from <http://www.dtf.vic.gov.au>.
116
INDEX
118
Planning and Approving Projects Better Practice Guide back of index divider
Index
A
acceptance criteria, 63, 100 accommodation, 48, 70 accountability and authority, 325 decision-making, 79 procurement, 38 see also governance arrangements; recordkeeping accounting system, 36, 62 acquisition of resources, 923, 94 see also procurement acronyms and abbreviations list, 99 advisers, 19, 50, 59, 94 conflict of interest, 39 agreements with other parties, 40, 70 confidentiality, 27 ambiguity, 47 appointments, 278 advisers, 39 business case development staff, 54, 55 to committees, 28, 39, 74 cross-boundary projects, 32, 33 project implementation phase, 90, 91, 93 approval, 218, 7881 checklist, 86 executive review questions, 86, 113 key controls, 81, 1079 objectives, 6 progressive, 64 recordkeeping, 40 related APS planning steps, 7 representation in, 278 variations in focus, 8; managing requests for changes, 95 approval committees, 19, 79, 80 APS planning steps, related, 7, 91n, 92n, 93n, 97n APS requirements, 3840 checklist, 42 APS Values and Code of Conduct, 39 architecture, ICT, 14, 15, 16, 24 arrangements, 842 assumptions, 53, 689, 92 see also reviews assurance, 22, 39, 55, 578, 59, 89 key project controls, 81 processes adopted by Government, 16 product testing, 945, 114 project size, 37, 55 provided to decision-maker, 78, 79 before resources committed, 93 about risks and assumptions, 68 authority, see accountability and authority
B
behaviour, 39 benefits, 4 cross-boundary projects, 77 deriving from project requirements statement, 63 detailed planning phase, 92 financial management arrangements, 36 government policy implementation projects, 7, 48, 50 issues for consideration for implementation approach, 73 options, 65, 67 project closure and handover phase, 97 project rollout phase, 96 see also cost-benefit analysis Budget funding, 26 Budget process, 8, 28 budgets, see finance and funding business case, 5477, 92 checklist, 845 executive review questions, 59, 69, 835, 11112 objectives, 6 project requirements statement, 635, 106 project size, 25, 56; requirements statement detail, 64 public private partnerships, 16 related APS planning steps, 7 steps in development process, 25 business need, see concept plan business-oriented project products, 94 business outcomes, 4, 4753, 1045 accountability for, 34 business case statement, 61, 62; operational managers agreement on achievability, 63 key controls, 107, 109 prioritising projects by, 31 programs of projects, 33 project closure and handover, 97 see also implementation; requirements business units, projects crossing, 32
INDEX
C
Cabinet Implementation Unit (CIU), 16, 103 capability, see entity capability changes to projects, 8, 95 chief executive, 5, 93 Chief Financial Officer, 32, 36 client service improvements, 47 measurement, 13, 31 clients, 68 communication, 71 involvement, 28, 74, 76 closure and handover, 97 Code of Conduct, APS, 39
SECTION
117
committee secretariats, 30 committees, 24, 28 for approval, 19, 79, 80 cross-boundary projects, 32, 33 ethics-related issues, 39 programs of projects, 33 project governance, 745, 95 see also project boards Commonwealth Grant Guidelines, 16 Commonwealth Procurement Guidelines, 38, 39 communication, 71, 88, 95, 96 cross-boundary projects, 77 communications facilitation projects, 64, 65 comparing implementation approaches, 723 comparing options, 67 comparing projects, 31 completeness and presentation screening criterion, 29 completion, 97 concept plan, 4553, 1045 checklist, 83 executive review questions, 83, 110 high-level project requirements, 512, 106 objectives, 6 reason for project, 54 reasoning of project elements, 48 related APS planning steps, 7 steps in development process, 25 see also business outcomes conduct (behaviour), 39 confidentiality, 27, 39 conflicts of interest, 39, 74 constraints, 56, 63 identified in concept stage, 53 on implementation approach, 72 on options, 66, 67 consultation, 278 about project requirements, 65 communication issues, 71 confidential, 27, 39 with Minister, 8 project governance committee representation, 74 see also committees content of business case, review of, 59 contingency allowances, 19 controls for project approval, 81, 1079 corporate goals, alignment with, 1113, 29 cost-benefit analysis, 36, 56, 634, 92 term assumption, 68 costs, see finance and funding CPGs, 38, 39 cross-boundary projects, 323, 767 culture, see people and culture
D
data, 35, 36, 70 data matching system projects, 34 decision-makers, 43, 98 better practices, 80, 86 completion report to, 97 key project controls, 81, 1079 decision-making, 234, 27, 76, 7880 client involvement, 28 ethical behaviour, 39 project governance committees, 74 see also approval decision-making time, 12, 13 delegated authority, 35 deliverables, see products delivery strategies, 1213, 14 Department of Finance and Deregulation, 28 detail provided in requirements statements, 64, 65 detailed planning during implementation, 912 development phase, 935 product testing, 945, 114
E
end users (recipients of benefits), 4, 63, 73 endorsement, 25, 29 business case, 589, 79 provided by committees, 24 entity arrangements, 842 entity capability, 8, 59, 75 ICT, 1415 entity capability projects, 7 accountability for business outcomes example, 34 concept stage example, 52 entity internal operational improvement projects, see internal operational improvement projects estimates, 20 see also finance and funding ethical behaviour, 39 executive review questions, 59, 69, 836, 11013 executive skills, 1718 executive summaries, 59 exit points, 75 expectations, 1920 expert advisers, see advisers external advisers, see advisers external funding, 26 external representation, see appointments external suppliers, 30
118
Planning and Approving Projects Better Practice Guide | Index
F
feasibility, 28, 92 executive review questions, 59 see also business case finance and funding, 61, 62 detailed planning, 91, 92 expense of requirements, 65 external, 26 operational requirements, 70 prioritising projects, 31 for procurement method, 38 project closure and handover, 97 resource acquisition stage information, 93 uncertainty of estimates, 20 variations, 75, 95 see also constraints; cost-benefit analysis financial assessment parameters, 62 financial management, 16, 36, 62 cross-boundary projects, 32, 77 delegated authority, 35 Financial Management Guidance, 16 fit for purpose arrangements, 8 fit for purpose products, 100 flexibility, 29, 33, 53, 73 format of business case, compliance with, 59 functional requirements, 106
H
handover and closure, 97 high-level requirements, see requirements
I
ICT, 1416, 24 as part of overall project, 94 government-wide, 16, 1023; planning steps, 7, 91n new computer system project proposals, 30 staff to undertake project costings, 62 standards compliance, 29 ICT Two Pass Review, 64, 102 planning steps, 7, 91n implementation, 8798 milestones, 74, 75, 77 product testing, 945, 114 related APS planning steps, 7, 91n, 92n, 93n, 97n implementation approach, 723 implementation plans, 16, 88, 103 validation, 54, 85 independent advisers, see advisers independent assurance, see assurance indicative success measures, 7, 13, 61 information sources, 11516 innovation, 69 inputs, see operational requirements interest, conflicts of, 39, 74 internal operational improvement projects, 7, 8 alignment with corporate goals, 13 business outcomes development difficulties, 47 cost reduction, 29 implementation approach example, 72 prioritising, 31 screening, 30
INDEX
G
Gateway Review, 57, 103 planning steps, 7, 91n, 92n, 93n, 97n timeframe for opinion, 58 generic risks, 69 glossary, 99 goals, 91 alignment with corporate, 1113, 29 high-level, 48, 49 risks and risk management, 30, 69; arising from high expectations, 1920 see also business outcomes governance arrangements, 2337, 745 checklist, 42 cross-boundary projects, 32, 77 governance committees, 74, 75 reports of testing to, 95 responsibility for appointments to, 90 government policies, alignment with, 16, 3840, 1023 screening criterion, 29 government policy (program) implementation projects, 7, 8, 26 business outcomes, 48, 50 confidentiality issues, 27 development phase, 94 Grant Guidelines, 16
J
just-in-time planning, 92
K
key project controls, 81, 1079
L
large projects, see size of projects launches, 91 legislative compliance, 29 letters of appointment, 39 liaison, 88, 91 see also consultation lifecycle, 48
SECTION
119
logic of project elements, 48, 114 long-term benefits, see benefits
M
milestones, 74, 75, 77, 94, 101 Minister and Ministers office, 8, 19, 47, 71, 88, 93 modular implementation, 73 monitoring, 36, 37 cross-boundary projects, 32, 77 implementation stage, 88, 89, 93, 96 risk events, 19, 68 see also reporting; reviews multiple criteria analysis, 31
N
necessity of project requirements, 51 non-financial resources, 62 see also people and culture non-functional requirements, 101, 105, 106 not negotiable elements, see constraints novelty, 69
O
operational arrangements, 19 operational improvement projects, see internal operational improvement projects operational managers, 4, 63, 97 roles and responsibilities, 5, 100 operational requirements (inputs), 70 data, 35, 36, 70 operational managers agreement on project requirements, 63 options, 63, 65, 667 Organisational Capability, 103 outcomes, see business outcomes outside funding, 26 outside representation, see appointments outside suppliers, 30 oversight roles, 74, 89 business case preparation, 559 skills, 1718 ownership of data, 35
P
P3M3, 103 partner business units, 32 people and culture, 1722, 70 business case developer, 55 business case development staff, 62
checklist, 41 detailed planning team, 92 ethical behaviour, 39 independent assurance can be obtained, 57 recipients of benefits (end users), 4, 63, 73 see also appointments; consultation; project teams; roles and responsibilities; skills; stakeholders planning, 58 project implementation phase, 912 recordkeeping, 40 representation in, 278 skills for, 201 support services for, 24 see also business case; concept plan; government policies, alignment with planning teams, see project teams policy compliance, 28 policy implementation projects, see government policy implementation projects Portfolio, Programme and Project Management Maturity Model, 103 powers of committees, 74 pre-rollout review, 95 presentation and completeness screening criterion, 29 priorities, 2831, 66, 73, 92 business outcomes development difficulties, 47 cross-boundary projects, 76 government, 72 prioritising decisions, 28, 31 procurement, 38, 39, 91, 93 multiple criteria analysis, 31 pre-rollout review, 95 reporting milestones, 75 product suppliers, see suppliers product testing, 945, 114 products (deliverables), 4, 73, 937 accountability for, 34 creation, 935, 114 just-in-time planning, 92 operational managers agreement on project requirements, 63 reporting variations, 75 rollout, 967 specification in business case, 55, 56 user representation on project governance committee, 74 see also business outcomes; finance and funding; requirements program delivery projects, see government policy implementation projects program delivery strategies, 1213, 14 programs of projects, 33, 97
120
progressive approval, 64 progressive planning, 45, 61 progressive testing and assurance, 81 project and program management, distinction between, 33 project boards, 745, 88, 89, 91 project sponsors views on, 94 regional office projects, 33 terms of reference, 37 project business case, see business case project changes, 8, 95 project closure and handover, 97 project concept plan, see concept plan project controls, 81, 1079 project governance, see governance arrangements project implementation, see implementation project initiation, 901 project launches, 91 project oversight, see oversight roles project planning, see planning project priorities, see priorities project products, see products project proposals, 4386 project reason, 54, 84 project reasoning, 48 project requirements, see requirements project rollout, 967 project scope, see scope project size, see size of projects project specification, 54, 84 project teams, 37 concept stage, 46, 50, 51 implementation, 54, 88, 89, 912, 97; rollout, 96 project (planning) teams for business case development, 56, 57, 58 communication strategy, 71 implementation approach, 72 options, 66; comparing, 67 requirements statement, 65 proposals, 4386 Public Private Partnerships: Business Case Development, 16
R
RACI matrix, 75 rate of return, 29 reason for project, 54, 84 reasoning of projects, 48 recipients of benefits (end users), 4, 63, 73 recordkeeping, 40, 55, 92 project requirements at concept stage for projects aimed at improving, 52 urgent projects, 26
regional office operations, projects involving, 33 reporting, 37, 81, 89 assurance report, 58 completion report, 97 implementation approach, 72, 73 milestones, 74, 75 about testing, 95 see also assurance representation, 278 see also appointments requests for changes to projects, 95 requirements, 106 business case statement, 635; options, 63, 65, 667 concept plan, 512 detailed planning at implementation stage, 912 see also operational requirements research projects, 7 residual risks, see risks and risk management resources, 24 acquisition, 923, 94 availability, 31, 92 implementation approach issue, 73 see also constraints; finance and funding; people and culture responsibilities, see roles and responsibilities reviews, 246 business case, 59, 70, 92; representation in governance arrangements agreed in, 91 concept plan, 53 implementation approach, 72 post-implementation, 97 pre-rollout, 95 questions for executives, 59, 69, 836, 11013 requirements statement, 65 risks and assumptions, 69, 92, 96 rollout, 96 see also assurance risks and risk management, 8, 1820 cross-boundary projects, 32 identified in approval stage, 79 identified in business case, 689 identified in concept stage, 53 implementation approach, 73 implementation stage, 92, 96 screening criterion, 29, 30 see also assurance roles and responsibilities, 45, 91, 100 approval, 234 cross-boundary projects, 323 delegated authority, 35 project closure and handover, 97 RACI matrix, 75
INDEX
SECTION
121
see also oversight roles rollout, 967
S
scope, 4950, 61, 66, 101 distinction between program and project management, 33 recording, 40 uncertainty of estimates, 20 variations, 8, 37, 47, 66, 95 scope creep, 95 scope of assurance activities, 58 screening of proposal for decision, 2830 scrutiny, see reviews secure communications facilitation project, 64 size of projects, 26 business case development, 25, 56; requirements statement detail, 64 closure and handover, 97 modular implementation, 73 monitoring and reporting arrangements, 37 resource acquisition, 93 treating as programs of projects, 33 skills, 31 financial management, 36 governance capability, 75, 90 operational requirements, 70 programs of projects management, 33 project oversight, 1718 project planning, 201 risk management, 19, 20 specialist and technical, 24, 38, 50, 55 small projects, see size of projects specialist and technical skills, 24, 50, 55 procurements, 38 see also advisers; committees specification of project, 54, 84 staff, see people and culture stakeholders, 18, 278 approval stage, 79 business case preparation, 55, 56, 69, 71, 72, 73; identifying and comparing options, 66, 67 concept stage, 46, 47, 48, 50, 51 confidentiality and, 27, 39 implementation stage, 88, 89, 93, 94, 95; detailed planning, 91, 92 project monitoring element, 37 standard reporting format, 37 strategic alignment, 1116, 29 checklist, 41 government policies and APS requirements, 16, 29,
3840, 1023 success measures, 7, 61 client service improvements, 13, 31 sufficiency of project requirements, 51 suppliers, 4, 36, 88 ethics-related issues, 39 project requirements statement, 63 projects with high dependence on external, 30 representation on project governance committee, 74 support services, 24, 70 risk factor, 19
T
technical skills, see specialist and technical skills terminology, 45, 212, 1001 assumption, 68 glossary, acronyms and abbreviations, 99 related APS planning steps, 7, 91n, 92n, 93n, 97n used by people in developing business outcomes, 47 terms of reference, 37, 39, 80 testing products, 945, 114 timeframes, 91, 92, 93 assurance report, 58 business case justification, 59, 61, 70 cross-boundary projects, 32 procurement method, 38 screening criterion, 29, 30 uncertainty of estimates, 20 variations, 75, 95 see also constraints timing of benefits, 73 top-down guidance, 31 training, see skills
U
uncertainty of estimates, 20 urgent projects, 26
V
validation, 54, 85 values, 39, 47 variations to projects, 8, 95
122
Better practices for executives during planning and
approving a project. By following these personal practices, executives can help improve the quality of project proposals. Additional guidance is available in the ANAO Better Practice Guide Planning and Approving Projects an Executive Perspective.
A project is a short term endeavour to provide products that meet specified requirements. Generally, the desired business outcomes flow from using the products.
Operational inputs
Use of project products
Specific business outcomes
Contribution to broader goals
Project implementation Deliver the specified products
Concept phase: project sponsor
Be available to planning teams to discuss possible projects and entity priorities. Maintain a strategic awareness of policy directions, and the opportunities and risks of emerging technologies and alternative delivery approaches. Encourage a degree of questioning and innovation. Maintain active external relationships and involve fresh perspectives early. Keep the project team focused at a concept level at this early stage, so as to avoid premature consideration of detail or specific solutions.
Business case phase: project sponsor
Consider for
Consider procedural requirements, including possible application of Gateway Review or ICT Two Pass Review process.
2. Business case
Specify outcomes, requirements, costs, timeframe
Gain assurance that probity and record keeping needs will be addressed. Provide enough time and resources so planning is of appropriate quality. Keep watch on the direction and cost of planning. If costly, consider a smaller proposal to justify the cost of a more comprehensive business case. Maintain a close relationship with senior stakeholders, to help clarify requirements and constraints, and remain aware of their commitment. Be readily accessible to the planning team, to provide guidance on strategic issues. Consider seeking independent assurance on draft business case. Assess realistically whether there is adequate internal capability to effectively govern and deliver the project. Consider which information is of most interest and relevance to decision makers and stakeholders. Make it clearly visible for them in the business case, including outcomes which will not be delivered by the project.
These questions are intended to assist executives during the planning and approval of a project. These practices may need to be tailored to take account of a specific entitys circumstances.
Approval phase: decision-maker
1. Concept plan
Clarify outcomes Check logic
Be clear about scope of role as a decision maker. Encourage an environment of open and honest discussion, and of continuity of attendance by members of review and approval committees. Focus on the central elements of project proposals relevant to approval (such as outcomes, costs, timeframe, feasibility, risks, and contribution to goals). Consider the overall effect of projects under consideration, including opportunities or difficulties arising from the impact of one project on another, or their effect on businessasusual activities. Keep in mind the option of conditional or staged approvals to better manage projects risks. Regularly consider opportunities to improve the assessment process (for example, the format of submissions, role and resourcing of support).
Copies of the Better Practice Guide and this checklist are available from anao.gov.au
June 2010
PLEASE TURN OVER
3. Approval
At the start of detailed planning, confirm the broad concept, appoint an appropriate person or team to develop the business case, consider whether specialist assistance will be useful, and commence engagement with stakeholders.
during planning and approving a project. These questions help assess whether a project is ready to proceed to the next stage. Additional guidance is available in the ANAO Better Practice Guide Planning and Approving Projects an Executive Perspective.
Tip: effective project planning engages people those implementing the project, those using the project products, those benefiting, and those who are funding the project.
Review questions for use by executives
Operational inputs
Use of project products
Specific business outcomes
Contribution to broader goals
Project implementation Deliver the specified products
Concept plan
Developed in a broad context. Business outcomes clear. Extent of improvement (or performance) for outcomes indicated. Proposed business outcomes largely independent of factors external to the project scope. Outcomes supported as important by key stakeholders. Reliable chain of reasoning from the proposed project requirements or products to the desired outcomes. Definite contribution to one or more broader goals. E.g. client satisfaction, agency flexibility and capability, cost control and enabling staff. Important assumptions, risks, and constraints identified. Overall, the concept has realistic and tangible business results, and a reasonable underlying logic.
Business case
Outcomes, costing and timeframe clearly described, sufficiently reliable. Responsibility allocated for all project products, expenditure, business outcomes. Business outcomes will be measured before rollout, and subsequently. Requirements are complete. E.g. functionality, quality, volume, security. Right people consulted on requirements. Operational manager agrees product acceptance criteria and that the business outcomes are achievable with the product. Options provide a real choice on level of investment. Risks and assumptions have been reliably assessed. Any significant residual risks accepted by relevant person. Risk treatment and monitoring funded. Operational requirements, such as staff and accommodation, budgeted for. Data issues addressed. The communications and stakeholder relationship approach is appropriate. Project phasing has review and exit points to reduce loss if problems occur. Able to develop or procure products. Product rollout and handover to operations budgeted. Project governance team are appropriate to the risks of the project. Overall, the business case puts forward business outcomes that are realistically achievable in the proposed timeframe and cost, with appropriate risk mitigation, risk responses and fall-back options.
Consider for
PLEASE TURN OVER
3. Approval
2. Business case
Specify outcomes, requirements, costs, timeframe
These questions are intended to assist executives form judgements about a project proposal. Consideration of the questions should be complemented by appropriate quality assurance of information being provided to executives for their review.
1. Concept plan
Clarify outcomes Check logic
Approval issues for consideration

Decision-maker to form own view on key issues, in an overall context.
Relative importance of outcomes, contribution to goals. Likelihood of on-time, on-budget completion. Allocation of responsibility for products and outcomes. Project option chosen is most appropriate investment. Appropriateness of acceptance of residual risks. Appropriateness of review and exit points to avoid loss. Appropriateness of project governance team to the risks. Compliance with entity and APS policies. Compatibility of project with other projects and workloads. Setting of specific controls to support senior management in external liaison, monitoring, corrective action. Overall, the project is an appropriate use of resources, taking into account the outcomes, costs, risks and alternative uses of funds.
These questions may need to be tailored to take account of a specific entitys circumstances.
Copies of the Better Practice Guide and this checklist are available from anao.gov.au
June 2010
125
Planning and Approving Projects Better Practice Guide inside of back cover
www.anao.gov.au

Planning and Approving Projects BPG

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Planning and Approving Projects BPG

Încărcat de

Drepturi de autor:

Formate disponibile

Planning and Approving Projects an Executive Perspective

SettinG the foundation for reSultS

Better Practice Guide

Ian McPhee Auditor-General June 2010

Planning and Approving Projects Better Practice Guide

Planning and Approving Projects Better Practice Guide

The structure of this Guide

1: Putting projects in context:

4: Overview of project implementation:

3: Individual project proposals:

Checklists and review questions

Planning and Approving Projects Better Practice Guide

the importance of projectsCONTEXT PUTTING PROJECTS IN

executives in project planning and approval

1: Putting projects in context

Planning and Approving Projects Better Practice Guide | Chapter 1

1.1 The importance of projects in delivering government programs

1.2 The project lifecycle

Planning and Approving Projects Better Practice Guide | Chapter 1

roleS and reSPonSiBilitieS

When used, achieve business outcomes

Long term benefits

Business case Project concept plan

Chief executive and Senior executive team

Entity arrangements to support project planning and approval

Executives add value early

Planning and Approving Projects Better Practice Guide | Chapter 1

Related APS planning steps

Gate 1 Business case

Different types of projects

Variations in focus during planning and approval

1.3 Arrangements should be fit for purpose

Planning and Approving Projects Better Practice Guide | Chapter 1

strategic alignment ENTITY ARRANGEMENTS effective governance

people and culture

Structure of this chapter:

2.1 Promoting strategic alignment

2.2 Having the right people and culture

Skills for project planning

Support for independent assurance

2.3 Having effective governance arrangements

Accountability and authority

Monitoring and reporting

2.4 Addressing common APS requirements

Key better practice summary

Planning and Approving Projects Better Practice Guide | Chapter 2

2.1 Promoting strategic alignment

Use of project products, leading to business outcomes

Alignment with corporate goals

The value of alignment:

Program delivery policies

ICT capability goals + strategies

Program delivery goals + strategies

Work unit and project plans

Work unit plans

Planning and Approving Projects Better Practice Guide | Chapter 2

Case study: New delivery strategy drives new projects

Goal: Improved Client Service

Sub-goal: Faster decision-making

Sub-goal: More information online

Sub-goal: Less phone waiting

Target: 3 days faster

Target: 20% more