The prompt
Score 10 of 10, Excellent
Use it when You have an agreed project scope and need it broken into deliverables and work packages that cover all the work, with an owner for each.
- {{project}}
- {{audience}}
- {{scope}}
- {{exclusions}}
- {{owners}}
- {{package_size}}
Full prompt and why it works
Prompt
# Role You help project managers break a project's scope into a work breakdown structure (WBS) that covers all of the work and nothing outside it. # Goal Build a WBS for {{project}} from the scope below, for {{audience}}, so that every piece of agreed work has a place, an owner and a clear finish, and the estimates and schedule can be built on it. # Material Scope statement, charter or statement of work: """ {{scope}} """ What is out of scope, if stated: {{exclusions}} Teams or roles who could own work: {{owners}} How small a work package should be for us (for example "one owner, two weeks of work or less"): {{package_size}} # Output 1. The WBS as an indented, numbered outline (1, 1.1, 1.1.1), at most four levels deep and 20 to 60 items in all, with project management as its own branch. 2. A table with the columns WBS ID, Name, Description, Done when, Owner (role). Names are deliverables or outcomes written as nouns ("Training materials"), not activities ("Write training materials"), because the schedule handles the activities. 3. Out of scope: a list, so the boundary is written down. 4. Questions: scope items that are vague, could sit under two branches, or seem to need work the statement does not mention. For example, one branch could read: "3 Data migration; 3.1 Data mapping; 3.2 Cleaned customer records; 3.3 Migration test report." That example shows the form only. # Rules - Follow the 100% rule: the children of each element add up to all of its work, with no overlap and nothing outside the scope. - Size work packages to our rule above, so each can be estimated and given to one owner. - Do not add deliverables the scope does not include; put anything that seems missing under Questions instead. - Do not put dates or sequence in the WBS. - A good WBS lets anyone point at a piece of work and say which element it belongs to and who owns it. # When the scope is unclear If part of the scope could be read two ways, show it once under Questions with both readings and leave [CHECK] in the outline instead of choosing. If no owners are given, leave Owner as "to assign".
Variables
- {{project}}
- The project, in a line, for example "moving the customer service team to a new phone system".
- {{audience}}
- Who will use the WBS, for example "the project team and the sponsor".
- {{scope}}
- The agreed scope statement, charter or statement of work, pasted in full.
- {{exclusions}}
- What is out of scope, if written down, or "not stated".
- {{owners}}
- Teams or roles who could own work packages, or "not yet known".
- {{package_size}}
- Your rule for the size of a work package, or "no rule".
Why it works
- What good looks like. The 100% rule, deliverable names as nouns and packages sized to your own rule are the tests a WBS is judged by, and the prompt states each one.
- What to avoid. No deliverables beyond the scope and no dates or sequence, so the WBS stays a map of the work and scope creep shows up as a question.
- If unsure. Scope that can be read two ways is shown with both readings and a [CHECK] mark instead of being settled by the model.