A simple tool that helps IT Project Managers succeed

- Imagine you are the captain of a spaceship. You are traveling faster than the speed of light in a very unpredictable and ever changing environment. Unexpected things like asteroids, hostile aliens, black holes and spaceship malfunctions may happen any second. You try to make sure that this journey goes smoothly, so you follow a robust risk management protocol. And yeah, spaceships still use Google sheets for critical operations. But there are hundreds of risks and they change all the time. The

next moment, boom, you hit the asteroid, you are dead. My very last project was very similar to that. Everything changed so fast, no one had time to do proper risk management, so I had to use something different to ensure that we finish projects on time. In this video, we'll talk about an alternative risk management tool. I'll explain why it's better for some small or even large projects, and in the end, I'll give you my template if you want to try it out. But first of all, what's the main prob

lem with a typical risk management approach? You see, you need to identify all the risk, perform the risk analysis, and write them down in the risk register. By the way, a risk register is a spreadsheet where you capture all non-project risks, which may look like this, and it's a centerpiece of the whole risk management framework. As a result, the main problem is that a risk register contains all known risks. And you can imagine there might be hundreds of entries here, and risks will have differ

ent levels of details. Some will be fully explained, some will have only titles, so it's a permanent work in progress state. That's why people other than project managers have difficulties using risk documentation. Instead, a project manager needs to spend a lot of time to extract digestible information from it, and sometimes it's too slow. At the same time, the risk register is only about risks, but in many cases, stakeholders need to see other aspects of a project side by side with the risks.

So returning to the space travel analogy, we need something that gives us actionable information at a glance. We need a dashboard with top priority problems. That's why you may consider using the RAID log on your project. It's a tool that combines risks, assumptions, issues, and dependencies on one screen. So again, think about it as a dashboard for your project. Bring it up during every meeting and keep everyone focused on the main challenges. Now the main question is how do you actually use th

e RAID log in project management? Also, you must understand one critical distinction between the two main sections of this tool to make it work. So first of all, we have risks. These are your typical risks as you would put them in the risk register. So risks are negative things or threats that could cause trouble to your project if they happen. Next, we have assumptions. These are the things you believe to be true for your project, but you cannot verify your beliefs right now. After that, we hav

e issues and these are the problems you are facing right now. You must fix them as soon as possible, otherwise your project will go off track really fast. Obviously, risks, assumptions and dependencies may transform into an issue, and in this case, you'll move them into this section. In the dependencies section, you list out all the deliverables that other teams or third parties need to produce, and some parts of your project depend on those deliverables. Now, many people have the same question.

When you put these things side by side, what's the difference between risks and assumptions? And it's a good question. It's a critical concept. You must understand. It's often the reason why projects fail. Imagine you are planning a big outdoor picnic in a park. So in this case, you may have a risk of rain. The picnic will happen if it rains, but people might be unhappy about the whole experience. But at the same time, somewhere at the start of the project, you'll have to make one critical assu

mption. You are forced to make this assumption because, for example, your kids demand a picnic in the park and it's the goal of the project. So the assumption is that the park will be available for the picnic in the first place. For example, there won't be any significant events on the day and the park won't be overcrowded. Obviously, if this assumption proves to be wrong, the picnic won't happen at all. But we have to make this assumption to do some planning and see if it's feasible to organize

the picnic with some other constraints, for example, with the available budget. And again, if it's not feasible for other reasons, then the availability of the park, we may have to cancel the picnic and start a backyard barbecue project instead. But we want to do it before we invest resources into the picnic project. So that's why we must keep track of all project assumptions and work really hard to verify them. And by the way, I made an assumption that you will click the like button at this po

int. Otherwise, this video will not reach all project managers in the world. Thank you in advance. Alright, I hope you see why putting this information side by side is so powerful. These are the primary sources of the most crucial project risks. But now you ask yourself this question, when is it better to use a RAID log and when is it better to use a risk register and dedicated assumptions list? In most cases, a small project with about one or two scrum teams will benefit from the RAID log becau

se it's one tool, you can easily integrate into any agile framework and add proper risk management. Large projects will benefit from the RAID log, but only as an additional reporting tool. In practice, you will have a dedicated risk register, but you will summarize the most critical information in the RAID log for executive meetings. So use it when stakeholders need a spaceship dashboard to focus on the most critical aspects that you cannot solve alone. But for the same reasons, the RAID log may

not be a good option for a mid-sized project because on one hand you do need a dedicated risk register, and on the other hand, it's an additional tool you must maintain. So you must consider pros and cons for your specific project. But here's the main problem. The RAID log is just one tool in the risk management framework and in the real world, the framework and the workflow is really messy at best. That's why before you make any decisions about the tool, you should watch this video next where

I show how to deal with risks in a real world scenario. You'll also find all the templates there. Click the video now and master all aspects of risk management. See you there.