In my last article Applications vs. Design, I ended by introducing Fermi estimations. As a young engineer, I would struggle searching for exact mathematical models that represented analysis problems. Years ago a Research Engineer gave me three words of advice approximate, approximate, approximate. That same advice is what Fermi estimation i...s about. Fermi may not be a good tool for a detailed proposal but it is an excellent tool to help decide if you wish to submit a proposal especially when you have little data. If you are trying to decide which product to develop or market to pursue from among a few possible choices the process is also useful.
Two observations I made during my years working as an engineer and manager are: 1) At first glance most people under estimate an effort, 2) If you ask a person for an estimate they often freeze. Keeping these two human traits in mind will make Fermi an easier tool to use. Instead of asking how long it will take, it is better two ask “will it take 2 weeks” - you will get a faster response, yes, no, 1 week, three weeks etc. Now you have something to work with. Keep observation 1 in mind. With a hard number offered by a coworker, ask why. They will reveal what hard points they used to make the assessment. This is all happening real time. This could reveal issues you were not aware of or self-imposed requirements your coworker used in his estimate.

For a family story about observation #2 see below*

To address observation number one above, just break down the task into smaller pieces. If there are teams break it down along the team functions, mechanical engineering, electrical, purchasing etc. Within each group break it down further. How far you need to go will vary from project to project and how exact an answer you require. Breaking it down is a key step. It allows people to focus on a small aspect. Another phenomenon is that some estimates will be high and others low so many smaller pieces will have an averaging effect.

You can do a good job of estimating unfamiliar things by comparing it to things the team members know and have hard data for. Project X took Y hours of lab time and we had previous experience with X type projects. The proposed project has a few areas we have no experience with, there will likely be areas that we discover that we are not familiar with. This tells you it will likely take longer and more money that project X.

Ask simple questions - is this effort more difficult than X? Once you get an answer then ask, is it twice as much or half etc. You will find it much easier to get someone to say yes or no to a hard suggestion than to get him or her to offer the number straight away. If the design looks twice as complex as projects you know multiple the known by the complexity factor. If it took 100 hours for a similar project and the new project is twice as complex, estimate 200 hours.

Who to involve will depend on the situation. For example, If your detailed schedules indicate that in 6 months you will have a large quantity of engineering resources idle, you may want to use Fermi to decide among several design concepts which to develop into a new product. This may need to involve just engineering. If you narrow the selection to two or more you may need to do a similar exercise which includes manufacturing or all departments.

Fermi may sound like wild guessing to you. Think about it this way. If you were guided blindfolded into a room that contained a dartboard on one wall, you would have no idea which wall the target was on or what direction you were facing. Since you have hard data to apply complexity factors to it would be like putting the blindfold on after seeing the location of the target. You may miss the target but you will likely hit the correct wall. Fermi gets you into the ballpark.

Remember that the Fermi estimation is just that an estimate. If your results indicate the project would take 3 times the resources that you have and another project will take 75% you can make a decision. Even if the 3x turns out in the end to be 2.25X and the 0.75X is 1.25X you still picked the lower risk project going with 0.75X – all else being the same. If your estimates for two competing projects are 1.0X vs. 1.1X you may need to dig a little deeper. If you applied the same method to estimate profit and the riskier project (3X of resources) had a profit 10X over the safer project, there is a decision point. Do you borrow money and ramp up staffing?

This process can be used in countless ways. If you have questions don’t hesitate to contact me. [email protected],

If you found this information helpful, there are other articles at www.jagengrg.com/blog

*Now for the family story. When I moved from home for my first engineering job I wanted to continue with the traditional Easter cakes my late mom baked. Many of mom’s written receipts made the German enigma code appear easy to crack. Some would call out items quite clear, 6 eggs for example. For other quantities, all that was listed was “enough” - I kid you not. I asked my sister what was enough - flour in this case. She could not, would not, provide a number after repeated requests. She said use your judgment. I thought I would seek up on the correct amount by the tablespoon. After the first disaster I told my sister, that I used 5 tablespoons. (bakers stop laughing). She instantly said (think Brooklyn NY) “what! you need at least 5 cups.” The psychology here I think is a self-imposed requirement on accuracy. When I asked how much she was thinking 5.1 vs. 5.2 cups. I was the guy who walked into the room blindfolded. An estimate on her part of 4 to 6 cups would have gotten me a lot closer. Once I suggested a number a good estimate came without delay.

Donald Rumsfeld raised many eyebrows when he spoke about unknown unknowns. If you are a design engineer, you have a better appreciation for that comment than most people do. What may not be appreciated is the gap between application engineering and design engineering – here lurks the unknown unknowns.

Many of the unknowns discovered during the development phase will drive the final design. But are the reasons for the final configuration documented and parameter boundaries fully understood? During testing, are we unknowingly approaching the parameter envelopes that minor modifications in the future will allow expected use of the product to exceed the envelopes? To avoid being too abstract I will use an example where I nearly headed down the application path when a design program was required.

A web printing press uses a continuous length of paper (the web) guided through the machine by rollers. Our product used dead shafts to support rollers. Dead shafts are easily aligned in the field. This greatly reduces the precision required for manufacturing the support frames and the skills and equipment required during installation. The dead shafts are steel shafts with diameters ranging from one to two inches. A dead shaft does not rotate. The shaft is attached at each end to vertical frames that are parallel to each other. The roller body has ball bearings at each end with the inner race fixed to the dead shaft with setscrews. Our equipment, which we configured for a great variety of machines used rollers of various diameter and length combinations. Though the two parameters, diameter and length, had many combinations we remained within the parameter envelope and did not realize when we were approaching the limits. This often happens when a design is inherited (transferred from the design group to the application group) and an incomplete data trail exists to explain why the design is as it is.

The initial design accepted a web width of 40”. Later variations ranged from 26” to 80” wide. There was one parameter we did check each time and we were OK. There was another that we did not consider. We were always well inside the envelope at 40” and just pushing the envelope at 80” length but did not know it.

The parameter we were familiar with but never addressed for these applications was the axial alignment of the inner and outer races. The load on the roller induced by the web tension is surprising high. This is very much the case with a 180 degree web wrap which doubles the load. Our concern was always with the bending of the roller body not the shaft that supported it. Though the roller was a thin wall cylinder with end plugs for mounting the bearing’s outer race it had a diameter of 4 to 12” vs. the dead shaft of 1 or 2”. The moment of inertial of the roller body was magnitudes greater than the shaft. Loading on the roller body was evenly distributed by the web. The loading on the dead shaft was a point load at the bearings.

We were a fast turnaround shop. Often fire-ready-aim but good at it most of the time. When management wanted to go to 120” length rollers their expectation was just another two to three week application project vs. a design and development project which will take considerably more time. Design engineering and application engineering may look similar especially to the sales department but there is a difference. The difference can range from a fine line to a wide and deep canyon. When orders are coming in hand over fist, it is easy skip the assessment and in short time find your team as the bottom of that canyon.

Recalling the pain caused by those fire-ready-aim projects that went bad, I was able to insist on a proper study. One of the unknowns that became a known was the length limit for which dead shaft rollers are used. Too long and the bowing of the dead shaft creates too large of an angular misalignment of the bearing races. You can increase the shaft diameter but the shaft’s own weight causes it to bow with gravity. In short, at some point rollers needs to go to live shafts and at 120 inches we were way past that point.

Live shafts require bearings mounted in the support frames that required machining accuracies that would have turned the entire product line on its ear. Someone likely picked the dead shaft approach early on and so much of the design and installation became depended on it. That simple fact of inner race to outer race angular alignment had a major ripple effect on the entire design and alignment process during installation.

My study was fast and dirty. How close I was to a true budget and schedule will never be clear. The study clearly indicated the effort we faced was not just another application. Had we proceeded we would have quoted prices and schedules that would have proved impossible to meet. The resources to develop the design were too great and the project dropped with minimal resources expended.

I was able to do the study very quickly using a method I watched an old sage use to put together a multimillion-dollar budget estimate in less than two hours. I later come to learn I was using the Fermi estimation method. Fermi estimation is a powerful tool and would make a good article for the future.