Show Me, Don’t Tell Me: Technical Challenges For Federal Procurement

Over the last few years Dev Technology has had the opportunity to take part in several different and unique technical challenges across agencies such as the U.S. Citizenship and Immigration Services (USCIS). These technical challenges have the potential to give the government a real look at an offeror’s capabilities. It also gives a sense of how they work on solving technical problems and make trade-offs based on time and resources. While this type of proposal effort can be time consuming and costly to the offeror, Dev Technology believes that with well-crafted evaluation criteria these challenges give the government a greater sense of confidence in choosing a team to help adapt new processes and technologies to drive their mission. The technical challenges we have participated in that have set both the agency and the contractor up for the best possible outcome share the following attributes:

• Multi-phased approach. For example, the team might have two weeks to work on building out a cloud environment, a CI/CD pipeline, and create code using government provided data and user stories which is then submitted. Each contractor team is then brought in for a live demo to talk about the solution, demo the solution, and make a change to code so that the government can evaluate how the team solves problems together.
• Detailed and clear evaluation criteria. This is important to ensure that each technical team can deliver code and other artifacts that are meaningful to achieving the goals outlined in the challenge statement. Due to the limited timeframe to work on code challenges it is important for the offeror to understand specifically where they should focus their time and effort. This allows the government to make a true assessment of the skills and capabilities that went into the technical challenge and fairly make a determination of strengths and weaknesses.
• Limited technical scope. It is important that the challenge is relevant to the RFP and does not introduce extraneous technology, as this can cause confusion for the code challenge team on how to best focus their effort to deliver a meaningful demonstration to the government. This focused scope will better enable the government reviewers to determine which contractor will be right for solving their agency’s technical challenges.
• Evaluating across people, processes, and tools. Delivering working code is critically important in these code challenges. However, it is important to assess how the contractor team works and communicates, in addition to assessing the process they used to design, develop, test, and deliver the code. This will paint a more thorough picture for the government to evaluate all aspects of an offeror’s delivery capabilities from technical prowess, to teamwork, to the ability for their process to manage change and difficulties.

Although these challenges can be time intensive for our technical team members, they frequently enjoy the opportunity to collaborate within our organization to solve interesting problems. While it might be easier telling the government how our team’s technical proficiencies can help solve their problems in a written proposal, my team and I would much rather write code to demonstrate our skills and abilities in a technical demonstration. Showing off our ability to perform user-centric design, to build out a CI/CD pipeline, or to demonstrate how we incorporate security into our software design and development process gives our teams a great sense of pride and enjoyment.