Digital Project Governance Boards

Digital Project Governance Board Composition

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 ⁽¹¹^,²⁾.

“Ownership of decisions are attributed to governance forums rather than individuals or roles. The lack of clear decision-making powers and accountabilities across all levels of the program is impacting the effectiveness of timely decision-making”

Review of the Modernising Business Registers Programme

People: Core Literacy, Experience and Culture

Corporate boards have moved away from an emphasis on stakeholder representation to skills-based composition. Project boards should also look past stakeholder representation to consider the skills and capabilities that members contribute. Board members should include external members, and be chosen for their authority, expertise, experience, status and connection ⁽¹¹⁾, focusing on people who:

Are authorised to represent the interests of the area they represent;
Can provide necessary resources; and
Are committed to the project outcomes ⁽¹⁰^,²⁸⁾.

Project boards rarely have the time or luxury to be able to develop complete knowledge of all aspects of any project. Some literacies can readily be taught, helping board members know what to look for and the questions to ask. Project board training can help rapidly develop core literacies ⁽¹¹^,²¹⁾. Other board member capabilities are developed through years of experience. We differentiate between SROs’ and board members’ digital project literacies (Table 4), the collective experience the board should contain (Table 5), and the culture, attitude and behaviours that needs to be established for a digital project board to be effective (Table 6).

Core Literacy

Table 4: Foundational literacy all project board members should have
Capability	Description
Benefits and outcomes	Understanding of benefits management processes, and the relationship between outputs and outcomes, benefits and value ⁽²³^,⁴⁰⁾
Communication in the context of change	Understanding the importance of a project narrative, creating a culture of transparency, stakeholder identification, constructive conflict and feedback loops ⁽²⁰⁾
Project management foundations	Understanding of key project management concepts, giving the board the ability to question aspects of the project lifecycle, critical path, earned value, burn rate and baselines ⁽⁵^,¹⁵^,²³⁾

Core Experience

The expertise needed on the Board should be guided by key areas of risk, both enterprise and project delivery.

Table 5: Common expertise requirements for Digital Project Boards
Skills	Description
Business expertise	Understanding of the business, impacts and change required for end users, allowing the board to maintain sight of the business logic of the project ⁽⁵^,¹⁵^,²³⁾
Operations expertise	Understanding of the operational environment to ensure the solution is integrated, maintainable and sustainable within the existing IT applications portfolio ⁽²⁹⁾
Digital project management expertise	Understanding of digital projects, their lifecycle, risks, ideally with experience in a similar type of project (e.g. AI, SAAS, risk tier)
Interpersonal skills and social capital	Strong networks and relationships that support negotiation, decision-making, issue resolution, stakeholder management, effective communication and resourcing ⁽⁵^,²⁸⁾
Digital, data and cyber expertise	Depending on the project type and stage, deep technical expertise may be required
Legal and policy	Depending on the project type and stage, regulatory and policy expertise may be required
Procurement and contract management	Depending on the project type and stage, expertise in procurement and contract management may be necessary
Independence	Balancing the need for vested interests, ensuring there is someone who can view the project and its progress objectively and independently
Supplier expertise	Depending on the project, experience and knowledge of the product, implementation approach and supply chain
Interdependencies	Knowledge of areas the project has interdependencies with, for example, resourcing, systems integration
Employee/customer experience	Expertise in ensuring a solution is well suited to the needs of the users of project deliverables
Change management expertise	Experts in communicating and designing organisational change, reducing resistance and increasing uptake of change
Financial expertise	Depending on the complexity, size, risk and procurement strategy of the project

Culture, Attitude and Behaviours

Table 6: Attitudes and behaviours required on project boards
Culture	Description
Skin in the game	Members should have a genuine interest, commitment and ownership of the project's success ⁽²⁸⁾
Psychological safety	Boards need to foster a no-blame environment where people feel safe with constructive conflict, raising ideas and escalating issues ⁽²³^,⁴¹⁾
"Can do" agency	Board membership is not a passive role. Members should take action to ensure they have the right information to support decisions and proactively identify strategies that enhance project success ⁽²³⁾
Time commitment	Board members often underestimate the time involved. Members must ensure they are suitably informed, attending meetings and prepared to support decision-making ⁽¹¹^,²³^,⁴²⁾
Courage	Courage to stop a project, escalate risks or reset the project if the project does not have sufficient business justification and/or delivery confidence is low ⁽¹^,²⁵⁾
Attendance	Continuity in core board membership facilitates historically informed decision-making. Use of deputies or proxies should be avoided as it signals a lack of commitment, dilutes accountability and can delay decision-making ⁽¹¹⁾. Members should not attend just to report to others ⁽²⁸⁾
Decision expediency	Boards need to make decisions escalated to them in a timely manner, possibly despite incomplete information. Decisions should be clear and prioritise action⁽²³^,⁴³⁾
Value-focused	Boards should suspend self-interest and operate from a position of what is best for the organisation and project, optimising value from the project investment
Empowering	The project board can make the decisions it needs to so that the project is empowered to deliver
Humility	Openness to learning and adaptation – seeking robust advice from independent advisors and project assurance, seeking out lessons learned from similar projects, listening to user and reference groups, acting on recommendations ⁽¹^,⁴⁴⁾

“SPER conducted at least 20 reviews (gateway reviews, program health checks and various other reviews)… SPER did not address warning signs raised through some of these reviews—including concerns with the lack of an operating model, the vendor’s product, and SPER’s relationship with the vendor” ⁽³⁾.

Audit office inquiry

Everyone has a stake but no one wants to be responsible

Interviewed governance professional, DTA

Information flow: Reporting and Communications

Project reporting

Project Board meetings should be regular, scheduled and aligned as much as practical to the organisation’s financial reporting cycles, so that the project manager can give timely information on project progress and costs, and to escalate issues beyond their delegation. Most digital project boards meet on a monthly basis and at key decision points, but the frequency of meetings should be adapted to project pace and risk ⁽¹¹⁾, with the possibility of a higher meeting frequency, for example, when the project is close to go-live or release.

The content of board meetings is often influenced by the project manager, supported by key topics in project reports. To keep the board focused on decision-making, reports should focus on exceptions to planned progress, changes to scope, risks and relationships ⁽¹¹⁾. The agenda and supporting project reports will need to adapt to maintain a focus on the critical decisions needed to progress the project ⁽²³^,⁴³⁾.

Project reporting should be “a single source of truth” to reduce reporting burden and to share with internal and external stakeholders, and contain the following ⁽²⁾:
Key project milestones
Spend to data and forecast spend to complete
Earned value (or equivalent) to enable clear monitoring of work completed compared to plan
Key workforce metrics
Material risks
Governance effectiveness metrics – feedback loops on quality of materials, engagement, debate and decision-making (e.g. short survey at end of each meeting)
Change readiness indicators
Go-live date

From the Review of the Modernising Business Registers Program

Production of reports for the board divert resources from other project activities. The SRO needs to balance information requests from the board to the project team, with the effort needed to produce them. There is also a tension in the timeliness of information for project reporting. Where possible, board meetings should be scheduled to minimise the lag between report data and the meeting. The board should regularly reflect on whether all sections of project reports play a role in the decisions the board makes. Removing redundant sections of reports can make it easier to focus on key information and reduce a project reporting burden. Focus for reports should be on exceptions, earned value, and differences between planned and actual progress.

Good communication overcomes poor governance

Interviewed SRO, Australian Government

The board maintain responsibility for obtaining the information they need to govern project progress and may need to work with the project manager to ensure they obtain necessary information, moving past a passive information-consumption attitude. Technical jargon should be avoided in reporting in favour of language that allows the board to make trade-off judgements on the business logic and strategic alignment of the project. Board members may have to actively seek outside information if they are to be suitably informed, for example by attending regular project meetings ⁽²³^,⁴³⁾, engaging directly with users and operational mechanisms (e.g. walking the shop floor), or conducting informal discussions with stakeholders.

Supporting project documentation

The following table lists some of the common documentation used to support project board formation and decision making. Governance tips from an SRO are also included later in this document.

Project Artefacts and Core Elements
Artefacts	Core elements
Project Board Terms of Reference (ToR)	The ToR should clearly articulate the scope of the board's remit, authority of the board and its positioning with corporate governance forums and other project governance mechanisms. It should clearly define board roles, potentially including a RACI matrix (responsible, accountable, consulted, informed). The ToR needs to place strongly restrictive conditions on board members use of delegates or proxies. Escalation processes and criteria for exception reporting should be included. These should detail the specific delegated time, cost, quality, or scope change limits that the project manager is delegated to approve, and which must be escalated for board approval.
Business Case	It specifies why the project is required, its objectives, intended benefits, and solution strategy. It specifies the parameters within which the project operates (e.g. time, budget, scope), which provide the baseline against which project delivery performance can be measured.
Benefits Realisation Plan (BRP)	A BRP outlines how the benefits of an investment will be achieved and measured. Its purpose is to ensure an investment delivers its intended value. The BRP describes the context, structure, and approach to the realisation of planned benefits and is typically developed alongside the business case (at least to initial draft level) to ensure there is a clear plan for the realisation of benefits outlined in the business case. See the DTA's Benefits Management Policy and Toolkit for more information.
Benefits Map	A benefit map links the key project benefits and enabling changes on which benefits realisation depends to an organisation's strategic objectives. Benefit mapping and the resulting Benefits Map, is an iterative process which should be revisited multiple times during the investment. This will ensure that unintended consequences and disbenefits are accurately factored into the investment planning process and that the investment remains on track to realise intended benefits. See the DTA's Benefits Management Policy and Toolkit for more information.
Stakeholder Impact Assessment	A Stakeholder Impact Assessment identifies who is affected by the project and evaluates the nature of the impact. It assesses relative power of each stakeholder, their interests and readiness for change. The assessment can be utilised to inform engagement strategies and risk mitigation plans.
Project Board Papers	Project board papers are produced by the project manager, focusing on decision-making and exception reporting. They are designed to support decisions escalated to the board. They should make clear recommendations, clearly noting the action required (e.g. note or approval). They should be distributed to the board at least 3 days in advance ^[³^-^DTA^]. Standardising reporting across an agency is recommended to help board members can easily consume information ^[¹⁴^,^SRO^].
Assurance Plan	Agencies are required to plan for assurance by applying the Key Principles for Good Assurance and meeting minimum assurance requirements applicable to the tier of the investment. The Assurance Plan is agreed with the DTA and submitted to Cabinet for approval as part of the proposed investment. The Assurance Plan should be regularly reviewed by the board, at least as often as the relevant tier requires. This is key to ensuring the plan continues to be fit-for-purpose. See the Assurance Framework for Digital and ICT Investments for more information.

Governance tips from an experienced SRO
On structure:
Use defined decision-making frameworks. Treat governance as a “friend” framed around risks
In my programme with >10 projects, each had its own SRO. The formal programme board was a decision-making forum, with feedback mechanism to the agency head through to the organisation’s board and across government
Underneath the programme board, I established good delivery governance. I also attended standups with each project and SRO every week to unblock things, clear change protocols and manage dependencies
To succeed, we needed a high functioning PMO, tracing original requirements to delivery, governance ensuring that “right people are working on right things at right time”
On decision-making:
Ensure clear delegation of decisions and authority between the programme and project levels
Defined project and programme tolerances:
Programme level – decision-making sits with SRO. For example, there were 34 milestones. If we shift on those, that is a decision for SRO and minister.
Project level - decision making authority to make decisions around their milestones, as long as it doesn’t impact delivery of government milestone and SRO has transparency.

Experienced SRO

Lifecycle considerations:

There are several considerations in running an effective project board throughout a project’s lifecycle. This section provides guidance on the project board duration, inducting board members, review processes and dissolution

Project Lifecycle and Duration

Project boards should commence at a project’s inception. Different skills, capabilities and focus may be required at different stages of a project, and consequently the board composition may need to change. For example, architectural expertise may be more necessary in the design phase, procurement in the planning phase.

In addition, certain events can trigger changes to the project and/or Board. This can include a change in government, turnover of the SRO, handover of project between phases (e.g. after business case approval). These events should also trigger a review of the business case, board charter and composition.

Induction and On-Boarding

The following activities are recommended when standing up a project board, or after significant change ^[¹⁴^-^SRO^,¹^-^SRO^].

Explain why the project is needed, the outputs and outcomes it is intended to deliver, and high- level project plan
Provide clarity on roles, positioning of this board with other governance mechanisms and expectations on behaviour
Understanding of baseline plan so the board know what they are measuring against
Build capability in the core literacy areas. For example, an agency providing a Managing Successful Projects ⁽⁴⁵⁾ course so that board members would have common understanding of project principles.

Reflection and Review

There should be a regular reflection and review on the effectiveness of a digital project governance board, as:

Organisational needs can vary over the project lifecycle
The external context might have changed, impacting the project’s feasibility
Practices and processes can develop over time, and the board may need to manage reporting impost and regularly ‘de-clutter’
The bespoke nature of digital project governance boards means it may need adjustment to be effective.

Participants for this research recommended having an item on the agenda (quarterly) to review the agenda and papers and remove lower value items. It might also be necessary to change the board composition, meeting cadence or address any cultural issues. The Self-Assessment provided in this document can also be helpful for providing a snapshot of board effectiveness.

Dissolution

Closing down the project board should be aligned with the project benefits being realised or accountability transferred to an operational role, rather than the technical output delivery. It should
also align with DTA’s Closure reporting standard for digital and ICT-enabled projects.

Any lessons learned, for example from post- implementation reviews, should be integrated into project management disciplines in the agency.

There should be a formal handover of any remaining risks and benefits to be realised.

Tools for Digital Project Governance Boards