If Anyone Can Move The Date, Nobody Owns The Plan

The sentence that ended the debate

An operations leader put it in one line during a weekly review: if everybody has the ability to change the dates, we have no idea what we are driving toward, or how long it takes, or why it is late.

That is three separate losses in one sentence, and they compound. Losing the target is the obvious one. Losing the duration is worse, because duration is the input to every future plan you will build. Losing the ability to explain lateness is worst of all, because it means the same slip will happen again next quarter and you will have no evidence about where it came from.

The specific trigger was small and completely ordinary. One contributor had not gotten to a task, so the date moved out three days. Nobody objected, because three days is nothing and the person was busy. The response from the operations lead was sharper than the size of the slip warranted, and he was right: just because you could not get to it does not mean the whole thing pushes out three days, and it certainly does not mean three days is the new standard.

An unapproved date change is a baseline change

Here is the mechanism, and it is worth being precise about it because the fix follows directly from it.

A plan holds two numbers per task even when it only displays one. There is the date you committed to, and there is the date you now expect. Variance is the difference. Variance is the only thing in a schedule that teaches you anything, because it is the measured gap between what a step was estimated to take and what it actually took.

When the owner of a task can edit its date directly, those two numbers collapse into one. The committed date is overwritten by the expected date at the moment they diverge, which is precisely the moment the information was created. The plan does not record a three-day slip. It records a task that was always due three days later than it was. Run that for a quarter and the plan is a perfect account of what happened and a useless account of what was supposed to happen.

The second-order effect is the one that actually costs money. Because the new date arrived without a decision, it also arrived without a judgment about whether three days was acceptable, whether the downstream steps could absorb it, or whether somebody should have worked a longer day instead. The slip propagates by default. Nobody chose it. And the next time the same step runs, the estimate it inherits is the slipped one, so the underestimate becomes permanent and invisible in the same motion.

This shows up on plant floors in exactly the same shape. A maintenance PM date that any technician can push. A qualification gate whose owner can restate the target. A promised ship date that customer service can quietly move in the system. In every case the plan stays green and the organization loses the ability to say why anything is late.

Assign the authority, and split it three ways

The fix that came out of this argument was a three-way split, and the split is the useful part.

Anything not in the customer's hands gets a single named approver for date changes. Not a committee, not the project manager by default, one person. The owner of a task can request a change and can state why. They cannot execute it. That single rule restores the committed date, which restores variance, which restores everything downstream of variance.

The person who does the work sets the duration in the first place. This is the half that makes the rule survivable rather than resented. The team that will do the analysis is the team that says how long the analysis takes once the inputs land. Nobody imposes a number on them. Having set it, they hold it, and the trade is explicit: you own the estimate, so you own the date.

Anything genuinely in the customer's hands belongs to whoever owns the customer relationship, and it belongs there as an accountability, not as an excuse. Waiting on client data is a real reason a plan slips. It is also the most-used cover for slips that had nothing to do with the client, which is why it needs a named owner whose job is to go get the input rather than to report that it has not arrived.

One more discipline belongs with these, and it costs nothing. Two tasks in this program were finished but not marked finished, which meant the plan could not distinguish completed work from late work. If done is not marked done on the day it is done, the board is not a status system, it is a rumor with columns.

There is a leadership lesson in this one that took me a while to accept. I had put the plan document out explicitly as a draft to be corrected, with no ownership or pride attached to it, and invited the team to tell me exactly how they wanted it to run. Nothing came back. I read that as a people problem for longer than I should have. It was not. Removing your ego from an artifact does not create ownership in anyone else; it just leaves the ownership unassigned. Authority over a plan has to be given to a named person, out loud. Offering it to a room gives it to nobody.

What a well run plan reads like

Every line carries an original date and a current date, both visible. One named person approves changes to any date the customer does not hold. Durations are proposed by the team that will do the work and are not edited by anyone else. Client-dependent dates carry the name of the person responsible for chasing the input, not the name of the client. Completed tasks are marked complete the day they complete, and a weekly variance report names the three steps whose actuals most exceed their estimates.

Green is not the same as on time

A plan everyone can edit will almost always look healthy, because every date on it was written after the fact. The question worth asking at your next review is not whether the plan is green. It is when each of those dates was last changed, and by whom, and whether anyone approved it.