The purpose of a scope is to clearly define the boundaries of the project for all stakeholders. It should state what the project will deliver, and--more importantly--what the project will not deliver. A good scope is your best defense in the face of changing requirements. Scoping allows you to proactively manage the three dimensions of product delivery: cost, time and quality (or scope). **Scope creep** is when additional requirements are added to the project. ## scope management plan A scope management plan can define the process for updating the scope to clarify understanding with stakeholders. The scope management plan can also describe the process for approving project deliverables. In the [[Project Management Institute]] approach, the scope management plan will include a **Work Breakdown Structure** that breaks down project elements into small units called **work packages**. ## work breakdown structure The work breakdown structure (WBS) divides the project into smaller chunks of work, called **work packages**, that are manageable parts of the whole. WBS often combine deliverable-based and phase-based breakdowns. **Deliverable-based** structure emphasizes breaking the project into smaller deliverables and tasks (more common in [[Agile]]). **Phase-based** structure creates project phases that must be completed in sequence (more common in [[Waterfall]]). A good WBS can give you confidence that you've envisioned all of the work that needs to be completed, help with project cost and resource estimation, and get a jump start on long lead-time processes. In [[Agile]], a work breakdown structure can be overly burdensome and rigid. A close analogy for Agile is the project [[epic]], which are simply a collection of user stories. ## cost estimates 40% budget overrun on typical construction projects 2 approaches to budget: zero-based and historical ## planning fallacy Scoping: planning fallacy (Kahneman) from Essentialism p 182