The project proposal: scope, risks and the client agreement

The proposal turns three weeks of discovery into a plan the client, the supervisor and the team all agree to. It is the most important document of the term because it fixes scope, and scope is what a student team controls least well. A good capstone proposal is short, usually eight to twelve pages, and answers six questions: what problem are we solving and for whom; what will we build, and what will we not build; how will we know it worked; how will we build it and when; what could go wrong; and who owns what at the end. It is written for a reader who is busy and not technical, which describes most clients and many supervisors.

CMPUT-401 covered MVPs, prioritization, roadmaps and client contracts in a product setting. Here the constraints are sharper. You have a fixed end date, about ten weeks of development, no budget, and a client who will be left with whatever you build. The proposal is where you protect both sides from over-promising. Clients rarely object to a small, well-defined scope if they understand why; they object strongly when a large promised scope quietly shrinks in week 11.

From problem to minimum viable product

The minimum viable product, or MVP, is the smallest version of the product that solves the core problem well enough for real users to use and for the team to learn from. It is not a prototype, which may be thrown away, and not a demo, which only has to look good. For Team Relay, the problem statement was about filling, swapping and confirming shifts and reducing coordinator effort. Features that serve that statement directly are candidates for the MVP; features that serve other themes from discovery, such as funder reports or allergen notes, are candidates for later.

To choose among candidates, the team scored each feature with RICE, a prioritization method covered in CMPUT-401: reach (how many people it affects in a period), impact (how much it helps each one), confidence (how sure the team is about the estimates) and effort (person-weeks to build). The score is reach times impact times confidence, divided by effort. The numbers are rough, and the method's value is that it forces the team to state its assumptions and argue about them, not that the score is precise. Team Relay then filled its development capacity in score order to see what the numbers suggested.

# Scoping the MVP with RICE: reach x impact x confidence / effort.
# Reach = people affected per month; impact on a 0.25-3 scale; confidence 0-1;
# effort in person-weeks of the team's time.
features = [
    # (feature, reach, impact, confidence, effort)
    ("Driver sign-up for open shifts",        140, 2.0, 0.9, 3.0),
    ("Shift confirmation and reminders",      140, 3.0, 0.8, 2.5),
    ("Driver-to-driver shift swap",            90, 2.0, 0.7, 2.5),
    ("Coordinator dashboard of unfilled shifts", 2, 3.0, 0.9, 2.0),
    ("Text message to store: who is coming",   35, 1.0, 0.6, 1.5),
    ("Monthly report for funders",              2, 2.0, 0.8, 1.5),
    ("Route optimization across pickups",      140, 1.0, 0.3, 6.0),
    ("Allergen and contents notes",            25, 1.0, 0.5, 1.0),
    ("Native mobile apps (iOS and Android)",   140, 0.5, 0.5, 8.0),
]
scored = sorted(((r * i * c / e, f, e) for f, r, i, c, e in features), reverse=True)
capacity = 12.0   # person-weeks the team can spend on features after setup, testing and docs
used = 0.0
print(f"{'RICE':>7}  {'effort':>6}  feature")
for score, f, e in scored:
    fits = used + e <= capacity
    if fits:
        used += e
    print(f"{score:7.1f}  {e:6.1f}  {f}{'   <- fits by score' if fits else ''}")
print(f"effort chosen by score alone: {used} of {capacity} person-weeks")

   RICE  effort  feature
  134.4     2.5  Shift confirmation and reminders   <- fits by score
   84.0     3.0  Driver sign-up for open shifts   <- fits by score
   50.4     2.5  Driver-to-driver shift swap   <- fits by score
   14.0     1.5  Text message to store: who is coming   <- fits by score
   12.5     1.0  Allergen and contents notes   <- fits by score
    7.0     6.0  Route optimization across pickups
    4.4     8.0  Native mobile apps (iOS and Android)
    2.7     2.0  Coordinator dashboard of unfilled shifts
    2.1     1.5  Monthly report for funders   <- fits by score
effort chosen by score alone: 12.0 of 12.0 person-weeks

The capacity figure deserves attention. Five students taking four other courses can typically give the capstone ten to twelve hours a week each, which is about 0.25 to 0.3 of a full-time week. Over ten weeks of development, that is roughly 13 to 15 person-weeks in total. A large share goes to work that is not features: setting up the repository, pipeline and environments, testing, documentation, client meetings, demos and the report. Team Relay estimated that only 12 person-weeks would be left for features, and planned the MVP against that, not against the optimistic total.

The output needs judgment, not obedience. Filling capacity strictly in score order puts shift swaps, texts to stores and allergen notes into the MVP and leaves out the coordinator dashboard, because RICE counts reach in people and only two people at the co-op coordinate. That is a known weakness of the method: it undervalues features used by a few people whose work the whole system depends on. The problem statement was explicitly about coordinator workload, so the team overrode the ranking. The final MVP was sign-up, confirmation and reminders, the coordinator dashboard and the funders' report; shift swaps and texts to stores became stretch goals, and allergen notes went to the later list. The team recorded the override and its reason in the proposal, which is exactly how a scoring method should be used.

Other results surprised the team too. Native mobile apps had looked essential, but their effort was large and their impact over a mobile-friendly web application was small, since drivers already used phone browsers. Route optimization had huge reach but low confidence, because nobody knew whether drivers wanted routes chosen for them. Writing down what is out of scope is as important as listing what is in: it gives the team a polite, pre-agreed answer when new ideas arrive mid-term.

Timeline and milestones

The proposal includes a timeline at the level of sprints, not days. For each sprint, name the goal and the features expected, and mark the fixed milestones: the design review in week 5, each sprint demo, the code freeze before the final week, and the final demonstration. Team Relay planned four sprints: sprint 1 for sign-up and the data model, sprint 2 for confirmation and reminders, sprint 3 for the coordinator dashboard and report, and sprint 4 for hardening, the pilot and stretch goals if time allowed. They put the riskiest work, reminders through an external messaging provider, in sprint 2 rather than at the end, so that a failure would leave time to switch to email.

Leave slack. A plan that uses every hour of every week will slip, because something always goes wrong: an illness, a library bug, a client who wants a change. Team Relay planned sprint 4 at half capacity on purpose. Their supervisor told them it was the best-calibrated plan she had seen that year, and in the event they used most of that slack on bugs found during the pilot. A capstone that finishes its MVP in sprint 3 and spends sprint 4 polishing and testing ends far better than one that finishes in a panic on the last day.

Risks

A risk register lists what could go wrong, how likely it is, how bad it would be and what you will do about it. Score each risk on likelihood and impact, typically on a scale of 1 to 5, and multiply for a priority. For the highest risks, write a mitigation: an action that makes the risk less likely or less damaging. Review the register at every sprint planning meeting, because risks change. Team Relay's top risk was not technical at all: it was that drivers would not adopt the tool. Their mitigation was to design mobile-first, involve drivers in prototype testing, and run a real pilot with Grace as the champion.

# Risk register: score = likelihood (1-5) x impact (1-5); review the top risks weekly.
risks = [
    ("Client contact unavailable for weeks", 2, 4, "Named backup contact; fortnightly fixed meeting"),
    ("Drivers do not adopt the tool",        3, 5, "Pilot with 30 drivers; mobile-first design; Grace champions it"),
    ("Hosting costs exceed co-op budget",    2, 4, "Estimate early; choose free or low-cost tier; document costs"),
    ("Team member leaves or falls ill",      2, 3, "Pairing, documented setup, no single owner of any module"),
    ("Scope creep from new client ideas",    4, 3, "Change process: new ideas go to backlog, trade against MVP"),
    ("Personal data of volunteers exposed",  2, 5, "Collect minimum data, access control, no PII in logs"),
    ("Integration with SMS provider slips",  3, 2, "Email reminders as fallback; SMS behind a feature flag"),
    ("Key library breaks on upgrade",        2, 2, "Pin versions; automated dependency checks"),
]
ranked = sorted(risks, key=lambda r: r[1] * r[2], reverse=True)
print(f"{'score':>5}  {'L':>1} {'I':>1}  risk")
for name, l, i, plan in ranked:
    band = "HIGH" if l * i >= 12 else "MED " if l * i >= 6 else "LOW "
    print(f"{l * i:5}  {l} {i}  {band} {name}")
print()
print("top three with mitigation:")
for name, l, i, plan in ranked[:3]:
    print(f"- {name}: {plan}")

score  L I  risk
   15  3 5  HIGH Drivers do not adopt the tool
   12  4 3  HIGH Scope creep from new client ideas
   10  2 5  MED  Personal data of volunteers exposed
    8  2 4  MED  Client contact unavailable for weeks
    8  2 4  MED  Hosting costs exceed co-op budget
    6  2 3  MED  Team member leaves or falls ill
    6  3 2  MED  Integration with SMS provider slips
    4  2 2  LOW  Key library breaks on upgrade

top three with mitigation:
- Drivers do not adopt the tool: Pilot with 30 drivers; mobile-first design; Grace champions it
- Scope creep from new client ideas: Change process: new ideas go to backlog, trade against MVP
- Personal data of volunteers exposed: Collect minimum data, access control, no PII in logs

The statement of work and the client agreement

The proposal becomes a lightweight contract when the client signs it, or a separate statement of work that summarizes it. This is not a legal contract with payment terms, but it records what both sides have agreed. It should include the scope (in and out), the deliverables and when they arrive, the client's commitments (meeting time, response times, access to data and a test group of users), how changes to scope will be handled, what happens at the end of term, and who owns the code and the data. Have the supervisor review it before the client signs: they have seen many projects go wrong and know which clauses matter.

Changes to scope are inevitable and healthy, as long as they are visible. Team Relay's agreement said that new ideas go into the backlog, and that adding something to the current term's scope means removing something of similar effort. When Grace asked in week 7 for volunteers to be able to log hours for their own records, Priya added it to the backlog, estimated it, and asked Grace whether it was more important than the funders' report. Grace chose to keep the report. Nobody was upset, because the rule had been agreed in week 3.

Intellectual property, licensing and data

Two ownership questions must be settled in the proposal: who owns the code, and who owns the data. Universities have different policies on student intellectual property. At many institutions students own what they create in a course unless they sign an agreement saying otherwise, and some clients ask students to assign copyright to them. Never sign anything about IP without checking your institution's policy and talking to your supervisor. A common, simple arrangement for community projects is to release the code under an open-source license, so the client can use, modify and hand it to future volunteers or contractors freely, and the students can show it in their portfolios.

Team Relay and the co-op chose the MIT license after the director said she wanted any future volunteer or local company to be able to improve the system without asking permission. Data is different: the co-op owns all data about its volunteers, donors and pickups, and the team may use only synthetic or anonymized data outside the project. The agreement said that at the end of term the team would delete any copies of real data, hand over the production database and admin accounts, and keep only the code and documentation in their portfolios.

Privacy law applies to how the co-op and the team handle personal information about volunteers, such as names, phone numbers and availability. The United States has no general federal privacy law for this kind of data. About twenty states have passed comprehensive consumer privacy laws, but most apply only to businesses above revenue or data-volume thresholds and many exempt non-profits; Wisconsin had privacy bills before its 2025-2026 legislature but, as far as we could confirm, no comprehensive privacy law in force. FERPA protects student education records and does not apply here unless school data is involved. For the co-op in Milwaukee, the practical standard is good practice: collect only what is needed, say why, protect it, and let people see and correct their own information. Text messages to volunteers must also respect consent rules for automated texts under the federal TCPA. Lesson 9 turns this into design decisions.

What a good proposal looks like

Supervisors see dozens of proposals and the good ones share features. They open with a one-paragraph summary a busy director can read in a minute. They state the problem with evidence from discovery and baseline numbers. They show scope as a clear in, stretch and out list rather than burying it in prose. They have a sprint-level timeline with slack, a risk register with mitigations, success metrics agreed with the client, and a section on what happens after the term. Weak proposals describe technology at length before the problem, promise everything the client mentioned, and say nothing about maintenance.

Worked examples