How to write a great technical proposal even though you don't know what you're talking about

Sometimes people get stuck writing a technical proposal about something in which they are not an expert. Sometimes the subject matter experts aren’t available or don’t exist within your organization. You can do research, but you can’t become an expert in a week or even a month. So how do you write a technical proposal that competes against real experts, proves your credibility, and earns your customer’s trust? If you’re the stuckee, we have good news for you. We have a little trick that may work for you. And it may work so well that you win the proposal right out from under the noses of the so-called experts.

Most people try to win their proposals by loading their technical approach up with details. They seek lots of technical meat instead of the empty carbs of marketing slogans and unsubstantiated claims. But what if there’s no way for you to produce those details? If you try, the best you can hope for might be a watered down attempt that talks around the details. It’s surprising how many of the proposals we review end up looking like that.

Instead of focusing on the technical details, you need to focus on something else. Instead of focusing on the steps for doing the work or the specifications of the components, try focusing on how you know the steps were performed correctly, or whether the results produced meet the requirements. That subtle distinction produces a very different proposal, but one that can still establish credibility and earn the customer’s trust. In fact, if you do it well you might appear more trustworthy and credible.

For each milestone, deliverable, or component on the project, ask yourself how you will know:

• If it’s on track before it gets delivered
• If it will meet specifications or requirements and be free of defects upon delivery
• How you can achieve transparency, so both you and the customer can see the status of everything at all times
• What the customer will get out of it

It will help if you know the language of quality assurance programs. But a little common sense can go a long way. Here are 10 things to consider:

• How will you measure and track progress?
• How can you use online tools for status awareness?
• How will the customer know if you are going to deliver on time, within budget, and according to specs?
• How will the customer know if you are delivering as promised?
• How many check-ins, double-checks, checklists, checks and balances, and any other kind of checks can you define?
• What sign-offs, approvals, and reviews might be added?
• Do you check every item or implement a sampling program?
• Can you design quality in at the beginning to prevent defects?
• Would collaboration and stakeholder involvement be beneficial?
• How do you make sure that every step is visible: from the start, during performance, and in the result?

Just keep in mind the difference between a technical approach and a management plan. What you need to do is make your technical approach about ensuring results instead of about construction.

You still need technical details, but you can get by with less. For example, you might not know all the steps, but if you know the major ones you can discuss how you ensure that progress, performance, or delivery will be what it needs to be at each major step instead of discussing the minor steps in between. You can get by knowing what needs to be accomplished without all the details about how it will be accomplished.

Instead of proving to the customer that you know what you’re doing, you will prove to the customer that they will get what they need as promised. You can actually ghost against technical experts who only have great skills, but may not be able to deliver on time, within budget, and according to specs.

Even though the customer has asked for a technical approach, the technical details may not be what matters the most to the customer. The customer may not even understand the technical details. Most customers are concerned with trust issues. If you are not credible, you are not trustworthy. If you are a high risk, you are not trustworthy.

Showing that you know how to build something doesn’t mean that you will be successful, although it helps. What you want to show is that you know how to be successful. You need to establish credibility and trust with the non-technical customer who is concerned about whether the contractor they select will deliver as promised.

If the customer has tunnel vision when they evaluate your technical approach, the fact that you have less technical detail than another proposal written by someone who really is a subject matter expert will be obvious. But if you don’t have access to that level of subject matter expertise, then that’s a battle you would lose anyway. The battle you can win is with the customer who is more concerned with delivery than technical composition.