Capstone projectsMiddleLesson 3316 min read

Plan it in one page

A one-page plan names the problem, the users, the data, how you will measure success, the risks and the timeline. It keeps a group focused and makes the project easy to explain.

Lesson in motion

In 60 seconds

Plan it in one page

A one-page plan names the problem, the users, the data, how you will measure success, the risks and the timeline. It keeps a group focused and makes the project easy to explain.

1/4
In simple words
Before a cricket match, the captain decides who bats first, who bowls, and what score the team is aiming for. It fits on one small card. Nobody writes a book. A one-page plan is that card for your project.
A plan does not need to be long. It needs to be clear. If you cannot fit your plan on one page, the project is probably still too big. A good one-page plan answers six questions.
PartQuestion it answersWeak exampleBetter example
ProblemWhat goes wrong today, for whom, and how often?"People need information.""Parents call the school office many times a week to ask about fees and holiday dates."
UsersWho exactly will use it, and where?"Everyone.""Parents of Class 6–8 students, on their phones, mostly in Hindi."
DataWhat information does it need, where does it come from, and are you allowed to use it?"From the internet.""The school's public notices, shared by the office with permission."
Success measureOne number you will measure, with a target"It should work well.""8 out of 10 test questions answered correctly with the right notice cited."
RisksWhat could go wrong, and what will you do about it?"None.""It may give an old date: show the notice date with every answer."
TimelineWhat will be done by when?"Finish soon.""Days 1–3 content, days 4–8 build, days 9–12 test, days 13–14 fix and share."

Choosing a success measure

Pick a measure you can actually count during the project. Good measures are about the user's task, not about how clever the model is. For a FAQ bot: "questions answered correctly with the right source". For a scam checker: "scams caught" and "normal messages wrongly flagged". Write the target before you build, so you cannot quietly move it later.

Writing down risks

Every project has risks. Writing them down is a sign of good work, not weakness. For each risk, write one thing you will do about it.
  • Wrong answers: answer only from trusted content, show the source, say "not found" when unsure.
  • Privacy: collect as little personal data as possible; use made-up data while building.
  • Misuse: think how someone could use the tool to hurt others, and block that.
  • Over-trust: tell users clearly what the tool cannot do and who to ask instead.
  • Running out of time: decide early what you will drop if you fall behind.

A two-week timeline

  1. 1

    Days 1–2

    Talk to users. Collect content you are allowed to use. Finish the one-page plan.
  2. 2

    Days 3–7

    Build the smallest working version. Test it yourself on 10–20 questions or examples.
  3. 3

    Days 8–11

    Small pilot with a few real people, with their consent. Collect feedback.
  4. 4

    Days 12–13

    Fix the biggest problems. Measure again with the same test set.
  5. 5

    Day 14

    Write the README with honest limits, record a short demo, share.
Note
Add a line called "Not doing". List the features you decided to leave out, like voice input or a second language. This stops the project from growing every day.
Real example
A Class 11 group in Guwahati planned a bot for their school's sports day questions. Their first plan said "answer all questions". After writing the success measure, they changed it to "answer 15 real questions from last year's sports day, with the right notice". That one change told them exactly what content to collect and what to test.
Try this. Explain your project to a friend in one breath: "It helps who do what, using which data, and we will know it works if number." If you cannot, your plan needs work.

Watch and read more

Lab

Your one-page project plan, written as a Python dictionary and checked for missing or vague parts.

~25 min

The problem

  1. Run the starter. The review function shows which parts of PLAN are still empty.
  2. Replace every TODO with your own project. Write short, specific sentences (at least eight words for problem, users, data and success measure).
  3. Your success_measure must include a number, such as a target like "8 out of 10".
  4. Say where the data comes from and whether you may use it (for example: public, your own, made-up, or shared with permission).
  5. Give at least two risks, each with what you will do about it, at least three timeline steps, and at least one item in not_doing.

Practice lab

Edit the code and run it. Python runs in your browser — nothing is sent to our server.

Output

No output. Add print(...) to see values.

You are done when

Hard questions

Try to answer before you reveal. If you can answer these, you understood the lesson.

Q1Your group's success measure is "users are happy". How would you turn it into something you can count?Reveal

Pick an action or a result you can observe. For example: "In a pilot with 8 parents, at least 6 find the answer to their question without calling the office", or "average rating of 4 or more out of 5 from at least 8 testers". Say who, how many, what counts as success, and the target, before you build.

Q2A teammate says the risks section makes the project look bad to judges. How do you answer?Reveal

A clear risk list shows that you understand your project and care about users. Every real system has risks. Judges, teachers and employers trust work more when the team names the risks and shows what they did about them. Hiding risks is what looks bad when they appear later.

Please sign in to continue.

Questions people ask

Is one page really enough?

For a two-week project, yes. You can keep extra notes elsewhere. The one page is for decisions: anyone in the group, or a teacher, should understand the project from it in two minutes.

What if we miss our success target?

That is still a result. Report the real number honestly, explain what you learned, and say what you would change. An honest "6 out of 10, and here is why" teaches more than a vague "it works well".

Can the plan change?

Yes, but change it on purpose. Update the page, write the date and the reason. Do not let the plan drift quietly.

Who should see the plan?

Everyone in the group, your teacher or mentor, and ideally one of your users. A user can tell you quickly if the problem or the success measure is wrong.

Lesson test

5 questions. Get 3 right (60%) to pass and complete this lesson.

Sign in to take the test and save your progress