Key Personnel in Tech Challenges & Procurements
You need to run a procurement for IT services, and maybe you’ll use a technical challenge in the evaluation. You have a choice that will shape the competition and project: to require key personnel or not.
For those new to contracting, the term “key personnel” carries with it a definition enshrined in federal regulations. Those named people must be committed to the project for a period (usually one year), and you can’t move them elsewhere. If they quit, you are obligated to find an equal or better replacement. The idea is to make sure the contractor can’t do a “bait and switch” when it comes to who will show up to deliver vs. who was there at proposal time.
You might require that the team who shows up on challenge day is committed to the project. This guards against a cynical “beltway bandit” firm that will send in the A-team to win the challenge, then scrape the C-team off the street to deliver. However, it doesn’t always make sense.
The Big Problem: Finding the Unicorn
If I could wave a magic wand (as the buying program manager), I would find a high-functioning team that works together like a well-oiled machine. They know each other and have gelled. They can parachute in and add value from day one, starting at a running pace.
If you find one of these “unicorn” teams, great! However, they don’t really exist (thus the term unicorn) except by sheer luck — a bidder happens to have a team ending a project the week before yours starts.
Small firms only have so many people, so it’s hard to just generate a whole team that can start if they win. They can’t hire ahead a whole team at a time. The big firms talk about their deep bench and staffing reach. In theory they can deliver a team; in practice they are worse off than the small firms unless your project needs 8 new college hires. (Trust me, I’ve worked for small, medium, and super-big firms.)
When it Can Work
Requiring the challenge team to be the real team can work under the following conditions.
- Scope: You are awarding for a specific project
- Size: The work is sized for one team
- Schedule: The work will start soon after the challenge, i.e. 2–4 weeks, or at least on a known (with high confidence date)
If all of the above criteria are met, it might make sense. You can require that some or all of the challenge team are key. You get to try before you buy, and that team will quickly roll into doing the real work.
When it Fails
Let’s take the opposite case of the three S’s above.
Broad Scope: You are procuring an agency-wide IDIQ. The projects will vary in many ways. The tech challenge team builds a Java app, but the first Task Order that vendor wins is to build a .NET app. The difference in technical skills means that the vendor will have to field a different team anyway.
Large Size: Some procurements are for several teams worth of people. Requiring that the challenge team is real is great. If we assume a cynical vendor, making the challenge team key guarantees that you’ll get one presumably strong team, which may be accompanied by several more mediocre teams. (The key personnel are real and obligated to show, but only represent a fraction of the overall program.)
Uncertain Schedule: It’s a familiar story among contractors: agency requires several key personnel for a project, but can’t manage their procurement timeline. They run a competition, spend a bunch of time evaluating (often with no communication on updated timeframes), then 9 months later finally award. Of course they expect the contractor to deliver a full team including key personnel to start immediately. What exactly was this team doing for 9 months? Getting assigned to other projects is what.
The Big Secret: Make Your Own Unicorns
You can’t find a unicorn in the wild. But, you can buy a horse, some glue, and a sawed-off Narwhal horn. In contracting terms, you can have your own ready-to-go teams.
The best way to get great IT services is to take a team-centric approach to procurement, and build a pipeline of work for strong teams. Generally, a team learning a new domain (even some new technologies) is not too hard. Getting a team to gel and fire on all cylinders is very hard. You can design a procurement strategy to grow teams, then keep feeding work to the good ones through additional tasking.
Remember to question precisely what you are trying to validate through the evaluation process, and what are the real indicators for that.
