Scope, Schedule & the WBS

The project charter is the document that formally authorizes a project to exist, names the project manager, and grants that person authority to apply organizational resources. Issued by the sponsor or initiating authority during the Initiating process group, it links the project to the organization’s strategic objectives and captures the business need, high-level scope, milestones, assumptions, constraints, and key stakeholders. A common exam trap is confusing it with the scope statement: the charter is high-level and sponsor-issued before detailed planning, while the scope statement is produced by the team during Planning. Without a charter, create one before proceeding.

The project scope statement is the primary output of the Define Scope process and documents the project’s deliverables, boundaries, constraints, assumptions, and acceptance criteria. It elaborates the high-level requirements from the charter into a precise description of what will, and will not, be produced. Unlike the charter, which authorizes the project and names the project manager, the scope statement defines the work in detail. It is the basis for the WBS, and approved changes flow through integrated change control, making it the reference point for evaluating scope creep.

The Work Breakdown Structure is a hierarchical, deliverable-oriented decomposition of all project work into progressively smaller components, ending in work packages at the lowest level. It is created during the Create WBS process and, together with the scope statement and WBS dictionary, forms the scope baseline. Each element represents a deliverable or outcome, not an activity. The WBS defines what must be delivered, while the schedule defines how and when. Per the 100% rule, work absent from the WBS is outside scope. The WBS dictionary holds detailed descriptions, acceptance criteria, and resource estimates.

A work package is the lowest level of the Work Breakdown Structure (WBS), a discrete unit of work that can be uniquely assigned, estimated, scheduled, and monitored. It is where scope, cost, and schedule are measured, making it the foundation of earned value tracking using metrics such as Planned Value (PV) and Actual Cost (AC). The critical exam distinction is between a work package and an activity: work packages define what must be produced, then are decomposed into schedule activities during the Define Activities process, which determine how the work is executed. Confusing the two levels causes scope-versus-schedule errors.

The critical path is the longest sequence of logically connected activities through a network, and it determines the project’s minimum completion date. It is identified by a forward pass (Early Start/Finish) and a backward pass (Late Start/Finish), then deriving total float per activity. Critical-path activities have zero total float, so any delay extends the project end date equally. A frequent exam trap confuses total with free float: free float is slip allowed without delaying an activity’s immediate successor, while total float measures slack against the overall deadline. Multiple critical paths of equal length can exist, and near-critical paths warrant monitoring too.

Float, or slack, measures schedule flexibility: how long an activity can be delayed without causing a downstream impact. Total float equals Late Start minus Early Start (or Late Finish minus Early Finish) and is the leeway before the project end date slips. Free float is narrower: how long an activity can slip before delaying any immediate successor. On the exam, free float is always less than or equal to total float for a given activity, and critical-path activities carry zero total float by definition. Watch near-critical paths, since small float erodes quickly.

The project schedule is an output of the Develop Schedule process, presenting linked start and finish dates for project activities and milestones. It is built by combining the activity list, sequencing logic, estimated durations, resource calendars, and project calendar constraints into a time-model. Exam questions test the distinction between the schedule model (the data and logic in the tool) and the schedule baseline (the approved version used for variance measurement). Compressing the schedule uses crashing—adding resources to critical-path activities at added cost—or fast tracking, which overlaps activities originally planned in sequence and introduces rework risk.

A milestone is a significant event in a project schedule that carries zero duration — it marks a moment in time rather than a span of work. Common examples include phase-gate approvals, completion of a key deliverable, or formal sign-off by a sponsor. The key exam distinction is between a milestone and a deliverable: a deliverable is a tangible output produced through work effort and therefore has duration, while a milestone simply marks when a noteworthy event occurs. On the PMP exam, watch for schedule-progress scenarios — milestones communicate status without implying effort or cost consumption, making them a useful reference point for executives and steering committees.

A deliverable is any unique, verifiable product, result, or capability that must be produced to complete a process, phase, or the project as a whole. Deliverables can be internal (a design document, a test plan) or external (software handed to a client), and they feed into the Validate Scope process, where the customer formally accepts them against documented acceptance criteria. The key exam distinction is deliverable versus milestone: a deliverable is a tangible output, while a milestone marks the completion of a significant event and has zero duration. Always ask whether the output is something produced or simply a point in time reached.