The capstone project: process, teams and the team charter

This is the last course in the computer engineering program, and it is different from every course before it. There are no weekly problem sets with known answers. Instead, a team of four students spends two terms taking a real client's problem from a vague need to a working, tested hardware and software system, and then explains that system to the client, to faculty and to the public. Everything from earlier courses comes back: digital design, embedded programming, signals, networks, real-time scheduling, electronics and professional practice. What is new is that nobody tells you which of those tools to use, or when.

We follow one team through the whole project. Jonah Abara has just returned from his final co-op term at Northway Sensing, the Kingston, Ontario company whose NS-5 roadside traffic sensor he helped analyze in CMP-440 and accelerate in CMP-450. Northway has offered the department a capstone project, and Jonah's team took it. The client contact is Ines Carvalho, Northway's hardware lead. Behind her is a real end user: the City of Kingston's active transportation office, which wants to know how many people walk and cycle on the K&P Trail, at what times, and in which direction, so it can plan lighting, winter maintenance and crossings.

The other team members are Amira Haddad, who loves embedded firmware and did a co-op term writing drivers for a medical device company; Keisha Grant, who is strongest in analog electronics, power and mechanical design; and Lucas Moreau, who has worked on cloud back ends and wants to manage the project. Their faculty advisor is Professor Helen Osei, a former product development manager who now teaches design. The product the team will build is a solar-powered trail counter they soon name TrailCount: a sealed box on a post that counts pedestrians and cyclists separately, in both directions, all year, and sends the counts to a dashboard without anyone visiting the site.

What makes a capstone different

Earlier courses trained you to solve well-posed problems. A design project starts with an ill-posed one. The city's real request was a sentence in an email: we need better trail counts. It did not say how accurate, how often, at what cost, with what power, or what better means. Turning that sentence into something buildable and testable is the first real engineering task, and lessons 2 and 3 are about it. A capstone is also the first time most students face trade-offs that cannot be optimized away. A more accurate sensor costs more power. A faster schedule costs more money or more risk. A feature the client loves may be impossible to verify in the time available. Engineering judgment is the skill of making those trade-offs explicitly, with evidence, and writing down why.

The third difference is that the work is done by a team that did not choose each other for their compatibility, under deadlines that collide with other courses, interviews and life. Many capstone projects that fail do so for team reasons rather than technical ones: unclear roles, unequal effort that nobody raised early, decisions made by whoever shouted loudest, and a final month of panic. Accreditation bodies treat teamwork, communication, project management and professionalism as outcomes to assess, not side effects. That is why this course spends real time on the process before any circuit is drawn.

In Canada, accredited engineering programs are assessed against graduate attributes defined by the Canadian Engineering Accreditation Board. They include a knowledge base for engineering, problem analysis, investigation, design, use of engineering tools, individual and team work, communication, professionalism, the impact of engineering on society and the environment, ethics and equity, economics and project management, and life-long learning. The capstone is where most programs collect their strongest evidence for design, teamwork, communication and project management, so your reports and reviews are also how the program shows that it works.

A design process you can actually follow

There are many named design processes, and they agree more than they differ. Most describe a loop: understand the need, define requirements, generate concepts, select one, design in detail, build, test against the requirements, and deliver, with iteration wherever a test or review shows a problem. For a hardware and software capstone, a practical version has six phases that map onto the two terms.

• Discovery (weeks 1 to 4): meet the client, visit the site, read about existing solutions, write the team charter and a short proposal that states the problem and the approach to solving it.
• Requirements (weeks 4 to 7): turn needs into measurable requirements with verification methods, agree them with the client, and put them under change control.
• Concept and architecture (weeks 6 to 10): generate several concepts, run trade studies, choose an architecture, partition functions between hardware and software, define interfaces and identify the biggest risks. This phase ends at the preliminary design review.
• Detailed design and prototyping (weeks 10 to 18): design circuits, firmware and back-end pieces, build proof-of-concept and alpha prototypes that retire risks, and present the design at the critical design review.
• Integration and verification (weeks 18 to 23): build the beta units, integrate, run the verification plan, fix what fails, and validate with real users in the field.
• Delivery (weeks 23 to 26): final demonstration, final report, handover of source files and documentation to the client, and a reflection on what the team learned.

The phases overlap. Risk-reduction prototypes often start in the first month, because waiting until the design is on paper to discover that the radar cannot tell a jogger from a cyclist would waste half the project. But the order of decisions matters: requirements before architecture, architecture before detailed design, and a verification plan before the hardware arrives.

Roles on a student team

Every member of a capstone team designs and builds; nobody is only a manager or only a note-taker. But clear roles stop work from falling into gaps. Jonah's team assigned two kinds of role. Technical leads own a subsystem: they make day-to-day decisions within it, keep its documentation current and are the first person asked when it breaks. Process roles keep the team running.

Two points about this table are worth noticing. First, each subsystem has exactly one owner, but owners are not alone: the charter says that every major design decision is reviewed by at least one other member. Second, the client liaison role stops the client from receiving four slightly different messages. Ines is busy; she wants one email a week with a clear status and a short list of questions, not a stream of messages from different people.

Jonah's role as liaison needed one more conversation. Because he worked at Northway, he knows things about the NS-5 that are confidential. Professor Osei asked the team to record in the charter that Jonah will not bring Northway's confidential designs or code into the project unless Northway provides them to the whole team under the project agreement. This is a small example of a conflict of interest handled openly, a topic lesson 11 returns to.

The team charter

A team charter is a short document, usually two or three pages, that the team writes in its first two weeks and every member signs. It records the agreements that otherwise stay implicit until they cause a fight. Professor Osei's course requires a charter, and she reads them carefully, because she has seen what happens without one. A good charter covers the following.

• Purpose and goals: one paragraph on what the project is for, and what each member wants from it, such as a portfolio piece, a particular skill or a strong grade.
• Roles and responsibilities, as in the table above.
• Communication: which channels are for what (a chat channel for quick questions, the issue tracker for work, email for the client), the expected response time, and how the team records decisions.
• Meetings: a fixed weekly team meeting with an agenda and notes, a weekly or biweekly advisor meeting, and a regular client meeting.
• Workload expectations: planned hours per week, how time is logged, and what happens when someone has an exam week or an emergency.
• Decision making: what the team decides by consensus, what the subsystem lead decides alone, and how deadlocks are broken.
• Quality standards: code review before merging, design review before ordering boards, and a definition of done for each kind of task.
• Conflict and escalation: how concerns are raised, first privately, then at a team meeting, then with the advisor, and what consequences are possible.

The escalation path matters most, and it is the part students most often skip. Raising a problem with a teammate is hard. A charter that says, in advance, that anyone falling more than 30 % below the team's average logged hours for two weeks will be asked about it at the next check-in turns an awkward accusation into the routine application of an agreed rule.

Planning capacity before planning work

Students usually plan a capstone by listing everything they would like to build. Professional teams start from the other end: how many hours do we actually have? Lucas did this in week 2. The course outline expects about 12 hours per week per student. Over 26 teaching weeks, minus 4 weeks around exams in which little project work happens, that gives a raw capacity. He then held back a reserve, because something always goes wrong: a part on backorder, a board that needs a second spin, a teammate with the flu.

# Team capacity plan for a two-term capstone
members = {'Amira': 12, 'Jonah': 12, 'Keisha': 11, 'Lucas': 13}   # planned hours per week
weeks = 26                      # teaching weeks across both terms
exam_weeks = 4                  # weeks with almost no project time
reserve = 0.15                  # held back for surprises

capacity = sum(members.values()) * (weeks - exam_weeks)
usable = capacity * (1 - reserve)
print(f"Raw capacity: {capacity:,} person-hours")
print(f"Usable after {reserve:.0%} reserve: {usable:,.0f} person-hours")

# work packages: most likely estimate in hours, first draft and after scope decisions
wp = {'Requirements and concept':     (120, 100),
      'Radar signal chain':           (260,  80),
      'Firmware and power modes':     (300, 200),
      'Radio and cloud link':         (150,  60),
      'Enclosure, solar and battery': (170, 100),
      'Verification and field trial': (230, 190),
      'Reviews, reports and demo':    (180, 130)}
for col, label in ((0, 'First draft'), (1, 'After scope decisions')):
    total = sum(v[col] for v in wp.values())
    print(f"{label}: {total:,} h = {total / usable:.0%} of usable capacity")
print()
for name, (a, b) in wp.items():
    print(f"  {name:30s} {a:4d} h -> {b:4d} h")

# contribution balance check from the first six weeks of the time log
log = {'Amira': 61, 'Jonah': 72, 'Keisha': 30, 'Lucas': 64}
mean = sum(log.values()) / len(log)
print()
for who, h in log.items():
    flag = '  <- discuss at next check-in' if abs(h - mean) / mean > 0.30 else ''
    print(f"{who:6s} {h:3d} h  {h / mean:4.2f} x team mean{flag}")

Raw capacity: 1,056 person-hours
Usable after 15% reserve: 898 person-hours
First draft: 1,410 h = 157% of usable capacity
After scope decisions: 860 h = 96% of usable capacity

  Requirements and concept        120 h ->  100 h
  Radar signal chain              260 h ->   80 h
  Firmware and power modes        300 h ->  200 h
  Radio and cloud link            150 h ->   60 h
  Enclosure, solar and battery    170 h ->  100 h
  Verification and field trial    230 h ->  190 h
  Reviews, reports and demo       180 h ->  130 h

Amira   61 h  1.07 x team mean
Jonah   72 h  1.27 x team mean
Keisha  30 h  0.53 x team mean  <- discuss at next check-in
Lucas   64 h  1.13 x team mean

The result was sobering. The team's first list of work packages added up to 157 % of the hours they could realistically spend. That is normal for a first draft, and it is far better to discover it in week 2 than in week 20. The team made three scope decisions with Ines. They would buy a radar module that performs detection on its own processor instead of building a radar signal chain from the NS-5 hardware, cutting that package from 260 to 80 hours. They would send data through Northway's existing network and cloud infrastructure, where Dana Okoye's fleet dashboard already lives, instead of writing their own back end. And they would use a commercial enclosure with a custom mounting plate instead of designing a molded case. The revised plan uses 96 % of usable capacity, leaving the reserve intact.

The second half of the code is the contribution check that the charter promised. After six weeks, Keisha had logged 30 hours against a team mean of almost 57. The script flags anyone more than 30 % away from the mean. At the next check-in, it turned out that Keisha had spent many hours ordering and testing battery cells and had simply not logged them, and that she also had a heavy laboratory course that term. The team adjusted: she logged her bench time, and Lucas moved one documentation task from her list to his. A flag is a prompt for a conversation, not a verdict.

Meetings, notes and the decision log

Capstone teams meet a lot, and many meetings are wasted. Three habits make them worthwhile. First, every meeting has an agenda sent in advance, even if it is three lines long. Second, every meeting ends with notes that record decisions and action items, each with an owner and a due date. Third, the team keeps a decision log: a running list of significant decisions, the options considered, the reason for the choice and who agreed. The log feels like bureaucracy in week 3 and feels like a lifeline in week 20, when the client asks why the team did not use a camera, or when the final report needs to explain the design rationale.

Client meetings deserve special care. Jonah sends Ines an agenda two days before each meeting, brings a short demonstration or a figure whenever possible, and sends a summary within a day that lists what was agreed. If the client asks for something new, he does not say yes on the spot. He writes it down as a change request, and the team evaluates its cost in hours and risk before answering. Clients respect this, because it shows that the team takes their requests seriously enough to analyze them.

Tools of a modern capstone team

Jonah's team set up its tools in week 1, before there was anything to put in them. A shared repository holds firmware, scripts, schematics, the enclosure model and documents, with a simple branching rule: nothing reaches the main branch without a review by a second member. An issue tracker holds every task, linked to the work packages in the schedule. Schematic and layout files live in the same repository as the code, with exported PDFs for reviewers who do not use the tools. A shared drive holds datasheets, vendor quotes and meeting notes. The bill of materials is a spreadsheet with part numbers, suppliers, prices and lead times, and its total feeds the budget.

The rule that saved the most time was a naming and release convention. Every firmware build prints its version and the repository commit on start-up and in every uplink message, so that when a field unit misbehaves the team knows exactly which code it runs. Every hardware revision has a letter, silkscreened on the board. These habits cost minutes and save days.