Table of Contents

Predecessors

The course template will come with pre-determined predecessors (aka "Dependencies") associated with each task. These are the standard relational effects between each task. For some courses, it might have been determined during the Planning stage that tasks will be started in a non-standard sequence. Adjusting the predecessors will reflect these changes in the structure of your project schedule.

The Benefits of Using Predecessors

The main utility of predecessors is to minimize the amount of manual updating that is needed to keep task's dates current and up to date. Predecessors achieve this by automatically updating tasks' start and due dates based off changes that are made to other tasks further up in the dependency chain. Here is a visual example of how they accomplish this:

Without using predecessors in the above example, the user responsible for keeping this project up to date would have instead had to manually update all of the dates of the tasks that followed the first task that had its dates changed. Or, if the tasks had neither dates nor predecessors applied to them, and a task was then assigned to another user, the project overseer would have then had to manually enter any start and/or due dates that were needed by the assignees for task completion clarification. This is exactly why learning how to intelligently use predecessors can save you a lot of project upkeep time.

Understanding Predecessor Fundamentals

Predecessors are a feature within Wrike that allow for the creation of date-based relationships between a project's tasks. They establish a formula that sets when a task will either start and/or finish. There are multiple types of predecessors that can be applied to individual tasks by setting specific values within either the Table or Gantt views within projects. Accessing them can be done by toggling the "Predecessor" field in either Gantt or Table view.

Predecessors can reduce the amount of manual updates that are necessary to keep task dates updated. Understanding how predecessors work will enable you to keep your project schedule in alignment with changes in the development plan that deviate from the default task sequence.

Predecessor values have two relationships with tasks. First, they interact with the "Selected" task. For the purpose of this article, the "Selected" task is the task on which the predecessor value is being placed. Second, they interact with one or more "Predecessor" tasks. A "Predecessor" task has the task row number which the predecessor value references. See below for a visual representation:

Tip: The line numbers of the predecessor tasks are dynamic so if the course project was re-sorted and the placement of "0. Course Setup" shifted the row number, the predecessor value would also shift automatically.

"Predecessors" vs. "Dependencies"

You may also hear the term “Dependencies” used to refer to predecessors. If you open a task’s card view, you will also see the “Dependencies” listed there. So, what is the difference between “Predecessors” and “Dependencies”?

The term “Dependencies” refers to both sides of the relationship between tasks - the predecessors and the successors. As you’ll see in the card view, a task may have both “Predecessor” dependencies and “Successor” dependencies.

The Predecessors are tasks which have dates that the selected task’s dates depend on. The successors are tasks which have dates that depend on the selected task’s dates. So as described, the term “Predecessor” relates to one side of the dependency chain.

Why then in Wrike can you only add the “Predecessor” field in the gantt and table view? Why can you not also specify the “Successors” in those views? The answer is that it’s a simpler user experience. By specifying all of the predecessors in a project schedule, you have automatically also specified the successors. By only focusing on the predecessors, and going down the list, it’s easier than thinking about both ends of the dependency relationships for every task, one at a time.

Types of Predecessors

There are four types of predecessors within Wrike. Here are the four types with a brief description of each:

  • Finish to Start (FS): Indicates that the selected task cannot start before the predecessor task has finished.
  • Finish to Finish (FF): Indicates that the selected task cannot finish before the predecessor task has finished.
  • Start to Finish (SF): Indicates that the selected task cannot finish before the predecessor task has started.
  • Start to Start (SS): Indicates that the selected task cannot start before the predecessor task has started.

eCornell's projects primarily use the Finish to Start (FS) predecessors, and to a smaller extent Start to Start (SS) predecessors. Finish to Finish (FF) and Start to Finish (SF) are not currently used (except in rare specific instances).

Note: For a more detailed look at the types of predecessors and their specific functionalities please refer to this Wrike Help article

Choosing Predecessor Use Per Project

We now provide project leads (mainly lead IDs) the option as to whether or not they would like to use predecessors on the second level of tasks within their projects. More specifically, when setting up Wrike projects for new programs, users can either use predecessors and dates on all tasks at all levels, or only on the top "bucket" levels, without any on the subtask level. For shorthand, we refer to these two different structures as either a "Task-Driven" schedule or a "Milestone-Driven" schedule. See below for a visual example of how these different structures look in the Gantt View.

Predecessors On All Tasks (Task-Driven Schedule):

Predecessors Only On Bucket-Level Tasks (Milestone-Driven Schedule):

There are pros and cons to both approaches. We will break down the key pros and cons for each approach separately.

Predecessors On All Tasks (Task-Driven Schedule)

Pros:

  • Reduced need for manual monitoring/updating of dates at the subtask level
  • Tasks that are assigned out to internal service groups (Creative, Video, etc) will always have some form of a due date attached to them
  • More informed context of how delays in one subtask will impact the overall schedule of the project
  • More informed context of the assumed durations of tasks within the project

Cons:

  • Increased amount of time needed/recommended to learn the fundamentals of how predecessors operate
  • Higher potential for system related glitches/frustrations such as unpredicted task date changes and creation of Wrike "features" such as Start Constraints (more on this particular item below)
  • Increased need for the use of the Item Rollup feature (covered in detail in another article within this category)

Predecessors Only On Bucket-Level Tasks (Milestone-Driven Schedule)

Pros:

  • Reduced number of dates to manage
  • Simplified user experience when keeping a course project's overall dates current
  • Less of a need for users to understand predecessor fundamentals
  • Potential to create a greater sense of ownership of the dates in a project for some users

Cons:

  • Need to manually enter dates on tasks for cross-team and cross-user communication/clarification
  • Lack of context in how updates to one task will affect the entire project's projected completion
  • Increased level of responsibility and time for a project's overseer to maintain a project's dates
  • Dates become increasingly abstract without a series of relationships to more specific deliverables
Note: It is usually required for the predecessors to remain on the subtasks within the QA and Course Deployment buckets of work, as these are necessary for the QA team to adequately delegate work out to internal and external (contracted) team members.

Adding Predecessors

Predecessors can be added to any unique tasks in your projects, after the project has been created from a template. Predecessors will not automatically be included on tasks that added outside of the templated tasks for eCornell projects. In order to add predecessors to these tasks, the aspects of predecessors described in this article should be considered.

First, a user will need to establish what "Predecessor" task is going to be affecting the start and completion of the "Selected" task (the unique task being added to the project). The user will then need to determine the task number of the predecessor task. Then, the user will need to assess if there are any other potential tasks that should be specified as a predecessor of the selected task, as multiple predecessor relationships can be applied to a single task.

Once these have been determined, the user will then need to determine the type of predecessor that reflects the relationship between the tasks. For simplicity's sake, it is recommended to always lean towards using the Finish to Start (FS) predecessor type.

Here is an example of all of these steps being carried out:

In the above example, the tasks "4. Write Course & Module Intros/Wrapups" and "4. Write Page Intros & Context" have been assigned to the project's IDA. For thoroughness, a new task called "5. ID Review of Course Copy" has been added. Since both of the existing tasks will need to be completed before the new task can begin, both tasks will be the predecessor tasks. We then establish that this new task which is the "selected task", would need a Finish to Start (FS) predecessor (the selected task cannot start until the predecessor tasks have finished). So, after finding the line numbers of the predecessor tasks, the predecessor values "8FS" and "9FS" are placed. You can then see, whenever either of the predecessor tasks are pushed out, the start date of the selected task is automatically pushed out by the system.

Overriding and Removing Predecessors

A user managing a project may reach a point where predecessors on certain tasks are creating more trouble than value. Some examples of when this can happen are:

  • Task(s) dates need to be strictly specified for a determined timeframe because of a hard due date for task completion. If a task needs to be started or completed at very specific date, it might be necessary to remove predecessors from the task, so any changes to tasks further upstream do not move that task's established dates.
  • Continued date malfunctions and frustrations managing a project's schedule. If a user is having continued frustrations and is "fighting" with their project's dates when trying to keep the project up to date, they might want to consider reverting to the option mentioned above in removing the dates/predecessors on all 2nd level tasks in the project, or specifically removing the dates/predecessors on a particularly bewildering task(s).

Removing the predecessor(s) of a task can be done by toggling on the predecessor field in the Gantt or Table view of a project, and simply remove/delete any present predecessor values.

If a user wishes to remove the dates completely from a task, they can do so by simply deleting either the due date, or the duration of the task. Deleting the due date will remove the dates, and the predecessors from a task. Deleting the duration of task will remove the duration, predecessors, and dates from a task.

Advanced Topic: Start Constraints

One issue that occasionally occurs is the unintentional inclusion of system generated values called "Start Constraints". A Start Constraint will make it so that a task can no longer be scheduled before the date that has been set as the constraint. This affects the way the project's dependency chain functions. Start Constraints are at times generated when Finish to Start predecessors are placed on tasks within a project (it is still unclear at this time what conditions establish these start constraints being generated automatically). In terms of eCornell's use case, these start constraints are an issue, not a helpful feature, so it is prudent for users to remove them from tasks when they appear.

Recognizing when a start constraint has appeared can be done through examining the graphical Gantt chart of a project. When a task has a solid dark line present at the very beginning of its gantt block, that means there is a start constraint present on that task. Toggling on the start constraint field will show the user the exact date of the start constraint.

Removing a start constraint can be done by toggling on the Start Constraint field in the Gantt view of a project, and then removing/deleting that date. That will then allow the predecessors to freely adjust the task's start date once more.

How did we do?

Updating Task Start and Due Dates

Durations

Contact