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
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