- Foreword and Introduction
- 1: Putting projects in context
- 2: Entity arrangements
- 2.1 Strategic alignment
- 2.2 People and culture
- 2.3 Effective governance
- 2.4 Common APS Requirements
- Summary for entity arrangements
- 3: Individual project proposals
- 3.1 Clarifying the concept
- 3.2 The business case
- 3.3 Approving the project
- Summary for individual projects
- 4: Project implementation
- Quick reference card
PDF version of guide [3.0MB]
PDF of Quick reference card [0.3MB]
Tips for PDF and HTML versions [0.5MB]
Word version of checklists [0.1MB]
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.
"One factor present in successful projects, and absent in failed projects, is paying sufficient attention to the requirements."
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.
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 manager's 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.
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
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 applicant's 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.
- 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:
"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."
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.
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.
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 project's 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.
|Completeness of requirements||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.|
|Adequacy of consultation||The quality and completeness of the requirements is likely to be affected by the extent of consultation and the extent of agreement obtained.|
|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 one second response time may cost twice as much as one with a four second 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.|
|Project options with variations of the requirements||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.|
|Omission of one or more categories of requirements||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.)|
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.
Previous: Outcomes and cost