:quality(90))
:quality(90))
“One of the true tests of leadership is the ability to recognize a problem before it becomes an emergency.”
~ Arnold H. Glasgow, businessman, humorist, and author
Can business exist without risk?
Risk is inevitable, a nearly unavoidable byproduct of seeking to make a profit. But there’s a big difference between risks we never see coming and those we plan carefully for.
Risk management comes up repeatedly in any discussion of project management best practices because identifying, tracking, and planning for risk are all keys to lessening its potential impact.
One tool agencies can use to better understand and track risk is called a risk register. In this brief guide, you’ll learn what a risk register is, the components you should include, and how and when to use this powerful tool.
What is a risk register?
:quality(90))
A risk register is a project management tool used for identifying, assessing, and managing risks associated with a specific project. Every project worth doing has some level of risk, and a risk register is a way of cataloging those risks so they can be understood, avoided, or mitigated.
A well-structured risk register can contribute to project success by helping all involved in the project see risks ahead of time — including project stakeholders who won’t be doing the day-to-day work.
Who creates the risk register?
While organizations large enough to engage in complex high-level disciplines like project portfolio management may employ a risk manager (or even an entire risk management department) to handle this aspect of project planning, most agencies aren’t operating at that scale.
If that kind of structure isn’t in place, then the project manager is typically responsible for creating the risk register.
If a project doesn’t have a dedicated project manager, then the team member or team lead with project management responsibilities would create the risk register.
:quality(90))
When should a risk register be used?
Ideally, a risk register should be used for every project. The simpler the project, the simpler the risk register. But even short projects tend to run better when everyone understands the risks.
A risk register is valuable at all points in a project lifecycle, offering particular benefits during project initiation and as the project progresses through the execution phase.
Project initiation is the time to first identify the risks that belong in the risk register. Going into a project with both eyes open about the possible risks often helps teams create stronger, more realistic schedules and timelines.
Then, during the execution phase, the risk register serves as a point of reference. In the moment when a potential risk is turning into reality, it’s easy for team members to reach for the nearest available solution, even if that’s not the right solution.
The risk register provides a kind of anchor, reminding project team members that this risk was foreseen and a solution already exists.
Also, be aware that building a risk register isn’t a one-time activity. It’s an ongoing process that can and should evolve as the project does, accounting for new risks as they emerge and updating existing ones as the team encounters and solves them.
Components of a risk register in project management
The more complex the project, the more detailed you’ll want to get, but most projects (regardless of complexity) should include these nine components in their risk register.
1. Risk identification
Identifying risks within a project starts with naming them. Every risk identified should be given a unique name ID number so that all tracking activities can stay organized under the right risk.
Where do you come up with a list of risks? There are several ways to do so. One is looking at historical data: Have you completed similar projects in the past? Where did they go off track? If any failed, why did they fail?
Brainstorming sessions are another good option here. The realists on your team are probably already thinking through potential paths to project failure, so tap into those fears and concerns.
Make sure to capture both known and potential risks; the stuff that’s gone wrong before is important, but so is the stuff that could (but hasn’t yet).
2. Risk description
Second is a description of the risk. Keep it concise yet clear so that project team members and stakeholders can understand at a glance what the risk is about.
Here are a few project risk descriptions that could show up in a creative project or marketing campaign:
Client could interfere with creative direction after sign-off
Changes to campaign scope could affect deliverables and project completion date
A Google Core Update could disrupt content effectiveness and require a shift in strategy
Risk descriptions play an important role in understanding the nature of each risk. Which team members or departments does the risk involve? What are the ramifications if the risk becomes a reality? A good description answers questions like these.
3. Risk category
Not every risk is equally important throughout the project timeline, so teams need to understand risk categories. For example:
Schedule risks are a problem late in the project when deadlines can’t be adjusted, but they’re less crucial early on when the scope is still malleable.
Operational risks are always important but aren’t usually as actionable or adjustable as other types.
Security risks are crucial at every stage, but only a few people have real influence on them.
Common risk categories in project management include:
Project budget
Schedule
Resource allocation
Operations
Technology
Quality
Client
Applying a risk analysis category to every risk is also helpful for data analytics purposes, giving you another way to measure the types of risks a project could incur.
4. Risk owner
Assign each identified risk to a specific person or department. This isn’t to say the owner is entirely to blame should the risk come true. Instead, the risk owner is responsible for solving the problem or developing the solution.
Assigning risk ownership ensures accountability and gives teams a clearer sense of what to do when something goes wrong. It also helps create clarity around who should monitor and manage which risks throughout the project.
5. Risk probability
Risk probability is all about the likelihood that the risk event will take place.
Is a flood a risk for an agency located in Atlanta or Raleigh? Yes. But is the flood probability there the same as in coastal Miami or below-sea-level Charleston? Not even close.
On creative teams, estimating the likelihood of risks occurring is often qualitative. You know how often a client has rejected an initial design, but that number doesn’t guarantee what will happen with the next client (or the next design).
Other risks, like on-time completion, are easier to measure using historical data.
So why worry about risk probability? Because it helps in prioritizing risks. Quality or resource concerns are more likely to occur than floods or fires. So, while you need a plan for those natural disasters, you probably want to focus your risk management plan more on the less disastrous but more likely risks.
6. Risk mitigation
Risk mitigation is the practice of identifying what steps the team would take to resolve the problem if the risk becomes a reality.
Some risks have relatively simple answers on mitigation. If the right course of action can be described in just a few words, then that's all you need to include on the project risk register.
However, many risks in business don't have simple answers. Determining the right mitigation strategy could require a meeting or a series of meetings, and the results may be lengthy enough to need to live in a separate document.
:quality(90))
7. Risk impact
Risk impact is the level of damage that would occur if the risk in question happened. For example:
Is this risk an existential threat to your agency or your client?
Is the risk limited to a lost sale or minor relational damage?
Is the worst that could happen a missed deadline that won't really cause any ripple effects?
You may also want to engage in risk assessment based on specific project objectives. Which are under threat from each risk, and which would be unaffected?
Risk impact often charts closely with risk priority (the next item in this list). But it’s at least feasible for a low-impact risk to end up as a high priority (or vice versa), which is why risk registers note these separately.
8. Risk priority
Risk priority can be a calculation if you’re able to assign numerical values to both impact and probability (in which case, you simply multiply the two figures and end up with a risk score).
But, in creative contexts, risk evaluation is often more qualitative than quantitative. If that’s true for your agency, then prioritize risks based on both the seriousness of the potential impact and the likelihood of the risk occurring.
Prioritizing risks in this way helps focus resources on high-priority risks.
9. Risk status
Last is a column or entry for risk status, which allows teams to see whether a risk has happened, is being dealt with, or has already been addressed.
These three categories are often termed open, in progress, and closed in the risk register.
Make sure to conduct regular reviews of the risk register to keep the risk status column accurate and up to date.
Benefits of risk registers in project management
:quality(90))
Keeping a risk register is a resource commitment. And if you’re still early on in formalizing project management procedures at your agency, the idea of creating a risk register for every single little project might seem like overkill.
But, risk registers can deliver project management benefits. Consider whether these four advantages would help your agency mature in its approach to projects, prioritization, and risk.
Proactive risk management
First, creating and maintaining a risk register promotes proactive risk management.
Perhaps the easiest way to fail to see a risk coming is to not look in the first place. However, the act of creating a risk register forces teams to look for those risks, exponentially increasing the odds that the team will identify, find a solution for, and mitigate that risk if it occurs.
A risk register similarly reduces project uncertainty. Instead of wondering what unknown issues might pop up, teams will go into the project armed with knowledge about many of those issues — including who will address each issue and what steps they’ll take.
Stronger risk mitigation strategies
Along the same lines, risk registers enable organizations to create more robust risk mitigation strategies. When risks are left unsaid, mitigation strategies are fuzzy at best (and usually live only in the mind of one employee who may or may not be around when the, er, risk hits the fan).
But proactive risk management puts meat on the bones, defining those mitigation strategies in clear terms that everyone can see and agree on.
Pattern identification
Risk registers also help to identify patterns from threats. If a specific risk category is repeatedly the type that threatens project outcomes, there may be something deeper to investigate or change. But it’s hard to see this in any quantifiable way if you aren’t tracking it.
Stakeholder confidence
Last, using a risk register enhances stakeholder confidence because it shows stakeholders that a project isn’t being launched without careful thought, planning, and attention.
Further, by being transparent in risk management and creating a risk register, agency teams can build greater trust among project stakeholders.
Manage and mitigate risks effectively with Teamwork.com
A risk log can help your creative team understand what threatens project success. The process can also support the creation of an action plan or contingency plan when one of those risks inevitably becomes a reality.
Adopting Teamwork.com’s suite of project management tools is another powerful strategy for managing numerous types of risks. With Teamwork.com, you’ll gain clearer insights into project progress, task status, and challenges to the project plan. You can use this increased visibility to understand where the threats are coming from and then mitigate those risks efficiently.
:quality(90))
:quality(90))
:quality(90))
:quality(90))
:quality(90))
:quality(90))