Is Cooperation Possible? Funding 2.0: A Model for Multi-Agency Funding for Gov 2.0 Initiatives

Certainly, I am not fantasizing magic filled utopia where happiness radiates all around and unicorns slide down rainbows into pools of blueberry jam, but let’s be realistic about the situation here. We are living in a time of shrinking budgets and disappearing funds with no relief in sight. The key is doing more with less, and that really means more cooperation with less money. Web 2.0 technologies generally do not cost a lot, and sometimes very simple projects can have a large impact. Think Google maps and the idea of getting directions: simple idea, huge impact even without considering all the other “unintended” ways people have developed to magnify the benefit of its usage.

There must be a way to get multiple agencies within the Department of Defense (DoD), the Intelligence Community (IC), and other Federal/State/Local Agencies to collaboratively fund small, innovative projects for the Enterprise community. We know the benefits of collaborative development and information sharing, but it is time to make more happen with distributed financial contributions. In effect, the transition to web 2.0 capabilities must take on a “funding 2.0’ model to provide for them. This article intends to develop a vision of the framework for accomplishing this but first we must start with some considerations needed to frame the issue.

Shifting Funding into the Web 2.0 Paradigm
How is Wikipedia funded? Wikipedia is a great resource that millions of people read and contribute to every day, but it exists as a non-profit service. It is funded by donations from the user community to continue its operations and expand our global pool of knowledge. Even think of the wiki model in creating an article: three people each contribute a sentence and the whole world has a paragraph. When people collaborate and contribute in this fashion, everyone benefits with less overall effort from any one individual.

Looking past legal requirements, “color of money”, and other artificial barriers our bureaucracies have erected, we consider the same model, where Agencies, not individuals contribute financially to produce and maintain capabilities for the Enterprise. In this aspect, the cost burden is shared by many for an individual cost far less then what anyone could afford on their own. While this idea is simple enough and sounds great, there are several problems which we need to consider; the first of which is the problem of control.

We’ll Just Create our Own
If one agency does not like the product, politics, or lack of ownership in a capability, a first reaction is just to begin standing up their own product without consideration of the costs. This action is then followed by a realization of the cost, which is then proceeded by a generous heaping of hemming, hawing, and stalling. Meanwhile, valuable opportunities have been wasted with no progress made.

This need for centralized control is a devastating hurdle to getting anything done. Initial calls for developing the ‘governance process’ seem to be a popular time sink where the benefits of such activity hardly justify the means of pursuing it. The Internet is a sort of controlled Chaos where “ownership” is decentralized, or distributed amongst many interested parties. No one “owns” a Wikipedia article, yet there are many who have taken responsibility for a while in keeping a few up to date. The Twitter community has developed social norms within the system, including appropriate methods of tagging data and communicating with other users. These standards of conduct occurred within the context of the system, but they are not confined by any overarching organization to have created or enforced them.

Sometimes political infighting make it more convenient to go the “our own” route for purposeful avoidance of another bureaucracy to deal with. Another response is that the particular service or tool does not meet 100% of the organizations needs. Others will argue in long winded paragraphs on how they are unique and must therefore spend money on such a system. Yet another trend also exists: let’s just use their system for free, and no money will come out of our budget.

The Consequences of “Free”
From E-Bay auctions, sharing information with the public through Facebook and Twitter to using Google Map mashups to display the locations of government jobs on usajobs.com, the US Government is just breaking into what they can do with the current social media and other Internet based capabilities. In the case of the DoDIC, using “public” sites to conduct business outside the normal public release of information becomes a slippery slope in protecting what should be shared and what should not. For “Official Use” and other non-public data, taking the same commercially available technologies and using them in house is well worth paying for. One such example is the Defense Collaboration Online (DCO) capability provided by the Defense Information Systems Agency (DISA) for the Enterprise. DCO has chat, Instant Messaging, webinar with audio and video capability, application sharing and other features using commercial technologies.

In the case of DCO, DISA was funded to provide a collaboration capability to the enterprise. It’s also important to note that DISA is a joint agency and requirements were not developed in a DISA vacuum. Now let’s look at the UGov mail debacle where an Enterprise wide secure email service was being provided for multiple users across the DODIC as part of the Intelink suite of capabilities. Users could remotely access email and many used it on travel. It was a constant in times of job/position/agency flux, like a universal address to maintain contact continuity. Since it was announced that the capability was being deprecated, many have struggled to understand its true impact and how to subvert the damages. Here was a “free” service that people depended upon that was taken away by the singularity of a control levied by the power of the purse. Since no other stakeholders had a financial share in the matter, political argument and support lacks the same punch and force when dollars have been set forth in securing its preservation.

The Monolithic System Paradox
Just because it is an “Enterprise” system does not mean everyone has to use it. Building the end-all to end-all systems and expect everyone to use it is the wrong approach. We are in an information age of choices and tools limited by our imagination. Sometimes we can get caught up in the mega-system where competition to improve and stagnation occur. To say that there can only be one “Wiki” service, for example, is folly. There might be a better product, service, or way of doing business that would be left unseen or discovered if we rely only on what we know. Innovation can occur when someone decides to forego the status quo, take on a vision to do something better and make a good run at it.

Yet, it is a question of balance and a point where duplication of an existing service reaches a saturation point where more of the same begins to rapidly erode the utility of technology. Competition encourages winners to emerge from the heap and pushes the few that remain to adapt and improve to keep alive. It’s a healthy and normal part of technology to have new technologies emerge, sometimes born on the backs of the old or existing, or for some to die away. Part of the problem is getting rid of the dead wood before it comes to fruition. In this case, the idea of how we reward success needs to be readjusted.

Rewarding Failure
Something almost seemly contraindicated to an organization is Rewarding Failure. We talk about rewarding risk, but it seems more like we reward “successful risk” and a culture of punishing failure (unsuccessful risk). Also, in this aspect, great bureaucracies have been created to marginally stumble forward in small conservative increments and do not allow natural market corrections to occur. Example: it seems like getting 10/10 software programs completed is a success when in fact, only one of those ten were really what was useful in the end. Instead of letting 9/10 “fail” (because that would have been a waste of tax payer dollars) we use the system to complete programs, reward individuals for their success, and spend 100x more than necessary in the end. As we lead into Gov 2.0, we need to understand that the normal mode of the marketplace is to “fail early and often.” It seems strange that we need to invest in failure, but how else are we to discover what works in a time frame that matters?

Funding 2.0: Collaborative Funding Framework
There are four main components to the collaborative, multi-agency funding and continued support of Enterprise capabilities as listed below:
1. Marketplace for innovation
2. Funding arbitration and agreement
3. Implementing the project plan
4. Securing funding for continued support

Each of these areas is vital for a different purpose in supporting collaborative funding. As we examine each of the components in more detail, there should be a lot more to be explored and that the purpose of this document is to begin the journey towards a better way of doing business.

Marketplace for Innovation
Finding projects or like minded people to develop them can be a challenge. Places like DISA’s Forge.mil, a secure Open Source Community using the same technology as Sourceforge behind the firewall is collaborative software development environment and a potential place for establishing a market. This is not to say that only one market should exist, but if a few major areas should be present, making use of the best tools within the context of the projects to connect interested parties together. Intelink’s Intellipedia could use a wiki category tag to mark projects, or they could be suggested via their microblogging service, Chirp. The point is that projects need a space to develop, sell, and gather interested parties to them. There needs to be a mechanism for communicating the total cost of a project and way for an interested party to contribute/pledge funds towards it.

Funding Arbitration and Agreement
Once parties have found a project they are willing to buy into, their must be an agreement established to take care of the legal issues that might surround potential funding. Resolving the ability to transfer funds via a Memorandum of Understanding or Agreement (MOU/MOA), year funds expire, or not being able to use Operation and Maintenance (O&M) funds on a Research Development Test and Evaluation (RDT&E) projects needs to be understood up front. Once an Agency has “pledged” finances, they cannot pull them back; it needs to be a good faith contribution.

Implementing the Project Plan
An integrated project plan, showing who pays for what and when needs to be worked out between the parties paying for the project. It may occur in phases or co-mingled, but the success and what each party expects to get from its contribution needs to be agreed upon before getting too far along. Limiting the scope of the project and setting achievable metrics, while excellent parts of any project plan, are critical in setting the expectations of each stakeholder as well as the criteria for success.

This should not be about controlling who has access. If it’s for the enterprise, then anyone can use it. If the three parties want a capability for themselves, that is their business, but be amiable to other interested parties who might want to buy-in to what is being done, else we are back to the “I’ll start my own” problem. If an outsider wants 300 seats, figure out what that costs and use the Funding Arbitration and Agreement process to make it work. And while it may seem like a commercial, all paid supporters of the service should be displayed in some fashion: Brought to you by Agency X, Y and Z. Recognition is important not only because it allows those that have funded the project to identify themselves with the innovation, but it also attracts interested parties to apply funds toward projects they would like to be known supporters of.

Securing and Funding Continued Support
Projects must receive annual sustainment contributions, and they will be limited to the extent that the acquisition laws allow. More importantly, a yearly refreshment of the coffers revalidates the importance of the product being provided and allows new contributors a chance to apply funding toward the capability baseline. This would allow an agency to support the sustainment as well as develop additional capability, like an improved mobile interface for a handheld that they are specifically interested in. The normal POM cycle is every two years and technology moves much faster than that. Coordination for development of unfunded or underfunded requirements could be coordinated into mutually beneficial timelines that meet the needs of all parties interested in developing and fielding capabilities.

With all contributions, 50% must go to product sustainment and the later to enhancements if that is the wish to develop. Sustainment might include additional servers when expansion is necessary, but this simple practice has a responsibility in keeping the product up and running. The actual percentages or sustainment contribution amounts could be individualized in the Funding Arbitration and Agreement process as part of the known “contract” each party agrees to within the context of actual project. Once the sustainment limit has been reached, the funding can be reallocated to better suit the needs of enhancement as more funds are available. In this aspect, if Agency X contributes to the fund after sustainment has been met, their required sustainment contribution could proportionately reduce the overall burden to all parties involved, freeing up more cash for innovation. If nobody wants additional capability, everyone’s cost is simply reduced, saving money in the end.

Final Thoughts
The mere fact that transfer of funds between agencies can be a difficult process presents the first barrier to overcome. For instance, the Navy wants to use Project Forge, a private instance of the otherwise free and open Forge.mil. They cannot transfer money to DISA for their own Project Forge space to work in until they have a valid MOU worked out. The very fact that both are within the DoD and cannot transfer money without additional effort directed into a bureaucratic process seems silly, but it’s the state we are in and must contend with. The POM cycle moves in two year windows whereas technology moves at a much faster pace, making technology current at the beginning of the cycle obsolete at the end. This makes future planning and programming of funds very difficult through the think fog of technological evolution.

We need to work smarter, not harder and I realize that cooperation will not happen overnight. But if we want to reduce redundant efforts and make progress quickly, this is a means to an end that is not only achievable; it can become a working model to field the right kinds of capabilities in a timeframe before they are made obsolete. It does not have to be constrained by rigid rules and procedures, but can evolve organically as more people try to work together. More importantly than how it is done is the initial question of why we need to build a Funding 2.0 way of doing business. I think the answer to that is simple: our current processes are archaic, slow to respond to the pace of technological change, unable to keep up or maintain velocity with our adversaries, and are a wasteful means of fielding inadequate technologies before they are rendered into antiquity.

Disclaimer: This entire article represents the author’s opinions only and mention of any product or brand is for illustration only and not an endorsement.