Creating winning technical solutions
I’m amazed at how few companies present good, compelling technical solutions in their proposals. The reason is probably that their technical teams don’t know what constitutes a good proposal solution.
In this article, I’m going to describe the process we use to ensure we develop solutions that will score well when reviewed by government proposal evaluators. Here’s how we do it.
Step 1 – Understand the requirement
The first step in engineering is to understand the requirement. I don’t mean to speak down to you since this seems pretty obvious, but I’ve read a lot of proposals where the technical team misunderstood the requirement or misinterpreted the intent of the government’s RFP.
To make sure everyone understands the requirement, we do a structured walkthrough of the requirement with the technical team. We discuss what is in the statement of work (SOW), the relevant attachments to the RFP, the proposal instructions, and the proposal evaluation criteria.
Let’s also make sure we agree on what is not part of the requirement. As engineers might say, “Let’s bound the problem.” Otherwise, our solution will become open ended and risk not addressing what is important to the evaluators. The better we understand the requirement, the more likely we are to create a winning technical solution.
Step 2 – Create candidate technical solutions
Next, let’s look at various technical solutions or approaches to doing the work. We like to have more than one approach since we want to trade off the merits of each as we close in on our preferred solution. The chosen solution should be technically sound, complete, logical, and internally consistent. In other words, we need an excellent technical solution that achieves what the customer has asked for, addresses the appropriate requirements in the RFP, and has no weaknesses in its approach.
Keep the alternative solutions handy since we may want to discuss them in our proposal as alternatives we considered when developing our technical solution, but discarded because our chosen approach is superior. This tradeoff discussion can be an effective way of ghosting another bidder’s approach, especially if they have chosen to propose one of the alternative approaches that we discarded.
Step 3 – Engineer in your proposal evaluation strengths
When the government evaluates your technical approach, they will be looking for proposal strengths. These are the features of your solution that either 1) increase the likelihood of successful contract accomplishment or 2) exceed a contract requirement in a way that is beneficial to the government. There may be other features that are evaluated as proposal strengths depending on the mission of the agency, for example, lethality of the system, safety inherent in your solution, etc.
Make sure you agree on how the government is going to define proposal strengths. In our experience, the definition is pretty narrow and may cause a lot of the features of your solution to be noted as interesting, but not scored as proposal strengths.
As a solution development team, we must comb through your technical solution and identify all features that might be scored as strengths since these will need to be highlighted in your proposal. If we don’t find evaluation strengths in your solution, then we go back and rework the solution until we have engineered features into the solution that can be scored as proposals strengths. The more strengths, the better the proposal will score.
For each proposed evaluation strength, make sure you include evidence to support your claims, and clearly delineate the benefit of each feature to ensure that the benefit tracks with the definition of what proposal strengths are for your solution.
Step 4 – Bring in the innovation
There is a natural tension between the need to propose proven solutions and the need to continually improve the way you propose to perform the work being bid. If you are justifying your solution by saying, “This is the way we always do this work,” or “This is how we did it last time,” then challenge your engineers to do it better, quicker, and cheaper.
Build innovation into your solution and show the government that you are indeed committed to improving the way work is done—and offer real solutions to do this. Make creativity part of your solutioning process, and always remember that last year’s breakthrough in technology can become this year’s obsolete solution.
Step 5 – Reduce the cost
Challenge your technical team to engineer cost avoidance and cost reduction into their solutions. If it cost you a certain amount to do this work last time, then figure out how you can do it for less. Be mindful that you need to engineer cost reductions into your solution or technical approach when you are creating it, not wait for executive management to force it into you proposal in the final days of the pricing exercise.
Make these 5 steps part of your solutioning process, and you will consistently produce technical solutions that score well—hopefully bringing you more victories!
Please send your comments to RLohfeld@LohfeldConsulting.com.
By Bob Lohfeld
This article was originally published August 2013 in WashingtonTechnology.com.
Paperback or Kindle
by Bob Lohfeld
contributors Edited by Beth Wingate
Did you know that contracting officers spend up to 20% of their time mitigating disputes between teaming partners? In an informal poll we conducted on LinkedIn last month, 40% of respondents classified their teaming partners as “frenemies” on their last bid.
- Advice (405)
- APMP (18)
- Business Development (182)
- Capture Management (183)
- Favorite Books (5)
- Go-to-Market (27)
- Graphics (5)
- Lohfeld Books (3)
- Past Performance (56)
- Post-submission Phase (15)
- Pre-RFP Preparation (187)
- Proposal Management (245)
- Proposal Production (50)
- Proposal Reviews (22)
- Proposal Writing (61)
- Pursuit Phase (84)
- Research Report (2)
- Resources (59)
- Tools & Tips (218)
- Training (11)
- Uncategorized (214)