Calling All Procurement Officers: A Crash Course in Contractor Success
Government entities, from the Parks and Recreation department of a municipality to the U.S. Department of Transportation, have been around much longer than some of the household names we can’t live without, like Google, Amazon, etc. Yet, increasingly these new kids on the block are helping their long-standing counterparts in public office build great things. While both the public and the private sector have made massive strides with technology, it’s also worth noting that they each do things….differently.
In our extensive work with government bodies of all sizes, we’ve seen first-hand the pain points that government procurement officers go through with each new privately contracted project. The government and private companies motivators are shaped differently, with government being accountable to their public mandate and companies being driven by markets. This means the government's approach to procurement is based on processes that have been built over decades in the public eye whereas companies must stay nimble to respond as the market shifts and evolves. In this post, we’ll share tips on how you, the procurement officers, can make use of some of the things the private sector has learned to make the procurement process more efficient, with fewer hurdles, without having to rewrite any laws.
Getting to know you: The pre-award process
A Request for Proposal (RFP) is an avenue for respondents to review the needs of Government and explain how they would meet them and what it will cost. As a procurement officer, you’ll often receive hundreds of book-length responses, which need to be reviewed in a limited time frame, and are often left to one person and a short-staffed technical review team who are also working on other projects.
What if you could whittle the time an RFP is active down to two or three weeks all while increasing vendor accountability?
Impossible? Maybe not.
One way to do this is to build out a list of vendors that meet certain pre-qualifications so that when it’s time to solicit your project to vendors, you’ve greatly narrowed down the responses you’ll have to wade through. Think speed dating, not blind dating--and do it months before the prom. Don’t put out a singles ad and hope for the best; narrow down your pool of potentials with a pre-validation effort before a project is on the table. While you’re not offering immediate payment for anything specific, you’re vetting contractors now instead of later, when time is really important. This prevents the newest up-and-coming groups from being considered for the immediate future, but the benefits of pre-vetting generally outweigh this and you can always do "on-ramps" later.
Think about the parameters that a vendor would need to meet in order to even be considered. Do you need them to be on a mass schedule like GSA IT 70? Do you need a team of a certain size?
You can apply pre-qualification organically to the two functional areas which almost every RFP includes: technical and business. The response to the technical side should answer whether a vendor can do the work, understands it, and is able to explain their approach. With a trusted technical pre-qualification pool, the only remaining criterium is a focused vendor response to task-order-specific requirements. You’ll want to focus on approach more than tool-specific experience--since you’re buying agile digital services you must assume that those requirements are going to evolve during development based on feedback from users and stakeholders. On the business side, you’ll want to address things like budget, terms, and other constraints so that pre-approved vendors can make an informed decision about whether to respond to the RFP. A mass schedule like GSA’s IT-70 or State of California’s CMAS are helpful in prequalifying a lot of these business considerations up-front, without requiring a lot of rework.
Action: The government has logical restrictions on providing unfair advantage to vendors. Unfortunately, because of the many-to-one problem we touched on earlier in the deluge of RFPs to review, the way that these regulations are enacted often cause a lot of obfuscation and a “hurry-up-and-wait” mentality toward the vendor community. Because there are usually limited government staff to address and respond to a much larger number of vendors, the standard is to greatly restrict the information given to responding vendors. One of the ways we’ve seen this turned on its head is to be fully transparent. All information and documentation is publicly available and well socialized using modern collaboration tools. This allows all vendors to have equal access to the same material, and greatly improves responses. Additionally, this method takes some of the burden off of procurement officials. Leveraging modern tools like github allows immediate feedback and deals nicely with the version control nightmares that can come from trying to marry multiple documents.
Testing time: evaluation
Evaluation is a hard problem. This is especially true when hiring a digital services vendor. Often the software you think needs to be built is very different from the software which will actually address your problem. And when the agency lacks sufficient staff with deep technical knowledge, it becomes almost impossible to determine which vendor knows their stuff. Here’s how we suggest you work around it:
Most proposals have a significant (or massive) written requirement. Usually these are several volumes long and, due to the fact that each volume is designed for a different audience, there is a fair amount of redundancy (business volume will go to finance and contracts, while the technical volume will go to the TRB). These voluminous written proposals are holdovers from a time when the best way a vendor could demonstrate performance was by writing an essay about their proposed solution. What we learn from hiring best practices is that this will yield great essay writers, but rarely great engineers. The ability to communicate and document is obviously important for a software project, but it’s hardly the main deliverable. The same should be true of a proposal. Allow the vendor to provide solid and succinct documentation. Be mindful of buzzword bingo and grand soliloquies. The main goal of a vendor’s written response should be to make sense, and support the much more important requirement: work performance, AKA building software.
For the work performance portion, approach it as if you were a hiring manager at a firm. At Truss, when we put a call out for engineers, we ask candidates to spend no more than four hours responding to a problem that we’ve provided. Even if the applicants can’t complete it, it gives us a window into what decisions they made and why--and, since communication is one of the skills we most value, we discuss it with them afterwards.
But we still request something complete, whether in build or thought process. Procurement officers should ask for a finite prototype, and talk about the decisions the vendor made along the way. Anyone can cobble something together (the what), but the best can show the thinking behind it (the why). Are they are empathetic to your needs and collaborative? Worry less about technicalities like whether they have “five years of experience in X language or Y tool”.
Again, communication is key--post-award, contractors should be able to thoroughly document processes and offer ongoing advice to the agency. Therefore, a vendor should be able to explain their process and decisions as part of the work performance portion. Truss believes this ability has irreplaceable value in technical engagements. The awarded team should not only show that they can build, but that they can talk through it, and walk you through potential scenarios--what if a spec had to change? What if a constraint was uncovered during discovery? Asking vendors how they would go about addressing those challenges turns the evaluation into a valuable tool for measuring substance and communication savvy.
Action: Treat procurement like hiring. Ask the vendors to provide a small sample of the services you’re hiring them for. Have someone available who can thoughtfully review their work, and then have a conversation about what they built and the choices they made. We’ve all seen the person who is excellent at interviewing, but when it comes to actually doing the job, they come up short. Focusing on how the team performs and their ability to explain their method will allow the procurement team to make a good use of everyone’s time and avoid a painful attrition process down the road.
In the weeds: Managing and collaborating with your Digital Service (DS) team
So now you’ve selected the contractor that will own the project, and thanks to the tips Truss offered around the early part of the process, you’re feeling confident. But our work--yes ours--is not over. There are three things we must do every step of the way:
Unite your home team. Show up. Guide.
Massive projects, especially those replacing a legacy system, can not be completed in a vacuum. Great software starts with buy-in from stakeholders, so begin with identifying all the relevant ones and hash through everything with them early on. Allowing folks to air their concerns and provide (often valuable) insight is a great way to avoid 11th hour requirements. Make sure everyone feels heard, but also establish a single, authoritative decider to avoid endless back-and-forths.
For many government agencies, “showing up” is where the “agile” approach falls apart. For a project to be successful, a good public-private partnership is required. The Government must provide direct guidance and support to the digital services team, and the team must provide valuable information so that everyone can prioritize and make decisions. This is a daily engagement. Regular input and a prioritized backlog that the software team can work from requires buying into the “ceremonies” of agile. The government team member with the most in-depth technical knowledge should be involved in these if they want to have a product that meets their needs. And in general, it’s a best practice to identify point people to help the team explore specific areas of expertise.
Why? Private contractors will need support from you to manage roadblocks on the government side and to understand the constraints (for example, internal approval timelines may be entirely unknown to your vendor’s development team). Help your vendor to understand what those constraints are, which ones can be changed and which ones can’t.
It all goes back to our favorite word: communication. It’s up to procurement officers to tell the contractors what you need to feel safe in a collaborative working environment, and to communicate that to all stakeholders on the government side (for buy-in, of course).
Action: Give potential vendors a chance to get their hands dirty. Offer a deep dive that shows them exactly what they are working with--like the actual code, and what the user pain points are. This will give you a more realistic idea of what needs to be done, the staffing and timeline. Get all stakeholders in a room at the start of the project, lay out what the plan is, and discuss and record disagreements and doubts. Thank them for their time and assure them that all points will be addressed. By doing that in the beginning, you can plan your approach on the same page without last minute overhauls.
We threw a lot of advice at you, so here are the crib notes:
Vet a pool of contractors now, before a project comes along, to lessen the time and work before a project begins.
Ask candidates to do the work, not write about it — find the best teams by gauging their thought process and ability to explain their decisions.
Communicate and guide daily; act as the liaison between the contractor and the government. You are key in navigating change.