An engineering goal in a science project is a specific statement describing something you want to design, build, or improve to solve a practical problem. Unlike a scientific question, which asks “why” or “how” something works, an engineering goal starts with a need and focuses on creating or optimizing a solution. If your project involves building a device, improving a process, or designing something that performs a task, you’re working with an engineering goal rather than a traditional science hypothesis.
Engineering Goals vs. Science Questions
Science fair projects generally fall into two categories: investigation projects and engineering projects. An investigation project asks a testable question like “Does the color of light affect how fast a plant grows?” You form a hypothesis, run an experiment, and analyze whether the data supports your prediction. The point is to learn something about how the world works.
An engineering project flips this around. Instead of exploring a question, you start with a problem that needs solving. Your engineering goal describes what your solution should accomplish. For example: “Design a water filter using household materials that removes at least 90% of sediment from dirty water.” The goal gives you a clear target to design toward, build a prototype for, and then test and refine.
The key difference is the endpoint. A science question ends with new knowledge. An engineering goal ends with a working solution, or at least a prototype that gets closer to one.
What a Good Engineering Goal Looks Like
A strong engineering goal has three qualities: it identifies a real problem, it describes what the solution should do, and it includes a way to measure success. Vague goals like “build a better bridge” don’t give you enough direction. Compare that to “design a bridge using balsa wood and glue that supports at least 50 pounds while weighing under 200 grams.” The second version tells you exactly what you’re building, what materials you’re working with, and how you’ll know if it works.
Here are a few examples across different topics:
- Energy: Design a solar oven from recycled materials that heats water to at least 150°F within 30 minutes.
- Environment: Build a composting system small enough for an apartment balcony that breaks down food scraps within two weeks.
- Transportation: Create a rubber band-powered car that travels at least 10 meters on a smooth surface.
- Agriculture: Design an automatic watering system using a plastic bottle that keeps soil moisture consistent for five days without refilling.
Notice that each one names specific numbers or conditions. Those measurable criteria are what separate a goal you can actually test from a wish list.
The Engineering Design Process
Once you have your goal, engineering projects follow a different workflow than the classic scientific method. Instead of hypothesis, experiment, and conclusion, you move through a cycle of designing, building, testing, and improving. Most science fairs expect you to go through this loop more than once, because iteration is the core of engineering.
The typical steps look like this. First, you define the problem and write your engineering goal, including any constraints you’re working within (budget, materials, size, time). Next, you research existing solutions to see what’s already been tried. Then you brainstorm multiple possible designs before choosing the most promising one to build. After building your prototype, you test it against the criteria in your goal. Almost always, the first version won’t fully meet your target, and that’s expected. You analyze what went wrong, redesign, rebuild, and test again.
Judges at science fairs look specifically for evidence of this iteration. Documenting what failed and how you improved it is just as important as the final result. A project that went through three design rounds and still falls slightly short of its goal can score higher than one that succeeded on the first try but shows no refinement process.
Setting Constraints and Criteria
Every engineering goal operates within constraints, and spelling those out is part of what makes your project realistic. Constraints are the limitations you have to work within. Criteria are the standards your solution has to meet. They often overlap, but thinking about them separately helps you plan.
Constraints might include a materials budget (under $15), a size limit (fits on a standard table), a time restriction (must work within 60 seconds), or a rule about what materials you can use. Criteria are the performance benchmarks pulled directly from your goal: how much weight the structure holds, how far the vehicle travels, how clean the filtered water is.
Writing these out before you start building prevents scope creep. It also gives you a clear scoring system for comparing your different design attempts. If version one of your water filter removes 60% of sediment and version three removes 85%, you have concrete evidence of improvement even if you didn’t hit the 90% target.
How to Choose a Problem Worth Solving
The best engineering goals come from real problems you’ve actually noticed. Think about inconveniences in your daily life, issues in your school or neighborhood, or challenges you’ve read about. A student who notices their phone sliding off the desk has the seed of a project about friction and grip design. Someone who sees stray animals getting into garbage bins could engineer a latch system.
Start broad and narrow down. If you’re interested in clean water, research what specific contaminants are the biggest problem in different situations. If you like robotics, identify a repetitive task that a simple machine could handle. The more specific and personal the problem feels, the easier it is to write a focused engineering goal and stay motivated through multiple rounds of testing.
Teachers and judges also respond well to goals that connect to larger real-world issues like clean energy, food waste, accessibility for people with disabilities, or disaster preparedness. You don’t have to solve climate change, but framing your balsa wood insulation project as a small-scale test of affordable home weatherproofing shows you understand why the problem matters beyond the science fair table.
Presenting Your Results
When it’s time to present an engineering project, your display board and presentation should emphasize the journey from problem to solution. Include your original engineering goal prominently so viewers can immediately understand what you were trying to accomplish. Show your research into existing solutions, your initial design sketches, and photos or descriptions of each prototype version.
Data tables and graphs are just as important in engineering projects as in traditional science experiments. Track your test results numerically across each design iteration. A simple table showing “Version 1: 12 meters, Version 2: 8 meters (design change backfired), Version 3: 17 meters” tells a compelling story about your process. If your final design met the goal, highlight that. If it didn’t, explain what you learned and what you’d change in a fourth round. Honest analysis of shortcomings demonstrates stronger engineering thinking than pretending everything worked perfectly.