Six months into the year is a good moment for a mid-year technology review, not because it's a milestone anyone celebrates, but because it's early enough to still change course and late enough that you have real data instead of January's plans and hopes. Most owners skip this until the annual budget review, by which point a stalled project has quietly cost six more months of subscription fees and team attention.
This isn't a full audit. A full audit takes weeks, needs a consultant, and usually produces a report that sits in a drive folder. What I'm proposing is six questions, answerable in one meeting, that force a real decision instead of a status update.
The discipline that makes this useful isn't the questions themselves, it's the willingness to kill one thing publicly by the end of the meeting. If nothing gets cut, you didn't do a review, you did a status meeting.
Question 1: What actually shipped this year?
Not "what did we start," what shipped and is in use today. List every technology initiative from January: new software, an automation project, a platform migration, an AI pilot. For each one, mark it shipped, in progress, or stalled.
Be honest about "in progress" past month four. A project genuinely in progress has a visible next milestone and someone accountable for it. A project quietly stalled has neither, it just hasn't been declared dead.
Question 2: What stalled, and why?
For everything not shipped, ask the actual reason, not the polite one. The common real reasons are:
- The scope was bigger than anyone admitted at kickoff.
- There was no single owner, so it fell between two people's job descriptions.
- Priorities shifted and nobody formally deprioritized it, it just stopped getting attention.
- It depended on a decision (budget, vendor, hire) that never got made.
Each of these has a different fix. Scope problems need re-scoping, not more time. Ownership problems need a name attached, not a team. Priority problems need an explicit "not this year" instead of silent neglect.
Question 3: What are we paying for that nobody uses?
This is the fastest win in any mid-year technology review, and it's almost always bigger than expected. Pull the last three months of software subscription charges and, line by line, ask who used this tool in the last 30 days. In our experience running this exercise with SME clients, 15-25% of the software line item is paying for licenses nobody has logged into in over a month.
We've written a full breakdown of this pattern in Subscription Creep: The Silent Leak in Your Tech Budget, and it's worth pulling up alongside this review, because the fix (cancel, downgrade, consolidate) is usually a same-day action once you see the list.
Question 4: Does our stack still match how the business actually works?
Software gets chosen to fit the business at a point in time. Six months on, the business has usually changed, headcount, product mix, customer volume, and the software hasn't been re-evaluated against that change. A tool that made sense for a 10-person team can become the bottleneck for a 25-person team, and nobody notices until someone complains loudly enough.
Ask specifically: has any tool become the thing people work around rather than work with? Workarounds are the clearest signal of a stack that's aged out of fit.
Question 5: What's on the roadmap for the second half that shouldn't be?
This is where most reviews get soft, because it means questioning a plan someone is already attached to. Push through it anyway. For every initiative planned for the next six months, ask the 90-day version of the equity-hour test: does this need to happen now, with these resources, or is it filling a slot because it's on a plan from January that nobody revisited.
If you're building a plan for the second half, keep it to one page. We cover the format in The One Page Digital Strategy Every SME Can Write, and a mid-year review is the natural moment to rewrite that page rather than patch the old one.
Question 6: What are we going to kill, out loud, today?
This is the question that makes the other five worth asking. Pick one project, subscription, or initiative from the list above and end the meeting with a public decision to stop it. Not "we'll revisit," a decision.
Killing something publicly does two things a private decision doesn't: it frees the budget and attention immediately, and it signals to the team that the review actually changes things, which makes the next review get taken seriously too.
Building the review into a table
A simple way to run this in one sitting is a table everyone can see during the meeting:
| Initiative | Status | Real reason if stalled | Keep / Cut / Fix |
|---|---|---|---|
| CRM rollout | In progress | No single owner | Assign owner, 60-day deadline |
| Old inventory tool | Shipped, unused | Replaced by new system | Cut subscription |
| AI support pilot | Stalled | Budget never approved | Fix: get a decision this week |
Filling this out honestly for everything on your list is the entire exercise. It doesn't need software, a facilitator, or a deck.
The takeaway
A mid-year technology review that produces a report is theater. One that produces a cancelled subscription, a reassigned owner, and one killed project is worth the hour it takes. Book one hour before July, bring the last six months of subscription statements, and don't leave the room until something is actually cut. If you want a second opinion on where your stack has drifted from what the business needs, that's exactly the kind of conversation to start at /partner.