At the end of the day, after the smoke (and mirrors) have cleared and all the do’s and don’ts have been collected and accounted for, if the lessons learned are not properly articulated and invested into the improvement process, and properly disseminated back into the organization, then all the metrics, charts, accolades and rhetoric become like any other well-meaning, self-help book we read enthusiastically and voraciously before it finds a hiding place high up on our bookshelf. Now what?

Well, there are at least four key questions that warrant review as soon as possible after the boxes full of our best proposal efforts are handed over to the customer:

  1. What did the customer say?
  2. Did we properly execute our current process?
  3. Do we have the proper process documentation?
  4. Do we have the proper and most-effective tools?

It is certainly cathartic after a proposal submission, to allow people to meet, speak their peace and clear the air, but, if you really want to use these sessions to improve your proposal quality—and your win ratio—you need to re-think how you collect your lessons learned, and, how best to use the information you come up with. For a lesson to be learned, it must be applied, it must effect change. Oftentimes, after the dust settles, management moves on, oblivious to the pratfalls in the process. Amnesia befalls everyone, especially if by chance — daggone it — you actually win the thing!

So, even though contract award may be months away, followed only then by the debrief, there are ways to elicit constructive feedback and inject positive change into your process sooner rather than later. While you’re waiting for the debrief, and then again afterward, ask yourself the following questions:

Does what you learned apply to other customers, all of your customers, or just to this one specific opportunity?

Did you know enough about what the customer wanted? What questions would have given you the right information? How would you incorporate getting answers to these questions into the pre-RFP process?

Did you find out that you had misinterpreted the customer? What questions would have mitigated misinterpretation in the pre-RFP release phase?

Were there errors in the production or delivery of the proposal? What steps can you take on future proposals to prevent them?

Are there additional steps or guidance that could be added to the process that would address other customer comments?

Are there any changes you can make to the Validation Process to ensure a better proposal next time?

Consider how the following line of questioning elicits constructive feedback and focuses on positive changes:

In some instances issues arise because the process was not faithfully executed. Had the process been properly followed, the issue would not have come to be, or would have been mitigated. If this is the case, you can ask participants:

Would better guidance or notifications help with executing the process?

Would better orientation, discussion and/or training help proposal contributors? If so, when should it occur? If this is not the case, it means that following the process did not prevent or mitigate the issue. In this case, you should ask:

Should you change what information you collect, when you collect it, how you collect it, or how you distribute the information?

Should you clarify or change in any way the guidance provided?

Should you change what, when, or how you validate the key aspects of the proposal?

Consider if the lesson learned feedback impacts your process documentation:

Does the process address the topic identified? If yes: Where is it addressed, and how should the items be changed? If no: Should a new page/topic be added?

Does the change have an impact on roles and responsibilities?

What can occur earlier in the process to mitigate the issue?

During future proposals, how can you validate that the issue has not recurred?

Reminder: Keep a list of which process pages and topics you make changes to so that when you release a new edition you can reapply your changes. (While this is standard for the large organizations, this is often overlooked, or simply abandoned, by smaller companies.)

Many companies now take advantage of software tools, such as Privia, to facilitate workflow automation, proposal collaboration, and document management. If your company takes advantage of a software tool, consider the following line of questioning:

Was the team able to use the full system as designed, or did they find the need to work around it?

Did participants have sufficient technical support available when and how it was needed?

Can the software issue be resolved through user training or guidance? Would better orientation, discussion and/or training help? If so, when should it occur? Should it be provided online or offline (in person)?

Does the workflow require changing? Do any of the templates or files in the workspace require changing?

Knowing and doing are two different things. In the proposal process, like anything else, “insanity IS doing the same thing over again and expecting a different result.” So, unless everyone has input, and then access to the information, and that information is applied throughout the company, you really haven’t learned anything.

 *Carl Dickson contributed to this article