Skip to content

Manage Conflicts

Step 3 of 57

Manage Conflicts

Introduction

This lesson covers Task 1.2 of the People domain of the July 2026 PMP Examination Content Outline (ECO), a domain that carries 33% of the scored questions. Conflict is normal in any project: people with different goals, skills and pressures share limited time and money. The exam does not ask whether conflict exists; it asks how a project manager analyses it, chooses a response and puts in place principles that stop the same conflict from returning. Scenario questions typically describe two team members, two departments or a team and a vendor in disagreement, and ask for the best next step.

After this lesson you will be able to identify the sources of a conflict, analyse its context, choose among the resolution strategies, communicate conflict management principles, set ground rules with the team, and respond when someone breaks them.

Learning objectives

  • Name the common sources of project conflict and the stage at which a conflict has escalated.
  • Analyse the context (people, stakes, culture, delivery approach) before choosing a response.
  • Compare the five classic resolution strategies and pick the right one for a situation.
  • Agree on and communicate conflict management principles with the team and stakeholders.
  • Build ground rules (team agreement) collaboratively and manage violations.
  • Distinguish task conflict from relationship conflict, and know when to intervene.

1. Sources of conflict

Conflict is a disagreement in which parties perceive that their needs, goals or values are threatened. Project research and PMI materials repeatedly list the same sources.

Source Typical example
Schedule Two teams need the same environment in the same week; a milestone date is disputed
Priorities The sponsor wants speed, the quality lead wants more testing
Resources A shared specialist is pulled between two projects
Cost and budget A department refuses to pay for rework caused by another
Technical opinions Architects disagree about a framework or about build versus buy
Roles and responsibilities Nobody knows who approves a design, or two people believe they decide
Administrative procedures A reporting rule is felt to be bureaucracy
Personalities and values Communication styles clash; working-hour norms differ across cultures
Information A stakeholder learned of a change late or from a third party

Conflict is also classified as task conflict (about the work: scope, method, design), process conflict (about who does what and how decisions are made) and relationship conflict (about personalities and trust). Moderate task conflict can improve decisions, because alternatives are examined. Relationship conflict almost always harms performance and needs early attention.

Levels of escalation

A conflict usually escalates in stages: a problem to solve (disagreement about facts), a disagreement (people defend positions), a contest (winning matters more than solving), a crusade (people attack each other) and a world war (the relationship is destroyed). The earlier the project manager intervenes, the more options remain. Exam answers that act at the first signs, rather than waiting for the team to "work it out" when the conflict is already damaging delivery, are usually preferred.

Example: a conflict traced to its source

A telecom project has a recurring argument between the network engineering lead and the testing lead. Engineers say testers raise too many low-priority defects; testers say engineers close defects without retesting. On the surface it looks like personalities. On analysis the source is a process gap: there is no agreed defect severity scale and no rule on who closes a defect. Fixing the process removes most of the friction without any coaching of individuals.

2. Analyse the conflict context

Before choosing a response, collect facts. The ECO lists analysis of the conflict context as a distinct step.

  1. Who is involved? Individuals, groups, or a team and a vendor? Is a sponsor or senior stakeholder involved?
  2. What is the stake? Resources, reputation, workload, a safety or compliance issue?
  3. What is the stage? Early disagreement or a damaged relationship?
  4. What is the source? Use the table above. Treat the source, not the symptom.
  5. What is the context? Time pressure, culture, hierarchy, geography, the project's delivery approach and the history between the parties.
  6. What are the interests behind the positions? A position is "I want the test environment on Monday". An interest is "I must show the client a working build on Tuesday". Different positions can serve compatible interests.
  7. Are there signs of misconduct? Harassment, discrimination or ethical breaches are not conflicts to be negotiated; they follow the organisation's policy and the PMI Code of Ethics and Professional Conduct, which means reporting and involving HR or compliance.

Cultural and delivery context affects the best response. In a high-context culture a public confrontation may destroy trust, so a private conversation is better. In an agile team, many conflicts are resolved inside the team through the retrospective or a quick conversation, while a predictive project may use the escalation path defined in governance.

3. Resolution strategies

The classic model (Thomas-Kilmann, used in PMI guidance) describes five approaches. The exam uses PMI's names:

Approach Also called What happens Result Use when
Collaborate / problem solve Win-win Parties work together on the root problem and integrate viewpoints Lasting resolution, commitment Time allows; the issue is important; trust must be built; interests can be reconciled
Compromise / reconcile Lose-lose-ish Each party gives up something Partial satisfaction A quick, workable solution is needed; stakes are moderate; collaboration failed
Accommodate / smooth Give in Emphasise agreement and set differences aside Short-term peace, issue may return The relationship matters more than the issue; the issue is minor to you
Force / direct Win-lose One viewpoint is imposed by authority Fast, but resentment Emergency, safety, legal matter, or an unpopular but necessary decision
Withdraw / avoid Postpone Retreat or defer the issue Unresolved The issue is trivial, emotions need to cool, or more information is needed

Collaborate is generally the preferred approach in PMI scenarios, because it solves the root cause and maintains relationships. It is not always best: if a safety rule is at stake, force is appropriate; if the disagreement is minor and time is short, compromise or accommodate may fit. Read the situation and the constraint words ("urgent", "safety", "relationship") carefully.

The conversation structure

A useful pattern for a facilitated conversation:

  1. Meet the parties, first separately if emotions are high, then together.
  2. Set the frame: the aim is to solve the problem and keep working together.
  3. Let each party describe the situation and the impact without interruption. Use neutral language and focus on behaviour and facts, not on character.
  4. Identify the interests and the points of agreement.
  5. Generate options together, then evaluate them against agreed criteria (impact on the objectives, cost, risk).
  6. Agree on actions, owners and a follow-up date, and record the agreement.
  7. Follow up, because conflicts that look solved often reappear.

Worked example: choosing a strategy

Scenario. Two senior developers on a hybrid project disagree about whether to use a message queue or direct API calls between two services. The discussion has become heated in stand-ups and the team is waiting for a decision. Delivery is in six days, with a demo to the customer. Both are respected and both have valid arguments.

Step 1 - Analyse. The conflict is technical (task conflict) and has begun to affect the team. The source is differing technical opinions, the stake is the architecture and the demo date, and there is a time limit but no safety issue.

Step 2 - Choose. Collaboration is first choice, because the decision matters and both are experts. The project manager meets them together, asks each to define the criteria (latency, resilience, delivery effort, long-term maintenance), and asks them to score both options. They discover that for the demo a direct call is acceptable, and the queue can be introduced in the next iteration with a technical-debt item recorded.

Step 3 - Follow up. The agreement is recorded in the decision log; the team is told.

Why not other options? Forcing a decision by authority would solve the speed problem but could damage trust and ignore good arguments. Withdrawing would leave the team blocked. Compromising by using half of each approach would create an unnecessarily complex design. Collaboration found a solution that respected the date and the technical concern.

When to intervene directly

The project manager should step in when the conflict affects delivery, the people cannot resolve it, safety or compliance is involved, or when relationships are deteriorating. For minor task conflicts the team can work it out; encouraging the team to solve its own conflict first is preferred, particularly in self-organising agile teams, but the leader stays available and watches for escalation.

4. Communicate conflict management principles

The ECO asks the project manager to communicate conflict management principles and agreed-on resolution strategies, so people know in advance how disagreements will be handled.

Principles that work well:

  • Address it early and directly, with the people concerned, before involving others.
  • Be open and honest, and keep the discussion on the issue, not the person.
  • Focus on the present and the future, not on blame for the past.
  • Look for the interests behind the positions.
  • Use the escalation path only when the parties cannot resolve it themselves, and tell them when you will do so.
  • Respect confidentiality and cultural differences.
  • Prefer collaboration and document the agreement.

Include these principles in the team charter or working agreement, in the communications management plan (where conflict communication and escalation are defined) and in onboarding for new members. Stakeholders outside the team, including vendors and customers, should know the escalation path and its time limits, for example "unresolved within two working days goes to the product owner and the vendor manager".

5. Ground rules

Ground rules (also called a team agreement or team charter) are the behavioural expectations the team commits to. They reduce conflict by making norms explicit, and they are most effective when the team creates them, rather than receiving them.

Building ground rules

  1. Run a short workshop at team formation, ideally at kickoff or in the first iteration.
  2. Ask: "What helps us work well together? What makes us angry or frustrated? How will we make decisions? How will we handle disagreement?"
  3. Group the answers (communication, meetings, decision making, working hours, tools, conflict, respect), then write a short list, normally 5 to 10 rules.
  4. Obtain explicit agreement from everyone and publish the rules visibly.
  5. Review them regularly, for example in retrospectives, and adjust when the team or the context changes.

Examples of ground rules

Area Example rule
Meetings Start and end on time; cameras on for decisions in virtual meetings
Communication Answer direct questions within one working day; urgent issues by phone
Decisions Decide by consent after discussion; the owner decides if time runs out
Conflict Raise concerns with the person first; escalate after two working days
Respect One person speaks at a time; no personal criticism
Time zones Core overlap hours of 13:00 to 16:00 UTC; rotate inconvenient meeting times

Managing violations

When a ground rule is broken, the response should be proportionate and consistent.

  1. Observe and verify the facts. Was it a misunderstanding, an oversight or a pattern?
  2. Speak privately and promptly with the person, referring to the agreed rule and its impact, and ask for their view. Often the rule is unclear or the person had a reason.
  3. Agree on a correction and a time to check.
  4. Involve the team if the violation concerns the group's norms. The team that wrote the rules should own enforcement; in agile teams, use the retrospective.
  5. Escalate to the functional manager or HR only if the behaviour continues or is serious (for example harassment), and always follow policy.
  6. Review the rule if many people break it, because it may be unrealistic.

Worked example: a ground rule violation

Scenario. The team agreed that meetings start on time and that decisions are recorded in the shared log. A senior tester arrives 15 minutes late to three consecutive planning meetings, and the team starts to complain in private messages.

Step 1. The project manager checks the facts: the tester is attending a separate daily meeting that now overlaps, a result of the schedule changing two weeks ago.

Step 2. She meets the tester privately, refers to the agreement, acknowledges the clash and asks for suggestions. They agree to move the planning meeting by 30 minutes, and the rule is confirmed.

Step 3. She informs the team of the change and invites comments on whether the ground rules need updating, then adds "check calendar conflicts when scheduling" to the agreement.

Why not other options? Publicly reprimanding the tester would damage trust and ignore the real cause. Ignoring it would let resentment grow. Reporting to the functional manager at the first lateness would escalate prematurely.

6. Common pitfalls and exam tips

  • Avoiding conflict. Withdrawal rarely resolves a significant conflict. The first move is usually to talk with the parties.
  • Jumping to escalation. Unless safety, ethics or a stalemate are involved, the project manager first tries to help the parties resolve it.
  • Forcing a decision when time allows collaboration.
  • Treating symptoms. Look for the source (process gap, unclear role) and fix it.
  • Public criticism. Address behaviour in private and keep the focus on facts.
  • Ignoring culture. Directness that works in one culture offends in another.
  • Ethics are not negotiable. Any breach of law or the PMI Code of Ethics is reported and handled by policy, not by compromise.

Exam tip. When two options are "collaborate" and "compromise", choose collaborate if there is time and the issue is important, and choose compromise if the scenario stresses a fast, workable result after collaboration has failed.

Exam tip. In agile scenarios, the preferred first move is often to let the team resolve the conflict itself with support, using the retrospective or a facilitated conversation, rather than the project manager deciding for them.

7. Mini case study

Situation. A construction technology project involves an internal software team and a vendor providing sensors. The vendor's account manager says the internal team keeps changing the integration requirements, which causes rework. The internal product owner says the vendor's documentation is inaccurate. Both sides have started copying senior managers on emails, and a milestone is two weeks away. Neither the contract nor the team agreement defines how changes or documentation errors are handled.

Question. What should the project manager do?

Model solution.

  1. Analyse the context. The sources are unclear process and roles (no change rule, no documentation standard), and communication (emails with senior managers copied signals escalation toward a contest). Stakes: the milestone, the vendor relationship, cost of rework.
  2. Meet both parties (first separately, then together) to hear facts and interests: the vendor needs stable requirements and payment for out-of-scope work; the product owner needs accurate documentation to integrate on time.
  3. Collaborate to design the missing process: a joint change request step with an impact assessment, a documentation correction log with a response time, and a weekly integration call. Check the contract: any commercial effect goes through the procurement or change control path.
  4. Agree on conflict principles and an escalation path for the joint team (for example, unresolved after two working days goes to the product owner and the vendor manager), and ask both sides to stop copying senior managers unnecessarily.
  5. Record and communicate the agreement, inform the sponsor of the resolution and the schedule effect, and follow up at the next integration call.

Why this is best. It fixes the root cause (no agreed process), keeps the vendor relationship, and protects the milestone. Forcing the vendor by contract threats, asking the sponsor to decide immediately or ignoring the dispute would escalate or leave the cause in place.

Key terms

  • Conflict management: the process of identifying, analysing and resolving disagreements.
  • Collaborate / problem solve: working jointly to find a solution that satisfies the interests of all parties.
  • Compromise / reconcile: each party gives up something to reach a workable solution.
  • Accommodate / smooth: emphasising agreement and de-emphasising differences.
  • Force / direct: imposing one viewpoint.
  • Withdraw / avoid: postponing or retreating from the issue.
  • Ground rules / team agreement: agreed behavioural norms for the team.
  • Escalation path: the sequence of people to whom an unresolved issue is raised.
  • Interests versus positions: the underlying needs versus the stated demands.

Summary checklist

  • I can list the main sources of project conflict and tell task, process and relationship conflict apart.
  • I analyse people, stakes, stage, source and context before acting.
  • I know the five resolution approaches, and why collaboration is usually preferred.
  • I can run a structured conflict conversation and record the agreement.
  • I communicate conflict principles and the escalation path in advance.
  • I can build ground rules with the team and handle violations proportionately.
  • I know when to escalate, and that ethics breaches follow policy and the PMI Code.

Official sources