The simplest way to manage projects and tasks in one system

If you're looking for the simplest way to manage projects and tasks in one system, you're probably dealing with one of two problems: either tasks exist without context (nobody knows which outcome they serve), or projects exist without execution (nice plans that never translate into daily work).

The solution is a two-layer model — Projects for outcomes, Tasks for actions — connected by one relation and driven by one weekly review.

Why most project-task systems fail

The typical failure isn't structural. It's behavioral. People create projects for everything (a project for "fix the logo" next to a project for "launch the new product line"), or they skip projects entirely and live in an endless task list where priorities are invisible.

The fix is a clear threshold: a project exists when work needs coordination. If it involves multiple tasks, multiple people, or spans more than a week — it's a project. Everything else is a standalone task.

This single rule eliminates 80% of the mess.

The Projects database: outcomes, not activities

A project is an outcome with an owner and a finish line. It answers: what are we delivering, and who is accountable?

Keep properties ruthlessly lean:

• Status — Planned / Active / On hold / Done (4 options, not 12)
• Owner — one person, not a team
• Priority — High / Medium / Low (or Impact × Effort if your team can handle it)
• Target date — when it should be done
• Type — Client / Internal / Product Development (for filtering views)

Properties that sound useful but rarely get maintained:

• % complete (nobody updates this honestly)
• Multiple date ranges (start, end, revised end — just use one target)
• Tags (unless you actively filter by them weekly)

The test: if a property doesn't change a decision during weekly review, it's noise.

The Tasks database: actions, not documentation

A task is the smallest unit of work that moves a project forward. It should be completable in a single work session (1–4 hours). If it takes longer, it's either poorly scoped or it's actually a project.

Core properties:

• Status — To do / Doing / Done
• Assignee — who is doing this
• Due date — hard deadline (not aspirational)
• Project — relation, limit 1 (one task serves one project)

Optional but useful:

• Tags — only if you use them for view filtering (Design, Development, Admin)
• Blocked by — self-relation for dependencies (use sparingly)

The critical constraint: WIP limits

The single biggest improvement you can make to a task system is limiting work in progress. A person with 15 "Doing" tasks has zero "Doing" tasks — they have 15 things they're context-switching between.

Set a rule: maximum 3 tasks in "Doing" per person. If something new becomes urgent, something else moves back to "To do." This forces prioritization at the point of execution, not just at the planning stage.

Three views that run weekly execution

1. "This week" (Tasks)

Filter: Status ≠ Done, Due date within 7 days

Group by: Assignee (teams) or Project (solo)

This is the view you open Monday morning. If it's empty, your team doesn't know what to work on. If it has 50 items per person, your planning is aspirational, not operational.

2. "Active projects" (Projects)

Filter: Status = Active

Show: Owner, Target date, Priority

Sort: Priority descending

This view answers: what are we actually working on right now? If a project has been "Active" for 3 months with no task movement, it's not active — it's abandoned. Archive it or restart it.

3. "Project tasks" (inside each project page)

A linked view filtered to: Project = this project, Status ≠ Done

This gives the project owner a clear picture: what's left, who's doing it, what's overdue.

The weekly review: 20 minutes that prevent decay

Without a weekly review, every task system turns into a graveyard of good intentions.

1. Close what's done. Mark completed tasks. Archive completed projects.
2. Kill what's dead. If a task has been untouched for 3+ weeks, it's not happening. Delete or rescope.
3. Confirm the top 3. What are the 3 most important projects this week? Does each have tasks assigned and due?
4. Check WIP. Is anyone carrying more than 3 "Doing" tasks? If yes, what moves back?

This review is the difference between a system that reflects reality and one that reflects what you hoped would happen two months ago.

When to break the rules

Some tasks genuinely don't belong to a project — recurring admin, one-off requests, maintenance. That's fine. Create a standing "Operations" project as a catch-all, or let those tasks float unlinked.

The system should serve execution, not bureaucracy. If linking a 5-minute task to a project creates more overhead than value, skip it.

If you want a project and task system that reflects what's actually happening — not what was planned three months ago — book a call to see how UniFrame structures this.

‍