checklist ambiguity
Thread Starter
Join Date: Aug 2001
Location: A few miles from the airport
Posts: 219
Likes: 0
Received 0 Likes
on
0 Posts
checklist ambiguity
According to ICAO doc 8168 Vol 1 SOPs chapter 2;
"Checklist responses should portray the actual status or the value of the item (switches, levers, lights, quantities, etc). Checklists should avoid non-specific responses such as "SET", "CHECKED" or "COMPLETED". "
I find myself responding SET, CHECKED or COMPLETED in 80% of the items on most checklists. In fact I have yet to see a checklist where Set, checked or completed is nonexistent.
Is this a design error or do I misinterpret the lovely doc 8168.
"Checklist responses should portray the actual status or the value of the item (switches, levers, lights, quantities, etc). Checklists should avoid non-specific responses such as "SET", "CHECKED" or "COMPLETED". "
I find myself responding SET, CHECKED or COMPLETED in 80% of the items on most checklists. In fact I have yet to see a checklist where Set, checked or completed is nonexistent.
Is this a design error or do I misinterpret the lovely doc 8168.
Moderator
The airlines with which I have had involvement have had policies requiring the response to be appropriate where the printed word(s) is(are) generic.
While there may be other considerations, could I suggest that the checklist generic response provides
(a) for more than one response being appropriate according to the particular system or circumstance ? So "XYZ ... set" might better be responded to as "on" or "off", for example, but the checklist would be made needlessly complex if all options were to be itemised - it's bad enough having to wade through the emergency and abnormals as it is in some cases ....
(b) a simple acknowledgement may be preferable where a response identifying a greater level of complexity would be superfluous in the circumstances ? So "C/B ... checked" might be better than "I've looked all over the panels and all the C/B that should be in, are in, and all the C/B that should be out, are out, captain" ?
However you develop a certification or operator checklist, there will always be several ways to skin the cat (how many different airlines have quite different checklists for the same aircraft ?) and, at the end of the day, some of the aims are to achieve
(a) (workload and cognitive) simplicity
(b) crew action/response reliability and repeatability
(c) consistency across different fleets for operators which have a strong requirement for standardisation. This may make a particular aircraft a bit more complicated to operate but simplifies transition training and company SOPs greatly. I can recall quite clearly in my early airline experience
(a) going from a limited GA background to a very simple turboprop (during which I was terribly confused and overloaded)
(b) and then transitioning to a much more complex turboprop (I didn't necessarily know what was going on but I certainly expected various actions and so on at different stages of flight)
(c) transitioning to my first jet was then a bit of a doodle ....
The KISS principle is a great way to start any technical writing ..
.. and, no matter how it is done, you will never please all the people all of the time ...
While there may be other considerations, could I suggest that the checklist generic response provides
(a) for more than one response being appropriate according to the particular system or circumstance ? So "XYZ ... set" might better be responded to as "on" or "off", for example, but the checklist would be made needlessly complex if all options were to be itemised - it's bad enough having to wade through the emergency and abnormals as it is in some cases ....
(b) a simple acknowledgement may be preferable where a response identifying a greater level of complexity would be superfluous in the circumstances ? So "C/B ... checked" might be better than "I've looked all over the panels and all the C/B that should be in, are in, and all the C/B that should be out, are out, captain" ?
However you develop a certification or operator checklist, there will always be several ways to skin the cat (how many different airlines have quite different checklists for the same aircraft ?) and, at the end of the day, some of the aims are to achieve
(a) (workload and cognitive) simplicity
(b) crew action/response reliability and repeatability
(c) consistency across different fleets for operators which have a strong requirement for standardisation. This may make a particular aircraft a bit more complicated to operate but simplifies transition training and company SOPs greatly. I can recall quite clearly in my early airline experience
(a) going from a limited GA background to a very simple turboprop (during which I was terribly confused and overloaded)
(b) and then transitioning to a much more complex turboprop (I didn't necessarily know what was going on but I certainly expected various actions and so on at different stages of flight)
(c) transitioning to my first jet was then a bit of a doodle ....
The KISS principle is a great way to start any technical writing ..
.. and, no matter how it is done, you will never please all the people all of the time ...
Last edited by john_tullamarine; 18th Mar 2004 at 01:01.
