In any organization that intends to exist for an extended time period, learning is critical. Not repeating mistake allows a business increased profitability. Someone once said (I can’t remember who) something like – “the school of hard knocks is a hard school to go through, but only fools return”.

Over the years Setpoint has been, is, and will continue to be an engineering centric business. Most of the projects we build have never been built before; most are completely clean sheet designs, meaning that no one is quite sure what this machine will end up looking like. This means that there will be multiple iterations as we develop the machine. It is critical to our success that we discover our mistakes as soon as possible to reduce our costs. The table below illustrates how critical it is to discover the problems as soon as possible.

Over time we have developed some unwritten rules that we use to help us down the development path. For this blog we sat down and wrote down the ones that matter to Setpoint.  These are in no particular order:

• Right to left thinking – What are we really trying to solve here?  What must be solved, what would be nice to solve, what doesn’t matter if it is solved? What happens if we just leave it alone?  Is it really a problem?

• Stop to think and drive towards root cause or what really needs to be solved, it is too easy to get caught up in ‘noise’.  Always ask the five whys

• Evaluate and Prioritize: does this need to be resolved this instant, don’t get caught up in minor issues and miss a fundamental problem – (forest for the trees). Most problems don’t have to be solved this instant – a little time and thought usually pays big dividends

• Take a system view of problem, don’t resolve one problem and create 3 others because you isolated the problem and disconnected it from how it has to interact with the rest the system

• Don’t get designed into a corner, you may need Plan B – in fact it usually helps to have more than one legitimate idea as you move forward. This helps avoid sticking with a solution too long that should be discarded.

• You can’t ‘will it to work’. And ”it might work” generally means it won’t work

• Document all important work in a simple manner…your memory’s not that great and often results in faulty assumptions that somehow get turned into facts. Always pull the data to see what is really going on. Many so called facts are generally assumptions…if in doubt, treat it as an assumption and react accordingly

• Turn the problem objective into a math problem if possible. Typically the guy with the equation wins.  It is easy to argue about subjective ideas like – that’ll never last, that’s not strong enough, or that’ll never make cycle time. Facts should rule in those kinds of discussions

• When debugging, only change one thing at a time if possible…seems slow but it’s much faster long term. That way you know what worked and what didn’t.

• When debugging, document a known ‘baseline’ that can be returned to when you’ve tried 4 things & you can’t get anything to work anymore, if in doubt go back to the baseline.

• Sometimes the best way to improve the Design Factor of a system is not by increasing the capability of the system but reducing the requirement…sounds obvious but it’s not.

• When working on timing issues never forget parallel operations are your friend…once again, not always obvious

• Watch for unaccounted moment loading in a design.  Forces are rarely overlooked; however, moments are commonly ignored

• Is the process defined?  Because a process has been duplicated twice in a lab doesn’t mean it can be automated

• What’s the simplest thing that could work?

• Given enough time and money you can solve anything, is regularly heard on the engineering and assembly floors, and it is the enemy of profitability.

• If you had to contribute your paycheck towards it would you still solve it that way?

• And finally – What would Steve do?