PROJECT SCOPE MANAGEMENT

PROJECT SCOPE MANAGEMENT

• 5.1 COLLECT REQUIREMENTS
• 5.2 DEFINE SCOPE
• 5.3 CREATE WBS (WORK BREAKDOWN STRUCTURE)
• 5.4 VERIFY SCOPE
• 5.5 CONTROL SCOPE
 PROJECT SCOPE VS. PRODUCT SCOPE

• PROJECT SCOPE
• THE WORK THAT HAS TO BE PERFORMED TO DELIVER THE
PRODUCT OF THE PROJECT WITH THE SPECIFIED FEATURES AND
FUNCTIONS.

• PRODUCT SCOPE
• FEATURES AND FUNCTIONS THE CHARACTERIZE THE PRODUCT
OF THE PROJECT.

• A DELIVERABLE IS A PRODUCT PRODUCED AS PART OF A

PROJECT, SUCH AS FACILITY, HARDWARE OR SOFTWARE,
PLANNING DOCUMENTS…
 PROJECT SCOPE

• SETS THE LOGICAL BOUNDARIES OF THE PROJECT

• DEFINES WHAT THE PROJECT IS AND WHAT IT IS NOT.
• CONCERNED WITH DEFINING AND CONTROLLING WHAT IS
AND WHAT IS NOT INCLUDED IN THE PROJECTS
• PREVENTS EXTRA WORK OR GOLD PLATING

• PROJECT SCOPE MANAGEMENT INCLUDES THE PROCESSES

INVOLVED IN DEFINING AND CONTROLLING WHAT IS OR IS
NOT INCLUDED IN A PROJECT.
 PROJECT SCOPE MANAGEMENT PROCESSES

• COLLECT REQUIREMENTS: THE PROCESS OF DEFINING AND DOCUMENTING

STAKEHOLDER’S NEEDS TO MEET THE PROJECT OBJECTIVES.
• SCOPE DEFINITION: THE PROCESS OF DEVELOPING A DETAILED DESCRIPTION OF
THE PROJECT AND PRODUCT
• CREATING THE WBS: SUBDIVIDING THE MAJOR PROJECT DELIVERABLES INTO
SMALLER, MORE MANAGEABLE COMPONENTS.
• SCOPE VERIFICATION: FORMALIZING ACCEPTANCE OF THE PROJECT SCOPE.
• SCOPE CONTROL: CONTROLLING CHANGES TO PROJECT SCOPE.
 SCOPE PLANNING AND THE SCOPE
MANAGEMENT PLAN
• THE SCOPE MANAGEMENT PLAN IS A DOCUMENT THAT INCLUDES
DESCRIPTIONS OF HOW THE TEAM WILL PREPARE THE PROJECT SCOPE
STATEMENT, CREATE THE WBS, VERIFY COMPLETION OF THE PROJECT
DELIVERABLES, AND CONTROL REQUESTS FOR CHANGES TO THE PROJECT
SCOPE.

• KEY INPUTS INCLUDE THE PROJECT CHARTER, PRELIMINARY SCOPE STATEMENT,

AND PROJECT MANAGEMENT PLAN.
 MANAGING PROJECT SCOPE

 ACTIVITIES AND PROCESSES NEEDED TO ENSURE THAT

ONLY REQUIRED WORK IS PERFORMED
 MANAGING CHANGES ON THE PROJECT SCOPE
 SCOPE MANAGEMENT NEEDS TO BE INTEGRATED WITH
OTHER KNOWLEDGE AREAS TO ENSURE THE PROJECT
WORK WILL RESULT IN DELIVERY OF THE SPECIFIED
PRODUCT SCOPE.
 THE PROJECT MANAGER MUST BE IN CONTROL OF
SCOPE.
 SCOPE CHANGES SHOULD BE HANDLED IN A
STRUCTURED LOGICAL AND CONTROLLED MANNER.
 5.1 COLLECT REQUIREMENTS

Inputs Process Outputs

“…Defining and
• Project charter documenting • Requirements
• Stakeholder stakeholders needs to documents
meet the project
register objectives. The projects
• Requirements
success is directly management plan
influenced by the care • Requirements
taken in capturing and
managing project and traceability matrix
product requirements

Tools & Techniques

•Interviews
•Focus groups
•Workshop
•Group
Discussion
•Questionnaires
and surveys
•Observations
•Prototypes
 INPUT
 CREATED IN PROJECT COMMUNICATIONS MANAGEMENT,
IDENTIFY STAKEHOLDER PROCESS
 STAKEHOLDER IDENTIFICATION INFORMATION
◦ NAME, ORGANIZATION, POSITION, LOCATION, ROLE IN PROJECT, ETC.
• ASSESSMENT INFORMATION
◦ IDENTIFIES STAKEHOLDERS TO PROVIDE REQUIREMENTS
◦ POTENTIAL INFLUENCE IN THE PROJECT
• STAKEHOLDERS CLASSIFICATION
◦ INTERNAL VS. EXTERNAL, SUPPORTIVE VS. RESISTANT, ETC
 COLLECT REQUIREMENT ACTIVITIES
• BASED ON THE PROJECT CHARTER, ASSESS DETAILED
PROJECT REQUIREMENTS, CONSTRAINTS, AND
ASSUMPTIONS WITH STAKEHOLDERS.
• EXPLOIT LESSON LEARNED FROM PREVIOUS PROJECTS.
• UTILIZE REQUIREMENT-GATHERING TECHNIQUES (E.G.
PLANNING SESSIONS, BRAIN STORMING, FOCUS GROUP)
ESTABLISH THE PROJECT DELIVERABLES.
 REQUIREMENT DOCUMENTATION
• BUSINESS NEED OPPORTUNITY
• BUSINESS AND PROJECT OBJECTIVE (TRACEABILITY)
• REQUIREMENTS
• FUNCTIONAL (E.G. BUSINESS PROCESSES, PRODUCT INTERACTION)
• NON- FUNCTIONAL REQUIREMENTS ( E.G. SERVICE LEVEL, SAFETY
COMPLIANCES)
• QUALITY

• ACCEPTANCE CRITERIA
• TRAINING REQUIREMENTS
• SUPPORT REQUIREMENTS
• REQUIREMENTS ASSUMPTIONS AND CONSTRAINTS
 TOOLS AND TECHNIQUES

• INTERVIEW
• FORMAL & INFORMAL
• SPONTANEOUS AND PREPARED QUESTIONS
• 1:1 OR GROUP

• FOCUS GROUP
• BRING TOGETHER PREQUALIFIED STAKEHOLDERS TO LEARN
MORE ABOUT EXPECTATIONS OF PROPOSED DELIVERABLES
• MODERATOR GUIDES THE GROUP THROUGH INTERACTIVE
DISCUSSION.
 TOOLS AND TECHNIQUES
• FACILITATED WORKSHOP
• BRING TOGETHER PREQUALIFIED STAKEHOLDERS TO DEFINE PRODUCT
REQUIREMENTS
• GOOD APPROACH FOR GATHERING CROSS FUNCTIONAL
REQUIREMENTS AND RECONCILING STAKEHOLDERS DIFFERENCES.
• CAN BUILD TRUST AND RELATIONSHIPS.
• ISSUES DISCOVERED AND RESOLVED MORE QUICKLY THAN
INDIVIDUAL SESSIONS.
 TOOLS AND TECHNIQUES

• GROUP CREATIVITY TECHNIQUES

• BRAINSTORMING
• DELPHI TECHNIQUE
• IDEA/MIND MAPPING
• AFFINITY DIAGRAM
• GROUP DECISION MAKING TECHNIQUES
• UNANIMITY
• MAJORITY
• PLURALITY
• DICTATORSHIP
 DELPHI TECHNIQUES
 A FORM OF EXPERT JUDGMENT
 USED TO COLLECT OPINIONS ON TECHNICAL ISSUES,
ESTIMATES, RISKS AND SCOPE OF WORK.
 A REQUEST FOR OPINION IS SENT TO EXPERTS, RESPONSES
ARE COMPILED AND SENT BACK FOR FURTHER REVIEW
 HAS 3 RULES
◦ EXPERT ARE NOT IN SAME ROOM
◦ KEEP IDENTITIES ANONYMOUS
◦ FOCUS ON BUILDING CONSENSUS

THIS IS A COMMON TOOL IN MANY PROCESS

 TOOLS AND TECHNIQUES
• QUESTIONNAIRES AND SURVEYS
• ACCUMULATE INFORMATION FROM A WIDE NUMBER OF
RESPONDENTS.
• USED WITH BROAD AUDIENCES, QUICK TURNAROUND AND
STATISTICAL ANALYSIS.
• OBSERVATIONS
• VIEW INDIVIDUALS WORKING IN THEIR ENVIRONMENT
• HELPFUL IN UNDERSTANDING DETAILED PROCESSES.
• PROTOTYPES
• PROVIDE A WORKING MODEL OF THE EXPECTED PRODUCT TO
OBTAIN EARLY FEEDBACK
• PROGRESSIVE ELABORATION APPROACH.
 OUTPUT

• REQUIREMENTS DOCUMENTATION
• DESCRIBES HOW INDIVIDUAL REQUIREMENT MEET THE BUSINESS NEED FOR THE PROJECT.
• PROGRESSIVELY DETAILED AS MORE IS KNOWN
• MUST BE MEASUREABLE, TESTABLE, TRACEABLE, COMPLETE, AND ACCEPTANCE TO STAKEHOLDERS.
 OUTPUTS

 REQUIREMENTS MANAGEMENT PLAN

◦ DESCRIBES HOW REQUIREMENTS WILL BE ANALYZED. DOCUMENTED, AND MANAGED DURING THE
PROJECT.
◦ PHASE TO PHASE RELATIONSHIP FOR THE PROJECT INFLUENCES HOW REQUIREMENTS ARE MANAGED
AND IS DOCUMENTED HERE
◦ COMPONENTS
 HOW THE PROJECT WILL TRACK AND REPORT REQUIREMENTS ACTIVITIES
 PRIORITIZATION PROCESS
 TRACEABILITY STRUCTURE
 OUTPUT

• REQUIREMENTS TRACEABILITY MATRIX

• TRACES REQUIREMENT THROUGHOUT THE PROJECT LIFE CYCLE
• CONFIRMS THAT APPROVED REQUIREMENTS ARE DELIVERED AT THE END OF THE PROJECT
• HELPS MANAGE CHANGES TO SCOPE
• TRACE REQUIREMENTS TO
• BUSINESS NEED AND OBJECTIVES
• DESIGN, DEVELOPMENT, TEST CASES/ SCENARIOS
 DEFINE SCOPE

Inputs Process Outputs

“…Developing a detailed
• Project Scope statement
• Project charter description of a project and
product. (A) detailed •Project document updates
• Requirements project scope statement is •Stakeholder register
critical to the project •Requirements doc
documentation success and builds upon •Requirements
•Organizational the major deliverables, traceability matrix
assumptions and
process assets constraints that are
documented during project
initiation”.

Tools & Techniques

• Expert
judgment
•Product
Analysis
•Alternative
Definition
•Workshop
 DEFINING PROJECT SCOPE

 USE THE PROJECT CHARTER, DEFINE HIGH LEVEL SCOPE BASED ON BUSINESS AND
COMPLIANCE REQUIREMENTS.
 ANALYZE ALL EXISTING INFORMATION, INCLUDING LESSONS LEARNED, TO DETERMINE
REQUIREMENTS TO MEET CUSTOMERS EXPECTATIONS.
 VALIDATE EXISTING RISKS, ASSUMPTIONS, AND CONSTRAINTS FOR COMPLETENESS.
 ADD NEW RISK, ASSUMPTIONS, AND CONSTRAINTS THAT ARE IDENTIFIED.
 OUTPUTS
PROJECT SCOPE STATEMENTS
 PRODUCT SCOPE DESCRIPTION
◦ CHARACTERISTICS OF THE PRODUCT, SERVICE OR RESULT OF THE PROJECT. THESE WILL BE DETAILED
THROUGH PROGRESSIVE ELABORATION.

 PROJECT BOUNDARIES AND EXCLUSIONS

◦ WHAT IS INCLUDED IN THE PROJECT AND EXPLICITLY, WHAT IS EXCLUDED. ASSUMPTIONS ON THE
SCOPE SHOULD BE AVOIDED.
 OUTPUT
PROJECT SCOPE STATEMENT (CONT)
• PROJECT DELIVERABLES
• PRODUCT, SERVICE OR RESULT OF THE PROJECT (AND ITS
COMPONENTS)
• PROJECT MANAGEMENT DELIVERABLES (DOCUMENT)
 PRODUCT ACCEPTANCE CRITERIA
 PROJECT CONSTRAINTS
• APPLICABLE RESTRICTION THAT LIMITS THE PROJECT OPTIONS
• CONTRACTUAL TERMS ARE USUALLY CONSTRAINTS
 PROJECT ASSUMPTIONS
• FACTORS THAT, FOR THAT PLANNING PURPOSES, ARE
CONSIDERED TO BE TRUE, REAL OR CERTAIN.
 PROJECT CHARTER VS. PROJECT SCOPE STATEMENT
Charter Scope Statement
Project purpose or justification Product scope description
(Progressively elaborated)
Measurable project objective and related Project deliverables
success criteria
High level requirements Product user acceptance criteria

High level project description, product Project Boundaries

characteristics
Summary milestone schedule Project Constraints
Summary budget Project assumption
Project approval requirements (what
constitutes success, who decides it, who
sign off)
Assigned project manager, responsibility
and authority level
Name and responsibility of the person (s)
 TOOLS AND TECHNIQUES

• PRODUCT ANALYSIS
• TRANSLATING PROJECT OBJECTIVE IN TO TANGIBLE DELIVERABLES AND
REQUIREMENTS

 ALTERNATIVE IDENTIFICATION
• GENERATING DIFFERENT APPROACH TO PERFORM WORK
• VARIOUS MANAGEMENT AND CREATIVE THINKING OF METHODS: BRAINSTORMING,
LATERAL THINKING
Creating the Work Breakdown Structure
(WBS)
 A WBS is a deliverable-oriented grouping of the work
involved in a project that defines the total scope of the
project.

 A WBS is a foundation document that provides the basis

for planning and managing project schedules, costs,
resources, and changes.

 Decomposition is subdividing project deliverables into

smaller pieces.

 Work package is a task at the lowest level of the WBS that

the project manager is using to monitor and control the
project
Partial WBS Organized by Product Areas
Partial WBS Organized by Project Phase
Partial Intranet WBS in Tabular Form

1.0 Concept
1.1 Evaluate current systems
1.2 Define Requirements
1.2.1 Define user requirements
1.2.2 Define content requirements
1.2.3 Define system requirements
1.2.4 Define server owner requirements
1.3 Define specific functionality
1.4 Define risks and risk management approach
1.5 Develop project plan
1.6 Brief Web development team
2.0 Web Site Design
3.0 Web Site Development
4.0 Roll Out
5.0 Support
Intranet WBS and Gantt Chart in
Microsoft Project
Intranet Gantt Chart Organized by Project
Management Process Groups
 Create WBS

Inputs Process Outputs

“…Subdividing project • Work Breakdown structure
• Project scope
deliverables and project • WBS Dictionary
statement
work into smaller, more • Scope baseline
• Requirements
manageable •Project documents updates
documents
components. • Requirements doc.
• Organizational process
assets.

Tools & Techniques

• Decompositions
 APPROACHES TO DEVELOP THE WBS
• GUIDELINES: SOME ORGANIZATIONS, SUCH AS THE DOD, PROVIDE GUIDELINES
FOR PREPARING WBSS.
• ANALOGY APPROACH: REVIEW WBS OF SIMILAR PROJECTS AND TAILOR TO
YOUR PROJECT.
• TOP-DOWN APPROACH: START WITH THE LARGEST ITEMS OF THE PROJECT AND
BREAK THEM DOWN.
• BOTTOM-UP APPROACH: START WITH THE SPECIFIC TASKS AND ROLL THEM UP.
• MIND-MAPPING APPROACH: WRITE TASKS IN A NON-LINEAR, BRANCHING
FORMAT AND THEN CREATE THE WBS STRUCTURE.
Mind Mapping
 Mind Mapping is a way of creating pictures that
show ideas in the same way that they are
represented in your brain.
 Your brain uses words, pictures, numbers, logic,
rhythm, color and spatial awareness to build up
unique pictures of information.
 The ideas are linked together in a way that makes
it easy to understand and remember.
 http://www.novamind.com/mind-mapping/
 http://www.youtube.com/watch?v=MlabrWv25qQ
Mind Mapping
Sample Mind-Mapping Approach for
Creating a WBS
Resulting WBS in Chart Form
 Output
Work Breakdown Structure (WBS)
 Creating a hierarchical, deliverable-oriented
decomposition of project work.
 Organizes and defines the total project scope
 What is not in the WBS will not be done
 The lowest level is called work package
◦ Can be estimated
◦ Scheduled
◦ Monitored and Controlled
 Granularity ( detail level) may vary with the size and
complexity of the project.
 OUTPUT
SCOPE BASELINE

THE SCOPE BASELINE IS A COMPONENT OF THE PROJECT MANAGEMENT PLAN,

WHICH INCLUDES;
• APPROVED DETAILED PROJECT SCOPE STATEMENT
• ASSOCIATED WBS AND WBS DICTIONARY
• OTHER OUTPUT
• UPDATES TO PROJECT DOCUMENTS
 Verify Scope

 The process of obtaining formal acceptance of the

completed project scope and associated deliverables.
 Includes
◦ Reviewing deliverables and work products
◦ Determining if the results conform to requirements
 Performed at the end of each phase
 Differs from quality control
 Scope verification
 Acceptance of deliverables (completeness)
 Quality control
 Meeting the quality requirements ( correctness)
 What Went Wrong?
 A project scope that is too broad and grandiose can cause
severe problems
◦ Scope creep and an overemphasis on technology for
technology’s sake resulted in the bankruptcy of a large
pharmaceutical firm, Texas-based FoxMeyer Drug
◦ In 2001, McDonald’s fast-food chain initiated a project to
create an intranet that would connect its headquarters
with all of its restaurants to provide detailed operational
information in real time; after spending $170 million on
consultants and initial implementation planning,
McDonald’s realized that the project was too much to
handle and terminated it

41
Project Scope Management
Control Scope

 Is concerned with
◦ Monitoring the status of the project and
product scope
◦ Controlling impact of the changes
◦ Determining that a scope change has occurred
◦ Managing changes when and if they occur
◦ Avoiding uncontrolled scope changes (scope
creep)
Best Practices for Avoiding Scope Problems

1. Keep the scope realistic: Don’t make projects so large that they
can’t be completed; break large projects down into a series of
smaller ones
2. Involve users in project scope management: Assign key users to
the project team and give them ownership of requirements
definition and scope verification
3. Use off-the-shelf hardware and software whenever possible:
Many IT people enjoy using the latest and greatest technology,
but business needs, not technology trends, must take priority
4. Follow good project management processes: As described in this
chapter and others, there are well-defined processes for
managing project scope and others aspects of projects