Sydney, Melbourne, Perth, Brisbane, Canberra and Adelaide
Sydney, Melbourne, Perth, Brisbane and Canberra
Staff in Australia
~1,400
~90
Australian partner network
~290 companies
N/A
Australian revenue
$1.57 billion AUD
Not provided
First Australian Government contract
1986
2018
Current SSA
Iteration 1, expires 24/11/2025 with one more 12-month extension remaining
Iteration 1, expires 28/1/2026
7.1 The details in these tables were populated based on data provided by each SSA seller and the DTA.
7.2 The tax paid by each SSA seller was expressly not in scope of this review as this is the remit of the Australian Taxation Office and the Department of the Treasury, however previous reporting by the media has investigated this.
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
Appendix A
Appendix B
Appendix B: Single seller arrangements (SSAs) representation on the Digital Transformation Agency (DTA) panels
8.1 The table below summarises the representation of the SSA sellers on the established whole of Australian Government technology panels.
8.2 Of note, whilst Data#3 is not an SSA seller, it is Microsoft’s dedicated distributor and Microsoft is itself not on any of the panels. This is a commercial model Microsoft uses throughout the world. Agencies seeking to purchase Microsoft products and services will contract via Data#3 under these panels.
Table 17 SSA representation on the Whole of Australian Government panels (with X marks where they impact)
Panel
AWS
Rimini Street
IBM
Oracle
SAP
Microsoft
Data#3
Total sellers on the panel
Coordinated Procurement?
Telecommunications Marketplace Panel (SON3713272)
Nil
Nil
Nil
Nil
Nil
Nil
X
54
X
Software and ERP Marketplace Panel – Category 1 Microsoft Volume Sourcing Agreement (SON3490955)
Nil
Nil
Nil
Nil
Nil
Nil
X
1
X
Software and ERP Marketplace Panel – All other categories (SON3490955)
Nil
Nil
X
X
X
Nil
X
392
X
Hardware Marketplace Panel (SON3541738)
Nil
Nil
X
Nil
Nil
Nil
X
204
X
Data Centre Panel 3 (SON3945937)
Nil
Nil
Nil
Nil
Nil
Nil
Nil
22
X
Peppol Capabilities and Associated Services Panel (SON3726339)
Nil
Nil
X
Nil
Nil
Nil
Nil
0
Nil
Digital Marketplace Panel 2 (SON4102906)
X
Nil
X
Nil
X
Nil
X
1,605
Nil
Cloud Marketplace (SON3668352)
X
Nil
X
X
X
Nil
X
402
Nil
Appendix C
Appendix C: Procurement policy environment
9.1 The below is a summary of the relevant thresholds applicable to digital projects.
Table 18 Financial thresholds for policies to digital projects
Value
Requirement
Source
Target
Reporting obligations
$0
Invoices are to be paid within 20 days or 5 days if Pan-European Public Procurement On-Line (PEPPOL) enabled
Supplier Pay On-Time or Pay Interest Policy (RMG 417)
All invoices
Not applicable, however, interest is automatically payable by Non-corporate Commonwealth entities if payments terms are not met (interest is optionally paid by Corporate Commonwealth Entities)
$10k
Contracts to be published within 42 days of arrangement being entered
CPRs
Procurement Publishing and Reporting Obligations (RMG 423)
All contracts
Report on AusTender after contract signature
$80k
Tenders must be put out to open market on AusTender
CPRs
All procurements
All procurements which exceed threshold, where there is no exemption
Completion of the Fair Criteria Checklist
Digital Sourcing Fair Criteria Policy
All procurements
Not applicable
Completion of the Consider First Assessment Tool
Digital Sourcing Consider First Policy
All procurements
Not applicable
Suppliers must provide a Certificate of Compliance with the Workplace Gender Equality Act
Workplace Gender Equality Procurement Principles
All procurements
All procurements which exceed threshold, where there is no exemption
$80 to 200k
Mandatory Set Aside requiring Indigenous enterprises be engaged first on procurement opportunity
Indigenous Procurement Policy
All contracts
Portfolios report to NIAA via IPP Reporting System every six months against Mandatory Set Aside targets.
$1m
Sellers to provide Supplier Environmental Sustainability Plans for ICT goods
Environmentally Sustainable Procurement Policy
All contracts
Six monthly reporting by suppliers to the Agency, including for sub-contractors
ICT contracts need to consider economic benefit to Australia
CPRs
All procurements
All procurements which exceed threshold, where there is no exemption
$2m
Consultancy contract reporting
Meeting the Senate Order for Consulting Services (RMG 406)
All contracts over threshold
Report on AusTender after contract signature
$4m
Statement of Tax Record must be submitted as part of any Open Tender response and be maintained throughout the contract
Shadow Economy – increasing the integrity of government procurement
All procurements
STR is provided by the supplier to the agency prior to completion of tender evaluation, then upon request thereafter
Payment Times contractual clauses to be included requiring suppliers to pay sub-contractors up to $1m (GST inc) within 20 calendar days or pay interest
Payment Times Procurement Connected Policy
All contracts
Not applicable, however, complaints mechanism is applicable for breaches of this policy or the contractual clauses
$7.5m
Indigenous Procurement Plan required, including Mandatory Minimum Requirements for contracts / panels to be awarded to Indigenous enterprises where contracts are wholly delivered in Australia
Indigenous Procurement Policy
2.25% at 2024-25 of contract value, increasing to a maximum of 3% by 2027-28
3% of the volume of contracts
Supplier needs to report quarterly to the NIAA on achieving the IPP via the IPP Reporting System to Agency
Portfolios report to NIAA every six months if not on AusTender or registered with Supply Nation or ORIC.
$10m
Skills guarantee requires targets for ICT projects for gender equality, apprentices and cadets to be set
Australian Skills Guarantee Procurement Connected Policy
All contracts
Quarterly reporting by suppliers to the Agency against the targets, including for sub-contractors
Agencies need to report every 6-months to DEWR on progress
ICT Investment Approval Process requires first and second pass business case submission for Government approval
Investment Oversight Framework
All proposed investments with digital spends in excess of $10m
Upon approval, agencies need to comply with both ongoing delivery oversight (e.g. assurance) and Department of Finance Gateway Reviews.
$20m
Australian Industry Participation Plan required
Commonwealth Australian Industry Participation (CAIP) plans for Government Procurement
Not applicable as discretion for requiring CAIP Plan is with buying agency
Supplier provides an Implementation Report to agency, generally within 14 months of contract execution or final close
Australian Industry Capability Plans
Australian Industry Capability Plans
Mandatory for all new contracts
Tenderers must describe how their proposed approach will enhance defence industry capability and capacity
$100m
Digital contracts cannot exceed $100m in value, unless an exemption has been granted
Digital Sourcing Contract Limits and Reviews Policy
All contracts, unless exemption applies
Not applicable, however, contract values are reported on AusTender
Modern Slavery Reporting by suppliers with $100m+ revenues.
Modern Slavery Act 2018
All businesses over the threshold
Annual Compliance Statement reported by supplier to the Attorney-General's Department
Appendix D
Appendix D: Survey results
10.1 The review undertook two surveys to identify views of the SSAs from a range of perspectives aligned to the focus of the review.
A survey of Australian Government, State and Territory agencies, and Australian Universities who utilise the SSAs was undertaken as part of this review that received 98 responses.
A survey of sellers to Australian Government and industry more broadly was published on the BuyICT website and received two industry submissions.
10.2 The section below provides a summary of the responses to the questions.
Note: each graphic provides detail on the number of responses received to the specific question in the top left-hand corner, or above the graph where there is multiple focus areas. Percentages in the graphs are based on the number of responses to the question.
Question: Which of the DTA’s SSAs has your agency used in the last 2-3 years?
10.3 For context, survey respondents are predominantly users of the Microsoft and AWS SSAs, with limited use of other SSAs in comparison, meaning that the answers to questions through the survey will be biased towards the use, benefit and challenges of those arrangements. However, due to similarities in the structure of the SSAs, the lessons learned through this survey were deemed to be applicable against each SSA, and useful in the context of future planning.
Figure 26 - Survey response: Which of the DTA’s SSAs has your agency used in the last 2-3 years?
Figure 26 – Survey response: Which of the DTA’s SSAs has your agency used in the last 2-3 years?
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:
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 (28). 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 (29). 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 (11, 29, 30).
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) (2)
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 (1, 2, 24).
Ensuring vendor contracts are managed appropriately and delivering value (1).
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 (1, 2)
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 (1, 2, 25).
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 (26)
Ensuring productive relationships with those impacted by, influencing or involved in the project (26)
Progress
Understand and effectively monitor progress, workforce plans and cost forecasts against the project's critical path, scope, budget and deployment strategy (2)
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 (3, 26)
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 (1, 3, 26)
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 ([1-SRO], 1).
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 [3-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 (13, 15, 19, 21, 23, 28, 31). Members should be sufficiently senior to represent areas within their expertise with authority (21).
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.
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 (32, 33), with both playing a role in communication, consolidation, negotiation and decision making on projects (34). 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 (35).
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 (36).
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 (37). 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 (11, 23). 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 (11, 21, 23).
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 (38, 39). Information on status may be constantly available to the board, instead of waiting for board reports (10).
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 (6, 10). 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 (11, 2).
Connect with the digital community
Share, build or learn digital experience and skills with training and events, and collaborate with peers across government.
