How a Proposal Postmortem is like an Agile Retrospective

Looking back at the past and into the future makes me think of the Proposal Postmortem. Performing a critical Lessons Learned review of what worked well and what can be improved is an important best practice in the lifecycle of a proposal. Do we always have at least one? How much attention do we give it before rushing off to the next proposal?

Agile approaches like Scrum and Kanban employ a similar best practice called the Agile Retrospective. Its purpose is the same as a Proposal Postmortem—to capture Lessons Learned and improve processes and outcomes on future sprints (or proposal efforts). What can we learn from our counterparts in the software engineering field? What new perspectives can we adopt from the agile principles? After all, we are all developing a product—theirs is software, and ours is the proposal. Let’s explore this a bit…

Retrospective (from Latin retrospectare, “look back”) refers to looking back at past events. In the context of both proposal and IT projects, it is a meeting held by a team at the end of a project/process/iteration/cycle/sprint to discuss what was successful, what can be improved, and how to incorporate the successes and improvements in future projects. This discussion also gives the team members a chance to inspect and adapt their behavior and reaction to the current state of the process and helps them devise ways to improve coordination and collaboration.

Retrospectives are widely considered one of the most important and indispensable Agile techniques. Inspection and adaptation are all about continuous improvement, and without continuous improvement, there is no true sense to the term agility.

Agile Retrospective: The five-phase structure

Agile Retrospectives are not just a quick round robin over coffee and donuts. A good Retrospective has structure and requires preparation. In the book Agile Retrospectives: Making Good Teams Great, Esther Derby and Diana Larsen identify five steps the facilitator should follow when conducting a Retrospective.

1. Set the stage. Lay the groundwork for the session by reviewing the goals and agenda. Create an environment for participation by checking in and establishing working agreements.
2. Gather data. Review objective and subjective information to create a shared picture. Capture each person’s perspective. Seeing the iteration from many points of view provides greater insight.
3. Generate insights. Step back and look at the picture the team has created. Use activities that help people think together to delve beneath the surface.
4. Decide what to do. Prioritize the team’s insights and choose a few improvements or experiments that will make a difference on future efforts.
5. Close the Retrospective. Summarize how the team will follow up on plans and commitments. Thank team members for their hard work. Conduct a Retrospective on the Retrospective. The Scrum Master (Proposal Manager) usually facilitates the Retrospective, and part of his/her job is to make sure that all participants know they can speak their mind. Working agreements include recognizing that all viewpoints have merit.

Data gathering involves examining:

1. What worked well? List the processes, interactions, and events that the team found helpful and would like to continue.
2. What didn’t work well? List the delays, impediments, and broken processes that the team would like to either improve or discontinue.
3. What actions can we take to improve our process going forward? List the improvements and actions that can be carried forward into future sprints based on the lessons learned in the Retrospective.

One technique Agile teams use to collect ideas at a Retrospective is to use Post-its or a white board to capture all ideas on the wall. The team puts forth ideas/suggestions for improvement and collectively decides which to carry forward for future projects.

There are other techniques, games, and simulations that Agile teams use to promote a creative and comfortable platform for team members to express themselves freely. These games make the Retrospective meeting more productive, interactive, and fun.

As a rule of thumb, a Retrospective for a 30-day sprint lasts about 4 hours. How much time do we as proposal managers take for a Retrospective? Another Agile rule of thumb is to make sure at least one actionable item comes out of each Retrospective session. Do we always have a Retrospective, or post-mortem at the end of a proposal effort? Perhaps we are not putting enough focus on this activity?

Conclusions

In summary, consider approaching the Proposal Postmortem with renewed focus in 2015:

• Always have one
• Make it a priority
• Make sure at least one actionable component comes out of each meeting

Agile practices place a high degree of importance on the Retrospective. Retrospectives are planned, executed, and revisited with a follow-up at the same level as Agile code inspections (or our Color Team Reviews). Perhaps we should treat the Proposal Postmortem like another Color Team? For 2015, let’s treat the Proposal Postmortem like another color review, giving it the planning, execution, and follow-up it deserves!

By Maryann Lesnick, Lohfeld Consulting Group Principal Consultant

Connect with Maryann on LinkedIn

Reprinted with permission from the APMP-NCA Executive Summary, Fall 2014.

Lohfeld Consulting

See Full Bio