Category Archives: Schedules

For the novice – and not so novice scheduler, creating a dynamic, logical, and accurate schedule can be a daunting task. Having in your tool-kit and adhering to a ‘good scheduling practices checklist’ is essential in achieving that goal. Project managers demand and expect accurate schedules that gives them confidence in using it as one of their chief management tools. Professional, well-structured schedules just do not happen by accident. Here are some of the governing principles/ standards that can guide you in what to do/ what not do when creating a project schedule.

Schedule should map to the WBS, which defines the project’s scope

Tasks should have a verb in the task name

Task Duration: Assigned duration should be consistent with the work/scope required to complete the task

Long durations on discrete tasks should be avoided. Generally no longer than 2 months

Constraints: Constraints fine-­tune a logic-driven schedule by establishing date restrictions based on factors such as component delivery, near term resource availability, or contractual obligations.

Soft constraints such as Start-No-Earlier-Than and Finish-No-Earlier-Thanenable the schedule to be logic-driven. If there is a logical reason/ justification for using a constraint, it should be documented

Use of hard constraints such as Must-Finish-On, Must-Start-On, Start-No-Later-Than, & Finish-No-Later-Thanprevents tasks from being dynamically adjusted by their dependencies (predecessors/ successors)/ network, thus preventing the schedule from being logic-driven. Hard constraints should therefore be avoided

All schedule tasks, except the first and last, should be linked (at least one predecessor and one successor), creating the schedule ‘network’ which shows logical dependencies. Missing predecessors/ successors will skew the networked logic, creating erroneous forecast dates, and an inaccurate critical path (CP). Project managers and SMEs/ technical leads need to verify the accuracy of the network. Relationship types: There are four scheduling relationship types used for linking: Finish-to-Start (FS), Finish-to-Finish (FF), Start-to-Start (SS) and Start-to-Finish (SF)

Start-to-Finish (SF) relationship type is counter-intuitive (“the successor cannot finish until the predecessor starts” – huh?) and should only rarely be used and with detailed justification

Lags and Leads: A lag is a delay in the start of a successor task; leads are the opposite – they accelerate the start of the successor. Lags and leads should be used sparingly. Leads are illogical and should be avoided. If a ‘lead’ is absolutely necessary, changing the relationship type to SS with a lag is recommended. Use of lags should be documented.

Summary Tasks: Summary tasks should not be linked and should not have resources assigned to them. Linking summaries causes errors in the schedule network and dates by preventing the start of other summary groups until all sub-tasks are completed. Summaries are just that – they are intended to only provide a calculated rollup of the subtasks and linking summaries skews the summary % complete calculation.

Level of effort (LOE) tasks that continue for the life of the schedule should have durations less than the overall duration of the total program to ensure they do not fall on the critical path (CP).

Schedule structure: Horizontal Integration – shows work is planned in a logical sequence considering interdependencies; work and planning packages. It ensures the overall schedule is logical and depicts schedule dependencies, etc. within the same scheduling level.

Schedule Structure: Vertical Integration – Shows consistency between various scheduling levels and consistency between various WBS elements in the schedule.

There is a wealth of information on scheduling practices, techniques, standards, etc. that can be quickly found, including PMI Community of Practice, Microsoft Project Users Group (MPUG), LinkedIn scheduling/PM groups, Project Management blogs, webinars, seminars, and the like. Quick internet searches should get you 95% or more of what you’re looking for when developing your schedule. Remember: a good schedule needs to be accurate in scope definition, dynamic in structure, and realistic.

According to Wiki, “The Work Breakdown Structure (WBS)…is a deliverable oriented decomposition of a project into smaller components. It defines and groups a project’s discrete work elements in a way that helps organize and define the total work scope of the project.” So what does this really mean? The Work Breakdown Structure (WBS) is an integral tool in developing the project schedule. But what is a work breakdown structure, where does it come from, how is it developed? The WBS is developed directly from the contract/ Statement of Work/ Requirements document. The high-level WBS should be directly traceable to the governing scope document for the project/ program.

Brief History:

WBS was first developed by the Department of Defense (DoD) during the early days of the Program Evaluation and Review Technique (PERT) development. According to the DoD the WBS is:

a. A product-oriented family tree composed of hardware, software, services, data, and facilities. The family tree results from systems engineering efforts during the acquisition of a defense materiel item.

b. A WBS displays and defines the products or deliverables, to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end-result. In other words, the WBS is an organized method to breakdown a product or deliverable into sub-products at lower levels of detail.

c. A WBS can be expressed to any level of interest. Generally, the top three levels are sufficient unless the items identified are high cost or high risk. It is then important to take the WBS to a lower level of definition.

The WBS precedes schedule development – that is the schedule is produced from the WBS and Integrated Master Plan (IMP); it traces directly from the project scope, the “what”, i.e. “what is/are the thing(s) that will be delivered. The Integrated Product Team (IPT – Systems, Software, Hardware, CM, etc.) reviews the high-level deliverables and breaks them down (decomposition) into chunks (actual deliverables, not tasks) at the next lowest level. This breakdown process continues at each level culminating in a deliverable-oriented hierarchy until you get to the lowest “what”. At each decomposition level, use of the “100% rule” is applied. Simply, the “100% rule” says the sum of the “what” of the child level must equal 100% of its parent.

Since the WBS is focused solely on scope, it does not granulate to the “how” level. “Hows” are the activities and tasks from which the schedule is developed. To use an analogy, the WBS is the backbone (support structure) whiles the activities and tasks comprise the ribs and appendages connected to the backbone.

When scope creep inevitably rears its ugly head, the PM can raise her/ his WBS shield to hopefully thwart this enemy. If management wants additional requirements or scope, then the WBS speaks up and says, ‘no can do….unless you provide additional time and resources’. The WBS is, in fact one the PMs best friends and strongest allies.

One the very heated and passionate debates of the project management discipline is that of the capabilities of the well-known critical path form of schedule analysis and management and the lesser-known critical chain. Guest columnist, Mr. Barry Clark, a credentialed schedule professional, writes this month’s Schedule Dispatch on the major differences between these two often-confused scheduling tools.

Critical chain (CC), derived from the Theory of Constraints, is the longest chain of tasks in the schedule that accounts for both duration and the resources required for tasks. Simply stated, the critical chain is the ‘resource constrained critical path’. By contrast, the Critical path (CP), the longest chain of tasks in the schedule that represents the shortest amount of time to project completion, is irrespective of resource availability or resource allocation or over-allocation. Critical path strictly considers task duration and float (the difference between late finish and early finish, or late start and early start), ignoring resource availability, over-allocation, and possible multiple tasks having assigned identical resources that are simultaneously scheduled. Resource over-allocation inevitably results in bottlenecks and/or scheduling conflicts that invariably lead to schedule delays.

One of the key differences between CC and CP is their use of buffers. Buffers are added to tasks or schedule as blocks of time to prevent slippage. Critical chain utilizes buffers, while Critical path does not. There are three types of buffers:

1) Feeding Buffers: time-block set at the end of a sequence of non-critical tasks;

2) Resource Buffers: time-block set aside to indicate resource needs. It is basically a resource place-holder;

3) Project Buffer: time-block set aside at the end of the project.

These buffers are strategically placed along the critical chain to account for and accommodate resource allocation, risk avoidance, and human behaviors, i.e. Parkinson’s Law and student syndrome. Parkinson’s Law is filling available time with redundant work when tasks are completed early (if you know you have a set time to complete a task, people generally will use the entire time); student syndrome is putting off until the last minute what should have been initiated earlier. Both issues are chronic problems in traditional scheduling using CP analysis.

Comparatively, the Critical path doesn’t consider resource allocations or dependencies, or the use of time-blocks (which reduces schedule risk), and basically ignores non-critical tasks, which can easily become critical. When projects inevitably run afoul, CP calls on schedule crashing and fast-tracking to ‘right-the-ship’ (move back to the left, or ‘left-the-ship’).

Conclusions:

Given the nature of projects (and people who work them), including poorly defined project tasks, unknown pop-up tasks, unrealistic durations, multi-stakeholders with varying interests, volatile financial/ resource markets, etc., it is little wonder why projects run at an unacceptably high failure rate. Critical Chain analysis accounts for many known and unknowns (risks) and addresses the human factor, which consequently keeps projects under control more effectively.

With focus on resource leveling and bottle-neck avoidance (and thus risk avoidance), Critical chain scheduling paints a more realistic view of current status and future project outcome given that many projects are often underfunded and understaffed (usually due to Management’s demand to do more with less). If they are running a tight critical chain ship, the Project Manager need not sound the alarm to arms since the buffers have provided the needed relief; if however, they are running a Critical path ship and rough gales are eminent, crashing or fast tracking the schedule may exacerbate an already precarious situation.