this presentation describes how project scope can be management keeping in view the different factors of project management process

1. Project Scope Management

2. Scope
 Project scope management is one of the most critical project
management knowledge (skill) areas
 Scope defines
 All the work that is required to complete the project
successfully and
 Only the work that is required, no more, no less
 This latter point is critical: project scope management
defines and controls what is and is not part of the project
work

3. Project Scope Management
 It includes the processes required to ensure that the
project includes all the work required, and only the work
required, to complete the project successfully.
 Scope refers to all the work & only the work involved in
creating the products of the project and the processes used
to create them.
 A deliverable is a product produced as part of a project,
such as hardware or software, documents etc.

4. Project Scope Management
 Scope Management means:
 Constantly check to make sure you are completing all the
work.
 Not letting people randomly add to the scope of the
project without a structured change control system.
 Making sure all changes fit within the project charter.
 Defining and controlling what is and is not included in the
project.
 Preventing extra work or gold plating: You should give
the customer what they asked for, no more and no less.
Giving any extras is a waste of time and adds no benefit to
the project!

5.  Components of Project Scope Management
1. Plan Scope Management
2. Collect Requirements
3. Define Scope
4. Create WBS
5. Validate Scope
6. Control Scope
Project Management Process Groups
Knowledge Areas
Initiating Planning Executing
Monitoring &
Controlling
Closing
5. Project Scope
Management
1. Plan Scope Management
2. Collect Requirement
3. Define Scope
4. Create WBS
5. Valide Scope
6. Control Scope
Project Scope Management

6. Components of Project Scope Management
1. Plan Scope Management: The process of creating a scope
management plan that documents how the project scope will be
defined, validated and controlled.
2 Collect Requirements: the process of determining, documenting
and managing stakeholder’s needs to meet the project objectives.
3 Define Scope: the process of developing a detailed description of
the project and the product.
4 Create WBS: the process of subdividing the project deliverables and
the project work into smaller, more manageable components.
5 Validate Scope: the process of formalizing acceptance of the
completed project deliverables.
6 Control Scope: the process of monitoring the status of the project
and product scope and managing changes to the scope baseline.

7. Project Scope Management
In the project context, the term “scope” can refer to:
Product scope. The features and functions that characterize a
product, service, or result.
Project scope. The work performed to deliver a product, service, or
result with the specified features and functions. The term “project scope”
is sometimes viewed as including product scope.
Completion of the project scope is measured against the PMP, while
completion of the product scope is measured against the product
requirements.
The term “requirement” is defined as a condition or capability that is
required to be present in a product, service, or result to satisfy an
agreement or other formally imposed specification.
Key Trends & Tailoring
Concepts Practices considerations
Considerations for
Agile/Adaptive environments

8. Eliciting (extracting), documenting, and managing stakeholder
requirements takes place within the Project Scope Management
processes. Trends and emerging practices for Project Scope
Management include a focus on collaborating with business
analysis professionals to:
Determine problems and identify business needs;
Identifyand recommend viable solutionsfor
meeting those needs;
Elicit, document, and manage stakeholder requirements in order to
meet business and project objectives;
Facilitate the successful implementation of the product, service, or end
result of the program or project.
Key
Concepts
Tailoring
considerations
Considerations for
Agile/Adaptive environments
Trends &
Practices
Project Scope Management

9. Considerations for tailoring include but are not limited to:
Knowledge and requirements management. Does the organization have
formal or informal knowledge and requirements management systems? What
guidelines should the PM establish for requirements to be reused in the future?
Validation and control. Does the organization have existing formal or
informal validation and control-related policies, procedures, and
guidelines?
Development approach. Does the organization use agile approaches in
managing projects? Is the development approach iterative or incremental?
Is a predictive approach used? Will a hybrid approach be productive?
Stability of requirements. Are there areas of the project with unstable
requirements? Do unstable requirements necessitate the use of
lean, agile, or other adaptive techniques until they are stable and well
defined?
Governance. Does the organization have formal or informal audit and
governance policies, procedures, and guidelines?
Key Trends & Tailoring
Concepts Practices considerations
Considerations for
Agile/Adaptive environments
Project Scope Management

10. In projects with evolving requirements, high risk, or significant
uncertainty, the scope is often not understood at the beginning of the
project or it evolves during the project.
Agile methods deliberately spend less time trying to define and agree
on scope in the early stage of the project and spend more time
establishing the process for its ongoing discovery and refinement.
Many environments with emerging requirements find that there is
often a gap between the real business requirements and the business
requirements that were originally stated. Therefore, agile methods
purposefully build and review prototypes and release versions in
order to refine the requirements. As a result, scope is defined and
redefined throughout the project. In agile approaches, the requirements
constitute the backlog.
Key
Concepts
Tailoring
considerations
Considerations for
Agile/Adaptive environments
Trends &
Practices
Project Scope Management

11. Creating a scope management plan that documents how the
project scope will be defined, validated and controlled.
It starts with the
Project charter and
the approved
subsidiary plans
Project Scope Management

12. Plan Scope Management
Focus of Plan Scope Requirements
You must plan in advance, how you will determine the scope. This is part of your scope
management plan.
Scope must be defined, clear, and formally approved before work starts.
Requirements are gathered from all the stakeholders.
Requirements gathering can take a substantial amount of time, especially on large projects
that may require you to obtain requirements from hundreds of stakeholders.
A work breakdown structure (WBS) is used on all projects. A side benefit of this tool is that you
may find additional scope and be able to clarify identified scope when you create WBS.
While the project is being completed, you must check to make sure you are doing all the work
but only the work included in the PMP.
Any change to scope must be evaluated for its effect on time, cost, risk, quality, resources and
customers satisfaction
“Gold plating” in project is not allowed
No changes to scope are allowed without an approved change request.
Scope changes should not be approved if they relate to work that does not fit within the project
charter
You need to clearly understand what is and is not included in the project.

13. Plan Scope Management
Inputs Tools & Techniques Outputs
1. Project charter
2. Project
management plan
• Quality
management
plan
• Project life cycle
description
• Development
approach
3. Enterprise
environmental
factors
4. Organizational
process assets
1. ExpertJudgment
2. Dataanalysis
• Alternatives analysis
1. Meetings
1. Scope
management plan
2. Requirements
management plan

14. Tools & Techniques
Plan Scope Management
Input Output
2. Project Management Plan
Project management plan components include:
 Quality management plan. The way the project and product
scope will be managed can be influenced by how the
organization’s quality policy, methodologies, and standards are
implemented on the project.
 Project life cycle description. The project life cycle
determines the series of phases that a project passes through from
its inception to the end of the project.
 Development approach. The development approach defines
whether waterfall, iterative, adaptive, agile, or a hybrid
development approach will be used.

15. Tools & Techniques
Plan Scope Management
Input Output
1. Scope Management Plan
The Scope Management Plan describes the processes needed to be
implemented to manage the scope:
 Process for preparing a project scope statement;
 Process that enables the creation of the WBS from the detailed
project scope statement;
 Process that establishes how the scope baseline will be
approved and maintained;
 Process that specifies how formal acceptance of the completed
project deliverables will be obtained.
 The scope management plan can be formal or informal, broadly framed
or highly detailed, based on the needs of the project.
 It becomes an important part of the PMP and important input to the
other scope management processes.

16. Tools & Techniques
Plan Scope Management
Input Output
2. Requirements Management Plan
Describes how the requirements will be analyzed, documented and
managed. The components of the requirements management plan
include:
 How requirements activities will be planned, tracked, and
reported;
Configuration management activities such as: how changes will be
initiated; how impacts will be analyzed; how they will be traced,
tracked, and reported; as well as the authorization levels required to
approve these changes;
Requirements prioritization process;
Metrics that will be used and the rationale for using them;
Traceability structure that reflects the requirement attributes
captured on the traceability matrix.

17. Scope planning
 Scope planning is concerned with choosing the most
appropriate, most effective approach to managing the scope
of the project
 Scope planning defines how to:
 Define the scope
 Develop the detailed project scope statement
 Define and develop the WBS
 Verify project scope
 Control project scope
 Scope planning takes two primary inputs: the project charter
and the preliminary project scope statement
 Scope planning results in a project scope management plan

18. Project detailed scope statement
 The project detailed scope statement is an evolved version
of the preliminary project scope statement
 Content (template) requirements are identical to the
preliminary version
 Actual content of the detailed scope definition should reflect
any additional information gathered since preliminary scope
statement

19. Inputs, tools & techniques, and outputs
Inputs
 Project management plan
 Project Charter
 Enterprise environmental factors
 Organizational process assets
Tools & Techniques
 Expert judgment
 Meetings
Outputs
 Scope management plan
 Requirements management plan
19 of 101

20. Scope management plan
 According to PMBOK: “The scope management plan can be
formal or informal, broadly framed or highly detailed, based
on the needs of the project.”
 This course adopts the informal, broadly-framed perspective
 The components of a scope management plan include:
 Process for preparing a detailed project scope statement
 Process that enables the creation of the WBS from the detailed
project scope statement
 Process that establishes how the WBS will be maintained and
approved
 Process that specifies how formal acceptance of the completed
project deliverables will be obtained
 Process to control how requests for changes to the detailed project
scope statement will be processed—this process is directly linked to
the Perform Integrated Change Control process
20 of 101

21. Requirements management plan
 Components of the requirements management plan can
include, but are not limited to:
 How requirements activities will be planned, tracked, and reported
 Configuration management activities such as:
» How changes to the product will be initiated
» How impacts will be analyzed, how they will be traced, tracked,
and reported
» Authorization levels required to approve these changes
 Requirements prioritization process
 Product metrics that will be used and the rationale for using them
 Traceability structure to reflect which requirement attributes will be
captured on the traceability matrix
21 of 101

22. Plan Scope Management: Data Flow Diagram
22 of 101

23. Process: Collect Requirements
 An American Co. namely Standish Group reported critical
analysis of project scope in 2019 and determined that:
» Requirements are unclear, incomplete, or the project
management methodology does not accommodate changing
requirements effectively
 Collecting initial requirements is a critical first step in
managing requirements over the course of the project
 In an iterative/incremental or adaptive/agile project, requirements
collection continues throughout the life cycle of the project
 Requirements elicitation and analysis requires a complete
course.
23 of 101

24. Types of requirements
 Business requirements. Describe the high-level needs of the
organization as a whole
 Examples: Increase e-commerce purchases by 25%
 Stakeholder requirements. Describe the needs of a particular
stakeholder, especially with respect to external stakeholders
 Example: As the site owner, I want the site supply chain applications
to interface with the Web site
 Functional requirements.* Describe the behavior of the product
 Example: As a retail customer, I want to be able to shop by brand or
product category
 Nonfunctional requirements.* Describe the behavioral qualities required
for the product to be effective
 Example: As the Web site owner, I want the site to be available
99.99% of the time over a 1-year period
24 of 101

25. Types of requirements
 Transition requirements. Describe temporary capabilities,
such as data conversion and training requirements, needed
to transition from the current to the future state
 Example: As a data entry clerk, I want to be able to use the keyboard
shortcuts from the previous order system, so that I can maintain my
level of productivity
 Project requirements. Describe the actions, processes, or
other conditions the project needs to meet
 Example: Project must use the hybrid plan-driven, iterative and agile
methodology
 Quality requirements. Capture condition or criteria needed
to validate the successful completion of a project deliverable
 Example: As the site owner, I want a retail customer test group to be
able to successfully search for and find a requested product within
30 seconds
25 of 101

26. Inputs, tools & techniques, and outputs
26 of 101

27. Requirements documentation
 Business requirements
 Business and project objectives
 Business rules for the performing organization
 Guiding principles of the organization.
 Stakeholder requirements
 Impacts to other organizational areas
 Impacts to other entities inside or outside the performing
organization
 Stakeholder communication and reporting requirements.
27 of 101

28. Requirements documentation
 Solution requirements
 Functional and nonfunctional requirements
 Technology and standard compliance requirements
 Support and training requirements
 Quality requirements
 Reporting requirements
 Project requirements
 Levels of service, performance, safety, compliance, etc.
 Acceptance criteria
 Transition requirements
 Requirements assumptions, dependencies, and constraints
28 of 101

29. Project Considerations
 Is infrastructure setup part of your project?
 Assumptions
 What are you counting on?
 These can be critical to identify
 Resources expected: equipment/people, approvals
 Availability of partners, connections
 Delineate key limits:
» For example: System load: expect a maximum of 100
users
29 of 101

30. Overview
 The Define Scope process develops a detailed description
of the project and product
 Implicit (and stated) in the Define Scope process is the
assumption that not all of the requirements collected in the
Collect Requirements process may be included in the
project
 Though compatible with an adaptive/agile methodology, this
assumption represents a less-flexible approach to managing
requirements and scope
 The Project Scope Statement describes the project scope,
major deliverables, assumptions, and constraints
30 of 101

31. Tools and techniques
 Product analysis. Product analysis is the process of
translating high-level product descriptions into tangible
deliverables. Product analysis in IT includes techniques
such as:
 System analysis
 Requirements analysis
 Systems engineering
 Alternatives identification. Attempts to uncover alternative
approaches to executing and performing the project work,
using techniques such as brainstorming and mind mapping
 Alternatives provide contrasting options to the planned approach,
allowing better definition of scope
31 of 101

32. Project scope statement
 The project scope statement documents the entire scope, including
project and product scope
 Project scope encompasses product scope plus the work required to
create the product: any project-related activities, such as
documentation delivery and training
 Product scope encompasses the functional and non-functional
requirements for the final project deliverable
 The project scope statement provides a common understanding of the
project scope among project stakeholders
 The project scope statement may contain explicit scope exclusions that
can help to manage stakeholder expectations
 This can prevent the project from straying from the original vision in
all project cycle methodologies: sequential, iterative/incremental, and
adaptive/agile
32 of 101

33. Project scope statement
 Project scope statement. The project scope statement
contents include:
 Product scope description. Progressively elaborates the
characteristics of the product described in the project charter and
requirements
 Product acceptance criteria. Conditions required for acceptance of
deliverables
 Project deliverables. Deliverables include both product outputs and
project outputs, such as project reports and documentation
 Project exclusions. Identifies what is excluded from project
 Project constraints. Lists and describes anything that limits the
project team's options, such as budget, imposed schedule,
milestones, etc.
 Project assumptions. Lists and describes anything assumed to be
true with respect to the scope and impact if these prove to be false
33 of 101

34. Project document updates
 Results of the Define Scope process may affect other
project documents, including:
 Stakeholder register
 Requirements documentation
 Requirements traceability matrix [not discussed]
34 of 101

35. Process: Create WBS
 WBS – Work Breakdown Structure. Technique for
describing all work in a project.
 PERT – Program Evaluation and Review Technique. A well-
entrenched technique for scheduling.
 CPM – Critical Path Method. Used with PERT to determine
problems in scheduling.
 Gantt Charts – bar chart that graphically displays project
schedule
35 of 101

36. The Work Breakdown Structure
 The Work Breakdown Structure (WBS) is a hierarchical
description of the work that must be done to complete the
project as defined in the Project Overview Statement (POS).
 The WBS terms
 Activity: An activity is simply a chunk of work.
 Task: A task is a smaller chunk of work.
 Milestone: a task of zero duration. Usually an external
event. Can be used to mark completion of an activity or
phase.
36 of 101

37. Overview: Tasks
 Planning and scheduling use tasks as the basic element.
 Sometimes this is known as activities.
 The main tool for activity definition is decomposition
Divide and Conquer
 Decomposition is the process of breaking the project scope and
deliverables into smaller, more manageable components
 These more manageable components are called work packages
 Work packages are the lowest level of decomposition in the WBS
 Reliable time, cost, and resource estimates can be made at the level of
work packages in a project
 ‘Work’ in the context of the WBS means work products or deliverables,
not the effort itself, as in ‘staff-hours of effort’
37 of 101

38. Decomposition
 Decomposition is usually performed in a top-down, hierarchical manner
as expressed by the Work Breakdown Structure (WBS)
 Creating the Work Breakdown Structure (WBS) is the process of
decomposing project deliverables and work into smaller, more
manageable components
 The level of detail for work packages vary depending on project size and
complexity
 As we have seen, for IT projects using the agile process we have
defined, each iteration (sprint) defines one or more work packages
38 of 101

39. Overview: Tasks
 Decomposition is the core tool and technique of all WBS effort
 The WBS is:
 Structured hierarchically: each successively lower level represents a
more-detailed definition of project work
 Deliverable-oriented: each lower level represents a more detailed
definition of project work
 A representation of project scope: it organizes and defines the total
scope of the project
 The lowest level of detail in the WBS is the work package
 Work packages are scheduled, cost estimated, monitored, and
controlled
 Decomposition proceeds until it is possible to define the component as a
work package:
 A deliverable or work component at the lowest WBS level that
includes schedule activities and milestones to complete the
deliverables or ‘work’
39 of 101

40. Work Breakdown Structure
 A Work Breakdown Structure (WBS) captures all the work of
a project in an organized way.
 Portrayed graphically as a hierarchical tree,
 A tabular list of "element" categories and tasks or the
indented task list that appears in your Gantt chart
schedule.
 Breaking Large, complex projects into progressively smaller
pieces
 A collection of defined "work packages" that may include
a number of tasks.
 Continue to refine work until packages are of a suitable
size
 A work package can include design, coding, testing, etc.
40 of 101

41. Decomposition activities
 Identify and analyze the deliverables and related work
 The project scope statement provides the basis for the first
iteration of deliverable identification
 Structure and organize the WBS according to an
appropriate high-level hierarchy
 For IT projects using an iterative system development model, a
phase/iteration/discipline hierarchy most closely matches the
relevant process
 Note that one of the disciplines in the iterative process is ‘Project
Management’– it is here that appropriate project management
processes may be entered
 Decompose the upper WBS levels into lower-level
detailed components
 If appropriate, larger deliverables may be decomposed into smaller
deliverables, all the way down to the work package level
41 of 101

42. Decomposition activities
 Develop and assign identification codes to the WBS components
 Note that each item in the WBS has both a unique identifier (the
code or account identifier) and a WBS code
 The unique identifier does not change if a component is moved
about in the WBS structure; however, the WBS code does change
 Verify that the amount of decomposition of work is necessary and
sufficient
 This can be translated into a simple concept: the ‘just right’
principle
 The just right principle states that no more decomposition is
needed–it would be too detailed–and any less decomposition
would be too coarse
 Insufficient decomposition leads to reduced ability to plan,
manage, and control the work
 Excessive decomposition leads to wasted effort and decreased
efficiency
42 of 101

43. The Work Breakdown Structure
GOAL
Activity Activity
Activity
Activity Activity
Activity
Level 1
Level 2
Activity
Task #1 Task #2 Task #3 Task #4 … Task #n
43 of 101

44. 1. Breaks project into a hierarchy.
2. Creates a clear project structure.
3. Avoids risk of missing project
elements.
4. Enables clarity of high level planning.
Work Breakdown Structure

45. Uses for the WBS
 Thought process tool:
 The WBS is a design and planning tool.
 It helps the project manager and the project team
visualize exactly how the work of the project can be
defined and managed effectively.
 Architectural design tool:
 The WBS is a picture of the work of the project and how
the items of work are related to one another.
45 of 101

46. Uses for the WBS
 Planning tool:
 In the planning phase, the WBS gives the project team a
detailed representation of the project as a collection of
activities that must be completed in order for the project
to be completed.
 It is at the lowest activity level of WBS that we will
estimate effort, elapsed time, and resource requirements;
build a schedule of when the work will be completed; and
estimate deliverable dates and project completion.
46 of 101

47. Uses for the WBS
 Project status reporting tool.
 The WBS is used as structure for reporting project status.
 The project activities are consolidated from the bottom as
lower-level activities are completed.
 Completion of lower-level activities cause higher-level
activities to be partially complete.
 Therefore, WBS defines milestone events that can be
reported to senior management and to the customer.
47 of 101

48. Six Criteria to Test for Completeness in the WBS
 The WBS is developed as part of a Joint Planning session.
But how do you know that you've done this right? Each
activity must possess six characteristics to be considered
complete – that is, completely decomposed. The six
characteristics are
1. Status/completion is measurable
2. Start/end events are clearly defined
3. Activity has a deliverable
4. Time/cost is easily estimated
5. Activity duration is within acceptable limits
6. Work assignments are independent
» Let us review each one in detail …
48 of 101

49. Six Criteria to Test for Completeness in the WBS
 Measurable Status: The project manager can ask for the
status of an activity at any point in time during the project. If
the activity has been defined properly, that question is
answered easily.
 Example: a system's documentation is estimated to be
about 300 pages long and requires approximately four
months of full-time work to write, here is a possible report
that a developer can provide regarding the status:
“I’ve written 150 pages, so I guess I am 50 percent
complete.”
49 of 101

50. Six Criteria to Test for Completeness in the WBS
 Bounded:
 Each activity should have a clearly defined start and end
event.
 Once the start event has occurred, work can begin on the
activity.
 The deliverable is most likely the end event that signals
work is closed on the activity.
» For example, using the systems documentation
example, the start event might be notification to the
team member who will manage the creation of the
systems documentation that the final acceptance tests
of the systems are complete. The end event would be
notification to the project manager that the customer
has approved the systems documentation.
50 of 101

51. Six Criteria to Test for Completeness in the WBS
 Deliverable
 The result of completing the work that makes up the
activity is the production of a deliverable.
 The deliverable is a visible sign that the activity is
complete.
 This could be an approving manager's signature, a
physical product or document.
 Cost/Time Estimate
 Each activity should have an estimated time and cost of
completion.
 Being able to do this at the lowest level of decomposition
in the WBS allows you to aggregate to higher levels and
the total project cost and the completion date.
51 of 101

52. Six Criteria to Test for Completeness in the WBS
 Activity Independence
 It is important that each activity be independent. Once
work has begun on the activity, it can continue
reasonably without interruption and without the need of
additional input or information until the activity is
complete.
 Though it is possible that an activity could be scheduled
during different times based on resource availability.
52 of 101

53. Approaches to Building the WBS
 There are many ways to build the WBS. There is no one
correct way to create the WBS. Hypothetically, if we put
each member of the JPP session in a different room and
asked that person to develop the project WBS, they might
all come with different answers.
 There are three general approaches to building the WBS:
1. Noun-type approaches.
2. Verb-type approaches.
3. Organizational approaches
53 of 101

54. Approaches to Building the WBS
 Noun-type approaches. Noun-type approaches define the
deliverable of the project work in terms of the components (
physical or functional) that make up the deliverable.
 Verb-type approaches. Verb-type approaches define the
deliverable of the project work in terms of the actions that
must be done to produce the deliverable. These include the
design-build-test-implement and project objectives
approaches.
 Organizational approaches. Organizational approaches
define the deliverable of the project work in terms of the
organizational units that will work on the project. This type of
approach includes the department, process, and geographic
location approaches.
54 of 101

55. WBS and Gantt Chart in Microsoft Project
55 of 101

56. Importance of Phases
 The end of each phase should be a milestone
 The end of each significant task should be a milestone
 These can define your management review points
 “Phase exits” or “kill points”
 Ensure continued alignment with goals
 Form of Validation & Verification (V&V)
 Milestones should be entered into the WBS as a zero
duration task such as “approve project plan”
56 of 101

57. Work Breakdown Structure (WBS)
 Recall the definition from the PMBOK Guide:
 “The WBS is a deliverable-oriented hierarchical
decomposition of the work to be executed by the project
team to accomplish the project objectives and create the
required deliverables.”
 WBS is the primary tool for managing the scope of a project
 Work in the WBS is within scope
 Work not in the WBS is out of scope
 Though relatively simple, considered the single most
important project management tool
 In WBS, levels represent different levels of project
decomposition
57 of 101

58. The 100% rule
 The 100% rule is one of the most important principles guiding
development, decomposition, and evaluation of the WBS
 Rule states that the WBS:
 Includes 100% of the work defined by the project scope
 Captures all internal, external, and interim deliverables in
terms of work to be completed, including project management
 Rule applies at all levels within the hierarchy: the sum of the work
at the “child” level must equal 100% of the work represented by
the “parent”
 WBS should not include any work that falls outside the actual
scope of the project, that is, it cannot include more than 100% of
the work
58 of 101

59. Conventional WBS levels
 Level 1
 Project name
 Level 2
 Major subsystems of the project
 Level 3
 Components/task activities of subsystems at Level 2
 Level 4
 Subcomponents/subtasks of components/tasks at Level 3
 Level 5
 Work packages for subcomponents/subtasks at Level 4
 Work packages are where the actual work takes place
 Assigned to a person and given a schedule and budget
Note that conventional WBS
decomposition levels are
product-oriented
59 of 101

60. Criticisms of conventional WBS
 Conventional WBS is prematurely structured around product
design
 Note early orientation toward concrete subsystems
 Conventional WBS is prematurely decomposed, planned,
and budgeted in too much or too little detail
 Recall the idea of progressive elaboration
 Conventional WBS is project-specific, making cross-project
comparisons difficult or impossible
 Result of first item, above
60 of 101

61. Sample conventional WBS
Note early commitment to a
specific system decomposition
or architecture
Other subsystems have same
WBS pattern as sensor
detection subsystem
Comparison of different
projects requires extracting this
information for each subsystem
& combining
61 of 101

62. WBS terminology (PMI)
 Deliverable. Any unique and verifiable product, result, or capability to
perform a service that must be produced to complete a process, phase,
or project
 Milestone. A significant point or event in the project
 Work Breakdown Structure Component. Entry in the work breakdown
structure that can be at any level. Also known as WBS Element
 Work Package. Deliverable or project work component at the lowest
level of each branch of the WBS. Includes schedule activities and
milestones required to complete the work package deliverable or project
work component
Note: It is not necessary to enter every work package activity as a
separate WBS component
62 of 101

63. WBS representations
 There are two common ways of representing the WBS
 Hierarchical graphical format. A graphical view, similar in form to an
organization chart
 Hierarchical textual format. This is the common hierarchical list view
of the WBS, provided by most project management software such as
MS Project
 WBS should always be developed before the schedule is worked out,
without trying to sequence specific activities
 This is primarily important (and essential) when using a functional
WBS decomposition
 Process-oriented WBS decomposition (e.g. evolutionary) usually has
well-defined higher-level WBS components
 Specific activity sequencing is determined in the schedule
63 of 101

64. Rolling wave planning
 Our understanding of work that must be accomplished in the near
term is better than that for work to be performed far in the future
 Rolling wave planning varies the amount of planning detail
depending on the immediacy of the tasks to be performed
 Rolling wave planning is a means for implementing progressive
elaboration
 Work in the upcoming one or two reporting periods is planned in
detail, while later work is planned at a lower level of detail
64 of 101

65. Rolling wave planning
 Note on 100% rule:
 What encompasses 100% of the project work is
referenced to a particular time point in the project
 Scope may change, but only with proper approval and
control
 Implication: ‘100%’ comprises all approved work at a
particular point in time
65 of 101

66. Create WBS: Outputs
 Scope baseline. The scope baseline is the approved version
of a scope statement, work breakdown structure (WBS), and
its associated WBS dictionary:
 Project scope statement. Output from Define Scope process
 WBS. Either graphical or tabular form
 WBS dictionary. A companion document to the WBS, providing
detailed information about components in the WBS, including work
packages (see next slide for content)
 In a conventional project management environment the
scope baseline can be changed only through formal change
control procedures
66 of 101

67. WBS dictionary
 Companion document to the WBS
 Provides the detailed content for the WBS, including work
packages
 Practically, WBS dictionary is developed concurrently with
Activity Definition process under Project Time Management
knowledge area
 WBS components are cross-referenced to other WBS
components as needed
67 of 101

68. WBS dictionary content
 Required
 Code or account
identifier – unique
number assigned to a
WBS component
 Statement of work –
scope statement for the
WBS component
 Responsible
organization for WBS
component
 Schedule milestones for
WBS component
 Optional
 Contract information
 Quality requirements –
may be used in
assessment planning
 Technical references to
assist in executing work
 Charge number
 List of schedule
activities
 Resources required
 Estimate of cost
68 of 101

69. WBS template
Component groups with a ‘+’ in
front of them are ‘rolled up’–
subcomponents are hidden to
reduce clutter
69 of 101

70. Activity or
task
definition
Note expansion and
detailing of WBS template
Architecture design
modeling entry; renamed
Software architecture
description to Document
software architecture
Note expansion and
detailing of WBS template
Design demonstration
planning and conduct entry
Added System architecture
definition WBS component
Note expansion and
detailing of WBS template
Critical component coding
demo integration entry
Note rework of WBS
template Elaboration phase
assessment entry
70 of 101

71. Create WBS: Data Flow Diagram
71 of 101

72. Agile Perspective: Create WBS
Valuable concepts and tools
 The Create WBS process is among the least compatible with a complex
(or agile) project perspective
 It encourages solidifying the scope of the project in a complex,
difficult to change artifact, the WBS
 Once an artifact is created, it assumes an authority that may not be
justified
 Most WBSs are out-of-date shortly after being created
☛ People are reluctant to toss something that has taken so much effort
 Nevertheless, the process of thoughtful decomposition of the product
into smaller, more manageable pieces is certainly compatible with an
adaptive/agile methodology
 Adaptive/agile limits high-level decomposition to the product roadmap,
and defers low-level decomposition to the release and iteration (sprint)
level
72 of 101

73. WBS – Basis of Many Things
 Network scheduling
 Costing
 Risk analysis
 Organizational structure
 Control
 Measurement
73 of 101

74. The MS-Project Process
 Move WBS into a Project outline (in Task Sheet)
 Add resources (team members or roles)
 Add costs for resources
 Assign resources to tasks
 Establish dependencies
 Refine and optimize
 Create baseline
 Track progress (enter actuals, etc.)
74 of 101

75. Defining Task Sets
 Determine type of project
 Assess the degree of rigor required
 Identify adaptation criteria
 Select appropriate software engineering tasks
 Task Set Refinement
 Use Work Breakdown Structure to determine tasks
 Define a Task Network
 Use a Gantt Chart and/or PERT to document

76. To be Continued…