This is Part 6 of our series on project risk management for hardware product development. In our last post we explored the project risk management (or learning management) process. For the next few posts we will dive deeper into each step of the process. This post covers step 1, project risk identification and risk capture.
As a reminder, in Part 1, we looked at the definition of risk management and discussed how the trick to effective risk management is to learn – both carefully and quickly – in the right balance.
In Part 2, we looked at the key piece of project risk management – the project’s objectives and how effective risk management must start with defining project objectives. We concluded that project objectives are best established in economic terms such as sales volumes, sales price, cost of goods sold, and project expenses. As well as the all-important launch schedule, which directly impacts the other objectives.
In Part 3, we looked at another key piece of project risk – the uncertain events and conditions that are the cause of a risk.
In Part 4, we looked at the return on investment of risk management and how to calculate risk exposure.
In Part 5, we explored the risk management (or learning management) process.
Now, let's look at the process step by step starting with risk identification and capture. (For your referenence, the full project risk management process is outlined at the end of this post.)As a reminder, before we can effectively identify and evaluate risks, the team must have clarity around the project’s requirements and objectives. For the purpose of this discussion, we will assume project objectives and requirements have been defined.
First, what risk attributes should you capture in the initial identification stage?
In risk identification, there are four attributes of each risk to capture.
- Assign a title: The title is a short 1-5 word name for the risk.
- Describe the risk: Provide a short description of the risk; enough to get the team thinking about the right things when they get to the Analysis step. During analysis,the list of risk drivers - key questions we’ll need to answer to mitigate the risk, will be completed. Often the description includes risk drivers. In fact, many teams we work with don’t actually capture a separate description, but rather they start by populating the drivers. This is fine as it serves the same purpose.
- Assign an owner: We must assign each risk an owner. The risk owner is the person responsible for making sure the risk is analyzed and mitigated. This may or may not be the person doing most of the mitigations.
Note: Avoid the temptation to assign multiple owners. Capturing who needs to be involved in the discussions is a good idea when it isn’t obvious, but have a single owner who can be the main point of contact about the risk and who has primary responsibility for getting it through the risk management process.
- Estimate risk severity/risk exposure: Rating the risk is optional at this stage but it helps establish priorities for risk analysis and planning. Rank each risk high, medium or low. The severity rating can be changed during analysis.
Risk identification can occur any time. Risk capture must be easy.
Ideas, concerns, and questions which are the basis of a risk can pop up at any time. Of course, when an engineer is reading through the project’s requirements, there are always questions that come to mind. When we are developing conceptual designs, mockups, and early-learning tests, even more new ideas and questions come to mind. But that’s just some common on-the-job examples.
Ideas, concerns, and questions can also come up when we’re driving home, just dozing off for the night, or in the morning shower. They can come up when we’re doing something completely different like working on a home project, or coaching our child’s team.
As such, making it easy to capture these ideas any place, any time is a key requirement of an effective risk managment process. Risks that don’t make it into the risk management process will become future issues and ultimately reduce profits.
Holding an effective project risk identification meeting
One important way to get ideas out in the open is what most people think of when we talk about identifying risk, holding a risk identification meeting. Whatever you call it, a risk identification meeting is generally is characterized by a team meeting, which includes most or all of the core team members and often some more peripheral team members.
It’s often helpful to pull in a few people not on the team but with experience and knowledge of risks the team members may not yet have.
The meeting could be an hour or two long, or could go on for a few days. The ones that go for days, which I’ll call "deep dives" per the vernacular of one of our clients, actually take some of the risks further through the process into analysis, planning and even mitigation. But in each case, first comes identification.
Generally, this meeting is time we dedicate to being open about new ideas and concerns. It is essentially brainstorming about what could go wrong on a project. Astute teams will also include some time to identify opportunities to go above and beyond the current objectives.
As with most brainstorming meetings, it is important that there is an absence of any jumps to judgement about the validity of the ideas. When an idea or two is quickly shot-down, the person offering those ideas will often just stop making their ideas known. Any other ideas that person had will instead fall into the pool of things you’ll just take your chances on, some of which will become issues you could have avoided by keeping the communication going.
This openness to accepting ideas and concerns holds equally true when risks are identified outside the meeting as well. Every risk/concern/question anyone has should at least make it into the ‘analysis’ step. If the risk is invalid, it will be designated as such during analysis or planning stage. The important things are that it’s considered and recorded, to keep the communication flowing, and in case it turns out it was not invalid after all.
I’ll offer a few more tips for an effective meeting, but keep them short, so we can move on to the other ways we identify risks:
- Start out making sure everyone knows the rules: No judging, avoid interrupting others and jumping around to too many different topics too fast, etc.
- Give everyone a stack of Post-it notes or access to the electronic tool you use to capture risks. Ideas often pop-up during discussion about a different risk but are ‘off-topic’ enough to defer. Have a quick way to keep them from being forgotten.
- Include every type of risk you can imagine: technical, supply chain, marketability and other risks which are more project-specific, but also those resource and process risks (such as resources being pulled off the project to do other work). Outline the main categories, focus on one category at a time, and cover all of them.
- Use a Risk Checklist. This is a list of common risks we’ve identified on previous similar projects. If this checklist isn’t available, review risk registers from past projects with the team and use those to jog the team’s memories.
The risk checklist can also include other important info, such as mitigations that have worked well previously, answers to questions, as well as recommendations on which people (roles) to involve in risk analysis and mitigation planning.
Capture just name and description initially. Then go back toward the end of the meeting to assign owners and initial exposure ratings. Keep people focused on what could go wrong until the popcorn stops popping. (The rate at which people are identifying new risks drops to a trickle.)
Other team meetings and discussions are a great opportunity to capture risk
During other team meetings focused on a specific topic, new ideas and risks often arise. This is common in meetings about design concepts, project/product requirements, product architecture, and design reviews, but any meeting has potential for new risks to be identified.
Most teams have a weekly team meeting to review the project status and resolve schedule issues. This meeting, like the other examples above, often has new risks brought to light during the conversation. However, this meeting also presents a good opportunity to solicit risks that may not have yet made it into the conversation.
Allocate 5 minutes in the agenda for a little risk identification meeting, where the team is asked to think about what else could go wrong and/or what new ideas are there to improve on the current plan. Sometimes there won’t be any new ideas, but when there are, this is a good way to keep them from falling through the cracks.
Similarly, teams having frequent stand-up meetings can have 1-minute dedicated to risk identification. This provides a good platform to collect those ideas that came up outside of work, during the drive into work or morning shower, and for those that come from ad-hoc discussions at the proverbial water cooler (or coffee machine).
More tips for getting new risks into the risk management process
In every case, an easy way to capture risks in the risk management system is critical. Some recommended ways to easily get newly identified risks into the system include:
- Have a good electronic system (such as PLAYBOOK) that is shared across the team and is easily accessible to everyone, rather than a spreadsheet that can only be edited by one person at a time.
- Until you have such a system, have the ’risk register’ (e.g. Excel file) centrally located on a shared-drive. Make sure everyone knows where it is and how to add a new item.
- Have a white-board or some designated wall-space in the room where the team meeting and/or standup meetings are held. Have people put new risks onto a post-it note and stick it to the wall as soon as something comes up. The project manager can collect those and get them entered into the risk management tool.
Once a risk has been officially identified, it is up to the owner to get it into and through analysis and planning quickly. The higher the risk, the faster it should go through the rest of the process.
In the next post, we’ll start reviewing the details of the analysis step of the process. Analysis has more sub-steps than identification, so it will take a couple/few posts to get through it all. However, good analysis is one of the keys to good risk mitigation, so we want to make sure the analysis steps are clear.
Interested in taking risk management a step further? Download your free risk management template.
The Learning Management ProcessThe learning management process is cyclical, and we put each risk, issue, question, and opportunity through it as quickly and independently as we can.
We’ll start with an overview of the process steps, before we get into detail in each area (in future posts).
a. Briefly describe the risk
b. Give it a short name
c. Assign it an owner
a. Determine/Document the risk drivers
b. Evaluate impact, probability, and exposure
c. Establish value rating (High/Medium/Low)
d. (Sometimes) merge with or supersede another risk
e. (On rare occasions) determine it is invalid
a. Evaluate mitigation options and determine which mitigations to implement
b. Establish a detailed mitigation plan, integrated with the overall project plan
c. Establish burndown milestones (Milestones after which we re-evaluate the status and rating of the risk.)
d. (Sometimes) decide not to mitigate the risk, because the mitigation cost is too high compared to the value