HKSM

A project scope statement is the approved description of what the project will and will not deliver, including major deliverables, acceptance criteria, assumptions, and constraints. It aligns stakeholders on boundaries and guides planning, estimation, validation, and change control.

Key Points

• Defines what is in and out of scope, the major deliverables, and how acceptance will be verified.
• Captures assumptions, constraints, and high-level boundaries to prevent scope creep.
• Becomes part of the scope baseline along with the WBS and WBS dictionary.
• Supports planning, estimating, quality criteria, and stakeholder alignment.
• Developed collaboratively and approved; any change afterward follows formal change control.
• Should trace back to requirements so nothing important is omitted or added unintentionally.

Purpose of Analysis

• Clarify the product and project boundaries so teams and stakeholders share the same expectations.
• Identify gaps, overlaps, or conflicts in requirements before work begins.
• Make acceptance criteria measurable and testable to enable effective validation.
• Surface constraints and assumptions that affect scope, schedule, and cost.
• Provide a stable reference for estimating, procurement, and risk analysis.

Method Steps

• Review business objectives and the project charter to understand the purpose and success criteria.
• Analyze approved requirements and group them into clear deliverables and outcomes.
• Define in-scope work, out-of-scope items, and key boundaries using specific, measurable language.
• Document acceptance criteria for each major deliverable and overall project completion.
• Record assumptions and constraints that influence what can be delivered.
• Socialize the draft with key stakeholders to validate completeness and clarity.
• Refine the statement based on feedback and align it with the initial WBS structure.
• Seek formal approval and baseline the scope; manage future changes through change control.

Inputs Needed

• Project charter and business case or product vision.
• Requirements documentation and a requirements traceability structure.
• Stakeholder register and stakeholder engagement information.
• Assumption log and known constraints (policies, contracts, standards).
• Risk register entries that may impact scope choices.
• Organizational process assets, lessons learned, and templates.

Outputs Produced

• Approved project scope statement with inclusions, exclusions, acceptance criteria, assumptions, and constraints.
• Updates to requirements attributes and traceability to align with defined deliverables.
• Refinements to the WBS and WBS dictionary as part of the scope baseline.
• Updates to the assumption log and risk register based on scope decisions.
• Change requests if new or altered scope is discovered during analysis.

Interpretation Tips

• Check that acceptance criteria are objective and testable, not subjective or vague.
• Verify exclusions are explicit to reduce misunderstandings and hidden scope.
• Ensure each deliverable maps to approved requirements; resolve any orphan or extra items.
• Confirm assumptions and constraints are realistic and reflected in plans and estimates.
• Look for consistency across related documents (charter, WBS, contracts, and schedule).

Example

A team defining a scope statement for an internal reporting initiative writes:

• In scope: design and implement a standard dashboard with 10 KPIs; train users; migrate 12 months of historical data.
• Out of scope: custom reports beyond the 10 KPIs; mobile app development; external data integrations.
• Acceptance criteria: dashboard loads within 3 seconds for 95% of users; KPI values match source system within 0.5% variance; user training completed for 100% of target roles.
• Assumptions: source system access is available weekdays; subject matter experts provide definitions by agreed dates.
• Constraints: budget capped at $250k; go-live must occur before end of Q3.

Pitfalls

• Using vague wording (e.g., user-friendly, fast, minimal) that cannot be verified.
• Omitting explicit exclusions, inviting uncontrolled scope growth.
• Locking in a specific solution too early instead of defining outcomes and criteria.
• Not involving key stakeholders, leading to rework and disputes.
• Failing to align with requirements or the WBS, causing gaps or overlaps.
• Not updating the statement after approved changes, making it obsolete.

PMP Example Question

While reviewing a baselined project scope statement, a stakeholder asks to add a new deliverable that was not included. What should the project manager do next?

1. Update the scope statement and inform the team to start the new work.
2. Revise the WBS to include the new deliverable without changing the baseline.
3. Submit a change request and analyze the impact before any updates are made.
4. Add the item to the assumptions log and proceed with current plans.

Correct Answer: C — Submit a change request and analyze the impact before any updates are made.

Explanation: Once scope is baselined, additions must follow integrated change control. The change is evaluated for impacts on schedule, cost, risk, and quality before approval and updates.