[el0hel]

Thanks for the feedback. I agree that risk management is a part of project management. What I, perhaps unclearly, was communicating is that people and organizations can often conflate the two. A project is not managed if all you've focused on are the risks. They are related, but distinct things.

Let's take your example and apply it to my post. Imagine I need a new water heater. I found a contractor/company to come and install it. Should I assume the installation company will bear all the risks associated with a potentially problematic installation? No, I will carry some risk. Ideally, I would argue homeowners should familiarize themselves with the basics of correct water heater products and installation because if it fails outside of the installer's (or manufacturer's) warranty period the homeowner is liable for repairs. It's a stretch of an example because homeowners often share risk with insurers, but I think my point is clear - one should not confuse project management _with_ risk management.

[bumby]

It's a good blog post and highlights a real issue. As discussed well in this thread, there may be incentives that make PMs weigh certain risks higher, but I'm struggling to come up with a project manager task that isn't, in some way or another, about managing risk. I would be curious if you have specific examples you're thinking of. I agree with you in terms of many people conflating the two; i.e., they pretend they've mitigated a risk but all they've done is pass the buck. As you point out, they've confused themselves about what risk management really is.

Regarding the extension of the water heater example, I get what you're aiming at, but I'm not sure I agree. I deliberately used the term "licensed" because that is a risk management mechanism. Credentials and legal structures are a way we can manage risk. In this case, a license is a mechanism to ensure the work is insured in case it's done incorrectly. A bonded contract is another mechanism that mitigates the risk that the contractor won't complete the work. An inspector is a mechanism to manage the risk that the installation wasn't performed to code. None of these require me to know about mechanical systems, or hoop stress vs. longitudinal stress, or any other design elements. Now I agree on a simple example, this may be stretching the analogy. But when we get to really complex projects, I don't think it's entirely reasonable for a PM to be familiar with the aspects to that degree. Of course it's preferential, but on some projects I've been a part of, it's all but impossible for a PM to be knowledgable about control theory, and environmental compliance, and aerodynamics, and material science, and contract law etc. to a sufficient degree to manage the risk themselves. That's why they have systems engineers, codes, inspectors, and quality assurance plans, etc. These are the frameworks for risk management.