What a complete embarrassment to realize I have gone 2 1/2 months without authoring a post. Which I guess means I have to say Merry Christmas, Happy New Year 2013, Happy Asian New Year of your choice, and (for my U.S. readers), happy President’s day next Monday.

Recently, Angel Candelario featured my Writing Operating Procedures course/book, which is still available for free by contacting me at mrprocedure@gmail.com, on his fine Tech Writer News blog. This brought a (very gratifying) new rush of requests for the book (people like free, that I have learned!), which I have been more than happy to fill.

One request came from a gentleman named Johan (I don’t know what country he hails from), but in his request, he described his technical writing credentials, and he closed his request by saying:

In particular, I’d be interested to see what you have to say about the use of “shall” versus “must” in procedures …   🙂

This was a very good question, which I answered privately to Johan. I did not directly discuss “must” vs. “shall” in Writing Operating Procedures. But in reality I did discuss this. I hope Mr. Johan was satisfied with my answer, though it was likely not what he expected.

In general usage, as far as I am aware, “shall” is considered to carry more weight in standards than “must.” For example, “the worker shall clock in and out every time they enter and exit the plant.” This would be considered better form than “the worker must clock in…”

To me, the more critical issue is “the worker shall clock in and out…” is not a statement of procedure. Specifically, the statement is not telling the worker how to do anything. This statement describes a rule, which makes it a statement of policy. It is not a statement of procedure.

In Section 2 of Writing Operating Procedures, I discuss the difference between policies and operating procedures. One point I make is that in most renderings of ISO documents, what organizations call “operating procedures” are really policies. Usually these documents (called “tier 2”) will list activities in order, with who is responsible for what (i.e., “the test lab shall certify the product”). This is necessary and good information, but it does not tell anyone how to do anything. For that reason, I do not place such information in procedures.

Now, in a procedure, I will use the word “must” in cases where I need to emphasize something important. For example, I may say “the clamps on the mixer lid must be sealed before starting the mixing blade.” You could argue that is a statement of policy, but it is really a condition to be met before performing a procedure step.

For people concerned about ISO ramifications of their documents, ISO does not specify any tiered structure. So an organization can follow my recommendations on document definitions without fear of reprisals from their auditor.

If this is your first exposure to my FREE offer of the Writing Operating Procedures course, please don’t hesitate to write me for your copy. It’s in .pdf form, so there is no production cost and you will receive it as soon as I receive your request.

Happy writing! Mr. Procedure