What to Ask in the Discovery Phase of the Engineering Design Process


    Troubleshooting Technology: It’s Not What You Think

    The pace at which technology, innovation, and design morphs is staggering. There are plenty of intelligent people out there to create great change and discover the next best way to do something, anything … everything. What happens when you’ve invested time, money, and lots of human capital in bringing in a new system, and then another technology comes along and complements it while promising to increase its output, but is not as integrative as it should or could be?

    discovery phase of design engineering process.jpgOr perhaps your operation has outgrown the existing technology or platform and there is no need—or budget available—to go back to the investment drawing board. Sometimes two divisions merge and some form of communication is needed so the inventory control systems and production lines can transfer real-time data to each other. But you’re stuck trying to figure out how.

    Troubleshooting: It’s Not What You Think (Literally!)

    Typically, you would troubleshoot the situation prior to simply writing a check for new systems, machines, or platforms. The process of buying a product is fairly predictable and (somewhat) linear. But how do you effectively troubleshoot a problem during the engineering design process to see if the solution is closer than you think and doesn’t require purchasing a new product or system? Keep in mind that what you “think” you have in front of you as options can be hampered precisely by what you think.

    Discovering the Fastest Path … to Failure

    Yes, that’s right. You want to create a path for the development of the device, but your initial goal in the design phase should be to find the cheapest, fastest product, and best overall solution that you can test out quickly. You want to know if that path doesn’t pan out that you haven’t spent too much time or money. Indeed, you want this to fail as quickly as possible, so if it won’t work, you will know as soon as possible. That way, you vet the best ideas for the lowest cost—and as quickly as possible. You may get lucky and find the solution on the first round, but if it does fail, you will know on the first try and not the third or fourth. What you want to avoid is putting all your resources into it and have it fail. What you will gain is a pathway to either the solution, or a possible solution.

    Click here to find out how asking the right questions created the perfect count-verification solution for the BioPharma industry.

    Brainstorming: What Questions to Ask and Answer?

    There are basic questions you need to ask in the design engineering discovery phase. Remember to consider any offshoot questions ... and answers and suggestions as you go through the process. This applies in a re-design or the initial engineering design process. Invariably an open brainstorming session will elicit organic possibilities that reveal themselves. You may discover that the solution doesn’t live in the software or mechanics, but in an operational shift that needs to occur. At the top of the list is the most basic question that helps you to explore if there even is a problem. You may find out, after uncovering these variables, that the problem you think you have isn’t really the problem.   

    1. Is there a real need?
    2. What is the physical nature of it?
    3. What does it really have to do? And not do?
    4. Is it—the existing problem or possible solution—safe?
    5. Is it worth the investment if the solution already exists; when status quo is simple enough, viable, and available?
    6. Are there size and weight constraints?
    7. Are there requirements and/or constraints it must meet for its ability to function to spec?
    8. What are the constraints holding you back, such that it hasn’t been done before? (Drill down on these constraints … get specific.)

    Here’s an example of how you might drill down on some of the questions above for something electronic—say, a CPU that needs to be in a particular environment, with some size and longevity requirements that make using a battery a necessity. 

    1. Are there requirements and/or constraints for the power supply?
    2. Does it have to function for a year on a battery? More? Can you function with less (length of time)?
    3. Regarding the constraints: do you have the space to put on a bigger battery?
    4. If it needs a smaller battery and must stay on for a long time, you should make sure your computer is off for a long time. Can you design for this contingency?
    5. Is there software that can replace hardware, and vice versa?

    Back to Basics

    When troubleshooting, the concerns address three basics: the person(s), their environment, and the task at hand. Be sure to have the people who are directly involved and affected at the table—or make provisions to include their input. One project we worked on involved instrumentation that oral surgeons use during surgery. When we asked the end-users, the surgeons, what was vital for them to do their jobs, the feedback informed our next steps. They needed to have a visual display of the tooth they were working on to show on the monitor. Making the changes allowed them to work more efficiently, effectively, and safely for the sake of their patients.

    Having all the facts, variables, and input from concerned parties will often save you valuable time, money, and resources. Think of an example of something as simple as getting a new coffee pot for the office. You could spend money on a self-grinding coffeepot that perks up with a timer … then sits half full, burning coffee for the better part of the day. Once you realize that only three people drink only one cup a day, your money will be better spent on a single-cup system. Now everyone can get a fresh cup when they want—and no one has to endure that burnt coffee smell all day.

    As you can see, this approach works when re-designing the most sophisticated of electronic instruments to simple, common-sense situations. When customers come to us with problems, they usually have a solution (or several) in mind. Even though they are experts their fields, this doesn’t mean this is the (only) way to go. What we do then is pull apart the possible solutions and ask them to teach us (convince us), one by one, why it is the right solution. Why? Because we are in the business of looking—not at just certain technologies—but at all technologies. 

    Enginasion has had many different customers over 40 years—from diverse industries. What we do when we configure a solution is to first listen to your situation, challenges, and goals, and then pool history with the latest technologies to create new solutions with solid foundations. We can adapt and engineer new technologies to answer your unique needs—we do it all the time.  

    Case in Point

    We did just that with IMA North America, a large OEM packaging equipment manufacturer, that wanted to upgrade its count verification system to a better design. The goal: 100% accurate counting of tablets, capsules, soft gels, and caplets of all shapes and sizes with a flexible hardware platform that is reconfigured with the touch of a button. 

    Some of the finer design points of the upgrade are: 

    • The new TruCount® machines are 39” and 16” wide—scalable to manage growth
    • Built-in redundancy of 40 networked cameras replaced one camera previously tasked with covering 40” of pills dropping
    • Photo diodes and detectors scan the product at nearly 2,000 times per second

    The case study offers more information about this remarkable technology solution. Is the solution you need one download away? Download it now to find out.

    Download the BioPharma Case Study Here 


    Topics: High-Speed Count Verification Systems, Count Verification Systems, Discovery Phase Design Engineering Process, Troubleshooting Technology

    Share this:

    Written by David Bonneau

    Subscribe to Email Updates

    Recent Posts