Need a book? Engineering books recommendations...

Return to index: [Subject] [Thread] [Date] [Author]


[Subject Prev][Subject Next][Thread Prev][Thread Next]
David Merrick,

Optimum group size is an odd number and typically around 5 or 7, but groups
of 11 have also proven acceptable. Depends on task.

Bay of pigs also highlighted problem of group think. No point in a group if
no one actually expresses personal viewpoint. The group sort off end up with
an opinion independent of the members, a false consensus is assumed and no
one wants to be the odd one out. The group can end up with a view contrary
to all the individual members.

It as also been determined that 100% inspection is no better than
statistical sampling, variability in human behaviour is the primary cause.

Industrial pyschology and human behaviour are important factors in designing
effective processes. And QA and TQM are some what concerned with an
iterative cycle of engineering the engineering process itself. Unfortunately
most QA/TQM systems implemented by most consulting engineers, are simply
their original contract document management systems. More focused on which
revised document is current, than the fact they shouldn't have had to revise
document in the first place.

I think consultants are part of the problem. It magnifies the problem known
in manufacturing as over-the-wall-design. It is easy to automate
documentation, and submissions for approval, but misses what the point of
engineering is about in first place. I consider the emergence QA and TQM, to
be illustrative off: well what did you think engineering was about in first
place? If was being done properly, then QA/TQM would not have been born.

But regulations have focused engineering effort on the performance of the
end-product, to the detriment of the constructability. I get a fair few
people turn up, that declare council to be a bunch of idiots for approving
things that cannot be built. But council doesn't care if can build the
proposal, only if it should be permitted. It is the building proponents
responsibility to figure out how to build it: if they only employed someone
to get it through council then thats their problem.

So the regulatory system hasn't actually imposed design, only documentation
and reference to appropriate clauses in standards. The builders don't pay
attention to the clauses, they do what they always do. So its all a paper
shuffling exercise. End up with carpenters sat on roof tops scratching
heads, going I can't build this. Which is too late, problems were supposed
to be sorted out in the design office.

There is emergent behaviour in the system, so most engineers only concerned
with supplying what the client requests: calcs-for-council. Most of the time
its ok, and the builder figures everything out on site. Occasionally however
it all falls in a heap. Largely because everything is taken for granted.

Part of the problem is that the original engineers and builders were one and
the same person. Now there is a massive division of labour, between job
functions, businesses and organisations. So there is little engineering
going into the building process, and little engineering going into the
entire system of supply itself. 

BIM and computers do pose a problem. But the focus has been on hand
calculations, I don't believe that is the issue. Mindlessly plugging numbers
into formula and calculating point-values project after project is
relatively useless exercise, and such persons readily replaced by computers.
So human computers can be replaced by electronic computers, the problem is
having confused the human computers to have been engineers.

I don't believe we study mathematics to evaluate expressions, I believe it
is so that we understand the relationship between the characteritics of a
system as expressed by a mathematical formula. It is this that advises us
what parameter to change and in what direction to achieve our objectives:
and where sensitivity lies. So computer can do the code checking
consistently but when it rejects: what has to be changed?

Design is an iterative process, and having resolved one issue in one cycle,
may mess up something else. So final assessment and approval needs to be
separate from the design process: by someone who was not involved in the
design. Psychologically people are preconditioned to see what they want to
see rather than what is actually there, so should never check own work:
unless put aside for fairly significant period of time.

So yes the whole: design, assessment and approval process needs to be
designed, taking human behaviour and human error into consideration. Problem
is a segmented industry, lots of small businesses only contributing a small
part to the whole. The majority of which only care if the code changes what
they do: for most buildings, code changes don't bring about any changes for
the builders. It only affects designers, the piece of steel you were
confident worked last week, now has to be reassessed to determine if still
compliant. Causing delays, though builder may just rush off and build
anyway, meaning have no choice but to prove still compliant.

Systems in place but cannot really be certain about the output. Hence
quality robust design to deal with variability no matter where it turns up.
And ... its deliberatly a cycle, hopefully with diminishing error and not
increasing documentation.


******* ****** ******* ******** ******* ******* ******* ***
*   Read list FAQ at:
*   This email was sent to you via Structural Engineers 
*   Association of Southern California (SEAOSC) server. To 
*   subscribe (no fee) or UnSubscribe, please go to:
*   Questions to seaint-ad(--nospam--at) Remember, any email you 
*   send to the list is public domain and may be re-posted 
*   without your permission. Make sure you visit our web 
*   site at: 
******* ****** ****** ****** ******* ****** ****** ********