Dec 292011
 

business team planningIn most organizations, it’s common practice to conduct “postmortem” or lessons learned review sessions upon completion of major projects.

If the project achieved its goal, management questions typically focus on what went right. What did we do well? How can we sustain this success? What could we improve to make the outcome even better?”

If the project failed to meet expectations, the postmortem tends to focus on what went wrong. Where did we get off track? How and when should we have adjusted? What can we learn from this experience?”

Postmortems play an important role in improving our businesses. But in today’s world, they may not be enough. I believe the time has come for leaders and managers to start engaging in “premortems.” In other words, to conduct the review process before embarking on major projects or initiatives.

In the spirit of full disclosure, I confess to borrowing the term “premortem” from a McKinsey Quarterly Report article entitled “Strategic Decisions: When Can You Trust Your Gut?” In the article, Nobel laureate Daniel Kahneman and psychologist Gary Klein debate the risks and rewards of senior executives using their intuition to make key strategic decisions.

Not only is the article a fascinating read, it also supports one of my core beliefs that today’s leaders and managers need to slow down in order to go fast. One good way to do that is by asking postmortem-type questions before, rather than only after, the fact.

Klein recommends gathering the project team and saying, “We’re looking into a crystal ball, and this project has failed miserably. Everyone take two minutes and write down all the reasons why you think the project failed.” This gets people to voluntarily engage in devil’s advocate thinking before the project gets started.

What’s the value in conducting a premortem?

For starters, it can identify potential problems that otherwise would not have surfaced until they caused major damage to the project. It can also change the dynamics of the decision-making process for the better. Rather than trying to avoid conflict and reach consensus as quickly as possible (a common cause of ill-fated decisions), people actively look for contrarian ideas to bring to the table.

In most cases, problems identified during the premortem won’t cause the demise of the project. More likely, they will cause the project to get tweaked in ways that will improve its chances of success. For the amount of time invested, a premortem is a low-cost, high-payoff activity. It is a simple way to slow down (just enough) to get it right versus go fast and do it over.

The article also suggests going through a checklist before approving any major strategic decisions. This may seem like focusing on the details rather than the big picture. But in this case, the checklist focuses on process rather than content, thereby keeping it at a high-impact level.

According to Kahneman, the checklist should include:

· Quality of the information. Is the data coming from multiple independent sources or just one source saying the same thing in different ways?

· Decision-making process. Did the team engage in honest, open debate, or did it engage in “groupthink” in order to avoid conflict?

· Leadership deference. Did the leader’s opinion unduly influence others in a certain direction?

· Group mindset. Did the group accept the data without challenging it? Was there a rush to achieve consensus that might have caused key elements to be overlooked?

To this I would add:

· Assumption testing. What assumptions about our customers, our market and our industry did we bring to this project? Are they still valid? Do we need to update any of them?

· Environmental scan. What has changed in our industry/the world/with our competitors in the past three to six months? What has changed outside our industry that might impact how we serve our customers?

· Making stuff up (MSU) test. What are we making up about this project? What voids of information are we filling in? What decisions are based on our MSU’s (making stuff up) rather than on hard data?

In today’s business environment, customers, markets, and entire industries can change overnight. If you get it wrong the first time, you may not get another chance.

Obviously, you can’t have all the information every time you make a strategic decision. But by taking the time to identify what could go wrong before launching a project, you can have contingency plans in place before you need them. You can practice the thinking that might be required quickly if challenges arise.

“Slow down to go fast” may sound counterintuitive, but it works. You can (and should) still conduct postmortems after the fact. But you will get a lot more bang for your buck by adding a premortem into the mix.


About the Author:

Holly Green has a BA in behavioral sciences and Master of Science degree in organizational development from American University in Washington, D.C. She is currently on staff at Webster University where she teaches courses in the graduate program. Holly also teaches for the University of California San Diego, Rady School of Management in the executive education program.Ms. Green is the CEO of THE HUMAN FACTOR, Inc. ( www.thehumanfactor.biz ) She has over 20 years of executive level and operations experience in FORTUNE 100, entrepreneurial, and management consulting organizations. She conducts more than 50 workshops annually for Vistage, the world’s largest CEO membership organization. She is also a frequent keynote speaker for numerous corporate and professional associations. Her book, More Than A Minute: How To Be An Effective Leader & Manager In Today’s Changing World ( www.MoreThanaMinute.com ) lends voice to her corporate experience and goes beyond the theory of leading and managing by providing practical action oriented information.

Article Source: http://EzineArticles.com/?expert=Holly_Green
Article Source: http://EzineArticles.com/4434628

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>