A practical way to review your IT strategy each quarter

A quarterly strategy review can consume a great deal of effort without changing a single decision. The roadmap gets new dates, completed work moves to another slide and the ambitions remain broadly the same.

I would use the review to test whether the choices behind the strategy still make sense. Delivery progress matters, but a project can be on schedule and no longer be the best use of the organisation's time.

The review should make room for that possibility without turning every quarter into a full strategy rewrite. Start with the decisions and assumptions already recorded, then inspect what has changed.

Bring the previous choices into the room

Use the existing decision record, current commitments and a concise account of material changes. Avoid asking teams to recreate every project update for a different audience.

For each strategic commitment, remind participants what problem it was meant to address, why it was chosen and what would have caused a different choice. If that reasoning was never recorded, reconstruct it openly rather than pretending it was clear all along.

Check the conditions attached to approval. Was funding conditional on a successful trial? Did the plan assume a business owner would provide staff? Did one investment depend on another completing first?

The approach in a strategy that survives the budget meeting gives this review a useful starting point. Without those explicit choices, the quarterly session can drift into a general conversation about everything technology might do.

Ask what changed outside the project plan

Look beyond delivery status. Business demand, supplier terms, staffing and risk exposure may have changed. A planned benefit may have become less valuable, or a previously minor problem may now justify earlier work.

Ask for evidence. Distinguish a changed business requirement from a new executive preference, and a confirmed supplier change from a rumour. Uncertainty can still justify investigation, but it should not be presented as settled fact.

Consider a fictional organisation that approved a reporting replacement because staff were manually reconciling two systems. A separate business decision now plans to retire one of those systems. The replacement project may be progressing well, yet its original scope deserves review.

That does not automatically mean cancellation. The remaining reporting requirement may still justify some work. The useful question is which portion of the investment continues to solve a problem the organisation expects to have.

Separate progress from evidence of value

A delivery milestone shows that work reached a defined point. It does not necessarily show that the intended business change occurred.

Ask owners for evidence appropriate to the stage. Early discovery might produce a clearer cost range or reject an unsuitable option. A pilot might demonstrate that users can complete the task. A live service should provide information about actual use and unresolved limitations.

Do not require mature benefits evidence from work that has not reached that stage. Equally, do not keep accepting activity reports from an investment that has been operating long enough to test its purpose.

Where evidence is missing, assign a specific check and date. "Benefits tracking to improve" is less useful than asking the process owner to inspect whether the old manual step is still being performed and why.

Make stopping a managed decision

Give each material investment an explicit disposition: continue as agreed, change scope, pause pending evidence or stop. Explain the reason and any conditions. Avoid quietly pushing an unwanted project further along the roadmap every quarter.

Stopping work requires an orderly close. Check contractual commitments, information created, temporary access and operating arrangements. Decide what should be retained and who will maintain any useful partial result. Tell the people affected before the next planning cycle assumes they are still committed.

Treat sunk effort honestly. The work already performed may provide useful learning, but it does not by itself justify spending more. Compare the remaining investment with the remaining expected value and alternatives.

For the fictional reporting project, a smaller close-out might preserve a reusable data definition while ending the replacement build. That is different from pretending the original project succeeded. Record what was learned and what will not be delivered.

Reallocate capacity before approving new starts

A stopped project does not instantly free every person or dollar. There may be transition work, notice periods or specialised skills that do not fit the next proposal.

Confirm what capacity becomes available and when. Check the support load and existing commitments before assigning it again. If the review adds work without removing or delaying anything, ask what assumption makes the addition feasible.

Keep the decision group small enough to act but broad enough to represent the consequences. Escalate matters beyond its authority through a defined route. A steering committee with a clear remit can help, but another standing meeting is not automatically necessary.

Publish the changes people need to act on

Send a short account of the decisions, owners and changed commitments. Update the roadmap and budget assumptions where necessary. Keep the previous record so people can understand why the position changed.

Be direct with sponsors whose work was stopped or deferred. They should hear the reason and any review trigger, not discover a missing line in a deck.

Finish by checking the unresolved questions. Give each one a route to a decision rather than leaving it until the next quarterly session by default. The review has done its job when teams know which commitments remain valid and which assumptions they no longer need to work around.