Wednesday, 3 April 2013

Design Philosophies

I was discussing academic design philosophies with a colleague from the Malaysia campus last night. Apparently, academics interested in the area have proposed a number of different new approaches to process design. Such experimental philosophies are popular in academic circles, and also in a certain type of consultancy (more akin to a management consultancy than an engineering consultancy) engaged only at the most loose-weave conceptual phase of design.These philosophies are(my colleague agreed) more proposals for how process design "should" be done than a reflection of how it is done - they are normative, rather than descriptive as they say in the humanities.

But I talk to practical process design engineers all over the world, and how it is done varies surprisingly little- why is this? I think it is for the same reason as all animals which live in similar ecological niches look somewhat similar-convergent evolution. I was not taught a design methodology/philosophy - I evolved one.

My initial experience was in a university spinout, where I saw the pitfalls of attempts to base process design on research output and the first principles academic engineering I learned in university first hand.

Next I went to work for process contractors, where I spent five years producing proposals for competitively bid design and build contracts. At first I was too cautious, and won nothing,then I swung a little too far the other way, and nearly won a contract or two I was lucky not to bring in.Eventually I learned how to win tenders consistently through competitive design. I learned where I needed to place my attention and effort to get a working design for the right price.

Then I went to work for consultants and operating companies, and learned the mistakes they make in specifying plant, and their lack of knowledge of what works and what does not in design. I knew from previous experience that contractors do not like to embarrass clients by pointing out that their designs are not going to work, they just quietly adjust the design so that it will work and keep it to themselves. Operating companies on the other hand have a lot of information about how well designs work in practice which contractors do not have. There are longer term implications of design choices which are unknown to designers in contracting companies.

I then gained a fair bit of installation and commissioning experience, and found another layer of design requirements, and after that I did a lot of process troubleshooting, de-bottlenecking, and resource efficiency studies across a wide range of industries. I could now see the big picture - all of the mistakes process designers make again and again, often because of a narrowness of experience and vision.

Most people who work for consultancies have no real experience of process design, and they receive little genuine feedback on the effect of the choices they make in conceptual designs. They are not in a position to learn from their mistakes-they cannot evolve into process designers.

Proposals engineers in contracting companies only care about winning the work. It is a stressful job, which few do long-term. They may learn how to win, as I did, but their designs are frequently sub-optimal, due to their frequent lack of experience, pressured working environment, and the over-emphasis on cost reductions.

The build team may fix some of their errors, but may well not feed back to them how to do it right next time. Proposals engineers can evolve into competitive designers, and indeed must if they are to survive. They have to start winning quite quickly if they want to keep their jobs.

Only after seeing the errors and elegance of the hundreds of  designs by others I have now been employed to fix, and provided long-term process support for plants I have designed do I think I really understand process design. Robustness, Safety and Cost should be the process designer's watchwords.

The common methodologies of the world's process designers are fitted to their environments. Operating companies, contractors and consultants each see different parts of the puzzle, and have different possibilities for feedback. Communication between them is poor for a number of reasons. Information from all three sources must be combined to truly understand process design, but if one must be chosen, contracting organisations are where the maximum information of how to design plants which work is concentrated.

Essentially none of this knowledge is available to academia. Operating companies and contracting companies have their design and operating manuals, but these are jealously guarded secrets. The consultants which academia engages with know nothing useful about how to design plants which work.If they need to know the financial or practical implications of something they are thinking of doing, they call a contractor and ask a favour.The contractor doesn't tell them how they worked it out.

So academic design practice drifts ever further from professional design practice. Expensive mathematical modelling at the conceptual stage, using software with cheap academic licences which is prohibitively expensive and unfit for purpose on a commercial basis, designs based on first principles or primary scientific research, groundless theorising, the list is endless.

Philosophy is about what might be true, so a design philosophy is about what might work, but no-one is going to give you £100M to build a plant which might work.

There is nothing wrong in an academic setting with telling students about your vision for alternative futures, but when I did my teaching qualification, I had repeatedly to stop lecturers and ask if they were telling me about how things were, or how they ought to be. In the humanities department, they seemed to have little interest in how things were. In fact they repeatedly told me that there was no such thing as how things are. All very clever in its way, but there is no postmodern school of engineering.

In engineering, practitioners and academics agree that there is a difference between "is" and "ought". We need the descriptive far more than the normative.We need to teach our students how design IS done.

No comments: