A plan is a set of commitments about people's time. State the hours available before asking for the plan.
Do now: Write your real weekly capacity in hours, then plan within it.
Every task needs a person's name, not a role.AI produces excellent-looking plans instantly, and excellent-looking plans that ignore capacity are worse than no plan, because they generate confidence and then collapse.
Constraints before tasks
State the real numbers first: who is available, how many hours each per week, what money exists, what is already committed, and what the hard deadline is. A model given no constraints will produce a plan for an organisation you do not have.
Include the constraints people are embarrassed to state. One person is only free on weekends. Nobody can travel in the rainy season. The person who approves things is unreachable for two weeks in December. These are the things that actually determine whether a plan survives.
Then ask for the smallest plan that reaches the goal, and separately for what would be cut first if capacity halved. That second list is enormously useful and almost nobody asks for it.
A plan that does not name hours is a wish list with dates attached.
Owners, dependencies, and the critical path
Every task gets one person's name. Not a team, not a role. Shared ownership reliably produces unowned tasks, and the plan will not tell you which ones until the deadline.
Dependencies are where plans actually fail. Ask what cannot start until something else finishes, then ask which single delay would push the end date. That chain is the critical path, and it is where your attention belongs — most people spend it on whichever task is most visible instead.
Ask what must be true for the plan to work, and you will surface assumptions nobody had stated: that a permit arrives, that a supplier delivers, that someone stays in the role. Those assumptions are your risk register, written in plain language.
Define the failure signal
Decide in advance what tells you the plan is not working, and when you will check. 'If we have not completed the pilot by the end of week four, we replan' is a signal. 'We will monitor progress' is not, and it is how projects run to the deadline before anyone admits difficulty.
Build in a review point that is allowed to conclude 'stop'. Plans without a stop condition tend to be completed rather than evaluated, which is how organisations finish things nobody needed.
Keep the plan short enough to be read weekly. A document nobody opens after the kickoff is not a plan; it is a record of a meeting.
A review point that cannot conclude 'stop' is not a review point.