The capstone project and the engineering design process

The capstone is the last course in the mechanical engineering program, and it is unlike the others. There is no textbook chapter to master and no single right answer at the back. A real client brings a real need, a team of four students turns it into a working design and a prototype over two terms, and the result is judged against the client's requirements rather than against a marking key. Everything from the earlier courses comes back: thermodynamics and fluid mechanics, machine design, vibrations, finite elements, measurement and control. So do skills that no lecture can fully teach, such as negotiating scope, keeping a schedule when parts arrive late, and telling a client something they do not want to hear.

This course follows one capstone team at the engineering school in Portland from the first meeting with its client to the final presentation. Each lesson takes one stage of the design process and works through the decisions the team makes, with a runnable Python check of the numbers. The project is mechanical through and through: a portable, engine-driven pump skid for flood response.

The project: a pump skid for flood response

Every spring the Presumpscot River and the small streams that feed it rise with snowmelt and rain, and every few years a storm pushes water into basements, lift stations and low streets across the region. The towns and volunteer fire services that respond pooled their resources into the Casco Bay Flood Response Cooperative, which owns trailers, sandbags and hoses but rents its large pumps. In the last major flood every rental unit within 300 km was already out, and crews spent two days moving water with small trash pumps that could not keep up. The cooperative has now set aside money to own six large pumps, and it wants them designed for its volunteers, its trailers and its kind of emergency.

Tidewater Pump Works, the pump manufacturer in Portland whose engineers have appeared throughout this program, agreed to sponsor the project. Tidewater would supply the pump wet end from its range, lend its test loop and its welding shop, and consider building the skid as a product if the prototype proved itself. Owen Clarke, a junior engineer at Tidewater who did three co-op terms there as a student, volunteered as the team's industry mentor. Farah Siddiqui, Tidewater's senior design engineer and a licensed professional engineer (PE), will review the design on Tidewater's behalf and decide whether it can carry the company's name.

The client's contact is Dale Thibodeau, the cooperative's equipment coordinator and a retired firefighter. His first email set out the problem in a dozen lines: the pumps must move a lot of water, start quickly, cope with debris, fit on the cooperative's single-axle trailers, run all night without anyone refueling them, be quiet enough to run beside homes, and be set up by two volunteers who may not have touched one since last year's training.

The team

The team has four members. Émilie Gaudet is project manager and the single point of contact with the client. Kwame Asante leads the analysis: pump hydraulics, frame strength and fatigue, noise. Hannah Whitcomb leads manufacturing and CAD, and keeps the configuration: the one controlled set of drawings and the parts list that everyone works from. Rafael Ortiz is test and safety officer, responsible for the risk assessment and the test plan. Their faculty advisor, Professor Margaret Leger, has supervised capstones for fifteen years and will grade the work, but she is clear from the first meeting that she is not the client and will not make the team's decisions for it.

Roles in a capstone are not job titles. Each role is a responsibility for making sure something gets done, not a promise to do all of it alone. Kwame owns the analysis, but Hannah will run the finite element model of the lifting points because she built the CAD geometry, and Émilie will check his hand calculations because a second pair of eyes catches errors the author cannot see. Assigning an owner to every piece of work, and writing it down, prevents the two commonest team failures: the task everyone assumed someone else was doing, and the task two people did twice.

The team charter

In week one the team writes a charter, a two-page agreement that everyone signs. It states the project's goal in one sentence, the roles, how decisions are made, how often the team meets, how members communicate and how quickly they reply, what happens when someone misses a deadline, and how disagreements are escalated. It also records each member's other commitments, so that Rafael's part-time job and Hannah's varsity schedule are known at the start rather than discovered in week twelve.

Decision rules matter most. The TDX-150 team agrees that technical decisions within a lead's area are that lead's to make after consulting the others; decisions that change a requirement, the budget or the schedule need all four members and are recorded in a decision log; and a deadlock goes first to Owen for technical advice and then to Professor Leger. The charter also includes a conflict of interest clause. Kwame's uncle is a volunteer firefighter in one of the cooperative's member towns. That is not a reason for him to leave the project, but it is disclosed so that nobody later wonders whether a decision favored one town's needs.

Models of the design process

Engineers have described the design process in many ways, and most descriptions share the same stages: understand the problem and write requirements; generate many concepts; select the most promising; develop it into a coherent layout, known as embodiment; complete the detailed design and analysis; build and test; and deliver. The figure shows the version this team uses, with four review gates where the client, sponsor and advisor must agree before work moves on.

The process is drawn as a sequence, but real design is iterative. A frame analysis may show that the chosen engine mounts transmit too much vibration, sending the team back to embodiment. A priming test may show that the requirement itself was written badly, sending them back to definition. A good process does not prevent iteration; it makes iteration cheap by catching problems early, when changing a sketch costs an hour rather than when changing a welded frame costs a week.

Two families of process models are worth knowing. Stage-gate models, common in product companies such as Tidewater, divide the work into stages separated by formal reviews at which management decides whether to continue, change direction or stop. Agile models, born in software, work in short cycles that each deliver something usable and are reviewed with the client. Mechanical capstones increasingly blend the two: formal gates for the big decisions, and two- or three-week sprints inside each stage, each ending with a short demonstration to Owen. Hardware cannot be released every two weeks the way software can, but a sketch, a calculation, a 3D-printed model of the priming separator or a test result can.

The review gates

Each gate has an entry condition, a list of what must be shown, and a decision. The critical design review is the one that matters most for a hardware project, because it releases money and shop time. After it, Tidewater's welders will cut steel to Hannah's drawings, and a mistake found later costs real money. Farah has told the team that she will not sign the release until she has seen the frame calculations, the lifting point design and the guarding layout.

Scoping the work: how many hours does the team have?

The first quantitative question in any project is whether the work fits the resources. A student team's main resource is time. The four members expect to give between 10 and 12 hours a week each over 26 teaching weeks. Not all of that time produces design work: meetings, progress reports and the weeks around midterm and final exams take a share, which the team estimates at 18 percent from previous capstones. Professor Leger's experience is that teams who skip this calculation discover in March that their plan needed twice the hours they had.

For the work itself the team uses three-point estimates. For each work package they write an optimistic, a most likely and a pessimistic number of hours, and combine them with the PERT formula, which weights the most likely value four times as heavily as the extremes:

Summing the expected times gives the total effort, and if the packages are treated as independent, their variances add, so the standard deviation of the total is the square root of the sum of the squares. The program below does that arithmetic for the team's first plan and for the revised scope they agreed with Tidewater.

# Team capacity and a three-point (PERT) estimate for the TDX-150 capstone
import math

members = {"Emilie Gaudet": 11, "Kwame Asante": 12, "Hannah Whitcomb": 10, "Rafael Ortiz": 11}  # hours per week
weeks = 26                      # two terms of teaching weeks
overhead = 0.18                 # meetings, reporting, lost weeks around exams
raw = sum(members.values()) * weeks
usable = raw * (1 - overhead)
print(f"Raw capacity {raw:.0f} h, usable after {overhead:.0%} overhead {usable:.0f} h")

# Work packages: (optimistic, most likely, pessimistic) hours
wp = {"requirements and QFD": (60, 80, 130), "concepts and selection": (90, 120, 190),
      "embodiment and CAD": (150, 210, 330), "analysis (pump, frame, noise)": (130, 170, 280),
      "prototype build": (140, 200, 360), "testing": (90, 130, 240),
      "reports and reviews": (120, 150, 210)}
mean = var = 0.0
for name, (a, m, b) in wp.items():
    te = (a + 4 * m + b) / 6
    sd = (b - a) / 6
    mean += te; var += sd * sd
    print(f"  {name:31s} expected {te:6.1f} h  (sd {sd:4.1f})")
sd = math.sqrt(var)
print(f"Total expected {mean:.0f} h, sd {sd:.0f} h")
print(f"Planned load {mean / usable:.0%} of usable capacity")
p90 = mean + 1.2816 * sd
print(f"Hours with 90 % confidence {p90:.0f} h  ->  {'fits' if p90 <= usable else 'does not fit'}")

# Scope agreed with Tidewater: its shop welds the frame to the team's drawings, and its test group runs the loop
revised = dict(wp)
revised["prototype build"] = (60, 90, 160)
revised["testing"] = (70, 100, 180)
revised["analysis (pump, frame, noise)"] = (100, 140, 230)   # enclosure acoustics kept at concept level
m2 = sum((a + 4 * m + b) / 6 for a, m, b in revised.values())
s2 = math.sqrt(sum(((b - a) / 6) ** 2 for a, m, b in revised.values()))
print(f"Revised: expected {m2:.0f} h, 90 % value {m2 + 1.2816 * s2:.0f} h, load {m2 / usable:.0%}")

Raw capacity 1144 h, usable after 18% overhead 938 h
  requirements and QFD            expected   85.0 h  (sd 11.7)
  concepts and selection          expected  126.7 h  (sd 16.7)
  embodiment and CAD              expected  220.0 h  (sd 30.0)
  analysis (pump, frame, noise)   expected  181.7 h  (sd 25.0)
  prototype build                 expected  216.7 h  (sd 36.7)
  testing                         expected  141.7 h  (sd 25.0)
  reports and reviews             expected  155.0 h  (sd 15.0)
Total expected 1127 h, sd 64 h
Planned load 120% of usable capacity
Hours with 90 % confidence 1209 h  ->  does not fit
Revised: expected 940 h, 90 % value 1006 h, load 100%

The first plan needed about 1,127 hours against 938 usable, a load of 120 percent. With 90 percent confidence it would need over 1,200 hours. That plan was going to fail, and the calculation showed it in week two rather than week twenty. The team took the numbers to Owen and Farah, and three changes were agreed. Tidewater's shop would weld the frame to the team's drawings, with the team supervising and inspecting rather than welding; Lucie Arsenault's test group would operate the TL-3 loop for the performance tests; and the acoustic canopy would be designed to concept level only, with Tidewater taking it to production drawings if the project went ahead.

The revised plan needs about 940 hours, 100 percent of usable capacity, and its 90 percent value is still above the hours available. A plan that uses every available hour has no room for the unexpected, so the team also wrote a stretch list: tasks that would be done if time allowed and dropped without discussion if not. A sound-insulating prototype canopy went at the top of that list. Professor Leger approved the plan with one comment in the margin: watch the testing estimate, because testing is where capstones run late.

Writing the problem statement

Before any requirement or concept, the team writes a problem statement. A good problem statement describes the need without describing a solution. 'Design a diesel pump skid' is not a problem statement; it presumes the answer. 'Volunteer flood crews need to remove water from basements, underpasses and lift stations at up to 90 liters per second, using equipment they own, can transport on their existing trailers and can set up in the dark' is closer. It leaves room for diesel, electric, hydraulic and submersible ideas, and it says who the users are and what conditions they face.

The team tested its draft statement on Dale, who added two things it had missed. The pumps would often run beside homes overnight, where neighbors had complained about rented units in the last flood, and volunteers rotate, so many users will have had only an annual training session. Those two sentences became requirements on noise and on set-up, and they changed the concept selection later.

Engineering judgment and the limits of a student project

A capstone is supervised work. The students are not yet licensed engineers, and nothing they produce can be relied on by the public without review. In practice that means two things for this team. Anything the cooperative will actually use, such as the lifting points, the guarding and the fuel containment, must be reviewed and accepted by a licensed engineer, in this case Farah on Tidewater's behalf. And the team must be honest about what it has and has not verified, especially at the end, when the temptation to describe a partly tested prototype as finished is strong. Lesson 11 returns to this.