A day-based classical project planner with milestones, resource leveling and a separate CPM reference.
In this article
Project Planner Guide: Tasks, Milestones, Resources and Baseline Changes
This guide walks a fictional engineering project through Project Planner: requirements, design review, integration, verification and handover. The goal is a plan you can inspect and save, not an automatically approved project schedule. Start from the synthetic example so every input is harmless and easy to check.
Step 1: Define scope and the shared calendar
Enter a project name and a short purpose or scope statement. Choose the start date and the calendar window, then select working weekdays. Add holidays one YYYY-MM-DD date per line. Calendar days include weekends; the scheduler builds its working-day list from those settings.
This is one shared day calendar without timezone conversion. Task duration means working days at the selected resource demand, not hours of effort distributed among several people. The present model does not support half-day allocations, separate individual shifts or multiple project portfolios.
Step 2: Represent real constraints as resources
Add a shared resource for anything whose limited availability should affect dates: an engineer role, a bench, an integration facility or a device pool. Capacity is the number of concurrent reservations the resource supports. Resource unavailable intervals use inclusive start and end dates.
An owner is a descriptive responsibility label. To constrain that person's schedule, also select a resource representing that availability on the relevant tasks. Otherwise the scheduler can legitimately overlap activities assigned to the same owner label, because labels alone do not consume capacity.
Step 3: Build the work breakdown
Expand an activity to edit its ID, title, phase, owner, type, duration, status, progress, priority, dependencies and notes. Use Design, Integration, Test and Handover as lifecycle groupings; a phase label does not create an implicit dependency. Add explicit finish-to-start links where an activity truly waits for another.
For example, Design package depends on Requirements baseline. Design review is a milestone depending on Design package. Build and integrate and Prepare test procedures can both depend on the review. Verification depends on both of those branches, and Handover follows closure work. Use acceptance criteria in notes to explain what “finished” means.
A milestone has zero duration and no resource reservations. A normal task needs a positive whole working-day duration. Unique IDs and acyclic dependencies are required. Duplicating a task makes a new activity; it is not an execution rerun with inherited approval.
Step 4: Add target dates, risks and status
Not before prevents an early start. Due target requests a desired finish; a forecast that misses it produces a warning. These dates are planning inputs, not imported obligations verified by the tool.
Track risks separately with a title, owner, severity and mitigation or next action. A risk entry does not automatically change a task duration. To explore a delay, change the relevant scheduling input and recalculate. Similarly, progress is self-reported: marking a task done sets its progress to 100%, but the forecast still schedules full scope from project start rather than reconstructing actual execution.
Mark an unresolved activity blocked when it should not receive a forecast. Descendants also remain unscheduled; independent tasks can still have dates. This deliberately prevents a reassuring overall completion date when unresolved work has no credible release condition.
Step 5: Calculate and inspect both models
Press Calculate project plan or Ctrl/Command+Enter. Review the complete or partial forecast message, project-finish summary, milestones, unscheduled count, Gantt chart and detailed table. Check resource workload and due warnings, not only the final date.
Open Precedence-only critical path reference to inspect slack and critical activities in that separate dependency model. Its day positions are reference working-day indices. It ignores resource capacity, status and due targets. Do not present it as the critical path of the resource-leveled schedule without an additional analysis.
Step 6: Capture a comparison and test a change
Capture comparison baseline after a calculation. Increase an integration duration or add a resource outage, then calculate again. Inspect the changed start and finish dates for activities present under the same IDs in both plans. The comparison is not a complete history of renamed, added or removed activities.
Use Find a task and the phase filter to edit a long work breakdown efficiently. Clear filters before concluding an activity is missing. Filtering only affects the editor view, not the scheduling inputs. The status board is another view of the entered status, not a separate system of record.
Step 7: Save, export and reopen
Save project file downloads JSON containing inputs and an explicitly captured baseline. Ctrl/Command+S triggers the same local file download. Export schedule CSV creates a result table; Download project report produces a Markdown summary with activities and risks. Print / PDF uses the browser's print controls.
The workspace does not automatically persist in browser storage or synchronize with a team. Reloading unsaved content loses it, and replacing unsaved input asks for confirmation. Reopen a saved JSON file and calculate again to verify it. Keep versioned filenames outside the app if you need a manual history. For a deeper explanation of the model choices, read the Project Planner overview.