Project Scope Management

ITPM
Session 10
13.10.2022
 Definition of Scope

• Scope refers to all the work involved in creating the products of the
project and the processes used in creating them.
• Products of the project are called deliverables which emphasizes
that the products and processes are created for a sponsor
• Deliverables can be product related such as hardware or software or
process related concept, planning or design
• Scope is converted to requirements through elaboration and
quantification
 Definitions of Requirements
PMBOK
• Requirements are defined as “ conditions, or capabilities that must be met by
the project or present in the product, service or result to satisfy an agreement
or other formally imposed specification” PMBOK Guide (Fifth Edition)
1910 IEEE (Institute of Electrical and Electronics Engineers) Standard Glossary
of Software
• A condition or capability needed by a user to solve a problem or meet an
objective
• A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification or other formally
imposed document
 Six Processes Groups of Project Scope
Management
(1) Planning Scope Management
(2) Collecting Requirements
(3) Defining Scope
(4) Creating Work Break Down Structure (WBS)
(5) Validating Scope
(6) Controlling Scope
initiating Planning Executing closeout
 (1)Planning Scope Management
• For good management it is essential to have a plan. The plan for
scope management (which must be made after stakeholder
consultation) generally includes:
• Methodology/Processes for:
• (a)Collecting Requirements and creating a Requirements document
• (b) Creating the Scope Statement of the project (basically what should it include)
• (c) Creating Work Break Down Structure (WBS -Dividing scope into smaller components)
• (d) Validating Scope
• (e) Controlling Scope (controlling changes to project scope)
1. Planning Scope Management -RMP
• Another output of scope management is the Requirements management
Plan (RMP)
• The RMP includes:
• How to plan, track and report requirement activities ( actions such as conducting
interviews, scheduling meetings, or holding team brainstorming sessions)
• How changes to the requirement would be handled (process should specify why
the decision was made, who will sign off on the change, what impact will it have on
the project)
• How to prioritize requirements (e.g. identifying requirements that are mission-
critical and prioritizing them over others).
• How to trace the requirement (processes used to track requirements from the
start to the end of the project)
Collecting Requirements
 Collecting
Requirements
• This is the most difficult step in scope definition. What ever technique
is used it is not possible to get the user to indicate all the requirements
• A major consequence of not defining requirements well is rework
which can consume up to half of project software costs specially in case
of software development
• However the cost of failure is high: It costs 100 times more to correct a
defect in operation than it is at design stage
• After collecting the requirements the scope statement has to be
defined
https://www.researchgate.net/figure/IBM-System-Science-Institute-Relative-Cost-of-Fixing-Defects
_fig1_255965523
Methods to collect Requirements
 Methods to collect Requirements

• Interviewing stakeholders is effective but time consuming and costly

• Less costly than one on one interviews are: holding group workshops and using
group creativity and decision making techniques
• Questionnaires are effective if stakeholders provide honest and thorough
information
• Other techniques are:
• Context diagrams (A context diagram, sometimes called a level 0 data-flow diagram, is
drawn in order to define and clarify the boundaries of the software system. It identifies
the flows of information between the system and external entities. The
entire software system) is shown as a single process.
• Prototyping (building a working replica)
• Document Analysis
Context Diagram for Product Ordering
System
Context Diagram for Hotel Room Booking
System
Context Diagram for
Prototyping is done in the Requirements
Phase to collect and clarify Requirements
Document Analysis
 “Document Analysis” for Gathering
Requirements
• Document Analysis is a technique used to gather requirements during the
requirements elicitation phase of a project. 
• It describes the act of reviewing the existing documentation of
comparable business processes or systems in order to extract pieces of
information that are relevant to the current project, and therefore should
be considered as current project’s requirements.
• Existing documentation can be examined to gain an understanding of key
functions, business rules, business entities, and business entity attributes. 
• Document analysis may also be necessary when stakeholders are not
available to offer insight into existing business processes or systems.
Other Approaches
 Use Case Modeling
• A use case is a structure for documenting the functional requirements for a system, usually
involving software, whether that is new or being changed.
• Each use case provides a set of scenarios that convey how the system should interact with a
human user or another system, to achieve a specific business goal.
• Use cases typically avoid technical jargon, preferring instead the language of the end-
user or domain expert. Use cases are often co-authored by requirements engineers and
stakeholders.
• Use cases are deceptively simple tools for describing the behavior of software or systems. A
use case contains a textual description of the ways in which users are intended to work with
the software or system.
• Use cases should not describe internal workings of the system, nor should they explain how
that system will be implemented. Instead, they show the steps needed to perform a task
without sequential assumptions.
 Use Case Modeling
• A use case describes how a user uses a system to accomplish a particular goal.
• A use case diagram consists of the system, the related use cases and actors and
relates these to each other to visualize:
• what is being described? (system),
• who is using the system? (actors) and
• what do the actors want to achieve? (use cases),
Use cases help ensure that the correct system is developed by capturing the
requirements from the user’s point of view.
• A use case diagram is usually simple. It does not show the detail of the use cases:
• It only summarizes some of the relationships between use cases, actors, and systems.
• It does not show the order in which steps are performed to achieve the goals of each use
case.
 Example of Use Cases using Use Case
In the use case model
there are 4 actors:
Modeling Language (UML)
check-in
representative,
customs of destination
airport, passenger and
baggage
transportation.

They interact with the

system to achieve
various business goals,
as modeled by use
cases check-in,
automated check-in,
express check-in,
boarding and request
passenger list.
Use Case Example for a School Information
System
Use Case Steps
Use Case Description Login to enter the system
Actors Parents, Students, Teachers, Admin
Pre condition System must be connected to the network

Post Condition After a successful login a mail should be sent to the user mail id

Extensions 1a Invalid Username

System shows an error message

2b Invalid Password
System shows an error message

3c Invalid Password for 4 times

Application closed
 Methods for
Reducing Incomplete and Changing
Requirements
 Reducing Changes in Requirements
• A process has to be developed to ensure that there are not many
change requests at the later stages in the project
For this following techniques should be used:
• Prototyping: involves developing a working replica of the system or
some aspect of the system.
Prototyping is an effective tool for gaining an understanding of
requirements, determination the feasibility of requirements and
resolving user interface uncertainties
 Controlling Scope
• Joint Application Development (JAD)
Uses highly organized and intensive workshops to bring together
project stakeholders – sponsor, users, business analysts, programmers
etc.- to jointly define and design information systems
• CASE (Computer Aided Software and Engineering)
A process for identifying and modeling business events, who initiated
them and how the system should respond to them
JAD Session for Requirement Gathering
 CASE Tools
(Central Repository)
CASE tools can be broadly divided into
the following parts based on their use
at a particular SDLC stage:
Upper Case Tools - Upper CASE tools
are used in planning, analysis and
design stages of SDLC.
Lower Case Tools - Lower CASE tools
are used in implementation, testing
and maintenance.
Integrated Case Tools - Integrated
CASE tools are helpful in all the stages
of SDLC, from Requirement gathering
to Testing and documentation.
 Examples of Case Tools in Requirements phase
https://www.tutorialspoint.com/software_engineering/case_tools_overview.htm

• Document Tools
• Before the beginning of software process, documentation of the software project must
begin. This documentation must cover the all the software development life cycle phases
and the completion of the software development phase as well. The documents are
generated by the documentation tools for both technical and end users.
• Example: Doxygen, Adobe Robohelp, DrExplain etc.
• Analysis of Requirements
• Requirements gathering, inconsistency checks, diagrams inaccuracy, redundancies in the
data etc. can be checked using analysis tools.
• Example: For requirement analysis are Accept 360, Accompa, Casecomplete etc.
 Upper
CASE Tools
CASE Tools
• Diagram tools
• These tools are used to represent system components, data and
control flow among various software components and system
structure in a graphical form. For example, Flow Chart Maker tool for
creating state-of-the-art flowcharts.
• Process Modeling Tools
• Process modeling is method to create software process model, which
is used to develop the software. Process modeling tools help the
managers to choose a process model or modify it as per the
requirement of software product. For example, EPF Composer
 CASE Tools
• Analysis Tools
• These tools help to gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous omissions. For example,
Accept 360, Accompa, CaseComplete for requirement analysis, Visible Analyst for total
analysis.
• Prototyping Tools
• Software prototype is simulated version of the intended software product. Prototype
provides initial look and feel of the product and simulates few aspect of actual product.
• Prototyping CASE tools essentially come with graphical libraries. They can create
hardware independent user interfaces and design. These tools help us to build rapid
prototypes based on existing information. In addition, they provide simulation of
software prototype. For example, Serena prototype composer, Mockup Builder.
 CASE Tools
• Design Tools
• These tools help software designers to design the block structure of
the software, which may further be broken down in smaller
modules using refinement techniques. These tools provides detailing
of each module and interconnections among modules. For example,
Animated Software Design
• Repository
• CASE tools also help in providing a repository for project data. A
CASE tool’s database can be used to document and control
requirements
Method to collect requirements
• Although there are many ways to collect requirements, a 2011 study
(page 192) showed
• 73 percent of respondents felt that the most important challenge was to gain
understanding of what the customers wanted
• 70 percent of the respondents spent at least 10 percent of their time
managing changes, 30 percent spent more than 25 percent of time
• 83 percent of the development teams use Microsoft Word or Excel to
communicate requirements
• Respondents listed requirement collaboration and management software and
requirement modeling and visualization as two most software development
tools as being on their wish list
Tricks of the Trade
Methods for Improving User Input (page
212)
• Have users on the project team
• Some organizations require project managers to come from business area
• Locate users with developers
• Have regular meeting with users with fixed agendas
• Developers often assume they have understood user’s needs without getting feedback (so
regular meetings are required). Users should sign off on the requirements presented in
meetings
• Deliver something to project users and sponsors on regular basis
• This results in good feed back but what is delivered should work other wise the project
gets a bad name
• Do not make over promises
• Make sure the project schedule allows enough time to produce the deliverables
 How to control changing user Requirements
• When the customer found that project was going well s/he wanted more
requirements. The project manager adjusted the baselines to show that the
project would not meet its cost
• Ensure that project scope changes include associated cost and schedule changes,
appropriate level approval and emphasize completion dates (ask users what they
want to give up, in lieu of requested changes, to meet completion date)
• Emphasize completion date. Create a drop dead date and adjust everything
accordingly
• Allocate resources specifically to handling change requests (in one case the
project provided a function key by which users could ask for changes and
provisioned coders specifically for handling these changes)
Issues in Documenting
Requirements
 Documenting Requirements
• The format for documenting stakeholder requirements can be:
• Listing all requirements on a single sheet of paper
• Or on a roomful of books
• People who have worked on designing and construction of aero
planes indicate that “the weight of the requirement documents can
weigh more than the plane itself”
• Requirements should be broken down into functional requirements,
system requirements, performance requirements etc. and given an
ID number
Building Traceability
Requirement Traceability
Matrix (RTM)
(An Output of “Collecting Requirements”)
 What is Traceability?
https://web.archive.org/web/20100601214050/http://www.compaid.com/caiinternet/ezine/westfall-
bidirectional.pdf
• The IEEE Standard Glossary of Software Engineering Terminology defines
traceability as “the degree to which a relationship can be established
between two or more products of the development process, especially
products having a predecessor-successor or master-subordinate
relationship to one another.” [IEEE-610]
• Traceability is also used to track the relationship between each unique
product-level requirement and the work products to which that
requirement is allocated.
• For example, a single product requirement might result into: one or more
architectural elements, detail design elements, objects/classes, code units, tests
cases, user documentation topics, and/or even to people or manual processes that
implements that requirement
 What is traceability
• Traceability is used to track the relationship between each unique
product-level requirement and its source. For example, a product
requirement might trace from: a business need, a user request, a
business rule, an external interface specification, an industry standard
or regulation, or to some other source.
• Good traceability practices allow for bidirectional traceability,
meaning that the can be the traceability chains can be traced in
both the forwards and backwards directions as seen in the next
figure
Forward Traceability Backward Traceability
Tracing the Tracing each unique
requirements work product (e.g.,
sources to their design element,
resulting product object/class, code
requirement(s) to unit, test) back to its
ensure the associated
completeness of the requirement (and
product requirement also to source)
specification.
Backward traceability
The objective is to can verify that there
ensure that each is no gold plating (i.e.
requirement is the scope of the work
implemented in the has not increased by
product and that making requirements
eachrequirement is more complex).
thoroughly tested.
Good traceability practices allow for bidirectional traceability, meaning that
the can be the traceability chains can be traced in both the forwards and
backwards directions as seen in the next figure
Traceability is ensured using an Requirement
Traceability Matrix (RTM)
 Requirement Traceability Matrix (RTM)
https://reqtest.com/requirements-blog/requirements-traceability-matrix

• In a software development project, Requirements Traceability Matrix

(RTM) is a document which is used to validate that all the
requirements are linked to either their current status or test cases.
This helps to ensure that all the requirements will be covered in the
testing phase.
• A Requirements Traceability Matrix is usually in tabular format as it
holds multiple to and fro relationships between requirements and
test cases.
 Example of RTM
• Business Requirement R1
• A customer should be able to log in and log out of his account using the log in page and a business
manager who looks after the customer’s account should be able to log in from the same account.
• Technical Requirement
• TR1 A customer should be able to log in on the home page using a valid customer id consisting of user
id and pass word. Manager should also be able to log in on the same page
• TR2 User ID and password should not be blank
Test Cases
• TC 1 Use Customer ID 123 and password xyz for customer: success
• TC 2 Use Manager id 456 and password abc for manager: success
• TC 3 Keep only user id blank, then password blank, then both blank two fields blank and test log in:
failure
R1 TR1, TR2 TC1, TC2, TC 3
Requirement Traceability Matrix
(Forward)
Directionality of Traceability
Requirement Traceability Matrix (RTM)
• In Software Engineering, traceability matrix can be divided into three major component as
mentioned below:
• Forward traceability: This matrix is used to check whether the project progresses in the
desired direction and for the right product. It makes sure that each requirement is applied
to the product and that each requirement is tested thoroughly. It maps requirements to
test cases.
• Backward or reverse traceability: It is used to ensure whether the current product
remains on the right track. The purpose behind this type of traceability is to verify that we
are not expanding the scope of the project by adding code, design elements, test or other
work that is not specified in the requirements. It maps test cases to requirements.
• Bi-directional traceability ( Forward+Backward): This traceability matrix ensures that all
requirements are covered by test cases. It analyzes the impact of a change in
requirements affected by the defect in a work product and vice versa.  
 Forward Traceability
https://www.javatpoint.com/traceability-matrix

The forward traceability test

matrix is used to ensure that
every business's needs or
requirements are executed
correctly in the application and
also tested rigorously.

The main objective of this is to

verify whether the product
developments are going in the
right direction. In this, the
requirements are mapped into
the forward direction to the test
cases.
 Backward Traceability
https://www.javatpoint.com/traceability-matrix
Backward traceability is used
to check that we are not
increasing the scope of the
product by enhancing the
design elements, code, test
Backward
other things which are not
mapping shows
mentioned in the business
that if the Test
needs.
Cases have
The main objective of this
increased then
that the existing project
there is evidence
remains in the correct
of scope creep
direction. In this, the test
cases are mapped into the
backward direction to the
requirements.
 Backward Traceability

TC1 (Test Case 1) User Req 1, User Req 2

TC2 User Req 3,4
TC3 Uer Req 5,6
 Bi-Directional RTM
https://www.javatpoint.com/traceability-matrix

It is a combination of forwarding
and backward traceability matrix,
which is used to make sure that all
the business needs are executed in
the test cases.

It also evaluates the modification in

the requirement which is occurring
due to the bugs in the application.
Some people say that RTM should only
contain Id numbers and no words
Bi-Directional Traceability Matrix
Bi-Directional Traceability Matrix
 Bi-Directional RTM
• It establishes a relationship between two artifacts. And it’s important
to be able to trace from one item to the next and back again.
• That means tracing forward from requirements to source code to test
cases to test runs to issues.
• And from issues back to requirements. You should also be able to
trace back from requirements to business goals or objectives (to
answer why the requirement is there).
 After Collecting Requirements
Define Scope (i.e. Prepare a Scope
Statement)
 Project Scope Statement
• Characteristics As Defined by PMI
• Product Scope description
• User Acceptance Criteria
• Define the boundaries of the project.
• Define the business need and the expected outcome of the project.
• Identify business processes impacted by the project
• Identify constraints that limit a project team’s options for developing a
solution. 
• List assumptions regarding decisions outside the project team’s control.
• Identify internal and external entities with which the project team will
interface.
Boundaries
 Project Scope Statement(PSS)
• Detailed Project Scope statement should reference the functional
requirements and non functional requirements
• PSS is dynamic. As time progresses the scope of the project should
become more clear or specific. The statements should be labelled as
versions
• An up-to-date PSS is an important for developing and confirming a
common understanding of the project
Example of Scope Statement
For
E-Commerce Website Upgrade
Functional Requirements for Website
Upgrade
• Visual components (to make the website authentic and competitive)
•  Integration with payment and shipping systems
• Product rating (likes) and reviews
• Search tools, sorting, filtering, navigation, on the site (customer should be able to search by price,
reviews, size)
• Facility for linking of cart to promotions (discounts, coupons)
• Facility of purchase for unregistered users
• Email and news letter tools
• Linkage to social media
• Facility for Chat using a bot
• Availability on mobile
• Return form for unsatisfied buyers to fill out
 Non-Functional Requirements
• Performance: the website should load without delay
• Reliability: Uptime specifications (99.9%)
• Concurrency: Number of users that can simultaneously use the website
(20,0000 concurrent users)
• Security features: to protect credit card information as per PCIDSS
standards (The Payment Card Industry Data Security Standard -PCI DSS
is a set of requirements intended to ensure that all companies that
process, store, or transmit credit card information maintain a secure
environment)
• Ease of use (in navigation, filtering etc.)
Example Project Scope
Statement
See Next Side
Project Web Site upgrade
Scope Upgrade the existing web site of the company as per functional and non-functional requirements
to attract more customers and thereby increase sales and revenues.
The new website will be hosted on the company’s servers

Boundaries The project does not include upgradation of the company’s hardware. This will be done through a
separate project after observing the performance of the upgraded website on the existing
hardware. Also Recommendation System is outside the scope of work.

Deliverables New software with features as given in functional and non-functional requirements.
Module for Management of website such as adding new products and promotions
Training of IT staff on the Management module

Acceptance Sign off by the marketing staff and finance staff that all the deliverables have been delivered as per
criteria the functional and non-functional requirements

Constraints The development team does not have the requisite expertise in development of a chat bot and
training would have to be given to two members (with one acting as standby)

Assumptions The functional and non-functional requirements will be signed off by the marketing and finance
teams in one month
ITPM
Session 11
18.10.2022
 After Collecting Requirements and
Project Scope Statement
Prepare Work Break Down Structure
WBS
 Work Break Down Structure (WBS)
• After collecting requirements and defining scope the next step in scope
project management is to define the work break down structure (WBS)
• The WBS is a deliverable focused grouping of work involved in the project
• The WBS is a foundation document in project management because it provides
the basis of planning and managing project schedules, costs, resources and
changes
• The Project Management Body of Knowledge (PMBOK 5) defines the
work-breakdown structure as a "hierarchical decomposition of the
total scope of work to be carried out by the project team to accomplish
the project objectives and create the required deliverables."
 Creating a WBS
• The project scope management plan, scope statement, requirements
documents, enterprise environmental factors and organizational
process assets are the primary inputs
• The main tool or technique employed is DECOMPOSITION (divide the
scope into smaller groups of tasks) and expert judgement.
• There are summary tasks and work packages in a WBS:
• Summary tasks are just there for organizational purposes. Summary tasks do
NOT get estimated and delegated
• The work packages are where the actual work resides. Work packages get
estimated and delegated.
 Work Packages
• A work package is a task at the lowest level of WBS
• A work package should be defined at the proper level so the project manager
can clearly establish an estimate of the effort needed to:
• Complete it
• Estimate the cost of all required resources
• Evaluate the quality of the results when the work package is finished
• In the software, estimates of work time should be entered only at the work
package level
• The rest of the WBS items are groupings or summary tasks for the work packages
• The software will automatically calculates duration estimates for various WBS
levels based on data entered for each work package and WBS hierarchy
 Creating a WBS
• The project scope management plan, scope statement, requirements
documents, enterprise environmental factors(refer next slide) and
organizational process assets are the primary inputs
• The main tool or technique employed is DECOMPOSITION (divide the
scope into smaller groups of tasks) and expert judgement.
• There are summary tasks and work packages in a WBS:
• Summary tasks are just there for organizational purposes. Summary tasks do
NOT get estimated and delegated
• The work packages are where the actual work resides. Work packages get
estimated and delegated.
 Enterprise Environmental Factors (EEF)
• Enterprise environmental factors are the influences not under the control of the organization
or the project management team that affect the organization, the project, and its outcome.
Every organization has to exist and work within the EEF.
• These influences may have positive or negative impacts on your project constraints, though
often, the impact is negative.
• Enterprise environment factors can be either internal or external.
• Examples of external enterprise environmental factors are as follows:
• Government regulations
• Market conditions
• External political conditions
• Industry standards
• Legal restrictions
Visualization of WBS
• A WBS is often depicted as a deliverable oriented tree of tasks similar
to an organizational chart
• A chart form helps in visualization of the whole project and the main
parts
• A WBS can be organized around:
• Project Products
• Project phases (Concept, Design, Development, Roll out, Support)
• PMI Process Groups (Initiating, Planning, Executing, Controlling)
Visualizing a WBS
https://en.wikipedia.org/wiki/Work_breakdown_structure
WBS on the basis of Products
WBS for Mobile Application

1.

1.1 1.2 1.3 1.4 1.5

 Always include Project
Management Component in
WBS
 WBS with PMI Process Groups
(Recommended Approach)

Intranet Entire Project

Project Level 1

Level 2
1.1 1.2 1.3 1.4 1.5
Initiating Planning Executing M&C Closing

Level 3
1.1.1 1.1.2 1.1.3 1.3.2 1.3.3 1.3.5
1.3.1 1.3.4
Select Form Project Web site Web site Support
Concept Roll out
PM Team Charter design Development
WBS with Project Phases (TPLC contd.)

1.1.2 Define
Requirements Level 3

1.1.2.1Define 1.1.2.2Define 1.1.2.3 Define 1.1.2.4Define

User Content System Server Level 4
Requirements Requirements Requirements Requirement
 Tabular Form in PMI with Project at level 1
1 (Level 1) Intranet Project
1.1 (Level 2) Concept (decomposed to Evaluate current systems)
1.1.2 (Level 3) Evaluate Current systems
1.1.2.1 (Level 4) Define User Requirements
1.1.2.2(Level 4) Define Content Requirements
1.1.2.3 (Level 4) Define System Requirements
1.1.2.4(Level 4) Define Server Requirements

Tasks that are decomposed further are called summary tasks

What is a good WBS
 What is a Good WBS
• It is difficult to create a good WBS.
• To create a good WBS it is necessary to understand the project, its
scope, and incorporate the needs of the stakeholders
• If the decomposition is not done in detail the project risk may actually
be increased. For only if detailed decomposition is done is it possible to
accurately estimate duration and costs.
• However too much detail may result in missing the larger picture
• At the WBS stage the focus should be on what has to be done and not
when it has to be done or the sequencing of tasks (although data entry
in the software will demand both)
 What is a good WBS
• A WBS is not a statement or a narrative. The work breakdown structure is often
confused with scope statement. Both come early in a project’s life cycle. WBS is
an outline of work to be done.
• Exclude the Distractions and Details. A well-crafted WBS is worded to include all
of the work needed to complete the project and purposefully excludes all the
anticipated, but unnecessary, diversions and distractions that would slow it
down. Don’t include technical specifications or work instructions inside the
WBS. Don’t try to write the WBS using full sentences.
• Think deliverables. A WBS specifies the major and subordinate deliverables so it
is best to write it in terms of nouns as opposed to actions. Remember that
project approvals from a project sponsor, or executive management, are a
deliverable.
 Benefits of WBS

• Defines project scope.

• Defines a structure for project integration.
• Provides a foundation for estimation of resources, duration and costs.
• Provides proof of needed resources, time and money.
• Helps to prevent scope creep.
• Helps to integrate changes.
• Focuses the team on what needs to be done.
• Helps to identify risks.
• Provides context for any discussion.
 Benefits of WBS
• Helps with managing stakeholders expectations
• Helps to prevent changes
• Facilitates cooperation
• Gets team buy-in
• Provides ownership of a piece of the project
• Shows impact of each team member
• Shows global roles of a team member in the project.
Approaches to Developing
WBS
 Approaches to developing WBS
1. Using Guidelines
• Many organizations provide guidelines and templates for developing
WBS as well as examples from past projects
• PMI has developed a WBS Practice Standard for developing and
applying WBS to project management
2. Analogy Approach
• Use a similar project as a starting point
• Some organizations keep a repository of WBSs and other project
documentation on file to assist project managers
Approaches to developing WBS
3) Top Down Approaches
Top Down
• Start with the largest items in the project and break them down into smaller
components
• Refine the work into more and more detail
• After finishing the process resources should be assigned at the work package level
• Top level approach is suited to managers who have strong technical background and
high level picture approach
4) Bottom Up
• Team members identify as many specific tasks related to their project as
possible
 Approaches to developing WBS
4) Bottom Up Approach (contd.)
• They then aggregate them and organize them to higher level
(summary tasks)
• The bottom up approach can be very time consuming but also very
effective to create a WBS (e.g. hardware requirements. Software
requirements can be clubbed as “Define Requirements”)
• Project managers often use bottom up approach for projects that
represent (a) entirely new systems or (b) to help create buy in and
synergy in the project team
 Approaches to developing WBS
5) Mind Mapping
• Mind mapping is a technique that uses branches radiating from a core idea to
structure thoughts
• Mind mapping allows people to write or even draw pictures of tasks in a non-
linear format
• This more visual, less structured approach to defining and then grouping tasks
can unlock creativity among individuals and increase participation among
teams
• After discovering WBS items and their structure using the mind-
mapping technique, the information has to converted into tabular
form
Mind Map for Developing a WBS for a
project
Mind Map for one application
 Some Mind Mapping Tools
MindView by Matchware (www.matchware.com)
• MindView can be used for top down approach (listing the project in
the center and developing the braches or
• The separate mind maps developed for each deliverable can be
merged for bottom up approach (page 206)
• Mind Manager (www.mindmanager.com)
• Build flowcharts, concept maps, timelines, diagrams, and visualize
your data in any way that you can imagine. 
Important factors in developing WBS
• Consistency between the project charter, scope statement and WBS,
Gantt Chart should be ensured
• The customer as well as the project team should be involved in
creating the WBS
• If people who will do the work develop the WBS then every member
of the team has a good understanding of the project
• 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
• Each WBS item must be documented in a WBS dictionary
 WBS Dictionary
• A WBS dictionary is a document that provides detailed information about
each WBS item. A unit of work should appear at only one place
• Normally one paragraph should be used to describe each work package
• For a complex project an entire page or more might be needed for each of the
work package descriptions
• The term WBS dictionary should not be confused with glossary (it does not
describe acronyms). The WBS dictionary is a fairly detailed definition of the
work involved in the task
• A WBS dictionary enables all team members to have a common
understanding of the work involved for each work package. It helps in
bringing everyone on the same page
 WBS Dictionary
• While there is s no set format for a WBS dictionary, if the steps below are followed we get a
good WBS dictionary:
1. Identify item
2. Describe the item
3. State assumptions and constraints
4. Assign owner
5. Give start and end date
6.  List Resources
7. Calculate Cost
8. Define Quality
9. Acceptance Criteria
10. Technical References (If there are any guidelines, manuals, standards, etc.)
11. List Compliance (any contracts, corporate agreements and other documents that are part of the project)
12. Indicate Risk
 Work Packages
• A work package is a task at the lowest level of WBS. It is assigned to a specific
person who is accountable for its delivery.
• A work package should be defined so the project manager can clearly establish an
estimate of the effort needed to:
• Complete it
• Estimate the cost of all required resources
• Evaluate the quality of the results when the work package is finished
• In the software, estimates of work time should be entered only at the work package
level
• The rest of the WBS items are groupings or summary tasks for the work packages
• The software will automatically calculates duration estimates for various WBS levels
based on data entered for each work package and WBS hierarchy
Example of WBS in
Agile
Example of WBS in
Agile
 Use of WBS in Agile
1.0 Project

1. Feature 2.0 Feature 3.0 Feature

1.1 Epic 1 1.2 Epic 2 2.1 Epic 1 3.1 Epic 1 3.2 Epic 2

2.1.1 User story 1 2.1.2 User Story 2

Note: Tasks are
added in each
2.1.1.1 Task 1 2.1.1.3 Task 3 sprint (dynamic
2.1.1.2 Task 2
process)
Themes, Initiatives and Epics
Notes: Micro expressions are short facial expressions (with a duration between 1/5 and 1/25 of a second) that usually occur when people try to
hide their feelings (either consciously or unconsciously).
Smile to Pay technology allows consumers to purchase goods simply by posing in front of point-of-sale (POS) machines
equipped with cameras after linking an image of their face to a digital payment system or bank account.

Back Office
Front Office
Machine learning
Smile to pay facial
to detect fraud and
scanning to initiate
cybersecurity
transaction
attacks

Micro Biometric
Expression (voice , video,
Analysis with print) to
virtual loan authenticate
officers and authorize
Themes, Initiatives, Epics and Stories
• Theme: Digital Transformation
• Initiatives: (1) Facial Scanning for initiating payment transactions, (2)
Micro Expression Analysis with virtual loan officers, (3) Biometrics
(video, voice) for authentication and authorization (4) Machine
learning to detect fraud and cybersecurity attacks
• Initiative 4: Machine learning to detect fraud and cybersecurity
attacks
• Feature is a chunk of functionality which has business use.
• Features 1: Fraud detection for credit card
• Feature 2: Fraud detection for customer account
Themes, Initiatives, Epics and Stories
(contd.)
• Feature 1: Fraud detection for credit cards
• Epic1: Abnormality in credit card transaction
• Epic 2: Unauthorized access of user credentials
• Epic 1: Abnormality in credit card transactions
• Story1: As user I would like to be informed when transaction value is above normal
• Story 2: As user I would like to be informed when transaction number is above
normal
• Epic 2: Unauthorized access of user credentials
• Story 1: As user I would like to be informed if wrong password is given
• Story 2: As a user I would like my account to be suspended if three attempts are
made with wrong password
Validating Scope
Page 190 of Information Technology Management by Kathy Schwalbe

Process Groups

/validation

Initiating Planning Executing closing

 Validating Scope
• Involves formalizing a process for acceptance of the project deliverables
• Key project stakeholders such as customer and sponsor of the project
inspect and then formally accept the project deliverables with a sign off
• To receive formal acceptance of the project scope the project team must
develop clear processes and documentation to evaluate whether the
project’s products were completed correctly and satisfactorily
• The key benefit of this process is that it brings objectivity to the acceptance
process and increases the chance of final product, service, or result
acceptance by validating each deliverable.
 Validating Scope
• The main tools and techniques for scope validation are inspection and
group decision making
• The main inputs are: scope management plan, RTM, deliverables (as
validated by sponsor)
• The main outputs of the process are accepted deliverables, change
requests, work performance information, and updates to project
documents
• The visual details are in the next slide
https://www.oreilly.com/library/view/a-guide-to/9781935589679/sub5.5.xhtml
https://www.oreilly.com/library/view/a-guide-to/9781935589679/sub5.5.xhtml
 Scope Validation (By using Product
Configuration Management)
• The project team may rely on configuration management specialists
to audit the functional and physical characteristics of the project’s
products
Product Configuration Management
• Identify and document the product’s characteristics,
• Control any changes to such characteristics,
• Record and report the changes and audit the products to verify conformance
to requirements.
Project Configuration Management
• project configuration management: 
• The collective body of processes, activities, tools and methods
project practitioners can use to manage items during the project life
cycle. 
• But here we require product configuration management
Controlling Scope
 Controlling Scope (1/5)
• Due to progressive elaboration change is inevitable in projects
specially in scope of IT projects
• Users are not sure how they want the screen to look like or what functionality
they will need to improve business performance
• Developers are not exactly sure how to interpret user requirements
• Scope Control involves managing changes to the project scope while
keeping project goals and business strategy in mind
• The details inputs, tools and techniques and output are given in the
next three slides slide
 Controlling Scope (2/5)
• Inputs
• Requirements documentation, requirements traceability matrix, work
performance data, organizational process assets
• Tool used for performance of scope control:
• Variance Analysis
• Variance is the difference between planned and actual performance
• Outputs
• Work performance information
• Change requests
• Project management plan updates
• Project document updates
Controlling Scope(3/5)
 Tool for Scope Control-Variance Analysis
(4/5)
Variance Analysis
• Variance is the difference between planned and actual performance.
• We can use variance to impress upon the client
• That there are too many change requests
• The number of requirements have grown
• That many change requests have been met
• That the remaining change requests cannot be met without affecting
time or cost
Controlling Scope (5/5)
ICC From Integration
Management
 Performing Integrated Change Controls
(Monitoring and Controlling Process Group)
• Change Control on IT projects
• Beginning 1990s it was realized that project management is a process
of constant communication and negotiation about project objectives
and shareholder expectations
• The assumption is that changes could be beneficial to some projects
(e.g. if there is improvement in hardware or software technology).
• Some changes while making sense may be so large that they cannot
be accommodated into the current project scope. So if an
organization wants to meet time and cost goals it must control
changes to project scope.
 Performing Integrated Change Control
Even if the project team is flexible, it is important that projects must have a
formal system of change control
Integrated change control involves:
• Influencing the factors that create changes to ensure that changes are beneficial.
(That a change helps in meeting project scope, schedule, cost, quality cost etc.)
• Determining that the change has occurred the PM should know the status of key
project areas at all times. In addition the PM should also communicate the same
to top management as they do not like surprises relating to scope, time or cost
• Managing actual changes as they occur: Managing change is a key role of project
managers and their teams. It is important that project managers exercise
discipline managing the project to minimize the number of changes that occur
 Change Control System
• A change control system is a formal documented process that
describes when and how official project documents may be changed.
• A change control board (CCB) is a formal group of people responsible
for approving or rejecting changes to a project. An organization could
have key stakeholders for the entire organization on this board
• The primary function of the CCB is to
• prepare guidelines for preparing change requests
• evaluating change requests
• managing the implementation of approved changes
 Change Control System
• Limitations of CCB
• CCBs meet only once a week or once a month
• May not make decision in one meeting
So some companies apply the guillotine process (48 hours deadline)
• Use Configuration Management in ICC
• Configuration Management ensures that the descriptions of project’s products are
correct and complete
• Members of the project team are frequently designated as configuration
management specialists.
• Their job is to identify and document the functional and physical characteristics,
record and report changes and audit the project and report conformance to
requirements
 Role of Communications
• The inputs to change control process are all the documents in the project plan
along with change requests, work performance information, enterprise
environment factors, and organizational process assets.
• The outputs are approved change requests, change log, updates to the PMP.
• While documents are important the most critical factor for the success of
integrated change control (ICC) is good communications.
• Besides written or formal communication oral and informal communications are
important.
• Some project managers have stand up meetings once a week or every morning
with all team leaders
 Summary: Suggestions for ICC
• View project management as a process of constant communication
and negotiation
• Plan for change
• Establish a formal change control system, including change control board
(CCB)
• Use effective configuration management
• Define procedures for making timely changes for small changes
• Use Project Management software to help manage and communicate
changes
• Focus on leading the project team and meeting the overall project goals and
expectations
Work Packages and
Activities
 Work Packages
• A work package is a task at the lowest level of WBS
• A work package should be defined at the proper level so the project manager
can clearly establish an estimate of the effort needed to:
• Complete it
• Estimate the cost of all required resources
• Evaluate the quality of the results when the work package is finished
• In the software, estimates of work time should be entered only at the work
package level
• The rest of the WBS items are groupings or summary tasks for the work packages
• The software will automatically calculates duration estimates for various WBS
levels based on data entered for each work package and WBS hierarchy
 Tabular Form in PMI
1 (Level 1) Intranet Project
1.1 (Level 2) Concept (decomposed to Evaluate current systems, Define
Requirements, Define specific functionality etc.)
1.1.2 (Level 3) Evaluate Current systems
1.1.2.1 (Level 4) Define User Requirements
1.1.2.2(Level 4) Define Content Requirements
1.1.2.3 (Level 4) Define System Requirements
1.1.2.4(Level 4) Define Server Requirements

Level 4 tasks are work packages. Those tasks that are decomposed further are called
summary tasks
 Work Packages
Project Management (Gray, Clifford Desai)

• Each work package in the WBS:

• Defines work (what)
• Identifies time to complete a work package (how long)
• Identifies a time-phased budget to complete the work (cost)
• Identifies resources needed to complete the work package (how much)
• Identifies a single person responsible for units of work (who)
• Identifies monitoring points for measuring progress (how well)
Difference between work package and
activity
Work Package Activity
It is one of the lowest level of deliverables in a It is a means to create a deliverable. A series of
project. activities results in a lowest level of deliverable.
It is the result or outcome of an endeavor. It is one step of the endeavor.
It fulfills a portion of project and provides An activity, in itself, does not provide any value to the
part satisfaction and some value to the project project stakeholders.
stakeholders.
A deliverable has a tangible value and it is It cannot be handed over to the project stakeholders.
generally handed over to the project stakeholders.
It is generally defined using a noun(outcome) e.g. It is generally defined using a verb(work to be done)
‘Module X’. e.g. ‘testing’.
 Examples of Work Packages and Activities
Construction
• Building Construction Project – Let us assume that project team has
created a WBS with building floors as work packages. Completion of
all floors will result in the completion of the Building. One such floor
could be “Floor N” – it would be a work package.
• Project Team will have to perform series of Activities to construct
“Floor N”. These Activities might include Floor laying, Wiring, Painting,
Inspection etc. Project Team might have to repeat these activities
until delivery ready “Floor N” is completed.
 Examples of Work Packages and Activities
IT
• Let us take a look at two examples to understand the difference further.
• Software Development Project – Let us assume that project team has
created a WBS with software modules as work packages. Integration of
all modules will result in the completion of the software product. One
such module could be “Module X” – it would be a work package. Project
Team will have to perform series of Activities to create “Module X”.
• These Activities might include Algorithm Writing, DB preparation,
Coding, Testing, Integration etc. Project Team might have to repeat
these activities until delivery ready “Module X” is created.
 Summarizing
https://www.pmbypm.com/work-package-vs-activity/#:~:text=A%20work%20package%20is%20comprised,an%20Activity%20or%20vice%2Dversa .
• “A series of actions results in a (creates) a Work Package”.
• These actions are, in fact, the Activities performed by the project
team.
• In simple terms we can say that series of activities creates a Work
Package. An Activity, in itself, may not produce any tangible outcome
but a series of Activities would result into a deliverable.
https://www.youtube.com/watch?v=WwNdq2PNelQ
Thank You
Controlling Scope(3/5)
Controlling Scope(3/5)