Work Breakdown Structure

Work Breakdown Structure [1]

A hierarchical list of work activities needed to complete the project; a description of the work to be performed broken down to its key components, down to the lowest level.
Divide and conquer level
Work breakdown structure identifies activities at a level useful for selecting the team with the proper skills.
Based on staff number and estimates for the work breakdown structure, schedule cost and duration can be estimated.

Work Breakdown Structure Architecture [1]

The work breakdown structure must cover all activities
it is crucial to capture all disciplines or stages (requirements, design, implementation, testing…)
Project manager must ensure everything is covered

Work Breakdown Structure Ganularity [1]

Avoid too much detail and granularity.
Don’t plan in more detail than you can manage
Project manager has to train and trust the engineering team for those.
Stop at a level where there is sufficient information for the people who will work on the activity.
Obviously, don’t be too general either!

Milestones [1]

A milestone is a significant event
Usually associated with an interim deliverable
For IIP, there can be a milestone at the end of each iteration.
For eXtreme Programming (XP), there is typically a milestone every 1 to 3 weeks.
Important to get the numbers right:
- Too few: big-bang effect, progress will be hard to track
- Too many: slows down project
It is achieved as the result of the completion of a number of activities.

Work Packages [1]

Lowest identifiable activities to be completed
Contains:
- Description of work
- Staffing requirement (who, how many)
- Name(s) of personnel responsible for completion
- Schedule
- Budget ($, hours, …)
- Acceptance criteria (quality)
Used mostly for large groups, or smaller groups of people who haven’t worked with each other before; rarely used in smaller organizations.

Activities and Tasks [1]

Activity: the smallest component of the work breakdown structure, usually contains many tasks.
Task: the lowest level of effort, typically achievable by one individual.
Initially, an educared guess from past experience can be sufficient for the size of an activity. As requirements evolve, this size is estimated better.
We cannot have all the details needed for a project plan at the beginning!
It might be necessary later to break down larger activities
IEEE 1074 provides a set of 65 activities carried out by software project activities (not all of which are needed for all projects, but still a good guidelines)

3 Level Work Breakdown Structure [1]

One possible way to tackle the work breakdown structure:

Level 1: workflows
- Management, environment, requirements, design, …
Level 2: phases
- Inception, elaboration, construction, transition
Level 3: activities
- Lowest level that may be a work package or lead to a number of work packages

Creating the Work Breakdown Structure [1]

Go through existing documents
- requirements
- design documents
- customer conversations
Synchronize the work breakdown structure with the process framework: keep in mind the life cycle when doing the work breakdown structure.
Project manager: sanity check the work breakdown structure:
- everything is covered
- granularity is appropriate

—

[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 4