Software Project Management

Part 2: Work Breakdown

Structures

Introduction into Software Engineering

Lecture 20

Bernd Bruegge
Applied Software Engineering
Technische Universitaet Muenchen

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 1

Where are we?
• The lectures on software lifecycle modeling and
project management addressed the following
questions:
• Software lifecycle modeling: How do we deal with change?
• Project planning: How do we plan a project?
• Decomposition of work: What are the tasks?
• Other project management issues:
• Project organization: Who is doing these tasks?
• Estimation: How long do these tasks take?
• Scheduling: How long will it take to finish them?
• Study them in other lectures on project
management and organization and experience
them in practical courses, eg. a software
engineering praktikum.
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 2
Outline of this Lecture

• Determining Work and Tasks Sizes

• Work Breakdown Structure (WBS)
• Different Approaches for developing a WBS
• Notations for Work Breakdown Structures
• Heuristics and examples
• Starting with templates
• How to identify work
• What do we do with risky tasks?
• Work Breakdown Structures in large projects
• How detailed should a WBS be?
• How can you plan the tasks of a long project when
things are unknown or changing all the time?

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 3

What is the Problem?
Your boss: “How long will this take?”
You: “Between 1 and 6 months.” “As long as I can do it
within 6 months, I keep
my promise.”

“With hard work, he can

do it in 1 month.”

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 4

What is the real Problem?
Your boss: “How long will this take?”
You: “Between 1 and 6 months.” “I have not he
slightest clue, if this is
possible at all.”

“Even if it is possible,
I don’t know, how long
it will take.”

Solution: Use divide and conquer

• To give a good answer you have to break the work down
into activities for which you try to get timing estimates
• Only if with good estimates can you estimate the overall
project duration
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 5
Activities to obtain Time Estimates

• Identify the tasks that needs to be done

• Work breakdown structure (WBS)
• Identify dependencies between tasks
• Dependency Graph
• Estimate the duration for each task to be done
• Schedule

• These are the topics of the SPMP, Section 5.1,

5.2 and 5.5.

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 6

Software Project Management Plan
0.Front Matter
1.Introduction
2.Project Organization
3.Managerial Process
4.Technical Process
5.Work Elements, Schedule, Budget
5.1 Work Breakdown Structure (WBS)
5.2 Dependencies between tasks
5.3 Resource Requirements
5. 4 Budget
5.5 Schedule
Optional Inclusions
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 7
Software Project Management Plan
0.Front Matter
1.Introduction
2.Project Organization
3.Managerial Process
4.Technical Process
5.Work Elements, Schedule, Budget
5.1 Work Breakdown Structure (WBS)
5.2 Dependencies between tasks
5.3 Resource Requirements
5. 4 Budget
5.5 Schedule
Optional Inclusions
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 8
Building a House

What are the activities that are

needed to build a house?

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 9

First Step: Identify the Work to be done

• Surveying • Install Wallboard

• Excavation • Paint Interior
• Request Permits • Install Interior Doors
• Buy Material • Install Floor
• Lay foundation • Install Roof
• Build Outside Wall • Install Exterior Doors
• Install Exterior Plumbing • Paint Exterior
• Install Exterior Electrical • Install Exterior Siding
• Install Interior Plumbing • Buy Pizza
• Install Interior Electrical

• Initially finding these tasks is a brainstorming activity

• Similar to activities used during requirements
engineering and analysis.
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 10
Second Step: Hierarchically organize the
Tasks
• Building the house consists of
• Prepare the building site
• Building the Exterior
• Building the Interior
• Preparing the building site consists of
• Surveying
• Excavation
• Buying of material
• Laying of the foundation
• Requesting permits

• Finding this organization involves categorization

and refinement
• Good after brainstorming, not during brainstorming.
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 11
Third Step: Identify dependencies between
tasks
• The work breakdown structure does not show
any dependence among the activities/tasks
• Can we excavate before getting the permit?
• How much time does the whole project need if I know
the individual times?
• What can be done in parallel?
• Are there any critical actitivites, that can slow down
the project significantly?
• Dependencies like these are shown in the
dependency graph
• Nodes are activities
• Lines represent temporal dependencies

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 12

Building a House (Dependency Graph)
The activity Install
Interior
Install
Interior
Install
Wallboard
„Buy Material“ must Plumbing Electrical

precede the activity Paint

Interior
„Lay foundation“
Install
Interior
Install Doors
Flooring

Lay Build
START Survey Excava Buy FINISH
Founda Outside
ing tion Material tion Wall Install
Roofing
Install
Exterior
Doors

Request
Paint
Exterior

Install Install Install

Exterior Exterior Exterior
Plumbing Electrical Siding

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 13

Fourth step: Map tasks onto time

• Estimate starting times and durations for each

of the activities in the dependency graph
• Compute the longest path through the graph
• This is the estimated duration of your project

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 14

Building a House (Schedule, PERT Chart)
12/3/05 12/21/05 1/11/95
Each Activity has a start time Install
Interior
Install
Interior
Install
Wall
and an estimated duration Plumbing Electrical board
0 0 0 1/22/95
12 15 9 Paint
Interior
0 2/8/95
11
1/22/95 Install
Interior
Install Doors
Flooring
0
10/15/05 11/5/05 7
8/27/05 8/27/05 9/17/05 10/1/05 0 2/16/95
Lay Build 18
START Survey Excava Buy Founda Outside 1/19/95 FINISH
ing tion Material tion Wall Install
0 Roofing 1/19/95 0
0 12 0 0 0
0 3 10 10 20 Install 0
15 12
9 Exterior
8/27/05 Doors
15
Request 1/12/95
6
Permits Paint
0 Exterior
15 12
5
12/3/05 12/17/05 12/31/05
Install Install Install
Start Time 8/29/05
Exterior Exterior Exterior
Legend Plumbing Electrical Siding

12 12 12
Duration 0
10 10 8
Slack Time 0
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 15
How do we get good Time Estimates?

• Estimation of starting times and durations is

crucial for setting up a plan
• Estimation is still like black magic
• Methods and heuristics on how to do it and how
to establish a software project schedule , eg:
• Traditional methods:
• Project Management and Organization (Module
IN2082)
• Agile Techniques like Scrum:
• Agile Project Management Seminar (WS 2007-8)
• Practice, practice, practice:
• Real Project
• Software Engineering Praktikum WS 2007-8
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 16
Work Breakdown Structure

Work Breakdown Structure Work

* *

Task Activity

Work Breakdown Structure: The aggregation of all the work

to be performed in a project. Often called WBS

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 17

Approaches to Develop Work Breakdown
Structures
• Result-oriented approach
• Structure the work based on the work products
• Activity-oriented approach
• Structure the work based on development activities and
project functions
• Geographical area approach
• Structure the work based on geographical location
• Organizational approach
• Structure the work based on organizational structure

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 18

When to use what Approach
• The teams are distributed over the continent:
• Geographical area approach
• The teams consist of experienced developers:
• Result-oriented approach
• The project has mostly beginners or an
inexperienced project manager:
• Activity-oriented approach
• The project is a continuation of a previously
successful project, no changes
• Organizational approach
Whatever approach you choose, stick with it to
prevent possible overlap in categories.

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 19

Should you mix the WBS Approaches?
• Consider a WBS for the activity „Prepare report“
• Activity-oriented approach:
Why is this bad?
• Write draft report (Joe)
• Review draft report (Ann)
• Write final report (Joe) Who do check with on the the task?
• Result-oriented approach:“Write the final version of Chapter 2”
Ann or Joe?
• Chapter 1 (Joe)
• Chapter 2 (Ann)
• Mixed approach: “Write the final version of Chapter 2”
• Chapter 1 (Joe) can be included Ann’s task:
• Chapter 2 (Ann) “Chapter 2” or in Joe’s task
“Write final report”.
• Review draft report (Ann)
• Write final report (Joe)
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 20
How do you develop a good WBS?

• Top down approach:

• Start at the highest, top level activities and
systematically develop increasing levels of detail for all
activities
• Bottom up approach (“Brainstorming”):
• Generate all activities you can think of that will have to
be done and then group them into categories
• Which one you use depends on
• how familiar you and your team are with the project,
• whether similar projects have successfully been
performed in the past, and
• how many new methods and technologies will be used.

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 21

Top Down WBS Development

• Specify all activities for the entire project to be

finished
• Determine all tasks to complete each activity
• If necessary, specify sub-activities required to
complete each task
• Continue in this way until you have adequately
detailed your project
• Approach is good if
• You (or your team) are familiar with the problem
• You have successfully managed a similar project in the
past
• You are not introducing new methodologies or tools.

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 22

Brainstorming WBS Development
• Brainstorming means you
• Don’t worry about overlap or level of detail
• Don’t discuss activity wordings or other details
• Don’t make any judgements
• Write everything down
• On a single list, write any activities you think will
have to be performed
• Then study the list and group activities into a few
major categories with common characteristics
• Try to group activities into higher level activities
• Consider each category you have created
• Use top-down WBS development to determine any
additional activities you may have overlooked.

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 23

Displaying Work Breakdown Structures

• Three different formats are usually used

• Organization-chart format
• Effectively portrays an overview of your project
• Hierarchical relationships of participants, different
activities and tasks
• Outline format
• Subactivities and tasks are indented
• Bubble format
• The bubble in the center represents the project
• Lines from the center bubble lead to activities
• Lines from activities lead to tasks.

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 24

 Prepare Report
Prepare Report
1.0 Prepare draft
report
Prepare Review Prepare
Draft Report Draft Report Final Report
2.0 Review draft report
3.0 Prepare final report
3.1 Write final report
Org-Chart 3.2 Print final report
Write Print
Format Final Report Final Report
Outline
Format

Review
Final Report
Review
Draft Report Prepare
Report
Bubble
Format Review Write Print
Draft Report Final Report Final Report

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 25

What is the best display format for WBS?

• Organization-chart format:
• Often good for a “bird view” (executive summaries,...)
• Less effective for displaying large numbers of activities
• Outline format:
• Easier to understand, if WBS contains many activities
• Bubble format:
• Effective for supporting brainstorming
• Not so good for displaying work breakdown structures
to audiences who are not familiar with the project.
• Mixed approach
• In large projects

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 26

Heuristics for developing high quality WBS
• Involve the people who will be doing the work in
the development of the WBS
• In particular involve the developers
• Include information from WBS structures
developed for similar projects
• Use a project template if possible

• Use more than one approach to develop a WBS

• Do project activity-oriented and result-oriented approach
simultaneously
• This allows you often to identify overlooked activities
• Make assumptions regarding uncertain activities
• Identify risky activities
• These are often the activities whose times are hard to
estimate.
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 27
How Detailed should the WBS be?

• Activities in software projects are often unclear:

• Vague requirements and/or changing requirements
• Dependency on technology enablers that are promised
• Simultaneous development of hardware and software
(“concurrent engineering”)
• Heuristic:
• A WBS, especially for an innovative software project,
should not address details beyond 3 months.
• How should we describe a WBS for a longer
project?

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 28

Project planning
Introduce phases
• Phase 1 (1-3 months):
• Plan your WBS in detail
• List all activities that take one week or less to complete
• Phase 2, Phase 3, … (1-3-months):
• Plan the WBS for these phases in less and less detail
• List activities that will take between one and two months
• At the end of each phase, revise the activities and plan
them on the weekly level for the next 3 months

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 29

Phases in Projects

• Project-Initiation Phase
• Steady State Phase
• Initial Planning phase
• Project-Termination Phase

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 30

Project-Initiation Phase: To-Do List

• Activities
• Meet with client, develop visionary scenario
• Develop initial top level design (software architecture):
• System as a set of subsystems
• Establish staffing plan (flat staffing, ramping up)
• Identify human resources
• Hire team members
• Assign each team to a subsystem
• Establish additional cross-functional teams
• Write problem statement (with client and other stake
holders; if possible, involve project participants early)
• Write initial SPMP with WBS, but without schedule,
without budget

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 31

Initial Planning Phase: To-Do List

• Activities
• Do scouting on technology enablers that might
influence the design or nonfunctional requirements
• Revise requirements and initial top level design if
necessary
• Revise team structure, reassign team members if
necessary
• Revise WBS and dependencies
• Establish cost and scheduling information
• Agree with client on requirements, duration and cost of
the project
• Write the “project agreement” (companion document
to the SPMP)
• Duration: About 2 weeks time.
• When: After project kickoff, often called “planning phase”,
Parallel to “requirements elicitation phase”
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 32
Project-Termination Phase

• Do a project-review: “What went right, what

went wrong”
• also often called “project post-mortem review”
• Based on input from the post-mortem session
• Revise your software process, identify in particular any
new activities that happened in the project
• Revise your project kickoff activities
• Revise the SPMP template (to be reused for your next
project)

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 33

Where are we?
• SPMP IEEE Std 1058
• 0. Front Matter
• 1. Introduction
 2. Project Organization
• 3. Managerial Process
• 4. Technical Process
• 5. Work Elements, Schedule, Budget
 5.1 Work Breakdown Structure (WBS)
• 5.2 Dependencies between tasks
• 5.3 Resource Requirements
• 5. 4 Budget
• 5.5 Schedule
• Optional Inclusions
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 34
Additional Readings

• [IEEE Std 1058] Standard for Software Project

Management Plans
• Stanley E Portny, Project Management for
Dummies, Hungry Minds, 2001, ISBN 0-7645-
5283-X

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 35

Summary

• Different approaches to develop a WBS

• Product Approach
• Functional Approach
• Geographical Approach
• Organizational Approach
• Top down and bottom up WBS development
• Heuristics for developing good WBS
• WBS for Large Projects

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 36

Additional and Backup Slides

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 37

Heuristic: Use Templates

• Try to derive the SPMP from a template

• A template reflects the cumulative experience gained
from doing numerous projects of a particular type
• Using templates can save you time and improve your
accuracy
• When developing templates, develop them for
frequently performed tasks (reviews, meetings)
• Develop “Checklists”:
• Develop and modify your WBS templates from previous
projects that worked, not from plans that looked good
• Use templates as starting points, not as ending points
• Continually update your templates to reflect the
experience gained from performing different projects.

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 38

Heuristic: Develop more than one WBS

• Consider to create more several different

hierarchies with different categories for your
work breakdown structure
• Having two or more different perspectives helps you
identify activities you may overlook
• Good starting point are the following
hierarchies:
• Entity-oriented decomposition
• Activity-oriented decomposition
• Example: You are running your first object-
oriented project
• Develop a WBS based on the project documents
• Develop a WBS based on the software process
activities.
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 39
Heuristic: Identifying Risky Activities

• When you identify activities for a work

breakdown structure, you can also identify the
risks in your project.
• Risks are usually associated with “unknown
information”.
• Unknown information comes in two flavors
• A “known unknown”: Information that you don’t have
but someone else does
• An “unknown unknown”: Information that you don’t
have because it does not yet exist
• Describe these risks in SPMP 3.3 Risk
Management.

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 40

Risk Management Examples
• Risk: Members in key roles leave the project
• Contingency Plan?
• Roles are assigned to somebody else. Functionality of the
system is renegotiated with the client
• Risk: The project is falling behind schedule
• Contingency Plan?
• Extra project meetings are scheduled
• Risk: Team 1 cannot provide functions needed by team 2
• Contingency Plan?
• A: We drop the functionality
• B: The liaisons of both teams get together to solve this
problem
• Risk: The planned PDA platform will not be available in time
• Contingency Plan?
• We will use an PC for development.
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 41
Risk Management Examples ctd
• Risk: The selection of the database system takes
too much time
• Contingency Plan?
• The Database team uses a bridge pattern and provides a
test stub to be used by the other teams for data access
while the selection process goes on
• Risk: The customer is not available for discussing
and reviewing the user interface during
development
• Contingency Plan?
• Make the design decisions that we feel are appropriate
• Risk: No suitable wireless library can be found
• Contingency Plan?
• The team develops its own library.
© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 42
 WBS Based on Project Documents (Entity-
oriented)
<<Name>>
Project

Problem Project
RAD SDD
Statement Agreement
- Write Introduction - Write Requirements - Write Introduction - Write Design Goals
- Write Requirements - Write Constraints - Describe Functional - Write Hardware
- Write Constraints - Write Acceptance Model Software mapping
- ... Criteria - Describe Object Model -Write boundary
- Promise delivery date - Describe Dynamic conditions
Model - Write Data
... Management
- Write Open Issues
...

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 43

 WBS Based on Software Process (Activity-
oriented)
<<Name>>
Project

Project
Planning Analysis
Initiation Design

- Establish guidelines - Determine WBS - Brainstorm on - Develop Models

- Formulate requirements - Determine dependencies application domain - Write code
with client between tasks objects - Present problems to
- Establish scenarios - Write SPMP - Develop class diagram coach
- Write project agreement - Assign teams to - Partition objects into - Giove status reports
subsystems boundary, entity and - Write RAD
- Establish project control objects - Write SDD
calendar - Develop use cases - Write ODD

Question: Which activities mentioned in the WBS based on Project documents

is left out in the WBS based on Software Process?

© 2007 Bernd Bruegge Introduction into Software Engineering Summer 2007 44