How do I improve teamwork when the project team is temporary?
After twelve years of navigating the complex, often messy world of UK project delivery, I have come to a singular, slightly uncomfortable realisation: the project plan is the easy part.
When you are dropped into a temporary project team—perhaps a group of strangers assembled to execute a digital transformation or a regulatory change—you don’t have the luxury of years to build trust. You have a Gantt chart that looks like a game of Tetris gone wrong, a budget that’s already been squeezed by the finance department, and a team of people who are likely distracted by their "day jobs."
In these environments, traditional hierarchy is useless. Nobody reports to you. You have to rely on influence, radical clarity, and the ability to turn a collection of individuals into a functioning unit before the first milestone hits.
The Trap of the "Project artefact"
Too many PMs treat the Gantt chart and the budget tracker as the "work." They aren't. They are just weather reports. If your team is failing to collaborate, it isn't because the Gantt chart is missing a dependency; it’s because the human infrastructure is broken.
When I look at my "Corridor Chat Log"—that little notebook I keep where I jot down the whispers that never make it into the formal risk register—the themes are always the same. "I didn't want to ask Dave because he seems busy," or "I assumed the marketing team had already signed off on the budget."
These are the weak signals of a team that doesn’t have established collaboration habits. Here is how you fix that, starting today.
1. Establishing "Team Norms" in the First 72 Hours
In a permanent team, norms evolve organically. In a temporary project team, you have to engineer them. If you don't define how you work together, the loudest person in the room will define it for you.
Don't call it a "team charter." That sounds like corporate fluff. Call it your "Ways of Working Agreement." Make it a living document that covers:
The "Bad News" Clause: Establish early that bad news is not a failure; hiding bad news is. Reward the person who brings you a problem at 9:00 AM, not the person who hides it until the status report at 4:00 PM. The "Audience-First" Rule: Agree that all communication—emails, meeting notes, slack updates—must be written for the reader, not the writer. If a stakeholder doesn't understand the budget impact in two sentences, it’s not their fault; it’s yours. The "Default to Open" Policy: Discourage siloed emails. If it affects the delivery, keep the relevant people in the loop.
2. Communication: Tailored to Audience, Not Template
I loathe copy-paste stakeholder plans. They are the death of projects. You cannot treat a Lead Engineer the same way you treat a Finance Director.
The Art of the Rewritten Meeting Note
One of my golden rules is to never send raw meeting notes. If your notes are just a chronological list of who said what, you’ve failed. Rewrite them for the reader:
The Summary: Start with the "So What?" Why does this meeting matter? The Decisions: A bulleted list of what was agreed. The Actions: Clearly marked with a name and a deadline. The Context: A brief sentence on how this impacts the budget or the timeline.
3. Developing the "Project Ear": Listening for Weak Signals
As a coach, I see so many PMs waiting for a formal status update to discover a problem. By the time it’s in a status report, it’s no longer a "risk"; it’s an "issue" (and usually a catastrophe).
You need to practice active listening. Pay attention to what people don't say. If you ask a specialist, "Are we on track for the integration test?" and they pause for three seconds before saying, "Yeah, it should be fine," that pause is the most important piece of data you have.
Don’t push them. Just make space. "I heard a hesitation there. Is there a technical blocker or a resource constraint I need to know about?"
4. Managing the "Temporary" Dynamics
Because these teams are temporary, people often feel less invested in the outcome. They are "passing through." You have to combat this by making the mission tangible. Use the following framework to align them:
Tool The "Common" View The "Delivery Coach" View Gantt Chart A list of tasks and dates. A visual narrative of how we win together. Budget A cost constraint. A prioritisation tool to empower decision-making. Status Report "Everything is green." An honest conversation about current momentum and obstacles.
5. Documentation for Non-Specialists
The biggest threat to a temporary team is the "Expertise Cliff." If one person holds all the knowledge about how the budget spreadsheet works or how the API integration functions, you have a why psychological safety matters in projects massive single point of failure.
Force documentation to be simple. If a non-specialist in the team can’t read your project document and understand the core risk, it’s too complex. Use simple language. Avoid acronyms unless you have a glossary. Your role as a leader is to act as the translator between departments, not the gatekeeper of jargon.
Final Thoughts: The Soft Skills are the Hard Skills
If you take anything away from this, let it be this: people work better when they feel seen and understood.
When I look back at the most successful temporary teams I’ve led, the common denominator wasn't the software they used or the robustness of their Gantt chart. It was the fact that we had collaboration habits. We had a culture where people felt safe enough to say "I don't know," where meeting notes were actually readable, and where we spent as much time talking about how we worked as we did talking about what we were working on.
Your team may only be together for six months, but the impact of a well-functioning team lasts much longer. Don't waste the time you have.
Got a "corridor chat" you’re worried about? Let’s talk about how to turn those weak signals into project health.
