如何管理專案團隊衝突：從立場對立回到問題解決
團隊為專案交付內容爭論時，先核對目前承諾的成果、日期、可用人力及估算依據，再討論讓步。接著分清楚：眼前需要的是查證，還是由有權限的人作選擇。要求大家更合作，不會自動補上不足的時間或人手。 這個做法用於影響實際專案承諾的分歧，關注需要改變的工作，不評斷個人性格。結果可以是調整範疇、改變順序，或不接受缺乏依據的要求，未必是兩個原始主張的折衷。
把新增要求與原先約定放在一起
假設小團隊準備內部工作坊的示範，原本約定展示三項功能，現在有人要求再加一項，製作人員認為會擠掉必要的檢查時間。這是說明方法的虛構情境。先找到目前確認的範疇與日期，核對第四項功能是早已承諾，還是新提出的要求。
具體寫出差異，包括新增動作、預估工作量及受影響檢查。還沒核實的時間應標明是估算。若雙方參照不同版本的範疇，先確認現行版本；表面上的速度爭論，可能源自兩人以為要交付不同成果。
確認各自要保留的專案條件
主張立即增加的人，可能重視工作坊要讓參與者學會什麼；不贊成的人，可能要保留必要檢查。問清楚參與者必須看到或做到什麼，以及哪些檢查仍然必須完成。讓展示更豐富的偏好，不等於已確認的使用需要；擔心來不及，也不等於已拆解工作後的估算。
Harvard Program on Negotiation 區分立場與背後利益，並建議採用客觀標準。在這裡應使用專案自己的確認成果與證據，不替別人猜動機。請對方確認，你對其條件的描述是否正確，不要單方面宣布已經有共同目標。
區分技術查證與範疇決定
若問題是現有元件能否支援新增功能，就安排一次有限查證，說明誰負責、可用時間及應觀察結果。先確認相關元件，而不是直接完成整個新增功能。開始前約定什麼發現才支持可行，以及查完之後仍有哪些未知。
若大家已知道新增工作超過可用時間，繼續技術討論未必能解決，需要的是範疇、時程或資源選擇。反過來說，小型查證成功也不代表功能已獲核准。它只提供決策資訊，不能替代授權，也不能假設其他準備與檢查時間已經足夠。
沒有新增需求時，也可能出現這種分歧。假設兩位同事對已約定成果提出不同實作路徑，先用相同輸入、運作條件與驗收標準對照各自假設，並請雙方說出什麼觀察會推翻自己支持的方案。有限比較可能發現，一方估算漏了前置工作，或兩人採用不同條件。記錄已查證部分與剩餘未知，再決定下一步，不把較高職級當成方案可行的證據。
檢查每個選項對其他交付的影響
比較真正可以採取的做法：保留原示範；經負責人同意，用新功能替換原有一項；或留到後續場次。逐項記錄會影響的準備、檢查、材料與人員。若需要會議外的同事投入，先確認其可用時間，不替對方承諾。
Atlassian 的 Project Trade-Off Analysis 討論範疇、時間、成本、品質與風險的調整空間，並要求在新資訊出現時重看優先順序。可以使用這些問題，不必完整搬入一場工作坊。必要檢查不會因為日期難以更動，就變成可以省略的工作。
以可執行的決定結束這次分歧
依既有權責提交原約定、已證實發現、未定假設及選項後果。無權調日期或增加人手，就清楚說明。決定後寫下採用安排、負責執行各項變更的人，以及被取代的舊指示，讓受影響者確認如何開始下一步。
PON 的談判團隊討論區分任務分歧與針對個人的攻擊，不能由此保證衝突會改善專案成果。維持討論聚焦此次承諾。到相關檢查點，再看結果是否達到需要、哪些假設不成立；必要時重開具體決定，不把前次爭論變成對同事的永久評價。