This article is aimed at Junior level PM’s but none-the-less; it’s a critical component of the PM’s responsibilities and is often overlooked to the detriment of Projects !.

Logs are among the simplest but most valuable tools of a project manager. Basically, a log is a list of items with key pieces of information for each item. The use of a log includes the following benefits :

  • To help the project team remember
  • To provide a visible way of verification
  • To give each team member an equal chance to raise a concern
  • To guide the focus of a meeting or discussion
  • To help the project manager monitor progress
  • To be proactive
  • To document resolutions


One important project management log for managing issues and risks is the RAID log. Projects will always have issues that arise during the execution of a project. And risks are issues that have not happened yet. A RAID log helps keep track of the risks the team foresees as well as the issues that arise.

What is a RAID log?

A RAID log is a project management tool where the project manager logs, documents, or tracks the risks, assumptions, issues, and dependencies of a project. One variation of the RAID log substitutes ‘actions’ for assumptions, and ‘decisions’ for dependencies. Another version combines them to form a RAAIDD log. The version that a team uses will depend on what they consider more helpful in managing their project.

Why should you use a RAID log?

After the project planning phase, the project execution phase begins. Happening at the same time is the project monitoring and control phase to measure performance and progress if everything is proceeding according to plan. A RAID log is an effective tool to track risks, issues, or any other event or circumstance that can affect or influence the project. Examining the items of a RAID log can show its importance.


A risk is an exposure of the project to an uncertain future event that may have an impact on the project’s completion. A RAID log lets the project manager identify probable risks and the events, situations, or activities that either increase or decrease the chance of the risk from happening and becoming an issue. Aside from the likelihood of happening, the project manager can also asses the severity of the risk, and plan for the resources and actions to minimize it.


An assumption is a supposition that a piece of information is true, because there is no evidence at hand that shows it is not. A project manager may assume that something will stay the same or something will eventually change as the project team proceeds to execute their tasks. It is important to review or track if assumptions still hold true. Once assumptions are proven to be false, changes in the plan and the execution should be made.


The other A stands for action, which is needed to complete a task or to respond to an issue. The action needs to have an owner who will complete the action by a certain time or date. The project manager can track and note the date the action has been completed, and if it needs a follow-up.


An issue is a problem that occurred and needs to be clearly identified. It may affect the project in various ways, such as prolonging the completion, delaying its progress, adding complexity, requiring additional resources, and others. The project manager needs to track all issues, their severity and impact, and communicate how they are being managed and resolved.


A dependency is a required project item that must be completed in order for the plan to proceed unimpeded. It can be a deliverable, a resource, a normalized condition, a pending approval, or something else. Whatever it is, it must be delivered or presented for the project to proceed. The project manager should monitor all dependencies, help obtain faster delivery on them if possible, and communicate with stakeholders how they are managed.


The other D is decision, which the project manager should record all that were made during the course of the project. It is a reference and should include information such as who made the decision, when that decision was made or implemented, and the justification as to why it was made.

How to implement a RAID log in your current process

Use a spreadsheet or specialized project management tool to maintain your RAID log. Organize the log according to the items or topics it tracks. Each topic can have its own tab. The project manager maintains the log and decides the level of detail each item in the log will have.

The input to the log can come from many sources, such as the project sponsor, team members, users, partners, vendors, contractors, and other stakeholders. Additionally, documents from other similar projects can be considered a source.

Create the RAID log during the initial planning phase. You can update it during regular meetings. The frequency of the updates may vary from topic to topic, depending also on the nature of the project. For example, risks and assumptions should be updated at least once a month, more often if possible. Actions, like project tasks, may need updating daily. Issue updates also depend on the severity of the issue, and usually require the corresponding update of the corrective action. Dependencies and decisions also need to be updated as needed, at least once a month.

Potential pitfalls to look out for

For the busy project manager, the RAID log is a shortcut for organizing information and maintaining control of some of less visible parts of a project. However, as a shortcut, it should not be considered as the single complete source of information.

A RAID log is only as current as the updates it receive. If it is outdated, then the information it provides will not be reliable. If you spend too much time updating your RAID log, you may miss out on other important responsibilities. Delegate some of the updating responsibilities to your team members who can change certain areas of the log according to their role. Use modern tools like project management software.

Review periodically not only the items you have identified, but also your definition of risks, assumptions, issues, and dependencies. And do not forget to make a final review at the close of the project.