Lect 04

SE 477
Software and Systems Project Management
Dennis Mumaugh, Instructor

dmumaugh@depaul.edu
Office: CDM, Room 428
Office Hours: Wednesday, 4:00 – 5:30
January 25, 2017 SE 477: Lecture 4 1 of 101

Administrivia
 Comments and feedback
 MS-Project
 Short set of slides (from John Musser) on class web page
 Download the Automatic Tollbooth example and work with it.
 Google “microsoft project tutorial”
» A random such tutorial is
http://www.profsr.com/msproject/msproj01.htm
 Homework
 Page size suggestions are for single spaced documents. Double
them for double spaced. I prefer single spaced or space and a half!
 Show paragraphs: indent or use a space [change MS Word style].
Show section heads.
 Proof read!

Administrivia
 Project
 Continue work on team assignment
» By now you should have organized and have had some virtual
meetings.
» Should have some of the work on Project Charter and Preliminary
Project Scope finished.
» Should have rough schedule for rest of work.
 Keep in touch and make sure your team members are
communicating and doing work.
 Inform me immediately if your partner(s) are not keeping up and you
are having problems.

Homework
Assignment 3 – Due February 8, 2017
 Develop a plan and project schedule for a small subsystem
 Assume the project is using the waterfall SDLC and has the following
phases: Requirements, High Level Design, Detailed Design, Coding
and Unit Test, Integration and Testing, Documentation.
 There is a WBS provided with the required phases, activities and
information to complete this project.
 Assign Resources to the Tasks making any assumptions you
consider appropriate (Software Engineering Assumptions).
 Provide an executive summary
 What is the earliest finish date for this project if it is scheduled to
start on 3/20/2017? Don’t forget holidays!
 Show the duration and delivery schedule given the start date is
March 20, 2017.
 Show the staffing and resources used, and the total staff time.
 You should use ProjectLibre or MS Project to develop this.
SE 477 – Class 4
Topic:
 Project Planning
 Project scope management
» Project requirements
» Creating the Work Breakdown Structure (WBS)
 Activity:
» Activity Definition
» Activity Sequencing
Reading:
 PMBOK-SWE Ch. 5, Ch. 6.1-6.3

Thought for the day
“Predictions are hard, especially about the

future”
– Yogi Berra

Last time
 Initial Phase:
 Developing the project charter
» Statement of work (SOW)
» Agile Perspective: The Product Overview Document
 Stakeholders
» Organizational Structures & Influences
 Project planning
 Initial documents
» Project Charter – Statement of Work (SOW)
» Project plans
 The Project Management Plan;

Project Planning: A 12 Step Program
1) Set goal and scope 7) Identify tasks
2) Select lifecycle 8) Identify task
3) Set dependencies
organization/team 9) Estimate size
form 10) Estimate effort
4) Start team selection 11) Assign resources
5) Determine risks 12) Schedule work
6) Create WBS

Project scope management
Scope Planning
Project Requirements
Define Scope
Creating the Work Breakdown Structure (WBS)

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

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

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

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

Scope management plan
 According to PMBOK 5: “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
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

Plan Scope Management: Data Flow Diagram

Process: Collect Requirements
 Recall the most critical lesson from the Standish Group's
2009 CHAOS report:
 Requirements, requirements, requirements
» 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; we touch on the topic here for completeness

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
*PMBOK 5 groups functional and nonfunctional requirements under the heading ‘Solution Requirements’
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
Inputs, tools & techniques, and outputs

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.

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

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

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

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

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 methodologies: sequential, iterative/incremental, and
adaptive/agile

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

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

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

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.
 [See notes below!]
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 …

 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.”

 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.
 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.
 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 needed

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
WBS component  Estimate of cost

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

Design demonstration
planning and conduct entry
Note rework of WBS
template Elaboration phase
assessment entry
Note expansion and
Critical component coding
demo integration entry

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
examples)
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
 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
 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-finish

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

Next Class
 Topic:
 Activity Resource Estimating
 Activity Duration Estimating
» Estimating
• Size and complexity
» Tools
• Gantt Chart
• PERT
 Schedule Development
 Reading:
 PMBOK-SWE Ch. 6 Intro & Ch. 6.1-Ch. 6.6

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!

Lect 04

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Lect 04

Caricato da

Copyright:

Formati disponibili

SE 477

Software and Systems Project Management

Dennis Mumaugh, Instructor

January 25, 2017 SE 477: Lecture 4 1 of 101

January 25, 2017 SE 477: Lecture 4 2 of 101

January 25, 2017 SE 477: Lecture 4 3 of 101

January 25, 2017 SE 477: Lecture 4 5 of 101

“Predictions are hard, especially about the

January 25, 2017 SE 477: Lecture 4 6 of 101

January 25, 2017 SE 477: Lecture 4 7 of 101

January 25, 2017 SE 477: Lecture 4 8 of 101

January 25, 2017 SE 477: Lecture 4 9 of 101

January 25, 2017 SE 477: Lecture 4 10 of 101

January 25, 2017 SE 477: Lecture 4 11 of 101

January 25, 2017 SE 477: Lecture 4 12 of 101

January 25, 2017 SE 477: Lecture 4 13 of 101

January 25, 2017 SE 477: Lecture 4 15 of 101

January 25, 2017 SE 477: Lecture 4 16 of 101

January 25, 2017 SE 477: Lecture 4 17 of 101

January 25, 2017 SE 477: Lecture 4 20 of 101

January 25, 2017 SE 477: Lecture 4 21 of 101

January 25, 2017 SE 477: Lecture 4 22 of 101

January 25, 2017 SE 477: Lecture 4 23 of 101

January 25, 2017 SE 477: Lecture 4 24 of 101

January 25, 2017 SE 477: Lecture 4 25 of 101

January 25, 2017 SE 477: Lecture 4 26 of 101

January 25, 2017 SE 477: Lecture 4 27 of 101

January 25, 2017 SE 477: Lecture 4 28 of 101

January 25, 2017 SE 477: Lecture 4 29 of 101

January 25, 2017 SE 477: Lecture 4 30 of 101

January 25, 2017 SE 477: Lecture 4 32 of 101

Activity Activity Activity Level 1

Activity Activity Activity Level 2

January 25, 2017 SE 477: Lecture 4 37 of 101

1. Breaks project into a hierarchy.

January 25, 2017 SE 477: Lecture 4 39 of 101

January 25, 2017 SE 477: Lecture 4 40 of 101

January 25, 2017 SE 477: Lecture 4 41 of 101

» Let us review each one in detail …

January 25, 2017 SE 477: Lecture 4 43 of 101

January 25, 2017 SE 477: Lecture 4 46 of 101

January 25, 2017 SE 477: Lecture 4 47 of 101

January 25, 2017 SE 477: Lecture 4 48 of 101

January 25, 2017 SE 477: Lecture 4 49 of 101

January 25, 2017 SE 477: Lecture 4 50 of 101

January 25, 2017 SE 477: Lecture 4 51 of 101

January 25, 2017 SE 477: Lecture 4 52 of 101

 Major subsystems of the project

January 25, 2017 SE 477: Lecture 4 53 of 101

January 25, 2017 SE 477: Lecture 4 54 of 101

Note early commitment to a

Other subsystems have same

January 25, 2017 SE 477: Lecture 4 55 of 101

Note: It is not necessary to enter every work package activity as a

January 25, 2017 SE 477: Lecture 4 56 of 101

January 25, 2017 SE 477: Lecture 4 57 of 101

January 25, 2017 SE 477: Lecture 4 58 of 101

January 25, 2017 SE 477: Lecture 4 59 of 101

January 25, 2017 SE 477: Lecture 4 60 of 101

January 25, 2017 SE 477: Lecture 4 61 of 101

January 25, 2017 SE 477: Lecture 4 62 of 101

Component groups with a ‘+’ in

January 25, 2017 SE 477: Lecture 4 63 of 101