Although I’d written a couple of years back about poor scheduling practices which I’ve encountered in the field, when I think about the subject, one bad habit stands out above all else – misuse of start-on or finish-on schedule constraints. If I had received a dollar for each time I’ve run into one of these…
As the name implies, a start-on or finish-on constraint is used to identify a real-world situation which overrides when one or more activities could start or finish. It is as if you took a hammer and nails to the start or end dates for the constrained activities – the activities would like to start sooner (or later), but they are nailed down.
Unfortunately, the simplicity of adding start-on or finish-on constraints to activities in most current scheduling tools results in their misuse.
Sometimes this is a reflection of the scheduling tool being used to define the project’s network diagram instead of the tool reflecting an already defined network diagram. Instead of defining the relationships between activities first (irrespective of the calendar dates when they would be performed) and then transposing those onto a timeline, the practitioner has already jumped ahead to envisioning the planned start or end dates for activities.
Other times it might simply be a lack of experience in the use of the scheduling tool – after all, it is so easy to just click on the planned start or end dates and set them to the desired dates!
Finally, sometimes it might be because it is simpler to use a constraint than to find a better way to capture the cause for start or end dates not happening when they normally would – a common example of this might be if the practitioner is unaware or elects not to use task or resource calendars.
For small schedules or short duration projects, constraint misuse might not result in any real damage, but on larger schedules or long running projects, a key impact of this issue is the inability to optimize your schedule as things change. For example, a constraint might be used to force an activity to commence on a particular date which represents the first availability of someone who possesses a particular skill set. Later on if the person becomes available sooner, the project manager might have forgotten the reason why they had place a constraint on that team member’s activities, and the opportunity to accelerate activity timelines is lost. Constraint abuse on large schedules can also make it extremely complicated to maintain and revise your schedule through changes.
To avoid such issues, I’d recommend using start-on or finish-on constraints as the last resort – project start (or end if you are scheduling backwards) dates, dependencies, lags & leads, and task or resource-specific calendars are all preferable methods of defining activity timelines. If there is no alternative to using a start-on or finish-on constraint, document the rationale for its usage within the schedule itself. That way, if the cause of the constraint changes at a later date, you can then modify or eliminate the constraint.
Did my scheduling pet peeve make your top five list? If not, please share your top pick by submitting a comment!