COLUMN

When the plan comes back with “a bit more explanation,”
what you fix is not the amount of information

A plan can get sent back on comments that aren’t about errors. What gets added is information. The reason it never stops is a lack of calibration to the people who execute it and the person who gives final approval.

Separate the executor’s view from the approver’s view →

2026.09.23 #ProjectPlan #SentBack #Readers

Written by Kazuo Yutani, Representative of Metamorphose LLC. PMO for plan approval at financial institutions and system integrators.

The reason a plan isn’t approved doesn’t start with an error in it

After the approval meeting, the plan comes back. The comment isn’t “something is missing” but “make the whole picture clearer” or “this is hard to explain to stakeholders.” You revise and resubmit. It comes back again.

What’s missing isn’t task coverage. It’s calibration to the readers — the people who execute, and the person who gives final approval. The plan itself may already be correct enough. What isn’t there is who reads it and cuts the next decision.

Three things plans that keep getting sent back have in common

What’s happening	What’s missing in the plan
The content passes, but “add more explanation” never ends	The approver can’t read what they should decide next
Approval went through, but the team can’t start the following week	The executors can’t break it down into their own work
Every revision draws a new comment	Revisions add no new information. The reader axis hasn’t changed

The third one is common when revisions don’t make the meeting shorter. The edits aren’t additional information but rephrasing of the same sentences. The longer the meeting, the thicker the plan — and approval gets no closer.

There are two kinds of reader. One document isn’t enough

The same plan is read by a team lead and by an executive. The granularity, order, and language each needs are different. Try to satisfy both in one document and one of them feels “this isn’t written for me.” Part of the send-back is that mix-up.

The people who execute: what do I do today? Is it at a granularity I can write with the information I have?
The person who approves: what do I decide now, and what can wait? Is there one question for the next meeting?

“Write in detail so everyone can read it” reaches neither. The more detail, the more the approver loses the storyline and the executors can’t find their own row.

Four inputs to line up before rewriting the plan

Before rewriting, the four things most often not yet in place are these. The parts filled in by guesswork become the seeds of the next send-back.

What information the team actually has, and what it doesn’t
The overall direction (what “done” means)
Why the last plan of this kind failed
The client’s decision rhythm (who cuts what, in which meeting)

Polish the format without these four and a correct plan still won’t move. This isn’t about the name of a methodology; it’s about the sequence of work on the ground.

If you fix it, the test is that the next decision can be identified in the meeting

Don’t make “it’s clearer now” the pass condition. The benchmark is that the approver can identify “the next decision to cut” inside the meeting. If questions aim at gaps in explanation rather than at conditions, close them in the next version.

In large programs, don’t try to align everything at once. Carve out a unit — a team or a phase — where the people with the knowledge can be reached, there is a single approver, and the purpose of the deliverable is agreed, then calibrate. Units that don’t meet the conditions are cut first.

CONTACT

Don’t take it into the next meeting with more explanation added.

We only check whether it’s aimed at the executors or at the person who cuts — and whether that’s off. That single line is the entry point to our Metamon diagnostic. We don’t ask for the plan document. One line on the form (a team name is enough if you’re not sure).