The capstone project and the team

In his final year, before he joined Larchmont Energy's distribution planning group as an engineer-in-training, Leo Tremblay led a capstone design team. Larchmont was electrifying the line-crew fleet based at its Lincoln Road substation, and its fleet manager, Doug Pelletier, had a problem nobody inside the utility had time to solve: eight electric trucks, vans and pickups were arriving in the spring, the yard had a small service with little spare capacity, and the trucks had to be ready to roll out after storms, when the grid itself might be down. Marguerite LeBlanc, Leo's former supervisor in planning, agreed to sponsor a student project. The brief that reached the university was one paragraph long: design a solar charging canopy with battery storage for the Lincoln Road yard that charges the fleet every night, keeps the trucks storm-ready, and does not need a service upgrade. This course follows Leo's team through that project, from the first meeting to the final demonstration, and uses it to teach how electrical engineers design real systems.

What a capstone is for

Most engineering courses give you a well-posed problem with one correct answer. A capstone does the opposite. The problem arrives vague, the requirements conflict, the information is incomplete, and many designs could work. Your job is to turn a client's need into a set of measurable requirements, generate and compare alternatives, choose one with defensible reasons, design it in enough detail that someone could build it, build and test the parts you can, and report what you found, including what did not work. Accreditation bodies treat this experience as the point where a student shows they can do engineering rather than just solve exercises.

In Canada, the Canadian Engineering Accreditation Board expects every accredited program to include a significant design experience in the final year that draws on earlier course work and is done under the supervision of licensed engineers. Its graduate attributes, twelve broad abilities that programs must show their graduates have, include 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. A good capstone gives evidence for most of them, which is why your report and logbooks matter as much as the hardware.

This course follows one team's project, but it is written so that you can use it for your own. Each lesson covers one stage of the work, shows what Leo's team did and why, and points back to the earlier courses whose methods they used: power electronics from ELE-470, protection from ELE-480, grid integration from ELE-490, control from ELE-390, and communications and RF from ELE-350, ELE-360 and ELE-455.

Forming the team

Leo's team had four members, chosen partly by the instructor and partly by preference. Aisha Rahman, who had spent a co-op term at a drive manufacturer, took the power electronics. Mateo Silva, an embedded systems enthusiast who had built a small solar charge controller in second year, took the controller and communications. Hannah Kowal, who planned to work in industrial electrical design, took protection, grounding and code compliance, and agreed to be the team's safety officer and test lead. Leo took system architecture and became project manager and client liaison. Their faculty advisor was Professor Simone Gagnon, a licensed engineer with a background in power systems, and Amara from Cedarline Controls, the company where Leo had done earlier co-op terms, offered to review the embedded hardware and lend a corner of Cedarline's test bay.

Two things about that assignment are worth copying. First, every technical area had a single named owner, so there was always one person responsible for each decision, even though everyone reviewed everything. Second, the project roles, project manager, liaison, safety officer, configuration manager and report editor, were assigned explicitly rather than left to emerge. Teams that leave roles implicit usually discover in week ten that nobody has been tracking the budget or talking to the client.

The charter

In the second week the team wrote a charter, a two-page document that everyone, including the advisor, signed. It stated the project's purpose in one sentence, the deliverables, the client and advisor contacts, each member's role and technical area, how decisions would be made, how conflict would be handled, how often the team would meet and with whom, and what each member could expect of the others. The decision rule they chose was common for student teams: the owner of an area decides, after the others have had a chance to object; if two members disagree and cannot settle it, the project manager decides; and anything that changes the scope, budget or schedule goes to the client.

The charter also recorded a conflict of interest. Leo had worked at Larchmont and had a job offer from it, and the client was Larchmont. That is not a reason to keep him off the project, but it is something the advisor and the other members need to know, because it could bias his judgment, for example when the team has to tell the client that one of its requirements cannot be met. Disclosing it in writing, and agreeing that the advisor would sit in on any meeting where the team negotiated scope, was the simple remedy. Engineering codes of ethics treat undisclosed conflicts of interest as a serious matter, and lesson 11 returns to them.

Working agreements in the charter covered the practical things that sink teams: replying to messages within a day, telling the team early when a task will be late, keeping all design files in the shared repository, logging work in individual logbooks, and not changing someone else's part of the design without telling them. These sound trivial. They are exactly what the team argued about in week twelve, and having agreed to them in writing in week two made those arguments short.

Stage gates and sprints

Large engineering organizations often run projects through stage gates: defined phases, each ending in a formal review where the work is judged complete enough to move on. In a capstone the gates are usually the proposal, the preliminary design review (PDR), where the requirements and chosen concept are presented, the critical design review (CDR), where the detailed design is presented before money is spent on hardware, and the final demonstration. Software teams more often use agile methods, working in short sprints that each end with something working, and adjusting the plan as they learn.

Leo's team used both. The reviews at weeks 9 and 15 were fixed gates with the client, the advisor and two outside reviewers, and they were taken seriously: at the CDR the reviewers could, and did, send part of the design back. Between the gates the team worked in two-week sprints, each starting with a short planning meeting and ending with a review of what had been finished. The hybrid suited the project, because the hardware needed the discipline of a frozen design before boards were ordered, while the controller software benefited from being built and tested in small pieces.

Planning the work

Leo broke the project into a work breakdown structure: twelve top-level tasks, each with an owner, an estimate of duration and the tasks it depended on. He then used the critical path method from your project management course to find which tasks set the length of the project. The program below does the forward pass, finding each task's earliest start and finish, and the backward pass, finding the latest times each can start without delaying the end. The difference is the task's float.

# Capstone plan: forward and backward pass over the team's task network (durations in weeks)
tasks = {  # name: (weeks, predecessors, owner)
    'charter':      (1, [], 'Leo'),
    'requirements': (3, ['charter'], 'Leo'),
    'concepts':     (2, ['requirements'], 'all'),
    'trade study':  (1, ['concepts'], 'all'),
    'architecture': (2, ['trade study'], 'Leo'),
    'converter':    (6, ['architecture'], 'Aisha'),
    'controller':   (6, ['architecture'], 'Mateo'),
    'site design':  (4, ['architecture'], 'Hannah'),
    'PCB build':    (3, ['converter', 'controller'], 'Aisha'),
    'integration':  (2, ['PCB build'], 'Mateo'),
    'testing':      (3, ['integration'], 'Hannah'),
    'report':       (2, ['testing', 'site design'], 'all'),
}
order = list(tasks)
es, ef = {}, {}
for t in order:
    d, pre, _ = tasks[t]
    es[t] = max([ef[p] for p in pre], default=0); ef[t] = es[t] + d
finish = max(ef.values())
ls, lf = {}, {}
for t in reversed(order):
    succ = [s for s in order if t in tasks[s][1]]
    lf[t] = min([ls[s] for s in succ], default=finish); ls[t] = lf[t] - tasks[t][0]
print(f"{'task':14s}{'ES':>4s}{'EF':>4s}{'LS':>4s}{'float':>7s}")
for t in order:
    fl = ls[t] - es[t]
    print(f"{t:14s}{es[t]:4d}{ef[t]:4d}{ls[t]:4d}{fl:6d}{'  critical' if fl == 0 else ''}")
print(f"project length {finish} weeks against 26 teaching weeks; schedule margin {26 - finish} wk")
hours = {'Leo': 0, 'Aisha': 0, 'Mateo': 0, 'Hannah': 0}
for t, (d, _, who) in tasks.items():
    for p in (hours if who == 'all' else [who]):
        hours[p] += d * (10 if who != 'all' else 6)
for p, h in hours.items(): print(f"{p:7s} planned {h:4d} h")

task            ES  EF  LS  float
charter          0   1   0     0  critical
requirements     1   4   1     0  critical
concepts         4   6   4     0  critical
trade study      6   7   6     0  critical
architecture     7   9   7     0  critical
converter        9  15   9     0  critical
controller       9  15   9     0  critical
site design      9  13  19    10
PCB build       15  18  15     0  critical
integration     18  20  18     0  critical
testing         20  23  20     0  critical
report          23  25  23     0  critical
project length 25 weeks against 26 teaching weeks; schedule margin 1 wk
Leo     planned   90 h
Aisha   planned  120 h
Mateo   planned  110 h
Hannah  planned  100 h

The result was sobering. The plan took 25 weeks of a 26-week year, leaving one week of margin, and nearly every task was on the critical path. The only task with float was the site design, the drawings and specifications for the full-size canopy, which could slip ten weeks without delaying the end. That told the team two things. They could not afford a late start on the converter and controller, so Aisha and Mateo began reading and simulating during the architecture phase rather than after it. And Hannah's site design work could absorb interruptions, so she became the person who covered when someone else was sick.

The planned hours told a second story. Aisha had 120 hours of planned work and Leo only 90, and Leo's figure did not include the hours he would spend talking to the client, writing meeting notes and chasing decisions. Project managers on student teams almost always underestimate this overhead. The team agreed that Leo would also write the first draft of the report's introduction and requirements chapters, which balanced the load and put the person who knew the client's needs best in charge of describing them.

Working with the client and the advisor

A capstone client is not a professor. Doug and Marguerite had their own jobs, limited time and their own ideas about what success looked like. The team met them every three weeks, sent a one-page status note every week, and kept a decision log: a running list of every decision that affected the client, with the date, the options considered and who agreed. When, in week eleven, the fleet manager asked why the design would not let trucks charge at full power all at once, Leo could point to the entry from week five where the client had chosen a 60 kW grid limit over a service upgrade. The decision log turned a potential argument into a two-minute conversation.

The advisor's role is different again. Professor Gagnon did not tell the team what to design. She asked questions, pointed out where their reasoning was thin, made sure they were working safely and fairly, and assessed their work. Teams get the most from an advisor by bringing specific questions and draft documents to every meeting, rather than hoping to be told what to do.

Records: logbooks, the repository and configuration

Every member kept a logbook, paper or electronic, with dated entries recording what they did, what they measured, what they decided and why. Logbooks are part of the evidence for individual assessment, but they are also how a design team remembers. When the team's converter measured less efficient than predicted in week 21, Aisha found the reason in an entry from week 13 about a gate resistor she had changed and never re-simulated.

Mateo acted as configuration manager. All schematics, layouts, code, calculations and documents lived in one version-controlled repository, with a short naming convention, a rule that nothing was ordered or built from an unreleased file, and a tag for each released version of the design. Hardware revisions were labelled on the boards themselves. These practices are standard in industry and save student teams from the classic disaster of building a board from last week's layout.

Why capstone projects get into trouble

Experienced advisors see the same failures every year. Teams spend too long on requirements and concepts and too little on building and testing, then run out of time. They choose a design because one member likes it rather than because it best meets the requirements. They order parts late, discover that a key component has a twelve-week lead time, and lose the build phase. They test only at the end, find a fundamental problem, and have no time to fix it. They avoid telling the client bad news. And they let one member carry the project while others coast, which damages both the project and the relationships. Most of the methods in the rest of this course exist to prevent one of these failures.