How to Decide Which IT Projects to Do First

Most companies don’t struggle because they lack IT ideas. They struggle because they try to do too many things at the same time.

New requests keep coming. Everything feels important. And decisions end up being driven by urgency, pressure, or whoever asks loudest.

If you want IT projects to actually finish — and deliver value — this is how to decide what comes first.

Step 1: Separate ongoing work from real projects

Not everything that feels important should be treated as a project.

A simple test:

If we do nothing, will the business still operate tomorrow?

If yes, it’s ongoing work. If no, it’s likely a project.

Support tasks, fixes, and small improvements shouldn’t compete with real projects for priority. When everything is labeled a “project,” nothing is prioritized properly.

Step 2: Group projects by why they exist

Instead of ranking all projects from 1 to 20, group them by intent.

Common groups:

• Projects that fix something broken
• Projects that reduce risk
• Projects that remove friction
• Projects that support growth

A system fix should never compete with a growth initiative. They solve different problems and require different decisions.

Step 3: Focus on the cost of waiting, not the benefit

Most teams ask:

What will we gain if we do this?

A better question is:

What gets worse if we don’t do this in the next 3–6 months?

Look for:

• Growing manual work
• Increasing dependency on one person
• Higher chance of failure
• More workarounds being added
• Rising customer or operational impact

Projects with a rising cost of waiting should move up the list, even if they’re not exciting.

Step 4: Check how disruptive each project is

Many projects fail not because they’re hard, but because they disrupt too many people at once.

For each project, ask:

• How many teams need to change how they work?
• How much coordination is required?
• Are teams ready to absorb the change?

High disruption combined with low readiness almost always leads to delays.

Sometimes the right decision is to delay a good project until the organization is ready for it.

Step 5: Limit how many projects can run at the same time

This is the hardest step — and the most important.

Running too many projects doesn’t speed things up. It slows everything down.

A practical rule:

• Small teams: no more than 2–3 active IT projects
• Medium teams: no more than 3–5

Fewer projects mean faster delivery, less context switching, and better results.

Step 6: Make it clear who decides priorities

When ownership isn’t clear, priorities change quietly.

To avoid this:

• Assign one role to own IT project prioritization
• Document decisions
• Require justification when priorities change

It’s what keeps teams focused and prevents constant resets.

Step 7: Review priorities quarterly, not weekly

Constant reprioritization kills momentum.

Set a simple rhythm:

• Review the project list every quarter
• Only change priorities mid-quarter for real emergencies

This gives teams stability and protects progress.

When prioritization becomes a full-time job

As businesses grow, prioritizing IT projects becomes harder:

• More dependencies
• More stakeholders
• More pressure
• More risk

At this point, many companies bring in IT leadership to own this responsibility.

A CIO+ by eXceeders helps by:

• Connecting projects to business goals
• Balancing risk, effort, and impact
• Reducing noise and pressure on teams
• Keeping focus on what truly matters

Final thought

If you want support in structuring your IT priorities and keeping focus on what truly matters, learn how CIO+ can help here:👉 https://www.exceeders.com/pages/cio-plus-lb