Team formation and project planning

The capstone is the last course of the aerospace program and the first time most students carry a design from a blank page to a defended recommendation. At Kildonan Polytechnic University the course runs across two terms, 26 teaching weeks in all, and every team works for a real sponsor with a real problem. This year Borealis Aerospace is sponsoring five teams. Dr. Teresa Nakamura, the company's chief engineer, has written the brief for the team this course follows, and she has kept it to a single page on purpose: Lockport Flight Centre, a flight school at St. Andrews Airport, just north of Winnipeg, wants to know whether an all-electric two-seat trainer could fly its circuit and air-work lessons at a lower cost per hour than its piston fleet, and Borealis Aerospace wants to know whether such an aircraft is worth developing. The deliverable is a conceptual and preliminary design, a subscale flight demonstration, a certification plan, a cost estimate and a recommendation, presented at a final review in front of the company and the school.

The team is five students. Priya Raman will lead the project. Owen Kowalchuk takes aerodynamics and performance, Fatima Haddad structures and loads, Lucas Moreau propulsion and the battery, and Grace Tanaka-Bell stability, systems and certification. Their faculty advisor is Professor Margaret Lindqvist, P.Eng., who taught aircraft design for twenty years before the course existed. The sponsor provides mentors from the people students met in earlier courses: Élise as the company's day-to-day contact, Arjun Mehta, who sized the Petrel 19 commuter two years ago as an engineer in training, Sam Littlechild for flight test and flight school operations, Marcus Webb for structures, Tomasz Wierzbicki for aerodynamics, Kenji for propulsion and program planning, Hélène for manufacturing, and Rachel Oduya for certification. The aircraft will be called the Plover E2.

This lesson covers the first two weeks: forming a team that can work for eight months without falling apart, agreeing how decisions will be made, and building a plan with a schedule that has been tested against the calendar rather than hoped into it. The rest of the course follows the team through the work, one stage per lesson, and each lesson teaches the methods the team uses at that stage.

What a capstone is for

A capstone is not a longer homework assignment. Earlier courses gave students a well-posed problem and a method; the capstone gives them an ill-posed problem, a customer who does not know exactly what they want, incomplete data, conflicting requirements and a deadline. The engineering accreditation boards in both countries expect graduates to show that they can design under those conditions, work in a team, communicate, manage a project, and weigh safety, cost, regulation and environmental effects together. Professor Lindqvist tells the team on the first day that the grade does not depend on whether the Plover E2 turns out to be a good aircraft. It depends on whether the team finds out honestly whether it is, and can show its reasoning.

That point matters more than it seems. Teams that believe they must deliver a success tend to choose favourable assumptions, stop checking once the numbers look good, and present marginal results as if they were firm. A sponsor gains nothing from such a report. Dr. Nakamura says she would rather read a well-argued “not yet” than an optimistic “yes” that falls apart in the first month of real development.

Forming the team

Teams pass through recognizable stages. Tuckman's model names them forming, storming, norming and performing: members are polite and cautious at first, then disagree about goals, roles and standards, then settle on ways of working, and finally do their best work. The model is a simplification, but it gives the team a vocabulary. When the first real argument comes, usually about who does what or how good is good enough, it helps to know that it is a normal stage and not a sign that the team is broken.

Priya runs the first meeting with three questions: what does each person want from the project, what is each person good at, and what does each person need to learn. Owen wants to work in flight performance after graduating; Fatima has already accepted a job in structures; Lucas built battery packs for the university's solar car; Grace has worked two summers in a certification office. Their answers shape the roles, but the team agrees that every member will also review work outside their own area. A team whose members only check their own work has five single points of failure.

The team charter

The charter is a short document, signed by all members and the advisor, that records the team's agreements before there is anything to argue about. It is far easier to agree on how to handle a missed deadline in week 2 than in week 14, when the person who missed it is in the room.

The decision rule deserves attention. Teams that decide everything by consensus move slowly and give the loudest member a veto; teams that let one person decide everything lose the benefit of five minds. The charter gives each technical owner authority within their area, after review, and keeps consensus for decisions that cut across areas, such as the choice of concept. When consensus fails, the team votes and the minority's objection is recorded. Professor Lindqvist calls this “disagree and commit”: the dissenter commits to the decision but is entitled to have the objection on file, and the team revisits it if new evidence supports it.

The work standard is the clause that will matter most for the quality of the design. A calculation that only its author has seen is not a result. The team uses a simple rule: every number in the report traces back to a calculation with a written method, the inputs and their sources, an independent check (a hand estimate, a second method or a comparison with a known aircraft) and a named reviewer. Marcus tells them this is the same standard his structures group uses at Borealis Aerospace, and that most errors in industry are found by the reviewer, not the author.

Stakeholders

The team lists everyone who has a stake in the outcome and what each one wants. The flight school wants a lower cost per hour, an aircraft its instructors trust, and lessons that are not cut short by the battery. Its students want an aircraft that flies like the ones they will rent after their licence. Borealis Aerospace wants to know whether there is a product, what it would cost to develop, and what the risks are. Transport Canada will want a certification basis that addresses the new hazards of a high-voltage battery and an electric drive. The university wants a design that meets the course outcomes. The neighbours of St. Andrews, who complain about training circuits on summer evenings, would welcome a quieter aircraft, and nobody in the meeting had thought of them until Sam mentioned it.

Each stakeholder has different power over the project and a different level of interest in it. A simple grid helps: the school and the sponsor have high power and high interest and must be managed closely; the regulator has high power but will only engage when the certification plan is ready; the neighbours have low power but high interest and are kept informed through the school. The point of the exercise is not the grid; it is making sure no one whose needs could change the design is forgotten until the final review.

Breaking the work down

A work breakdown structure divides the project into deliverables and then into work packages small enough that one person can own each one, estimate it and report its progress. The rule of thumb is that a work package should take between one and four weeks of one person's part-time effort. Anything larger cannot be tracked; anything smaller drowns the plan in detail. The team's breakdown follows the design process: requirements, concepts, sizing, analysis, detailed design, battery testing, the subscale demonstrator, certification and safety, cost and schedule, and the report and presentation.

Estimating durations is the weakest part of any student plan, because students have never done most of the tasks before. Kenji gives them a technique he uses for new programs at Borealis Aerospace: estimate an optimistic, a most likely and a pessimistic duration for each task, and use the weighted mean

This is the PERT estimate. It is not more accurate than a single guess in any statistical sense, but it forces the estimator to think about what could go wrong, and the spread \(\sigma\) shows which tasks are uncertain enough to deserve a buffer. For the subscale demonstrator, Lucas estimates 3 weeks if a kit airframe can be modified, 5 most likely, and 9 if the team must build its own moulds: \(t_e = (3 + 20 + 9)/6 = 5.3\) weeks with \(\sigma = 1\) week. The team rounds it to 5 weeks and notes the risk.

The critical path

With durations and dependencies, the critical path method finds the shortest possible project length and the tasks that set it. A forward pass computes each task's earliest start and finish; a backward pass from the project end computes its latest start and finish. The difference between the latest and earliest start is the task's float: the time it can slip without delaying the project. Tasks with zero float form the critical path. Any slip on the critical path delays the whole project week for week.

# Critical path for the Plover E2 capstone: two terms, 26 teaching weeks
tasks = {   # id: (name, weeks, predecessors)
    'A': ('Team charter and project plan', 2, []),
    'B': ('Requirements and certification basis', 3, ['A']),
    'C': ('Concept generation', 2, ['B']),
    'D': ('Concept selection and review', 2, ['C']),
    'E': ('Preliminary sizing and layout', 3, ['D']),
    'F': ('Battery cell test rig', 4, ['D']),
    'G': ('Aerodynamics, performance, stability', 3, ['E']),
    'H': ('Structures and loads', 3, ['E']),
    'I': ('Preliminary design review', 1, ['G', 'H']),
    'J': ('Detailed design of wing and battery bay', 4, ['I']),
    'K': ('Subscale demonstrator build', 5, ['I']),
    'L': ('Cell tests and pack model update', 3, ['F', 'J']),
    'M': ('Subscale flight tests', 2, ['K']),
    'N': ('Certification plan and safety assessment', 3, ['J']),
    'O': ('Cost and schedule estimate', 2, ['J']),
    'P': ('Design report', 3, ['L', 'M', 'N', 'O']),
    'Q': ('Final presentation', 1, ['P']),
}
def cpm(tasks, show=True):
    order = list(tasks)                           # listed with predecessors first
    ES, EF = {}, {}
    for t in order:
        ES[t] = max((EF[p] for p in tasks[t][2]), default=0)
        EF[t] = ES[t] + tasks[t][1]
    end = max(EF.values())
    LS, LF = {}, {}
    for t in reversed(order):
        succ = [s for s in order if t in tasks[s][2]]
        LF[t] = min((LS[s] for s in succ), default=end)
        LS[t] = LF[t] - tasks[t][1]
    if show:
        print(f'{"task":44s} {"dur":>3} {"ES":>3} {"EF":>3} {"LS":>3} {"LF":>3} {"float":>5}')
        for t in order:
            fl = LS[t] - ES[t]
            print(f'{t} {tasks[t][0]:42s} {tasks[t][1]:3d} {ES[t]:3d} {EF[t]:3d} {LS[t]:3d} {LF[t]:3d} {fl:5d}{"  *" if fl == 0 else ""}')
    crit = [t for t in order if LS[t] == ES[t]]
    return end, crit

end, crit = cpm(tasks)
print(f'\nproject length {end} weeks; critical tasks: {" ".join(crit)}; margin against 26 weeks: {26 - end}')
# recovery plan: requirements workshop with the sponsor (B 3 -> 2 weeks) and a kit-based demonstrator (K 5 -> 4)
fast = dict(tasks)
fast['B'] = ('Requirements and certification basis', 2, ['A'])
fast['K'] = ('Subscale demonstrator build', 4, ['I'])
end2, crit2 = cpm(fast, show=False)
print(f'recovery plan: project length {end2} weeks; critical tasks: {" ".join(crit2)}; margin: {26 - end2}')

task                                         dur  ES  EF  LS  LF float
A Team charter and project plan                2   0   2   0   2     0  *
B Requirements and certification basis         3   2   5   2   5     0  *
C Concept generation                           2   5   7   5   7     0  *
D Concept selection and review                 2   7   9   7   9     0  *
E Preliminary sizing and layout                3   9  12   9  12     0  *
F Battery cell test rig                        4   9  13  16  20     7
G Aerodynamics, performance, stability         3  12  15  12  15     0  *
H Structures and loads                         3  12  15  12  15     0  *
I Preliminary design review                    1  15  16  15  16     0  *
J Detailed design of wing and battery bay      4  16  20  16  20     0  *
K Subscale demonstrator build                  5  16  21  16  21     0  *
L Cell tests and pack model update             3  20  23  20  23     0  *
M Subscale flight tests                        2  21  23  21  23     0  *
N Certification plan and safety assessment     3  20  23  20  23     0  *
O Cost and schedule estimate                   2  20  22  21  23     1
P Design report                                3  23  26  23  26     0  *
Q Final presentation                           1  26  27  26  27     0  *

project length 27 weeks; critical tasks: A B C D E G H I J K L M N P Q; margin against 26 weeks: -1
recovery plan: project length 26 weeks; critical tasks: A B C D E G H I J L N P Q; margin: 0

The first result is uncomfortable: the plan needs 27 weeks and the course has 26. Nearly every task is critical, because the design process is a chain in which each stage needs the one before it. Only two tasks have float: the battery cell test rig, which can start any time after the concept is chosen and has seven weeks of slack, and the cost estimate, with one. The team looks at the critical tasks for ones it can shorten. Two stand out. Requirements can be compressed from three weeks to two if the school and the sponsor agree to a single full-day workshop instead of a series of meetings. The subscale demonstrator can be built in four weeks if the team starts from a commercial kit airframe rather than its own moulds, which Lucas's PERT estimate had already flagged as the main risk. With both changes the plan fits in exactly 26 weeks.

Exactly 26 weeks means zero float on the whole project, and Kenji warns that a plan with no margin is a plan that will be late. The team takes two further steps. It starts drafting the report in week 18, section by section as each analysis is finished, so the three-week report task becomes mostly assembly and editing. And it schedules a formal check at the end of each month, when any task more than a week late triggers a decision about what to cut. Deciding in advance what can be cut is part of planning: the team agrees that the subscale demonstrator's motor-cut glide tests are the first item to go if time runs out, and the report and presentation are the last.

Risks

A risk register lists what could go wrong, how likely it is, how bad it would be, and what the team will do about it. Each risk has an owner. The scoring is deliberately simple, likelihood and consequence from 1 to 5, because the value of the register is the discussion, not the number.

The third risk is the one Dr. Nakamura cares about most. A battery-electric aircraft may simply not close: the battery needed for the mission may be so heavy that the aircraft grows past any useful size. The team's response is to run a rough sizing loop as early as week 10, with deliberately pessimistic assumptions, and take the answer to the sponsor whatever it is. A bad answer in week 10 leaves time to change the mission; a bad answer in week 24 leaves time only to write it up.

Communication

The team agrees on a single shared repository for all files, with a naming rule and a weekly frozen copy, and a single source of truth for the design numbers: a configuration sheet that holds the current mass, wing area, span, battery energy and every other parameter that more than one person uses. Anyone who changes a number in the sheet records why. Arjun says that the most common failure he saw in industry is two engineers working from different versions of the same number for a month. Weekly progress goes to the advisor and the sponsor as one page: what was done, what is late, what decisions are needed. Design reviews, described in later lessons, are the formal points where the sponsor can redirect the work.