A project scoring model is the mechanism by which an IT organization moves from "which project should we prioritize" to a documented, defensible answer. Without one, approval decisions rest on relationships, urgency signals, and whoever makes the strongest argument in the room. With one, the same criteria apply to every request and the scores are comparable across projects and across time.
The model does not need to be complicated. Five criteria, clearly defined, with consistent weights produce better decisions than fifteen criteria that nobody scores honestly.
The five criteria that appear in every effective model
1. Strategic alignment
The most common first criterion. It asks whether this project directly supports a business goal the organization has stated for the current planning period. Not a general aspiration. A specific, named objective.
Scoring guide:
- 5: Directly enables a named strategic priority for this year
- 3: Supports a stated priority but is not the primary enabler
- 1: Neutral to stated strategy, internally beneficial
- 0: Misaligned with or contradicts current strategic direction
Practical example. An organization has stated a priority of expanding into the European market. A project to build GDPR compliance infrastructure scores a 5. A project to redesign the US customer portal scores a 2. Both have genuine value. Only one is directly serving the stated priority.
Typical weight: 25 to 35%
2. Business value
What does the organization gain from doing this project? Value can be measured as revenue generated, cost avoided, risk reduced, or customer impact. Some organizations score this as a dollar range. Others use qualitative bands.
Scoring guide:
- 5: Revenue or cost impact above a defined threshold (for example, more than $500K annually)
- 3: Moderate impact, between $100K and $500K
- 1: Small but real impact, below $100K
- 0: No quantifiable value, internal-only benefit with no measurable outcome
The dollar thresholds should match the scale of your organization. What matters is that the bands are defined in advance, not set to fit a particular project.
Typical weight: 20 to 30%
3. Urgency and deadline criticality
Some projects have hard external deadlines: regulatory requirements, contractual milestones, or date-certain market windows. Others are desirable but have no firm external deadline. This criterion separates the two.
Scoring guide:
- 5: Hard external deadline with legal, regulatory, or contractual consequence for missing it
- 3: Business-preferred deadline with real commercial consequences for slipping
- 1: Internally desired timeline, no external dependency
- 0: No specific deadline, can be deferred indefinitely without consequence
Typical weight: 15 to 25%
4. Risk of not doing it
This is separate from urgency. A project can have no specific deadline but carry a high cost if it is never done. A legacy system running without security patches may have no external deadline, but the risk of a breach grows every quarter it remains unaddressed.
Scoring guide:
- 5: Significant operational, regulatory, or financial risk if deferred
- 3: Moderate risk that grows over time without the project
- 1: Small, manageable risk if deferred for one to two quarters
- 0: No meaningful consequence if this work never happens
Typical weight: 15 to 20%
5. Resource fit and feasibility
A well-scored project that requires skills the organization does not have is a scheduling problem regardless of its priority score. This criterion flags resource feasibility before the governance body makes an approval decision.
Scoring guide:
- 5: All required skills are available in the current team with capacity to take on the work
- 3: Minor skill gaps, addressable with existing contractors or short-term hires
- 1: Significant skill gaps requiring new capability development or major recruitment
- 0: Required capability does not exist in the organization or its established vendor network
Typical weight: 10 to 15%
A worked scoring example
| Criterion | Weight | Project A | Project B | Project C |
|---|---|---|---|---|
| Strategic alignment | 30% | 5 (1.50) | 3 (0.90) | 4 (1.20) |
| Business value | 25% | 3 (0.75) | 5 (1.25) | 2 (0.50) |
| Urgency | 20% | 2 (0.40) | 4 (0.80) | 5 (1.00) |
| Risk if deferred | 15% | 2 (0.30) | 3 (0.45) | 4 (0.60) |
| Resource fit | 10% | 4 (0.40) | 2 (0.20) | 3 (0.30) |
| Total | 100% | 3.35 | 3.60 | 3.60 |
Projects B and C score identically. The governance body now needs to make a call with context the scoring model cannot capture: which team is less constrained, which dependency resolves first, which business sponsor's timeline has the harder consequence. The score gives the governance body a starting position. The discussion makes the final call.
How to set the weights
Weights should reflect what the organization actually values in this planning period. A healthcare organization facing a regulatory filing deadline will weight urgency and risk of non-delivery higher than strategic alignment. A technology company entering a new market will weight strategic alignment and business value more heavily.
The weights should not change quarter to quarter without a deliberate governance decision. When weights shift frequently, scores become incomparable across periods. A project that scored 4.2 in Q1 and 3.8 in Q2 may have done so not because its priority changed but because the weighting changed under it.
When to override the score
Scores are a starting point, not a verdict. A regulatory mandate that scores 4.2 may need to be treated as the top priority regardless of rank because missing the deadline has legal consequences the scoring model does not fully represent. A legacy system replacement that scores 3.0 may be a precondition for three higher-scoring projects and therefore functionally requires approval first.
Every override should be documented with a stated reason. The reason should be specific: not "strategic importance" but "this project is a prerequisite for Project X, which has a contractual Q4 delivery date." Undocumented overrides erode the model's credibility. When the governance body consistently ignores the scores without explanation, the model stops getting taken seriously.
Preventing the model from being gamed
Business stakeholders learn quickly how to fill out scoring forms. A criterion that says "strategic alignment" gets a 5 from almost every submitter within two cycles.
Three practices reduce gaming:
Require evidence for scores above 3. A strategic alignment score of 5 requires a citation from the current strategic plan. A business value score of 5 requires a business case with financial projections. No evidence, no high score.
Have the PMO normalize scores. Before presenting to governance, the PMO reviews all submissions and flags obvious outliers. A project that scores 5 on every criterion when the submitted business case is two sentences gets questioned before it reaches the room.
Require the submitter to defend high scores in the meeting. Stakeholders who know they will be asked to justify a score of 5 with specific evidence assign it less casually. The governance meeting should include a brief business case presentation for any request above a defined score threshold.
For how the scores feed into the governance decision, see the article on how to run a portfolio review meeting. For the intake process that brings requests to the scoring stage, see the guide on the IT work intake process.
Frequently Asked Questions
What criteria should an IT project scoring model include?
The five criteria that appear consistently in effective IT scoring models are strategic alignment, business value, urgency and deadline criticality, risk of not doing the work, and resource fit. Each is weighted according to organizational priorities, with weights adding to 100%.
How do you weight IT project scoring criteria?
Weights should reflect what the organization actually values. Regulated industries typically weight urgency and risk of non-delivery higher. Growth-stage companies typically weight strategic alignment and business value higher. Weights should remain stable across planning cycles so scores are comparable over time.
When should the governance body override a project score?
Overrides are appropriate when a regulatory mandate or contractual obligation makes a project non-negotiable, or when context the model cannot capture makes a lower-scoring project functionally essential. Every override should be documented with a specific, stated reason.
How do you prevent stakeholders from gaming the scoring model?
Require evidence for high scores, have the PMO normalize submissions before presenting to governance, and require submitters to defend high scores in the meeting. Stakeholders who know they will be asked to justify a score with specific evidence assign inflated scores far less often.