Gains:
- Understand the concepts of scope statement and work breakdown structure (WBS) and use AI to produce a draft WBS divided into work packages
- Clarify out-of-scope items, deliveries and acceptance criteria with artificial intelligence support and see scope creep early
- Ability to understand that it is the project manager's responsibility to confirm the integrity, realism, and suitability of the WBS produced by artificial intelligence with the organizational context through team and stakeholder verification.
When you start a project with "what are we going to do?" Starting with this is like walking in the dark. Projects often fail not because they are poorly managed, but because they were defined incorrectly from the start. The subject of this unit is the two basic tools that outline the boundaries of the project and divide the work into manageable pieces: the scope statement and the work breakdown structure. When these two documents are set up correctly, schedule, forecast, risk and budget sit firmly on top of them; When set up incorrectly, everything shakes throughout the project. AI is a powerful drafting partner in both documents: it proposes a scope skeleton and a breakdown into work packages in minutes. But remember: AI produces a general pattern; Only you and your team know your organization's actual deliverables, constraints, and acceptance criteria.
What is a scope statement?
Scope is what the project includes and what it does not include. The scope statement is the document that puts it in writing and typically includes: the purpose of the project, key deliverables, acceptance criteria, out-of-scope items, assumptions, and constraints. The most critical and most neglected part here is the out of scope list: "We won't do X in this project" prevents the "but I thought that was included" argument later on.
When the scope gets out of control, it is called scope creep: small, unapproved work added to the project bloats it over time. "Just one more little addition", when repeated, blows up the budget and schedule. A good scope statement and clear acceptance criteria are the first line of defense against scope creep. Acceptance criteria are the measurable condition that a deliverable must meet to be considered "complete" (e.g. "form loads in less than 2 seconds").
Tip: When writing the scope statement, put as much effort into the "what we won't do" list as the "what we will do." Excluded items are the cheapest insurance for the project.
What is a work breakdown structure (WBS)?
Work breakdown structure (WBS) is a hierarchical tree that divides the total work of the project into logical pieces that gradually get smaller from top to bottom. At the top is the project, below it are the main deliverables/phases, and below them are the work packages. A work package is the lowest level piece of work that can be assigned to a person/team and is small enough to estimate its duration and cost. A good WBS follows two rules: the 100% rule (the sum of the lower parts includes the entire upper part, no more, no less) and mutual exclusivity (no two packages contain the same work, no overlap).
Why is WBS so important? Because forecasting, schedule, budget and risk are always done at the work package level. “We will make a website” is unpredictable; but packages such as "login page design", "user registration form", "payment integration testing" are predictable. WBS is also the framework for assigning responsibility (RACI), progress monitoring and communication.
Step by step: Generating WBS draft with AI
- Clarify the scope. Anonymously give the AI the project's purpose, key deliverables, and known constraints. A good WBS does not come from an unclear purpose.
- Ask for a draft breakdown. Ask AI for a hierarchy divided into phases and work packages; Ask for a one-line scope description and suggested delivery for each package.
- Test the 100% rule. Check whether the total of produced packages fully meets the scope; Mark the missing and unnecessary items.
- Add acceptance criteria. Require draft measurable acceptance criteria for each key deliverable, then refine them against reality.
- Clarify out of scope. Ask the AI for a list of “items that should probably be out of scope for this project” and discuss it with the team.
- Team and stakeholder validation. Review the draft with the work package owners. WBS is never a "plan" without team approval.
Caution: AI-generated WBS may often miss a critical package (e.g. “legal approval,” “data migration,” “user training”) that seems logical but is specific to your organization. The missing packet will make your prediction wrong from the beginning. Be sure to apply the 100% rule from a human perspective.
three mini cases
Case 1 — Time-saving blueprint. Instead of building WBS from scratch for a new intranet project, a PMO expert gave YZ the anonymous scope summary and asked for a draft. YZ proposed 6 phases and 34 work packages. The expert removed 5 packages and added 3 missing packages (SSO integration, accessibility testing, content migration) in a 45-minute workshop with the team. The work, which would have taken one day from scratch, was completed in half a day and became more complete.
Case 2 — Catching scope creep. A project manager gives AI 12 small requests from the customer and asks "are these in scope or out of scope according to the current scope statement?" He had it classified as: YZ 7 flagged the request as "possibly out of scope". PM turned these into official change requests; otherwise the additional 3 weeks of work would silently leak into the project.
Case 3 — Missing packet trap. A team approved 28 packages of WBS produced by YZ without verification. In the middle of the project, it was noticed that there were no "data migration" and "go-live rehearsal" packages; these two misses added 4 weeks to the schedule. Lesson: AI drafts should not be approved without human testing with the 100% rule.
Weak prompt / Strong prompt
Weak prompt:
Write WBS for a mobile application project.
This prompt is very general: AI typically produces a template, but has little relevance to your project's actual deliverables, constraints, and acceptance criteria.
Powerful prompt:
Your role: a senior project planning specialist.Context: An inventory tracking mobile application for a retail client (name masked).Constraints: 4 months, integration with existing ERP mandatory, iOS+Android, data migration available.Task: Produce a draft WBS divided into phases and work packages.Rules:- Observe the 100% rule; packages under each phase should fully cover the phase.- For each work package: single line scope + main deliverable + measurable acceptance criteria.- Give a separate "possibly OUT of scope" list at the end.- Mark institution-specific packages that you are not sure about with "[confirm with team]", fitting. Output: markdown table (Phase | Package | Scope | Delivery | Acceptance criteria).
This request is strong because the context, constraint, 100% rule, acceptance criteria, and out-of-scope request are clear; also enforces uncertainty with "[confirmation with team]".
Additional templates:
# Out of scope finderRead the scope statement below. List as "out-of-scope candidates" tasks that are common but not EXPRESSLY mentioned here (e.g. training, documentation, support, migration, security testing). For each, ask why it should be included/excluded.
# Acceptance criteria manufacturerSuggest 3-5 measurable acceptance criteria for the following delivery (in SMART format):[delivery]. Don't write criteria that can't be measured (like "it should work well").
# 100% rule checkerExamine the WBS below. Which deliverable from the scope statement does NOT have a counterpart in any workpack? Which packages EXCEED the scope statement? List the gaps.
Common mistakes
- Not writing out of scope: If "what we won't do" is unclear, scope creep is inevitable.
- Packages that are too large or too thin: A giant package that lasts a month is unpredictable; The tiny one-hour package overwhelms the management. Packages must be predictable and trackable.
- Approving the AI blueprint without validating it: An incomplete enterprise-specific package (data migration, regulatory approval, training) falsifies the plan from the start.
- Skipping acceptance criteria: If there is no criteria, the "done" discussion is endless.
- Not setting WBS focused on outputs rather than activities: Good WBS shows deliverables (names), not activities like "holding a meeting".
Tip: Don't write WBS once and leave it at that. When an approved change arrives, update the WBS, then the schedule and budget. WBS is a living document.
In summary
The scope statement defines the boundaries of the project, while the WBS defines the manageable parts of the work. A good scope statement includes clear acceptance criteria and a strong “out of scope” list; A good WBS follows the 100% rule and mutual exclusivity. AI produces fast and complete blueprints for both, but can skip institution-specific packages. It is up to the project manager to apply the 100% rule from a human perspective, clarify out-of-scope, and obtain team validation.
Application task
For a current project of yours, produce a draft WBS from AI divided into phases and work packages (anonymize data). Then, with a member of your team, apply the 100% rule: which packages are missing, which are unnecessary, which delivery has no acceptance criteria? Correct at least 3 missing/incorrect points and save the corrected WBS.
checklist
- [ ] My scope statement has purpose, deliverable, acceptance criteria, out-of-scope, assumption and constraint.
- [ ] I filled in the "out of scope" list on purpose.
- [ ] WBS follows the 100% rule (no missing/excess packets).
- [ ] Each work package is predictable and traceable.
- [ ] Every important deliverable has measurable acceptance criteria.
- [ ] I verified the AI draft with the team; I added institution-specific packages.