RACI Matrix in Engineering Projects: how to define responsibilities and prevent communication failures

Learn how to use the RACI matrix in engineering projects to define responsible parties, accountable decision-makers, consulted and informed stakeholders, reducing conflicts and communication failures.

Check it out!

In engineering projects, many failures do not occur because of a lack of technical capability, but because responsibilities are unclear. Who executes? Who approves? Who needs to be consulted before a decision? Who only needs to be informed? When these answers are unclear, delays, rework, contradictory decisions, supplier conflicts and difficulties with technical acceptance emerge.

The RACI matrix is a simple and highly useful tool for organizing responsibilities in projects, contracts, construction works, consulting services, commissioning, due diligence, procurement, design coordination and Owner’s Engineering.

In engineering, the RACI matrix helps transform diffuse roles into an objective governance structure. It defines who is responsible for performing an activity, who is accountable for the decision, who needs to be consulted and who must be informed.

When properly applied, the RACI matrix reduces ambiguity, improves communication, supports decision-making and helps the owner control critical interfaces.

What is a RACI matrix?

A RACI matrix is a responsibility assignment tool. The acronym RACI comes from four roles:

Letter	Term	Function
R	Responsible	The person or team that performs the activity or delivers the result
A	Accountable	The person accountable for the decision, approval or final result
C	Consulted	Those who must be consulted before the decision or execution
I	Informed	Those who must be informed about progress, a decision or a result

The most important point is to distinguish who performs the work from who approves or is accountable for it. In many engineering projects, this distinction prevents significant conflicts.

Why use a RACI matrix in engineering projects?

Engineering projects involve multiple parties: owner, designers, consultants, integrators, suppliers, operations, maintenance, procurement, legal, inspection, commissioning and, in some cases, Owner’s Engineering. Without a clear structure, responsibilities can overlap or remain uncovered.

Without a RACI matrix	With a RACI matrix
Ambiguous responsibilities	Roles defined by activity
Decisions without clear ownership	Person accountable for approval identified
Consultations occur too late	Consulted parties defined in advance
Excessive or insufficient communication	Informed parties objectively defined
Conflicts between departments and suppliers	Interfaces better controlled
Delays caused by unclear ownership	Clearer decision flow

In practice, a RACI matrix works as a responsibility map. It does not replace the contract, scope, schedule or risk matrix, but complements these instruments.

RACI is a governance mechanism, not just a spreadsheet

A mature RACI matrix does not begin with the question “which letter should we assign to each person?” It begins with governance: what decisions exist, who has authority to make them, which deliverables need an owner, what knowledge must be brought in before a decision, and which parties need information to fulfill their own obligations.

The PMBOK® Guide — Eighth Edition, available in A3A’s technical collection, treats governance as the structure that organizes project systems, processes, roles, responsibilities and decision models. In this context, the publication presents RACI as an example of a governance mechanism. This matters because it moves the tool from the realm of a “task spreadsheet” into the realm of accountability, authority and coordination.

In an engineering project, the same deliverable can cross several levels. A designer produces it, a coordinator checks it, the Owner’s Engineer analyzes it, operations validates a requirement, and the owner decides whether to accept a given result. If RACI treats all of this as one generic activity, it hides exactly the boundaries it should clarify.

Therefore, the matrix must be consistent with the contract, organizational structure, authority matrix, interface management, communication plan and change workflows. When these instruments point to different accountable parties, there is a governance inconsistency that must be resolved—not merely a spreadsheet cell to be corrected.

What ABNT NBR ISO 21502 adds to the logic of responsibilities

ABNT NBR ISO 21502:2021, consulted in the A3A Knowledge Base, does not prescribe a mandatory RACI matrix, but establishes the basis that justifies its use. The standard advises the temporary project organization to define roles, responsibilities and authorities, maintain clear reporting lines and communicate them to everyone involved.

The standard also requires responsibilities to be sufficiently clear so that each person understands not only their own role but also the roles of those they work with. In multidisciplinary engineering, this is especially important: designer, supplier, inspection, operations and owner must understand the boundaries among producing, checking, recommending, authorizing and accepting.

Another central point is the limit of authority. ISO 21502 distinguishes the responsibilities of the sponsor, project manager, work-package leaders, team and support structures such as the PMO. It also provides for escalation when risks, issues or changes exceed delegated authority. Therefore, marking someone as A without checking whether that role can actually make the decision contradicts the governance logic itself.

Traceability also matters. A responsibility shown in the RACI must be compatible with the contract, management plan, approval procedures and authority-delegation documents. One “truth in the matrix” and another “truth in the contract” creates exposure precisely at the most critical moments: scope changes, claims, design approval, energization, commissioning and acceptance.

Role, function, person and organization are not the same thing

A RACI should preferably work with roles or functions, not only individual names. People can be replaced; institutional responsibility must remain. Columns such as “Project Manager”, “Electrical Coordination”, “Owner’s Engineer”, “Operations”, “System Supplier” and “Inspection” tend to be more robust than personal names.

It is also important to maintain consistency of level. Mixing a company, a person, a discipline and a department in the same matrix without a clear criterion can create ambiguity. Larger projects may have a contractual layer by organization and an operational layer by function. The goal is not to create the most detailed matrix possible, but the level of detail required to eliminate uncertainty about responsibility and decision-making.

Difference between Responsible and Accountable

The greatest difficulty in using a RACI matrix is often the distinction between Responsible and Accountable.

The Responsible role performs the activity. More than one person or team may be responsible for execution, although too many responsible parties should be avoided so that accountability for the work is not diluted.

The Accountable role is accountable for approval or for the final result. As a general rule, there should be only one accountable role per activity. When there are too many final approvers, decisions become slow, conflict-prone or ownerless.

Role	Question it answers	Engineering example
Responsible	Who does it?	Designer prepares the technical drawing
Accountable	Who approves or is accountable for the result?	Technical coordinator approves the deliverable
Consulted	Who needs to provide input beforehand?	Operations validates a maintenance requirement
Informed	Who needs to know afterward?	Contract management receives the update

Example of a RACI matrix in engineering projects

A RACI matrix normally crosses activities with roles, teams or stakeholders. The example below shows a simplified application in a technical project.

Activity	Owner	Technical Consultant	Designer	Supplier	Operations
Define technical requirements	A	R	C	I	C
Develop basic design	A	R	C	I	C
Evaluate technical proposal	A	R	C	C	I
Perform installation	I	C	C	R	I
Witness tests	A	R	C	R	C
Validate technical acceptance	A	R	C	C	C
Receive final documentation	A	R	C	R	I

This model must be adapted to the contract, project size and criticality of the deliverable. In larger projects, the matrix can be detailed by discipline, work package, phase or deliverable.

When should a RACI matrix be created?

The RACI matrix should be created before critical activities begin. The best time is usually during planning, scope structuring, basic design development, contracting or project mobilization.

It is especially useful when there are:

• multiple suppliers or disciplines;
• interfaces among design, construction, operations and maintenance;
• an owner with several departments involved;
• a complex technical approval process;
• consulting engineering or Owner’s Engineering services;
• commissioning and technical acceptance;
• technical due diligence or audits;
• risk of conflict among scope, contract and operations.

How to build a RACI matrix step by step

An effective RACI matrix depends on a clear scope and a good understanding of the parties involved.

1. List the activities or deliverables

Start with the project’s relevant activities. In engineering, it can be more useful to work by deliverable: basic design, requirements matrix, technical proposal, design review, due diligence report, test plan, commissioning, final documentation and technical acceptance.

2. List the roles involved

Include departments, teams or functions, not necessarily individual names. Examples: owner, technical consultant, designer, integrator, supplier, operations, maintenance, procurement, legal, inspection and Owner’s Engineering.

3. Assign R, A, C and I

For each activity, define who executes, who approves, who must be consulted and who must be informed. Avoid too many Responsible roles and try to maintain only one Accountable per row.

4. Review conflicts and gaps

Check for activities without a Responsible, without an Accountable, with too many Accountable roles or with critical parties missing. These points indicate governance risk.

5. Validate with stakeholders

The RACI matrix only works if the parties involved recognize the defined roles. It should be validated with affected departments before execution. Stakeholder analysis helps identify who needs to participate in this validation and over which decisions they have influence, impact or legitimacy.

6. Update it when the project changes

Projects change. If scope, suppliers, phases or responsibilities change, the RACI matrix must also be reviewed.

Practical rules for a good RACI matrix

Rule	Why it matters
Have at least one Responsible per activity	Prevents an activity from having no executor
Have only one Accountable per activity	Prevents decisions without clear ownership
Avoid too many Consulted roles	Reduces delays in the decision flow
Define Informed roles deliberately	Prevents excessive or insufficient communication
Review activities without R or A	Indicates a responsibility gap
Review activities with too many R roles	May indicate diluted responsibility
Align the matrix with the contract	Prevents conflict between governance and contractual obligations
Update after scope changes	Keeps the matrix useful throughout the project

RACI matrix in Consulting Engineering

In consulting engineering, the RACI matrix is useful because it organizes the relationship among the owner, consultant, designers, suppliers and operations.

It helps define who analyzes, who recommends, who approves, who executes and who needs to be informed. This is important because the technical consultant usually supports the decision but is not always the final approval authority.

For example, in a technical proposal analysis, the consultant may be responsible for the technical evaluation while the owner is accountable for the contracting decision. Procurement and legal may be consulted, while operations may be informed or consulted depending on the impact.

This use is directly connected to the role of Consulting Engineering in supporting the owner’s technical decisions.

RACI matrix in Owner’s Engineering

In Owner’s Engineering, the RACI matrix is especially important because the Owner’s Engineer acts on behalf of the owner but does not replace all of the owner’s responsibilities.

The matrix helps define the boundaries among the owner, Owner’s Engineer, EPC contractor, designers, inspection, operations and suppliers.

Activity	Owner	Owner’s Engineer	EPC Contractor	Operations
Define owner requirements	A	R	C	C
Review detailed design	A	R	R	C
Monitor technical progress	I	R	R	I
Validate tests and commissioning	A	R	R	C
Recommend technical acceptance	A	R	C	C

This clarity reduces authority conflicts and improves the project’s technical governance.

RACI matrix in Technical Due Diligence

In a technical due diligence, a RACI matrix helps organize document collection, interviews, inspections, evidence analysis, validation of findings, the risk matrix and action plan.

Without clear roles, due diligence can be delayed because documents are not submitted, departments do not respond, suppliers do not provide information, or decisions remain pending.

This use is connected to the article Technical Due Diligence Report: evidence, risk matrix and action plan, because report quality depends on the quality of the information collected and on clearly identifying who is responsible for providing it.

RACI matrix in technical proposal analysis

In engineering technical proposal analysis, a RACI matrix helps define who compares scope, who evaluates price, who checks risks, who consults operations, who interacts with the supplier and who approves the final recommendation.

Stage	Engineering	Procurement	Legal	Operations	Technical Consultant
Define technical criteria	A	C	I	C	R
Request clarifications	C	A/R	I	C	R
Equalize proposals	A	C	I	C	R
Assess contractual risks	C	R	A	I	C
Issue technical recommendation	A	I	I	C	R

This organization prevents the contracting decision from becoming fragmented across departments with no clearly defined final owner.

RACI matrix in basic design

The basic design depends on clear definitions of scope, requirements, assumptions, interfaces, acceptance criteria and responsibilities. The RACI matrix helps define who provides information, who consolidates requirements, who validates assumptions and who approves the final document.

It can also be used together with the basic design checklist, especially before tendering or contracting a construction work or technical service.

RACI matrix in commissioning and technical acceptance

In commissioning and technical acceptance, the RACI matrix is important because tests, punch items, evidence and final documentation involve many parties.

Activity	Owner	Commissioning	Supplier	Operations
Define acceptance criteria	A	R	C	C
Perform tests	I	C	R	C
Record evidence	I	R	R	I
Classify punch items	A	R	C	C
Validate technical acceptance	A	R	C	C
Receive training	A	C	R	R

This matrix prevents critical punch items from being left without ownership and acceptance from being signed without adequate validation.

RACI matrix in BIM design coordination

In multidisciplinary and BIM projects, the RACI matrix helps define responsibilities among coordination, modelers, designers, the owner, clash/design coordination and operations.

It can support decisions about who updates the model, who validates clashes, who approves changes, who is responsible by discipline and who must be informed in each review cycle.

This use complements the article on BIM Design Coordination.

RACI matrix vs. risk matrix

The RACI matrix and the risk matrix are different but complementary tools.

Tool	Purpose	Main question
RACI matrix	Define roles and responsibilities	Who does, approves, is consulted and is informed?
Risk matrix	Classify risks and priorities	What can affect the project and how should we respond?

In engineering projects, the risk matrix may identify a critical risk, while the RACI matrix defines who is responsible for treating that risk, who approves the response, who must be consulted and who needs to be informed.

Common mistakes when using a RACI matrix

Mistake	Consequence
Having several Accountable roles for the same activity	Slow decision or unclear ownership
Failing to define Responsible	Activity without an executor
Making everyone Consulted	Heavy and slow process
Informing too many people	Communication noise
Not validating the matrix with the parties	Low adoption during the project
Not updating after a scope change	Matrix becomes outdated
Confusing RACI with an organization chart	Focus shifts from activities to hierarchy
Not connecting the matrix to the contract	Risk of conflict between practice and contractual obligation

RACI does not replace the contract, organization chart, WBS or communication plan

One reason matrices become excessively large is the attempt to make RACI answer questions that belong to other instruments. The contract defines formal obligations, rights and responsibilities; the organization chart shows hierarchical relationships; the WBS decomposes scope; stakeholder analysis identifies influence, impact and engagement needs; the communication plan defines information, channel and frequency; the interface matrix controls boundaries and dependencies.

RACI connects some of these elements to day-to-day work. It helps answer who executes, who is accountable for the result, who should contribute before a decision and who needs to be informed. If there is a conflict between the matrix and a contractual obligation, the problem is not solved by “following the RACI”: the inconsistency must be analyzed and the formal source of authority preserved.

RACI and stakeholder analysis: C and I should not be chosen at random

The Consulted and Informed roles depend directly on understanding the stakeholders. PMBOK 8 describes stakeholder analysis using dimensions such as position, role, interest, expectations, attitude, knowledge and influence. The article on stakeholder analysis develops this logic for engineering projects.

A department may have low formal authority and still hold critical knowledge that requires consultation. Operations may not execute the project, but can be strongly affected by the solution and need to participate in requirements definition and acceptance. A regulatory body may not appear on the project team, but its decisions may condition milestones. Therefore, C and I should not be distributed solely according to hierarchy or the meeting attendee list.

Stakeholder mapping helps prevent relevant actors from being forgotten, while the stakeholder matrix helps prioritize the level of attention. RACI uses this information to answer a more operational question: in which activity or decision does that party actually need to act?

RACI and the communication plan: responsibility is not information flow

Marking a role as I does not mean copying it on every email. Marking a role as C also does not mean inviting it to every meeting. RACI identifies the need for participation; the project communication plan should define content, channel, timing, frequency, format and feedback mechanism.

ABNT NBR ISO 21502 advises that communication be planned according to stakeholder needs and that interactions be effective. A team may have a technically correct RACI and still fail because consultations occur late, decisions are not recorded, or informed people receive excessive volume without context. The matrix is an input to the communication system, not its substitute.

RACI and interface management: responsibility on both sides of the boundary

Technical and contractual interfaces are points where clarity of responsibility has direct impact. An interface exists because two or more elements depend on each other: they may exchange energy, signals, information, space, requirements, documents, data or operating conditions.

Imagine an integration between a security system and the corporate network. The integrator may be R for configuring its application; IT may be R for configuring the network under its administration; the owner may be A for an architecture decision; cybersecurity may be C and operations may be C or I. If the row simply says “integration,” multiple R roles appear to conflict. If parameters, deliverables and decisions are separated, responsibility becomes understandable.

Therefore, RACI and Interface Management need to work together. The interface matrix shows where dependencies exist; RACI helps organize who acts, who decides, who provides information and who should participate in closing the interface.

RACI in risks, issues and changes

ISO 21502 addresses risks and issues with clear assignment of responsibility and provides for escalation when a decision exceeds team authority. This logic is directly applicable to RACI. A project manager may be R for coordinating the analysis of an issue, while the sponsor is A for a decision that exceeds the delegated limit. Specialists participate as C and affected departments may be I or C.

In project risk management, defining a risk owner without clarifying their authority and interfaces can also create nominal responsibility. The risk register needs to identify who leads the response, who authorizes resources or changes and when the matter must be escalated.

In change control, the separation is even clearer: the requester is not necessarily the analyzer; the analyzer is not necessarily the authorizer; the implementer is not necessarily the verifier. A specific RACI for change control can prevent changes from being executed without impact analysis or valid approval.

RACI in requirements, verification, validation and acceptance

Engineering projects frequently treat preparation, review, verification, validation and acceptance as if they were the same act. They are not. Requirements management needs to identify who provides needs, who consolidates requirements, who verifies their implementation and who validates whether the solution meets the intended use.

In technical acceptance, a supplier may be R for performing tests and delivering evidence. A consultant may be R for analyzing results and recommending acceptance. The owner, however, may remain A for the formal decision. Making the consultant A simply because it performed the analysis can transfer, on paper, authority that was not contractually delegated.

RACI in contracts and Owner’s Engineering

The RACI matrix does not transfer contractual obligations. If the contract assigns the contractor responsibility for detailed design, an internal spreadsheet cannot remove that obligation. Likewise, the fact that an Owner’s Engineer reviews documents, witnesses tests or recommends decisions does not mean it becomes responsible for the contractor’s technical execution.

In Owner’s Engineering, RACI is particularly valuable for separating technical recommendation from the owner’s decision. The Owner’s Engineer may conduct Design Reviews, analyses, diligence, inspection, evidence verification and recommendations. Decisions related to budget, risk appetite, contractual changes and formal acceptance may remain with the owner.

How the delivery model changes the RACI matrix

The PMI Construction Extension available in the KB shows how engineering and construction projects bring together the owner, designer, constructor, specialists, regulatory bodies and other parties, and how responsibilities change according to the delivery strategy. Although it is a historical reference, this observation remains useful for understanding why a RACI should not simply be copied from one contract to another.

In design-bid-build, design and construction tend to be separate: the designer is responsible for design documentation, the contractor executes the work and the owner administers approvals and changes according to the contracts. In design-build, a single organization concentrates design and construction, reducing some external interfaces but retaining the need to separate production, verification and acceptance.

In EPC, the contractor assumes broad integration of engineering, procurement and construction. RACI must respect this allocation so as not to recreate owner micromanagement, while continuing to identify requirements, milestones, changes, external interfaces and acceptances that remain under the owner’s authority. In EPCM or multiple-package models, the number of interfaces increases because the management organization coordinates activities executed by other contractors.

Therefore, a technically sound RACI for EPC may be inappropriate for EPCM, Design-Build or fragmented contracting. The contract and delivery strategy are mandatory inputs to the matrix.

RACI changes throughout the project life cycle

Organization and responsibilities do not remain static. During concept development, the sponsor and owner concentrate investment decisions while specialists produce studies. During planning and basic design, requirements, interfaces and the contracting strategy come into focus. During detailed design, designers and vendors assume strong production responsibility, while coordination and Design Review gain importance.

During procurement and manufacturing, engineering, supply chain, legal and suppliers share different responsibilities. During implementation, field contractors, inspection, planning, safety and operations become more prominent. During commissioning and handover, responsibilities shift again toward testing, evidence, training, documentation, operational validation and acceptance.

This supports phase-specific matrices or a matrix controlled through revisions. The same “Owner” column may be A during concept development, C for certain design details and A again at final acceptance. Governance must follow the project’s evolution.

How to control RACI as a living document

A matrix that guides decisions must be controlled as project information. It should have an owner for maintenance, a version, date, scope of application, source of authority and review triggers. Changes in phase, supplier, organizational structure, contract, scope or authority delegation are events that justify review.

In environments with a DMS or CDE, the team should consult a single source of truth. Parallel local versions are especially dangerous because a responsibility update may be known by one department and ignored by another. The stakeholder register should also track relevant changes in roles, influence and participation.

Indicators that show whether RACI is working

RACI success is not measured by the number of completed cells, but by reduced ambiguity. Signs of low maturity include overdue decisions caused by unclear authority, activities started without a Responsible role, issues repeatedly escalated because of role disputes, changes implemented without approval, reopened interfaces and meetings whose recurring agenda is to discover “who should solve this.”

It is also useful to read the matrix vertically. A role marked A on almost every row can become a decision bottleneck; a discipline marked C everywhere can paralyze the flow; several R roles without boundaries may indicate that the row is too broad. Vertical analysis complements activity-by-activity analysis and helps identify organizational design problems.

How PMBOK 8 supports the use of the RACI matrix

PMBOK 8th Edition is an important reference for RACI use because it reinforces governance, value focus, stakeholders, resources, project focus areas, tailoring and procurement.

PMBOK 8 element	Application in the RACI matrix
Governance Performance Domain	Defines how decisions, responsibilities and oversight are organized
Stakeholders Performance Domain	Helps identify involved parties, influence and communication needs
Resources Performance Domain	Connects resources, teams and execution responsibilities
Scope Performance Domain	Connects responsibilities to deliverables and requirements
Focus Areas	Allows RACI to be applied in initiation, planning, execution, monitoring and closeout
Procurement Appendix	Supports definition of roles in contracting, suppliers, selection and contract management
Tailoring	Adapts the matrix to project size, complexity and criticality

Practical checklist for reviewing a RACI matrix

Question	Status	Note
Are all critical activities listed?	Yes / No / Partial	Avoid governance gaps
Does each activity have at least one Responsible?	Yes / No / Partial	Ensure a defined executor
Does each activity have only one Accountable?	Yes / No / Partial	Avoid decisions without ownership
Are the Consulted roles really necessary?	Yes / No / Partial	Avoid excessive consultation
Were the Informed roles defined deliberately?	Yes / No / Partial	Avoid communication noise
Is the matrix aligned with the contract?	Yes / No / Partial	Avoid conflict with formal obligations
Was the matrix validated with stakeholders?	Yes / No / Partial	Increase adoption
Will the matrix be updated when changes occur?	Yes / No / Partial	Maintain usefulness throughout the project

Technical references

[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 21502:2021 — Project, programme and portfolio management — Guidance on project management. Rio de Janeiro: ABNT, 2021.

[2] PROJECT MANAGEMENT INSTITUTE. The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 8th ed. Newtown Square: PMI, 2025. Available at: https://www.pmi.org/standards/pmbok.

[3] PROJECT MANAGEMENT INSTITUTE. Construction Extension to A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — 2000 Edition. Newtown Square: PMI, 2003.

[4] 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.

Frequently asked questions

What is a RACI matrix?

It is a responsibility matrix that associates activities or deliverables with the roles Responsible, Accountable, Consulted and Informed, making explicit who performs the work, who is accountable for the result, who must be consulted and who needs to be informed.

What does RACI mean?

RACI stands for Responsible, Accountable, Consulted and Informed.

What is the difference between Responsible and Accountable?

Responsible performs or coordinates the execution of the activity. Accountable is accountable for the result and final decision. A good matrix avoids multiple Accountable roles for the same activity.

How do you build a RACI matrix?

List activities or deliverables, identify the roles involved, assign R, A, C and I, review gaps and conflicts, validate with stakeholders and update the matrix whenever responsibilities or interfaces change.

Is a RACI matrix useful in engineering projects?

Yes. It reduces ambiguity among owners, designers, inspection, suppliers, operations and other parties, especially in interfaces, approvals, reviews, commissioning and acceptance.

Does a RACI matrix replace the contract?

No. RACI organizes operational and governance responsibilities, but it does not alter contractual obligations, legal competencies or formally established professional responsibilities.

Who should approve a RACI matrix?

Validation should involve those responsible for the main deliverables and decisions, especially whoever holds the Accountable role and the departments or organizations affected by the assignments.

When should the RACI matrix be reviewed?

Whenever there is a relevant change in scope, team, contract, supplier, project phase, responsibilities, interfaces or approval process.

Complementary technical materials

Related solutions

• Contract, Scope and Deliverables Management
• Requirements, Evidence and Acceptance Criteria Management
• Punch Items, RFIs and Nonconformity Management

Related services

• Engineering Project Management
• Owner’s Engineering

Main content on the topic

• Stakeholder Management in Projects: identification, engagement and communication
• Stakeholder Analysis: influence, impact, legitimacy, urgency and prioritization in projects
• Stakeholder Matrix: influence, interest, impact and prioritization in projects
• Interface Management in Engineering Projects

Related technical content

• Project Communication Plan
• Stakeholder Register
• Stakeholder Engagement
• Conflict Management in Engineering Projects