A Project Manager once asked me a question that caught me off guard:
"How do I force my team to follow what I say? I know the best workflow for them, but they’re defensive and won’t change anything."
This kind of question doesn’t lead anywhere good. In fact, it’s based on a mistaken premise: that you know what’s best for the team before you’ve worked with them.
Courses and certifications are useful. They give you a toolkit. But they don’t give you the team. And they definitely don’t give you permission to treat frameworks as commandments.
Knowing how Scrum works doesn't mean your team should use it. In fact, if your first instinct is to force a team into Scrum, there are two possibilities: either you don’t fully understand Scrum, or your team doesn’t need it.
The same goes for Waterfall, Kanban, PRINCE2—any framework, really. They’re all optional. The real skill of a Project Manager is not in memorizing process diagrams, but in choosing what fits. And more often than not, what fits is something you’ll have to tailor yourself.
Right now, I’m managing three projects. Each one runs differently.
So what influences your approach?
Start with team size. The bigger the team, the more communication paths exist. There’s even a formula for it: n(n-1)/2. A team of 8 has 28 communication channels. A team of 11 has 55. That’s why scaling is hard. Every new person adds more complexity than you’d expect.
Then there’s team maturity. Agile isn’t easy. Neither is Waterfall. If your team hasn’t worked with a given methodology before, there’s going to be a learning curve. Most developers I’ve worked with have never read the Scrum Guide, let alone been certified in it.
If you want to dig deeper into this, look up the Capability Maturity Model (CMM). It breaks maturity into five stages: Initial, Repeatable, Defined, Managed, Optimizing. But even without the model, the idea is simple: don’t assume your team starts at level 5.
And don’t forget yourself. Your own experience matters too. Not just what you know, but how well you can adapt to the situation in front of you.
So what do you do if the team seems chaotic and unstructured?
You might be tempted to push hard. But that’s the worst time to do it. The better approach is to observe, stabilize, and co-create.
Start by watching how things already work. Map out their current process. It might be messy. That’s fine. Your job is to find the patterns in the mess and help the team make them repeatable.
Then bring them into the process.
→ Ask simple questions: “What’s frustrating you right now?”
→ Let them define the problems. They usually know.
→ Don’t propose a framework—propose a small change. “What if we tried breaking this into smaller chunks?” That’s how you sneak in iterations without triggering resistance.
If you want to make a process stick, don’t sell it. Let the team discover the benefit themselves.
→ Show small wins. A kanban board that cuts down on chaos. A weekly check-in that prevents last-minute surprises. A better way to share updates that saves them time.
These small shifts build momentum. And momentum builds trust.
Once the team feels stable—once they trust you and see that change can actually make things better—you can guide them further. Not by force, but by alignment.
That’s how real transformation happens. Not all at once. And not because you told them what to do. But because you listened, adapted, and moved forward—together.