Chapter 26. Transparency Inside Out
A surprisingly regular experience in the Pentagon is what I call the boomerang email. You email a question to a colleague. Not knowing the answer, he forwards the email on to someone else, restating the question in his own words. Through subsequent forwarding, the email passes through government offices and military bases across the country, and the question is rewritten several times over. Days later, someone forwards you an email with a question similar to yours, asking if you have any insights. The sender never scrolled to the bottom of the long thread to see that you were the original person to ask the question.
While the Pentagon is notorious for its opacity to the public, one would assume we are transparent to ourselves. Yet an insider, not knowing where to find necessary information, can email an inquiry to a colleague and a few days and dozens of people later get nothing in return but an echo. I’ve spent three years at the Pentagon as an on-site contractor in an organization that oversees the acquisition of all major military systems, including ships, planes, tanks, and satellites. We don’t have a secret dashboard with all key information ready for analysis. We certainly collect data and generate a lot of reports, but too often the information is either out of date, incomplete, scattered across dozens of databases, or all of the above. In some cases, the desired information is simply never captured. In my world, it’s implicitly understood that the only reliable way to follow the week-to-week evolution of an issue is to participate directly in the discussion or talk to someone who has.
In his Transparency and Open Government memo, President Barack Obama declared that “executive departments and agencies should harness new technologies to put information about their operations and decisions online and readily available to the public” (see the Appendix A). To the average citizen this may sound like simply uploading existing government information to a web portal. The difficult reality is that the departments and agencies themselves do not have easy access to information about their operations and decisions. For government to be appropriately transparent to the public, it must figure out how to be more transparent to itself.
I’ve recently begun to focus on how to foster internal transparency within my organization. My leadership wants more visibility into a host of operational information, including all relevant tasks, meetings, events, and formal staff opinions about proposed decisions. As it stands, most of this operational information is either recorded without structure (emails, documents) or not recorded at all (meetings, phone calls). In other words, it’s not usefully visible. I am one of many focused on laying the groundwork for a migration of these invisible operations into online applications that will automatically capture the underlying data in a structured, analyzable format—for example, an online task manager, public calendar, and opinion coordination system.
Face-to-face meetings, phone calls, and emails are indispensable, but to answer the current call for transparency we need nothing short of an e-government that formally recognizes a vote, decision, or any piece of information only once it is properly captured. This is not simply a matter of training federal employees to use existing Web 2.0 applications. Undoubtedly some consumer application concepts can and should be incorporated into government, but few organizations have figured out how to facilitate staff operations with services like Facebook and Twitter. This is also not simply a matter of duplicating enterprise information technology (IT) practices. Government can learn valuable lessons from companies like Amazon, Walmart, and Google about integrating IT into operations, but given its enormity, special constraints, and wide range of responsibilities, government faces different and tougher management challenges than any commercial business. Achieving e-government requires a 233-year-old behemoth to leapfrog most of the enterprise world and pioneer new IT management approaches.
As I’ve begun to experiment with e-government within a single organization in the Office of the Secretary of Defense (OSD),[177] I’ve had the privilege (or misfortune) of experiencing many of the obstacles firsthand. In the upcoming sections of this chapter, I briefly cover a few of these obstacles to provide needed context for the dialogue about government transparency. I then offer several guiding principles for overcoming them.
Please keep in mind that it’s impossible to generalize about the many disparate organizations that make up the federal government. My experience working on collaboration and knowledge management tools within an OSD bureaucracy probably best compares to similar efforts within other large bureaucracies in the Department of Defense (DoD), State Department, and Department of Homeland Security, and likely overlaps somewhat with efforts in other major federal agencies. But I have little to no idea, for instance, how the Federal Reserve, Department of Agriculture, or FBI operates. Even the military organizations within the DoD are notably different from OSD. (Rather than introduce confusion about the distinctions between OSD and DoD, however, I will stick with the familiar “DoD” acronym.) My experience is far from the entire story, but I believe it still offers important lessons for the general discussion.
As a final caveat, I will intentionally avoid the issue of what information should and should not be available to the public. My efforts are focused on creating the window, not deciding who gets to see through it.
Complexity Creates Opacity
Complex systems are fundamentally difficult to render transparent, and the U.S. federal government is arguably the most complex institution ever known to man. It is a massive, constantly evolving, highly interconnected bureaucracy. Winston Churchill said it best: the worst form of government, except all the others.
Our federal government employs roughly 1.9 million civil servants.[178] If all of them retired tomorrow, Uncle Sam would have to hire every U.S. college graduate for the next two years to be fully staffed again. This army of civil servants is augmented by more than 7 million contractors like me whose day-to-day responsibilities are often indistinguishable from their government counterparts. Add them to the count and the executive branch is more populous than Sweden, Austria, or Israel. There are also roughly 1.5 million people in the military, nearly 3 million workers funded by federal grants, and around 750,000 employed by the postal service.
This nation-size institution is made up of a labyrinth of organizations and processes that are continually reshuffled by competing and changing powers. DoD leadership often addresses a major challenge by shaking up existing offices and processes, and even in times of relative stability the gray area between organizational lines of responsibility is the source of constant debate driven by internal politics. Congress also has the power to modify operations through DoD-specific legislation. The DoD gets some interpretive wiggle room when it decides how to translate law into practice, until Congress decides to again intervene. The back and forth can be unending. If the dust ever settles, the next president is sure to kick it up again by demanding dramatic changes within the bureaucracy. It can take months, if not years, to translate a president’s vision into concrete changes within the executive agencies. Toward the end of George W. Bush’s second term of office, DoD leadership hastily finalized a flurry of overdue policy and process changes that were years in the making. And just a few short months later, the Obama administration promptly began to revisit many of them.
This constant churn combined with the vast size of government introduces uncertainty about who does what, which is a frequent problem in an institution that operates via consensus. For example, a Pentagon analyst may need up to two dozen organizations from various agencies to concur with a draft decision memorandum before getting it approved, and it’s next to impossible for her to know which specific person in each organization is qualified to review the memo on its behalf. So, the analyst sends it to the organizations’ central administrative offices, which reroute it to suboffices, which reroute it again, and so on, until the memo reaches someone willing to review it. Ambiguities surrounding who should review a memo can introduce substantial delay in the form of increased processing time, routing errors, or political infighting. I’ve received memos for review that were originally distributed weeks ago by someone whose office is a minute away from mine.
In the age of Amazon and Twitter, OSD’s memo routing process feels a lot like early twentieth-century telephony, when human operators routed calls. It’s unfair, however, to compare government to businesses and consumer web products. The DoD is not simply an online bookseller that can focus on optimizing and organizing a well-defined, recurring transaction. Its issues won’t reach a conclusion through haphazard, open communication (much less in 140 characters). It must manage a bewildering array of nuanced issues in an evolving political, legal, and diplomatic landscape; balance the competing demands of saving money and saving lives; and make long-term preparations for an uncertain future. This complexity has frustrated countless efforts to develop simplified, optimized work processes. To simplify the DoD’s byzantine memo-routing process might sacrifice thoroughness for efficiency, which can be an inappropriate trade-off given the gravity of the department’s sphere of operations and decisions.
Transparency thrives on simplicity. Our steady march toward larger, more complex government means that transparency will be an ongoing challenge. Consider the “Transparency and Open Government” memo itself: six months after President Obama signed it I conducted an informal poll within a DoD office. No one had heard of it.
Transparency, Meet Institutional Inertia
Establishing e-government requires recognizing IT as an enabler of operations and decision making. Fascinating examples can be found in companies like Walmart, which uses IT to automatically manage store inventories in response to sales data. When you check out with your cereal, toothpaste, and flat-screen TV at any Walmart store, headquarters instantly adjusts its distribution of those products accordingly. The company also knows to overstock stores on beer and strawberry Pop-Tarts before a hurricane, for instance, since pre-storm sales of those items tend to skyrocket.[179] Through information technology, Walmart makes customers implicit company managers. Your purchases determine its operations.
My organization, on the other hand, treats IT like an administrative assistant: it stores information, maintains calendars, and creates handy presentations. While the help is greatly appreciated, it is not considered integral to operations and decision making. This mentality is a vestige of the pre-Internet era when the computer was a miscellaneous toolbox that patiently stood by on your desk. Many people in government began their careers during this era, if not before it. The average age among civil servants is just over 46,[180] and about half of them are now eligible for retirement. The organizations at the top of the food chain, which set policy and operational procedures, are nearly exclusively composed of senior staff members. In my organization, which sits on top of all military acquisition, 46 is relatively young.
But this mentality is less a function of the individual employees as it is institutional inertia. Some of my colleagues demonstrate a formidable grasp of the power and future of IT. Formal organizations, however, tend to evolve more slowly than individuals. While many of us use Facebook and Flickr at home, the established standards at work are Microsoft Office, Web 1.0, and the C drive. People are willing to try something new independently and in their free time, but group work habits are hard to break, especially when they’re reinforced by legacy management processes.
And it’s not just about work habits. The administrative image of IT means senior analysts and their bosses simply don’t believe they should have to bother with it. They involve themselves only in important discussions and decision making, all of which occurs in the real world of face-to-face meetings and phone calls. Most of us are stuck with email, but if you’re important enough, even that becomes an afterthought. One of the first pronouncements of a newly appointed leader in my department was that he would not be personally checking his email.
People sometimes actually refuse to use helpful software on the grounds that it is beneath them. My organization, for instance, maintains an online calendar that displays meetings of general interest. In the past, anyone holding a meeting emailed or called the calendar’s administrator with the details. Because she was generally busy, she became a bottleneck to announcing meetings on the calendar. To remove this delay, the calendar was redesigned with universal access. The analysts calling the meetings, however, continued to contact the administrator directly. Though still frustrated by the lag time, they preferred not to bother with inputting the data themselves. Calendars are for secretaries.
Because we value IT but cannot commit to it as a medium of operations and decision making, we end up hedging—doing official business on paper while maintaining digital records online. The memorandum, the classic vehicle of decision making, is a prime example. A proposed memo is presented to the decision maker with a standard set of explanatory materials that are assembled according to strict protocols, from the ordering of documents down to the size and content of their footers and margins. This highly organized package is essentially the decision memo’s metadata, albeit on paper. The executive summary defines the purpose and context and highlights the key issues. The background materials include previous decisions, law, budget documents, and other official information that supports the proposed decision, as well as a list of the opinions of relevant government authorities: whether they agree, partially agree, or disagree, any comments they had, and whether those comments were incorporated or ignored.
After a paper package is dutifully assembled, it is archived online by scanning it in PDF format. If you’re a data geek, you winced already. If you’re not, put it this way: from a machine’s point of view, this PDF copy could be anything from a presidential memo issuing a nuclear attack to a Dr. Seuss excerpt. To find an issue of interest among these documents without making a bunch of phone calls you would have to individually read every memorandum rather than perform a five-second search within machine-readable text. All of the formatting, tagging, and text searchability of the information is lost in a scanned document. A scanned document can be translated back into machine-readable text, but the process is error-prone and often skipped. And our online archive does have a very basic tagging feature, but generally speaking, no one uses it. All eyes are on the paper package, as that’s what the boss will see. After the boss signs, the scanned memo is distributed and the rest of the package, with all of its carefully composed metadata, is never looked at again.
Storing structured information via structureless scanning is the e-government equivalent of burning the files. If the boss were to review the decision-making information online, his meticulous staff would ensure that all content was properly formatted, linked, and tagged for his benefit. This digitally structured package would then be archived online and, unlike a scanned copy, be amenable to search, mashups, data mining, and so forth. Something as simple as switching from paper to electronic signatures could yield dramatically more transparent operations and decision making.
But while the technology of electronic signatures and packages is simple, convincing and training thousands of legacy organizations to use the technology is not. The DoD CIO is actually planning to pilot an application that would manage the assembly of a decision document online, including collecting input from multiple organizations. This is a laudable step in the right direction, though it remains to be seen whether the pilot organization fully adopts the virtual document management approach or simply incorporates it as another layer that shadows the tried and true paper process.
In a similar situation, my organization has taken the latter route. The staff is so busy handling day-to-day issues that it never seems to have time to completely reboot its work processes. And given the comfort level with the established way of doing things, many simply don’t want change. Among those who do want change, there is disagreement about which change is the right change. Despite my leadership’s desire for increased transparency, institutional inertia holds us back.
Kaleidoscope IT: One-Off Apps Obscure Information
Imagine yourself as a senior official within one of the dozens of departments in the DoD. You care deeply about your organization’s mission, and you’re always looking for ways to improve its performance. One day, you’re told that a web application custom-built for your organization runs on outdated technology and will be obsolete in two years. You request funding to rebuild the application with newer technology, the funding is approved, and the 18-month development project begins. A few months later, someone approaches you from a different organization about building an application similar to yours. Because your organizations work with overlapping information, this person suggests that you collaborate on building a single application that serves both, thus expanding the information-sharing community and increasing internal transparency.
It sounds like a nice idea, but it would delay your progress while the requirements are developed for the new, combined application. Even worse, replacing your current effort to collaborate on another means you would lose your current funding, as it was specifically approved for the project in its original form. You would be forced to reapply for funding for the new, combined project and risk being declined. Your dilemma: continue on your path, guaranteeing your organization continued access to the application it knows, or agree to collaborate with another organization, incur delays, and risk your funding for the sake of experimenting with the idea of a larger information-sharing community. What would you do?
The Pentagon official who is the basis for this story very quickly opted to stick with his original plan. I approached him about combining efforts. He was committed in the abstract to exploring “synergies,” but outright merging our efforts would have been too costly and risky for him. This kind of tragedy of the anticommons happens everywhere, all the time. While it’s ideal for everyone to adopt a common framework that ensures shared standards, it’s usually too difficult and costly for any one group in an organization to take on the challenge of creating it. On the occasion when one tries, the minor network effects of an infant framework are typically not compelling enough for other organizations to be willing to make the necessary changes and sacrifices to join. It’s difficult, then, for a standard to ever take off.
The core problem is the fact that DoD organizations are responsible for their own IT solutions. Many of them have their own, internal IT teams. When authority is fragmented, solutions are fragmented. Most organizational decision makers don’t even think to consider a solution that could expand its reach beyond their niche. It’s beyond their scope. They’re not IT product managers looking to increase market share. They fund IT projects that support their particular mission.
As a result, the DoD is riddled with one-off applications. It’s analogous to commerce before mass production. If every county designed and manufactured its own brand of vehicle we’d have a lot of trouble driving between counties: some places would put the driver on the right, others on the left; city cars would be go-carts that top out at 40 mph; rural vehicles wouldn’t bother with turn signals or door locks.
In the same vein, government’s custom applications cannot communicate with one another, making them counterproductive information silos that reduce transparency. I might research the test plan for a helicopter prototype within one application and never know about additional information within another application. On the other hand, many applications store copies of the same underlying data, but these copies are not linked. When the helicopter’s cost estimate changes, for instance, each application’s data set must be independently updated. Inevitably, some data sets are not updated, meaning that an analyst will run into different cost figures for the same helicopter within different applications. Sometimes meetings devolve into determining whose data is correct rather than discussing the significance of the data.
The variety of unique needs among the DoD’s many organizations makes any standardization effort fundamentally difficult, but in some cases even easy opportunities for consolidation are lost. My organization developed its own collaborative calendar even though many other DoD organizations already use some form of public calendar. Multiple instances of meetings are passed back and forth across one or more systems, some up-to-date and others not. A meeting might have only a partial attendee list in one system and simply not exist in another. This fragmentation makes meeting management more tiresome and opaque than it should be. A universal calendar framework would enable consistent transparency into what meetings are being held and who’s attending them.
The lack of IT standards is a recognized problem in DoD and throughout government. Countless consolidation efforts have been unraveled by institutional inertia, the politics of agreeing on a standard, and the inherent difficulty of standardizing complex data sets. As a result, my experience with government IT has been a bit like looking through a kaleidoscope, where each organization has added its own, uniquely colored shard. Through this kind of lens, a piece of information may be inaccurate, lack context, or simply be invisible. It’s an unreliable kind of transparency.
A Market Focused on Proposals, Not Products
While some DoD applications are handicapped from the beginning by a needlessly niche mission, many are in fact designed to achieve some level of cross-organizational transparency. The Pentagon manages a web-accessible central repository of cost data, for instance, with the stated purpose of providing government analysts with complete, timely, and accurate information about the costs of major military acquisitions. It sounds like a perfect example of a web service providing internal transparency. Unfortunately, the user interface is so clunky and the data so poorly structured that no one uses it. Even the analysts in the office that manage the repository don’t use it. When they need cost data, they ask the people who input the data into the system to email it to them directly, sometimes only days after the very same data was submitted to the repository.
Many of the one-off apps we create are not used enough to justify their existence. This in itself should not be blameworthy. Most commercial software products are flops too. In a free market, however, flops die. In my area of the DoD, flops are sometimes ignored or even expanded, because decision makers often do not have the right type of information to judge the success of an application. Understanding why requires understanding how the government IT market works.
When a government organization needs an IT solution, it will usually release to the public a document called a Request for Proposals (RFP) that outlines its specific needs. Companies respond to this solicitation with write-ups of their proposed solutions and costs. The organization evaluates all proposals and picks a winner. The idea is that when companies compete for the government’s business, the government gets the best value. The process is also meant to reduce the chance of corruption, as government officials cannot simply pick any company to do a particular job. Instead, they must choose the winning proposal based on predefined cost, performance, and schedule criteria. It’s a good model, in theory.
There are, however, a number of well-known problems with the way this model plays out in practice. First and foremost, it puts the government organization in charge of identifying its own technical needs and, often, specifying high-level solutions. But an organization with a nontechnical mission like policy-making or contract oversight is not especially qualified for this role. And though the IT companies that develop software for the government may themselves be qualified, the RFP process rewards those who provide what the government client requests, not businesses looking to solve unidentified root problems.
A nontechnical government colleague of mine recognized a few years ago that his organization did not manage meeting notifications well and wanted a new system built. Because the organization’s in-house development team was occupied with an ongoing effort, he contracted an outside IT company. Unfortunately, given his lack of technical expertise, he did not know to specify that the system should interact with existing applications that manage related information. The system’s resultant isolation meant that its data quickly became out of sync with those more established applications. Lacking any user interface design experience, my colleague also did not recognize problems with the interface that inevitably frustrated early users. Today the application is replete with out-of-date information and usage has tapered off. My colleague cannot be blamed for his lack of technical or design knowledge, and the IT company cannot be blamed for developing the product as requested and approved by the client. The failure lies with the RFP process, which puts a nontechnical user in charge of requirements. If the consumer world worked that way, you’d be expected to dream up Google or Facebook yourself.
Another problem with the RFP process is its complexity. Much like tax law, the legal requirements of writing and responding to proposals have evolved over the years to close loopholes, meet quotas, and stay consistent with laws enacted by Congress in its fervor to improve the system. As an IT company, participating requires substantial time and specialized knowledge. This effectively shuts out both small companies who can’t afford the overhead of writing the proposals and highly tech-oriented companies that don’t specialize in paperwork.[181] The companies that do participate typically have built their business model around writing winning proposals, which has little to do with creating worthwhile applications.
In my experience, the company that wins the contract often has an existing relationship with the organization that released the RFP, which also has little to do with an ability to create worthwhile applications. Naturally, a company with experience supporting the government organization will have a better sense of the type of proposal the organization is looking for than will an outside company that knows nothing more than the high-level description of technical requirements in the RFP. The inside company knows how the organization thinks and works and the nuances of its needs. After winning the contract, this inside company expands its IT services within the organization and becomes further entrenched. Over time, the government organization and its entrenched supporting company might form a nearly inseparable bond. The dividing line gets blurry when onsite company personnel actually influence how future government RFPs are written.
Companies like this are called “government contractors” because they specialize in supporting the government. They hire government retirees, attend government meetings, and have staff members on-site in government offices. In some cases, there is little actual difference between them and the government. These contractors’ strong incumbent advantage and experience with the complex RFP process virtually guarantees that they will continue to win government IT contracts, making the government market a poor choice for innovative startups. While young companies like Google, Facebook, and Twitter dominate the Web, only one of the top 10 government IT contractors[182] was founded after the 1960s:[183] Dell, where we buy our computers, not our software. Despite the government’s wide variety of IT needs, half of all spending in the civilian technology sector finds its way to one of these 10 companies. It’s a market dominated by long-standing government–contractor relationships, not IT products that speak for themselves.
It’s also a market not driven by user-level supply and demand. On the general Web, we gauge the value of an app through the feedback of others and direct experience. Since proposals are often not tied to existing products, however, the government must commit to paying the costs of building a solution (plus profit) before anyone can see or use it. Trying to gauge the value of an app from a paper proposal is a bit like trying to guess how good an apple pie will taste from a recipe.
As a result, the government is often more or less blind in determining how useful and user-friendly an application will be. And rather than “take a peek” with a pared-down beta version, my organization tends to initiate multimillion-dollar development efforts based on the paper proposal alone.
Once an app is launched, the blindness is often maintained by failing to collect rigorous usage metrics. The company that manages one of my organization’s primary web applications only records the number of people that log in. It’s a motley app with tools for everything from document preparation to cost analysis. People in my office regularly use one small feature buried within the app, a simple form that we fill in, print out, and incorporate in the memo packages discussed earlier. Most of the more sophisticated and costly tools within the app are poorly designed and left untouched. Our use of the form helps validate the entire app, however, since a login is a login.
Many apps I work with do not seem to collect any usage metrics at all. If they do, they’re not discussed. Because decision makers generally do not use the applications themselves, with little to no usage data they tend to believe the new app is a success. After all, they chose the solution in the first place. As new IT needs arise, they naturally look to leverage previous investments by modifying an existing app, regardless of whether anyone is actually using it.
This lack of emphasis on user adoption, combined with the fact that the government RFP defines both the problem to be solved as well as the desired solution, drives IT contractors to be more service-oriented than product-oriented. A product-oriented company focuses on end-user value. A service-oriented contractor, on the other hand, is incentivized to simply find work. It doesn’t matter if that work produces an application that gets used or collects dust; the company gets paid either way, as long as the app meets the spec defined by the government. Outright creating additional work is profitable too. A close friend works for a company that intentionally develops a government application to require dedicated, company software administrators to keep it operational. The yearly profit on charging the government for these staff hours is a lucrative part of their business model. Making a simple, standalone product would mean less profit. To a certain extent, it makes good business sense to develop a solution that is not user-friendly.
The government IT market too often rewards incumbent contractors with paper proposals that check the requirements boxes rather than applications that employees want to use to get the job done. In the general consumer world, where companies fully understand that software lives or dies based on its usability, the number of failed products clearly demonstrates that usability is difficult to achieve. Naturally, when usability is not properly incentivized, the resultant apps are frequently clunky and unhelpful. If managing many social networking and web accounts seems annoying, try working regularly with dozens of apps that are so confusing you feel like you have to relearn them on every visit. People tend to give up. When a new government app is launched that promises to make our work lives easier, my office doesn’t applaud, it groans. Rather than even bother figuring out the clunky app, they stick with what works: email, Microsoft Office, a few helpful websites, and the C drive. Without new IT solutions that are both pleasant to use and helpful for government workers, these workers will continue to operate as they always have, and transparency will be just as difficult tomorrow as it is today.
Framing the Window
Each of these challenges reinforces the others. The pre-Internet mentality of the computer as administrative toolbox underlies the pursuit of one-off IT solutions, and the one-off solutions reinforce the toolbox mentality. The size and complexity of government creates a disparate, complex web of authority, making it difficult and somewhat unnatural to seek out government or even department-wide solutions. The lack of standards, in turn, drives complexity in government. Because one-off solutions are rarely optimized for usability, people tend to avoid them and fall back on older, more reliable methods, like emailing files back and forth, which maintains the pre-Internet mentality regarding IT. And when the dysfunctional IT market promises helpful tools but never delivers, that mentality seems justified.
These challenges, then, cannot be addressed in isolation. And they are not the only ones. I didn’t even discuss the wide variety of regulations, for instance, covering everything from security to the environment to equal opportunity, which constrict a problem solver’s range of motion, sometimes rightly and other times in silly ways. There are no easy answers or step-by-step processes to addressing all of these challenges. There are, however, a number of principles that can and should guide our e-government and transparency efforts. Here are a few to consider.
Downsize or Eliminate Organizational IT Development Teams
Many federal organizations, including mine, have in-house IT development teams for smaller projects that aren’t contracted out via an RFP. This leads us down the path of custom, one-off solutions, both because we have the dedicated resources to build a custom application and because those resources are focused only on our specific requirements. My organization’s IT development office should be replaced by a smaller corps of in-house technologists who have intimate knowledge of and experience with the organization’s goals and needs. These technologists should focus on finding existing solutions and interoperating with partner organizations, not on building organization-specific tools. Keeping internal technologists is vital, as too often the process of nontechnological clients defining the problem for contracted technology providers to solve ends up producing short-sighted solutions.
User Analytics
The Federal Chief Information Officer (CIO) should create a standard usage analytics kit that must be installed on all federal web applications. The kit would collect standard app usage metrics like number of daily and monthly users, user loyalty, and view counts for all pages, and would also offer users a standard method for providing feedback on an app. Though there are a wide variety of federal apps with user bases of different sizes and different intended usage patterns, these metrics would provide some basis for comparing apps across government agencies. The metrics could serve as a basis for eliminating or expanding existing solutions that are clearly behind or ahead of others in their respective categories. The CIO might also pilot an IT procurement process that ties compensation to these metrics rather than development cost, which would incentivize companies to produce apps that employees will actually use.
IT Transparency
In June 2009, the government launched an IT Dashboard on http://www.usaspending.gov that makes available a variety of information about government IT investments, including a description of the investment, the prime contractors and monthly updates on cost, schedule, and performance figures, and agency CIO ratings. This is a great example of holding the government accountable to the public through greater transparency. I would like to see it expanded, where prudent, to include things like subcontractors, user analytics, underlying technologies, informational and operational interdependencies, reused code components, and even demos. This would afford greater transparency into how the government is using technology, allowing technologists, whether for profit or simply for the public good, to identify redundancies across government applications, opportunities for adoption of existing enterprise solutions, or just plain inefficient or poorly designed solutions. The government would be wise to both invite and capture this kind of feedback so that the collective dialogue builds upon itself.
IT Products, Not Projects
This dashboard could help the government initiate fewer one-off IT projects and begin reusing existing solutions. As government, industry, and citizens tag, group, and comment on government’s IT investments, the dashboard could evolve into a Federal App Catalog. Aided by a growing body of helpful metadata, government organizations could browse the catalog for existing solutions that partially or fully meet their needs. The federal CIO could facilitate this process by identifying its “best-of-breed” picks within functional categories like public calendars, workflow tools, and document management systems. Eventually, shopping the catalog could become a formalized, mandatory step in pursuing a solution before an organization decides to initiate a new IT project. The organization could include the public in this step by sharing its requirements—not just through an opaque, formal document, but also by having government officials and staff members explain their needs in plain English via videos and open discussions—and soliciting shopping recommendations. Ideally, the CIO’s best-of-breed picks would evolve into a suite of standard federal applications. This would greatly simplify government’s information management and, in turn, increase operational and decision-making transparency.
Set the Tone at the Top
The federal government is too large and varied to be changed all at once. In this situation, it makes sense to initiate change at the top to serve as an example for the rest of government. The federal CIO could focus resources on integrating IT into White House operations and decision making. Even something as simple as having President Obama electronically sign laws, budgets, and executive orders would be substantial. Any e-government measure adopted by the White House would be a forcing function as well as an example for the rest of the executive branch. If the White House reviews packages exclusively online, for instance, then the executive agencies will have to prepare those packages online, in which case they might as well adopt online package processes.
Bottom-Up Change Through Young Technologists
While top-down change sets an example, it’s generally more effective at adopting existing innovations than driving innovation itself. Innovation tends to be bottom-up and fueled by fresh minds. Government needs to recruit young, talented technologists to begin and later lead the transition to e-government and greater transparency. Many young people, however, are turned off by the lack of responsibility in most entry-level government positions. One notable exception is the prestigious Presidential Management Fellows (PMF) Program. Graduate students interested in civil service apply to the competitive PMF Program to spend two years working in challenging developmental roles across multiple federal agencies in four 6-month rotations. Many go on to lead distinguished careers in public service. It’s a fast-moving career track with the cachet to attract top-notch graduates. A similarly prestigious program for technologists interested in transparency would instantly create a fresh cadre of on-the-ground eyes and ears to both report back to leadership as well as play roles in transparency initiatives and pilot applications. It would also plant the seed for tomorrow’s technology and transparency leadership in government.
Conclusion
While transparency clearly requires operational changes within government, the system does not need to be completely reinvented. I opened with the boomerang email as an example of the lack of internal transparency. Yet the fact that my question can pass through dozens of relevant people in different parts of the country and, not finding an answer, naturally make its way back to me without any top-down control is also a remarkable testament to the inherent order within government. E-government will sometimes require brand-new, web-inspired approaches, but many other times it will be a matter of transitioning existing, well-ordered “analog” processes to a new medium. These processes were engineered before the web medium introduced an entirely new notion of transparency, where information is expected to be instantaneous, granular, accurate, complete, and universally accessible. Government’s current lack of transparency by this standard is not necessarily an explicit choice. In many cases, it simply has not yet had a chance to catch up with the new definition.
Figuring out how to “catch up” an enormous, complex, legacy institution and make it transparent to 300 million citizens will be an ongoing effort. The call for a more transparent government has no final solution, only a general direction against which incremental improvements can be measured. Fortunately, the pace of these improvements should accelerate, as transparency efforts benefit from a powerful positive feedback loop. When government becomes more transparent, more people have a greater understanding of its operations and the challenges it faces, including the obstacles on the path to greater transparency. These additional, diverse minds are then primed to help clarify and overcome these challenges. Transparency is more than a vehicle of accountability. It is a platform that educates and empowers citizens and businesses to offer better solutions for government. Better solutions lead to greater transparency, which further empowers those outside government. The natural conclusion of transparency is a blurring of the line between government and the governed, when the window becomes so clear that it’s difficult to tell who is outside and who is in.
About the Author
Since February 2009, Tim Koelkebeck has focused on facilitating collaboration and increasing transparency within his department at the Pentagon by transitioning its analog work processes to web applications. During the preceding two and a half years, he was a senior analyst fully immersed in the day-to-day operations of the department, which oversees the acquisition of major military systems. Tim was introduced to the Government 2.0 community in November 2008, when he and two friends won the first Apps for Democracy contest hosted by Vivek Kundra, then the Chief Technology Officer of Washington, D.C. Tim received an Honors B.A. in computer science from Harvard, where he focused on the intersection of computation and neuroscience. He reengaged this line of thought in 2008 by launching MyType, a web app experimenting with personality-driven recommendation technology.
[177] OSD is composed of the civilian staff organizations that work for the Secretary of Defense. It is distinct from the military departments like the Army, Navy, Air Force, and Joint Staff that report to the Secretary. All of these departments and organizations are collectively the DoD.
[178] All figures are from Paul C. Light’s research at NYU in 2005, which the Washington Post nicely profiled at http://www.washingtonpost.com/wp-dyn/content/article/2006/10/05/AR2006100501782.html.
[181] Government does set aside a small percentage of contracts for small businesses and other under-represented companies. These quotas introduce their own problems.
[182] In terms of civilian, not defense, revenue.
Get Open Government now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
