Appendices

Previous heading | Top | Next heading

A – Glossary, acronyms and abbreviations

AGIMO	Australian Government information Management Office
ANAO	Australian National Audit Office
APS	Australian Public Service
Business case	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.
CIU	Cabinet Implementation Unit
Entity	An organisation subject to the Financial Management and Accountability Act 1997 (FMA Act) or the Commonwealth Authorities and Companies Act 1997 (CAC Act).
Finance	Department of Finance and Deregulation
Gateway Review Process	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.
ICT	Information and Communications Technology
ICT Two Pass Review Process	A process in the Australian Government whereby certain projects provide an initial business case, to seek approval to prepare a more comprehensive business case.
MSP	Managing Successful Programmes – a program management methodology of the UK Government’s Office of Government Commerce.
PM&C	The Department of Prime Minister and Cabinet
P3M3™	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 Government’s Office of Government Commerce.
Residual risk	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.
Risk appetite	The level of risk that an organisation is willing to accept.

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.

Previous heading | Top | Next heading

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.
Decision-maker	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.
Operational manager	Represents the interest of the people who will use or operate the project products. Also called senior user(s).
Senior supplier(s)	Represents the interests of the major suppliers who will provide or develop the project products.
Stakeholder	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.
Project board	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.

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.
Assumptions on resources and dependencies	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.
Benefits	Expected improvements as a result of a project. See Business outcomes.
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.
Constraint	‘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.
Deliverable	Another term for a project product.
Exit points	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.
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.
Milestones	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.
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 capacity, usability, security and performance.
Objectives	A short description of the main reason for the project.
Out of scope	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.
Phase	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.
Products	The specific outputs of the project as a result of work carried out. the project products should fulfill the project requirements. Sometimes called deliverables.
Project	A time limited endeavour undertaken to create a unique product or service. every project has an end.
Requirement	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.
Scope	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.

Previous: Concluding remarks

Next: B – Related government policies