Planning for Failure

Project managers automatically plan for success. Success is the desired end goal, so it is logical to plan in that direction. More experienced project managers know that there is also an undesired end state, namely failure. Sometimes, arguably most of the time, planning for success is sufficient … but it is prudent to both plan for success and plan to avoid failure if you want to increase the odds of a happy outcome.

Planning with failure in mind can be proactive or reactive. Proactive planning is usually in the form of using historical data during the construction of a plan. The format of this historical data will vary depending on the industry, the maturity of the organisation in question, and the maturity of the organisation’s PMO, or general planning processes. An example of historical data would be lessons learned from past projects, ideally analysed and classified to show the most common issues in the type of project. Use the lessons of the past to instruct on good planning for the project in question. Typically, this is just done once during the planning of the project.

Reactive planning takes the current plan and analyses it to identify bottlenecks, too many overlapping activities, too many interconnected activities, areas where too many marginal or finger-in-the-air estimates converge, etc. This analysis need not always cover the entire duration of the plan. In the case of projects with a long duration (e.g. 12, 18 months, or more), with an increased probability of scope change during the project, it would be more practical to inspect the current plan in phases or only weeks/months into the future as appropriate to the overall duration of the project.

Reviewing a project plan in this manner can sometimes be seen by some as needlessly criticising the plan. I remember once being accused by the owner of a project plan of having a “negative attitude”  when challenging aspects of the plan. My response to this was to explain the benefits of taking a risk-based approach to project planning – I was looking for where the plan did not take probable failure into account and that if you don’t actively try to avoid failure you are inviting it to the table. After a short conversation, it clicked for him that it was basically a perspective shift, in the same way having as diverse a team as possible when creating a plan is to avoid inherent biases and perceptual blind spots. Changing perspective when reviewing a plan shows it in a different light.

Another form of proactive planning is in the form of contingency plans or predetermined fallback positions. It is not necessarily appropriate for every project but in my personal experience, it was used to great effect in an organisation I worked in responsible for releasing maintenance software updates for global telecoms network equipment. We had multiple product families/tracks in operation in parallel (between 3 and 5 at any one time) with 4 products in each family. We had an interweaving release schedule with the most frequent releases on the newest product family and the least frequent on the oldest product family. This means we usually had 2 releases a week, sometimes just one, and painfully 3 at times. Due to this tight and interwoven schedule, any delay to a release was a big problem as it would very quickly impact the next release in the cycle, if not multiple releases.

As a result, we devised contingency plans, timelines for critical activities, the structure of firm go / no go decisions, and defined approaches to salvaging/sacrificing planned content, automatic kick-off of specific troubleshooting activities depending on the type of issue. This also included what to do if we delayed a release and the absolute cut-off point at which we would cancel a release and fold planned content into the next release on that track. This meant we had a readymade playbook to work from when a release blocking issue arose. Time was not lost debating which path to choose, stakeholders were informed with pre-agreed information by designated points of contact. An agreed schedule of updates kept stakeholders informed and in the loop at all times with the current status.

The benefit of planning for these eventual failures was that we quickly reacted in a coordinated manner in a minimum of time. No time was wasted debating the pros and cons of one choice over another, no time was wasted as one subsystem pointed fingers at another, and no time was wasted as test resources needed for critical testing were reconfigured or handed over to another test activity. As a result of this effort, 95% of releases were on schedule, 98% of the ones delayed were released within one day of the originally planned schedule, and 98% of the originally planned content was included.

Planning for failure (how to avoid it preferably!) is as important as planning for success. Ideally, failures should not occur, but if you embrace that some failures are probable, maybe even inevitable, then planning for failure in advance puts you in the best position to deal with failure.

To find out more about our Project Management services or seek advice on an upcoming project, contact the team today.