A project plan states the problem, who it is for, what the project must do, and when each part will be finished and tested. The goal is a plan short enough to use every week.
This lesson belongs to web and project development. Your school’s project brief sets the required scope, so read it first and plan inside it.
What goes in a one page plan?
Five short parts are enough: the problem, the user, the requirements, the milestones and the test plan. Each part should fit in a few lines.
Problem and user. One sentence each. “Students forget which library books are due back” and “Form 4 students at my school.”
Requirements. A numbered list of things the project must do. Each one must be testable.
Milestones. Dates by which each requirement is working, not started.
Test plan. For each requirement, one or two inputs and the result you expect.
Worked example: a fictional library return checker
This is a worked example. The project is a page where a student enters a book ID and sees whether it is overdue.
| No. | Requirement | Test input | Expected result |
|---|---|---|---|
| R1 | Accept a book ID of 4 digits | 1234 | Accepted |
| R2 | Reject an empty or short ID | blank, 12 | Message shown |
| R3 | Show “Overdue” when days late is above 0 | 3 days late | “Overdue” |
| R4 | Show “On time” otherwise | 0 days late | “On time” |
| R5 | Show the fine at RM0.20 per day late | 5 days late | RM1.00 |
Check R5: 5 × RM0.20 = RM1.00. Because each requirement has a test input and expected result, you can tick it off without arguing about whether it is “done”.
Milestones then attach to the table:
- Week 1: R1 and R2.
- Week 2: R3 and R4.
- Week 3: R5 and full testing.
- Week 4: polish, log and final check.
The mistake: planning the look, not the work
A common first plan lists colours, a logo and animations, with nothing testable underneath. By the deadline the page looks attractive and fails when a user types an unexpected value.
| Weak plan | Stronger plan |
|---|---|
| “Make a cool library page” | “Show whether a book is overdue from its ID” |
| “Add animations” | “Reject an empty ID with a message” |
| “Finish sometime in March” | “R1 and R2 working by 12 March” |
Appearance is worth adding only after the core requirements pass their tests. Treat it as a bonus that you drop first when time runs short.
How do I cut the scope?
Mark each requirement as must have or nice to have. If a week slips, remove the nice to have items, never the testing.
In the library example, R5, the fine, is the first to go. R1 to R4 already make a complete, testable project, and a recorded decision to drop R5 is better than a rushed R5 that breaks R3.
Check yourself
Your idea is a school canteen queue page. Write three testable requirements, each with a test input and an expected result.
Answer
One possible set:
- The page accepts a queue number from 1 to 99. Input 45 is accepted.
- The page rejects a number outside that range. Input 0 and 100 show an error message.
- The page shows “Your turn” when the entered number equals the number now being served. Input 12 with 12 being served shows “Your turn”.
Each has a clear input and an expected result, so each can be tested. Your own project will have different requirements, so build yours from your own brief.
What to study next
Plans need records and tests. Continue with testing interaction and data validation and documenting your own work on an assessed project.
To talk through your plan with a teacher, see online one-to-one Computer Science tuition.