- 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]
“Focusing early on requirements, and not project deliverables, helps avoid the trap of approving a solution that is in search of a problem.”
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:
|CHECKING NECESSITY||CHECKING SUFFICIENCY|
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).
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).
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.
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.
Previous: Business outcomes
Next: Checking the concept plan