engineering problem solving methodology

10 Steps to Problem Solving for Engineers

Updated: Dec 6, 2020

With the official launch of the engineering book 10+1 Steps to Problem Solving: An Engineer's Guide it may be interesting to know that formalization of the concept began in episode 2 of the Engineering IRL Podcast back in July 2018.

As noted in the book remnants of the steps had existed throughout my career and in this episode I actually recorded the episode off the top of my head.

My goal was to help engineers build a practical approach to problem solving.

Have a listen.

Who can advise on the best approach to problem solving other than the professional problem solvers - Yes. I'm talking about being an Engineer.

There are 2 main trains of thought with Engineering work for non-engineers and that's trying to change the world with leading edge tech and innovations, or plain old boring math nerd type things.

Whilst, somewhat the case what this means is most content I read around Tech and Engineering are either super technical and (excruciatingly) detailed. OR really riff raff at the high level reveling at the possibilities of changing the world as we know it. And so what we end up with is a base (engineer only details) and the topping (media innovation coverage) but what about the meat? The contents?

There's a lot of beauty and interesting things there too. And what's the centrepiece? The common ground between all engineers? Problem solving.

The number one thing an Engineer does is problem solving. Now you may say, "hey, that's the same as my profession" - well this would be true for virtually every single profession on earth. This is not saying there isn't problem solving required in other professions. Some problems require very basic problem solving techniques such is used in every day life, but sometimes problems get more complicated, maybe they involve other parties, maybe its a specific quirk of the system in a specific scenario. One thing you learn in engineering is that not all problems are equal. These are

 The stages of problem solving like a pro:

Is the problem identified (no, really, are you actually asking the right question?)

Have you applied related troubleshooting step to above problem?

Have you applied basic troubleshooting steps (i.e. check if its plugged in, turned it on and off again, checked your basics)

Tried step 2 again? (Desperation seeps in, but check your bases)

Asked a colleague or someone else that may have dealt with your problem? (50/50 at this point)

Asked DR. Google (This is still ok)

Deployed RTFM protocol (Read the F***ing Manual - Engineers are notorious for not doing this)

Repeated tests, changing slight things, checking relation to time, or number of people, or location or environment (we are getting DEEP now)

Go to the bottom level, in networking this is packet sniffers to inspect packets, in systems this is taking systems apart and testing in isolation, in software this is checking if 1 equals 1, you are trying to prove basic human facts that everyone knows. If 1 is not equal to 1, you're in deep trouble.At this point you are at rebuild from scratch, re install, start again as your answer (extremely expensive, very rare)

And there you have it! Those are your levels of problem solving. As you go through each step, the more expensive the problem is. -- BUT WAIT. I picked something up along the way and this is where I typically thrive. Somewhere between problem solving step 8 and 10. 

The secret step

My recommendation at this point is to try tests that are seemingly unrelated to anything to do with the problem at all.Pull a random cable, test with a random system off/on, try it at a specific time of the day, try it specifically after restarting or replugging something in. Now, not completely random but within some sort of scope. These test are the ones that when someone is having a problem when you suggest they say "that shouldn't fix the problem, that shouldn't be related" and they are absolutely correct.But here's the thing -- at this stage they have already tried everything that SHOULD fix the problem. Now it's time for the hail mary's, the long shots, the clutching at straws. This method works wonders for many reasons. 1. You really are trying to try "anything" at this point.

2. Most of the time we may think we have problem solving step number 1 covered, but we really don't.

3. Triggering correlations.

This is important.

Triggering correlations

In a later post I will cover correlation vs causation, but for now understand that sometimes all you want to do is throw in new inputs to the system or problem you are solving in order to get clues or re identify problems or give new ways to approach earlier problem solving steps. There you have it. Problem solve like a ninja. Approach that extremely experienced and smart person what their problem and as they describe all the things they've tried, throw in a random thing they haven't tried. And when they say, well that shouldn't fix it, you ask them, well if you've exhausted everything that should  have worked, this is the time to try things that shouldn't. Either they will think of more tests they haven't considered so as to avoid doing your preposterous idea OR they try it and get a new clue to their problem. Heck, at worst they confirm that they do know SOMETHING about the system.

Go out and problem solve ! As always, thanks for reading and good luck with all of your side hustles.

If you prefer to listen to learn we got you covered with the Engineering IRL show!

For Youtube please go to:

https://youtu.be/EHaRNZhqmHA

For Spotify please go to:

https://open.spotify.com/show/3UZPfOvNwQkaCA1jLIOxp4

And don't forget to subscribe if you get any value from the Engineering IRL Content

• Technical Tactics
• 10+1 Steps to Problem Solving

Recent Posts

How to Implement OSHA’s Requirement of Emergency Medical Services in Construction

Preventing Noise-Induced Issues in Construction

The Advantages of CAD for Modern Engineers

Comentarios

Get your free Engineering Toolkit for Engineering IRL listeners only

Get a copy of the Operational Technology Ultimate Guide for Engineers e-book for free.

• What is Chemical and Biological Engineering?
• Engineering problem solving
• Error and uncertainty
• Process variables
• Process Fundamentals
• Material Balances
• Reacting systems
• Reaction kinetics
• Reactor design
• Bioreactors
• Fluids and fluid flow
• Mass transfer
• Energy balances
• Heat transfer
• Heat exchangers
• Mechanical energy balances
• Process safety
• Engineering ethics
• Sustainability
• Engineering in a global context
• How ‘good’ a solution do you need
• Steps in solving well-defined engineering process problems, including textbook problems
• « What is Chemi...
• Teamwork »

Engineering Problem Solving ¶

Some problems are so complex that you have to be highly intelligent and well-informed just to be undecided about them. —Laurence J. Peter

Steps in solving ‘real world’ engineering problems ¶

The following are the steps as enumerated in your textbook:

Collaboratively define the problem

List possible solutions

Evaluate and rank the possible solutions

Develop a detailed plan for the most attractive solution(s)

Re-evaluate the plan to check desirability

Implement the plan

Check the results

A critical part of the analysis process is the ‘last’ step: checking and verifying the results.

Depending on the circumstances, errors in an analysis, procedure, or implementation can have significant, adverse consequences (NASA Mars orbiter crash, Bhopal chemical leak tragedy, Hubble telescope vision issue, Y2K fiasco, BP oil rig blowout, …).

In a practical sense, these checks must be part of a comprehensive risk management strategy.

My experience with problem solving in industry was pretty close to this, though encumbered by numerous business practices (e.g., ‘go/no-go’ tollgates, complex approval processes and procedures).

In addition, solving problems in the ‘real world’ requires a multidisciplinary effort, involving people with various expertise: engineering, manufacturing, supply chain, legal, marketing, product service and warranty, …

Exercise: Problem solving

Step 3 above refers to ranking of alternatives.

Think of an existing product of interest.

What do you think was ranked highest when the product was developed?

Consider what would have happened if a different ranking was used. What would have changed about the product?

Brainstorm ideas with the students around you.

Defining problems collaboratively ¶

Especially in light of global engineering , we need to consider different perspectives as we define our problem. Let’s break the procedure down into steps:

Identify each perspective that is involved in the decision you face. Remember that problems often mean different things in different perspectives. Relevant differences might include national expectations, organizational positions, disciplines, career trajectories, etc. Consider using the mnemonic device “Location, Knowledge, and Desire.”

Location : Who is defining the problem? Where are they located or how are they positioned? How do they get in their positions? Do you know anything about the history of their positions, and what led to the particular configuration of positions you have today on the job? Where are the key boundaries among different types of groups, and where are the alliances?

Knowledge : What forms of knowledge do the representatives of each perspective have? How do they understand the problem at hand? What are their assumptions? From what sources did they gain their knowledge? How did their knowledge evolve?

Desire : What do the proponents of each perspective want? What are their objectives? How do these desires develop? Where are they trying to go? Learn what you can about the history of the issue at hand. Who might have gained or lost ground in previous encounters? How does each perspective view itself at present in relation to those it envisions as relevant to its future?

As formal problem definitions emerge, ask “Whose definition is this?” Remember that “defining the problem clearly” may very well assert one perspective at the expense of others. Once we think about problem solving in relation to people, we can begin to see that the very act of drawing a boundary around a problem has non-technical, or political dimensions, depending on who controls the definition, because someone gains a little power and someone loses a little power.

Map what alternative problem definitions mean to different participants. More than likely you will best understand problem definitions that fit your perspective. But ask “Does it fit other perspectives as well?” Look at those who hold Perspective A. Does your definition fit their location, their knowledge, and their desires? Now turn to those who hold Perspective B. Does your definition fit their location, knowledge, and desires? Completing this step is difficult because it requires stepping outside of one’s own perspective and attempting to understand the problem in terms of different perspectives.

To the extent you encounter disagreement or conclude that the achievement of it is insufficient, begin asking yourself the following: How might I adapt my problem definition to take account of other perspectives out there? Is there some way of accommodating myself to other perspectives rather than just demanding that the others simply recognize the inherent value and rationality of mine? Is there room for compromise among contrasting perspectives?

How ‘good’ a solution do you need ¶

There is also an important aspect of real-world problem solving that is rarely articulated and that is the idea that the ‘quality’ of the analysis and the resources expended should be dependent on the context.

This is difficult to assess without some experience in the particular environment.

How ‘Good’ a Solution Do You Need?

Some rough examples:

10 second answer (answering a question at a meeting in front of your manager or vice president)

10 minute answer (answering a quick question from a colleague)

10 hour answer (answering a request from an important customer)

10 day answer (assembling information as part of a trouble-shooting team)

10 month answer (putting together a comprehensive portfolio of information as part of the design for a new $200,000,000 chemical plant)

Steps in solving well-defined engineering process problems, including textbook problems ¶

Essential steps:

Carefully read the problem statement (perhaps repeatedly) until you understand exactly the scenario and what is being asked.

Translate elements of the word problem to symbols. Also, look for key words that may convey additional information, e.g., ‘steady state’, ‘constant density’, ‘isothermal’. Make note of this additional information on your work page.

Draw a diagram. This can generally be a simple block diagram showing all the input, output, and connecting streams.

Write all known quantities (flow rates, densities, etc.) from step 2 in the appropriate locations on, or near, the diagram. If symbols are used to designate known quantities, include those symbols.

Identify and assign symbols to all unknown quantities and write them in the appropriate locations on, or near, the diagram.

Construct the relevant equation(s). These could be material balances, energy balances, rate equations, etc.

Write down all equations in their general forms. Don’t simplify anything yet.

Discard terms that are equal to zero (or are assumed negligible) for your specific problem and write the simplified equations.

Replace remaining terms with more convenient forms (because of the given information or selected symbols).

Construct equations to express other known relationships between variables, e.g., relationships between stoichiometric coefficients, the sum of species mass fractions must be one.

Whenever possible, solve the equations for the unknown(s) algebraically .

Convert the units of your variables as needed to have a consistent set across your equations.

Substitute these values into the equation(s) from step 7 to get numerical results.

Check your answer.

Does it make sense?

Are the units of the answer correct?

Is the answer consistent with other information you have?

Exercise: Checking results

How do you know your answer is right and that your analysis is correct?

This may be relatively easy for a homework problem, but what about your analysis for an ill-defined ‘real-world’ problem?

Electrical and Computer Engineering Design Handbook

An Introduction to Electrical and Computer Engineering and Product Design by Tufts ECE Students

Engineering Method

The engineering method (also known as engineering design) is a systematic approach used to reach the desired solution to a problem. There are six steps (or phases): idea, concept, planning, design, development, and launch from problem definition to desired result.

Engineering Method. Source: Ronald L. Lasser

The engineering method has six steps (or phases):

• Development

The development step is often divided to include the iterative cycle of build, test, debug, and redesign. The engineering method by nature is an iterative process.

The idea phase usually begins with a problem. The problem statement is typically only vaguely defined and requires research into its viability and its feasibility. Viability suggests that there is significant value (or demand in the case of product development) in pursing the solution. Feasibility serves as a check on whether the idea can be realized. Feasibility may be high, medium, or low: where high feasibility means that people, technology, and time resources are readily available or known; medium is that resources may not be available directly, but can be found; and low means the resources may be rare or do not exist. The most critical part of the idea phase is to define the problem, validate its value, and identify the customer who desires its solution.

The concept phase is about generating numerous models (mathematical, physical, simulation, simple drawings or sketches), all of which should convey that the solution meets the customer’s expectations or requirements. The numerous concepts are generated using brainstorming techniques, which are review sessions in which elements of one concept are recombined with elements from other in an effort to find a single concept that fits best. Typical design judgment and compromise are required to merge concepts. The concept phase ends with a selection of a single concept.

3. Planning

The planning phase is about defining the implementation plan: identifying the people, tasks, task durations, task dependencies, task interconnections, and budget required to get the project done. Many tools are used to convey this information to team members and other stakeholders including Gantt and Pert charts, resource loading spreadsheets, sketches, drawings, proof-of-concept models to validate that the project can be successfully completed.

One critical tool of the planning phase is the system engineering diagram. This diagram shows the solution as an interconnection of smaller and less complicated sub-systems. A system engineering diagram establishes all the inputs and outputs for each module, as well as the way in which the module transforms the inputs into outputs.

The design phase is where “the rubber meets the road.” Details are specified; specifications are established. Some call this phase “design planning” and the development phase “detailed design.” But no matter what it is called, the purpose of this phase is to translate the customer requirements and systems engineering model into engineering specifications that an engineer (designer) can work with to design and build a working prototype. Specifications are detailed using a number with associated units, e.g., 4 volts, or 3.82 inches, or 58 Hz, or a completion time of 22 days.

5. Development

The purpose of development is to generate the engineering documentation: schematics, drawings, source code, and other design information into a working prototype that demonstrates the solution to the problem. The solution may be a tangible working prototype or an intangible working simulation. Of course, nothing works the first time, so this part of the process tends to be more iterative than the other phases. Specifically, it consists of the iterative cycle: design, test, debug, and redesign. If the project had earlier delays or is not on the planned schedule for other reasons, then this time may be the most frantic since the customer deadline may be closely looming.

While testing and debug are often consider a separate phase, most times they occur side-by-side with development as a design morphs from a concept to an artifact. The latter is recommended, reserving time at the end of development for a final test to confirm the desired result meets customer expectation and designer’s intent. Testing is the verification and validation phase where the concept meets both the anticipated design specifications and the customer’s requirements of the solution. Testing is achieved through experiments—an information-gathering method where dissimilarity and difference are assessed with respect to the design’s present and compared to desired state for the design. The purpose of an experiment is to determine whether test results agree or conflict with the a priori stated behavior. A sufficient numbers of successful testing verifications and validations are necessary to generate acceptable results and to reduce any risk that the desired behavior is present and functions as expected. If the test observations and results do not agree, then a debug process is necessary to identify the root causes and begin corrective action to resolve the discrepancies.

Launch includes the release of the engineering design and documentation package to manufacturing facilities for production. At this point, all qualification testing is complete, and the working prototype has demonstrated functionality.

Cited References

• Ertas, A., & Jones, J. C. (1996). The Engineering design process (2nd ed.). New York: John Wiley & Sons. OCLC WorldCat Permalink: http://www.worldcat.org/oclc/807148675
• Ullman, D. G. (2009). The Mechanical Design Process (4th ed.). New York, N.Y.: McGraw Hill. OCLC WorldCat Permalink: http://www.worldcat.org/oclc/244060468
• Ulrich, K.T., & Eppinger, S. D. (2008). Product Design and Development (4th ed.) New York, N.Y.: McGraw Hill. OCLC WorldCat Permalink: http://www.worldcat.org/oclc/122424997
• ← Art of Design
• Product Liability →

Disclaimer | Non-Discrimination | Privacy | Terms for Creating and Maintaining Sites

#012 - Problem-Solving: A Practical Methodology for Engineers

Today’s newsletter features the flocode podcast. I’m still figuring it all out so please bear with me.

If you would prefer to read rather than listen, the article below contains mostly the same content as the audio version, with the exception of a few additional tangents exclusive to the podcast.

This discussion (with myself) highlights the similarities between problem-solving in engineering and coding, focusing on efficient, iterative, and pragmatic approaches. It advocates for simplicity and continuous learning, underscoring the value of interdisciplinary insights in engineering problem-solving.

These are my opinions based on my own experiences so take it easy.

Some of the books I mentioned:

The Pragmatic Programmer by Andrew Hunt and David Thomas Goodreads Link

Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin Goodreads Link

The Lean Startup by Eric Ries Goodreads Link

Structures: Or Why Things Don't Fall Down by J.E. Gordon Goodreads Link

The Feynman Lectures on Physics by Richard P. Feynman Goodreads Link

Thoughts on the podcast?

I have a rough plan for many topics I plan to cover in these episodes but the main goal is to enjoy the process.

Please let me know if you have suggestions/feedback or requests for topics. I want the Flocode Project to become a collaborative community of engineers growing together and sharing ideas and perspectives. Pull no punches, assassinate me.

Leave a comment

See you in the next one 👊

Problem-Solving: A Practical Methodology for Engineers

This guide is crafted for anyone out there navigating the complexities of modern engineering problems and seeking insights that transcend the usual boilerplate stuff. It's a weird amalgamation of lessons learned thus far on my engineering journey.

The aim is not to prescribe an infallible method or to diminish the tried-and-true practices honed over years of collective experience. Rather, it's to share a collection of principles that have proven their worth in my own personal and professional growth.

This is a delicate topic. Engineers by definition solve problems so far be it from me to tell other engineers how they should go about their business. I would likely have the same success rate as if were to ask my wife to ‘calm down’.

Readers should consider this post as a peer's perspective, offered with humility, acknowledging the vast ocean of wisdom that the engineering community has accumulated and continues to build upon. Every project has its unique context and constraints, and this post is not a one-size-fits-all solution but a starting point for reflection and, perhaps, discussion.

Programming Principles in Engineering

At the intersection of engineering and programming best practices lies a shared commitment to precision, and efficiency. Both disciplines involve constructing systems—be they of concrete, steel or code—that must perform reliably under various conditions. This guide explores how the methodical approach inherent in software development, with its emphasis on clean, maintainable code, parallels the planning and execution required in structural engineering.

The value of pragmatic and efficient problem-solving cannot be overstated. It is the engine driving projects to completion on time and within budget, ensuring that structures not only stand but endure with minimal need for intervention. Efficiency in engineering translates directly into cost savings, safety, and longevity of structures, reflecting the same principles that guide the creation of robust and scalable software.

While pragmatism is a widely acknowledged virtue in engineering, its practical application is more challenging than it appears. It requires a disciplined adherence to simplicity and functionality, resisting the allure of over-complication, and focusing on what truly works within the constraints of the project.

Framing the Problem

Every project begins by confronting a problem that demands a solution. To clearly define the problem, engineers must go beyond the surface symptoms and understand the underlying issues. The questions behind the questions. I often think back to my squeakier 6-year-old self asking my dad a conveyor belt of “Why?, But Why? But How? And then what? Why?”, until he was on the verge of an aneurysm and straining with every fibre of his being to calmly asked me to shut up while he was driving. A fine testament to his patience.

A problem well stated is a problem half-solved.

Breaking down complex challenges into smaller, more manageable parts is the divide-and-conquer strategy. This approach can simplify the problem and enable parallel development. It makes immense projects, which can seem intimidating at first glance, approachable and executable.

Assumptions are the Achilles' heel in problem-solving. I've blindly followed poor assumptions many times in the past. Questioning every hypothesis and commonly accepted 'truths' ensures that solutions are not just innovative but also grounded in reality.

"The first step to solving any problem is to understand that it exists," - Seneca

The psychology of accepting unproven realities is an interesting one, especially when you start to consider authority bias, social proofs and information cascades.

The quality of inquiry often dictates the innovation in response. The best engineers ask the best questions. And everyone loves a good question.

In my best Donald Trump voice - “Nobody loves a good question more than me, believe me”.

The planning and design phase is where the foundation for success is laid. Establishing clear requirements and constraints is imperative. It's a principle borrowed from lean startup methodologies that instructs one to be clear about the 'must-haves' and the 'nice-to-haves'. This clarity in requirements helps in crafting a roadmap that is focused and lean, devoid of unnecessary complexities.

Iterative design is at the heart of agility. Starting with a minimal viable solution and refining it through successive iterations is a strategy that builds resilience into the design process. This allows for adjustments based on real-world feedback, enhancing the suitability and functionality of the final product. It's a process of evolution, where each iteration is an opportunity to learn and improve.

Over-engineering is a common pitfall that can lead to increased costs, extended timelines, and systems that are cumbersome to maintain.

"Simplicity is the ultimate sophistication" - Leonardo da Vinci

Leo’s quote holds true in engineering as much as it does in art. The simplest design often leads to the most robust solutions.

Execution is the stage where plans and designs materialize into tangible outcomes. Writing code—or in the case of an engineer, creating designs—as if one has to maintain it for a lifetime instills a mindset geared toward quality and sustainability. It calls for a vision that looks beyond the immediate completion of a design deliverable toward constructability, long-term utility and reliability.

In software development, test-driven development (TDD) represents a paradigm shift towards ensuring reliability from the get-go. This concept, when adapted to structural engineering, can lead to the implementation of proactive validation through simulation and modelling before physical construction begins. It mitigates risks and ensures that the structure will perform as expected when subject to real-world forces.

Continuous integration and delivery, staples of modern software development practices, are becoming more commonplace in large engineering projects. The ideas of incremental progress and continuous assessment, enabling teams to identify and address issues promptly are standard practice now, think of BIM coordination on any major project. This approach ensures that the final product is refined through continuous feedback and improvement, embodying the thought "We cannot control the wind, we can direct the sail."

This is easy to say and sounds like a standard corporate marketing video but it is the correct way to approach execution, especially in a complex multidisciplinary engineering project where scope changes can have significant domino effects. I have mixed feelings about this personally, with the right team, it’s a fantastic approach but there are times when I felt like there were too many cooks in the kitchen along with backseat drivers and armchair quarterbacks all in my office at the same time.

My advice is to be ruthlessly pragmatic with your execution. Idealize constraints and the limits of your scope, let it be known so that stakeholder expectations are crystal clear. If the goalposts move, adapt and refocus but maintain transparency on all challenges and effects. Easy to say, hard to do.

Review and Refinement

The iterative cycle is incomplete without review and refinement. In the world of programming, code reviews are essential to quality assurance—another practice that finds its parallel in engineering as peer reviews. This collaborative process not only helps in catching errors but also facilitates knowledge sharing and collective ownership of the project's success.

Refactoring is as vital in engineering as it is in coding, described in "Clean Code". It's about revisiting and revising the design to improve its structure and efficiency without altering its external behaviour. It embodies the spirit of continuous improvement and the strive for excellence.

The feedback loop is the heartbeat of the lean startup model and is just as crucial in engineering. It ensures that the project adapts to new information and evolves in response to functional requirements and constraints.

Three excellent books that have profoundly impacted my ability to both frame and solve problems include:

‘The Pragmatic Programmer' by Andrew Hunt and David Thomas has been pivotal. It transformed my perspective on coding practices and embedded the core philosophy of pragmatism, enhancing the flexibility and effectiveness of the solutions I develop. It’s for programmers but at least half of the concepts are perfectly applicable to project management and engineering. It’s a fantastic book and easy to read.

" Clean Code: A Handbook of Agile Software Craftsmanship " by Robert C. Martin - This book profoundly influences the pursuit of clarity and simplicity in writing code, which has an obvious correlation with structural and civil engineering. I might be heavy lifting for beginners. I recommend having 6 months of programming under your belt.

" The Lean Startup" by Eric Ries - This book introduces principles of agility and iterative learning that can be extrapolated to engineering, emphasizing the importance of adaptability and efficient solution-finding in project development. Every project is a startup.

While the books above are not specific to structural/civil engineering, I found tremendous value in the ideas presented and found so many reflections of the common pitfalls I have encountered throughout my career as an engineer.

One engineering-specific, yet casual book that I highly recommend is Structures : Or Why Things Don't Fall Down by J.E. Gordon .

And as a bonus, the Feynman Lectures on Physics by the Richard P. Feynman is the most incredible set of explanations of the basic principles of physics. I recommend this to anyone interested in the nature of reality. The clarity of Feynman’s delivery is inspiring.

In conclusion, the journey through problem-solving in engineering is a continuous learning process, enriched by insights from various disciplines. While this path is often fraught with unexpected challenges, like trapdoors, wild goose chases, and moments of wheel spinning, these hurdles are integral to the process.

As you continue to push the boundaries of what is possible, let us remember that at the heart of every great engineering feat lies a simple yet profound truth: the best solutions are often those that simplify complexity, harness efficiency, and adapt to evolving needs. Let this be a guiding principle as you forge ahead in your quest to solve the engineering challenges of today and tomorrow.

See you in the next one.

Discussion about this podcast

Ready for more?

Engineering Problem-Solving

• First Online: 21 September 2022

Cite this chapter

• Michelle Blum 2  

716 Accesses

You are becoming an engineer to become a problem solver. That is why employers will hire you. Since problem-solving is an essential portion of the engineering profession, it is necessary to learn approaches that will lead to an acceptable resolution. In real-life, the problems engineers solve can vary from simple single solution problems to complex opened ended ones. Whether simple or complex, problem-solving involves knowledge, experience, and creativity. In college, you will learn prescribed processes you can follow to improve your problem-solving abilities. Also, you will be required to solve an immense amount of practice and homework problems to give you experience in problem-solving. This chapter introduces problem analysis, organization, and presentation in the context of the problems you will solve throughout your undergraduate education.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Subscribe and save.

• Get 10 units per month
• Download Article/Chapter or eBook
• 1 Unit = 1 Article or 1 Chapter
• Cancel anytime
• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info
• Durable hardcover edition

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

https://www.merriam-webster.com/dictionary , viewed June 3, 2021.

Mark Thomas Holtzapple, W. Dan Reece (2000), Foundations of Engineering, McGraw-Hill, New York, New York, ISBN:978-0-07-029706-7.

Google Scholar  

Aide, A.R., Jenison R.D., Mickelson, S.K., Northup, L.L., Engineering Fundamentals and Problem Solving, McGraw-Hill, New York, NY, ISBN: 978-0-07-338591-4.

Download references

Author information

Authors and affiliations.

Syracuse University, Syracuse, NY, USA

Michelle Blum

You can also search for this author in PubMed   Google Scholar

End of Chapter Problems

1.1 ibl questions.

IBL1: Using standard problem-solving technique, answer the following questions

If you run in a straight line at a velocity of 10 mph in a direction of 35 degree North of East, draw the vector representation of your path (hint: use a compass legend to help create your coordinate system)

If you run in a straight line at a velocity of 10 mph in a direction of 35 degree North of East, explain how to calculate the velocity you ran in the north direction.

If you run in a straight line at a velocity of 10 mph in a direction of 35 degree North of East, explain how to calculate the velocity you ran in the east direction.

If you run in a straight line at a velocity of 10 mph in a direction of 35 degree North of East, explain how to calculate how far you ran in the north direction.

If you run in a straight line at a velocity of 10 mph in a direction of 35 degree North of East, explain how to calculate how far you ran in the east direction.

If you run in a straight line at a velocity of 10 mph in a direction of 35 degree North of East, how far north have you traveled in 5 min?

If you run in a straight line at a velocity of 10 mph in a direction of 35 degree North of East, how far east have you traveled in 5 min?

What type of problem did you solve?

IBL2: For the following scenarios, explain what type of problem it is that needs to be solved.

Scientists hypothesize that PFAS chemicals in lawn care products are leading to an increase in toxic algae blooms in lakes during summer weather.

An engineer notices that a manufacturing machine motor hums every time the fluorescent floor lights are turned on.

The U.N. warns that food production must be increased by 60% by 2050 to keep up with population growth demand.

Engineers are working to identify and create viable alternative energy sources to combat climate change.

1.2 Practice Problems

Make sure all problems are written up using appropriate problem-solving technique and presentation.

The principle of conservation of energy states that the sum of the kinetic energy and potential energy of the initial and final states of an object is the same. If an engineering student was riding in a 200 kg roller coaster car that started from rest at 10 m above the ground, what is the velocity of the car when it drops to 2.5 m above the ground?

Archimedes’ principle states that the total mass of a floating object equals the mass of the fluid displaced by the object. A 45 cm cylindrical buoy is floating vertically in the water. If the water density is 1.00 g/cm 3 and the buoy plastic has a density of 0.92 g/cm 3 determine the length of the buoy that is not submerged underwater.

A student throws their textbook off a bridge that is 30 ft high. How long would it take before the book hits the ground?

Rights and permissions

Reprints and permissions

Copyright information

© 2022 Springer Nature Switzerland AG

About this chapter

Blum, M. (2022). Engineering Problem-Solving. In: An Inquiry-Based Introduction to Engineering. Springer, Cham. https://doi.org/10.1007/978-3-030-91471-4_6

Download citation

DOI : https://doi.org/10.1007/978-3-030-91471-4_6

Published : 21 September 2022

Publisher Name : Springer, Cham

Print ISBN : 978-3-030-91470-7

Online ISBN : 978-3-030-91471-4

eBook Packages : Engineering Engineering (R0)

Share this chapter

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research