The great truism that underlies the civic technology movement of the last several years is that governments face difficulty implementing technology, and they generally manage IT assets and projects very poorly.
It can be tempting to view this lack of technology acumen as a symptom of a larger disfunction. Governments are thought to be large, plodding bureaucracies that do lots of things poorly – technology management and implementation are but one of the many things that governments do not do well.
But the challenges facing governments as it relates to technology are quite specific – there are a handful of processes, all easily identifiable, that work against the efficient adoption of technology by governments. Understanding why governments struggle to implement new technology requires us to understand what these factors are and why they negatively impact technology adoption so specifically.
The challenges that governments face in adopting new technology are not symptomatic of a larger disfunction – when it comes to the efficient adoption of technology, governments are built to fail.
The Government Procurement Process
Over the past year, primarily as a result of the botched rollout of the federal Healthcare.gov website, there has been significant attention given to the aspects of the government procurement process that hinder efficient technology adoption.
The process clearly does not work well for governments – and many would argue that it does not work well for technology vendors either. Typical government procurement rules shut out many small firms that may be well positioned to execute on a government IT project but that lack the organizational endurance to make it through the lengthy selection process.
The process is complex, costly and – most importantly – slow. To illustrate the magnitude of the issue, consider that in the City of Philadelphia the period between a contract award (when a vendor gets selected to work on a project) and the final execution of that contract (when the work actually begins) can take an average of four months for some projects. Some technology solutions have shorter release cycles than that.
This makes the government procurement process particularly ill suited (in its current form) as a means for governments to acquire technology. The pace at which new technologies mature is much more rapid, and the glacial pace at which the government procurement process moves can lock governments into outdated solutions.
The most under-appreciated characteristic of the procurement process is that it’s current design is largely intentional. Governments imbue the process with requirements and other stipulations that they hope will lead to outcomes that are deemed desirable. Each of these requirements adds to the complexity of the process and the burden of firms that choose to respond to government RFPs.
For example, almost every government has purchasing requirements for minority- and women-owned businesses, and many have requirements that local companies receive preference over firms from outside the jurisdiction. The objective is to drive more government procurement dollars to minority- and women-owned businesses and to local businesses that create local jobs and pay local taxes.
There are also larger, overarching values embedded in the procurement process. For example, fairness and transparency are values that inform requirements like the public posting of bids and related materials, ample public notice of vendor meetings, and the clear specification of when and how bids must be submitted.
Risk aversion is another value that impacts the complexity and cost of the public procurement process. It is this value that informs requirements like performance bonds, vendor insurance, scrutiny of company financial statements, and requirements for financial reserves—all things that seek to reduce the risk assumed by governments from engaging with a company to provide a good or service. Each of these requirements can make the procurement process more complex and burdensome for bidders, particularly smaller companies.
These features of the procurement process were designed with a specific intent, and few people would argue with the laudable goals they seek to encourage. Yet, one of the side effects of these requirements is that they make the process slower, more complex, and harder for smaller and more nimble firms to participate in.
In other words, the procurement process works largely as it was built to work, but its design makes it a lousy tool for acquiring technology.
The Public Budgeting Process
Perhaps more fundamental than the procurement process, the process used by governments to deliberate and adopt spending plans is deeply flawed as it relates to encouraging innovation generally and adopting new technologies specifically. There are built-in disincentives in the public budgeting process for agencies to demonstrate large efficiency gains that result in the need to outlay fewer dollars.
Public agencies that have unused allocations at the end of a fiscal year – money that is appropriated but not spent – inevitably see those dollars redirected to another agency or policy priority in the next budget cycle. Mayors, governors, and legislators see this as an effective way to allocate finite resources between competing interests. If an agency doesn’t spend down their entire budget allocation, they must not need it and a reduction is justified. In other words, the budget process works as government administrators have designed it to work – to reallocate resources away from agencies that don’t need them to agencies that do.
However, most agencies see this outcome as unfavorable – a diminution of their mission and a loss for the clientele that they serve and are advocates for. It can be a powerful disincentive for agencies to use new technologies to create efficiencies that result in cost savings.
Employee Recruitment & Retention
Most government employees – at the federal, state and local levels – are hired into an agency through a merit-based civil service system. The development of civil service systems, which are supposed to grant job opportunities on the basis of merit, were a response to widespread political patronage that was common long ago.
Most civil service systems have fairly rigid job classifications and salary structures, meant to provide transparency into what specific positions are paid and to place limits on the ability to reward specific employees because of political preference or for other reasons. There are typically requirements for public job postings, and advertisement of openings for specified period. Applicants are typically required to demonstrate fitness for a position and may often be required to take a civil service exam to demonstrate minimum competency on a particular subject.
Not unlike the procurement system, we imbue certain values into the civil service system in the hopes of fostering outcomes deemed favorable. For example, in the City of Philadelphia the children of police and fire personnel are given preference in the civil service process. This is not meant to suggest that granting such applicants a preference is inherently a bad thing, but (as with the procurement process) using the civil service system as a vehicle for fostering outcomes can come at the cost of making the process more lengthy and complex for all applicants.
Public sector salaries and benefits generally lag behind the private sector, and altering pay structures and adding new job classifications in response to changes in the world of technology can be difficult. This is particularly troubling for those interested in recruiting top IT talent into government because, unlike with many other kinds of government job types, governments are in direct competition with the private sector for IT workers. A “system administrator” or a “web developer” or a “project manager” requires largely the same kinds of skills and experience inside of government or outside.
Like the procurement process and the budget process, the civil service system works as it was designed to work. Unfortunately, the way that it works makes it ill suited for attracting and retaining a highly skilled IT workforce.
The Cost of Building to Fail
What’s particularly interesting is that even if the policies that underpin each of these processes doesn’t change at all in the next several years, the problems that governments face in adopting new technology will get steadily worse. That’s because the pace of change in the world of technology continues to accelerate – as it does, the difference between the rate at which new technologies mature and the rate at which governments can make budget or purchasing decisions, or reclassify jobs and salaries in response will get larger.
The old Hippocratic maxim of “first, do no harm” will be insufficient in addressing this problem. We absolutely must do better, and we must do it soon.
How Do we Fix It?
It’s important for advocates of successful technology adoption in government to understand why governments face so many challenges in acquiring and implementing technology. The processes that support paying for and acquiring technology, and the process for hiring IT workers are designed in a way that make them a bad match for the dynamics of the technology industry.
Knowing why governments face challenges in implementing new technology is important if we’re going to find ways to address the problem. When we examine the range of different approaches being advocated to help governments more successfully adopt technology, we should evaluate their merits based on the degree to which they address one or more of the processes detailed above.
For example, efforts to bring more highly skilled technology employees into government through groups like 18F in the US, or the Government Digital Service in the UK are meant to address the challenges faced in recruiting IT staff through traditional civic service channels. Projects like Screendoor are meant to address challenges that typically arise from traditional government procurement processes.
There are lots of other examples of efforts underway to help governments get better at implementing and using technology – too many to discuss fully here. But the ultimate success of each will be tied – I believe – to the degree to which they help address the challenges engineered into one of the three processes discussed above – procurement, budgeting and employee recruitment / retention.
Governments are not bad at adopting new technologies on accident. The processes that support the adoption of new technology were built to fail. Understanding this is the first step to fixing them.
The IT community consistently blames its failure to deliver on anyone and everyone but themselves. Point the finger at procurement or budgeting or HR. How about instead we ask questions like:
Is it possible for the IT community to just get the basics right? Provide a stable, safe fast infrastructure on which business units can develop their own solutions?
Can IT gurus spend more time on hardware plus software and less time trying to redesign the procedures of the business unit they are supposed to support?
Can IT professionals accomplish even the most simple, routine tasks without hiring multiple consultants to conduct EAPs, develop vision statements, needs analysis, alternatives analysis, architecture updates, vision refreshes and maybe after 18 months finally getting started on an actual deliverable product?
If, as and when the IT community ever gets its own act together, the rest of us might listen to their criticism of procurement, budgeting and HR with a little less eye rolling.
Amen, Peter Sperry! Agile development instead of waterfall, and working with established business processes instead of creating new ones.
This isn’t meant to “point the finger” at budget, HR or procurement. I think inhere is value in pointing out the institutional disincentives to proper technology implementation in government – they’re real, and we need to address them in order to get more out of the resources being invested in technology staff and assets.
This isn’t just the problem of the IT department. Everyone working in government has a stake in getting IT right.
I like the analysis and I think that you have addressed most of the big issues. I’ve seen both sides and think there are also some technical reasons that also dampen IT projects. It is not just a process issue. The government usually has a size issue that dwarfs even the largest of commercial applications in the same space. You want an HR system in the commercial world and a big one is 100,000 employees — and they pretty much have one major function of build cars or retail sales. The federal government has it in mind that they want one system for everybody and the headcount is in the millions.
Of course, no two departments do anything alike and they have sometimes as much as 200 years of “we’ve always done it this way” to compete with. A commercial system may think they are getting into the big leagues when they plan on a system that can handle 100 million potential customers. The government sometimes has to do the same thing for no less than 300 million. Size makes a big difference.
One other thing too is that the government is not allowed to fail. Companies that start a major IT project and fail horribly sometimes can sweep it under the rug or go out of business relatively quietly. Governments are chastised in the press until the whole thing is made right. If it takes 5 years to do it again, they are lambasted for 5 years. Commercial failures show up once in a quarterly stock report, the old vendor is fired and promises of a new vendor are all started before the quarterly report even hits the public. It is just really hard to make a meaningful comparison.