Managing Team Conflict and Performance

Managing team conflict and performance is the systematic process a project manager uses to identify interpersonal disagreements, address their root causes, and then help team members work together more effectively while also tracking and improving individual and group productivity. The PMP exam treats this as a core skill because research shows that unresolved conflict is one of the top three causes of project failure.

When two team members disagree about a technical approach, that is a conflict. But not all conflict is bad. Constructive conflict — where people argue about ideas, not personalities — can lead to better solutions. Destructive conflict — personal attacks, blame, or refusal to collaborate — damages trust and slows delivery. Your job as a project manager is to distinguish between the two and act accordingly.

The PMBOK guide (the Project Management Institute's official book of best practices) outlines five common conflict-resolution techniques. You need to memorise these for the exam:

The exam expects you to choose "collaborating" or "problem-solving" as the preferred technique whenever the question describes a situation where the conflict is substantive (about the work) and there is time to discuss it.

Performance management is the second half of this objective. It means setting clear expectations, monitoring work quality and speed, giving regular feedback, and taking corrective action when someone underperforms. The exam uses a model called the "Tuckman ladder" — Forming, Storming, Norming, Performing, and Adjourning — to describe how teams develop. Conflict peaks during the "Storming" phase, and your job is to help the team move into "Norming" (where ground rules are accepted) and then "Performing" (where the team runs on its own).

A key tool for performance is the "team charter" — a document the team creates together at the start of a project. It lists ground rules for communication, decision-making, meeting etiquette, and how to handle disagreements. When you have a team charter, you can refer back to it during a conflict instead of making up rules on the spot.

For continuous improvement, the exam introduces "lessons learned" — formal sessions at the end of each project phase (or at the end of the project) where the team discusses what went well, what went wrong, and what should change next time. You also use "retrospectives" (common in agile frameworks) which are shorter, held more frequently, and focus on small process adjustments.

The mistake beginners make is thinking the project manager must solve every conflict personally. In reality, you act as a facilitator: you bring the parties together, ensure everyone speaks, and help them find their own resolution. Only escalate to a sponsor or senior manager if the conflict involves ethical violations or is blocking critical decisions.

An IT project manager named Priya is leading a team building a customer portal for a bank. During a sprint review, a developer named Raj says the front-end designer, Lena, keeps adding features that weren't approved. Lena says Raj is too rigid and is ignoring user feedback. The team is stuck.

Priya does not take sides. She schedules a thirty-minute meeting with just Raj and Lena, using the "collaborating" technique. First, she asks each person to describe the problem from their perspective while the other listens without interrupting. Raj says he is worried about the sprint deadline because each unapproved feature takes two extra days to integrate. Lena says the design team's user-testing report recommended those changes.

Priya then asks them to restate each other's concerns to confirm understanding. She says, "Raj, can you tell Lena what you heard her say?" After that, she asks, "What is the underlying need for each of you?" Raj needs to hit the deadline; Lena needs the product to meet user-testing thresholds. Priya helps them brainstorm a compromise: they will merge only two of the four unapproved features into this sprint, and the other two will go into the next sprint after formal approval from the product owner. Both agree.

Priya also uses this moment to improve future performance. She updates the team's working agreement: all feature requests must go through the product owner before any code changes are made. In the next retrospective, the team discusses this process and decides to add a daily fifteen-minute "design sync" so developers and designers can flag conflicts early.

Priya tracks individual performance using velocity — a measure of how many story points the team completes per sprint. She notices that one junior developer, Mei, has consistently low output. Instead of assuming laziness, she has a private chat and discovers that Mei is spending three hours a day fixing merge conflicts because she does not understand the branch strategy. Priya pairs Mei with a senior developer for two days to learn the workflow. After that, Mei's velocity doubles.

At the end of the project, Priya runs a lessons-learned session. The team writes down that the design sync should become permanent, that the working agreement should include a clear escalation path for unapproved features, and that Mei's mentoring model should be repeated for future new hires. These notes go into the organisation's project repository for the next team to reference.