Learning from our Mistakes

In a previous blog I commented on the need to quickly accept our situation if in job transition and move on after trying to understand if we had anything to do with it so we can avoid the same problem prospectively.  Don't dwell on trying to fix blame or hold angry thoughts.  However, if you're on a team trying to roll out a new product or process, you shouldn't wait until the project is complete to do your post mortems/after action reviews.  It should be a part of the project manager's action steps during the project.  However the team should analyze the team's successes and key learnings for improvement at the end so as to learn from the process.  While the blog thread suggests the need to do after action reviews when there is a problem, I'd suggest that every time we rollout a major initiative or even an annual event or training program, a plus/delta or review of what we can do better the next year be part of the process and documented for future events. 

Blog Post:
Can mistakes become a competitive advantage?.
I suggest that mistakes, which are bound to occur, give you and edge when they are:
- accepted as a fact of life
- expected to occur
- unique, revealing something innovative
- learned from.

Richard Blakemore responded:
Years ago, I learned a lesson from a mistake that my boss knew would happen, but decided to let me make it anyway. I found it really frustrating, humiliating, and completely avoidable, and was thoroughly ticked off that my boss let me blunder into it when he could have alerted me to it. So my view is somewhat jaded on this front.

Suffice to say, if my team are trying things within the boundaries, and they make what I'll call "discovery" mistakes (as opposed to dumb mistakes), then I am all for it, because we all learn from them. If they want to play outside the boundaries, then they need to let me know first so that I can run a risk assessment of the proposed course of action, because the boundaries have been set for a reason, and sometimes, staying within them is critical to the development of the team.

Otherwise, if my team are likely to blunder into mistakes because of a lack of knowledge that I have and can give them, then I would rather not waste the time of recovering from the mistake, and let them in on the secret ahead of time. That way, no-one feels betrayed, and we can all move forward together.

Frank Feather, host of the blog writes:
To learn from a failure, we must do so intentionally and methodologically.

It is a good idea to carry out an objective post-mortem. This is not to be a witch hunt to point fingers, but a collective effort to understand all possible contributors (human and other factors) to the failure or the less-than-successful result/outcome.

If a project, innovation, or change initiative failed or fell short of expectations, we need to know why, with comprehensive answers and analysis. A failure is not a matter of merely falling short on an ROI or other target. Maybe the target setting was faulty or overly-ambitious.

We need to learn what elements of the strategy design and implementation execution fell short, and why. Plus we need to discern the lessons that will help the organization perform better next time.

Then you need to document these findings to create a knowledge base that can be drawn upon when planning future projects.

In addition, you should develop a set of criteria under which the failed project might be revived, should the underlying internal/external conditions change in your favor. Then, with any needed modifications, the failure might become the success it was intended to be.
.
Let me know if you have experienced any benefit from a mistake you've made on the job.