English 
Português
To prioritize IT projects, link each request to a business objective, score projects against criteria and weights agreed with leadership, check team capacity, and validate cost, timeline and return estimates before approving anything. In seven steps: (1) gather every request; (2) tie each one to an objective; (3) define criteria and weights; (4) estimate with evidence; (5) score and rank; (6) balance the portfolio; (7) decide and review every quarter.
Businesses’ Scenario
In almost every company, demand for technology exceeds delivery capacity. Every department has an “urgent” project, budgets are finite, and a committee has to choose. When the choice rests on who pushes hardest, the cost shows up later. A McKinsey study of more than 5,400 projects found that large IT projects run 45% over budget, 7% over schedule and deliver 56% less value than predicted.
This guide shows how to prioritize IT projects from the perspective of the people who sponsor and fund them. It offers a seven-step method, a comparison of the main frameworks, a worked example with numbers, and the step that most teams skip: validating a project before scoring it.
What IT project prioritization is, and why it is a business decision
Prioritizing IT projects means setting, with explicit criteria, the order in which initiatives will be executed, weighing impact, urgency, cost, return and alignment with strategy. IT understands technical complexity, but the business understands the value of an initiative. The decision therefore has to be shared: the business defines what matters, and IT explains what is feasible and what it costs.
Prioritization also protects the IT team. Without clear criteria, the queue turns into a political contest, and the team spends its time firefighting instead of delivering value. As CIO.com notes, today’s IT leaders need to know not only how to prioritize initiatives but also when and how to say no to projects that will not advance business goals.
What poor prioritization costs
The price of a bad choice rarely appears on the day of the decision. It surfaces later as missed deadlines, rework and projects that deliver less than promised. A few data points help size the problem:
- According to McKinsey, each additional year of duration in a large IT project adds 15% to the budget overrun. The same study recommends managing strategy and stakeholders, not only budget and schedule.
- The Project Management Institute (PMI) found that organizations with high alignment between projects and strategy have, on average, 65% of strategic initiatives meeting their original goals, versus 35% in organizations with low alignment.
- In its 2016 Pulse of the Profession survey, PMI estimated that for every US$1 billion invested in projects, US$122 million is lost to poor performance. The 2018 edition reported that 35% of organizations lack strong alignment between initiatives and strategy, and that the top driver of projects meeting their goals is an actively engaged executive sponsor.
The conclusion is that the problem starts before execution: in the choice of what to do and in the quality of the estimates behind that choice.
How to prioritize IT projects in 7 steps
1. Gather every request in a single inventory
List everything competing for budget and people: new projects, enhancements, regulatory obligations and initiatives already under way. Without one inventory, each department defends its own list and the committee sees only part of the picture. For each item, record the sponsor, the problem it solves and an initial effort estimate.
2. Tie each project to a business objective
Every project should answer one question: which company goal does it help achieve? It could be reducing operating costs, growing revenue, meeting a regulation or improving the customer experience. A project with no clear objective leaves the list or goes back to be rewritten. This filter removes many requests before any scoring begins.
3. Define criteria and weights with leadership
Choose five to seven criteria and assign weights from 1 to 5 according to their importance to the business. Set them before looking at the projects, so the weights cannot be adjusted until they favor a particular initiative. A criteria-based matrix built in a workshop with the key stakeholders is a proven way to do this, and it replaces the biases of stakeholders who insist their project is the most critical without evidence.
4. Estimate value, cost, timeline and risk with evidence
This is the most fragile step of any method. Return and effort scores are only estimates, and an estimate without a basis is a guess dressed up as a number. When scope is still uncertain, validate it first: a structured discovery, such as NextAge’s Discovery & Blueprint, turns those estimates into data before the project enters the queue.
5. Score and rank
Give each project a score from 1 to 5 on each criterion, multiply by the weight and add up the results. The outcome is an objective ranking you can take to the committee and revisit when assumptions change. A full example appears later in this article.
6. Check capacity and balance the portfolio
An ordered list is not an executable plan. Check whether you have the people, budget and time window for what sits at the top, and consider dependencies: some projects can only start after others. Also remember that a portfolio made up only of high-priority projects is not sustainable. Balance short-term and long-term work, and be transparent about it.
7. Decide, communicate and review every quarter
Record the decision and the reason each project moved up, moved down or left the queue. Transparency reduces disputes and makes the process auditable. Review the order every quarter, and whenever strategy, budget or capacity changes.
Which criteria to use to prioritize IT projects
Criteria should reflect what the company values at that moment. A commonly used set:
| Criterion | Question it answers | How to measure |
|---|---|---|
| Strategic alignment | Does the project support a priority company goal? | Direct link to an objective or OKR |
| Financial return | How much does it save or generate? | Estimated ROI and payback period |
| Urgency and cost of delay | What do we lose each month without it? | Value lost per period; regulatory deadlines |
| Risk and compliance | Is there a legal obligation or operational risk? | Level of exposure; possible penalties |
| Effort and cost | How much does it cost and how long does it take? | Hours, budget, team required |
| Dependencies and capacity | Are there prerequisites and available people? | Dependency map; team allocation |
| Technical uncertainty | How much do we still need to find out? | Technical risk level; need for a proof of concept |
Avoid basing the decision only on financial criteria. They can leave out compliance, security and customer experience projects, which have real value even without a directly measurable return.
RICE, MoSCoW, value vs. effort or WSJF: which method to choose
There is no single best method. For the business leader, the most practical combination is a weighted score to build the ranking, cost of delay to break ties, and MoSCoW inside each project to define scope.
| Method | How it works | Best use | Limit |
|---|---|---|---|
| Weighted scoring | Scores of 1 to 5 on weighted criteria; the sum produces the ranking | Portfolios with competing objectives | Requires agreement across departments on weights and scores |
| WSJF and cost of delay | Cost of delay divided by job size | Tie-breaking and ordering the queue | Depends on estimating cost of delay well |
| RICE | Reach x Impact x Confidence ÷ Effort | Features and initiatives with measurable users | Can be slow and subjective |
| Value vs. effort | Four quadrants: do first, plan, do last, avoid | Quick triage in a workshop | Relies on intuition |
| MoSCoW | Must, should, could, won’t have in this release | Defining scope and an MVP | Does not rank projects against each other |
What they have in common is that all of them depend on estimates of value and effort. If those estimates are weak, the result will be weak too.
Worked example: ranking five projects
The example below is illustrative, with fictional data. The weights are: strategic alignment 5, financial return 4, risk and compliance 3, urgency 3 and ease of execution 2 (maximum score of 85). The score is the sum of weight x rating.
| Project | Alignment (5) | Return (4) | Risk/compliance (3) | Urgency (3) | Ease (2) | Total |
|---|---|---|---|---|---|---|
| A. Billing automation | 4 | 5 | 2 | 3 | 4 | 63 |
| B. Data privacy compliance in the CRM | 3 | 2 | 5 | 5 | 3 | 59 |
| C. Customer self-service app | 5 | 4 | 2 | 2 | 2 | 57 |
| D. Legacy ERP migration | 4 | 3 | 4 | 3 | 1 | 55 |
| E. AI agent for internal support | 3 | 3 | 3 | 2 | 3 | 48 |
Projects A and B go first. C and D sit only two points apart, and their order depends on the return and ease scores, which are estimates. In a tie like this, a blueprint with estimated scope, timeline, cost and ROI settles the question with data rather than opinion.
The step most teams skip: validate before you prioritize
Prioritizing IT projects on unvalidated estimates is ranking guesses. Before scoring a project, confirm the problem it solves, its scope, its cost and its expected return. That work is discovery, and it is what lets the ranking reflect the reality of the business.
The reason is economic. According to a NASA study summarized by Astadia, fixing a requirements error costs 8 times more during design, 16 times more after coding, 21 times more after testing and 29 times more after deployment. According to Karl Wiegers, rework can consume 30% to 50% of total development cost, and requirements errors account for 70% to 85% of that rework. Finding problems late is expensive.
That is what NextAge’s software discovery service, Discovery & Blueprint, does before the first sprint, in four steps:
- Immersion: a diagnosis of strategic goals, operational pain points and constraints. It feeds step 2, tying the project to a business objective.
- Scope definition: functional and non-functional requirements, technical dependencies and success criteria. It feeds step 3, the criteria.
- Prototyping and validation: navigable prototypes validated with decision-makers and end users. It confirms the value estimated in step 4.
- Business case: a document with timeline, cost, ROI and an execution plan. It gives the return and effort scores in step 5 a data-based foundation.
The result is a technical blueprint with documented scope, a risk map, a validated prototype, timeline and cost estimates and a phased roadmap, which supports approval by boards, directors and investment committees. The process is scaled to the size of the project, from early-stage digital products to large corporate modernization.
How to prioritize AI projects
AI projects concentrate the pressure to decide in 2026, along with the greatest uncertainty about return. According to Gartner, as reported by the National CIO Review, 40% of CIOs say they cannot point to the value they get from AI. Brazilian surveys show a similar picture. Logicalis’s IT Trends Snapshot 2025, with 129 IT executives, found that many investments are unstructured and lack clarity on ROI, and that around 3 in 10 companies have achieved concrete results. A survey by ABES and IDC Brasil of 107 IT decision-makers indicates that 86% of companies will increase their IT budgets in 2026, and that data governance is the main challenge in scaling AI.
A few practical rules:
- Start with the business problem, not the technology.
- Check data quality and availability before scoring.
- Require a result metric and a stopping criterion.
- Validate the use case at small scale before scaling. At this stage, a discovery phase reduces the risk of funding a pilot that never reaches production.
Common mistakes when prioritizing IT projects
- Deciding by who pushes hardest instead of by criteria.
- Changing criteria and weights in every round.
- Filling the portfolio with “high-priority” projects and no balance.
- Ignoring real team capacity and dependencies between projects.
- Looking only at financial criteria, leaving out compliance, security and customer experience.
- Scoring with unvalidated estimates.
- Prioritizing once and never reviewing.
Frequently asked questions
Which criteria should I use to prioritize IT projects?
The most common are strategic alignment, financial return, urgency or cost of delay, risk and compliance, effort and cost, and dependencies. Choose five to seven, assign weights with leadership and apply the same criteria to every project. Clear, objective criteria keep the decision from depending on who pushes hardest.
What is the difference between RICE, MoSCoW and a value vs. effort matrix?
RICE calculates a score from reach, impact, confidence and effort. MoSCoW sorts requirements into must, should, could and won’t have. A value vs. effort matrix places projects in four quadrants. RICE and value vs. effort rank initiatives; MoSCoW is better for defining the scope of a single project.
What is cost of delay?
It is the value a company fails to earn, or starts to lose, for each period a project is not delivered. In WSJF, you divide the cost of delay by the job size, and the highest result goes first. It is useful for breaking ties between projects with similar scores.
How do I justify an IT investment to the board?
Present a business case with the business objective, scope, timeline, cost, expected return, risks and execution plan. Numbers validated through prototypes and requirements analysis give a committee more confidence than informal estimates. A discovery such as NextAge’s Discovery & Blueprint produces this material before development starts.
When does a project need discovery before entering the queue?
When the objective, scope or estimates are still uncertain, when it involves several departments or integrations, or when the investment is large. If you cannot state timeline, cost and return with confidence, validate before scoring; otherwise the ranking reflects guesses.
How often should I review priorities?
Every quarter, and whenever strategy, budget or capacity changes. A prioritization done once loses validity quickly. Record why each project moved up, moved down or left the queue, so the decision stays transparent and auditable.
Conclusion
Prioritizing IT projects is a business decision that needs clear criteria, agreed weights and reliable estimates. The seven-step method organizes the choice; validation up front makes sure the numbers behind the ranking are real.
Want to take your portfolio to the committee with numbers instead of opinions? Talk to a NextAge specialist. The first conversation is free and carries no commitment, and it shows what is still open in your project planning.
