I count myself as one of the fortunate ones to be a witness and an active participant in a new trend in federal government procurement evaluation strategy - the "don't write me a wordy proposal with pretty pictures, but build me a working product to prove you are are right vendor for the job" method of source selection. A few federal agencies have adopted the 'DevSecOps hackathon' style of source selection as their main non-price-related evaluation method. A few more agencies are either experimenting with the feasibility of the approach or are cautiously using it to complement their traditional acquisition strategies. The "hackathons" are often called "Coding Challenge," "Technical Demonstration," "Technical Challenge," or "Paired Programming Assignment."
Semantics aside, the hackathon-style evaluation method has its strong proponents and opponents. However, this seems to be the trend that is here to stay and only spread wider.
One of the trailblazers and pioneers in this effort is the Department of Homeland Security, Citizenship and Immigration Services agency and their Office of Information Technology. They were one of the first agencies to adopt the method, and their 'hackathons' are one of the most sophisticated, challenging, and ever-evolving.
Over the past few years, I've had the opportunity and privilege to participate and collaborate in a number (~10) of such hackathons. Each hackathon and each team are a little different. They have different requirements, evaluation criteria, participants, starting points, end-goals, processes, technology, and methods to get there. However, over time some patterns and lessons-learned emerged that I can share without divulging any proprietary knowledge:
Tuckman’s Law is universal – all teams must plan to set aside time forming-storming-norming workshops before they can perform.
Best results are produced by teams on a burning platform – some sense of urgency and crunch is crucial for mobilizing the team.
Yet, too much unmanaged pressure and stress lead to sub-par performance well below the team's actual capabilities.
Executive leadership must be first-hand involved but also stay out of the way – servant leadership at its finest.
The 1-day Technical Demo is akin to a 100m dash race – resources must be optimized for flow.
The 2-week Coding Challenge is akin to a marathon – resources must be optimized for quality and endurance.
The preparation for the two is very different!
Both are one-shot-delivery experience – no room for refactoring. Planning and execution must be flawless. Practice!
Each one is unique – teams cannot rest on their laurels from prior wins. Practice! Practice! Practice!
One of the aspects I appreciate the most about the hackathons is that despite how grueling, resource-intensive, and disappointing they can be, at the end - everyone is a winner. It is true that only one of the competing teams gets the juicy contract! However, all "failed" participating teams, if they have done their due diligence during the preparation, walk out learning new technical skills and forging stronger relationships. And of course, the biggest winner is the Government Client and the constituents they serve!
With a new proposal season looming on us, I can't wait to see what other brave agencies will take on the challenge of conducting more hackathons.
Comments