A driving predecessor is an immediate predecessor that currently determines the start or finish date of its successor through schedule logic. If the driving predecessor moves later, the successor will also move later unless another scheduling factor, such as a constraint or calendar, intervenes.
A task may have several predecessors, but not all of them drive its current date. Some may finish with time to spare. Others may tie for the driving position. As the schedule changes, a different predecessor can become the driver.
This distinction helps schedulers identify the specific handoff controlling an activity, milestone, or deliverable. It also supports logic tracing, forecast analysis, corrective-action planning, and critical path analysis in an Integrated Master Schedule.
How a Driving Predecessor Controls a Task Date
Critical Path Method (CPM) software calculates activity dates from durations, logic relationships, calendars, status, and constraints. When multiple predecessor relationships feed a task, the scheduling engine evaluates each relationship. The relationship that establishes the controlling date is the driving relationship.
For example, assume a successor has three finish-to-start predecessors:
- Predecessor A finishes on June 10.
- Predecessor B finishes on June 14.
- Predecessor C finishes on June 12.
If all three relationships use zero lag and the same calendar, Predecessor B normally drives the successor’s June 15 start. Predecessors A and C remain valid dependencies, but they do not currently control that start.
However, simply choosing the predecessor with the latest finish does not always work. Relationship types, lag, working calendars, actual progress, and constraints can change the result.
The relationship type determines which date is controlled
A driving relationship can use any relationship type supported by the scheduling tool:
- Finish-to-start: The predecessor’s finish, adjusted for lag and calendars, may control the successor’s start.
- Start-to-start: The predecessor’s start may control the successor’s start.
- Finish-to-finish: The predecessor’s finish may control the successor’s finish. The successor’s duration then affects its calculated start.
- Start-to-finish: The predecessor’s start may control the successor’s finish. This relationship is uncommon and often difficult to interpret.
The GAO Schedule Assessment Guide recommends logically sequencing activities and minimizing unusual or complicated logic. Likewise, the NASA Schedule Management Handbook emphasizes appropriate predecessor and successor relationships supported by the planned work.
A Driving Predecessor Is Not Necessarily Critical
Driving describes a local relationship between an activity and its immediate successor. Critical describes an activity or path’s effect on a selected completion point, usually the project finish or a key milestone.
Therefore, a driving predecessor can have positive total float. It may immediately move its successor while the entire branch still has time available before it affects the program finish.
Consider a design package that drives the start of an internal peer review. The peer review may have 15 working days of total float before it affects Critical Design Review. The design package is still the peer review’s driving predecessor, but neither activity is currently on the program’s critical path.
Conversely, identifying a list of critical activities does not explain every immediate driving relationship. A proper logic trace follows the controlling relationships from a milestone backward through the network. For more detail on the broader calculation, see the Critical Path Method guide for program schedulers.
Driving Predecessor vs. Free Float
Free float measures how long an activity can slip before it delays an immediate successor. Total float measures flexibility relative to a project completion point or another controlling endpoint. The two measures answer different questions, as explained in Free Float vs. Total Float.
In a simple finish-to-start, zero-lag network with consistent calendars, a driving predecessor will often have zero free float relative to the successor it drives. Any delay to the predecessor passes directly to that successor.
Still, schedulers should not use a zero-free-float filter as a universal substitute for driving logic analysis. Activity-level float values can reflect multiple successors. In addition, non-finish-to-start logic, lags, calendars, constraints, and software calculation settings can complicate the comparison.
Use driving logic to answer, “Which predecessor controls this task now?” Use total float to evaluate how much schedule flexibility remains before a target completion date is affected.
Fictional Program Example: Environmental Test Completion
Assume the Falcon Ridge avionics program has a milestone named “Environmental Qualification Complete.” Three activities feed that milestone through finish-to-start relationships:
- Complete thermal-vacuum testing finishes August 6.
- Close environmental test anomalies finishes August 12.
- Approve the qualification test report finishes August 9.
With zero lag and compatible calendars, “Close environmental test anomalies” drives the August 12 milestone. If anomaly closure slips to August 14, the milestone also moves to August 14.
Now assume the team accelerates anomaly closure to August 7. The test report approval, scheduled for August 9, becomes the new driving predecessor. Driving status changed because the schedule condition changed.
The scheduler should not report only that the milestone slipped. Instead, the scheduler should explain that unresolved anomalies controlled the milestone forecast, identify the responsible control account or team, and assess the downstream effect on system integration.
This analysis gives the Control Account Manager (CAM) and program manager a specific cause-and-effect chain. It also supports a more credible estimate to complete than a narrative based only on milestone variance.
How to Identify a Driving Predecessor in Microsoft Project
Microsoft Project provides Task Path highlighting for this purpose. According to Microsoft’s Task Path guidance, driving predecessors are tasks that come before the selected task and directly affect it.
- Open a Gantt Chart view.
- Select the task or milestone you want to analyze.
- Open the Format tab under the Gantt Chart tools.
- Select Task Path.
- Choose Driving Predecessors.
Project highlights the driving predecessor path associated with the selected task. You can also use the Task Inspector to review factors affecting its dates. Microsoft’s Task Inspector documentation notes that these factors can include predecessor tasks and calendars.
Task Path highlighting is a calculated view, not a permanent task classification. After status updates, logic revisions, calendar changes, or schedule recalculation, Project may identify a different driver.
Other CPM tools, including Deltek Open Plan, may expose controlling logic through different views, fields, or trace functions. Therefore, use the documentation for the deployed software version rather than assuming that every tool applies Microsoft Project terminology or calculations in the same way.
A Practical Driving-Logic Review
A driving predecessor analysis should go beyond highlighting one task. Use the following process when reviewing an Integrated Master Schedule (IMS):
- Select the target. Start with a contractual event, technical milestone, delivery, or management control point.
- Confirm the schedule is current. Verify progress through the established IMS status date and recalculate the schedule.
- Review all direct predecessors. Check relationship types, lag, activity dates, calendars, and status.
- Identify the current driver. Determine which relationship controls the target’s start or finish.
- Trace the logic upstream. Repeat the analysis for the driving predecessor until the path reaches completed work, the status date, or a valid external interface.
- Inspect constraints and calendars. Confirm that logic, rather than an unexplained date constraint, produces the forecast.
- Review alternate paths. Examine close competitors that could become driving after a small change.
The final step matters because the current driver may not remain the driver. A path with only slightly more float can overtake it after an update. Program teams should therefore monitor both the driving path and relevant near-critical paths.
Why Driving Logic Matters to Program Controls
Driving logic connects schedule mechanics to management action. It shows which activity must move to improve a forecast and where a delay will propagate next.
For an executing program, this insight helps CAMs prioritize recovery actions. For example, adding resources to a non-driving predecessor may produce no improvement in the successor date. The team must address the actual driver or change the underlying execution sequence.
During proposal development, driving logic helps the team test whether planned reviews, supplier deliveries, integration events, and customer approvals form a credible sequence. It also reveals whether the proposed completion date comes from network logic or from imposed constraints.
For customer delivery, driving-path analysis supports clear schedule narratives. A reviewer can see the controlling technical sequence instead of receiving a list of late activities with no explanation of their effect.
The term driving predecessor is a scheduling and software concept. It is not, by itself, a universal Federal Acquisition Regulation or Defense Federal Acquisition Regulation Supplement requirement. Contractual schedule obligations depend on the contract, applicable Contract Data Requirements Lists, Data Item Descriptions, agency direction, and program-specific tailoring.
Common Mistakes
Assuming every predecessor drives the task
Every predecessor represents a dependency, but only the controlling predecessor or tied group establishes the current calculated date.
Equating driving with critical
A driving predecessor may sit on a noncritical branch with positive total float. Always evaluate the selected completion point before calling the activity critical.
Looking only for the latest predecessor finish
This shortcut works only under limited conditions. Start-to-start or finish-to-finish logic, lag, calendars, and constraints may produce a different driver.
Ignoring tied driving predecessors
Two or more relationships can establish the same controlling date. If the schedule tool highlights several drivers, review all of them rather than selecting one arbitrarily.
Tracing logic before updating the schedule
Incomplete status, invalid actual dates, or an outdated data date can produce misleading driving paths. Status and recalculate the schedule before presenting the analysis.
Ignoring constraints that override logic
A hard or semi-flexible constraint may control a date instead of the predecessor network. Review the task’s constraints and other scheduling drivers before concluding that logic alone produces the forecast.
Frequently Asked Questions
Can a task have more than one driving predecessor?
Yes. Multiple relationships can tie and establish the same controlling start or finish date. A scheduling tool may identify all tied relationships as driving.
Can the driving predecessor change?
Yes. Status updates, delays, acceleration, revised logic, calendar changes, or duration changes can cause another predecessor to become the driver.
Does a driving predecessor always have zero total float?
No. Driving is a local relationship to an immediate successor. The predecessor and successor can both have positive total float relative to the program finish.
Is the driving predecessor always on the critical path?
No. It lies on a driving path to the selected task, but that path may not control the project finish or another key milestone.
What should a scheduler report about a driving predecessor?
Identify the controlling activity, relationship type, responsible organization, current forecast, reason for any variance, downstream effect, and planned corrective action. Also note alternate paths that may become driving.
Key Takeaway
A driving predecessor is the immediate predecessor that currently controls a successor’s calculated start or finish through schedule logic. It identifies the dependency that matters now, but it is not automatically critical and may change after the next update.
Professional schedule analysis should trace driving logic, inspect constraints and calendars, review float, and monitor competing paths. That approach turns a schedule from a collection of dates into a useful model of program execution.