Most of my work as a trainer is with managers who have operational responsibility. They lead teams, departments, or shifts, ensuring that the day-to-day operation runs smoothly. Their leadership is about consistency: keeping people aligned, solving problems, and making sure everything continues to function effectively.

I also have a background in project management. And I can tell you: it’s a completely different game. Different mindset, different rules, different way of leading people. Yet I keep seeing operational managers step into a project and manage it the way they would manage their department. That’s where things start to go wrong.

Here’s what makes projects different, and the traps that come with not taking that difference seriously. Below a few of the things to keep in mind when you want to start and run a project.

Temporary, not routine

Operational management never really “ends.” It’s a continuous cycle of keeping things going and improving them along the way.

A project is the opposite. It’s temporary by design. It exists to reach a specific, agreed result. Once that result is delivered, tested, and the client is happy, the project is done. It gets handed over to operations, maybe with a bit of aftercare, and then it closes. There’s a clear finish line, something operational management simply doesn’t have.

That’s the mindset shift a lot of people underestimate: a project manager isn’t there to keep something running. They’re there to make themselves unnecessary as fast as possible, by delivering the result and closing the project down.

One client, one project manager

This is the golden rule, and it needs to be crystal clear from day one: there is one client and one project manager, and only they make formal decisions and agree to changes.
Sure, the client will lean on advisors. The project manager has a team behind them. That’s normal. But the moment formal decisions start happening outside that one relationship — a stakeholder here, a team member there, an advisor pushing their own agenda — the project starts to drift. Costs go up, quality shifts, deadlines move. Every one of those is a symptom of the same disease: decision-making that leaked outside the two people who are supposed to own it.

If you’re running a project, protect that line. It’s not bureaucracy for the sake of it,  it’s what keeps the project on track.

Leading without the authority you’re used to

Here’s something operational managers often underestimate until they’re in the middle of it: as a project manager, you usually don’t have hierarchical authority over your team. People are “on loan” from their own departments. They still report to their own manager, get their appraisal from their own manager, and go back to their own manager when the project ends.

In operations, if you need something done, you can simply direct it… you’re the boss. In a project, you can’t. You lead through influence, clear agreements, and making sure people understand why their piece matters. That’s a different muscle entirely, and it’s usually the thing that trips up operational managers the most when they first run a project: the tools they’ve always relied on to get things done just aren’t there anymore.

Know the result before you start

In operational work, “the result” is often a moving target, you’re optimizing something that never really finishes. In a project, the end result has to be clear before you begin, and it needs to be written down: requirements, specifications, whatever you want to call it. That’s the yardstick the client uses at the end: is this what we agreed on?

Of course, some projects are inherently uncertain, think of something genuinely new, where the technology doesn’t fully exist yet (sending a rocket to the moon, as I like to say). Those need more room for discovery. But even then, you define as much as you can up front, and you build in moments to re-confirm scope as you learn more. “We’ll figure it out as we go” is not a project plan, it’s a warning sign.

Keep the project outside daily operations

This is probably the most common — and most damaging — mistake I see. Someone with a full operational job gets pulled into a project “on top of” their regular work. And I always ask the same question: where exactly is this person supposed to find that time?

They don’t find it. Something gives. Either the daily job suffers, or the project suffers, or — most often — the person themselves burns out trying to do both. Nobody wins.
If you want people from operations involved in a project, you have to actually free them up. Temporarily replace them in their day job, or scale down their operational load for real. Anything less and you’re not resourcing a project, you’re setting someone up to fail quietly.

I once saw this play out with a warehouse supervisor asked to join a new system implementation “for two days a week.” Those two days never materialized, he was still fully needed on the floor, so project meetings got skipped, deliverables slipped, and after a few weeks he was quietly dropped from the project “for a while.” The project lost his knowledge exactly when it needed it most, and he spent months feeling like he’d failed at something he was never actually given the time to do. Nobody planned for that outcome. It just happens, quietly, whenever this trap isn’t taken seriously.

Training: timing is everything

One thing I see forgotten in projects, or simply done at the wrong moment, is training the people who’ll actually work with the result. And when it does happen, it’s often scheduled far too early,  sometimes months before go-live, because “we had a training slot available” or “the trainer was free that week.”

That’s a mistake. Adults learn by doing, not by sitting through a session and then waiting weeks before they get to apply it. If you train people too early, most of what they’ve learned has faded by the time they actually need it, and you end up training them again anyway, just informally, on the job, under pressure, without a trainer in the room.

Training should sit as close to handover as possible, ideally right before people start using the new system, process, or way of working for real. That way what they’ve just learned is still fresh, and they get to put it into practice immediately, while there’s still support around if something doesn’t click. It also means training shouldn’t be an afterthought squeezed in wherever it fits in the planning. it needs its own spot on the project timeline, deliberately placed right before the switch to daily operations.

Get this right and the handover goes smoother, people feel confident instead of thrown in at the deep end, and the operational team is actually ready to own what the project delivered…not just formally, but in practice.

The handover: the moment everything is decided in advance

Because the end result is agreed at the start, the handover shouldn’t be a surprise at the end, it should already be designed on day one. Who tests what? Who inspects, who signs off, in what order?

The way I see it: the project team is responsible for testing before handover. The client is responsible for testing before formal discharge. Two separate checks, two separate responsibilities.

Once the project is discharged, the team disbands, the project manager moves on to the next project, specialists go back to their own jobs or leave entirely. Getting anything fixed after that point becomes painfully hard, because the knowledge and the people have already scattered. That’s exactly why the handover deserves as much attention as the kickoff, not an afterthought once everyone’s mentally already moved on.

Don’t start too fast

“Preparation is half the work” is true almost everywhere, but it’s especially true for projects, because you don’t get the luxury of course-correcting forever, there’s a fixed end point.
Before anything else: get the result crystal clear, put it on paper, and get it formally signed by both client and project manager. Only then select and prepare your team. And make sure everyone connected to the project — directly or indirectly — actually knows it’s happening and what it means for them.

Skipping this phase to “just get started” almost always costs more time later than it saves now.

Project management is a profession

Put it all together and the picture is clear: project management isn’t operational management with a different label. It runs on different principles; a defined end, a single decision-making line, resources that are truly dedicated, and a handover that’s planned from the very start.

It’s a profession in its own right. Not everybody’s cup of tea, and definitely not something you do well “on the side” of an operational job. Take it seriously, or the project will make sure you do, usually the expensive way.

We offer a hands-on, practical project management training; no dry theory, just the tools and mindset you need to run a project well from day one. The training is led by a certified Project Management Practitioner with real, hands-on project experience, so you’re learning from someone who’s actually been in the room where these traps happen…not just read about them 🙂

Peter Henssen