Search

Understand privacy impacts

Undertake a Privacy Impact Assessment: Undertake a Privacy Impact Assessment to capture issues. Mitigate unwarranted and unauthorised surveillance, data collection and malicious data breaches, and share these actions with users.
Obtain consent: Where required, seek and obtain informed consent from users prior to collecting, storing or disclosing any of their data. Consider opt-out options and build your service to require as little user data as possible.
Be transparent: Communicate how data your service will be used or may be used in the future at the time of consent. This includes how it may be shared with other people or between services and secondary or less obvious uses.
Off
Undertake a Privacy Impact Assessment: Undertake a Privacy Impact Assessment to capture issues. Mitigate unwarranted and unauthorised surveillance, data collection and malicious data breaches, and share these actions with users.
Obtain consent: Where required, seek and obtain informed consent from users prior to collecting, storing or disclosing any of their data. Consider opt-out options and build your service to require as little user data as possible.
Be transparent: Communicate how data your service will be used or may be used in the future at the time of consent. This includes how it may be shared with other people or between services and secondary or less obvious uses.
Guidance for Senior Responsible Officials
Assurance Research Series 02

There are three main considerations in establishing a digital project board:

the structure,
the people who will be involved, and
the information flows between them ⁽²⁷⁾.

We step through each of these areas in turn, and then outline considerations for different stages of the project lifecycle.

Structure: Scope, Organisation positioning and context

Before deciding on the members of the project board, it is important to consider the decisions the board will need to make, what level of delegation is needed to make those decisions, and how the board can escalate issues if the project needs to operate outside its delegated authority. It is important to provide clarity on how the digital project board interacts with other governance and standards forums, for example, perpetual governance forums (e.g. organisation’s board), architecture boards and user reference groups. Clarity on the ToR, roles and responsibilities, decision-making authority and the role of the SRO are essential board success criteria ⁽²⁸⁾. Consider also that if the project is transformational, the required organisational roles may not yet exist.

To ensure delivery of business value, the board needs visibility of changing business needs, including broad representation across relevant parts of the organisation ⁽²⁹⁾. As required, the board membership could include the project executive, internal customers, representatives of IT and the business, internal customers, senior users, finance, and other key stakeholders ⁽¹¹^,²⁹^,³⁰⁾.

Other considerations include the project method being used, the project risk and the optimising of the board size to get the right mix of skills and accountability. We provide guidance on each of these topics in turn.

Scope of Digital Project Board

Common roles and responsibilities for digital project boards include:

Area of Scope and Specific Responsibilities
Area of Scope	Specific Responsibilities
Strategy	Providing strategic direction to the project and maintaining its strategic alignment Monitoring the external environment and adapting appropriately if the context changes (e.g. change in government, change in policy, change in market conditions) ⁽²⁾
Value and impact	Ensuring the project delivers the intended benefits and business outcomes, delivers good value for money and is sustainable Ensuring impact on the business is understood, communicated and managed appropriately ⁽¹^,²^,²⁴⁾. Ensuring vendor contracts are managed appropriately and delivering value ⁽¹⁾.
Risk	Ensuring risks are identified, appropriately mitigated and escalated when project is at risk or operating outside its approved boundaries Understanding, minimising and mitigating, as much as possible, risk, complexity and barriers to progress ⁽¹^,²⁾ Engaging independent assurance commensurate to the project risk to assess ongoing viability of the project. This should be done on a regular basis, when base assumptions are found to be flawed (e.g. complexity underestimated), or when context significantly changes ⁽¹^,²^,²⁵⁾. The DTA's Assurance Framework for Digital and ICT Investments provides more guidance on this.
Stakeholders	Interpreting between the enterprise perspectives on strategy, value, risk and culture and the project's focus on delivery and implementation Aligning stakeholder perspectives on purpose, scope and quality ⁽²⁶⁾ Ensuring productive relationships with those impacted by, influencing or involved in the project ⁽²⁶⁾
Progress	Understand and effectively monitor progress, workforce plans and cost forecasts against the project's critical path, scope, budget and deployment strategy ⁽²⁾ Ensuring the project is appropriately resourced
Decision-making	Providing timely and effective decision making Navigating tensions associated with digital projects, such as the tradeoff between standardisation and localisation, the use of consultants to bolster capability vs accountability for project outcomes ⁽³^,²⁶⁾ Assessing and approving the progression of a project between implementation stages
Compliance	Ensure the product or service produced by the project is fit-for-purpose, compliant and integrates with existing systems and data ⁽¹^,³^,²⁶⁾

Positioning of the Board within the organisation

Layers of governance and separation of duties

The levels of governance should generally be minimised, while ensuring there is sufficient separation to avoid conflicts of interest between those doing the work and those governing, and to facilitate escalation paths. Too many layers of governance dilute accountability and can slow down decision-making ^([¹^-^SRO^],¹⁾.

It is important that members of the board are not conflicted in decision-making, for example, an external vendor on a board that makes decisions on the vendor's scope or payment. To avoid a conflict of interest, external supplier interests could be represented in a separate advisory committee, or represented by internal procurement management, as appropriate to the needs of the project.

Ownership and Membership

In general, membership of the board should be limited to those who have ongoing ownership for the solution and those that will be most impacted by the operation, maintenance, benefits and risk. Similarly, risk and benefit ownership should be assigned to the individuals whose roles are best placed to control risk, and with ongoing ownership of benefits. For example, ownership of benefits should not reside with the delivery manager ^[³^-^DTA^].

Membership, roles and responsibilities will vary to suit the specific conditions of a project, and it is important these are clearly understood by members of the board ⁽¹³^,¹⁵^,¹⁹^,²¹^,²³^,²⁸^,³¹⁾. Members should be sufficiently senior to represent areas within their expertise with authority ⁽²¹⁾.

The typical roles and relationships to the board are outlined in Table 1, with more detail on the roles and responsibilities in Appendix A.

It is important to note that the relationship to the board can vary, depending on the project and where in the organisation the role is sourced from. Board members will typically represent different parts of an organisation, or even different organisations. This helps to ensure project outputs meet the needs of different stakeholder groups. The governance structure of a project board may have little resemblance to the organisational hierarchy.

Indicative organisational chart showing that governance board members will typically represent different parts of an organisation — Figure 1, Garland, R.; Morey, A.

Table 3: Roles relative to the board


Role on the Board	Roles
Members of the board	Chair (typically the SRO) Business Owner(s)/Senior Customer(s) Senior Supplier(s)
Support to the board	Secretariat Audit and Risk Officer Independent expert Project Management Office (PMO)
Reports to the board	Project Manager Vendor Change Manager Benefits Manager

Role of the Chief Information Officer

Because of the inherent complexity and nuances of digital projects, and the high connectivity between people and the digital solutions they use, there needs to be a productive and close working relationship between the SRO and senior digital experts in the organisation. There is some debate on how this relationship should be structured.

Some advocate for shared accountabilities and KPIs for the SRO and CIO (or equivalent) in a two-in-a-box model ⁽³²^,³³⁾, with both playing a role in communication, consolidation, negotiation and decision making on projects ⁽³⁴⁾. This model can mitigate situations with a historic dominance of organisational unit over another, or where the SRO does not have adequate digital implementation experience. However, shared accountability and shared KPIs can reduce individual responsibility. Assurance providers and project governance experts interviewed for this report, as well as industry standards maintain that sole accountability should be maintained as standard practice.

Irrespective of what model is chosen, there should be clear documentation of expectations, a willingness from the participants, clear responsibilities and decision-rights, an appearance of unity and mechanisms for conflict resolution ⁽³⁵⁾.

Cross-agency projects

The multidisciplinary nature of cross-agency projects gives rise to nuanced governance challenges, often shaped through the involvement of multiple institutional stakeholders and political tensions. The Queensland Health Payroll system case exemplifies the need for a robust governance forum that includes cross-agency stakeholders.

The absence of a formal centralised project governance structure with clearly articulated roles and responsibilities led to fragmented decision-making, diluted accountability and misaligned objectives across involved parties, including the lead agency, Queensland Health ⁽³⁶⁾.

There is no prescriptive solution to cross-agency governance, however it is recommended to establish formal collaborative project governance arrangements, prioritising the achievement of shared goals using structured, collective decision-making mechanisms and practices ⁽³⁷⁾. Further considerations for SROs on the governance of cross-agency projects are provided in the section: Common Challenges: with recommendations to navigate them.

Other structural considerations

Board size

Board size may vary based on the project needs and the point in the lifecycle. A common issue in board effectiveness is a tendency to allow board membership to increase to an unmanageable size. Including too many voices as core members of a board can reduce effectiveness and dilute decision-making accountability ⁽¹¹^,²³⁾. While a larger board may appear to facilitate information dissemination and access to potentially relevant perspectives, effective participation in large boards is difficult to achieve, resulting in passive membership and slower decision processes.

A balance is required between the faster decision-making and increased engagement common to smaller boards and the inclusivity of larger boards. This balance will vary between projects and should be actively questioned as a project moves through delivery.

Research consistently recommends that a board size of six to eight people is both manageable and effective, supported by advisers on an as-needs basis ⁽¹¹^,²¹^,²³⁾.

Project methodology

There can be significant differences in the kinds of activities project teams take when using agile or waterfall delivery methods. The project's chosen delivery approach does not necessarily affect board composition, but it may affect the way the board engages with project information and the exceptions raised to the board.

Reporting in waterfall projects traditionally uses exception-based reporting, discussed at regular, formal board meetings. Governance in agile projects tends to be more actively aware of day-to-day developments ⁽³⁸^,³⁹⁾. Information on status may be constantly available to the board, instead of waiting for board reports ⁽¹⁰⁾.

The flexibility of constraints, and their implications for exception reporting to the board may also vary between agile and waterfall projects. In agile projects, it is more common for scope and quality to be flexible, while in waterfall projects it is more common to time and cost to flex ⁽⁶^,¹⁰⁾. Irrespective of which method is used in project delivery, it is important that the board clearly define with the project manager the point at which exceptions must be raised to the board for each key criteria.

Project risk

There are two ways the project risk can impact the board composition. First, the project's overall risk profile can impact who is involved in the project board, and the higher the risk, the closer connection to the organisation's governance mechanisms. For example, a Tier 1 project may have a representative from DTA on the project board and have oversight by the organisation's audit and risk committee.

Second, the project may identify specific risks, for example, regulatory or cyber risk, that requires specific skillsets on the project board to ensure the materiality of risk is monitored and mitigated.

Terms of Reference

The Terms of Reference is a key artefact for documenting the Board's scope, positioning in the organisation and accountabilities. Accountabilities should be made clear for the project board, the SRO and the board members. The relationship of the board to other corporate and project governance mechanisms should also be clear. Decision-making rights need to be explicit and assigned to individuals ⁽¹¹^,²⁾.

Understand the limits of data

Use data ethically: Data should only be collected and used for the stated purpose that the user agrees to. Account for how data models, datasets and algorithms may produce discriminatory results and provide transparent detail to users on how decisions and calculations are made. Before sharing data, apply the DATA Scheme’s Data Sharing Principles to help assess whether it would be safe to do so.
Use qualitative and quantitative data: Quantitative (numeric, measurable; metrics) data helps us understand what is happening on a service, while it takes qualitative (descriptive, observable; user observation) data will help us understand why. Use both to fully understand the story and match any correlation with a provable causation before making important decisions.
Off