Column

The Value of the Debrief for Project Success

It’s difficult to find the balance between beating yourself up for a failure and reviewing what went wrong in an attempt to uncover the lessons learned. I try not to stew on past mistakes and quite frankly, rarely categorize less ‘successful’ projects that way. All my project experiences have improved me professionally and helped to fine tune my processes for the next project.

Whether a project is perceived as a success or a failure, I can’t stress enough the value of the debrief. Hindsight really is 20/20. On a project we need a bit of distance to reflect on what worked and what didn’t work in order to make the next project flow more smoothly. To keep following the processes that worked well while tweaking those that caused hiccups. This doesn’t necessarily have to occur only at the end of the project. Reflecting on lessons learned following a project milestone or step can also help guarantee completion of the project on schedule and within budget.

A debrief doesn’t have to be an onerous task and comes down to asking a few basic questions:

  1. How did it go? Did we achieve what we set out to do? Were the timelines we set achievable?
  2. What are the lessons learned? What worked and what didn’t work? Could we have anticipated or prevented the less successful outcomes?
  3. What should we do differently next time? Do processes need to be tweaked?

I recently had the invaluable experience of being a project team member on two similar and somewhat simultaneous projects. One project launched on time and on budget. The other project was paused due to delay and an expanding budget. Debriefing on both projects helped determine why one succeeded and the other failed. As noted above, I struggle with labeling one project a failure as incredible progress was made by dedicated team members. I will instead refer to the ‘failed’ project as Project One and the ‘successful’ project as Project Two.

While there was considerable overlap between the two projects, Project One started first. Debriefing following Project One milestones allowed the team to utilize lessons learned for Project Two. Project Two was able to reuse many of the system requirements from Project One and a more streamlined process was developed thanks to the debriefing questions above.

What were the lessons learned?

  • Project One had numerous stakeholders and perspectives that required extensive consultation that was not factored into the timeline. More perspectives also led to less alignment on goals and made decision making more complicated.
  • Project One had many moving parts. For example, it required legislative changes and integrations with external systems. The time and expense for both was underestimated.
  • Some stakeholders were unable to visualize the end product. This made it difficult to keep them on track and to develop focused content.

What did we do differently?

  • A clear decision-making hierarchy was established for Project Two. While numerous perspectives were welcomed, the final decision maker was clear on the project goals and stayed on track. The final decision maker was also more heavily involved in the day-to-day development, which allowed for quicker decisions and for the project to be more nimble if required.
  • Project Two did not require legislative changes or integration with external systems. These delays were avoided as they didn’t factor into Project Two.
  • Project Two had more topic areas and required more content development. However, a more efficient content development process was developed by incorporating a prototype content format, i.e. a clickable PowerPoint. This allowed the stakeholders to ‘see’ what we were aiming for and allowed us to produce more focused content.

If you are looking for more guidance on how to ‘guarantee’ project success, consider the recent book, “How Big Things Get Done: The Surprising Factors That Determine the Fate of Every Project, From Home Renovations to Space Exploration and Everything in Between”. Megaproject expert, Bent Flyvbjerg, and co-author Dan Gardner provide common-sense advice on the matter through an extensive study or debrief of over 16,000 projects.

Comments are closed.