What's your process for defining the problem in your engineering design project?

Defining the problem in an engineering project: Gather Information: Understand project details and constraints. Stakeholder Insights: Analyze needs and expectations. Context Exploration: Understand the problem's scope and causes. Clear Statement: Create a concise, SMART problem statement. User Focus: Define from user perspective. Constraints: Highlight limitations. Impact Consideration: Assess consequences and benefits. Team Collaboration: Gather diverse insights. Validation: Confirm accuracy with stakeholders. Refinement: Continuously improve the statement. A defined problem anchors your engineering design project effectively.

The symptoms are not the disease. Complaints are not causes. Are solving the problem? Or are you soothing the symptoms? Get to the root causes.

Every design process is done to meet a set of requirements - stakeholder, regulatory, functional, statutory, qualitative or quantitative etc. These requirements define the problem, the scope of design, the boundaries and acceptance criteria. This also forms the basis of design - a document that highlights the set of requirements and data that go into the design process. An optimized design takes care of most of these requirements and creates an acceptable balance. When a parameter within the set of requirements/design basis changes, the design is no longer valid, hence a new design or revalidation process is begun. Several methods had been employed by practitioners to manage design problems one is interface management systems.

Problem definition. Define process to state the problem. Collect all stakeholders opinion on problem cause. Comparison of current state Vs future state. Collect all stake holders opinions on solutions for eliminate problem. Define the process to rating solutions. Collect the alla stake holders opinion on high rated solution. Reframe the current and future state. Conclusion is high rated solution implementation with defined process.

Always start with the customer/client/solution-seeker and get a clear understanding of the issues they are facing. Determine their requirements - essential/non-essential. Before you start engineering in any detail, check their system to identify the solution interface: new feature, modification of existing feature, repair of existing feature, removal of an existing feature or best of all - utilisation of an existing feature. Then I'd recommend reviewing your preliminary findings with the customer/client/solution-seeker before developing any engineering proposals.

The most important part in defining the criteria is to tre to get rid of as much of unnecessary requirements as you could at the beginning. You need to peel every criterion to bare core, and be specific. Constrains should be identified and checked the probable cost of overcoming it(any constraing has a way to overcome), for later cross check it against your solutions. Example: Negotiating standart's requirements with the sertification body. Probubly it would be cheaper to get a clerance for you design rother than designing strictly by the book.

The criteria is somewhat defined by the level of understanding of the problem. The more that is known about the determinants of the problem the easier it is to identify possible solutions and thus the pathway towards achieving a specific aim. Clear understanding of constraints assists in defining and promptly pursuing the solution that is acceptable. However an acceptable solution may not be optimal. Constraints also define how adequately the problem can be addressed and thus communication is important in balancing stakeholder anticipation.

In my experience this personalized approach empowers you to make decisions and solve problems in a way that resonates with your individual preferences and circumstances.

One thing that I have found helpful is that besides defining the criteria and constraints for the problem, you also need to establish the criteria for evaluating the success of the implemented solution.

The problem statement should be clear, concise and direct. The problem statement shouldn't include proposed ways for the solution, since it could create anchoring bias down the road. Statement should also include: -Exact charecteristics you won't to improve. -Quantifiable/mesurable metrics which should be improved. Mesurable metrics will help you assess the success of the work you've done later, by checking against those parameters.

The current final quality check process in our manufacturing facility, impacting both our product quality and customer satisfaction, is marred by inconsistencies and missed defects. It is imperative to address this challenge to enhance product quality, uphold our reputation for excellence, and ensure customer satisfaction. Success will be measured by achieving a 25% reduction in defects missed during the final quality check within the next quarter. This problem statement will guide our efforts to design an improved final quality check process.

By diligently validating and refining the problem statement through stakeholder engagement and analytical tools, you can ensure that it accurately reflects the actual problem and aligns with stakeholder needs. This sets a strong foundation for your engineering design project, enhancing the likelihood of generating effective solutions.

The frameworks as SMART, SWOT and PESTEL will certainly help you to correctly put together the statement. However, the best way to check it is to give the statement to review by your colleagues, or collaborators. Their perspectives will give you a new angle and in future help you to aproch the issue easier. There also can be a hiden benefit, since they helped you identifying the problem, whenever you'll be collaborating later on the issue, they'll be more informed and invested in solving the issue.

Sometimes the problem is not a problem at all, and this must be considered as a valid hypothesis. This may read dumb but almost always someone brings "the problem" to the discussion, already labelled as a problem. However, people should ask themselves why that is a problem, in the first place. Maybe it's a problem only for the person who raised it. Ok, it may be hard to do this especially when the one who raised the red flag holds a hierarchically superior position, but some situations first-read as problems may actually be great opportunities.

It's great to have some structure in approaching new problems, however, there is no one silver bullet to tackle every one of them. Sometimes there is no time to collect all the necessary information and you need to act assuming the cost of delay is higher than the cost of your mistake. The most important thing in such kase is to mesure and be aware of risks of such approach, as well as always inform stakeholders.

Also, it is important to keep a record of everything, document findings, discussions, and decisions because all of these documents can serve as a reference throughout the project.