Project Risk Management: How to Identify, Assess and Control Risks

Imagine your company is developing a new booking platform for a client. The deadline is twelve weeks away, the developers have started work, and everything looks fine.

Then, in Week 7, the team discovers that the client’s existing payment system cannot support one of the required features.

The integration needs extra development. Testing gets pushed back, the client wants to know whether the launch date will change, and the project manager has to find a solution.

The technical problem matters, but there’s another question worth asking: could the team have spotted this risk earlier?

Perhaps an early integration test would have revealed the issue before it affected the schedule.

That’s what project risk management is about. It helps teams identify uncertain events, understand their possible effects and decide what to do before they cause serious problems.

In this guide, we’ll walk through the project risk management process, create a practical risk register, and look at how businesses can manage risks in software, engineering and other projects.

What Is Project Risk Management?

Project risk management is the process of identifying, analysing, responding to and monitoring uncertainty that could affect a project’s objectives.

A project risk is an uncertain event or condition that could affect something important, such as the schedule, budget, scope, quality or expected business benefits.

For example:

• A software integration may take longer than estimated.
• A key supplier might fail to deliver equipment on time.
• A client could delay approval of an important design.
• A specialist employee may become unavailable.
• A new technology might allow the team to finish part of the work earlier than planned.

Notice that the last example is positive.

In project management, risks can be threats or opportunities. An opportunity is an uncertain event that could improve project results.

The Association for Project Management (APM) describes risk management as a way to manage threats while also making use of opportunities.

The basic process is straightforward:

Identify risks → Assess them → Plan responses → Assign owners → Monitor and update

The amount of detail depends on the project. A small marketing campaign may only need a short risk register, while a major engineering project may require detailed assessments, quantitative analysis and formal risk reviews.

1. Start by Identifying What Could Go Wrong

Let’s return to our booking platform.

The project has a twelve-week schedule and involves a project manager, two developers, a designer, a tester and a client representative.

The team needs to deliver customer accounts, booking functionality, payment integration and an administration dashboard.

Before development moves too far, the project manager brings the team together for a short risk identification session.

Instead of asking a vague question like “Are there any risks?”, they look at each major part of the project.

For payment integration, the team asks whether the existing payment provider supports the required functionality.

For development, they review dependencies on third-party APIs and specialist employees.

For testing, they consider how much time will be available if important defects are discovered.

A few possible risks emerge.

This gives the team something useful to assess.

Write Risks Clearly

Avoid vague entries such as “technical problems” or “project delays”.

A better risk statement explains the cause, uncertain event and possible effect.

For example:

Because the payment provider’s API capabilities have not yet been verified, the required integration may not work as expected, which could increase development effort and delay testing.

Now the project manager knows what needs investigating.

Risks can be identified through workshops, interviews, lessons learned, technical reviews, supplier discussions and project assumptions.

For larger projects, a Risk Breakdown Structure (RBS) can help organise risks into categories such as technical, commercial, financial, external and organisational.

2. Assess Which Risks Need Attention First

Not every risk deserves the same amount of effort.

A minor design change may be inconvenient but manageable. A failure in a critical payment integration could threaten the entire launch.

A simple starting point is qualitative risk analysis, where you assess two things:

• Probability: How likely is the risk to occur?
• Impact: How seriously could it affect the project?

For a small business, a five-point scale is often enough.

The descriptions should be defined for the particular project. For example, a major schedule impact could mean a delay of more than two weeks for one business, while a shorter delay could be critical for a time-sensitive launch.

Example: Assessing the Payment Integration Risk

Suppose the team assesses the unverified payment integration as:

• Probability: 4 out of 5
• Impact: 5 out of 5

Using a simple scoring method:

Risk score = Probability × Impact

That gives a score of 20 out of 25.

The team might classify this as a high-priority risk requiring immediate action.

Here’s an illustrative risk matrix.

The numbers help the team compare risks, but they are not statistical probabilities. Multiplying two rating categories is a prioritisation convention, and the thresholds need to be agreed for the project.

A high-priority risk might justify immediate testing, a management decision or additional resources.

When Is Quantitative Risk Analysis Useful?

A simple risk matrix cannot answer every question.

For a larger project, management may want to know the possible financial exposure or likelihood of meeting a contractual deadline.

Quantitative risk analysis can use numerical estimates and techniques such as Monte Carlo simulation, decision trees or Expected Monetary Value (EMV).

For example, if a risk has an estimated 30% probability of causing an additional £10,000 cost, its simple expected monetary exposure is £3,000.

That figure can help inform decisions, but it does not mean the business will actually lose £3,000. The eventual cost might be zero or the full amount, depending on what happens.

More detailed analysis is useful when the project justifies it and the input data is reliable.

3. Create a Risk Register That People Will Actually Use

A risk register is where the team records identified risks and how they will be managed.

It doesn’t need to be complicated.

For our booking platform, a practical register could look like this:

In a working register, I would also include the risk’s status, response deadline, triggers and latest review date.

Why Assign a Risk Owner?

Suppose the project manager records “payment integration may fail” but nobody is assigned to investigate it.

The risk remains on the register for several weeks.

When the problem eventually occurs, the team discovers that no action was taken.

Assigning a risk owner creates accountability. The owner monitors the risk and coordinates the agreed response.

The owner doesn’t necessarily perform every action personally. For example, a technical lead may ask a developer to run the integration test, while remaining responsible for reporting the outcome.

Where Should You Keep the Register?

For a small project, an Excel or Google Sheets risk register may be sufficient.

For a business managing several projects, the register can also be maintained within a tool such as ClickUp, Asana, monday.com or a dedicated risk management system.

The platform matters less than the information being accurate, accessible to the right people and reviewed regularly.

4. Choose the Right Risk Response

Once a risk has been assessed, the team needs to decide what to do about it.

Different risks require different responses.

Avoid the Risk

Risk avoidance involves changing the plan to remove a particular threat.

For example, if a proposed third-party integration is technically uncertain, the business might remove that feature from the first release, subject to client approval.

This avoids the immediate integration risk, although it may affect the intended scope or benefits.

Mitigate the Risk

Risk mitigation reduces the probability or impact of a threat.

For our booking platform, the team could test the payment API during Week 2 rather than waiting until the final development stage.

The risk still exists, but an early test gives the team more time to respond.

Transfer the Risk

Risk transfer places agreed responsibility for certain consequences with a third party, such as through insurance or contractual arrangements.

For example, a company may use appropriate insurance to manage some financial consequences of a covered event.

However, transferring risk does not necessarily remove its impact on the project. A supplier failure can still delay delivery even if a contract provides financial compensation.

Accept the Risk

Sometimes the response cost is greater than the likely impact, or there is no reasonable action that can reduce the risk further.

In that case, the business may decide to accept it.

Acceptance should be deliberate. The team may still monitor the risk or prepare a contingency plan.

What About Positive Risks?

An opportunity needs a different type of response.

Suppose an existing software component could reduce development work by two weeks if testing confirms it meets the requirements.

The team might run an early proof of concept to increase the chance of gaining that benefit.

Project management guidance recognises responses such as exploiting, enhancing, sharing or accepting opportunities.

The PMI risk management terminology and APM risk management guidance provide further detail on these strategies.

5. Know When a Risk Becomes an Issue

This distinction matters during project delivery.

A risk concerns something uncertain that may happen.

An issue is a situation that has already occurred and requires management action.

For example:

Risk: The payment API may not support the required functionality.

Issue: Testing has confirmed that the payment API does not support the required functionality.

Once the incompatibility is confirmed, the team needs to manage it as an issue.

That may involve evaluating another provider, changing the technical approach, reviewing the project scope or agreeing on a revised delivery plan.

The project manager should also assess whether the issue creates new risks.

For example, switching payment providers could introduce additional security, cost or testing requirements.

An issue log is useful for recording the problem, its impact, assigned owner, required actions and target resolution date.

6. Review Risks Throughout the Project

Imagine the team creates a detailed risk register during planning and never opens it again.

By Week 6, some original risks may no longer matter. New ones may have appeared, and the project’s circumstances may have changed.

Risk management needs regular attention.

For a small software project, I would include a short risk review in the weekly project meeting.

The team can ask:

• Have any new risks appeared?
• Has the probability or impact of an existing risk changed?
• Are the agreed response actions complete?
• Do any risks need escalation?
• Have any risks become issues?
• Can any risks be closed?

Pay particular attention to risks affecting upcoming milestones or important dependencies.

For example, a risk affecting user acceptance testing becomes more urgent as the planned testing date approaches.

Use Risk Triggers

A risk trigger is a warning sign that an identified risk may be getting closer.

For example, the team might establish a trigger for client approvals:

If the client has not responded within three working days of the agreed review deadline, escalate the pending decision.

This gives the team a clear point at which to act.

A trigger may initiate a response before the full consequences occur.

A Practical Example: What Happens When a Risk Is Managed Early?

Let’s compare two possible outcomes for our booking platform.

Scenario A: The Team Ignores the Risk

The project team assumes that the existing payment provider will work.

Development continues for several weeks.

During final integration testing, the team discovers that the provider cannot support a required feature.

Developers must investigate alternatives, update the implementation and repeat testing.

The launch date is now under pressure.

Scenario B: The Team Manages the Risk

During planning, the technical lead identifies payment integration as a significant risk.

The project manager assigns an owner and schedules a proof of concept in Week 2.

The early test reveals the incompatibility.

The team discusses alternatives with the client while there is still enough time to adjust the technical approach.

The project may still face additional work, but the issue has been discovered much earlier.

This is a hypothetical comparison, but it illustrates why risk responses should be linked to the schedule.

Common Risk Management Mistakes

One of the biggest mistakes is treating the risk register as a document that only needs to be completed at the start of the project.

Other problems include recording vague risks, assigning no owner, using arbitrary probability scores and planning responses that nobody follows through on.

Another common mistake is focusing only on major external threats while ignoring everyday project dependencies.

Late approvals, unclear requirements and overloaded employees may not look dramatic, but they can still seriously affect delivery.

It is also possible to spend too much time on risk analysis.

A small, low-risk project doesn’t need a complex quantitative model. Start with a proportionate process and add detail when the uncertainty and potential consequences justify it.

When Should a Business Get Help With Project Risk Management?

Some projects can be managed with a short register and regular team reviews.

Professional support may be useful when a business is dealing with complex technical dependencies, several suppliers, major schedule uncertainty or multiple projects sharing limited resources.

A project manager or risk management consultant can help identify important threats and opportunities, improve risk assessment, develop response plans and connect risk monitoring with project controls.

This can be particularly valuable when a business repeatedly encounters unexpected delays or cost increases without understanding the underlying causes.

Frequently Asked Questions

What are the main steps in project risk management?

The usual process involves identifying risks, assessing their probability and impact, planning responses, assigning owners, and monitoring them throughout the project.

What is the difference between a risk register and a risk management plan?

A risk management plan explains how risks will be identified, assessed, managed and reported. A risk register records the individual risks, their assessments, owners and responses.

What is the difference between a risk and an issue?

A risk is uncertain and may occur in the future. An issue is something that has already happened and requires action.

Can project risks be positive?

Yes. Risks may represent opportunities as well as threats. For example, an uncertain technical improvement could reduce delivery time if it proves successful.

Is a 5×5 risk matrix suitable for every project?

No. It can be useful for simple qualitative assessments, but complex projects may need more detailed analysis. The scoring criteria should reflect the project’s objectives and risk tolerance.

Final Thoughts

Project risk management gives teams a better chance to recognise uncertainty before it causes serious problems.

Start with the project objectives and identify what could affect them. Record important risks, assess their significance and agree on practical responses.

Make sure each significant risk has an owner.

Review the risks as the project progresses, especially when requirements change or important milestones are approaching.

For many businesses, a well-maintained risk register and a short weekly review can make a meaningful difference.

The real value comes from the decisions and actions taken because of the risk information.

---

Need Help Managing Risks in Your Projects?

At KAFA Consultancy, we help businesses improve project planning, risk management, change control and delivery processes.

Our services include project risk assessments, risk registers, scheduling, project controls, reporting and workflow digitalisation.

If your organisation is managing complex projects or regularly facing unexpected delays and resource problems, we can help review your existing processes and develop practical improvements.

Explore KAFA Consultancy’s Project Management & Automation Services

---

References and Further Reading

1. Association for Project Management (APM). What Is Risk Management? Guidance based on APM Body of Knowledge, Eighth Edition, covering threats, opportunities and project risk management. Official APM guidance.

2. Project Management Institute (PMI). (2025). A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Eighth Edition, and The Standard for Project Management. Official PMI resource.

3. International Organization for Standardization (ISO). (2018). ISO 31000:2018 — Risk Management: Guidelines. Official ISO resource.

4. Project Management Institute (PMI). PMI Lexicon of Project Management Terms. Definitions of risk owner, risk register, risk response and related terminology. PMI standards and terminology.

5. Association for Project Management (APM). (2025). APM Body of Knowledge, Eighth Edition. Further reading on project uncertainty, risk management and decision-making. APM.