What The Heck Went Right?!

Have you found yourself working on a project that's having problems, missing deadlines, over budget and/or full of defects? 

Or have you launched new products only to discover that they didn’t get the uptake you had hoped in the market?

On most such projects, at some point, someone will say "when this is all over we need to do a post-mortem" to determine what went wrong and how we avoid these kinds of problems in the future. 
 
This is certainly an important and worthwhile activity. In Agile practices, we refer to this as a "retrospective" instead of using the term "post-mortem." We do this partly to avoid the ever so slightly negative death-related connotations of the term "post-mortem;"  also because anything named in Latin tends to sound intimidating. But most importantly because we take the mindset that a retrospective should not be triggered because "there was a problem" (or death!) but rather should be part of the completion of every project (or even a phase of a project).
 
In fact, I recommend you don’t view the retrospective being exclusively, or even primarily about identifying "what went wrong" on a project.  The first and primary focus of every retrospective is what went right. The recommended guideline is that over 75% of the time in every retrospective should be spent on what went right. Why is that? 

Sure, its good to understand what went wrong, but even once you've done that you have a lot more work to do. Just knowing what went wrong doesn’t make the next project more successful, you then need also to figure out what you will do differently to make that "wrong" thing not happen again. And then even once you have "figured that out," the reality is you may or may not have gotten it correct. Your "fix" is not yet proven. So, there is yet a third step to try that "fix" on another project and see if it has the desired effect. Hopefully, it does and if so, great. In fact, I heartily recommend you do take this three-step approach when looking at "what went wrong."  But, let's contrast that with how many steps it takes to benefit from what went right. Step 1- determine what went right. Step 2- determine why that thing went right (which is usually a lot easier than finding the root cause of problems).  And once you have figured out what went right and why you just need to keep doing that thing. So it's simpler to get future benefit from what's right vs. what's wrong.  

Now I can hear your wheels spinning, and you may be thinking "yeah, but come on if we are already doing something right, why would we stop doing it anyway? We are already doing that thing; we aren't going to get any "incremental value" by praising what we already know how to do! We should focus on improvements! I'd like to say, "good point," but I can't. It’s a terrible point, and here is why. This line of thinking is based on a fallacy. The fallacy is that good and beneficial practices sort of automatically perpetuate themselves. Having worked with scores of large enterprises, I have not found this to be the case.  In fact, when project teams retrospect on "what went wrong," very often the root cause of the problem was a failure to engage in practices which they have done in the past that led them to success.  There are many reasons for this - efforts to seek efficiency, change in project leadership, a desire for variation, or just old-fashioned "forgetting to do it." That's why it's incredibly valuable to reinforce what went right, so we don’t forget to keep doing it, and we acknowledge the value of the practices that led to the successful outcome.

Perhaps you are thinking, "Come on, this is a place of business!  We don’t come here to feel good; we come here to get things done! You can feel good at home!"  In reality, many studies have shown morale is a hugely important component of productivity. In one study, the Gallup organization estimated that low morale in the form of worker "disengagement" costs the US economy as much as $350 billion a year. Giving people the opportunity not just to say "good job" but really "get into" what was done right, by who and why is a huge morale booster for everybody.
 
And here's one final benefit to focusing on "what's right," when it comes time to get to that last 25% of your retrospective where you do want to talk about "what can we do better next time," the team is going to be a lot less defensive and a lot more open to acknowledging problems and responsibility if it's preceded by discussion of the positive aspects of the project.  Furthermore, when team members become accustomed to retrospectives being positive experiences, they are less likely to procrastinate scheduling them, less likely to find an excuse to miss them, and less likely to show up in a defensive posture. All good things.
 
And I'll anticipate one final question; you may be thinking, "But what if nothing went right on the project, it was a total disaster?"  Believe this; something always went right; you just aren't seeing it. Just like something can always be improved. On super successful projects its still very valuable to consider whether there are "things that went wrong" (once you've thoroughly covered what went right) and even on the most messed up projects, it's worth digging to find what went right, it might be more than you think and its working from those past aspects of success, however small, that you will build towards an even more successful future.