Conflict Is Not Always a Problem


Harmonious projects get praised, and some of them deserve it. Others are harmonious because the disagreements are happening in the car park, in one-to-ones, and in the private judgement of people who have decided it is not worth saying anything. The work still gets built, and what it gets built on is a set of decisions nobody tested.

The useful reframe is that disagreement on a project is usually information arriving. Two competent people reaching different conclusions from the same situation means something in the situation is genuinely unresolved, and finding out what is far cheaper than discovering it later at full scale. The PMBOK® Guide Eighth Edition keeps conflict inside the resource work at Section 2.6, alongside capacity and team development, which reflects where it actually appears: among people doing real work under constraints that do not all point the same way.

Two kinds, and only one of them helps

Task conflict is disagreement about the work: what to build, how to sequence it, whether a risk is real, which standard applies. It improves decisions when it is handled openly, because it forces the reasoning into view and gives everybody a chance to notice the weak part. Teams that never have it are not aligned; they are deferring to whoever spoke first.

Relationship conflict is disagreement about the people: who is difficult, who is not pulling their weight, whose fault the last thing was. It rarely improves anything, it consumes enormous amounts of attention, and it converts task disagreement into something unsafe, because once a dispute is personal, nobody can concede a point without losing standing. Most of a project manager's conflict work is keeping the first kind from turning into the second.

What silence costs

Decisions go untested. An objection not raised is an analysis not done, and the project proceeds with a gap in its reasoning that nobody has measured. This is the cost that never appears in a report, because a decision that was never challenged looks identical on paper to one that survived a challenge.

The disagreement arrives later, physically. Unraised objections do not disappear; they are held by people who continue to believe them, and they surface at implementation as resistance, workarounds, or something that does not fit. The person who knew tends to be the person operating the result, and they knew in March.

People stop bringing evidence. Where a team learns that raising a concern produces friction and no change, it stops raising concerns, and the loss is not the objections. It is everything else those people would have said: the observation about the supplier, the doubt about the data, the small thing that looked odd on Tuesday.

A pick station and a trolley that would not pass

An online retailer was refitting the picking mezzanine at one of its fulfilment centres, installing new pick stations across four sites. The design had been through a review with operations, engineering and the project team, and it had been approved without significant debate.

One person had a concern. An operations supervisor at the pilot site had looked at the layout and thought the gap between the new station and the mezzanine rail was too tight for a loaded trolley, because the trolleys had been changed the previous year and the drawing showed the old ones. She raised it once, briefly, in a meeting where the design lead had just explained the clearance calculation, and she did not raise it again. She was not certain, the room had moved on, and she was the most junior person in it.

The first station went in and the trolleys did not pass. Not by much: about seventy millimetres, which is the kind of number that stops a trolley completely. Picking on that aisle ran at roughly half rate for nine days while the stations were unbolted and reset, and the fix cost more than the original installation of the four stations that had not yet been built.

The recovery was straightforward once it was visible. What changed permanently was the review itself. Every design review afterwards ended with the same question, asked of the people who would operate the thing and answered one at a time: what will go wrong with this that we have not discussed? At the third site that question produced an objection about a cable route that would have failed in the same way, and it cost four minutes.

Making disagreement usable

Ask for the strongest case against. Putting the question directly, to a named person, converts dissent from an act of courage into a task somebody has been asked to do. It also removes the implication that objecting means being unhelpful, which is what keeps most people quiet.

Name what each party is defending. Behind most task conflict sits a constraint somebody is protecting: a safety standard, an operational rate, a budget line, a regulatory position. When both constraints are on the table, the argument stops being about who is right and starts being about which constraint gives, which is usually somebody else's decision and is at least a decidable question.

Give it a boundary. Disagreement is useful up to the point where it becomes rumination, and a team that knows the discussion has until Thursday and then goes to a decision will use the time well. Open-ended debate exhausts people and teaches them that raising things creates meetings.

Record the dissent when you decide against it. Writing down that a named person disagreed, and why, costs a line and does two things: it lets the project revisit the point quickly when new information arrives, and it tells the person their analysis was heard. That second effect is what keeps them bringing the next one.

For a PMP® candidate, the thing to carry is that disagreement about the work is a signal worth surfacing, so a situation describing a silent or unusually agreeable team is worth treating with suspicion rather than satisfaction. A response that smooths a task disagreement away has removed information from the project. Situations where the harmony is the problem are among the ones a structured PMP exam preparation course takes seriously.

The test is uncomfortable and quick. Think of the last significant design or approach decision your project made, and name the person who argued against it. If there was nobody, the decision was not examined, and the cheapest moment to examine it is before anything has been built to it.

By Andre Malowney

Interested in going further?

Knowing which disagreements to encourage, and which to stop before they become personal, is one of the more demanding judgements a project manager makes. Omega's PMP® Exam Preparation works through team situations where the right move is to open the argument rather than close it.

Conflict, capacity and team development are treated together in the PMBOK® Guide Eighth Edition.