TL;DR When scheduling features for a quarter, it's very risky to plan on
delivering multiple projects that are starting from scratch.

Let's call this the "Shiny New Quarter" approach to planning.

Is this self-evidently problematic? Maybe to you. But apparently not to
everyone, because I've seen it done repeatedly.

A year or so ago, when I took the notes that this is based on, my team at work
was suffering from this in a big way. I have to credit
our engineering manager for saying "no" consistently and articulately until
things improved a lot.

Why is Shiny New Quarter risky?

Scheduling uncertainty increases

The beginning of each project is when we know the least about it,
and therefore is when we can least accurately forecast when it'll be done.

In the worst case, we know
literally nothing and haven't even estimated anything. Even in a perfect
process, the uncertainty is initially high and decreases as we
progress.

So every brand-new project decreases the odds that you can
predict your completion dates.

Unbalanced workload.

This varies depending on your typical project breakdown into functional
roles and how those roles interact. But a typical example might be:

We start with a pile of up-front design
and research, while engineers wait for clarity on what they can start
building.

We end with an inevitable crunch marathon for (especially)
front-end and mobile engineers. The QA team, if there is one,
gets the worst of it.

Possibly there is a
devops crunch near the end too, eg. if there are new kinds
of services to deploy.

Sandwiched somewhere in between is a crunch for any back-end or other work that is a dependency for the client-facing work.

Crunch time side-effects.

End-of-quarter crunch marathons have bad side effects: more fatigue, more
bugs, more forced tech debt, more last-minute surprises during integration
work, lower team morale, lower quality of the delivered product. If
every quarter ends in crunch time for a year, you might want to
stop doing that to yourselves.

Limited throughput.

The things you can deliver in a quarter are limited to
those things you can start and finish from scratch while laboring
under unbalanced load. Three months is a nice-sounding upper bound
for project length, but it doesn't have to all be the same three months.

Solution

It's simple and hopefully obvious by now. To more effectively parallelize work,
at any given time there
should be a project in each stage of your process.

To achieve this, simply
stagger the project kickoff dates. Aim to have a project in early research
stages, a project primarly in design, a project primarly in back-end work, and
a project primarily in front-end or mobile work, a project in final testing.

Then:

We are more likely to be able to communicate and meet our delivery dates.

We are less likely to have painful crunch time and fewer side effects.

Over the long term, the average number of successful completed
projects per cycle should be higher.

You can think of this as planning for maximum long-term throughput rather
than for minimum short-term latency.

In this approach, ending a quarter with projects in many stages of progress
wouldn't be cause for alarm; it would be the normal way we set up success for
the next quarter.