Technical proposal writing vs. solution architecting

Solutioning is figuring out what to offer the customer to solve their problem or address their need. However, in practice, it really involves incorporating subject matter expertise to figure out what to propose. While the term implies creating the solution for proposals that address customer problems, it is similar to systems architecting or offering design. We’re using the term solutioning to cover all of them just to keep it simple.

Solutioning may not be needed in every proposal. Sometimes the customer tells you exactly what you should propose. Some RFPs specifically ask for solutions to problems. Others ask for approaches to achieve the customer’s goals. The more complex, technical, or uncertain things get, the more likely you’ll need help from a specialist who can solve what to offer.

How to tell when you need solutioning

Here are some signs that you need solutioning prior to proposal writing. Does the RFP tell you:

• How many people to bid?
• What the level of effort will be?
• Everything that your staff should do?
• Desired quality standards, but not how to achieve them?
• About problems the customer has with an expectation that you will propose how to solve them?

Or does the RFP tell you what to accomplish but not:

• What approaches to take?
• How much effort will be required?
• How trade-offs should be made?

If the RFP does not give you the answers, then the customer expects you to provide a solution that does.

The more technically challenging the requirement, the more subject matter expert (SME) participation you’ll need. 

Another consideration is that the SMEs are often the ones who will be performing the work and are stakeholders in ensuring that what gets proposed is feasible. Even if you think you know what should be offered, it might be a good idea to involve the stakeholders. 

Solutioning and technical proposal writing are not the same

While there are some SMEs who can do proposal writing, no one should do solutioning by writing about it. Figuring out your solution or what you plan to offer by writing about it is not only bad engineering, it’s a recipe for proposal disaster. If you don’t figure out what to offer and validate it before you start writing, you condemn yourself to re-write after re-write based on every change to your offering in search of something that will win. It never comes because you run out of time. Solutioning by writing about it can ruin a perfectly winnable proposal.

Solutioning should be completed and validated before you start writing your technical approaches. This means that once you think you have a solution, you should have it reviewed to make sure it's what the company thinks will win and is what it wants to propose. You should do this before you invest in writing about it.

Figuring out what to offer can be thought of as an engineering process. Or it can be thought of as a business process improvement effort. Or a design effort. Or an implementation planning effort. It depends on the nature of what your company does and what the RFP requires. The level and type of documentation required will also vary. 

When should you start writing about your solution?

Proposal writing can start when you know enough about the components of your offering to describe them and you have validated that you have the right solution components. It usually does not require the same level of detail as pricing. It may simply require a few answers to questions or details that aren’t obvious.

Having enough detail to illustrate your offering can help with both getting ready to write and with validating the solution. Working out at least a conceptual graphic is a great way to get started because it can show the components, what they accomplish, how they relate to the customer's needs, how they play out over time, and what the customer will get out of it all. A big part of Proposal Content Planning is figuring it all out and the relationships between everything before you start writing.

Once you know what you will be offering, proposal writing can be done either by the SME or by a proposal writer. Proposal writing involves different skills than solutioning and not everyone has enough of both skills to do it all. Even when a SME is also doing proposal writing, the solution needs to be validated before writing starts in order to avoid unnecessary and risky writing and review iterations.

What to do about it

Make your assignments clear. People often assume that a proposal assignment is a writing assignment. This is not always the case. Consider:

• Someone needs to determine how the solution should be documented prior to writing. Less detail prepared at a high level quickly is better. It just needs to be enough to validate that the solution will not need to be changed later. This is what you should focus on because you want to avoid getting into the middle of the proposal and finding out you have the wrong technical solution.
• Someone needs to validate the solution. Is this a person, perhaps the executive sponsor, or is it a team? Who can decide that the solution is correct, competitive, and what the company wants to offer without the need to change it later? This is who you need to review and validate the solution before you commit it to paper in the proposal.
• A proposed solution might include a list of steps for an approach, the number of staff required, the tools they will use, the schedule, or implementation details. An assignment might just be providing details like these at the bullet level. What you don't want is paragraphs of text, at least not until the solution is validated.
• A proposal writer might be able to complete most of a section without input, but need answers to questions to complete it. A solutioning assignment might just be to provide answers to the questions.
• For more complex bids, a subject matter expert might be required to determine what needs to be done to be RFP compliant. Communicating and reviewing this should not require writing a narrative and should not take as long.
• How will you integrate the solutioning into the proposal content plan? Once you have a validated solution, it becomes part of the input into proposal writing. Ideally it should be part of the input or instructions to proposal writers. For this to happen the description of the solution should easily drop into the proposal content plan, and the timing of solutioning and validation should be synchronized with the proposal content planning schedule.

Does all this really matter?

Only if you want to win. Only if you want to avoid having your proposals turn into train wrecks at the end because someone decided late in the game to change the solution resulting in last minute re-writes without any quality control. If you’ve lived through a proposal delivered in the final minutes there’s a good chance it was because solutioning wasn’t performed and validated prior to proposal writing.

I've taken to calling this the proposal death spiral — where each change to the solution initiates another rewriting cycle that concludes with another attempt to improve the solution and produces another rewriting cycle. This can continue without end until you run out of time and submit what you have instead of the proposal you wanted to have. Trying to figure out what to propose while solutioning by writing paragraphs about it is a primary cause of the proposal death spiral.