“There is no greater evil than men’s failure to consult and to consider.” Sophocles
In our office, we write a lot of recommendations. As a rule, we begin recommendations with the words “consider” or “confirm.” This isn’t because we’re looking for weasel-words. It’s because not every recommendation is the best idea. Some recommendations aren’t even good ideas. We think recommendations should make things better and it’s only with proper consideration that good ideas get implemented and other ideas get shelved.
Recommendations can come from anywhere. In process safety management as covered by the PSM standard (29 CFR 1910.119), recommendations are a requirement. The regulation requires recommendations to improve the safety of a covered process from PHAs, management of change, pre-startup safety reviews, incident investigations, and compliance audits. Any recommendation generated as a requirement of complying with regulations must be resolved and resolved quickly.
Specifically, the language of the PSM standard states
- in (e)(5) that “the employer shall…assure that the recommendations are resolved in a timely manner and that the resolution is documented,”
- in (i)(2)(iii) that “the pre-startup safety review shall confirm that … recommendations have been resolved or implemented before startup,”
- in (m)(5) that “the employer shall establish a system to promptly address and resolve the incident report findings and recommendations. Resolutions and corrective actions shall be documented,” and
- in (o)(4) that “the employer shall promptly determine and document an appropriate response to each of the findings of the compliance audit, and document that deficiencies have been corrected.”
You should get the impression that OSHA is pretty serious about recommendations being resolved, being resolved without delay, and being documented. This means that as soon as a recommendation is made, somebody has some work to do.
Resolving a recommendation doesn’t necessarily mean implementing it. The task of the teams that are performing the PHAs, pre-startup safety reviews, incident investigations, and compliance audits is to identify problems. Sometimes the teams that identify problems are also the right teams to identify solutions, but there is no reason to expect it. This means that the recommendation that a team makes when it identifies a problem may not be the best way to solve the problem. It may not solve the problem at all. In fact, it’s entirely possible that a recommendation, when implemented as suggested, will actually make a problem worse.
Because of this, while the standards insist that all recommendations be resolved, they never insist that all recommendations be implemented. The requirement is that recommendations be “resolved or implemented.” Certainly, implementing a recommendation is one way to resolve it. However, resolving a recommendation may consist of a course of action that bears little resemblance to what the team making the recommendation first envisioned.
Some of the teams we work with are uncomfortable with the word “consider.” They fear that “consider” means that their organization can simply say, “Yeah, we thought about it—we considered it—and decided not to do it.” They fear that “consider” means that their organization can “weasel out” of doing something about the problem they’ve identified.
Nothing could be further from the truth.
All recommendations must be resolved and the resolutions must be documented. By documenting a resolution, it would not be enough to write a memo listing the recommendation followed with the notation, “ “It was considered and determined to be unnecessary.”(In other words, “We considered it and decided not to do it.”)
When a recommendation is considered, alternatives are identified. It may be that one of the alternatives is “Do nothing.” The alternatives are analyzed. The analysis is recorded and the logic behind the eventual course of action is documented, explaining why it was the best choice. While people may disagree on what the best choice was, the alternatives and underlying assumptions will be laid out for others to see. Then, whatever the course of action is to resolve the recommendation, it will be documented and completed as soon as possible.
Given the effort necessary to justify the resolution of recommendation, it is important that only serious recommendations be made. Recommendations should act as additional safeguards against the hazard being addressed and they should contribute to reducing the risk of that hazard to a tolerable level. When a recommendation doesn’t safeguard against the hazard being addressed, it doesn’t belong in the list of recommendations. Likewise, when the risk of the hazard can be shown to be less than what is tolerable, then there is no need for additional safeguards and so no need for the recommendation.
On the other hand, when a hazard is identified that has a risk higher than what is tolerable, enough safeguards must be recommended to reduce the risk to a tolerable level. A resolution of “do nothing” is unacceptable. When a recommendation is not viable, “consider” becomes very important; “consider” then requires that someone determine a resolution that is viable and that will also reduce the risk to a tolerable level.
The other word we use to begin a recommendation is “confirm.”
Items to confirm are safeguards the team already believes are in place, but they are not quite certain. When a safeguard exists, it is appropriate to take credit for it. When team isn’t certain that it exist, at least not as they imagine it, then it is not appropriate to take credit for it. It is appropriate, however, to make a note that it might exist and then check it later. This is what we call “confirm.”
The interesting thing about a recommendation to confirm is that it is not necessarily a recommendation to implement. If the follow-up to the recommendation confirms that the safeguard exists, then by all means, take credit for the safeguard. On the other hand, if the follow-up doesn’t confirm that the safeguard exists, then there is a whole new set of questions, all centered around whether the safeguard should exist. In the case where the follow-up doesn’t confirm that a safeguard exists, the recommendation then becomes one of considering whether the safeguard should be implemented.
Again, when the risk of the hazard can be shown to be less than what is tolerable without the unconfirmed safeguard, then there is no need to add it. Likewise, when the risk of the hazard is more than what is tolerable, then the course of action should be to implement the best safeguard, not simply the one that was suspected of already being in place.
Leading off a recommendation with the word “consider” or “confirm” is not a way to get out of doing something. They are not “weasel words.” They are a way to remind the team that the purpose of a recommendation is to highlight the need to address a hazard and to suggest a way that the problem might be solved. Correctly done, the consideration of a such a suggestion is a rigorous analysis.
Consider your own recommendations
This is the point in a blog that there is a call to action, a recommendation for readers to follow. In the spirit of this blog, let me recommend that you consider whether your recommendations need to be structured differently. Consider making them more flexible, so that they clearly define the problem that needs to be solved, and leave it to the team responsible for detailed design and implementation to determine the best resolution.