How to write a better technical approach

Most proposal technical approaches are written with the wrong goals in mind.

Technical subject matter experts or project managers often write the response to the statement of work in a proposal, which is usually called the Technical Approach. The Technical Approach volume defines your offering, saying what you will do or deliver.

What the technical 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 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.

Project management training helps people understand planning and execution, but doesn't teach how to help someone else make a decision. Throw in a little miscommunication in the RFP, 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?

For more information about preparing your technical approach:
Technical Approach

The most common answers we hear from technical subject matter experts are:

  • It must focus on the technical details
  • It must be all meat, with no fluff
  • It must show the right way to do things

All of these common answers are wrong. Worse, they are wrong on their technical merits. They are a result of enthusiastically saying 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. Some or all of the above common answers 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. They need to see why it is their best alternative. Often the explanation of why you do things 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 can 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. It should not be presented in the same sequence every time. What matters to each organization that you send a technical approach to will be different, even if the proposed offering is the same. What makes you the customer's best alternative is different for each customer. 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, the offering fulfills a purpose. One that they’ve put a considerable amount of effort into pursuing. The goal of a technical approach document 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.

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 technical approach should talk about results. It should explain what the customer is going to get. It should explain 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.

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.

Carl Dickson

Carl is the Founder and President of and PropLIBRARY

Carl is an expert at winning in writing. The materials he has published have helped millions of people develop business and write better proposals. Carl is also a prolific author, frequent speaker, trainer, and consultant and can be reached at To find out more about him, you can also connect with Carl on LinkedIn.

Click here to learn how to engage Carl as a consultant.

Proposal Help Desk
Contact us for assistance
In addition to PropLIBRARY's online resources, we also provide full-service consulting for when you're ready to engage one of our experts.

It all starts with a conversation. You can contact us by clicking the button to send us a message, or by calling 1-800-848-1563.