What improving IT procurement in the public sector looks like: navigating, balancing, and initiating procurement conversations to avoid sprinting off cliffs

By Pia Andrews

October 23, 2019

Getty Images

THE PIA REVIEW: PIA ANDREWS This is a Public Sector Pia Review — a series on better public sectors.

This article addresses the persistent assumption that simplifying public sector procurement is the silver bullet required to get better outcomes for both public servants and private sector vendors. I’ve spoken to so many people who start their project with the premise that something just needs to be bought and that ‘procurement’ is often only limited to external sourcing. There are often significant barriers or systemic disincentives to internal or cross sector sourcing, which means shared platforms or reusable components are not easy to find or consider. It is not to say that government procurement couldn’t or shouldn’t be made easier, but I thought it might be helpful to share some insights about how procurement reform in itself can be something of a red herring unless it occurs within a broader program of reform.

A big thank you to Thomas Andrews and others who provided some peer review and spirited discussions on this one.

Below are some ideas that hopefully will help you navigate, balance, or initiate conversations about procurement (or procurement reform) along with other considerations and frameworks to get the best possible public and service outcomes, as well as a stable markets for vendors. There are three overarching messages here:

  • Ensure you have relevant internal technical expertise to inform decision-making, differentiate what you should buy off the shelf (commodity needs) between what you should potentially build or co-build (domain-specific needs). Don’t assume either are inherently better, as they both have pros and cons.
  • Do not engage only with vendors, who understandably need to sell their products and services, but also engage with those who share the same goal or need as you. That might be people in other governments, but could also be organisations systemically motivated to achieve a similar outcome.
  • It is imperative that you consider the long-term direction for whatever you buy or build and whether the motivations are aligned with the goals. This means distinguishing what should be national digital infrastructure from what are just IT systems and not accidentally giving away the keys to the kingdom.

If you are procuring anything, there are great guides available in every jurisdiction that document all the mandatory requirements, but here are a few additional things I would suggest you also consider:

  • Have you done any service or system design prior to choosing a solution to buy or build? If not, your choice may not be fit for purpose. Testing is critical before you commit, which is why it is worth spending small on discovery and alpha stages before doing a full business case. See the UK agile digital and IT projects guide.
  • Have you engaged with procurement or sourcing experts early to understand all of the options available to you? Not just external, but internal options?
  • Do you maintain ownership, access, and visibility to all data in the system? If not, have you considered the impact of the loss of this ownership in a future changed world order?
  • How do you maintain visibility of operations for digital design standards assurance, auditing, and accountability purposes?
  • What is the exit cost and other exit challenges of the arrangement?
  • How much flexibility do you have for changing needs? Both predictable or unexpected ones?
  • Is it possible for the solution to be vendor agnostic, as far as practicable?
  • How have you maintained a good likelihood of competitive bidding for the work moving forward? Have you mapped out the potential futures for the solution, including negative ones to mitigate against?

 A quick note to the private sector

Please don’t assume public servants are clueless. The amount of meetings I have had where it is assumed we must know nothing about technology, or implementation, or running systems is both condescending and darkly amusing. I have worked 10 years in the private sector and 10 in the public sector, and although there are pros and cons in both, there is no less a level of expertise and professionalism required for the public sector as in the private. Indeed, in the public sector, we have to deal with complexity of requirements, systems, programs, constraints, competing interests, and outcomes that are unmatched by most non-government organisations, and yet there is a prevailing attitude held that by merit of being a public servant, we must have no understanding about anything. Consider that we are balancing these multitude of factors when we make procurement decisions, and this can make some big decisions in government inherently slower. So when we get together across sectors, community and organisational boundaries, let’s work collaboratively and respectfully on what the best possible public outcome is. After all, having a great society and economy is in everyone’s best interests, and functional and effective public sectors are critical for that to happen.

Procurement complexity in government isn’t just for the fun of it, or to make life difficult for you

One of the challenges we face is that we do have genuine complexity around procurement. A lot of this is laid out in the Commonwealth Procurement Rules and the complexity it is a result of the co-existence of specific domestic requirements (accountability, auditing, privacy, legislative orders, etc) with a web of intersecting (and sometimes conflicting) rules and requirements set by various free trade agreements and international organisations (some additional context here and here). It isn’t reasonable to expect everyone to understand this web of complexity, but it is important to understand that it is indeed complex, and that if there is something weird that your team is struggling with, be it the team seeking a solution, the sourcing team, or a vendor, it might help to go back to why it is a requirement and what was the source of that requirement. There are certainly some complexity from legacy habits or inherited processes, but understanding what is a genuine mandatory legal and/or policy requirement — and what isn’t — might also help to make better judgement calls and a better use of your time, both from a procurement and from a provider perspective.

Commodity versus domain-specific systems

How often do you hear people talk openly about commercial off the shelf (COTS) software as the assumed better solution? Usually, this sentiment is held by people who don’t actually implement solutions, because many implementations require significant customisation, configuration, integration, or modifications to actually implement a COTS product into production. The very concept of COTS assumes a binary ‘bespoke versus COTS’ dichotomy without taking into account the differing needs of different types of systems or problems.

Let’s briefly acknowledge there is a difference between commodity and domain-specific functions. In most agencies in the public sector, there will always be work to do for which there are no COTS product ready to go and no generic solution. This is due to some systems in government being inherently niche and specialised. How many clients are there for a national taxation solution? Or a social welfare payments tool? Or for managing and publishing high integrity legislation? Or for recording and preserving high integrity and high trust information like trust births, deaths, and marriages in perpetuity? How many private organisations have to think about anything in perpetuity, like our agencies and archives do every day? The public sector has many unique and domain specific functions, which is in itself no different to any other sector. But we also have some quite domain-specific obligations and requirements that are entirely appropriate for a democratic system that needs to be accountable to the government, the parliament, and the people — our three bosses. Although there are certainly commodity, repeatable, well defined, or componentised needs for which COTS products may make perfect sense, the amount of shoehorning domain-specific requirements into COTS products, often to the point where the COTS product is completely bespoke, means we often get the worst of both worlds. Unfortunately, when people assume COTS, they often can miss relevant and appropriate open source software.

So, my first framework for you is to consider whether what you are doing is commodity or domain-specific and whether it is well defined or relatively ambiguous. Generally speaking, you don’t want to jump straight to pure COTS for domain-specific functions or where there is high ambiguity. You also want to consider whether what you are doing should be considered as digital public infrastructure, especially where it is relied upon by others (like is the case with roads, hospitals, and other public infrastructure). Digital public infrastructure includes functions for which government are uniquely placed to provide or be authoritative for such as high integrity identity, various government data, legislation and regulation rules (as code), government service registers, spatial data, etc. I believe digital public infrastructure is generally a good candidate to consider having internal expertise to design, run, manage, or at least heavily oversee as distinct from general IT solutions that serve the department to function and have limited reuse value. For the purpose of this article, it is just worth considering but I’ll do another article on “Government as a Platform” to explore this concept more fully.

If your particular solution needs to be able to scale with low cost, needs to be flexible to change and extendable over time, then you might also want to explicitly explore open-source options for which there is now a significant marketplace of commercial support available (like any other software) but it also helps to maintain a greater competitive market by not locking in to any one vendor. I believe there are some domain specific solutions that governments would be best served to build, to open source and to collaborate with a community of government developers across jurisdictions because of the uniqueness of those functions to government. This is already the default approach taken for software developed with public money in several countries, but it is variable in Australia.

Co-creating design and solutions

Where there is another organisation that shares your objective, you may find opportunities to co-design, co-resource, and co-implement or co-run a shared solution or service. My favourite example of this is the Fintel Alliance, an AUSTRAC initiative that brings intelligence, regulators, and financial sector organisations together to collaborate on strengthening the financial system and disrupting financial crime. This is obviously very different from procurement, but is nicely supported through flexible procurement approaches, as each partner organisation might choose to provide their piece of the puzzle through internal or external capabilities. A vendor is generally incentivised to provide you with something you are willing to pay for, which means the possibilities for innovation are completely tethered to the appetite of the procuring officer or agency senior executive. But we share many needs and goals with other organisations, including in the private, public, and non-profit sectors, so identifying natural partners to work through ambiguity, and to co-design, co-resource, and co-implement if there is a genuinely shared interest is a great way of improving the efficiency and effectiveness of programs or solutions. This might be something to do before a significant procurement, or something that complements procurement approaches.

The risk of perverse incentives and false equivalence in whole-of-government procurement arrangements

There are certainly benefits in establishing all of government procurement arrangements for software tools that are commonly needed. These panels provide a great way to save money through leveraging economies of scale rather than each agency or business unit engaging in procuring the tools individually. There are two challenges I have seen that need to be taken into consideration when designing and delivering all of government procurement arrangements to ensure you don’t get unintended consequences.

The first is the success criteria for procurement teams can create inverse incentives. If your value and success is measured by how many agencies or teams you have using the arrangement, then you run the risk of prioritising panel subscriptions rather than ensuring the right solution for the right need. I have seen small teams in agencies be encouraged to use very complex and expensive software tools where a simple database, cloud-based, or free tool might have sufficed. I have worked with great procurement teams who present a genuinely full range of sourcing options but I have also seen many procurement teams simply interpret needs through the lens of what panels they have in place.

The second challenge is the lack of subject matter expertise at key decision points in sourcing. You get IT contracts where the procurement, contract managers and project managers who have little understanding about technology making big decisions about (usually) purchasing a tool, which assumes buying technology is set and forget. You must have actual technologists involved in the process, and the requirements must be informed by great service design and testing, otherwise you are just taking a gamble.

It is critical to ensure anyone looking for solutions go through two useful steps before talking about procurement panels, noting, of course, sometimes services need to be procured to undertake these steps, a difficult catch 22 for some:

  1. Some service-design basics to ensure they have a well defined problem space, an understanding of user needs, and some prototyping or testing on different approaches that can confirm what will meet the user needs;
  2. Once there is clarity of what is needed, it is important to consider what is available for reuse, be it all-of-government platforms or tools, reusable components, solutions used by other jurisdictions, any relevant open-source or cloud-based options that provide a point of functional and cost comparison, or indeed any agencies that provide a service or tool that meets the need. Of course, this would require a place to search for reusable components, something for which NSW Government has an early example and the UK Government has an excellent repository of reusable gov.uk services/platforms, components and guidance. The UK ‘Choosing a Technology’ guide is quite helpful.

Only then, armed with a good understanding of the ‘what’, some points of comparison and options, does it make sense to look through procurement panels. Though I note some of the above is not easily possible at the moment, it would be more useful.

Habits of oversimplified but false equivalence are easy to fall into when you get preferred panels and then have procurement teams under pressure to increase the panel subscription. “That sounds like an HR solution, here’s SAP” or “that sounds like a data need, here’s Tableau” rather than what would be more useful at times: “What are you trying to achieve and let’s see if anything we have is appropriate, but you may be best served to go outside of the scope of our panels”. You get significant inefficiencies and productivity issues when people are led or forced into using tools that aren’t fit for purpose.

For anything we do in government, it is useful to use design methods to better define the problem or opportunity, and only then either build, take to market, use a panel or leverage some that is reusable. The pressures of buying now and getting the cheapest immediate option need to be carefully balanced against the longer-term opportunities, risks, value, flexibility, and minimising technical debt.

When to collaborate and when not to

If you are open to collaborating on a solution, then when should or shouldn’t you do so? This is far simpler than may seem to be the case. Basically, if the problem you are trying to solve has others who are similarly motivated or invested, then there is a good chance of genuine collaboration. If you don’t, then collaboration isn’t viable. For instance, legislation as code has a huge group of organisations who would benefit, including regulated entities (and government agencies themselves) who consume rules from legislation every day and so would benefit from having legislation-as-code as digital public infrastructure. But running the email or office suite for your organisation would likely excite no one outside your organisation, so it is likely not a candidate for collaboration, except with those trying to sell you the best possible email/office suite solution. Great vendor relationships are important, but they are very distinct from naturally motivated collaborations around a shared need. Taking the time to determine the best procurement model for these collaborations may be a new practice for your organisation, but the end result will reap dividends (and you’ll have a new procurement model to use in the future).

Having the expertise to engage with experts

One complaint you often hear from companies is that the people they deal with in government don’t seem to understand what they do. This is partly a result of engagement with vendors being largely managed by procurement and contract managers rather than by people who understand the substance of the engagement or solution. If you don’t have domain experts in the room and who are involved in the ongoing vendor relationship, then you run the risk of mutual incomprehension, poor understanding of requirements, and a tick-box approach to assuring a good outcome. One of the challenges here is that the over reliance on outsourcing from some agencies and jurisdictions has hollowed out a lot of technology domain expertise, and where there is expertise, it is often 110% committed to dealing with the IT systems and growing internal technical debt. There is also a dangerous habit of outsourcing the expertise to define and then manage complex contractual arrangements, creating dependencies on contractors for mission-critical implementations. I would suggest that bringing IT and procurement/contract management closer together would get better outcomes, and maintaining an internal workforce of technologists and technical experts, particularly ones that are supported to continually develop their skills and knowledge, is crucial to good procurement outcomes.

Some business and IT teams treat their procurement (and legal) colleagues as peripheral players, but expert procurement advice brought early into the process can save significant time and money for everyone. If you don’t have the necessary procurement skills in your team, grow or secure them.

‘Set and forget’ is not a viable methodology for digital projects, and ‘launch’ is not the end of a project, but rather than start of continuous improvement if you are to have systems that respond to changing needs and requirements. If you want digital systems that are sustainable beyond launch, it is helpful to ensure contracts and contractors align to some common digital design standards and agile work methods, which also means a little flexibility in contracts so that every change request doesn’t break the bank.

Of course, it is hard to maintain technical expertise if you subscribe to the idea that you should outsource all implementation, because the expertise will often leave. So, I would like to suggest that getting the right and appropriately sustainable outcome for the public sector isn’t about outsourcing or insourcing, but rather it is about having a balanced hybrid model of internal and external delivery. My recommendation is that anything genuinely domain-specific or that is a national digital public infrastructure should be run by internal capabilities (with support, but not complete dependence, on vendors) and that it provides a persistence of internal capability for ensuring procurement outcomes are generally better. It goes without saying that no single person in the organisation should be expected to have, or be allowed to build, subject matter expertise to the exclusion of all others, or to be made irreplaceable.

Agency procurement guidelines need to allow their business and technical staff to consult with vendors directly and widely, to both learn what is available on the market and to allow vendors to pitch their products without going through lengthy EOI processes. There are widely divergent interpretations of the Commonwealth Procurement Guidelines on this matter across agencies.

The necessary accountability of public sectors

A lot of work is outsourced by government to third parties. This can be a good way to deliver some things (and there are many arguments as to how much outsourcing is too much); however, there is a serious transparency issue when the information about contracted work is unable to be monitored, generally with the excuse of ‘commercial in confidence’. In reality, truly unique solutions to procurement needs are relatively rare. All contracts should have minimum reporting requirements and should make publicly available the details of what exactly is contracted, with the exception of contracts with national security where such disclosure creates a significant risk. This would also help in creating a motivation for contractors to deliver on their contractual obligations. If procurement officers across government had enhanced training to correctly apply the existing confidentiality test from the Commonwealth Procurement Rules, it would be reasonable to expect that there would be less information hidden behind commercial in confidence and more accountability, which would drive better outcomes and would provide greater possibilities for managing and mitigating risks. When things go wrong in the public sector the impacts can be devastating, so accountability, oversight, and effective continuous management is critical.

The barriers of insourcing

Often a business unit in a department will find it hard to find and engage with potentially appropriate internal capabilities. There is rarely an internal service offering that isn’t limited to BAU IT functions, and I’ve seen many IT departments or service-design functions that have to charge for services, which creates a barrier for even the most basic advice or support. Many IT departments are underfunded, and so can be tempted to overcharge for new works in order to subsidise critical but underfunded systems. So if the internal IT expertise is hard and expensive, how would a typical team get the necessary expertise to make a great technology decision let alone have a realistic chance of effective insourcing? The answer is that business units end up being completely reliant upon either the advice of ad hoc skills in their team or their vendors. More technically-literate functions end up being able to innovate with technology, while many other business units struggle with basic tools and low investment. A real case I saw included an internal IT department give a quote to a low capability business unit to do an ‘online survey’ for… wait for it… $4 million, for a non-sensitive and small survey of agency needs. On the one hand, I can only imagine IT were either limited to an expensive tool or trying to subsidise their budget, but the business unit accepted the quote without question and ended up doing the survey by emailing documents.

Better technology literacy would help everyone make better choices.

If departments both valued and supported the maintenance of an internal capability (which necessarily means designing and running some things internally, or the expertise erodes over time), and then ensured the expertise was funded to provide some advice, expertise and design/delivery to the rest of the organisation, then you’d have better informed sourcing and procurement decisions being made.

Final word

In conclusion, of course we need procurement practices that are streamlined, effective, easy for vendors to understand and engage with, and as simple as possible. But procurement-reform efforts that simply improve the ease of buying stuff can lead to bigger, faster, and more costly disasters unless there are also improvements in all the areas outlined above.

It is relatively easy to just speed up: from walking, to jogging, to running as fast as you can. But if you are headed in the wrong direction, you might well find yourself just sprinting off cliffs.

About the author
Inline Feedbacks
View all comments
The Mandarin Premium

Canberra’s changed

Stay on top for only $5 a week


Get Premium Today