Download Project Management

Project Management
Project Scope Management
Knowledge Areas
Software Project Management
2
What is Project Scope Management?
• Scope refers to all the work involved in creating
the products of the project and the processes
used to create them
• A deliverable is a product produced as part of
a project, such as hardware or software,
planning documents, or meeting minutes
• Project scope management includes the
processes involved in defining and controlling
what is or is not included in a project
Software Project
3 Management
Knowledge Area
Processes
Project Management
Integration
Project Management Process Groups
Initiating Process Group
Planning Process Group
Executing Process Group
Monitoring and
Controlling Process
Group
Closing Process Group
- Develop Project Charter
- Develop Preliminary
Project Scope Statement
- Develop Project
Management Plan
- Direct and Manage
Project Execution
- Monitor and Control
Project Work
- Integrated Change
Control
- Close Project
Project Scope
Management
- Scope Planning
- Scope Definition
- Scope WBS
- Scope Verification
- Scope Control
Project Time
Management
- Activity Definition
- Activity Sequencing
- Activity Resource
Estimating
- Activity Duration
Estimation
- Schedule Development
- Schedule Control
Project Cost
Management
- Cost Estimating
- Cost Budgeting
- Cost Control
Project Quality
Management
- Quality Planning
- Perform Quality
Assurance
- Perform Quality Control
Project Human
Resources Management
- Human Resources
Planning
- Acquire Project Team
- Develop Project Team
- Manage Project Team
Project Communication
Management
- Communications
Planning
- Information
Distribution
- Performance Reporting
- Manage Stakeholders
Project Procurement
Planning
- Plan Purchase and
Acquisitions
- Plan Contracting
- Request Seller
Responses
- Select Sellers
- Contract Administration
Project Risk
Management
- Risk Management
Planning
- Risk Identification
- Qualitative Risk Analysis
- Quantitative Risk
Analysis
- Risk Response Planning
Software Project Management
- Contract Closure
- Risk Monitoring and
Control
4
Project Scope Management Processes
•
•
•
•
•
Scope planning: deciding how the scope will be defined,
verified, and controlled
Scope definition: reviewing the project charter and
preliminary scope statement and adding more information as
requirements are developed and change requests are
approved
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
Software Project
5 Management
Project Scope Management Summary
Software Project
6 Management
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
Software Project
7 Management
Sample Scope Management Plan
Software Project Management
8
The Project Scope Statement
• The preliminary scope statement, project
charter, organizational process assets, and
approved change requests provide a basis for
creating the project scope statement
• As time progresses, the scope of a project
should become more clear and specific
• It is one of the main inputs for creating a Work
Breakdown Structure (WBS)
Software Project
9 Management
Project Scope Statement Content
• description of the project
• detailed descriptions of project deliverables
• characteristics of products and services produced
as part of the project
• project success criteria and acceptance criteria
• constrains and assumptions
• defined risks
• milestones
• raw cost estimate
• configuration management requirements, etc
Software Project Management
10
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
• Decomposition is subdividing project
deliverables into smaller pieces based on
product characteristics OR project phases.
• A work package is a task at the lowest level of
the WBS
Software Project
11 Management
WBS – Basis of Many Things
•
•
•
•
•
•
Network scheduling
Costing
Risk analysis
Organizational structure
Control
Measurement
Software Project Management
12
WBS
• Hierarchical list of project’s work activities
• 2 Formats
– Outline (Indented format)
– Graphical Tree (Organizational chart)
• Uses a decimal numbering system
– Ex: 3.1.5
– 0 is typically top level
• Includes
– Development, mgmt., and project support tasks
• Shows “is contained in” relationships
• Does not show dependencies or durations
Software Project Management
13
WBS
• List of Activities
• List of items can come from many sources
– SOW, proposal, brainstorming, stakeholders, team
• Describe activities using “bullet language”
– Meaningful but terse labels
• All WBS paths do not have to go to the same level
• Do not plan more detail than you can manage
• WBS items trace back to scope statement items
Software Project Management
14
The WBS Dictionary and Scope
Baseline
• Many WBS tasks are vague and must be explained
more so people know what to do and can
estimate how long it will take and what it will cost
to do the work
• A WBS dictionary is a document that describes
detailed information about each WBS item
• The approved project scope statement and its
WBS and WBS dictionary form the scope baseline,
which is used to measure performance in meeting
project scope goals
Software Project
15 Management
Project Elements
• A Project: functions, activities, tasks
Software Project Management
16
WBS Chart Example
Software Project Management
17
WBS Outline Example
0.0 Retail Web Site
1.0 Project Management
2.0 Requirements Gathering
3.0 Analysis & Design
4.0 Site Software Development
4.1 HTML Design and Creation
4.2 Backend Software
4.2.1 Database Implementation
4.2.2 Middleware Development
4.2.3 Security Subsystems
4.2.4 Catalog Engine
4.2.5 Transaction Processing
4.3 Graphics and Interface
4.4 Content Creation
5.0 Testing and Production
Software Project Management
18
Partitioning Your Project
• You need to decompose your project into
manageable chunks
• ALL projects need this step
• Divide & Conquer
• Two main causes of project failure
– Forgetting something critical
– Ballpark estimates become targets
• How does partitioning help this?
Software Project Management
19
WBS
• Contract WBS (CWBS)
– First 2 or 3 levels
– High-level tracking
• Project WBS (PWBS)
– Defined by PM and team members
– Tasks tied to deliverables
– Lowest level tracking
Software Project Management
20
A Full WBS Structure
• Up to six levels (3-6 usually) such as
• Upper 3 can be used by customer for reporting (if
part of RFP/RFQ)
• Different levels can be applied to different uses
• Ex: Level 1: authorizations; 2: budgets; 3: schedules
Software Project Management
21
WBS Types
• Process WBS
• a.k.a. Activity-oriented
• Ex: Requirements, Analysis, Design, Testing
• Typically used by PM
• Product WBS
• a.k.a. Entity-oriented
• Ex: Development of the financial engine, Building the interface
system, Creating the DB
• Typically used by engineering manager
• Hybrid WBS: both above
• This is not unusual
• Ex: Lifecycle phases at high level with component or featurespecifics within phases
• Rationale: processes produce products
Software Project Management
22
Product WBS
Software Project Management
23
Process WBS
Software Project Management
24
Outline WBS w/Gantt
Software Project Management
25
WBS by PMI Process Groups
Software Project Management
26
WBS Types
• Less frequently used alternatives
– Organizational WBS
• Research, Product Design, Engineering, Operations
• Can be useful for highly cross-functional projects
– Geographical WBS
• Can be useful with distributed teams
• NYC team, San Jose team, Off-shore team
Software Project Management
27
Work Packages
• Generic term for discrete tasks with definable end results
• Typically the “leaves” of the tree
• The “one-to-two” rule
• Often at: 1 or 2 persons for 1 or 2 weeks
• Basis for monitoring and reporting progress
• Can be tied to budget items (charge numbers)
• Resources (personnel) assigned
• Ideally shorter rather than longer
•
•
•
•
•
Longer makes in-progress estimates needed
These are more subjective than “done”
2-3 weeks maximum for software projects
1 day minimum (occasionally a half day)
Not so small as to micro-manage
Software Project Management
28
WBS & Methodology
• PM must map activities to the chosen lifecycle
• Each lifecycle has different sets of activities
• Integral process activities occur for all
methodologies: planning, configuration, testing, etc
• Operations and maintenance phases are not
normally in plan (considered post-project)
• Some models are “straightened” for WBS:
– Spiral and other iterative models
– Linear sequence several times
• Deliverables of tasks vary by methodology
Software Project Management
29
WBS Techniques
•
•
•
•
Top-Down
Bottom-Up
Analogy
Rolling Wave
– 1st pass: go 1-3 levels deep
– Gather more requirements or data
– Add more detail later
• Post-its on a wall
Software Project Management
30
WBS Techniques
• Top-down
– Start at highest level
– Systematically develop increasing level of detail
– Best if
• The problem is well understood
• Technology and methodology are not new
• This is similar to an earlier project or problem
– But is also applied in majority of situations
Software Project Management
31
WBS Techniques
• Bottom-up
– Start at lowest level tasks
– Aggregate into summaries and higher levels
– Cons
• Time consuming
• Needs more requirements complete
– Pros
• Detailed
Software Project Management
32
WBS Techniques
• Analogy
– Base WBS upon that of a “similar” project
– Use a template
– Analogy also can be estimation basis
– Pros
• Based on past actual experience
– Cons
• Needs comparable project
Software Project Management
33
WBS Techniques
• Brainstorming
– Generate all activities you can think of that need
to be done
– Group them into categories
• Both Top-down and Brainstorming can be
used on the same WBS
Software Project Management
34
WBS Guidelines Part 1
• Should be easy to understand
• Some companies have corporate standards for these
schemes
• Some top-level items, like Project Mgmt. are in WBS
for each project; others vary by project
• Break down until you can generate accurate time &
cost estimates
• Ensure each element corresponds to a deliverable
Software Project Management
35
WBS Guidelines Part 2
• How detailed should it be?
– Not as detailed as the final MS-Project plan
– Each level should have no more than 7 items
– It can evolve over time
• What tool should you use?
– Excel, Word, MS Project
– Org chart diagramming tool (Visio, etc)
– Specialized commercial apps
• Re-use a “template” if you have one
Software Project Management
36
Advice for Creating a WBS and WBS
Dictionary*
• A unit of work should appear at only one place
in the WBS
• The work content of a WBS item is the sum of
the WBS items below it
• A WBS item is the responsibility of only one
individual, even though many people may be
working on it
• The WBS must be consistent with the way in
which work is actually going to be performed; it
should serve the project team first, and other
purposes only if practical
*Cleland, David I. Project Management: Strategic Design and Implementation, 1994
Software Project
37 Management
Advice for Creating a WBS and WBS
Dictionary (continued)*
• Project team members should be involved in
developing the WBS to ensure consistency
• Each WBS item must be documented in a WBS
dictionary to ensure accurate understanding of
the scope of work included and not included in
that item
• The WBS must be a flexible tool to accommodate
inevitable changes while properly maintaining
control of the work content in the project
according to the scope statement
*Cleland, David I. Project Management: Strategic Design and Implementation, 1994
Software Project
38 Management
Scope Verification
• It is quite difficult to create a good scope
statement and WBS for a project
• It is even more difficult to verify project scope
and minimize scope changes
• Scope verification involves formal acceptance of
the completed project scope by the stakeholders
• Acceptance is often achieved by a customer
inspection and then sign-off on key deliverables
Software Project
39 Management
Scope Control
• Scope control involves controlling changes to the project
scope
• Part of the overall integrated change control (see PIM)
• Goals of the scope control are to:
– Influence the factors that cause scope changes
– Ensure changes are processed according to procedures developed
as part of integrated change control
– Manage changes when they occur
• Variance is the difference between planned and actual
performance
Software Project
40 Management
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: there are welldefined processes for managing project scope and others aspects
of projects
Software Project Management
41
Suggestions for Improving User Input
• Develop a good project selection process and
insist that sponsors are from the user organization
• Have users on the project team in important roles
• Have regular meetings with defined agendas, and
have users sign off on key deliverables presented
at meetings
• Deliver something to users and sponsors on a
regular basis
• Don’t promise to deliver when you know you
can’t
• Co-locate users with developers
Software Project Management
42
Suggestions for Reducing
Incomplete and Changing
Requirements
• Develop and follow a requirements
management process
• Use techniques such as prototyping, use case
modeling to get more user involvement
• Put requirements in writing and keep them
current
• Create a requirements management database
for documenting and controlling requirements
Software Project Management
43
Suggestions for Reducing
Incomplete and Changing
Requirements (continued)
• Provide adequate testing and conduct testing
throughout the project life cycle
• Review changes from a systems perspective
• Emphasize completion dates to help focus on
what’s most important
• Allocate resources specifically for handling
change requests/enhancements
Software Project Management
44