Conflict Management in Engineering Projects: causes, negotiation and resolution

Learn how to manage conflicts in engineering projects: causes, negotiation, escalation, documentation, interfaces and decision-making.

Check it out!

Conflict management is the structured process of identifying disagreements among people, teams, companies or stakeholders, understanding their causes, assessing impacts on the project and conducting negotiation, decision-making or escalation proportionally. In engineering projects, conflicts are not merely relationship problems: they may arise from incompatible requirements, poorly defined interfaces, different priorities, technical constraints, ambiguous responsibilities, contractual interests or decisions made without the appropriate parties.

Managing conflict does not mean eliminating every disagreement. Complex projects depend on technical debate, challenging assumptions and comparing alternatives. The objective is to prevent legitimate differences from becoming delays, rework, loss of trust, informal decisions, uncontrolled changes or contractual disputes. Good management separates facts, criteria, interests, positions and authority levels while preserving decision traceability.

In Consulting Engineering, the topic is especially relevant because the consultant often works at the interface among the owner, designers, suppliers, inspection, operations and contractors. In this position, the role is not to “take sides,” but to organize evidence, clarify responsibilities, facilitate decisions and protect the project’s technical and contractual objectives.

What is conflict management

Conflict exists when two or more parties perceive incompatibility among objectives, needs, interests, interpretations, resources, criteria or execution methods. The incompatibility may be real or perceived. In either case, its effect on the project may be concrete.

A conflict may begin simply: an operations team wants to keep equipment accessible for maintenance, while layout engineering seeks to reduce occupied space. Neither party is necessarily wrong. The problem arises when the project has no mechanism to make criteria explicit, compare impacts and decide at the correct authority level.

Conflict management turns disagreement into a manageable process. Instead of reacting only after the relationship deteriorates, the team looks for early signals, records the issue, identifies the cause, defines who should participate, selects the approach and monitors closure.

Why conflicts are common in engineering projects

Engineering projects combine different specialties, contracts, companies, phases and objectives. Each group sees the project through its own logic.

The design team tends to protect technical performance and solution consistency. Procurement focuses on schedule, commercial conditions and availability. Construction looks at constructability, productivity and sequence. Operations prioritizes continuity, safety and maintainability. The sponsor considers investment, risk and return. Suppliers defend scope boundaries and contractual conditions. Inspection needs to demonstrate compliance and acceptance.

The greater the number of interfaces, the greater the probability of disagreement. This does not mean multidisciplinary projects are poorly managed. It means they need governance compatible with their complexity.

Conflicts frequently arise around:

• scope and responsibility boundaries;
• interpretation of requirements and specifications;
• acceptance criteria;
• schedule and cost priorities;
• resource availability;
• design changes;
• interfaces among disciplines;
• access to areas and operating windows;
• responsibilities for supply, installation and testing;
• documentation quality;
• delays and cross-impacts;
• payments, measurements and deliverables;
• risks transferred between parties;
• decisions without records or outside the proper authority level.

Technical, organizational and contractual conflicts are not the same

Correctly classifying the nature of the conflict helps avoid using the wrong tool.

Type	Typical origin	Example	Main treatment
Technical	different criteria, requirements or solutions	two protection concepts based on different assumptions	technical analysis and criteria-based decision
Interface	poorly defined boundaries	civil infrastructure incompatible with electromechanical equipment	interface coordination and definition of responsibility
Organizational	priorities, resources or authority levels	operations does not release the window planned by the project	governance, negotiation and executive decision
Relational	trust, communication or behavior	parties stop sharing information	mediation, alignment and rebuilding commitment
Contractual	interpretation of obligation, schedule or scope	supplier considers a test outside its contracted scope	contract analysis, evidence and formal mechanism
Commercial	price, condition or economic consequence	cost impact of a change	commercial negotiation within governance

Mixing these categories makes the situation worse. A technical conflict should not be resolved through hierarchical pressure before the criteria are compared. A contractual disagreement does not disappear because teams have a good relationship. And a trust problem is unlikely to be solved only with a responsibility matrix.

What are the main causes of conflict in projects

Incomplete or contradictory requirements

When requirements are unclear, different teams develop their own interpretations. Conflict appears later during review, manufacturing, installation or acceptance.

Prevention begins with requirements management, using verifiable criteria, defined owners and change traceability.

Poorly defined interfaces

Interfaces are one of the largest sources of conflict in engineering. One package depends on data, infrastructure or decisions belonging to another package. If the boundary is not explicit, each party may assume that the obligation belongs to the other.

Interface management reduces this risk by defining contact points, deliverables, responsibilities, ICDs and resolution mechanisms.

Unclear authority levels

Conflicts drag on when nobody knows who can decide. The discussion continues among people who have opinions but lack the authority to close the issue.

Different incentives

The owner, supplier and contractor may have legitimate but different objectives. The owner seeks performance and adherence to scope. The contractor needs to protect productivity and margin. The supplier wants to limit exposure beyond contracted conditions. Without governance, these differences can become disputes.

Information asymmetry

One party may hold technical, historical or contractual knowledge that others do not have. If the information does not circulate at the appropriate time, decisions may appear arbitrary or incomprehensible.

Schedule pressure

Delay reduces tolerance for debate and increases improvised decisions. Paradoxically, trying to “save time” by skipping analysis and documentation often creates more rework.

How to identify a conflict before it escalates

Conflicts rarely begin with a formal dispute. They usually show smaller warning signs:

• decisions repeatedly reopened;
• increasingly defensive responses;
• more people copied on emails;
• meetings without closure;
• approval delays without clear justification;
• recurring statements such as “this is not in our scope”;
• open items that repeatedly change owners;
• documentation submitted without prior alignment;
• requirements discussed only after execution;
• technical issues quickly turned into contractual claims;
• parallel communication outside the defined channels.

These signs should be treated as management information. Waiting until the conflict becomes formal increases the cost of resolution.

The difference between position and interest

One of the most useful negotiation techniques is to separate position from interest.

A position is what a party says it wants. An interest is the reason that makes that position relevant.

Imagine operations says: “the intervention can only happen on Sunday.” That is the position. The underlying interest may be avoiding production impact, ensuring a contingency team is available or preserving a safety window. If the team debates only Sunday versus Saturday, the solution space is narrow. If it understands the interest, it can create equivalent alternatives.

The same applies to contractual conflicts. “This is not in the scope” is a position. The interest may be avoiding unplanned cost, preserving responsibility or preventing a precedent. The solution may involve a formal change, compensation, redistribution of scope or evidence that the obligation was already included.

How to choose a conflict resolution strategy

There is no single correct way to handle every conflict. The strategy depends on urgency, impact, importance of the relationship, quality of evidence and authority of the parties.

Collaborate

Collaboration seeks a solution that addresses the main interests of the parties. It is appropriate for complex decisions, critical interfaces and issues where solution quality matters more than speed.

Negotiate or seek compromise

Compromise is useful when each party can make partial concessions and a practical solution is needed within a limited timeframe. It should be used carefully with mandatory requirements: legal compliance or essential technical criteria cannot be “negotiated” without a formal basis.

Accommodate

One party accepts the other’s position because the issue has low relative importance or because preserving the relationship matters more at that moment. Conscious accommodation is different from omission.

Avoid temporarily

Postponing the discussion may be appropriate when data is missing, tension is high or another decision must occur first. Permanently avoiding a relevant conflict merely transfers the problem to a more expensive phase.

Compete or decide by authority

There are situations in which safety, compliance, emergency or formal authority requires a rapid decision. Authority can close the discussion, but the basis, consequences and actions should still be documented.

When to negotiate and when to escalate

Escalation should not be the first reflex, but neither can it be avoided indefinitely.

Negotiate at the current authority level when:

• the parties have authority to close the issue;
• the criteria are clear;
• there is genuine room for a solution;
• the impact is controllable;
• the schedule allows sufficient analysis.

Escalate when:

• the decision exceeds the parties’ authority;
• there is a conflict among strategic objectives;
• there is a significant impact on cost, schedule, safety or compliance;
• the contract requires a decision at a higher level;
• previous attempts did not achieve closure;
• there is a risk of stoppage or significant harm.

Escalating correctly means bringing facts, options, impacts and a recommendation, not simply transferring the problem.

How to prepare a technical negotiation

A technical negotiation should begin before the meeting.

Define the problem in neutral language

Avoid framing the issue as blame. “The contractor failed to comply” already assumes a conclusion. It is more useful to record: “deliverable X was received without document Y required by item Z; treatment and the impact on acceptance must be decided.”

Separate facts from interpretations

Facts are verifiable evidence: dates, documents, requirements, measurements and records. Interpretations are readings about cause, responsibility or intent.

Define criteria

Criteria may include technical requirements, contract, standard, risk, schedule, cost, safety, operability, maintainability and impact on third parties.

Prepare alternatives

Negotiation without alternatives becomes a dispute between two positions. The earlier the team develops viable options, the greater the likelihood of resolution.

Confirm authority

Participants need to know who can recommend, negotiate and decide.

Communication and conflict management

Communication failure is rarely just a “lack of email.” It may involve missing context, the wrong recipient, inappropriate language, delay, excessive information or no feedback.

The project communication plan should define how critical issues are escalated, the expected response time, who receives the decision and where evidence is recorded.

During a conflict, prefer channels that enable understanding and closure. Complex topics may require a meeting or workshop, but the final decision needs to be recorded in the appropriate formal channel.

The role of stakeholders in conflict

Not every conflict involves only the two most visible parties. People with influence, authority or impact may need to participate in the solution.

Stakeholder mapping helps identify who has information, who will be affected and who can decide. The stakeholder matrix helps define priority and engagement strategy.

Bringing too many people, however, is also a mistake. The meeting should include the perspectives needed, not turn every disagreement into an expanded committee.

How to handle conflicts among engineering disciplines

Multidisciplinary conflicts are frequent because a local decision can have a global impact.

A conduit can interfere with a structure. A panel can make maintenance access impossible. A network architecture can change power and cooling requirements. An electrical protection scheme may depend on process data that has not yet been consolidated.

Effective treatment follows a logical sequence:

1. identify the exact interface;
2. document each discipline’s requirements;
3. distinguish mandatory requirements from preferences;
4. compare alternatives and impacts;
5. define the decision authority;
6. update design, requirements and records after the decision.

The decision should not exist only in meeting minutes. It needs to be reflected in controlled documents.

How to handle conflicts with suppliers and contractors

Contractual relationships require a balance between collaboration and formality.

The team may work technically with the supplier to resolve an incompatibility, but it should not create an informal commercial obligation. Changes in scope, schedule or price need to follow the contractual mechanism provided.

Good practices include:

• use the channels defined in the contract;
• preserve records of submissions and responses;
• distinguish technical guidance from contractual authorization;
• avoid tacit acceptance of a solution outside the requirement;
• record impacts before implementing a relevant change;
• define response and escalation deadlines;
• close open items before irreversible stages.

How to handle conflicts between the owner and inspection

Inspection and contract management need to maintain technical independence without losing coordination with the owner. A common mistake is turning an inspector’s opinion into a new requirement without documentary basis or, at the other extreme, ignoring a relevant warning because it was not literally described in the design.

The solution requires tracing the origin of the requirement, assessing its need, checking authority and formalizing any change.

In complex projects, Owner’s Engineering helps structure this interface with independent technical analysis and decision governance.

Schedule and priority conflicts

When several work fronts compete for the same resource or operating window, the conflict should not be resolved by whoever “shouts the loudest.” Criticality, dependencies, impact, risk and the critical path must be compared.

The decision should answer:

• which activity constrains other deliverables;
• which delay produces the greatest accumulated impact;
• what risks arise from each alternative;
• which resources can be redistributed;
• who has authority to set priorities.

Scope conflicts

Scope conflicts often arise when boundaries are unclear or when a need emerges after contracting.

The central question is: was the obligation already part of the contracted scope or is it a change?

Answering requires comparing the contract, terms of reference, specifications, drawings, minutes, proposal, responsibility matrix and clarification history. If it is a change, it should follow formal control. If it was already an obligation, the discussion shifts to evidence and compliance.

Quality and acceptance conflicts

During inspection and acceptance, pressure to close the project increases. It is common for the contractor to consider physical installation as completion while the owner requires documentation, tests, corrections and evidence.

The conflict is reduced when acceptance criteria are defined before delivery. Requirements management, the inspection plan, commissioning and final documentation should converge toward verifiable criteria.

How to record conflicts and decisions

Not every disagreement needs to become a specific formal document. But conflicts affecting scope, schedule, cost, quality, risk, safety or critical relationships need to be traceable.

The record may exist in an issue log, meeting minutes, RFI, change log, risk register or contract management system, depending on the nature of the issue.

Useful fields include:

Field	Purpose
issue	describe the disagreement without judgment
parties	identify those involved and affected
evidence	documents, data and records
impact	schedule, cost, risk, quality, safety
probable cause	guide treatment
authority level	indicate who can decide
alternatives	options analyzed
decision	approved solution
owner	execute the action
deadline	closure date
closure evidence	demonstrate implementation

How to measure the effectiveness of conflict management

The number of conflicts alone is not an indicator of poor management. Transparent projects may record more disagreements precisely because they do not hide problems.

Better indicators include:

• average time to close critical issues;
• percentage of reopened conflicts;
• decisions made at the correct authority level;
• rework caused by late decisions;
• changes generated by unaligned requirements;
• number of avoidable escalations;
• completion of actions arising from agreements;
• recurrence of the same root cause;
• cumulative impact of conflicts on schedule and cost.

Common mistakes in conflict management

Personalizing the disagreement

Turning a technical problem into a judgment about people destroys objectivity.

Escalating too early

Taking every disagreement to the sponsor reduces team autonomy and congests governance.

Escalating too late

Keeping a conflict outside the correct authority level can consume weeks with no real chance of resolution.

Negotiating a mandatory requirement

Safety, compliance and legal obligations cannot be relativized merely to reach consensus.

Deciding without updating documents

A verbal agreement without revision of the controlled document creates a new source of conflict.

Confusing silence with agreement

Lack of response does not represent approval unless the formal process explicitly provides for that effect.

Using email as a substitute for negotiation

Long message chains increase noise and make interpretation more difficult.

Checklist for handling a project conflict

Before considering the issue properly addressed, confirm:

• the problem is described objectively;
• facts and interpretations have been separated;
• the nature of the conflict has been classified;
• the parties actually required have been identified;
• interests and positions have been distinguished;
• decision criteria are clear;
• applicable documents have been checked;
• comparable alternatives exist;
• decision authority has been confirmed;
• schedule, cost and risk impacts have been assessed;
• the decision has been recorded;
• actions, owners and deadlines have been defined;
• controlled documents will be updated;
• closure will be verified.

Conflict management and Consulting Engineering

In projects with many disciplines, contracts and interfaces, conflict is often a symptom of a systemic failure: an ambiguous requirement, inadequate governance, poorly distributed responsibility, an uncontrolled change or information that did not reach the right person.

Consulting Engineering adds value when it treats disagreement within the project management system. The work may involve independent analysis, preparation of alternatives, technical facilitation, requirements review, interface coordination, support to inspection, change management and decision structuring.

Engineering Project Management organizes these governance and integration mechanisms, especially when the owner needs to coordinate several suppliers and disciplines without losing control of scope, schedule, risk and acceptance.

Final considerations

Conflicts are part of complex projects. The problem is not the existence of disagreement, but the inability to turn it into a traceable decision. Mature management identifies signals early, classifies the nature of the conflict, brings together the right parties, separates positions from interests, uses verifiable criteria and escalates only when necessary.

In engineering, resolving a conflict means more than reaching an agreement. The solution needs to be technically valid, compatible with the contract, implementable, documented and reflected in project documents. When this happens, disagreement stops being a source of friction and becomes a mechanism for improving decisions.

Technical references

[1] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Newtown Square: PMI. Available at: https://www.pmi.org/standards/pmbok

[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Geneva: ISO, 2020. Available at: https://www.iso.org/standard/74947.html

[3] THOMAS, Kenneth W.; KILMANN, Ralph H. Thomas-Kilmann Conflict Mode Instrument — TKI. Available at: https://kilmanndiagnostics.com/overview-thomas-kilmann-conflict-mode-instrument-tki/

Frequently asked questions

What is conflict management?

It is the process of identifying disagreements, understanding causes and interests, assessing impacts and conducting negotiation, decision-making or escalation in a structured way. In projects, it should preserve technical criteria, authority levels, records and responsibilities.

What are the main causes of conflict in projects?

Common causes include ambiguous requirements, poorly defined interfaces, unclear responsibilities, competing priorities, schedule pressure, information asymmetry, scope changes and different contractual interpretations.

What is the difference between technical and contractual conflict?

Technical conflict arises from engineering criteria, requirements or solutions; contractual conflict involves interpretation of obligations, scope, schedule or commercial conditions. One can generate the other, but the treatment mechanisms are not the same.

When should a conflict be escalated?

When the decision exceeds the parties’ authority, there is a significant impact on schedule, cost, safety or compliance, the contract requires a higher-level decision, or attempts to resolve it at the current level have not achieved closure.

Are negotiation and conflict management the same thing?

No. Negotiation is one of the tools used in conflict management. Management includes identification, diagnosis, strategy selection, definition of authority, negotiation, escalation, decision, documentation and follow-up.

How can conflicts be prevented from causing rework?

By defining requirements and interfaces early, documenting decisions, controlling changes, involving the appropriate stakeholders and updating project documents after each relevant decision.

Is conflict always negative in projects?

No. Well-managed technical disagreement can reveal risks, challenge assumptions and improve decisions. The problem arises when conflict is not managed, becomes personal or produces informal decisions and delays.

What is the role of Consulting Engineering in conflict management?

Consulting Engineering can organize evidence, independently analyze alternatives, coordinate interfaces, facilitate decisions and support the owner and inspection with technical independence and traceability.

Complementary technical materials

Main content on the topic

• Stakeholder Management in Projects
• Stakeholder Mapping
• Project Communication Plan
• Stakeholder Matrix

Related technical content

• Interface Management in Engineering Projects
• Requirements Management in Engineering
• RACI Matrix in Engineering Projects

Related solutions

• Contract, Scope and Deliverables Management
• Punch Items, RFIs and Nonconformity Management

Related services

• Engineering Project Management
• Owner’s Engineering