Work Breakdown Structures - PowerPoint PPT Presentation

Loading...

PPT – Work Breakdown Structures PowerPoint presentation | free to download - id: 75bd3c-M2NhN



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Work Breakdown Structures

Description:

Work Breakdown Structures Identifying Manageable Activities – PowerPoint PPT presentation

Number of Views:56
Avg rating:3.0/5.0
Slides: 55
Provided by: uwi61
Learn more at: http://web2.uwindsor.ca
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Work Breakdown Structures


1
Work Breakdown Structures
  • Identifying Manageable Activities

2
Agenda
1. Creating a WBS
2. Using the WBS for Estimation
3
Work Breakdown Structure
  • Work
  • A WBS considers the work that needs to be
    performed
  • This includes development, but also user manuals,
    sales support, administration, deployment, media,
    etc.
  • Breakdown
  • Work is broken down (decomposed) into small
    pieces (activities)
  • Activities are eventually broken down into tasks
  • A task is something that takes less than a week
    to complete
  • Activities are normally assigned to individuals
  • Structure
  • Each unit of work is broken down into a number of
    components
  • The result is a hierarchical structure
  • The lowest layers are tasks
  • e.g. A function that generates a polynomial
    collision-handling hash function is completed
  • e.g. Send user manual prototype to printer for an
    estimate
  • The middle layers could be milestones
  • e.g. Getting started tutorial is completed
  • The highest layers are normally deliverables
  • e.g. Source code distribution, with configuration
    and makefiles, is completed

4
Terminology
  • Activity
  • Some behaviour that needs to be done
  • Produces some outcome (e.g. a deliverable)
  • Is often decomposed into other activities or
    tasks
  • Task
  • An activity that is not decomposed
  • Is at the lowest level of the WBS
  • Also called a work package

5
Example WBS
Usability Training
1 - Personnel Available
2 - Training Seminars Booked
57 - Hotel Rooms Reserved



2.1 - Deal Made with Susan Carleson
2.13 - Cheque Requisition Made to Accounts
Payable
2.2 - Budget Approval Form Submitted to Accounts
Payable

6
Advantages of a WBS
  • The WBS
  • Gives you a somewhat complete list of tasks
  • Later, this can be a checklist to show how much
    is still to be done, and how much is done
  • Allows you to easily assign work to team members
  • Requires you to solidify things that are still
    vague, even after requirements analysis
  • Generating a WBS enables you to methodically
    decompose the work, exposing new risks and
    resource requirements

7
WBS Process Overview
  • The WBS process is basically as follows
  • The WBS is normally created from the top down
  • The estimates are created at the bottom
  • The estimates are summed from the bottom up
  • The totals at the top are used as input for the
    schedule

8
Creating a WBS Top-down
  • The top-down approach
  • Start with the projects overall goal
  • Decompose the goal into deliverables
  • Decompose the deliverables into modules
  • When you are finished you have tasks
  • Tasks should be a few days work or less
  • This is an iterative technique to creating a WBS
  • In XP projects, the WBS iterations might produce
    only a part of the next level while requirements
    are still being worked out
  • However, it should produce some tasks, so that
    work can begin
  • It is a good idea to create the WBS as a group
  • This can prevent important activities from being
    missed, and can add a level of peer evaluation to
    the process

9
When is a WBS done?
  • Since WBS is iterative, it could go on forever
  • There are guidelines for what is enough
  • Status/completion is measurable
  • The activity/task is bounded
  • The activity/task has a deliverable
  • Time and cost are easily estimated
  • Activity/task duration is within acceptable
    limits
  • Work assignments are independent

10
Status/Completion is Measurable
  • Project managers will ask team members about
    status
  • Status is generally how close they are to
    completion
  • Activities
  • Status of an activity is the ratio of completed
    tasks
  • e.g. Im finished 35 of 55 tasks, so Im 64 done
  • Completion of an activity is when all of its
    tasks are complete
  • Tasks
  • Status of a task is generally small enough to
    estimate
  • e.g. Ive written all the code for the class, and
    just need to test it, so Im about 50 done
  • Completion of a task should take a few days or
    less

11
The Activity/Task is Bounded
  • The starting and ending points of an activity
    should be well-known
  • How do you get started on the activity? What
    task to do first?
  • How do you finish the activity? What is the
    last task to be done?
  • e.g. Optimize the search engine
  • Tasks
  • Determine from customers the expected wait time
  • Measure existing search engine for comparison
  • Examine code for potential slowdowns
  • Make changes where possible
  • Investigate compiler options which could improve
    performance
  • Update build file to use new compiler options
  • Deploy search engine to test server
  • Measure new search engine performance
  • Verify that search engine meets customer criteria
  • Deploy search engine in public server
  • Ask customer for review and acceptance

12
The Activity/Task Has a Deliverable
  • All activities should produce something
  • High-level activities produce the deliverables
    outlined in the requirements
  • e.g. Source code distribution, user manual, DVD
    media
  • Lower-level activities can produce other
    deliverables
  • e.g. AI engine, device API for bar code readers,
    a customer class

13
Time Cost are Easily Estimated
  • The less work is involved in an activity, the
    easier it is to estimate
  • When we get down to task level, it should be
    possible to accurately estimate time and cost
  • Time It is less work, so estimates should be
    accurate, particularly when the task is similar
    to something else done recently
  • e.g. Write the code to manage persistence of
    customers to/from the database
  • This is similar to other persistent code you have
    (or will) write, so can be accurately estimated
  • Cost You will know if there are additional costs
    required
  • e.g. Licenses for an IDE, books, training
  • Well deal with estimation separately

14
Activity/Task Duration is Within Acceptable Limits
  • Activities can take a very long time
  • However, tasks (the lowest level of
    decomposition) should be limited in duration
  • Generally, less than 1-2 weeks is considered
    acceptable
  • This is something that can be easily tracked
  • Also, if something goes wrong, things should not
    go to far off track
  • e.g. A 5 day task takes 7 days to complete
  • e.g. A 10 day task was a waste of time, and needs
    to be re-thought

15
Work Assignments are Independent
  • When a task is assigned to a team member, it
    should be possible for that team member to
    complete without further instructions
  • e.g. A team member should not be meeting daily
    with a manager or customer while working on a 10
    day task
  • A team member working on a task should have all
    they need when they begin
  • A team member building on another tasks
    deliverables should start the task after the
    other tasks deliverable is ready
  • e.g.
  • A team member is working on improving the design
    for the 3D graphical engine
  • When this is complete, another programmer might
    want to incorporate her code into the graphics
    engine
  • This should not be done until the graphics engine
    is complete (with respect to the re-design)

16
Common Sense with WBS
  • Another way to ensure a WBS is complete is to use
    common sense
  • If you were to tell a young child to brush their
    teeth, they might need more detailed instructions
  • Get your toothbrush and the toothpaste
  • Put a little bit of toothpaste on the toothbrush
  • Brush the front, back, tops, bottoms, and sides
    of your teeth
  • Spit into the sink
  • Rinse out your mouth with some water
  • Put away the toothbrush and toothpaste
  • However, team members have done similar tasks
    before
  • If you say brush your teeth to an adult, they
    know what to do
  • Not only is it a waste of time to go into more
    detail, it is also insulting
  • This is called micromanaging

17
Activity/Task Names
  • Activities and tasks should have active names
  • e.g. Create a chart of search engine performance
  • e.g. Develop a sales pattern for the sales team
  • e.g. Establish a set of coding standards

18
Task Sequencing
  • In the WBS, tasks and activities are listed in
    chronological order where possible
  • e.g. In the setup development environment
    activity
  • Purchase new computers must come before
    Install IDE
  • However, specific task ordering will be done in
    the schedule later

19
Estimation
20
How to Estimate Software
  • How do you estimate how long it will take to
    develop a project?
  • Lets say you have an assignment due in 2 weeks
  • You want to decide when to work on it
  • You want to fit that into your schedule
  • To do so, you need to know how many hours it will
    take

21
Estimation
  • Estimation involves using the following
    information in order to make an educated guess
    about time or resource requirements
  • Knowledge of the work required (expertise)
  • Ask people who know how long it should take
  • Group knowledge
  • Coming up with estimates as a group is no
    substitute for expertise, but sometimes expertise
    is not available
  • Advice from a group is generally more reliable
    than advice from an individual
  • Prior experience
  • e.g. It previously took 8 minutes to copy, print,
    seal, stamp, and address 1000 brochures
  • It should take about 80 minutes to get 10,000
    brochures ready
  • Historical data
  • e.g. The team has worked on 3 other projects,
    which were all 25-50 over-budget on time
  • Therefore, expect them to go over their own
    estimates by a similar factor

22
Estimation
  • Who creates estimates?
  • Technically, the project manager does
  • However, the PM is not an expert in all areas
    (e.g. deliverables)
  • Thus, the experts need to be consulted when
    creating estimates
  • The experts are the people who might be asked to
    do the work
  • It is wise to get a second (or third) opinion, to
    offset estimate bloat and over-optimism
  • Estimates should start from the task level, since
    they are easy to estimate

23
Estimates as Ranges
  • If you dont know what the customer wants, so you
    cant yet make an informed decision

This house should take about 4 months to build.
Good! We have a deal.
Contractor
Customer
24
Estimation Units
  • There are several units in estimation
  • Total time
  • e.g. It should take 3-4 weeks, with a most likely
    estimate of 18 days
  • This makes it obvious when the project should be
    completed
  • Human resource utilization (effort)
  • e.g. It should take 2-3 person-months, with a
    most likely estimate of 10 person-weeks
  • This way, you can see how adding people to the
    project will affect its duration
  • Lines of code (size)
  • e.g. It should be around 50,000 lines of code
  • This figure can then be used for other estimates,
    such as total time
  • However, few developers count lines of code
    anymore, so this is not very common
  • Also, not all lines of code are created equal
  • Function points (size/difficulty)
  • An estimate of the number of inputs, outputs,
    files, database tables, etc. that an application
    will require
  • e.g. This should have 6 inputs of low complexity
    (x3), 2 inputs of medium complexity (x4), and
    for a 286 function point score

25
Creating Estimates
  • Estimates are created at the bottom, and work
    their way up
  • Tasks can be estimated easily
  • The activity durations can be computing by taking
    the sum of the task durations
  • This allows us to estimate activities that are
    cross-disciplinary
  • However, minor deviations in task durations can
    quickly add up to major deviations in activity
    duration
  • This is exactly why you use an estimate range
  • If your range includes the actual duration, it
    will be difficult to say that you were wrong
  • Creating an accurate estimate from day one is
    impossible

26
Case Study
  • PathFinder 2.0

27
Getting an Initial Estimate
  • Barb Having gathered requirements for the
  • PathFinder 2.0 project, how long do you think
  • it will take?
  • Tyrone Ive been thinking about this quite a
    bit, and Ive come up with about 4 months.
  • Barb That long?! I told the board of
    directors it
  • would be ready in about a month!
  • Tyrone We might be able to save some time here
    and there. Let me look at it again.
  • Barb Good. Lets aim for 1 month.

28
After Some Thought
  • Having examined the project further, Tyrone was
    able to cut corners by shortening the design
    duration, but still not enough to fit the 1 month
    schedule
  • However, Barb was so outraged by his original
    estimate, that he didnt have the courage to say
    anything to her about the slip
  • Perhaps the team will pull it together with the
    tighter budget

29
3 Weeks Later
  • Tyrone Barb, the team has been putting loads of
  • overtime into this project, but were not even
  • close to being finished. We just plain need
  • more time.
  • Barb Thats disappointing Ty. Ok, lets aim
    for 3
  • months total. That should be more than
  • enough time, given the extra hours your team
  • is putting in.
  • Tyrone Yes, I think so.

30
In the Meantime
  • Many aspects of the software have been hacks and
    the result is really ugly, low-quality code
  • The code is being constantly re-worked due to the
    lack of a decent design
  • The development is taking longer than expected,
    since team members have a tough time
    understanding the code with all the hacks and
    poor design
  • However, since they are in such a rush, they do
    not feel there is enough time to fix the hacks or
    refactor the code to represent a better design
  • The result is slow development and unreliable
    code
  • To meet the schedule, Tyrone increases
    development time well into the QA time

31
2 Months Later
  • Tyrone Were finished coding. This week will be
    for
  • quality assurance.
  • Barb Good, but I thought that QA was scheduled
  • for 3 weeks?
  • Tyrone It was, but we had to finish
    development.

32
The result
  • The final code was very poor quality, due to
  • Poor design
  • Rushed development, which included many
  • Bugs
  • Hacks

33
The result
  • The reduced QA time meant that the team only
    found the most obvious bugs and were able to fix
    them by the deadline
  • When the customer saw the finished product, it
    crashed twice and produced the wrong output on
    one occasion
  • The customer requested that the project be more
    thoroughly tested
  • After 6 more weeks, the product still had some
    bugs, but was finally useable
  • However, the customer was no longer interested,
    since
  • So much time had passed (5½ months), they lost
    interest
  • Market share had already been acquired by another
    competing product
  • They lost confidence in the team due to the poor
    quality product
  • Not to mention managements confidence in Tyrone
  • Is this entirely Tyrones fault?

34
Summary
  • The creation of WBS has only a few rules
  • It is created with the help of a team
  • The 1st level is completed before the project is
    broken down further
  • Each level of the WBS is a smaller segment of the
    level above
  • Work towards the project deliverables
  • Work not in the WBS is not part of the project
  • Break down the project into work packages or
    activities that
  • Can be realistically and confidently estimated
  • Cannot be logically further subdivided
  • Can be completed quickly (few days)
  • Have a meaningful conclusion and deliverable
  • Can be completed without interruption (without
    the need for more information)

35
An Introduction
  • Planning Scheduling

36
What is a plan?
  • A project plan is a network of dependent and
    independent tasks
  • A plan may also contain descriptions of persona
  • A persona is a fictitious representation of a
    real person
  • The plan may also include assignments of tasks to
    various persona
  • An important part of the project plan is the
    network diagram, which shows task flow and task
    dependencies

37
What is a schedule?
  • A schedule is a description of start and end
    times for all the WBS tasks
  • The schedule accommodates the plan
  • The schedule specifies all dates in terms of
    offsets from the start date
  • Ideally, the start date is a parameter which can
    be changed if the project start is delayed
  • This way, real dates can be seen
  • However, dates are not hardcoded so they can be
    easily changed
  • An important part of the schedule is the Gantt
    chart

38
Planning
  • Planning Scheduling

39
Network Diagram
  • A network diagram shows task/activity flow
  • Flow from one task to another may indicate
  • Dependencies between the tasks
  • Chronological ordering between the tasks
  • Parallel task flows indicate task independence
  • It is not necessarily the case that tasks may be
    done in parallel, but it is possible
  • Example

40
Task/Activity Dependencies
  • Finish to start One task/activity must finish
    before the other task/activity can start
  • e.g. Order PCs must finish before Install IDE
    begins
  • Start to start One task/activity must have
    started before the other task/activity can start
  • e.g. Design AI module must start before
    Implement AI module begins
  • Start to finish One task/activity must start
    before another task/activity can finish
  • e.g. Ensure successful handoff to Team B cannot
    finish until Team B begins work
  • Finish to finish One task/activity must finish
    before another task/activity can finish
  • e.g. User documentation screenshots must finish
    after User interface implementation

41
Network Diagram
  • Many notations exist, but a UML behaviour diagram
    is common
  • Here is an example network diagram showing start
    to finish dependencies

Make deal with Susan Carlson
Submit budget approval form to accounts payable
Register for seminars on the finalized dates

Collaborate with project managers to find
available times for employees
Finalize trip time with employees
Have employees sign waivers

42
Personas
  • A persona is a fictitious representation of a
    real person
  • e.g. Java Developer A
  • This could match either George Smith or Arin
    Kumal
  • The plan will not mention people by name, however
  • A persona has certain skills
  • e.g. Familiar with OOP, Java, modular
    programming, coding standards, documentation,
    etc.
  • A persona can be assigned responsibilities, such
    as tasks from the WBS

43
Why not use real names?
  • People might not be available when the project
    begins
  • A project may go over schedule
  • Our project start may be delayed
  • Replacement people will resent not being the
    first choice if they see the other names
  • The fact is, many project managers create a plan
    with real people in mind
  • They may write out somewhere else who Java
    Developer I is, and who Network Admin is, etc.

44
Task Assignment
  • Another part of the project plan is the task
    assignment
  • This includes a description of all team members
  • These are normally personas
  • The persona description will include a reasonable
    set of expected skills that the real person
    should have
  • For each task, a team member is assigned
  • This is done after the network diagram, so that
    work can be distributed evenly

45
Task Assignment
  • User interface expert
  • Java developer I
  • Java developer II
  • Database developer
  • Database admin
  • Server admin

Task Team Member
Create visual prototypes of the UI User interface expert
Write code to persist registration data Database developer
Write code to generate MD5 of password Java developer I
etc etc
46
Schedules
  • Planning Scheduling

47
Schedules
  • A schedule is an implementation of the project
    plan
  • However, in industry lingo, a project plan
    document normally includes the schedule
  • A common schedule representation is a Gantt chart
  • A Gantt chart is a graphical depiction of the
    task flow, with dates
  • Dates are shown as the x-axis, so questions about
    start/end times can be answered
  • e.g. Relative start times of parallel tasks
  • e.g. Completion of all of an activitys tasks
  • e.g. Chronological dependencies between tasks
  • However, other formats are possible
  • A calendar, showing tasks started, active, and
    completing
  • A list of task descriptions, including start and
    expected end dates

48
Gantt Charts
  • Visual representation can help when a project
    manager needs an overview

November
December
September
October
User Interface Prototype
Registration Dialog
etc
Registration Persistence
Code to Gen. Password MD5
etc
49
A Practical Guide
  • Planning Scheduling

50
Creating a Schedule
  • In practice, a PM will use a project management
    tool to do much of their work
  • Microsoft Project
  • Gantt Project
  • Open Workbench
  • OmniPlan
  • All of these applications let you easily create
  • Gantt charts
  • Task descriptions
  • Calendar views

51
Using Microsoft Project
  • Using Microsoft Project to create a schedule is
    easy
  • Step 1 Enter the tasks
  • Enter the task name
  • Enter the start time
  • Enter either the duration or expected end time
  • Enter dependencies, if any

52
Using Microsoft Project
  • MS Project generates the Gantt chart for you
    automatically, on the right

53
Using Microsoft Project
  • MS Project allows you to change dates whenever
    you want
  • Thus, you can push back the start date if the
    project is delayed
  • The entire schedule is shifted over in response
  • You can add/change dependencies as you wish as
    well
  • Next to tasks is a space for resources
  • Here is one place where you could put in persona
    names
  • e.g. Java developer I

54
Common Schedule Problems
  • Problems with estimates or deadlines
  • Customer or upper management set deadline without
    team consultation
  • Schedule is based on best case estimates
  • Target date moved up without re-adjustment to
    scope, resources, or schedule
  • Problems with requirements
  • Schedule omits necessary tasks
  • Project size is impossible within allotted time
  • Project is larger than estimated
  • Effort is greater than estimated
  • Problems with schedule management
  • Schedule was based on specific team members that
    will not be available
  • Schedule slips are ignored when schedule is
    re-evaluated (velocity)
  • Delays in tasks result in delays in dependent
    tasks
  • Unfamiliar territory causes unexpected delays
  • Problems with productivity
  • Demotivated personnel (e.g. schedule pressure)
  • Weak personnel
  • Friction between team members
About PowerShow.com