“I never had a policy; I have just tried to do my very best each and every day.”
– Abraham Lincoln[1]
17.1 Policy or Program?
I’ve often used the terms policy and program interchangeably, however others differentiate: A policy is an overarching guideline or rule typically established by upper management to guide an organization[1]. Programs tend to address specific issues that an organization needs to address or comply and are established by a specific department[2].
I have also seen the term procedure used synonymously with program, which I do not use because I confuse that with operating procedures.
17.2 Are They Necessary?
About every year or two, a company I worked for received a questionnaire from a bank or owner that included questions on whether we have policies forbidding child labor, deforestation and impacting threatened and endangered species, etc. Since our operations were limited to the United States, we did not have these policies: These were already required by law and we had a company policy to comply with applicable laws. These inquiries made me question whether we need a policy or program. It would certainly be easy and uncontroversial to have these policies but was it necessary.
With a few exceptions (e.g., several of Occupational Safety and Health Administration’s (OSHA) regulations require a program), the EHS regulations do not require a written policy or program. It may be advantageous to have them. Regulatory agencies, insurance companies and prospective purchasers have asked my companies for policies and a formal document can be impressive: It can show your company takes the EHS regulations seriously and has dedicated time and resources to address these regulations.
However, in the “Ten Commandments for Business Failure” Donald R. Keough, the former president of the Coca-Cola Company, has a commandment titled “Love Your Bureaucracy” the implication that too much bureaucracy can cause a business to fail[3]. Although this chapter does not mention policies and programs specifically, it implies that every additional policy or program may just be an additional layer of bureaucracy. Sidney Dekker, the founder of the Safety Science Innovation Lab, also discusses the problems with bureaucracy, but he specifically addresses its impact on safety[4]. Mr. Dekker points out that time spent on paperwork takes time away from more important safety work communicating with operating personnel and on the production floor[5].
At one company I worked for, the environmental management systems required a periodic review of the environmental programs. This was another layer of bureaucracy, but the questions were designed to assure that the program was effective and efficient. Additionally, one of the review questions I added was whether we even needed the policy. I did not want an unnecessary policy, and this forced us to question having that policy every few years.
What I have found is that we sometimes develop policies and programs, but really only need guidelines. In the book “Do Safety Differently”, authors Sidney Dekker and Todd Conklin discuss the concept of freedom in a frame:
“Freedom in a frame acknowledges and deploys the kind of professional autonomy and trust that allows people to know the boundaries of their roles and authority, yet encourages self-sufficiency, adaptive capacity, interpretative discretion and local innovation.”[6]
One of the implications I have taken from the freedom in a frame concept is to not spend as much time writing policies and programs, which, when written by EHS staff, may not allow the workers flexibility to safely and compliantly perform their work. Instead, I like to focus on providing appropriate guidance and only frame the work with policies and programs that are necessary (e.g., regulatory requirements, potentially fatal activities).
17.3 What To Include
The policy or program could just reiterate the regulatory requirements, but you may want to go beyond that to include more information to explain the regulation in layman’s terms. Items to include in a policy and program might be:
- Purpose: Why you have the policy or program, even if it is just to comply with a regulation.
- Scope: Who does the policy or program cover or what facilities, or operations are covered.
- Requirements: What the policy or program requires such as inspections, training, etc.
- Record retention: The record retention requirements (e.g., how long you keep) for the various documents created as part of the policy (e.g., completed inspection forms).
- Revision date or number: The revision date or number helps personnel know if they have the most recent version.
- Revision history: a detailed list of changes made to the policy or program so personnel can know when changes were made and what modifications were implemented.
- Uncontrolled When Printed: Companies include this text on documents to clarify that printed documents are not subject to updates (i.e., if a new revision is issued).
Another item I like to add to policies is a requirement to report issues (e.g., deviations, violations, etc.), because the regulation may not require reporting, but you want to know about these issues.
The level of detail in a policy or program is likely a personal preference. When writing a policy or program, consider whether something should be a requirement or something that could be provide to personnel as guidance. A company travel program where I worked included details on traveling in winter months: In one draft of the program, it specifically required you to carry certain items including a working flashlight. I found this level of detail frustrating because, if I forgot to bring a flashlight or the batteries had died, I would be in violation of a company program. Items like that can be instead conveyed as guidance. In the example above, we created winter driving guidance that was conveyed to company personnel but not required. This may seem nitpicky, but regulatory agencies can hold you to enforcing your policies and programs, so it is also an unnecessary compliance liability.
The policy detail level is a matter of personal preference. My preference is a prescriptive policy where you provide the policy intent and give latitude to the affected personnel to implement it as needed. If more information would be helpful, I would provide that as guidance (i.e., not a requirement), maybe as an attachment to the policy or training. A descriptive policy spells out the specific requirements and makes it clear exactly how the policy should be implemented. The flashlight requirement is an example of a descriptive policy. In a prescriptive policy, the winter driving recommendations would be attached as a guidance document..
A concept I have been wrestling with over the years is whether we should be addressing just dynamic issues and items (i.e., items that are prone to change) or also include static issues and items in polices and training. Take ladder policies and programs that might discuss inspection before use, proper angle of use and other dynamic items. Should it also address cages on fixed ladders? This should be a static item that does not change on a day-to-day basis, so are you diluting the message by including it? Who is the audience for the policy or training? If the policy or training is for the workers using the ladders, they likely do not need to know this, but if they ran across a fixed ladder without a cage, it might be helpful. If the policy or training is for engineering or maintenance personnel or personnel who might be conducting annual inspections on fixed ladders, they might need to know about this requirement.
17.4 Who Should Be Involved
When developing a policy or program, I feel it is imperative to get involvement from personnel affected by it. It may be easy to sit in an office and churn out a policy or program, but it may not be accurate or appropriate if you do not get input from those that will be implementing or impacted by its requirements. I used to refer to these as Mother Goose documents since they were fairy tales (i.e., not implemented as written). Getting affected personnel to work on the policy or program also helps with employee involvement and engagement which can improve your EHS[7].
17.5 Who Should Approve
You may want to establish who can approve and roll out a policy or program. Your organization may benefit from controlling the development and rollout of policies and programs, so having a gatekeeper is important. This person or persons would serve the following purpose:
- Compliance with company program and policy requirements
- Management commitment
- Quality check
- Verification that the policy or program is necessary
17.5 References
[1] “Policy vs Program: When and How Can you Use Each One?, The Content Authority, accessed April 24, 2024 (https://thecontentauthority.com/blog/policy-vs-program)
[2] Ibid, accessed April 24, 2024.
[3] “Ten Commandments for Business Failure” by Donald R. Keough, Portfolio/Penguin, New York, New York, 2011, Page 115.
[4] “The Field Guide to Understanding ‘Human Error’” Third Edition by Sidney Dekker, CRC Press, Boca Raton, Florida, page 149.
[5] Ibid
[6] “Do Safety Differently” by Sidney Dekker and Todd Conklin, Pre-Accident Investigation Media, Santa Fe, New Mexico, 2022 page 124
[7] “Safety and Employee Engagement—What’s in It for Them?”, By EHS Daily Advisor Staff, EHS Daily Adviser Website, July 11, 2019 (https://ehsdailyadvisor.blr.com/2019/07/safety-employee-engagement-whats/#:~:text=Among%20the%20many%20potential%20benefits%2C%20employee%20engagement%20with,…%207%20Maintain%20a%20positive%20cash%20flow.%20)