How to write a better technical approach

Subject matter experts or project managers often write the technical approach in response to the statement of work in a proposal. The Technical Approach volume addresses what you propose to do or deliver to the customer. Writing the technical approach often requires significant technical subject matter expertise.

What the subject matter experts may lack in writing and fine art skills, they often make up for with enthusiasm for their subject. When they bring that enthusiasm to the proposal, the result is mostly positive. People debate whether proposal writing specialists interviewing technical subject matter experts is a better approach, but either way, the subject matter experts are involved. They just need to be guided in the right direction to end up with a winning proposal.

Project management training helps people understand planning and execution, but doesn't teach how to help someone else make a decision. Throw in a complicated RFP that's difficult to interpret, and it's easy to see why technical staff focus on the wrong things in their proposal contributions.

So what should the best technical approach focus on?

Technical subject matter experts often come into proposals thinking:

• It must focus on the technical details.
• It must be all meat, with no fluff — which to them means be all technical.
• It must show the right way to do things, regardless of what it says in the RFP.

All of these common answers are wrong. Worse, they are wrong on their technical merits. They are a result of enthusiastically sticking to what you know, instead of solving the problem.

What the customer needs from a technical approach document is to determine which offering is their best alternative. The technical details play a role in this. But the real focus for a technical approach should be on what the customer will get as a result of what is being offered. They need to see that what they get will fulfill their goals. Accomplish those goals matters more to the customer than the technical details of how those goals are accomplished. They need to see why it is their best alternative. Often the explanation of why you do things or chose what you did matters more to the customer than what you will do or the procedures you will follow.

Once the customer sees what they will get, then how the work will be done becomes part of how they assess whether you will deliver as promised. All the technical details are part of establishing your credibility, but that comes after you’ve demonstrated that the technical details deliver what they want.

This is also why you shouldn't follow a template to write your technical approach, and why a technical approach example can lead you astray. A technical approach is not a description of something done the same way every time because each customer has different goals. Even if your procedures remain the same, the goals they should accomplish for this particular customer will be different. The technical approach should not be presented the same way or in the same sequence every time. What makes you the customer's best alternative may also be different for each proposal, requiring changes in the reasons why you are proposing what you are. And that's what you should build your technical approach around. You should end up with a highly personalized proof of why your approach is the best way to go for that particular customer, and not a generic template description of what you do.

What is the goal?

For the customer, they are procuring something to fulfill a purpose. One that they’ve put a considerable amount of effort into pursuing. The goal of a technical approach is to demonstrate fulfilling that customer’s goal better than any alternative. The goal is not to explain how you would do things. The difference is subtle, but it matters. A lot. It's the difference between winning and losing.

When you are on the receiving end, do you evaluate a technical solution by the approach or the results? If it delivers the wrong results, who cares about the approach? If you focus on the details instead of the results and a competitor focuses on the results, then their technical approach will likely be seen as the best alternative, even if your approach is technically superior. Your goal in writing a technical approach is not to be technical superior, but to explain why your approach should be chosen. Being technically superior may or may not be part of that rationale.

Your technical approach should talk about results because ultimately that is what the customer wants. It should explain what the customer is going to get, why your approach matters, and why you made the choices you did. Understanding “why” you do things is more important to the customer than understanding “how” you do things. The customer will say to themselves, “If I select this proposal, I will get [fill in the blank] because [fill in the blank]. I believe they will be able to achieve that because their approach is credible.” The approach is actually the last thing they consider. Even when the evaluator is technical.

It’s easy to understand why people get tricked into believing that the approach is the most important thing. For starters, there’s the name, “Technical Approach.” It does not accurately describe either what information the customer needs or what they are trying to do. Then there’s the way that customers write their RFPs. They ask you to describe your approach for doing what they ask. They really make it sound like they want to hear all about your approach and will make their selection that way.

Only they didn’t write the RFP because they want to purchase an approach. They wrote the RFP to fulfill their goals. And their best alternative for achieving those goals will be the proposal that best demonstrates how what the vendor does results in achieving those goals. That is the most important technical requirement. That is what the technical approach should be about.