ANAO - Planning and Approving Projects

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 entity’s 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.	Reduction of current ICT system costs from $10m p.a. to $5m p.a.
O2: Central, accurate data	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.
O3: Capped staff administrative effort	No net increase in time for line staff to do administrative tasks (accepting there may be changes for individual staff). Preferably a decrease.

Key Requirements

R1: Functional equivalence	All current business activities supported (noting that the detail of some business processes will change).
R2: Longevity of replacement	Expected system and support lifespan: at least 5 years.
R3: Timely decommissioning	Existing systems decommissioned within 2 years, so can harvest savings.
R4: Data cleansing process	Arrangements to ensure any data in new system meets new agreed definitions and is accurate.
R5: Staff training	Staff properly trained in new administrative processes.
R6: Efficient transactions	The combination of time per data screen, and number of screens per business transaction should be at least as fast as at present.

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.

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 entity’s 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.

Previous: B – Related government policies

Next: D – Categories and examples of requirements