Multi-Criteria Decision Analysis (MCDA) in Engineering Projects: How to Compare Technical Alternatives

Understand MCDA in engineering projects: criteria, weights, normalization, AHP, MAVT, outranking, TOPSIS, sensitivity, and technical alternative selection.

Check it out!

Multi-Criteria Decision Analysis, or MCDA, is a family of methods for structuring decisions in which several alternatives must be compared across multiple criteria that cannot naturally be reduced to a single measure. In engineering projects, MCDA applies when a solution must balance performance, reliability, safety, CAPEX, OPEX, schedule, maintainability, risk, sustainability, interfaces, and other trade-offs without pretending that one indicator can answer the entire decision.

MCDA is not a single method. Weighted matrices, AHP, multi-attribute value models, outranking methods, and techniques based on distance from ideal solutions belong to a broad family of approaches. The choice depends on the question, data type, whether compensation among criteria is acceptable, the number of alternatives, uncertainty, and the governance required. Applying “an MCDA spreadsheet” without declaring the method is therefore methodologically insufficient.

The central contribution of multi-criteria analysis is to make the decision architecture explicit. It separates mandatory requirements from preferences, structures objectives, defines criteria, records performance, models relative importance, tests sensitivity, and documents why a particular alternative was recommended. In Engineering Consulting, this process can connect Design Review, FEL, Business Case, TBE, Technical Authority, and Owner’s Engineering in a traceable decision chain.

What Is Multi-Criteria Decision Analysis — MCDA

MCDA is a field of decision analysis dedicated to problems with multiple potentially conflicting objectives or criteria.

The British Multi-Criteria Analysis manual describes a process that includes establishing the decision context, identifying options and objectives, defining criteria, assessing alternatives, weighting, combining weights and scores, and sensitivity analysis. INCOSE maintains a Decision Analysis Working Group dedicated to developing and promoting decision-analysis practices in Systems Engineering.

In engineering, MCDA addresses questions such as:

• which technical alternative offers the best overall balance?
• which architecture should advance to basic design?
• which technology preserves more value over the lifecycle?
• which solution meets requirements with acceptable risk?
• which trade-offs justify higher CAPEX?
• which alternative remains preferable under different scenarios?

The answer is not merely a ranking. It is a structure for technical argumentation.

MCDA Is Not Synonymous with AHP

AHP is one of the multi-criteria analysis methods.

The AHP Method in Engineering Projects uses a hierarchy, pairwise comparisons, and consistency checking to derive priorities.

MCDA is broader and includes different methodological schools.

Term	Scope
MCDA/MCDM	family of multi-criteria methods
Weighted matrix	simple additive model
AHP	pairwise comparison and hierarchy
MAVT/MAUT	multi-attribute value or utility models
ELECTRE/PROMETHEE	outranking families
TOPSIS	proximity to an ideal solution

There is no universally best method for every decision.

MCDA Is Not a Prioritization Matrix

A Prioritization Matrix may use multiple criteria to rank portfolio projects. MCDA, in this context, is applied mainly to selecting among technical alternatives for a defined decision.

Example:

• prioritization: which 20 retrofit projects should be executed first?
• multi-criteria decision: which retrofit technology should be used in the selected project?

The processes can connect, but they do not answer the same query.

MCDA Does Not Replace Mandatory Requirements

Compensatory criteria are dangerous when an alternative fails a mandatory requirement.

If a standard, contract, or operation requires a minimum capacity, a solution below that limit should not win because it costs less or has a better schedule.

Before MCDA, classify requirements as:

• mandatory;
• preferred;
• informational;
• conditional.

Requirements Management in Engineering Projects should provide the basis for this separation.

The Architecture of a Multi-Criteria Decision

A robust process can follow these steps:

The mathematical method appears in the middle of the process, not at the beginning.

Define the Decision Maker and Authority

An analysis may be prepared by consultants and specialists, but someone needs authority to decide.

Typical roles:

• sponsor;
• decision owner;
• Technical Authority;
• facilitator;
• discipline specialists;
• finance;
• operations;
• procurement;
• independent reviewer.

Technical Authority in Engineering helps formalize authority and independence in critical technical decisions.

Formulate the Decision Question

Generic questions generate generic criteria.

Instead of “what is the best solution?”, use:

Which electrical-supply alternative meets the project’s availability and safety requirements while minimizing TCO and implementation impact over a 15-year horizon?

The question makes explicit:

• function;
• requirements;
• context;
• horizon;
• priority dimensions.

Generate Alternatives Before Weighting Criteria

MCDA should not be used merely to choose among options brought by the dominant supplier.

During conceptual engineering, alternative generation may include:

• baseline solution;
• lower-CAPEX alternative;
• lower-TCO alternative;
• higher-performance alternative;
• modular alternative;
• hybrid alternative;
• do-nothing or defer alternative, where applicable.

Set-Based Design is complementary because it preserves options while information matures.

Criteria Should Derive from Objectives

A criterion should exist only if it helps measure a relevant objective.

Example of an objectives tree:

Technical objective: meet performance and availability.

Criteria:

• capacity;
• efficiency;
• availability;
• reliability.

Economic objective: minimize lifecycle cost.

Criteria:

• CAPEX;
• OPEX;
• TCO.

Implementation objective: reduce execution exposure.

Criteria:

• schedule;
• constructability;
• interfaces;
• shutdown requirement.

The structure should avoid “orphan” criteria with no link to an objective.

Criteria Should Be Complete, Nonredundant, and Operational

A good criteria set should cover relevant dimensions without counting the same characteristic twice.

Examples of redundancy:

• price, CAPEX, and acquisition cost;
• availability, uptime, and annual availability without distinction;
• supply schedule and lead time if they measure exactly the same event.

Also avoid vague criteria such as “quality” without an operational definition.

Prefer:

• failure rate;
• warranty;
• certifications;
• compliance with tolerances;
• support capability;
• demonstrated track record.

Quantitative and Qualitative Criteria

MCDA allows both to be combined, but the conversion method needs to be transparent.

Quantitative

• CAPEX currency value;
• OPEX per year;
• months;
• kW;
• Mbps;
• PUE;
• MTBF;
• availability;
• occupied area;
• consumption;
• emissions.

Qualitative

• technology maturity;
• ease of operation;
• flexibility;
• integration;
• maintenance complexity;
• local support;
• future adaptability.

Qualitative criteria need clear descriptors to reduce free interpretation.

Value Functions

A value function converts physical or economic performance into a preference scale.

The relationship may be:

• linear;
• range-based;
• convex;
• concave;
• with a threshold;
• saturated beyond a certain level.

Example: availability above 99.999% may add little value for an application whose requirement is 99.99%, while CAPEX increases sharply. The function does not need to reward indefinitely a performance level that already exceeds the required value.

Normalization

Criteria use different units. For aggregation, it is often necessary to place them on comparable scales.

Simple methods include:

• min-max;
• ratio to the best value;
• distance from target;
• value function defined by specialists.

The normalization choice can change the ranking.

The methodology should therefore be recorded and tested.

Benefit and Cost Criteria

Benefit criteria increase preference as the value increases.

Examples:

• capacity;
• efficiency;
• availability.

Cost criteria increase preference as the value decreases.

Examples:

• CAPEX;
• OPEX;
• schedule;
• consumption;
• footprint.

The method needs to handle this direction correctly.

Weights Represent Relative Importance

Weights are not alternative scores.

They represent how much a dimension contributes to overall preference within the model.

Weighting methods include:

• direct point allocation;
• swing weighting;
• AHP;
• pairwise comparison;
• trade-off weighting;
• structured workshops.

The choice depends on the MCDA method.

Weights Depend on the Scale

A methodological trap is asking for a criterion’s weight without specifying the relevant performance range.

If CAPEX varies only between BRL 10 million and BRL 10.2 million, while availability ranges from 95% to 99.999%, relative importance cannot be analyzed from criterion names alone.

Weight and value scale are interdependent in additive models.

Weighted Additive Model

The simplest form is:

V(a) = Σ wᵢ vᵢ(a)

where:

• V(a) = overall value of the alternative;
• wᵢ = weight of criterion i;
• vᵢ(a) = normalized value of the alternative on criterion i.

This structure is the basis of many weighted decision matrices.

The Decision Matrix in Engineering Projects shows the practical application of this simple form.

When Compensation Is Acceptable

Additive models allow compensation: poor performance on one criterion can be offset by strong performance on another.

This is acceptable only for preference criteria where a trade-off makes sense.

It is not acceptable to compensate:

• minimum safety;
• mandatory standard;
• required capacity;
• legal requirement;
• nonnegotiable interface condition.

When compensation needs to be limited, another method may be more appropriate.

AHP as an MCDA Method

AHP is useful when the problem has a hierarchical structure and decision makers can express relative preferences more naturally through pairwise comparisons.

It provides:

• derived weights;
• local and global priorities;
• consistency measurement;
• traceability of judgments.

Its limitations and rank-reversal issues need to be understood.

Multi-Attribute Value Models — MAVT

Multi-Attribute Value Theory structures value functions for criteria and combines preferences explicitly.

It is particularly useful when:

• value functions are well understood;
• quantitative criteria are strong;
• trade-offs need to be transparent;
• the decision can be modeled with compensation.

The UK government’s MCA manual uses an approach strongly aligned with weighted value models and sensitivity analysis.

MAUT and Risk

Multi-Attribute Utility Theory extends the logic to preferences under uncertainty and risk.

Utility is not synonymous with deterministic value. The concept incorporates attitude toward risk.

In engineering, it may be relevant when consequences and probabilities are central, but it requires more sophisticated elicitation.

Outranking Methods

Families such as ELECTRE and PROMETHEE do not necessarily depend on full compensation among criteria.

The logic may assess whether there is sufficient evidence to state that one alternative outranks another, considering:

• concordance;
• discordance;
• preference thresholds;
• veto.

This approach can be useful when very poor performance on a given criterion should not be easily compensated.

ELECTRE

ELECTRE methods were developed for multi-criteria decision problems using outranking relations.

They can include indifference, preference, and veto thresholds.

The methodology is more complex than a weighted matrix and requires justification for its parameters.

PROMETHEE

PROMETHEE also works with comparisons among alternatives and criterion-specific preference functions.

It can produce positive and negative preference flows and partial or complete rankings.

Its application is useful when the decision maker wants to model preference intensity without reducing everything to a simple linear sum.

TOPSIS

TOPSIS — Technique for Order Preference by Similarity to Ideal Solution — evaluates alternatives by their distance from a positive ideal solution and a negative ideal solution.

Intuitively, a good alternative should be close to the best performance on all criteria and far from the worst.

The method requires normalization and weights and can be sensitive to scale choices.

Which MCDA Method to Choose

Do not choose based on the software available.

Ask:

• is compensation among criteria acceptable?
• are there mandatory criteria?
• are weights easy to assign?
• is there a natural hierarchy?
• are criteria quantitative or qualitative?
• is uncertainty high?
• does the decision require a complete ranking or only a shortlist?
• do stakeholders disagree strongly?
• is executive transparency a priority?
• is there technical capability to apply and audit the method?

Practical Selection Guide

Situation	Possible approach
Simple decision, few criteria	weighted matrix
Difficult weights, hierarchical structure	AHP
Well-defined value functions	MAVT
Non-compensation and veto are important	outranking
Interest in proximity to ideal	TOPSIS
Uncertainty and risk attitude dominate	MAUT or probabilistic approach

The table is indicative, not prescriptive.

MCDA and Objective Data

Multi-criteria analysis should not replace metrics with opinions.

If there is:

• quoted CAPEX;
• calculated TCO;
• modeled availability;
• measured consumption;
• contractual schedule;
• certified efficiency;

use the data.

The method should transform evidence into a decision, not replace evidence with a subjective score.

Data Quality Should Appear in the Model

Two equal scores can have very different confidence levels.

Example:

• alternative A: efficiency measured in a test;
• alternative B: efficiency estimated in a brochure.

Treating both as equivalent data hides information risk.

Evidence quality can be recorded as metadata or as a separate criterion when genuinely relevant, while avoiding double counting.

Risk Criterion versus Risk in the Data

Do not confuse:

• risk of the alternative;
• uncertainty in the value used to assess the alternative.

A technology may have low operational risk while its CAPEX estimate is still highly uncertain.

The analysis needs to address both dimensions.

MCDA and Risk Analysis

MCDA can incorporate risks as criteria or use risk-analysis results as inputs.

Risk Analysis in Engineering Projects can provide:

• expected exposure;
• probability;
• severity;
• non-mitigable risks;
• response cost.

Do not turn every individual risk into a criterion unless necessary; this can explode the matrix and distort the weight of the risk dimension.

MCDA and Uncertainty

A deterministic analysis may use a single value for each criterion, but engineering projects involve ranges.

Examples:

• CAPEX: P50 and P80;
• schedule: probable range;
• availability: interval;
• demand: scenarios;
• service life: distribution.

Treatment options include:

• scenarios;
• sensitivity analysis;
• expected values;
• Monte Carlo;
• robust multicriteria methods.

Complexity should be proportional to materiality.

Sensitivity Analysis Is Essential

A ranking without sensitivity analysis is only a snapshot of the base assumptions.

Test:

• weights;
• scores;
• thresholds;
• economic rates;
• demand scenario;
• schedule;
• TCO;
• uncertain performance.

Sensitivity and Scenario Analysis in Engineering Projects helps identify switching values.

Univariate Sensitivity

Change one parameter at a time.

Example:

At what CAPEX weight does alternative B outperform A?

This crossover point is easy to communicate to a committee.

Multivariate Sensitivity

Criteria may change simultaneously.

Example:

• CAPEX +15%;
• schedule +4 months;
• availability -0.2 percentage point.

Combined scenarios can represent realistic execution conditions.

Ranking Robustness

An alternative is robust when it remains preferable across a broad range of plausible assumptions.

If the ranking changes with every small adjustment in weight, the decision is fragile.

Fragility does not mean the analysis failed. It may mean the alternatives are too close to justify a definitive decision with the information available.

Value of Information

When the ranking is sensitive, it may be worth buying information before deciding.

Examples:

• pilot;
• PoC;
• test;
• Site Survey;
• additional quotation;
• interoperability test;
• asset inspection;
• simulation;
• due diligence.

The cost of the study may be small compared with the value of avoiding a poor choice.

MCDA and the Business Case

The Business Case in Engineering Projects answers whether the organization should invest and why.

MCDA can select the technical alternative most aligned with the objectives. The Business Case then integrates:

• benefits;
• CAPEX;
• OPEX;
• TCO;
• DCF;
• risks;
• strategy;
• delivery capability.

Do not convert the entire Business Case into a single MCDA score if monetary values can already be modeled directly.

MCDA and Economic Analysis

Economic criteria can be inputs to MCDA, but NPV and TCO have their own meaning.

Evaluation using NPV, IRR, Payback, and ROI should remain transparent.

Example of good practice:

• calculate the NPV of each alternative;
• use NPV or TCO as an economic criterion;
• combine it with non-monetizable dimensions;
• also present the original monetary value to the committee.

MCDA and TCO

TCO and Life-Cycle Cost are particularly useful for preventing the lowest initial price from dominating the decision.

Alternatives may differ in:

• maintenance;
• energy;
• licenses;
• replacements;
• support;
• disposal;
• service life.

The economic criterion should represent the relevant horizon.

MCDA and FEL

In FEL — Front-End Loading, MCDA can support concept-selection gates.

FEL 1 may use parametric data. FEL 2 incorporates more Site Survey and engineering. FEL 3 may already include detailed estimates and quotations.

The same decision structure can mature without silently changing the criteria.

MCDA and Design Review

Design Review is an appropriate forum for reviewing:

• alternatives considered;
• requirements;
• criteria;
• method;
• weights;
• evidence;
• sensitivity;
• risks;
• interfaces;
• recommended decision.

The review should challenge the logic of the decision, not only the final design.

MCDA and Interfaces

An alternative that is technically excellent in isolation may create poor interfaces with existing systems.

Interface Management in Engineering Projects can provide criteria such as:

• number of interfaces;
• maturity of ICDs;
• need for gateways;
• third-party dependencies;
• integration complexity;
• commissioning risk.

Interfaces should be evaluated as real technical consequences, not as abstract preferences.

MCDA and Procurement

In procurement, MCDA can support a TBE when there are several preferential technical criteria.

TBE in Engineering should keep mandatory requirements, deviations, and documentation traceable.

If multicriteria scoring will be used to contract suppliers, governance needs to be defined before proposals are received, in accordance with the applicable process.

MCDA and Technical Requisition Scope

The Technical Requisition in Engineering should provide verifiable criteria.

If the TR is vague, the multicriteria analysis tends to score different interpretations of the scope.

Good decisions depend on good specifications.

MCDA and Owner’s Engineering

Owner’s Engineering can facilitate an independent analysis when:

• the designer favors its own solution;
• the supplier offers proprietary technology;
• internal areas have conflicting interests;
• the decision involves material CAPEX;
• the life cycle is long;
• the organization needs an auditable decision record.

Facilitator independence increases credibility, but the decision remains with the owner.

MCDA and Stakeholders

Stakeholders should not merely “vote on weights.”

Each group can contribute specific knowledge:

• operations: maintainability and usability;
• engineering: performance and interfaces;
• finance: cost of capital and TCO;
• procurement: market and supply chain;
• IT/OT: integration and cybersecurity;
• HSE: safety and compliance;
• management: strategy and schedule.

The process should structure disagreements rather than erase them through a simple average.

Multicriteria Workshops

A professional workshop should have:

• an approved decision question;
• comparable alternatives;
• criteria defined in advance;
• available evidence;
• a facilitator;
• judgment rules;
• decision records;
• subsequent sensitivity analysis.

If the workshop starts with “what score do we give each supplier?”, the structure has been skipped.

Bias and MCDA

MCDA is not immune to bias.

Risks include:

• anchoring;
• confirmation;
• availability;
• hierarchical pressure;
• framing;
• brand preference;
• overconfidence;
• adjusting weights after seeing the result.

The structure helps reveal these biases, but discipline is still required.

Criteria Created After the Result

This is one of the clearest signs of rationalization.

The criteria set may evolve if new information reveals a genuinely relevant dimension, but the change should be documented, justified, and reassessed for all alternatives.

A criterion should not be introduced merely to move the preferred solution into first place.

Numerical Precision Is Not Decision Precision

A score of 82.43 versus 82.12 does not prove material superiority.

If weights and scores contain uncertainty, the difference may fall within the noise of the model.

Present ranges, scenarios, or ranking stability when necessary.

Dominance

An alternative dominates another when it is at least as good on all relevant criteria and better on at least one, without violating constraints.

If clear dominance exists, complex methods may be unnecessary.

Before applying MCDA, eliminate dominated alternatives when methodologically appropriate.

Pareto Frontier

In multi-objective problems, alternatives may form a Pareto frontier: improving one objective requires worsening another.

These are the alternatives where the real trade-off occurs.

MCDA helps the decision-maker choose within this frontier based on explicit preferences.

Trade Studies in Systems Engineering

Systems Engineering uses decision analysis and trade studies to select solutions among alternatives that satisfy requirements.

INCOSE associates alternative selection with decision analysis and utility theory in systems engineering practices.

This context reinforces that MCDA is not merely a management tool; it is part of the decision engineering of complex systems.

MCDA and Systems Architecture

Architectural decisions are difficult to reverse and affect many interfaces.

Criteria may include:

• modularity;
• coupling;
• scalability;
• performance;
• safety;
• availability;
• testability;
• interoperability;
• cost of change;
• technology roadmap.

The analysis should occur before sunk cost makes change impractical.

MCDA and Obsolescence

Technology alternatives may have different support life cycles.

Relevant criteria:

• manufacturer roadmap;
• open standard;
• parts availability;
• firmware support;
• installed base;
• proprietary dependency;
• ease of migration.

Obsolescence may have a greater economic impact than a small difference in initial CAPEX.

Example: Critical-Power Architecture

Alternatives:

• N+1;
• 2N;
• distributed modular.

Criteria:

• availability;
• CAPEX;
• OPEX;
• efficiency;
• footprint;
• maintainability;
• schedule;
• expansion;
• common-mode failure risk.

A simple matrix may be sufficient if the weights are agreed. AHP can structure the weights if there is conflict. Outranking may be considered if strong non-compensation exists for certain criteria.

Example: Telecommunications Route

Radio, fiber, and hybrid alternatives can be evaluated by:

• capacity;
• latency;
• availability;
• physical diversity;
• CAPEX;
• licensing;
• maintenance;
• schedule;
• environmental exposure;
• scalability.

Minimum throughput and availability requirements should be filters.

Example: Electronic Security System

Architecture alternatives may differ in:

• coverage;
• retention;
• analytics;
• cybersecurity;
• integration;
• licenses;
• TCO;
• support;
• expansion;
• interoperability.

Scoring features alone can favor a more complex solution without verifying real benefit.

Example: Industrial Asset Retrofit

Alternatives:

• repair;
• partial retrofit;
• replacement.

Criteria:

• remaining life;
• CAPEX;
• TCO;
• future availability;
• shutdown duration;
• efficiency;
• parts;
• technical risk.

Asset-condition analysis is a critical source for the scores.

Example: Supplier Selection

After mandatory technical filters, suppliers can be compared by:

• performance above the requirement;
• warranty;
• schedule;
• support;
• manufacturing capacity;
• document quality;
• experience;
• supply-chain risk.

Commercial price should follow the defined governance and should not be hidden inside an arbitrary technical score.

Example: Facility Location

Criteria may include:

• access to power;
• telecommunications;
• logistics;
• land;
• licensing;
• climate risk;
• labor availability;
• infrastructure CAPEX;
• schedule;
• expansion.

This is a classic decision case in which no option dominates every dimension.

MCDA in Public Projects

Public decisions may combine economic, social, environmental, and technical impacts.

The British government MCA manual was developed specifically to support options appraisal in public policy and public-sector decisions.

The methodology needs to remain consistent with legislation and the formal criteria applicable to the specific process.

MCDA does not authorize creating criteria that were not provided for in a procurement process that has already been structured.

MCDA and Sustainability

ESG or environmental criteria should be operational, not slogans.

Examples:

• energy consumption;
• life-cycle emissions;
• water use;
• recyclability;
• noise;
• land use;
• toxicity;
• community impact.

Where possible, use physical metrics or LCA instead of generic “sustainability” scores.

MCDA and Carbon Cost

If the organization has an internal carbon price or a defined economic methodology, part of the environmental impact can be monetized and integrated into the Business Case.

Avoid counting the same effect twice as both a monetary cost and an environmental criterion without adjustment.

MCDA and Double Counting

Double counting can occur between:

• risk and contingency;
• CAPEX and TCO;
• energy and OPEX;
• availability and avoided loss;
• schedule and accelerated benefit;
• sustainability and carbon cost.

Before aggregation, map causal relationships among criteria.

MCDA and Causality

Criteria should represent relevant outcomes, not merely intermediate drivers that are already captured by another criterion.

Example:

• MTBF influences availability;
• availability influences production;
• production influences economic benefit.

Scoring all three without understanding the chain can triple-count the same effect.

MCDA and Incremental Economic Decision-Making

When two alternatives are mutually exclusive, it is useful to also show the incremental difference.

Question:

What does the additional CAPEX of alternative B buy in terms of performance, risk, and value?

MCDA can make these gains explicit. DCF verifies whether monetizable benefits justify the difference.

MCDA and Real Options

Some alternatives preserve flexibility.

Example:

• build full capacity now;
• implement an initial module and expand later;
• preserve an option for future technology.

Flexibility can be a criterion or, in sophisticated decisions, evaluated through real options.

Do not assign a high subjective score to “flexibility” if it can be quantified economically.

MCDA and Reversible versus Irreversible Decisions

The more irreversible the decision, the greater the rigor should be.

Choices involving structural architecture, a primary route, proprietary technology, or location usually carry a high cost of change.

A choice of an easily replaceable component may not justify a complex process.

Methodological Proportionality

The method should be proportional to:

• CAPEX value;
• criticality;
• irreversibility;
• number of stakeholders;
• complexity;
• uncertainty;
• regulatory exposure;
• impact of error.

Applying sophisticated MCDA to a trivial decision creates bureaucracy. Applying “lowest price” to a critical architecture creates risk.

How to Choose between a Simple Matrix, AHP, and a More Sophisticated Method

A practical rule:

Simple matrix

Use when:

• there are few criteria;
• data are clear;
• weights are agreed;
• compensation is acceptable.

AHP

Use when:

• weights need to be derived;
• hierarchy is important;
• relative judgments are natural;
• consistency needs to be reviewed.

Outranking or another MCDA method

Consider when:

• full compensation is inappropriate;
• thresholds matter;
• there is a veto;
• preferences are more complex.

Weight Governance

Weights should be defined before the final ranking is known whenever possible.

Record:

• who participated;
• method;
• rationale;
• version;
• disagreements;
• date.

If a weight changes, document the reason.

Score Governance

Each score needs:

• source;
• responsible person;
• data date;
• original unit;
• transformation applied;
• confidence level.

This allows the matrix to be audited without relying on workshop memory.

Decision Record

The decision package should contain:

• problem;
• objectives;
• requirements;
• alternatives;
• exclusions;
• MCDA method;
• criteria;
• value functions;
• weights;
• performance matrix;
• results;
• sensitivity;
• scenarios;
• risks;
• recommendation;
• decision;
• conditions;
• authority;
• version.

This artifact may become part of the Design Basis, Business Case, or trade-study report.

Configuration Control

Decision matrices are engineering documents and need version control when they influence a baseline.

A change in a requirement or alternative may invalidate the previous decision.

Preserve the version used at each gate.

MCDA and Change Management

When a material change arises after the decision, the organization may reopen the analysis.

Examples:

• a supplier exits the market;
• price changes materially;
• a standard changes;
• the cybersecurity requirement is raised;
• the schedule is compressed;
• an interface becomes infeasible.

The objective is not to defend the past choice, but to verify whether it remains valid.

Sunk Cost and Multicriteria Decision-Making

Sunk Cost in Engineering Projects should not keep an alternative in the ranking merely because it has already received investment.

At a new data date, compare what can still be decided.

Recoverable or reusable assets remain relevant as economic value.

MCDA and Value of Information

If an alternative loses only because one criterion relies on uncertain data, ask whether better measurement is worth obtaining before deciding.

A R$ 50 million decision may justify an additional R$ 100 thousand in testing if that meaningfully reduces the probability of error.

This reasoning is part of decision-oriented Engineering Consulting.

Common MCDA Errors

Starting with the software

A tool does not define the question.

Confusing MCDA with AHP

AHP is only one method in the family.

Scoring a mandatory requirement

This can allow improper compensation.

Creating redundant criteria

This duplicates influence.

Using scores without evidence

This turns opinion into false precision.

Normalizing without analyzing the effect

The normalization method can change the ranking.

Defining weights after seeing the result

This enables manipulation.

Not testing sensitivity

This hides fragility.

Ignoring data uncertainty

Scores appear more exact than the assumptions.

Hiding monetary value inside scores

This makes economic trade-offs harder to understand.

Using a complex method without audit capability

If no one can explain the calculation, governance gets worse.

Checklist before the Gate

Verify that:

• the decision question is clear;
• the alternatives are genuinely viable;
• mandatory requirements have been filtered;
• criteria derive from objectives;
• criteria are not redundant;
• original units are recorded;
• value functions are explicit;
• weights were defined before the ranking;
• the MCDA method was justified;
• scores have evidence;
• sensitivity analysis was performed;
• risks and uncertainties were addressed;
• NPV/TCO remain visible when relevant;
• the decision-maker and Technical Authority are identified;
• version and conditions were recorded.

If several items fail, the ranking should not support a CAPEX sanction by itself.

How to Present MCDA to Executives

A committee does not need all the mathematics on the first page.

The executive presentation can show:

• decision question;
• alternatives;
• knockout requirements;
• criteria and weights;
• ranking;
• main trade-offs;
• sensitivity;
• NPV/TCO;
• critical risks;
• recommendation.

The technical appendix retains the method and complete decision record.

How to Present Nearly Equivalent Alternatives

Do not force a false winner.

State:

• the small difference;
• parameters that change the ranking;
• information still required;
• tie-break criteria;
• the possibility of a pilot or negotiation.

A conclusion of “equivalence within current uncertainty” may be technically more correct than an artificial ranking.

When Engineering Consulting Adds Value

Technical Engineering Consulting adds value when the decision requires independence, multidisciplinary integration, and traceability.

The scope may include:

• problem structuring;
• requirements analysis;
• generation of alternatives;
• definition of criteria;
• selection of the MCDA method;
• workshops;
• weight and value modeling;
• integration with TCO and DCF;
• risk analysis;
• sensitivity;
• trade studies;
• recommendation report;
• support for Design Review and gate.

In high-impact decisions, the consulting function is to reduce uncertainty and make trade-offs auditable before the project commits to an architecture that is difficult to reverse.

Final Considerations

Multi-Criteria Decision Analysis is a discipline for decisions in which engineering must balance objectives that cannot be represented by a single metric. Its value does not lie in producing a sophisticated score, but in organizing requirements, alternatives, criteria, preferences, evidence, and uncertainty transparently.

MCDA is a family of methods. Weighted matrices, AHP, value models, outranking, and TOPSIS rely on different assumptions. The method selected should reflect the nature of the decision — especially whether compensation among criteria is acceptable, whether thresholds exist, whether weights are disputed, and whether the ranking needs to remain stable under changing scenarios.

In engineering projects, the process should remain connected to the physical and economic world. CAPEX and TCO should not disappear into scores; mandatory requirements cannot be compensated; objective data should prevail over judgment when available; and sensitivity analysis must show whether the recommendation is robust.

When properly applied, MCDA becomes a decision record: it documents why a particular alternative advanced, which trade-offs were accepted, which risks remained, and under which assumptions the gate was approved. This traceability is as important as the final ranking.

Technical references

[1] DEPARTMENT FOR COMMUNITIES AND LOCAL GOVERNMENT. Multi-criteria analysis: a manual. London, 2009. Available at: https://www.gov.uk/government/publications/multi-criteria-analysis-manual-for-making-government-policy

[2] INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING. Decision Analysis Working Group. West Lafayette: INCOSE. Available at: https://www.incose.org/group/decision-analysis-working-group/

[3] INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING. Systems Engineering Handbook. 5th ed. Information page. Available at: https://www.incose.org/resources-publications/technical-publications/se-handbook/

[4] INTERNATIONAL COUNCIL ON SYSTEMS ENGINEERING. Managing Priorities: A Key to Systematic Decision-Making. INCOSE International Symposium, 2005. Available at: https://www.incose.org/resource/11-4-2-managing-priorities-a-key-to-systematic-decision-making/

[5] SAATY, Thomas L. A scaling method for priorities in hierarchical structures. Journal of Mathematical Psychology, v. 15, n. 3, p. 234–281, 1977. DOI: 10.1016/0022-2496(77)90033-5. Available at: https://doi.org/10.1016/0022-2496(77)90033-5

[6] 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

Frequently asked questions

What is MCDA?

MCDA stands for Multi-Criteria Decision Analysis, a family of methods for comparing alternatives using multiple technical, economic, operational, environmental, or risk criteria.

Are MCDA and AHP the same thing?

No. AHP is one method within the MCDA family. MCDA also includes weighted matrices, multi-attribute value models, outranking methods, TOPSIS, and other approaches.

When should multicriteria analysis be used in engineering?

When there are several viable alternatives and the decision depends on trade-offs among criteria that cannot reliably be reduced to a single unit.

What is the difference between MCDA and a decision matrix?

A weighted matrix is a simple form of MCDA. Multicriteria analysis is a broader field and offers different methods depending on compensation, uncertainty, hierarchy, and preferences.

Should mandatory requirements be included as MCDA criteria?

They should generally be treated as compliance filters before comparison. Allowing compensation can cause a noncompliant alternative to win because of strong performance on secondary criteria.

How should the MCDA method be selected?

Assess whether compensation is acceptable, whether there is a criteria hierarchy, the type of data, uncertainty, the need for vetoes or thresholds, the number of alternatives, governance, and audit capability.

Does MCDA replace NPV or TCO?

No. Economic values should remain visible and be modeled directly whenever possible. MCDA integrates dimensions that are not appropriately reduced to money.

Why is sensitivity analysis necessary in MCDA?

Because weights, scores, thresholds, and data contain uncertainty. Sensitivity analysis shows whether the ranking is robust or whether small changes alter the preferred alternative.

Complementary technical materials

Related solutions

• Project, Program, and Portfolio Governance
• Process, Workflow, and Technical Approval Management
• Contract, Scope, and Deliverables Management

Related services

• Technical and Economic Feasibility Study
• Technical Engineering Consulting
• FEL — Front-End Loading
• Owner’s Engineering

Core content on this topic

• Decision Matrix in Engineering Projects
• AHP Method in Engineering Projects
• Business Case in Engineering Projects
• Set-Based Design in Engineering

Related technical content

• Technical Authority in Engineering
• TBE in Engineering
• Interface Management in Engineering Projects
• Sensitivity and Scenario Analysis in Engineering Projects
• Technical Requisition in Engineering