Clarifying the usage of schedule dependencies, constraints & deadlines

While a correctly developed project schedule is a thing of beauty, a poorly created one can be a source of frustration to the project team and risk to the overall project success.

Developing a schedule before spending time to decompose the scope of a project is likely the primary sin of most poor planners, but it is closely followed by the incorrect usage of schedule dependencies, constraints & deadlines.

  1. Schedule dependencies represent a logical connection between two discrete activities.  Such relationships should be related to the nature of the activities themselves and NOT to who will perform the tasks or to other such constraints.  The dependencies most commonly provided include:
    • Finish-to-Start: the most common causal relationship hence no explanation is necessary for its usage.
    • Start-to-Finish: Rarely used but is useful when developing a schedule backwards from a fixed end date.
    • Start-to-Start: this represents a true relationship between two activities and has nothing to do with their predecessors.  If I happen to have two tasks that start at the same time because of a predecessor, that is better represented as two finish-to-start relationships (e.g. systems testing & developing documentation can both begin once development is complete, but there is no relationship between systems testing & developing documentation so we wouldn’t want to use a Start-to-Start dependency here).  This dependency is often used with a lag to represent the connection between two activities that run in parallel but cannot start at exactly the same time (e.g. apply the first coat of paint & apply the second coat of paint).  A true Start-to-Start example is a race between two runners where each runner is represented as a separate activity – while they will likely finish at different times, both must start at exactly the same time.
    • Finish-to-Finish: this is generally used to represent activities that must complete at the same time so as to not impact their successor activities or one or more of the objectives for the project.  A non-project example of this is the act of preparing food at a restaurant – the chefs must ensure that the main course and garnishes are ready at exactly the same time so that plating can be done without impacting quality.
  2. Constraints represent a real-world limitation that prevents an activity from commencing or completing when it normally would (based on project start date or its dependencies).  Constraints are often most misused as the natural inclination for a novice scheduler is to manually set task start dates or end dates.  Valid examples of constraints include resource dependencies (e.g. unavailability of a training room) or external factors (e.g. maintenance blackout periods that would affect certain types of tasks).  Resource or task calendars if supported by a scheduling engine provide an alternative to the use of constraints.  However, with either of these features it is a good idea to document the specific condition that necessitated the use of the constraint or calendar so that if the condition no longer applies at a later point in time, the constraint can be removed resulting in potentially improved schedule performance.
  3. Constraints are occasionally used (especially “finish on” or “finish no later than”) where a deadline would work better.  Whereas dependencies and constraints affect scheduling logic and the start or end dates for tasks, deadlines provide a visual indicator to the scheduler that a “real-world” deadline is likely to be missed.  On large schedules while there might be numerous milestones, there may only be a few true deadlines that have to be observed.  To ensure that the planner is aware of the potential negative consequences of a scheduling change, deadlines provide a “soft” means of notification that will not impede tasks from moving freely or the schedule from being optimized.
  4. Lags are sometimes skipped in favour of artificial tasks being inserted between two dependent activities.  For example, once I have placed an order with my vendor, a period of time will pass until the equipment has been delivered.  Using a task to represent this procurement & delivery time is incorrect unless the activity is being performed by the project team and additionally this will throw off the calculation of overall project percentage complete.  A better approach is to introduce a lag between the two activities representing the expected number of days or weeks for the procurement & delivery activity.

While I have not tried to provide a comprehensive walkthrough for each of these features, hopefully it clarifies their usage such that the right tool can be used for the right job!




Categories: Project Management | Tags: | Leave a comment

Post navigation

Leave a Reply


You are commenting using your account. Log Out / Change )

Twitter picture


Facebook photo


Google+ photo


Connecting to %s

Blog at

%d bloggers like this: