Project management for robotics teams

A capstone has a fixed end date, a small team with competing commitments and a mix of hardware and software work with very different rhythms. Hardware has long lead times and is expensive to change; software can change daily but hides integration problems. Project management is how a team keeps these moving together. This lesson covers planning a 13-week term with a work breakdown structure and critical path, choosing an agile, plan-driven or hybrid approach, tracking progress with velocity and earned value, managing risk and running the team's version control, continuous integration and documentation. PMP-120 covers leading people in depth and PMP-130 covers scheduling theory; here the focus is applying them to a robotics capstone.

Work breakdown structure

A work breakdown structure (WBS) divides the project into deliverables and then into work packages small enough to estimate and assign, typically between one and five days of effort for a capstone. The top level is often organized by subsystem and by project activity: mobility, power, manipulation, sensing and perception, navigation and software integration, safety, testing, and project management and documentation. Each work package has an owner, an estimate, dependencies and a definition of done. The WBS is the basis for the schedule, the budget and the task tracker, so it is worth building carefully in week 2, with the whole team, so that nothing falls between subsystems.

Estimates are where student teams go wrong most often. A widely used technique is three-point estimation: for each task, estimate the optimistic, most likely and pessimistic durations and combine them, for example with the PERT formula \( (O + 4M + P)/6 \). Asking for a pessimistic estimate forces people to think about what could go wrong. Hardware tasks should include ordering and shipping time; software tasks should include testing and integration; every task should include documentation. A rule of thumb from many capstones is that integration and testing take at least as long as building the subsystems.

Scheduling and the critical path

With work packages and dependencies, the team can build a schedule network. The critical path is the longest chain of dependent tasks from start to finish; any delay on it delays the whole project. Tasks off the critical path have float, or slack, and can slip without affecting the end date. Knowing the critical path tells the team where to focus attention and where to add people or buffer.

# Critical path for Tern's term plan (durations in weeks, illustrative)
tasks = {  # name: (duration, predecessors)
    "requirements":     (2.0, []),
    "concept + SRR":    (1.0, ["requirements"]),
    "order long-lead":  (0.5, ["concept + SRR"]),
    "parts delivery":   (2.5, ["order long-lead"]),
    "chassis build":    (1.0, ["parts delivery"]),
    "nav software sim": (3.0, ["concept + SRR"]),
    "detector training":(3.0, ["concept + SRR"]),
    "arm + gripper":    (3.0, ["parts delivery"]),
    "base integration": (1.5, ["chassis build", "nav software sim"]),
    "arm integration":  (1.0, ["base integration", "arm + gripper", "detector training"]),
    "system testing":   (2.0, ["arm integration"]),
    "final demo + report": (0.5, ["system testing"]),
}
es, ef = {}, {}
for t in tasks:                       # tasks are listed in dependency order
    d, pre = tasks[t]
    es[t] = max((ef[p] for p in pre), default=0.0); ef[t] = es[t] + d
end = max(ef.values())
lf, ls = {}, {}
for t in reversed(list(tasks)):
    succ = [s for s in tasks if t in tasks[s][1]]
    lf[t] = min((ls[s] for s in succ), default=end); ls[t] = lf[t] - tasks[t][0]
for t in tasks:
    fl = ls[t] - es[t]
    print(f"{t:20s} ES {es[t]:4.1f}  EF {ef[t]:4.1f}  float {fl:4.1f} {'CRITICAL' if fl < 1e-9 else ''}")
print(f"project length {end:.1f} weeks; buffer in a 13-week term: {13 - end:.1f} weeks")

requirements         ES  0.0  EF  2.0  float  0.0 CRITICAL
concept + SRR        ES  2.0  EF  3.0  float  0.0 CRITICAL
order long-lead      ES  3.0  EF  3.5  float  0.0 CRITICAL
parts delivery       ES  3.5  EF  6.0  float  0.0 CRITICAL
chassis build        ES  6.0  EF  7.0  float  0.5 
nav software sim     ES  3.0  EF  6.0  float  1.5 
detector training    ES  3.0  EF  6.0  float  3.0 
arm + gripper        ES  6.0  EF  9.0  float  0.0 CRITICAL
base integration     ES  7.0  EF  8.5  float  0.5 
arm integration      ES  9.0  EF 10.0  float  0.0 CRITICAL
system testing       ES 10.0  EF 12.0  float  0.0 CRITICAL
final demo + report  ES 12.0  EF 12.5  float  0.0 CRITICAL
project length 12.5 weeks; buffer in a 13-week term: 0.5 weeks

The critical path runs through requirements, concept selection, ordering, parts delivery, the arm and gripper, arm integration, system testing and the final deliverables. Two things stand out. First, parts delivery is on the critical path, so ordering long-lead items immediately after SRR, or even ordering low-risk items before SRR, directly shortens the project. Second, the plan fills 12.5 of 13 weeks, leaving only half a week of buffer, far too little for a project with this much uncertainty. Critical chain project management, an approach associated with Eliyahu Goldratt, recommends removing hidden padding from individual tasks and placing an explicit project buffer at the end, often a quarter to a half of the critical path length. Team Tern ordered the motors and the arm in week 2, before SRR, which removed about one and a half weeks from the critical path, and started detector training from a pretrained model to free effort for the arm. The plan came to about 11 weeks, leaving a two-week buffer before the demonstration.

Agile, plan-driven or hybrid?

Agile methods such as Scrum and Kanban, covered in PMP-140, work in short iterations, deliver working increments, and adapt the plan based on feedback. They suit software and uncertain requirements. Plan-driven methods define the scope, schedule and budget up front and control changes; they suit hardware with long lead times and fixed interfaces. Most robotics capstones use a hybrid: a plan-driven skeleton of milestones, reviews and long-lead orders, with agile sprints of one or two weeks for the detailed work within each phase.

Team Tern ran two-week sprints aligned with the reviews. Each sprint began with a planning meeting that picked work packages from the backlog, and ended with a demonstration to the advisor and a short retrospective on what to change. Hardware tasks appeared in the same backlog as software tasks, with ordering and fabrication lead times shown explicitly. The team used a Kanban board with columns for backlog, ready, in progress, review and done, and a work-in-progress limit of two tasks per person, which stopped people from starting many tasks and finishing none.

Tracking progress: velocity and earned value

Agile teams track velocity, the amount of work completed per sprint, often in story points or estimated hours. Velocity helps forecast how much of the remaining backlog will be finished by the end of term. Plan-driven teams track earned value, which compares planned value (the budgeted cost of work scheduled to date), earned value (the budgeted cost of work actually completed) and actual cost. From these come the schedule performance index \( SPI = EV/PV \) and the cost performance index \( CPI = EV/AC \). In a capstone, the "cost" is usually team hours rather than money, which makes earned value a useful, honest measure of whether the team is on track.

# Mid-term status: earned value in team-hours and velocity forecast (illustrative)
import numpy as np
bac = 650.0                                # budget at completion: planned team-hours for the term
pv, ev, ac = 350.0, 308.0, 385.0           # at week 7
spi, cpi = ev / pv, ev / ac
eac = bac / cpi                            # estimate at completion if current efficiency continues
print(f"SPI {spi:.2f}  CPI {cpi:.2f}  EAC {eac:.0f} h vs budget {bac:.0f} h")
weeks_left, hours_per_week = 6, 5 * 10.0   # five people, about 10 h each per week
capacity = weeks_left * hours_per_week
print(f"remaining work at current efficiency {(bac - ev) / cpi:.0f} h; remaining capacity {capacity:.0f} h")
velocity = np.array([42, 51, 38])           # story points per two-week sprint
remaining_points = {"must": 95, "should": 35, "could": 25}
sprints_left = 3
low, mean = velocity.min() * sprints_left, velocity.mean() * sprints_left
print(f"forecast points in 3 sprints: {low:.0f} (worst) to {mean:.0f} (average)")
done = 0
for k, v in remaining_points.items():
    done += v
    print(f"through {k:6s}: {done:3d} points -> {'fits' if done <= low else 'fits on average' if done <= mean else 'does not fit'}")

SPI 0.88  CPI 0.80  EAC 812 h vs budget 650 h
remaining work at current efficiency 428 h; remaining capacity 300 h
forecast points in 3 sprints: 114 (worst) to 131 (average)
through must  :  95 points -> fits
through should: 130 points -> fits on average
through could : 155 points -> does not fit

Both measures say the same thing. The team has completed less than planned (SPI below 1) and has spent more hours than the completed work was worth (CPI below 1). At the current efficiency, the remaining work needs more hours than the team realistically has. The velocity forecast confirms that the must-haves fit even in the worst case, the should-haves fit only if the team maintains its average pace, and the could-haves do not fit. The right response is not to work all night; it is to re-plan: protect the must-haves, decide which should-haves to attempt, formally move the could-haves to won't-have, and record the decision in the mid-term report. Examiners respect teams that measure honestly and re-scope early.

Risk management

A risk is an uncertain event that would affect the project if it happened. Teams keep a risk register listing each risk, its probability, its impact, the resulting score, an owner, a response and a trigger that shows the risk is becoming real. Responses are usually classified as avoid (change the plan so the risk cannot occur), mitigate (reduce probability or impact), transfer (pass the impact to someone else, for example through a supplier warranty) or accept (with a contingency plan). Lesson 9 shows how to quantify risk exposure and track it over the term. The important habits are reviewing the register at every weekly meeting, adding new risks as they appear and closing risks that have passed.

Version control, continuous integration and documentation

Every robotics capstone should keep software, firmware, configuration and, where practical, CAD and documentation in version control. ROB-110 lesson 4 introduced Git and ROB-360 lesson 7 covered continuous integration; the capstone is where these practices pay off under pressure. A simple, reliable workflow for a five-person team is trunk-based development with short-lived feature branches: each change is made on a branch, opened as a pull request, reviewed by at least one other member, checked automatically by continuous integration and merged into the main branch within a day or two. Long-lived branches that diverge for weeks are the source of most painful merges.

Continuous integration for a ROS 2 project typically builds the workspace with colcon, runs unit tests and linters, and runs a short simulation test that launches the robot in a simulated world and checks that it reaches a goal. Firmware can be compiled in CI even if it cannot be run there. The team should also tag releases at each review and each field test, so that every result can be tied to a code version, as lesson 4 explained. A protected main branch, which cannot be pushed to directly and requires passing checks, prevents a late-night change from breaking the demonstration build.

Documentation is part of the work, not an afterthought. A good capstone repository has a README that explains what the robot does and how to build and run it, an architecture document, the ICD, setup instructions for new members, test procedures and results, and decision records. Architecture decision records, short notes that capture a decision, the options considered and the reasons, are particularly valuable: when someone asks in week 11 why the team chose a 2D lidar over a depth camera for safety, the answer is already written down. Teams that document as they go find the final report much easier, as lesson 10 shows.

Many US universities provide capstone teams with project management and collaboration tools through institutional licenses, and some programs link capstone project management to ABET student outcomes on teamwork and planning. Check your program's expectations for meeting minutes, logs and individual time records.