Select Page


Who Needs Risk Management? – Part 2 – Risk – A combination of Art and Belief
By Adrian Abramovici

Yes, there are lots of horror stories about projects run without risk mitigation and their spectacular failures, but what about all those “other” projects run by those same people that had the spectacular failures (or their contemporaries and peers in thinking), and which did NOT fail, despite not having had “formal” Risk Mitigation?

And how efficient IS Risk Mitigation after all? How much should we spend on it for best returns? To the best of my knowledge, there are no metrics showing Mitigation efficiency, or at least I could not come up with any from searches or personal experience.

In short, would it have happened to YOU and your project, in your circumstances and with your Risks? Let us look for a moment at those “old style” Project Managers – did they really NOT use modern Risk Management techniques..?

Well….. Most of the basic Risk Management techniques are really “basic instincts” for both the “creators of things” (the engineers, for example), and the “managers of the creative effort” – the ones we call Project Managers. I mean, ultimately, both groups want to create a product that works. Therefore they will design, and manage, in a manner that will attempt to ensure that within reasonable circumstances and based on their experience they will complete their project as promised and deliver a product that works.

In doing so, they will take normal precautions against known (from experience) problems they may encounter, technical or otherwise. In other words, they ARE, instinctively, doing basic Risk Management, even if they do not call it that and do not follow a formal process in doing it.
Hmmmm! So, was my boss right? Or better yet, how wrong was he?

I believe that three major changes have happened over time to force us away from an informal and towards a more formal risk management process: the complexity of our projects has increased, the circumstances in which we manage these projects have changed, and the experience project managers bring to their jobs is different. Let’s look at them one by one.

Technological Complexity

At one time, a Project Manager could be expected to be familiar with just about every thing his workers had to do, and if not be their ultimate expert in every field, at least be able to provide guidance and advice, having done it himself in his past.

However today’s projects are, on the average, more technically complex than anything we have ever done in the past. Fact of life, the technology has advanced by leaps and bounds. Therefore, the Project Manager has to rely more and more on outside experts whenever problems beyond the ability of his direct employees arise, or whenever he feels he or she needs a sanity check on the solutions his own people are providing. The PM does no longer have the expertise to fully be judge and jury for all aspects of his or her project, and a more formal process of peer review of ideas and solutions is required to enable him to properly manage project risks.

The Project Environment

In the past, project managers had a relatively simple environment to work in and with: a Customer, a Boss, and a bunch of workers.

The Customer, in most cases, told you what they wanted and by when, and once you delivered it, they paid you. Little other interaction happened, and usually very little technical meddling.The Boss took his cut of the money, then told you to go do it – and if you didn’t, he fired your tail. And the workers – they actually did what you told them to do, or you fired their tails. Well, things have changed.

The environment in which today’s Projects are being run is much more complex than in the past. There is way more interaction between the Project and its environment (customers, sponsors, regulation, competition, “acceptable” human relations practices, you name it) than on projects in the past.

Customers have, in many cases, whole engineering departments overseeing your project, they need a constant stream of information, and they need “managing”, or else the project scope will get out of hand in a jiffy!

Sponsors (read: Bosses) don’t just demand results, they also want you to report to them every which way from Sunday. And they still can, and will, fire your tail!
As for the employees, well, how does “empowerment”, “teamwork”, “team building”, “consensus management” sound to you? And if they don’t live up to your standards, usually just getting them off your project is a ten step process ….

Add to all that the fact that the complexity of many projects has increased by orders of magnitude over anything we have done in the past (think number of subsystems, number of parts, global sourcing, co-operative development between sites spread across continents and time zones, specialization of suppliers, and so on..), so that again, basic instincts just can’t cover everything.

In other words, the environment changes have, in many cases, “outgrown” the capability of single individuals, gifted as they might be, to just instinctively do the right things. We need to either specialize in many new things, or rely on specialist advice.

“Only two things are infinite, the universe and human stupidity, and I’m not sure about the former.” Albert Einstein


While in most cases Project Managers of the past were grizzled veterans who’ve seen it and done it all, many of today’s projects are staffed, or led, or both, by less experienced or “well rounded” people.

No insult intended – it is just a fact of life – pure economic expansion has multiplied the number of Projects concomitantly being run in our society, as well as their technical complexity, therefore outstripping the number of experienced resources available.

Our people are much more specialized when they start out, and when promoted to leadership roles, might not have the background and knowledge in all the fields in which their Project is dealing. Small Projects might deal with a single discipline and associated environments (say, a small software project), but most of us have to handle complex, integrated projects in which disciplines we sometimes haven’t even heard of before must be dealt with.

To put it differently, all of you who have done everything and know it all, from requirements development through testing, from Finite Element Modeling through thermal analysis, from real-time control models to composite fatigue tests, from ASIC design to FPGA programming and writing some ADA code in between – OK, you are excused from reading the rest of this blog!

In summary: as always, risk management is aimed at reducing the impact of unforeseen events unto the project. That much hasn’t changed! However, given the advances in technology, the changes in project environment and applicable rules, and the decrease in experience of the average Project Manager due to explosive growth in number of projects (and project managers), the capability for mistakes increases, the level of “foresight” decreases, and the “basic instincts” of the Project Managers are just not there, or not enough anymore.

So – back to the Question – Is it WORTH IT? To Do or Not To Do?
Here I am, with my under-funded, “success oriented” Project on Day One. I am being told that I should look at Risk, and that I should allocate budget to it. I know that for some items I should invest in Mitigation Activities – but can I afford to? And can I afford NOT to? And how much should I spend – how much is too much? Should I just put a buffer (money and schedule) in my plan, and pray real hard that I might just get away with it?

I believe Project Managers have ALWAYS done Risk Management – informal in the past and more formal today. Therefore the present day emphasis on Risk Management as a Project management technique is nothing new – merely a more formal approach to an old management technique. While there are no numbers to show why you should use Risk Management on your specific project, or to show how much you should spend on it – just think that if you DO NOT do it – YOU are the one that “breaks the chain” – Risk Management has always been part of Project Management.

Risk management is made by many to sound as if it were some scientific methodology – it isn’t. Risk management is a combination of art with belief on a solid foundation of experience…. Art – because despite the probabilities, formulas and graphs, it all boils down to unverifiable estimates and judgment calls. Belief – because nobody knows what would happen if you would NOT do it, or at least not for the specific Risk you are dealing with, and no one is willing to….. risk finding it out by NOT implementing Risk Mitigation…

Therefore my own, personal ground rules at project start are simple:

Murphy is alive and kicking…. despite anyone that thinks otherwise! So I just do it!
In order to decide how formal a Risk Management process I should follow, I look at the Project Environment and Project Team Experience. For a small, simple, isolated, fully defined project, one I have managed many like it in the past, one staffed with experienced people (again in same or similar work) – I might just rely on my own, and my team’s experience, use the back of a (few) envelope(s) and forget about formality.

But if one or more of these assumptions does not hold true, I will start to involve more players and ratchet up the formality of Risk management…. How much? Well, that is one of your Homework questions… Personally, though, I never went for the three decimal prediction accuracy….

Adrian Abramovici is, after more than 25 years of aerospace project management, an executive in the rail transportation industry based in Toronto, Canada. He is writing about his experiences and views on Project Management, Risk Management and the day-to-day frustrations and successes of leadership at

Recommended PM App

Recommended PM App