Government Contract Recompetition

Welcome to Part VII of our government program offices series on contract recompetition. If you haven’t already, go back and read the introduction to the government program offices series to learn more about how Jama Software supports government program offices and more about me and my qualifications. You can also read Part I, where I discuss the development of the RFI/RFP and we got approval to release the RFP, Part II on source selections, Part III where I cover contractor requirements decomposition, and Part IV, where we discuss financial management, and Part V on test planning, and finally, Part VI on contractor deliverable management.

Welcome to the final post in this series. Give yourself a huge pat on the back for staying with me. Now, if you are a government contractor, you may not like what I’m going to have to say here. But bear with me, you are also a taxpayer (right?) and as such you should want the government to wisely spend your money.

It shouldn’t come to a shock to anyone, but not all government contracts are successful. Even for successful contracts, every contract has an existing period-of-performance which can be extended only so much. Eventually, unless there is justification for a sole source contract, the program office will need to either end the program or recompete the contract.

Now, let’s suppose that the program office didn’t want to do requirements in Jama Connect and instead just allowed the contractor to use their own systems to develop the requirements. Okay, that is the easy button for the program office and is really tempting to go this route at the beginning of a contract because you know, this time will be different and the contract will be a huge success. Unfortunately for our poor program office, life isn’t perfect and they find themselves needing to recompete the contract.

So what is the program office to do? All of the detailed requirements are inside a contractor-owned system. How does a program office get that information, which is needed for the new source selection from the existing contract. If they were smart, delivery of the requirements would have been included in the original contract. If not, they will have to either modify the contract to make that a deliverable or attempt to download or scrape the requirements from the contractor’s systems, assuming they have access to it.

Even if the program office can get the requirements from the contractor, the contractor is motivated to make this process as difficult as possible, especially if they can squeeze a contract extension out of the program office. This means unless you are really good, the contractor may deliver the requirements in the least useful format they can find, without any context or relationship information, and at the absolute last possible moment. Not all contractors are spiteful this way, but I wouldn’t be writing this if I haven’t seen this.

In a non-Jama Connect world, this is this inherent conflict between the program office and the contractor leading up to a contract recompetition. Now, let’s look at how this works in Jama Connect. The program office has full access to the requirements, deliverables, along with the comments, decisions, and discussion around all of these. They can easily export anything they need for the source selection, or export the information into a new Jama Connect project that can be directly shared with perspective bidders. Jama Connect can easily become the new bidder’s library, if you are familiar with that concept.

Now comes the most important part of this discussion. If a different contractor wins the re-competition, traditionally this is an extensive timeline associated with them coming up to speed and being able to perform the work. While Jama Connect may not fix everything, the program office can easily just remove the previous contractor personnel from having access, and granting the new contractor access to the Jama Connect project. This grants the new contractor access to all of the same material that the old contractor had, and provides critical context that will accelerate their learning curve so they can become productive on the new contract sooner.

Generally, all work products produced under a government contract have at a minimum a Government Use data rights. This legally allows the government to share contractor A’s work products with contractor B, as long as contractor B has a legitimate “need to know.” In practice and in my experience, this sharing is fairly limited and is focused on the minimum amount of material that contractor B needs to perform their work. Jama Connect automates this process and expands the scope of the material shared to a wide range of work products. If you ask contractors about the program office sharing their work products with other contractors, they generally accept that it is legal but they do not like that it happens. If you ask more questions, you will find out that one of the major concerns is that they do not want other contractors to see the quality of their work products. They are competitors not only for contracts but also for talent, and the reputation of a contractor is an important recruiting tool.

So, what happens when nearly all work products (except those that are legitimately proprietary) are shared between the original contractor and their replacement. First of all, the quality of the first contractor’s work becomes known outside of just the program office, and if the quality is bad it harms that company’s reputation. As a taxpayer, I don’t see this as bad. There are few motivators to do high quality work as knowing that your work will be shared with your competitors. In the proposal so long ago the contractor claimed that they were better than everyone else, and shining the light onto their works gives them motivation to live up to that claim. And given that that follow-on contractor knows that this will happen to them as well, they are also motivated to put forth high quality work products. The only ones that should be concerned are the companies that are not producing high quality work. Now, I will admit that I’m greatly oversimplifying the corporate politics around this, but I stand by my belief that the taxpayer deserves high quality work to be performed on their behalf.

If you are curious about how Jama Connect can handle the material that is legitimately proprietary, there are several ways. It is possible to tag or categorize everything in Jama Connect with the appropriate data rights statement, or the Jama Connect project can be segmented to have a separate access restricted area for proprietary information. In either case, it is possible to manage that concern if taken into account when Jama Connect was set up by the program office to ensure that only the data that the government has legal authority to share is shared.

Author
Recent Posts

John Allison

John Allison entered the US Air Force in 1991, and spent the next 24 years working primarily as an engineer and program manager across multiple Air Force acquisition programs. He was responsible for taking user generated operational requirements and delivering a product that met the requirements, while attempting to be on schedule and on budget. This involved a significant amount of requirements analysis, requirements tradeoff analysis, RFI/RFP and contract development, and contractor technical oversight. After retiring in 2015, John joined Cisco where he led their first DoD cloud collaboration effort. Today, John is at Armis Security, a leading cybersecurity startup where he leads their federal product management. John lives in Raleigh, North Carolina with his wife, son, three cats and one dog. When not working on public sector cybersecurity, John tries to convince non-traditional companies to enter into the US public sector market.

How Jama Software Supports Government Program Offices Part VII: Contract Recompetition