More initiatives than capacity.Prioritising IT investments with a clear rationale

In many organisations, the list of IT initiatives grows faster than the capacity to deliver them. Each one comes with a good reason: a new system for sales, replacing an ageing application, requirements from information security or regulation, first AI applications.

The problem is rarely a lack of ideas. What is missing is a shared basis for comparing them. Without one, priority goes to whoever argues loudest or asked last. And what is decided today is up for debate again tomorrow.

Every initiative is important. But where do we start, and what do we deliberately leave for later?

Why are IT initiatives so hard to compare?

Initiatives arrive in different shapes. Some are fully worked-out business cases, others a single line in the budget plan. The value usually arises in the business, while most of the effort falls on IT. The two are rarely described in the same language.

Initiatives also differ in nature. Some are mandatory, for example because an application reaches end of support or a regulation has to be implemented. Others are opportunities that could move the business forward. And some depend on each other without the proposals saying so.

Where does prioritisation with a clear rationale start?

With business goals, not with the list. Translate the few goals that really matter for the coming years into capabilities that need to improve. For example: processing orders faster, keeping customer data reliably in one place or bringing new products to market sooner.

Each initiative then states which goal and which capability it contributes to. Initiatives that cannot be linked to a goal are not automatically superfluous. But they need a reason of their own, for instance as a mandatory initiative or as a prerequisite for another one.

Which criteria belong on the table?

A few criteria, agreed in advance and applied equally to every initiative, are worth more than an elaborate model. These cover the essentials:

• Contribution to goals. Which capability improves, and how directly does it connect to an agreed goal?
• Mandatory or optional. Is there a legal, contractual or security requirement, or a deadline that cannot move?
• Effort and capacity. What does the initiative cost, and which people does it tie up, in the business as well as in IT?
• Risk. How uncertain is delivery? And what risk arises if the initiative does not go ahead?
• Dependencies and transition effort. Does the initiative depend on others, or block them? How much effort does it take to get from today’s state to the future one?

Before the assessment, agree what each criterion means. Otherwise the discussion shifts from the initiatives to the terminology.

What role does architecture play?

Many dependencies cannot be seen in individual proposals. Two initiatives change the same application at the same time. A seemingly small project needs an interface that does not exist yet. Another solves a problem that a planned consolidation would remove anyway.

An architecture view makes these connections visible: which business capabilities depend on which applications, where data originates and where it flows. This does not require a complete inventory. Start with the decision at hand and capture only what is relevant to it.

The result is not just a ranking but a sequence with a rationale.

How does a ranking become a roadmap?

A ranking says what matters. A roadmap says what will be delivered when. In between lie capacity, dependencies and the question of how much change the organisation can absorb at once.

A simple split helps:

• Now. Initiatives that are under way or starting with secured capacity.
• Next. Initiatives being prepared to move up as soon as capacity frees up.
• Later. Initiatives with recognisable value but no capacity at present.
• Not. Initiatives deliberately not pursued, each with a brief reason.

The last category is the most uncomfortable and the most valuable. Only once it is said out loud what will not happen do the remaining priorities become binding. Also plan a reserve. Unplanned mandatory work will come, reliably.

Who decides, and how often are priorities adjusted?

Prioritisation is not a one-off exercise but a question of governance. Define who submits and prepares initiatives, who decides and who delivers. The decision belongs in a forum where management, business units and IT sit together.

Agree a fixed rhythm for reviewing the roadmap, for example alongside budget or quarterly planning. In between, an initiative’s priority changes only if a key assumption changes, and only through the same forum. This protects teams from constant changes of course without making the organisation rigid.

How can you tell that prioritisation is working?

Not by a perfect list, but by changes in day-to-day work:

• Decisions are understood even by those whose initiative was deferred.
• Fewer initiatives run in parallel, and those that do move forward more steadily.
• Discussions are about criteria and assumptions, not about people.
• The roadmap is actually used in budget discussions.

If these signs are missing, the bottleneck is often not the method but unclear decision rights. That is the place to start.