DHS FLASH Primer
Having successfully competed for the Department of Homeland Security (DHS) FLexible Agile Support for the Homeland (FLASH) contract, I often get questions about the background of how FLASH was structured and conducted. Here’s it is…
The Why
Government agencies in general have had, in general, lackluster results when it comes to performance of IT application development contracts. Many agencies, and DHS in particular, have recognized that how they procure contracts is a huge part of the problem. The status quo structure and existing contracts (such as DHS EAGLE) have a few successes, many duds, and a few spectacular failures.
With FLASH, DHS wanted to encourage a targeted, high-quality pool of firms that “get it” regarding modern software development — more silicon valley than beltway bandit. They also wanted more streamlined but higher-value procurement mechanisms to better compete, award and manage contracts — more concrete results (“show”) than paper narrative (“tell” ).
What’s New
FLASH is not the first to apply innovative procurement techniques, but it was arguably the biggest and most visible thus far. The more notable innovations included:
- Initial feedback from 3 minute video submissions by vendors for ‘advisory down-select’ instead of 5–15 page capability statements in response to a Request for Information
- Technical evaluation based on 3 pages of approach plus a 4-hour in-person technical challenge with 30 minute oral presentation component instead of evaluation based on comprehensive (20–50+ pages) written technical and management approach, possibly with oral presentations
- Focus on small business and new firms (both new to DHS and new to Government) instead of prizing extensive past federal/DHS contracting experience
- A timeline of 6 months from industry day announcement to IDIQ award instead of 12+ months to compete & award a large (~$1.5b) IDIQ
The Challenge
The central feature, and most heavily weighted evaluation criterion, was the technical challenge. The basic structure of the challenge was as follows:
- DHS provided a high-level description of the “kudos” application, with a detailed backlog to be provided on the challenge day.
- DHS encouraged the use of modern software and tools, focusing on industry best practice rather than typical government tech stacks.
- Teams could prepare technical “scaffolding” — such as having a shell application and CI/deployment pipeline running.
- At the start of the challenge, the team would be given the specific feature backlog, and then had 4 hours to collaborate with the DHS-supplied “user/product owner” to produce working software.
- The team then presented their approach for 30 minutes, followed by up to 30 minutes of Q&A.
The challenge was scored on 3 subfactors:
- Engineering: using best practices such as automated testing and DevOps
- Agile: effectively managing and communicating
- Design: incorporating user experience and business goals
DHS conducted over 100 of these challenges in a very short window (over a few weeks). This was a tremendous effort and achievement in terms of logistics and marshaling the staff resources to evaluate teams.
The details provided to vendors before the challenge can be found on page 74 of the RFP document. The challenge evaluation criteria are detailed on page 84.
Is it Better?
In my other story on FLASH, I provide my overall opinion, which is that challenges are far superior to paper-based procurements. For teams, it is more satisfying to build something than write — and the show-don’t-tell principle is generally sound.
Additional Resources & Information
Additional Topics
How We Won: I’ll follow this article up with one covering our ultimately successful approach to competing on FLASH.
How and When to Tech Challenge: I intend to write up a more thoughtful and nuanced set of guidelines on how to use different flavors of technical challenge procurements. There are still ways to game the system and favor vendors who are better at proposals than delivery.
