EC-15.1 Choosing a Capstone and Writing the Proposal

What this is and why it exists

Choosing badly is the commonest way a capstone goes wrong, and it happens in the first fortnight when nobody is paying attention.

This topic is about that fortnight.

The test it keeps returning to is whether the project has a demonstrable result. A project that ends with an explanation of what was attempted cannot be assessed. It does not satisfy anyone, least of all the person who did it.

The vocabulary

• Scope — how much the project undertakes to do.
• Demonstrable result — something you can show that someone else can judge.
• Prior art — what already exists that solves or partly solves the problem.
• Milestone — a dated, checkable point of progress.
• Feasibility — whether this can be done by these people in this time.
• Proposal — the document a supervisor agrees to or pushes back on.

The mental model

Start with size, because everything else follows from it. Estimate the work, double the estimate, and then check that it fits alongside the other commitments of those weeks.

Doubling is not pessimism. It accounts for the parts you have not thought of yet, and the historical record of every project ever planned suggests it is still optimistic. A project sized to fit is not a modest project; it is the only kind that finishes.

Then state what the project will demonstrate, before it starts. The result should be something you can show and someone else can judge.

A project whose stated outcome is a better understanding of the area has no way to succeed or fail. It therefore has no way to guide a decision six weeks in. Every choice you make later needs a criterion, and the demonstrable result is that criterion.

Now a point that surprises people. A capstone does not have to be new to the world.

Rebuilding something known, properly, with measurements and evidence, is a legitimate project and usually a better one than an original idea half attempted. Novelty is not a requirement, and treating it as one is why so many capstones are ambitious in week one and abandoned in week eight.

The prior art check belongs in the first fortnight and takes about an hour. Search for what already exists, read two or three of the best results, and note what they did and did not do.

That hour changes most proposals for the better. It also prevents the discovery, in the final week, that the problem was solved and published in 2011. Nobody recovers from that gracefully.

The plan should use dates rather than durations, and milestones that are demonstrable rather than proportions complete.

Ninety per cent done is an assertion nobody can check. A working sensor interface by the eleventh of October is not. Milestones of the second kind let you and your supervisor see a slip while there is still time to respond to it.

Finally the proposal document. Six things: the problem, why it matters, what will be built, how it will be judged, the plan, and the risks.

A supervisor reads it to answer two questions. Is this feasible? And is it assessable? Both should be visible on the first page, and a proposal that buries them under background is a proposal that gets a vague answer.

What you should now be able to explain or do

• Size a project against the time actually available, including other commitments.
• State a demonstrable result and use it as the criterion for later decisions.
• Explain why novelty is not required and what a good rebuild project looks like.
• Do a prior art check early enough for it to change the proposal.
• Write a plan with dates and demonstrable milestones.
• Write a proposal that answers feasibility and assessability on the first page.

Check yourself