Every business’s technology wish list is longer than its year: the server decision, the segmentation project, the phone system, the Wi-Fi that everyone hates, the new industry platform someone saw at a conference. Without a method, sequencing gets decided by whoever argued last, whatever broke most recently, or whichever vendor called — and the quiet, important projects lose to the loud, shiny ones every time. The fix is a small prioritization pass, run once a year and touched quarterly, that turns the debate into a sorted list. Here’s the method.
First cut: the forced moves aren’t projects — they’re the calendar
Before scoring anything, pull out the items that aren’t actually optional: end-of-support deadlines, expiring warranties on critical gear, the lease that ends, the compliance requirement with a date, the insurance renewal’s gap list. These aren’t competing for priority — they’re the fixed points the year gets built around, and mislabeling them as “projects under consideration” is how businesses end up doing forced migrations in a panic at premium prices. Schedule them first, at calm-season dates of your choosing; that’s the entire privilege of planning.
Second cut: score what remains on two axes
For the genuinely discretionary list, resist the ten-factor matrix (nobody maintains it) and score each project 1–3 on exactly two questions:
Risk retired. What exposure does this remove? The single point of failure, the detection gap, the aging hardware’s failure probability priced at your downtime number. A 3 means “this closes something that could genuinely hurt us”; a 1 means the risk story is a stretch.
Return delivered. Hours saved, friction removed, capability gained — in honest terms, ideally with a number (“the crew re-enters field data for ~5 hours a week”). A 3 pays for itself visibly; a 1 is a nice-to-have.
Plot the list. The high-risk-retired projects go first even when they’re invisible — this is the method’s entire spine, because security and resilience projects lose every popularity contest and win every incident retrospective. High-return follows. The double-3s are rare and jump the queue; the double-1s get the most valuable verdict on the list: a written no, not this year — a decision, revisitable, instead of a zombie item that haunts every meeting.
Third cut: sequence for dependencies and digestion
Scores rank; sequencing schedules, with three adjustments: dependencies first — the identity cleanup before Copilot, the inventory before the management rollout, the classification before DLP; half of failed IT projects are good projects attempted before their prerequisite · change digestion is real — the same team can’t absorb a phone system, a new ERP, and an office move in one quarter; spread the disruption the way the budget spreads the spend, and never adjacent to the busy season · and one slot stays empty — the year always delivers an unplanned project, and a full calendar makes it a crisis instead of a reshuffle.
Keeping it honest through the year
The list survives contact with reality through two habits: the quarterly review re-asks “did anything change the scores?” — a new client requirement, an incident, a near-miss that just re-priced a risk — and adjusts openly rather than via hallway decisions · and every mid-year insertion pays the same toll: score it on the two axes, name what it displaces. That one rule — new projects must displace, not stack — is what keeps the method from becoming a list of everything, which is where it started.
The bottom line
Project prioritization at small-business scale is three cuts: forced moves onto the calendar first, the rest scored on risk-retired and return-delivered, then sequenced for dependencies with room to breathe. It takes an afternoon a year, it gives the quiet critical projects their rightful place ahead of the shiny ones, and it replaces the perennial “what should we do first?” debate with a sorted list and a reason for every position — which is all a roadmap ever was.