No Assembly Required

assembly

Photo courtesy of Flickr user Sharyn Morrow

When we think about all of the work being done in the civic technology and open government communities over the last several years, it’s easy to see the impact.

Evaluated just in terms of the number of datasets that have been released by governments it is clear that the impact of those advocating for more open, responsive and agile government has been significant. But those working in these communities have far more to show for their efforts. One of the most under appreciated (at least in my opinion) is advice: solid guidance and recommendations for how to make things better.

Consider all of the work being done to provide recommendations for governments to use technology more efficiently and to become more open and transparent. There are countless examples where individuals that have developed expertise over many years of working to improve how governments use technology and data share their learnings and recommendations freely and openly. We don’t have a shortage of good ideas for governments to use to start making changes to how they use technology to build services and engage citizens.

But I think there is a legitimate questions as to whether enough governments are using these recommendations, or they’re not using them quickly or effectively enough.

I’ve spent a lot of time lately wondering why.

Read More

Why 18F’s New Approach to Procurement Reform Matters

Fast Track

Image courtesy of Flickr user lchunt.

In another recent post, I talked about how public sector technology procurement was not well suited for the digital age.

But there are some efforts underway that seek to identify new methods of procuring technology solutions for government. As these ideas start to take hold, there is hope that those in the govtech community will create a set of strategies for more successfully implementing public sector technology solutions.

Built to fail?

The design of procurement policies that are used by our federal, state, and local governments are meant to encourage broad participation by requiring things like public announcements of solicitations, open vendor meetings, and fixed deadlines for submitting responses. The hope is to make the process as predictable and transparent as possible, and to level the playing field so that any qualified vendor can participate.

Procurement policies are also designed to mitigate risk and to ensure that selected vendors are competent and capable of undertaking the work required in government IT projects. It is important that these policies be consistent with the government’s duty to be responsible stewards of public resources.

In light of this, there is a great irony in the outcomes that these policies often seem to produce.

Read More

Enabling the Enterprise

Its not often that I run across posts about enterprise architecture that get me excited. This one – by Tariq Rashid – did. Very much so.

This issue interests me because its one that, as a former state IT executive and policy advisor, I have personal history with. I also believe its an issue that will have great impact on how successful governments are at redesigning services around users, and embracing civic technology and open data.

Read More

Pursuing Change by Finding Balance

The recent crash of a quadcopter drone on the grounds of the White House has drawn attention to the absence of final rules from the FAA governing unmanned aircraft – rules that have now been in the works for years.

This one incident almost perfectly encapsulates the difficulty that governments have with keeping pace with changes in technology. Technology can change in a matter of months or even weeks, quickly making it easy and affordable for almost anyone to buy a drone. The process that the government uses to adopt new rules and regulations, that can govern how these newly affordable drones may be used, can take years to become final.

Read More

Hacking the RFI Process

rfi

The Seattle Police Department recently held a hackathon.

When the event was initially announced, there was a fair bit of skepticism in the civic technology community with more than a few people stating that the event would likely not be a productive one, for either the Seattle Police or those that chose to attend. I was one of those skeptics – I thought the event was too narrowly focused and that the problem that attendees would be working to help resolve wouldn’t appeal to a broad enough audience for it to work as the organizers probably hoped.

Read More

The Collaborative State

“Civic Hacking” is the awareness of a condition that is suboptimal in a neighborhood, community or place and the perception of one’s own ability to effect change on that condition. The apps are incidental.

In 2008, civic hacking was the furthest thing from my mind.

Read More

What if We’re Doing it Wrong?

Ever since the botched launch of Healthcare.gov, procurement reform has become the rallying cry of the civic technology community.

There is now considerable effort being expended to reimagine the ways that governments obtain technology services from private sector vendors, with an emphasis being placed on new methods that make it easier for governments to engage with firms that offer new ideas and better solutions at lower prices. I’ve worked on some of these new approaches myself.

The biggest danger in all of this is that these efforts will ultimately fail to take hold – that after a few promising prototypes and experiments governments will revert to the time honored approach of issuing bloated RFPs through protracted, expensive processes that crowd out smaller firms with better ideas and smaller price tags.

I worry that this is eventually what will happen because far too much time, energy and attention is focused on the procurement process while other, more fundamental government processes with a more intimate affect on how government agencies behave are being largely ignored. The procurement process is just one piece of the puzzle that needs to be fixed if technology acquisition is to be improved.

Right now, the focus in the world of civic technology is on fixing the procurement process. But what if we’re doing it wrong?

Things Better Left Unsaid

During the eGovernment wave that hit the public sector in the late 90’s to early 2000’s, tax and revenue collection agencies were among the first state agencies to see the potential benefits of putting services online. I had the good fortune to work for a state revenue agency around this time. My experience there, when the revenue department was aggressively moving its processes online and placing the internet at the center of its interactions with citizens, permanently impacted how I view technology innovation in government.

It’s hard for people to appreciate now, but prior to online tax filing state tax agencies would get reams and reams of paper returns from taxpayers that needed to be entered into tax processing systems, often by hand. Standard practice at the time was to bring on seasonal employees to do nothing but data entry – manually entering information from paper returns into the system used to process returns and issue refunds.

The state I worked for at the time had a visionary director that embraced the internet as a game changer in how people would file and pay taxes. Under his direction, the revenue department rolled out innovative programs to fundamentally change the way that taxpayers filed – online filing was implemented for personal and business taxpayers, and the department worked with tax preparers to implement a new system that would generate a 3D bar code on paper returns (allowing an entire tax return and accompanying schedules to be instantly captured using a cheap scanning device).

When these new filing options were in place, the time to issue refunds plummeted from weeks to days, and most personal income taxpayers saw their refunds issued from the state in just a couple of days. By this time, I had moved to the Governor’s office as a technology advisor and was leading an effort to help state departments move more and more services online. I wanted to use the experience of the revenue department to inspire others in state government – to tout the time and cost savings of moving existing paper processes to the internet, making them faster and cheaper.

When I asked the revenue director for some specifics on cost savings that I could share more broadly, his response could not have been further from what I expected.

He told me rather bluntly that he didn’t want to share cost saving estimates from implementing web-based services with me (or anyone else for that matter). Touting costs savings meant an eventual conversation with the state budget office, or questions in front of a legislative committee, about reducing allocations to support tax filing. The logic would go something like this – if the revenue department was reducing costs by using web-based filing and other programs, then the savings could be shifted to other department and policy areas where costs were going up – entitlement programs, contributions to cover the cost of employee pensions, etc.

All too often, agencies that implement innovative new practices that create efficiencies and reduce costs see the savings they generate shifted to other, less efficient areas where costs are on the rise. This is just one aspect of the standard government budgeting process that works against finding new, innovative ways for doing the business of government.

Time to Get Our Hands Dirty

A fairly common observation after the launch of Healthcare.gov is that governments need to think smaller when implementing new technology projects. But at the state and local level, there are actually some fairly practical reasons for technology project advocates to “think big,” and try and get as big a piece of the budget pie as they can.

There is the potential that funding for the next phase of a “small” project might not be there when a prototype is completed and ready for the next step. From a pure self-interest standpoint, there are strong incentives pushing technology project advocates to get as much funding allocated for their project as possible, or run the risk that their request will get crowded out by competing initiatives. Better to get the biggest allocation possible and, ideally, get it encumbered so that there are assurances that the funding is there if things get tight in the next budget cycle.

In addition, there are a number of actors in the budget process at all levels of government (most specifically – legislators) who equate the size of a budget allocation for a project with its importance. This can provide another strong incentive for project advocate to think big – in many cities and states, funding for IT projects is going to compete with things like funding for schools, pension funding, tax relief and a host of other things that will resonate more viscerally with elected officials and the constituencies they serve. This can put a lot of pressure on project advocates to push for as much funding as they can. There’s just too much uncertainty about what will happen in the next budget cycle.

Its for all of these reasons that I think it’s time for advocates of technology innovation in government to get their hands dirty – to roll up our sleeves and work directly with elected officials and legislators to educate them on the realities of technology implementation and how traditional pressures in the budget process can work to stifle innovation. There are some notable examples of legislators that “get it” – but we’ve got yeoman’s work to do to raise the technology IQ of most elected officials.

Procurement reform is one piece of the puzzle, but we’ll never get all the way there unless we address the built in disincentives for government innovation – those that are enforced by the standard way we budget public money for technology projects (and everything else). We’re having conversations in state houses and city halls across the country about the future costs of underfunding pensions, but I don’t think we’re having conversations about the dangers of underfunding technology with the same degree of passion.

Time for us to wade into the morass and come back with a few converts. We’ve got work to do.

Built to Fail

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.

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.

On Sustainable Civic Technology

Sustaining civic technology will mean that both government’s IT infrastructure and the civic technology sector that builds on it will need to change.

A pair of recent blog posts caught my eye and highlighted this theme in my head, and motivated me to capture a few thoughts on this topic.

The first post was by Dan O’Neil, Executive Director of the Smart Chicago Collaborative. Dan’s post on the the things that need to happen to drive the “…maturation of the civic innovation sector of the technology industry” are worth the read. It’s a great post that helps highlight the connection between legacy IT system in government and open data, which is used to build civic technology.

“[without] existing legacy gov IT systems, there would be no civic tech. The data we use for our civic tech projects doesn’t get collected, managed, and exported by itself.”

The second post is from the Bay Area design firm Stamen, and highlights the need for data visualizations (and other bits of civic technology that rely on open data) to be maintained over time. The post uses the analogy of gardening to underscore the need to constantly update and maintain the things we build with data.

“If you plant a flower in a garden and then never give it water or light, it will in fact die. Unless, of course, it happens to placed in just the perfect spot, in which case it will need to be pruned. Either way, some kind of tending is always required.

We don’t always think of digital works in the same way, perhaps because their metaphor of creation more closely resembles that of a built object, like a bookcase or building. But even buildings need maintenance, and after so many years, the shelves on the bookcase may falter and need new ones. We need to be more conscious about this aspect of dynamic data visualization, at the outset.”

These two posts call out the need for both the government technology systems that lie at the foundation of open data, and the civic technology that uses this data to get better. To mature. To advance to the next level.

For me, the takeaways from these two posts are pretty clear.

Technology and civic apps are like gardening – except when they’re not.

I like the analogy of gardening applied to investment in technology solutions. It underscores the need to continually invest in the maintenance and upkeep of the solutions that are used to consume government data. However, I think there is some danger in using this analogy in that it obscures the the fundamental nature of change in the technology world.

I can tend my garden today in pretty much the same way as someone did 100 years ago – soil, water and sunshine. Boom. However, when building a technology solution (particularly web-based solutions) its not feasible to use the same approach or components that might have been acceptable as recently as 10 years ago. Budgeting for maintenance and enhancements for technology projects isn’t a nice to have – its absolutely essential to their success. The pace of change in the world of technology is just too fast for anything less.

We have to fix the budget process as it relates to investment in technology.

I’ve harped on this before, but we most definitely need to get better at helping non-technology people in government (particularly budget officials) understand the need for continuous support and maintenance of IT projects. Correction – we need to help them understand technology better in general. Not since the first season of The Bachelor has there been a worse match than the current public budgeting process and the pace of change in the world of technology.

To understand how acute this problem is, ask some you know that works in state or local government if they (or someone they work with) interacts as part of their job with a technology system that is 10 years old or older. I think the responses would be surprising to many people, and rather alarming to most professional technologists.

Government needs to embrace its role as a data steward

Governments need to understand their role in the civic technology production chain. The current public budgeting and procurement processes make us lousy at investing in the kinds of technology that chance rapidly – like those that power web-based solutions.

When I read the post by Stamen about their Crimespotting project with the City of Oakland, I see a city that hasn’t accepted its role as a mature data steward:

“…over the years, the project started wavering. Oakland’s API has sputtered to the point of being nonfunctional, rendering Oakland Crimespotting totally spotless.”

If governments are serious about open data, they need to invest in systems that will make their data easy to consume and readily available – without this, the civic technology sector won’t go far.

I think part of this is accepting the role of data steward, and engineering our IT infrastructure accordingly. I don’t know if Stamen’s was the only project consuming the Oakland crime data API, but building a robust community of users around open data can help public officials see the importance of investing to keep these systems stable and available.

Don’t underestimate the power of open source

When it comes to helping ensure that civic technology solutions continue to thrive after launch, there is almost nothing better than leveraging the power of open source. There’s nothing wrong with closed source solutions built on top of open data, but if governments are paying for custom solutions from vendors to display open data we should insist that the underlying code be open sourced. This can go a long way toward helping ensure that it continues to evolve over time, as civic technologists contribute fixes and enhances and (potentially) as other governments fork these solutions for their own use.

It’s really cool to see the conversation around civic technology and open data focused on how we can take the great work that has been done to the next level. I think it means we’re ready for the next steps.

Three Hard Truths for Government Procurement Reform

Advancing the innovation agenda within government often means confronting the harsh reality of the government procurement process. This is not a new problem, and there are a number of initiatives underway in governments around the country aimed at “streamlining” or “overhauling” the government procurement process to support the acquisition of new technologies and projects that engage smaller and more nimble companies with new solutions.

The City of Philadelphia, in particular, is engaged in some progressive efforts to use the government procurement process as a means to develop an ecosystem of smaller companies that offer innovative new ideas to longstanding city problems. If the goal of using the procurement process to stimulate (or at least not hinder) innovation inside government is to be realized, reformers in Philadelphia and elsewhere will need to face some hard truths about procurement reform.

Balancing Values

[M]any of the factors that make government procurement processes complex and slow are also things that are intended to produce desired outcomes.

The arguments in favor of reforming the government procurement process bear a striking similarity to arguments used by advocates for overhauling the federal income tax system. Both sets of advocates point to the problem of unnecessary complexity as an element that can stifle innovation or even harm participants. In many instances, the same verbs are used when calling for reform—words like “overhaul” and “streamline” can be used almost interchangeably when talking about tax reform and procurement reform.

The federal income tax system is a useful reference for talking about procurement reform. It is often used by governments as a vehicle for achieving desired outcomes that (as many economists will quickly point out) have nothing to do with an efficient tax system. We imbue our tax code with certain provisions that, we hope, will help achieve outcomes deemed to have broad societal value.

A perfect example of this is the federal income tax deduction for mortgage interest. As a country and a society, we value homeownership over other kinds of investments, so our tax system “rewards” this investment with a special deduction. The objective is to encourage more homeownership because it is highly correlated with desired outcomes, like higher property values and more stable neighborhoods. This deduction comes with a cost, however: it increases the complexity of tax forms, and it increases the effort required both to process these forms and to audit taxpayer compliance.

There are many other examples of income tax provisions that are specifically engineered to produce outcomes with broad social benefits—a myriad of deductions and credits for married couples, particularly those with children; deductions for contributions made to charities; and deductions for interest on student loans. Each of these examples shares two characteristics: they are designed to encourage specific outcomes, and they increase the overall complexity of the system. On an individual level, the cost of these broader societal benefits manifests as more time and effort to comply with income tax requirements.

Procurement processes are similar in many ways. Governments imbue these processes 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.

All of this underscores the point that many of the factors that make government procurement processes complex and slow are also things that are intended to produce desired outcomes. 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.

Efforts to overhaul or streamline the procurement process will undoubtedly run up against the provisions just discussed. Are there ways to streamline the procurement process that don’t require provisions of this type to be relaxed or removed, or are there ways to relax these provisions without compromising the laudable outcomes they seek to encourage? This remains to be seen.

Nimbler Doesn’t Always Mean Better

Simply making the government procurement process “simpler” won’t guarantee that better IT decisions get made

One of the great myths in government IT is that the private sector is always way ahead of the public sector in how technology is used.

In between two tours of duty in state and local government, I spent about ten years in the private sector working for both large and small technology firms. Before joining Code for America as Director of Government Relations in 2011, I worked for four different technology companies headquartered in places as different as Horsham, Pennsylvania; Blacksburg, Virginia; and San Francisco, California. I learned a lot about technology and how to be a software developer during this time, but I also learned that—as far as technology is concerned—the grass is not always greener on the other side.

There are plenty of examples of poor technology decisions in the private sector. We just hear about them less often because they are usually not a matter of public record or visible to the public through a budget submission or legislative hearing.

To be sure, governments around the world have issues with implementing technology, but some of the things I’ve seen in the private sector have been shocking—inexcusably bad decisions made by people who should know better, a complete lack of strategic thinking about how technology is used to benefit the company, and dragging old legacy technology along far past its point of usefulness simply because upgrading would be tricky and complex—the list goes on. The private sector has all of these problems and more. We just don’t hear about them as much.

What my experience in the private sector made exceedingly clear to me is that it is entirely possible (and not very unusual) for private sector organizations, unshackled by complicated procurement processes like those used by governments, to make lousy choices and invest poorly in technology.

Simply making the government procurement process “simpler” won’t guarantee that better IT decisions get made. Governments will still need to think more strategically about how they invest in technology and become better at learning how it can be used to make the delivery of public services more efficient and effective.

A Dearth of Makers Inside Government

If the people who work for government don’t have a clear enough sense of how things get made, they are ill-equipped to evaluate RFP responses from individuals or companies that want to do work on behalf of the government.

My experience working as a software developer for several years, and continuing to work with other developers from a variety of disciplines for years after that, has affected the way I approach problems. Whenever I hear about an application or service or an idea someone has for one, I’m often privately thinking (as I think most people who have worked as developers are), how would I build something like that? This is probably true of most people who have built things for a living.

Understanding how things work and how to build them can be a useful skill when evaluating the level of effort required to perform a service or to solve a problem. This is something software developers do often—estimate the amount of time it will take them (or their team) to complete a series of tasks they have not yet begun. It’s hard to do well. Even software developers who do this often will sometimes underestimate or overestimate the amount of time required to complete a task.

The ability to translate a problem into a series of steps that a person can imagine herself doing is the specific byproduct of making things. This is a problem in government, where, in general, there is a woeful lack of awareness about how things are made and what resources and materials are required to build things. In short, there is a critical lack of makers in government.

This problem is particularly acute when it comes to technology and how governments acquire it, even for needs that should be simple and relatively cheap, like content management systems for websites and web-based applications. The web is now an essential component of how governments deliver services and communicate with citizens, and yet, there are far too few people inside government (including those in the technology discipline) who have a solid understanding of how the internet works.

In just the last few years, the world of software development has seen a sea change that has transformed how web and mobile applications are built. Never before has it been easier or cheaper to build these applications. Yet governments continue to overpay for them (or the services of those firms that build them) because there is very little in-house knowledge of how these things are built.

This is not to suggest that effective websites and useful web applications are easy to build and don’t require skill. They certainly do, but without a fundamental understanding of what the technologies behind these applications are, how they work, and how they are changing, governments cannot distinguish the skilled vendors offering reasonably priced solutions from the shysters.

If the people who work for government don’t have a clear enough sense of how things get made, they are ill-equipped to evaluate RFP responses from individuals or companies that want to do work on behalf of the government. This is especially important for technology procurement, where new software development paradigms can evolve rapidly.

Governments need to place an emphasis on recruiting and hiring people who have experience making things. In addition, governments need to focus on developing the “maker skills” of existing employees. This, by extension, will enhance the ability of governments to evaluate the estimates for work provided by respondents to RFPs.

[Note – this content appeared as part of a chapter I wrote for the book “Beyond Transparency.” If you want to read more, check it out.]