Wasteful Automation: When Your Tools Make Decisions You Should Be Making

As Eiji Toyoda of Toyota said, you're responsible for the data you pass on. That single principle should govern every automated process in your project. Yet in practice, teams are eager to automate — auto-calculated critical paths, automatic emails, self-adjusting schedules — without asking the most important question: is the tool making a decision that a human should be making?

Successful projects require an intelligent eye on every scope change, task expansion, and delay. Without that, automation quietly locks in decisions that cause failure long after the fact.

The fork is simple. When a change occurs in a project, you have two choices: let your tools accept it automatically, or pause and review it before accepting. The first path creates waste — hidden risks and needless delays. The second path protects the schedule through thoughtful, team-based responses.

Three Common Examples

1. Scope Changes That Slide In Unreviewed

A customer requests a new feature. It gets added to the requirements document and automatically becomes a deliverable — without anyone evaluating its impact on the project's timeline, resource allocation, or overall goals. The scope grew, but the schedule didn't adjust to reflect reality. Weeks later, the team is behind and nobody can pinpoint why.

The VPM approach: Every scope change gets reviewed by the team against the current plan. The question isn't "can we do this?" — it's "what does this cost us, and is it worth it?" That review takes minutes. The cost of skipping it is measured in weeks.

2. Gantt Charts That Extend Themselves

A task takes longer than estimated. The Gantt chart automatically pushes downstream tasks to the right, extending the timeline. The project manager sees the new dates and accepts them as inevitable.

But automatic rescheduling assumes the original task structure is correct. A more thoughtful approach might restructure the work — parallelize tasks, reassign resources, descope low-priority items, or find a different technical path. The tool chose the laziest option (push everything later) because that's all it knows how to do.

The VPM approach: When a task expands, the team asks: how do we recover? The fever chart shows the buffer impact immediately. The stand-up meeting becomes a problem-solving session, not a status update. The goal is never to passively accept a new date — it's to fight for the original commitment.

3. Agile Sprints That Push Without Reassessing

A story isn't completed in the current sprint. It gets pushed to the next sprint automatically. No one asks why it wasn't completed. No one reassesses the remaining scope in light of what was learned. No one considers whether the feature could be restructured so that the critical parts ship now and the rest follows later.

Over time, the backlog grows with pushed stories that nobody re-examines. Features that could have been delivered sooner — in a different form, at a different scope — sit in a queue because the system made it easy to defer instead of think.

The VPM approach: Every pushed item gets a root cause. Was the estimate wrong? Was a dependency missed? Was the scope unclear? And critically: can we restructure this work so the most valuable part ships sooner? Pushing without reassessing is waste disguised as process.

The Principle

Automation is powerful when it eliminates repetitive, low-judgment work — sending reminders, calculating earned value, generating reports. It becomes dangerous when it makes decisions that require human judgment — accepting scope changes, rescheduling work, deferring deliverables.

The test is simple: would you want a human to review this decision before it takes effect? If the answer is yes, don't automate it. Build a process that surfaces the decision for review, and trust your team to make the right call.

You're responsible for the data you pass on. Make sure your tools aren't passing on decisions you never made.