This Scope Management Plan Software Development document shows how Eduardo Montes defined the processes for planning, defining, validating, and controlling the scope of the ProjectAdm SaaS platform across 28 sprints and five milestone gates. It establishes how scope is defined (user story mapping + WBS), how the scope baseline is maintained, how scope validation is performed at each milestone, and how scope changes are controlled — creating the framework that enabled ProjectAdm to process four change requests without any scope creep incidents.

What Is a Scope Management Plan?

A Scope Management Plan is a component of the Project Management Plan in PMBOK 8's Planning Performance Domain. It describes how the project scope will be defined, developed, monitored, controlled, and validated. It establishes the process for creating the WBS, how the scope baseline will be maintained, how changes to scope will be processed, and the criteria for scope acceptance. The Scope Management Plan does not define the scope itself — that is the role of the Project Scope Statement and WBS. Instead, it defines the rules by which scope is governed throughout the project lifecycle.

What This Scope Management Plan Software Development Includes

The ProjectAdm Scope Management Plan establishes the complete scope governance process:

• Scope Definition Process — Product scope: defined via user story mapping workshop (Henry Douglas as PO, 2-day session January 16–17, 2025); WBS: 12 packages defined by Eduardo Montes with input from all team members; WBS Dictionary: one entry per package defining deliverables, acceptance criteria, and responsible team member
• WBS Creation Method — Decomposition approach: deliverable-oriented; top level: ProjectAdm SaaS Platform; level 2: 12 work packages; level 3: sprint stories within each package (managed in Notion backlog); WBS and WBS Dictionary completed by end of Sprint 2 (February 11, 2025)
• Scope Validation Process — Sprint validation: Henry Douglas reviews and accepts completed stories in biweekly sprint review; milestone validation: formal acceptance against Deliverables Acceptance Checklist signed by Henry Douglas; rejected deliverables re-enter backlog with refined acceptance criteria
• Scope Control Process — Any request outside the approved scope baseline triggers a Change Request; CCB (Eduardo Montes + Henry Douglas) evaluates within 5 business days; $5,000 threshold for cost impact requiring CCB review; 4 CRs processed in 13.5 months (CR-001 through CR-004)
• Scope Creep Prevention — Sprint planning: only approved backlog items are sprint candidates; stakeholder requests: formal change request required regardless of perceived size; informal verbal commitments explicitly prohibited; team trained on this rule at kickoff workshop
• Scope Exclusions Management — Exclusions list maintained in Project Scope Statement; 2 exclusion challenges received (native iOS app Sprint 10; offline mode Sprint 18) — both resolved by reference to Scope Statement within 24 hours, no formal CR required
• Scope Performance Reporting — Sprint completion percentage in biweekly Status Report; scope variance tracked in Change Requests Log; milestone scope acceptance documented in Deliverables Acceptance Checklist; final: 0 scope creep incidents, 4 approved changes, 100% baseline deliverables accepted

How Eduardo Montes Used This Scope Management Plan Software Development

The Scope Management Plan Software Development prohibition on informal verbal commitments proved its value in Sprint 16 when a stakeholder casually mentioned a Slack integration during a sprint review. Eduardo Montes responded that any such feature would require a formal change request — the stakeholder decided it wasn't a priority and did not submit a CR. Without this explicit rule in the plan, the Slack integration might have been informally committed to and later caused a scope dispute that would have been far more expensive to resolve than the 30-second conversation that prevented it.

How to Use This Scope Management Plan Software Development Document

When writing your own Scope Management Plan Software Development document, be explicit about what constitutes a scope change versus a clarification, and communicate the prohibition on informal verbal commitments to stakeholders at kickoff. These rules need to be known before disputes arise — not retrieved from a document when they do.

Download the Template and Deepen Your Knowledge

Ready to create your own scope management plan? Download the blank Scope Management Plan Template (PMBOK 8).

• Download the Scope Management Plan Template — PMBOK 8 (blank, ready to use)
• Read the full guide: Scope Management Plan in PMBOK 8

Want to go deeper? The PMBOK Guide 8th Edition is the definitive reference for modern project management. Get your copy and use it alongside these examples to build a solid, practical understanding of every performance domain.

Format: Microsoft Word (.docx) | Project: Software Development (SaaS Platform) | PMBOK Edition: 8th (2025) | Domain: Planning