Risk on the Fly

 

This brief is going to read like course notes! I wrote about a lesson learned in ignoring proper risk appraisals & risk documentation in my previous blog.

I hardly hear nowadays — the words quality & risk used literally particularly when a project, stage or project phase duration is deemed short; unless quality & risk are explicitly specified in requirements. Work seems to be always in a rush, with little time to spare for thinking through what was planned the first time around. Working on projects feels a lot like routine operations. Couple with the fast pace in Agile, the notion that if it works one should just go with it again seems to be the new norm. Working like clockwork may help the team deliver any assigned project pronto, eliminate overall project risks, and minimize disruptions. But it presents a downside, among which include:

• Reliant on routines & safe zones
• Complacency
• Falling behind in exploiting new & emerging skills & technologies 
• Loss of innovation (capability)
• Eroding (team) professionalism

Whatever the circumstances may be to rush a project (or lagging project activities), give a thought for project risks. It is an essential management attribute of a quality project. A quick recap on dealing with project risks ~

Some structures. There has to be some form of structure when discussing risks. Consider a structured approach to administer project risks. For starters:

• Adapt guidelines & recommendations of a risk standard to the needs of your business or project. The standard may be from PMI or any other recognized bodies.
• Categorize identified risks e.g. high, low, medium; where possible put a value to the risk e.g. risk score or perhaps cost should the risk occur.
• Plan to mitigate the threat or exploit an opportunity; and put in place contingencies should the risk event happen. Keep in mind that contingencies for positive risks are meant perhaps to seize the moment e.g. secure pre-authorized approval to act. 

Give it some numbers. Create a risk score ႟. There are different means to evaluate risk. Choose a suitable approach /template e.g./wordings. Rate your risk attributes e.g.:

1. What is the likelihood the risk will happen
2. What will be its impact
3. How hard is it to detect the risk (easy ↓ hard ↑ )

႟ = Risk Likelihood ✘ Risk Impact ✘ Risk Detectable

I would advocate framing risk & quality agendas when discussing project activities; especially when hard pressed for time to examine & investigate associated risks & quality concerns in separate meetings. For each prioritized risk:

Remember ...

1. Assign risk ownership - as internal control & to flesh out the following points later
2. Plan risk responses i.e. risk mitigation; and
3. Implement risk responses (may entail changes to plans /activities at subsequent meetings), and monitor the risk response plan/activities (a QA task because the processes to monitor risk responses being put in place & in-effect are essentially quality processes)
4. Plan for contingencies
5. Test (where applicable) & review planned contingencies for identified risks. Depending on the context, risk contingencies may utilize evolving technologies which may silently run out of efficacy with knock on effects e.g. no parts, no expertise, no vendors. That will be really disastrous when you then have a useless contingency plan in hand. This brings us back to why we must revisit to review, revise & renew RA templates /samples /past submissions.

References

• Lukas, J. A. & Clare, R. (2011). Top 10 mistakes made in managing project risks. Paper presented at PMI® Global Congress 2011—North America, Dallas, TX. Newtown Square, PA: Project Management Institute.
• Hillson, D. (2014). Managing overall project risk. Paper presented at PMI® Global Congress 2014—EMEA, Dubai, United Arab Emirates. Newtown Square, PA: Project Management Institute.

"Documentation is not understanding, process is not discipline, formality is not skill." — Jim Highsmith, Adaptive Software Development