How to manage project team conflict: moving from opposing positions back to problem solving
When a project team argues about what can be delivered, return to the current agreement before asking anyone to compromise. Identify the promised outcome, the date, the available people and the evidence behind the disputed estimate. Then distinguish a question that needs investigation from a choice that needs an authorised decision. A request to “work together better” cannot create missing capacity. This approach is useful when disagreement affects an actual project commitment. It addresses the work that must change, not a person’s character. The result may be a revised scope, a different sequence or a clear refusal of an unsupported change; it need not be a midpoint between two initial demands.
Put the disputed change beside the existing commitment
Imagine a small team preparing a demonstration for an internal workshop. The agreed demonstration covers three functions. Someone now requests a fourth, while the person preparing it says the existing review time would disappear. This is an illustrative example. Before discussing attitudes, locate the current scope and the accepted workshop date. Check whether the new function was already promised or is genuinely a new request.
Record the difference in plain language: one additional function, the work it appears to require and the review activity it may affect. Do not present an unverified estimate as a fact. If two people are using different versions of the scope, settle which version is current before negotiating a solution. Otherwise they may appear to disagree about effort while actually planning different deliverables.
Ask which project condition each position protects
“Include it now” may protect a workshop objective; “leave it out” may protect a necessary review. Ask what participants must be able to see or do, and which checks remain required. A preference for a more impressive demonstration is different from a confirmed participant need. A general fear that something will take too long is different from an estimate based on identified tasks.
Harvard’s Program on Negotiation distinguishes underlying interests from stated positions and recommends using objective standards. Here, apply that principle to the project’s own agreed outcome and evidence. Do not infer someone’s motives or declare a shared goal on their behalf. Ask them to confirm whether your description represents the condition they are trying to preserve.
Separate technical uncertainty from a scope decision
If the disputed question is whether an existing component can support the extra function, agree on a limited check with a named person, a time allowance and an observable result. For example, verify the relevant component rather than building the entire proposed feature. Decide beforehand what finding would make the option feasible and what uncertainty would remain afterwards.
If everyone already knows the additional work exceeds available time, more technical discussion may not resolve anything. The choice concerns scope, timing or capacity. Likewise, a successful small check does not approve extra work automatically. It only supplies evidence for the person responsible for the project decision.
The same distinction applies when nobody has requested an addition. Suppose two teammates recommend different ways to produce an already agreed result. Compare their assumptions about the same input, operating conditions and acceptance criteria. Ask each person to identify one observation that could contradict their preferred approach. A limited comparison may reveal that one estimate omitted a dependency or used a different condition. Record what was checked and what remains unknown; do not choose an approach merely because its advocate is more senior.
Compare consequences across the project
Consider options that are actually available: keep the original demonstration, replace one agreed function with the requested one if the owner permits it, or move the additional work to a later session. For each option, identify affected preparation, review, materials and people. An apparently small change can create work for someone outside the meeting, so ask that person before promising on their behalf.
Atlassian’s Project Trade-Off Analysis examines variables such as scope, time, cost, quality and risk, and asks which are more flexible. It also recommends revisiting priorities when new information appears. You can use those questions without adopting its full workshop format. A required check does not become optional simply because another variable is difficult to change.
Close the disagreement with an executable decision
Use the existing decision authority. Present the current commitment, verified findings, unresolved assumptions and consequences of the viable options. If the team cannot change the workshop date or allocate another person, say so. Record the selected arrangement, who will carry out each changed task and which previous instruction it replaces. Confirm that affected colleagues can work from the new arrangement.
A PON discussion of negotiating teams distinguishes disagreements about the task from personal attacks; its setting does not establish that conflict always improves projects. Keep debate focused on this commitment. After the next relevant check, see whether the chosen arrangement preserved the required outcome and whether any assumption failed. Reopen the specific decision if necessary, rather than viewing the earlier conversation as a permanent verdict on someone’s reliability.