Nobody needs another “idea man”; be an idea editor

Anyone can inject ideas into the discussion.  The job of the planner 
is not to come up with brilliant ideas, but to coalesce them down 
into a larger coherent whole.  Adding more ideas onto a big pile of 
ideas is not contributing much value.
 

Without active curation planning documents decompose into many 

partially overlapping, partially redundant subsections which bury the 

useful information.

Planning is Not Plannable

The schedule can’t be turtles all the way down.  The planning process 

itself can be unpredictable -- in particular, there is always more that 

can be done to reduce the uncertainty in the plan, but at some point it is 

better to start writing code.

If you get a group of people together and say “play devil’s advocate and 

come up with corner cases” you will almost always come up with more 

and more abstract potential problems.  Conversely, if you stop the first 

time the plan “seems correct” without going over it carefully looking for 

flaws there are almost guaranteed to be important pieces missed.

Waterfall is a Boogeyman

“Waterfall” has always been a strawman punching-bag.  Every software project 

management approach has presented itself as an alternative to waterfall.  

Describing any approach as better than waterfall is meaningless.

The first formal description of the waterfall model is often cited as a 

1970 article by Winston W. Royce,[3][4] although Royce did not use the 

term waterfall in that article. Royce presented this model as an example 

of a flawed, non-working model; which is how the term is generally 

used in writing about software development—to describe a critical view 

of a commonly used software development practice.[5]

https://en.wikipedia.org/wiki/Waterfall_model#History

Nobody Has Hard Data

The very nature of the type of data involved and the costs of projects 

do not lend themselves well to studies.  The two options are to try and 

generalize from cognitive psychology studies, or go by published data 

from companies.

Even more than that, be design, "agile" is kind of an "un-process"

survey paper from cognitive psychology is not quite on point

one consultant's study says agile is great

the Voke report says agile is terrible

Conclusion is: you’ve really got to go with your gut, personal experience, 

and advice from others.

Planning Needs Feedback

Closing the feedback loop from implementation back to planning is

very important.  This should be uncontroversial. The proper unit of

feedback is the unit of planning -- the high level feature  / objective. 

Tracking individual tickets or sprints alone does not achieve this. 

Focusing on ticket or sprint level objectives may even be counterproductive 

by creating a false sense of security.

As the plan itself mutates over the course of execution, the number 

of sprints/tasks under that umbrella themselves mutate.  A team may 

be perfectly hitting all small scale targets while still being unreliable in

terms of delivery.

Plans Change

Plans will change as implementation progresses.  This should be minimized
but is practically unavoidable.  Rather than a single transition from planning to
execution, it will probably bounce back and forth, with each planning and execution
phase getting smaller as the implementation zeroes in on the final form.

You can’t know the best approach for anything in infinite detail when you start
for any practical problem (this is engineering)

Planning is something that will need to be done periodically as information
becomes more clear. Also, the project will never feel “fully done” -- there will
always be additional layers of polish that could be added.  Polishing is also a
good analogy -- rough and then gradually finer.

The goal of a good plan is not to become set in stone, but to “see around the corner
 and anticipate as many of these issues as possible.  And also to serve as a living
document and record to determine how well the initial plan matched the final product.

The project never really leaves the planning phase until implementation is complete.