Antiquated Policy Wording: Part 1 — “Must,” “May,” and “Should”
This article is the first of a four-part series on drafting requirements in IM policies, looking at the problems of using the words “must,” “may,” and “should.”
Part 1 — Overview
The traditional use of “must,” “may,” and “should” when drafting policy requirements is problematic. It’s time to modernize our approach to making rules and drop those terms completely. The conventional approach to indicating the relative strictness of these three words can be summarized as follows:
- “Must” means mandatory/required.
- “May” means permitted.
- “Should” means recommended.
The International Standards Organization (ISO) uses a similar model. According to ISO,
- “’shall’ indicates a requirement
- ‘should’ indicates a recommendation
- ‘may’ is used to indicate that something is permitted
- ‘can’ is used to indicate that something is possible…”
Despite their pervasiveness, these terms have two shortcomings: they are heavy-handed, and they lack clarity.
Heavy-handedness: From the reader’s point of view, policies have a tone of voice. Too often, though, that tone of voice is bossy or condescending and does not invite buy-in. If you’ve come across any of my articles (e.g., Have You Considered Tone of Voice?), then you know I am a big proponent of respectful policy statements.
To reflect an attitude more appropriate for the modern workplace, we want to move our rules away from implying a Parent–Child dynamic in favor of an Adult–Adult dynamic. “Must,” “may,” and “should” are all born of a Parent–Child dynamic. They all convey an undertone that says, “We are in charge, and you will listen.” “Must” means “We are in charge, and you will do this because we say so.” “May” means “We are in charge, and we grant you permission to do this.” “Should” means “We are in charge, and even though we’ve decided not to make this mandatory, you would be better off if you did it.”
All three of the terms rely on the underlying presumption that there are two separate interests involved: rule makers and rule followers. That presumption alone is divisive and a barrier to a collaborative work environment. Fortunately, every policy statement that uses one of those terms can be reworded to sound less dictatorial and more inclusive. We will look at how to do that in parts 2, 3, and 4.
Lack of clarity: Although they may seem straightforward on the surface, all three terms — “must,” “may,” and “should” — are ambiguous in far too many contexts. No question, in some corners old habits die hard. Those three words have become fossilized, and some people fear dropping them on the grounds that doing so would sacrifice clarity.
In any discussion about drafting policies, I am the first to assert that the most important goal of a policy statement is clarity. As far as we can control, we want the message we think we are conveying to be the same as the message that is heard. With oral instructions, ambiguity of meaning can be annoying but is rarely irreparable. In most cases, we have context to help us differentiate nuances, and we can ask questions for clarification. Ambiguity in writing, on the other hand, can render a policy statement useless and unenforceable. In short, clarity in writing is key.
Parts 2, 3, and 4 will look at situations where “must,” “may,” and “should” disguise the actual decision being made. Most of the analysis will focus on statements expressed in the positive, because when the terms “must” and “may” appear in the negative, the difference between them all but disappears completely.
Compare the statements:
Paper files may not be removed from the office.
Paper files must not be removed from the office.
These produce identical results. In the first case an action is “not permitted,” and in the second it is “forbidden.” In neither case are you allowed to remove the files from the office. You might think that “may” makes the statement sound more polite, but in this context it doesn’t represent an option. In negative statements, therefore, the argument to preserve the modals “must” and “may” is weakened considerably.
Overall, policy statements are more inclusive when worded as a simple description of the office practice, for example:
Paper files do not leave the office.
With this wording, we capture the strictness of the rule without having to divide people into rule makers and rule followers. Worded this way, the rule applies to everybody.
In parts 2, 3, and 4 we’ll look at ways to word rules that avoid both the ambiguities and the Parent–Child dynamic.
View the PDF version of this article.
 ISO. “Expressions in ISO International Standards And Other Normative ISO Deliverables.”
 Eisen, Lewis. ARMA Magazine. “Have You Considered Tone of Voice.” December 5, 2019.
About the Author
- Lewis S. Eisen, B.A., J.D., C.I.P., offers an approach to drafting policy that has been adopted by groups at organizations such as the Royal Canadian Mounted Police, the U.S. Government Services Administration, and others across Canada, the United States, and the United Kingdom. He is the author of the international bestseller 'How to Write Rules that People Want to Follow: A Guide to Writing Respectful Policies and Directives.' Contact him to run a day-long workshop for your chapter or region.
- Compliance2021.06.01Revisiting Our Views on Non-Compliance with IM Policy
- Communications2020.04.26Antiquated Policy Wording: Part 4 — The Problem with “Should”
- Communications2020.04.15Antiquated Policy Wording — Part 3: The Problem with “May”
- Communications2020.04.08Antiquated Policy Wording — Part 2: The Problem with “Must”
Thanks for this really helpful series identifying how the use of language in policy-writing lags behind new organizational structures and ways of working. These new ways demand more employee engagement and self-direction in line with a more collaborative and less command-and-control management style.
Applying this advice for policies about records and information is particularly important as it is such a large and hybrid domain where everyone is accountable for the protection and retention of corporate data assets at some stage in the lifecycle.
Comments are closed.