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