Drone Operations Manuals – Tips and Tricks
Eyeup Aerial Solutions Ltd
Operations Manual
Version 1.0 Dated 31/08/2021
Amendment Record
1. Introduction
This manual, “Drone Operations Manual – Tips and Tricks”, provides the basis for an article in Drone User Magazine’s September 2021 issue. It provides a methodology by which professional drone users may choose to structure and control their Operations Manual (OM). It does this by explaining some of the basic principles of technical writing and document control.
The following areas will be covered:
- Document versioning.
- Where to insert basic manual information such as date and version number.
- How to use the “Abbreviations and Definitions” section.
- Use (and overuse) of your company name.
- Must, should, may.
- Use of images.
- Easy mistakes.
You will note that the language in this article may be a little more formal than usual. You may even find the wording repetitive in places. This can go against the grain for anybody not used to it. In your English language lessons, you will have been encouraged not to repeat words in sentences, to make them more interesting. However, writing an OM is about producing a set of clear instructions, sometimes using strictly defined terms. It would be no good carefully defining Observer, then referring to this role as a Spotter because you were getting bored with seeing the word Observer in the document. If a word is the correct word, then you should use it consistently.
2. Document Versioning
I see documents with version numbers made up of one, two or even three sections (i.e. they may be numbered 1, 1.0, 1.0.0). Whichever version you use needs to make sense to you. If you already have a small business with controlled documents, then naturally your numbering should follow your in-house convention – no matter what the template provided by your training organisation contains. As far as I’m aware, the CAA doesn’t care how you version a document as long as they can reference a unique document in their records and confirm that you are working to a known version should they ever audit you.
But what do the numbers mean? That is your decision entirely but here’s an approach that might work for you. Your manual should be updated on a regular basis to take into account minor changes. These are considered minor in nature and may include the addition of a remote pilot or airframe, changes forced upon you by legislation or even typographical corrections . You may then carry out a major, annual review where you tweak parts of your operating methodology (providing you stay within the bounds of you Operational Authorisation [OA]) and issue the document to the CAA for renewal of your OA.
I use a 2-digit numbering scheme, using the first (or cardinal) number to denote major changes such as an annual review and the second (or decimal) to denote minor changes. Make sure that when you shift up a major version that you “zero” the decimal number. This way you can easily keep track of changes against that particular major version. Using this scheme your versions may run over time as 1.0; 1.1; 1.2; 2.0; 2.1 etc.
3. Where to Stick It
You now have a document with a nice header page and version number with a date. This information appears in the first three lines of this article. But what do you do with the version number?
It will appear in the amendments table naturally, but also on the front page of your manual. Many templates also include the version number, date or both in the document headers or footers so they appear on every page. In some document control environments this is important, but I would suggest that for most small operators it is overkill. The problem becomes one of ongoing maintenance. When you update your document set you need to catch every example of the version and date. There is nothing wrong with stripping out all but the necessary appearances of these details.
In my documents the version and date appear on the front page and amendments table, nowhere else. However, when I print the document I always print all pages so I know the versioning is correct on the hard copy.
Keep it simple.
4. Abbreviations and Definitions
Once again, I see both extremes of the Abbreviations and Definitions section. I’m afraid our regulator hasn’t done anybody any favours here as they seem to have taken different view on this at different times. I know training organisations that encourage the whole list of abbreviations in CAP722A (which contains the official OM template) to be included in a manual, whether they are used or not. The CAA will generally allow this on a PDRA01 application (at least that’s what is suggested by the number I see), but they have also been known to reject an OSC application containing a similar list.
It also doesn’t help that while including a list of abbreviations in CAP722A, the CAA has also issued a separate document, CAP722D, devoted to just abbreviations and definitions…and the lists are different! It makes you head hurt and a little consistency wouldn’t go amiss.
What do I do? It’s a pain in the short term but worth doing to avoid confusion. Make sure that the only abbreviations your manual lists are ones which actually appear within the manual itself. This is easy to do. Just carry out a [Find} command on the abbreviation. If it is only counted as appearing once then that is the one in the abbreviation table and it can be removed.
On the other hand, you should ensure that if you are constantly repeating a word and want to abbreviate it, then you must add that new abbreviation to the table.
Finally, if you have gone to the trouble of having an abbreviation (such as RP for Remote Pilot), then don’t use the full version of Remote Pilot in the document…otherwise you may have saved your time and not bothered with the abbreviation. Keep it consistent. The one deviation from this rule is where the term is used in a title. For example in Roles and responsibilities I would probably retain the full “Role of the Remote Pilot”, rather than “Role of the RP”, both for clarity and emphasis and to ensure a new pilot reading the manual doesn’t miss these key points.
Once you have an abbreviation or defined term then make sure you stick with it throughout your document. A common example has again been caused by the constant changes over time of the regulator on how they expect us to refer to the tools of our trade. You should know which are the two preferred abbreviations for our drones out of these recent examples; UAS, SUAS, RPAS, UAS, SUSA, UAV, UA. If not, check in CAP722D and use them.
5. Company Name
Isn’t it great to see your company name in print? It still give me a kick to see Eyeup Aerial Solutions Ltd! However, there is a time and a place for everything and you can have too much of a good thing.
I have worked on manuals for companies with some pretty long names, some of them taking up almost a whole line of text when written in full. The company has completed a badly constructed (in my opinion), autofill template which has inserted the full company name throughout the document. Far better to define a term, either “Company” or “Organisation” in the definitions and abbreviations table. Provide full contact details when you do this so there is no doubt what the term “Company” or “Organisation” means. Thereafter you can just use Company or Organisation (always capitalized) throughout.
But why? Think what the manual is for. It is designed for you, the CAA or another pilot to pick up and read and thoroughly understand your operations. Reading past the word Company or Organisation is easy. However, you will find that reading past a long company name is awkward, time consuming and will reduce the ability to understand the key points of the document.
Remember, the OM is about getting important information across, it isn’t part of your marketing.
6. Must, Should, May
When you are reviewing your manual you should be very careful to avoid painting yourself into a corner. Language is very important here and the CAA provides clear definitions of the three words in the title of this section, must, should and may.
- ‘Must’ or ‘must not’ indicates a mandatory requirement.
- ‘Should’ indicates a strong obligation (i.e. a person would need to provide clear justification for not complying with the obligation).
- ‘May’ indicates discretion.
There are some things you won’t get away with saying. You MUST undertake to comply with the requirements of the Air Navigation Order and UAS Implementing Regulations for instance. You SHOULD avoid hovering over uninvolved persons for long periods and you MAY place cones around your take off area in a rural location.
Use “should” with discretion here and get the balance right.
7. A Picture Paints a Thousand Words
Well done if you’ve got this far. You’ve clearly got a better level of sustained concentration that the average social media user. Reams of text have their place and words are incredibly useful for describing thinks. That’s sort of what they do.
However, if you can more easily describe a procedure or set of information with a chart, graph, diagram or picture then don’t be afraid to do it. Use your imagination. I’ve even created links to YouTube videos into a Safety Assessment document and let the CAA watch my antics!
Diagrams are great to show how you may use spotters in a range of scenarios. The layout for a typical take off and landing area can be provided as photos. As long as you are getting the key information across and the CAA and other reader will understand then it’s all good. I’m even considering creating an OM in flowchart form at some point…though this may blow a few minds in the CAA assessment department.
8. Easy Mistakes
Some of you may have already spotted a couple of errors in this article. There are no doubt a tonne of grammatical errors since I was never taught grammar at school (true story…they were different times). I’m pretty sure that errors can’t be measured in units of mass either!
However, there are a couple of critical errors that the CAA will reject a manual for. These are date and version inconsistencies. You will see that the opening three lines of the article show different dates. The latest version in the amendment table is 1.1 while the header shows 1.0. Such rejection isn’t to punish the operator for a minor typographical error or forgetfulness, it is because the CAA needs to know the version of the manual you are working to, because in the event of an incident all eyes will be on whether you were following a known and logged set of procedures.
Other Resources.
Updating your own ops manual can be a real pain can’t it? It can also be very rewarding and a very good way to stop you “drifting” away from good practise. You can get more information on updating your manual here.
