Working on projects can be a tricky endeavour at times. As business analysts, we are often balancing the perspectives of multiple stakeholders whilst also working within strict constraints of time or budget. We collaborate and innovate to help ensure our projects and initiatives deliver solutions that enable value to be delivered within our organisations and enterprises.
Yet things rarely seem to go smoothly. So many things can go wrong in projects—perhaps a process or system is far more complex than we anticipated. Or perhaps an external environmental factor (such as a law) changes and has a knock-on impact. If we are working on an experimental or cutting-edge project then the risk might be very high indeed. We may sometimes be pioneers, travelling through unchartered territories, and we might not even be able to predict what the risks are (let alone mitigate against them!).
In situations like these, it is valuable to consider contingency planning. In doing so we ask questions like “What do we do if something so unexpected and so disruptive happens that the project is no longer viable?”. Yet the very idea of contingency planning is seemingly controversial. I recently saw a very interesting discussion on an online forum, and a view was expressed by a number of participants which I have summarised below:
“We shouldn’t ever think or even talk about contingency planning, definitely not on large scale radical projects. Success is the only acceptable option. If we let people know there’s a ‘Plan B’ they won’t buy into ‘Plan A’ and we’ll never succeed as they bale out too early. Set out to succeed, or don’t set out at all!”
At first glance, this seems like a rational perspective. Indeed, there were others on the forum explaining that they like to have secret contingency plans that they only communicate if there is a need to use them.
Yet both of these views raise some interesting questions. If people aren’t bought into ‘plan A’ then there is a fundamental engagement problem—and if you have to keep your escape plan secret then there’s a danger that you won’t get the valuable input that is needed to make it as robust as possible. So perhaps the very temptation to avoid (or hide) a contingency plan is an early warning sign of engagement issues that could ironically lead to project failure anyway.
I was mulling over these ideas on a recent flight. As anyone who has ever flown will know, prior to take-off, the cabin crew do a safety demonstration—typically showing how to use the life-vests and oxygen masks. There is also a safety card in your seat pocket showing the ‘brace position’ that must be adopted in the event of an emergency landing.
Now, I don’t know about you, but as a passenger on a plane, I am very much bought into “Plan A” (safely landing on tarmac at the destination airport). But I also feel re-assured that somebody has thought about a whole range of contingency plans, and that there is an expertly experienced and qualified pilot in the cockpit calling the shots. If a pilot came over the public-address system and said “we’re running late and we don’t plan to crash, so we’re not doing a safety demonstration” I would be very unsettled. If he went on to say that all the life-jackets and oxygen masks have been removed, I’d be very worried indeed.
Air travel is probably the safest form of travel that there is. Yet still, even though the chances of failure are so low, contingency plans have been well thought through and are briefed prior to take off. Surely we should consider similar exit plans for our major projects too? And we should get equally worried if none have been considered?
Now, I know what you’re thinking: “But aviation accidents are life threatening, projects aren’t”. But is that really true? What about the business analyst working on an Electronic Patient Record system in a hospital? Or the BA working to improve processes in an air traffic control centre? Or the BA working in a bank on a currency transfer system (which, if it fails, could have a knock-on impact for life-critical services throughout the economy). So often our projects are more crucial than it first appears, and our analysis helps build the quality in from the very beginning.
So, when it comes to contingency planning, having a ‘Plan B’ isn’t a sign of weakness, it’s a sign of cohesive strength. Deciding in advance what we would do and the conditions in which we would trigger it enables us to objectively and dispassionately plan when time is on our side.
What are your views on project contingency planning? Do you have any tips? Please add a comment below, and lets keep the conversation flowing!
If you’ve enjoyed this article don’t forget to subscribe.
About the author:
Adrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.
To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com
Having watched in horror as an Emirates Triple 7 slewed in flames down a runway in the Middle East, dragging it’s detached powerplant behind it like some kind of mechanical puppy. Having then read about the critical 90 seconds that Air and Cabin crew work to when evacuating aircraft. I was amazed that nobody was either hurt nor killed either during the crash. This I do not doubt was down to some serious contingency planning and training. And that’s to be applauded.
What echoes most however were the passengers ferreting about in overhead lockers despite the protestations of other passengers and cabin crew. These passengers remind me of stakeholders on projects. You know, the ones who feel that they can operate outside of the bubble and miss conference calls and webinars at will, that then cry when a decision is made that adversely affects their team.
Sometimes I feel like the firefighters who bravely rushed to the scene to douse the burning aircraft, but without the bravery. Sadly for one man in the Firefighting team it was too cost him his life. One can only presume a contingency plan for the situation he found himself in would have been ideal. May peace be upon him.
Pingback: Eric's Business Analysis Reading List #16 - Eric the Business Analyst.com
Pingback: Project Lessons From Aviation Part 3: Avoiding Communication Overload in a Crisis With “NITS” | Adrian Reed's Blog