Thursday, 26 December 2013

Teaching and Training Engineers: Problems and Tasks

Qatari engineers work in a group to solve practical engineering problem
I was in the Middle and Far East until Monday, training practising engineers as well as academics from the University's China and Malaysia Campuses. The picture above is of a particularly good group of course attendees in Qatar.

Most of my teaching and training features a lot of groupwork, and I have quite a number of exercises which replicate the real-life problems I have encountered in designing, commissioning, and troubleshooting plants. I have given these exercises to maybe five hundred undergraduates, postgraduates, researchers, academics, and professional engineers from many countries, and I can't help but notice a pattern in competence.

The group in the picture were very experienced ex-pat operational staff with an oil and gas background. They required no assistance from me to solve a problem which has reliably completely baffled many academics.

The pattern of competence I notice is as follows: Highly experienced practical professional engineers>Top-flight academics>Less experienced professional engineers = My best under- and post- graduate students>Run-of-the-mill academics>Engineering management>Less-able under- and post- graduate students.

Many of the most able groups of all are in my experience those like the one in the picture, made up of the ex-pats who run a lot of the plants in Gulf states. Local conditions mean that they tend not to stop working as engineers, and become hands-off managers. Similar extreme competence can be seen in the UK with many of the free-lancers often known as contractors. Selection by drop-out and decades of immersion in a pressured, practical problem-solving group environment seems to produce the required competence.

Top-flight academics (usually full professors) often do pretty well on these exercises too. Management roles in an academic setting also involve knotty problem solving, as I know from my own experience, and people do not make professor without a certain amount of smarts.

So why does "problem based learning" have such a poor track-record in academia? There are a number of reasons, but I am coming to the conclusion that much of it is to do with a misunderstanding of the nature of a "problem".

Pahl and Beitz helped me out with this, by differentiating in "A Systematic Approach" between a task and a problem. When there is a well-established methodology which produces unambiguous guidance on how to choose between design options, following such an approach is not problem-solving activity, but is merely a task.You gather the data, enter it into your computer program or design methodology, and a reasonably straightforward answer is produced - this is monkey-work, not engineering.

Much of what is done in academic engineering courses focusses on such scenarios. Sinnott and other textbooks provide turn-the-handle methods to "design" various unit operations. So-called "design projects" consist in many institutions world-wide of getting students to knit together a group of tasks of this nature,  operating a simulation program like Hysys, or grinding through pinch analyses.

In order to turn the vague messiness of real engineering problems into a collection of unambiguous tasks, a great deal of data is given, the problem is very tightly framed, and in a "successful" example, (judged by student satisfaction) it is very clear to students that they are faced with carrying out a number of the tasks which they were previously trained in. Though these are very often supposedly group exercises, they are so structured that students can readily split them into a number of standalone tasks.

When you examine students who have carried out such exercises, it becomes clear that none but the very best of them have any understanding of the overall picture - the majority are just grinding through the textbook method, or operating the program. Neither do they have any appreciation of the complexity of the sub-structures of a process plant. The method has produced neither system-level vision, nor a grasp of detailed considerations.

My exercises are very different, as all are based in examples from my professional practice. The students or trainees are given quite complex materials, the same ones I had when I had to solve the problem. They are not an academician's attempt to obfuscate a reasonably clear instruction to follow a number of standard methods.

There are no clues in the question, so they have first to figure out for themselves what the problem is. When they do, they will find that the solution requires both system level thinking, and a detailed grasp of the sub-units which the plant is constructed from. Even understanding the answers well enough to put them to some practical use is intellectually challenging.

Standard methods are of no use when there is insufficient data to apply them. There may well be some "tasks", such as checking the sizes of unit operations using heuristics, but these are mathematically trivial, and the product may be ambiguous. There is no opportunity to start thinking that engineering is a branch of applied maths, or that a computer can solve engineering problems - computers only carry out tasks. Common sense is what is needed, and a feeling for ambiguity, qualitative knowledge, multi-dimensional evaluation of options - professional judgement.

I can create more of this elusive quality in the best students than the average practising academic or manager has in a single semester of exposure to real problem-solving. I can create enough of it in anyone attending my courses that they will have a new understanding of what engineering is about.

I also note that professors, ex-pats in a very competitive market and the very best students in a top university have something in common. They are a selection within a selection - they have been selected not just for cleverness, but for personal qualities such as persistence, resourcefulness, and a willingness to work hard. They also tend to have the greatest ability to generalise from specifics - Oil and Gas sector staff who can troubleshoot a previously unseen effluent treatment plant, or students who can apply an overall design methodology to a wide range of different types of plant.

If universities were just about sifting these more able students from lesser ones, it may well be that almost any other intellectual challenge would produce the same winners. Alternatively, it might be that different aptitudes are being tested when we move away from thinking that engineering is applied maths, and start asking students to think by drawing, work with qualitative / verbal knowledge, and start to display intuition.

Either way, it is my opinion that the best way to teach engineering is to ask people to engineer something at full-scale with as much realism as possible.

No comments: