Posts Tagged ‘Open Source for the Government’

3 Flaws in the Government RFP Process

Posted Thursday, July 31st, 2008 by Jason Hull

I’ve recently discovered Blair Enns’s Win Without Pitching website (thanks to David Robinson of Birch Studio Graphics for pointing me to the fantastic FunctionFox seminar). The main theme of Enns’s site, as I have gathered, is that proposal writing is, for the most part, an ineffective way for buyers to purchase specialized services, and for sellers of specialized services to prove their value. It is ineffective for buyers because the request for proposal (RFP) process often doesn’t allow the buyer to truly find out if there’s a fit between the seller and the buyer, and it attempts to normalize factors between competitors to create an apples to apples analysis. As Enns points out, what if you’re a pomegranate? You don’t want to be compared to an apple because you’re NOT an apple. This is why proposal writing is ineffective for providers of specialized services, because proposals which normalize factors often then reduce the reason that you’re specialized in the first place. A filet mignon prepared by Bobby Flay (or any other Food Network denizen) is not the same as beef tips purchased from Ponderosa Steakhouse. Yet, without the opportunity to engage in a conversation, the filet mignon is often reduced to the level of the beef tips in comparison.

So, how does this impact the largest buyer in the free world, the U.S. government? Less than it should. Check out the FedBizOpps website and see how many open proposals are available for a seller to peruse. As of the evening of July 30, there were 6,736 requests for proposals with expected response dates of July, 2008. If the process is flawed, then those flaws replicate themselves many times over on a regular basis.

Here are three flaws that I see in the process:

1. RFPs seek to mitigate the wrong risk. As a buyer, I want to know if I pay for something, then I’m going to get my money’s worth out of it. The risk i want to mitigate is that the provider doesn’t know what they’re doing or provides me a bad product and I can’t take it back for a refund. However, many RFPs seek to mitigate cost risk first and foremost, looking for price reductions, best offers, and fixed price bids in situations where expected outcomes are unclear or not well-defined. The mantra “nobody ever got fired for hiring IBM” seems to come to mind (though, to be clear, there are many cases where IBM should get the work), and that low cost bidders will often win. The risk that buyers of specialized services should seek to mitigate is fit, and by normalizing on other factors (are you CMMI qualified, give me your three best references, etc.), the government is trying to indirectly answer the question of fit. However, process gets in the way of answering that question…

2. The strict adherence to the process makes meaningful conversations difficult. Once a RFP is published, then communication with the actual customer is not allowed. Questions must be asked via the contracting officer, who then relates them to the customer, who then answers the question for everyone to see. This process creates a game of “gotcha” because a potential provider of services doesn’t want to ask the “a-ha” question that will reveal the true nature of the need and alert competitors to the same need. As a buyer, I’d rather get the deep, insightful question from one seller that reflected higher skill and continue conversations with that seller to explore fit. It seems inimical to then take away the benefit of that thoughtfulness by sharing that information with all other potential sellers. Yet, that’s what the government regularly does. I understand that this is a question of access, and with potential sellers often numbering in the hundreds, it’s a tough problem to solve. Still, encouraging more real conversations in the process would help to address the issue that the strict RFP process tries to mitigate through its normalization efforts.

3. The vendor qualification process is not rigorous enough. To become a registered government vendor, you need to follow a few steps: a) Register as a legal entity (corporation, LLC, partnership, DBA, etc.); b) Get an EIN; c) Get a DUNS number; d) Register in the Central Contractor Registry (CCR). As a result, there are, as of July 30, 2008, 465,684 active registrants in CCR. Increased viable competition for the government is great–it gets more value for the taxpayer dollar. However, increasing the noise-to-signal ratio does exactly the opposite. It’s why contracting officers hate full and open competitions–they have to read volumes of non-competitive responses from people who think that throwing a proposal over the wall is the surefire way to success. If contracting officers knew that they would get responses only from companies who had a reasonable probability of being able to do the work, their job would be easier. Put another way, if contracting officers knew of the fit between client and provider, their job would be easier. Tightening up the registration requirements would be one way to help this.

I believe that the government RFP process is flawed. It often puts out interpretations of needs and opens it up to the masses, putting the decision-makers in a tough situation of trying to discern differentiation from dozens, if not hundreds, of potential suitors. As a result, the RFP process tries to normalize as much as possible to reduce decisions down to a few factors, and, where possible, down to one–price. It does not address the issue of fit and localizes variables rather than finding global optimization. The process leads to over budget, out of scope, and missed timeline performance. By trying to be fair to EVERYONE who wants to participate in government contracting, the government is not fair to the most important stakeholder of all–the taxpayer.

What Do Your Business Tags Say About Your Company?

Posted Tuesday, July 22nd, 2008 by Jason Hull

Eric’s R&D project is HighTechCville, a website aimed at helping people identify technology communities of interest in the Charlottesville area. The engine behind the website pulls in information about people and companies from disparate sources such as the Neon Guild, the Virginia Biotechnology Association, LinkedIn, and personal and business web pages. It then performs cluster analysis on the people and organizations to determine communities of interest.

Naturally, I was curious about what our website (and appurtenant profiles) said about us through the eyes of HighTechCville. Our tags are Ruby and Rails, which is not surprising given the provenance is from our entry on the Working With Rails website. I decided to dig a little deeper to see the story that our website told to the search engines. The ten most common search terms leading to our site for the past three months are as follows:

apple itouch
itouch calendar
new pda
textmate clone
dedupe itunes
textmate windows
itouch
new apple itouch
open source connections
itunes dedupe

Of the top 10 terms, only 3 really relate to what we do. As an aside, I’m sure that simply posting these terms in this blog entry will only solidify the results. Naturally, this concerns me, as the people who need what we provide obviously aren’t coming to us via the website.

How should we tag our business? I think that our work falls into the following 5 broad categories:

Open Source for the Government: The government, as a steward of taxpayer money, has a responsibility to provide the highest value products and services for the lowest price possible. Paying license fees for commercial applications that can be performed equally well (and often better) by open source applications does not fall into the category of good stewardship. Furthermore, the government could and should own as much source code as possible to encourage broader and higher quality competition for subsequent work. This work takes two vectors–leveraging existing open source products and applications (and hopefully contributing back where possible) for government work, and helping government agencies learn the lessons of development in open source communities to improve their development methodologies. (Note: opensource.gov, if it was up to us, would encompass much more than just translations and analysis of open source media for government policy and implications) We feel that these lessons also segue well into our second business tag…

Build Better Software: Our developers are fascinated by the craft of software development. While not pedantic to the point of being obsessed about process for the sake of process, we do believe that software development is an art that follows the rules of Pareto optimality. In terms that undersell the definition, 80% of the work in software development is plumbing, and 20% is “secret sauce.” We leverage and create tools which minimize the amount of human time necessary to get to the point where developer skill has the maximum impact. This covers the range of the software development life cycle, from ensuring that the right questions are being asked to determine a pain point we are to actually solve (often rather than the one that is first described to us) through to code coverage metrics and unit testing to automated test scripts before deployment. We also are avid proponents of Agile Development methodologies during development to ensure that our skills are applied to the right problems at the right times to maximize customer value. Agile Development involves rapid prototyping, which helps us help customers to move…

From 0.1 to 1.0: We assist companies who have a great concept to get through prototyping phases and to develop a working application that is an embodiment of their ideas. Often, this occurs when companies successfully raise an initial round of venture capital financing and now need to bring a product or service to market to generate beginning sales or beta customers. They must demonstrate working features for customers to get orders for the full product, and often do not have the team put together to meet the aggressive deadlines of their investors. We quickly embed ourselves with the business and deliver on the highest priority features to facilitate rapid sales cycles. Of course, we don’t just focus on version 1.0, as we specialize in…

Web 3.0 for the government: The government owes it to citizens to be as transparent as possible, and it has started to achieve this in limited areas, such as the TSA blog and the Charlottesville Albemarle Airport Authority blog. However, this is only a small step in the right direction. Not only does the government need to reach out more to its citizens in a proactive manner and engage them (note: the TSA is experiencing the problem of engagement, discussed here. They could use a few hours with the Rimm-Kaufman Group.) Making the plethora of information available more user-friendly and accessible for self-help is a good start. The government also has another, more somber need for Web 3.0. No matter how one defines it, the United States is locked in a war on terror against unconventional enemies who are very smart, very adaptive, and very technology savvy. We need to maximize our usage of Web 3.0 technologies to get in front of enemy decision cycles and interdict their actions. Our intelligence agencies collect far more signal and human intelligence than our analysts can sift through, and throwing more analysts at the problem is not the answer; technology is the only way we can identify what analysts should take a deeper look at.

Location aware applications: One specific area of focus of leveraging Web 3.0 capabilities is in location aware applications. These applications provide context based on geographic location and temporal activity to isolate information specific to a given area of geographical interest. Identifying not only where information is tied to, but also who is interested in the same location helps quickly automate creation of communities of interest based on the specifically identified locus. Through the use of geographical information systems, users can overlay and share appropriate information in a visually intuitive manner that helps others quickly grasp the salient points to be shared. This can also be used to plot information over time (time is, after all, another point on a geographic grid) for users to see quick patterns emerging.

Clearly we have a long way to go to get our website to tell the story of our business. Maybe a pleading letter to Matt Cutts is in order.

How do you perceive us? Are you surprised at the tags we have self-identified? What tags would you use to describe us? What tags would you use to describe your business?