In the following sentence, “Unless indicated by qualifiers such as ‘may’, all provisions in this SOP are required and are to be interpreted as ‘shall’ statements”, I want it to mean that every statement that tells you to do something is required. But statements such as definitions in a list are not included because, well, they’re not requirements to be met.
I’m not sure about using the word provisions. Is it the correct word? Is there a better word?
Can this be stated better? Should I just leave it with this, Unless indicated by qualifiers such as ‘may’, all provisions in this SOP are required. ? Hmm, I may like that better.
For a little context, this is a brief, high-level SOP defining Validation for my company (not Verification, which will be elsewhere). This is a parent SOP and all testing activities will fall under its umbrella.
In an early section, where sections include purpose, scope, departments affected, and whatnot, this is the only sentence in a section I named Document Convention. That title may need tweaking too.
I’m probably overthinking this, but so be it. And thanks for your help!
If I did that, then there would be shalls all over the place. I want the default to be shall, and the exceptions to be may, or it’s advisable, or it’s recommended…
I’d avoid “shall”, since it can be ambiguous. (“You shall go to the ball, Cinderella!” is a promise or a prediction, not a command.) Use “must” for obligatory commandments, “may” for permissive statements.
If you do that consistently, you won’t need the general interpretive provision that you are intending. I’d argue, in fact, that if you think you need such a provision, that means the body of the SOP is poorly written, containing ambiguous statements. The fix you need is to rewrite the ambiguous statements, not to put in a general interpretive provision.
Must can also be used similarly: Brenda, you must try this beer, it’s great and you’ll love it! It’s the same problem. That’s why I do not like using shall or must. If it is stated in the SOP then it is a requirement. Unless I explicitly state, you may try this good beer. Then it is obviously optional.
Examples (from this SOP; wonky formatting pasted from Word, the o are sub-bullets under the • ):
8.2 Test plan
Testing is to be planned beforehand and documented in a test plan. The plan is to be approved prior to formal test execution and includes but is not limited to the following:
• Purpose
• Product(s): the product(s) or item(s) to be tested
• Scope, including:
o features/items to be tested, to be itemized in a numbered list
o features/items not to be tested, as applicable, itemized
o feature-independent tests, as applicable, itemized, e.g., i18n, Help
• Pass/Fail criteria
• Test suspension and resumption criteria, as applicable
• Test deliverables, itemized, to be delivered after test completion, including
o test configuration, including product/item version(s) tested and OSs as applicable
o date(s) testing performed
o testing steps to be executed
o anomalies found, to include their ID # and disposition (e.g., open, closed), and test step(s) where found
o testers: printed names and signatures for all
o test notes, as applicable, to record, e.g., test steps executed by tester A and those by tester B
o test results
o TPRs, as applicable
8.3 TPR, Test protocol
TPRs, test protocols, may be used to document all or some test deliverables from the plan. When used, like the plan, the TPR is to be approved prior to formal test execution.
I do not want to have ‘shall’ all over the place.
About your last point, without seeing the SOP and based on a limited description in the OP, one might draw that conclusion. But I believe that is not the case with this SOP.
Passive voice can cause problems. It’s better to identify who is required to act.
I second the other advice above. Must should be pretty clear. It has a clear meaning in my line of work. Use may for permitted but not required, and must for required.
Just wanted to mention that I’m having a good time switching “modified” and “qualified” back and forth in my mind:
“unless modified by qualifiers…”
“unless qualified by modifiers…”
OP, you seemed concerned about using the same word over and over, but that’s exactly what you should do in this sort of document. It’s not meant to be riveting prose, it’s meant to make expectations, procedures, etc. very clear. Using different words to mean the same thing can be confusing – some people will think you intended something different by using a different word.
ETA: My work involves understanding what laws mean, which involves paying attention to how they are worded, including things like whether mandatory or permissive, and whether words are the same or different from other similar or related laws.
It’s not as clean-cut as that. The mays fall into a few sections, while most of the SOP consists of requirements. The mays are scattered and not easily grouped.
Will is more of a command, yes. While about 95% of the SOP is requirements and 5% is optional, I don’t want to put “will” or “shall” or “must” into almost every statement.
I’ve seen SOPs where some statements include “shall”. But does that then mean the rest of the SOP, even though they are requirements, aren’t really required? Of course not.
Does “shall” mean you really REALLY have to do this? In a way, yes, including shall (or equivalent) puts emphasis on the requirement.
Converseley, when “shall” is not included does that mean the statement is not a requirement? Clearly, no, that is not the case.
I like it. I’m using the first one. It is clean and succinct. I removed the comma, however. Thank you!
Funny, but true and a good point. So I changed it to this,
All provisions of this SOP are requirements unless qualified by, e.g., “may".
Thanks again! Again, thanks!
I’ve seen a few SOPs like that too. I like that practice much better than the usual SOPs I’ve seen.
Exactly, yes that is true. I don’t want to use shall over and over.
Perhaps I should but I’m choosing not to. The backstory is that my first introduction to quality systems (for FDA-regulated medical devices) was by a former lawyer. The SOPs he wrote were verbose, and to an engineer like me I thought unnecessarily so. I used to jokingly say about his SOPs (and I really like and respect the guy) by saying, “Why use 7 words when 27 will do?”
But he was the boss and I toed the line. No problem at all. And I learned a lot from him.
But I am an engineer and not a lawyer. Maybe the law requires many words to flesh out the nuances and subtleties different scenarios may present. But I’m writing for engineers, and we just want to do our work. Make it clear and straightforward. Minimal yet sufficient. And compliant.
Okay, I’m now getting verbose!
This has been a very productive conversation. Again, thank you all.
It doesn’t have to be more verbose. And using active voice/naming the actor places responsibility and makes sentences more straightforward. If I could provide only one piece of feedback it would be to clearly identify who is required to act in each of your sentences (or who may act, etc.). E.g., for these examples, my edited suggestion is below:
Here’s how I would recommend doing it. I’m guessing/making place holders for the people involved. Knowing who is mandated to act is really important.
The engineer in charge of testing (EIC) must create a test plan before testing. The EIC must obtain approval of the plan from the department head (DH) before formal test execution. The plan must include, but is not limited to, the following components
8.3
The EIC may use TPRs, test protocols, to document all or some test deliverables from the plan. When the EIC uses TPRs, they must be approved by the DH before formal test execution, as with a plan.
Those may not capture what the original is saying, but I hope you can see what I mean.
Who is responsible for creating the plan?
Who has to get it approved, and whose approval do they need? Etc.
“Will” is not necessarily a commandment; it can be a promise, prediction or statement of intent — “I will go to Paris on Thursday; Michel will meet me at the airport and take me to my hotel, where I will get an early night”.
Whether “shall” or “will” is more like to be understood as an imperative depends on which variant of English the reader uses, which is why in a diverse organisation both words should be avoided. “Must” is the least ambiguous imperative; if you feel it reads too harshly in a particular context then consider “is to”- “You must get your plan approved by your manager before proceeding” or “You are to get your plan approved by your manager before proceeding”. Either of these is better than “You will/shall get your plan approved by your manager before proceeding”.
As others have said, avoid the passive voice. If you are imposing an obligation, be explicit about whose obligation it is. Same goes for granting a permission.
Also, avoid a structure like this:
“The plan is to be approved prior to formal test execution and includes but is not limited to the following…”
The first statement is a command; the plan is to be approved (but because it’s in the passive voice we don’t know who is responsible for getting it approved, Plus, we don’t know who can approve it, though that may be stated elsewhere in the SOP).
But the second statement looks like a simple statement of fact; the plan includes X. It isn’t even a shall/will statement. And that looks like a deliberate contrast from the first statement, which is an imperative, so the reader is given the impression that you are deliberately not expressing the second statement as an imperative. People may read it as an aspiration or an exhortation or an encouragement. If you mean it to be an imperative, then state it that way; “the plan must include, but need not be limited to, the following…“
Ultimately, you need to do whatever works, and some of that will be very specific to the audience, their dialect, the existing corporate culture, the intended force of the policy etc.
Although it is repetitive, IMO, it’s best to put ‘must’ into each and every statement where it applies - YMMV, but I think there is something about the proximity of the word that underlines the absolutely mandatory nature of each statement, and there is something about the rhythm of the repetition that hammers the message home as a set of commands, not suggestions.
People have a tendency to treat rules as guidelines and comply as minimally as they feel they can - IMO, in addition to the facts of what the document states, the feeling of the audience needs to be managed by repeated stress on the importance of the instructions.
