Conflict Management Techniques in Project Management: Five Strategies

Four weeks before practical completion on a hospital refurbishment — somewhere around £28m contract value — the structural and M+E lead engineers were called into a joint session to address a coordination failure that had been building for months. Both had been attending the same progress meetings. Both had signed the same minutes. The M+E engineer had been running his services design on an assumption about structural penetration locations that the structural engineer hadn’t confirmed. The structural engineer had been assuming M+E would coordinate around the as-built slab positions. Neither had said anything. By the time anyone noticed, the remedial cost — just in direct rework and re-ordered equipment — came in above £300,000. That’s before the programme extension, before the knock-on to the follow-on contractor, before the client’s own fit-out programme slipped. I’ve thought about that project a lot — and I’ve used it as an opening example in more than one session on conflict management techniques in project management.In the coordination meetings both men were professional, polite, present. Nobody watching would have identified a conflict. That’s the thing conflict management techniques in project management training almost never addresses: the most destructive conflicts don’t look like conflicts.

TYPES OF CONFLICT IN PROJECT MANAGEMENT — WHY CONFLICT MANAGEMENT TECHNIQUES AREN’T ONE-SIZE-FITS-ALL

The first thing worth knowing about conflict management in project management is that “conflict” isn’t one thing. The approach that resolves a technical disagreement between two engineers often makes an interpersonal dispute worse. The intervention that works on a governance argument is wrong for a relationship problem. Most conflict management techniques in project management training treats the five Thomas-Kilmann modes as if the type of conflict doesn’t affect which mode is appropriate. It does. Significantly.

Task conflict is disagreement about the work itself — what to do, how to do it, what the right answer is. When handled well, it produces better decisions than premature agreement. The disagreement surfaces information. Two engineers who genuinely disagree about a structural specification and work through it are more likely to arrive at the right answer than a team where seniority determines the outcome before anyone argues the case.

Relationship conflict is personal — friction between individuals that has nothing to do with the work itself. History between people, perceived disrespect, incompatible working styles. It’s also the type most project managers handle worst, partly because it requires engaging with emotions rather than facts, and partly because acknowledging it feels like admitting the team has a people problem rather than a technical one. Which it does. That’s fine. It’s honest. Ignoring it is not.

Process conflict is disagreement about how work should be organised, who has authority over what, or whose approval is needed before proceeding. Common on matrix structures where reporting lines are ambiguous. Often mistaken for task conflict when the actual disagreement is about governance, not substance.

Status conflict is about authority, recognition and professional standing. Two senior team members competing for influence over a decision. A contractor feeling undermined by a client representative who bypasses their site manager. A specialist being told to work to a programme they weren’t consulted on. Status conflict is almost never named. It hides well. It presents as a technical disagreement, a governance argument, a scope dispute. The tells: one party keeps raising the same issue even after it’s been resolved; decisions get re-litigated; people talk to each other’s managers rather than to each other. The issue isn’t the work. It’s the hierarchy.

The Thomas-Kilmann Model: A Framework for Conflict Resolution Strategies

The Thomas-Kilmann model maps five conflict resolution strategies on two axes: how assertively you pursue your own position, and how cooperatively you try to meet the other party’s needs. The five modes are Competing, Collaborating, Compromising, Avoiding and Accommodating. It’s been the standard reference since the 1970s, and it holds up — not because it tells you what to do in a given situation, but because naming the modes makes it easier to notice when you’re defaulting to the same one regardless of context.

The model’s value isn’t in telling you what to do. It’s in making you aware of your default mode — the one you reach for automatically under pressure — and recognising when that default is wrong for the situation. Most people have one or two dominant modes. A project manager who defaults to avoiding tends to let conflicts quietly damage the project for weeks before acting. One who defaults to competing tends to win arguments and lose relationships. Neither is universally right or wrong, but being stuck in one mode regardless of context is almost always a problem.

Five Conflict Management Techniques in Project Management: What Each One Actually Does

1. Collaborating (Problem-Solving)

Collaborating — or problem-solving — is the mode where both parties work through the underlying interests rather than arguing positions. It’s slower than every other approach. It requires enough trust for both parties to say what they actually need, rather than defending what they initially asked for. PMBOK recommends it as the primary approach, which is right in principle and sometimes impractical in reality. You need both parties willing to engage in good faith, and you need enough time. On a project under commercial pressure with parties who have reason to be suspicious of each other’s motives, those conditions aren’t always present.

The hospital refurbishment conflict I described in the opening was eventually resolved through a three-hour facilitated session between the structural and M+E leads. Not a negotiation — a joint problem-solving exercise where both were asked to explain their design assumptions and constraints from the beginning. What emerged was that both engineers had made reasonable assumptions given their information, and neither had created the problem alone. The collaborative session identified four specific coordination interfaces that needed formal sign-off before either party could finalise their design. The process produced a protocol that should have existed from the start of the project.

Collaboration fails when there isn’t enough time, when the relationship damage is too severe for honest dialogue, or when one party is unwilling to engage in good faith. Attempting a collaborative approach when those conditions aren’t met produces a meeting that looks collaborative but actually just delays resolution. Both parties know it. Neither says so.

2. Compromising

Compromising is the mode where both parties accept less than they wanted. Faster than collaborating, less damaging than competing, more equitable than accommodating. It works when the stakes are moderate and both parties are genuinely motivated to resolve the issue — a programme date dispute where both sides need the project to move forward is the classic case. Both accept a date neither wanted. Both get on with it. Good enough.

Compromise is overused. On technical decisions it’s usually just a polite way of being wrong — a structural specification set at the midpoint between two engineers’ positions isn’t necessarily correct, or safe. Technical disagreements should be resolved through evidence. Splitting the difference is faster, and it gets both parties out of the room, and it leaves you with an answer nobody thinks is right.

3. Competing (Forcing)

Competing means using your authority or positional power to impose an outcome. Fast. Decisive. Appropriate in emergencies where a decision needs to be made immediately and there isn’t time for dialogue. Also appropriate when one party is clearly right based on evidence and the other is obstructing rather than contributing to the resolution.

Competing damages relationships and creates resentment. The party who loses tends to comply but not commit — they do what they’re told and wait for an opportunity to raise the issue again. On a project where the same people need to work together for another year, winning a conflict through force usually stores up a worse conflict for later. I’ve seen project managers resolve a disagreement by invoking their authority in a meeting, only to find the other party had quietly escalated to the sponsor and was having a separate conversation about whether the PM had the authority to make that call. Competing without the authority to back it up is worse than not competing. The room notices. It remembers. Every time.

4. Accommodating (Smoothing)

Accommodating means conceding your position to preserve the relationship. It’s appropriate when the issue genuinely matters more to the other party than to you, when you’ve assessed that you might be wrong, or when maintaining goodwill is worth more than winning this particular point. A PM who lets a contractor’s preferred minor programme adjustment stand because the relationship is more important than the two-day schedule impact is making a reasonable call.

Accommodating becomes a problem when it’s used habitually to avoid difficult conversations. A PM who accommodates every time faces pushback ends up managing a project where the path of least resistance always wins, regardless of merit. The team learns that persistence is more effective than evidence. Accommodating occasionally is relationship management. Accommodating consistently teaches the team that persistence beats evidence. That’s a governance failure with a long tail. The team has learned something. You didn’t intend to teach it.

5. Avoiding (Withdrawing)

Avoiding. Declining to engage. — postponing, deflecting or withdrawing. Sometimes appropriate when emotions are running too high for productive dialogue, when more information is needed before a position can be taken, or when the issue is genuinely trivial and will resolve itself. The two-week delay between a conflict surfacing and a structured conversation about it can sometimes be the right call if it allows parties to reconsider their positions.

The hospital engineers were avoiding. They weren’t arguing. That was the problem. They had made a shared, rational calculation that the coordination conversation would be difficult — probably involving admissions of design assumptions that hadn’t been formally agreed — and they deferred it indefinitely. Avoiding a difficult conversation doesn’t make the underlying issue go away. It makes it more expensive. Usually much more.

When to Use Which Conflict Management Technique

The Thomas-Kilmann model gives you a map of the options. What it doesn’t give you is a decision rule. The right technique depends on four things: the stakes, the relationship, the time available, and the power dynamic between the parties.

High-Stakes Technical Disagreements: Which Conflict Resolution Strategy Applies

Collaborating is the right approach here. The cost of a wrong technical decision usually exceeds the cost of the time spent resolving the conflict properly. Compromising is dangerous — the midpoint between two technical positions isn’t necessarily correct. Competing is appropriate if one party has genuinely superior expertise and the evidence is clear, but needs to be exercised carefully to avoid creating the impression that technical authority is being overridden by positional authority.

Resource and schedule disputes

These are the conflicts most project managers encounter most often. Two work packages competing for the same resource. A milestone date that the programme says is achievable and the delivery team says isn’t. Compromising often works here — partial satisfaction is genuinely possible, and both parties usually understand that neither gets everything they want. Collaborating is appropriate when there’s a creative solution neither party has considered. Competing — invoking authority to resolve the dispute — is appropriate when the project’s critical path makes one priority clearly higher than the other.

Interpersonal and relationship conflicts

Avoiding is almost never the right approach to relationship conflict on a project. It defers the cost and increases it. Collaborating is often the right approach, but usually requires a facilitated process — the parties can’t resolve a relationship conflict through the same conversation structures they use for task conflict. Competing makes it worse. Accommodating treats symptoms. The honest answer is that genuine relationship conflict on a project often requires a conversation the PM is not equipped to facilitate, and escalating to HR or bringing in a neutral third party is the right call sooner than most PMs make it.

When to Escalate: Limits of Conflict Management Techniques in Project Management

Escalation is not a failure. It’s a conflict management technique. Most project managers reach for it too late. Most project managers wait too long to escalate conflict — either because escalation feels like admitting they can’t handle it, or because they’re worried about the political fallout of involving senior stakeholders in what looks like a team problem.

Escalate when: the conflict involves parties with authority levels above the PM’s capacity to resolve; when a direct attempt at resolution has failed and the conflict is affecting delivery; when the conflict involves a contractual or governance question that the PM doesn’t have authority to determine; or when one party is behaving in bad faith — escalating costs, withholding information, or pursuing an agenda that conflicts with the project’s interests.

Don’t escalate as a first move in a conflict that could be resolved at team level. Don’t escalate to embarrass the other party. Don’t escalate without first making a genuine attempt to resolve the conflict directly. And don’t delay escalation past the point where the project has absorbed significant damage because you were trying to manage something that was beyond your authority to resolve.

On a large construction programme I was involved with, a conflict between the main contractor’s commercial team and the client’s quantity surveyor over interim payment certification had been running for eleven weeks before it was escalated. Both parties had legitimate positions. Neither had the authority to resolve the underlying contractual ambiguity. The PM kept trying to mediate a dispute that required a legal interpretation. When it finally reached the senior client and contractor representatives, it was resolved in one meeting. Eleven weeks of tension, damaged relationships and delayed cash flow. For a one-hour conversation.

Structural Conflict Management in Project Management: When Technique Isn’t the Problem

Many project conflicts aren’t interpersonal — they’re structural. They arise from the way the project is organised, the contracts are written, or the governance is designed. Applying conflict management techniques to a structural conflict is treating symptoms. The conflict will recur. Different form, same structure.

Matrix Structure: Conflict Management in Project Management When Authority Is Split

In a matrix organisation, team members have two reporting lines — to their functional manager and to the project manager. When those two authorities disagree about priorities, the team member is caught between them. This is a structural conflict. The conflict management technique that “works” is whichever authority wins the immediate argument. But the conflict will happen again on the next priority question. The fix isn’t a better conversation. Not this time. The structural fix is clear governance about how competing priorities are resolved — which authority prevails in which circumstances, and what the escalation path is when they disagree. Without that clarity, the conflict is baked in. It will recur every time priorities diverge. For more on how structure drives authority conflicts, see the article on types of organisational structures in project management.

Contract and commercial conflicts

Construction and infrastructure projects routinely generate commercial conflicts — variations, extensions of time, loss and expense claims — that are partly genuine disagreements about fact and partly strategic positioning for commercial advantage. These conflicts have a legal and contractual dimension that sits above the interpersonal. Applying collaborative problem-solving to a commercial dispute where one party is building a claim position is naïve. Sometimes dangerously so. The right approach is usually a combination of commercial awareness (understanding the other party’s incentives), legal clarity (knowing what the contract actually says), and relationship management (preserving the working relationship while the commercial dispute is handled through formal mechanisms).

Ambiguous scope and authority

Conflicts arising from unclear scope — who owns this decision, whose design takes precedence, what constitutes a variation — are governance conflicts, not personality conflicts. The resolution is not a better conversation. It’s a clearer contract, a more explicit responsibility matrix, or a governance forum with the authority to make binding decisions. The PM’s role here is to identify that the conflict is structural and to escalate the request for structural clarity, rather than repeatedly mediating the same boundary dispute as it recurs in different forms.

Conflict Management Techniques in Project Management: PMP Exam Context

The PMP exam hits conflict management hard. Most questions are scenarios — here’s a situation, here’s what the PM did, was it right? Or: here’s a conflict, what should the PM do next? The scenarios are usually clear enough that the right answer is identifiable if you understand the five modes and PMI’s preference ordering.

PMI’s preferred answer is almost always collaborating. If the scenario gives you options and one of them involves exploring underlying interests, that’s usually the right pick. Avoiding is wrong on the exam even when it looks reasonable — the exam is testing the ideal response, not the politically expedient one. In real projects, collaborating is usually right too, just harder to pull off than the exam scenarios suggest.

One thing the exam gets right that practice often gets wrong: conflict isn’t inherently a problem. Moderate task conflict improves decisions. A project with no visible disagreement isn’t necessarily well-managed — it might just mean nobody is saying what they actually think. Which brings you back to where this started.

If the conflict on your project is structural — authority overlaps, unclear governance, matrix ambiguity — the article on project life cycle phases, which covers when conflict is most common across a project’s development, and the risk management process article — unresolved conflict is one of the most consistently underlogged project risks. The PMI’s own resource on conflict resolution strategies and the APM’s guide to conflict management in project management are worth reading alongside this for exam preparation.