No Comments

When Things Go Awry

Management, Planning, problem solving Comments (0)

Robert Burns wrote in “To a Mouse”:

“The best laid schemes o’ mice an’ men / Gang aft a-gley.”

We all know this one as, ” The best–laid plans of mice and men often go awry” but i am a romantic and prefer the older language.

But the fundamental truth here is that no matter how carefully we plan and execute our projects, occasionally situations arise when, in spite of our best efforts, plans and projects fail. This happens for one or more of many reasons, but I think it comes down to this distillation.

  • We did not know all of the parameters necessary to construct and effective plan. We did not have all of the necessary information.
  • Our assumptions were erroneous.
  • We had a faulty plan.
  • We did not have control of the environment in which we executed the plan.
  • We did not have contingencies in place to deal with deviations from plan.
  • We do not have enough time (or other resource) to respond.

I am sure the list goes on and I missed a big one, so if I did please comment to this blog and we can start an aggregate list.

What do we do when a project does fail?

  • Realize that life is an ebb tide and a flood tide. There will be more failures and more successes in life, and no one event is totally life changing.
  • Look for the solution. From every failure comes the opportunity to learn and to achieve a greater success. The cause of he failure, when analyzed, will demonstrate significant opportunity for contribution. Entrepreneurs thrive on identifying failures and problems in processes and systems, and they benefit and succeed when they provide solutions.
  • Examine what you could have done. We all have a circle of influence, to borrow from Covey. Often the cause of the project’s failure occurs outside of our circle of influence, and consequently we have no way to exercise control over the situation leading to the project’s failure. If the situation was in your circle of influence, reflect on the issue in the project review.
  • Always conduct a project review, a post mortem. The purpose of this exercise is not to place blame but to identify real issues that we can correct, escalate for correction, or provide contingencies should they occur again. Our focus is creating a blueprint for a better plan and a successful project next time. Before you start the project review, review the following list with the review team and brainstorm other questions and tasks you want to add to the list.
    • Identify what went right with the project.
    • Identify what went wrong with the project.
    • Identify assumptions that were invalid.
    • Identify defects in the plan, its execution, and/or the project’s control systems.
    • Identify what was our of our control that contributed or caused the project’s failure.
    • Identify resource deficiencies and shortages.
    • Identify communications issues.
    • Identify structural issues and organizational aspects that contributed to the project’s failure.
    • Have each participant relax, clear their minds, and intuitively sense why they feel the project failed, list these observations, and discuss them

    From this exercise, produce a succinct report listing items that people can take action upon, identify the importance or priority of each item, and identify the person or organization best capable of resolving the issue. Publish this report to your management team, then to those who have action items to accomplish.

  • I think the most important thing that allows us to deal with project failure is to maintain a realistic and healthy view of life. There are no successes or failures in our lives, just outcomes. Some are positive outcomes and some are negative. We will experience both outcomes several times in our lives. We need to view both our successes and our failures with this perspective and realize that we are not our failures, nor are we our successes.

Craig @ May 12, 2008

Leave a comment

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