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.
 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
“Gallia est omnis divisa in partes tres”
Commentarii de Bello Gallico
Julius Caesar
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’
 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
 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’
 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.

 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 SDLC process
 Note that one of the disciplines in the iterative SDLC 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
 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
 The Work Breakdown Structure

GOAL

Activity Activity Activity Level 1

Activity Activity Activity Level 2

Activity
Task #1 Task #2 Task #3 Task #4 … Task #n
Work Breakdown Structure

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.
 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.
 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.
 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.
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 …

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.”
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.
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.
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.
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
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.
WBS and Gantt Chart in Microsoft Project
 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”
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
 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
 Conventional WBS levels
 Level 1
 Note that conventional WBS
Project name decomposition levels are
 Level 2 product-oriented

 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
 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
 Sample conventional WBS

Note early commitment to a

specific system decomposition
or architecture

Comparison of different
projects requires extracting this
information for each subsystem
& combining

Other subsystems have same

WBS pattern as sensor
detection subsystem
 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
 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
 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
 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
 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
 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 neede
 WBS dictionary content
 Required  Optional
 Code or account  Contract information
identifier – unique  Quality requirements –
number assigned to a may be used in
WBS component assessment planning
 Statement of work –  Technical references to
scope statement for the assist in executing work
WBS component  Charge number
 Responsible  List of schedule
organization for WBS
activities
component
 Resources required
 Schedule milestones for
 Estimate of cost
WBS component
 WBS template

Component groups with a ‘+’ in

front of them are ‘rolled up’–
subcomponents are hidden to
reduce clutter
 Activity or
task
definition
Added System architecture
definition WBS component

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
Note rework of WBS
template Elaboration phase
assessment entry
Note expansion and detailing
of WBS template Critical
component coding demo
integration entry

January 25, 2017

Create WBS: Data Flow Diagram
 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
 WBS – Basis of Many Things
 Network scheduling
 Costing
 Risk analysis
 Organizational structure
 Control
 Measurement
 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.)
 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
 Project Planning
Project Time Management I

Introduction
Activity Definition
Activity Sequencing
 Overview
 Project time management is the project management
knowledge area concerned with analyzing the logical and
temporal relationships among the activities needed to
complete the project
 Three elements form the core of time management analysis:
 The schedule data and associated calculations (e.g., activity
definitions and estimates)
 The scheduling method applied to the schedule data in order to
define estimated start and end dates for activities and milestones,
including project completion
 The schedule that represents the output from a scheduling tool
applying the method to the data
 In a conventional methodology, the project schedule acts as
the planning backbone for virtually all other project activities
Project time management processes
 The project time management processes include:
1. Define activities. Identifies specific activities to be carried out in
work packages
2. Sequence activities. Identify and document relationships among
activities
3. Estimate activity resources. Estimate the number and type of
resources needed for activity, such as staff, materials, equipment,
software, etc.
4. Estimate activity durations. Estimate number of work periods (e.g.
hours, days, weeks) to complete activity with estimated resources
5. Develop schedule. Analyze network of activity sequences,
durations, resources, and constraints to estimate planned dates for
activities and milestones
Project time management processes
 The project time management processes include:
6. Control schedule. Monitor schedule status and manage schedule
updates
 We focus only on the planning process knowledge area for
time management, comprising the the first five processes
above. In practice, on smaller projects, the middle four
processes are carried out concurrently
 Scheduling workflow
 Define activities
 Use of WBS helps guide definition process and organize
activities
 Perform activity sequencing
 Develop schedule framework according to what is
logically possible – perform resource allocation later
 Estimate effort – the total number of labor units (e.g. staff-
days) for each activity
 Estimate elapsed time
 Identify resources for each activity
 Apply calendars to schedule framework
 Scheduling workflow
Some of these will be covered in a later lecture.
 Estimate activity duration based on resources for activity
 Perform forward pass or backward pass critical path
analysis to generate schedule model [later lecture –
appendix]
 Apply schedule compression, if needed
 Perform ‘what-if’ scenario analysis to identify contingency
and risk response needs
 Apply resource leveling to schedule model
 Planning, Estimating, Scheduling
 What's the difference?
 Plan: Identify activities. No specific start and end
dates.
 Estimating: Determining the size & duration of
activities.
 Schedule: Adds specific start and end dates,
relationships, and resources.
 Note the term activities – much the same as tasks
but more general.
 How To Schedule
 Identify “what” needs to be done
 Work Breakdown Structure (WBS)
 Identify “how much” (the size)
 Size estimation techniques

 Identify duration
 Effort estimation techniques

 Identify the dependency between tasks

 Dependency graph, network diagram
 Gantt chart and PERT

 Estimate total duration of the work to be done

 The actual schedule
 PERT and CPM
 Overview
 The Define Activities process identifies the specific actions or tasks
needed to carry out the project and produce the project deliverables
 In a conventional project methodology, the Create WBS process defines
the project deliverables and work packages
 In an adaptive/agile project methodology, only the high-level
deliverables are defined up front, while work packages are defined at
the iteration level
 Each work package comprises the specific activities needed to complete
the work package
 Recall that:
 Deliverables and work packages are the planning units for project
management purposes
 Tasks (activities) are the planning unit for development purposes
 An iteration/sprint comprises one or more work packages (and their
associated activities)
 Activity definition
 PMBOK factors out activity definition as a separate process
from the creation of the WBS
 However, in practice, the activity definition list, WBS, and
WBS dictionary are usually developed concurrently
 Rolling wave planning should be applied to activity definition
in order to optimize the level of detail in the WBS: neither
too little (for immediate work) or too much (for later work)
 The main tool for activity definition is decomposition
 Activity definition
 Decomposition is the process of breaking the project
scope and deliverables into smaller, more manageable
components
 Decomposition is usually performed in a top-down,
hierarchical manner
 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
 Significant part of the WBS decomposition can be defined
by WBS templates (see Practice Standard for Work
Breakdown Structures, Second Edition (ebooks 24x7), for
exampes)
 Sidebar: A useful rule of thumb
 No work package should have a duration greater than four
to six weeks
 For knowledge work, durations should be in the range of
one to three weeks, because knowledge work is harder to
track than tangible work
 People tend to back-end load tasks with lengthy
durations by pushing all the effort toward the end
 For this class [the team project], keep work package
durations in the one-to-two-week range
 Activity definition workflow
 Choose an appropriate WBS template as a guide for activity
definition
 Enter WBS template into a project management tool (if
preloaded template not available)
 Define activities in the task list of the project management
tool
 If decomposition results in an activity with a deliverable/work
component and a duration of 1-2 weeks, consider it a work
package
 If decomposition results in a set of shorter (<1 wk) activities,
group them into one or more 1-2 week work packages that
produce deliverable/work components
 Activity definition workflow
 Assign each activity a unique identification code that
remains with the activity if it is moved in the list
 The WBS code is a position-dependent hierarchical code
– it does not stay with an activity if moved
 Example: Architectural Cost-Benefit Analysis has a WBS
code of 4.2.1.2 but a unique identification code of
(hypothetically) ADM2 (or 25.0, or any other code)
 Work packages usually have additional activity detail
specified in their WBS dictionary entry
 This is essential if the work package is not a highly
standardized process
Agile Perspective: Define Activities
Essential, but do it just in time
 In this process, PMBOK leans heavily toward the complicated—rather
than complex—project methodology
 The PMBOK states: “The activity list is a comprehensive list that
includes all schedule activities required on the project”
 In an adaptive/agile project, this list cannot—and should not—be
generated early in the project
 Attempting to define activities up-front in a complex project leads to
wasted effort and inconsistencies between documents and reality
 Instead, application of the agile method delays specific activity definition
to the start of each individual sprint, and delegates the activity definition
to the individual sprint development teams
 Define activities no earlier than during iteration planning
 Reading
 Practice Standard for Work Breakdown Structures, Second
Edition by Project Management Institute (2006)
 Available on Books 24x7 (through the DePaul e-library)
 Appendix K: Web Design Work Breakdown Structure
(WBS) Example
 Appendix O: Software Implementation WBS Example
 Note that both of these templates are process-oriented
 Activity Sequencing

Precedence diagram method

Dependency types
Leads and lags
 Introduction
 Activity sequencing identifies and documents the logical relationships
among activities in a project
 Logical sequencing is determined by precedence (predecessor-
successor) relationships
 Activity sequencing, though executed differently is an important concept
in all project management methodologies
 Essential inputs
 Activity list, which may be developed concurrently with WBS
 May use scope statement information to determine or refine
precedence constraints
 Essential outputs
 Project schedule network diagrams
 UPdated activity list/WBS
 Precedence Diagram Method (PDM)
 The Precedence Diagram Method (PDM) is a graphical
schedule diagramming method aka Network Diagram
 Represents activities as rectangular nodes
 Connects the nodes with arrows to show dependencies
 Connection points of arrows to activities refine and impose
constraints on dependencies
 Classified as an ‘Activity on Node’ (AON) diagramming
scheme
 Alternative is ‘Activity on Arrow’ (AOA) that models
project in states, with activities as transitions from one
state to another
 Dependency types illustrated
Activity 1 Activity 2 Activity 1 Activity 2

Finish-to-Start Finish-to-Finish

Activity 1 Activity 2
Activity 1 Activity 2

Start-to-Start
Start-to-Finish
30%

Activity 1

Activity 2
50%
Percent Complete
 Dependency types
 Finish-to-start. Start of successor activity depends on finish
of predecessor activity
 Example: Start of testing after code completion in
traditional waterfall development
 Finish-to-finish. Finish of successor activity depends on
finish of predecessor activity
 Example: Acceptance of a component can only complete
when acceptance of last subcomponent is complete
 Start-to-start. Start of successor activity depends on start
of predecessor activity
 Example: Start of acquisition of third-party software
component triggers training for involved developers
 Dependency types
 Start-to-finish. Finish of successor activity depends on start
of predecessor activity
 Example: Subcontract x will complete t days after
subcontract y begins
 Percent complete: Last n% of successor activity depends
on m% completion of predecessor activity
 Example: Last 30% of network interface development will
begin when 50% of application development is complete
 Note: A better choice of terms might be dependent and
independent activities, as in the cases of Start-to-start and
Start-to-finis
PDM example
 Activity
sequencing

Note dual predecessors.

Default relationship is Finish-
to-Start. Here, we have
defined a Start-to-Start
relationship with an added
lag of 5 days

Here, we have defined a Finish-

to-Finish relationship: this is
common for
implementation/integration task
pairs
 Dependency type determination
 Mandatory dependencies. Dependencies that are inherent in the
nature of the work
 Example: Acceptance testing can only begin after all code
development is complete (except for bug fixes)
 Discretionary dependencies. Dependencies that are not inherent in
the work, but might be preferred by the PM team based on best
practices or other factors. Also known as preferred or soft logic
 Discretionary dependencies should be fully documented so they can
be properly considered and evaluated for later scheduling options
 Example: Schedule high-risk activities early in development in order
to mitigate those risks (best practice)
 Example: Beginning work on second draft of a document before first
draft is complete
 Example: admissions system has a dependency upon delivery and
configuration of smart card reader
 Dependency type determination
 Internal dependencies. Dependencies that are between
project activities and within the project team's control
 Example: Start of procurement of third-party software component
triggers training for developers who will work with the component
(internal, discretionary dependency)
 External dependencies. Dependencies that involve a
relationship between project and non-project activities
 External dependencies are usually outside the project team's control
☛ Example: Delivery of any third-party component, such as a custom
or COTS component
 Leads and lags
 Lead. A lead moves an activity back in time from its
expected point. Sometimes referred to as an accelerated
activity
 Example: Beginning work on second draft of document
before first draft is complete
 Lag. A lag introduces a delay into a successor activity.
Restricts the start of the successor, even if predecessor
activity is complete
 Example: Requiring ten days lag before acceptance
testing can begin (possibly introduced as contingency)
 Outputs
 Schedule network diagrams. Schedule network diagrams
graph the project activities and their dependencies. These
may be produced manually or using project management
software
 Documentation explaining discretionary dependencies, leads and
lags, or other exceptional dependencies should accompany the
diagram
 Project document updates. The Sequence Activities process
may lead to updates in the following project documents:
 Activity lists
 Activity attributes, specifically the predecessor and successor
activities, logical relationships, and leads and lags attributes
 Milestone lists
 Risk register
 Task
 Name
 ID
 Description of work
 Duration (days)
 Start Date (Earliest, Latest)
 Finish Date (Earliest, Latest)

 Resources (People and equipment)

 Effort (In staff-days)

 Predecessors (other tasks)

 Inputs (documents, decisions, information)
 Successors (other tasks)
 Outputs (documents, decisions, information)
Agile Perspective: Sequence Activities
Useful concepts, but apply them just in time
 As in the Define Activities process, PMBOK leans heavily
toward the complicated—rather than complex—project
methodology perspective
 The concepts of activity dependency are applicable across
all project management methodologies
 However, in an adaptive/agile project, the activity list, upon
which sequencing depends, is generated in small chunks
throughout the project at the start of each individual sprint
 This is the logical time at which to work out sequencing of specific
activities
☛ Define activities no earlier than during iteration planning
 Journal Exercise
 Considering the WBS:
 How detailed should a project get?
 Should we include sub-activities?
» For example, should the coding task have sub-tasks of
• Write code
• Review code
• Test code
• Release code to the CM system
» Should we have a test for each code module?
• We don't even know what the software looks like!