My long-time co-workers will tell you the following about me:
- She’s usually prepared for most contingencies. “Worst case scenario? She’s likely considered it.”
- She hates surprises.
So the idea of Risk Registers? Trying to prepare for everything?
Being more optimistic sorts, the Project Management Body of Knowledge defines risk as
…An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.
Risk Registers help you identify and plan responses for known risks.
Because…um…you can’t plan for what you don’t know.
Step 1 – Collect Information
- If your organization has templates and processes for risk management – get them.
- CDC Risk Management Template – This is a Word file that is a full risk management document
- University of California Enterprise Risk Management Tools – Multiple documents for analysis
- Other templates – for smaller scale organizations and projects (Google Search)
- If you have projects similar to the one you are pursuing, look at the records from previous projects.
- Take advantage of Lessons Learned. Did anything happen that they didn’t anticipate?
- Look at your project intake notes or documents.
- Who are your stakeholders? What is their risk tolerance?
- What is the impact if one of the stakeholders changes?
- Talk to people
- What sort of surprises do they encounter as they work?
- What is going on in the environment that might impact your project?
Step 2 – Organize Your Information
For many of the projects that I work on, I like this framework of categories from the PMBOK (slide from a presentation from Marco deSantis)
A few areas I pay particular attention to…
- Technical – Particularly the technology (1.2) and the complexity / interfaces (1.3). I find that most products fail testing when you walk through a process and move between modules or section. You know – when trying to do real work.
- External – If your organization has had prior relationships with particular sub-contractors and suppliers (2.1), what were the relationships like? Did they tend to deliver on time or late? And what is your relationship to the customer (the person or people requesting the solution) (2.4)? Will they participate? Over-participate? Can they make timely decisions? Do they stick to those decisions?
- Organizational – Pay attention to all of this! What happens if you can’t get the star developer on your project? Or if you get the star developer and they leave half-way through the project? What happens if other priorities become more important for the organization and suddenly the people on your project stop working on your project? What happens if another project that impacts YOUR project doesn’t finish on time? Or worse, gets cancelled?
The other stuff will happen. Those tend to be the areas that bite me in the tail during projects.
Step 3 – What is the probability that risk is going to happen?
For each risk that you have identified, put it in a Probability and Impact Matrix.
I like this one from IndustrialAudit. The page gives a nice summary of Risk Management.
This is a good time to pull out the post-its, markers, whiteboards etc and brainstorm with friends.
They may find more risks.
You may learn that some things are more important / likely than others.
Step 4 – What are you going to do to mitigate that risk?
This is where you build the risk register.
If your organization doesn’t have a risk register template, there are plenty of options available online.
Eventually, you wind up with a reference document that will help you make decisions when you encounter those risks during the course of the project.
Martin Davies at Causal Capital has a very nice blog post outlining things to watch out for as you use Risk Registers. HIGHLY recommended read.
Even with those warnings, it is best to have SOMETHING to help guide your decisions as you encounter opportunities and challenges in your projects.