Dennis, congratulations (and commiserations) on working on a much needed but challenging task.
Please note that because negative critique is easier, this should not detract from the overwhelming positive aspects of the draft.
Also note that it is impossible to satisfy everyone, just as it is impossible to provide an SOP for all situations. This is an essential point in providing guidance for developing an SOP, thus should be stated early in the document.
Comments:
Title ? – Guidance for developing, implementing, and updating of Standard Operating Procedures (SOP)
Ch 1.1
Mental model,
“This shared model, in its turn, is based on SOPs”. I would strongly disagree; it is most importance to first understand the situation, then relate a course of action to a SOP, and continually revise the situational understanding and thus relevance / progress of the SOP. i.e. do not use an SOP to create understanding.
Refs for “non compliance” /SOPs
http://ntrs.nasa.gov/archive/nasa/ca...2002103814.pdf
https://www.scribd.com/doc/242656679...he-Flight-Deck
Assessing Procedures (OGHFA BN) - SKYbrary Aviation Safety (and links)
https://www.scribd.com/doc/37230102/...pliance-PAT-v2
SOPs - SKYbrary Aviation Safety
Beware the root source of any references; e.g. FSF might not be completely independent, FAA follow FSF, both of which may have Boeing influences; c.f. “Dominant Cultures”.
Ch 2.1
“Crew resource management (CRM) is not effective without adherence to SOPs.” Debatable; CRM might enable the key activity in situations where there are no SOPs.
Beware overreliance on monitoring / crosschecking, these are good defences but often fail during high workload periods when they are most required.
Aeroplane State Awareness during Go Around
“..make possible for each crewmember to”, instead of
‘always know what s/he is going to do’, use what s/he should be going to do … thus this becomes a basis for error checking and coordination; don’t pre-empt someone else’s thoughts and actions.
--------
The goal should be to provide a generic guide to SOPs, but this could be difficult without using specific examples, which should be chosen carefully by considering the point being made, and thus where to positon the example in the text.
Thus Ch4, Stabilised Approach could be misplaced and ‘irrelevant’ (debatable); also it might not be a good example because of the variable scenarios, impracticability, conflict with other safety initiatives (e.g. deceleration required to achieve TCH speed) – discussed in the presentation text.
When using an example, is it to be based on scenario, process, or limit.
4.3 Expansion can add complexity; try to use ‘if – then’ processes, avoiding ‘except’, ‘or’, … e.g. RTO; if engine (system) fail and speed (+- V1) then stop / go; (but which comes first ‘fail’ or ‘speed’?). Minimise judgemental processes by defining what an engine (system) failure is, i.e. two gauge indications, or a gauge / lamp / system indication – remove subjective assessment, e.g a ‘bang’.
What is the primary purpose of a ‘call out’? Is it to direct attention to an urgent issue or just to provide information? It’s often better to include the action required rather than just the ‘error’.
You have taken on a challenging task; the current draft falls between specific procedures and generic operations manual. There are many examples of how operations manuals are written; the difficulty is in identifying the good ones.
IIRC Airbus used to publish an example Ops Manual and SOPs.
Also reconsider what has been or will be written; is this against a background of the human as a hazard or as a valuable resource in need of guidance?