Managing Resistance in Training

Then the afternoon arrives.

We turn to the Work Breakdown Structure — the WBS — and the participants work on breaking the project down to define the deliverables, the work required and the estimates more clearly. They then consider the sequencing of activities and their dependencies.

We begin the debrief to check that each group has correctly applied the technique. Just before I hand over to them, I show an example of a WBS from an aerospace project.

In hindsight, it was probably not the best choice if I wanted to convince them that the tool was lightweight.

The atmosphere becomes heavy.

When I speak, there is no resonance. My words fall flat. Faces close up. I can feel that I need to name the elephant in the room.

One participant speaks up. Let’s call him Glenn — some details have been changed. He seems to be speaking on behalf of several colleagues:

“Julien, we don’t really see the point of this exercise. Breaking down an entire project is a very cumbersome process. And why define dependencies? Each task follows another one — that’s obvious. It’s pointless!”

I breathe calmly.

I know that defending a technique is pointless, at least in that moment. First, I need to understand what is happening. Everyone in the room is looking at me, waiting.

I decide to reframe the issue more simply:

“OK. You don’t have time to carry out this kind of breakdown. You’re overwhelmed by projects and, above all, you want to keep things moving without adding yet more work. You’re not launching space stations. In your environment, this technique feels too cumbersome for the value it delivers. Is that right?”

Most of the participants nod and smile.

But Glenn is still frustrated. He has spent time on an exercise whose benefits he cannot see. We are nearing the end of the day — a critical point for mental fatigue during a training course.

We need to create some breathing room and lower the pressure.

I say:

“OK, I understand what you’re saying — and you’re right. We’re going to stop here and move on to one final exercise that is completely different. We’ll sleep on it. Tomorrow morning, we’ll spend five minutes revisiting the thinking behind this exercise and try to see it more clearly. Other groups in other companies have raised the same points.”

Glenn’s shoulders relax. He seems calmer. He has been heard.

I continue:

“One thing to bear in mind: all the techniques we are looking at today are standard approaches. It is up to you to take what seems useful and, above all, adapt it to your environment. Scale each technique to your projects and to what you can realistically do.”

I go home and prepare a few slides to explain the distinction between the WBS and dependencies more clearly.

The WBS breaks down the scope of a project so that the team can better understand the work required and produce more realistic estimates. Dependency analysis then helps the team consider the sequence of activities and how the work will be organised in practice.

I anticipate the questions… and the answers.

I clarify my thinking into three key points.

After a night’s sleep: Day 2

On the morning of the second day, everyone arrives on time. We have coffee.

I open the day:

“OK, we’re going to talk about Glenn’s favourite subject: the Work Breakdown Structure.”

Everyone laughs. The tension has eased. Now I can clarify the purpose of the tool.

I explain that the breakdown does not have to become a massive exercise. It simply needs to reach the level of detail required to understand the work, allocate responsibilities, and build a realistic budget and schedule.

I then explain that dependencies force us to ask questions about the sequence of the work: what genuinely has to be completed before something else can begin? Which activities can run in parallel? Where are bottlenecks likely to form?

And what happens if we never address those dependencies in a project?

A silence settles over the room. But this time, it is a silence with resonance. Glenn nods. He understands. They understand.

Their reaction ultimately revealed a broader challenge: how can cross-functional projects be moved forward without direct authority, without making processes even more cumbersome, and without losing the teams along the way?

I therefore suggest slightly refocusing the course to place greater emphasis on the human dimension and on helping people navigate projects.

Groups form. Discussion circles, debriefs. We follow the planned content, but spend more time on motivation, cross-functional relationships and managing disagreements.

At the end of the course, Glenn comes over to me:

“Sorry if I took the training a little off the rails.”

I tell him that, on the contrary, these are often the moments when something meaningful happens.

And I mean it.

A training course does not necessarily go off the rails when a participant challenges its content. It can go off the rails when the trainer refuses to hear what that challenge reveals.

This was not just about explaining a technique. It was about hearing a frustration, giving it space, and then returning to the work.

A form of trust had been created.

It is 6 p.m. I pack my things and head back towards the metro.

Outside, the sun is still shining.