Engineering teams should weight concept selection criteria based on how directly each criterion affects the project’s primary objectives, the customer’s requirements, and the technical constraints that cannot be traded away. Criteria that govern safety, regulatory compliance, or core performance targets typically carry the most weight, while secondary factors like aesthetics or ease of manufacture carry less unless the brief specifically elevates them.
The weighting process is not arbitrary. It reflects the team’s understanding of what success actually means for a given project, which is why the same set of criteria can carry very different weights across different programs. The sections below address the most common questions engineering teams face when setting and applying these weights.
What factors determine how much weight each criterion should carry?
The weight assigned to a criterion should reflect how much influence that criterion has over whether the final design succeeds or fails. Criteria tied to non-negotiable requirements, such as structural integrity, regulatory certification, or mission-critical performance, should receive the highest weights. Criteria that affect desirable but optional qualities receive lower weights proportional to their actual impact on the outcome.
Several factors shape this judgment. Customer requirements and contractual specifications often define a floor: any criterion that appears in the formal requirements document carries inherent weight because failing it disqualifies the design outright. Technical risk is another driver. If a criterion addresses a known failure mode or a performance gap from a previous program, teams commonly increase its weight to ensure concepts are genuinely differentiated on that dimension.
Context matters as well. A criterion like noise output might carry minimal weight in an industrial pump design but becomes a dominant factor in aerospace applications, where regulatory certification and community noise standards impose strict limits. The same logic applies to weight and volume in any airborne system, where mass penalties cascade through the entire design.
A practical starting point is to rank criteria by consequence: ask what happens to the program if a design performs poorly on each criterion. Criteria where the answer is “the design is rejected or the program fails” should carry high weights. Criteria where the answer is “the design is less convenient or slightly more expensive” carry lower weights.
What are the most common methods for weighting selection criteria?
The most widely used methods for weighting concept selection criteria are direct assignment, pairwise comparison, and the analytical hierarchy process (AHP). Each balances rigor against the time and effort available to the team.
Direct assignment is the simplest approach: team members assign a numerical weight to each criterion, often on a scale of one to ten or as a percentage that sums to one hundred. It is fast and transparent, but it is vulnerable to anchoring bias, where the first number proposed shapes everyone else’s judgment.
Pairwise comparison removes that bias by asking a simpler question: between any two criteria, which matters more, and by how much? The team works through every possible pair and builds a weight table from the results. This approach surfaces disagreements that direct assignment tends to paper over, because it forces the team to make explicit trade-offs rather than assigning weights in isolation.
AHP formalizes pairwise comparison into a structured matrix that also checks for consistency in the team’s judgments. If a team says criterion A is more important than B, and B is more important than C, but then rates C as more important than A, AHP flags the inconsistency. This makes it particularly useful for complex programs where many criteria interact.
For most engineering teams working on component-level design and analysis, pairwise comparison offers the best balance between rigor and practical speed. AHP is worth the additional effort when the stakes are high and the team is large enough that individual biases could otherwise skew the outcome significantly.
How does the Pugh matrix handle criterion weighting in practice?
In a Pugh matrix, criterion weighting is applied by multiplying each concept’s score on a criterion by that criterion’s weight before summing across all criteria to produce a total score. This means a concept that performs well on high-weight criteria scores significantly better than one that performs well only on low-weight criteria, even if both receive similar raw ratings.
In practice, teams often run the Pugh matrix twice: once without weights to see the raw pattern of strengths and weaknesses across concepts, and once with weights applied to see how the ranking shifts. The comparison between the two runs is informative. If weighting dramatically changes which concept leads, it signals that the top-performing concepts are optimized for different priorities, and the team should examine whether the weights genuinely reflect the project’s goals.
One practical limitation is that Pugh matrices use relative scoring, typically rating each concept as better than, worse than, or the same as a reference concept on each criterion. When weights are applied to relative scores, small errors in the reference concept’s selection or in the scoring judgments can amplify into misleading totals. Teams working with weighted Pugh matrices should treat the final scores as directional rather than definitive, and use them to narrow the field rather than to select a winner mechanically.
Who should be involved in setting concept selection weights?
Criterion weights should be set by a cross-functional group that includes the lead systems engineer, the customer or customer representative, and the discipline leads whose work is most affected by the criteria being weighted. Decisions made by a single person or a single function tend to reflect that person’s or function’s priorities rather than the program’s actual requirements.
The customer’s voice is particularly important at this stage. Engineering teams sometimes weight criteria based on what they find technically interesting or technically tractable, rather than what the customer actually values. Involving the customer directly, or working from a validated requirements document that captures their priorities, keeps the weighting grounded in real program objectives.
For programs that cross into regulated domains, such as defense or civil aviation, a representative from the certification or compliance function should also participate. Regulatory requirements often impose weights implicitly: a criterion that must meet a certification threshold is effectively non-negotiable, and the weighting scheme should reflect that.
Teams working across defense engineering programs frequently find that involving a broader group at the weighting stage reduces conflict later in the design process, because stakeholders who helped set the weights are less likely to challenge the eventual concept selection on the grounds that their priorities were ignored.
When should criterion weights be revised during a project?
Criterion weights should be revised when the project’s requirements change, when new technical information significantly alters the feasibility of meeting a criterion, or when a formal design review reveals that the original weights were based on assumptions that no longer hold. Weights set at project initiation reflect the team’s understanding at that moment, and that understanding evolves.
The most common trigger for revision is a change in customer requirements or regulatory context. If a customer adds a new performance target or a regulatory body issues updated certification criteria, the weighting scheme must be reviewed to ensure it still reflects what success means for the program.
Technical discoveries also justify revision. If early testing or analysis shows that a criterion the team rated as easily achievable is actually a significant technical challenge, its weight may need to increase to ensure concept selection accounts for the difficulty. The reverse is also true: if a criterion that seemed risky proves to be well within reach, reducing its weight prevents the team from over-optimizing for a problem that has already been solved.
What teams should avoid is revising weights retroactively to justify a concept the team has already developed a preference for. Weight revision should be driven by new information about the problem, not by new preferences about the solution.
What are the most common weighting mistakes engineering teams make?
The most common mistake is treating all criteria as roughly equal in importance, either by assigning similar weights across the board or by using a scoring method that implicitly equalizes them. Equal weighting is rarely appropriate because real design problems almost always involve criteria that matter far more than others. Flattening the weights produces concept rankings that do not reflect the program’s actual priorities.
A second frequent error is weighting criteria based on what the team can measure easily rather than what actually matters. Criteria that are straightforward to quantify, such as mass or manufacturing cost, tend to receive high weights in practice even when they are secondary to harder-to-quantify factors like reliability or operational flexibility. Teams should resist this tendency and assign weights based on importance, then find ways to assess harder criteria rather than downweighting them because assessment is difficult.
A third pattern is failing to revisit weights after the concept selection phase. Teams that set weights early and then reference them again during detailed design reviews often find the original weights no longer fit the program’s current state. Treating weights as a living part of the decision framework, rather than a one-time input, produces more durable decisions.
Finally, teams sometimes allow the most senior voice in the room to set weights unilaterally, bypassing the cross-functional input that makes the weighting defensible. When weights reflect one person’s judgment rather than a structured team process, the concept selection loses credibility with stakeholders who were not involved, and the team is more exposed if the selected concept later underperforms.
How AneCom supports engineering concept evaluation
AneCom AeroTest works with engineering teams at the point where concept selection decisions have to be validated against physical reality. For gas turbine and aero-engine development programs, that validation often determines whether the weights assigned to performance criteria during the design phase were correct. AneCom’s testing and engineering services provide the data that makes those judgments defensible:
- Aerothermal component testing for compressors, combustors, and turbine assemblies, generating the performance data that concept selection criteria are built around
- Acoustic testing in Europe’s largest anechoic chamber, providing noise and fan system data that directly informs how noise criteria should be weighted in early-stage concept evaluation
- Instrumentation and measurement services that produce traceable, high-fidelity datasets for use in design reviews and concept down-selection
- Non-destructive testing services that support validation of structural and integrity criteria without damaging test hardware
If your team is at a stage where concept selection criteria need to be grounded in test evidence rather than analysis alone, contact AneCom to discuss how experimental validation can support your decision process.
Related Articles
- How can engineers design complex machinery to make assembly and maintenance easier?
- How do engineers evaluate technical risk when selecting a design concept?
- How does mechanical design change for highly loaded rotating systems?
- What is Design for Manufacture in mechanical engineering?
- What are the main design risks in high-speed rotating machinery?