What should an engineering student put in a project portfolio?

Include the requirement, constraints, your decision, the evidence you collected, what failed or changed, the retest and the next unresolved question. Label worked examples clearly and never present sample data as a real result.

Can a failed engineering project belong in a portfolio?

Yes. A failed test can be useful evidence when you preserve the original result, explain the diagnosis, document one justified change and show the retest honestly.

How long should one engineering portfolio case study be?

Start with one scannable page and link to deeper artifacts such as a drawing, test log, repository or process map. The first page should make the requirement, decision and evidence easy to locate.

Engineering Portfolio Projects: Turn a Failed Test Into Proof

The portfolio is not a museum of perfect outcomes

A portfolio can make your reasoning inspectable. That means preserving the awkward evidence: the tolerance that did not fit, the voltage that sagged, the cycle time that refused to move, or the assumption your first test disproved.

This is not a trick for dressing up failure. The evidence has to be real, the context has to be clear, and sample numbers must be marked as examples. The value comes from showing how you moved from observation to an engineering decision.

Why this structure is defensible: ABET’s current engineering criteria include experimentation, data analysis, interpretation and engineering judgment among the outcomes that prepare graduates for practice. NASA’s systems-engineering guidance similarly distinguishes objective verification evidence from validation in the intended environment. A project page built around evidence and decisions mirrors the work itself.

Use the five-part proof stack

1 · Requirement 2 · Attempt 3 · Evidence 4 · Decision 5 · Retest

1. State the requirement before the solution

Write one sentence that explains what the system had to do and the constraint that made the work non-trivial. “Designed a bracket” is an activity. “Designed a bracket that fit the existing envelope while meeting the specified load case” creates a standard against which the decision can be examined.

2. Preserve the first attempt

Keep the drawing revision, test photo, console output, process map or calculation that existed before the fix. Remove personal data and confidential employer material. Do not recreate a cleaner “before” state after the fact.

3. Show the evidence gap

Put expected and observed behavior beside each other. Use units, test conditions and dates where they matter. If you do not have the original reading, say so. “Measurement not recorded” is more credible than a number invented to complete the layout.

Worked example—not a student result: expected 5.0 V; observed 4.61 V under a stated load. A real portfolio must use the student’s actual measurement, instrument and test condition. The number here only demonstrates the layout.

4. Explain one decision

Name the evidence you relied on, the options you considered, the trade-off you accepted and why. If a teammate owned part of the project, make your contribution explicit without claiming theirs.

5. Show the retest—and the remaining risk

Report what changed after the decision. If the retest still missed the requirement, keep it. Finish with the next test you would run, the assumption still unverified or the constraint you would revisit. Engineering proof does not require a cinematic ending.

What this looks like by discipline

Mechanical

Requirement and load case → drawing revision → tolerance or material decision → measurement or simulation result → fit/load retest.

Electrical

Expected behavior → schematic or firmware revision → scoped or logged result → fault hypothesis → controlled retest.

Industrial

Process boundary → baseline definition → intervention → before/after measure with the same method → confounders and next check.

A one-page case-study layout

Top line: project, your role, dates and the single requirement.
Context strip: constraints, tools and what you personally owned.
Before evidence: one labeled visual with units or test conditions.
Decision block: alternatives, trade-off and chosen revision.
After evidence: retest using the same measurement method when possible.
Integrity note: limitations, team attribution, confidentiality redactions and unresolved risk.
Deep links: sanitized drawing, repository, log, notebook or process map.

Copyable proof template

Project:
My role:
Dates:
Requirement:
Constraint:
First test:
Expected behavior:
Observed behavior:
Instrument / method / conditions:
Evidence link:
Decision and trade-off:
Retest using the same method:
Unresolved risk or next test:

If a value was not recorded, write “not recorded.” Do not invent a number to complete the layout.

What to leave out

Employer, lab or teammate material you do not have permission to publish.
Invented measurements, customer outcomes, testimonials or placement claims.
A wall of screenshots with no requirement or decision trail.
Tool lists that do not explain what the tool helped you decide.
“We” language where the reader cannot tell what you did.

Turn today’s project into a return loop

Build the one-page version first. Then release the deeper artifacts as a sequence: the failed test, the decision, the retest and the final reflection. Each installment should stand on its own and point to the next specific piece—not a vague promise to “follow for more.”

Sources and method

This guide combines an Enterns documentation framework with current primary references: the ABET 2026–2027 Criteria for Accrediting Engineering Programs, especially its student outcomes on engineering design, communication, experimentation and judgment; and NASA’s Systems Engineering Handbook: Product Realization and verification/validation appendices. Enterns is not affiliated with ABET or NASA.