<aside>
</aside>
<aside>
A lightweight Notion prototype for helping small teams forecast future workload, schedule pressure, and resource allocation before tasks become delayed or overloaded.
</aside>
This prototype is a Notion-based scheduling and workload forecasting tool.
Rather than being a fully featured commercial product, it serves as a proof of concept that explores whether a Notion database can connect projects, tasks, task allocations, estimated effort, team capacity, and future workload into a practical planning system.
<aside>
The prototype consists of five primary databases and one integrated dashboard:
<aside>
The current version relies on manual data maintenance, including assignees, execution periods, estimated hours, task status, and progress. As a result, the accuracy of the dashboard depends heavily on the quality of the input data.
It also does not currently support features such as automatic scheduling, task dependencies, critical path analysis, resource leveling, holiday-aware scheduling, or integrations with external project management platforms.
This prototype is not intended to replace platforms like Jira, Trello, Asana, ClickUp, or Monday.com.
It is neither a complete task management system nor an enterprise-grade scheduling engine.
Instead, it is best described as a PM Planning Console :
A lightweight workspace that helps project managers quickly evaluate whether a project schedule is realistically achievable before execution begins.
</aside>
<aside>
The core purpose of this prototype is workload forecasting, not task tracking.
Based on each task allocation's execution period, estimated effort, progress, status, and assigned member, the system estimates every team member's workload over the next 7, 14, and 30 days.
This allows project managers to identify potential risks before execution begins:
Rather than asking,
"Have all the tasks been created?"
the prototype asks,
"Is this schedule actually realistic?"
</aside>
<aside>
The prototype separates work into two levels:
This distinction reflects how real projects operate.
A project's workload isn't created by the parent task itself—it's created by the individual responsibilities assigned underneath it.
For example, a single "Login UX Design" task may include:
Viewing only the parent task hides the true workload distribution. Breaking it into task allocations provides much better visibility into how work is actually shared across the team.
</aside>
<aside>
</aside>
<aside>
</aside>
<aside>
</aside>
<aside>
</aside>