Wednesday, April 30, 2008
Workshare and Calculations
I believe in workshare, it is sharing the opportunity to do useful work together, into the future. I have grown beyond the hand-me prognoses that says workshare don't work and they are to blame for all the problems meeting the deadlines. It is so wrong! I grew up in the negative culture that downgraded the abilities of others than themselves that could do the work properly. Communication is more than dialect, accents, the emails and cultural barrier. It starts with the calculations, at the grassroots level. If that works and is performed on time then what can go wrong? I found the Indians to be flexible, curious, adaptable and enthusiastic. That's more than I can say for my western colleagues! Culturally, in the west we are defensive by nature and losing this habit can be hard for some.
Workshare teams are sensitive to the needs of the parent project, they often work alone, they know once work is handed over; they are on their own until a problem is determined (and they are blamed for the delay.) As a younger engineer, I experienced not so successful arrangements. However, I have been on two significant projects with indian workshare, as a lead engineer, and they were great successes because we determined the basis, assumptions and reasons for the calculations. Workshare engineers found they were not just copying but keeping the designers, modellers and multidiscipline engineers in the loop before they actively started the analysis component of the calculations. We had no recycle of work. I trained them in small groups ( < 20) to produce the calculations and they learned well. They succeeded where the main project failed and the clients welcomed the workshare option as the path forward.
Based on my experience, I believe countries like India and South Korea has the potential to succeed where traditional western cultures are failing. Workshares are the future, but there is an art to the comunication and it starts with the purpose of the calculations. I think questioning the details of the calculations and assuming full responsibility is key to the engineer seeing the difference between mere copying and understanding their roles. Even in the absence of site experience there is a whole learning that can be put in place. Site experience is a benefit every engineer should seek.
I recognise the tradition of engineers acquiring site experience is becoming more and more rare with the ever increasing annual numbers coming into the profession but it means we need to commuicate more to solicit and educate the readers appreciation.
Workshares are the future, it is up to us, singly and collectively, to make it succeed. Once upon a time, I was surprised how quality-driven calculations worked well; now I see it as a fundemental necessity.
Question 5 for Structural Engineers
Tuesday, April 29, 2008
The Rise of the Modellers
These unwritten rules would look something like:
Get site experience;
Ask questions;
Take your time;
Understand the common sense design; and
Talk about the design with other disciplines.
These rules look simplistic but there is much wisdom and it embodies the lore of the age. Any time I look at a concrete drawing, Ed Eve would be there in my head, smoking a cigarette, shaking his head in a wreath of smoke, pointing out problems in his lancashire brogue. His acerbic wit, common sense and eye for details were a great learning curve for me. Watching a master perform his trade is exactly what the unwritten rules are all about. I smile now, but I still value his training and knowledge. I still apply the rigorous and critical review to engineering calculations that Ed Eve brought to his drawings and demanded of engineers. Now engineers working along side myself watch how I put my work together on paper and marvel similarly. Suddenly, I find myself teaching my craft and I do so with pride.
I worked on a refinery site in Denmark and it was the quiet craftsmen who patiently built the three-dimensional scale models of the refinery, in a clean room, knowing their days were numbered. The three men team worked solidly and patiently from drawings to create a scale model of the refinery. It was an amazing experience to walk around that model and see the design come to life while outside the site looked grim, flat and empty. That was the last time I saw anything like that model, in 1995. It is not a long time ago, yet it already seems another age has passed.
Monday, April 28, 2008
Question 2 for Structural Engineers
Sunday, April 27, 2008
Question 1 For Structural Engineers
Friday, April 25, 2008
Microsoft Office 2007 tangent?
Over the years I have watched (and admired) how Microsoft Office grew and integrated their diverse products. They have been competing (who with?) for vertical splits in the market by languages. Conquering country by country, waayyy! They got Japan finally, whoopee here's Finland, now Hindi...... Yet nobody really understands how to get the most from the products because we don't understand the programmers' philosophy. The MS business says you can do what you want, here are the books. Lots of them, read 'em, go on....The world is your oyster. How many times have you seen the ads showing people hitting the keyboard and colour-printed works of arts are spewing out, looking so easy and effortless. Ever happen to you? Didn't think so! It is sweaty, pressurised, stressful and endless recycling of work in search of fabled excellence.
There is a simple remedy for Microsoft. I think I know exactly how MS Word and Excel should be reconfigured for structural engineers. A dentist might feel differently. Whatever MS Office marketing gurus believe, an engineer is not going to want to read about payroll or market segmentation setups like Northwind. But it is a fact. Neither is an accountant going to use MathCAD with engineering examples and references to figure out their needs. If MS Office want to expand their share, they need to understand their market needs now and split it horizontally. We need profiling. MS programmers need to understand how I might use the product and they can tailor my defaults to suit. It is sad that engineers (and many people too) do not understand that the defaults can and should be tweaked like a cook adding spices to the recipes. But it is a fact. I spend most of my time pointing this out to engineers and it is alwways a revelation to many.
For some insane reason, Microsoft Office 2007 had to happen; it was probably boredom, or the sense of do 'something, anything but don't stand still' idiocy. Exactly what advantage did it bring to my work? I haven't figured that out yet. I know the next few years are going to lead to another generation of mediocre defaulting calculations because some guy decides that using the templates in 2007 are signs of being smart....... and all calcs should be in colour even though we don't use colour printers....all good but useless intentons.
Apparently, there are ways to design the ribbons, so I will look into that.
In the meantime I hope they are planning on keeping VBA macros......I heard rumours it might get bumped. I can finally get engineers excited and enthusiastic about VBA Macros and back into the game as programmers and masters of their destiny. But MS Office thinks it should disappear...killjoys... Just as we reached the fabled promised land at long last, they'll switch it off. Sick. What's the alternative? If VBA gets switched off, I might as well buy a MAC.
I've seen many friends, lifelong IBM PC users now swear by their MACs. I am tempted. Should I buy a MAC? Or give Bill one more chance?
Thursday, April 24, 2008
The Engineer's Path
Engineering calculations are a requirement for any structural engineering project looking to record the design assumptions and demonstrate the adequacy of the design. These documents are subjected to scrutiny and verification by third party before the design is approved.
Within the Oil and Gas industry of which I have been involved for over 20 years there has been a sea of change in the way we work, where we work and how we work. Everyone is familiar with the seismic changes in our environment; from the smoky, noisy halls of stand-up drawing boards to the silent cathedrals of cubicles and screen power. Major projects and companies now call upon designers to prepare budgets, schedules and manpower plans; the engineers are becoming figureheads, support staff required for final approval. The Oil and Gas industry uses workshare and provides the team with go-by example calculations of previous project. We close the door on them expecting high a degree of performance without interaction. These example calculations are presented as the baseline for the work; they are copied and expanded upon faithfully.
This article looks more closely at the structural engineer, within and without the workshare, and the calculations. I found more often than not that engineers do not challenge the example and do not seek to improve upon it. Change is frowned upon and engineers are not encouraged to go against the grain. The assigned scope of work will likely be modelled already and a concept is started which means the engineer also accepts the model at face value and proceeds to analyse it. It seems the engineers are being subordinated to a role of technologists.
The last fifteen years has seen a strait-jacket imposed on the way design office structural engineers work. The emergence of desktop computers ironically killed the structural engineer’s ability to interact with technology. We also saw the loss of many engineering graduates and professionals to the computer industries leaving large generation gaps within our numbers. We are a senior and aging profession missing the continuity of experienced and maturing engineers to maintain and nurture our numbers into the future. While no profession has been immune to the impact of the new technology, some have maximised the benefits more than others, for example the architects and electrical engineers have embraced the opportunities more positively.
Calculations produced by hand twenty years ago were concise and simplified; they identified and addressed the key elements of the design. Nowadays, calculations are not concise or simplified; they are detailed and address every component of the design without identifying the critical behaviour. Nowadays, the hardest part of the engineer’s job is to check calculations, requiring more and more time and resources. The activity of checking getting pushed all the way out to five minutes before the deadline and is not seen as an enjoyable chore.
What happened to us? Mainframe computers were designed, programmed and managed by engineers. We could put man on the moon, build and operate nuclear power stations and model complex seismic behaviours. The languages of FORTRAN, Basic and COBOL ruled the world. The engineers were kings and queens of technology. Desktop computer and Windows smashed that. The languages became complex and obscure like Pascal, C+, VB, Java and we saw the birth of the computer profession.
The drawing/design office saw the transformation of the draughtsman into designer and the rise of the modellers. The designers’ training multiplied and is still a substantial budget for companies to keep abreast of the latest technology. The engineers’ training remained static.
Globally, companies bought into the Windows network and provided MS Office to all employees. Training was not provided as it was determined to be intuitive and of low value to the business balance sheet. On the shop floor, we discovered the profit motivated drive of the Windows business and the endless recycling. MS Office is not geared for engineers but for businesses, payroll, marketing and sales; just look at the endless examples and references. The endless continual revision and upgrade of the MS office product and Windows operating systems also frustrated the engineers. The lack of consistency and uniformity has kept the engineer away from learning how to maximise the opportunities collectively. Even today, the majority of engineers do not know how to use MS Word or get the most from MS Excel. The only software applications having engineering-related components are the structural analysis packages and MathCAD and these have become the staple products for most engineers.
So what happened to the calculations? Structural analysis programmers saw the opportunity to bind the structural engineers to their products by taking care of the reporting features. Many of the big name software applications were developed before MS Windows so the reports are still DOS-based formats. Consequently, the reports show their ancient heritage of courier text, fixed lines, poor graphics and ASCII formats. Only in this direction did engineers embrace the new technology; to perform complex and over-detailed 3D analysis where 2D would suffice. The result of every member would then be printed out and presented as the calculation and the proof. Engineers got drawn into the quality of the analysis, not the quality of the calculation. Calculations have become quantitative tomes of work, failing to meet the primary and fundamental requirements of any structural calculations.
Calculations are required to provide:
III Summary of changes 1 page
II Post-calculation notes 1 page
I Material Take off summary 1 page
8 Scope of work 1 page
9 References 1 page
3 A reasonable basis for design 1 page
1 Design Concept 1 page
2 Sketch for the designer 1 page
4 Load assumptions 2 pages
5 Building the model x pages
6 Key results y page
7 Conclusion 1 page
10 Appendices z pages
QA/QC Checking would then occur after steps 2, 4 and 7.
The calculation cannot be changed after it is signed off as this is the baseline and the original document. Any changes are captured and measured as impact, by statements and percentages, on a page prefacing the original calculations.
To break the strait-jacket thinking, engineers need to look at the way they work:
- Brainstorm the details together
- Talk to each other
- Work together, not in isolation
- Break the work into smaller components
- Perform more frequent regular checks.
- Be visual in your work
- Identify, agree and focus on the key component of the design
- Avoid automatically performing 3D analysis
- Use analysis to verify the thinking.
- Leave the analysis towards the end of the design cycle
- Think about the reader
- Do not keep a history of superseded pages in the calculations
- Ensure the calculations are an active component of the design office cycle
- The calculations are a minimum basis for design, not the final.
- Go electronic
I will revisit each of these points in time.
Monday, April 21, 2008
What's the Plan?
I am waiting for the final edits back on the second book before I can go for a second contract with Trafford. This means the Engineer's Tables will be out in print by the end of June 08. The second book is about how to use Excel as a vital engineer's tool. The first book is about The Engineer's Word (MS Word as a desktop tool).
Most engineers I train accept that maybe the can handle the first two topics MS Word and MS Excel but put their foot down at VBA. When I show the first two topics and it is seen to be easier than anticipated there is a lot pressure to show VBA, from all quarters!
The third book is in progress but I haven't spent as much time as I would like on it, so I need to find a space and time to focus on it. The daytime job is time-consuming and demanding (and exciting), domestic chores are always waiting for me and get ready for the move to Ottawa at the end of June...... Life.
I would like to see the third book ready by late October, I know this book will be the key for most engineers and then designing engineering documents become a creative and powerful process.
My website will go eCommerce-enabled in the next month and the first two books will be available through Motagg website as ebooks. Seminars are of great interests but I really need to finish my books before I consider the next step.
I was asked today what will I write next and I thought about two things:
1) Rules for creating good databases. The Engineer's Database
This is a popular request on my time so I think I can present two types of databases. One that is a MTO collection from external cad files and setting up a drawing register.
2) Anthology of Structural Engineers experiences. the Engineer's Tales
This is a hit list of questions engineers will be invited to answer and write about their careers, the highs, the lows, the best, the worse, the fun and the why.
Saturday, April 19, 2008
At the Palliser Fairmont
I hope we will be able to work together and foster our relationship further on common goals. It was a great pleasure to meet her. She presented a fantastic sketch by Stephen Wilshire to Nigel Shriver, our Chairman of the CPGCE. It was a landscape sketch of famous buildings. I remember watching a documentary of him from when he was maybe 9 or 10. He is a wonderful and thoughtful inspiration for engineers! You should see this clip of him today.
Friday, April 18, 2008
IStructE visit
The little party go on to downtown Calgary to visit a construction site and there's a blizzard in progress! It was a pleasant visit and I look forward to meeting up with them for dinner tonight.
Thursday, April 17, 2008
Life by defaults
Defaults are ruining our ability to express ourselves on paper. Consider this, generally, Structural engineers do not know how to use MS Word, in their work. Many engineers claim indifference but the reader's perception will not be denied. Let's change only one default and pause. Consider the following:
1) Skyscraper designs breaks the limit
2) Skyscraper designs breaks the limit
3)Skyscraper designs breaks the limit.
What do you percieve when you read these sentences just by the strength of the text type? Are you aware of the choices? Are you aware of the reader's perception? Do you care?
You should care. Helping people to understand your work, with subliminal choices, is a skillset of the ninja assassin calibre, in the midst of mediocre conscripted bored soldiers! Choice of text fonts is probably the only default most people would consider they have the confidence to change when they open MS Word.
Number 1 is the default Times New Roman font. It is the mindset of the american publishing standard imposed on the rest of the world.
Number 2 is the arial font, perhaps the second most common selection. Strong in Europe. It enables faster reading speading and is uncluttered at small scale. It is my preferred setting.
Number 3 is the courier font, a relic of the MS-DOS, common to structural analysis packages, producing the results file. Looks ancient and slow, everything spelled with hammer and chisel.
I haven't touched on other text fonts or text sizes, underlining,super- or sub-scripting, or bolding defaults but this will follow in future blogs. The human eye and the ability to visualise are the engineer's most critical tools. I believe engineers are also craftsmen but how many time do you hear someone say 'wow!' when they look at your calculation? How many times have you said it?
It happens nearly every time when people look at my calculations, the pleasure of reading it is apparent. Obviously, it takes more than the font selection and size to get it right but it is a good place to start. Readers always start to wonder how did I do it? It looks simple enough.
The only difference is I do not live by default.
Wednesday, April 16, 2008
Luddites Rules
Slowly, we realised the endless cycle of revisions that would characterise the Windows business and their associated applications. Engineers like to be experts and know everything first before they play around, so the constant changes and development by Windows, was viewed negatively. Some of the tricks I saw the old boys do on the Texas Instruments and Hewlett Packards in the early 90's were exceptionally well planned and professional effort; they inspired me. Unfortunately, the old boys froze in the glare of the headlights that was the future. The changes in upgrading applications of Word and Excel through the mid-90's was a tsunami of too much information and the old boys just wanted to survive. In succeeding generations, they went on to be the bosses and they had no hand-me down rules and wisdom. Collectively, engineers gave up on discovering how to improve computer competencies, what was the point?
The Research companies 'window'-dressed their structural analysis products. They added reporting features, international code-checking routines, interactive graphics and other user interfaces. I am still surprised how reports are still produced in the laughable ASCII formats. I still know many engineers locked only onto MathCAD, STAADPro and Visio and their hand calculations, churning out volumes of notes.
So for structural engineers with no need to interact with the outside world and relate to the general expectations of computer literacy, engineers became luddites. Luddite is a term given to people not accepting changes in technology. At the time of the Napoleonic wars (1812), workers in Nottingham UK protested the changes in their factories breaking loom machines. It occured over a brief period 1811 to 1813 with roots back to 1770. The government stood up to them and in a mass trial in 1813, it was over with people hanged, imprisoned or deported. Luddism never happened again.
Fifteen years on, we accept our work methods and computer literacy leaves a lot to be desired. It's great we can do 3D analysis and complex studies but we cannot do a simple final product calculation worthy of the quality of the analysis. Look around you at the visible products of your work and ask yourself, would a graduate like to work along side a master, or a Luddite?
One engineering graduate, talks of the culture shock of the drawing office as if they had entered the movie set of the Land before Time, surrounded by dinosaurs in cubicles. Tyrannosaurus Rex tapping on keyboards and thinking a lot. I don't believe we are scary, we are just Luddites, scared of the future but we will overcome and move on. For now, Luddites Rules.
Tuesday, April 15, 2008
To first days....
Well, I will settle for a beer. The first day for doing new-style spreadsheets belongs in Holland, circa May 1997. I was creating a spreadsheet for a material take off estimate of civil/structural items on a large Saudi Arabian project. I saw so much repetition of various structural types that I decided to set up a spreadsheet preformed with sketches for each structure. The format and layout would be consistent. The only thing that would change was the sketching of the structural concept and the key assumptions. I learned to draw using Excel and discovered some neat tricks with the shift and control keys, I was getting hooked. My boss was a garrulous and fearsome Dutchman Martin Ouwe who flipped when he saw me drawing. He said I was wasting time, doodling, playing around and blah blah blah. When he finally calmed down, I showed him I had nearly finished the job; he harrumphed and said he over-estimated the hours then. He was not a man for compliments! Over the next two years, I repeated the exercise for a number of projects, in Sweden, Norway, Russia and Africa; changing and tweaking the spreadsheets for specific needs. I think Martin Ouwe became my first fan.
Last year, 2007, I finished an estimate spreadsheet/database for a huge project in Canada, capturing all the piles, steel and concrete drawings. We were originally given ten months to complete it but by the time we had useful information, we only had two months left on the clock! All engineers on the team (+20) knew from experience endless filing of paper, unreferenced numbers and superseded plot plans - lost in time, lost in space. Panic was visible. In spite of the crunched time, it was not a problem. I had used the waiting time to plan the database and plan how the critical information would be handled. I showed five engineers how a plot plan could be captured into Excel and used to track and monitor quantities. It was a vast improvement on what I started ten years ago; I loved it. It was the first day for these five engineers; they were blown away by the method. Four of them have since moved on to other projects enthusiastically bringing 'first days' to others. The last one was my boss, full of enthusiasm and pride; he saw the light from the first day we were teamed up. It was the first day for the client too, who would say they cannot see how it could have been done any other way. I enjoy doing spreadsheet development and showing engineers how to do it. I still find better ways to do what I do, all the time.
When I look at what ten years has shown me, I am still proud of how I got started and those first days. Maybe I will have champagne; I might get a taste for it. To first days.....
