Tanner James Blog

Why i Don't Care for Risk Theory

Matt Overton

“Risk, what is it good for? Absolutely nothing, say it again,” as Edwin Starr never sang.

But, a bit like insurance, risk is one of those things that you wish you’d paid attention to after the fact. And it is a vital component of project and programme management regardless of the mental model you bring to the subject.

From the Australian Qualifications Framework (AQF) side of the house (and influenced by the PMBOK Guide), risk is a mandated core unit in BSB51415 Diploma of Project Management in the form of BSBPMG517 Manage project risk. For BSB41515 Certificate IV in Project Management Practice, it’s a Group A elective unit (BSBPMG415 Apply project risk-management techniques).

From AXELOS’ perspective, it’s a (governance) theme in MSP and PRINCE2 and influences its respective principles. Risk – or rather its management – can be a significant reason in your justification for setting up a P3O and the risk role can provide your organization with functional expertise that might be shared at the project, programme and portfolio levels. It’s a process perspective in the P3M3 framework also.

Risk is also an ever-present component in ANAO Better Practice Guides, among them Planning and Approving Projects – an Executive Perspective: setting the foundation for results, Commonwealth of Australia, 2010, and Successful Implementation of Policy Initiatives, Commonwealth of Australia, 2014. (One of my axioms is that they might be better practices, but what argument could you possibly advance not to follow government-endorsed advice?) So, rather than what is it good for, maybe the question would be better articulated as: why should risk matter to you, the practitioner?

The answer is: because you need to do something about it. This component was writ large in the Report of the Royal Commission into the Home Insulation Program (Commonwealth of Australia, 2014). Chapter 14 detailed the lessons learned; along with addressing the capacity of Commonwealth agencies and staff to undertake projects and programmes (section 14.2), emphasis was paid to the importance of risk (section 14.7). In particular, it pointed to the significance of having a functioning risk management process and for staff to be able to use the process.

And what about risk’s sometimes unloved and neglected cousin, issue? While I’m sure (I hope!) we all know the theoretical difference between a risk and an issue, in practice I don’t think it matters. I have been asked countless times whether you should have a combined or separate approach to risks and issues. My stock answer is: I don’t mind. I’d like to believe that your delegate feels the same way. The requirement is to have something; the unit of specification (separate? combined?) can be managed and decided at the task level rather than the escalated level. That said, another of the conclusions from the HIP Report (section 14.7.4) was that risk is holistic. Rather than it being the domain – or for the protection – of senior officials and the Minister, or for reputational and political purposes, risk impacts policy, business-as-usual and projects, and all of those people who are involved in these areas.

Accordingly, accepting this advice on face value, you should forget about which flavour of project or programme management philosophy you prefer. You need to ignore the delineation of whether the item under discussion would be better located in the risk management strategy rather than in the risk management plan. Instead, your approach to risk should focus on something that is usable, flexible and extensible, and at an appropriate level of specificity for the project/programme team, management and corporate governance. Far better to have something that is used and flawed (and can be improved) rather than a product that is robust, complicated and sits on the shelf. My view is that while it is great to have a comprehensive risk strategy, I would trade off some of that ‘great’ to have a good – think functional – risk management process that everyone knows and, even better, has adopted. Then you can join it up to the rest of your project and programme management framework as your maturity increases.

So, I started off opining that, for me, risk didn’t matter. Of course, it does, but more in practice than it does in theory. As a practitioner, trainer and educator, I’m more far more interested in the practicality of application (and response!) than I am in an esoteric discussion of perspective and approach. Perhaps that’s the lesson to learn in preparation for when your delegate asks you how confident you are of managing, mitigating and recovering from the situation in which you find yourself. Good in theory, better in practice...

Click here to access Tanner James’ collection of templates, which includes examples of a Risk Management Strategy, Issue Resolution Strategy and Risk Register and Issues Log for MSP, and a Risk Management Strategy and Issue Report for PRINCE2.

Process maps, explaining how risk and issue management fits in to both MSP and PRINCE2, along with their supporting documents, may be found here.

Matt Overton is a Principal Consultant and Trainer with Tanner James Management Consultants. He has spent the last 20 years delivering risky projects and programmes in the UK, the USA and Australia. Matt is an AXELOS MSP Accredited Trainer and PRINCE2 Registered Practitioner. He is an accredited trainer and assessor in the Diploma of Project Management and Certificate IV in Project Management Practice under the Australian Qualifications Framework. He welcomes feedback to the issues (pardon the pun) he’s raised and invites you to suggest subjects for future consideration.

How to Handle Project Issues

Daniel Oyston

This is a guest post by our good friend Gavan Murphy.


We’ve all got them, and projects are no different. They’re like weeds - you can pretend they don’t exist until they take over your garden (or project).

Some projects are so dynamic there’s a multitude of issues to juggle on a daily basis. Other projects work at a different pace, or have much longer time frames and potentially fewer issues.

Regardless of the style of project you’re running, a Project Manager ignores issues at his or her own peril. 

Don’t fall into the traps

Like most things in life, the more mistakes you make experience you have the better you become at noticing the weeds in and around your project environment. Don’t fall into the trap of thinking that lots of project issues is a bad sign for your project.

Nor is the opposite true, that few issues means the project is running well.

It’s ultimately your judgement, responsibility, and dare I say it, honesty as a PM what you choose to notice, raise and manage through to resolution.

How do you tell if you’re dealing with issues effectively?

Three measures I regularly use are:

  • if I can’t succinctly tell a stranger what the three major issues I’m dealing with on a daily basis are, I’m not on the ball;
  • if I wake up in the middle of the night thinking about work, whatever it is that woke me up is an issue that needs some (more) attention; and
  • if an issue hasn’t been updated in more than a month, I’m in denial or it’s not really an issue.

I’ve also discovered, the better systems I have in place for managing issues the more willing I am to be honest about them.

Make sure all the verbs are covered

From the good book (PRINCE2) your issue management system needs to cater for all the verbs: 

  • capturing;
  • describing;
  • prioritising;
  • assigning responsibility;
  • monitoring;
  • reporting;
  • resolving (as quickly as you can); and
  • escalating issues if they get beyond your remit. 

The importance of software

I’ve been using Atlassian’s JIRA for managing my project issues for more than 18 months now. In short it’s brilliant! It handles each of the issue management verbs competently, except automatically recording issues for me J.

There’s a large number of tools available for PMs to use, but issue management software is one of the most important in my opinion, because it will do all the heavy lifting for you.

If you have the discipline to capture and update issue details then:

  • reporting becomes pain free;
  • prioritisation is much easier because you can see all the issues in one place; and
  • escalation is a matter of assigning the issue until resolved.

Using an issue management tool leaves you free to focus on project delivery - the stuff you get paid for!

Garbage In and Garbage Out

Of course the old adage applies: garbage in and garbage out. Your issue management system won’t replace face-to-face conversations or the need to wear out shoe leather engaging those involved in issue resolution.

But it does record history, reduce email spam, diminish finger poking and blame. If used effectively, it makes people accountable for their part - you included!

Effective issue management won’t necessarily guarantee a successful outcome for your project, there’s a lot more to it than that. Some project issues are so intractable, for all sorts of reasons, that they require constant advocacy and energy on your part to get them resolved.

However without a willingness to tackle them, or get a handle on their management, it will be increasingly difficult to see the garden for the weeds.

What approaches work best for you with issue management? Have you got any horror stories to share?


Gavan started his passion for Project Management 20 years ago, initially in engineering projects, and then following his interest into ICT communications, infrastructure and software development projects. 

He has a knack for building high performing project teams and when given enough rope, has delivered some really challenging project outcomes. Most of his project success has come from a preparedness to learn (and learn fast), anticipate where things are heading, diligence and seeking out opportunities to build strong working relationships. 

He shares common sense insights based on his experience, hard knocks and snippets of brilliance he has picked up from other PMs along the way.