Project Integration and Scope Management
Project Integration and Scope Management
This domain tests whether you can unify plans and control change while defining exactly what the project will and will not deliver. Questions often target the charter, the project management plan, integrated change control, the WBS, and formal acceptance.
Core rules
- The charter authorizes the project and the project manager. It is not a detailed plan; the project management plan integrates subsidiary plans and baselines.
- The scope baseline is the approved scope statement, WBS, and WBS dictionary. Apply the 100% rule: the WBS contains all work required for scope and no unrelated work.
- Every change enters integrated change control: record the request, assess impact on scope, schedule, cost, quality, risk, and benefits, decide, then update baselines and communicate.
- Validate Scope obtains formal customer acceptance of completed deliverables. Control Quality checks correctness before acceptance.
Worked example
A customer asks for an extra report “while the team is in the area.” The project manager logs a change request and estimates 40 hours of development and testing, a two-week schedule slip, and a $6,000 cost increase. The change control board rejects it because the business case does not justify the delay. The manager records the decision in the change log and informs the customer. Reasoning: informal requests do not authorize a baseline change; the request must be assessed and decided through change control.
Traps that cost marks
- Treating Validate Scope as testing. It is acceptance, not defect detection.
- Adding small requests without change control, producing scope creep.
- Building the WBS around the organization chart instead of deliverables.
- Failing to update the scope baseline and WBS dictionary after an approved change.