Managing the Project Scope Flashcards
Project Scope
defines everything you need to do to complete a project
Gold Plating
making a component more than requirements
Defining scope in Agile vs Traditional
Agile- define scope as project goes on
Traditional- define scope before work
Scope Creep
scope changes without change being managed
Causes of scope Creep
unexpected scope related issues
perfectionism (going beyond what is required)
pleasing stakeholders (beyond initial scope)
Misunderstandings
Tools and Techniques for Collecting Requirements
Expert Judgement
Data Gathering- brainstorming, interviews, focus groups
Data Analysis- voting, mutli criteria analysis
Decision Making
Data Representation Techniques- affinity diagram, multicriteria analysis
Interpersonal and team skills
Context Diagrams
Protypes
4 types of voting
Unanimity
Majority
Plurality
Autocrasty
Nominal Group technique
team skill for collecting requirements
guide stakeholders in prioritizaion
let everyone have a say, anonymous, group activity but individual decision
Buy a Feature
stakeholders have _____
Requirements should be
clear, measurable, testable, traceable
Requirements Trackability Matrix
when, why, how, requirements changed
Tools and Techniques to define scope
Expert Judgement Data Analysis Decision Making Interpersonal and Team skills Product Analysis (ex: prod breakdown, system analysis)
Project Scope
object, deliverables
reference documents:
Project Charter- high level
Project Management Plan > Scope Mgmt Plan
Project scope based on
reference documents (project charter and scope mgmt plan)
Organizational process assets
Enterprise Environments
Questions for defining scope
What must exact specifications be to meet all requirements
What must exactly be done to deliver
Project Scope statment
4 components
Description- all attributes to meet requirements (ex: avail 98% of time)
Deliverables- what stakeholders can expect to receive (ex: reports, end product, approval)
Exclusions- what isn’t included (ex: video doesn’t include audio)
Acceptance Criteria- standards that are agreed to (verify scope, confirm completion and acceptance)
Work Breakdown Structure (WBS)
breaks work into manageable units Benefits: 1 helps define responsibilities 2 better control of project (monitor and control budget and facilitates accurate progress reports) 3 helps with scheduling 4 facilitates budget creation
Work Breakdown Structure format
multiple layers- usually 4-6 levels top- project name 2nd- broadest definitions, can be phase based or deliverable based (ex: planning, administration, tasks subtasks work packages
100% rule (WBS)
each level of WBS must add up to 100% of level above
Tools and Techniques to create Work Breakdown Structure
Expert Judgement
Decomposition
Pros and Cons of Decomposition
pro-
resources, costs, schedule estimates are easier
con-
over decomposition- goes too small, waste of time and overwhelming
Activities in Decomposition
1- Id deliverables- from scope statement
2- Structure and organize WBS- in scope mgmt
3- Decompose deliverable
4- Assign identification codes
5- Verify WBS- look at templates, use similar
8/80 rule
when decomposing requirements, aim to be between 8-80 hours for each deliverable
WBS Verfication
Expert judgement
- clear and complete
- 100% of work is represented at next level
- reasonable duration
- Id is logical
- Integration is included
- Project Management included (on second level)
- Contract work included (the deliverable, not org)
- matches business norms
WBS Finalization
ID components that need monitoring and establish control points at which you will use performance analysis to compare performance vs baseline
Control points
during finalization of WBS, they are added
at each control point- check performance
must be apporpriate level
WBS Dictionary
details that don’t fit in WBS
name and WBS component
position in WBS, who is responsible, requirement #, scope description (instructions to complete package), who prepared the form, date of sign off, schedule and cost estimate, milestones
Validation of Scope
confirm deliverables are accepted
- id the deliverables, are they meeting requirements?
- validate each deliverable internally before to stakeholders
- project isn’t complete until stakeholder accepts
Validation vs Control Quality
validation- all requirements are included and accepted
purpose- product meets requirement
who- PM and customer
review against- requirement documentation
vs
quality- deliverables are correct and meet quality requirements
purpose- id and eliminate poor quality
who- QA dept, PM and team
review against- predefined standards
Types of Scope Change
Managed- via change request, manage scope creep, only beneficial changes
Unmanaged change- not planned, scope creep or variance, negative impact to schedule/budget, halt until corrected
Variance Analysis
used in controlling scope, type of dat analysis
- id variance
- id cause
