Where Risk Management Trumps Quality Principles
For those of you who haven’t already completely forgotten about the Maple Leaf Foods tainted meat disaster, there is a lesson to be taken away about managing risk.
I find it incredibly interesting that the policy followed regarding testing of meat was to test swabs from the machines. If these were okay then the meat could be shipped. Even more amazing is that, if a machine test swab failed, all that had to be done, by way of accepted industry best practice, was to keep cleaning and retesting the machine until a pass was achieved. The meat wasn’t tested.
It seems like the traditional quality principle failed us this time. That is the principle that says control the process (in this case the process machinery) and you’ll be successful controlling the outcome of the process.
While I can appreciate where some quality gurus might weigh in on this when it comes to processed food, as a consumer and meat-eater, I’d like to see testing done on the end product before it gets to my table.
So what’s to take away from Maple Leaf Foods for project managers?
Let’s start with the definition of quality. There are several definitions but for the PMP exam it’s sufficient to know that quality is ‘every characteristic that influences satisfaction’. Not meaning to be glib I’d say that dying because of your salami sandwich would be most unsatisfying.
When you’re managing a project the quality plan describes how the quality policy will be implemented on the project. And this is where we need to be careful because, if the policy is poor, the project will be a failure.
If the business objective is at risk, for any reason, then as project managers we’re obliged to register the risk and address it. Escalate it if necessary. In the case of Maple Leaf Foods it seems the quality policy on this matter was insufficient to cover a business objective of providing safe-to-eat food.
If your project was to set up a process for making meat you’d want to identify the risk event of shipping bad meat. Clearly in this case sampling the output of the process would have mitigated the impact of the risk event. But this was not in line with the quality policy at Maple Leaf.
The take away for project managers is that, if there is a risk that business objectives will not be met, then those risks must be fully explored, regardless of company policies.
Risk management in projects is not limited to identifying project risks alone (i.e. risk events that may result in cost or schedule overruns). Risk identification should include risks the solution delivered by the project to the business will fail to meet the objectives. No pun intended.