Scheduling Best Practice Conundrums

by TheCobraGuy

The following are top tips from professional schedulers that will help keep your project on track:

There are some common mistakes made during the creation of project schedules, particularly by folks who are new to the art. In this article I’ll be pointing out a few of the most frequent scheduling faux pas that we encounter out in the field, and talk about common best practice guidelines and the dilemmas that these can throw at schedulers working in the real world.

I’m focusing on following guidelines that are common to many publications including Unified Facilities Guide Specifications (UFGS) and the PMI’s Project Management Body of knowledge (PMBOK).

1. Avoid Open-ended Logic.

2. Use as few constraints as possible.

3. Keep activity durations below 45 days unless they are Level of Effort (LOE) type tasks.

One problem I’m always wrestling with when it comes to using best practice guideline, is that they often seem to be contradictory. Following one guideline seems to cause you to have to ignore another. The following is an example of a best practice guideline that will get you into a dilemma.

Open-ended Logic

Various guidelines say to avoid open-ended logic activities that have no successors. This seems to be the most common issue I see in schedules, whereby an activity that has no successor and is just left dangling at the end of a chain of predecessors. If I ask the scheduler about it, the answer is invariably the same: “There are no other activities dependent on that activity, so there’s no successor”. In real-world terms, that actually makes a lot of sense; if there’s nothing dependent upon its completion, then there’s no dependency to illustrate.

However, best practice is to not have such dangling activities in the network. Doing so drops the activity out of the critical path and generates an unusually large Total Float value. Arguably you could say that if it’s in the scope of the project, at some point it’s going to impact the completion of the project, so if nothing else, make the project finish milestone its successor.

However on longer projects, this could really push the boundaries of acceptable Total Float limits; especially if the activity is early in the project life-cycle. And here’s where we start running into some guideline conundrums. The obvious solution is to add a constraint date to the end of the dangling activity. However, this can appear to be in conflict with the following general guideline:

Limit the use of Activity Constraints

Generally speaking the term “Constraint” doesn’t necessarily refer to the special Start or Finish date attributes that can be added to activities in most scheduling software tools. The term “constraint” can mean a relationship between two activities, the constraint being physical: i.e. the roof cannot be built until the walls are completed. It can also refer to a condition in a contract where a crucial delivery date is specified. This is referred to as an external constraint. However for our purposes, I am referring to constraints that can be added as special date attributes to activities in a software tool; dates that will influence the calculation of the critical path.

Many of the published guidelines recommend very limited use of activity constraints in a project schedule, that is: hard dates that are added to activities that will lock down the early and/or late dates.

If the dangling activity (or chain of dangling activities) delivers a major contract milestone, then the use of a hard constraint date is appropriate. This will reduce the overall float of the dangling activity. For greater schedule clarity, a Milestone should be added as a successor to the dangling activity and the constraint applied to it. Depending on how close the constraint date is to the current scheduled dates, this option will reduce or remove the Total Float for the open-ended chain. And if the scheduled date is already later than the constraint date, negative Float will be calculated indicating that you already can’t meet that contractual date and changes to the plan are required.

In the following example, we’ve added a contract deliverable milestone to the back of activity “G’ and then applied a hard Finish On constraint date. The constraint date is 3 days past the scheduled finish date for the activity, so we have 3 days of Total Float, rather than the 21 days we had before introducing the constraint.  We could still link the Contract Complete Milestone date to the Finish milestone, but if I slipped that badly as to push out the project end date, we’re in trouble anyway.  We could add a long lag between the new milestone and Finish milestone, but some guidelines also discourage the use of long lags and leads.  What you finally do will be a judgment call in the end, based upon the particulars of the actual work being modeled.

The guidelines that discourage the use of constraints are sound because too many constraints will mask the true critical path. It makes it harder to differentiate between activities on the critical path and constrained activities. I’ve seen schedules littered with constraints and it was nearly impossible to see the true critical path. Also it can potentially create bucket-loads of negative float, never a good thing. If the customer is schedule savvy, they will think that the dates cannot be met and constraints have been used to artificially paint a happy, but horribly unrealistic picture of workflow; underpinned by an inability to meet the goals of the project.

In short, only use constraints when you have a very good reason to do so. And even then use constraint types such as Start on or After or Finish On or Before type (soft constraints), that will still allow the schedule to shift in at least one direction if needs be.

Keep activity durations below ‘n’ days

I’ve seen this guideline in various publications with differing duration limits depending on the types of projects being scheduled. Of course such ongoing activities as Management, Safety, Security and so on may run the entire length of the project, but these are normally created as some kind of hammock: that is a task whose duration is dependent on activities to which it is linked.

Above: activity A1005 is a Level of Effort activity

Any activity that doesn’t create a deliverable can be of virtually any length; however discrete work packages that describe a particular package of work should be kept to a reasonable length. A common maximum length is to keep activity durations below three months. When the activity is longer than this, it suggests it’s functioning as more of a summary activity, and it probably represents many operations that could be broken down to smaller packets of work.

Figuring out the right level at which to break out the work and estimating the durations for activities can be a conundrum all of its own. There are various guidelines that discuss formal methods for doing this, such as Expert Judgment, Analogous Estimating and Parametric Estimating. Nevertheless, because the work can always be performed in more than one way, getting the activities at just the right level and duration for your particular project is always a challenge.

When creating your activity list, one tip is to keep in mind how the work’s status will be recorded. If the activity’s description covers more than one discrete step of the work, it will be difficult to track and apply status. For example you may have an activity named “Build Foundations”. For a small project, this makes sense as a single task because the entire operation may only take a couple of days. However if this is a larger building where the foundation takes a few weeks to complete, then it will need to be broken out into more discrete packages, such as “Dig footings”, “Wire Rebar”, “Build and Set Forms”, “Pour Concrete” and so on. With each of the activities being a few days long, status will be more discrete. The footings have been dug so that task is 100% done. If the activity was just called “Build Foundation”, and was 5 weeks long, what percentage of the activity is complete when the footings are done? So think about the need for accurate updating of status when you are considering the level of detail at which to create the activity as this often helps in estimating the durations too.

Summary

In the end, all guidelines are designed to give you the optimum way of achieving a viable schedule. They are guidelines and not hard and fast rules precisely because every schedule has unique challenges to overcome. As schedulers, dealing with the day-to-day challenges of putting together a viable schedule, being given guidelines can be a prickly subject, particularly when you know you’ll have to ignore some of them in order to make the schedule reflect the reality it is attempting to model. When challenged about scheduling guidelines I simply say this; “if you can defend it, and there was no better way to do it, then just do it”, even if you’ve had to ignore a guideline or two to make it happen.