Serial, concurrent, parallel

I am surprised (disturbed?) at the problems people seem to have
sorting these things out in their thought processes.  I don't
*believe* people think strictly "serially" but I am beginning to
question that belief as I witness smart/capable people stuck in
that mindset!
I've been finding problems with their implementations that
would not be present if they TRULY "thought in parallel".  Things
that should be obvious seem to slip right past them.  This came
to a head when I asked a colleague to explain multitasking:
   "Well, FIRST, the processor does... and THEN..."
   "Ah, 'THEN'!  So, you are thinking about multitasking as the
   SERIALIZATION of multiple tasks instead of the CONCURRENT
   execution of them!  So, when your code is run in true parallel
   form (multiple cores, multiple processors), all of those hidden
   assumptions that you've baked into your design fall apart because
   they are no longer implicitly serialized!
   "THIS is what your algorithm does (see Petri net X) and this is what
   you THINK it does (see Petri net Y).  See the differences?  The
   *hardware* does!  And THIS is where the bug manifests..."
I tackled the problem with folks failing to understand how an IPC/RPC/RMI
can fail *in* the (apparent) function invocation -- by sugarizing the
syntax to make RMI's more obvious.  One source of problems (largely) gone.
But, there still seems to be a problem wrapping people's heads around
the fact that something is truly executing in parallel -- and, likely
on some other processor (with all that entails).
I.e., unlike a multicore/SMP implementation where the other processor
is there, beside you (so, "available" as much as 'YOUR' processor is),
an RMI can actually get started and then fail "later" (e.g., if the
remote node is powered down, disconnected, etc.).  So, you can't
rely on the fact that the invocation succeeded to be indicative of the
actual method running to completion.  This is particularly important
for asynchronous actions where your thread doesn't virtually migrate
to the remote node but, effectively, forks, expecting a later join.
TL;DR.  I need a mental model that is easy for folks to consult to
"remind/reinforce" this true parallelism.  I'm hoping to discuss it at
an upcoming off-site where they can feed off each other's understanding
of it.
Perhaps "inspired" by the travel issue, I'm thinking along the lines
of "taking a trip" and the steps involved:
     Contact airline to arrange travel
         Airline (phone/www) may not be available at that time.  Or,
             you may lose the connection (voice/data) during the
             transaction.  How to recover:  Spin?  Reschedule?  Spawn
             a separate task to handle that contact (i.e., ask your
             secretary to do it WHILE you do something else)
     Book hotel
         No vacancies.  Find another?
     Pack clothing/supplies
         Some items may need to be washed/purchased.  Spin?  Reschedule?
         Spawn a task to handle those dependencies (i.e., have spouse
         run out and pick up those few items needed)
     Go to airport
         Family car?  Taxi?  Uber?
     Check luggage
     Board flight
     Fly
     Arrive destination
     Deplane
     Collect luggage
     ...
I.e., some of these things are truly serial (can't "fly" until after
you have boarded the flight).  Others can be handled concurrently.
And, some are truly parallel.  Order is flexible WITHIN a set of
dependency constraints (e.g., you can easily imagine packing BEFORE
having your travel reservations.  Or, while "on hold" with the
travel agent.)
NEEDLESSLY serializing them just means it will take you longer
(wall time) to get them done.  At the extreme, you may miss your
intended arrival time/date!
*But*, the more important issue that hides in these dependencies
is that they can abend and you (the traveler) will have to catch
those "exceptions" and handle them if you really want to ensure
your travel!
E.g., your secretary could tell you (after you'd "delegated" that
task) that there are no flights available on your desired travel
days.  YOU, then, have to decide on a new strategy/timetable.  Or,
the flight could get canceled AFTER you have a confirmed reservation.
Your luggage might not arrive WITH your flight.  The hotel might
have double-booked your room.  Etc.
So, WHILE you are proceeding on what you think is a successful
path to your goal, exceptions can be thrown ASYNCHRONOUSLY that
require your attention.  In some cases, you can ignore them until
they manifest as hard failures (i.e., you get to the airport and
THEN realize the flight was canceled and the SMS that you ignored
likely was a notification of this event!)
This is complex (in writing) but trivial -- and relatable -- in a
discussion.  I *think* it draws attention to the fact that things
are actually happening in parallel despite the fact that you might
WANT to think of this as a SERIES of steps towards a goal.
You certainly wouldn't describe it as "I called the airline AND THEN..."
because you would know that many things were (or could) be happening
at literally the same time.
Can anyone suggest a simpler "real world" problem to promote these
"situations/scenarios"?