Schedule Risk Analysis (SRA) is great – but like all great things, it’s best in moderation.
About a year ago I recall having a conversation with one of my former colleagues, Phil Jakubowski, about his experience of working within Land Command. He introduced to me the idea that managing a project is much like managing a battlefield; battles are not necessarily won by whoever has the best weapons, but by those who gain “information superiority”.
The idea of a war game may not seem relevant here, but when you think about project management, and in our case more specifically risk management, it becomes extremely tangible.
Let’s imagine a scenario, with a battlefield that could look like this:
There is uncertainty between you and your target; who they are, where they may be travelling, what weapons they have or indeed whether they are your primary target anymore. Defeating them is your objective. You have a military platform and supporting platform you can deploy to defeat them, as well as surveillance and target acquisition capabilities. You have training and logistics to help you too.
A project, in much the same way, has an objective you need to achieve (your target); human and physical resources to deploy (your military capability); and decision support techniques to monitor progress and direct action (your surveillance and target acquisition). Logistics and training are still required.
The battlefield now looks like this:
By taking this different perspective, the role of risk management (or in this case, uncertainty management) becomes more interesting. It becomes obvious that uncertainty exists between you and your enemy – the better informed you are as to their movements, and the quicker you can adapt, the more likely you are to defeat them. The military refer to this as “remaining inside your adversaries’ decision-making cycles”.
Project managers must also strive for this information superiority. If you think about scheduling, earned value management, risk management, budgeting, benefits management (to name but a few) they are all forms of decision support which assist in information superiority. The better you are, the more likely you are to defeat your objective.
Consider this concept from a specific risk management perspective. Over the years I’ve been very encouraged to see the rise in the use of schedule risk analysis (SRA) as a means to achieve information superiority in projects. It is a great way of testing the validity of schedules and dates, to understand which risks or uncertainties could be threatening our project and to test the effectiveness of our action plans.
However, I’ve also seen that this rise in SRA deployment has led to a form of ‘over analysis’; that is, a tendency to polish a model within an inch of its life. Increased functionality in project risk software and growth of risk management personnel can, perhaps oddly, result in SRA models that reduce in value the longer the time spent building them.
I think SRA is great and I’m certainly not knocking it, but the point is that too much SRA does not necessarily give a more useful result. Remember the idea of staying within our enemies’ decision-making cycles? A very thorough SRA takes time, and often by the time the model is built, run, discussed and tweaked again – the target has moved. You are now making decisions based on information that may no longer be relevant.
Of course, this will always be the case, but how can we mitigate this problem?
I think the key is to understand what you want SRA to do, and who your audience is. Some of the most useful models are the simple ones, that help determine with some speed yet reasonable accuracy the validity of a project schedule, importance of various risks, chances of making key project dates or even whether a particular scenario is ‘less risky’ than another. Think of it in terms of the Pareto 80/20 principle.
When I presented this concept at Forum Safran in October 2016 in Stavanger, I drew the following graph which showed the Law of Diminishing Returns:
The value gained early on in constructing SRA models and running early scenarios, often far outweighs the additional value gained by spending that length of time all over again by making tweaks to the model. Why do SRA if you’re not actually helping the battle commander catch their target? Surely it is better to derive a useful answer that delivers intelligence on your target’s next move, rather than the perfect answer on where they were the week before?
This won’t be the case in all SRA activity, but my point is to appreciate what sort of decision you are trying to make. Often taking a long time building the model means that the relevance of the result is, well, no longer relevant.
What do you think?
With acknowledgements to Phil Jakubowski of Jakubowski and Associates Ltd for the initial discussions used in this article, and to Babcock Information Analytics and Security Ltd, who helped draw the battlefield graphics.