Evaluation of Contract Proposals within the Government

Evaluation of Contract Proposals within the Government — a simple example.

Let’s get straight to the point. You have a bona fide business need. A pain point in the business community can be solved with Commercial Off The Shelf (COTS) technology. You conduct research and discover a software brand name that can solve the problem. How do you go from zero, nada, scratch, to an implemented solution? This article will show how this process works, from the cradle to the grave. This is a higher-level overview and is not comprehensive. Each step in this article can be expanded to pages of content; however, I will paint broad strokes and give a high-level overview of the process.

As an Amazon Associate, I earn from qualifying purchases. At no extra cost to the consumer, I get commissions for purchases made through links in this post.

Budgeting

First things first. You can’t do anything without money planned — a budget or a line item that says you have money even to pursue this type of solution. Someone in your organization maintains a planned budget. You must, in advance, let that person know you plan on purchasing software. This is tricky because you may not know precisely what you need today. How do you tell the budget authority you want XXX dollars if you don’t know the exact costs? You can base it on best-effort estimates. Perhaps, you have a yearly budget you can go off. Maybe you spend $800,000 per year on company licenses, which can be divided into many products or services. Perhaps you have a pretty good understanding that you want commercially available software with a price tag online to base this off. The point is, you need money. There is not a single correct method; it’s whatever methods your organization can support and defend.

Requirements Gathering

It is necessary to understand the software’s end-user’s pain points. What problem are you trying to solve? Ask yourself a few of these questions first:

1. Is this a problem?
2. Do we even need to do these processes?
3. Can we automate the processes with in-house solutions or open-source solutions?
4. Is the economic cost worth the automation?

There are plenty more questions to ask, but you must consider why you are spending money to solve this problem. How often does the problem come up (frequency)? You need a business case for why it’s worth spending that budgeted (planned) money.

Next, shadow the business user and get a true understanding of the process. They often describe the process one way but do the work differently. It’s not their fault; they do this process often and skip steps. It’s your job to capture the exact steps in the process.

Statement of Work or Performance Work Statement

The next step is to put everything down in writing. This could be either a Statement of Work (SOW) or a Performance Work Statement (PWS). The SOW is simply a document that describes the work to be done. It defines activities and deliverables and usually a timeline. The PWS describes performance objectives that are expected of the contractor. The PWS is more about results than the “how” of getting the desired outcome.

Estimate Cost

Now that you have the SOW or PWS, it’s time to break it down to estimate the costs associated with the work or results. There are many ways of estimating costs. One common way is to look at the history of a similar type of PWS/SOW. If it’s similar work, perhaps it’s similar costs. Another method is to break down the work performed into manageable chunks and calculate the costs. Knowing exactly which types of labor categories are very helpful. For example, you need to know if you need a developer or a project manager or a technical writer.

It’s hard to determine the proper labor categories without experience. Reach out to colleagues and other departments to see if they have subject matter experts who can assist. If you need to maintain servers under the contract, perhaps reach your IT department to ask for estimated costs. After all, if it costs your organization XXX dollars to maintain a server, surely, a contractor can compete with that cost. Another way to estimate costs is to get a Rough Order of Magnitude price estimate from several vendors for similar work. Be careful with this approach because it might give vendors an unfair advantage if the information you provide them to make the estimate is not available to other vendors. There are many other methods as well. I suggest you research how to do an independent cost estimate for a project and start there.

Within the government, the estimated cost worksheet will be called the Independent Government Cost Estimate, or IGCE.

Select Contract Vehicle

This step may be optional, depending on your circumstance. Many organizations will already have a Blanket Purchase Agreement (BPA) or an Indefinite Delivery, Indefinite Quantity (IDIQ) type contract. If this is the case, you can piggyback off those contracts if they suit your needs. For example, many organizations have a larger, enterprise-level contract covering all their employees’ computer hardware. When new employees enter the workforce, they request a new computer through the contract already in place. In my world, we have an umbrella contract, a BPA that covers many IT software development initiatives.

This means that a select set of vendors is already preapproved to do the work you are asking them to perform. When you create a Task Order (TA) of the BPA, you are limited to the set of vendors already pre-selected. This makes competition slightly less, but it also expedites the time to award the contract.

Work with the Team

Typically, you would get the subject matter experts to review the SOW or PWS. You would have the financial folks review the IGCE. You then would have your supervisor review the entire package. Every organization will have multiple documents that must go with the SOW/PWS & IGCE. You may also need a formal Acquisition Plan (AP) to go with it. This is not an individual’s sole responsibility. The leadership and management teams are signing off on this purchase. They should be involved in the entire process. Do not be afraid to look to them for guidance.

Send the Package to the Contracting Team

Cross your T’s and dot your I’s and send the package to the contracting team. The contracting team will put the legal jargon into the SOW/PWS and double-check everything is good for a solicitation. There is usually a bit of back and forth with questions between the contracting team and your internal team. This is normal. The contracting team does not understand your particular needs as well as you do. Once everything is good, the contracting team will solicit the contract from the public or the vendors on the BPA/IDIQ. The contracting team will likely ask you how you plan to evaluate the proposals. How do you know which vendor is the right choice? This means you may have to have already come up with a method of evaluation. The contracting team will allow the vendors to respond to the Request for Quote (RFQ) — the solicitation. Depending on the contract’s total value, this can range from 15 to 60 days and sometimes much longer. Imagine a response to building the B-2 Bomber. That response might take months to years.

Evaluate the Proposals and Make Recommendations

The vendor responses have now arrived, and the contracting team has vetted them. Now, they send you the redacted proposals. Usually, they send just the technical documents without any pricing attached first.

If you are working with a simple contract, like a license to use software or buying a few computers, you may do the evaluations yourself. This will also depend on your organization’s policies. More complex projects may require a team of people, sometimes called a Program Action Group (PAG). The PAG would refer to the evaluation criteria created before the proposals came in. The PAG would individually evaluate, based on the evaluation criteria, and write up the responses and recommendations. When all evaluations are completed, there would be a consensus meeting with a meeting of the minds — a determination and recommendation.

Sometimes, all proposals are technically acceptable with commodities like a license or computer hardware. In this case, you would normally recommend the lowest-cost bid.

Award Contract and Administrate

Finally, the contract is awarded to the vendor after all the work you have completed. Now, it’s up to the contracting administrator to ensure the contract runs smoothly and follows the scope of the SOW or PWS.

Final Thoughts

What I talked about in this article is only the tip of the ice burg when it comes to how contracts are created from scratch. Most of my material will relate to government contracts; however, the concepts can also apply to the private sector. The main difference is that the government must be fair and unbiased with its solicitation and selection process. In the private sector, you can choose your favorite contract despite the cost or technical merit.

There are many steps missing from this article and several exceptions, too. The goal was to give you an overview only of some ways contracting could work in your organization.