T.E.L.O.S. Feasibility

At levels 7–10 of C1-1, feasibility stops being a formality and starts earning marks. A brief that just lists "Technical: yes, we can do it" scores in the 3–4 band. One that names a specific constraint and argues your project clears it — or flags where it doesn't — is what the higher bands look like.

mindmap
  root((Feasibility))
    Technical
      Can you build it with named tools?
    Economic
      What does it cost — time, licences, hosting?
    Legal
      Does it respect copyright, privacy, data rules?
    Operational
      Will real users actually adopt it?
    Scheduling
      Can an MVP ship in the available weeks?

What T.E.L.O.S. means

Each letter is an angle for testing whether your project is actually achievable. You don't need all five — address at least three, and choose the ones with real stakes for your project.

Technical

Can you build what you're proposing with the languages and tools you've named? Point to specific evidence: a library that handles the hard part, hardware that's already available, or a known workaround for a likely obstacle.

Example: "Python's sqlite3 module handles local data storage without a separate database server. NiceGUI runs as a local web app, so no school firewall changes are needed."

Economic

What does the project cost? Developer time (yours) counts even if you're not charging. No paid licences doesn't automatically mean zero cost — name any ongoing costs like hosting.

Example: "Development cost is my own time, which is part of the SAT workload. Python and NiceGUI are open source with no licence fees. Cloud hosting on Hetzner VPS would cost approximately $5–10 AUD/month if required, which is within the client's budget."

Legal

Is the project legal? Does it comply with copyright (for any assets you use), and with privacy law if the software collects or stores user data? For most student projects in Victoria, the relevant instruments are the Privacy Act 1988 (Cwlth) and the Privacy and Data Protection Act 2014 (Vic) — but only if you're handling personal information.

Example: "The system stores student quiz responses. These are personal data under the Privacy Act 1988. Data will be stored in JSON files on a controlled local server with no third-party access. No student names are required — responses are identified by session only."

If your project handles no personal data and uses only freely licensed assets, say so explicitly — that is your legal feasibility statement.

Operational

Will the people you've identified as users actually use it? Consider training time, technical confidence, and whether the system fits the workflow it's meant to support.

Example: "The teacher (primary user) manages the system independently via a web dashboard. First-run configuration takes approximately 10 minutes; no ongoing technical skill is required. Students access quizzes through a browser — no installation needed on student devices."

Scheduling

Can you deliver a working version in the time you have? An MVP scope, a rough week-by-week breakdown, and an honest note about what gets cut if time runs short is more credible than "yes, it fits in the semester."

Example: "Weeks 1–2: data model and core quiz logic. Weeks 3–5: user interface and session management. Weeks 6–8: flashcard mode and testing. Weeks 9–10: refinement and documentation. If time is short, flashcard mode is deferred to a post-MVP iteration."

How to write it in your brief

Don't list — argue. For each angle you address, name the specific constraint your project faces, then state whether your project clears it and why. A sentence like "Python is free so my project is economically feasible" is generic — it applies to every student's project and earns nothing. A sentence like "No paid licences are required; the only potential cost is $5–10/month cloud hosting, which the client has agreed to fund" names a real constraint and resolves it. See the feasibility section of C011-Draft-Design-Brief and the NiceQuiz brief for worked examples at brief length.

Common mistakes

"Python is free so my project is economically feasible" — too generic. Name something specific: a licence you don't need, a cost that does exist, or a budget figure the client confirmed.
Listing T.E.L.O.S. without addressing it — a heading followed by three words scores nothing. Each angle needs a named constraint and a resolution.
Ignoring legal — even student projects have privacy implications if they collect user data. If yours doesn't, say so. If it does, name the relevant law and how you'll comply.
Treating scheduling as one sentence — "It fits in the semester" is not a schedule. Give a rough week-by-week breakdown and name what's in scope for the MVP.

Further viewing

Types of Feasibility Study — Legal, Economic, Technical, Operational, Scheduling — covers all five T.E.L.O.S. angles (verify runtime before sharing in class)