Teamwork Is Not Motivational. It Is an Architectural Discipline.
Most executives form a project team the way you’d assemble a dinner party. Get good people in the room, set a friendly tone, trust that competence and goodwill will do the rest. Then three months in, the team is missing deadlines, blaming each other quietly, and someone in the steering committee asks why “morale” is low — as if the fix is a pizza lunch and a motivational quote on a slide.
It isn’t. Teams don’t lose because they lack motivation. They lose because no one built the architecture underneath them.
Here is what that architecture actually looks like, and where I’ve watched it missing.
The rules of winning were never written down.
Before you staff a project, ask what winning looks like — precisely. Not “successful go-live.” What does successful mean, measured how, by when. I’ve sat in programs where the PM thought winning meant on-time delivery, the sponsor thought it meant zero disruption to the business, and the vendor thought it meant contract sign-off. All three were “winning” by their own definition while the program quietly failed by everyone else’s. That isn’t a communication problem. It’s a missing architecture problem — nobody built the shared definition before the team started running.
The opposition was never named.
Every project has an opposition. Sometimes it’s a competing vendor. More often it’s something less obvious — the department that loses control when the new system goes live, the legacy process with twenty years of institutional memory behind it, the executive whose budget shrinks if this succeeds. Teams that don’t name the opposition spend their energy fighting each other instead, because the resistance has to land somewhere. I’ve watched implementation teams turn on their own project manager mid-program, when the actual opposition was a business unit that was never going to cooperate no matter who ran the project.
Roles were assumed, not assigned.
“We’ll figure it out as we go” is not a role structure. On more than one ERP program, I’ve seen a business analyst and a process owner both assume the other was documenting the requirement — and neither did. Not because either was careless. Because nobody had drawn the line of who owns what, in writing, before the work started. Ambiguity in roles doesn’t average out to shared ownership. It averages out to gaps.
The sponsor led from behind the report, not from the front.
A sponsor who reviews a steering pack once a month and signs off is not sponsoring — they’re auditing. I’ve sat in rooms where a hard call needed to be made — cut scope, extend timeline, remove a non-performing vendor — and the sponsor deferred it to “let the team work it out.” The team can’t make that call. That’s what sponsorship is for. When the sponsor won’t stand in front of the decision, the team learns that no decision is safe to make, and everything slows down waiting for cover that never comes.
The plan was agreed but never rehearsed.
Everyone signs off on the cutover plan. Almost nobody rehearses it. I’ve watched go-live weekends unravel not because the plan was wrong on paper, but because it had never been run end-to-end under pressure before the day it mattered. A plan that’s only ever been discussed, never rehearsed, is a hypothesis — not a strategy.
Individual members didn’t know if they were winning — so they declared victory alone.
A developer hits their module deadline and feels like they’ve won, while integration testing is three weeks behind because nobody else is close to done. That’s not malice. That’s a team where individual winning and collective winning were never connected. The strongest teams I’ve been part of had a simple discipline: you don’t get to feel like you’ve won until the team has. That single shift in what “winning” means changes how people behave weeks before the deadline, not just on the day.
Wins were banked silently. Losses were buried quietly.
The programs that keep improving are the ones that stop and name what happened — properly, not in a five-minute agenda item nobody reads. A win gets analysed for what to repeat. A loss gets analysed for what to fix, without anyone getting quietly blamed and reassigned before the lesson is extracted. Most project teams skip this because everyone wants to move on. That’s exactly how the same mistake reappears in the next phase, with a different name on it.
None of the above is about morale. It’s about whether the structure a team operates inside was actually built, or just assumed into existence because the org chart said “project team” at the top of a slide.
So when you next stand up a team — for a project, a turnaround, a campaign, anything with a real opposition and a real cost of losing — ask yourself honestly: did you build the architecture, or did you just hope the people you picked would supply it themselves?
