NUC-499 · Lesson 1 of 12 · 27 min

Team formation and project planning

Hana Okoye has spent three work terms at Meridian Nuclear Engineering, writing chapters for studies on reactor control, licensing and advanced reactors. Now she is back at Red River Polytechnic University in Fargo for her final year, and the capstone project she has been assigned is the most ambitious one the nuclear engineering program has offered. The university's director of facilities and energy, Grant Whitford, has asked a simple question that turns out to be hard: could a small reactor on campus replace most of the natural gas the university burns to heat its buildings? Meridian Nuclear Engineering has agreed to sponsor the project, with Rohan Desai as industry mentor, and Professor Helen Mwangi, PE, is the faculty advisor.

The team has five members. Hana will be project manager and integrator. Kofi Asante takes the reactor physics, Mira Lindqvist the thermal hydraulics, Sofia Reyes the safety analysis and shielding, and Nikolai Petrov the licensing strategy and the cost estimate. At their first meeting, Professor Mwangi gives them the rule that will govern the next two terms: “Your design will be judged on whether every number in it can be traced to a requirement, an assumption or a calculation. A good-looking reactor with untraceable numbers is a failed capstone.”

This lesson covers how a capstone design team is formed and organized, how the project is scoped and planned, and how schedule, risk and communication are managed from the first week. It introduces the work breakdown structure, the critical path method and the team charter, and it shows how the habits of a nuclear safety culture, such as questioning attitudes, conservative decisions and clear records, apply to a student team as much as to an operating plant.

What a capstone design project is for

A capstone project is the point in an engineering degree where analysis turns into design. Earlier courses gave the team the tools: neutron diffusion, heat transfer, fluid mechanics, radiation shielding, reactor kinetics and probabilistic safety assessment. The capstone asks them to use those tools together, under constraints, to make decisions that cannot be checked against an answer key. ABET, which accredits engineering programs in the United States, expects every program to include a major design experience that draws on the whole curriculum and requires students to meet needs within realistic constraints, including public health, safety and welfare, economic, environmental and societal factors. The capstone is where the program shows that its graduates can do this.

A nuclear capstone carries an extra expectation. The public and regulators judge nuclear engineers by whether their designs are safe under conditions nobody wants to happen, and by whether they can explain why. A team that designs a heat exchanger and gets the fouling factor wrong produces an inefficient plant. A team that designs a reactor and gets the reactivity balance wrong has produced something that could not be licensed. The capstone therefore spends as much effort on safety analysis, shielding and licensing as on the core itself, and the final report is written so that a reviewer can follow each safety argument from its premises to its conclusion.

The deliverables for this capstone are set by the program: a requirements document by week four, a concept selection report and gate review by week eight, a design review package in the second term, a final report and a final presentation to a panel of faculty and industry reviewers. Each deliverable is assessed for technical content and for the team's use of engineering judgment: whether assumptions are stated, whether the uncertainty of each result is understood, and whether design choices follow from analysis rather than preference.

Forming the team and assigning roles

Most student teams are formed by the course instructor, sometimes with input from the students about their interests and schedules. The instructor tries to balance strengths, but no team arrives with exactly the skills the project needs. The first task is to map the work to the people, then to identify the gaps. Hana's team draws a simple matrix with the technical areas down the side and the team members across the top, and marks who is the lead, who is the reviewer and who needs to learn the area. Every technical area must have a lead and an independent reviewer, which in a nuclear project is not a formality: an independent check of each calculation is how errors are found before they reach a safety argument.

The team's responsibility matrix. Each area has a lead and an independent reviewer.
AreaLeadReviewerMain outputs
Project management, requirements, integrationHanaNikolaischedule, requirements matrix, report structure
Reactor physicsKofiSofiacore layout, reactivity balance, control rod worth
Thermal hydraulicsMiraKofinatural circulation, temperatures, boiling margins
Safety analysis and shieldingSofiaMiraaccident analysis, event trees, dose rates
Licensing and costNikolaiHanalicensing route, schedule, cost estimate, cost of heat

Roles in a capstone are not job titles; they are commitments about who will make sure something gets done. The project manager is not the person who does the most technical work, and should not be. Hana's job is to keep the schedule, chair meetings, track decisions and actions, maintain the requirements and make sure the pieces fit together. The engineers who lead each technical area own their calculations, including the assumptions behind them, and they are responsible for telling the team early when a result threatens another area's work. In this project the most important interfaces are between neutronics and thermal hydraulics, which share the power distribution, and between thermal hydraulics and safety analysis, which share the temperatures and flows.

Teams also need someone who can say no to scope growth. In an open-ended project, the temptation is to keep adding features: a second reactor concept, a hydrogen plant, a research beam line. Each addition is interesting and each consumes weeks that the schedule does not have. Nikolai volunteers to be the scope keeper, which means any proposal to add work must come with an estimate of its effort and a suggestion of what will be dropped to make room.

The team charter

A team charter is a short written agreement, signed by all members, that sets out how the team will work. It is the cheapest risk control a team can adopt. Most student team failures are not technical; they come from unclear expectations, uneven workloads, missed meetings and disagreements that are left to fester. A charter does not prevent these problems, but it gives the team an agreed way to deal with them before they become personal.

Hana's team writes a one-page charter in its first week. It states the project objective in one sentence, lists each member's role, sets a weekly team meeting and a fortnightly meeting with the sponsor, defines how decisions are made, and says what happens when someone misses a deadline. Technical decisions are made by the area lead after consulting the reviewer, and recorded in a decision log with the reason and the alternatives considered. Decisions that affect more than one area, or that change a requirement, are made by the whole team by consensus, and if consensus cannot be reached within one meeting, by a vote with the advisor informed. The charter also commits the team to raising problems early: anyone who expects to miss a deadline tells the team as soon as they know, not on the day it falls due.

The charter includes two items that come from nuclear industry practice. The first is a questioning attitude: any team member may challenge any assumption or result, including those of the project manager and the advisor, and the challenge must be answered with evidence rather than authority. The second is conservative decision making: when the team is uncertain whether a design is safe, it assumes it is not until analysis shows otherwise. Both are elements of the safety culture that regulators expect of licensees, and Rohan tells the team that reviewers notice quickly whether a design team has them.

Scope and the work breakdown structure

The scope statement says what the project will and will not deliver. For Kestrel-10, the name the team gives its reactor, the scope is a conceptual design of a small reactor that supplies most of the campus space heating, carried to the level of detail needed to judge its feasibility, safety, licensing route and cost. The scope explicitly excludes detailed mechanical design, fuel fabrication, the design of the campus district heating network itself, and any work on fuel cycle facilities. The fuel is specified only as commercially available low-enriched uranium oxide of a stated enrichment; how it is produced is outside the project.

The work breakdown structure (WBS) divides the scope into deliverable pieces small enough to estimate and assign. Each element at the lowest level, called a work package, has an owner, an estimated effort, a start condition and a clear definition of done. The team's WBS has thirteen work packages, from the kickoff and team charter through requirements, concepts, the four technical analyses, licensing, cost, design review, report and presentation. The definition of done matters most: “neutronics complete” means a reviewed calculation package with stated assumptions and results that thermal hydraulics can use, not a spreadsheet that only Kofi understands.

Scheduling with the critical path method

Once work packages and their dependencies are known, the critical path method (CPM) finds the longest chain of dependent activities, which sets the shortest possible project duration. A forward pass through the network gives each activity its earliest start and earliest finish; a backward pass from the project end gives the latest start and latest finish that would not delay the project. The difference between latest and earliest start is the float. Activities with zero float are critical: any delay to them delays the whole project.

\[\mathrm{float} = \mathrm{LS} - \mathrm{ES} = \mathrm{LF} - \mathrm{EF}\]
Forward and backward passes for the thirteen work packages of the capstone, followed by a fast-tracked schedule in which report chapters are drafted as soon as the safety analysis ends.
# Critical path for the two-term capstone schedule (durations in weeks).
# Each task: (name, duration, list of predecessors)
tasks = {
    "A": ("Kickoff, team charter and work breakdown", 1, []),
    "B": ("Requirements and constraints document", 3, ["A"]),
    "C": ("Concept generation and screening", 3, ["B"]),
    "D": ("Concept selection and gate review", 1, ["C"]),
    "E": ("Neutronics design", 6, ["D"]),
    "F": ("Thermal hydraulic design", 6, ["D"]),
    "G": ("Shielding and radiation protection", 4, ["E"]),
    "H": ("Safety analysis", 5, ["E", "F"]),
    "I": ("Licensing strategy", 4, ["D"]),
    "J": ("Cost and schedule estimate", 3, ["F", "I"]),
    "K": ("Design review and close-out of actions", 2, ["G", "H", "J"]),
    "L": ("Final report", 4, ["K"]),
    "M": ("Final presentation and rehearsals", 2, ["L"]),
}
def cpm(tasks, show=True):
    order = list(tasks)                   # tasks are listed in a valid order
    ES, EF = {}, {}
    for t in order:                           # forward pass
        name, d, pre = tasks[t]
        ES[t] = max((EF[p] for p in pre), default=0)
        EF[t] = ES[t] + d
    end = max(EF.values())
    LS, LF = {}, {}
    for t in reversed(order):                 # backward pass
        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 not show: return max(EF.values())
    print(f"{'task':5s}{'activity':44s}{'ES':>4s}{'EF':>4s}{'LS':>4s}{'LF':>4s}{'float':>7s}")
    for t in order:
        fl = LS[t] - ES[t]
        print(f"{t:5s}{tasks[t][0]:44s}{ES[t]:4d}{EF[t]:4d}{LS[t]:4d}{LF[t]:4d}{fl:7d}{'  critical' if fl == 0 else ''}")
    crit = [t for t in order if LS[t] == ES[t]]
    print("project duration:", end, "weeks; critical tasks:", ", ".join(crit))
    print("teaching weeks available: 26; schedule reserve:", 26 - end, "weeks")
    return end

base = cpm(tasks)
# Fast-track: draft report chapters as soon as safety analysis ends, leaving one week of final edits after the review
fast = {k: v for k, v in tasks.items() if k != "M"}
fast["L"] = ("Draft report chapters", 3, ["H"])
fast["N"] = ("Final edits after design review", 1, ["K", "L"])
fast["M"] = ("Final presentation and rehearsals", 2, ["N"])
print()
cpm(fast)
Output
task activity                                      ES  EF  LS  LF  float
A    Kickoff, team charter and work breakdown       0   1   0   1      0  critical
B    Requirements and constraints document          1   4   1   4      0  critical
C    Concept generation and screening               4   7   4   7      0  critical
D    Concept selection and gate review              7   8   7   8      0  critical
E    Neutronics design                              8  14   8  14      0  critical
F    Thermal hydraulic design                       8  14   8  14      0  critical
G    Shielding and radiation protection            14  18  15  19      1
H    Safety analysis                               14  19  14  19      0  critical
I    Licensing strategy                             8  12  12  16      4
J    Cost and schedule estimate                    14  17  16  19      2
K    Design review and close-out of actions        19  21  19  21      0  critical
L    Final report                                  21  25  21  25      0  critical
M    Final presentation and rehearsals             25  27  25  27      0  critical
project duration: 27 weeks; critical tasks: A, B, C, D, E, F, H, K, L, M
teaching weeks available: 26; schedule reserve: -1 weeks

task activity                                      ES  EF  LS  LF  float
A    Kickoff, team charter and work breakdown       0   1   0   1      0  critical
B    Requirements and constraints document          1   4   1   4      0  critical
C    Concept generation and screening               4   7   4   7      0  critical
D    Concept selection and gate review              7   8   7   8      0  critical
E    Neutronics design                              8  14   8  14      0  critical
F    Thermal hydraulic design                       8  14   8  14      0  critical
G    Shielding and radiation protection            14  18  16  20      2
H    Safety analysis                               14  19  14  19      0  critical
I    Licensing strategy                             8  12  13  17      5
J    Cost and schedule estimate                    14  17  17  20      3
K    Design review and close-out of actions        19  21  20  22      1
L    Draft report chapters                         19  22  19  22      0  critical
N    Final edits after design review               22  23  22  23      0  critical
M    Final presentation and rehearsals             23  25  23  25      0  critical
project duration: 25 weeks; critical tasks: A, B, C, D, E, F, H, L, N, M
teaching weeks available: 26; schedule reserve: 1 weeks

The first schedule comes out at 27 weeks against 26 teaching weeks: the project is late before it starts. This is a normal result for a first schedule, and the response is to change the logic, not to wish the durations shorter. The team notices that the final report cannot start until the design review is complete, yet most chapters describe work that will be finished weeks earlier. By drafting chapters as soon as the safety analysis ends and leaving one week of final edits after the design review, the project shortens to 25 weeks with one week of reserve. The price is a risk: if the design review finds a serious problem, drafted chapters will need rework. The team accepts that risk and records it.

A bar chart of fourteen tasks against weeks 0 to 26. Critical tasks in red run in sequence: kickoff, requirements, concept generation, the concept selection gate, neutronics and thermal hydraulics in parallel from week 8 to 14, safety analysis to week 19, draft report chapters to week 22, final edits to week 23 and the presentation to week 25. Tasks with float are drawn as pale outlined bars: shielding, licensing strategy, cost and schedule, and the design review. Dashed lines mark the term break near week 13 and the end of the second term at week 26.
The fast-tracked capstone schedule. Neutronics, thermal hydraulics and safety analysis form the core of the critical path.

The schedule also shows where the team's capacity is stretched. Weeks 8 to 14 have Kofi and Mira on the critical path at the same time, with licensing work running in parallel. Sofia's shielding work has float but depends on Kofi's results, so a delay in neutronics would push both the safety analysis and the shielding. Hana marks the end of week 14 as a hard internal milestone: neutronics and thermal hydraulics must hand over reviewed results to safety analysis, and if either is late the team will meet to decide what to simplify rather than let the safety analysis absorb the delay.

Risk management from the start

A project risk register lists the events that could stop the team from meeting its objectives, with a likelihood, a consequence, an owner and a response. It is updated at every team meeting. Hana starts the register with the risks the team already knows about: a key calculation might not converge or might give implausible results; team members might be unavailable during examinations or co-op interviews; the sponsor's data on campus heat demand might arrive late; and the design might turn out to be uneconomic, which is not a failure of the project but would change the recommendation.

Risk responses come in four kinds: avoid the risk by changing the plan, reduce its likelihood or consequence, transfer it to someone better able to manage it, or accept it with a contingency. For the risk of late heat-demand data, the team reduces the consequence by building its own heat load model from climate data and building floor areas, to be replaced by metered data if it arrives. For the risk of unavailability during examinations, it accepts the risk and plans no critical-path work in the last week of each term. For the risk that the reactor proves uneconomic, it decides to treat the economics honestly from the start rather than tuning assumptions to reach a favorable answer.

Communication, records and meetings

Engineering projects are run on records. Every calculation the team performs will be documented in a calculation package with its purpose, inputs and their sources, method, assumptions, results and a reviewer's signature. Every decision will be entered in the decision log. Every requirement will have an identifier, such as R-05, that can be traced through the design to the analysis that shows it is met. The team keeps all of this in a shared repository with version control, so that the final report can cite the exact version of each calculation. This mirrors the quality assurance requirements that nuclear licensees must meet, scaled to a student project.

Meetings are short and structured. The weekly team meeting reviews the schedule, the open actions and the risk register, and then spends most of its time on the one or two technical issues that need the whole team. The fortnightly sponsor meeting is prepared in advance with a one-page status summary, and its purpose is to get decisions and information the team cannot get elsewhere. Grant Whitford attends the first sponsor meeting and gives the team the campus facts it needs: about forty buildings on a central heating network, natural gas boilers that are approaching the end of their life, and a campus commitment to cut its greenhouse gas emissions sharply over the next fifteen years.

Worked problem

Float and the cost of a delay

In the fast-tracked schedule, the licensing strategy (task I) has an earliest start of week 8, a duration of 4 weeks, and a latest finish of week 17. The cost and schedule estimate (task J) starts after both licensing and thermal hydraulics. Nikolai is ill for three weeks starting in week 10. Does this delay the project?

Show solution
  1. Task I earliest finish = 8 + 4 = 12. Latest finish = 17, so its float is 17 − 12 = 5 weeks.
  2. A three-week delay starting in week 10 moves the finish of task I to week 15.
  3. Task J needs both F (finishing week 14) and I (now week 15), so J starts in week 15 instead of 14 and finishes in week 18.
  4. Task J's latest finish is week 20, so J still finishes within its float, and the design review is not delayed.

Answer: No. The delay uses three of the five weeks of float in task I and one of the three weeks of float in task J, but the project end date is unchanged. Hana records the reduced float in the risk register.

Common mistakes

  • MistakeThe project manager should do the hardest technical work.

    InsteadThe project manager's job is integration, schedule and decisions; technical areas need their own leads.

  • MistakeA schedule that comes out late should have its durations cut.

    InsteadChange the logic, the scope or the resources; optimistic durations only hide the problem.

  • MistakeFloat belongs to whoever owns the task.

    InsteadFloat is shared along a path; using it on one task reduces it for those that follow.

  • MistakeRecords can be written up at the end.

    InsteadCalculations, decisions and assumptions are recorded as the work is done, so they can be reviewed and traced.

Summary and key terms

  • The capstone integrates the curriculum in an open-ended design with safety, licensing and economic constraints.
  • Every technical area needs a lead and an independent reviewer, and the project manager integrates rather than designs.
  • A team charter sets roles, meetings, decision rules and the handling of problems, and adopts a questioning attitude and conservative decision making.
  • The work breakdown structure divides scope into work packages with owners and definitions of done.
  • The critical path method finds the longest dependent chain; float shows where delays can be absorbed.
  • A risk register, a decision log and calculation packages are kept from the first week.
Capstone design project
A final-year design experience that integrates earlier courses in an open-ended problem.
Team charter
A short written agreement on roles, meetings, decisions and conduct.
Work breakdown structure
A hierarchical division of project scope into deliverable work packages.
Critical path
The longest chain of dependent activities, which sets the project duration.
Float
The time an activity can be delayed without delaying the project.
Risk register
A list of project risks with likelihood, consequence, owner and response.
Calculation package
A documented, reviewed record of an engineering calculation and its inputs and assumptions.

Practice problems

Work each problem on paper first, then reveal the answer to check.

  1. Why does each technical area need an independent reviewer?

    Show answer

    Independent checks find errors before they enter safety arguments and the final design.

  2. What is the difference between earliest start and latest start?

    Show answer

    Earliest start is the soonest an activity can begin; latest start is the last it can begin without delaying the project.

  3. How did the team shorten its schedule from 27 to 25 weeks?

    Show answer

    It changed the logic so report chapters are drafted after the safety analysis instead of after the design review.

  4. Name two elements of safety culture the team wrote into its charter.

    Show answer

    A questioning attitude and conservative decision making.

  5. What does a good definition of done for a work package include?

    Show answer

    A reviewed, documented result that the next work package can use, with stated assumptions.

Lesson quiz · 5 questions

Score 60% or more to complete this lesson.

Take the quiz