3&4. project scope management at project.ppt

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
Allthe work that is required to complete the project
successfully and
Onlythe work that is required, no more, no less
This latter point is critical: project scope management
defines and controls what isand is notpart of the project
work

3. ProjectScopeManagement
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 deliverableis a product produced as part of a project,
such as hardware or software, documents etc.

4. ProjectScopeManagement
Scope Management means:
Constantly check to make sure you are completing all the
work.
Notlettingpeoplerandomlyaddtothescopeofthe
projectwithoutastructuredchangecontrolsystem.
Making sure all changes fit within the project charter.
Defining and controlling what is and is not included in the
project.
Preventingextraworkorgoldplating:Youshouldgive
thecustomerwhattheyaskedfor,nomoreandnoless.
Givinganyextrasisawasteoftimeandaddsnobenefitto
theproject!

5. Components of Project Scope Management
1.PlanScopeManagement
2.CollectRequirements
3.Define Scope
4.CreateWBS
5.ValidateScope
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.PlanScopeManagement:Theprocessofcreatingascope
managementplanthatdocumentshowtheprojectscopewillbe
defined,validatedandcontrolled.
2CollectRequirements:theprocessofdetermining,documenting
andmanagingstakeholder’sneedstomeettheprojectobjectives.
3DefineScope:theprocessofdevelopingadetaileddescriptionof
theprojectandtheproduct.
4CreateWBS:theprocessofsubdividingtheprojectdeliverablesand
theprojectworkintosmaller,moremanageablecomponents.
5ValidateScope:theprocessofformalizingacceptanceofthe
completedprojectdeliverables.
6ControlScope:theprocessofmonitoringthestatusoftheproject
andproductscopeandmanagingchangestothescopebaseline.

7. Project Scope Management
Intheprojectcontext,theterm“scope”canreferto:
Productscope.Thefeaturesandfunctionsthatcharacterizea
product,service,orresult.
Projectscope.Theworkperformedtodeliveraproduct,service,or
resultwiththespecifiedfeaturesandfunctions.Theterm“projectscope”
issometimesviewedasincludingproductscope.
CompletionoftheprojectscopeismeasuredagainstthePMP,while
completionoftheproductscopeismeasuredagainsttheproduct
requirements.
Theterm“requirement”isdefinedasaconditionorcapabilitythatis
requiredtobepresentinaproduct,service,orresulttosatisfyan
agreementorotherformallyimposedspecification.
Key Trends & Tailoring
Concepts Practicesconsiderations
Considerations for
Agile/Adaptive environments

8. Eliciting(extracting),documenting,andmanagingstakeholder
requirements takes place within the Project Scope Management
processes.TrendsandemergingpracticesforProjectScope
Managementincludeafocusoncollaboratingwithbusiness
analysis professionals to:
Determine problems and identify business needs;
Identifyand recommend viablesolutionsfor
meetingthose 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. Considerationsfortailoringincludebutarenotlimitedto:
Knowledgeandrequirementsmanagement.Doestheorganizationhave
formalorinformalknowledgeandrequirementsmanagementsystems?What
guidelinesshouldthePMestablishforrequirementstobereusedinthefuture?
Validationandcontrol.Doestheorganizationhaveexistingformalor
informalvalidationandcontrol-relatedpolicies,procedures,and
guidelines?
Developmentapproach.Doestheorganizationuseagileapproachesin
managingprojects?Isthedevelopmentapproachiterativeorincremental?
Isapredictiveapproachused?Willahybridapproachbeproductive?
Stabilityofrequirements.Arethereareasoftheprojectwithunstable
requirements?Dounstablerequirementsnecessitatetheuseof
lean,agile,orotheradaptivetechniquesuntiltheyarestableandwell
defined?
Governance.Doestheorganizationhaveformalorinformalauditand
governancepolicies,procedures,andguidelines?
Key Trends & Tailoring
Concepts Practicesconsiderations
Considerations for
Agile/Adaptive environments
Project Scope Management

10. Inprojectswithevolvingrequirements,highrisk,orsignificant
uncertainty,thescopeisoftennotunderstoodatthebeginningofthe
projectoritevolvesduringtheproject.
Agilemethodsdeliberatelyspendlesstimetryingtodefineandagree
onscopeintheearlystageoftheprojectandspendmoretime
establishingtheprocessforitsongoingdiscoveryandrefinement.
Manyenvironmentswithemergingrequirementsfindthatthereis
oftenagapbetweentherealbusinessrequirementsandthebusiness
requirementsthatwereoriginallystated.Therefore,agilemethods
purposefullybuildandreviewprototypesandreleaseversionsin
ordertorefinetherequirements.Asaresult,scopeisdefinedand
redefinedthroughouttheproject.Inagileapproaches,therequirements
constitutethebacklog.
Key
Concepts
Tailoring
considerations
Considerations for
Agile/Adaptive environments
Trends &
Practices
Project Scope Management

11. Creatingascopemanagement planthatdocumentshowthe
project scope will be defined, validated and controlled.
It starts with the
Project charter and
the approved
subsidiary plans
Project Scope Management

12. PlanScopeManagement
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.
Requirementsgatheringcantakeasubstantialamountoftime,especiallyonlargeprojects
thatmayrequireyoutoobtainrequirementsfromhundredsofstakeholders.
Aworkbreakdownstructure(WBS)isusedonallprojects.Asidebenefitofthistoolisthatyou
mayfindadditionalscopeandbeabletoclarifyidentifiedscopewhenyoucreateWBS.
Whiletheprojectisbeingcompleted,youmustchecktomakesureyouaredoingallthework
butonlytheworkincludedinthePMP.
Anychangetoscopemustbeevaluatedforitseffectontime,cost,risk,quality,resourcesand
customerssatisfaction
“Goldplating”inprojectisnotallowed
Nochangestoscopeareallowedwithoutanapprovedchangerequest.
Scopechangesshouldnotbeapprovediftheyrelatetoworkthatdoesnotfitwithintheproject
charter
Youneedtoclearlyunderstandwhatisandisnotincludedintheproject.

13. PlanScopeManagement
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
•Alternativesanalysis
1.Meetings
1.Scope
management plan
2.Requirements
management plan

14. Tools&Techniques
PlanScopeManagement
Input Output
2.ProjectManagementPlan
Projectmanagementplancomponentsinclude:
Qualitymanagementplan.Thewaytheprojectandproduct
scopewillbemanagedcanbeinfluencedbyhowthe
organization’squalitypolicy,methodologies,andstandardsare
implementedontheproject.
Projectlifecycledescription.Theprojectlifecycle
determinestheseriesofphasesthataprojectpassesthroughfrom
itsinceptiontotheendoftheproject.
Developmentapproach.Thedevelopmentapproachdefines
whetherwaterfall,iterative,adaptive,agile,orahybrid
developmentapproachwillbeused.

15. Tools&Techniques
PlanScopeManagement
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;
Processthat establishes how the scope baseline will be
approved and maintained;
Process that specifies how formal acceptance ofthe 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
PlanScopeManagement
Input Output
2.RequirementsManagementPlan
Describeshowtherequirementswillbeanalyzed,documentedand
managed.Thecomponentsoftherequirementsmanagementplan
include:
Howrequirementsactivitieswillbeplanned,tracked,and
reported;
Configurationmanagementactivitiessuchas:howchangeswillbe
initiated;howimpactswillbeanalyzed;howtheywillbetraced,
tracked,andreported;aswellastheauthorizationlevelsrequiredto
approvethesechanges;
Requirementsprioritizationprocess;
Metricsthatwillbeusedandtherationaleforusingthem;
Traceabilitystructurethatreflectstherequirementattributes
capturedonthetraceabilitymatrix.

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
19of 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
20of 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
21of 101

22. Plan Scope Management: Data Flow Diagram
22of 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.
23of 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
24of 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
25of 101

26. Inputs, tools & techniques, and outputs
26of 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.
27of 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
28of 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
29of 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
30of 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
31of 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
32of 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
33of 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]
34of 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
35of 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.
36of 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’
37of 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
38of 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’
39of 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.
40of 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
41of 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 accountidentifier) 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
42of 101

43. The Work Breakdown Structure
GOAL
Activity ActivityActivity
Activity ActivityActivity
Level 1
Level 2
Activity
Task #1 Task #2 Task #3 Task #4 … Task #n
43of 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.
45of 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.
46of 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.
47of 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 …
48of 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'sdocumentation 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.”
49of 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 eventmight 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.
50of 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.
51of 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.
52of 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
53of 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 (
physicalor 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-implementand 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.
54of 101

55. WBS and Gantt Chart in Microsoft Project
55of 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”
56of 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
57of 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
58of 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
59of 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
60of 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
61of 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
62of 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 beforethe 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
63of 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
64of 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 approvedwork at a
particular point in time
65of 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
66of 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 Definitionprocess under Project Time Management
knowledge area
WBS components are cross-referenced to other WBS
components as needed
67of 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
organizationfor WBS
component
Schedule milestonesfor
WBS component
Optional
Contract information
Quality requirements –
may be used in
assessment planning
Technical referencesto
assist in executing work
Charge number
List of schedule
activities
Resources required
Estimate of cost
68of 101

69. WBS template
Component groups with a ‘+’in
front of them are ‘rolled up’–
subcomponents are hidden to
reduce clutter
69of 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 WBScomponent
Note expansion and
detailing of WBS template
Critical component coding
demo integration entry
Note rework of WBS
template Elaboration phase
assessment entry
70of 101

71. Create WBS: Data Flow Diagram
71of 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
72of 101

73. WBS –Basis of Many Things
Network scheduling
Costing
Risk analysis
Organizational structure
Control
Measurement
73of 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.)
74of 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…