Back when technology was expensive, applications only made sense for high-volume, well-structured work. Think payroll. The lower unit costs of the automated system compensated for the large costs of setting the system up. Well-structured work made the programming simpler, and gaining the payback required lots of lower-cost units, so it was natural for computing to go first to the Census Bureau, the military and to other large governments that had lots of standardized clerical work.
Over time, as processing productivity doubled, we could increasingly cost-justify applications with more complexity and lower volumes. The more we learned, the more programming and other set-up costs fell. And we could cover those costs even if we used the new applications less frequently than the payroll-type work that got us started. A spreadsheet model for revenue projections, for instance, might be worthwhile even if used only a few times during a single planning season.
Explosive growth in technology productivity has expanded the range of computer applications from automation to innovation, and from working with clerical managers to working throughout the organization. The targets have grown from large governments with high volumes of work to include smaller governments with less volume.
Moreover, work that is suitably standardized for computerization has expanded to include not just the work of smaller organizations but also work that is standardized across multiple organizations. Many agencies now use "packaged" applications -- the same payroll, enterprise resource planning, customer relationship management and other packages -- thus saving the original costs of programming and many of the ongoing costs of maintenance and upgrades. Because we can now reach users through the enormous scale of the Internet, the most important standardization is not that within a given institution, but the aggregated results across many.
But do we really expect the small fish governments to offer more attractive applications than the whales?
Yes, and for two reasons:
- The long tail. Even if the Pareto distribution holds, where the largest 20 percent of governments hold 80 percent of the workers, we've still got a major opportunity left with the small ones. The remaining 20 percent of the workforce (those from the 64,000 U.S. governments we consider small) has a lot of "catch up" room which will allow producers to take advantage of applications they understand well but have not yet reached smaller governments. The individual projects may be smaller in small governments, but the overall impact will be large. Ohio, for example, has the relatively big city of Columbus, but what about the potential impact of technology-based innovations for Westerville, Chillicothe, Marietta and Bexley?
- Lower "sales" cost. High costs for reaching small players have traditionally kept vendors and CIOs fishing for the whales. But it's easier now to reach small governments and small programs. They (like individual consumers) can be reached through Internet marketing and other communications that don't require much manual effort. More importantly, small governments are less resistant to accepting technology services from outside organizations, since they don't have the same traditions or capacity for handling technology on their own that large governments do. Small governments have neither complex legacy systems to manage nor a large and longstanding technology staff with turf to protect. Given the enormous cost pressures on all governments, it will be easier for the small ones to give up on supplying technology services for themselves (a means to their goal) in order to maintain their relationship with constituents (their ultimate goal).
For larger governments. Those governments that can supply technology services efficiently should prepare to produce not only for themselves but for communities of public agencies that could benefit from their services (and particularly from shared producer/consumer commitments to security, privacy and public service).
To identify these opportunities, larger governments need to seriously explore and analyze the possibilities. Perhaps they should offer services on their own, as Oakland County in Michigan has done for policing, licensing, GIS and other services. On the other hand, perhaps they should work through a private partner, as the Virginia Information Technology Authority is doing. More complex aggregations of work are also possible, as with the federal/state/local collaborations fostered by the National Environmental Information Exchange Network.
For small governments. These governments need to take advantage of applications for tasks not yet computerized and/or outsource their existing computing to more efficient larger governments or the private sector. They should focus on applying technology services, not producing them.
To identify these opportunities, smaller governments need to evaluate what's being offered and what others are taking. They should explore shared procurement options, certainly for computing services and also for technology-enabled services such as HR and regional 311 systems. Typical early targets include e-mail and office applications, cloud storage and backup support, collaboration tools and even low-demand K-12 courses that can no longer be afforded by the local school system (e.g., the less popular language courses or other niche subjects).
Given ongoing technology developments, the most efficient scale for technology service operations is becoming larger in most cases than a single governmental institution can provide for itself, especially the smaller ones. Optimal use of those services requires standardization and sharing across multiple governments. Because small governments don't have as much internal resistance to outsourcing, and because they offer, in aggregate, a huge target for IT-enabled work that has yet to be addressed, we need to give small government computing more attention than we have in the past.
