Filling up the Civic Tech Toolbox
By: Mark Headd
Tags: Procurement, Product Management, Civictech, Government, Technology

Assuming rationality

So much of the work we do in government technology modernization involves developing what essentially boils down to advice — lists of best practices, playbooks, and guides to help agencies adopt technology more successfully. “Here is how agile works, here is why DevSecOps is so important, talk to users, scope projects smaller — now go do these things.” *

And while all of this guidance and content is valuable, this approach assumes that the sole problem facing development and service delivery teams is a lack of information. But what if we proceeded from the assumption that an information deficit was not the primary cause of technology dysfunction in a government agency, that delivery teams had access to information on how to properly run their projects but chose not to anyway? What would explain these decisions if lack of access to information on how to do it properly was not the issue?

It’s useful in these cases, I think, to look at a framework from the world of economics — rational choice theory. This theory holds that individual actors in a market will (usually) act rationally and in their own self interest based on available information. I’m not suggesting that this theory explains everything about how markets work (it doesn’t), but it is a useful construct in helping us understand why service delivery teams — and government agencies more broadly — sometimes make the choices that they make. If we approach a technology problem using the assumption that the individuals making decisions will act rationally, then it helps us to focus on the forces behind how these choices get made.

Consider the common civic tech precept to scope technology projects more modestly, and to iterate more frequently. There is plenty of information and accumulated experience to suggest that larger technology projects fail at a higher rate than smaller ones. If we assume that information deficit is not the root cause of decisions to make projects larger — i.e., project teams know that larger projects have increased risk of failure — what then explains the reasons that projects become large?

If we assume rationality, we might better understand the reasons why a service delivery team might choose a larger project over a smaller one. Consider the process to accredit technology systems for production deployment — this process usually involves a significant amount of paperwork and documentation on a litany of different security controls. It can sometimes cost a team more in terms of time and effort than the work to actually build a solution in the first place. Given the overhead involved in a process like this, it might make sense from a project team perspective to limit the need to run this gauntlet to as few times as possible — or even only once if that can be achieved. This might drive a team to enlarge a project scope, to reduce the number of iterations, and jam as much work into a release as possible so as to only pay the overhead of the accreditation process once.

Viewed in this way, we can see that the decision to scope a project more broadly is rational (from the perspective of the project team). It makes sense given the weight of the process that may be needed to get successive iterations of a solution released. It’s not that a project team isn’t aware of the risks of larger projects with fewer iterations, it’s that the environment in which they are building the solution favors larger projects. It “rewards” them with fewer trips through the accreditation labyrinth.

This is a bit of a contrived example, but it’s not a stretch to apply this same framework to things like the procurement process (which can also be lengthy and costly) or other processes that have phase-gates with large documentation requirements at each step. Faced with the overhead of complying with these processes, it is sometimes the rational choice to enlarge projects so as to pay this cost as few times as possible.

Understanding why delivery teams would make these decisions is key to understanding the root cause of technology dysfunction. The answer is often about more than just the technology being used.

We need to free our minds, to open up opportunities for thinking about these problems differently. For this to work, we need to look at how other disciplines analyze problems and understand their causes. There’s so much room here to add to our standard tool kit for fixing government technology issues. As civic technologists, it’s up to us to find them and start using them.

Let’s fill up our tool box.

* Oversimplified to make a point, but you get my drift.