This is part of a five-day blog series on how to write a winning proposal. It will go discuss actually writing the proposal. If you want to get more in-depth information, examples, and what to do before the proposal, check out my “How to Write a Winning Proposal” handbook.

You have written the Management Approach, and now it’s time to start talking about the actual solution.

You have done all the analysis, talked to SMEs, and really thought about the best way to solve the organization’s problem. It is now time to write it on paper. The Technical Solution section is a great way to do some preliminary thinking of the future solution that you will present to the organization. Even if you do not win the contract, you will have the foundation in developing a sound solution for future contracts. It is like a Concept of Operations (ConOps) document within a proposal. If you don’t know what a ConOps is. A ConOps is a useful technical document that can aid you in envisioning the perfect system to tackle a current issue that you are trying to solve. One thing that I will stress is that you should only offer one solution. You might want to offer an alternative as well. Don’t. It will make you look indecisive. You are the expert, so you tell the organization what it is they need.

Here are the main sections that a basic Technical Solution section usually has:

Introduction, Including Section Overview

A Technical Solution section has an introduction. As I stated before, the person reading the Past Performance section is usually not the same one reading the Technical Solution section. Therefore, you have to treat it as its own document, so a person could rip it out of the proposal and still understand what is going on. You should introduce your technical solution and briefly let the reader know how the section is organized.

Client’s Issue

Before you can discuss the proposed solution, you have to give stakeholders a bit of history of the issue you are trying to solve. The background and history of the current issue is very important because you want to show stakeholders that you fully understand how the issue evolved. It will also help you in designing a better solution.

If there is already a current solution in place, then you want to discuss that as well. You want to detail everything about the current solution and/or issue. When you are writing about the current issue, you want to ensure that you get everything down from your interviews with Subject-Matter Experts (SMEs and stakeholders. If you don’t fully understand what is currently going on, how can you find the proper solution?

Therefore, take your time in gathering everything you can about the current issue and its history.

Technical Solution Description

You have done your research, and you have written all you could about the current issue the organization is having. It’s now time to discuss how to solve the issue. You want to really take a week or longer to really come up with a solution that will be better than what is currently in place. You want to start off by giving a high-level overview of the future solution. Please make sure that you use “will” and not “shall.” The latter is requirements talk.

After giving a high-level overview, you want to go into the detail. You want to explain the reason you approached the issue the way that you did. This is kind of a bridge between the organization’s current issue and your solution. It gives the Technical Solution section a better flow.

You want to discuss any policies and constraints that the future solution will have. Additionally, you want to ensure stakeholders that you will adhere to any current and near-future policies that are in place. Also, that it is interoperable with other systems. Organizations and government agencies have realized the importance of being able to work alongside other groups, so if you can show that your future solution can do that, then stakeholders will be almost sold.

The impact that the future solution will have to the users, everyday operations, and other systems is the best way to conclude this sub-section. You want to reassure stakeholders that you have thought about this, and you will ensure that everything is smooth sailing, or as near to that as possible. This is something you should go into further in the next sub-section, Implementation Plan.

Implementation Plan

If the organization already has a solution in place, you want to discuss how you plan to phase that solution out, and implement yours. This includes processes, equipment, and strategies. Also, you want to discuss how you will measure the plan to ensure that it is highly effective. This could be done by having a schedule that includes milestones. If you reach the milestone before or on schedule, then you know that you are on the right track. You might be thinking, “I haven’t even gotten to the point of creating a full schedule.” The best way to handle this is by breaking things down by phases.

You can explain to the organization that you will work with them to create a more detailed implementation plan and schedule when you win the contract. However, you still should show the organization that you have put some thought as to how you will implement your solution.

One thing to remember is that even though you have done tons of research, interviewed SMEs and the client, and have applied your expertise, there are always going to be a few gaps. This is where assumptions come in. You will have to state the assumptions, why you made it, and why you weren’t able to find out that information before writing your proposal. If you have done your homework before you made the assumption, then usually the assumption has a likely chance that it is true.

You can now start writing the Executive Summary and Cover Letter.

Tags: proposal management, proposal writing, proposal writing handbook, technical solution