From Group to Team: How People Actually Come Together to Deliver Projects
When Polite Yeses Aren't Enough
Early in my career, on a track replacement project at a key London location, I thought team management was about getting to "yes". I walked in with project plan print-outs, went milestone by milestone, and secured dates on the spot. Heads nodded. Names went next to tasks. We left "committed".
It looked organised. It wasn't real.
Over the next few weeks, the team challenged me. "We've done this work for years, and there's a better way than what's on that plan." That honesty shifted everything. We talked, disagreed, and eventually aligned on what actually mattered. The plan didn't disappear; we just made sure it reflected reality, not the other way around.
By midpoint, we'd found our groove. When delivery day came, we performed as one unit. Issues cropped up but were handled without drama. Then, just as quickly, we wrapped up: debrief done, lessons logged, everyone scattered to their next thing.
Only later did I realise I'd lived through the classic stages of team development. And that's what I want to share with you: not the theory, but what it actually looks like on the ground.
Why This Actually Matters
Project teams come in all shapes: small core groups, massive multi-org setups with suppliers, consultants, clients, end users. But they're all formed for one thing: to deliver something specific.
Here's what makes it complex. Every person brings their own way of working, their own expectations, their own cultural norms. You're not just managing tasks; you're navigating all these differences. And as a PM, you often don't get to choose your team. That's actually fine. Some of my best teams have been the ones I didn't pick.
Your job isn't to build the perfect team on paper. It's to create an environment where the team you have can thrive.
A real team isn't just people with tasks. It's people who depend on each other, working towards the same goal, holding each other accountable. That's what separates a team from a group of individuals who happen to share a deadline.
In my experience, teams thrive on four things:
Clarity: Everyone knows the goal, their role, and how decisions get made
Psychological safety: People speak up and admit mistakes without fear
Routine: There's a steady rhythm that keeps things moving
Care: People get support when they need it
Get these right and you'll know it. Work flows. People challenge ideas without attacking each other. Innovation happens because it's safe to fail. That's what we're aiming for.
The Five Stages Every Team Goes Through
Teams move through five predictable stages. This is Bruce Tuckman's model from 1965: Forming, Storming, Norming, Performing, and Adjourning. He studied loads of teams and found they all go through these phases when coming together to achieve something.
Here's what each stage actually looks like:
Stage 1: Forming ("We've Just Met")
The team first comes together. People are figuring out who's who and how we'll work together.
You know you're here when:
Conversations are polite but surface-level
People are unsure about roles
Lots of questions but not many challenges
Everyone's being carefully professional
This was my track replacement team with those print-outs: everyone nodding along, nobody really committed.
What to do as a PM:
Write a one-paragraph project purpose together
Agree how decisions get made and where they're logged
Go for a quick win: "What can we finish in two weeks?"
Make it safe to say "I don't understand"
Set up shared spaces: boards, folders, channels
Stage 2: Storming ("The Gloves Come Off")
Things get real. People start pushing back and disagreeing. It's uncomfortable but healthy.
You know you're here when:
Disagreements become visible
People push back on decisions
Frustration shows up in meetings
Some go quiet while others get louder
This is when my team told me there was a better way than my perfect plan. It felt uncomfortable. It was exactly what we needed.
What to do as a PM:
Make space for disagreement without punishment
Run small experiments to test approaches
Clarify who decides what and log it
Stay calm and guide, don't control
Help people see conflict as progress
Stage 3: Norming ("Finding Our Rhythm")
The team starts to gel. People understand each other's strengths and find their rhythm.
You know you're here when:
Meetings start on time with clear actions
People volunteer to help each other
The team self-corrects when off track
Work flows without constant checking
By month two of my project, we'd stopped debating and started delivering. Regular catch-ups, clear responsibilities, everyone knew their part.
What to do as a PM:
Document what's working
Create simple templates and checklists
Rotate meeting leads to build ownership
Protect the rhythm; don't change unnecessarily
Start stepping back gradually
Stage 4: Performing ("This Is What Good Looks Like")
The team is flying. They're self-managing, solving problems, delivering without constant oversight.
You know you're here when:
Problems get solved before escalating
People make decisions confidently
The team handles changes smoothly
You can step back without things falling apart
This was my team on delivery day: when problems popped up, they sorted them without even pulling me in.
What to do as a PM:
Protect the team from distractions
Clear blockers fast; that's your main job now
Let the team own their delivery
Focus on stakeholders and future planning
Celebrate wins and capture lessons
Stage 5: Adjourning ("Time to Move On")
The project ends. Time to wrap up, hand over, and move on.
You know you're here when:
Delivery is complete or winding down
People start asking "what's next?"
Energy shifts to documenting
Team members begin transitioning out
After our track replacement: quick debrief, lessons logged, handshakes, then everyone scattered.
What to do as a PM:
Build a close-out pack: decisions, contacts, lessons
Document what worked and what didn't
Thank people publicly, feedback privately
Don't let the team drift apart; give closure
The Messy Reality
It's never a straight line. You'll loop back, skip forward, get stuck. A new joiner might pull you back to Storming. A crisis might jump you straight to Performing. That's all normal.
The good news? Once you know where you are, you know what to do. And if you've been through the stages before, you'll move through them faster the second time. That team that took six months to reach Performing? When you add a new person, you might cycle back through in just a few weeks.
The key is recognising where you are and responding accordingly. Don't panic when you slip backwards. Just identify the stage and apply what it needs.
What I've Learned (The Hard Way)
You don't always know who "the team" is. Core team? Suppliers? Stakeholders? You can categorise them based on their role in your outcome: delivery team, supply chain, governance. Map them out and treat each accordingly.
Teams beat plans. The best Gantt chart means nothing if your team isn't aligned. Invest time in building the team first; the delivery will follow.
Conflict is progress. That uncomfortable storming phase is where real alignment happens. Don't shut it down. Create safe spaces for disagreement and work through it together.
Make everything visible. Decisions, progress, problems: out of heads, onto boards. Use shared documents, visual boards, recorded decisions. If people can't see it, it doesn't exist.
Key Takeaways
Teams move through predictable stages: Forming, Storming, Norming, Performing and Adjourning
It's never linear; you'll loop back and that's okay
Your job changes with each stage: know when to direct, facilitate, or step back
Conflict isn't failure; it's a necessary step to alignment
You create the environment for teams to thrive, even when you didn't choose them
Recognition is key: know where you are, apply what that stage needs
Next time you're pulling a team together, remember: you're guiding people from strangers to a performing unit. It won't be smooth, but now you know what to expect and what actually works.
What's your experience with team development? Have you watched a team move through these stages? Or struggled when stuck in storming?
Drop me a message. Let's share what actually works when groups become teams.
References
Bruce Tuckman's Stages of Team Development (1965)
Want more practical PM insights like this?
Subscribe to The PM Notebook for regular insights straight to your inbox, or listen to The Real PM Podcast for honest conversations about what actually works.
Ready to bridge theory and practice? Try Mindcast - the first-of-its-kind interactive experiences I developed where you step through real project scenarios and make PM decisions hands-on. It's my way of helping and guiding you beyond traditional learning to build the practical judgment that only comes from doing.
Connect with me on LinkedIn for project management insights or get in touch to share your thoughts and experiences.