By Abigail Smith, FedHealthIT.com
Leveraging his recent experience as the first Defense Health Agency Director of Procurement, along with a distinguished career spent as a Senior Contracting Official, the recently retired Scott Svabek now spends his time as an independent consultant serving industry organizations striving to win government business. In typical Scott Svabek style, he provides his clients with the type of blunt direct feedback and insight that few can offer.
Recently G2Xchange had the opportunity to catch up with Scott to get his survival tips for winning business in the Federal Health IT marketplace.
[bctt tweet=”Survival tips for winning business in the Federal Health IT marketplace” username=”fedhealthit”]
On Solicitations
First, Scott says that industry needs to understand that in order to get a foot in the door, it helps to be a better partner in the process. When government is putting together a solicitation, it can be a challenge as “it’s not always a cookie-cutter solution.” He expands further, “Human beings are generally lazy and the process tempts government to take the path of least resistance. Building on his experience during Ranger School, it was driven into him that humans have to train themselves not to take the path of least resistance by getting lazy while walking patrols on trails. That can be deadly. He applies this same theme in contracting. “The requiring activity often times just copies and pastes from older SOW documents and then hands it over to the contracting officials to fix and package. If it was a poorly written document before, it is worse now because unclear requirements cause confusion to industry, which drives up costs, especially on FFP contracts.” He sympathetically adds that while such a method seems easier, because it’s faster and therefore cheaper, it can become “very confusing, on top of not necessarily being effective or successful. They fall back on the authority of the contracting officers signing the documents who can manipulate language to what they’re comfortable with.” In addition, Scott notes that it is very easy for the author to “get too close to the material, and they miss the nuanced leaves in the forest.”
How Industry Can Be a Better Partner
Scott goes on to highlight that government knows their solicitations and SOWs are far from perfect and that these agencies “thirst for interaction at the RFI-draft level where industry could ask questions.” For example, he ponders, “What don’t you know – but were afraid to ask?” It is better to ask now than not and be deemed non-responsive to the RFP. Scott explains that he is not sure why, but more established firms tend to ask questions and provide comments; while smaller firms, who could benefit the most, don’t. Industry reading RFP’s generally fall into “two buckets: those who do it repeatedly in the same agency with certain policies, procedures, or SOP’s when they run their traps; and those newly emergent companies who try to offer, but are not successful.”
On developing better proposals – Keep it simple
Scott says “When a proposal is hard to read, digest, or follow; even if it’s accurate, then your work earns a negative connotation in the source selection.” He reminds us that the people “crafting requirements, especially within Military Health, may not be a team of requirement writers,” so ultimately, technical response teams need to “keep it simple by meeting the minimal standards at the price’s breakpoint.” The best way to do this, Scott advises, is to “answer all the questions after fully reading the RFP because words have meaning.” He advises to have someone read the proposal who has no real knowledge of the requirement to see if it makes sense to that person. He understands there are technical issues they might not comprehend but the overall concept should be understandable. Also, at that high level they can offer areas that potentially conflict with other sections or see duplicate comments that could distract from the proposal. Scott also reminds us that directions citing shall, must, and will require special treatment in comparison to could and should. He further recommends that attention needs to be paid to whether it’s a “Lowest Priced Technically Acceptable (LPTA) type of award versus best value cost/technical trade off. Phrasing your solution requires different language, and you can’t submit the same language twice.”
For further information, see Scott’s LinkedIn profile at www.linkedin.com/in/scottsvabek
