Conflict in Projects: Where It Really Comes From, and What Actually Works
The worst meeting of one integration go-live had no shouting. It was the silence of two teams sliding log files at each other across the table. The vendor's logs proved they had sent the data. Our internal team's logs proved it never arrived. Both were right, both felt accused, and every hour we spent on whose fault it was, real orders sat stuck in a queue.
That day I learned the first rule of conflict on projects: the argument is almost never about the thing being argued. It was not about log files. It was about who would take the blame in front of leadership. Once I said out loud that the incident review would name causes and not people, both sides put their logs down and we found the dropped message in forty minutes, sitting in a retry queue between the two systems, belonging to nobody.
Where conflict actually comes from
PMI lists the classic sources: scarce resources, scheduling priorities, technical opinions, personal styles. All true, and I have met each one. Two teams fighting over the same test environment. A parent company and an offshore team with different answers to "when is this due". Engineers deadlocked over adopting a new framework. The list in the book is accurate.
What the book undersells is that these are usually the surface. Beneath a scheduling fight there is often a resourcing promise someone made upstairs without asking the team. Beneath a technical deadlock there is often a fear of being the one who maintains the risky choice at 2 a.m. If you resolve the surface argument without touching the real one, congratulations: you have scheduled the same conflict for next sprint.
The five approaches, ranked by how often they get misused
PMBOK gives project managers five ways to handle conflict: withdraw, smooth, compromise, force, and collaborate. The exam wants you to know that collaborating is generally best. Real delivery work is messier.
Collaborate is the right default and the only approach that kills a conflict permanently, because it digs for the interest under each position. In the log-file standoff, the shared interest was obvious once spoken: nobody wanted a repeat incident. That turned two defense teams into one investigation team.
Compromise is what you do when time is scarcer than perfection. Splitting the test environment by odd and even days satisfied no one fully and unblocked everyone the same afternoon. Acceptable, as long as you know you traded quality of solution for speed.
Force has a bad reputation and one legitimate use: when the clock beats consensus. During an incident with money burning, I will pick a direction, state that I own the consequences, and we argue about it in the retrospective. Forcing a decision is sometimes leadership. Forcing it every week is just being a bully with a title.
Smooth is the most misused of the five. Emphasizing agreement to calm a room before a client call is a tactic. Doing it every time is how a team learns that raising problems is impolite, and then you get the silent slippage I wrote about in Why Projects Fail.
Withdraw looks like weakness and occasionally is wisdom. Not every hill needs a battle, and not every battle needs to happen in front of six spectators. Some conflicts I deliberately park for a one-on-one the next morning, when both people can back down without an audience.
Working across cultures raises the stakes
Several years of sitting between a Japanese parent company and a Vietnamese engineering team taught me that conflict style is cultural. A flat "no" that reads as honesty in one office reads as aggression in the other; a polite "we will consider it" that means "no" in one culture gets booked as a "yes" in the other's plan. The PM's job in that seat is translator of intent, not just language: restating each side's position in words the other side can actually hear, and confirming decisions in writing so politeness doesn't quietly become scope.
What I check before stepping into any conflict
Three questions, before saying a word. What does each side actually lose if they back down, status, workload, or risk exposure? Is this the real disagreement or the surface one? And does this need solving now in this room, or better tomorrow with fewer people? Getting those three right matters more than any technique name from the exam. The techniques tell you what to do. The questions tell you which one, and conflict handled at the right layer tends not to come back.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.