Initial Risk Identification Log Template – Free Word Download

Introduction to Risk Identification

Risk management is the project manager’s primary tool for predicting the future. While the schedule tells us what we hope will happen, the Risk Identification Log tells us what might prevent that hope from becoming reality. It is the art and science of identifying uncertain events that, if they occur, will have a positive or negative effect on the project’s objectives.

The Initial Risk Identification Log differs slightly from the formal “Risk Register” (which will be detailed in Template 17). The Identification Log is the raw capture tool used during the earliest stages of the project, often during the initiation phase or the very first workshop. At this stage, you do not have enough data to perform detailed qualitative analysis (scoring probability and impact) or to assign detailed mitigation owners. You simply need to capture the universe of possibilities before they are forgotten.

Think of this document as a wide funnel. You want to capture every anxiety, every worry, every “what if,” and every assumption. Later, you will filter this list, combine duplicates, and promote the valid items to the formal Risk Register. However, if you do not capture the risk now, you cannot manage it later.

This template provides a structured approach to brainstorming. It guides you away from vague statements like “Resource availability” (which is a category, not a risk) and toward actionable risk statements like “If the Senior Architect is pulled into the emergency audit, then the design phase will be delayed by two weeks.”

Section 1: The Context of Identification

Guidance for Completion

Risk identification is an iterative process. It is not a one-time event. However, the initial identification is special because it sets the tone for the project’s culture. If you perform this exercise thoroughly, you signal to the stakeholders that “bad news early is good news.” If you rush this step, you signal that you only want to hear happy thoughts.

The Cone of Uncertainty

In the early days of a project, the “Cone of Uncertainty” is at its widest. You know the least about the detailed work, yet you are making the biggest commitments (budget and timeline). Therefore, your initial risk log is your primary defense against over-optimism.

Instructions

Use this log during your “Project Kick-off” or “Pre-Mortem” workshop. Encourage stakeholders to speak freely. Do not judge or filter ideas in this document; simply record them.

Section 2: Identification Techniques and Sources

Guidance for Completion

How do you find risks? You do not just stare at a blank spreadsheet. You need triggers. Use this section to document how you identified the risks listed. This adds credibility to the process.

Common Techniques

1. Brainstorming: A facilitated session with the team where ideas are shouted out and recorded on sticky notes.
2. Checklist Analysis: Reviewing the “Lessons Learned” logs from previous similar projects to see what went wrong there.
3. Assumption Analysis: Reviewing the Assumptions Log (Template 20). Every assumption that proves false is a risk.
4. SWOT Analysis: Looking at Strengths, Weaknesses, Opportunities, and Threats.
5. Interviewing: Asking experts “What keeps you up at night regarding this project?”

Draft Example

“The risks in this log were identified during a 2-hour workshop held on October 12th using the PESTLE framework (Political, Economic, Social, Technological, Legal, Environmental) to prompt discussion among the Steering Committee.”

Section 3: The Risk Statement Syntax

Guidance for Completion

The single biggest failure in risk management is writing “Risks” that are actually just “Worries.” To be manageable, a risk must be specific. You must strictly use a structured syntax. This ensures you understand the root cause and the final impact.

The “If-Then-Result” Format

You should strive to write every risk in this format:

“If [CAUSE / EVENT] happens, then [CONSEQUENCE] will occur, resulting in [IMPACT ON OBJECTIVES].”

Examples of Good vs. Bad Syntax

• Bad Risk: “Heavy Rain.” (This is just a weather report).
• Good Risk: “If heavy rain occurs during the excavation phase (Event), then the foundation trenches will flood (Consequence), resulting in a 3-day delay to the concrete pour and a cost of $5,000 for pumping equipment (Impact).”
• Bad Risk: “New Technology.” (This is a fact, not a risk).
• Good Risk: “If the new server architecture proves incompatible with the legacy database (Event), then we will have to write custom middleware (Consequence), resulting in an unplanned 4 weeks of development time (Impact).”

Section 4: Risk Categories (The Prompt List)

Guidance for Completion

To ensure you don’t miss anything, use the Risk Breakdown Structure (RBS) categories as prompts. Group your log by these categories.

Category 1: Technical Risks

• Complexity of the solution.
• Unproven technology.
• Performance benchmarks.
• Legacy integration.

Category 2: Management / Project Risks

• Resource availability.
• Communication breakdowns.
• Scope creep.
• Unrealistic schedule.

Category 3: Commercial / External Risks

• Vendor bankruptcy.
• Contract disputes.
• Supply chain delays.
• Currency fluctuation.

Category 4: Regulatory / Compliance Risks

• New laws passing mid-project.
• Data privacy breaches.
• Health and safety violations.

Section 5: The Log Structure (Columns)

Guidance for Completion

This section defines the columns of your spreadsheet. Since this is the Initial log, keep it simple. Do not add complex scoring columns (like Probability x Impact) yet; that comes later in the formal Register. Here, we just want to capture the data.

Column 1: Risk ID

• Format: R-001, R-002.
• Purpose: Unique identifier for tracking.

Column 2: Risk Category

• Format: Dropdown (Technical, Commercial, etc.).
• Purpose: Helps to sort and assign to experts later.

Column 3: The Risk Description

• Format: The “If-Then-Result” sentence defined in Section 3.
• Tip: Be verbose here. More detail is better than less.

Column 4: Potential Owner

• Format: Name or Role.
• Purpose: Who is the best person to worry about this? (e.g., The Lead Developer for technical risks).

Column 5: Initial Triage (High/Medium/Low)

• Format: Simple Rating.
• Purpose: This is a “gut check.” Is this a showstopper (High) or just a nuisance (Low)?

Section 6: Distinguishing Risks from Issues and Facts

Guidance for Completion

During brainstorming, people will shout out things that are not risks. You must filter these out, or your log will become useless.

The Three Definitions

1. Risk: An uncertain event in the future. It might happen. (Action: Mitigate).
2. Issue: A problem that is happening now. It has a probability of 100%. (Action: Resolve).
3. Fact/Constraint: A limitation of the project. (Action: Plan around it).

Filtering Example

• Stakeholder says: “We don’t have enough budget.”
  • PM Response: That is a Constraint, not a risk. We must plan the scope to fit the budget.
• Stakeholder says: “The server crashed this morning.”
  • PM Response: That is an Issue. Please log a support ticket.
• Stakeholder says: “The vendor might go bust next month.”
  • PM Response: That is a Risk. Let’s log it here as R-005.

Section 7: The “Pre-Mortem” Brainstorming Guide

Guidance for Completion

One of the most effective ways to fill this log is the “Pre-Mortem” exercise. Use this guide to facilitate the session.

The Script

“Imagine it is one year from now. The project has failed spectacularly. It was a disaster. I want you to write down the ‘History of the Failure.’ What happened? Did the vendor quit? Did the software crash? Did the users revolt?”

Why it Works

This technique removes the fear of being negative. You are asking the team to be creative about failure. Once they list the “causes of death,” you reverse-engineer them into the Risk Log.

Draft Example of Output

• Pre-Mortem Idea: “The system failed because no one knew how to use it.”
• Converted Risk Entry (R-010): “If the training materials are not delivered in the local language, then user adoption will be below 50%, resulting in a failure to realize business benefits.”

Section 8: Capturing Opportunities (Positive Risk)

Guidance for Completion

Risk is not just about bad things. Positive uncertainty is called an Opportunity. Most project managers forget this. Opportunities are events that, if they happen, will save time or money. You should log them here too.

Syntax for Opportunities

“If [EVENT] happens, then [BENEFIT] will occur, resulting in [POSITIVE IMPACT].”

Draft Example

• ID: OPP-001
• Description: “If the currency exchange rate improves by 5% (Event), then our hardware purchasing power will increase (Benefit), allowing us to buy better servers for the same budget (Impact).”
• Action: Monitor the exchange rate and hold off on purchasing until the trend is confirmed.

Section 9: The Initial Risk Log (Drafting Table)

Guidance for Completion

Below is a sample structure you can copy into Excel or Word. Populate this with at least 10-20 initial items.

Draft Log Example

ID	Category	Risk Description (If/Then/Result)	Potential Owner	Initial Triage
R-001	Resource	If the Lead Developer is called for jury duty during the critical path coding phase (Sept), then development will stall, resulting in a 2-week delay to UAT.	Project Manager	Medium
R-002	External	If the supplier increases prices in January due to inflation, then the project budget will be exceeded, resulting in a request for contingency funds.	Finance Lead	High
R-003	Scope	If the Marketing Department changes the branding guidelines after the design sign-off, then all UI screens will need re-work, resulting in $10k extra cost.	Sponsor	High
R-004	Technical	If the API documentation from the third party is outdated, then the integration team will waste time coding to the wrong specs, resulting in testing failures.	Tech Lead	Medium
R-005	Safety	If the scaffolding is not inspected daily during the windy season, then it may become unstable, resulting in a potential safety incident and site shutdown.	Site Foreman	Critical

Section 10: Initial Risk Response Strategy (The “First Thoughts”)

Guidance for Completion

While you don’t need a detailed mitigation plan yet, it is helpful to capture the “First Thoughts” on how to handle the risk while the idea is fresh.

The 4 T’s of Risk Management

1. Treat (Mitigate): Reduce the probability or impact.
2. Transfer: Give the risk to someone else (e.g., Insurance, Outsourcing).
3. Terminate (Avoid): Change the plan to remove the risk entirely.
4. Tolerate (Accept): Do nothing and accept the consequences.

Draft Example

• Risk: R-001 (Jury Duty).
• First Thought Strategy: Treat. Cross-train a secondary developer now so they can step in if needed.
• Risk: R-002 (Inflation).
• First Thought Strategy: Transfer. Sign a fixed-price contract with the vendor immediately to lock in current pricing.

Section 11: Bias and Blind Spots

Guidance for Completion

As the Project Manager, you must sanitize the log for cognitive biases. This section serves as a checklist for you to review the log before publishing it.

Common Biases to Check

1. Optimism Bias: “We won’t have any bugs.” (Add a risk for bugs).
2. Anchoring: Relying too heavily on the first piece of information. (e.g., “The sales guy said it was easy”).
3. Groupthink: Everyone agreeing with the boss. (Did the junior staff stay silent? If so, interview them privately).

Correction Strategy

If you notice the log is empty of “Management Risks” because the boss was in the room, you have a blind spot. You must add these risks yourself based on your professional judgment (diplomatically, of course).

Section 12: Review and Validation

Guidance for Completion

Once the initial list is generated, you need to validate it. Send the draft log to the key stakeholders with a simple question: “What did we miss?”

The “Silent Review” Technique

Send the document via email and allow people to add comments in “Suggestion Mode.” People are often more honest in writing than they are in a meeting.

Validation Checklist

1. Are the risks specific?
2. Are the risks realistic?
3. Are there duplicates? (Merge them).
4. Are there Issues disguised as Risks? (Remove them).

Section 13: Transition to the Formal Register

Guidance for Completion

This document is a temporary artifact. Its contents will eventually be migrated to the detailed Risk Register (Template 17) or the Risk Management Plan.

The Migration Process

1. Clean Up: Fix the grammar and syntax.
2. Filter: Remove risks that are “Low/Low” and not worth tracking.
3. Migrate: Copy the valid rows to the official project repository.
4. Archive: Save this Initial Log as a record of the project’s starting point.

Section 14: Sign-Off (Optional)

Guidance for Completion

While not strictly a legal document, having the Project Sponsor acknowledge the Initial Risk Log is powerful. It confirms that they are aware of the potential pitfalls before they approve the full budget.

Signature Block

• Acknowledged By (Sponsor): ___________________
• Date: ___________________
• Statement: “I have reviewed the initial risks identified by the team. I understand that the project is not risk-free, and I support the investigation of mitigation strategies for the ‘High’ priority items.”

Detailed Tips for Facilitating a Risk Workshop

The “Sticky Note” Method

Do not use a projector and a spreadsheet in the meeting. It kills creativity.

1. Give everyone a pad of sticky notes.
2. Set a timer for 10 minutes.
3. Ask them to write one risk per note.
4. Stick them all on the wall.
5. Group them by theme (e.g., “All these are about the vendor”).
6. Then type them into this template.

The “Risk Prompt” Cards

If the room is quiet, hand out cards with words on them to trigger thoughts:

• “Rain”
• “Sickness”
• “Bankruptcy”
• “Hacking”
• “Changes”
• “Misunderstanding”

Dealing with the “Naysayer”

Every workshop has one person who says, “That will never happen.”

• Response: “You are probably right, but let’s write it down anyway. If it doesn’t happen, we can close it later. Better safe than sorry.”

Conclusion – Initial Risk Identification Log Template – Free Word Download

The Initial Risk Identification Log is the project manager’s radar. It scans the horizon for storms while the sky is still blue. By completing this template, you are performing the vital psychological work of shifting the team from “blind optimism” to “informed realism.”

Remember that a risk log is not a list of problems; it is a list of potential problems that you intend to prevent. It is a proactive tool. A long risk log is not a sign of a bad project; it is a sign of a good Project Manager. It shows that you are looking ahead.

Once this initial capture is complete, do not let it gather dust. These risks will evolve. Some will vanish, and new ones will appear. This document feeds directly into your Risk Management Strategy and will be the basis for your contingency budget calculations.

Take the time to refine the “Risk Descriptions” in Section 9. The quality of your future decision-making depends entirely on the clarity of these statements. If you write “Vendor Issues,” you cannot solve it. If you write “Vendor contract lacks a penalty clause for late delivery,” you can solve it immediately by rewriting the contract. Precision is power in risk management.

---

Meta Description

A template for the Initial Risk Identification Log. Includes brainstorming techniques, risk statement syntax, categorization prompts, and methods to distinguish risks from issues.

Discover free project management templates at www.pmresourcehub.com