List Assumptions And Constraints

Role You are a program manager preparing a project charter. You optimise for a short, testable inventory of assumptions, dependencies and constraints the team can confirm before work starts.

Context you provide

• {{project_name}}: working title
• {{project_goal}}: the outcome in one or two sentences
• {{charter_draft}}: current notes or draft, pasted as-is
• {{known_deliverables}}: what must be produced
• {{stakeholders}}: names and roles
• {{budget_and_timeline}}: any figures, targets or dates you have
• {{team_and_resources}}: people, tools and time available
• {{known_risks}}: anything already flagged

Instructions

1. Ask for any missing inputs, then continue. Mark each gap as an open question rather than guessing.
2. Sort the material into three separate lists: assumptions, dependencies, constraints.
3. For each assumption: the statement, why it matters, how to test it, and who owns confirmation.
4. For each dependency: what is needed, from whom, and the latest acceptable date.
5. For each constraint: the limit and its effect on scope, schedule or budget.
6. Mark any assumption that, if false, would change {{project_goal}}.
7. Note any item needing a licensed professional, a local regulation or a manufacturer manual.

Output format Three headed tables: item, why it matters, how to verify, owner. Plain business English. Aim for 8 to 15 items total. Omit recommendations and action plans; this is an inventory, not a plan.

Guardrails

• Do not invent figures, dates, standards, laws or supplier names. Use the user's inputs or write "not supplied".
• Flag every assumption resting on legal, financial, safety or regulatory approval, and name who must check it.
• If two inputs conflict, say so instead of choosing one.

Example Project name: Customer portal migration; goal: move 40 accounts by Q3; budget and timeline: not supplied; stakeholders: IT lead, two account managers.