Pugh Analysis Template: Compare Solutions Clearly

Start With the Options Already on the Table

If you have two or more solution options in front of you and someone is expecting a recommendation, a Pugh analysis template is one of the most practically useful tools you can reach for. It gives you a structured matrix that scores each option against weighted criteria, so the final recommendation is grounded in something more defensible than collective gut feel. I have used variants of this approach across government, utilities, and enterprise environments for over two decades, and the reason it keeps appearing in my toolkit is simple: it makes the reasoning visible, and that matters enormously when you are trying to get sign-off from people who did not participate in the evaluation.

The Pugh matrix, named after the design engineer Stuart Pugh, was originally developed for product design decisions. In practice, it works just as well for any situation where you need to select between competing system configurations, vendor proposals, process redesigns, or platform options. If you are already comfortable with how solution assessment criteria work, the Pugh template is the natural next step: it takes your criteria and turns them into a scored comparison.

How to Build the Template From Scratch

The structure is straightforward. You need a grid with your evaluation criteria running down the left-hand column, your solution options running across the top, and scoring cells in the body. You also need two additional columns for each criterion: a weight (how important is this criterion to the decision?) and, optionally, a datum column representing your baseline or current-state comparison point.

Here is the step-by-step build:

  • List your evaluation criteria first, before looking at the options. This is the discipline most teams skip. If you look at the options first, you unconsciously build criteria that flatter the option someone already prefers. Agree the criteria in a workshop or with your key stakeholders before any scoring begins.
  • Assign a weight to each criterion. Weights are typically expressed as a number from 1 to 5 or as a percentage of 100. The weighting reflects how much this criterion matters to the business outcome, not to the technical team or the loudest person in the room.
  • Define your scoring scale and stick to it. I use a simple 1 to 5 scale: 1 means the option barely meets this criterion, 5 means it meets it fully or exceeds it. Some practitioners use plus, minus, and same (S) symbols relative to a datum, which works well when you have a clear current-state baseline to compare against.
  • Score each option against each criterion independently. Try to do this before aggregating totals. The whole point of the matrix is to separate the per-criterion assessment from the overall conclusion.
  • Multiply each score by its weight to get a weighted score, then sum the column. The option with the highest total weighted score is the strongest performer against your agreed criteria. That does not automatically mean it is the right answer, but it is the starting point for your recommendation.

A Worked Example: CMS Platform Selection

I worked on a project at Organisation B, a large public-sector body, that needed to replace its ageing intranet and content management system. Three vendor platforms had passed an initial capability screen. The project team had a strong preference for Vendor 2 before the analysis even started, partly because one senior stakeholder had used it at a previous employer. The BA role on that engagement was mine, and my job was to produce a recommendation that the governance board would actually trust.

We ran structured workshops to agree the evaluation criteria before any vendor was discussed. The criteria we landed on were: ease of use for non-technical content authors, workflow and approval capability, search and discoverability, integration with the existing Active Directory environment, total cost of ownership over five years, and supplier support quality. These mapped closely to the organisation’s stated operational priorities. Each criterion was weighted from 1 to 5 in a second workshop, with the stakeholder group reaching consensus. Ease of use and workflow came out highest at weight 5 each.

Here is a simplified version of the matrix we produced:

Criterion Weight Vendor 1 Score Vendor 1 Weighted Vendor 2 Score Vendor 2 Weighted Vendor 3 Score Vendor 3 Weighted
Ease of use (non-technical authors) 5 4 20 3 15 5 25
Workflow and approval capability 5 3 15 5 25 4 20
Search and discoverability 4 4 16 4 16 3 12
Active Directory integration 4 5 20 4 16 3 12
Total cost of ownership (5 yr) 3 4 12 2 6 5 15
Supplier support quality 3 3 9 4 12 4 12
Total Weighted Score 92 90 96

Vendor 3 came out on top. The problem was that the senior stakeholder who had pre-committed to Vendor 2 was not happy. He immediately challenged the weighting of ease of use, arguing that the technical team’s workflow needs should be weighted higher. This is the friction moment that every Pugh analysis eventually produces, and it is actually the point where the tool earns its place.

Because the weights had been agreed in a stakeholder workshop before scoring, I had a written record of the rationale. I brought the group back together, walked through the sensitivity analysis (what would need to change for Vendor 2 to win?), and showed that workflow would need to be weighted at 8 out of 5 for the outcome to flip. That was not a defensible position given the organisation’s stated priority around serving non-technical content authors. The board approved Vendor 3. The senior stakeholder disagreed but accepted the process.

Common Mistakes That Undermine the Analysis

I have seen Pugh matrices produced after the decision has already been made, used to justify a preferred outcome rather than discover the best one. Here is how to avoid the most common traps:

  • Setting criteria after reviewing the options. This is the single most common error. Criteria must be set blind to the options, ideally by a group rather than by one person.
  • Using uniform weights for all criteria. If every criterion has the same weight, you are not making a decision matrix, you are making a count. Weight by business priority, not by what is easy to agree on.
  • Scoring by consensus in the room rather than by evidence. Scores should be traceable to something: a demo, a reference check, a technical assessment, a requirements compliance spreadsheet. If a score cannot be justified, it should not appear in the matrix.
  • Treating the total score as the final word. The matrix informs the recommendation, it does not replace judgement. A high-scoring option with a fatal constraint (a compliance failure, an unresolvable integration gap, a supplier with financial instability) may still be the wrong choice.
  • Failing to document the scoring rationale. When the decision is challenged six months later, and it will be, the narrative behind each score is your evidence. Record it alongside the matrix, not just the numbers.

What to Include in Your Pugh Analysis Template

A reusable template should have the following components ready to populate:

  • A criteria column with space for rationale. Each criterion should have a brief explanation of what it means and how it will be assessed, so that scorers are interpreting it consistently.
  • A weight column with an agreed scale. Document the weighting method and who agreed it. This is your protection against post-hoc challenges.
  • Option columns (up to six is workable; beyond that, consider a pre-screening step). Each option should be named clearly, with a reference to where its detail can be found.
  • Raw score and weighted score columns for each option. Keep both visible. The raw scores are where the per-criterion story lives; the weighted totals are the summary.
  • A sensitivity analysis section. At minimum, note which criteria are close-call differences between options and what the outcome would be if top-weighted criteria shifted by one point.
  • A recommendation narrative field. The matrix is evidence. The recommendation is a sentence or two that translates the evidence into a clear conclusion, including any caveats or conditions.

If you are working in an agile environment, the Pugh template fits comfortably into a spike or options analysis story. If you are working in a more formal waterfall or governance-driven environment, it belongs inside or alongside your business case or solution options paper. Either way, the output should be something a decision-maker can read in under five minutes and immediately understand.

How Many Options Should You Compare?

Three to five is the practical sweet spot. Fewer than three and you are not really comparing, you are validating. More than five and the matrix becomes unwieldy and the cognitive load on scorers starts to introduce noise. If you have six or more candidates, run a lightweight pre-screening against must-have criteria first and eliminate any that do not pass the threshold before building the full matrix. This mirrors the approach used in formal procurement settings, where long lists are reduced to short lists before detailed evaluation begins.

For product owners and BAs working on requirements prioritisation, the Pugh matrix can also be adapted for feature comparison rather than full solution comparison. Swap vendors for feature variants, keep the weighted criteria structure, and you have a tool that works equally well in sprint planning conversations as it does in architecture decisions.

Making the Recommendation Stick

The hardest part of any options analysis is not building the matrix, it is presenting the outcome to people who had a preferred answer before you started. The matrix gives you something concrete to point to. Walk your key stakeholders through the scoring row by row, not just the totals. Show where the preferred option scored well and where it did not. Acknowledge the close calls. If two options are within five percent of each other on weighted score, say so and explain the tiebreaker. A recommendation that arrives with its reasoning intact is far more durable than one that simply declares a winner. That transparency, more than the numbers themselves, is what makes a Pugh analysis worth doing.

Frequently asked questions

What is a Pugh analysis template used for?

A Pugh analysis template is used to compare competing solution options against weighted evaluation criteria, producing a scored matrix that supports evidence-based decision-making. It is commonly used by business analysts and product owners when selecting between vendor platforms, design options, or process alternatives. The template makes the reasoning behind a recommendation transparent and defensible to stakeholders and governance boards.

How do you weight criteria in a Pugh matrix?

Criteria are typically weighted on a scale of 1 to 5 or as a percentage of 100, reflecting how important each criterion is to the business outcome. Weights should be agreed by the relevant stakeholder group before any options are scored, to prevent bias toward a preferred solution. Documenting who agreed the weights and the rationale behind them protects the integrity of the analysis if it is challenged later.

What is the difference between a Pugh matrix and a standard decision matrix?

A standard decision matrix scores options against criteria using raw scores. A Pugh matrix extends this by assigning weights to each criterion and optionally benchmarking options against a datum, which is usually the current state or a baseline solution. The weighted scoring in a Pugh matrix produces a more nuanced result that reflects actual business priorities rather than treating all criteria as equally important.

How many options should I include in a Pugh analysis?

Three to five options is the practical range for a Pugh analysis. Fewer than three limits the value of the comparison, while more than five creates cognitive overload for scorers and can introduce inconsistency. If you have more than five candidates, use a pre-screening step to eliminate any that fail must-have criteria before building the full weighted matrix.

Can I use a Pugh matrix in agile projects?

Yes, a Pugh matrix works well in agile environments as a spike or options analysis activity. It can be used to compare feature variants, architectural approaches, or third-party integrations during discovery or planning. The template is lightweight enough to be completed in a single session and the output translates directly into a recommendation that can be referenced in backlog discussions or sprint reviews.

Try Ash, Your Virtual BA

If you have just worked through a Pugh analysis and you are now facing the task of writing up the options assessment, the recommendation narrative, or the supporting business case, Ash can help you produce those documents quickly and with the right structure. Ash is a virtual BA assistant built specifically for business analysis work, so it understands the language of weighted criteria, solution options, and governance-ready recommendations. Tell Ash what you are comparing and what your key criteria are, and it will help you structure a document your stakeholders can actually act on. Try Ash Virtual BA.

Further reading


Written by Sam Cordes, founder of the Business Analyst’s Toolkit.

We use cookies in order to give you the best possible experience on our website. By continuing to use this site, you agree to our use of cookies.
Accept