Are people afraid your proposal writers will sell something you can’t deliver?

Sometimes the friction between sales and fulfillment results in the company being afraid that someone might say something in the proposal that the company can’t deliver in order to make the sale. 

I see this often at engineering companies, where the customer’s concerns can deviate from the engineering realities. A proposal is supposed to be written from the customer’s perspective and address their concerns. But what about the engineering realities?

The truth is that there is no conflict. But there is a lack of understanding. And the result can be decisions that do more harm than good.

Proposal writing is not about saying whatever needs to be said to win. Proposal writing is about putting things in context. It is a lot like translation. Proposal writing is about putting your solution in terms that the customer will understand and that show the alignment between your features and their concerns. In many ways it is merely an extension of engineering, since it begins with understanding the requirements and measures its success by how well it addresses them, just like engineering does.

One key difference is that for proposal writing, the evaluation criteria and procurement process are part of the requirements assessment. I could probably make the case that this is not different from including supply chain considerations or alternatives assessments in an engineering methodology, but I’m not trying to convince anyone that proposal writing is the same as engineering. What I am trying to do is show that there are enough similarities to make an integrated process-driven approach better than fighting over who should control the writing.

When companies have their engineers write their proposals but don’t train them to understand what drives the evaluation process, they get poorly engineered proposals that do not meet the requirements of the end user. In other words, they lose. Engineers can be great proposal contributors. In fact, great proposals require strong technical contributions. But proposal quality is based on the procurement process and not simply on the offering design. It requires both to be addressed. You can teach your engineers to understand proposal development, or you can teach them to work with people who do. Either way, you need a process that defines and validates proposal quality. If engineering does not address fitness for purpose, it is not good engineering. And you can’t have a great proposal without having a well-designed offering. 

When companies try to handle everything from offering design, approach validation, RFP compliance, and bid strategy effectiveness to proofreading in a single review, it can be worse than not having a review at all. A better approach is to have multiple reviews to validate specific criteria like whether the approach as written reflects an approved offering design.

When companies try to do engineering in writing, they are just asking for trouble. The design of your offering and the design of your proposal are two separate things. Is there any engineering methodology that recommends designing things by writing narratives about them?  Don’t let your engineers do this and call it proposal writing. Don’t let your proposal writers do this. First design your offering to fulfill the relevant requirements. Then write about how your offering fulfills those requirements and is the customer's best alternative.

The implementation of engineering benefits from also having a quality methodology. The implementation of a proposal process benefits from having a quality methodology. The success of your integration of your engineering and proposal practices can be proven by your quality methodologies. Any concerns or debates about how to interpret the requirements that drive both engineering and proposals, as well as whether the work product produced reflects them, should be addressed by defining quality criteria and applying them to the proposal.

The debate you should be having is not who should write the proposal. It’s not about control. The debate you should be having is about what a quality proposal is, what concerns need to be addressed in producing a proposal, and how to validate the proposal that is produced. The debate you should be having is about what defines proposal quality and what your proposal quality criteria should be. If you can’t engineer the right proposal quality criteria, you shouldn’t be trying to produce a proposal.