Sprint follows sprint, roadmaps are rewritten every quarter, and no sooner has one project stabilized than the next priority comes along. Many project managers are familiar with this feeling: “We're working faster than ever before, but every free minute is automatically filled with new issues.”

But is this really because projects are more complex today? Or are we following a self-reinforcing dynamic of acceleration?

This article takes a look at why project work increasingly feels like an endless endurance run and what can be done in project management to deal with this constructively.

Acceleration is more than just speed

When we talk about acceleration, we rarely mean just “working faster.” In a project context, acceleration is primarily reflected in:

  • ever shorter planning and decision-making cycles

  • frequent changes of direction during implementation

  • increasing communication and coordination density

Projects don't just run faster, they constantly change direction. It is precisely this dynamic that creates a feeling of constant stress. Interestingly, this dynamic is independent of how efficiently teams actually work.

Why better tools don't make projects less stressful

Project management tools, agile frameworks, and automation promise relief. Tasks become more transparent, coordination faster, progress more measurable. Paradoxically, however, this rarely leads to more peace of mind.

The reason: efficiency gains do not reduce work pressure, but rather increase expectations. If a team can deliver faster, it will be assigned tasks more quickly. If coordination becomes easier, there will be more coordination. Opportunities become requirements.

Sociologist Hartmut Rosa describes this phenomenon as social acceleration: technological progress does not save time, but rather creates new obligations.

 

Three levels of acceleration in project management

Hartmut Rosa's model identifies various types of acceleration that can be easily applied to the work on a project:

1. Technical acceleration


Digital tools, automation, AI-supported planning — projects can be launched, managed, and scaled faster than ever before.

Important: This type of acceleration ensures that we can perform the same tasks in less time, so technical acceleration is not the reason for increased time pressure and is wrongly criticized.

2. Acceleration of change


Requirements change during implementation. Strategies are adjusted, markets shift, stakeholders change their priorities. Planning becomes increasingly provisional.

This kind of acceleration negates the time savings achieved through technical acceleration.

3. Acceleration of the work pace


More meetings, more parallel initiatives, shorter deadlines. Work becomes more intense without becoming any clearer.

The acceleration of the pace of work is a coping mechanism for dealing with the acceleration of change.

4. Frantic standstill

A state of its own that should be avoided. There must always be a concrete goal to pursue. No one sums it up more aptly than the Roman philosopher Seneca:

“If you don't know the port you want to sail to, no wind is the right wind.”

In order to slow down projects in a sustainable way, we must therefore address the acceleration of change, the constantly changing framework conditions, and stakeholder priorities.

Why don't we all slow down a little?

Anyone who goes to their potential customers and says, “Let's all relax and take more time until the product goes live,” will either lose the job to someone who is willing to work under time pressure or, in the medium term, lose the competitive battle in capitalism against other companies that bring products to market faster, assuming the quality is the same.

And that brings us to the central point of this article:

Slowing down in companies can only be temporary and must improve quality

Acceleration and working at full capacity is not a choice in competitive markets, but a necessity created by the competition. However, those who do not incorporate “slowdown oases” into their project cycles so that those involved can recover risk burning out the entire team.

The tools for this are versatile. In an agile environment, for example, there are regular retrospectives and refactoring sprints that serve as natural deceleration oases because they focus on the known past rather than the uncertain future.

These tools thus contribute fundamentally to deceleration and should not be neglected for “time reasons.” The short-term added value is quickly outweighed by the long-term loss of productivity.

Why acceleration must be considered across projects

When people are involved in several projects at the same time, any gap in capacity in one project is often filled by more work in an alternative project, and the stress-free phases overlap at most by chance.

Anyone who wants to perform well in a team over the long term must always plan across projects, and even though it should be avoided to make critical phases of several projects dependent on the same people at the same time, it should be planned specifically to overlap recovery cycles as much as possible so that energy can be recharged and the inevitable acceleration can be tackled head-on.

Cover image: Jonathan Petersson from Pexels