Building a WBS by Robert Kelly, MCP | May 24, 2005

Scheduling a project can be a daunting task. Whether you are developing a WBS or auditing one here are some things that will help.

    Scheduling tools are designed to provide an objective baseline and measure of performance during, and after a project.
        Plan and analyze when a project, with a given scope and resource pool, will complete (or must start)
        Provide a rough estimate of resource cost
        Provide performance metrics: Schedule Variance, Cost Variance, and CPI

    Microsoft Project is not:
        Time reporting / tracking tool
        Detailed financial analysis tool
        Tool to capture lessons learned

    Work Breakdown Structures (WBS)
        Do not and cannot drive any processes
        Must model the processes used by the environment
        Is not a schedule
        Are DELIVERABLE based NOT activity based


When building a WBS the above should be considered with the following:

    The purpose of tasks is to produce deliverables.
        The identification of deliverables and tying those deliverables together is how a WBS is created
        Thinking and attending meetings are not tasks, they are step required to complete tasks
        If three meetings with five people are required to produce a deliverable the meetings are not listed as tasks
        Duration, and work are applied to tasks. Sufficient work and time are allocated to tasks to account for meetings and thinking.

    Only have as much detail in a WBS as required to track and status the project and provide pro forma analysis.
        The fewer tasks you have on the WBS the more assumptions you have to make regarding what effort will go into the task and completion of the deliverable associated with them
        If you have too many tasks/too much detail your WBS can get bogged down in a level of detail that is cumbersome and difficult to maintain
        This also applies to deliverables. Sometimes it is better to capture intermediate deliverables in a separate document or use the Notes field of the deliverable.

    Only assign resources you have control of to tasks you have control of
        Applying resources you don't have control of to deliverables can cause unnecessary leveling delays and frustration
        If a vendor is responsible for providing a deliverable do not attempt to apply resources to the deliverable
        Vendor deliverables are milestones with a date constraint promised by the vendor
        The cost of the deliverable can be tracked in the "Fixed Cost" field.
        This information is captured in the baseline along with all other information so it can be tracked and reported on
        It does not matter if the vendor uses one person or ten to complete the deliverable, only the actual cost and delivery date are relevant to the WBS
        Vendors should use appropriate planning to commit to deliverable due dates. It is common to audit vendor schedules to verify the planning and commitment dates.


Now about that, "a WBS is not a schedule", comment. Schedules are activity based; they tell someone or a group what to do, when to do it, and the order it must be done it. This information is derived from the WBS. If you focus on the schedule while developing a WBS you will not build a good WBS.

"Work Breakdown" is about decomposing an elephant into its basic parts (deliverables), identifying the relationship between those parts (predecessors & successors), and how much effort and how long it will take to produce each part (work/duration). The assignment of resources to produce the parts and assemble them together is the last step.

NEVER schedule tasks to be sequential because the same resource is working on them (this would be a schedule mentality) it will corrupt your critical path. Leveling will account for over allocations. Critical Path is the longest path through the WBS based on successors and free slack. This is independent of resources and is explained in the axiom, "Nine women can't have a baby in a month." Most projects have an end date beyond the critical path, if only because of resource constraints. However most projects reach the point of being driven by critical path and not resources. It is important to know when that happens because after that any slip in production of deliverables causes a slip in the project end date.
Robert Kelly
former Project Manager
Expert Scheduler
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值