Project Scope Management - PowerPoint PPT Presentation

Loading...

PPT – Project Scope Management PowerPoint presentation | free to download - id: 6e7075-OTFlO



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Project Scope Management

Description:

Project Scope Management 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 ... – PowerPoint PPT presentation

Number of Views:18
Avg rating:3.0/5.0
Date added: 6 February 2020
Slides: 49
Provided by: Ceng150
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Project Scope Management


1
Project Scope Management
2
Learning Objectives
  • Understand the importance of good project scope
    management
  • Discuss methods for collecting and documenting
    requirements in order to meet stakeholder needs
    and expectations
  • Explain the scope definition process and describe
    the contents of a project scope statement
  • Discuss the process for creating a work breakdown
    structure using the analogy, top-down, bottom-up,
    and mind-mapping approaches

3
Learning Objectives (continued)
  • Explain the importance of verifying scope and how
    it relates to defining and controlling scope
  • Understand the importance of controlling scope
    and approaches for preventing scope-related
    problems on information technology projects
  • Describe how software can assist in project scope
    management

4
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
  • Deliverables can be product related such as a
    piece of hardware or software, or process related
    such as planning documents, or meeting minutes
  • Project stakeholders must agree to the products
    of a project and to some extent how they would
    produce them to define all the deliverables.
  • Project scope management includes the processes
    involved in defining and controlling what is or
    is not included in a project

5
Project Scope Management Processes
  • Project Scope Management ensures that project
    team and stake holders have the same
    understanding as to what products the project
    would produce and what processes the team would
    use to produce them. There are five processes
  • Collecting requirements defining and documenting
    the features and functions of the products
    produced during the project as well as the
    processes used for creating them
  • Defining scope reviewing the project charter,
    requirements documents, and organizational
    process assets to create a scope statement
  • Creating the WBS subdividing the major project
    deliverables into smaller, more manageable
    components
  • Verifying scope formalizing acceptance of the
    project deliverables
  • Controlling scope controlling changes to project
    scope throughout the life of the project

6
Project Scope Management Summary
7
Collecting Requirements
  • A requirement is a condition or capability that
    must be met or possessed by a system, product,
    service, result, or component to satisfy a
    contract, standard, specification, or other
    formal document (PMBOK Guide, 2008)
  • It is helpful to document requirements in enough
    detail so that requirements can be measured
    during execution.
  • Meeting scope goals is often based on meeting
    documented requirements
  • It is important to use an iterative approach to
    defining requirements since they are often
    unclear early in a project

8
Requirement s Development Approach
  • Process can be divided into following
    sub-activities
  • Elicitation - this involves interviewing the
    stakeholders and determining their needs. This is
    not writing down everything they say
  • Analysis - this involves developing detailed
    requirements from elicitation. These detailed
    requirements don't need to be just textual in
    nature. They can be of different forms, such as
    business process diagrams, data models, use
    cases, and prototypes
  • Specification - this involves documenting the
    various types of requirements, which can be
    textual or graphical. It is usually a good idea
    to have a few documentation standards for vision
    and scope document, FRS, SRS, BRD, etc.
  • Validation - this involves making sure that the
    requirements are correct and will meet the
    stakeholders' needs. One good way to validate
    requirements is to have the stakeholders develop
    user acceptance criteria. These criteria specify
    the primary tasks the software will allow the
    users to perform and the common errors that the
    software will handle.

9
Requirement s Development Approach (Contd)
  • You don't need to develop all the requirements
    for the entire project at once
  • Requirements development is an iterative process,
    so trying to develop detailed requirements all at
    once can lead to analysis paralysis
  • During elicitation, you will identify the high
    priority or first built features
  • Start with analysis and specification of these
    requirements and do validation with a quick
    informal review
  • Then move to the next set of elicited
    requirements for analysis and specification, all
    the while correcting the previous set of
    requirements of missing or misunderstood
    requirements that are discovered along the way
  • Having multiple cycles will refine the
    requirements to a level of detail that can be
    efficiently communicated to the stakeholders,
    testers, and developers

10

11
Methods for Collecting Requirements
  • Interviewing Expensive and Time consuming for
    large projects
  • Focus groups - The feedback can be gathered about
    needs / opportunities / problems to identify
    requirements, or can be gathered to validate and
    refine already elicited requirements
  • Facilitated workshops - To specify your business
    needs or requirements, according to the published
    objectives
  • Questionnaires and surveys Involves
    stakeholders honesty and thoroughness
  • Observation The study of users in their natural
    habitats.Good for projects which involve
    improving processes and procedures
  • Prototyping - Make a mock-up of the user
    interface screens
  • Software tools Microsoft Word, UNICASE
    (opensource) etc.

12
So which method is Best.
Catch-up Interviews, work in target environment
Fuzzy Brainstorming, workshops Mature
Questionnaires, workshops, prototypes
Selling/Teaching prototypes
Selection of Techniques
13
What Went Right?
  • Genesys Telecommunications Laboratories uses
    Accept software, a product planning and
    innovation management application and winner of
    the Excellence in Product Management Award from
    20062008
  • Accept helps them instill a consistent,
    repeatable, and predictable process for new
    product definition and development
  • They can define what information comprises a
    requirement and enforce discipline around that
    process

14
Documenting Requirements
  • Requirements documents are often generated by
    software and
  • Include text, images, diagrams, videos, and other
    media
  • They are often broken down into different
    categories such as functional, service,
    performance, quality, training requirements, and
    so on
  • A requirements management plan describes how
    project requirements will be analyzed,
    documented, and managed
  • A requirements traceability matrix (RTM) is a
    table that lists requirements, various attributes
    of each requirement, and the status of the
    requirements to ensure that all requirements are
    addressed

15
Facts about RTM
  • A table that lists requirements and their
    attributes and status
  • There can be many variations of what can be
    included in the RTM
  • The requirement traceability matrix is usually
    developed in concurrence with the initial list of
    requirements. Usually the FRS, BRD etc.
  • RTM can contain specific tests to validate the
    requirements
  • Simply put, the main purpose of RTM is to
    maintain the linkage from the source of each
    requirement through its decomposition to
    implementation and verification.

16
Sample Requirements Traceability Matrix
17
Defining Scope
  • The main tools and techniques used in defining
    scope are expert judgment, product analysis and
    facilitated workshops
  • Key inputs for preparing the project scope
    statement include the project charter,
    requirements documentation, and organizational
    process assets such as policies and procedures
    related to scope statements as well as project
    files and lessons learned from previous, similar
    projects
  • As time progresses, the scope of a project should
    become more clear and specific

18
Whats a project charter?
  • A document describing high level scope, time and
    cost goals
  • Project objectives
  • Main project success criteria
  • General Approach to accomplish the project goals
  • Main roles and responsibilities of major
    stakeholders
  • Signoff from major stakeholders

19
Project Scope Statements
  • Project scope statements are used in an
    iteratively manner
  • Versions of scope statements can be produced
  • Clear example of progressive elaboration
  • Project scope statements should include at a
    minimum,
  • Product scope descriptions
  • Product user acceptance criteria
  • Project constraints, boundaries and assumptions
  • Reference to supporting documentation
  • Detailed information on all project deliverables
  • Functional and design specifications

20
Further Defining Project Scope
21
Project Scope Statements (Contd)
  • Scope statements often refer to related documents
    like product specs, product brochures or other
    plans
  • The updates to project scope statements
    iteratively, require changes to other project
    documents also.
  • An up-to-date project scope statement helps in
    developing understanding of project scope and
    also helps in avoiding scope creep.
  • Scope creep (also called requirement creep and
    feature creep) in project management refers to
    uncontrolled changes or continuous growth in a
    projects scope

22
Media Snapshot
  • Many people enjoy watching television shows like
    Trading Spaces, where participants have two days
    and 1,000 to update a room in their neighbors
    house since the time and cost are set, its the
    scope that has the most flexibility
  • Although most homeowners are very happy with work
    done on the show, some are obviously
    disappointed part of agreeing to be on the show
    includes signing a release statement
    acknowledging that you will accept whatever work
    has been done
  • Too bad you cant get sponsors for most projects
    to sign a similar release form it would make
    project scope management much easier!

23
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
  • WBS is a foundation document that provides the
    basis for planning and managing project
    schedules, costs, resources, and changes
  • Since the WBS defines the total scope of the
    project, some experts believe that work should
    not be done on a project if it is not included in
    the WBS.
  • Inputs to creating a WBS include project scope
    statements, requirements documents and
    organizations process assets.
  • The main tool or technique used to create a WBS
    is decomposition.

24
Sample Intranet WBS Organized by Products of the
Project
Above figure shows WBS for an Intranet project.
This WBS is organized around the products of this
project
25
WBS Organized around Phases
  • Another way of organizing a WBS could be around
    the phases of a project.
  • The complete project is shown at level1
  • The phases can be seen as Concept, website
    design, website development, roll out and support
    are on the level 2
  • Each level of work in the WBS is defined as task
    (according to PMI)
  • The tasks that can be broken down into smaller
    ones are known as Summary tasks
  • The WBS can also be represented in terms of
    tabular form
  • The hierarchy or level of tasks is shown by
    indenting and numbering.

26
Sample Intranet WBS Organized by Phase
27
WBS Work Packages
  • The tasks which are on the lowest level are known
    as work packages.
  • A work package also represents the level of work
    that the Project Manager monitors or controls
  • Work packages can be thought in terms of
    accountability and reporting
  • Another way of thinking about the work packages
    is calculating time estimates. Only enter time
    estimate for work packages and rest of the tasks
    (summary tasks) would have the accumulated time.

28
Intranet WBS and Gantt Chart in Microsoft Project
29
WBS Considerations
  • WBS tasks are not to be confused with functional
    specifications.
  • Please note that the WBS is created on the basis
    of what needs to be done or how it needs to be
    done
  • The question about when it needs to be done is
    not addressed in WBS
  • In other words the tasks do not have to be
    developed as sequential list of steps.
  • If we want some sequence we can create a WBS
    using the project management process groups of
    initiating, planning, executing, monitoring and
    controlling.
  • Preparing and reviewing WBS should involve the
    whole project team and customer. Group meetings
    can be conducted in this regard.

30
Intranet Gantt Chart Organized by Project
Management Process Groups
31
Approaches to Developing WBSs
  • Using guidelines some organizations, like the
    DOD, provide guidelines for preparing WBSs
  • The analogy approach review WBSs of similar
    projects and tailor to your project
  • The top-down approach start with the largest
    items of the project and break them down
  • The bottom-up approach start with the specific
    tasks and roll them up
  • Mind-mapping approach mind mapping is a
    technique that uses branches radiating out from a
    core idea to structure thoughts and ideas. This
    technique could use top-down or bottom up
    approaches or no approach.

32
Sample Mind-Mapping Approach for Creating a WBS
Created in software MindManager and can be
converted into tabular form once it is finalized
33
Project 2007 File with WBS Generated from a Mind
Map
34
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

35
(No Transcript)
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

37
Advice for Creating a WBS and WBS Dictionary
(contd)
  • Project team members should be involved in
    developing the WBS to ensure consistency and
    buy-in
  • 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

38
What Went Wrong?
  • A project scope that is too broad and grandiose
    can cause severe problems
  • Scope creep and an overemphasis on technology for
    technologys sake resulted in the bankruptcy of a
    large pharmaceutical firm, Texas-based FoxMeyer
    Drug
  • In 2001, McDonalds 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, McDonalds
    realized that the project was too much to handle
    and terminated it

39
Verifying Scope
  • It is very 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
  • In order to receive formal acceptance the project
    team must prepare clear documentation of
    projects products and procedures
  • Inputs to project verification are project
    management plan, requirements documentation,
    requirements traceability matrix, validated
    deliverables

40
Verifying Scope (Contd)
  • The main tool for verifying scope is Inspection
  • Deliverables are measured, examined, and verified
    in order to ascertain whether they meet the
    product acceptance criteria
  • The customer, sponsor or user inspects the
    delivered work
  • Other terms for this step are reviews, audits,
    and walkthroughs
  • Outputs from verifying scope are accepted
    deliverables or requested changes/recommended
    corrective actions

41
Controlling Scope
  • Scope control involves controlling changes to the
    project scope
  • Users often are not really sure how they want
    screens to be shown or what functionality they
    need to address business needs
  • Developers are not really sure how to interpret
    user requirements and control contantly changing
    technologies.

42
Controlling Scope (Contd)
  • Goals of scope control are to
  • Influence the factors that cause scope changes
  • Assure changes are processed according to
    procedures developed as part of integrated change
    control
  • Manage changes when they occur
  • Stakeholders should be discouraged to suggest
    unnecessary changes
  • Important tool to controlling scope is variance
    analysis
  • Variance is the difference between planned and
    actual performance
  • Outputs of controlling scope can be work
    performance measurements, organization's process
    assets updates, change requests and project
    documents update

43
Best Practices for Avoiding Scope Problems
  • 1. Keep the scope realistic. Dont make projects
    so large that they cant 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.

44
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
    like assigning co-project manager from the
    business area
  • 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
  • Dont promise to deliver when you know you cant
  • Co-locate users with developers

45
Suggestions for Reducing Incomplete and Changing
Requirements
  • Develop and follow a requirements management
    process that includes procedures for initial
    requirements determination
  • Use techniques such as prototyping, use case
    modeling, and joint application design (JAD) to
    get more user involvement
  • Put requirements in writing and keep them current
  • Create a requirements management database for
    documenting and controlling requirements

46
Suggestions for Reducing Incomplete and Changing
Requirements (contd)
  • Provide adequate testing and conduct testing
    throughout the project life cycle
  • Review changes from a systems perspective by
    ensuring that scope changes include associated
    cost and schedule changes.
  • Emphasize completion dates to help focus on
    whats most important
  • Allocate resources specifically for handling
    change requests/enhancements. Enhance user
    support to satisfy them.

47
Using Software to Assist in Project Scope
Management
  • Word-processing software helps create several
    scope-related documents
  • Spreadsheets help to perform financial
    calculations and weighted scoring models and to
    develop charts and graphs
  • Communication software like e-mail and the Web
    help clarify and communicate scope information
  • Project management software helps in creating a
    WBS, the basis for tasks on a Gantt chart
  • Specialized software is available to assist in
    project scope management

48
Chapter Summary
  • Project scope management includes the processes
    required to ensure that the project addresses all
    the work required, and only the work required, to
    complete the project successfully
  • Main processes include
  • Collect requirements
  • Define scope
  • Create WBS
  • Verify scope
  • Control scope
About PowerShow.com