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