Beyond Agile (2/52): Thinking About Project Risks
There are many types of project risks but they all fall under 2 categories - risks you prevent, risks you react to.
Do a quick Google search on Project Risks?
Numerous opinions and written material can be found on 10, 15, 40, 100, N number of types of project risks.
7 common project risks and how to prevent them
Scope creep.
Low performance.
High costs.
Time crunch.
Stretched resources.
Operational changes.
Lack of clarity.
Although it is good to know the various types of risks that can derail your project progress, for those either starting out in Technical Program Management or Project Management in general, it can be overwhelming understanding and track the vast number of risk types.
All you need to know is that there are only two categories of risks:
risks you prevent from happening
risks you react to after they happen.
Risks you prevent require a pre-emptive solution or mitigation to prevent from happening.
Risk you react to require a swift, decisive, and actionable plan to get the project back on course.
Let me share examples to help better understand the two categories:
When building a HW schedule, say for a consumer personal computing device, there are number of certification milestones you must clear before you can sell a device to consumers. Certification is falls under the category of risks you prevent.
For example: When I built the HW schedule for Android Things Lenovo Smart Clock v1.0, for certification milestones, I made sure I allocated as many devices from HW builds as I could for only Certification Activities. I lined up Pre-cert testing milestones in the adjacent SW schedule so we could catch cert blockers early. Mitigation is key.
When a feature you are working on turns out to be more complex than you originally expected, this can lead to schedule delays. This is a risk you react to category. So, what do you do?
Example: The v1.0 of the iOS Home App had a fantastic low user input HomeKit device setup UX. Unfortunately, the HomeKit framework was not setup, due to engineering decisions in prior iOS releases, to support this UX. The Home App cross-functional team, which included design, framework and frontend engineer, rapidly put together new solution paths which we reviewed with the SVP of SW Engineering and other Apple execs and charted a new course which allowed us to retain some of the UX proposed while still sticking to the iOS release schedule. If we wanted to build the UX originally proposed, we would’ve had to delay the Home App launch. Rapid Decisiveness is key.
With every project you work on, with every schedule or project plan you build, make an active effort with the cross-functional team to list out all possible known risks and put them into a Risk Register with possible solutions. For Risks that require reaction after they happen, make sure that you as a TPM have established robust processes to get the right information to the right leaders and guide them towards an effective and reasonable solution.
Risk management doesn’t need to be complicated but it is often the most overlooked aspect of any project. No one pays attention until project is circling the circle of doom. By just focusing on these two categories of risks - you can catch things early or make better decisions later.
Until next time.
-Aadil 👋
Further Reading: I recommend reading one of my favorite books on this topic - Risk Up Front. They have tons of strategies and templates on how to work with Project Risk more effectively.
Feedback: Was it useful? Relevant? Help me to improve!
