The Elephant in the Room
Spring 2026, Paris. A group of employees from a French technology company gathers for a project management training session. They come from different countries and work in support, deployment and IT roles. We communicate in English. Different backgrounds, different personalities—far from the stereotypical corporate profile.
Together, we are exploring the fundamentals of project management.
The company is managing dozens of cross-functional projects simultaneously. Teams work in agile environments at a fast pace. Fast & Furious.
However, today’s course focuses on a more traditional, predictive project management approach. We review project phases, the project charter and the RACI matrix. Everything is going smoothly. The atmosphere is positive and everyone is engaged.
Then the afternoon arrives.
When the Atmosphere Changes
We move on to the Work Breakdown Structure (WBS). Participants break a project down into deliverables, tasks and estimates. Afterwards, they work on activity sequencing and task dependencies.
Before each group presents its work, I show an example of a WBS taken from an aerospace project.
Looking back, it was probably not the best example to convince them that the tool could actually be simple and practical.
The atmosphere suddenly becomes heavy.
When I speak, nothing resonates. Faces close up. I realise it is time to acknowledge the elephant in the room.
One participant—let’s call him Glenn (some details have been changed)—speaks on behalf of several colleagues:
“Julien, we don’t really see the value of this exercise. Breaking down an entire project is extremely time-consuming. And why define dependencies? Every task naturally follows another one. It doesn’t seem useful.”
Listening Before Explaining
I take a deep breath.
I know that defending the technique won’t help—at least not immediately. First, I need to understand what is really happening. The whole room is waiting for my reaction.
So I rephrase their concern:
“OK. You don’t have time to create this level of detail. You’re already overwhelmed with projects, and your priority is simply to move things forward without creating more work. You’re not launching space stations. In your environment, this technique feels too heavy compared with the value it provides. Is that a fair summary?”
Most participants smile and nod.
Glenn is still frustrated. He has spent time on an exercise without seeing its benefit. The day is almost over, and mental fatigue is beginning to take its toll.
The pressure needs to come down.
So I tell the group:
“OK, I understand—and you’re right. Let’s stop here and finish today with a completely different exercise. We’ll let this idea rest overnight. Tomorrow morning, we’ll spend five minutes revisiting the philosophy behind this technique. What you’re saying is something I’ve heard from other groups in other companies as well.”
Glenn visibly relaxes. He feels heard.
I add one final point:
“Every project management technique we explore is a standard framework. Your job is to take what is useful and adapt it to your own environment. Scale the tools according to the size of your projects and what is realistically achievable.”
Preparing for Day Two
That evening, I go home and redesign a few slides to explain more clearly the difference between a Work Breakdown Structure (WBS) and task dependencies.
A WBS helps break down the project scope to better understand the work involved and produce more realistic estimates.
Dependency analysis then helps determine the logical sequence of activities and how the work should be organised.
I anticipate the questions.
I prepare the answers.
I simplify everything into three key ideas.
Day Two
The next morning, everyone arrives on time. We grab a coffee.
I begin the session with a smile:
“All right, let’s talk about Glenn’s favourite topic: the Work Breakdown Structure!”
The room bursts into laughter. The tension has disappeared. Now the group is ready to understand the real purpose of the tool.
I explain that a WBS is not supposed to become a huge administrative exercise. It only needs to provide enough detail to understand the work, allocate responsibilities and build realistic budgets and schedules.
I then explain that dependencies force us to ask important questions:
- What truly needs to be completed before another activity can begin?
- Which activities can be carried out in parallel?
- Where are the potential bottlenecks?
Then I ask one final question:
“What happens if we never discuss dependencies in a project?”
Silence fills the room.
But this time, it is a meaningful silence.
Glenn nods.
He understands.
Everyone understands.
The Real Issue
Their reaction was never really about the WBS.
It revealed a much bigger challenge:
How do you move cross-functional projects forward without formal authority, without adding unnecessary processes, and without losing your teams along the way?
So I slightly adjust the remainder of the training programme. We still follow the planned agenda, but we spend much more time discussing motivation, cross-functional collaboration and managing disagreements.
Discussion groups form naturally. We continue with the planned content while placing greater emphasis on the human side of project management.
When Training Truly Happens
At the end of the session, Glenn comes to see me.
“I’m sorry if I derailed the training a little.”
I smile.
“On the contrary. Those are often the moments when real learning happens.”
And I genuinely mean it.
A training course does not necessarily go off the rails because someone challenges its content.
It goes off the rails when the trainer refuses to hear what that challenge is really revealing.
This was never just about explaining a project management tool.
It was about listening to frustration, giving it space, and then returning to the learning process.
That is how trust is built.
It is 6 p.m.
I pack my things and head towards the metro.
Outside, the sun is still shining.
