No proposal is ever perfect. Every company executive wishes he or she had just a few more days to tweak the last sections. But after the proposal goes out the door, it is time to reflect on what did or did not go well in the proposal process and what could have been done to improve the outcome. A review of lessons learned is a valuable step in improving proposal development efficiency and raising your win probability on the next bid.
Surprisingly, not all companies do such reviews. Even more surprisingly, many companies that do them repeatedly make the same mistakes. The review should follow the same process after every significant proposal. The process has these three fundamental steps:
1. Gather data. Give the proposal team a few days to settle back into its normal operations before trying to collect information about the last proposal. People need time to reflect — but not so much time that they forget what they learned. One or two weeks is typically the right time frame to begin data collection.
Start the data collection process by selecting the participants and inviting them to join in the review. Participants should include the proposal team, technical and management contributors, executive team, and subcontractors. Congratulate the team on the successful proposal delivery and set expectations for the review. Ask the participants to reflect on the proposal process and their experience on the proposal team. This will enable them to share their perspective on what they could have done differently to improve the process and the proposal.
Designate someone to be the recipient of all the comments and ask each participant to send comments to that person. Ask for comments covering the full life cycle of procurement, not just the proposal development phase. You will want comments about opportunity qualification, pursuit and preproposal phases in addition to the proposal development phase. For each phase, each participant should address three fundamental questions: what went well, what didn’t go well, and how activities could have been done differently to improve the process and the proposal.
2. Analyze data. Begin by sorting the comments along the procurement timeline. For example, group all comments dealing with preproposal activities together and then sort those into subcategories by comment type: what worked well, what didn’t and how to improve. Combine redundant or similar comments and edit out comments about an individual’s performance or comments that might become career-limiting expressions of personal dissatisfaction. Those are personnel issues to be dealt with separately and are not part of a process improvement review.
Use a three-column table to show the analysis results. The columns are symptoms, root causes and recommendations. Most comments will describe symptoms, not the root cause of the problem. For example, writers who consistently miss deadlines could be a symptom of several different root causes. Perhaps they are overworked and fully billable during the day, the corporate culture doesn’t enforce deadlines, or they never had proposal training. Whatever the reasons, getting at the root cause is critical because treating symptoms just masks the real problems.
This is the hardest part of the analysis because most people treat the symptoms without ever understanding the root cause of the problems. We need to fix what is broken, not just treat the symptoms — and of course, we want to preserve what is working and be open to accepting improvement suggestions.
3. Learn from mistakes. Brief corporate management and the proposal team with the results of the analysis. Give them time to understand the findings and accept the recommendations. Improvement requires careful changes to processes, better training for participants and investments in better technology. Implementing them requires consensus and a road map for change.
If you conduct your lessons learned review correctly and after every proposal, you can break the cycle of relearning the same lessons after each major proposal.
This article was originally published August 27, 2010 on WashingtonTechnology.com.