Post Project Reviews and Continuous Learning

It is hard to believe the staggering success proclaimed by business professionals everywhere. Have you been to LinkedIn lately? Have you read the recommendations?

Apparently, the world is filled with Zen Master Jedi Guru Black-belts who have mastered every known methodology, development framework, software package, cultural issue, change management challenge, and supporting tool; all of their projects are on time and under budget, and all of their children are above average. These supreme beings have nothing but glowing references to prove it. Wait, I think I just spotted one:

Maybe that is all true and maybe I am the only manager that has experienced a less than optimal outcome at work. Here’s the truth. Some projects actually fail. Go read Michael Krigsman for some perspective on IT project failures. And even the ones that do not fail are rarely flawless. And the ones that you think are flawless? They are not.

In the past year or so Joe has helped me to drive a more disciplined project management approach in our organization. One practice that we are starting to use more and more is the post project review. We model our approach on kaizen techniques used by our manufacturing colleagues to solve operational problems. We were also inspired by after action reviews in the US military.

Very recently, we have used the technique after an internal audit (those are always fun) and after a server migration project. The internal audit example was interesting because this was not a project in the classical sense; however, the review process was very useful. And since we performed the review through our wiki/blog platform, it’s now online for tens of thousands to learn from. It won’t get that many hits but it has already been shared with dozens of colleagues throughout the company. And if we’re lucky, those same audit findings will never occur again. Avoiding future mistakes is what it is all about.

By the way, this process is not meant to be a love fest; it’s meant to solve actual problems.

Joe is much more capable of describing our technique in depth but I will try to do it justice:

• Gather everyone involved in the project. If there are lots of stakeholders, you might need several meetings to accomplish this.
• Focus on what went wrong or not quite right.
• Everyone gets a chance to speak and give their perspective.
• The moderator must elicit participation; trust me – some of your best material from some of your quietest people.
  
• Do not focus only on technical problems and deliverables; communication, process, methodology, bureaucracy, working conditions – heck, anything is fair game for criticism.
• Gather up your issues and try to distill them into separate problems that can be explored to root cause.
• Explore the impact, temporary resolutions, root cause and future process corrective actions.
• Assign actions and drive change. Learn!
• Share your findings widely. It’s just good karma.

Here’s a sample issue from our server migration project. I’ll pick on myself here because I was assigned the action item:

Is this perfect? Not really. Is it better than pretending everything is fine? I think so. Should you use it in your project management processes? Up to you. Good luck!

Technorati Tags: Project Management,Continuous Learning