AI Project Planner: Scope a Project Before Scheduling It

An AI project planner should help you decide what you can finish with the time you have. Give it an outcome, your starting point, available sessions, and a deadline. Ask for ordered milestones with checkable outputs. Before accepting the plan, check its total effort and the first dependency.

For a small project, that can be as simple as publishing one portfolio case study in six 45-minute sessions. A plan that spends all six sessions designing the site leaves no time to write the case study or test the link.

This guide uses an illustrative two-week project. The session lengths are a planning budget, not measured completion times. It assumes you already know basic HTML and CSS, have a working site repository, and can publish it without setting up a new hosting account.

Kognivu can turn your project goal and schedule into a path with daily quests. Review the proposed first quest against your existing files and available time before you start. You still need to check estimates and request changes when the scope or schedule changes.

Write the finish line before the task list

“Improve my portfolio” gives a planner too many directions. Use a finish line you can inspect:

Publish one case-study page about my existing weather app by the end of next Friday. Include the problem, my contribution, two screenshots, and links to the source and working demo. Use my existing site layout. A reader should be able to open it on a phone and follow both links.

Keep a separate list of work you are deliberately leaving out: a new site design, animations, another case study, and a custom domain. Those may be useful later. They do not belong in this project's first release.

A milestone should describe a change in the work: “case-study content ready” or “page published and checked.” “Work on portfolio” does not tell you whether the project is closer to done.

Give the planner a brief it can use

Copy this and replace the details with your own:

Outcome: one published weather-app case study on my existing portfolio.
Starting point: working app, repository, two usable screenshots,
existing site layout and a working publishing process.
Deadline: next Friday evening.
Capacity: Monday, Wednesday and Friday, 45 minutes each, for two weeks.
Total budget: 270 minutes.
Required sequence: inspect evidence -> outline -> build page ->
review content -> test on a phone -> publish and check links.
Out of scope: redesign, animations, another case study, new domain.

Return ordered tasks, a checkable output and a time budget for each.
Flag missing inputs and estimates that may exceed one session.
Do not invent results, users, metrics or facts about the app.

If screenshots are missing or the app is broken, change the brief. Collecting screenshots and fixing the demo consume time; they are not free prerequisites. The plan should reveal that work before it promises a publication date.

Check a six-session project plan

Six sessions at 45 minutes give you 270 minutes. Here is one possible allocation:

These allocations depend on the starting point. If placing the page takes two sessions, the original budget no longer fits. Cut an optional improvement or move the deadline; do not leave the overrun hidden in a 45-minute label.

For the first session, the task should point to work you can begin: open the existing app and site, then make the evidence list. You should not need another planning session to decide which project or repository to use.

Check dependencies before putting dates on tasks

A schedule can look orderly while its sequence is wrong. In this example:

• The draft depends on real app evidence. Write that before designing a new layout.
• The local page depends on a draft and screenshots. Empty placeholders are not a completed case study.
• Publication depends on a working publishing process. Confirm it in the starting point.
• The final check depends on the public URL. A local preview cannot prove the deployed links work.

Ask the planner what blocks each task. A tool can suggest a plausible dependency; you must verify it against the project. For a larger schedule, use the work-plan example to check the total available time before adding more milestones.

Remove a session and inspect the tradeoff

Suppose Week 2 Wednesday becomes unavailable after you finish the first three sessions. Your original 270-minute budget becomes 225 minutes: 135 completed and 90 remaining.

Give the planner this change:

Week 1 is complete. Week 2 Wednesday is unavailable. Keep Monday and Friday at 45 minutes each. Preserve the completed page. Remove optional styling refinements so Monday covers the content and phone-width checks; keep Friday for publication and public-link testing. Tell me if that still does not fit.

This proposed tradeoff drops polish, not the evidence or final link check. If required fixes take longer than the remaining 90 minutes, publish later or narrow the case study further. Moving all Wednesday's work onto Friday would create a 90-minute session you never agreed to.

Do not assume the software makes this adjustment automatically. Inspect its actual edit or recovery flow and confirm which changes it applies. Keep completed outputs so you can resume the project after a break without repeating the first week.

Which kind of planner fits this project?

Use the workflow you need to choose the tool:

A task list is enough when you already know the actions and their order. AI is useful here when it helps expose missing work or makes a scope tradeoff easier to inspect. Do not spend more time configuring the planner than you save on the project.

Try the project brief in Kognivu

Bring your existing project, finish line, deadline and working sessions. Inspect the generated roadmap and first quest. Check whether the first action uses what you already have, produces something useful, and fits the time you supplied.

Build a project path in Kognivu and check that first action before committing to the rest of the plan. Review the current preview and trial terms in the app before choosing paid access.