The capstone and the client brief

Every course in this program has asked you to solve a piece of a problem that someone else had already framed: size this beam, route this flood, check this footing. The capstone asks for the harder thing. A client describes a need in ordinary language, with a budget, a site and a list of people who care about the result, and a team turns that into a design that can be priced, permitted, built and maintained. This course follows one such project from the first meeting to the final presentation, and each lesson is a stage of the work. The design calculations draw on almost everything you have studied since your sophomore year: steel, concrete, foundations, hydraulics, stormwater, transportation, construction management and professional practice.

The project: the Kestrel Creek trail link

The setting is the one you know from the earlier civil courses. On the edge of Duluth, the city has built a municipal operations center beside Kestrel Creek: the garage and fleet storage building, the pump station, the training pavilion and the wash bay. The Ridgeway Road corridor study rebuilt the road east of Carrick Street with a road diet, a roundabout at the operations center and a new multi-use path along the north side. The Kestrel Creek master plan replaced the Ridgeway culvert and set out a long list of watershed projects.

One item on that list is a gap in the trail network. The new path on Ridgeway Road stops at the creek, about 250 yards upstream of the culvert. On the far side, the training pavilion, the community garden plots and an informal trail along the creek are used every day by staff, students from the nearby high school and residents of the seniors' residence, who currently walk along the road shoulder to get there. The city's parks and engineering departments want a crossing, a short connecting path, a small trailhead parking lot, and stormwater treatment for the new hard surfaces. They have offered the project to the civil engineering capstone at the local university, with Kestrel Bay Engineering as the industry mentor.

The team and the people around it

The team has four seniors at Arrowhead State University. Maya Fontaine is the team lead and takes the structural design. Kenji Sato covers geotechnical and hydraulic work. Amara Osei takes the path, accessibility, parking and stormwater. Lucas Petrov handles the cost estimate, the schedule and the Python tools that the team uses to keep its numbers consistent. Their faculty advisor is Professor Daniel Okonkwo, PE, who grades the work and runs the design reviews. Their industry mentor is Priya Raman, PE, of Kestrel Bay Engineering, who led the earlier operations center work; Dr. Lena Kowalczyk and Anika Rao from the same firm answer questions on the ground and the creek. The client representative is Marion Kask, the city's parks capital projects coordinator, supported by the city's roads engineer.

Each of these people has a different relationship to the work. The client owns the problem and the budget and will live with the result. The advisor is responsible for the education and for the grade, and will not let the team skip a step simply because the client would not notice. The mentor brings practice: how the city really runs its projects, which details fail in the field, and what a reviewing engineer will ask. Keeping those roles distinct is the first skill of the capstone. When the client asks for something that the advisor thinks is beyond the course, or the mentor suggests a shortcut that the advisor will not accept, the team lead has to say so early and find a way through.

Reading the client brief

The city's brief is two pages long. It asks for a crossing that is safe for walkers, cyclists, people using mobility devices and the parks maintenance vehicle; a connecting path from the Ridgeway Road path to the pavilion; trailhead parking for about 30 cars with accessible stalls; treatment of runoff from the new surfaces; a design that respects the creek, which supports a cold-water fishery; and a construction cost within the capital budget, with construction in a single season. It also mentions, almost in passing, a second crossing of the swale beside the pavilion, path lighting and a viewing platform.

A brief like this mixes three kinds of statement. Some are requirements: the bridge must carry the maintenance vehicle. Some are constraints: the budget, the construction season, the permit conditions that will apply to work near the creek. Some are wishes: the viewing platform, the lighting, a bridge that looks good from the road. The team's first deliverable is a scope statement that sorts the brief into these categories, states what the team will and will not deliver, and records the assumptions it is making. Lesson 2 turns that statement into measurable requirements and design criteria.

Stakeholders

A trail bridge looks like a small project, but it touches many people. The team lists them on a stakeholder map, with what each cares about and how the team will hear from them. The parks department wants low maintenance and a trail that people use. The roads department cares about the crossing of Ridgeway Road and about snow clearing. The operations center staff care about security at the pavilion and about construction traffic. The high school and the seniors' residence care about safety and access. Neighbors care about parking spilling onto their street. The conservation authority and the fisheries regulator care about the creek. People who use wheelchairs, walkers or strollers care about grades, surfaces and rest areas, and the city's accessibility advisory committee reviews public projects of this kind.

Tribal nations are stakeholders and, in some respects, more than stakeholders. Duluth lies within the area ceded under the Treaty of 1854, in which the Ojibwe bands reserved rights to hunt, fish and gather, and several bands keep close ties to the region's streams. When a federal permit is needed, the federal agency consults with tribes on historic and cultural resources under Section 106 of the National Historic Preservation Act, and the city has its own engagement practice. The team's role is modest and specific: to ask the city how consultation applies, to make room in the schedule for it, to listen to what is said about the creek and the land, and to reflect it in the design. A student team should not attempt to run consultation itself or to speak for anyone.

Team charter and ways of working

Before any design work, the team writes a charter: a one-page agreement on goals, roles, meetings, decisions and conflict. Theirs commits to a weekly two-hour working session and a weekly 30-minute client or mentor call; to decisions by consensus, with the team lead deciding when consensus fails on a technical question and the advisor deciding on questions of scope; to a shared repository for calculations, with every number in the report traceable to a script or a checked hand calculation; and to raising problems within a week rather than at the next review. The charter also names who checks whose work. In practice this matters more than any other clause, because a design that only its author has looked at is not a design that anyone should build.

Many capstone teams fail not on engineering but on time. The team estimates the effort for each work package and compares it with the hours available. A Python script keeps the comparison honest and is easy to rerun when the scope changes.

# Capstone hours budget: can four students deliver the client's wish list in two terms?
team = ["Maya (lead, structures)", "Kenji (geotechnical, hydraulics)",
        "Amara (path, accessibility, stormwater)", "Lucas (cost, schedule, tools)"]
hours_per_week, weeks = 12, 24          # two 12-week terms
available = len(team) * hours_per_week * weeks
core = [("Client brief, scope and requirements", 50), ("Site data review and site visit", 40),
        ("Concept options and evaluation", 90), ("Superstructure design", 120),
        ("Substructure and foundations", 100), ("Hydraulics, stormwater and permits", 45),
        ("Path, parking and accessibility", 70), ("Cost estimate and schedule", 80),
        ("Risk, safety in design and life-cycle cost", 45), ("Drawings", 150),
        ("Design report and QA responses", 90), ("Presentations and reviews", 60)]
wish = [("Second crossing at the pavilion swale", 180), ("Lighting and electrical design", 75)]
def check(label, items):
    need = sum(h for _, h in items)
    reserve = available - need
    print(f"{label}: need {need} h, available {available} h, reserve {reserve} h ({reserve / available:.0%})")
    return reserve / available
print(f"Available time: {len(team)} students x {hours_per_week} h x {weeks} weeks = {available} h\n")
r1 = check("Client wish list", core + wish)
if r1 < 0.15:
    print("  Reserve under the team's 15 % rule: negotiate scope with the client\n")
# agreed scope: second crossing becomes a recommendation only, lighting becomes a performance
# specification, and the drawing set is trimmed from 14 to 12 sheets
agreed = core + [("Second crossing: recommendation memo", 25), ("Lighting performance specification", 20)]
agreed = [(n, h - 20 if n == "Drawings" else h) for n, h in agreed]
r2 = check("Agreed scope", agreed)
print("  Meets the 15 % rule" if r2 >= 0.15 else "  Still short: trim further")

Available time: 4 students x 12 h x 24 weeks = 1152 h

Client wish list: need 1195 h, available 1152 h, reserve -43 h (-4%)
  Reserve under the team's 15 % rule: negotiate scope with the client

Agreed scope: need 965 h, available 1152 h, reserve 187 h (16%)
  Meets the 15 % rule

The first run is sobering. The full wish list needs about 1,200 hours against about 1,150 available, before allowing anything for the surprises that every project brings. The team's rule is to keep a reserve of at least 15 % of available time, so the wish list is out of reach. After a frank conversation with Marion and Professor Okonkwo, the second crossing at the swale becomes a short recommendation memo, path lighting becomes a performance specification for the city's electrical consultant, and the drawing set is trimmed. The agreed scope leaves a reserve of about 16 %. Nothing was lost by doing this early; a team that discovers the shortfall in the last month delivers less and delivers it worse.

The deliverables and the review gates

The course has three review gates, and the lessons that follow are arranged around them. The concept review, after lesson 4, presents the options and the recommended concept. The design review, after lesson 9, presents the developed design with calculations, a cost estimate and a schedule. The final review, in lesson 12, presents the complete design report and drawings to the client, the advisor, the mentor and an external reviewer from another firm. At each gate the reviewers record comments, and the team must respond to every comment in writing: accepted and done, accepted with a different solution, or not accepted with reasons.

Practical points

• Sort the brief into requirements, constraints, wishes and assumptions before designing anything.
• Write down who the client, advisor and mentor are, and what each is responsible for.
• Budget the team's hours against the scope and keep a reserve.
• Agree in the charter who checks each piece of work.
• Keep a scope log: every change, who asked for it, and what it displaced.