The principal risk management tool for project managers is called your risk register or risk log. And it is a schedule of all the risks you've identified and key information about it. The best software tool to use for most of us is a spreadsheet. For very simple projects or a table using Word Processor or even a drawn out table in your notebook will suffice. Only the very most sophisticated projects use database tools for their risk management. Now a risk log fulfills two crucial purposes.

And as far as any documentation on the project can be justified to be mandatory. I would That risk log to have the primary place here. Because of course, you are hazarding your organization's reputation, its time and its money. And so you have to have a process of transparency and accountability. So the first purpose of a risk register or risk log is to create a document of record an audit trail that shows you diligently identified the risks, evaluated their priority, put together appropriate plans, and taken action, and review. And the second purpose is to have a management tool that allows you to see what risks remain on your project, and therefore to make choices about how you're going to manage them day to day is a document of record.

Therefore, each risk that you identify needs a unique ID number, a unique reference number that stays with that risk and if that risk of retired for any reason And then clearly that number needs not to be reused. I would say that there are a range of risk registers around from the startlingly simple to the astonishingly complex. My guidance to is this, go for the simplest risk register that meets your needs, because the more complex it is, the more off putting it's going to be to use. So don't go for a risk register that has loads of fields that you know, you're not going to use because they're a bit too sophisticated for your project. far better to use a small number of fields quite a small number of small amount of data and do it well than to not do it. So if you need to just hide or don't use fields that are not relevant.

But I would say there are some fields that you're always going to have a unique reference number or risk name, and I would separate the name of the risk from a long form description. Because just a simple description of the risk means that he may not be clear, what precisely is the problem. You need some sort of evaluation of the risk. And typically, that's going to be an assessment of the likelihood and an assessment of the impact. You may also have on there and assessment of the proximity. If this happens, it's gonna happen within three weeks, or within three months, within three years.

You may have some sort of overall score or priority for the risk even if it's only red, or green. And crucially, you must have a list of the actions you're going to take to manage the risk. Identify who has been allocated the responsibility for taking those actions, and review point and good risk register will allow you to keep a running record of the reviews and to track the reduction in likelihood or the reduction of impact from the results. There's going to be some way of recording whether the risk is open and still a threat or closed and no longer considered to be harmful. Some people will have a separate issue register, but a definition of an issue is a risk that is actually going to happen. It's a risk with a 100% likelihood.

And so for me, my preference is to keep risks and issues on the same log and just identify issues as 100% risks or as issues, then you don't have to get get into the the problem of transferring a risk, which has materialized onto another document, as an issue actually seems to be a waste of time that you could spend actually managing the issue. And I'll be making available to viewers of this course, risk register templates that you can adapt to your own purpose. So a risk register document of record. Yes. And also in management tool. When I'm managing projects, I will frequently look at my risk register, I will actually have a regular cycle, maybe daily, maybe a couple of times a week.

And I'll take a cut from that risk register, and then go and speak to the people who are allocated the responsibilities to find out what progress they've made, what support they need, what resources they need, and how that risk is moving. And then at a slightly less frequent period, maybe on a fortnightly or even monthly basis. I'll get some team members together representing different areas of the project, just to brainstorm if any new risks have a reason that we need to be managing. Risk management needs to be a proactive activity. And indeed, as some project managers would say, risk management is how grownups manage projects. And my interpretation of that is that experienced project managers know how to define a project they know how to create a plan.

They know how to manage your team. We do that. The one thing that remains that we have less control over than anything else are the uncertain things that are risks. And so experienced project managers put a lot of time into staying on top of their risk management associated