Autoschedule behavior for Finish-to-Finish predecessors on started tasks

Products

• Clarity PPM On Premise
• Clarity PPM SaaS

Issue/Introduction

Autoschedule does not move the finish date of a task to match a Finish-to-Finish predecessor once the task status is set to Started․․․․

SYMPTOMS:

• Task finish dates do not shift to align with FF dependencies.

• The scheduler appears to ignore FF constraints for tasks with actuals.

• Finish dates remain calculated based on the Actual Start and remaining duration.

CONTEXT: Occurs when a task has an Actual Start date recorded and a Finish-to-Finish dependency linked to a successor or predecessor date.

IMPACT: Users may perceive the scheduler as broken or inaccurate when dates do not align with visual dependency lines.

Environment

Products: Project Management Portfolio (PPM) / Clarity

Environment:

• Scheduler: Autoschedule Engine

• Task Status: Started / In Progress

• Dependency Type: Finish-to-Finish (FF)

Cause

Actual Start dates freeze the beginning of the task, and scheduling engines prioritize recorded progress over flexible dependency shifting to maintain the integrity of the original project plan.

Resolution

This behavior is working as expected based on standard scheduling logic.

EXPLANATION:

1. ACTUAL START PINNING When a task is Not Started, the scheduler treats it as a flexible block that can move to satisfy dependencies. Once a task is Started, it gains an Actual Start date. This "pins" the start of the task to the calendar.

2. DURATION CALCULATION The software calculates the Finish Date based on the Actual Start plus the planned duration. It will not automatically extend the finish date to meet an FF constraint (e.g., 8/28) if the current work is calculated to finish earlier (e.g., 4/10), as doing so would incorrectly imply the work is taking longer than planned.

3. FINISH-TO-FINISH AS A MINIMUM CONSTRAINT A Finish-to-Finish dependency is a minimum constraint, not a "must match" constraint. The logic dictates that Task B cannot finish BEFORE Task A finishes. If Task B is scheduled to finish on 4/10 and its FF predecessor Task A finishes on 8/28, the rule is technically satisfied because 4/10 occurs during the lifecycle, but the scheduler will not force a delay to make them identical.