As someone who’s rewritten hundreds of resumes for federal proposals, you start to notice patterns in the way people construct their resumes that often make it difficult for evaluators to assess the quality of the candidates.
Resumes are the first chance the Government gets to meet (virtually speaking) your team, especially your key personnel. As a proposal development firm, Key Solutions knows this.
No matter what government agency you’re bidding to, proposal resumes usually require the same things: relevant experience, education, certifications, and training. Just four items, yet the way people handle them varies widely. Follow these five steps to develop effective resumes for government proposals:
I’ve actually seen a proposal team collect resumes, scan them into an attachment, and submit them as is—technically compliant, but what a missed opportunity.
To really score points with a resume, you need to have the SOW and the job descriptions and qualifications in front of you as you filter each resume for past experience, skills, and areas of knowledge relevant to the specific project or task order.
Evaluators are often looking for keywords in resumes, so one’s job experience must be written in the same language as the RFP.
For example, say in one’s last job, trouble tickets were generated using ServiceDesk, but the government agency you’re proposing to uses Remedy. Some evaluators might never have heard of ServiceDesk, so why not just say "using ticketing software similar to Remedy?"
In another example, what you call a Business Process Analyst the RFP calls a Knowledge Management Analyst. The job descriptions are similar, so guess which one you go with?
Too often, job experience includes bullets that say things like, “Leveraged expertise and led the development team to enhance system functionality." It’s vague and unusable because it begs too many questions from an evaluator:
Make your accomplishments shine brighter. These are the concrete details evaluators usually look for.
Most resumes combine certifications and training, which makes sense because they sometimes overlap.
Still, Government RFPs often distinguish between the two, mainly because evaluators are looking for industry-standard credentials such as CompTIA Security+, Project Management Professional, and Information Technology Infrastructure Library certifications. In many cases, specific certifications are required for the job.
Training is different. Its purpose is to help evaluators assess a candidate’s relevant skills and areas of knowledge. But the difficulty is there are so many forms of training: formal and informal, instructor-led classroom-style coursework, online self-paced courses, on-the-job training, peer-to-peer training, self-taught through how-to manuals, and sites such as YouTube. Often, there’s no administrating authority to provide proof of completion or to validate a candidate’s level of expertise. Plus, training is usually an ongoing process.
A good way to handle the training element is to provide the areas of knowledge (say, SharePoint, JavaScript, C#, etc) along with the year and administering authority for the more formal training. For the rest, you could put, “Guided, hands-on training in …” and list the other areas of knowledge. At least that gives evaluators a better idea of a candidate’s skills and helps them connect training to job experience, where those skills were applied in a real-world setting.
Right off the bat, provide a one-paragraph rationale for selecting this candidate for the proposal role.
Use the brightest moments of their relevant past experience: exceptional accomplishments, awards, customer kudos. It’s usually not required, but keep in mind they are reading through a pile of resumes. Chances are, they’re focused on whether a candidate meets the education level, years of experience, and certification requirements, and they will skim through the rest. So it helps to have a short summary up top telling them why a candidate is perfect for a proposed role.
Many resume writers assume their audience is other people like them. Software developers have their own jargon and easily recognized acronyms (for other developers, that is), but it’s a safe bet that most people evaluating your resume are not going to be software developers.
So make sure the resumes are written in plain language. Put it in layman’s terms. And, please, do us all a favor, spell out acronyms on first use.
Resumes don't exactly win government contract bids the way a good technical solution or price can, but they can move the needle in your favor. So it pays to focus on them. What a shame to put together such a great team of key personnel and other staff to execute the project, but fail to show an evaluator what makes them so well-suited to the task.