In brief: Responding to drift means acting on the Job itself: complete the Deliverable, change its due date, reassign a task, or write a Change Order.

Applies to: Anyone who can edit an Active Job and the tasks inside it.

See also: How Performance Works: Effort, Timeline, and Drift defines what counts as drift, and Change Orders: How to Add Scope to a Locked Job Plan covers the scope response in full.

Net Net never forces a response to drift, and there is no single button on the Performance tab that fixes a Deliverable for you. Performance is where you notice something; the Job itself is where you act on it. The real options, once you know what you are looking at, are: complete the Deliverable if the work is genuinely done, change its due date if the timeline needs to move, reassign a task to someone with room, or create a Change Order if the scope has actually grown. All four already exist on the Job. None of them require a special drift-response screen.

This article is the practical follow-up to How Performance Works: Effort, Timeline, and Drift. That one explains what drift means. This one is about what to do when you see it.

Performance reports. It doesn't act.

The Deliverable Drift table on a Job's Performance tab is a read-only view, on purpose. It reports Original Plan, Current Plan, Actual, and due date status for every Deliverable, sorted so the biggest overage is at the top. Nothing on that table rewrites your plan, changes a status, or reassigns anyone.

That separation is deliberate. The moment you decide something needs to change, you are editing the Deliverable or the Task, not a special performance control. That way you never end up with two places in Net Net both claiming to be the source of truth for a due date or a status.

Complete the Deliverable

If the work behind a drifting Deliverable is actually finished, the fix is simple: set its Status to Completed on the Job's Tasks tab. The timeline stops there. Actual hours already logged stay exactly as they are, and the Deliverable drops out of the active drift picture because there is nothing left to drift.

Full mechanics, including how Status and Confidence work together, are in Deliverables: Status, Due Dates, and Confidence Explained.

Change the due date

A date that no longer reflects reality is one of the most common reasons a Deliverable reads as overdue when the work itself is fine. Due dates are editable on an Active Job at any time, for any reason, without a Change Order. Moving one does not touch the estimated hours in the plan; it only updates the schedule the Deliverable is measured against going forward.

That is also covered in Deliverables: Status, Due Dates, and Confidence Explained.

Reassign a task

Deliverables in Net Net don't have a single owner the way a task does. If a Deliverable is drifting because one person on it is overloaded, the fix happens at the task level: open the task, add the new person as an assignee with their own service type and LOE, and remove the assignee who no longer has room. You can do this for one task or several, one at a time, on any task inside the Deliverable.

The full mechanics of assignees and allocations are in Job Tasks: Assignees, Allocations, and Statuses. If what you actually need is to move a task to a different Deliverable or a different Job entirely, rather than change who is doing it, that's a separate action covered in Moving a Task Without Losing Its Time or History.

Create a Change Order

Sometimes drift isn't a scheduling problem or a workload problem. The scope genuinely grew: the client asked for three more rounds, or a piece of work turned out to be bigger than anyone expected. When that's true, the honest move is a Change Order. It adds the new hours to the plan without pretending the original estimate was wrong, so the gap between what you first committed to and what you're actually doing stays visible forever. Why that original number is never edited in place is the whole subject of Baselines: Why Net Net Never Rewrites the Plan.

Change Orders have their own full walkthrough in Change Orders: How to Add Scope to a Locked Job Plan, including who can create one, who can apply one, and how a bad one gets reversed.

Putting it together

There isn't a required order to these. A Deliverable that's overdue because the date was wrong needs a date change, not a Change Order. A Deliverable that's over on hours because the client added scope needs a Change Order, not a due date change. Reading Deliverable Drift correctly, understanding whether you're looking at a scheduling problem, a workload problem, or a scope problem, is most of the work. Acting on it is just editing the Job like you normally would.

For the wider habit of watching the schedule and the budget together instead of one at a time, we wrote Managing Timelines and Budgets for Advertising Agencies on the blog.

Frequently Asked Questions

Is there a button on the Performance tab that fixes drift for me?

No. The Performance tab, including Deliverable Drift, is read-only. It shows you where to look. Every fix happens on the Deliverable or Task itself, in the Job's Tasks tab, or in Change Orders.

Do I have to respond to a yellow or red meter?

No. Ignoring it is always valid. Net Net never blocks work or forces a decision because a number crossed a threshold. The color is information, meant to help you decide where to look first, not a requirement to act.

How do I move a drifting Deliverable's due date?

Open the Deliverable on the Job's Tasks tab and change its Due field directly. Dates are not part of the frozen plan, so this never requires a Change Order, on a Project or a Retainer.

How do I reassign work off someone who's overloaded?

Open the task, add the new assignee with their own service type and LOE, and remove the one stepping away. This happens one task at a time; there isn't a single bulk "reassign this whole Deliverable" control. See Job Tasks: Assignees, Allocations, and Statuses.

When is a Change Order the right response instead of a date change?

When the scope itself grew, not just the schedule. If the client asked for more, or the work turned out bigger than planned, a Change Order records that honestly. If the work is the same size and just needs more time, that's a due date change instead.

Does marking a Deliverable Complete erase the drift it showed?

No. Completing a Deliverable stops its timeline and keeps every number it generated along the way. Performance never rewrites history. A Deliverable that ran over stays visible as one that ran over, even after it's marked done.

Related articles

If the same kind of work keeps drifting, Jobs Report: Look Up Any Job's Plan vs Actual History lets you look back across every Job you have run and see whether the pattern lives in your estimates rather than your execution. Activating a Job: What Happens When the Plan Locks covers the moment the plan you are responding against gets frozen, and Job Lifecycle: Pending, Active, Completed, Archived puts that moment in sequence with everything around it. For Retainers, where the work renews each month instead of ending, Running Retainers: Monthly Cycles, Tasks, and Actuals is the companion read.

Updated on: 08/04/2026