IT4306 · IT Project Management · Level II Sem 4

Topic 5: Project Scope Management

University Q&A Practice — 10 Key Questions with Diagrams

Reference: Managing IT Projects — Kathy Schwalbe, 9th Edition
PROGRESS
0 / 10 revealed
How to use: Click each question card to reveal the answer. Diagrams are included where they help visualise key concepts. Based on UCSC BIT lecture slides and the Schwalbe textbook.
01
What is Project Scope Management? Define "scope" and "deliverable" and list all five main processes.
Core Concept
+
▶ Answer

Scope refers to all the work involved in creating the products of the project and the processes used to create them.

Project Scope Management includes all processes involved in defining and controlling what is or is not included in a project — ensuring all required work and only the required work is done.

A Deliverable is any product produced as part of a project: hardware, software, planning documents, training manuals, or even meeting minutes.

▸ The 5 Processes of Project Scope Management (in order)
01Scope Planning
›
02Scope Definition
›
03Create the WBS
›
04Scope Verification
›
05Scope Control
Core purpose: ensure the project includes all the work required — and only the work required — to complete it successfully.
02
What is a Scope Management Plan? What are its key inputs and what information does it typically contain?
Scope Planning
+
▶ Answer

A Scope Management Plan is a document describing how the team will prepare the scope statement, create the WBS, verify deliverable completion, and control scope change requests.

It is a subsidiary part of the overall Project Management Plan.
▸ Scope Management Plan: Inputs → Plan → Contents
INPUTS • Project Charter • Preliminary Scope Statement • Project Management Plan SUBSIDIARY PLAN Scope Management Plan CONTENTS • How to define the scope • How to get formal acceptance • How to control scope changes

As time progresses, scope should become clearer and more specific — from vague charter language to a fully detailed scope statement.

03
What is a Requirements Management Plan and a Requirements Traceability Matrix (RTM)? What are the consequences of poor requirements management?
Requirements
+
▶ Answer

A Requirements Management Plan documents how project requirements will be analyzed, documented, and managed — including how to plan/track/report requirements, prioritize them, and perform configuration management.

A Requirements Traceability Matrix (RTM) maintains the linkage from each requirement's source through decomposition, implementation, and validation.

▸ Sample Requirements Traceability Matrix (RTM)
Req. No.NameCategorySourceDesign ImpactTest CaseStatus
R32Laptop MemoryHardwareProject Charter & Corp. SpecsServer config updateTC-014Complete
R45User LoginSoftwareUser Requirements DocAuth module designTC-022In Progress
R61Data BackupOperationsRisk Management PlanBackup schedulerTC-031Pending
Consequences of poor requirements management: missing requirements, misunderstandings, uncontrolled feature creep, and costly rework.
04
What is a WBS? Define decomposition and show the two main ways a WBS can be organized, with examples.
WBS
+
▶ Answer

A Work Breakdown Structure (WBS) is a deliverable-oriented grouping of the work involved in a project that defines the total scope. It is the foundation document for planning schedules, costs, resources, and changes.

Decomposition is the process of subdividing major deliverables into smaller, more manageable work packages.

▸ WBS Organized by Product — Intranet Example
Intranet
 
Web Site Design
 
Site Map
Graphic Design
Programs
Home Page Design
 
Text
Images
Hyperlinks
Marketing Pages
 
Text
Images
Hyperlinks
Sales Pages
 
Text
Images
Hyperlinks
▸ WBS Organized by Phase — Tabular Form with PMI Numbering
Level1.0 Intranet Project
Level 1 1.1 Concept 1.2 Web Site Design 1.3 Web Site Development 1.4 Roll Out 1.5 Support
Level 2 1.1.1 Evaluate Current Systems
1.1.2 Define Requirements
1.1.3 Define Functionality
1.1.4 Define Risks
1.1.5 Develop Project Plan
1.1.6 Brief Dev. Team		 Design activities Development activities Rollout activities Support activities
Level 3 1.1.2.1 Define User Req.
1.1.2.2 Define Content Req.
1.1.2.3 Define System Req.
1.1.2.4 Define Server Owner Req.		 (Further sub-tasks at Level 3 and below…)
A WBS can be a chart (tree diagram), tabular form with PMI numbering, or displayed in MS Project as a Gantt chart.
05
Describe all five approaches for developing a WBS. Which approach is best suited to which situation?
WBS Approaches
+
▶ Answer
▸ Five WBS Development Approaches at a Glance
⬇️
Top-Down
Start with biggest items, break into finer detail. Best for PMs with strong technical insight & big-picture view.
⬆️
Bottom-Up
Team identifies specific tasks first, then rolls up into summary activities. Very thorough but time-consuming.
📋
Analogy
Review WBSs from similar past projects and tailor to current project. Saves time using proven structures.
📏
Guidelines
Use organizational or industry standards (e.g., DOD). MS Project includes built-in WBS templates.
🧠
Mind Mapping
Visual non-linear brainstorming. Unlocks creativity, boosts participation & morale. Works with top-down or bottom-up.
▸ Mind Mapping Approach — Sample IT Upgrade WBS
IT Upgrade Project Project Management Upgrade Inventory Building A/B/C Install H/W & Software Acquire H/W & Software Servers / Laptops User Training & Support
Mind mapping is best when project scope is not yet well understood — it encourages free thinking before imposing formal structure.
06
What is Scope Verification (Validation)? How does it differ from Scope Control, and why is it difficult in IT projects?
Scope Verification
+
▶ Answer
▸ Scope Verification vs. Scope Control — Side-by-Side
Aspect✅ Scope Verification🔄 Scope Control
DefinitionFormal acceptance of completed deliverablesManaging changes to project scope
TimingAt deliverable completion pointsContinuously throughout the project
MethodCustomer inspection + formal sign-offChange control procedures + variance tracking
GoalEnsure deliverables meet requirementsPrevent unauthorized scope expansion
OutputAccepted deliverablesApproved / rejected change requests

Why is scope verification difficult in IT projects?

  • Very difficult to write a precise scope statement and WBS from the start.
  • Many IT projects suffer from scope creep.
  • Notable failures: FoxMeyer Drug (bankruptcy due to scope creep on robotic warehouse); Grumman engineers refused to use a system; 21st Century Insurance Group wasted resources on a project that could have used off-the-shelf components.
07
What is scope creep? What are the goals of Scope Control and how is "variance" defined in this context?
Scope Control
+
▶ Answer

Scope Creep is the tendency for project scope to keep growing over time without proper authorization or control. It is one of the most damaging problems in IT project management.

▸ Scope Creep — Uncontrolled Growth of Project Scope Over Time
📌 Planned Scope
Original Baseline
⚠️ Mid-Project
+ Added Features & Requests
🚨 Near Delivery
+ More Requests → Over budget & late!
Without control, each addition expands scope, inflating time and cost well beyond the original plan.

Goals of Scope Control:

  • Influence factors that cause scope changes (proactive prevention).
  • Ensure changes are processed via integrated change control procedures.
  • Manage actual changes when they occur.
Variance = the difference between planned and actual performance. Tracking variance helps detect scope creep and deviations early before they escalate.
08
How does scope definition evolve from the Project Charter through to the final Project Scope Statement? Illustrate with an example.
Scope Definition
+
▶ Answer

Scope Definition is the process of progressively adding more detail to the scope as requirements develop and change requests are approved. This is called Rolling Wave Planning.

▸ Progressive Elaboration of Scope (IT Upgrade Project — Servers Example)
Stage 1 · Initiating
📄 Project Charter
"Upgrades may affect servers…"

— Very vague, high level
→
Stage 2 · Planning
📋 Preliminary Scope Statement
"If additional servers are required, they must be compatible with existing servers. A detailed description must be submitted to the CIO for approval at least two weeks before installation…"
→
Stage 3 · Executing
✅ Project Scope Statement v1
"This project will require purchasing 10 new servers: Web, network, database, application, and printing. Two of each type will be purchased and dedicated to this project. Full specs in Appendix 8."
Progressive elaboration ensures all stakeholders share a common understanding of what the project will and will not include — significantly reducing disputes and rework.
09
What suggestions are recommended for improving user input? Why is user involvement critical for scope management?
User Input
+
▶ Answer

Many IT project failures stem from poor user involvement. Effective user input prevents scope issues and ensures deliverables meet actual business needs.

▸ Six Strategies for Improving User Input
Improve User Input Good Project Selection Sponsors from user org Users on Project Team Requirements, UI design, planning Sign-off on Deliverables Formal acceptance points Regular Meetings With defined agendas Regular Delivery Something useful each cycle Don't Over-Promise Honest commitments only
Unlike reality TV renovation shows (where homeowners sign away their right to complain), IT project sponsors cannot simply accept whatever is delivered — genuine stakeholder engagement throughout is essential.
10
What considerations apply to Scope Management in Agile/Adaptive environments? How do they differ from traditional approaches?
Agile / Adaptive
+
▶ Answer

In Agile/Adaptive environments, scope management must be more flexible and iterative, because requirements evolve throughout the project rather than being fixed upfront.

▸ Traditional vs. Agile Scope Management — Comparison

🏗️ Traditional (Predictive/Waterfall)

  • Scope fixed upfront before work begins
  • Changes discouraged / need formal approval
  • Full requirements documented at start
  • Single testing phase near project end
  • Scope baseline tightly controlled
  • Changes viewed as risks / deviations

🔄 Agile / Adaptive

  • Scope evolves iteratively across sprints
  • Changes expected and planned for
  • Requirements updated continuously
  • Testing throughout the lifecycle
  • Dedicated resources for change requests
  • Completion dates guide iteration focus
▸ Key Agile Scope Techniques
Prototyping Early user feedback Use Case Modeling JAD Sessions Joint App. Design Requirements Mgmt. Database Written, current, traceable
Key difference: traditional scope management fixes scope upfront; agile embraces and controls change through iterative planning, continuous stakeholder involvement, and regular delivery.