Scribd Logo
Upload

Welcome to Scribd!

  • 25 views

    Breakdown Top Tips

    Uploaded by

    Elchin Sattarov
    The document provides tips for developing an effective breakdown structure for project management. It recommends starting with clear project objectives and identifying the type of structure needed. The work should be subdivided into a pyramid with the most general levels at the top and most specific at the bottom. Each discrete element should have a unique reference code and estimates should be made at the lowest level. Common sense guidelines include tailoring the structure to each unique project, minimizing levels for clarity, and involving customers and the project team.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    Breakdown Top Tips

    Uploaded by

    Elchin Sattarov
    25 views2 pages
    The document provides tips for developing an effective breakdown structure for project management. It recommends starting with clear project objectives and identifying the type of structure needed. The work should be subdivided into a pyramid with the most general levels at the top and most specific at the bottom. Each discrete element should have a unique reference code and estimates should be made at the lowest level. Common sense guidelines include tailoring the structure to each unique project, minimizing levels for clarity, and involving customers and the project team.

    Original Description:

    Schedule breakdown

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document provides tips for developing an effective breakdown structure for project management. It recommends starting with clear project objectives and identifying the type of structure needed. The work should be subdivided into a pyramid with the most general levels at the top and most specific at the bottom. Each discrete element should have a unique reference code and estimates should be made at the lowest level. Common sense guidelines include tailoring the structure to each unique project, minimizing levels for clarity, and involving customers and the project team.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    25 views2 pages

    Breakdown Top Tips

    Uploaded by

    Elchin Sattarov
    The document provides tips for developing an effective breakdown structure for project management. It recommends starting with clear project objectives and identifying the type of structure needed. The work should be subdivided into a pyramid with the most general levels at the top and most specific at the bottom. Each discrete element should have a unique reference code and estimates should be made at the lowest level. Common sense guidelines include tailoring the structure to each unique project, minimizing levels for clarity, and involving customers and the project team.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 2

    PROJECT MANAGEMENT ESSENTIALS

    Top Tips for Developing a Breakdown Structure

    The following is a list of simple but effective tips that you should use each time you
    create a breakdown structure.

    1. Be clear on your project objectives: these are your starting point.


    2. Identify the type of breakdown structure you need to do, e.g. WBS, PBS, OBS, CBS.
    3. Sub-divide the work, from the most general level at the top, down to the most specific
    at the bottom, until manageable units are achieved; i.e. organise the outputs or work
    into a pyramid arrangement.
    4. Define the objectives and inter-relationships at each level within the structure.
    5. Allocate each discrete element of the structure a unique reference code (1.1, 1.2
    and so on).
    6. Estimate effort, time and cost at the lowest level of the WBS or PBS.

    Project

    1 2 3

    1.1 1.2 1.3


    3.1 3.2

    7. This process should be democratic, with all project participants being represented
    so that nothing is left out, ensuring all parties commit themselves to, and take
    responsibility for, their part in the project.
    8. When developing your breakdown structure, check the following:
     Does the structure represent how the work is going to be done?
     Is it compatible with other existing processes (e.g. time recording, purchasing,
    finance, etc.)?
     Is there consistency in size of the lowest level activities (or tasks)?
     Can I reconcile the structure back to the requirements (or contract) to ensure
    that all elements are included?
     Can I be sure that there are no tasks that cross a phase or stage boundary?
     Have I got too much detail or developed too many levels?
    9. When developing a WBS, and all tasks identified, it is useful to check that all tasks
    have the following attributes:
     results in a product
     is a definable scope of work
     has a measurable start (restraint)
     has a measurable finish
     any assumptions are clearly stated

    Some Common Sense Guidelines

    It is impossible to define a single set of workable rules on how to develop a Breakdown


    Structure. However, a number of common sense guidelines do exist. Remember...

     each project is different


     each project manager has a preferred approach
     customers may have a preferred approach
     tasks must not cross life cycle stage boundaries

    Tasks should be of a size that they could be completed within two reporting periods but:

     Project management or other support tasks should not be unnecessarily limited.


    They should cover a phase or stage of the project and should, ideally, have a
    duration of no longer than twelve months.
     If an activity is to cover outside purchases that have a long lead-time, it is counter-
    productive to split this work into separate tasks.
     If an activity is to cover intense activity over a short time period, it may be useful
    to sub-divide the activity into smaller elements (tasks) than two months.
     Do not develop the WBS in to too much detail in the early stages of a project. A WBS
    that has been developed too early will require frequent changing. Once a WBS has
    been set up it becomes difficult to change.
     Minimise the number of levels. Too many levels will cause confusion and
    misunderstandings.
     Look at other successful projects. Copy their ideas and layout. Examine unsuccessful
    projects and learn from their failures. Use templates where possible.
     Leave gaps in any numbering system. Anticipate changes and variation orders. By
    leaving gaps, any new tasks can be built into the structure at a logical point.
     If projects are short-term and can be completed in one or two reporting cycles it is
    pointless to develop a detailed WBS. In many of these cases, a single activity with
    associated tasks may suffice.
     Each task must have strictly defined entry and exit criteria, with the scope of each
    work package being unambiguously defined.
     Templates can be useful but do not slavishly copy them. If templates or structures
    from other projects are being used as the basis for developing the WBS, take care to
    ensure that elements are not omitted or that elements have not been included from
    the template that do not apply to the current project.
     If possible, involve the customer when developing the WBS. Also involve the
    project team. They are the people who have to accept responsibility for doing the
    work.

    You might also like