Seven priorities for technology leaders in 2027

Planning for 2027 is happening under more outside pressure than usual. Boards have a view on AI. Licence costs moved. Staff have already adopted tools nobody approved. Below is what earns a line in the plan, roughly in the order the work has to happen.

1. Decide what AI is actually for here

Most businesses now have a dozen small experiments and no funded program. The shift for 2027 is from experiments to two or three uses that have a named owner, a budget, and a number they are supposed to move.

That means saying no to the rest, in writing. An AI roadmap that keeps twenty ideas alive is a way of avoiding the decision, and it costs real money in licences and attention while it does.

2. Put a ceiling on what AI consumption can cost

Software licensing used to be a per-person number you could multiply. Agent and AI features are increasingly billed by usage, which means the bill moves with adoption — and adoption is the thing you are trying to encourage.

Before the first agent goes live, you want a forecast, a ceiling, and an alert. Not a policy document. A number, a limit, and someone who gets told when it is approached.

3. Fix the content estate before pointing anything at it

An assistant answers from what it can see. If permissions have drifted, if three versions of the same policy exist, if the current one lives in someone’s OneDrive, the assistant will find all of it and answer confidently from the wrong one.

This is the least glamorous item on the list and the one most likely to decide whether any of the rest works. It is also slow, which is why it belongs in the plan rather than in the month before a rollout.

4. Put a number on capacity

Most technology plans list what will be delivered and never state what the organization can actually absorb or build. The result is a roadmap that was never deliverable, discovered in month five.

Capacity is a count of the people available for project work, net of run and support. It is usually smaller than anyone expects, and having the number changes the conversation from “why is this late” to “which of these three do you want”.

5. Decide what happens to the applications you are tolerating

Every estate has applications that nobody has decided about: still running, no owner, no roadmap, one person who knows how they work. They are not urgent until the person leaves or the vendor stops supporting the version you are on.

Each one needs a decision — keep and invest, keep and leave alone, move, or retire — and a date. The decision matters more than which way it goes.

6. Make the reporting agree

If two reports disagree about revenue, every decision that uses either one is slower and less confident than it should be. This is rarely a tooling problem. It is that nobody owns the definition.

The fix is to settle the disputed measures with the people who argue about them, write the definitions down, and build one model everything else reads from.

7. Work out who decides what

Most escalation is a decision-rights problem wearing a different costume. Who can approve a new application. Who can commit to an integration. Who decides between two business units that both want the same team next quarter.

Writing this down takes an afternoon and removes a category of argument that otherwise recurs every month.

What can wait

A tooling consolidation with no business driver. A reorganization ahead of the operating model that justifies it. A data platform migration where the current one is not actually the constraint. Each of these is a real project that becomes urgent when something else makes it urgent — and expensive when it is done because it was next on a list.