Risk Identification: 7 Techniques and Real Examples

Risk identification is the effort to discover threats and opportunities that may affect your project, its feasibility, or its management plan. You apply risk identification techniques with your team and stakeholders, and you capture every risk you find in the Risk Register.

Key takeaways

• Start early, keep going. You identify risks from the day you’re assigned until the project ends.
• Talk about risks every day. You’ll find more risks in ongoing conversations with your team than in any single workshop.
• Add sessions at key points. Hold a dedicated session after you draft the requirements, the WBS, the schedule, and the budget.
• Log every risk. The Risk Register is the output of risk identification.

Here’s the most important thing you need to take from this article.

Risk identification is not a rigid process that you follow step by step. Good risk identification comes from communication and collaboration with all project stakeholders.

I learned that the hard way. When I got my PMP, I tried to bring its processes to a company that had none. Nobody followed them, and I was back to managing chaos. Every risk we missed turned into a fire I had to put out later.

So you also need to teach others how to use your risk management process.

Let me show you how it works in the real world, with real people.

What Is Risk Identification in Project Management?

Risk identification answers one question: what could happen on this project that we haven’t planned for?

Most of the answers are threats: a vendor delivers late, a key developer leaves, a requirement means two different things to two people. Some are opportunities, like a reusable component that could save you a sprint. You look for both.

You capture every identified risk in a Risk Register. That’s the output of risk identification.

Risk identification comes right after you plan your risk management approach. Then you continue by analyzing risks in the next steps of your risk management process.

When Do You Perform Risk Identification?

Throughout the whole lifetime of the project. You start as soon as you’re assigned, sometimes in pre-sales, and you keep identifying risks until the project closes.

In practice, you should use an integrated risk management approach. You talk through possible risks for every activity on the project.

For example, when you collect requirements and write specifications, you and your team should always look out for risks:

• Track all the assumptions you make.
• Check if the requirements are ambiguous. Do people understand the same requirement differently?
• Don’t hide uncertainties. Turn them into risks.

But that’s not enough. You also need in-depth risk identification sessions at critical points in project planning, where you take a broader look at the project as a whole.

Here are the moments when I consider a dedicated risk identification session:

• When the client has defined the project goal.
• After you’ve identified key stakeholders.
• When you review risk categories for the first time.
• After you’ve collected most of the requirements.
• After you’ve drafted the work breakdown structure (WBS).
• After you’ve identified the required resources.
• After you’ve drafted the project schedule.
• After you’ve drafted the project budget.

How to Identify a Risk?

A risk identification technique is a way to discover threats and opportunities you weren’t aware of by working with your project stakeholders.

Textbooks list dozens of them. In practice, we use a handful. These are the seven I use on real IT projects:

1. Talking about risks (not a formal technique, but I’ll explain it below).
2. Checklists (risk categories).
3. Requirements review.
4. Document analysis (reviewing the project management plan with the team).
5. Brainstorming and interviews.
6. Root cause analysis.
7. Assumptions analysis.

Now you need to understand when to use them and how to apply them to your project documentation. In this video, I walk you through my risk identification method and show each technique in action.

You’ll capture all identified risks in the Risk Register.

How to Use Risk Identification Techniques

Some techniques, like brainstorming, are universal. You can apply them to anything on a project.

Other techniques, like a requirements review, belong to a specific piece of project documentation.

You don’t use every technique on everything. But you might apply several techniques to one input. For example:

You review the project schedule with the team (#1) and brainstorm (#2) possible threats. After that, you check common risk sources in the risk categories (#3). Then you take the schedule to a senior project manager and interview (#4) her to get her insights.

Notice how we used four techniques on the same piece of project documentation. Not every artifact needs that much attention. I recommend putting the extra effort into the project budget and schedule.

It all comes down to using your time and resources well. Risk management isn’t free. You pay for it with time and resources from your project.

Now, let me give you some real-life examples.

Risk Identification Examples

In real life, it’s tough to make risk identification timely and efficient. The key is to keep it simple. Team members and stakeholders should be able to use these techniques without special training or experience.

That’s why I picked seven techniques you can use on any project, no matter how experienced you are. The table shows what each one looks like on an IT project and the kind of risk it uncovers.

Technique	When you use it	Example of a risk it uncovers
1. Talking about risks	Every day: stand-ups, planning meetings, one-on-ones	You ask “What may go wrong with this plan?” and a developer says the client’s IT team still hasn’t opened access to the test server.
2. Risk categories	Once you know the scope of work	The “third parties” category reminds you that an external design team delivers the designs, and any delay there pushes back the web application.
3. Requirements review	Whenever you receive or clarify requirements	Two developers read “users can export reports” differently. One estimated PDF only, the other PDF and Excel.
4. Project plan review with the team	After each draft of the WBS, schedule, and budget	A developer sees critical tasks next week and remembers a trip he hasn’t told you about.
5. Brainstorming and interviews	At critical planning points, deliverable by deliverable	Nobody on the team has worked with the client’s legacy CRM, so the integration estimate is a guess.
6. Root cause analysis	After a serious problem, or at the end of a project	Estimates on your last two projects left out testing time, so this project’s estimates probably do too.
7. Assumptions analysis	At the start, then on a regular review cycle	The plan assumes your subject matter expert is available two days a week, but she may get pulled onto another critical project.

If you prefer video, here are the same simple techniques and how they work in the real world:

#1: Continuously Discuss Possible Risks

In the real world, we identify risks all the time. It’s the most effective approach.

But it’s not a casual conversation. It has rules and agreements. That’s why you need to teach all team members and stakeholders your risk management process.

Keep it short. You want just enough process to stay in control, light enough that your team follows it.

Make sure everyone shares the same understanding of:

1. Why risk management matters.
2. What each person is responsible for in risk management.
3. What is a risk, and what is a fact?
4. How do we capture risks in the risk register?
5. How do we handle risks in general?

Then you use the same terms and mean the same thing when you talk about project risks.

Once you have a shared vision of risk management, you can build risk identification into every project activity. You can ask something along the lines of:

• Do you see any risks here?
• How risky is this approach?
• Please provide a list of risks along with your estimates.
• Let’s think about possible risks.
• What may go wrong with this plan?

You’ll use the other techniques below now and then, some only once. Talking about risks happens daily.

#2: Analyze Risk Categories to Discover Typical Risks

Most organizations carry out projects of a similar nature. Processes and policies stay the same. Some stakeholders never change. So a new project inherits the same sources of risks from your environment.

Risk categories are a list of these common sources of risks in your organization.

Organizations in the same niche share many of the same sources of risks. So this technique is worth your time: you can reuse it throughout your whole career.

The list of risk categories comes from lessons learned. Ideally, project managers share these lessons with each other. That rarely happens.

That’s why you won’t find such a list in most organizations. Worse, you probably don’t have your own list of risk categories right now. I’ve got you covered. You can use my list of risk categories.

The risk categories technique:

• helps you identify risks you may not be aware of;
• stops you from forgetting some risk sources; and
• gives your risk identification a structure.

The process is simple. You go through the list and pick out the risks that may apply to your current project. You can approach this in different ways.

You may review the list alone, shortlist the categories, and then discuss the shortlist with your team. Or you can brainstorm through the whole list with your team. The best time to do this is when you already know the project’s scope of work.

I also keep the list close at hand as a cheat sheet for other risk identification sessions. It’s a good starting point for finding new sources of risks.

#3: Perform Requirements Review

A requirements review is one part of assessing the project documentation. I cover it separately because it’s critical.

Requirements carry significant risks for a project. You need to analyze them to find anything ambiguous or unclear. This review also helps you assess how much work each requirement takes.

Poor requirements are one of the most common causes of project failure. Quality and level of detail are only half of it. You also need enough time to analyze the project specifications.

You need a chance to review and discuss each requirement with the team, with the big picture in mind. You need to make sure the requirements don’t conflict with one another. If you don’t give yourself time for all of this, that’s a risk in itself!

In the real world, you clarify requirements throughout the project’s lifetime, so you re-evaluate these risks as you go. Here’s what you do in practice:

1. Select some requirements.
2. Select a group for analysis (the whole team or just the leads).
3. Let them read through the specifications, designs, and emails.
4. Plan a meeting to analyze the requirements.
5. Let one person explain the requirements to the others.
6. Clarify the requirements until everyone has the same understanding.

If you’ve never done this before, try it at least once, even just out of curiosity. You’ll notice that different people read the same words and sentences differently.

To prepare for that meeting, run the Requirement Conflict Detector prompt from my free AI Prompt Pack. Attach your raw requirements, and AI flags contradictions and vague requirements before your team reads them.

I’m also a big fan of visualizing workflows, information flows, and user experience.

If your product, service, or result has a user interface or any tangible form, take the time to draw it. You’ll find new use cases, weak spots in the requirements, and inconsistencies. As the old saying goes, a picture is worth a thousand words.

In this video, I take a short email from a client and turn it into the full project scope. Watch the questions I ask along the way: each one closes a gap that would otherwise become a risk.

#4: Review the Project Management Plan with the Team

This is the broader part of reviewing project documentation, and you can apply it to any risk assessment.

So, which documents should you review to find risks? Every single one! For example, once you have a first draft of the project management plan, review it with your team.

First of all, you need to engage the project team in planning and get their buy-in from the start. A disengaged and unmotivated team that doesn’t believe in the project plan is a huge risk by itself.

Your team is also your primary source of information and risks. Walk the whole team through the project plan, and I promise each person will find at least one risk related to their work. You want to find those risks early and adjust the plan.

You’ll talk about many things with the team. At the very least, discuss the following:

• Units of measurement. Did they provide estimates in effective or ideal hours, working days, or something else?
• What did they include in those estimates? Is there a buffer?
• Do they know how to report the money they spend?
• Do they know how and when to log their progress?
• Do they know your project management approach in general? What about risk management?
• Do they understand what “done” means for a task?

The list goes on and on. Never assume that team members see and understand your plan the way you do. And don’t assume they all share the same understanding of every project activity.

Once I have a draft of a schedule, I show it to the team. They review dependencies, the flow of tasks, and any buffers we have. They also think through their personal plans, vacations, and other errands.

For example, a team member sees the project schedule. He has several critical tasks next week. Then he remembers an important trip he hasn’t told you about yet. Now you can adjust the schedule for his absence.

Different parts of your project also depend on each other, and you want to make sure nothing blocks your progress. Team members often discover hard dependencies I’ve missed. That lets me correct the plan early and account for these possible delays.

I use the same process to verify our Work Breakdown Structure (WBS). Draft after draft, I collect feedback from the team and correct the WBS. This often reveals missing details in the requirements, and we take a step back. Sometimes we discover a new piece of work when we look at the product as a whole.

I also recommend creating and reviewing project workflows. At the very least, you need them for:

• starting, reporting on, and finishing a task;
• identifying and controlling risks;
• reporting on project status;
• identifying and fixing defects;
• handling a change request; and
• taking requirements from concept to an approved specification.

You can draw the workflows on a piece of paper or in a tool like diagrams.net. Either way, I believe you need to visualize them. If you use project management software, tie it all to “statuses” and “fields.” You don’t need flashy diagrams. Just make the flow clear to team members.

The good news: you only need to do this once per organization. Then you adjust it for new projects. It helps you spot roadblocks, diffused responsibility, inefficient communication, and more.

Your superiors, who need to approve your work, are another source of risks. They show up on the workflow diagram too.

Q: Dmytro, do you really review all the documents on your projects?

A: No, I don’t. Some of them are pretty similar to the ones I used on previous projects. So I just make sure the same plans, templates, and workflows will work for the new project.

#5: Use Brainstorming and Interview Techniques for Deeper Analysis

In general, I don’t like to identify risks with wild brainstorming. But at a few critical points in project planning, I use brainstorming to identify risks at a higher level:

• when analyzing essential requirements;
• while reviewing the WBS;
• when reviewing the schedule and HR plan;
• while creating a quality management plan; and
• before finalizing the whole project management plan.

For example, once I have a draft of the WBS, I plan several brainstorming sessions. I go through the major deliverables one by one with the team. I point at one of them and ask, “What could go wrong when we implement this piece of the project?”

Then I ask, “What challenges do you see in putting it all together?” Once we know enough details, we take a broader look at our future work.

I use interviews with Subject Matter Experts (SMEs) the same way. These experts rarely have time for every risk management activity. So I ask them for feedback and validation on the most critical risks and their response plans.

#6: Apply Root Cause Analysis for Systematic Risks

In practice, I use root cause analysis for risk identification in three scenarios:

1. To analyze severe problems from past projects. It might be my previous project, or a similar project another project manager ran in the organization. It can also be relevant notes from lessons learned or a list of risk categories.
2. When I’m trying to solve a systematic problem. This usually means inefficient communication, poor quality, inaccurate estimates, or ambiguous requirements.
3. To group all identified risks by root cause. It shows me the primary sources of problems and helps me find even more risks.

On a real project, you rarely run a full root cause analysis during planning. It’s usually a post-mortem, or an analysis after a significant problem.

First, you collect lessons learned. Then you set aside time at the end of the project for a root cause analysis session. You can use a fishbone diagram, the “5 Whys” technique, or a scatter diagram. Later, you develop a systematic risk response plan for the next project.

Don’t assume the same risks won’t occur on the next project. They will, especially the ones related to your project management approach and your organization’s environment.

Always add such risks to your risk categories list.

#7: Analyze Assumptions to Identify the Most Impactful Risks

Every assumption carries a risk. If an assumption is wrong, the project is in trouble.

First, keep track of all major assumptions. I keep a separate list of project-level assumptions. I also log assumptions about specific requirements right in the specification document. Then you review and validate the assumptions on a regular basis.

We make assumptions all the time, but we make most of them at the start of a project. They come back to hit the project later down the road. The riskiest assumptions are the ones you make because of problems in the organization. For example:

• Resources. You assume you’ll get the required resources in time. Why?! Do your recruiters always hire people quickly?
• Experts. You assume your SME will be available for your project. But what if she’s assigned full-time to another critical project?
• Vendors. You assume a third party will deliver on time. Usually, they don’t, and the whole project stalls.

Work hard to validate each assumption. Either confirm it as a fact or turn it into a known risk.

How to Find Time for These Activities?

First of all, delegate well. You don’t need the whole team for risk identification.

Second, build these techniques into your existing processes and meetings. You don’t need separate meetings unless you want to explore possible risks in depth.

Third, once you teach people risk management techniques, they use them on the fly. They bring up risks and assumptions in all their conversations.

You also need to explain the benefits of risk management to the project owners. Strike the right balance between your effort and the benefits it brings, and ask for enough time to get those benefits.

Can AI Identify Project Risks for You?

Yes, if you give it the right context.

Type “list the risks for my software project” into ChatGPT, and you’ll get the same generic list you’d find in any textbook. You’ll see scope creep, unclear requirements, and resource constraints, but nothing about your vendor, your legacy CRM, or the SME who’s already on two other projects.

A checklist or a risk register template has the same problem. It helps you start, but it can’t tell you what’s risky on your project. That still comes from the process in this article: talking to your team, reviewing requirements, and testing your assumptions.

Once you understand that process, AI speeds it up. You feed it your project’s context, and it reads requirements and documents faster than any of us. It flags the conflicts and gaps that would take you a full afternoon to find.

I put together a free AI Prompt Pack for project managers: 27 copy-paste prompts for real IT project work. Three of them fit risk identification:

• Project Context File Builder. AI asks you targeted questions about your goal, scope, stakeholders, team, timeline, budget, and known risks and constraints. Then it builds one file you attach to every other prompt, so the answers are about your project.
• Requirement Conflict Detector. Attach your raw requirements, and AI flags contradictions and dangerously vague requirements, rates each conflict by risk level, and gives you the exact question to ask your stakeholders. It’s technique #3 in minutes.
• Hidden Deliverable Detective. AI lists the governance, compliance, and transition deliverables nobody has planned for yet, and flags the hidden systemic risks it sees for your industry and organization.

Get the free AI Prompt Pack and run these prompts on the project you’re managing now. You’ll walk into your next risk identification session with a list of real risks to discuss.

Risk Identification FAQ

When do you perform risk identification?

During the whole lifetime of a project. You start as soon as you’re assigned, hold dedicated sessions after key planning milestones (requirements, WBS, schedule, budget), and keep identifying risks through execution until the project closes.

What are the main risk identification techniques?

Brainstorming, interviews, checklists (risk categories), document analysis, assumptions analysis, and root cause analysis. The PMBOK® Guide also lists SWOT analysis and prompt lists such as PESTLE. On real IT projects, the most effective technique is the simplest one: talking about risks with your team every day.

What is an example of risk identification?

You walk the team through the draft schedule, and a developer remembers a trip next week he hasn’t mentioned. You log it in the Risk Register (“The developer is away next week, which will delay the payment integration”) and adjust the plan. You’ll find six more examples in the table above.

Which activities are part of the risk identification process?

Reviewing project documents and requirements, running brainstorming sessions and interviews, going through risk categories, analyzing assumptions, and recording each risk with its cause and effect. Scoring probability and impact belongs to the next step, qualitative risk analysis. Planning responses comes after that.

What is the final step in the risk identification process?

You record the identified risks in the Risk Register, with a clear description and, ideally, a potential risk owner. The PMBOK® Guide also lists a risk report as an output. From there, the risks move on to analysis.

In which model is risk identification done continuously?

Among software development models, the Spiral model is built around it: each loop of the spiral includes a risk analysis phase. In practice, you identify risks continuously in any model. In Scrum, risks come up in daily stand-ups, sprint planning, and retrospectives.

Conclusion

Risk identification doesn’t happen in one workshop at the start of a project. You do it every day, in every conversation with your team, and in a few deeper sessions at the critical points of planning.

Keep the techniques simple, so your team and stakeholders can use them without special training. Teach everyone your risk management process. Log every risk in the Risk Register, and turn every unchecked assumption into a known risk.

Do that, and you’ll see most problems coming before they turn into fires. Your project runs on a system, not on overtime. That’s how you stop managing chaos and start managing projects.

You’ll find the rest of my articles on this topic on the Risk Management page.

Before your next planning session, grab the free AI Prompt Pack and build your Project Context File first. You’ll get risks about your project instead of a generic list.