✅ RAID Log in Project Management

1. What is a RAID Log?

A RAID Log is a project management document used to record, track, and manage four important aspects of a project:

• R – Risks: Uncertain events that may affect the project in the future.
• A – Assumptions: Things believed to be true for planning purposes but not yet fully verified.
• I – Issues: Problems that have already occurred and require action.
• D – Dependencies: Tasks, activities, decisions, or deliverables that depend on other tasks, people, or external factors.

The purpose of a RAID Log is to help the project team anticipate problems, make informed decisions, assign responsibility, and prevent avoidable delays.

Example: In a software development project, a third-party API may become unavailable, a customer may be assumed to provide requirements on time, a production defect may already exist, and deployment may depend on approval from the security team. These can be tracked in a RAID Log.

2. Why is a RAID Log Important?

• Identifies potential risks before they become problems.
• Records assumptions that need verification.
• Tracks existing issues until they are resolved.
• Identifies dependencies that may delay project activities.
• Assigns clear ownership and accountability.
• Helps project managers prioritize actions.
• Improves communication with stakeholders.
• Supports project reporting and decision-making.
• Reduces the chance of missing important project concerns.

3. R – Risks

What is a Risk?

A Risk is an uncertain event or condition that, if it occurs, can affect one or more project objectives, such as scope, schedule, cost, quality, or security.

A risk may have a negative effect (a threat) or a positive effect (an opportunity).

Example: A third-party payment API may not be ready by the planned integration date.

How to Manage Risks

1. Identify the risk.
2. Assess its likelihood and potential impact.
3. Prioritize the risk.
4. Define a response or mitigation plan.
5. Assign a risk owner.
6. Monitor the risk until it is closed or no longer relevant.

Example Risk Entry

Field	Example
ID	R-01
Risk	Third-party payment API may not be ready on time.
Probability	Medium
Impact	High
Response	Confirm the provider's delivery schedule and prepare a mock API for early integration testing.
Owner	Technical Lead
Status	Open

4. A – Assumptions

What is an Assumption?

An Assumption is something considered true for planning purposes even though it has not yet been completely verified.

Assumptions are often necessary because project planning takes place before every detail is known. However, incorrect assumptions can lead to delays, additional costs, or rework.

Example: The project team assumes that the customer will provide all required business requirements within five working days.

How to Manage Assumptions

1. Record the assumption clearly.
2. Identify why the assumption is necessary.
3. Determine how it can be verified.
4. Assign someone to validate it.
5. Set a verification date.
6. Update the project plan if the assumption proves incorrect.

Example Assumption Entry

Field	Example
ID	A-01
Assumption	The customer will provide complete business requirements within five working days.
Validation Method	Confirm the requirements delivery date with the customer.
Owner	Business Analyst
Verification Date	End of the first project week.
Status	Pending Verification

Important: If an assumption is found to be false, assess its impact. Depending on the circumstances, it may create a new risk, become an issue, or require a change to the project plan.

5. I – Issues

What is an Issue?

An Issue is a problem or condition that has already occurred and needs to be addressed.

Unlike a risk, which describes something that might happen, an issue describes something that is already happening or has happened.

Example: The payment API integration has failed because the provider's authentication endpoint is returning errors.

How to Manage Issues

1. Describe the issue and its impact.
2. Assess its urgency and severity.
3. Assign an issue owner.
4. Define corrective actions.
5. Set a target resolution date.
6. Escalate if the issue cannot be resolved within the agreed authority or timeframe.
7. Verify the solution and close the issue.

Example Issue Entry

Field	Example
ID	I-01
Issue	Payment API integration is failing because the authentication endpoint is returning errors.
Impact	Payment testing is blocked.
Priority	High
Action	Contact the provider, investigate the authentication failure, and test a workaround if approved.
Owner	Backend Developer
Target Resolution Date	Within two working days.
Status	In Progress

6. D – Dependencies

What is a Dependency?

A Dependency is a relationship in which one task, activity, decision, or deliverable relies on another task, activity, decision, or deliverable.

A dependency can be internal to the project or external to the project.

Example: The deployment team cannot deploy the application to production until the security team approves the release.

Common Types of Dependencies

• Finish-to-Start (FS): Task B cannot start until Task A finishes.
• Start-to-Start (SS): Task B cannot start until Task A starts.
• Finish-to-Finish (FF): Task B cannot finish until Task A finishes.
• Start-to-Finish (SF): Task B cannot finish until Task A starts. This relationship is uncommon in typical project schedules.

How to Manage Dependencies

1. Identify the predecessor and dependent activity.
2. Determine whether the dependency is internal or external.
3. Confirm the expected completion date or required decision.
4. Identify the person or team responsible.
5. Assess the impact of a delay.
6. Monitor progress and follow up before the dependency becomes a blocker.

Example Dependency Entry

Field	Example
ID	D-01
Dependency	Production deployment depends on security approval.
Dependency Type	External to the development team's direct control.
Required By	Before the planned production release.
Owner	Release Manager
Action	Submit the release for security review early and track approval.
Status	Pending

7. Difference Between Risk, Assumption, Issue, and Dependency

RAID Element	Meaning	Example	Main Action
Risk	Something uncertain that may happen.	The payment provider may delay API delivery.	Assess and plan a response.
Assumption	Something believed to be true for planning purposes.	The customer will provide requirements on time.	Validate the assumption.
Issue	A problem that already exists.	The payment API is currently failing.	Resolve or contain the problem.
Dependency	Something that relies on another activity, decision, or deliverable.	Deployment requires security approval.	Track the dependency and coordinate the required work.

8. Sample RAID Log for a Software Project

The following is a combined example of a RAID Log for an e-commerce website project.

ID	Type	Description	Impact or Priority	Action	Owner	Status
R-01	Risk	Payment API delivery may be delayed.	High	Confirm provider timeline and prepare a mock API for early testing.	Technical Lead	Open
A-01	Assumption	Customer requirements will be provided within five working days.	Schedule impact if incorrect	Confirm the delivery date with the customer.	Business Analyst	Pending Verification
I-01	Issue	Payment API authentication is currently failing.	High	Investigate the failure and coordinate with the provider.	Backend Developer	In Progress
D-01	Dependency	Production deployment requires security approval.	Release dependency	Submit the release for review and track approval.	Release Manager	Pending

Note: The entries, owners, priorities, and dates above are illustrative examples. A real RAID Log should contain project-specific information.

9. Recommended Fields in a RAID Log

A practical RAID Log may include the following fields:

• ID: A unique identifier, such as R-01, A-01, I-01, or D-01.
• Type: Risk, Assumption, Issue, or Dependency.
• Description: A clear explanation of the item.
• Impact: The potential or actual effect on the project.
• Probability: The likelihood of a risk occurring, where applicable.
• Priority: The urgency or importance of the item.
• Action or Response: The planned steps to address the item.
• Owner: The person accountable for monitoring or resolving it.
• Due Date: The target date for an action or resolution.
• Status: Open, In Progress, Pending, Escalated, or Closed, as appropriate.
• Last Updated: The date the item was most recently reviewed.
• Comments: Additional context, decisions, or progress updates.

Not every RAID item needs every field. For example, probability is particularly useful for risks, while a target resolution date is especially useful for issues.

10. RAID Log Best Practices

• Keep it updated: Review the RAID Log regularly, especially during status meetings and milestone reviews.
• Assign clear owners: Each item should have a person responsible for monitoring it or coordinating its resolution.
• Prioritize important items: Focus attention on items that could materially affect the project's objectives.
• Use clear descriptions: Describe the situation, its impact, and the action needed without vague wording.
• Track actions, not just observations: Record the next step, owner, and target date.
• Escalate when necessary: Raise significant risks, unresolved issues, or blocked dependencies through the agreed governance process.
• Verify assumptions: Do not leave important assumptions unverified indefinitely.
• Close items properly: Record the resolution or reason an item is no longer relevant before closing it.
• Share with relevant stakeholders: Make sure the people who need to act or make decisions can access the appropriate information.
• Link related items: An issue may arise from a risk occurring, an assumption proving false, or a dependency being delayed. Link related records where useful.

11. Common Mistakes to Avoid

• Recording risks without identifying response actions.
• Listing issues without assigning owners.
• Treating assumptions as confirmed facts.
• Ignoring dependencies until they block delivery.
• Leaving outdated statuses in the log.
• Assigning vague actions such as “follow up” without an owner or due date.
• Recording too many insignificant details while overlooking high-impact concerns.
• Failing to communicate major changes to the appropriate stakeholders.
• Closing an item without verifying that the action is complete or the item is no longer relevant.

12. RAID Log vs. Risk Register

A Risk Register primarily records and manages project risks. A RAID Log combines risks with assumptions, issues, and dependencies in one tracking document.

Aspect	Risk Register	RAID Log
Primary Purpose	Manage project risks.	Track risks, assumptions, issues, and dependencies.
Typical Contents	Risk description, probability, impact, response, owner, and status.	Records for all four RAID categories, with fields appropriate to each category.
Level of Detail	Often more detailed risk analysis and response planning.	May provide a consolidated overview for project coordination and reporting.
Best Used For	Detailed risk management.	Coordinated tracking of key project uncertainties, problems, assumptions, and dependencies.

A project may maintain both documents: a RAID Log for consolidated tracking and a separate Risk Register for more detailed risk analysis.

13. How Often Should a RAID Log Be Reviewed?

The review frequency depends on the size, complexity, and risk level of the project.

• Daily: For high-risk projects or active delivery periods where significant blockers need frequent attention.
• Weekly: A common frequency for regular project status meetings.
• At milestones: To review risks, assumptions, issues, and dependencies before important decisions or releases.
• When something changes: Update the log when a new risk emerges, an assumption is invalidated, an issue occurs, or a dependency changes.

The RAID Log should be updated when important information becomes available rather than waiting for the next scheduled review.

14. Easy Way to Remember RAID

• Risk: What might happen?
• Assumption: What do we believe is true?
• Issue: What has already happened?
• Dependency: What are we waiting for, or what relies on something else?

15. Final Summary

A RAID Log is a simple but powerful project management tool that helps a project manager maintain visibility into important uncertainties, assumptions, existing problems, and dependencies.

• Risks are uncertain events that may affect the project.
• Assumptions are beliefs used for planning that need validation where appropriate.
• Issues are existing problems that require action.
• Dependencies are relationships in which work, decisions, or deliverables rely on other activities or parties.

The key principle: Record each item clearly, assign an owner, define the next action, set a suitable target date, review progress regularly, and escalate when necessary.