By Heather Anderson-Schroeder
for the 2024 Risky Women Writing Competition, presented in partnership with Bovill Newgate
How to make policy relatable through everyday examples like baking a chocolate cake. This article illustrates the importance of policies, standards, and procedures in driving compliance and program success. Learn how clear guidelines and effective controls can enhance understanding and implementation, ensuring that policies support innovation and risk management without becoming barriers.
Recently I had the opportunity to attend a working session where the purpose was to document a plan that would stand up a program that could successfully support policy and then vice versa. As part of the working session, I was asked if I could present the current policy and explain where the risks and opportunities were for the policy and what were the recommendations to improve the program, generate higher usage, and thus higher compliance to the policy. As I was preparing to present this information, I realized in order to help the people driving this work we needed to take the idea of policy out of corporate speak and bring it to an everyday life event that can be experienced. In taking the idea of policy and relate it to an everyday task to show the value and importance of policy that they were missing. Policy is not always top down; it can go bottom up and in a circle.
As a hobby baker, the example I used to help tell my story was around baking a chocolate cake. Policy, at its very core, sets the rules and guideline of what needs to be done in a program. A Chocolate Cake at its core has some basic requirements for it to be considered a Chocolate Cake, the most important requirement being that it contains coco powder or a type of chocolate.
There are many kinds of Chocolate Cake, each just as tasty and delicious as the next, but each one has additional details and requirements that make the unique type of Chocolate Cake. This is where a Standard can come in, a Standard provides more detail in the requirements for what is needed to be in the Chocolate Cake other than just coco or chocolate. Example a Chocolate Fudge Cake vs a Chocolate Cake, the standard will define that the Chocolate Fudge Cake is dense in texture where a regular Chocolate Cake is light and fluffy. A standard defines the difference and more details on the requirements; however, the steps and ingredients would be defined in a recipe.
A Recipe provides you all the ingredients and steps needed to ensure that your Chocolate Cake will be tasty. A Recipe, like Procedures, provides a user the right detailed requirements needed to ensure the Policy is being followed, weather a user inherently knows it or not. If the recipe for a Chocolate Cake did not require a type of chocolate, I would not be able to say I am baking a chocolate cake. Procedures work the same way; you want to make sure that the right steps are documented to help set users up for success. You want procedures to be clear for the user and to offer examples when that is applicable. Have you ever used a recipe from a grandparent where you have to figure out what is meant by sugar, do they mean white, brown, raw, or something else. Or to understand what is meant when they say cream, do they mean sour cream, heavy whipping cream, or half and half. Having procedures that any user, a new hire to an experienced employee, can understand helps to ensure that the program and the people using the program procedures are following policy.
A Recipe with the ingredients and steps is only helpful if you know how much of each ingredient to use. The how much of what to use is key, not enough butter or oil and you have a dry cake, not enough sugar your cake will be bitter and so on. Measurement of each ingredient is key; the measurements can be considered the controls. Controls provide the check points in the procedure or automation help a user preform the actions as documented in the procedure or system flow. These checkpoints ensures that the procedure, program, standard, all the say to the policy is being followed. Controls range from being fully manual to fully automated, either way the controls are there to help ensure that unintended risk is not introduced to the company or if it is it can be mitigated efficiently with no or a limited impact to a customer.
Once I was done presenting policy through this lens, I could see some realization occurring. Policy is not there to get it the way or to make up rules just for rules sake. There is a reason for a policy, and it is not so that risk and compliance can get in the way. A good policy does not mean that every detail of what needs to be done, is documented in policy. Policy is there to provide the highest requirements to allow the programs to flex and change as innovative approaches, technology, emerging risks, or regulations are released. The details are the purpose of procedures and controls to help to make sure that users are following the documentation and if a user is not there stops along the way to make sure that user does not get too far down the road before they find out it was done wrong and they now need to start over, which I have done when I bake, and to be honest it is really frustrating to have to start over.