James I. Finkel Edited by Leland Teschler |
Engineering students frequently must complete some kind of design project as part of their studies. The comment students involved in these endeavors often make is that they learned more from the design project than from any other challenge attempted during engineering school.
Nevertheless, real-world engineering projects bear little resemblance to academic simulations. Engineers must navigate their work through such obstacles as departmental turf wars, managers with little technical background, and economic realities for which school projects provide scant preparation. Because of such factors, the planning process for actual engineering work differs greatly from what the experience of a senior design project might lead you to believe.
All too often, new engineers armed with too much theory make huge mistakes by not asking the right questions of the right people up front. In a previous article, I suggested that new engineers run trial projects through their organization (“When You Don’t Have a Mentor,” Machine Design, Aug. 25). Lessons learned while interacting with company departments in low-pressure situations come in handy when planning a first real project. Before I begin, I can hear the purists screaming that my arguments are incomplete. I would agree with them. The advice that follows is a single possible plan of attack. Based on your organization, I am sure you will want to make changes.
Planning encompasses two phases: internal (your department) and external (other departments). The experience of walking a sample project through the organization is valuable in the planning process. The key information it tells you are the number of steps in the entire process and, when expenses are involved, how much each department would charge to work on the project. Information gained in this exercise will help you create a crude method of estimating costs.
This informal procedure makes a lot of sense for several reasons. First, in all likelihood, no one has formally examined the project-planning process since the last merger, reorganization, or series of layoffs. So the existing procedures may not reflect the realities of the organization that exists today. Second, as an engineer, you are uniquely qualified to see the organizational chart for what it is — a massive maze. Your life’s mission is to shorten the path.
Consider the following real-life (now historical) example of a project involving thermocouples that failed during the testing of a large centrifugal compressor with an inert-gas mix. The design inlet volume was over 350,000 cfm and the rotor weighed about 17 tons. It took a steam turbine to drive the compressor and a cooling-pond pump system to cool down the hot compressed gas to prevent its deterioration. The problem was that the smaller-than-a-matchhead thermocouples in the fast-moving inlet stream were breaking off from vibration. The broken thermocouples had to be replaced or disconnected. And by the way, the testing cost was over $4,000/hr and even a short test spanned well over 30 hr.
The engineering analysis was twofold. It involved direct and indirect costs. The direct cost of each broken thermocouple was about $5. But what really added up were the indirect costs. There was about 15 min of dead time associated with just determining the thermocouple was out. Engineering then had to contact the instrument foreman, who informed the instrument technician, who replaced the thermocouple. This little game of telephone consumed another 15 min. The control computer had to be reprogrammed and then rebooted to implement the thermocouple change, accounting for another 15 min. Over this span of time and with some luck, the system would have stabilized and thermocouple readings would be steady enough to allow taking a performance data point. Unlucky was if you had to wait another 15 min. So the broken $5 thermocouple brought over $4,000 worth of indirect costs associated with downtime. The high inlet volume resulted in the typical test destroying two to three thermocouples.
Initially, the shop and management were dead set against engineering’s proposed solution: using “more-expensive” thermocouples with a covered bead. They cost about $50 each versus the $5 of the exposed bead type. When presented with the real cost of the item itself and the replacement cost in terms of lost time at over $4,000/hr, though, these two groups were convinced the expensive items were cheap indeed.
This is the type of planning engineering departments can implement using the “control-volume” approach: When you consider not just the item cost but the attendant costs of that selection, you can help nudge the interested parties toward the correct solution. And if (though not the case in this example) the costs of the alternative are too high, you could argue for a hybrid approach — in this case, installing the expensive thermocouples in the inlet stream but using less-expensive types where conditions aren’t as extreme. Even here, you could test your own argument by asking about the carrying costs of keeping two sets (one expensive and one inexpensive) close at hand.
In a case like this, the impact is felt across several departments (shop supervision, technician supervision, shop test crew, testing department, and facilities). It is advisable to stack the deck with decision makers or influencers who you know will make the right choice. By including another engineering function, you add a few more bodies on your side.
For example, the corporate R&D group was invited to participate because they had a vested interest in ensuring compliant test results, in that testing had to follow ASME PTC 10. And the choice of jacketed versus naked thermocouples impacted the time constant for the response. It likely would be difficult to sell the shop guys on the importance of a time constant, though it is an important consideration. (The extra thermocouple mass helps control the temperature swings and improves the test results.) Having other engineers nod in agreement that this slower response is good helps shield the shop from a long, boring, and likely incomprehensible technical argument that you did not have to make. All in all, you need not just piles of paper but also bodies to make your argument. Of course, you’d have to prep the R&D group before your meeting in this case. But when you know the engineering concepts are tough to explain, it certainly helps to bring in a group that is presold.
Planning and replanning
In the age of Google, plans change frequently (sometimes as often as a few times daily). It is often a good idea to plan projects in a way that keeps interruptions to a minimum and reduces the impact of changes in course. Often a good time for a major project that involves a lot of organizational lobbying is during the transition to the next update of the CAD system. While the following example took place during the first implementation of a CAD system, the techniques are still valid. The incident happened at an extruded-rubber products manufacturer.
In this case, the CAD system both created the problem and provided the solution. All of the plant’s formerly hand-drawn sketches had to be digitized or otherwise updated into CAD. In this process, much of the traditional curve fitting done by hand was replaced with a formalized set of rules. The resulting pretty drawings did not quite match what was actually manufactured. It is important to note that the products themselves did not change; they met every functional test. However, one number derived from dimensions in the “drawing” no longer matched the physical production, so there was an internal QA issue. The logical question was, “How do we address the issue?”
An engineer, of course, wants to make sure the end product is good. The first pass at the problem was to see if production could be changed to fit what the drawing described. The local plant-extrusion group said that the thickness at the edge of an extrusion had a well-defined minimum dimension. Too thin and the edge became ragged. A ragged edge gave rise to trapped air in the product. Trapped air is a defect that would show up in X-ray inspections. This air was rarely seen in inspection, so standard production was okay with no process changes.
So the next functional group to address was the drafting group. They explained their rules. Were they to change the curves, the drawing would be “fixed” but would not look right. And the new drawing standards gave great numbers for the 20+ other measured parameters. So their suggestion took a page right out of the current CAD playbook: Put a note where the number didn’t match. CAD is a great place for metadata. (In this case, increasing the derived dimension by 10% worked just fine.) This patch was checked against the several hundred items at the corporate site and it worked on every one.
Armed with a working idea, the next step was to close the loop. All groups — drafting (corporate), QA (corporate and local), engineering (corporate and local), and plant engineering — were asked if they could live with the patch. All suggestions went into an accompanying document that grew from two to 25 pages. Corporate departments and the plant sat in the same building complex so it was an easy task to meet with all the local groups.
Having passed the local “sniff test,” this provisional packet was then waved under the noses of all relevant off-site plant groups. The patch solved a problem that affected all divisions, and the most important groups had signed off, so approval was a formality. Thus, we have a process that serves as a general road map for any effort that is potentially contentious and involves multiple departments:
• Identify the root cause. In this case, the CAD process changed.
• Identify solutions. a) Change the production process? This was risky but had to be addressed so the alternatives were acceptable. b) Change the drawing? In this case, the solution was a resounding, “Maybe.” The drawing was left untouched but the note made other departments happy.
• Avoid turf wars. Keep all the people in the process aware that they are not alone.
• Work incrementally. The programmer’s maxim of starting with something small that works is good advice.
• Build consensus. No matter how good the solution, presenting it as a club is a certain path to failure.
There are additional details to keep in mind when planning this sort of initiative:
• Count steps and figure in variable costing.
• Note that each transaction has a cost, though that cost might not be in the form of dollars paid out. Time is money, even if it is time spent by internal departments.
• Each department has a cost. Google can provide a good estimate. Or simply use $100/hr. (Legal will be higher.)
• When laying out the schedule, start from the end and work back. Though it may seem obvious, avoid completion dates that require negative times. Do not assign an end date three weeks before a start date.
• Use a sanity check during scheduling. One project on which I had the misfortune to work was subjected to six weeks of planning for a review cycle. The review cycle consumed so much time that the actual time to do real work amounted to 1.5 days. No small part of the planning process is to ensure both achievable dates and cooperation in the next project.
Just as you never create just one CAD model, you should also never put together just a simple, stand-alone project proposal. When you discuss your proposal, it should be accompanied by a document tailored to that particular department. And the document should not be a quick note. If you take a bit more time to point out the benefits and risks, the approval process will move more quickly. You want to bring along a document that can go to the department boss, with the expectation of all questions answered.
In the thermocouple example, the strategy that sold the idea of going to a slightly more-expensive design was to point out that though initial costs would rise, total costs would fall in the long term (more than one test). And the total testing time would also drop by at least
2 hr/test. For just one model — there were performance related-issues that mandated extra testing — the savings were over $800,000. I’m not sure what these thermocouples would cost now, but nearly a million dollars buys a lot of test equipment.
All in all, engineering crosses a lot of departmental “silos” in any organization. (See “The Case of the Hollowed-Out Engineering Department,” Machine Design, Sept. 9, 2010.) The good news is that you can usually anticipate the arguments of “costs more,” “takes too much time,” or, “this is already working.” Returning to the extrusion example, CAD, QA, and the production department had different goals. The engineer in the middle had the job of working out a solution that let the work flow with relatively little interruption.
With the CAD group, the suggestion to add a note was balanced with an onerous counterproposal. Without the note, every single recently created working drawing would have had to be regenerated with a new set of rules, and all the drawings would have had to go through yet another review cycle. A second review cycle would chew up more QA and engineering time as well as the effort to redo what was just fixed.
The plant groups were happy as they had to just follow the rules of the “patch.” Normal production was unaffected. Finding out up front that changes could not be made to the process led you, the engineer, to pursue another path.